diff -Nrc3pad gcc-3.0.1/.brik gcc-3.0.2/.brik *** gcc-3.0.1/.brik Sun Aug 19 22:50:26 2001 --- gcc-3.0.2/.brik Tue Oct 23 11:37:15 2001 *************** *** 3,30 **** # CRC-32 filename # ------ -------- - 4294967295b ./.brik 2864072627b ./.cvsignore ! 873677691b ./BUGS 2171125041b ./COPYING 508743035b ./COPYING.LIB ! 226845448b ./ChangeLog ! 4244897222b ./FAQ ! 3826647863b ./GNATS 2229468985b ./INSTALL/README ! 3837555366b ./INSTALL/binaries.html ! 3242873726b ./INSTALL/build.html ! 3927920424b ./INSTALL/configure.html 1964338015b ./INSTALL/download.html ! 2951706212b ./INSTALL/finalinstall.html 4063529934b ./INSTALL/index.html ! 1238341873b ./INSTALL/specific.html 2369737775b ./INSTALL/test.html ! 3015795079b ./MAINTAINERS 253028645b ./Makefile.in 3697693037b ./README 3461973635b ./boehm-gc/BCC_MAKEFILE ! 227979088b ./boehm-gc/ChangeLog 4012707064b ./boehm-gc/EMX_MAKEFILE 145946109b ./boehm-gc/MacOS.c 591574792b ./boehm-gc/MacProjects.sit.hqx --- 3,29 ---- # CRC-32 filename # ------ -------- 2864072627b ./.cvsignore ! 1333652262b ./BUGS 2171125041b ./COPYING 508743035b ./COPYING.LIB ! 3674160514b ./ChangeLog ! 3468455665b ./FAQ ! 2513020160b ./GNATS 2229468985b ./INSTALL/README ! 2762343880b ./INSTALL/binaries.html ! 2525189791b ./INSTALL/build.html ! 2861585075b ./INSTALL/configure.html 1964338015b ./INSTALL/download.html ! 688694853b ./INSTALL/finalinstall.html 4063529934b ./INSTALL/index.html ! 1619414355b ./INSTALL/specific.html 2369737775b ./INSTALL/test.html ! 585133217b ./MAINTAINERS 253028645b ./Makefile.in 3697693037b ./README 3461973635b ./boehm-gc/BCC_MAKEFILE ! 3209638649b ./boehm-gc/ChangeLog 4012707064b ./boehm-gc/EMX_MAKEFILE 145946109b ./boehm-gc/MacOS.c 591574792b ./boehm-gc/MacProjects.sit.hqx *************** *** 70,78 **** 4184632247b ./boehm-gc/blacklst.c 971406525b ./boehm-gc/callprocs 3725131560b ./boehm-gc/checksums.c ! 482688713b ./boehm-gc/configure 202677859b ./boehm-gc/configure.host ! 1706589819b ./boehm-gc/configure.in 697594862b ./boehm-gc/cord/README 248857674b ./boehm-gc/cord/SCOPTIONS.amiga 722115270b ./boehm-gc/cord/SMakefile.amiga --- 69,77 ---- 4184632247b ./boehm-gc/blacklst.c 971406525b ./boehm-gc/callprocs 3725131560b ./boehm-gc/checksums.c ! 124915759b ./boehm-gc/configure 202677859b ./boehm-gc/configure.host ! 1207654743b ./boehm-gc/configure.in 697594862b ./boehm-gc/cord/README 248857674b ./boehm-gc/cord/SCOPTIONS.amiga 722115270b ./boehm-gc/cord/SMakefile.amiga *************** *** 106,112 **** 2971863704b ./boehm-gc/gc_private.h 3286861254b ./boehm-gc/gc_typed.h 3458300802b ./boehm-gc/gcc_support.c ! 1173157971b ./boehm-gc/gcconfig.h 81686212b ./boehm-gc/gcj_mlc.c 2300078171b ./boehm-gc/headers.c 2358466284b ./boehm-gc/hpux_irix_threads.c --- 105,111 ---- 2971863704b ./boehm-gc/gc_private.h 3286861254b ./boehm-gc/gc_typed.h 3458300802b ./boehm-gc/gcc_support.c ! 2802741123b ./boehm-gc/gcconfig.h 81686212b ./boehm-gc/gcj_mlc.c 2300078171b ./boehm-gc/headers.c 2358466284b ./boehm-gc/hpux_irix_threads.c *************** *** 134,140 **** 57220927b ./boehm-gc/include/private/gcconfig.h 2262051120b ./boehm-gc/include/weakpointer.h 705894296b ./boehm-gc/linux_threads.c ! 2186548913b ./boehm-gc/mach_dep.c 4294967295b ./boehm-gc/makefile.depend 651387412b ./boehm-gc/malloc.c 2906986244b ./boehm-gc/mallocx.c --- 133,139 ---- 57220927b ./boehm-gc/include/private/gcconfig.h 2262051120b ./boehm-gc/include/weakpointer.h 705894296b ./boehm-gc/linux_threads.c ! 4277754409b ./boehm-gc/mach_dep.c 4294967295b ./boehm-gc/makefile.depend 651387412b ./boehm-gc/malloc.c 2906986244b ./boehm-gc/mallocx.c *************** *** 155,161 **** 2022551282b ./boehm-gc/rs6000_mach_dep.s 3292223258b ./boehm-gc/setjmp_t.c 3718957139b ./boehm-gc/solaris_pthreads.c ! 4150894395b ./boehm-gc/solaris_threads.c 1458967877b ./boehm-gc/solaris_threads.h 3705733266b ./boehm-gc/sparc_mach_dep.s 293721320b ./boehm-gc/sparc_sunos4_mach_dep.s --- 154,160 ---- 2022551282b ./boehm-gc/rs6000_mach_dep.s 3292223258b ./boehm-gc/setjmp_t.c 3718957139b ./boehm-gc/solaris_pthreads.c ! 1880901174b ./boehm-gc/solaris_threads.c 1458967877b ./boehm-gc/solaris_threads.h 3705733266b ./boehm-gc/sparc_mach_dep.s 293721320b ./boehm-gc/sparc_sunos4_mach_dep.s *************** *** 167,178 **** 3707632643b ./boehm-gc/version.h 2262051120b ./boehm-gc/weakpointer.h 4042937657b ./boehm-gc/win32_threads.c ! 1773423874b ./bugs.html 3139906847b ./config-ml.in 1152210207b ./config.guess 3430029098b ./config.if 572719696b ./config.sub ! 2984923331b ./config/ChangeLog 612455112b ./config/acinclude.m4 3007349820b ./config/mh-a68bsd 1442196770b ./config/mh-aix386 --- 166,177 ---- 3707632643b ./boehm-gc/version.h 2262051120b ./boehm-gc/weakpointer.h 4042937657b ./boehm-gc/win32_threads.c ! 1430989246b ./bugs.html 3139906847b ./config-ml.in 1152210207b ./config.guess 3430029098b ./config.if 572719696b ./config.sub ! 3998075193b ./config/ChangeLog 612455112b ./config/acinclude.m4 3007349820b ./config/mh-a68bsd 1442196770b ./config/mh-aix386 *************** *** 216,222 **** 456622165b ./config/mh-vaxult2 3265825290b ./config/mh-x86pic 198559626b ./config/mpw-mh-mpw ! 1200430146b ./config/mpw/ChangeLog 3145098931b ./config/mpw/MoveIfChange 1476422091b ./config/mpw/README 4005879853b ./config/mpw/forward-include --- 215,221 ---- 456622165b ./config/mh-vaxult2 3265825290b ./config/mh-x86pic 198559626b ./config/mpw-mh-mpw ! 2151949570b ./config/mpw/ChangeLog 3145098931b ./config/mpw/MoveIfChange 1476422091b ./config/mpw/README 4005879853b ./config/mpw/forward-include *************** *** 244,258 **** 787786243b ./config/mt-v810 2659154290b ./config/mt-wince 771382916b ./config/mt-x86pic ! 3518489976b ./configure 3733934766b ./configure.in ! 1104011341b ./contrib/ChangeLog 550196746b ./contrib/compare_tests 2828387446b ./contrib/convert_to_f2c 2929939770b ./contrib/convert_to_g2c 2025073358b ./contrib/download_f2c 2292355102b ./contrib/gcc_build ! 2291211365b ./contrib/gcc_release 4179351048b ./contrib/gcc_update 1336632236b ./contrib/gccbug.el 2520368790b ./contrib/gennews --- 243,257 ---- 787786243b ./config/mt-v810 2659154290b ./config/mt-wince 771382916b ./config/mt-x86pic ! 3721047005b ./configure 3733934766b ./configure.in ! 1113421123b ./contrib/ChangeLog 550196746b ./contrib/compare_tests 2828387446b ./contrib/convert_to_f2c 2929939770b ./contrib/convert_to_g2c 2025073358b ./contrib/download_f2c 2292355102b ./contrib/gcc_build ! 2946097430b ./contrib/gcc_release 4179351048b ./contrib/gcc_update 1336632236b ./contrib/gccbug.el 2520368790b ./contrib/gennews *************** *** 263,273 **** 1719899924b ./contrib/test_summary 1623138628b ./contrib/texi2pod.pl 2210983108b ./contrib/warn_summary ! 2368292236b ./faq.html 1005262133b ./fastjar/AUTHORS 1745615150b ./fastjar/CHANGES 1396100520b ./fastjar/COPYING ! 953412608b ./fastjar/ChangeLog 2770615802b ./fastjar/INSTALL 2457567884b ./fastjar/Makefile.am 1854345631b ./fastjar/Makefile.in --- 262,272 ---- 1719899924b ./contrib/test_summary 1623138628b ./contrib/texi2pod.pl 2210983108b ./contrib/warn_summary ! 2110682007b ./faq.html 1005262133b ./fastjar/AUTHORS 1745615150b ./fastjar/CHANGES 1396100520b ./fastjar/COPYING ! 1191974177b ./fastjar/ChangeLog 2770615802b ./fastjar/INSTALL 2457567884b ./fastjar/Makefile.am 1854345631b ./fastjar/Makefile.in *************** *** 299,305 **** 1014730298b ./gcc/ABOUT-NLS 2171125041b ./gcc/COPYING 508743035b ./gcc/COPYING.LIB ! 1725818549b ./gcc/ChangeLog 1908191848b ./gcc/ChangeLog.0 1287222071b ./gcc/ChangeLog.1 3345586942b ./gcc/ChangeLog.2 --- 298,304 ---- 1014730298b ./gcc/ABOUT-NLS 2171125041b ./gcc/COPYING 508743035b ./gcc/COPYING.LIB ! 1027933138b ./gcc/ChangeLog 1908191848b ./gcc/ChangeLog.0 1287222071b ./gcc/ChangeLog.1 3345586942b ./gcc/ChangeLog.2 *************** *** 310,324 **** 232745070b ./gcc/FSFChangeLog.10 2525829644b ./gcc/FSFChangeLog.11 2771840517b ./gcc/LANGUAGES ! 356107076b ./gcc/Makefile.in ! 1041751184b ./gcc/NEWS 408114840b ./gcc/ONEWS 3310775363b ./gcc/README-fixinc 2741038711b ./gcc/README.Portability 1084935625b ./gcc/SERVICE 1319767072b ./gcc/acconfig.h 986758660b ./gcc/aclocal.m4 ! 888005559b ./gcc/alias.c 1470543567b ./gcc/basic-block.h 1630019981b ./gcc/bb-reorder.c 446912740b ./gcc/bitmap.c --- 309,323 ---- 232745070b ./gcc/FSFChangeLog.10 2525829644b ./gcc/FSFChangeLog.11 2771840517b ./gcc/LANGUAGES ! 4083143375b ./gcc/Makefile.in ! 3328882189b ./gcc/NEWS 408114840b ./gcc/ONEWS 3310775363b ./gcc/README-fixinc 2741038711b ./gcc/README.Portability 1084935625b ./gcc/SERVICE 1319767072b ./gcc/acconfig.h 986758660b ./gcc/aclocal.m4 ! 2509700127b ./gcc/alias.c 1470543567b ./gcc/basic-block.h 1630019981b ./gcc/bb-reorder.c 446912740b ./gcc/bitmap.c *************** *** 339,359 **** 3040046848b ./gcc/c-lang.c 61530428b ./gcc/c-lex.c 916578687b ./gcc/c-lex.h ! 3840276923b ./gcc/c-parse.c 353343561b ./gcc/c-parse.in 1042264003b ./gcc/c-parse.y 220833347b ./gcc/c-pragma.c 2111457647b ./gcc/c-pragma.h 4251225764b ./gcc/c-semantics.c 1365281254b ./gcc/c-tree.h ! 4101225614b ./gcc/c-typeck.c 3240633480b ./gcc/caller-save.c 1728509875b ./gcc/calls.c 1002247553b ./gcc/collect2.c 972672658b ./gcc/collect2.h 1330846505b ./gcc/combine.c 1434596660b ./gcc/conditions.h ! 715709234b ./gcc/config.gcc 1315260558b ./gcc/config.guess 2721129262b ./gcc/config.in 3329436298b ./gcc/config/1750a/1750a-protos.h --- 338,358 ---- 3040046848b ./gcc/c-lang.c 61530428b ./gcc/c-lex.c 916578687b ./gcc/c-lex.h ! 1529796766b ./gcc/c-parse.c 353343561b ./gcc/c-parse.in 1042264003b ./gcc/c-parse.y 220833347b ./gcc/c-pragma.c 2111457647b ./gcc/c-pragma.h 4251225764b ./gcc/c-semantics.c 1365281254b ./gcc/c-tree.h ! 1632067213b ./gcc/c-typeck.c 3240633480b ./gcc/caller-save.c 1728509875b ./gcc/calls.c 1002247553b ./gcc/collect2.c 972672658b ./gcc/collect2.h 1330846505b ./gcc/combine.c 1434596660b ./gcc/conditions.h ! 1496922945b ./gcc/config.gcc 1315260558b ./gcc/config.guess 2721129262b ./gcc/config.in 3329436298b ./gcc/config/1750a/1750a-protos.h *************** *** 439,445 **** 2696406159b ./gcc/config/arm/conix-elf.h 1087283327b ./gcc/config/arm/ecos-elf.h 3536639403b ./gcc/config/arm/elf.h ! 1132652007b ./gcc/config/arm/lib1funcs.asm 2964522736b ./gcc/config/arm/linux-elf.h 2372719730b ./gcc/config/arm/linux-gas.h 2387399091b ./gcc/config/arm/netbsd.h --- 438,444 ---- 2696406159b ./gcc/config/arm/conix-elf.h 1087283327b ./gcc/config/arm/ecos-elf.h 3536639403b ./gcc/config/arm/elf.h ! 822520065b ./gcc/config/arm/lib1funcs.asm 2964522736b ./gcc/config/arm/linux-elf.h 2372719730b ./gcc/config/arm/linux-gas.h 2387399091b ./gcc/config/arm/netbsd.h *************** *** 531,543 **** 3748147985b ./gcc/config/elxsi/x-elxsi 3457322814b ./gcc/config/elxsi/xm-elxsi.h 2520622557b ./gcc/config/float-c4x.h ! 3539372800b ./gcc/config/float-i128.h ! 1977266605b ./gcc/config/float-i32.h ! 2424642914b ./gcc/config/float-i386.h ! 951764911b ./gcc/config/float-i64.h ! 1916626677b ./gcc/config/float-m68k.h ! 4110511638b ./gcc/config/float-sh.h ! 3682857358b ./gcc/config/float-sparc.h 766947524b ./gcc/config/float-vax.h 729288938b ./gcc/config/fp-bit.c 86092851b ./gcc/config/fp-bit.h --- 530,542 ---- 3748147985b ./gcc/config/elxsi/x-elxsi 3457322814b ./gcc/config/elxsi/xm-elxsi.h 2520622557b ./gcc/config/float-c4x.h ! 36687624b ./gcc/config/float-i128.h ! 2077185169b ./gcc/config/float-i32.h ! 751904614b ./gcc/config/float-i386.h ! 466751418b ./gcc/config/float-i64.h ! 2601002892b ./gcc/config/float-m68k.h ! 1084189067b ./gcc/config/float-sh.h ! 3472567657b ./gcc/config/float-sparc.h 766947524b ./gcc/config/float-vax.h 729288938b ./gcc/config/fp-bit.c 86092851b ./gcc/config/fp-bit.h *************** *** 558,570 **** 3920011053b ./gcc/config/freebsd6.h 3236013445b ./gcc/config/gnu.h 1556064359b ./gcc/config/gofast.h 1075730847b ./gcc/config/h8300/h8300-protos.h ! 2022601699b ./gcc/config/h8300/h8300.c ! 611827174b ./gcc/config/h8300/h8300.h ! 3834479452b ./gcc/config/h8300/h8300.md ! 2745378669b ./gcc/config/h8300/lib1funcs.asm 836948877b ./gcc/config/h8300/rtems.h ! 665527148b ./gcc/config/h8300/t-h8300 2653746305b ./gcc/config/h8300/xm-h8300.h 2187046003b ./gcc/config/i370/README 2148254440b ./gcc/config/i370/i370-protos.h --- 557,570 ---- 3920011053b ./gcc/config/freebsd6.h 3236013445b ./gcc/config/gnu.h 1556064359b ./gcc/config/gofast.h + 1813884828b ./gcc/config/h8300/fixunssfsi.c 1075730847b ./gcc/config/h8300/h8300-protos.h ! 848177896b ./gcc/config/h8300/h8300.c ! 305883268b ./gcc/config/h8300/h8300.h ! 3675978024b ./gcc/config/h8300/h8300.md ! 2095012315b ./gcc/config/h8300/lib1funcs.asm 836948877b ./gcc/config/h8300/rtems.h ! 3200589132b ./gcc/config/h8300/t-h8300 2653746305b ./gcc/config/h8300/xm-h8300.h 2187046003b ./gcc/config/i370/README 2148254440b ./gcc/config/i370/i370-protos.h *************** *** 595,601 **** 3010444208b ./gcc/config/i386/config-nt.sed 3207315249b ./gcc/config/i386/crtdll.h 3943560803b ./gcc/config/i386/cygwin.asm ! 1819480147b ./gcc/config/i386/cygwin.h 2274149541b ./gcc/config/i386/dgux.c 3055146333b ./gcc/config/i386/dgux.h 1570943831b ./gcc/config/i386/djgpp-rtems.h --- 595,601 ---- 3010444208b ./gcc/config/i386/config-nt.sed 3207315249b ./gcc/config/i386/crtdll.h 3943560803b ./gcc/config/i386/cygwin.asm ! 8287530b ./gcc/config/i386/cygwin.h 2274149541b ./gcc/config/i386/dgux.c 3055146333b ./gcc/config/i386/dgux.h 1570943831b ./gcc/config/i386/djgpp-rtems.h *************** *** 610,618 **** 3714536309b ./gcc/config/i386/i386-coff.h 1565496826b ./gcc/config/i386/i386-interix.h 1433006975b ./gcc/config/i386/i386-protos.h ! 1144347387b ./gcc/config/i386/i386.c 663612626b ./gcc/config/i386/i386.h ! 3655216872b ./gcc/config/i386/i386.md 2138609268b ./gcc/config/i386/i386elf.h 2044371014b ./gcc/config/i386/interix.c 3245573839b ./gcc/config/i386/isc.h --- 610,618 ---- 3714536309b ./gcc/config/i386/i386-coff.h 1565496826b ./gcc/config/i386/i386-interix.h 1433006975b ./gcc/config/i386/i386-protos.h ! 1115041691b ./gcc/config/i386/i386.c 663612626b ./gcc/config/i386/i386.h ! 3903059271b ./gcc/config/i386/i386.md 2138609268b ./gcc/config/i386/i386elf.h 2044371014b ./gcc/config/i386/interix.c 3245573839b ./gcc/config/i386/isc.h *************** *** 624,630 **** 83628421b ./gcc/config/i386/lynx-ng.h 358216381b ./gcc/config/i386/lynx.h 2128828944b ./gcc/config/i386/mach.h ! 485142207b ./gcc/config/i386/mingw32.h 3361545892b ./gcc/config/i386/moss.h 2913497186b ./gcc/config/i386/netbsd.h 4211562640b ./gcc/config/i386/netware.h --- 624,630 ---- 83628421b ./gcc/config/i386/lynx-ng.h 358216381b ./gcc/config/i386/lynx.h 2128828944b ./gcc/config/i386/mach.h ! 1019451099b ./gcc/config/i386/mingw32.h 3361545892b ./gcc/config/i386/moss.h 2913497186b ./gcc/config/i386/netbsd.h 4211562640b ./gcc/config/i386/netware.h *************** *** 654,660 **** 1565106149b ./gcc/config/i386/sol2-ci.asm 4008317666b ./gcc/config/i386/sol2-cn.asm 2045686122b ./gcc/config/i386/sol2-gc1.asm ! 3461939003b ./gcc/config/i386/sol2.h 3870175252b ./gcc/config/i386/sol2gas.h 4009223163b ./gcc/config/i386/sun.h 1745602951b ./gcc/config/i386/sun386.h --- 654,660 ---- 1565106149b ./gcc/config/i386/sol2-ci.asm 4008317666b ./gcc/config/i386/sol2-cn.asm 2045686122b ./gcc/config/i386/sol2-gc1.asm ! 3161619351b ./gcc/config/i386/sol2.h 3870175252b ./gcc/config/i386/sol2gas.h 4009223163b ./gcc/config/i386/sun.h 1745602951b ./gcc/config/i386/sun386.h *************** *** 690,696 **** 482628910b ./gcc/config/i386/t-vsta 3516825605b ./gcc/config/i386/t-winnt 2348843648b ./gcc/config/i386/udk.h ! 4258439556b ./gcc/config/i386/unix.h 2149794869b ./gcc/config/i386/uwin.asm 4091738264b ./gcc/config/i386/uwin.h 1148022895b ./gcc/config/i386/v3gas.h --- 690,696 ---- 482628910b ./gcc/config/i386/t-vsta 3516825605b ./gcc/config/i386/t-winnt 2348843648b ./gcc/config/i386/udk.h ! 3077301906b ./gcc/config/i386/unix.h 2149794869b ./gcc/config/i386/uwin.asm 4091738264b ./gcc/config/i386/uwin.h 1148022895b ./gcc/config/i386/v3gas.h *************** *** 777,785 **** 2257162614b ./gcc/config/ia64/fde-glibc.c 3987815221b ./gcc/config/ia64/hpux.h 353921496b ./gcc/config/ia64/ia64-protos.h ! 1227923781b ./gcc/config/ia64/ia64.c ! 2598224474b ./gcc/config/ia64/ia64.h ! 102032371b ./gcc/config/ia64/ia64.md 3051569292b ./gcc/config/ia64/ia64intrin.h 3488320870b ./gcc/config/ia64/lib1funcs.asm 2361471520b ./gcc/config/ia64/libgcc-ia64.ver --- 777,785 ---- 2257162614b ./gcc/config/ia64/fde-glibc.c 3987815221b ./gcc/config/ia64/hpux.h 353921496b ./gcc/config/ia64/ia64-protos.h ! 1190921893b ./gcc/config/ia64/ia64.c ! 335927227b ./gcc/config/ia64/ia64.h ! 2221221481b ./gcc/config/ia64/ia64.md 3051569292b ./gcc/config/ia64/ia64intrin.h 3488320870b ./gcc/config/ia64/lib1funcs.asm 2361471520b ./gcc/config/ia64/libgcc-ia64.ver *************** *** 808,816 **** 2629267148b ./gcc/config/m68hc11/larith.asm 3563849705b ./gcc/config/m68hc11/m68hc11-crt0.S 321124732b ./gcc/config/m68hc11/m68hc11-protos.h ! 4119290448b ./gcc/config/m68hc11/m68hc11.c ! 1307274545b ./gcc/config/m68hc11/m68hc11.h ! 535592980b ./gcc/config/m68hc11/m68hc11.md 3915866468b ./gcc/config/m68hc11/m68hc12.h 3238866738b ./gcc/config/m68hc11/t-m68hc11-gas 1569281943b ./gcc/config/m68hc11/xm-m68hc11.h --- 808,816 ---- 2629267148b ./gcc/config/m68hc11/larith.asm 3563849705b ./gcc/config/m68hc11/m68hc11-crt0.S 321124732b ./gcc/config/m68hc11/m68hc11-protos.h ! 599626127b ./gcc/config/m68hc11/m68hc11.c ! 3375995232b ./gcc/config/m68hc11/m68hc11.h ! 2110857943b ./gcc/config/m68hc11/m68hc11.md 3915866468b ./gcc/config/m68hc11/m68hc12.h 3238866738b ./gcc/config/m68hc11/t-m68hc11-gas 1569281943b ./gcc/config/m68hc11/xm-m68hc11.h *************** *** 1191,1200 **** 3919710780b ./gcc/config/rs6000/lynx.h 1717863199b ./gcc/config/rs6000/mach.h 1820610909b ./gcc/config/rs6000/milli.exp ! 2609288545b ./gcc/config/rs6000/rs6000-protos.h ! 4126292778b ./gcc/config/rs6000/rs6000.c ! 1505319789b ./gcc/config/rs6000/rs6000.h ! 41571647b ./gcc/config/rs6000/rs6000.md 2636863004b ./gcc/config/rs6000/rtems.h 4210977084b ./gcc/config/rs6000/sol-c0.c 1695016479b ./gcc/config/rs6000/sol-ci.asm --- 1191,1200 ---- 3919710780b ./gcc/config/rs6000/lynx.h 1717863199b ./gcc/config/rs6000/mach.h 1820610909b ./gcc/config/rs6000/milli.exp ! 911358933b ./gcc/config/rs6000/rs6000-protos.h ! 1173041686b ./gcc/config/rs6000/rs6000.c ! 2662922828b ./gcc/config/rs6000/rs6000.h ! 845918244b ./gcc/config/rs6000/rs6000.md 2636863004b ./gcc/config/rs6000/rtems.h 4210977084b ./gcc/config/rs6000/sol-c0.c 1695016479b ./gcc/config/rs6000/sol-ci.asm *************** *** 1202,1208 **** 554206256b ./gcc/config/rs6000/sol2.h 4006545716b ./gcc/config/rs6000/sysv4.h 3795959522b ./gcc/config/rs6000/sysv4le.h ! 2145328627b ./gcc/config/rs6000/t-aix43 3185730278b ./gcc/config/rs6000/t-beos 2787085020b ./gcc/config/rs6000/t-newas 2333037305b ./gcc/config/rs6000/t-ppccomm --- 1202,1208 ---- 554206256b ./gcc/config/rs6000/sol2.h 4006545716b ./gcc/config/rs6000/sysv4.h 3795959522b ./gcc/config/rs6000/sysv4le.h ! 2917213310b ./gcc/config/rs6000/t-aix43 3185730278b ./gcc/config/rs6000/t-beos 2787085020b ./gcc/config/rs6000/t-newas 2333037305b ./gcc/config/rs6000/t-ppccomm *************** *** 1233,1242 **** 3390348482b ./gcc/config/s390/fixdfdi.h 3456013752b ./gcc/config/s390/linux.h 854043548b ./gcc/config/s390/linux64.h ! 640221274b ./gcc/config/s390/s390-protos.h ! 4149280158b ./gcc/config/s390/s390.c 1921139648b ./gcc/config/s390/s390.h ! 2541395328b ./gcc/config/s390/s390.md 2251075592b ./gcc/config/s390/t-linux 843019701b ./gcc/config/s390/xm-s390.h 1662767015b ./gcc/config/s390/xm-s390x.h --- 1233,1242 ---- 3390348482b ./gcc/config/s390/fixdfdi.h 3456013752b ./gcc/config/s390/linux.h 854043548b ./gcc/config/s390/linux64.h ! 2354442092b ./gcc/config/s390/s390-protos.h ! 905524531b ./gcc/config/s390/s390.c 1921139648b ./gcc/config/s390/s390.h ! 2766214118b ./gcc/config/s390/s390.md 2251075592b ./gcc/config/s390/t-linux 843019701b ./gcc/config/s390/xm-s390.h 1662767015b ./gcc/config/s390/xm-s390x.h *************** *** 1249,1255 **** 2599163754b ./gcc/config/sh/rtems.h 990865180b ./gcc/config/sh/rtemself.h 2070405666b ./gcc/config/sh/sh-protos.h ! 2938981636b ./gcc/config/sh/sh.c 2550458827b ./gcc/config/sh/sh.h 3029807708b ./gcc/config/sh/sh.md 3555569248b ./gcc/config/sh/t-elf --- 1249,1255 ---- 2599163754b ./gcc/config/sh/rtems.h 990865180b ./gcc/config/sh/rtemself.h 2070405666b ./gcc/config/sh/sh-protos.h ! 1358956373b ./gcc/config/sh/sh.c 2550458827b ./gcc/config/sh/sh.h 3029807708b ./gcc/config/sh/sh.md 3555569248b ./gcc/config/sh/t-elf *************** *** 1265,1272 **** 671302508b ./gcc/config/sparc/lb1spc.asm 892412538b ./gcc/config/sparc/lb1spl.asm 1118226000b ./gcc/config/sparc/linux-aout.h ! 2447083047b ./gcc/config/sparc/linux.h ! 1052751066b ./gcc/config/sparc/linux64.h 2041477542b ./gcc/config/sparc/lite.h 2098369347b ./gcc/config/sparc/litecoff.h 243249983b ./gcc/config/sparc/liteelf.h --- 1265,1272 ---- 671302508b ./gcc/config/sparc/lb1spc.asm 892412538b ./gcc/config/sparc/lb1spl.asm 1118226000b ./gcc/config/sparc/linux-aout.h ! 3074747325b ./gcc/config/sparc/linux.h ! 253698474b ./gcc/config/sparc/linux64.h 2041477542b ./gcc/config/sparc/lite.h 2098369347b ./gcc/config/sparc/litecoff.h 243249983b ./gcc/config/sparc/liteelf.h *************** *** 1401,1426 **** 556313302b ./gcc/convert.c 4032982380b ./gcc/convert.h 1230086821b ./gcc/cp/.cvsignore ! 1456544739b ./gcc/cp/ChangeLog 1903584b ./gcc/cp/ChangeLog.1 1881731020b ./gcc/cp/ChangeLog.2 2546444747b ./gcc/cp/ChangeLog.egcs ! 615847120b ./gcc/cp/Make-lang.in 846059250b ./gcc/cp/NEWS ! 1310742131b ./gcc/cp/call.c 4115552602b ./gcc/cp/cfns.gperf 1705070232b ./gcc/cp/cfns.h ! 3936615852b ./gcc/cp/class.c 1920345452b ./gcc/cp/config-lang.in 3406340479b ./gcc/cp/cp-tree.def 2682469958b ./gcc/cp/cp-tree.h 788167684b ./gcc/cp/cvt.c 1404777217b ./gcc/cp/decl.c 1027981985b ./gcc/cp/decl.h ! 2529358069b ./gcc/cp/decl2.c 217522872b ./gcc/cp/dump.c 3091430199b ./gcc/cp/errfn.c ! 3740657327b ./gcc/cp/error.c 374515501b ./gcc/cp/except.c 764912804b ./gcc/cp/expr.c 1673698151b ./gcc/cp/friend.c --- 1401,1426 ---- 556313302b ./gcc/convert.c 4032982380b ./gcc/convert.h 1230086821b ./gcc/cp/.cvsignore ! 788140310b ./gcc/cp/ChangeLog 1903584b ./gcc/cp/ChangeLog.1 1881731020b ./gcc/cp/ChangeLog.2 2546444747b ./gcc/cp/ChangeLog.egcs ! 1788488183b ./gcc/cp/Make-lang.in 846059250b ./gcc/cp/NEWS ! 3390344274b ./gcc/cp/call.c 4115552602b ./gcc/cp/cfns.gperf 1705070232b ./gcc/cp/cfns.h ! 1220336448b ./gcc/cp/class.c 1920345452b ./gcc/cp/config-lang.in 3406340479b ./gcc/cp/cp-tree.def 2682469958b ./gcc/cp/cp-tree.h 788167684b ./gcc/cp/cvt.c 1404777217b ./gcc/cp/decl.c 1027981985b ./gcc/cp/decl.h ! 2337829944b ./gcc/cp/decl2.c 217522872b ./gcc/cp/dump.c 3091430199b ./gcc/cp/errfn.c ! 3135875533b ./gcc/cp/error.c 374515501b ./gcc/cp/except.c 764912804b ./gcc/cp/expr.c 1673698151b ./gcc/cp/friend.c *************** *** 1436,1454 **** 701335209b ./gcc/cp/mpw-config.in 4041177245b ./gcc/cp/mpw-make.sed 1791576125b ./gcc/cp/operators.def ! 3678445539b ./gcc/cp/optimize.c ! 3051645323b ./gcc/cp/parse.c 4085964132b ./gcc/cp/parse.h 1879411084b ./gcc/cp/parse.y ! 2874107554b ./gcc/cp/pt.c 903594734b ./gcc/cp/ptree.c 1890655336b ./gcc/cp/repo.c ! 3470529425b ./gcc/cp/rtti.c 696207784b ./gcc/cp/search.c 2381646409b ./gcc/cp/semantics.c 1818467654b ./gcc/cp/spew.c 91515646b ./gcc/cp/tree.c ! 3390967551b ./gcc/cp/typeck.c 3459487995b ./gcc/cp/typeck2.c 1359529404b ./gcc/cp/xref.c 4198030259b ./gcc/cppdefault.c --- 1436,1454 ---- 701335209b ./gcc/cp/mpw-config.in 4041177245b ./gcc/cp/mpw-make.sed 1791576125b ./gcc/cp/operators.def ! 212667869b ./gcc/cp/optimize.c ! 348619331b ./gcc/cp/parse.c 4085964132b ./gcc/cp/parse.h 1879411084b ./gcc/cp/parse.y ! 940975689b ./gcc/cp/pt.c 903594734b ./gcc/cp/ptree.c 1890655336b ./gcc/cp/repo.c ! 2073476971b ./gcc/cp/rtti.c 696207784b ./gcc/cp/search.c 2381646409b ./gcc/cp/semantics.c 1818467654b ./gcc/cp/spew.c 91515646b ./gcc/cp/tree.c ! 1859957305b ./gcc/cp/typeck.c 3459487995b ./gcc/cp/typeck2.c 1359529404b ./gcc/cp/xref.c 4198030259b ./gcc/cppdefault.c *************** *** 1459,1551 **** 3904470681b ./gcc/cpphash.c 1641754935b ./gcc/cpphash.h 2491140484b ./gcc/cppinit.c ! 352253678b ./gcc/cpplex.c ! 512859427b ./gcc/cpplib.c 3400544410b ./gcc/cpplib.h ! 1284813508b ./gcc/cppmacro.c 373762755b ./gcc/cppmain.c 4137262150b ./gcc/cppspec.c 2903740050b ./gcc/cross-make 1363172067b ./gcc/crtstuff.c ! 2946810917b ./gcc/cse.c 1864237584b ./gcc/cselib.h 216805921b ./gcc/cstamp-h.in 3098946745b ./gcc/dbxout.c 181061183b ./gcc/dbxout.h 1104788844b ./gcc/dbxstclass.h 2469057166b ./gcc/dce.c ! 3555308222b ./gcc/defaults.h 2226328701b ./gcc/dependence.c 4065269356b ./gcc/diagnostic.c 2207352912b ./gcc/diagnostic.h 890851034b ./gcc/doc/.cvsignore ! 4124442826b ./gcc/doc/c-tree.texi 3680358381b ./gcc/doc/contrib.texi ! 1311187294b ./gcc/doc/cpp.1 ! 1331953370b ./gcc/doc/cpp.info ! 803760277b ./gcc/doc/cpp.info-1 ! 3665332888b ./gcc/doc/cpp.info-2 ! 3052985070b ./gcc/doc/cpp.info-3 ! 999296888b ./gcc/doc/cpp.info-4 ! 827033126b ./gcc/doc/cpp.texi 3141595163b ./gcc/doc/cppinternals.info 1445289518b ./gcc/doc/cppinternals.texi ! 2091691828b ./gcc/doc/extend.texi ! 4147779460b ./gcc/doc/gcc.1 ! 3026358753b ./gcc/doc/gcc.info ! 44556827b ./gcc/doc/gcc.info-1 1412220606b ./gcc/doc/gcc.info-10 3943813356b ./gcc/doc/gcc.info-11 418964136b ./gcc/doc/gcc.info-12 ! 4008064171b ./gcc/doc/gcc.info-13 ! 1648213693b ./gcc/doc/gcc.info-14 ! 588011301b ./gcc/doc/gcc.info-15 ! 1754573484b ./gcc/doc/gcc.info-16 ! 3930539567b ./gcc/doc/gcc.info-17 ! 2226344020b ./gcc/doc/gcc.info-18 ! 2417116799b ./gcc/doc/gcc.info-19 ! 3001818438b ./gcc/doc/gcc.info-2 ! 428958887b ./gcc/doc/gcc.info-20 525664717b ./gcc/doc/gcc.info-21 1348937332b ./gcc/doc/gcc.info-22 2619556996b ./gcc/doc/gcc.info-23 ! 1362771598b ./gcc/doc/gcc.info-24 ! 3470688996b ./gcc/doc/gcc.info-25 ! 735287455b ./gcc/doc/gcc.info-26 ! 3209657202b ./gcc/doc/gcc.info-27 ! 1582307263b ./gcc/doc/gcc.info-28 ! 525340619b ./gcc/doc/gcc.info-29 4095656035b ./gcc/doc/gcc.info-3 ! 1331327086b ./gcc/doc/gcc.info-30 ! 3864158157b ./gcc/doc/gcc.info-31 ! 1139465841b ./gcc/doc/gcc.info-32 ! 1565524835b ./gcc/doc/gcc.info-33 ! 278600549b ./gcc/doc/gcc.info-34 3348688145b ./gcc/doc/gcc.info-35 1797713626b ./gcc/doc/gcc.info-36 ! 347664857b ./gcc/doc/gcc.info-37 2743624506b ./gcc/doc/gcc.info-38 ! 701354272b ./gcc/doc/gcc.info-4 352877010b ./gcc/doc/gcc.info-5 979705408b ./gcc/doc/gcc.info-6 ! 1295006596b ./gcc/doc/gcc.info-7 ! 713760857b ./gcc/doc/gcc.info-8 102742701b ./gcc/doc/gcc.info-9 ! 528909035b ./gcc/doc/gcc.texi ! 4138844617b ./gcc/doc/gcov.1 2764453786b ./gcc/doc/gcov.texi 1008218839b ./gcc/doc/include/fdl.texi 3383701708b ./gcc/doc/include/funding.texi 423212962b ./gcc/doc/include/gpl.texi 4016541318b ./gcc/doc/include/texinfo.tex 2393405651b ./gcc/doc/install-old.texi ! 824388918b ./gcc/doc/install.texi 3260938793b ./gcc/doc/install.texi2html ! 109423404b ./gcc/doc/invoke.texi ! 135097364b ./gcc/doc/md.texi ! 2542227198b ./gcc/doc/objc.texi ! 326027164b ./gcc/doc/rtl.texi ! 548246333b ./gcc/doc/tm.texi 472588828b ./gcc/doloop.c 123944430b ./gcc/dominance.c 2660216905b ./gcc/doprint.c --- 1459,1551 ---- 3904470681b ./gcc/cpphash.c 1641754935b ./gcc/cpphash.h 2491140484b ./gcc/cppinit.c ! 791416625b ./gcc/cpplex.c ! 365830801b ./gcc/cpplib.c 3400544410b ./gcc/cpplib.h ! 2361742565b ./gcc/cppmacro.c 373762755b ./gcc/cppmain.c 4137262150b ./gcc/cppspec.c 2903740050b ./gcc/cross-make 1363172067b ./gcc/crtstuff.c ! 266646376b ./gcc/cse.c 1864237584b ./gcc/cselib.h 216805921b ./gcc/cstamp-h.in 3098946745b ./gcc/dbxout.c 181061183b ./gcc/dbxout.h 1104788844b ./gcc/dbxstclass.h 2469057166b ./gcc/dce.c ! 984558316b ./gcc/defaults.h 2226328701b ./gcc/dependence.c 4065269356b ./gcc/diagnostic.c 2207352912b ./gcc/diagnostic.h 890851034b ./gcc/doc/.cvsignore ! 1316708563b ./gcc/doc/c-tree.texi 3680358381b ./gcc/doc/contrib.texi ! 2846172728b ./gcc/doc/cpp.1 ! 3597805091b ./gcc/doc/cpp.info ! 4249470227b ./gcc/doc/cpp.info-1 ! 757268427b ./gcc/doc/cpp.info-2 ! 1262632653b ./gcc/doc/cpp.info-3 ! 167551904b ./gcc/doc/cpp.info-4 ! 3574813453b ./gcc/doc/cpp.texi 3141595163b ./gcc/doc/cppinternals.info 1445289518b ./gcc/doc/cppinternals.texi ! 597376622b ./gcc/doc/extend.texi ! 2101763670b ./gcc/doc/gcc.1 ! 3909373821b ./gcc/doc/gcc.info ! 1987967750b ./gcc/doc/gcc.info-1 1412220606b ./gcc/doc/gcc.info-10 3943813356b ./gcc/doc/gcc.info-11 418964136b ./gcc/doc/gcc.info-12 ! 2935130590b ./gcc/doc/gcc.info-13 ! 3149587542b ./gcc/doc/gcc.info-14 ! 695739271b ./gcc/doc/gcc.info-15 ! 1601557755b ./gcc/doc/gcc.info-16 ! 474223648b ./gcc/doc/gcc.info-17 ! 2119263243b ./gcc/doc/gcc.info-18 ! 1257216105b ./gcc/doc/gcc.info-19 ! 4207825738b ./gcc/doc/gcc.info-2 ! 2100888987b ./gcc/doc/gcc.info-20 525664717b ./gcc/doc/gcc.info-21 1348937332b ./gcc/doc/gcc.info-22 2619556996b ./gcc/doc/gcc.info-23 ! 2307737119b ./gcc/doc/gcc.info-24 ! 1607293577b ./gcc/doc/gcc.info-25 ! 3092425092b ./gcc/doc/gcc.info-26 ! 178291516b ./gcc/doc/gcc.info-27 ! 1510217315b ./gcc/doc/gcc.info-28 ! 3723298804b ./gcc/doc/gcc.info-29 4095656035b ./gcc/doc/gcc.info-3 ! 239428913b ./gcc/doc/gcc.info-30 ! 2220281758b ./gcc/doc/gcc.info-31 ! 414837311b ./gcc/doc/gcc.info-32 ! 1806833096b ./gcc/doc/gcc.info-33 ! 2139934929b ./gcc/doc/gcc.info-34 3348688145b ./gcc/doc/gcc.info-35 1797713626b ./gcc/doc/gcc.info-36 ! 177642172b ./gcc/doc/gcc.info-37 2743624506b ./gcc/doc/gcc.info-38 ! 183373778b ./gcc/doc/gcc.info-4 352877010b ./gcc/doc/gcc.info-5 979705408b ./gcc/doc/gcc.info-6 ! 2082768225b ./gcc/doc/gcc.info-7 ! 3184007007b ./gcc/doc/gcc.info-8 102742701b ./gcc/doc/gcc.info-9 ! 3679799138b ./gcc/doc/gcc.texi ! 3948564685b ./gcc/doc/gcov.1 2764453786b ./gcc/doc/gcov.texi 1008218839b ./gcc/doc/include/fdl.texi 3383701708b ./gcc/doc/include/funding.texi 423212962b ./gcc/doc/include/gpl.texi 4016541318b ./gcc/doc/include/texinfo.tex 2393405651b ./gcc/doc/install-old.texi ! 870109107b ./gcc/doc/install.texi 3260938793b ./gcc/doc/install.texi2html ! 3035201328b ./gcc/doc/invoke.texi ! 2662979853b ./gcc/doc/md.texi ! 1033541327b ./gcc/doc/objc.texi ! 1140289608b ./gcc/doc/rtl.texi ! 3106491649b ./gcc/doc/tm.texi 472588828b ./gcc/doloop.c 123944430b ./gcc/dominance.c 2660216905b ./gcc/doprint.c *************** *** 1556,1562 **** 369471853b ./gcc/dwarf2.h 1793399413b ./gcc/dwarf2asm.c 3481577918b ./gcc/dwarf2asm.h ! 3378597493b ./gcc/dwarf2out.c 907111294b ./gcc/dwarf2out.h 1291353303b ./gcc/dwarfout.c 1589660034b ./gcc/dwarfout.h --- 1556,1562 ---- 369471853b ./gcc/dwarf2.h 1793399413b ./gcc/dwarf2asm.c 3481577918b ./gcc/dwarf2asm.h ! 1091575516b ./gcc/dwarf2out.c 907111294b ./gcc/dwarf2out.h 1291353303b ./gcc/dwarfout.c 1589660034b ./gcc/dwarfout.h *************** *** 1564,1579 **** 626897841b ./gcc/enquire.c 3097048689b ./gcc/errors.c 3948305090b ./gcc/errors.h ! 2201789247b ./gcc/except.c 3751320921b ./gcc/except.h 3470052574b ./gcc/exgettext 1523181895b ./gcc/explow.c 1640629260b ./gcc/expmed.c ! 2323165388b ./gcc/expr.c 3169905778b ./gcc/expr.h 2920655732b ./gcc/f/.cvsignore 496151338b ./gcc/f/BUGS ! 3373181774b ./gcc/f/ChangeLog 4225493150b ./gcc/f/ChangeLog.0 1959441375b ./gcc/f/Make-lang.in 4163515796b ./gcc/f/NEWS --- 1564,1579 ---- 626897841b ./gcc/enquire.c 3097048689b ./gcc/errors.c 3948305090b ./gcc/errors.h ! 1058293138b ./gcc/except.c 3751320921b ./gcc/except.h 3470052574b ./gcc/exgettext 1523181895b ./gcc/explow.c 1640629260b ./gcc/expmed.c ! 2102481446b ./gcc/expr.c 3169905778b ./gcc/expr.h 2920655732b ./gcc/f/.cvsignore 496151338b ./gcc/f/BUGS ! 213841743b ./gcc/f/ChangeLog 4225493150b ./gcc/f/ChangeLog.0 1959441375b ./gcc/f/Make-lang.in 4163515796b ./gcc/f/NEWS *************** *** 1603,1609 **** 4228142157b ./gcc/f/ffe.texi 4039257523b ./gcc/f/fini.c 3733092107b ./gcc/f/g77.1 ! 2516470554b ./gcc/f/g77.info 2715588042b ./gcc/f/g77.info-1 1102432768b ./gcc/f/g77.info-10 1616293807b ./gcc/f/g77.info-11 --- 1603,1609 ---- 4228142157b ./gcc/f/ffe.texi 4039257523b ./gcc/f/fini.c 3733092107b ./gcc/f/g77.1 ! 2014578832b ./gcc/f/g77.info 2715588042b ./gcc/f/g77.info-1 1102432768b ./gcc/f/g77.info-10 1616293807b ./gcc/f/g77.info-11 *************** *** 1612,1623 **** 1552768627b ./gcc/f/g77.info-14 1960100262b ./gcc/f/g77.info-15 164148332b ./gcc/f/g77.info-16 ! 467035421b ./gcc/f/g77.info-17 ! 3347439222b ./gcc/f/g77.info-18 ! 4037002258b ./gcc/f/g77.info-19 3318968689b ./gcc/f/g77.info-2 ! 3405824903b ./gcc/f/g77.info-20 ! 2060286223b ./gcc/f/g77.info-21 2778233086b ./gcc/f/g77.info-3 2427118973b ./gcc/f/g77.info-4 4200013360b ./gcc/f/g77.info-5 --- 1612,1622 ---- 1552768627b ./gcc/f/g77.info-14 1960100262b ./gcc/f/g77.info-15 164148332b ./gcc/f/g77.info-16 ! 2446513571b ./gcc/f/g77.info-17 ! 246994537b ./gcc/f/g77.info-18 ! 2580610793b ./gcc/f/g77.info-19 3318968689b ./gcc/f/g77.info-2 ! 2060286223b ./gcc/f/g77.info-20 2778233086b ./gcc/f/g77.info-3 2427118973b ./gcc/f/g77.info-4 4200013360b ./gcc/f/g77.info-5 *************** *** 1625,1631 **** 87613785b ./gcc/f/g77.info-7 3338319587b ./gcc/f/g77.info-8 2783591220b ./gcc/f/g77.info-9 ! 4105631864b ./gcc/f/g77.texi 908822112b ./gcc/f/g77install.texi 2350422564b ./gcc/f/g77spec.c 1736110997b ./gcc/f/global.c --- 1624,1630 ---- 87613785b ./gcc/f/g77.info-7 3338319587b ./gcc/f/g77.info-8 2783591220b ./gcc/f/g77.info-9 ! 2640639478b ./gcc/f/g77.texi 908822112b ./gcc/f/g77install.texi 2350422564b ./gcc/f/g77spec.c 1736110997b ./gcc/f/global.c *************** *** 1705,1711 **** 4257635887b ./gcc/f/top.h 3443401298b ./gcc/f/type.c 1269043734b ./gcc/f/type.h ! 1656514385b ./gcc/f/version.c 1880947867b ./gcc/f/version.h 3584291506b ./gcc/f/where.c 422122823b ./gcc/f/where.h --- 1704,1710 ---- 4257635887b ./gcc/f/top.h 3443401298b ./gcc/f/type.c 1269043734b ./gcc/f/type.h ! 1430487999b ./gcc/f/version.c 1880947867b ./gcc/f/version.h 3584291506b ./gcc/f/where.c 422122823b ./gcc/f/where.h *************** *** 1724,1737 **** 2436281382b ./gcc/fixinc/fixincl.c 4214658264b ./gcc/fixinc/fixincl.sh 2178021789b ./gcc/fixinc/fixincl.tpl ! 1313142376b ./gcc/fixinc/fixincl.x 1372603529b ./gcc/fixinc/fixlib.c 971233728b ./gcc/fixinc/fixlib.h 4013194329b ./gcc/fixinc/fixtests.c 2003329934b ./gcc/fixinc/genfixes 3680461708b ./gcc/fixinc/gnu-regex.c 1403987073b ./gcc/fixinc/gnu-regex.h ! 726275978b ./gcc/fixinc/inclhack.def 1662855861b ./gcc/fixinc/mkfixinc.sh 3901871541b ./gcc/fixinc/procopen.c 1750379031b ./gcc/fixinc/server.c --- 1723,1736 ---- 2436281382b ./gcc/fixinc/fixincl.c 4214658264b ./gcc/fixinc/fixincl.sh 2178021789b ./gcc/fixinc/fixincl.tpl ! 306422479b ./gcc/fixinc/fixincl.x 1372603529b ./gcc/fixinc/fixlib.c 971233728b ./gcc/fixinc/fixlib.h 4013194329b ./gcc/fixinc/fixtests.c 2003329934b ./gcc/fixinc/genfixes 3680461708b ./gcc/fixinc/gnu-regex.c 1403987073b ./gcc/fixinc/gnu-regex.h ! 1552151123b ./gcc/fixinc/inclhack.def 1662855861b ./gcc/fixinc/mkfixinc.sh 3901871541b ./gcc/fixinc/procopen.c 1750379031b ./gcc/fixinc/server.c *************** *** 1803,1824 **** 1711694323b ./gcc/fixproto 4214100853b ./gcc/flags.h 14144180b ./gcc/floatlib.c ! 2898428361b ./gcc/flow.c 3036032403b ./gcc/fold-const.c 814448160b ./gcc/fp-test.c ! 1653566373b ./gcc/function.c 1538066423b ./gcc/function.h 1945284764b ./gcc/future.options 4221598017b ./gcc/gansidecl.h 4122921738b ./gcc/gbl-ctors.h ! 3367854049b ./gcc/gcc.c 2630706606b ./gcc/gcc.h 3891935819b ./gcc/gcc.hlp 2684927393b ./gcc/gccbug.in 1641833990b ./gcc/gccspec.c 1843506698b ./gcc/gcov-io.h 313069282b ./gcc/gcov.c ! 2174643399b ./gcc/gcse.c 3956392696b ./gcc/gen-protos.c 3274885314b ./gcc/genattr.c 1086728373b ./gcc/genattrtab.c --- 1802,1823 ---- 1711694323b ./gcc/fixproto 4214100853b ./gcc/flags.h 14144180b ./gcc/floatlib.c ! 1148505848b ./gcc/flow.c 3036032403b ./gcc/fold-const.c 814448160b ./gcc/fp-test.c ! 888363625b ./gcc/function.c 1538066423b ./gcc/function.h 1945284764b ./gcc/future.options 4221598017b ./gcc/gansidecl.h 4122921738b ./gcc/gbl-ctors.h ! 1168318307b ./gcc/gcc.c 2630706606b ./gcc/gcc.h 3891935819b ./gcc/gcc.hlp 2684927393b ./gcc/gccbug.in 1641833990b ./gcc/gccspec.c 1843506698b ./gcc/gcov-io.h 313069282b ./gcc/gcov.c ! 608033730b ./gcc/gcse.c 3956392696b ./gcc/gen-protos.c 3274885314b ./gcc/genattr.c 1086728373b ./gcc/genattrtab.c *************** *** 1882,1888 **** 2996455768b ./gcc/integrate.h 1933110400b ./gcc/intl.c 1326021680b ./gcc/intl.h ! 3523133344b ./gcc/intl/ChangeLog 2608513953b ./gcc/intl/Makefile.in 1035788439b ./gcc/intl/VERSION 2050167308b ./gcc/intl/bindtextdom.c --- 1881,1887 ---- 2996455768b ./gcc/integrate.h 1933110400b ./gcc/intl.c 1326021680b ./gcc/intl.h ! 1957716668b ./gcc/intl/ChangeLog 2608513953b ./gcc/intl/Makefile.in 1035788439b ./gcc/intl/VERSION 2050167308b ./gcc/intl/bindtextdom.c *************** *** 1906,1925 **** 3722123962b ./gcc/intl/textdomain.c 2960721199b ./gcc/intl/xopen-msg.sed 4005572097b ./gcc/java/.cvsignore ! 1719265326b ./gcc/java/ChangeLog 3199045892b ./gcc/java/Make-lang.in 3788283147b ./gcc/java/boehm.c 2541917855b ./gcc/java/buffer.c 1535113190b ./gcc/java/buffer.h 3525399284b ./gcc/java/chartables.h 2664267463b ./gcc/java/check-init.c ! 1536311856b ./gcc/java/class.c 2038704444b ./gcc/java/config-lang.in 3496722225b ./gcc/java/constants.c 640032177b ./gcc/java/convert.h 2740930497b ./gcc/java/decl.c 3124910668b ./gcc/java/except.c ! 1619508635b ./gcc/java/expr.c 2186347127b ./gcc/java/gcj.info 271445606b ./gcc/java/gcj.texi 4209811621b ./gcc/java/gen-table.pl --- 1905,1924 ---- 3722123962b ./gcc/intl/textdomain.c 2960721199b ./gcc/intl/xopen-msg.sed 4005572097b ./gcc/java/.cvsignore ! 2846269432b ./gcc/java/ChangeLog 3199045892b ./gcc/java/Make-lang.in 3788283147b ./gcc/java/boehm.c 2541917855b ./gcc/java/buffer.c 1535113190b ./gcc/java/buffer.h 3525399284b ./gcc/java/chartables.h 2664267463b ./gcc/java/check-init.c ! 3845730481b ./gcc/java/class.c 2038704444b ./gcc/java/config-lang.in 3496722225b ./gcc/java/constants.c 640032177b ./gcc/java/convert.h 2740930497b ./gcc/java/decl.c 3124910668b ./gcc/java/except.c ! 2881802120b ./gcc/java/expr.c 2186347127b ./gcc/java/gcj.info 271445606b ./gcc/java/gcj.texi 4209811621b ./gcc/java/gen-table.pl *************** *** 1950,1958 **** 1271687574b ./gcc/java/lex.h 3274830053b ./gcc/java/mangle.c 2248284043b ./gcc/java/mangle_name.c ! 3982948195b ./gcc/java/parse-scan.c 578153036b ./gcc/java/parse-scan.y ! 2381650795b ./gcc/java/parse.c 790738941b ./gcc/java/parse.h 3618600566b ./gcc/java/parse.y 3137203029b ./gcc/java/typeck.c --- 1949,1957 ---- 1271687574b ./gcc/java/lex.h 3274830053b ./gcc/java/mangle.c 2248284043b ./gcc/java/mangle_name.c ! 96916050b ./gcc/java/parse-scan.c 578153036b ./gcc/java/parse-scan.y ! 2814799967b ./gcc/java/parse.c 790738941b ./gcc/java/parse.h 3618600566b ./gcc/java/parse.y 3137203029b ./gcc/java/typeck.c *************** *** 1970,1980 **** 3947354765b ./gcc/libgcc2.h 2497915666b ./gcc/limitx.h 1045880008b ./gcc/limity.h - 1454959977b ./gcc/listing 4116099112b ./gcc/lists.c 3899123841b ./gcc/local-alloc.c 2278161154b ./gcc/longlong.h ! 1409720805b ./gcc/loop.c 3762441882b ./gcc/loop.h 983398590b ./gcc/machmode.def 2565031954b ./gcc/machmode.h --- 1969,1978 ---- 3947354765b ./gcc/libgcc2.h 2497915666b ./gcc/limitx.h 1045880008b ./gcc/limity.h 4116099112b ./gcc/lists.c 3899123841b ./gcc/local-alloc.c 2278161154b ./gcc/longlong.h ! 4152471143b ./gcc/loop.c 3762441882b ./gcc/loop.h 983398590b ./gcc/machmode.def 2565031954b ./gcc/machmode.h *************** *** 2000,2006 **** 2977909645b ./gcc/objc/lang-specs.h 4226828284b ./gcc/objc/objc-act.c 3444272236b ./gcc/objc/objc-act.h ! 1482096497b ./gcc/objc/objc-parse.c 3649582771b ./gcc/objc/objc-parse.y 620378166b ./gcc/objc/objc-tree.def 1567868913b ./gcc/objc/objc.gperf --- 1998,2004 ---- 2977909645b ./gcc/objc/lang-specs.h 4226828284b ./gcc/objc/objc-act.c 3444272236b ./gcc/objc/objc-act.h ! 3815467981b ./gcc/objc/objc-parse.c 3649582771b ./gcc/objc/objc-parse.y 620378166b ./gcc/objc/objc-tree.def 1567868913b ./gcc/objc/objc.gperf *************** *** 2010,2016 **** 52078911b ./gcc/params.def 200901683b ./gcc/params.h 1987145824b ./gcc/patch-apollo-includes ! 755698090b ./gcc/po/ChangeLog 1909445789b ./gcc/po/Makefile.in.in 230456843b ./gcc/po/POTFILES.in 2625119691b ./gcc/po/cat-id-tbl.c --- 2008,2014 ---- 52078911b ./gcc/params.def 200901683b ./gcc/params.h 1987145824b ./gcc/patch-apollo-includes ! 1044845750b ./gcc/po/ChangeLog 1909445789b ./gcc/po/Makefile.in.in 230456843b ./gcc/po/POTFILES.in 2625119691b ./gcc/po/cat-id-tbl.c *************** *** 2030,2047 **** 3792773945b ./gcc/recog.h 3444596851b ./gcc/reg-stack.c 1357530535b ./gcc/regclass.c ! 1810934709b ./gcc/regmove.c ! 2758954720b ./gcc/regrename.c 3830393261b ./gcc/regs.h ! 653206572b ./gcc/reload.c 725417840b ./gcc/reload.h ! 2875210057b ./gcc/reload1.c 2155579804b ./gcc/reorg.c 1244398550b ./gcc/resource.c 1586797891b ./gcc/resource.h 4283544518b ./gcc/rtl.c 1510325517b ./gcc/rtl.def ! 4008567039b ./gcc/rtl.h 222251668b ./gcc/rtlanal.c 1769394538b ./gcc/sbitmap.c 2634452046b ./gcc/sbitmap.h --- 2028,2045 ---- 3792773945b ./gcc/recog.h 3444596851b ./gcc/reg-stack.c 1357530535b ./gcc/regclass.c ! 3460075521b ./gcc/regmove.c ! 583135114b ./gcc/regrename.c 3830393261b ./gcc/regs.h ! 3006122128b ./gcc/reload.c 725417840b ./gcc/reload.h ! 715349482b ./gcc/reload1.c 2155579804b ./gcc/reorg.c 1244398550b ./gcc/resource.c 1586797891b ./gcc/resource.h 4283544518b ./gcc/rtl.c 1510325517b ./gcc/rtl.def ! 1663736017b ./gcc/rtl.h 222251668b ./gcc/rtlanal.c 1769394538b ./gcc/sbitmap.c 2634452046b ./gcc/sbitmap.h *************** *** 2056,2062 **** 4091631937b ./gcc/sched-vis.c 3073218432b ./gcc/sdbout.c 4067506551b ./gcc/sdbout.h ! 1862542497b ./gcc/sibcall.c 149348570b ./gcc/simplify-rtx.c 3345261950b ./gcc/sort-protos 4238707268b ./gcc/ssa.c --- 2054,2060 ---- 4091631937b ./gcc/sched-vis.c 3073218432b ./gcc/sdbout.c 4067506551b ./gcc/sdbout.h ! 2293681625b ./gcc/sibcall.c 149348570b ./gcc/simplify-rtx.c 3345261950b ./gcc/sort-protos 4238707268b ./gcc/ssa.c *************** *** 2064,2075 **** 2395322097b ./gcc/stab.def 471587796b ./gcc/stack.h 335514606b ./gcc/stmt.c ! 3592329788b ./gcc/stor-layout.c 1839687809b ./gcc/stringpool.c 567176141b ./gcc/sys-protos.h 482558466b ./gcc/sys-types.h 949648988b ./gcc/system.h ! 1804751077b ./gcc/testsuite/ChangeLog 986418331b ./gcc/testsuite/README 4258789052b ./gcc/testsuite/README.g++ 174183124b ./gcc/testsuite/README.gcc --- 2062,2073 ---- 2395322097b ./gcc/stab.def 471587796b ./gcc/stack.h 335514606b ./gcc/stmt.c ! 996837816b ./gcc/stor-layout.c 1839687809b ./gcc/stringpool.c 567176141b ./gcc/sys-protos.h 482558466b ./gcc/sys-types.h 949648988b ./gcc/system.h ! 1554221349b ./gcc/testsuite/ChangeLog 986418331b ./gcc/testsuite/README 4258789052b ./gcc/testsuite/README.g++ 174183124b ./gcc/testsuite/README.gcc *************** *** 2085,2090 **** --- 2083,2089 ---- 1078385668b ./gcc/testsuite/g++.dg/special/ecos.exp 2770706292b ./gcc/testsuite/g++.dg/special/initp1.C 873911472b ./gcc/testsuite/g++.dg/stdbool-if.C + 3595370582b ./gcc/testsuite/g++.dg/unify1.C 1148935665b ./gcc/testsuite/g++.dg/vtgc1.C 400952277b ./gcc/testsuite/g++.old-deja/g++.abi/aggregates.C 999778394b ./gcc/testsuite/g++.old-deja/g++.abi/align.C *************** *** 2104,2110 **** 1642224875b ./gcc/testsuite/g++.old-deja/g++.abi/primary4.C 758749582b ./gcc/testsuite/g++.old-deja/g++.abi/primary5.C 1620071560b ./gcc/testsuite/g++.old-deja/g++.abi/ptrflags.C ! 3932213883b ./gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C 627664718b ./gcc/testsuite/g++.old-deja/g++.abi/vbase1.C 1393433492b ./gcc/testsuite/g++.old-deja/g++.abi/vbase2.C 1591406699b ./gcc/testsuite/g++.old-deja/g++.abi/vbase3.C --- 2103,2109 ---- 1642224875b ./gcc/testsuite/g++.old-deja/g++.abi/primary4.C 758749582b ./gcc/testsuite/g++.old-deja/g++.abi/primary5.C 1620071560b ./gcc/testsuite/g++.old-deja/g++.abi/ptrflags.C ! 990658695b ./gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C 627664718b ./gcc/testsuite/g++.old-deja/g++.abi/vbase1.C 1393433492b ./gcc/testsuite/g++.old-deja/g++.abi/vbase2.C 1591406699b ./gcc/testsuite/g++.old-deja/g++.abi/vbase3.C *************** *** 2117,2125 **** 3642163828b ./gcc/testsuite/g++.old-deja/g++.abi/vbase8-22.C 3914589079b ./gcc/testsuite/g++.old-deja/g++.abi/vbase8-5.C 3332397893b ./gcc/testsuite/g++.old-deja/g++.abi/vbase8-9.C 186405531b ./gcc/testsuite/g++.old-deja/g++.abi/vmihint.C 2313706108b ./gcc/testsuite/g++.old-deja/g++.abi/vtable.C ! 975228361b ./gcc/testsuite/g++.old-deja/g++.abi/vtable2.C 3689828910b ./gcc/testsuite/g++.old-deja/g++.abi/vtable3.h 88732305b ./gcc/testsuite/g++.old-deja/g++.abi/vtable3a.C 376549672b ./gcc/testsuite/g++.old-deja/g++.abi/vtable3b.C --- 2116,2125 ---- 3642163828b ./gcc/testsuite/g++.old-deja/g++.abi/vbase8-22.C 3914589079b ./gcc/testsuite/g++.old-deja/g++.abi/vbase8-5.C 3332397893b ./gcc/testsuite/g++.old-deja/g++.abi/vbase8-9.C + 4009533659b ./gcc/testsuite/g++.old-deja/g++.abi/vbase9.C 186405531b ./gcc/testsuite/g++.old-deja/g++.abi/vmihint.C 2313706108b ./gcc/testsuite/g++.old-deja/g++.abi/vtable.C ! 1117843110b ./gcc/testsuite/g++.old-deja/g++.abi/vtable2.C 3689828910b ./gcc/testsuite/g++.old-deja/g++.abi/vtable3.h 88732305b ./gcc/testsuite/g++.old-deja/g++.abi/vtable3a.C 376549672b ./gcc/testsuite/g++.old-deja/g++.abi/vtable3b.C *************** *** 3897,3903 **** 3099602163b ./gcc/testsuite/g++.old-deja/g++.ns/using7.C 396388537b ./gcc/testsuite/g++.old-deja/g++.ns/using8.C 536814910b ./gcc/testsuite/g++.old-deja/g++.ns/using9.C ! 242949782b ./gcc/testsuite/g++.old-deja/g++.oliva/ChangeLog 3728265872b ./gcc/testsuite/g++.old-deja/g++.oliva/ctor1.C 3026414575b ./gcc/testsuite/g++.old-deja/g++.oliva/delete1.C 3639944207b ./gcc/testsuite/g++.old-deja/g++.oliva/delete2.C --- 3897,3903 ---- 3099602163b ./gcc/testsuite/g++.old-deja/g++.ns/using7.C 396388537b ./gcc/testsuite/g++.old-deja/g++.ns/using8.C 536814910b ./gcc/testsuite/g++.old-deja/g++.ns/using9.C ! 2957842485b ./gcc/testsuite/g++.old-deja/g++.oliva/ChangeLog 3728265872b ./gcc/testsuite/g++.old-deja/g++.oliva/ctor1.C 3026414575b ./gcc/testsuite/g++.old-deja/g++.oliva/delete1.C 3639944207b ./gcc/testsuite/g++.old-deja/g++.oliva/delete2.C *************** *** 4126,4133 **** 3559396844b ./gcc/testsuite/g++.old-deja/g++.other/eh3.C 3143843455b ./gcc/testsuite/g++.old-deja/g++.other/eh4.C 3053308594b ./gcc/testsuite/g++.old-deja/g++.other/elab1.C ! 1328545493b ./gcc/testsuite/g++.old-deja/g++.other/empty1.C 3170636835b ./gcc/testsuite/g++.old-deja/g++.other/empty2.C 845552508b ./gcc/testsuite/g++.old-deja/g++.other/enum1.C 1384469113b ./gcc/testsuite/g++.old-deja/g++.other/enum2.C 3409398862b ./gcc/testsuite/g++.old-deja/g++.other/enum3.C --- 4126,4134 ---- 3559396844b ./gcc/testsuite/g++.old-deja/g++.other/eh3.C 3143843455b ./gcc/testsuite/g++.old-deja/g++.other/eh4.C 3053308594b ./gcc/testsuite/g++.old-deja/g++.other/elab1.C ! 1418681681b ./gcc/testsuite/g++.old-deja/g++.other/empty1.C 3170636835b ./gcc/testsuite/g++.old-deja/g++.other/empty2.C + 3348313183b ./gcc/testsuite/g++.old-deja/g++.other/empty3.C 845552508b ./gcc/testsuite/g++.old-deja/g++.other/enum1.C 1384469113b ./gcc/testsuite/g++.old-deja/g++.other/enum2.C 3409398862b ./gcc/testsuite/g++.old-deja/g++.other/enum3.C *************** *** 5515,5520 **** --- 5516,5523 ---- 475581102b ./gcc/testsuite/gcc.c-torture/compile/20010605-1.c 1636067950b ./gcc/testsuite/gcc.c-torture/compile/20010610-1.c 3077114319b ./gcc/testsuite/gcc.c-torture/compile/20010611-1.c + 246682254b ./gcc/testsuite/gcc.c-torture/compile/20010903-1.c + 1179192833b ./gcc/testsuite/gcc.c-torture/compile/20011010-1.c 375311401b ./gcc/testsuite/gcc.c-torture/compile/900116-1.c 4181931788b ./gcc/testsuite/gcc.c-torture/compile/900216-1.c 426860692b ./gcc/testsuite/gcc.c-torture/compile/900313-1.c *************** *** 5747,5753 **** 668832071b ./gcc/testsuite/gcc.c-torture/compile/981001-3.c 2581029790b ./gcc/testsuite/gcc.c-torture/compile/981001-4.c 2455813842b ./gcc/testsuite/gcc.c-torture/compile/981006-1.c ! 129420555b ./gcc/testsuite/gcc.c-torture/compile/981006-1.x 436023456b ./gcc/testsuite/gcc.c-torture/compile/981007-1.c 3644509388b ./gcc/testsuite/gcc.c-torture/compile/981022-1.c 2402428546b ./gcc/testsuite/gcc.c-torture/compile/981022-1.x --- 5750,5756 ---- 668832071b ./gcc/testsuite/gcc.c-torture/compile/981001-3.c 2581029790b ./gcc/testsuite/gcc.c-torture/compile/981001-4.c 2455813842b ./gcc/testsuite/gcc.c-torture/compile/981006-1.c ! 2478222990b ./gcc/testsuite/gcc.c-torture/compile/981006-1.x 436023456b ./gcc/testsuite/gcc.c-torture/compile/981007-1.c 3644509388b ./gcc/testsuite/gcc.c-torture/compile/981022-1.c 2402428546b ./gcc/testsuite/gcc.c-torture/compile/981022-1.x *************** *** 5908,5919 **** --- 5911,5927 ---- 3606901851b ./gcc/testsuite/gcc.c-torture/execute/20010224-1.c 1780176502b ./gcc/testsuite/gcc.c-torture/execute/20010325-1.c 111828245b ./gcc/testsuite/gcc.c-torture/execute/20010329-1.c + 4181677122b ./gcc/testsuite/gcc.c-torture/execute/20010403-1.c 2948781834b ./gcc/testsuite/gcc.c-torture/execute/20010422-1.c 3398306936b ./gcc/testsuite/gcc.c-torture/execute/20010604-1.c 1597970944b ./gcc/testsuite/gcc.c-torture/execute/20010605-1.c 2151082111b ./gcc/testsuite/gcc.c-torture/execute/20010605-2.c 3978892519b ./gcc/testsuite/gcc.c-torture/execute/20010724-1.c 1723617799b ./gcc/testsuite/gcc.c-torture/execute/20010724-1.x + 731866148b ./gcc/testsuite/gcc.c-torture/execute/20010904-1.c + 731377342b ./gcc/testsuite/gcc.c-torture/execute/20010904-2.c + 2522784842b ./gcc/testsuite/gcc.c-torture/execute/20010910-1.c + 2728142706b ./gcc/testsuite/gcc.c-torture/execute/20011008-3.c 37158978b ./gcc/testsuite/gcc.c-torture/execute/900409-1.c 1241514475b ./gcc/testsuite/gcc.c-torture/execute/920202-1.c 3659466606b ./gcc/testsuite/gcc.c-torture/execute/920302-1.c *************** *** 6173,6178 **** --- 6181,6187 ---- 1805424399b ./gcc/testsuite/gcc.c-torture/execute/990128-1.c 1406479809b ./gcc/testsuite/gcc.c-torture/execute/990130-1.c 1075245403b ./gcc/testsuite/gcc.c-torture/execute/990208-1.c + 1370072006b ./gcc/testsuite/gcc.c-torture/execute/990208-1.x 1910322968b ./gcc/testsuite/gcc.c-torture/execute/990211-1.c 2520747136b ./gcc/testsuite/gcc.c-torture/execute/990222-1.c 4167898413b ./gcc/testsuite/gcc.c-torture/execute/990324-1.c *************** *** 6694,6699 **** --- 6703,6709 ---- 2498549558b ./gcc/testsuite/gcc.dg/20010202-1.c 3041407018b ./gcc/testsuite/gcc.dg/20010520-1.c 3520626317b ./gcc/testsuite/gcc.dg/20010622-1.c + 100264975b ./gcc/testsuite/gcc.dg/20010912-1.c 1577979025b ./gcc/testsuite/gcc.dg/920413-1.c 2176221389b ./gcc/testsuite/gcc.dg/940409-1.c 1567764883b ./gcc/testsuite/gcc.dg/940510-1.c *************** *** 6729,6734 **** --- 6739,6745 ---- 2092836833b ./gcc/testsuite/gcc.dg/array-2.c 1410330225b ./gcc/testsuite/gcc.dg/array-3.c 3803331180b ./gcc/testsuite/gcc.dg/array-4.c + 2233987289b ./gcc/testsuite/gcc.dg/array-5.c 2814093959b ./gcc/testsuite/gcc.dg/asm-1.c 2130035945b ./gcc/testsuite/gcc.dg/asm-2.c 2531825241b ./gcc/testsuite/gcc.dg/asm-3.c *************** *** 7266,7300 **** 3255809228b ./gcc/tlink.c 3744765622b ./gcc/toplev.c 3421121434b ./gcc/toplev.h ! 1805793420b ./gcc/tradcif.c 2773797431b ./gcc/tradcif.y 3120479866b ./gcc/tradcpp.c 1987124132b ./gcc/tradcpp.h 4149158830b ./gcc/tree.c ! 2661789638b ./gcc/tree.def 1228630084b ./gcc/tree.h 231560538b ./gcc/tsystem.h 4139263293b ./gcc/typeclass.h 17641651b ./gcc/unprotoize.c ! 2728334244b ./gcc/unroll.c 298823486b ./gcc/unwind-dw2-fde.c 2579082273b ./gcc/unwind-dw2-fde.h 1325164416b ./gcc/unwind-dw2.c 2257776618b ./gcc/unwind-pe.h 2658132252b ./gcc/unwind-sjlj.c ! 1179999985b ./gcc/unwind.h ! 2811456772b ./gcc/unwind.inc ! 1308552935b ./gcc/varasm.c 740604337b ./gcc/varray.c 3918364708b ./gcc/varray.h ! 1173990918b ./gcc/version.c 1227851131b ./gcc/version.h 1040256635b ./gcc/vmsconfig.com 4121715740b ./gcc/xcoffout.c 2574034949b ./gcc/xcoffout.h ! 3788021337b ./gnats.html 2171125041b ./include/COPYING ! 4266871069b ./include/ChangeLog 888917931b ./include/ansidecl.h 1789350587b ./include/demangle.h 2980645374b ./include/dyn-string.h --- 7277,7311 ---- 3255809228b ./gcc/tlink.c 3744765622b ./gcc/toplev.c 3421121434b ./gcc/toplev.h ! 3381960764b ./gcc/tradcif.c 2773797431b ./gcc/tradcif.y 3120479866b ./gcc/tradcpp.c 1987124132b ./gcc/tradcpp.h 4149158830b ./gcc/tree.c ! 1441632713b ./gcc/tree.def 1228630084b ./gcc/tree.h 231560538b ./gcc/tsystem.h 4139263293b ./gcc/typeclass.h 17641651b ./gcc/unprotoize.c ! 3034634162b ./gcc/unroll.c 298823486b ./gcc/unwind-dw2-fde.c 2579082273b ./gcc/unwind-dw2-fde.h 1325164416b ./gcc/unwind-dw2.c 2257776618b ./gcc/unwind-pe.h 2658132252b ./gcc/unwind-sjlj.c ! 1716444183b ./gcc/unwind.h ! 3680807945b ./gcc/unwind.inc ! 1491937623b ./gcc/varasm.c 740604337b ./gcc/varray.c 3918364708b ./gcc/varray.h ! 1464599016b ./gcc/version.c 1227851131b ./gcc/version.h 1040256635b ./gcc/vmsconfig.com 4121715740b ./gcc/xcoffout.c 2574034949b ./gcc/xcoffout.h ! 3832073952b ./gnats.html 2171125041b ./include/COPYING ! 4045792881b ./include/ChangeLog 888917931b ./include/ansidecl.h 1789350587b ./include/demangle.h 2980645374b ./include/dyn-string.h *************** *** 7312,7318 **** 176339077b ./include/splay-tree.h 1653599470b ./include/symcat.h 4171599065b ./install-sh ! 2735711540b ./libf2c/ChangeLog 57434001b ./libf2c/Makefile.in 3111321221b ./libf2c/README 308226469b ./libf2c/TODO --- 7323,7329 ---- 176339077b ./include/splay-tree.h 1653599470b ./include/symcat.h 4171599065b ./install-sh ! 4014153537b ./libf2c/ChangeLog 57434001b ./libf2c/Makefile.in 3111321221b ./libf2c/README 308226469b ./libf2c/TODO *************** *** 7327,7333 **** 1147257543b ./libf2c/libF77/Makefile.in 1384146782b ./libf2c/libF77/Notice 3594711912b ./libf2c/libF77/README.netlib ! 4287439991b ./libf2c/libF77/Version.c 1304659322b ./libf2c/libF77/abort_.c 2143735092b ./libf2c/libF77/c_abs.c 4102372920b ./libf2c/libF77/c_cos.c --- 7338,7344 ---- 1147257543b ./libf2c/libF77/Makefile.in 1384146782b ./libf2c/libF77/Notice 3594711912b ./libf2c/libF77/README.netlib ! 2358276950b ./libf2c/libF77/Version.c 1304659322b ./libf2c/libF77/abort_.c 2143735092b ./libf2c/libF77/c_abs.c 4102372920b ./libf2c/libF77/c_cos.c *************** *** 7459,7465 **** 999500799b ./libf2c/libI77/Makefile.in 1384146782b ./libf2c/libI77/Notice 3744878144b ./libf2c/libI77/README.netlib ! 303392302b ./libf2c/libI77/Version.c 1131505415b ./libf2c/libI77/backspace.c 2398093876b ./libf2c/libI77/close.c 3931934799b ./libf2c/libI77/config.h.in --- 7470,7476 ---- 999500799b ./libf2c/libI77/Makefile.in 1384146782b ./libf2c/libI77/Notice 3744878144b ./libf2c/libI77/README.netlib ! 211241024b ./libf2c/libI77/Version.c 1131505415b ./libf2c/libI77/backspace.c 2398093876b ./libf2c/libI77/close.c 3931934799b ./libf2c/libI77/config.h.in *************** *** 7507,7513 **** 2966234338b ./libf2c/libU77/Makefile.in 572996563b ./libf2c/libU77/PROJECTS 2980229902b ./libf2c/libU77/README ! 1033325637b ./libf2c/libU77/Version.c 1842933802b ./libf2c/libU77/access_.c 4214861580b ./libf2c/libU77/acconfig.h 2301261828b ./libf2c/libU77/aclocal.m4 --- 7518,7524 ---- 2966234338b ./libf2c/libU77/Makefile.in 572996563b ./libf2c/libU77/PROJECTS 2980229902b ./libf2c/libU77/README ! 2451964497b ./libf2c/libU77/Version.c 1842933802b ./libf2c/libU77/access_.c 4214861580b ./libf2c/libU77/acconfig.h 2301261828b ./libf2c/libU77/aclocal.m4 *************** *** 7569,7575 **** 3987376609b ./libf2c/libU77/vxttime_.c 1384146782b ./libf2c/permission.netlib 3513813969b ./libf2c/readme.netlib ! 1599344309b ./libffi/ChangeLog 2412263940b ./libffi/ChangeLog.libgcj 1481682558b ./libffi/ChangeLog.v1 2593181117b ./libffi/LICENSE --- 7580,7586 ---- 3987376609b ./libf2c/libU77/vxttime_.c 1384146782b ./libf2c/permission.netlib 3513813969b ./libf2c/readme.netlib ! 2825692990b ./libffi/ChangeLog 2412263940b ./libffi/ChangeLog.libgcj 1481682558b ./libffi/ChangeLog.v1 2593181117b ./libffi/LICENSE *************** *** 7619,7625 **** 4026965770b ./libffi/src/x86/win32.S 216805921b ./libffi/stamp-h.in 508743035b ./libiberty/COPYING.LIB ! 1214041342b ./libiberty/ChangeLog 1950042116b ./libiberty/Makefile.in 4016047250b ./libiberty/README 4152189310b ./libiberty/aclocal.m4 --- 7630,7636 ---- 4026965770b ./libffi/src/x86/win32.S 216805921b ./libffi/stamp-h.in 508743035b ./libiberty/COPYING.LIB ! 1610441598b ./libiberty/ChangeLog 1950042116b ./libiberty/Makefile.in 4016047250b ./libiberty/README 4152189310b ./libiberty/aclocal.m4 *************** *** 7646,7653 **** 1235651640b ./libiberty/config/mh-fbsd21 2904567379b ./libiberty/config/mh-openedition 2131807358b ./libiberty/config/mh-windows ! 1169495218b ./libiberty/configure ! 634329680b ./libiberty/configure.in 3602665671b ./libiberty/copysign.c 382214955b ./libiberty/cp-demangle.c 2181362183b ./libiberty/cplus-dem.c --- 7657,7664 ---- 1235651640b ./libiberty/config/mh-fbsd21 2904567379b ./libiberty/config/mh-openedition 2131807358b ./libiberty/config/mh-windows ! 424669765b ./libiberty/configure ! 2374920525b ./libiberty/configure.in 3602665671b ./libiberty/copysign.c 382214955b ./libiberty/cp-demangle.c 2181362183b ./libiberty/cplus-dem.c *************** *** 7722,7728 **** 3859667112b ./libiberty/xstrdup.c 2509140929b ./libiberty/xstrerror.c 2171125041b ./libjava/COPYING ! 3405806640b ./libjava/ChangeLog 3473562392b ./libjava/ChangeLog-1999 3913589198b ./libjava/HACKING 2906142423b ./libjava/LIBGCJ_LICENSE --- 7733,7739 ---- 3859667112b ./libiberty/xstrdup.c 2509140929b ./libiberty/xstrerror.c 2171125041b ./libjava/COPYING ! 351416319b ./libjava/ChangeLog 3473562392b ./libjava/ChangeLog-1999 3913589198b ./libjava/HACKING 2906142423b ./libjava/LIBGCJ_LICENSE *************** *** 7792,7798 **** 1925436486b ./libjava/gnu/gcj/awt/GLightweightPeer.java 2128850323b ./libjava/gnu/gcj/convert/BytesToUnicode.java 670718184b ./libjava/gnu/gcj/convert/Convert.java ! 3515894749b ./libjava/gnu/gcj/convert/IOConverter.java 624954174b ./libjava/gnu/gcj/convert/Input_8859_1.java 1230020474b ./libjava/gnu/gcj/convert/Input_ASCII.java 271098151b ./libjava/gnu/gcj/convert/Input_EUCJIS.java --- 7803,7809 ---- 1925436486b ./libjava/gnu/gcj/awt/GLightweightPeer.java 2128850323b ./libjava/gnu/gcj/convert/BytesToUnicode.java 670718184b ./libjava/gnu/gcj/convert/Convert.java ! 1836280018b ./libjava/gnu/gcj/convert/IOConverter.java 624954174b ./libjava/gnu/gcj/convert/Input_8859_1.java 1230020474b ./libjava/gnu/gcj/convert/Input_ASCII.java 271098151b ./libjava/gnu/gcj/convert/Input_EUCJIS.java *************** *** 7812,7818 **** 3336489456b ./libjava/gnu/gcj/convert/Output_SJIS.java 1644529420b ./libjava/gnu/gcj/convert/Output_UTF8.java 1244826212b ./libjava/gnu/gcj/convert/Output_iconv.java ! 1002757377b ./libjava/gnu/gcj/convert/UnicodeToBytes.java 173962255b ./libjava/gnu/gcj/convert/Unicode_to_JIS.cc 3408472191b ./libjava/gnu/gcj/convert/gen-from-JIS.c 3112494990b ./libjava/gnu/gcj/convert/make-trie.c --- 7823,7829 ---- 3336489456b ./libjava/gnu/gcj/convert/Output_SJIS.java 1644529420b ./libjava/gnu/gcj/convert/Output_UTF8.java 1244826212b ./libjava/gnu/gcj/convert/Output_iconv.java ! 1140731374b ./libjava/gnu/gcj/convert/UnicodeToBytes.java 173962255b ./libjava/gnu/gcj/convert/Unicode_to_JIS.cc 3408472191b ./libjava/gnu/gcj/convert/gen-from-JIS.c 3112494990b ./libjava/gnu/gcj/convert/make-trie.c *************** *** 7934,7940 **** 3196660512b ./libjava/include/java-interp.h 770850052b ./libjava/include/java-props.h 1103865457b ./libjava/include/jni.h ! 263050980b ./libjava/include/jvm.h 1398877611b ./libjava/include/jvmpi.h 2161520436b ./libjava/include/name-finder.h 528567171b ./libjava/include/no-gc.h --- 7945,7951 ---- 3196660512b ./libjava/include/java-interp.h 770850052b ./libjava/include/java-props.h 1103865457b ./libjava/include/jni.h ! 422446180b ./libjava/include/jvm.h 1398877611b ./libjava/include/jvmpi.h 2161520436b ./libjava/include/name-finder.h 528567171b ./libjava/include/no-gc.h *************** *** 7945,7951 **** 216805921b ./libjava/include/stamp-h.in 2649356437b ./libjava/include/win32-signal.h 2516944769b ./libjava/include/win32-threads.h ! 1492132191b ./libjava/interpret.cc 2309249335b ./libjava/java/applet/Applet.java 3172045496b ./libjava/java/applet/AppletContext.java 1042170972b ./libjava/java/applet/AppletStub.java --- 7956,7962 ---- 216805921b ./libjava/include/stamp-h.in 2649356437b ./libjava/include/win32-signal.h 2516944769b ./libjava/include/win32-threads.h ! 86111431b ./libjava/interpret.cc 2309249335b ./libjava/java/applet/Applet.java 3172045496b ./libjava/java/applet/AppletContext.java 1042170972b ./libjava/java/applet/AppletStub.java *************** *** 8331,8345 **** 4037044768b ./libjava/java/lang/mprec.c 338852744b ./libjava/java/lang/mprec.h 1038271037b ./libjava/java/lang/natCharacter.cc ! 1374869131b ./libjava/java/lang/natClass.cc ! 397542309b ./libjava/java/lang/natClassLoader.cc 299573242b ./libjava/java/lang/natDouble.cc 2312870767b ./libjava/java/lang/natEcosProcess.cc 91234316b ./libjava/java/lang/natFloat.cc 2021831688b ./libjava/java/lang/natMath.cc 4082444176b ./libjava/java/lang/natObject.cc 1594147159b ./libjava/java/lang/natPosixProcess.cc ! 3209286972b ./libjava/java/lang/natRuntime.cc 305206444b ./libjava/java/lang/natString.cc 269747584b ./libjava/java/lang/natSystem.cc 2135592706b ./libjava/java/lang/natThread.cc --- 8342,8356 ---- 4037044768b ./libjava/java/lang/mprec.c 338852744b ./libjava/java/lang/mprec.h 1038271037b ./libjava/java/lang/natCharacter.cc ! 3926684472b ./libjava/java/lang/natClass.cc ! 2190403644b ./libjava/java/lang/natClassLoader.cc 299573242b ./libjava/java/lang/natDouble.cc 2312870767b ./libjava/java/lang/natEcosProcess.cc 91234316b ./libjava/java/lang/natFloat.cc 2021831688b ./libjava/java/lang/natMath.cc 4082444176b ./libjava/java/lang/natObject.cc 1594147159b ./libjava/java/lang/natPosixProcess.cc ! 4074682623b ./libjava/java/lang/natRuntime.cc 305206444b ./libjava/java/lang/natString.cc 269747584b ./libjava/java/lang/natSystem.cc 2135592706b ./libjava/java/lang/natThread.cc *************** *** 8657,8669 **** 2067382225b ./libjava/javax/naming/spi/InitialContextFactoryBuilder.java 1709476683b ./libjava/javax/naming/spi/NamingManager.java 562080873b ./libjava/javax/naming/spi/ObjectFactory.java ! 1556519848b ./libjava/jni.cc 3263845190b ./libjava/libgcj-test.spec.in 1618850334b ./libjava/libgcj.spec.in 3693275905b ./libjava/libgcjdata.c 1996902805b ./libjava/libltdl/.cvsignore 1530919786b ./libjava/libltdl/COPYING.LIB ! 2940277496b ./libjava/libltdl/ChangeLog 3589765398b ./libjava/libltdl/Makefile.am 2495909158b ./libjava/libltdl/Makefile.in 1322928877b ./libjava/libltdl/README --- 8668,8680 ---- 2067382225b ./libjava/javax/naming/spi/InitialContextFactoryBuilder.java 1709476683b ./libjava/javax/naming/spi/NamingManager.java 562080873b ./libjava/javax/naming/spi/ObjectFactory.java ! 2965503045b ./libjava/jni.cc 3263845190b ./libjava/libgcj-test.spec.in 1618850334b ./libjava/libgcj.spec.in 3693275905b ./libjava/libgcjdata.c 1996902805b ./libjava/libltdl/.cvsignore 1530919786b ./libjava/libltdl/COPYING.LIB ! 3848332079b ./libjava/libltdl/ChangeLog 3589765398b ./libjava/libltdl/Makefile.am 2495909158b ./libjava/libltdl/Makefile.in 1322928877b ./libjava/libltdl/README *************** *** 8678,8690 **** 216805921b ./libjava/libltdl/stamp-h.in 813832923b ./libjava/libtool-version 3999324446b ./libjava/mauve-libgcj ! 2713958675b ./libjava/name-finder.cc 2661739964b ./libjava/no-threads.cc 1286501666b ./libjava/nogc.cc 4005482993b ./libjava/posix-threads.cc 3324310841b ./libjava/posix.cc 1977338832b ./libjava/prims.cc ! 3997383505b ./libjava/resolve.cc 211751055b ./libjava/scripts/MakeDefaultMimeTypes.java 2309086205b ./libjava/scripts/TexinfoDoclet.java 3367494457b ./libjava/scripts/blocks.pl --- 8689,8701 ---- 216805921b ./libjava/libltdl/stamp-h.in 813832923b ./libjava/libtool-version 3999324446b ./libjava/mauve-libgcj ! 705579572b ./libjava/name-finder.cc 2661739964b ./libjava/no-threads.cc 1286501666b ./libjava/nogc.cc 4005482993b ./libjava/posix-threads.cc 3324310841b ./libjava/posix.cc 1977338832b ./libjava/prims.cc ! 791119016b ./libjava/resolve.cc 211751055b ./libjava/scripts/MakeDefaultMimeTypes.java 2309086205b ./libjava/scripts/TexinfoDoclet.java 3367494457b ./libjava/scripts/blocks.pl *************** *** 8694,8700 **** 1359447378b ./libjava/scripts/showval.java 3969226176b ./libjava/sysdep/ia64-frame.h 4255020929b ./libjava/sysdep/ia64.c ! 3850398201b ./libjava/testsuite/ChangeLog 3806425466b ./libjava/testsuite/Makefile.am 1253427395b ./libjava/testsuite/Makefile.in 1230501773b ./libjava/testsuite/config/default.exp --- 8705,8711 ---- 1359447378b ./libjava/scripts/showval.java 3969226176b ./libjava/sysdep/ia64-frame.h 4255020929b ./libjava/sysdep/ia64.c ! 266237528b ./libjava/testsuite/ChangeLog 3806425466b ./libjava/testsuite/Makefile.am 1253427395b ./libjava/testsuite/Makefile.in 1230501773b ./libjava/testsuite/config/default.exp *************** *** 9053,9059 **** 1032868016b ./libjava/testsuite/libjava.mauve/mauve.exp 168151904b ./libjava/testsuite/libjava.mauve/xfails 1531406287b ./libjava/win32-threads.cc ! 866224902b ./libobjc/ChangeLog 3802413505b ./libobjc/Makefile.in 638422313b ./libobjc/NXConstStr.m 3285287551b ./libobjc/Object.m --- 9064,9070 ---- 1032868016b ./libjava/testsuite/libjava.mauve/mauve.exp 168151904b ./libjava/testsuite/libjava.mauve/xfails 1531406287b ./libjava/win32-threads.cc ! 1121501330b ./libobjc/ChangeLog 3802413505b ./libobjc/Makefile.in 638422313b ./libobjc/NXConstStr.m 3285287551b ./libobjc/Object.m *************** *** 9108,9122 **** 2005277748b ./libobjc/thr-vxworks.c 2963027857b ./libobjc/thr-win32.c 1509327042b ./libobjc/thr.c ! 427182117b ./libstdc++-v3/ChangeLog 4193951875b ./libstdc++-v3/ChangeLog-2000 ! 2983129040b ./libstdc++-v3/Makefile.am ! 188555504b ./libstdc++-v3/Makefile.in 476340085b ./libstdc++-v3/README ! 3623435792b ./libstdc++-v3/acconfig.h ! 2868158659b ./libstdc++-v3/acinclude.m4 ! 2329293138b ./libstdc++-v3/aclocal.m4 ! 1314486850b ./libstdc++-v3/config.h.in 1453199454b ./libstdc++-v3/config/basic_file_libio.cc 440650960b ./libstdc++-v3/config/basic_file_libio.h 3327448769b ./libstdc++-v3/config/basic_file_stdio.cc --- 9119,9133 ---- 2005277748b ./libobjc/thr-vxworks.c 2963027857b ./libobjc/thr-win32.c 1509327042b ./libobjc/thr.c ! 1971839529b ./libstdc++-v3/ChangeLog 4193951875b ./libstdc++-v3/ChangeLog-2000 ! 2737980541b ./libstdc++-v3/Makefile.am ! 455890377b ./libstdc++-v3/Makefile.in 476340085b ./libstdc++-v3/README ! 1785366352b ./libstdc++-v3/acconfig.h ! 941843433b ./libstdc++-v3/acinclude.m4 ! 1507045635b ./libstdc++-v3/aclocal.m4 ! 3139938778b ./libstdc++-v3/config.h.in 1453199454b ./libstdc++-v3/config/basic_file_libio.cc 440650960b ./libstdc++-v3/config/basic_file_libio.h 3327448769b ./libstdc++-v3/config/basic_file_stdio.cc *************** *** 9137,9143 **** 2887076979b ./libstdc++-v3/config/cpu/i486/bits/atomicity.h 3880622031b ./libstdc++-v3/config/cpu/ia64/bits/atomicity.h 2211053124b ./libstdc++-v3/config/cpu/m68k/bits/atomicity.h ! 4192061837b ./libstdc++-v3/config/cpu/mips/bits/atomicity.h 632361011b ./libstdc++-v3/config/cpu/powerpc/bits/atomicity.h 2029688870b ./libstdc++-v3/config/cpu/powerpc/bits/limits.h 3930061484b ./libstdc++-v3/config/cpu/s390/bits/atomicity.h --- 9148,9154 ---- 2887076979b ./libstdc++-v3/config/cpu/i486/bits/atomicity.h 3880622031b ./libstdc++-v3/config/cpu/ia64/bits/atomicity.h 2211053124b ./libstdc++-v3/config/cpu/m68k/bits/atomicity.h ! 2747806168b ./libstdc++-v3/config/cpu/mips/bits/atomicity.h 632361011b ./libstdc++-v3/config/cpu/powerpc/bits/atomicity.h 2029688870b ./libstdc++-v3/config/cpu/powerpc/bits/limits.h 3930061484b ./libstdc++-v3/config/cpu/s390/bits/atomicity.h *************** *** 9167,9173 **** 1667394230b ./libstdc++-v3/config/os/gnu-linux/bits/ctype_base.h 172209115b ./libstdc++-v3/config/os/gnu-linux/bits/ctype_inline.h 2769914139b ./libstdc++-v3/config/os/gnu-linux/bits/ctype_noninline.h ! 2434064470b ./libstdc++-v3/config/os/gnu-linux/bits/os_defines.h 2680166297b ./libstdc++-v3/config/os/hpux/bits/ctype_base.h 521899911b ./libstdc++-v3/config/os/hpux/bits/ctype_inline.h 1959980985b ./libstdc++-v3/config/os/hpux/bits/ctype_noninline.h --- 9178,9184 ---- 1667394230b ./libstdc++-v3/config/os/gnu-linux/bits/ctype_base.h 172209115b ./libstdc++-v3/config/os/gnu-linux/bits/ctype_inline.h 2769914139b ./libstdc++-v3/config/os/gnu-linux/bits/ctype_noninline.h ! 2655214212b ./libstdc++-v3/config/os/gnu-linux/bits/os_defines.h 2680166297b ./libstdc++-v3/config/os/hpux/bits/ctype_base.h 521899911b ./libstdc++-v3/config/os/hpux/bits/ctype_inline.h 1959980985b ./libstdc++-v3/config/os/hpux/bits/ctype_noninline.h *************** *** 9198,9207 **** 3980190828b ./libstdc++-v3/config/os/solaris/solaris2.7/bits/ctype_inline.h 1735304697b ./libstdc++-v3/config/os/solaris/solaris2.7/bits/ctype_noninline.h 186536916b ./libstdc++-v3/config/os/solaris/solaris2.7/bits/os_defines.h ! 3525118264b ./libstdc++-v3/configure 3116040814b ./libstdc++-v3/configure.host ! 3995946368b ./libstdc++-v3/configure.in ! 3653801858b ./libstdc++-v3/configure.target 4163616924b ./libstdc++-v3/docs/doxygen/mainpage.doxy 225771389b ./libstdc++-v3/docs/doxygen/maint.cfg.in 2208204477b ./libstdc++-v3/docs/doxygen/run_doxygen --- 9209,9218 ---- 3980190828b ./libstdc++-v3/config/os/solaris/solaris2.7/bits/ctype_inline.h 1735304697b ./libstdc++-v3/config/os/solaris/solaris2.7/bits/ctype_noninline.h 186536916b ./libstdc++-v3/config/os/solaris/solaris2.7/bits/os_defines.h ! 2689720803b ./libstdc++-v3/configure 3116040814b ./libstdc++-v3/configure.host ! 502813057b ./libstdc++-v3/configure.in ! 2732356862b ./libstdc++-v3/configure.target 4163616924b ./libstdc++-v3/docs/doxygen/mainpage.doxy 225771389b ./libstdc++-v3/docs/doxygen/maint.cfg.in 2208204477b ./libstdc++-v3/docs/doxygen/run_doxygen *************** *** 9209,9217 **** 404838806b ./libstdc++-v3/docs/doxygen/user.cfg.in 4001239912b ./libstdc++-v3/docs/html/17_intro/BADNAMES 1897516117b ./libstdc++-v3/docs/html/17_intro/BUGS ! 1994659480b ./libstdc++-v3/docs/html/17_intro/C++STYLE 1484663604b ./libstdc++-v3/docs/html/17_intro/CHECKLIST 2171125041b ./libstdc++-v3/docs/html/17_intro/COPYING 200707478b ./libstdc++-v3/docs/html/17_intro/DESIGN 1363011462b ./libstdc++-v3/docs/html/17_intro/HEADER_POLICY 12001592b ./libstdc++-v3/docs/html/17_intro/PROBLEMS --- 9220,9229 ---- 404838806b ./libstdc++-v3/docs/doxygen/user.cfg.in 4001239912b ./libstdc++-v3/docs/html/17_intro/BADNAMES 1897516117b ./libstdc++-v3/docs/html/17_intro/BUGS ! 1657776562b ./libstdc++-v3/docs/html/17_intro/C++STYLE 1484663604b ./libstdc++-v3/docs/html/17_intro/CHECKLIST 2171125041b ./libstdc++-v3/docs/html/17_intro/COPYING + 3922222294b ./libstdc++-v3/docs/html/17_intro/COPYING.DOC 200707478b ./libstdc++-v3/docs/html/17_intro/DESIGN 1363011462b ./libstdc++-v3/docs/html/17_intro/HEADER_POLICY 12001592b ./libstdc++-v3/docs/html/17_intro/PROBLEMS *************** *** 9219,9260 **** 1612896665b ./libstdc++-v3/docs/html/17_intro/TODO 3997884874b ./libstdc++-v3/docs/html/17_intro/concept_check.diff 3326490253b ./libstdc++-v3/docs/html/17_intro/contribute.html ! 783879501b ./libstdc++-v3/docs/html/17_intro/headers_cc.txt ! 3580331685b ./libstdc++-v3/docs/html/17_intro/howto.html 3565645043b ./libstdc++-v3/docs/html/17_intro/libstdc++-assign.txt 982764901b ./libstdc++-v3/docs/html/17_intro/organization 1278915005b ./libstdc++-v3/docs/html/17_intro/porting-howto.html 3336170739b ./libstdc++-v3/docs/html/17_intro/porting-howto.xml ! 760129033b ./libstdc++-v3/docs/html/18_support/howto.html ! 3928858592b ./libstdc++-v3/docs/html/19_diagnostics/howto.html ! 839083338b ./libstdc++-v3/docs/html/20_util/howto.html 2326263830b ./libstdc++-v3/docs/html/21_strings/gotw29a.txt ! 3584532325b ./libstdc++-v3/docs/html/21_strings/howto.html 3590781787b ./libstdc++-v3/docs/html/21_strings/stringtok_h.txt 3437467499b ./libstdc++-v3/docs/html/21_strings/stringtok_std_h.txt ! 1583334233b ./libstdc++-v3/docs/html/22_locale/codecvt.html ! 1957145555b ./libstdc++-v3/docs/html/22_locale/ctype.html ! 2288193034b ./libstdc++-v3/docs/html/22_locale/howto.html ! 2337980751b ./libstdc++-v3/docs/html/22_locale/locale.html ! 40197418b ./libstdc++-v3/docs/html/23_containers/howto.html 3458392326b ./libstdc++-v3/docs/html/23_containers/wrappers_h.txt ! 399881265b ./libstdc++-v3/docs/html/24_iterators/howto.html ! 3620204091b ./libstdc++-v3/docs/html/25_algorithms/howto.html ! 1991083162b ./libstdc++-v3/docs/html/26_numerics/howto.html 2452165260b ./libstdc++-v3/docs/html/27_io/binary_iostreams_kanze.txt 3249620502b ./libstdc++-v3/docs/html/27_io/binary_iostreams_kuehl.txt ! 3473074324b ./libstdc++-v3/docs/html/27_io/howto.html 1631173890b ./libstdc++-v3/docs/html/Makefile ! 2575593071b ./libstdc++-v3/docs/html/configopts.html ! 658418595b ./libstdc++-v3/docs/html/documentation.html ! 2090229703b ./libstdc++-v3/docs/html/explanations.html ! 1651767880b ./libstdc++-v3/docs/html/ext/howto.html ! 3210824684b ./libstdc++-v3/docs/html/faq/index.html ! 3130354152b ./libstdc++-v3/docs/html/faq/index.txt ! 122913300b ./libstdc++-v3/docs/html/install.html 2049389478b ./libstdc++-v3/docs/html/lib3styles.css ! 4020997386b ./libstdc++-v3/include/Makefile.am ! 3653389813b ./libstdc++-v3/include/Makefile.in 3124086694b ./libstdc++-v3/include/backward/algo.h 3952415343b ./libstdc++-v3/include/backward/algobase.h 3083859890b ./libstdc++-v3/include/backward/alloc.h --- 9231,9277 ---- 1612896665b ./libstdc++-v3/docs/html/17_intro/TODO 3997884874b ./libstdc++-v3/docs/html/17_intro/concept_check.diff 3326490253b ./libstdc++-v3/docs/html/17_intro/contribute.html ! 3461116413b ./libstdc++-v3/docs/html/17_intro/headers_cc.txt ! 2817107662b ./libstdc++-v3/docs/html/17_intro/howto.html 3565645043b ./libstdc++-v3/docs/html/17_intro/libstdc++-assign.txt + 2228462606b ./libstdc++-v3/docs/html/17_intro/license.html 982764901b ./libstdc++-v3/docs/html/17_intro/organization 1278915005b ./libstdc++-v3/docs/html/17_intro/porting-howto.html 3336170739b ./libstdc++-v3/docs/html/17_intro/porting-howto.xml ! 2063480760b ./libstdc++-v3/docs/html/18_support/howto.html ! 1410322631b ./libstdc++-v3/docs/html/19_diagnostics/howto.html ! 2835046806b ./libstdc++-v3/docs/html/20_util/howto.html 2326263830b ./libstdc++-v3/docs/html/21_strings/gotw29a.txt ! 456495239b ./libstdc++-v3/docs/html/21_strings/howto.html 3590781787b ./libstdc++-v3/docs/html/21_strings/stringtok_h.txt 3437467499b ./libstdc++-v3/docs/html/21_strings/stringtok_std_h.txt ! 2957885157b ./libstdc++-v3/docs/html/22_locale/codecvt.html ! 2826225921b ./libstdc++-v3/docs/html/22_locale/ctype.html ! 1554570816b ./libstdc++-v3/docs/html/22_locale/howto.html ! 60951948b ./libstdc++-v3/docs/html/22_locale/locale.html ! 2961292476b ./libstdc++-v3/docs/html/22_locale/messages.html ! 3038307209b ./libstdc++-v3/docs/html/23_containers/howto.html 3458392326b ./libstdc++-v3/docs/html/23_containers/wrappers_h.txt ! 403270116b ./libstdc++-v3/docs/html/24_iterators/howto.html ! 2968708740b ./libstdc++-v3/docs/html/25_algorithms/howto.html ! 4004053273b ./libstdc++-v3/docs/html/26_numerics/howto.html 2452165260b ./libstdc++-v3/docs/html/27_io/binary_iostreams_kanze.txt 3249620502b ./libstdc++-v3/docs/html/27_io/binary_iostreams_kuehl.txt ! 3113980624b ./libstdc++-v3/docs/html/27_io/howto.html 1631173890b ./libstdc++-v3/docs/html/Makefile ! 1903336430b ./libstdc++-v3/docs/html/configopts.html ! 95080851b ./libstdc++-v3/docs/html/documentation.html ! 3445372463b ./libstdc++-v3/docs/html/explanations.html ! 2886809538b ./libstdc++-v3/docs/html/ext/howto.html ! 2864809450b ./libstdc++-v3/docs/html/ext/lwg-active.html ! 3144932103b ./libstdc++-v3/docs/html/ext/lwg-defects.html ! 2490001280b ./libstdc++-v3/docs/html/ext/sgiexts.html ! 3349943401b ./libstdc++-v3/docs/html/faq/index.html ! 3450973058b ./libstdc++-v3/docs/html/faq/index.txt ! 3510747379b ./libstdc++-v3/docs/html/install.html 2049389478b ./libstdc++-v3/docs/html/lib3styles.css ! 1018934202b ./libstdc++-v3/include/Makefile.am ! 4040751705b ./libstdc++-v3/include/Makefile.in 3124086694b ./libstdc++-v3/include/backward/algo.h 3952415343b ./libstdc++-v3/include/backward/algobase.h 3083859890b ./libstdc++-v3/include/backward/alloc.h *************** *** 9298,9304 **** 2082508960b ./libstdc++-v3/include/bits/basic_string.h 1857306722b ./libstdc++-v3/include/bits/basic_string.tcc 1664028266b ./libstdc++-v3/include/bits/boost_concept_check.h ! 2383241272b ./libstdc++-v3/include/bits/c++config 2314692779b ./libstdc++-v3/include/bits/char_traits.h 2805936695b ./libstdc++-v3/include/bits/codecvt.h 4120003531b ./libstdc++-v3/include/bits/concept_check.h --- 9315,9321 ---- 2082508960b ./libstdc++-v3/include/bits/basic_string.h 1857306722b ./libstdc++-v3/include/bits/basic_string.tcc 1664028266b ./libstdc++-v3/include/bits/boost_concept_check.h ! 3612158683b ./libstdc++-v3/include/bits/c++config 2314692779b ./libstdc++-v3/include/bits/char_traits.h 2805936695b ./libstdc++-v3/include/bits/codecvt.h 4120003531b ./libstdc++-v3/include/bits/concept_check.h *************** *** 9338,9344 **** 2709925409b ./libstdc++-v3/include/bits/std_iostream.h 570267107b ./libstdc++-v3/include/bits/std_istream.h 2834882043b ./libstdc++-v3/include/bits/std_iterator.h ! 4140823078b ./libstdc++-v3/include/bits/std_limits.h 2877785888b ./libstdc++-v3/include/bits/std_list.h 3961142338b ./libstdc++-v3/include/bits/std_locale.h 201090893b ./libstdc++-v3/include/bits/std_map.h --- 9355,9361 ---- 2709925409b ./libstdc++-v3/include/bits/std_iostream.h 570267107b ./libstdc++-v3/include/bits/std_istream.h 2834882043b ./libstdc++-v3/include/bits/std_iterator.h ! 243895402b ./libstdc++-v3/include/bits/std_limits.h 2877785888b ./libstdc++-v3/include/bits/std_list.h 3961142338b ./libstdc++-v3/include/bits/std_locale.h 201090893b ./libstdc++-v3/include/bits/std_map.h *************** *** 9382,9388 **** 4190899759b ./libstdc++-v3/include/bits/stl_stack.h 2706761852b ./libstdc++-v3/include/bits/stl_tempbuf.h 4173037205b ./libstdc++-v3/include/bits/stl_threads.h ! 800388815b ./libstdc++-v3/include/bits/stl_tree.h 2510296522b ./libstdc++-v3/include/bits/stl_uninitialized.h 3933418180b ./libstdc++-v3/include/bits/stl_vector.h 2427064909b ./libstdc++-v3/include/bits/streambuf.tcc --- 9399,9405 ---- 4190899759b ./libstdc++-v3/include/bits/stl_stack.h 2706761852b ./libstdc++-v3/include/bits/stl_tempbuf.h 4173037205b ./libstdc++-v3/include/bits/stl_threads.h ! 885729826b ./libstdc++-v3/include/bits/stl_tree.h 2510296522b ./libstdc++-v3/include/bits/stl_uninitialized.h 3933418180b ./libstdc++-v3/include/bits/stl_vector.h 2427064909b ./libstdc++-v3/include/bits/streambuf.tcc *************** *** 9462,9484 **** 3189910958b ./libstdc++-v3/include/c_shadow/wchar.h 887325795b ./libstdc++-v3/include/c_shadow/wctype.h 4087026299b ./libstdc++-v3/include/c_std/bits/cmath.tcc ! 3665828964b ./libstdc++-v3/include/c_std/bits/std_cassert.h ! 3227211091b ./libstdc++-v3/include/c_std/bits/std_cctype.h ! 2490468855b ./libstdc++-v3/include/c_std/bits/std_cerrno.h ! 2453924167b ./libstdc++-v3/include/c_std/bits/std_cfloat.h ! 707487253b ./libstdc++-v3/include/c_std/bits/std_climits.h ! 3024925417b ./libstdc++-v3/include/c_std/bits/std_clocale.h ! 1949845030b ./libstdc++-v3/include/c_std/bits/std_cmath.h ! 2279758959b ./libstdc++-v3/include/c_std/bits/std_csetjmp.h ! 40068601b ./libstdc++-v3/include/c_std/bits/std_csignal.h ! 3760528725b ./libstdc++-v3/include/c_std/bits/std_cstdarg.h ! 3701324730b ./libstdc++-v3/include/c_std/bits/std_cstddef.h ! 2368623423b ./libstdc++-v3/include/c_std/bits/std_cstdio.h ! 3084491793b ./libstdc++-v3/include/c_std/bits/std_cstdlib.h ! 3354582070b ./libstdc++-v3/include/c_std/bits/std_cstring.h ! 2415161529b ./libstdc++-v3/include/c_std/bits/std_ctime.h ! 14436733b ./libstdc++-v3/include/c_std/bits/std_cwchar.h ! 566063818b ./libstdc++-v3/include/c_std/bits/std_cwctype.h 2457699013b ./libstdc++-v3/include/ext/bvector 32562494b ./libstdc++-v3/include/ext/hash_map 1791958016b ./libstdc++-v3/include/ext/hash_set --- 9479,9501 ---- 3189910958b ./libstdc++-v3/include/c_shadow/wchar.h 887325795b ./libstdc++-v3/include/c_shadow/wctype.h 4087026299b ./libstdc++-v3/include/c_std/bits/cmath.tcc ! 4173967768b ./libstdc++-v3/include/c_std/bits/std_cassert.h ! 3755378346b ./libstdc++-v3/include/c_std/bits/std_cctype.h ! 1941333242b ./libstdc++-v3/include/c_std/bits/std_cerrno.h ! 1754745587b ./libstdc++-v3/include/c_std/bits/std_cfloat.h ! 1073898404b ./libstdc++-v3/include/c_std/bits/std_climits.h ! 1419451335b ./libstdc++-v3/include/c_std/bits/std_clocale.h ! 210118b ./libstdc++-v3/include/c_std/bits/std_cmath.h ! 2753276786b ./libstdc++-v3/include/c_std/bits/std_csetjmp.h ! 3019403730b ./libstdc++-v3/include/c_std/bits/std_csignal.h ! 2011156002b ./libstdc++-v3/include/c_std/bits/std_cstdarg.h ! 1885068282b ./libstdc++-v3/include/c_std/bits/std_cstddef.h ! 1711293805b ./libstdc++-v3/include/c_std/bits/std_cstdio.h ! 459786272b ./libstdc++-v3/include/c_std/bits/std_cstdlib.h ! 3134790463b ./libstdc++-v3/include/c_std/bits/std_cstring.h ! 2488914866b ./libstdc++-v3/include/c_std/bits/std_ctime.h ! 2924979082b ./libstdc++-v3/include/c_std/bits/std_cwchar.h ! 1623200046b ./libstdc++-v3/include/c_std/bits/std_cwctype.h 2457699013b ./libstdc++-v3/include/ext/bvector 32562494b ./libstdc++-v3/include/ext/hash_map 1791958016b ./libstdc++-v3/include/ext/hash_set *************** *** 9537,9543 **** 2645437597b ./libstdc++-v3/include/std/utility 2280752861b ./libstdc++-v3/include/std/valarray 392237057b ./libstdc++-v3/include/std/vector ! 3071558991b ./libstdc++-v3/libio/ChangeLog 226381804b ./libstdc++-v3/libio/Makefile.am 1424658516b ./libstdc++-v3/libio/Makefile.in 314955067b ./libstdc++-v3/libio/_G_config.h --- 9554,9560 ---- 2645437597b ./libstdc++-v3/include/std/utility 2280752861b ./libstdc++-v3/include/std/valarray 392237057b ./libstdc++-v3/include/std/vector ! 131300061b ./libstdc++-v3/libio/ChangeLog 226381804b ./libstdc++-v3/libio/Makefile.am 1424658516b ./libstdc++-v3/libio/Makefile.in 314955067b ./libstdc++-v3/libio/_G_config.h *************** *** 9600,9607 **** 805804711b ./libstdc++-v3/mkinclosure 1536428020b ./libstdc++-v3/mknumeric_limits 2605795304b ./libstdc++-v3/porting.texi ! 2780687464b ./libstdc++-v3/src/Makefile.am ! 4194825822b ./libstdc++-v3/src/Makefile.in 1651858599b ./libstdc++-v3/src/bitset.cc 3659270218b ./libstdc++-v3/src/cmath.cc 3763564632b ./libstdc++-v3/src/codecvt.cc --- 9617,9624 ---- 805804711b ./libstdc++-v3/mkinclosure 1536428020b ./libstdc++-v3/mknumeric_limits 2605795304b ./libstdc++-v3/porting.texi ! 4153290084b ./libstdc++-v3/src/Makefile.am ! 3310504969b ./libstdc++-v3/src/Makefile.in 1651858599b ./libstdc++-v3/src/bitset.cc 3659270218b ./libstdc++-v3/src/cmath.cc 3763564632b ./libstdc++-v3/src/codecvt.cc *************** *** 9624,9630 **** 1651008667b ./libstdc++-v3/src/wstring-inst.cc 3407177850b ./libstdc++-v3/testsuite/17_intro/header_cassert.cc 718483329b ./libstdc++-v3/testsuite/17_intro/header_cerrno.cc ! 1494020948b ./libstdc++-v3/testsuite/17_intro/header_ciso646.cc 2740614555b ./libstdc++-v3/testsuite/17_intro/header_csetjmp.cc 4187004662b ./libstdc++-v3/testsuite/17_intro/header_cstdarg.cc 1187341165b ./libstdc++-v3/testsuite/17_intro/header_cstddef.cc --- 9641,9647 ---- 1651008667b ./libstdc++-v3/src/wstring-inst.cc 3407177850b ./libstdc++-v3/testsuite/17_intro/header_cassert.cc 718483329b ./libstdc++-v3/testsuite/17_intro/header_cerrno.cc ! 292833921b ./libstdc++-v3/testsuite/17_intro/header_ciso646.cc 2740614555b ./libstdc++-v3/testsuite/17_intro/header_csetjmp.cc 4187004662b ./libstdc++-v3/testsuite/17_intro/header_cstdarg.cc 1187341165b ./libstdc++-v3/testsuite/17_intro/header_cstddef.cc *************** *** 9632,9711 **** 2612537129b ./libstdc++-v3/testsuite/17_intro/header_cstdlib.cc 4184074218b ./libstdc++-v3/testsuite/17_intro/header_cstring.cc 446409895b ./libstdc++-v3/testsuite/17_intro/header_ctime.cc ! 3925991762b ./libstdc++-v3/testsuite/17_intro/header_cwchar.cc ! 488260507b ./libstdc++-v3/testsuite/17_intro/header_cwctype.cc ! 4080582439b ./libstdc++-v3/testsuite/17_intro/header_fstream.cc ! 2554052199b ./libstdc++-v3/testsuite/17_intro/header_iomanip.cc ! 1960478372b ./libstdc++-v3/testsuite/17_intro/header_ios.cc ! 1010657727b ./libstdc++-v3/testsuite/17_intro/header_iosfwd.cc ! 2496163297b ./libstdc++-v3/testsuite/17_intro/header_iostream.cc ! 341374387b ./libstdc++-v3/testsuite/17_intro/header_istream.cc ! 3410503300b ./libstdc++-v3/testsuite/17_intro/header_ostream.cc ! 2483682048b ./libstdc++-v3/testsuite/17_intro/header_sstream.cc ! 3141274919b ./libstdc++-v3/testsuite/17_intro/header_streambuf.cc 3461116413b ./libstdc++-v3/testsuite/17_intro/headers.cc 2076357409b ./libstdc++-v3/testsuite/17_intro/headers_c++.cc 3404318748b ./libstdc++-v3/testsuite/17_intro/headers_c.cc ! 174189524b ./libstdc++-v3/testsuite/18_support/numeric_limits.cc ! 3698335203b ./libstdc++-v3/testsuite/19_diagnostics/stdexceptions.cc ! 4089433858b ./libstdc++-v3/testsuite/20_util/auto_ptr.cc 4006660250b ./libstdc++-v3/testsuite/20_util/binders.cc ! 1649010988b ./libstdc++-v3/testsuite/21_strings/append.cc ! 856843894b ./libstdc++-v3/testsuite/21_strings/c_strings.cc ! 2618321153b ./libstdc++-v3/testsuite/21_strings/capacity.cc ! 3985370954b ./libstdc++-v3/testsuite/21_strings/char_traits_requirements.cc 4052621376b ./libstdc++-v3/testsuite/21_strings/char_traits_typedefs.cc ! 1265470747b ./libstdc++-v3/testsuite/21_strings/compare.cc ! 1778105169b ./libstdc++-v3/testsuite/21_strings/ctor_copy_dtor.cc ! 4139768422b ./libstdc++-v3/testsuite/21_strings/element_access.cc ! 493313566b ./libstdc++-v3/testsuite/21_strings/find.cc ! 4256816922b ./libstdc++-v3/testsuite/21_strings/insert.cc ! 1875980485b ./libstdc++-v3/testsuite/21_strings/inserters_extractors.cc ! 2582308111b ./libstdc++-v3/testsuite/21_strings/invariants.cc ! 929671461b ./libstdc++-v3/testsuite/21_strings/nonmember.cc ! 627597130b ./libstdc++-v3/testsuite/21_strings/operations.cc ! 169993642b ./libstdc++-v3/testsuite/21_strings/replace.cc ! 1080039855b ./libstdc++-v3/testsuite/21_strings/rfind.cc ! 1797640342b ./libstdc++-v3/testsuite/21_strings/substr.cc ! 43726910b ./libstdc++-v3/testsuite/22_locale/codecvt_char_char.cc ! 2600889589b ./libstdc++-v3/testsuite/22_locale/codecvt_unicode_char.cc ! 3094386971b ./libstdc++-v3/testsuite/22_locale/codecvt_unicode_wchar_t.cc ! 1624488211b ./libstdc++-v3/testsuite/22_locale/codecvt_wchar_t_char.cc ! 3494053967b ./libstdc++-v3/testsuite/22_locale/ctor_copy_dtor.cc 758113484b ./libstdc++-v3/testsuite/22_locale/ctype.cc ! 1655107037b ./libstdc++-v3/testsuite/22_locale/ctype_char_members.cc ! 186356523b ./libstdc++-v3/testsuite/22_locale/ctype_wchar_t_members.cc ! 3393527147b ./libstdc++-v3/testsuite/22_locale/facet.cc ! 4234494707b ./libstdc++-v3/testsuite/22_locale/global_templates.cc ! 1677219878b ./libstdc++-v3/testsuite/22_locale/members.cc 1852213058b ./libstdc++-v3/testsuite/22_locale/numpunct.cc ! 3412735271b ./libstdc++-v3/testsuite/22_locale/numpunct_byname.cc ! 2331480220b ./libstdc++-v3/testsuite/22_locale/numpunct_char_members.cc ! 3239751499b ./libstdc++-v3/testsuite/22_locale/operators.cc ! 3184344053b ./libstdc++-v3/testsuite/22_locale/static_members.cc ! 3678235856b ./libstdc++-v3/testsuite/23_containers/bitset_ctor.cc ! 4155129398b ./libstdc++-v3/testsuite/23_containers/bitset_members.cc ! 4226460375b ./libstdc++-v3/testsuite/23_containers/bitset_shift.cc 3178774718b ./libstdc++-v3/testsuite/23_containers/map_operators.cc 2332883344b ./libstdc++-v3/testsuite/23_containers/multiset.cc 584738240b ./libstdc++-v3/testsuite/23_containers/set_operators.cc ! 37688836b ./libstdc++-v3/testsuite/23_containers/vector_capacity.cc ! 1370781403b ./libstdc++-v3/testsuite/23_containers/vector_ctor.cc ! 2800496824b ./libstdc++-v3/testsuite/23_containers/vector_element_access.cc ! 417244904b ./libstdc++-v3/testsuite/23_containers/vector_modifiers.cc ! 2724503168b ./libstdc++-v3/testsuite/24_iterators/istreambuf_iterator.cc ! 3216307062b ./libstdc++-v3/testsuite/24_iterators/iterator.cc ! 3511007617b ./libstdc++-v3/testsuite/24_iterators/ostreambuf_iterator.cc 499887025b ./libstdc++-v3/testsuite/25_algorithms/equal.cc ! 631583587b ./libstdc++-v3/testsuite/25_algorithms/lower_bound.cc ! 3705954478b ./libstdc++-v3/testsuite/25_algorithms/min_max.cc 825452073b ./libstdc++-v3/testsuite/26_numerics/binary_closure.cc 4174117585b ./libstdc++-v3/testsuite/26_numerics/buggy_complex.cc 477083436b ./libstdc++-v3/testsuite/26_numerics/c99_classification_macros_c++.cc 1943684863b ./libstdc++-v3/testsuite/26_numerics/c99_classification_macros_c.cc ! 2781349120b ./libstdc++-v3/testsuite/26_numerics/c_math.cc ! 4101645345b ./libstdc++-v3/testsuite/26_numerics/complex_inserters_extractors.cc ! 2942362871b ./libstdc++-v3/testsuite/26_numerics/complex_value.cc 2560606731b ./libstdc++-v3/testsuite/26_numerics/fabs_inline.cc 2203801309b ./libstdc++-v3/testsuite/26_numerics/valarray.cc 2289035929b ./libstdc++-v3/testsuite/26_numerics/valarray_const_bracket.cc --- 9649,9729 ---- 2612537129b ./libstdc++-v3/testsuite/17_intro/header_cstdlib.cc 4184074218b ./libstdc++-v3/testsuite/17_intro/header_cstring.cc 446409895b ./libstdc++-v3/testsuite/17_intro/header_ctime.cc ! 545735980b ./libstdc++-v3/testsuite/17_intro/header_cwchar.cc ! 234720762b ./libstdc++-v3/testsuite/17_intro/header_cwctype.cc ! 4050243083b ./libstdc++-v3/testsuite/17_intro/header_fstream.cc ! 31531867b ./libstdc++-v3/testsuite/17_intro/header_iomanip.cc ! 1385850299b ./libstdc++-v3/testsuite/17_intro/header_ios.cc ! 2774643098b ./libstdc++-v3/testsuite/17_intro/header_iosfwd.cc ! 1794666783b ./libstdc++-v3/testsuite/17_intro/header_iostream.cc ! 1280776215b ./libstdc++-v3/testsuite/17_intro/header_istream.cc ! 3671158117b ./libstdc++-v3/testsuite/17_intro/header_ostream.cc ! 161485874b ./libstdc++-v3/testsuite/17_intro/header_sstream.cc ! 553109088b ./libstdc++-v3/testsuite/17_intro/header_streambuf.cc 3461116413b ./libstdc++-v3/testsuite/17_intro/headers.cc 2076357409b ./libstdc++-v3/testsuite/17_intro/headers_c++.cc 3404318748b ./libstdc++-v3/testsuite/17_intro/headers_c.cc ! 1297373821b ./libstdc++-v3/testsuite/18_support/numeric_limits.cc ! 410938608b ./libstdc++-v3/testsuite/19_diagnostics/stdexceptions.cc ! 3136764659b ./libstdc++-v3/testsuite/20_util/auto_ptr.cc 4006660250b ./libstdc++-v3/testsuite/20_util/binders.cc ! 2620430532b ./libstdc++-v3/testsuite/21_strings/append.cc ! 1828225934b ./libstdc++-v3/testsuite/21_strings/c_strings.cc ! 1157819296b ./libstdc++-v3/testsuite/21_strings/capacity.cc ! 2635888646b ./libstdc++-v3/testsuite/21_strings/char_traits_requirements.cc 4052621376b ./libstdc++-v3/testsuite/21_strings/char_traits_typedefs.cc ! 2800726480b ./libstdc++-v3/testsuite/21_strings/compare.cc ! 2548295922b ./libstdc++-v3/testsuite/21_strings/ctor_copy_dtor.cc ! 2661084265b ./libstdc++-v3/testsuite/21_strings/element_access.cc ! 2204151867b ./libstdc++-v3/testsuite/21_strings/find.cc ! 101500475b ./libstdc++-v3/testsuite/21_strings/insert.cc ! 2657132462b ./libstdc++-v3/testsuite/21_strings/inserters_extractors.cc ! 2168000074b ./libstdc++-v3/testsuite/21_strings/invariants.cc ! 1895351902b ./libstdc++-v3/testsuite/21_strings/nonmember.cc ! 1709617082b ./libstdc++-v3/testsuite/21_strings/operations.cc ! 1201188626b ./libstdc++-v3/testsuite/21_strings/replace.cc ! 2718476092b ./libstdc++-v3/testsuite/21_strings/rfind.cc ! 1483165749b ./libstdc++-v3/testsuite/21_strings/substr.cc ! 3866937567b ./libstdc++-v3/testsuite/22_locale/codecvt_char_char.cc ! 636244027b ./libstdc++-v3/testsuite/22_locale/codecvt_unicode_char.cc ! 511768235b ./libstdc++-v3/testsuite/22_locale/codecvt_unicode_wchar_t.cc ! 1812800874b ./libstdc++-v3/testsuite/22_locale/codecvt_wchar_t_char.cc ! 1033440651b ./libstdc++-v3/testsuite/22_locale/ctor_copy_dtor.cc 758113484b ./libstdc++-v3/testsuite/22_locale/ctype.cc ! 985554485b ./libstdc++-v3/testsuite/22_locale/ctype_char_members.cc ! 3584040307b ./libstdc++-v3/testsuite/22_locale/ctype_wchar_t_members.cc ! 2573412066b ./libstdc++-v3/testsuite/22_locale/facet.cc ! 3496730433b ./libstdc++-v3/testsuite/22_locale/global_templates.cc ! 3243201175b ./libstdc++-v3/testsuite/22_locale/members.cc 1852213058b ./libstdc++-v3/testsuite/22_locale/numpunct.cc ! 3463227673b ./libstdc++-v3/testsuite/22_locale/numpunct_byname.cc ! 4085763304b ./libstdc++-v3/testsuite/22_locale/numpunct_char_members.cc ! 1710593315b ./libstdc++-v3/testsuite/22_locale/operators.cc ! 2943563602b ./libstdc++-v3/testsuite/22_locale/static_members.cc ! 3600430355b ./libstdc++-v3/testsuite/23_containers/bitset_ctor.cc ! 475577229b ./libstdc++-v3/testsuite/23_containers/bitset_members.cc ! 897013241b ./libstdc++-v3/testsuite/23_containers/bitset_shift.cc ! 307316045b ./libstdc++-v3/testsuite/23_containers/map_insert.cc 3178774718b ./libstdc++-v3/testsuite/23_containers/map_operators.cc 2332883344b ./libstdc++-v3/testsuite/23_containers/multiset.cc 584738240b ./libstdc++-v3/testsuite/23_containers/set_operators.cc ! 2845787844b ./libstdc++-v3/testsuite/23_containers/vector_capacity.cc ! 2680681229b ./libstdc++-v3/testsuite/23_containers/vector_ctor.cc ! 3683155594b ./libstdc++-v3/testsuite/23_containers/vector_element_access.cc ! 3019110519b ./libstdc++-v3/testsuite/23_containers/vector_modifiers.cc ! 986439371b ./libstdc++-v3/testsuite/24_iterators/istreambuf_iterator.cc ! 1805154351b ./libstdc++-v3/testsuite/24_iterators/iterator.cc ! 1097193416b ./libstdc++-v3/testsuite/24_iterators/ostreambuf_iterator.cc 499887025b ./libstdc++-v3/testsuite/25_algorithms/equal.cc ! 3229510528b ./libstdc++-v3/testsuite/25_algorithms/lower_bound.cc ! 4253988362b ./libstdc++-v3/testsuite/25_algorithms/min_max.cc 825452073b ./libstdc++-v3/testsuite/26_numerics/binary_closure.cc 4174117585b ./libstdc++-v3/testsuite/26_numerics/buggy_complex.cc 477083436b ./libstdc++-v3/testsuite/26_numerics/c99_classification_macros_c++.cc 1943684863b ./libstdc++-v3/testsuite/26_numerics/c99_classification_macros_c.cc ! 162388279b ./libstdc++-v3/testsuite/26_numerics/c_math.cc ! 1078048999b ./libstdc++-v3/testsuite/26_numerics/complex_inserters_extractors.cc ! 4028172023b ./libstdc++-v3/testsuite/26_numerics/complex_value.cc 2560606731b ./libstdc++-v3/testsuite/26_numerics/fabs_inline.cc 2203801309b ./libstdc++-v3/testsuite/26_numerics/valarray.cc 2289035929b ./libstdc++-v3/testsuite/26_numerics/valarray_const_bracket.cc *************** *** 9713,9786 **** 4204648704b ./libstdc++-v3/testsuite/27_io/filebuf-1.txt 655821823b ./libstdc++-v3/testsuite/27_io/filebuf-2.tst 1896106013b ./libstdc++-v3/testsuite/27_io/filebuf-3.tst ! 1237897308b ./libstdc++-v3/testsuite/27_io/filebuf.cc 4294967295b ./libstdc++-v3/testsuite/27_io/filebuf_members-1.tst 4294967295b ./libstdc++-v3/testsuite/27_io/filebuf_members-1.txt ! 3155275885b ./libstdc++-v3/testsuite/27_io/filebuf_members.cc ! 101401905b ./libstdc++-v3/testsuite/27_io/filebuf_virtuals.cc ! 2045761453b ./libstdc++-v3/testsuite/27_io/fpos.cc ! 2710193704b ./libstdc++-v3/testsuite/27_io/fstream_members.cc 4294967295b ./libstdc++-v3/testsuite/27_io/ifstream_members-1.tst 4294967295b ./libstdc++-v3/testsuite/27_io/ifstream_members-1.txt ! 4049414931b ./libstdc++-v3/testsuite/27_io/ifstream_members.cc ! 3127816602b ./libstdc++-v3/testsuite/27_io/ios_base_callbacks.cc 3079502096b ./libstdc++-v3/testsuite/27_io/ios_base_members_static-1.tst ! 220992270b ./libstdc++-v3/testsuite/27_io/ios_base_members_static.cc ! 3625283711b ./libstdc++-v3/testsuite/27_io/ios_base_storage.cc ! 2090651728b ./libstdc++-v3/testsuite/27_io/ios_ctor.cc ! 2561207466b ./libstdc++-v3/testsuite/27_io/ios_init.cc ! 3219580649b ./libstdc++-v3/testsuite/27_io/ios_manip_basefield.cc ! 992448185b ./libstdc++-v3/testsuite/27_io/ios_manip_fmtflags.cc ! 1757256025b ./libstdc++-v3/testsuite/27_io/ios_members.cc 1023084641b ./libstdc++-v3/testsuite/27_io/istream.cc ! 3557806191b ./libstdc++-v3/testsuite/27_io/istream_extractor_arith.cc ! 2209659551b ./libstdc++-v3/testsuite/27_io/istream_extractor_char.cc 1013375821b ./libstdc++-v3/testsuite/27_io/istream_extractor_other-1.tst 1013375821b ./libstdc++-v3/testsuite/27_io/istream_extractor_other-1.txt 1013375821b ./libstdc++-v3/testsuite/27_io/istream_extractor_other-2.tst ! 3295497445b ./libstdc++-v3/testsuite/27_io/istream_extractor_other.cc ! 1835259045b ./libstdc++-v3/testsuite/27_io/istream_manip.cc 3951789237b ./libstdc++-v3/testsuite/27_io/istream_seeks-1.tst 3951789237b ./libstdc++-v3/testsuite/27_io/istream_seeks-1.txt 4294967295b ./libstdc++-v3/testsuite/27_io/istream_seeks-2.tst 2129191219b ./libstdc++-v3/testsuite/27_io/istream_seeks-3.tst ! 1245555215b ./libstdc++-v3/testsuite/27_io/istream_seeks.cc ! 1054070115b ./libstdc++-v3/testsuite/27_io/istream_sentry.cc 38986799b ./libstdc++-v3/testsuite/27_io/istream_unformatted-1.tst 38986799b ./libstdc++-v3/testsuite/27_io/istream_unformatted-1.txt ! 2426526705b ./libstdc++-v3/testsuite/27_io/istream_unformatted.cc ! 262790270b ./libstdc++-v3/testsuite/27_io/istringstream_members.cc ! 868556528b ./libstdc++-v3/testsuite/27_io/narrow_stream_objects.cc 4294967295b ./libstdc++-v3/testsuite/27_io/ofstream_members-1.tst ! 3320775849b ./libstdc++-v3/testsuite/27_io/ofstream_members.cc 1339570826b ./libstdc++-v3/testsuite/27_io/ostream.cc ! 2273977138b ./libstdc++-v3/testsuite/27_io/ostream_inserter_arith.cc 1556078817b ./libstdc++-v3/testsuite/27_io/ostream_inserter_char-1.tst 1556078817b ./libstdc++-v3/testsuite/27_io/ostream_inserter_char-1.txt ! 693260838b ./libstdc++-v3/testsuite/27_io/ostream_inserter_char.cc 4204648704b ./libstdc++-v3/testsuite/27_io/ostream_inserter_other-1.tst 4204648704b ./libstdc++-v3/testsuite/27_io/ostream_inserter_other-2.tst ! 326322335b ./libstdc++-v3/testsuite/27_io/ostream_inserter_other.cc ! 1733584562b ./libstdc++-v3/testsuite/27_io/ostream_manip.cc 4294967295b ./libstdc++-v3/testsuite/27_io/ostream_seeks-1.tst ! 3842422666b ./libstdc++-v3/testsuite/27_io/ostream_seeks.cc ! 1110785128b ./libstdc++-v3/testsuite/27_io/ostream_unformatted.cc ! 679364921b ./libstdc++-v3/testsuite/27_io/ostringstream_members.cc ! 4277495279b ./libstdc++-v3/testsuite/27_io/streambuf.cc ! 1462425224b ./libstdc++-v3/testsuite/27_io/stringbuf.cc ! 2183091853b ./libstdc++-v3/testsuite/27_io/stringbuf_virtuals.cc ! 1703881739b ./libstdc++-v3/testsuite/27_io/stringstream.cc ! 3596528495b ./libstdc++-v3/testsuite/27_io/stringstream_members.cc ! 3615124904b ./libstdc++-v3/testsuite/27_io/wide_stream_objects.cc 2294107082b ./libstdc++-v3/testsuite/Makefile.am 3640355275b ./libstdc++-v3/testsuite/Makefile.in 2848669759b ./libstdc++-v3/testsuite/README 872857903b ./libstdc++-v3/testsuite/config/default.exp - 3288938735b ./libstdc++-v3/testsuite/debug_assert.h 857963154b ./libstdc++-v3/testsuite/ext/headers.cc ! 1821447959b ./libstdc++-v3/testsuite/lib/libstdc++-v3-dg.exp 2361428628b ./libstdc++-v3/testsuite/libstdc++-v3.dg/dg.exp 1352817621b ./libstdc++-v3/testsuite/printnow.c 1283007056b ./libstdc++-v3/testsuite_flags.in 4084702431b ./libtool.m4 2081401147b ./ltcf-c.sh --- 9731,9804 ---- 4204648704b ./libstdc++-v3/testsuite/27_io/filebuf-1.txt 655821823b ./libstdc++-v3/testsuite/27_io/filebuf-2.tst 1896106013b ./libstdc++-v3/testsuite/27_io/filebuf-3.tst ! 3402256454b ./libstdc++-v3/testsuite/27_io/filebuf.cc 4294967295b ./libstdc++-v3/testsuite/27_io/filebuf_members-1.tst 4294967295b ./libstdc++-v3/testsuite/27_io/filebuf_members-1.txt ! 530760041b ./libstdc++-v3/testsuite/27_io/filebuf_members.cc ! 1696922807b ./libstdc++-v3/testsuite/27_io/filebuf_virtuals.cc ! 1987901042b ./libstdc++-v3/testsuite/27_io/fpos.cc ! 358840366b ./libstdc++-v3/testsuite/27_io/fstream_members.cc 4294967295b ./libstdc++-v3/testsuite/27_io/ifstream_members-1.tst 4294967295b ./libstdc++-v3/testsuite/27_io/ifstream_members-1.txt ! 2885752721b ./libstdc++-v3/testsuite/27_io/ifstream_members.cc ! 921559118b ./libstdc++-v3/testsuite/27_io/ios_base_callbacks.cc 3079502096b ./libstdc++-v3/testsuite/27_io/ios_base_members_static-1.tst ! 2904656871b ./libstdc++-v3/testsuite/27_io/ios_base_members_static.cc ! 3946940640b ./libstdc++-v3/testsuite/27_io/ios_base_storage.cc ! 3028704293b ./libstdc++-v3/testsuite/27_io/ios_ctor.cc ! 3943208282b ./libstdc++-v3/testsuite/27_io/ios_init.cc ! 126651840b ./libstdc++-v3/testsuite/27_io/ios_manip_basefield.cc ! 1876828962b ./libstdc++-v3/testsuite/27_io/ios_manip_fmtflags.cc ! 402291869b ./libstdc++-v3/testsuite/27_io/ios_members.cc 1023084641b ./libstdc++-v3/testsuite/27_io/istream.cc ! 773035515b ./libstdc++-v3/testsuite/27_io/istream_extractor_arith.cc ! 262004209b ./libstdc++-v3/testsuite/27_io/istream_extractor_char.cc 1013375821b ./libstdc++-v3/testsuite/27_io/istream_extractor_other-1.tst 1013375821b ./libstdc++-v3/testsuite/27_io/istream_extractor_other-1.txt 1013375821b ./libstdc++-v3/testsuite/27_io/istream_extractor_other-2.tst ! 906991134b ./libstdc++-v3/testsuite/27_io/istream_extractor_other.cc ! 3525724471b ./libstdc++-v3/testsuite/27_io/istream_manip.cc 3951789237b ./libstdc++-v3/testsuite/27_io/istream_seeks-1.tst 3951789237b ./libstdc++-v3/testsuite/27_io/istream_seeks-1.txt 4294967295b ./libstdc++-v3/testsuite/27_io/istream_seeks-2.tst 2129191219b ./libstdc++-v3/testsuite/27_io/istream_seeks-3.tst ! 2005418869b ./libstdc++-v3/testsuite/27_io/istream_seeks.cc ! 3260211703b ./libstdc++-v3/testsuite/27_io/istream_sentry.cc 38986799b ./libstdc++-v3/testsuite/27_io/istream_unformatted-1.tst 38986799b ./libstdc++-v3/testsuite/27_io/istream_unformatted-1.txt ! 2745209174b ./libstdc++-v3/testsuite/27_io/istream_unformatted.cc ! 2607021483b ./libstdc++-v3/testsuite/27_io/istringstream_members.cc ! 496005118b ./libstdc++-v3/testsuite/27_io/narrow_stream_objects.cc 4294967295b ./libstdc++-v3/testsuite/27_io/ofstream_members-1.tst ! 2333857258b ./libstdc++-v3/testsuite/27_io/ofstream_members.cc 1339570826b ./libstdc++-v3/testsuite/27_io/ostream.cc ! 2788616858b ./libstdc++-v3/testsuite/27_io/ostream_inserter_arith.cc 1556078817b ./libstdc++-v3/testsuite/27_io/ostream_inserter_char-1.tst 1556078817b ./libstdc++-v3/testsuite/27_io/ostream_inserter_char-1.txt ! 812427060b ./libstdc++-v3/testsuite/27_io/ostream_inserter_char.cc 4204648704b ./libstdc++-v3/testsuite/27_io/ostream_inserter_other-1.tst 4204648704b ./libstdc++-v3/testsuite/27_io/ostream_inserter_other-2.tst ! 493805556b ./libstdc++-v3/testsuite/27_io/ostream_inserter_other.cc ! 962776286b ./libstdc++-v3/testsuite/27_io/ostream_manip.cc 4294967295b ./libstdc++-v3/testsuite/27_io/ostream_seeks-1.tst ! 1270935874b ./libstdc++-v3/testsuite/27_io/ostream_seeks.cc ! 4124709644b ./libstdc++-v3/testsuite/27_io/ostream_unformatted.cc ! 3304429615b ./libstdc++-v3/testsuite/27_io/ostringstream_members.cc ! 57182980b ./libstdc++-v3/testsuite/27_io/streambuf.cc ! 3983604379b ./libstdc++-v3/testsuite/27_io/stringbuf.cc ! 256529737b ./libstdc++-v3/testsuite/27_io/stringbuf_virtuals.cc ! 3323753738b ./libstdc++-v3/testsuite/27_io/stringstream.cc ! 1600633309b ./libstdc++-v3/testsuite/27_io/stringstream_members.cc ! 365205754b ./libstdc++-v3/testsuite/27_io/wide_stream_objects.cc 2294107082b ./libstdc++-v3/testsuite/Makefile.am 3640355275b ./libstdc++-v3/testsuite/Makefile.in 2848669759b ./libstdc++-v3/testsuite/README 872857903b ./libstdc++-v3/testsuite/config/default.exp 857963154b ./libstdc++-v3/testsuite/ext/headers.cc ! 1601794371b ./libstdc++-v3/testsuite/lib/libstdc++-v3-dg.exp 2361428628b ./libstdc++-v3/testsuite/libstdc++-v3.dg/dg.exp 1352817621b ./libstdc++-v3/testsuite/printnow.c + 1460178224b ./libstdc++-v3/testsuite/testsuite_hooks.h 1283007056b ./libstdc++-v3/testsuite_flags.in 4084702431b ./libtool.m4 2081401147b ./ltcf-c.sh *************** *** 9794,9800 **** 902556840b ./move-if-change 1077958069b ./symlink-tree 1370970362b ./ylwrap ! 825175620b ./zlib/ChangeLog 2655845150b ./zlib/ChangeLog.gcj 3874989574b ./zlib/FAQ 467711448b ./zlib/INDEX --- 9812,9818 ---- 902556840b ./move-if-change 1077958069b ./symlink-tree 1370970362b ./ylwrap ! 1295615007b ./zlib/ChangeLog 2655845150b ./zlib/ChangeLog.gcj 3874989574b ./zlib/FAQ 467711448b ./zlib/INDEX diff -Nrc3pad gcc-3.0.1/BUGS gcc-3.0.2/BUGS *** gcc-3.0.1/BUGS Sun Aug 19 17:45:09 2001 --- gcc-3.0.2/BUGS Tue Oct 23 10:56:16 2001 *************** *** 2,8 **** GCC Bugs The latest version of this document is always available at ! [1]http://gcc.gnu.org/bugs.html. _________________________________________________________________ Table of Contents --- 2,8 ---- GCC Bugs The latest version of this document is always available at ! [1]http://www.gnu.org/software/gcc/bugs.html. _________________________________________________________________ Table of Contents *************** Table of Contents *** 31,40 **** reporting system. Before you report a bug, please check the [19]list of well-known bugs ! and, if possible in any way, try a current development snapshot or ! [20]CodeSourcery's Online Test Compilation. If you want to report a ! bug with egcs 1.x or versions of GCC before 3.0 we strongly recommend ! upgrading to the current release first. Before reporting that GCC compiles your code incorrectly, please compile it with gcc -Wall and see whether this shows anything wrong --- 31,39 ---- reporting system. Before you report a bug, please check the [19]list of well-known bugs ! and, if possible in any way, try a current development snapshot. If ! you want to report a bug with versions of GCC before 3.0 we strongly ! recommend upgrading to the current release first. Before reporting that GCC compiles your code incorrectly, please compile it with gcc -Wall and see whether this shows anything wrong *************** Summarized bug reporting instructions *** 98,106 **** Where to post it ! Please submit your bug report directly to the [21]GCC GNATS bug database. If this is not possible, please mail all information to ! [22]gcc-bugs@gcc.gnu.org. Detailed bug reporting instructions --- 97,105 ---- Where to post it ! Please submit your bug report directly to the [20]GCC GNATS bug database. If this is not possible, please mail all information to ! [21]gcc-bugs@gcc.gnu.org. Detailed bug reporting instructions *************** Detailed bug reporting instructions *** 146,152 **** The gcc lists have message size limits (200 kbytes) and bug reports over those limits will currently be bounced. If your bug is larger ! than that, please post it using the [23]GCC GNATS bug database. If you fail to supply enough information for a bug report to be reproduced, someone will probably ask you to post additional --- 145,151 ---- The gcc lists have message size limits (200 kbytes) and bug reports over those limits will currently be bounced. If your bug is larger ! than that, please post it using the [22]GCC GNATS bug database. If you fail to supply enough information for a bug report to be reproduced, someone will probably ask you to post additional *************** General *** 184,191 **** The following bugs are very frequently reported. * GCC 2.95.2 does not build on GNU/Linux systems using glibc 2.2, ! such as Red Hat 7.0. A [24]patch is available. This is fixed in ! GCC 2.95.3 and GCC 3.0. * GCC 2.95.2 crashes when compiling mbx.c from the PINE 4.30 or IMAP2000 distribution on Sparc systems running Solaris. _________________________________________________________________ --- 183,189 ---- The following bugs are very frequently reported. * GCC 2.95.2 does not build on GNU/Linux systems using glibc 2.2, ! such as Red Hat 7.0. This is fixed in GCC 2.95.3 and GCC 3.0. * GCC 2.95.2 crashes when compiling mbx.c from the PINE 4.30 or IMAP2000 distribution on Sparc systems running Solaris. _________________________________________________________________ *************** General *** 193,200 **** Fortran Fortran bugs are documented in the G77 manual rather than explicitly ! listed here. Please see [25]"Known Causes of Trouble with GNU Fortran" ! in the [26]G77 manual. _________________________________________________________________ C --- 191,198 ---- Fortran Fortran bugs are documented in the G77 manual rather than explicitly ! listed here. Please see [23]Known Causes of Trouble with GNU Fortran ! in the G77 manual. _________________________________________________________________ C *************** C *** 222,229 **** There is a common misconception that the GCC developers are responsible for GNU libc. These are in fact two entirely ! separate projects. The appropriate place to ask questions ! relating to GNU libc is [27]libc-alpha@sources.redhat.com. Cannot use preprocessor directive in macro arguments. Let me guess... you wrote code that looks something like this: --- 220,227 ---- There is a common misconception that the GCC developers are responsible for GNU libc. These are in fact two entirely ! separate projects; please check the [24]GNU libc web pages for ! details. Cannot use preprocessor directive in macro arguments. Let me guess... you wrote code that looks something like this: *************** C++ *** 301,307 **** reported very often, but not yet fixed. While it is certainly better to fix bugs instead of documenting them, this document might save people the effort of writing a bug report when the bug is already ! well-known. [28]How to report bugs tells you how to report a bug. There are many reasons why reported bugs don't get fixed. It might be difficult to fix, or fixing it might break compatibility. Often, --- 299,305 ---- reported very often, but not yet fixed. While it is certainly better to fix bugs instead of documenting them, this document might save people the effort of writing a bug report when the bug is already ! well-known. [25]How to report bugs tells you how to report a bug. There are many reasons why reported bugs don't get fixed. It might be difficult to fix, or fixing it might break compatibility. Often, *************** C++ *** 320,331 **** Common problems updating from G++ 2.95 to G++ 3.0 G++ 3.0 conforms much closer to the ISO C++ standard (available at ! [29]http://www.ncits.org/cplusplus.htm). We have also implemented some of the core and library defect reports (available at ! [30]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html & ! [31]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html respectively). * The ABI has changed. This means that both class layout and name mangling is different. You must recompile all c++ libraries (if --- 318,329 ---- Common problems updating from G++ 2.95 to G++ 3.0 G++ 3.0 conforms much closer to the ISO C++ standard (available at ! [26]http://www.ncits.org/cplusplus.htm). We have also implemented some of the core and library defect reports (available at ! [27]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html & ! [28]http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html respectively). * The ABI has changed. This means that both class layout and name mangling is different. You must recompile all c++ libraries (if *************** C++ *** 421,427 **** the nearest representable number. This is not a bug in the compiler, but an inherent limitation ! of the float and double types. Please study [32]this paper for more information. Missing features --- 419,425 ---- the nearest representable number. This is not a bug in the compiler, but an inherent limitation ! of the float and double types. Please study [29]this paper for more information. Missing features *************** A B::f1(bool b) *** 511,517 **** References ! 1. http://gcc.gnu.org/bugs.html 2. http://gcc.gnu.org/bugs.html#report 3. http://gcc.gnu.org/bugs.html#need 4. http://gcc.gnu.org/bugs.html#dontwant --- 509,515 ---- References ! 1. http://www.gnu.org/software/gcc/bugs.html 2. http://gcc.gnu.org/bugs.html#report 3. http://gcc.gnu.org/bugs.html#need 4. http://gcc.gnu.org/bugs.html#dontwant *************** References *** 530,545 **** 17. http://gcc.gnu.org/bugs.html#-O3 18. http://gcc.gnu.org/gnats.html 19. http://gcc.gnu.org/bugs.html#known ! 20. http://www.codesourcery.com/gcc-compile.shtml ! 21. http://gcc.gnu.org/gnats.html ! 22. mailto:gcc-bugs@gcc.gnu.org ! 23. http://gcc.gnu.org/gnats.html ! 24. http://gcc.gnu.org/install/glibc-2.2.patch ! 25. http://gcc.gnu.org/onlinedocs/g77_bugs.html ! 26. http://gcc.gnu.org/onlinedocs/g77_toc.html ! 27. mailto:libc-alpha@sources.redhat.com ! 28. http://gcc.gnu.org/bugs.html#report ! 29. http://www.ncits.org/cplusplus.htm ! 30. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html ! 31. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html ! 32. http://www.validgh.com/goldberg/paper.ps --- 528,540 ---- 17. http://gcc.gnu.org/bugs.html#-O3 18. http://gcc.gnu.org/gnats.html 19. http://gcc.gnu.org/bugs.html#known ! 20. http://gcc.gnu.org/gnats.html ! 21. mailto:gcc-bugs@gcc.gnu.org ! 22. http://gcc.gnu.org/gnats.html ! 23. http://gcc.gnu.org/onlinedocs/g77_bugs.html ! 24. http://www.gnu.org/software/glibc/ ! 25. http://gcc.gnu.org/bugs.html#report ! 26. http://www.ncits.org/cplusplus.htm ! 27. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html ! 28. http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html ! 29. http://www.validlab.com/goldberg/paper.ps diff -Nrc3pad gcc-3.0.1/ChangeLog gcc-3.0.2/ChangeLog *** gcc-3.0.1/ChangeLog Sun Aug 19 14:08:00 2001 --- gcc-3.0.2/ChangeLog Tue Oct 23 10:18:45 2001 *************** *** 1,3 **** --- 1,15 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + + 2001-10-03 Eric Christopher + + * MAINTAINERS: Replace Gavin with myself as MIPS maintainer. + + 2001-10-02 Joseph S. Myers + + * configure: Handle temporary files securely using mkdir. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/FAQ gcc-3.0.2/FAQ *** gcc-3.0.1/FAQ Sun Aug 19 17:45:10 2001 --- gcc-3.0.2/FAQ Tue Oct 23 10:56:17 2001 *************** *** 2,28 **** GCC Frequently Asked Questions The latest version of this document is always available at ! [1]http://gcc.gnu.org/faq.html. This FAQ tries to answer specific questions concerning GCC. For general information regarding C, C++, resp. Fortran please check the ! [2]comp.lang.c FAQ, [3]comp.lang.c++ FAQ, [4]comp.std.c++ FAQ, and the ! [5]Fortran Information page. ! Other GCC-related FAQs: [6]libstdc++-v3, and [7]GCJ. _________________________________________________________________ Questions ! 1. [8]General information ! 1. [9]What is the relationship between GCC and EGCS? ! 2. [10]What is the relationship between GCC and Cygnus / Red ! Hat? ! 3. [11]What is an open development model? ! 4. [12]How do I report a bug? ! 5. [13]How do I get a bug fixed or a feature added? ! 6. [14]How can I get a development environment for GCC without using CVS? 2. [15]Installation 1. [16]Problems building the Fortran compiler 2. [17]How to install multiple versions of GCC --- 2,28 ---- GCC Frequently Asked Questions The latest version of this document is always available at ! [1]http://www.gnu.org/software/gcc/faq.html. This FAQ tries to answer specific questions concerning GCC. For general information regarding C, C++, resp. Fortran please check the ! [2]comp.lang.c FAQ, [3]comp.std.c++ FAQ, and the [4]Fortran ! Information page. ! Other GCC-related FAQs: [5]libstdc++-v3, and [6]GCJ. _________________________________________________________________ Questions ! 1. [7]General information ! 1. [8]What is the relationship between GCC and EGCS? ! 2. [9]What is the relationship between GCC and Cygnus / Red Hat? ! 3. [10]What is an open development model? ! 4. [11]How do I report a bug? ! 5. [12]How do I get a bug fixed or a feature added? ! 6. [13]How can I get a development environment for GCC without using CVS? + 7. [14]Does GCC work on my platform? 2. [15]Installation 1. [16]Problems building the Fortran compiler 2. [17]How to install multiple versions of GCC *************** *** 35,57 **** 1. [24]Unable to run the testsuite 2. [25]How do I pass flags like -fnew-abi to the testsuite? 3. [26]How can I run the test suite with multiple options? ! 4. [27]Older versions of GCC or EGCS ! 1. [28]Why is there no testsuite in GCC 2.95? ! 2. [29]Is there a stringstream / sstream for gcc 2.95.2? ! 5. [30]Miscellaneous ! 1. [31]Virtual memory exhausted ! 2. [32]Friend Templates ! 3. [33]Why do I need autoconf, bison, xgettext, automake, etc? ! 4. [34]Problems debugging GCC code ! 5. [35]Using GCC with GNAT/Ada ! 6. [36]Why can't I build a shared library? ! 7. [37]How to work around too long C++ symbol names? (-fsquangle) ! 8. [38]When building C++, the linker says my constructors, destructors or virtual tables are undefined, but I defined them ! 9. [39]What is libstdc++-v3 and how can I use it with g++? ! 10. [40]Will GCC someday include an incremental linker? _________________________________________________________________ General information --- 35,53 ---- 1. [24]Unable to run the testsuite 2. [25]How do I pass flags like -fnew-abi to the testsuite? 3. [26]How can I run the test suite with multiple options? ! 4. [27]Older versions of GCC ! 1. [28]Is there a stringstream / sstream for GCC 2.95.2? ! 5. [29]Miscellaneous ! 1. [30]Virtual memory exhausted ! 2. [31]Friend Templates ! 3. [32]Why do I need autoconf, bison, xgettext, automake, etc? ! 4. [33]Why can't I build a shared library? ! 5. [34]How to work around too long C++ symbol names? (-fsquangle) ! 6. [35]When building C++, the linker says my constructors, destructors or virtual tables are undefined, but I defined them ! 7. [36]Will GCC someday include an incremental linker? _________________________________________________________________ General information *************** What is the relationship between GCC and *** 73,79 **** development on the gcc2 compiler and appointed the EGCS project as the official GCC maintainers. The net result was a single project which carries forward GCC development under the ultimate control of the ! [41]GCC Steering Committee. _________________________________________________________________ What is the relationship between GCC and Cygnus / Red Hat? --- 69,75 ---- development on the gcc2 compiler and appointed the EGCS project as the official GCC maintainers. The net result was a single project which carries forward GCC development under the ultimate control of the ! [37]GCC Steering Committee. _________________________________________________________________ What is the relationship between GCC and Cygnus / Red Hat? *************** What is the relationship between GCC and *** 84,90 **** While Red Hat does donate hardware, network connections, code and developer time to GCC development, Red Hat does not control GCC. ! Overall control of GCC is in the hands of the [42]GCC Steering Committee which includes people from a variety of different organizations and backgrounds. The purpose of the steering committee is to make decisions in the best interest of GCC and to help ensure --- 80,86 ---- While Red Hat does donate hardware, network connections, code and developer time to GCC development, Red Hat does not control GCC. ! Overall control of GCC is in the hands of the [38]GCC Steering Committee which includes people from a variety of different organizations and backgrounds. The purpose of the steering committee is to make decisions in the best interest of GCC and to help ensure *************** What is the relationship between GCC and *** 96,102 **** What is an open development model? ! We are using a bazaar style [43][1] approach to GCC development: we make snapshots publicly available to anyone who wants to try them; we welcome anyone to join the development mailing list. All of the discussions on the development mailing list are available via the web. --- 92,98 ---- What is an open development model? ! We are using a bazaar style [39][1] approach to GCC development: we make snapshots publicly available to anyone who wants to try them; we welcome anyone to join the development mailing list. All of the discussions on the development mailing list are available via the web. *************** What is an open development model? *** 134,146 **** the past few months. The paper which started all of this introduced two terms: A cathedral development model versus a bazaar development model. The paper is written by Eric S. Raymond, it is ! called ``[44]The Cathedral and the Bazaar''. The paper is a useful starting point for discussions. _________________________________________________________________ How do I report a bug? ! There are complete instructions [45]here. _________________________________________________________________ How do I get a bug fixed or a feature added? --- 130,142 ---- the past few months. The paper which started all of this introduced two terms: A cathedral development model versus a bazaar development model. The paper is written by Eric S. Raymond, it is ! called ``[40]The Cathedral and the Bazaar''. The paper is a useful starting point for discussions. _________________________________________________________________ How do I report a bug? ! There are complete instructions [41]here. _________________________________________________________________ How do I get a bug fixed or a feature added? *************** How do I get a bug fixed or a feature ad *** 155,168 **** * Hire someone to fix it for you. There are various companies and individuals providing support for GCC. This alternative costs money, but is relatively likely to get results. ! * Report the problem to gcc-bugs and hope that someone will be kind ! enough to fix it for you. While this is certainly possible, and ! often happens, there is no guarantee that it will. You should not ! expect the same response from gcc-bugs that you would see from a ! commercial support organization since the people who read ! gcc-bugs, if they choose to help you, will be volunteering their ! time. This alternative will work best if you follow the directions ! on [46]submitting bugreports. * Fix it yourself. This alternative will probably bring results, if you work hard enough, but will probably take a lot of time, and, depending on the quality of your work and the perceived benefits --- 151,165 ---- * Hire someone to fix it for you. There are various companies and individuals providing support for GCC. This alternative costs money, but is relatively likely to get results. ! * [42]Report the problem to the GCC GNATS bug tracking system and ! hope that someone will be kind enough to fix it for you. While ! this is certainly possible, and often happens, there is no ! guarantee that it will. You should not expect the same response ! from this method that you would see from a commercial support ! organization since the people who read GCC bug reports, if they ! choose to help you, will be volunteering their time. This ! alternative will work best if you follow the directions on ! [43]submitting bugreports. * Fix it yourself. This alternative will probably bring results, if you work hard enough, but will probably take a lot of time, and, depending on the quality of your work and the perceived benefits *************** How do I get a bug fixed or a feature ad *** 173,179 **** How can I get a development environment for GCC without using CVS? GCC snapshots are available from the FTP server and its mirrors; see ! the [47]GCC mirror list. _________________________________________________________________ Installation --- 170,186 ---- How can I get a development environment for GCC without using CVS? GCC snapshots are available from the FTP server and its mirrors; see ! the [44]GCC mirror list. ! _________________________________________________________________ ! ! Does GCC work on my platform? ! ! The host/target specific installation notes for GCC include ! information about known problems with installing or using GCC on ! particular platforms. These are included in the sources for a release ! in INSTALL/specific.html, and the [45]latest version is always ! available at the GCC web site. Reports of successful builds for GCC ! versions [46]3.0 and [47]2.95 are also available at the web site. _________________________________________________________________ Installation *************** Problems building the Fortran compiler *** 187,197 **** In particular, instead of using "make" to build GCC, you should use "make bootstrap" if you are building a native compiler or "make cross" if you are building a cross compiler. - - It has also been reported that the Fortran compiler can not be built - on Red Hat 4.X GNU/Linux for the Alpha. Fixing this may require - upgrading binutils or to Red Hat 5.0; we'll provide more information - as it becomes available. _________________________________________________________________ How to install multiple versions of GCC --- 194,199 ---- *************** How can I run the test suite with multip *** 387,404 **** Older versions of GCC and EGCS ! Why is there no testsuite in GCC 2.95? ! ! The GCC testsuite is not included in the GCC 2.95 release due to the ! uncertain copyright status of some tests. ! ! The GCC team has reviewed the entire testsuite to find and remove any ! tests with uncertain copyright status, following guidelines from Prof. ! Eben Moglen. The testsuite is included in GCC 3.0 and subsequent ! releases. Only a few tests needed to be removed from the testsuite. ! _________________________________________________________________ ! ! Is there a stringstream / sstream for gcc 2.95.2? Yes, it's at: [51]http://gcc.gnu.org/ml/libstdc++/2000-q2/msg00700/sstream. --- 389,395 ---- Older versions of GCC and EGCS ! Is there a stringstream / sstream for GCC 2.95.2? Yes, it's at: [51]http://gcc.gnu.org/ml/libstdc++/2000-q2/msg00700/sstream. *************** Why do I need autoconf, bison, xgettext, *** 501,523 **** of packages. _________________________________________________________________ - Problems debugging GCC code - - On some systems GCC will produce dwarf debug records by default; - however the gdb-4.16 release may not be able to read such debug - records. - - You can either use the argument "-gstabs" instead of "-g" or pick up a - copy of gdb-4.17 to work around the problem. - _________________________________________________________________ - - Using GCC with GNAT/Ada - - The GNU Ada front-end is not currently supported by GCC, but work is - in progress to integrate GNU Ada into the GCC CVS repository and - produce new releases based on current versions of GCC. - _________________________________________________________________ - Why can't I build a shared library? When building a shared library you may get an error message from the --- 492,497 ---- *************** tables are undefined, but I defined them *** 585,600 **** declared pure-virtual [class.dtor]/7. _________________________________________________________________ - What is libstdc++-v3 and how can I use it with g++? - - From the [54]libstdc++-v3 FAQ: "The GNU Standard C++ Library v3, or - libstdc++-2.9x, is an ongoing project to implement the ISO 14882 - Standard C++ library as described in chapters 17 through 27 and annex - D." - - libstdc++-v3 is enabled by default in 3.x releases of GCC. - _________________________________________________________________ - Will GCC someday include an incremental linker? Incremental linking is part of the linker, not the compiler. As such, --- 559,564 ---- *************** Will GCC someday include an incremental *** 604,623 **** References ! 1. http://gcc.gnu.org/faq.html 2. http://www.eskimo.com/~scs/C-faq/top.html ! 3. http://www.cerfnet.com/~mpcline/On-Line-C++-FAQs/ ! 4. http://reality.sgi.com/austern_mti/std-c++/faq.html ! 5. http://www.fortran.com/fortran/info.html ! 6. http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html ! 7. http://gcc.gnu.org/java/faq.html ! 8. http://gcc.gnu.org/faq.html#general ! 9. http://gcc.gnu.org/faq.html#gcc ! 10. http://gcc.gnu.org/faq.html#cygnus ! 11. http://gcc.gnu.org/faq.html#open-development ! 12. http://gcc.gnu.org/faq.html#bugreport ! 13. http://gcc.gnu.org/faq.html#support ! 14. http://gcc.gnu.org/faq.html#noncvs 15. http://gcc.gnu.org/faq.html#installation 16. http://gcc.gnu.org/faq.html#fortran 17. http://gcc.gnu.org/faq.html#multiple --- 568,587 ---- References ! 1. http://www.gnu.org/software/gcc/faq.html 2. http://www.eskimo.com/~scs/C-faq/top.html ! 3. http://reality.sgi.com/austern_mti/std-c++/faq.html ! 4. http://www.fortran.com/fortran/info.html ! 5. http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html ! 6. http://gcc.gnu.org/java/faq.html ! 7. http://gcc.gnu.org/faq.html#general ! 8. http://gcc.gnu.org/faq.html#gcc ! 9. http://gcc.gnu.org/faq.html#cygnus ! 10. http://gcc.gnu.org/faq.html#open-development ! 11. http://gcc.gnu.org/faq.html#bugreport ! 12. http://gcc.gnu.org/faq.html#support ! 13. http://gcc.gnu.org/faq.html#noncvs ! 14. http://gcc.gnu.org/faq.html#platforms 15. http://gcc.gnu.org/faq.html#installation 16. http://gcc.gnu.org/faq.html#fortran 17. http://gcc.gnu.org/faq.html#multiple *************** References *** 631,660 **** 25. http://gcc.gnu.org/faq.html#testoptions 26. http://gcc.gnu.org/faq.html#multipletests 27. http://gcc.gnu.org/faq.html#old ! 28. http://gcc.gnu.org/faq.html#2.95suite ! 29. http://gcc.gnu.org/faq.html#2.95sstream ! 30. http://gcc.gnu.org/faq.html#misc ! 31. http://gcc.gnu.org/faq.html#memexhausted ! 32. http://gcc.gnu.org/faq.html#friend ! 33. http://gcc.gnu.org/faq.html#generated_files ! 34. http://gcc.gnu.org/faq.html#gdb ! 35. http://gcc.gnu.org/faq.html#gnat ! 36. http://gcc.gnu.org/faq.html#picflag-needed ! 37. http://gcc.gnu.org/faq.html#squangle ! 38. http://gcc.gnu.org/faq.html#vtables ! 39. http://gcc.gnu.org/faq.html#libstdc++ ! 40. http://gcc.gnu.org/faq.html#incremental ! 41. http://gcc.gnu.org/steering.html ! 42. http://gcc.gnu.org/steering.html ! 43. http://gcc.gnu.org/faq.html#cathedral-vs-bazaar ! 44. http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ ! 45. http://gcc.gnu.org/bugs.html ! 46. http://gcc.gnu.org/bugs.html ! 47. http://gcc.gnu.org/mirrors.html 48. http://gcc.gnu.org/faq.html#gas 49. http://gcc.gnu.org/install/specific.html 50. http://www.gnu.org/software/dejagnu/dejagnu.html 51. http://gcc.gnu.org/ml/libstdc++/2000-q2/msg00700/sstream 52. ftp://ftp.gnu.org/gnu/ 53. ftp://gcc.gnu.org/pub/gcc/infrastructure/ - 54. http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html --- 595,623 ---- 25. http://gcc.gnu.org/faq.html#testoptions 26. http://gcc.gnu.org/faq.html#multipletests 27. http://gcc.gnu.org/faq.html#old ! 28. http://gcc.gnu.org/faq.html#2.95sstream ! 29. http://gcc.gnu.org/faq.html#misc ! 30. http://gcc.gnu.org/faq.html#memexhausted ! 31. http://gcc.gnu.org/faq.html#friend ! 32. http://gcc.gnu.org/faq.html#generated_files ! 33. http://gcc.gnu.org/faq.html#picflag-needed ! 34. http://gcc.gnu.org/faq.html#squangle ! 35. http://gcc.gnu.org/faq.html#vtables ! 36. http://gcc.gnu.org/faq.html#incremental ! 37. http://gcc.gnu.org/steering.html ! 38. http://gcc.gnu.org/steering.html ! 39. http://gcc.gnu.org/faq.html#cathedral-vs-bazaar ! 40. http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ ! 41. http://gcc.gnu.org/bugs.html ! 42. http://gcc.gnu.org/bugs.html ! 43. http://gcc.gnu.org/bugs.html ! 44. http://gcc.gnu.org/mirrors.html ! 45. http://gcc.gnu.org/install/specific.html ! 46. http://gcc.gnu.org/gcc-3.0/buildstat.html ! 47. http://gcc.gnu.org/gcc-2.95/buildstat.html 48. http://gcc.gnu.org/faq.html#gas 49. http://gcc.gnu.org/install/specific.html 50. http://www.gnu.org/software/dejagnu/dejagnu.html 51. http://gcc.gnu.org/ml/libstdc++/2000-q2/msg00700/sstream 52. ftp://ftp.gnu.org/gnu/ 53. ftp://gcc.gnu.org/pub/gcc/infrastructure/ diff -Nrc3pad gcc-3.0.1/GNATS gcc-3.0.2/GNATS *** gcc-3.0.1/GNATS Sun Aug 19 17:45:10 2001 --- gcc-3.0.2/GNATS Tue Oct 23 10:56:17 2001 *************** *** 64,69 **** --- 64,72 ---- This indicates the GCC subproject which is affected by the problem. Currently, it can be one of + ada + A problem with the Ada compiler, libraries or tools. + bootstrap GCC fails to bootstrap. This should be filed only if a bootstrap failure prevails for an extended period of time diff -Nrc3pad gcc-3.0.1/INSTALL/binaries.html gcc-3.0.2/INSTALL/binaries.html *** gcc-3.0.1/INSTALL/binaries.html Sun Aug 19 17:45:11 2001 --- gcc-3.0.2/INSTALL/binaries.html Tue Oct 23 10:56:17 2001 *************** contact their makers. *** 27,37 ****
  • DOS--DJGPP;
  • HP-UX Porting Center;
  • SCO OpenServer/Unixware; !
  • Solaris (SPARC, Intel)--Sunfreeware;
  • SGI--SGI Freeware; --- 27,42 ----
  • DOS--DJGPP; +
  • HP-UX: + +
  • SCO OpenServer/Unixware; !
  • Solaris 2 (SPARC, Intel)--Sunfreeware;
  • SGI--SGI Freeware; diff -Nrc3pad gcc-3.0.1/INSTALL/build.html gcc-3.0.2/INSTALL/build.html *** gcc-3.0.1/INSTALL/build.html Sun Aug 19 17:45:10 2001 --- gcc-3.0.2/INSTALL/build.html Tue Oct 23 10:56:17 2001 *************** Other broken versions may recompile part *** 20,26 **** installing the compiler.)

    Some commands executed when making the compiler may fail (return a ! non-zero status) and be ignored by make. These failures, which are often due to files that were not found, are expected, and can safely be ignored. --- 20,26 ---- installing the compiler.)

    Some commands executed when making the compiler may fail (return a ! nonzero status) and be ignored by make. These failures, which are often due to files that were not found, are expected, and can safely be ignored. diff -Nrc3pad gcc-3.0.1/INSTALL/configure.html gcc-3.0.2/INSTALL/configure.html *** gcc-3.0.1/INSTALL/configure.html Sun Aug 19 17:45:10 2001 --- gcc-3.0.2/INSTALL/configure.html Tue Oct 23 10:56:17 2001 *************** defaults to /usr/local unle *** 217,223 **** target system triple, such as sparc-sun-solaris2.7, and version denotes the GCC version, such as 3.0.

  • Check operating system specific directories (e.g. /usr/ccs/bin on ! Sun Solaris). Note that these rules do not check for the value of PATH. You may want to use --with-as if no assembler is installed in the --- 217,223 ---- target system triple, such as sparc-sun-solaris2.7, and version denotes the GCC version, such as 3.0.
  • Check operating system specific directories (e.g. /usr/ccs/bin on ! Sun Solaris 2). Note that these rules do not check for the value of PATH. You may want to use --with-as if no assembler is installed in the diff -Nrc3pad gcc-3.0.1/INSTALL/finalinstall.html gcc-3.0.2/INSTALL/finalinstall.html *** gcc-3.0.1/INSTALL/finalinstall.html Sun Aug 19 17:45:10 2001 --- gcc-3.0.2/INSTALL/finalinstall.html Tue Oct 23 10:56:17 2001 *************** that you successfully built and installe *** 31,37 ****

    Include the output from running srcdir/config.guess. (Do not send us the config.guess file itself, just the one-line output from ! running it!) Also specify which version you built.

    We'd also like to know if the host/target specific installation notes --- 31,42 ----

    Include the output from running srcdir/config.guess. (Do not send us the config.guess file itself, just the one-line output from ! running it!) Also specify which version you built. ! If the build was for GNU/Linux, also include the distribution name and version ! (e.g., Red Hat 7.1 or Debian 2.2.3, available from /etc/issue) ! and the version of glibc you used; for RPM-based systems like Red Hat, ! Mandrake, and SuSE type rpm -q glibc to get the glibc version, ! and on systems like Debian and Progeny use dpkg -l libc6.

    We'd also like to know if the host/target specific installation notes diff -Nrc3pad gcc-3.0.1/INSTALL/specific.html gcc-3.0.2/INSTALL/specific.html *** gcc-3.0.1/INSTALL/specific.html Sun Aug 19 17:45:10 2001 --- gcc-3.0.2/INSTALL/specific.html Tue Oct 23 10:56:17 2001 *************** as new information becomes available. *** 54,59 **** --- 54,60 ----

  • i?86-sequent-ptx1* i?86-sequent-ptx2*
  • i?86-*-sysv3*
  • i860-intel-osf* +
  • ia64-*-linux
  • *-lynx-lynxos
  • *-ibm-aix*
  • m32r-*-elf *************** as new information becomes available. *** 98,108 ****
  • romp-*-aos romp-*-mach
  • #s390-*-linux*
  • #s390x-*-linux* !
  • *-*-solaris* !
  • sparc-sun-solaris*
  • sparc-sun-solaris2.7 !
  • *-sun-solaris2.8 !
  • sparc-sun-sunos*
  • sparc-unknown-linux-gnulibc1
  • sparc64-*-*
  • *-*-sysv* --- 99,109 ----
  • romp-*-aos romp-*-mach
  • #s390-*-linux*
  • #s390x-*-linux* !
  • *-*-solaris2* !
  • sparc-sun-solaris2*
  • sparc-sun-solaris2.7 !
  • *-*-solaris2.8 !
  • sparc-sun-sunos4*
  • sparc-unknown-linux-gnulibc1
  • sparc64-*-*
  • *-*-sysv* *************** as new information becomes available. *** 114,120 **** --- 115,121 ---- *************** extern int vsprintf(char *, const char *** 777,783 ****


    !

    *-lynx-lynxos

    LynxOS 2.2 and earlier comes with GCC 1.x already installed as /bin/gcc. You should compile with this instead of /bin/cc. --- 778,809 ----


    !

    ia64-*-linux

    ! !

    IA-64 processor (also known as IPF, or Itanium Processor Family) ! running GNU/Linux. ! !

    The toolchain is not completely finished, so requirements will continue ! to change. ! GCC 3.0.1 and later require glibc 2.2.4. ! GCC 3.0.2 requires binutils from 2001-09-05 or later. ! GCC 3.0.1 requires binutils 2.11.1 or later. ! !

    None of the following versions of GCC has an ABI that is compatible ! with any of the other versions in this list, with the exception that ! Red Hat 2.96 and Trillian 000171 are compatible with each other: ! 3.0.2, 3.0.1, 3.0, Red Hat 2.96, and Trillian 000717. ! This primarily affects C++ programs and programs that create shared libraries. ! Because of these ABI incompatibilities, GCC 3.0.2 is not recommended for ! user programs on GNU/Linux systems built using earlier compiler releases. ! GCC 3.0.2 is recommended for compiling linux, the kernel. ! GCC 3.0.2 is believed to be fully ABI compliant, and hence no more major ! ABI changes are expected. ! !

    !
    ! !

    *-lynx-lynxos

    LynxOS 2.2 and earlier comes with GCC 1.x already installed as /bin/gcc. You should compile with this instead of /bin/cc. *************** installed tools, which produce a.o *** 790,796 ****


    !

    *-ibm-aix*

    AIX Make frequently has problems with GCC makefiles. GNU Make 3.76 or newer is recommended to build on this platform. --- 816,822 ----


    !

    *-ibm-aix*

    AIX Make frequently has problems with GCC makefiles. GNU Make 3.76 or newer is recommended to build on this platform. *************** and function declarations in the origina *** 820,825 **** --- 846,862 ---- not prevent the linker from producing a correct library or runnable executable. +

    GCC's exception handling implementation stores process-specific data in + the shared library which prevents exception handling from working + correctly on AIX in a default installation. To work around this, the + shared objects need to be loaded in the process private segment to + prevent them from being shared and marked read-only. This is + accomplished on AIX by installing the shared libraries + (libgcc_s.a and libstdc++.a) with file permissions + disallowing read-other (chmod a+x,o-r). If the shared libraries + have been used, the shared library segment can be cleaned using the + /usr/sbin/slibclean command. +

    AIX 4.3 utilizes a "large format" archive to support both 32-bit and 64-bit object modules. The routines provided in AIX 4.3.0 and AIX 4.3.1 to parse archive libraries did not handle the new format correctly. *************** linking such as "not a COFF file". The *** 828,853 **** with AIX 4.3.1 should work for a 32-bit environment. The -g option of the archive command may be used to create archives of 32-bit objects using the original "small format". A correct version of the ! routines is shipped with AIX 4.3.2.

    Some versions of the AIX binder (linker) can fail with a relocation overflow severe error when the -bbigtoc option is used to link GCC-produced object files into an executable that overflows the TOC. A fix for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is available from IBM Customer Support and from its ! service.boulder.ibm.com website as PTF U455193.

    The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core with a segmentation fault when invoked by any version of GCC. A fix for APAR IX87327 is available from IBM Customer Support and from its ! service.boulder.ibm.com website as PTF U461879. This fix is incorporated in AIX 4.3.3 and above.

    The initial assembler shipped with AIX 4.3.0 generates incorrect object files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS TO ASSEMBLE/BIND) is available from IBM Customer Support and from its ! service.boulder.ibm.com website as PTF U453956. This fix is incorporated in AIX 4.3.1 and above.

    AIX provides National Language Support (NLS). Compilers and assemblers --- 865,890 ---- with AIX 4.3.1 should work for a 32-bit environment. The -g option of the archive command may be used to create archives of 32-bit objects using the original "small format". A correct version of the ! routines is shipped with AIX 4.3.2 and above.

    Some versions of the AIX binder (linker) can fail with a relocation overflow severe error when the -bbigtoc option is used to link GCC-produced object files into an executable that overflows the TOC. A fix for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is available from IBM Customer Support and from its ! techsupport.services.ibm.com website as PTF U455193.

    The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core with a segmentation fault when invoked by any version of GCC. A fix for APAR IX87327 is available from IBM Customer Support and from its ! techsupport.services.ibm.com website as PTF U461879. This fix is incorporated in AIX 4.3.3 and above.

    The initial assembler shipped with AIX 4.3.0 generates incorrect object files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS TO ASSEMBLE/BIND) is available from IBM Customer Support and from its ! techsupport.services.ibm.com website as PTF U453956. This fix is incorporated in AIX 4.3.1 and above.

    AIX provides National Language Support (NLS). Compilers and assemblers *************** environment variable to C o *** 861,873 ****

    By default, GCC for AIX 4.1 and above produces code that can be used on both Power or PowerPC processors. !

    You can specify a default version for the -mcpu=cpu_type ! switch by using the configure option --with-cpu-cpu_type.


    !

    m32r-*-elf

    Mitsubishi M32R processor. This configuration is intended for embedded systems. --- 898,910 ----

    By default, GCC for AIX 4.1 and above produces code that can be used on both Power or PowerPC processors. !

    A default can be specified with the -mcpu=cpu_type ! switch and using the configure option --with-cpu-cpu_type.


    !

    m32r-*-elf

    Mitsubishi M32R processor. This configuration is intended for embedded systems. *************** This configuration is intended for embed *** 875,881 ****


    !

    m68000-hp-bsd

    HP 9000 series 200 running BSD. Note that the C compiler that comes with this system cannot compile GCC; contact law@cygnus.com --- 912,918 ----


    !

    m68000-hp-bsd

    HP 9000 series 200 running BSD. Note that the C compiler that comes with this system cannot compile GCC; contact law@cygnus.com *************** to get binaries of GCC for bootstrapping *** 884,890 ****


    !

    m6811-elf

    Motorola 68HC11 family micro controllers. These are used in embedded applications. There are no standard Unix configurations. --- 921,927 ----


    !

    m6811-elf

    Motorola 68HC11 family micro controllers. These are used in embedded applications. There are no standard Unix configurations. *************** applications. There are no standard Uni *** 892,898 ****


    !

    m6812-elf

    Motorola 68HC12 family micro controllers. These are used in embedded applications. There are no standard Unix configurations. --- 929,935 ----


    !

    m6812-elf

    Motorola 68HC12 family micro controllers. These are used in embedded applications. There are no standard Unix configurations. *************** applications. There are no standard Uni *** 900,906 ****


    !

    m68k-altos

    Altos 3068. You must use the GNU assembler, linker and debugger. Also, you must fix a kernel bug. --- 937,943 ----


    !

    m68k-altos

    Altos 3068. You must use the GNU assembler, linker and debugger. Also, you must fix a kernel bug. *************** Also, you must fix a kernel bug. *** 908,914 ****


    !

    m68k-apple-aux

    Apple Macintosh running A/UX. You may configure GCC to use either the system assembler and --- 945,951 ----


    !

    m68k-apple-aux

    Apple Macintosh running A/UX. You may configure GCC to use either the system assembler and *************** raises some of the arbitrary limits foun *** 926,932 ****


    !

    m68k-att-sysv

    AT&T 3b1, a.k.a. 7300 PC. This version of GCC cannot be compiled with the system C compiler, which is too buggy. --- 963,969 ----


    !

    m68k-att-sysv

    AT&T 3b1, a.k.a. 7300 PC. This version of GCC cannot be compiled with the system C compiler, which is too buggy. *************** bootstrap. Binaries are available from *** 937,943 ****


    !

    m68k-bull-sysv

    Bull DPX/2 series 200 and 300 with BOS-2.00.45 up to BOS-2.01. GCC works either with native assembler or GNU assembler. You can use --- 974,980 ----


    !

    m68k-bull-sysv

    Bull DPX/2 series 200 and 300 with BOS-2.00.45 up to BOS-2.01. GCC works either with native assembler or GNU assembler. You can use *************** assembler or for availability of the DPX *** 950,956 ****


    !

    m68k-crds-unox

    Use configure unos for building on Unos. --- 987,993 ----


    !

    m68k-crds-unox

    Use configure unos for building on Unos. *************** and linking from that library. *** 988,994 ****


    !

    m68k-hp-hpux

    HP 9000 series 300 or 400 running HP-UX. HP-UX version 8.0 has a bug in the assembler that prevents compilation of GCC. This --- 1025,1031 ----


    !

    m68k-hp-hpux

    HP 9000 series 300 or 400 running HP-UX. HP-UX version 8.0 has a bug in the assembler that prevents compilation of GCC. This *************** to look like: *** 1043,1049 ****


    !

    m68k-*-nextstep*

    Current GCC versions probably do not work on version 2 of the NeXT operating system. --- 1080,1086 ----


    !

    m68k-*-nextstep*

    Current GCC versions probably do not work on version 2 of the NeXT operating system. *************** for this sequence to work. *** 1089,1095 ****


    !

    m68k-ncr-*

    On the Tower models 4n0 and 6n0, by default a process is not allowed to have more than one megabyte of memory. GCC cannot compile --- 1126,1132 ----


    !

    m68k-ncr-*

    On the Tower models 4n0 and 6n0, by default a process is not allowed to have more than one megabyte of memory. GCC cannot compile *************** to the configuration file: *** 1104,1110 ****


    !

    m68k-sun

    Sun 3. We do not provide a configuration file to use the Sun FPA by default, because programs that establish signal handlers for floating --- 1141,1147 ----


    !

    m68k-sun

    Sun 3. We do not provide a configuration file to use the Sun FPA by default, because programs that establish signal handlers for floating *************** point traps inherently cannot work with *** 1113,1126 ****


    !

    m68k-sun-sunos4.1.1

    It is reported that you may need the GNU assembler on this platform.


    !

    m88k-*-svr3

    Motorola m88k running the AT&T/Unisoft/Motorola V.3 reference port. These systems tend to use the Green Hills C, revision 1.8.5, as the --- 1150,1163 ----


    !

    m68k-sun-sunos4.1.1

    It is reported that you may need the GNU assembler on this platform.


    !

    m88k-*-svr3

    Motorola m88k running the AT&T/Unisoft/Motorola V.3 reference port. These systems tend to use the Green Hills C, revision 1.8.5, as the *************** if you have one. *** 1137,1143 ****


    !

    m88k-*-dgux

    Motorola m88k running DG/UX. To build 88open BCS native or cross compilers on DG/UX, specify the configuration name as --- 1174,1180 ----


    !

    m88k-*-dgux

    Motorola m88k running DG/UX. To build 88open BCS native or cross compilers on DG/UX, specify the configuration name as *************** configuration based on the current softw *** 1154,1160 ****


    !

    m88k-tektronix-sysv3

    Tektronix XD88 running UTekV 3.2e. Do not turn on optimization while building stage1 if you bootstrap with --- 1191,1197 ----


    !

    m88k-tektronix-sysv3

    Tektronix XD88 running UTekV 3.2e. Do not turn on optimization while building stage1 if you bootstrap with *************** between stages. *** 1167,1173 ****


    !

    mips-*-*

    If you use the 1.31 version of the MIPS assembler (such as was shipped with Ultrix 3.1), you will need to use the -fno-delayed-branch switch --- 1204,1210 ----


    !

    mips-*-*

    If you use the 1.31 version of the MIPS assembler (such as was shipped with Ultrix 3.1), you will need to use the -fno-delayed-branch switch *************** To protect against this, GCC passes -shared or -call_shared switch. !

    mips-mips-bsd

    MIPS machines running the MIPS operating system in BSD mode. It's possible that some old versions of the system lack the functions --- 1237,1243 ---- linker unless you pass an explicit -shared or -call_shared switch. !

    mips-mips-bsd

    MIPS machines running the MIPS operating system in BSD mode. It's possible that some old versions of the system lack the functions *************** compilers, you may need to add -Wf *** 1220,1226 ****


    !

    mips-dec-*

    MIPS-based DECstations can support three different personalities: Ultrix, DEC OSF/1, and OSF/rose. (Alpha-based DECstation products have --- 1257,1263 ----


    !

    mips-dec-*

    MIPS-based DECstations can support three different personalities: Ultrix, DEC OSF/1, and OSF/rose. (Alpha-based DECstation products have *************** compilers, you may need to add -Wf *** 1252,1258 ****


    !

    mips-mips-riscos*

    If you use the MIPS C compiler to bootstrap, it may be necessary to increase its table size for switch statements with the --- 1289,1295 ----


    !

    mips-mips-riscos*

    If you use the MIPS C compiler to bootstrap, it may be necessary to increase its table size for switch statements with the *************** avoiding a linker bug. *** 1292,1298 ****


    !

    mips-sgi-irix4

    In order to compile GCC on an SGI running IRIX 4, the "c.hdr.lib" option must be installed from the CD-ROM supplied from Silicon Graphics. --- 1329,1335 ----


    !

    mips-sgi-irix4

    In order to compile GCC on an SGI running IRIX 4, the "c.hdr.lib" option must be installed from the CD-ROM supplied from Silicon Graphics. *************** ignored. *** 1322,1328 ****


    !

    mips-sgi-irix5

    This configuration has considerable problems, which will be fixed in a future release. --- 1359,1365 ----


    !

    mips-sgi-irix5

    This configuration has considerable problems, which will be fixed in a future release. *************** not have GNU make available *** 1367,1373 ****


    !

    mips-sgi-irix6

    If you are using IRIX cc as your bootstrap compiler, you must ensure that the N32 ABI is in use. To test this, compile a simple C --- 1404,1410 ----


    !

    mips-sgi-irix6

    If you are using IRIX cc as your bootstrap compiler, you must ensure that the N32 ABI is in use. To test this, compile a simple C *************** information about using GCC on IRIX plat *** 1442,1448 ****


    !

    mips-sony-sysv

    Sony MIPS NEWS. This works in NEWSOS 5.0.1, but not in 5.0.2 (which uses ELF instead of COFF). Support for 5.0.2 will probably be provided --- 1479,1485 ----


    !

    mips-sony-sysv

    Sony MIPS NEWS. This works in NEWSOS 5.0.1, but not in 5.0.2 (which uses ELF instead of COFF). Support for 5.0.2 will probably be provided *************** code generated by GCC when shared librar *** 1452,1465 ****


    !

    ns32k-encore

    Encore ns32000 system. Encore systems are supported only under BSD.


    !

    ns32k-*-genix

    National Semiconductor ns32000 system. Genix has bugs in alloca and malloc; you must get the compiled versions of these from GNU --- 1489,1502 ----


    !

    ns32k-encore

    Encore ns32000 system. Encore systems are supported only under BSD.


    !

    ns32k-*-genix

    National Semiconductor ns32000 system. Genix has bugs in alloca and malloc; you must get the compiled versions of these from GNU *************** Emacs. *** 1468,1481 ****


    !

    ns32k-sequent

    Go to the Berkeley universe before compiling.


    !

    ns32k-utek

    UTEK ns32000 system ("merlin"). The C compiler that comes with this system cannot compile GCC; contact tektronix!reed!mason to get --- 1505,1518 ----


    !

    ns32k-sequent

    Go to the Berkeley universe before compiling.


    !

    ns32k-utek

    UTEK ns32000 system ("merlin"). The C compiler that comes with this system cannot compile GCC; contact tektronix!reed!mason to get *************** binaries of GCC for bootstrapping. *** 1484,1490 ****


    !

    powerpc-*-*

    You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type. --- 1521,1527 ----


    !

    powerpc-*-*

    You can specify a default version for the -mcpu=cpu_type switch by using the configure option --with-cpu-cpu_type. *************** switch by using the configure option


    !

    powerpc-*-elf, powerpc-*-sysv4

    PowerPC system in big endian mode, running System V.4.


    !

    powerpc-*-linux-gnu*

    You will need binutils 2.9.4.0.8 --- 1529,1542 ----


    !

    powerpc-*-elf, powerpc-*-sysv4

    PowerPC system in big endian mode, running System V.4.


    !

    powerpc-*-linux-gnu*

    You will need binutils 2.9.4.0.8 *************** if you initially built it with gcc-2.7.2 *** 1509,1515 ****


    !

    powerpc-*-eabiaix

    Embedded PowerPC system in big endian mode with -mcall-aix selected as the default. --- 1546,1552 ----


    !

    powerpc-*-eabiaix

    Embedded PowerPC system in big endian mode with -mcall-aix selected as the default. *************** the default. *** 1517,1523 ****


    !

    powerpc-*-eabisim

    Embedded PowerPC system in big endian mode for use in running under the PSIM simulator. --- 1554,1560 ----


    !

    powerpc-*-eabisim

    Embedded PowerPC system in big endian mode for use in running under the PSIM simulator. *************** PSIM simulator. *** 1525,1545 ****


    !

    powerpc-*-eabi

    Embedded PowerPC system in big endian mode.


    !

    powerpcle-*-elf, powerpcle-*-sysv4

    PowerPC system in little endian mode, running System V.4.


    !

    powerpcle-*-eabisim

    Embedded PowerPC system in little endian mode for use in running under the PSIM simulator. --- 1562,1582 ----


    !

    powerpc-*-eabi

    Embedded PowerPC system in big endian mode.


    !

    powerpcle-*-elf, powerpcle-*-sysv4

    PowerPC system in little endian mode, running System V.4.


    !

    powerpcle-*-eabisim

    Embedded PowerPC system in little endian mode for use in running under the PSIM simulator. *************** the PSIM simulator. *** 1547,1567 ****


    !

    powerpcle-*-eabi

    Embedded PowerPC system in little endian mode.


    !

    powerpcle-*-winnt, powerpcle-*-pe

    PowerPC system in little endian mode running Windows NT.


    !

    romp-*-aos, romp-*-mach

    The only operating systems supported for the IBM RT PC are AOS and MACH. GCC does not support AIX running on the RT. We recommend you --- 1584,1604 ----


    !

    powerpcle-*-eabi

    Embedded PowerPC system in little endian mode.


    !

    powerpcle-*-winnt, powerpcle-*-pe

    PowerPC system in little endian mode running Windows NT.


    !

    romp-*-aos, romp-*-mach

    The only operating systems supported for the IBM RT PC are AOS and MACH. GCC does not support AIX running on the RT. We recommend you *************** can be safely ignored; the stage 3 compi *** 1574,1618 ****


    !

    s390-*-linux*

    IBM S/390 system running Linux for S/390.


    !

    s390x-*-linux*

    IBM zSeries system (64 bit) running Linux for zSeries.


    !

    *-*-solaris*

    !

    Sun does not ship a C compiler with Solaris. To bootstrap and install GCC you first have to install a pre-built compiler, see our binaries page for details. !

    Solaris' /bin/sh will often fail to configure libstdc++-v3, boehm-gc or libjava. If you encounter this problem, set CONFIG_SHELL to /bin/ksh in your environment and run make bootstrap again. Another possibility that sometimes helps is to remove ! *-*-solaris*/config.cache.

    Solaris 2 comes with a number of optional OS packages. Some of these packages are needed to use GCC fully, namely SUNWarc, SUNWbtool, SUNWesu, SUNWhea, SUNWlibm, SUNWsprot, and SUNWtoo. If you did not install all ! optional packages when installing Solaris, you will need to verify that the packages that GCC needs are installed.

    To check whether an optional package is installed, use the pkginfo command. To add an optional package, use the ! pkgadd command. For further details, see the Solaris documentation. !

    On some versions of Solaris, trying to use the linker and other tools in /usr/ucb to install GCC has been observed to cause trouble. For example, the linker may hang indefinitely. The fix is to remove /usr/ucb from your PATH. --- 1611,1656 ----


    !

    s390-*-linux*

    IBM S/390 system running Linux for S/390.


    !

    s390x-*-linux*

    IBM zSeries system (64 bit) running Linux for zSeries.


    !

    *-*-solaris2*

    !

    Sun does not ship a C compiler with Solaris 2. To bootstrap and install GCC you first have to install a pre-built compiler, see our binaries page for details. !

    The Solaris 2 /bin/sh will often fail to configure ! libstdc++-v3, boehm-gc or libjava. If you encounter this problem, set CONFIG_SHELL to /bin/ksh in your environment and run make bootstrap again. Another possibility that sometimes helps is to remove ! *-*-solaris2*/config.cache.

    Solaris 2 comes with a number of optional OS packages. Some of these packages are needed to use GCC fully, namely SUNWarc, SUNWbtool, SUNWesu, SUNWhea, SUNWlibm, SUNWsprot, and SUNWtoo. If you did not install all ! optional packages when installing Solaris 2, you will need to verify that the packages that GCC needs are installed.

    To check whether an optional package is installed, use the pkginfo command. To add an optional package, use the ! pkgadd command. For further details, see the Solaris 2 documentation. !

    Trying to use the linker and other tools in /usr/ucb to install GCC has been observed to cause trouble. For example, the linker may hang indefinitely. The fix is to remove /usr/ucb from your PATH. *************** For example, the linker may hang indefin *** 1621,1652 **** platform. We recommend the use of GNU binutils 2.11.2 or the vendor tools (Sun as, Sun ld). !

    Unfortunately, C++ shared libraries, including libstdc++, won't work ! properly if assembled with Sun as: the linker will complain about ! relocations in read-only sections, in the definition of virtual ! tables. Also, Sun as fails to process long symbols resulting from ! mangling template-heavy C++ function names.


    !

    sparc-sun-solaris*

    !

    Sun as 4.X is broken in that it cannot cope with long symbol names. A typical error message might look similar to the following:

    /usr/ccs/bin/as: "/var/tmp/ccMsw135.s", line 11041: error: can't compute value of an expression involving an external symbol. !

    This is Sun bug 4237974. This is fixed with patch 108908-02 and has ! been fixed in later (5.x) versions of the assembler.


    !

    sparc-sun-solaris2.7

    !

    Sun patch 107058-01 (1999-01-13) for SPARC Solaris 7 triggers a bug in the dynamic linker. This problem (Sun bug 4210064) affects GCC 2.8 and later, including all EGCS releases. Sun formerly recommended 107058-01 for all Solaris 7 users, but around 1999-09-01 it started to --- 1659,1711 ---- platform. We recommend the use of GNU binutils 2.11.2 or the vendor tools (Sun as, Sun ld). !

    Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or ! newer: g++ will complain that types are missing. These headers assume ! that omitting the type means int; this assumption worked for C89 but ! is wrong for C++, and is now wrong for C99 also. ! !

    g++ accepts such (illegal) constructs with the option ! -fpermissive; it ! will assume that any missing type is int (as defined by C89). ! !

    There are patches for Solaris 2.6 (105633-56 or newer for SPARC, ! 106248-42 or newer for Intel), Solaris 7 (108376-21 or newer for SPARC, ! 108377-20 for Intel), and Solaris 8 (108652-24 or newer for SPARC, ! 108653-22 for Intel) that fix this bug.


    !

    sparc-sun-solaris2*

    !

    Sun as 4.x is broken in that it cannot cope with long symbol names. A typical error message might look similar to the following:

    /usr/ccs/bin/as: "/var/tmp/ccMsw135.s", line 11041: error: can't compute value of an expression involving an external symbol. !

    This is Sun bug 4237974. This is fixed with patch 108908-02 for Solaris ! 2.6 and has been fixed in later (5.x) versions of the assembler, ! starting with Solaris 7. ! !

    Starting with Solaris 7, the operating system is capable of executing ! 64-bit SPARC V9 binaries. GCC 3.0 doesn't properly support this yet. ! Although some patches or recipes to enable this support have been posted ! to various newsgroups and mailing lists, we recommend against using ! them, since the compiler may either crash or, worse, silently generate ! bad code. If you really need this capability now, you might try a CVS ! version of GCC 3.1, which will fully support this. If all you want is ! code tuned for the UltraSPARC CPU, you should try the ! -mtune=ultrasparc option instead, which should be safe from ! those bugs and produce code that, unlike full 64-bit code, can still run ! on non-UltraSPARC machines.


    !

    sparc-sun-solaris2.7

    !

    Sun patch 107058-01 (1999-01-13) for Solaris 7/SPARC triggers a bug in the dynamic linker. This problem (Sun bug 4210064) affects GCC 2.8 and later, including all EGCS releases. Sun formerly recommended 107058-01 for all Solaris 7 users, but around 1999-09-01 it started to *************** recommend it only for people who use Sun *** 1657,1663 ****

  • Do not install Sun patch 107058-01 until after Sun releases a complete patch for bug 4210064. This is the simplest course to take, unless you must also use Sun's C compiler. Unfortunately 107058-01 ! is preinstalled on some new Solaris-based hosts, so you may have to back it out.
  • Copy the original, unpatched Solaris 7 --- 1716,1722 ----
  • Do not install Sun patch 107058-01 until after Sun releases a complete patch for bug 4210064. This is the simplest course to take, unless you must also use Sun's C compiler. Unfortunately 107058-01 ! is preinstalled on some new Solaris 7-based hosts, so you may have to back it out.
  • Copy the original, unpatched Solaris 7 *************** run code generated by GCC; it doesn't su *** 1674,1710 **** the hosts that run GCC itself. Second, Sun says that 106950-03 is only a partial fix for bug 4210064, but Sun doesn't know whether the partial fix is adequate for GCC. Revision -08 or later should fix ! the bug, but (as of 1999-10-06) it is still being tested.


    - - -

    *-sun-solaris2.8

    - -

    Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or - newer: g++ will complain that types are missing. These headers assume - that omitting the type means int; this assumption worked for C89 but - is wrong for C++, and is now wrong for C99 also. - -

    g++ accepts such (illegal) constructs with the option -fpermissive; it - will assume that any missing type is int (as defined by C89). !

    For Solaris 8, this is fixed by revision 24 or later of patch 108652 ! (for SPARCs) or 108653 (for Intels). !

    Solaris 8's linker fails to link some libjava programs if previously-installed GCC java libraries already exist in the configured prefix. For this reason, libgcj is disabled by default on Solaris 8. ! If you use GNU ld, or if you don't have a previously-installed libgcj in the same prefix, use --enable-libgcj to build and install the Java libraries.


    !

    sparc-sun-sunos*

    A bug in the SunOS 4 linker will cause it to crash when linking -fPIC compiled objects (and will therefore not allow you to build --- 1733,1758 ---- the hosts that run GCC itself. Second, Sun says that 106950-03 is only a partial fix for bug 4210064, but Sun doesn't know whether the partial fix is adequate for GCC. Revision -08 or later should fix ! the bug. The current (as of 2001-09-24) revision is -14, and is included in ! the Solaris 7 Recommended Patch Cluster.


    !

    *-*-solaris2.8

    !

    The Solaris 8 linker fails to link some libjava programs if previously-installed GCC java libraries already exist in the configured prefix. For this reason, libgcj is disabled by default on Solaris 8. ! If you use GNU ld, or if you don't have a previously-installed libgcj in the same prefix, use --enable-libgcj to build and install the Java libraries.


    !

    sparc-sun-sunos4*

    A bug in the SunOS 4 linker will cause it to crash when linking -fPIC compiled objects (and will therefore not allow you to build *************** be due to a bug in sh. You *** 1723,1729 ****


    !

    sparc-unknown-linux-gnulibc1

    It has been reported that you might need binutils 2.8.1.0.23 --- 1771,1777 ----


    !

    sparc-unknown-linux-gnulibc1

    It has been reported that you might need binutils 2.8.1.0.23 *************** for this platform, too. *** 1732,1738 ****


    !

    sparc64-*-*

    GCC version 2.95 is not able to compile code correctly for sparc64 targets. Users of the Linux kernel, at least, --- 1780,1786 ----


    !

    sparc64-*-*

    GCC version 2.95 is not able to compile code correctly for sparc64 targets. Users of the Linux kernel, at least, *************** recognize (via uname -a) th *** 1743,1749 ****


    !

    *-*-sysv*

    On System V release 3, you may get this error message while linking: --- 1791,1797 ----


    !

    *-*-sysv*

    On System V release 3, you may get this error message while linking: *************** is said to work. Smaller values may als *** 1775,1781 ****


    !

    vax-dec-ultrix

    Don't try compiling with VAX C (vcc). It produces incorrect code in some cases (for example, when alloca is used). --- 1823,1829 ----


    !

    vax-dec-ultrix

    Don't try compiling with VAX C (vcc). It produces incorrect code in some cases (for example, when alloca is used). *************** in some cases (for example, when a *** 1783,1789 ****


    !

    we32k-*-*

    These computers are also known as the 3b2, 3b5, 3b20 and other similar names. (However, the 3b1 is actually a 68000.) --- 1831,1837 ----


    !

    we32k-*-*

    These computers are also known as the 3b2, 3b5, 3b20 and other similar names. (However, the 3b1 is actually a 68000.) *************** as the file cc1plus is larg *** 1819,1825 ****


    !

    Microsoft Windows (32 bit)

    A port of GCC 2.95.x is included with the Cygwin environment. --- 1867,1873 ----


    !

    Microsoft Windows (32 bit)

    A port of GCC 2.95.x is included with the Cygwin environment. *************** without modification. *** 1830,1839 ****


    !

    OS/2

    GCC does not currently support OS/2. However, Andrew Zabolotny has been ! working on a generic OS/2 port with pgcc. The current code code can be found at http://www.goof.com/pcg/os2/.

    An older copy of GCC 2.8.1 is included with the EMX tools available at --- 1878,1887 ----


    !

    OS/2

    GCC does not currently support OS/2. However, Andrew Zabolotny has been ! working on a generic OS/2 port with pgcc. The current code can be found at http://www.goof.com/pcg/os2/.

    An older copy of GCC 2.8.1 is included with the EMX tools available at *************** at Older systems

    GCC contains support files for many older (1980s and early 1990s) Unix variants. For the most part, support for these systems --- 1890,1896 ----


    !

    Older systems

    GCC contains support files for many older (1980s and early 1990s) Unix variants. For the most part, support for these systems *************** current GCC) is to be found in the GCC t *** 1885,1891 ****


    !

    all ELF targets (SVR4, Solaris, etc.)

    C++ support is significantly better on ELF targets if you use the GNU linker; duplicate copies of --- 1933,1939 ----


    !

    all ELF targets (SVR4, Solaris 2, etc.)

    C++ support is significantly better on ELF targets if you use the GNU linker; duplicate copies of diff -Nrc3pad gcc-3.0.1/MAINTAINERS gcc-3.0.2/MAINTAINERS *** gcc-3.0.1/MAINTAINERS Fri Aug 10 15:06:30 2001 --- gcc-3.0.2/MAINTAINERS Wed Oct 3 17:46:36 2001 *************** m68k port (?) Jeff Law law@redhat.com *** 37,43 **** m68k-motorola-sysv port Philippe De Muyter phdm@macqel.be rs6000 port Geoff Keating geoffk@redhat.com rs6000 port David Edelsohn dje@watson.ibm.com ! mips port Gavin Romig-Koch gavin@redhat.com ia64 port Jim Wilson wilson@redhat.com i860 port Jason Eckhardt jle@redhat.com i960 port Jim Wilson wilson@redhat.com --- 37,43 ---- m68k-motorola-sysv port Philippe De Muyter phdm@macqel.be rs6000 port Geoff Keating geoffk@redhat.com rs6000 port David Edelsohn dje@watson.ibm.com ! mips port Eric Christopher echristo@redhat.com ia64 port Jim Wilson wilson@redhat.com i860 port Jason Eckhardt jle@redhat.com i960 port Jim Wilson wilson@redhat.com *************** John Wehle john@feith.com *** 177,180 **** Mark Wielaard mark@gcc.gnu.org * Indicates folks we need to get Kerberos/ssh accounts ready so they can write in the source tree - --- 177,179 ---- diff -Nrc3pad gcc-3.0.1/boehm-gc/ChangeLog gcc-3.0.2/boehm-gc/ChangeLog *** gcc-3.0.1/boehm-gc/ChangeLog Sun Aug 19 14:08:01 2001 --- gcc-3.0.2/boehm-gc/ChangeLog Tue Oct 23 10:18:51 2001 *************** *** 1,3 **** --- 1,28 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + + 2001-09-26 Rainer Orth + + * mach_dep.c (GC_push_regs) [I386 && (SVR4 || SCO || SCO_ELF) + && __GNUC__ ]: Call GC_push_one in C to allow for PIC code. + Fixes PR bootstrap/4162. + + 2001-09-26 Rainer Orth + + * solaris_threads.c (MAX_ORIG_STACK_SIZE) [I386]: Provide special + Solaris 2/Intel definition. + (GC_get_orig_stack_size): NL-terminate warning message. + + * configure.in (i?86-*-solaris2.[89]*): Define + SOLARIS25_PROC_VDB_BUG_FIXED. + * gcconfig.h [I386 && SUNOS5]: Use it. + * configure: Regenerate. + + * gcconfig.h [I386 && SUNOS5] (DATASTART): Use _etext. + (DATAEND): Define using _end. + (STACKBOTTOM): Define. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/boehm-gc/configure gcc-3.0.2/boehm-gc/configure *** gcc-3.0.1/boehm-gc/configure Tue Jul 3 15:29:46 2001 --- gcc-3.0.2/boehm-gc/configure Tue Oct 23 10:56:01 2001 *************** program_suffix=NONE *** 57,63 **** program_transform_name=s,x,x, silent= site= - sitefile= srcdir= target=NONE verbose= --- 57,62 ---- *************** Configuration: *** 172,178 **** --help print this message --no-create do not create output files --quiet, --silent do not print \`checking...' messages - --site-file=FILE use FILE as the site file --version print the version of autoconf that created configure Directory and file names: --prefix=PREFIX install architecture-independent files in PREFIX --- 171,176 ---- *************** EOF *** 343,353 **** -site=* | --site=* | --sit=*) site="$ac_optarg" ;; - -site-file | --site-file | --site-fil | --site-fi | --site-f) - ac_prev=sitefile ;; - -site-file=* | --site-file=* | --site-fil=* | --site-fi=* | --site-f=*) - sitefile="$ac_optarg" ;; - -srcdir | --srcdir | --srcdi | --srcd | --src | --sr) ac_prev=srcdir ;; -srcdir=* | --srcdir=* | --srcdi=* | --srcd=* | --src=* | --sr=*) --- 341,346 ---- *************** fi *** 513,528 **** srcdir=`echo "${srcdir}" | sed 's%\([^/]\)/*$%\1%'` # Prefer explicitly selected file to automatically selected ones. ! if test -z "$sitefile"; then ! if test -z "$CONFIG_SITE"; then ! if test "x$prefix" != xNONE; then ! CONFIG_SITE="$prefix/share/config.site $prefix/etc/config.site" ! else ! CONFIG_SITE="$ac_default_prefix/share/config.site $ac_default_prefix/etc/config.site" ! fi fi - else - CONFIG_SITE="$sitefile" fi for ac_site_file in $CONFIG_SITE; do if test -r "$ac_site_file"; then --- 506,517 ---- srcdir=`echo "${srcdir}" | sed 's%\([^/]\)/*$%\1%'` # Prefer explicitly selected file to automatically selected ones. ! if test -z "$CONFIG_SITE"; then ! if test "x$prefix" != xNONE; then ! CONFIG_SITE="$prefix/share/config.site $prefix/etc/config.site" ! else ! CONFIG_SITE="$ac_default_prefix/share/config.site $ac_default_prefix/etc/config.site" fi fi for ac_site_file in $CONFIG_SITE; do if test -r "$ac_site_file"; then *************** fi *** 574,580 **** # SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff" # ./install, which can be erroneously created by make from ./install.sh. echo $ac_n "checking for a BSD compatible install""... $ac_c" 1>&6 ! echo "configure:578: checking for a BSD compatible install" >&5 if test -z "$INSTALL"; then if eval "test \"`echo '$''{'ac_cv_path_install'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 --- 563,569 ---- # SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff" # ./install, which can be erroneously created by make from ./install.sh. echo $ac_n "checking for a BSD compatible install""... $ac_c" 1>&6 ! echo "configure:567: checking for a BSD compatible install" >&5 if test -z "$INSTALL"; then if eval "test \"`echo '$''{'ac_cv_path_install'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 *************** test -z "$INSTALL_SCRIPT" && INSTALL_SCR *** 627,633 **** test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644' echo $ac_n "checking whether build environment is sane""... $ac_c" 1>&6 ! echo "configure:631: checking whether build environment is sane" >&5 # Just in case sleep 1 echo timestamp > conftestfile --- 616,622 ---- test -z "$INSTALL_DATA" && INSTALL_DATA='${INSTALL} -m 644' echo $ac_n "checking whether build environment is sane""... $ac_c" 1>&6 ! echo "configure:620: checking whether build environment is sane" >&5 # Just in case sleep 1 echo timestamp > conftestfile *************** test "$program_suffix" != NONE && *** 684,690 **** test "$program_transform_name" = "" && program_transform_name="s,x,x," echo $ac_n "checking whether ${MAKE-make} sets \${MAKE}""... $ac_c" 1>&6 ! echo "configure:688: checking whether ${MAKE-make} sets \${MAKE}" >&5 set dummy ${MAKE-make}; ac_make=`echo "$2" | sed 'y%./+-%__p_%'` if eval "test \"`echo '$''{'ac_cv_prog_make_${ac_make}_set'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 --- 673,679 ---- test "$program_transform_name" = "" && program_transform_name="s,x,x," echo $ac_n "checking whether ${MAKE-make} sets \${MAKE}""... $ac_c" 1>&6 ! echo "configure:677: checking whether ${MAKE-make} sets \${MAKE}" >&5 set dummy ${MAKE-make}; ac_make=`echo "$2" | sed 'y%./+-%__p_%'` if eval "test \"`echo '$''{'ac_cv_prog_make_${ac_make}_set'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 *************** else *** 717,728 **** fi echo $ac_n "checking for Cygwin environment""... $ac_c" 1>&6 ! echo "configure:721: checking for Cygwin environment" >&5 if eval "test \"`echo '$''{'ac_cv_cygwin'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&6 ! echo "configure:710: checking for Cygwin environment" >&5 if eval "test \"`echo '$''{'ac_cv_cygwin'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* ac_cv_cygwin=yes else --- 722,728 ---- return __CYGWIN__; ; return 0; } EOF ! if { (eval echo configure:726: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* ac_cv_cygwin=yes else *************** echo "$ac_t""$ac_cv_cygwin" 1>&6 *** 750,768 **** CYGWIN= test "$ac_cv_cygwin" = yes && CYGWIN=yes echo $ac_n "checking for mingw32 environment""... $ac_c" 1>&6 ! echo "configure:754: checking for mingw32 environment" >&5 if eval "test \"`echo '$''{'ac_cv_mingw32'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* ac_cv_mingw32=yes else --- 739,757 ---- CYGWIN= test "$ac_cv_cygwin" = yes && CYGWIN=yes echo $ac_n "checking for mingw32 environment""... $ac_c" 1>&6 ! echo "configure:743: checking for mingw32 environment" >&5 if eval "test \"`echo '$''{'ac_cv_mingw32'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_compile) 2>&5; }; then rm -rf conftest* ac_cv_mingw32=yes else *************** else { echo "configure: error: can not r *** 873,879 **** fi echo $ac_n "checking host system type""... $ac_c" 1>&6 ! echo "configure:877: checking host system type" >&5 host_alias=$host case "$host_alias" in --- 862,868 ---- fi echo $ac_n "checking host system type""... $ac_c" 1>&6 ! echo "configure:866: checking host system type" >&5 host_alias=$host case "$host_alias" in *************** host_os=`echo $host | sed 's/^\([^-]*\)- *** 894,900 **** echo "$ac_t""$host" 1>&6 echo $ac_n "checking target system type""... $ac_c" 1>&6 ! echo "configure:898: checking target system type" >&5 target_alias=$target case "$target_alias" in --- 883,889 ---- echo "$ac_t""$host" 1>&6 echo $ac_n "checking target system type""... $ac_c" 1>&6 ! echo "configure:887: checking target system type" >&5 target_alias=$target case "$target_alias" in *************** target_os=`echo $target | sed 's/^\([^-] *** 912,918 **** echo "$ac_t""$target" 1>&6 echo $ac_n "checking build system type""... $ac_c" 1>&6 ! echo "configure:916: checking build system type" >&5 build_alias=$build case "$build_alias" in --- 901,907 ---- echo "$ac_t""$target" 1>&6 echo $ac_n "checking build system type""... $ac_c" 1>&6 ! echo "configure:905: checking build system type" >&5 build_alias=$build case "$build_alias" in *************** fi *** 952,958 **** missing_dir=`cd $ac_aux_dir && pwd` echo $ac_n "checking for working aclocal""... $ac_c" 1>&6 ! echo "configure:956: checking for working aclocal" >&5 # Run test in a subshell; some versions of sh will print an error if # an executable is not found, even if stderr is redirected. # Redirect stdin to placate older versions of autoconf. Sigh. --- 941,947 ---- missing_dir=`cd $ac_aux_dir && pwd` echo $ac_n "checking for working aclocal""... $ac_c" 1>&6 ! echo "configure:945: checking for working aclocal" >&5 # Run test in a subshell; some versions of sh will print an error if # an executable is not found, even if stderr is redirected. # Redirect stdin to placate older versions of autoconf. Sigh. *************** else *** 965,971 **** fi echo $ac_n "checking for working autoconf""... $ac_c" 1>&6 ! echo "configure:969: checking for working autoconf" >&5 # Run test in a subshell; some versions of sh will print an error if # an executable is not found, even if stderr is redirected. # Redirect stdin to placate older versions of autoconf. Sigh. --- 954,960 ---- fi echo $ac_n "checking for working autoconf""... $ac_c" 1>&6 ! echo "configure:958: checking for working autoconf" >&5 # Run test in a subshell; some versions of sh will print an error if # an executable is not found, even if stderr is redirected. # Redirect stdin to placate older versions of autoconf. Sigh. *************** else *** 978,984 **** fi echo $ac_n "checking for working automake""... $ac_c" 1>&6 ! echo "configure:982: checking for working automake" >&5 # Run test in a subshell; some versions of sh will print an error if # an executable is not found, even if stderr is redirected. # Redirect stdin to placate older versions of autoconf. Sigh. --- 967,973 ---- fi echo $ac_n "checking for working automake""... $ac_c" 1>&6 ! echo "configure:971: checking for working automake" >&5 # Run test in a subshell; some versions of sh will print an error if # an executable is not found, even if stderr is redirected. # Redirect stdin to placate older versions of autoconf. Sigh. *************** else *** 991,997 **** fi echo $ac_n "checking for working autoheader""... $ac_c" 1>&6 ! echo "configure:995: checking for working autoheader" >&5 # Run test in a subshell; some versions of sh will print an error if # an executable is not found, even if stderr is redirected. # Redirect stdin to placate older versions of autoconf. Sigh. --- 980,986 ---- fi echo $ac_n "checking for working autoheader""... $ac_c" 1>&6 ! echo "configure:984: checking for working autoheader" >&5 # Run test in a subshell; some versions of sh will print an error if # an executable is not found, even if stderr is redirected. # Redirect stdin to placate older versions of autoconf. Sigh. *************** else *** 1004,1010 **** fi echo $ac_n "checking for working makeinfo""... $ac_c" 1>&6 ! echo "configure:1008: checking for working makeinfo" >&5 # Run test in a subshell; some versions of sh will print an error if # an executable is not found, even if stderr is redirected. # Redirect stdin to placate older versions of autoconf. Sigh. --- 993,999 ---- fi echo $ac_n "checking for working makeinfo""... $ac_c" 1>&6 ! echo "configure:997: checking for working makeinfo" >&5 # Run test in a subshell; some versions of sh will print an error if # an executable is not found, even if stderr is redirected. # Redirect stdin to placate older versions of autoconf. Sigh. *************** fi *** 1030,1036 **** # Extract the first word of "gcc", so it can be a program name with args. set dummy gcc; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1034: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1019,1025 ---- # Extract the first word of "gcc", so it can be a program name with args. set dummy gcc; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1023: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** if test -z "$CC"; then *** 1060,1066 **** # Extract the first word of "cc", so it can be a program name with args. set dummy cc; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1064: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1049,1055 ---- # Extract the first word of "cc", so it can be a program name with args. set dummy cc; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1053: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_CC'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** fi *** 1109,1115 **** fi echo $ac_n "checking whether we are using GNU C""... $ac_c" 1>&6 ! echo "configure:1113: checking whether we are using GNU C" >&5 if eval "test \"`echo '$''{'ac_cv_prog_gcc'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1098,1104 ---- fi echo $ac_n "checking whether we are using GNU C""... $ac_c" 1>&6 ! echo "configure:1102: checking whether we are using GNU C" >&5 if eval "test \"`echo '$''{'ac_cv_prog_gcc'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** else *** 1118,1124 **** yes; #endif EOF ! if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:1122: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then ac_cv_prog_gcc=yes else ac_cv_prog_gcc=no --- 1107,1113 ---- yes; #endif EOF ! if { ac_try='${CC-cc} -E conftest.c'; { (eval echo configure:1111: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then ac_cv_prog_gcc=yes else ac_cv_prog_gcc=no *************** if test $ac_cv_prog_gcc = yes; then *** 1133,1139 **** ac_save_CFLAGS="$CFLAGS" CFLAGS= echo $ac_n "checking whether ${CC-cc} accepts -g""... $ac_c" 1>&6 ! echo "configure:1137: checking whether ${CC-cc} accepts -g" >&5 if eval "test \"`echo '$''{'ac_cv_prog_cc_g'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1122,1128 ---- ac_save_CFLAGS="$CFLAGS" CFLAGS= echo $ac_n "checking whether ${CC-cc} accepts -g""... $ac_c" 1>&6 ! echo "configure:1126: checking whether ${CC-cc} accepts -g" >&5 if eval "test \"`echo '$''{'ac_cv_prog_cc_g'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** do *** 1170,1176 **** # Extract the first word of "$ac_prog", so it can be a program name with args. set dummy $ac_prog; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1174: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_CXX'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1159,1165 ---- # Extract the first word of "$ac_prog", so it can be a program name with args. set dummy $ac_prog; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1163: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_CXX'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** test -n "$CXX" || CXX="gcc" *** 1203,1209 **** test -z "$CXX" && { echo "configure: error: no acceptable c++ found in \$PATH" 1>&2; exit 1; } echo $ac_n "checking whether we are using GNU C++""... $ac_c" 1>&6 ! echo "configure:1207: checking whether we are using GNU C++" >&5 if eval "test \"`echo '$''{'ac_cv_prog_gxx'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1192,1198 ---- test -z "$CXX" && { echo "configure: error: no acceptable c++ found in \$PATH" 1>&2; exit 1; } echo $ac_n "checking whether we are using GNU C++""... $ac_c" 1>&6 ! echo "configure:1196: checking whether we are using GNU C++" >&5 if eval "test \"`echo '$''{'ac_cv_prog_gxx'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** else *** 1212,1218 **** yes; #endif EOF ! if { ac_try='${CXX-g++} -E conftest.C'; { (eval echo configure:1216: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then ac_cv_prog_gxx=yes else ac_cv_prog_gxx=no --- 1201,1207 ---- yes; #endif EOF ! if { ac_try='${CXX-g++} -E conftest.C'; { (eval echo configure:1205: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }; } | egrep yes >/dev/null 2>&1; then ac_cv_prog_gxx=yes else ac_cv_prog_gxx=no *************** if test $ac_cv_prog_gxx = yes; then *** 1227,1233 **** ac_save_CXXFLAGS="$CXXFLAGS" CXXFLAGS= echo $ac_n "checking whether ${CXX-g++} accepts -g""... $ac_c" 1>&6 ! echo "configure:1231: checking whether ${CXX-g++} accepts -g" >&5 if eval "test \"`echo '$''{'ac_cv_prog_cxx_g'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1216,1222 ---- ac_save_CXXFLAGS="$CXXFLAGS" CXXFLAGS= echo $ac_n "checking whether ${CXX-g++} accepts -g""... $ac_c" 1>&6 ! echo "configure:1220: checking whether ${CXX-g++} accepts -g" >&5 if eval "test \"`echo '$''{'ac_cv_prog_cxx_g'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** fi *** 1260,1266 **** # NEWLIB_CONFIGURE, which doesn't work because that means that it will # be run before AC_CANONICAL_HOST. echo $ac_n "checking build system type""... $ac_c" 1>&6 ! echo "configure:1264: checking build system type" >&5 build_alias=$build case "$build_alias" in --- 1249,1255 ---- # NEWLIB_CONFIGURE, which doesn't work because that means that it will # be run before AC_CANONICAL_HOST. echo $ac_n "checking build system type""... $ac_c" 1>&6 ! echo "configure:1253: checking build system type" >&5 build_alias=$build case "$build_alias" in *************** echo "$ac_t""$build" 1>&6 *** 1281,1287 **** # Extract the first word of "${ac_tool_prefix}as", so it can be a program name with args. set dummy ${ac_tool_prefix}as; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1285: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_AS'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1270,1276 ---- # Extract the first word of "${ac_tool_prefix}as", so it can be a program name with args. set dummy ${ac_tool_prefix}as; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1274: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_AS'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** fi *** 1313,1319 **** # Extract the first word of "${ac_tool_prefix}ar", so it can be a program name with args. set dummy ${ac_tool_prefix}ar; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1317: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_AR'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1302,1308 ---- # Extract the first word of "${ac_tool_prefix}ar", so it can be a program name with args. set dummy ${ac_tool_prefix}ar; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1306: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_AR'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** fi *** 1345,1351 **** # Extract the first word of "${ac_tool_prefix}ranlib", so it can be a program name with args. set dummy ${ac_tool_prefix}ranlib; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1349: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1334,1340 ---- # Extract the first word of "${ac_tool_prefix}ranlib", so it can be a program name with args. set dummy ${ac_tool_prefix}ranlib; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1338: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** if test -n "$ac_tool_prefix"; then *** 1377,1383 **** # Extract the first word of "ranlib", so it can be a program name with args. set dummy ranlib; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1381: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1366,1372 ---- # Extract the first word of "ranlib", so it can be a program name with args. set dummy ranlib; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:1370: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** fi *** 1422,1428 **** # SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff" # ./install, which can be erroneously created by make from ./install.sh. echo $ac_n "checking for a BSD compatible install""... $ac_c" 1>&6 ! echo "configure:1426: checking for a BSD compatible install" >&5 if test -z "$INSTALL"; then if eval "test \"`echo '$''{'ac_cv_path_install'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 --- 1411,1417 ---- # SVR4 /usr/ucb/install, which tries to use the nonexistent group "staff" # ./install, which can be erroneously created by make from ./install.sh. echo $ac_n "checking for a BSD compatible install""... $ac_c" 1>&6 ! echo "configure:1415: checking for a BSD compatible install" >&5 if test -z "$INSTALL"; then if eval "test \"`echo '$''{'ac_cv_path_install'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 *************** test -z "$INSTALL_DATA" && INSTALL_DATA= *** 1476,1482 **** echo $ac_n "checking whether to enable maintainer-specific portions of Makefiles""... $ac_c" 1>&6 ! echo "configure:1480: checking whether to enable maintainer-specific portions of Makefiles" >&5 # Check whether --enable-maintainer-mode or --disable-maintainer-mode was given. if test "${enable_maintainer_mode+set}" = set; then enableval="$enable_maintainer_mode" --- 1465,1471 ---- echo $ac_n "checking whether to enable maintainer-specific portions of Makefiles""... $ac_c" 1>&6 ! echo "configure:1469: checking whether to enable maintainer-specific portions of Makefiles" >&5 # Check whether --enable-maintainer-mode or --disable-maintainer-mode was given. if test "${enable_maintainer_mode+set}" = set; then enableval="$enable_maintainer_mode" *************** if false; then *** 1510,1516 **** echo $ac_n "checking for executable suffix""... $ac_c" 1>&6 ! echo "configure:1514: checking for executable suffix" >&5 if eval "test \"`echo '$''{'ac_cv_exeext'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1499,1505 ---- echo $ac_n "checking for executable suffix""... $ac_c" 1>&6 ! echo "configure:1503: checking for executable suffix" >&5 if eval "test \"`echo '$''{'ac_cv_exeext'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** else *** 1520,1529 **** rm -f conftest* echo 'int main () { return 0; }' > conftest.$ac_ext ac_cv_exeext= ! if { (eval echo configure:1524: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then for file in conftest.*; do case $file in ! *.c | *.o | *.obj | *.ilk | *.pdb) ;; *) ac_cv_exeext=`echo $file | sed -e s/conftest//` ;; esac done --- 1509,1518 ---- rm -f conftest* echo 'int main () { return 0; }' > conftest.$ac_ext ac_cv_exeext= ! if { (eval echo configure:1513: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then for file in conftest.*; do case $file in ! *.c | *.o | *.obj) ;; *) ac_cv_exeext=`echo $file | sed -e s/conftest//` ;; esac done *************** ac_prog=ld *** 1643,1649 **** if test "$GCC" = yes; then # Check if gcc -print-prog-name=ld gives a path. echo $ac_n "checking for ld used by GCC""... $ac_c" 1>&6 ! echo "configure:1647: checking for ld used by GCC" >&5 case $host in *-*-mingw*) # gcc leaves a trailing carriage return which upsets mingw --- 1632,1638 ---- if test "$GCC" = yes; then # Check if gcc -print-prog-name=ld gives a path. echo $ac_n "checking for ld used by GCC""... $ac_c" 1>&6 ! echo "configure:1636: checking for ld used by GCC" >&5 case $host in *-*-mingw*) # gcc leaves a trailing carriage return which upsets mingw *************** echo "configure:1647: checking for ld us *** 1673,1682 **** esac elif test "$with_gnu_ld" = yes; then echo $ac_n "checking for GNU ld""... $ac_c" 1>&6 ! echo "configure:1677: checking for GNU ld" >&5 else echo $ac_n "checking for non-GNU ld""... $ac_c" 1>&6 ! echo "configure:1680: checking for non-GNU ld" >&5 fi if eval "test \"`echo '$''{'lt_cv_path_LD'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 --- 1662,1671 ---- esac elif test "$with_gnu_ld" = yes; then echo $ac_n "checking for GNU ld""... $ac_c" 1>&6 ! echo "configure:1666: checking for GNU ld" >&5 else echo $ac_n "checking for non-GNU ld""... $ac_c" 1>&6 ! echo "configure:1669: checking for non-GNU ld" >&5 fi if eval "test \"`echo '$''{'lt_cv_path_LD'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 *************** else *** 1711,1717 **** fi test -z "$LD" && { echo "configure: error: no acceptable ld found in \$PATH" 1>&2; exit 1; } echo $ac_n "checking if the linker ($LD) is GNU ld""... $ac_c" 1>&6 ! echo "configure:1715: checking if the linker ($LD) is GNU ld" >&5 if eval "test \"`echo '$''{'lt_cv_prog_gnu_ld'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1700,1706 ---- fi test -z "$LD" && { echo "configure: error: no acceptable ld found in \$PATH" 1>&2; exit 1; } echo $ac_n "checking if the linker ($LD) is GNU ld""... $ac_c" 1>&6 ! echo "configure:1704: checking if the linker ($LD) is GNU ld" >&5 if eval "test \"`echo '$''{'lt_cv_prog_gnu_ld'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** with_gnu_ld=$lt_cv_prog_gnu_ld *** 1728,1734 **** echo $ac_n "checking for $LD option to reload object files""... $ac_c" 1>&6 ! echo "configure:1732: checking for $LD option to reload object files" >&5 if eval "test \"`echo '$''{'lt_cv_ld_reload_flag'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1717,1723 ---- echo $ac_n "checking for $LD option to reload object files""... $ac_c" 1>&6 ! echo "configure:1721: checking for $LD option to reload object files" >&5 if eval "test \"`echo '$''{'lt_cv_ld_reload_flag'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** reload_flag=$lt_cv_ld_reload_flag *** 1740,1746 **** test -n "$reload_flag" && reload_flag=" $reload_flag" echo $ac_n "checking for BSD-compatible nm""... $ac_c" 1>&6 ! echo "configure:1744: checking for BSD-compatible nm" >&5 if eval "test \"`echo '$''{'lt_cv_path_NM'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1729,1735 ---- test -n "$reload_flag" && reload_flag=" $reload_flag" echo $ac_n "checking for BSD-compatible nm""... $ac_c" 1>&6 ! echo "configure:1733: checking for BSD-compatible nm" >&5 if eval "test \"`echo '$''{'lt_cv_path_NM'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** NM="$lt_cv_path_NM" *** 1778,1784 **** echo "$ac_t""$NM" 1>&6 echo $ac_n "checking whether ln -s works""... $ac_c" 1>&6 ! echo "configure:1782: checking whether ln -s works" >&5 if eval "test \"`echo '$''{'ac_cv_prog_LN_S'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1767,1773 ---- echo "$ac_t""$NM" 1>&6 echo $ac_n "checking whether ln -s works""... $ac_c" 1>&6 ! echo "configure:1771: checking whether ln -s works" >&5 if eval "test \"`echo '$''{'ac_cv_prog_LN_S'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** else *** 1799,1805 **** fi echo $ac_n "checking how to recognise dependant libraries""... $ac_c" 1>&6 ! echo "configure:1803: checking how to recognise dependant libraries" >&5 if eval "test \"`echo '$''{'lt_cv_deplibs_check_method'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1788,1794 ---- fi echo $ac_n "checking how to recognise dependant libraries""... $ac_c" 1>&6 ! echo "configure:1792: checking how to recognise dependant libraries" >&5 if eval "test \"`echo '$''{'lt_cv_deplibs_check_method'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** file_magic_cmd=$lt_cv_file_magic_cmd *** 1963,1975 **** deplibs_check_method=$lt_cv_deplibs_check_method echo $ac_n "checking for object suffix""... $ac_c" 1>&6 ! echo "configure:1967: checking for object suffix" >&5 if eval "test \"`echo '$''{'ac_cv_objext'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else rm -f conftest* echo 'int i = 1;' > conftest.$ac_ext ! if { (eval echo configure:1973: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then for ac_file in conftest.*; do case $ac_file in *.c) ;; --- 1952,1964 ---- deplibs_check_method=$lt_cv_deplibs_check_method echo $ac_n "checking for object suffix""... $ac_c" 1>&6 ! echo "configure:1956: checking for object suffix" >&5 if eval "test \"`echo '$''{'ac_cv_objext'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else rm -f conftest* echo 'int i = 1;' > conftest.$ac_ext ! if { (eval echo configure:1962: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then for ac_file in conftest.*; do case $ac_file in *.c) ;; *************** case $deplibs_check_method in *** 1993,1999 **** file_magic*) if test "$file_magic_cmd" = '$MAGIC_CMD'; then echo $ac_n "checking for ${ac_tool_prefix}file""... $ac_c" 1>&6 ! echo "configure:1997: checking for ${ac_tool_prefix}file" >&5 if eval "test \"`echo '$''{'lt_cv_path_MAGIC_CMD'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 1982,1988 ---- file_magic*) if test "$file_magic_cmd" = '$MAGIC_CMD'; then echo $ac_n "checking for ${ac_tool_prefix}file""... $ac_c" 1>&6 ! echo "configure:1986: checking for ${ac_tool_prefix}file" >&5 if eval "test \"`echo '$''{'lt_cv_path_MAGIC_CMD'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** fi *** 2055,2061 **** if test -z "$lt_cv_path_MAGIC_CMD"; then if test -n "$ac_tool_prefix"; then echo $ac_n "checking for file""... $ac_c" 1>&6 ! echo "configure:2059: checking for file" >&5 if eval "test \"`echo '$''{'lt_cv_path_MAGIC_CMD'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 2044,2050 ---- if test -z "$lt_cv_path_MAGIC_CMD"; then if test -n "$ac_tool_prefix"; then echo $ac_n "checking for file""... $ac_c" 1>&6 ! echo "configure:2048: checking for file" >&5 if eval "test \"`echo '$''{'lt_cv_path_MAGIC_CMD'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** esac *** 2126,2132 **** # Extract the first word of "${ac_tool_prefix}ranlib", so it can be a program name with args. set dummy ${ac_tool_prefix}ranlib; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:2130: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 2115,2121 ---- # Extract the first word of "${ac_tool_prefix}ranlib", so it can be a program name with args. set dummy ${ac_tool_prefix}ranlib; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:2119: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** if test -n "$ac_tool_prefix"; then *** 2158,2164 **** # Extract the first word of "ranlib", so it can be a program name with args. set dummy ranlib; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:2162: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 2147,2153 ---- # Extract the first word of "ranlib", so it can be a program name with args. set dummy ranlib; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:2151: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_RANLIB'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** fi *** 2193,2199 **** # Extract the first word of "${ac_tool_prefix}strip", so it can be a program name with args. set dummy ${ac_tool_prefix}strip; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:2197: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_STRIP'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 2182,2188 ---- # Extract the first word of "${ac_tool_prefix}strip", so it can be a program name with args. set dummy ${ac_tool_prefix}strip; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:2186: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_STRIP'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** if test -n "$ac_tool_prefix"; then *** 2225,2231 **** # Extract the first word of "strip", so it can be a program name with args. set dummy strip; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:2229: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_STRIP'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 2214,2220 ---- # Extract the first word of "strip", so it can be a program name with args. set dummy strip; ac_word=$2 echo $ac_n "checking for $ac_word""... $ac_c" 1>&6 ! echo "configure:2218: checking for $ac_word" >&5 if eval "test \"`echo '$''{'ac_cv_prog_STRIP'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** test x"$pic_mode" = xno && libtool_flags *** 2292,2299 **** case $host in *-*-irix6*) # Find out which ABI we are using. ! echo '#line 2296 "configure"' > conftest.$ac_ext ! if { (eval echo configure:2297: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then case `/usr/bin/file conftest.$ac_objext` in *32-bit*) LD="${LD-ld} -32" --- 2281,2288 ---- case $host in *-*-irix6*) # Find out which ABI we are using. ! echo '#line 2285 "configure"' > conftest.$ac_ext ! if { (eval echo configure:2286: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then case `/usr/bin/file conftest.$ac_objext` in *32-bit*) LD="${LD-ld} -32" *************** case $host in *** 2314,2320 **** SAVE_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS -belf" echo $ac_n "checking whether the C compiler needs -belf""... $ac_c" 1>&6 ! echo "configure:2318: checking whether the C compiler needs -belf" >&5 if eval "test \"`echo '$''{'lt_cv_cc_needs_belf'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 2303,2309 ---- SAVE_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS -belf" echo $ac_n "checking whether the C compiler needs -belf""... $ac_c" 1>&6 ! echo "configure:2307: checking whether the C compiler needs -belf" >&5 if eval "test \"`echo '$''{'lt_cv_cc_needs_belf'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** ac_link='${CC-cc} -o conftest${ac_exeext *** 2327,2340 **** cross_compiling=$ac_cv_prog_cc_cross cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* lt_cv_cc_needs_belf=yes else --- 2316,2329 ---- cross_compiling=$ac_cv_prog_cc_cross cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* lt_cv_cc_needs_belf=yes else *************** echo "$ac_t""$lt_cv_cc_needs_belf" 1>&6 *** 2364,2370 **** esac echo $ac_n "checking how to run the C++ preprocessor""... $ac_c" 1>&6 ! echo "configure:2368: checking how to run the C++ preprocessor" >&5 if test -z "$CXXCPP"; then if eval "test \"`echo '$''{'ac_cv_prog_CXXCPP'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 --- 2353,2359 ---- esac echo $ac_n "checking how to run the C++ preprocessor""... $ac_c" 1>&6 ! echo "configure:2357: checking how to run the C++ preprocessor" >&5 if test -z "$CXXCPP"; then if eval "test \"`echo '$''{'ac_cv_prog_CXXCPP'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 *************** ac_link='${CXX-g++} -o conftest${ac_exee *** 2377,2388 **** cross_compiling=$ac_cv_prog_cxx_cross CXXCPP="${CXX-g++} -E" cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:2386: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : --- 2366,2377 ---- cross_compiling=$ac_cv_prog_cxx_cross CXXCPP="${CXX-g++} -E" cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:2375: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then : *************** fi *** 2529,2535 **** echo $ac_n "checking whether to enable maintainer-specific portions of Makefiles""... $ac_c" 1>&6 ! echo "configure:2533: checking whether to enable maintainer-specific portions of Makefiles" >&5 # Check whether --enable-maintainer-mode or --disable-maintainer-mode was given. if test "${enable_maintainer_mode+set}" = set; then enableval="$enable_maintainer_mode" --- 2518,2524 ---- echo $ac_n "checking whether to enable maintainer-specific portions of Makefiles""... $ac_c" 1>&6 ! echo "configure:2522: checking whether to enable maintainer-specific portions of Makefiles" >&5 # Check whether --enable-maintainer-mode or --disable-maintainer-mode was given. if test "${enable_maintainer_mode+set}" = set; then enableval="$enable_maintainer_mode" *************** if test "x" = "y"; then *** 2558,2564 **** echo $ac_n "checking for executable suffix""... $ac_c" 1>&6 ! echo "configure:2562: checking for executable suffix" >&5 if eval "test \"`echo '$''{'ac_cv_exeext'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 2547,2553 ---- echo $ac_n "checking for executable suffix""... $ac_c" 1>&6 ! echo "configure:2551: checking for executable suffix" >&5 if eval "test \"`echo '$''{'ac_cv_exeext'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** else *** 2568,2577 **** rm -f conftest* echo 'int main () { return 0; }' > conftest.$ac_ext ac_cv_exeext= ! if { (eval echo configure:2572: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then for file in conftest.*; do case $file in ! *.c | *.o | *.obj | *.ilk | *.pdb) ;; *) ac_cv_exeext=`echo $file | sed -e s/conftest//` ;; esac done --- 2557,2566 ---- rm -f conftest* echo 'int main () { return 0; }' > conftest.$ac_ext ac_cv_exeext= ! if { (eval echo configure:2561: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; }; then for file in conftest.*; do case $file in ! *.c | *.o | *.obj) ;; *) ac_cv_exeext=`echo $file | sed -e s/conftest//` ;; esac done *************** ac_exeext=$EXEEXT *** 2591,2597 **** fi echo $ac_n "checking for thread model used by GCC""... $ac_c" 1>&6 ! echo "configure:2595: checking for thread model used by GCC" >&5 THREADS=`$CC -v 2>&1 | sed -n 's/^Thread model: //p'` echo "$ac_t""$THREADS" 1>&6 --- 2580,2586 ---- fi echo $ac_n "checking for thread model used by GCC""... $ac_c" 1>&6 ! echo "configure:2584: checking for thread model used by GCC" >&5 THREADS=`$CC -v 2>&1 | sed -n 's/^Thread model: //p'` echo "$ac_t""$THREADS" 1>&6 *************** esac *** 2643,2649 **** echo $ac_n "checking for dlopen in -ldl""... $ac_c" 1>&6 ! echo "configure:2647: checking for dlopen in -ldl" >&5 ac_lib_var=`echo dl'_'dlopen | sed 'y%./+-%__p_%'` if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 --- 2632,2638 ---- echo $ac_n "checking for dlopen in -ldl""... $ac_c" 1>&6 ! echo "configure:2636: checking for dlopen in -ldl" >&5 ac_lib_var=`echo dl'_'dlopen | sed 'y%./+-%__p_%'` if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 *************** else *** 2651,2657 **** ac_save_LIBS="$LIBS" LIBS="-ldl $LIBS" cat > conftest.$ac_ext < conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_lib_$ac_lib_var=yes" else --- 2651,2657 ---- dlopen() ; return 0; } EOF ! if { (eval echo configure:2655: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_lib_$ac_lib_var=yes" else *************** case "$host" in *** 2734,2739 **** --- 2723,2734 ---- # alpha*-*-*) # machdep="alpha_mach_dep.lo" # ;; + i?86-*-solaris2.[89]*) + cat >> confdefs.h <<\EOF + #define SOLARIS25_PROC_VDB_BUG_FIXED 1 + EOF + + ;; mipstx39-*-elf*) machdep="mips_ultrix_mach_dep.lo" cat >> confdefs.h <<\EOF diff -Nrc3pad gcc-3.0.1/boehm-gc/configure.in gcc-3.0.2/boehm-gc/configure.in *** gcc-3.0.1/boehm-gc/configure.in Fri Jun 8 10:59:15 2001 --- gcc-3.0.2/boehm-gc/configure.in Wed Sep 26 06:10:55 2001 *************** case "$host" in *** 105,110 **** --- 105,113 ---- # alpha*-*-*) # machdep="alpha_mach_dep.lo" # ;; + i?86-*-solaris2.[[89]]*) + AC_DEFINE(SOLARIS25_PROC_VDB_BUG_FIXED) + ;; mipstx39-*-elf*) machdep="mips_ultrix_mach_dep.lo" AC_DEFINE(STACKBASE, __stackbase) diff -Nrc3pad gcc-3.0.1/boehm-gc/gcconfig.h gcc-3.0.2/boehm-gc/gcconfig.h *** gcc-3.0.1/boehm-gc/gcconfig.h Wed Apr 4 17:13:13 2001 --- gcc-3.0.2/boehm-gc/gcconfig.h Wed Sep 26 06:10:55 2001 *************** *** 722,733 **** # endif # ifdef SUNOS5 # define OS_TYPE "SUNOS5" ! extern int etext, _start; extern char * GC_SysVGetDataStart(); ! # define DATASTART GC_SysVGetDataStart(0x1000, &etext) ! # define STACKBOTTOM ((ptr_t)(&_start)) /** At least in Solaris 2.5, PROC_VDB gives wrong values for dirty bits. */ ! /*# define PROC_VDB*/ # define DYNAMIC_LOADING # ifndef USE_MMAP # define USE_MMAP --- 722,737 ---- # endif # ifdef SUNOS5 # define OS_TYPE "SUNOS5" ! extern int _etext, _end; extern char * GC_SysVGetDataStart(); ! # define DATASTART GC_SysVGetDataStart(0x1000, &_etext) ! # define DATAEND (&_end) ! # include ! # define STACKBOTTOM USRSTACK /** At least in Solaris 2.5, PROC_VDB gives wrong values for dirty bits. */ ! # ifdef SOLARIS25_PROC_VDB_BUG_FIXED ! # define PROC_VDB ! # endif # define DYNAMIC_LOADING # ifndef USE_MMAP # define USE_MMAP diff -Nrc3pad gcc-3.0.1/boehm-gc/mach_dep.c gcc-3.0.2/boehm-gc/mach_dep.c *** gcc-3.0.1/boehm-gc/mach_dep.c Wed Apr 26 17:43:33 2000 --- gcc-3.0.2/boehm-gc/mach_dep.c Wed Sep 26 09:22:08 2001 *************** void GC_push_regs() *** 281,286 **** --- 281,298 ---- # if defined(I386) && (defined(SVR4) || defined(SCO) || defined(SCO_ELF)) /* I386 code, SVR4 variant, generic code does not appear to work */ + # ifdef __GNUC__ + /* This is necessary to support PIC code. */ + # define call_push(REGNAME) \ + { register word reg __asm__( #REGNAME ); GC_push_one (reg); } + + # ifndef PIC + call_push(ebx) + # endif + call_push(ebp) + call_push(esi) + call_push(edi) + # else /* !__GNUC__ */ asm("pushl %eax"); asm("call GC_push_one"); asm("addl $4,%esp"); asm("pushl %ebx"); asm("call GC_push_one"); asm("addl $4,%esp"); asm("pushl %ecx"); asm("call GC_push_one"); asm("addl $4,%esp"); *************** void GC_push_regs() *** 288,293 **** --- 300,306 ---- asm("pushl %ebp"); asm("call GC_push_one"); asm("addl $4,%esp"); asm("pushl %esi"); asm("call GC_push_one"); asm("addl $4,%esp"); asm("pushl %edi"); asm("call GC_push_one"); asm("addl $4,%esp"); + # endif /* !__GNUC__ */ # endif # ifdef NS32K diff -Nrc3pad gcc-3.0.1/boehm-gc/solaris_threads.c gcc-3.0.2/boehm-gc/solaris_threads.c *** gcc-3.0.1/boehm-gc/solaris_threads.c Wed Apr 19 03:09:58 2000 --- gcc-3.0.2/boehm-gc/solaris_threads.c Wed Sep 26 06:10:56 2001 *************** GC_thread GC_lookup_thread(thread_t id) *** 616,622 **** --- 616,633 ---- return(p); } + /* Solaris 2/Intel uses an initial stack size limit slightly bigger than the + SPARC default of 8 MB. Account for this to warn only if the user has + raised the limit beyond the default. + + This is identical to DFLSSIZ defined in . This file + is installed in /usr/platform/`uname -m`/include, which is not in the + default include directory list, so copy the definition here. */ + #ifdef I386 + # define MAX_ORIG_STACK_SIZE (8 * 1024 * 1024 + ((USRSTACK) & 0x3FFFFF)) + #else # define MAX_ORIG_STACK_SIZE (8 * 1024 * 1024) + #endif word GC_get_orig_stack_size() { struct rlimit rl; *************** word GC_get_orig_stack_size() { *** 627,633 **** result = (word)rl.rlim_cur & ~(HBLKSIZE-1); if (result > MAX_ORIG_STACK_SIZE) { if (!warned) { ! WARN("Large stack limit(%ld): only scanning 8 MB", result); warned = 1; } result = MAX_ORIG_STACK_SIZE; --- 638,644 ---- result = (word)rl.rlim_cur & ~(HBLKSIZE-1); if (result > MAX_ORIG_STACK_SIZE) { if (!warned) { ! WARN("Large stack limit(%ld): only scanning 8 MB\n", result); warned = 1; } result = MAX_ORIG_STACK_SIZE; diff -Nrc3pad gcc-3.0.1/bugs.html gcc-3.0.2/bugs.html *** gcc-3.0.1/bugs.html Sun Aug 19 17:45:06 2001 --- gcc-3.0.2/bugs.html Tue Oct 23 10:56:06 2001 *************** *** 8,15 ****

    GCC Bugs

    The latest version of this document is always available at ! ! http://gcc.gnu.org/bugs.html.


    --- 8,14 ----

    GCC Bugs

    The latest version of this document is always available at ! http://www.gnu.org/software/gcc/bugs.html.


    *************** http://gcc.gnu.org/bugs.html.

    *** 53,63 ****

    Before you report a bug, please check the list of well-known bugs and, if possible ! in any way, try a current development snapshot or ! CodeSourcery's ! Online Test Compilation. If you want to report a bug ! with egcs 1.x or versions of GCC before 3.0 we strongly recommend ! upgrading to the current release first.

    Before reporting that GCC compiles your code incorrectly, please compile it with gcc -Wall and see whether this shows --- 52,60 ----

    Before you report a bug, please check the list of well-known bugs and, if possible ! in any way, try a current development snapshot. ! If you want to report a bug with versions of GCC before 3.0 we strongly ! recommend upgrading to the current release first.

    Before reporting that GCC compiles your code incorrectly, please compile it with gcc -Wall and see whether this shows *************** contributors.

    *** 244,251 ****
    • GCC 2.95.2 does not build on GNU/Linux systems using glibc 2.2, ! such as Red Hat 7.0. A patch is ! available. This is fixed in GCC 2.95.3 and GCC 3.0.
    • GCC 2.95.2 crashes when compiling mbx.c from the PINE 4.30 or IMAP2000 distribution on Sparc systems running Solaris.
    • --- 241,247 ----
      • GCC 2.95.2 does not build on GNU/Linux systems using glibc 2.2, ! such as Red Hat 7.0. This is fixed in GCC 2.95.3 and GCC 3.0.
      • GCC 2.95.2 crashes when compiling mbx.c from the PINE 4.30 or IMAP2000 distribution on Sparc systems running Solaris.
      • *************** available. This is fixed in GCC 2.95.3 *** 256,265 ****

        Fortran

        !

        Fortran bugs are documented in the G77 manual rather than explicitly listed here. Please see ! "Known Causes of Trouble with GNU ! Fortran" in the G77 manual.


        --- 252,261 ----

        Fortran

        !

        Fortran bugs are documented in the G77 manual rather than explicitly listed here. Please see ! Known Causes of ! Trouble with GNU Fortran in the G77 manual.


        *************** main.

        *** 294,302 ****

        There is a common misconception that the GCC developers are responsible for GNU libc. These are in fact two entirely separate ! projects. The appropriate place to ask questions relating to GNU libc ! is ! libc-alpha@sources.redhat.com.

        Cannot use preprocessor directive in macro arguments.
        --- 290,298 ----

        There is a common misconception that the GCC developers are responsible for GNU libc. These are in fact two entirely separate ! projects; please check the ! GNU libc web pages ! for details.

        Cannot use preprocessor directive in macro arguments.
        *************** to round to the nearest representable nu *** 548,554 ****

        This is not a bug in the compiler, but an inherent limitation of the float and double types. Please study ! this paper for more information.

        --- 544,550 ----

        This is not a bug in the compiler, but an inherent limitation of the float and double types. Please study ! this paper for more information.

        diff -Nrc3pad gcc-3.0.1/config/ChangeLog gcc-3.0.2/config/ChangeLog *** gcc-3.0.1/config/ChangeLog Sun Aug 19 14:08:02 2001 --- gcc-3.0.2/config/ChangeLog Tue Oct 23 10:18:59 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/config/mpw/ChangeLog gcc-3.0.2/config/mpw/ChangeLog *** gcc-3.0.1/config/mpw/ChangeLog Sun Aug 19 14:08:03 2001 --- gcc-3.0.2/config/mpw/ChangeLog Tue Oct 23 10:18:55 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/configure gcc-3.0.2/configure *** gcc-3.0.1/configure Sat Feb 17 05:16:58 2001 --- gcc-3.0.2/configure Mon Oct 1 23:50:12 2001 *************** *** 3,9 **** ### WARNING: this file contains embedded tabs. Do not run untabify on this file. # Configuration script ! # Copyright (C) 1988, 90, 91, 92, 93, 94, 95, 96, 97, 98, 1999 # Free Software Foundation, Inc. # This program is free software; you can redistribute it and/or modify --- 3,9 ---- ### WARNING: this file contains embedded tabs. Do not run untabify on this file. # Configuration script ! # Copyright (C) 1988, 90, 91, 92, 93, 94, 95, 96, 97, 98, 1999, 2000, 2001 # Free Software Foundation, Inc. # This program is free software; you can redistribute it and/or modify *************** subdirs= *** 89,95 **** target_alias=NOTARGET target_makefile_frag= undefs=NOUNDEFS ! version="$Revision: 1.34.2.1 $" x11=default bindir='${exec_prefix}/bin' sbindir='${exec_prefix}/sbin' --- 89,95 ---- target_alias=NOTARGET target_makefile_frag= undefs=NOUNDEFS ! version="$Revision: 1.34.2.2 $" x11=default bindir='${exec_prefix}/bin' sbindir='${exec_prefix}/sbin' *************** case "${TMPDIR}" in *** 663,675 **** esac # keep this filename short for &%*%$*# 14 char file names and 8+3 file names ! tmpfile=${TMPDIR}/cNf$$ # Note that under many versions of sh a trap handler for 0 will *override* any # exit status you explicitly specify! At this point, the only non-error exit # is at the end of the script; these actions are duplicated there, minus # the "exit 1". Don't use "exit 0" anywhere after this without resetting the # trap handler, or you'll lose. ! trap "rm -f Makefile.tem ${tmpfile}.com ${tmpfile}.tgt ${tmpfile}.hst ${tmpfile}.pos; exit 1" 0 1 2 15 # split ${srcdir}/configure.in into common, per-host, per-target, # and post-target parts. Post-target is optional. --- 663,677 ---- esac # keep this filename short for &%*%$*# 14 char file names and 8+3 file names ! tmpdir=${TMPDIR}/cNf$$ ! mkdir ${tmpdir} || exit 1 ! tmpfile=${tmpdir}/cNf$$ # Note that under many versions of sh a trap handler for 0 will *override* any # exit status you explicitly specify! At this point, the only non-error exit # is at the end of the script; these actions are duplicated there, minus # the "exit 1". Don't use "exit 0" anywhere after this without resetting the # trap handler, or you'll lose. ! trap "rm -rf Makefile.tem ${tmpdir}; exit 1" 0 1 2 15 # split ${srcdir}/configure.in into common, per-host, per-target, # and post-target parts. Post-target is optional. *************** if test -f skip-this-dir; then *** 696,702 **** # Perform the same cleanup as the trap handler, minus the "exit 1" of course, # and reset the trap handler. trap 0 ! rm -f Makefile* ${tmpfile}.com ${tmpfile}.tgt ${tmpfile}.hst ${tmpfile}.pos # Execute the final clean-up actions ${config_shell} skip-this-dir # and stop configuring this directory. --- 698,704 ---- # Perform the same cleanup as the trap handler, minus the "exit 1" of course, # and reset the trap handler. trap 0 ! rm -rf Makefile* ${tmpdir} # Execute the final clean-up actions ${config_shell} skip-this-dir # and stop configuring this directory. *************** fi *** 1600,1606 **** # Perform the same cleanup as the trap handler, minus the "exit 1" of course, # and reset the trap handler. ! rm -f ${tmpfile}.com ${tmpfile}.tgt ${tmpfile}.hst ${tmpfile}.pos trap 0 exit 0 --- 1602,1608 ---- # Perform the same cleanup as the trap handler, minus the "exit 1" of course, # and reset the trap handler. ! rm -rf ${tmpdir} trap 0 exit 0 diff -Nrc3pad gcc-3.0.1/contrib/ChangeLog gcc-3.0.2/contrib/ChangeLog *** gcc-3.0.1/contrib/ChangeLog Sun Aug 19 14:08:04 2001 --- gcc-3.0.2/contrib/ChangeLog Tue Oct 23 10:19:03 2001 *************** *** 1,3 **** --- 1,11 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + + 2001-08-24 Mark Mitchell + + * gcc_release: Correct quoting. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/contrib/gcc_release gcc-3.0.2/contrib/gcc_release *** gcc-3.0.1/contrib/gcc_release Mon Aug 13 22:36:42 2001 --- gcc-3.0.2/contrib/gcc_release Fri Aug 24 13:16:05 2001 *************** EOF *** 131,137 **** for x in gcc/version.c; do y=`basename ${x}` (changedir `dirname ${SOURCE_DIRECTORY}/${x}` && \ ! sed -e 's|= \".*\"|= \"${RELEASE}\"|g' < ${y} > ${y}.new && \ mv ${y}.new ${y} && \ ${CVS} ci -m 'Update version' ${y}) || \ error "Could not update ${x}" --- 131,137 ---- for x in gcc/version.c; do y=`basename ${x}` (changedir `dirname ${SOURCE_DIRECTORY}/${x}` && \ ! sed -e 's|= \".*\"|= \"'${RELEASE}'\"|g' < ${y} > ${y}.new && \ mv ${y}.new ${y} && \ ${CVS} ci -m 'Update version' ${y}) || \ error "Could not update ${x}" *************** EOF *** 155,161 **** # Tag the sources. if [ -n "${TAG}" ]; then inform "Tagging release sources" ! ${CVS} rtag -r ${BRANCH} ${TAG} gcc || \ error "Could not tag release sources" BRANCH=$TAG fi --- 155,161 ---- # Tag the sources. if [ -n "${TAG}" ]; then inform "Tagging release sources" ! ${CVS} rtag -r ${BRANCH} -F ${TAG} gcc || \ error "Could not tag release sources" BRANCH=$TAG fi diff -Nrc3pad gcc-3.0.1/faq.html gcc-3.0.2/faq.html *** gcc-3.0.1/faq.html Sun Aug 19 17:45:09 2001 --- gcc-3.0.2/faq.html Tue Oct 23 10:56:16 2001 *************** *** 9,21 ****

        GCC Frequently Asked Questions

        The latest version of this document is always available at ! http://gcc.gnu.org/faq.html.

        This FAQ tries to answer specific questions concerning GCC. For general information regarding C, C++, resp. Fortran please check the comp.lang.c FAQ, - - comp.lang.c++ FAQ, comp.std.c++ FAQ, and the Fortran Information --- 9,19 ----

        GCC Frequently Asked Questions

        The latest version of this document is always available at ! http://www.gnu.org/software/gcc/faq.html.

        This FAQ tries to answer specific questions concerning GCC. For general information regarding C, C++, resp. Fortran please check the comp.lang.c FAQ, comp.std.c++ FAQ, and the Fortran Information *************** page.

        *** 37,42 **** --- 35,41 ----
      • How do I report a bug?
      • How do I get a bug fixed or a feature added?
      • How can I get a development environment for GCC without using CVS?
      • +
      • Does GCC work on my platform?
      • Installation *************** page.

        *** 58,67 ****
      • How can I run the test suite with multiple options?
      • !
      • Older versions of GCC or EGCS
          !
        1. Why is there no testsuite in GCC 2.95?
        2. !
        3. Is there a stringstream / sstream for gcc 2.95.2?
      • Miscellaneous --- 57,65 ----
      • How can I run the test suite with multiple options?
      • !
      • Older versions of GCC
          !
        1. Is there a stringstream / sstream for GCC 2.95.2?
      • Miscellaneous *************** page.

        *** 69,81 ****
      • Virtual memory exhausted
      • Friend Templates
      • Why do I need autoconf, bison, xgettext, automake, etc?
      • -
      • Problems debugging GCC code
      • -
      • Using GCC with GNAT/Ada
      • Why can't I build a shared library?
      • How to work around too long C++ symbol names? (-fsquangle)
      • When building C++, the linker says my constructors, destructors or virtual tables are undefined, but I defined them
      • -
      • What is libstdc++-v3 and how can I use it with g++?
      • Will GCC someday include an incremental linker?
      • --- 67,76 ---- *************** disadvantages.

        *** 197,208 **** individuals providing support for GCC. This alternative costs money, but is relatively likely to get results. !
      • Report the problem to gcc-bugs and hope that someone will be kind enough to fix it for you. While this is certainly possible, and often happens, there is no guarantee that it will. You should ! not expect the same response from gcc-bugs that you would see from a commercial support organization since the people who read ! gcc-bugs, if they choose to help you, will be volunteering their time. This alternative will work best if you follow the directions on submitting bugreports.
      • --- 192,204 ---- individuals providing support for GCC. This alternative costs money, but is relatively likely to get results. !
      • Report the problem to the GCC GNATS bug tracking system ! and hope that someone will be kind enough to fix it for you. While this is certainly possible, and often happens, there is no guarantee that it will. You should ! not expect the same response from this method that you would see from a commercial support organization since the people who read ! GCC bug reports, if they choose to help you, will be volunteering their time. This alternative will work best if you follow the directions on submitting bugreports.
      • *************** disadvantages.

        *** 219,226 **** without using CVS?

        GCC snapshots are available from the FTP server and its mirrors; ! see the GCC mirror list.


        --- 215,235 ---- without using CVS?

        GCC snapshots are available from the FTP server and its mirrors; ! see the GCC mirror list.

        ! !
        +

        Does GCC work on my platform?

        + +

        The host/target specific installation notes for GCC include information + about known problems with installing or using GCC on particular platforms. + These are included in the sources for a release in INSTALL/specific.html, + and the latest version + is always available at the GCC web site. + Reports of successful builds for GCC versions + 3.0 and + 2.95 + are also available at the web site.


        *************** do not follow the install instructions c *** 236,245 **** "make bootstrap" if you are building a native compiler or "make cross" if you are building a cross compiler.

        -

        It has also been reported that the Fortran compiler can not be built - on Red Hat 4.X GNU/Linux for the Alpha. Fixing this may require upgrading - binutils or to Red Hat 5.0; we'll provide more information as it becomes - available.


        How to install multiple versions of GCC

        --- 245,250 ---- *************** may have to take one of the following ac *** 355,361 **** the GNU versions of those programs.

        To ensure that GCC finds the GNU assembler (the GNU loader), which ! are required by some configurations, you should configure these with the same --prefix option as you used for GCC. Then build & install GNU as (GNU ld) and proceed with building GCC.

        --- 360,367 ---- the GNU versions of those programs.

        To ensure that GCC finds the GNU assembler (the GNU loader), which ! are required by some ! configurations, you should configure these with the same --prefix option as you used for GCC. Then build & install GNU as (GNU ld) and proceed with building GCC.

        *************** no additional flags.

        *** 458,476 ****

        Older versions of GCC and EGCS

        !

        Why is there no testsuite in GCC 2.95?

        ! !

        The GCC testsuite is not included in the GCC 2.95 release due to the ! uncertain copyright status of some tests.

        ! !

        The GCC team has reviewed the entire testsuite to find and remove ! any tests with uncertain copyright status, following guidelines from ! Prof. Eben Moglen. The testsuite is included in GCC 3.0 and ! subsequent releases. Only a few tests needed to be removed from the ! testsuite.

        ! !
        !

        Is there a stringstream / sstream for gcc 2.95.2?

        Yes, it's at: --- 464,470 ----

        Older versions of GCC and EGCS

        !

        Is there a stringstream / sstream for GCC 2.95.2?

        Yes, it's at: *************** testsuite.

        *** 480,485 **** --- 474,481 ----

        Miscellaneous

        + +

        Virtual memory exhausted error

        This error means your system ran out of memory; this can happen for large *************** of packages.

        *** 583,604 ****
        -

        Problems debugging GCC code

        - -

        On some systems GCC will produce dwarf debug records by default; however - the gdb-4.16 release may not be able to read such debug records.

        - -

        You can either use the argument "-gstabs" instead of "-g" or pick up - a copy of gdb-4.17 to work around the problem. - -


        -

        Using GCC with GNAT/Ada

        -

        The GNU Ada front-end is not currently supported by GCC, but work - is in progress to integrate GNU Ada into the GCC CVS repository and - produce new releases based on current versions of GCC.

        - - -

        Why can't I build a shared library?

        When building a shared library you may get an error message from the --- 579,584 ---- *************** done.

        *** 669,684 **** pure are defined. Note that a destructor must be defined even if it is declared pure-virtual [class.dtor]/7.

        -
        -

        What is libstdc++-v3 and how can I use it with g++?

        - -

        From the - libstdc++-v3 FAQ: - "The GNU Standard C++ Library v3, or libstdc++-2.9x, is an ongoing - project to implement the ISO 14882 Standard C++ library as described - in chapters 17 through 27 and annex D."

        - -

        libstdc++-v3 is enabled by default in 3.x releases of GCC.


        Will GCC someday include an incremental linker?

        --- 649,654 ---- diff -Nrc3pad gcc-3.0.1/fastjar/ChangeLog gcc-3.0.2/fastjar/ChangeLog *** gcc-3.0.1/fastjar/ChangeLog Sun Aug 19 14:08:05 2001 --- gcc-3.0.2/fastjar/ChangeLog Tue Oct 23 10:19:07 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/gcc/ChangeLog gcc-3.0.2/gcc/ChangeLog *** gcc-3.0.1/gcc/ChangeLog Sun Aug 19 14:08:08 2001 --- gcc-3.0.2/gcc/ChangeLog Tue Oct 23 10:19:18 2001 *************** *** 1,3 **** --- 1,524 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + + 2001-10-23 Joseph S. Myers + + * doc/gcc.texi (Sending Patches): Remove. + + 2001-10-17 Joseph S. Myers + + * doc/gcc.1: Regenerate. + + 2001-10-16 Matt Kraai + + * c-tree.texi: Eliminate duplicated word. + * cpp.texi: Likewise. + * install.texi: Likewise. + * invoke.texi: Likewise. + * tm.texi: Likewise. + + 2001-10-14 Craig Rodrigues + + PR c/4157 + * config/i386/cygwin.h: Add missing space to MINGW_INCLUDES. + + 2001-10-13 Craig Rodrigues + + * doc/invoke.texi: Remove -fvtable-gc. + * doc/gcc.1: Likewise. + + 2001-10-12 Joseph S. Myers + + * doc/cpp.1, doc/gcc.1, doc/gcov.1: Regenerate. + + 2001-10-11 Franz Sirl + + * unroll.c (loop_iterations): Extend check for multiple back edges. + + 2001-10-11 Mark Mitchell + + Revert these changes: + + 2001-10-10 Franz Sirl + PR c++/4512 + * unroll.c (loop_iterations): Ignore insns generated by loop + unrolling. + 2001-10-08 Franz Sirl + * unroll.c (loop_iterations): Extend check for multiple back edges. + + 2001-10-10 Danny Smith + + * config/i386/mingw32.h (WIN32_NO_ABSOLUTE_INST_DIRS): New define. + (Thanks to Chris Faylor for suggesting macro name). + (CPP_PREDEFINES): Define __MINGW32__ but don't set value; add more + WIN32 defines. + (STANDARD_INCLUDE_DIR): Remove i386- from directory name. + (STANDARD_INCLUDE_COMPONENT): Change to MINGW. + (MATH_LIBRARY): Undef before definition. + (OUTPUT_QUOTED_STRING): Likewise. + * config/i386/cygwin.h: Use WIN32_NO_ABSOLUTE_INST_DIRS. + + 2001-10-10 Franz Sirl + + PR c++/4512 + * unroll.c (loop_iterations): Ignore insns generated by loop + unrolling. + + 2001-10-10 Hartmut Schirmer + + * config/float-i128.h: Make sure __STDC__VERSION__ is defined + before using it. + * config/float/i32.h: Likewise. + * config/float-i386.h: Likewise. + * config/float-i64.h: Likewise. + * config/float-m68k.h: Likewise. + * config/float-sh.h: Likewise. + * config/float-sparc.h: Likewise. + + 2001-10-09 Danny Smith + + * config.gcc (i[34567]86-*-mingw32*): Make msvcrt-dependent + version default. + + 2001-10-10 Joseph S. Myers + + * doc/c-tree.texi, doc/extend.texi, doc/install.texi, doc/md.texi, + doc/rtl.texi, doc/tm.texi: Consistently use "nonzero" instead of + "non-zero". + + 2001-10-09 Kazu Hirata + + * doc/cpp.texi: Fix typos. + * doc/c-tree.texi: Likewise. + * doc/extend.texi: Likewise. + * doc/invoke.texi: Likewise. + * doc/objc.texi: Likewise. + + 2001-10-09 Joseph S. Myers + + * doc/gcc.texi: Document preference for "nonzero" over "non-zero". + + 2001-10-08 Neil Booth + + * doc/cpp.texi: Update. + + 2001-10-08 Neil Booth + + * cppmacro.c (_cpp_create_definition): Leave comments off. + * cpplex.c (_cpp_lex_token): Don't save comments if skipping. + + * doc/cpp.texi: Update. + + 2001-10-08 Franz Sirl + + * unroll.c (loop_iterations): Extend check for multiple back edges. + + 2001-10-08 Jeffrey A Law + + * sibcall.c (optimize_sibling_and_tail_recursive_calls): Call + purge_mem_unchanging_flag on all instructions, not just on those + before NOTE_INSN_FUNCTION_BEG. + + 2001-10-07 Joseph S. Myers + + * doc/gcc.texi: Fix spelling error of "separate" as "seperate". + + 2001-10-07 Joseph S. Myers + + * doc/c-tree.texi, doc/tm.texi: Consistently put NULL and + NULL_TREE inside @code. + + 2001-10-07 Joseph S. Myers + + * doc/gcc.texi: Document consistent style of "32-bit", + "Objective-C", and "@code{NULL}". + + 2001-10-05 Richard Henderson + + * i386.md (movsi_xor): Export. + (setcc peep2): Use it when available. + + 2001-10-05 Richard Henderson + + * dwarf2out.c (FRAME_BEGIN_LABEL): New. + (output_call_frame_info): Use it instead of __FRAME_BEGIN__ and + the gas section-name-as-label feature. + + 2001-10-04 Loren J. Rittle + + * Makefile.in (STAGE2_FLAGS_TO_PASS): Remove patch which + propagated HOST_CC. + + Thu Oct 4 16:18:12 CEST 2001 Jan Hubicka + + * gcc.c (main): Set this_file_error if the appropriate + compiler for a language has not been installed. + + 2001-10-01 Loren J. Rittle + + * Makefile.in (STAGE2_FLAGS_TO_PASS): Propagate HOST_CC. + (fixinc.sh): Map CC, CFLAGS and LDFLAGS to HOST_* versions for + later recursive make invocation. + + 2001-10-01 Stephane Carrez + + * config/m68hc11/m68hc11.md ("add-split"): Fix add split when + operand 2 is the stack pointer. + ("addr-peephole"): Fix address computation peephole when operand 2 + is the stack pointer. + + 2001-09-30 Stephane Carrez + + * config/m68hc11/m68hc11.md ("cmpqi_1"): Fix constraints. + ("tsthi_1"): Avoid allocation in register y. + ("*movqi_68hc12"): Reorganize and fix constraints. + ("zero_extendqisi2"): Prefer d over x and y for operand 1. + ("addqi3"): Likewise. + ("addhi3"): Fix constraints. + ("*logicalhi3_zexthi"): Disparage soft registers. + + 2001-09-30 Stephane Carrez + + * config/m68hc11/m68hc11.c (m68hc11_gen_movhi): Fix move of sp + to tmp reg. + + 2001-09-30 Stephane Carrez + + * config/m68hc11/m68hc11.h(INCOMING_RETURN_ADDR_RTX): Remove so + that we use setjmp/longjmp exceptions. + + 2001-09-30 Ulrich Weigand + + * config/s390/s390.c (s390_adjust_cost): Fixed incorrect scheduling. + * config/s390/s390.md (function units): Likewise. + + * config/s390/s390.md (addsi3_cc, addsi3_cconly, addsi3_cconly2, + subsi3_cc, subsi3_cconly): Removed. + + * config/s390/s390.c (legitimate_la_operand_p): New. + * config/s390/s390-protos.h (legitimate_la_operand_p): Add. + * config/s390/s390.md (movsi): Convert load address patterns to + arithmetic operations when necessary. + (addaddr_picR, addaddr_picL, addaddr_picN): Removed. + (do_la): Renamed to *do_la and use legitimate_la_operand_p. + (*do_la_reg_0): Don't use before reload. + + * config/s390/s390.c (legitimize_address): Make more efficient + use of two-register addressing mode. + + * config/s390/s390.c (s390_function_prologue): Fix incorrect prolog + with -mno-backchain in some corner cases. + + * config/s390/s390.md (cmpsi_cct): Operands 0 and 1 do not commute. + + 2001-09-29 Alexandre Oliva + + * reload.c (find_reloads): Mark new USE insns with QImode. + (find_reloads_toplev, find_reloads_address, subst_reg_equivs, + find_reloads_subreg_address): Likewise. + * regrename.c (note_sets, clear_dead_regs): Abort if pseudos are + encountered. + * reload1.c (reload_combine_note_use): Likewise, inside USEs and + CLOBBERs. + (reload): Make sure there are no USEs with mode other than + VOIDmode. At the end, remove those marked with QImode. + + 2001-09-28 Rainer Orth + + * config/i386/sol2.h (CPLUSPLUS_CPP_SPEC): Define. + + 2001-09-27 Richard Henderson + + * dwarf2out.c (dwarf2out_frame_finish): Never elide .debug_frame + in favour of .eh_frame; fix eh test wrt USING_SJLJ_EXCEPTIONS. + + Tue Sep 25 15:09:03 2001 Rainer Orth + + * doc/install.texi (Specific, sparc-sun-solaris2*): Document + 64-bit support. + + 2001-09-25 Janis Johnson + Jim Wilson + + * doc/install.texi (Specific, ia64-*-linux): Document. + + 2001-09-24 David Edelsohn + + * rs6000.c (lwa_operand): Address must be word aligned. + + 2001-09-24 Janis Johnson + + * doc/install.texi (Final install): Request additional information + in mail about successful builds. + + 2001-09-24 Rainer Orth + + * doc/install.texi: Markup fixes. + Use Solaris 2, SunOS 4 as appropriate. + (Specific, *-*-solaris2*): Explain this. + Unconditionally warn against /usr/ucb tools. + Remove Sun as warning, obsolete. + Move X11 header bug workaround here, update patches. + (Specific, sparc-sun-solaris2*): Detail Sun as fix status. + (Specific, sparc-sun-solaris2.7): Update patch 106950 status. + + 2001-09-21 Richard Henderson + + * tree.def (FDESC_EXPR): New. + * expr.c (expand_expr): Handle it. + * varasm.c (initializer_constant_valid_p): Likewise. + (output_constant): Likewise. + * defaults.h (TARGET_VTABLE_USES_DESCRIPTORS): New. + * config/ia64/ia64.h (TARGET_VTABLE_USES_DESCRIPTORS): New. + (ASM_OUTPUT_FDESC): New. + + 2001-09-20 Andrew MacLeod + + * testsuite/gcc.c-torture/execute/990208-1.x: New. XFAIL at -O3 + on ia64. + + Thu Sep 20 12:49:34 2001 J"orn Rennecke + + * sh.c (shiftcosts): Don't use shiftcosts array for modes wider + than SImode. + + Thu Sep 20 12:18:41 2001 J"orn Rennecke + + * sh.c (initial_elimination_offset): When seeing + RETURN_ADDRESS_POINTER_REGNUM, force pr to be live. + Fix FROM == RETURN_ADDRESS_POINTER_REGNUM case. + + 2001-08-21 Richard Henderson + + * config/ia64/ia64.c (ia64_return_in_memory): True for variable + sized types. + + 2001-06-19 Bernd Schmidt + + * regmove.c (optimize_reg_copy_3): Do nothing if previous insn + carries a REG_EQUIV note. If it carries REG_EQUAL, delete the + note. + + 2001-09-18 Philip Blundell + + * config/arm/lib1funcs.asm (L_dvmd_lnx): Don't rely on kernel + header files. + + 2001-09-17 Jeff Sturm + + * except.c (dw2_build_landing_pads): New local + clobbers_hard_regs. Emit an ASM_INPUT as a scheduling + barrier after clobbers. Fixes c++/4012. + + 2001-09-17 Franz Sirl + + * gcse.c (hash_scan_set): Fix merge glitch in last patch. + + 2001-09-17 Joseph S. Myers + + * listing: Remove obsolete file. + + 2001-09-15 Richard Henderson + + * c-typeck.c (comptypes): Handle zero-length arrays properly. + + 2001-09-15 David Edelsohn + + * doc/install.texi: Explain AIX exception handling work-around. + Update URL for AIX fixes. + + 2001-09-15 Neil Booth + + * cpplib.c (do_pragma): Never expand macros. + + 2001-09-14 Richard Henderson + + * config/i386/i386.c (internal_label_prefix): New. + (internal_label_prefix_len): New. + (override_options): Set them. + (local_symbolic_operand): New. + (legitimate_pic_address_disp_p): Use it. + (legitimize_pic_address): Likewise. + + 2001-09-14 Marc Espie + + * config/i386/unix.h (ASM_OUTPUT_MI_THUNK): Generate reference to GOT + correctly. + + 2001-09-13 Markus Werle + Gerald Pfeifer + + * doc/install.texi (Binaries): Add "Binaries for HP-UX 11.00 at + Aachen University of Technology". + + 2001-09-13 Andreas Schwab + + * config/float-m68k.h: Define DECIMAL_DIG and FLT_EVAL_METHOD for + C99. + + 2001-09-12 Josh Martin + + * fixinc/inclhack.def(hpux11_size_t): Keep HP-UX headers from + defining __size_t and leaving size_t undefined. + + 2001-09-12 Jakub Jelinek + + * gcse.c (gcse_main): Fix comment typo. + (delete_null_pointer_check): Likewise. + (hash_scan_set): Don't consider sets with REG_EQUIV MEM notes. + * cse.c (cse_insn): Likewise. + * function.c (fixup_var_refs_insns_with_hash): The sequence is + toplevel. + + 2001-09-11 Jim Wilson + + * alias.c (clear_reg_alias_info): Only handle pseudo registers. + + 2001-09-10 Tim Freeman + + * dwarf2out.c (incomplete_types, decl_scope_table): Make them + into varray's and register them as roots with the garbage + collector so they are not collected too soon. + + 2001-09-10 David Edelsohn + + * config/rs6000/rs6000.c (scc_eq_operand): New predicate. + * config/rs6000/rs6000-protos.h: Declare it. + * config/rs6000/rs6000.h (PREDICATE_CODES): Add it. + * config/rs6000/rs6000.md (SCC eq:DI): Use it. + * config/rs6000/t-aix43 (SHLIB_INSTALL): Use mode 751 (a+x,r-o). + + 2001-09-07 Jim Wilson + + * alias.c (clear_reg_alias_info): New. + * flow.c (attempt_auto_inc): Call clear_reg_alias_info. + * rtl.h (clear_reg_alias_info): Declare. + + 2001-09-06 Richard Henderson + + * simplify-rtx.c (simplify_binary_operation): Revert last change. + + 2001-09-06 Richard Henderson + + * simplify-rtx.c (simplify_binary_operation): Simplify contents + of CONST. + + 2001-09-06 Franz Sirl + + * config/rs6000/rs6000.c (rs6000_emit_prologue): Fix DWARF2 register + number used for CR register. + + 2001-09-06 Alan Modra + + * config/rs6000/rs6000.c (mask_operand): Use signed vars to avoid + compiler warnings. + (mask64_operand): Likewise. + (includes_rldic_lshift_p): Likewise. + (includes_rldicr_lshift_p): Likewise. + + 2001-09-05 Alan Modra + + * config/rs6000/rs6000.c (mask_operand): Rewrite without + bit-shifting loop. + (mask64_operand): Likewise. + (rldic_operand): Delete. + (includes_lshift64_p): Delete. + (includes_rldic_lshift_p): New function. + (includes_rldicr_lshift_p): New function. + (print_operand): Don't call rldic_operand in case 'W'. + * config/rs6000/rs6000-protos.h (rldic_operand): Remove. + (includes_lshift64_p): Remove. + (includes_rldic_lshift_p): Declare. + (includes_rldicr_lshift_p): Declare. + * config/rs6000/rs6000.h (PREDICATE_CODES): Remove rldic_operand. + * config/rs6000/rs6000.md : + Replace match_operand rldic_operand predicate with + const_int_operand. Replace includes_lshift64_p condition with + includes_rldic_lshift_p. + : New. + + 2001-09-05 David S. Miller + + * config/sparc/linux.h: Set CPLUSPLUS_CPP_SPEC. + * config/sparc/linux64.h: Likewise. + + 2001-09-05 Andreas Jaeger + + * doc/invoke.texi (i386 Options): -mwide-multiply is not + available anymore, remove the documentation. + (i386 Options): Fix typo, cleanup index entries. + + 2001-09-05 Jakub Jelinek + + * stor-layout.c (layout_type) [ARRAY_TYPE]: Copy elements + TYPE_USER_ALIGN. + + * loop.c (express_from_1): Fix CONSTANT_P(a) case. + + 2001-09-04 Richard Henderson + + * unwind.h (_UA_END_OF_STACK): New flag. + * unwind.inc (_Unwind_ForcedUnwind_Phase2): Set it. + + Thu Aug 30 18:50:37 2001 J"orn Rennecke + + * t-h8300 (LIB1ASMFUNCS): Add _fixunssfdi and _fixunssfsi_asm. + (LIB2FUNCS_EXTRA): Define. + config/h8300/lib1funcs.asm: New part: L_fixunssfsi_asm . + config/h8300/fixunssfsi.c: New file. + + Thu Aug 30 16:00:31 2001 J"orn Rennecke + + * h8300.c (dosize): Fix test for "sub". + + 2001-08-29 Kazu Hirata + + * config/h8300/lib1funcs.asm: Update the copyright. Fix + comment typos. + + 2001-08-29 Kazu Hirata + + * config/h8300/h8300.md (anonymous movhi pattern): Don't move + (reg n) to (mem (pre_dec (reg n)). + (anonymous movsi pattern): Likewise. + + 2001-08-29 Kazu Hirata + + * config/h8300/h8300.h (RETURN_ADDR_RTX): New. + + 2001-08-29 Kazu Hirata + + * config/h8300/lib1funcs.asm: Fix comment typos. + + 2001-08-28 Richard Henderson + + * config/ia64/ia64.md (andcmbi3, iorcmbi3): Fix typos. + (one_cmplbi2 splitter): Remove redundant test. + + 2001-08-28 Danny Smith + + * config/i386/cygwin.h (BIGGEST_FIELD_ALIGNMENT): Set to 64. + + 2001-08-24 David Edelsohn + + * config/rs6000/rs6000.c (rs6000_initialize_trampoline): Function + descriptor members are pointer size, not constant 4. + + 2001-08-23 Neil Booth + + * cppmacro.c (enter_macro_context): Push macro expansions even + if empty. + + 2001-08-23 Kazu Hirata + + * config/h8300/h8300.md (zero_extendqihi2): Correct the insn + length. + 2001-08-19 Release Manager * GCC 3.0.1 Released. *************** *** 14,20 **** 2001-08-17 Gerald Pfeifer ! * doc/invoke.texi (Optimize Options): The default for -finline-limit is 600. 2001-08-16 Joel Sherrill --- 535,541 ---- 2001-08-17 Gerald Pfeifer ! * doc/invoke.texi (Optimize Options): The default for -finline-limit is 600. 2001-08-16 Joel Sherrill *************** *** 27,33 **** * config/s390/linux64.h (CPP_PREDEFINES): Define __s390__ also on 64-bit s390x targets. ! 2001-08-14 Gerald Pfeifer * doc/install.texi (Specific, avr): Fix markup. --- 548,554 ---- * config/s390/linux64.h (CPP_PREDEFINES): Define __s390__ also on 64-bit s390x targets. ! 2001-08-14 Gerald Pfeifer * doc/install.texi (Specific, avr): Fix markup. *************** *** 62,79 **** * doc/install.texi (Specific, c4x): Fix cross-reference to the main manual to work both for info and HTML versions. ! 2001-08-10 Ulrich Weigand - - * glimits.h (__LONG_MAX__): Add s390x as 64-bit architecture. ! * config/s390/s390.c (legitimize_pic_address): Don't generate unnecessary moves (to avoid confusing loop optimization). ! (check_and_change_labels): Replace jump_long by indirect_jump. ! (s390_final_chunkify): Don't start a new literal pool on section switch in 64-bit code. (s390_va_start, s390_va_arg): Fixed incorrect sizes for 64-bit. ! * config/s390/s390.h (HARD_REGNO_MODE_OK, RETURN_IN_MEMORY): Support complex integer modes correctly. (reg_class, REG_CLASS_NAMES, REG_CLASS_CONTENTS): Remove CC_REGS. --- 583,600 ---- * doc/install.texi (Specific, c4x): Fix cross-reference to the main manual to work both for info and HTML versions. ! 2001-08-10 Ulrich Weigand ! * glimits.h (__LONG_MAX__): Add s390x as 64-bit architecture. ! ! * config/s390/s390.c (legitimize_pic_address): Don't generate unnecessary moves (to avoid confusing loop optimization). ! (check_and_change_labels): Replace jump_long by indirect_jump. ! (s390_final_chunkify): Don't start a new literal pool on section switch in 64-bit code. (s390_va_start, s390_va_arg): Fixed incorrect sizes for 64-bit. ! * config/s390/s390.h (HARD_REGNO_MODE_OK, RETURN_IN_MEMORY): Support complex integer modes correctly. (reg_class, REG_CLASS_NAMES, REG_CLASS_CONTENTS): Remove CC_REGS. *************** *** 82,89 **** * config/s390/s390.md (divsi3, modsi3): Clobber low word of divmoddisi3 before shifting (to avoid confusing flow analysis). ! (cjump_long, icjump_long, jump_long, indirect_jump, casesi_jump): ! Never use "address_operand" without "p" or "memory_operand" without mode. (builtin_setjmp_setup, builtin_setjmp_receiver, builtin_longjmp): Fixed broken setjmp/longjmp handling. --- 603,610 ---- * config/s390/s390.md (divsi3, modsi3): Clobber low word of divmoddisi3 before shifting (to avoid confusing flow analysis). ! (cjump_long, icjump_long, jump_long, indirect_jump, casesi_jump): ! Never use "address_operand" without "p" or "memory_operand" without mode. (builtin_setjmp_setup, builtin_setjmp_receiver, builtin_longjmp): Fixed broken setjmp/longjmp handling. *************** *** 119,126 **** 2001-08-07 Daniel Jacobowitz ! * config.gcc: Quote target_cpu_default2 correctly for ! powerpc*-*-* targets. 2001-08-07 David Edelsohn --- 640,647 ---- 2001-08-07 Daniel Jacobowitz ! * config.gcc: Quote target_cpu_default2 correctly for ! powerpc*-*-* targets. 2001-08-07 David Edelsohn *************** *** 159,165 **** 2001-08-04 Stephane Carrez ! * config/m68hc11/m68hc11.md ("cmphi_1", "cmpqi_1"): Allow memory and soft register for operand 0. ("cmphi_z_used", "cmpqi_z_used"): Allow memory for operand 0. --- 680,686 ---- 2001-08-04 Stephane Carrez ! * config/m68hc11/m68hc11.md ("cmphi_1", "cmpqi_1"): Allow memory and soft register for operand 0. ("cmphi_z_used", "cmpqi_z_used"): Allow memory for operand 0. *************** *** 200,221 **** (DTORS_SECTION_FUNCTION): Likewise for __do_global_dtors. 2001-08-03 Ulrich Weigand ! ! * config.gcc (s390-*-linux*, s390x-*-linux*): Added. ! * doc/install.texi: Add s390 and s390x targets. ! * doc/invoke.texi: Add s390 and s390x target options. ! * doc/md.texi: Add s390 and s390x extra constraints. ! * config/s390/s390.c: New. Subroutines for code generation. ! * config/s390/s390.h: New. Definitions for S/390. ! * config/s390/s390-protos.h: New. Prototypes. ! * config/s390/linux.h: New. Definitions for Linux for S/390. ! * config/s390/linux64.h: New. Definitions for Linux for zSeries. ! * config/s390/t-linux: New. Makefile fragment. ! * config/s390/s390.md: New. Machine description for S/390 and zSeries. ! * config/s390/xm-390.h: New. Host definitions for S/390. ! * config/s390/xm-390x.h: New. Host definitions for zSeries. ! * config/s390/fixdfdi.h: New. Fix L_fix*di. ! 2001-08-03 Neil Booth * cpplex.c (parse_string): Warn once per string. --- 721,742 ---- (DTORS_SECTION_FUNCTION): Likewise for __do_global_dtors. 2001-08-03 Ulrich Weigand ! ! * config.gcc (s390-*-linux*, s390x-*-linux*): Added. ! * doc/install.texi: Add s390 and s390x targets. ! * doc/invoke.texi: Add s390 and s390x target options. ! * doc/md.texi: Add s390 and s390x extra constraints. ! * config/s390/s390.c: New. Subroutines for code generation. ! * config/s390/s390.h: New. Definitions for S/390. ! * config/s390/s390-protos.h: New. Prototypes. ! * config/s390/linux.h: New. Definitions for Linux for S/390. ! * config/s390/linux64.h: New. Definitions for Linux for zSeries. ! * config/s390/t-linux: New. Makefile fragment. ! * config/s390/s390.md: New. Machine description for S/390 and zSeries. ! * config/s390/xm-390.h: New. Host definitions for S/390. ! * config/s390/xm-390x.h: New. Host definitions for zSeries. ! * config/s390/fixdfdi.h: New. Fix L_fix*di. ! 2001-08-03 Neil Booth * cpplex.c (parse_string): Warn once per string. *************** *** 226,232 **** * doc/install.texi (Configuration): Fix markup. (Specific, i?86-*-udk): Likewise. (Specific, alpha*-dec-osf*): Warn against --with-gnu-as, ! --with-gnu-ld. Document --enable-threads and --enable-libgcj status. (Specific, mips-sgi-irix*): Canonicalize triples. (Specific, mips-sgi-irix5): Warn about problems with this config. --- 747,753 ---- * doc/install.texi (Configuration): Fix markup. (Specific, i?86-*-udk): Likewise. (Specific, alpha*-dec-osf*): Warn against --with-gnu-as, ! --with-gnu-ld. Document --enable-threads and --enable-libgcj status. (Specific, mips-sgi-irix*): Canonicalize triples. (Specific, mips-sgi-irix5): Warn about problems with this config. *************** *** 258,266 **** 2001-08-01 Hartmut Penner ! * varasm.c (decode_rtx_const): Allow unspec (symbol_ref) in constant pool to be identical by string address and index. ! 2001-08-01 Gerald Pfeifer * params.def (PARAM_MAX_INLINE_INSNS): Change default to 600. --- 779,787 ---- 2001-08-01 Hartmut Penner ! * varasm.c (decode_rtx_const): Allow unspec (symbol_ref) in constant pool to be identical by string address and index. ! 2001-08-01 Gerald Pfeifer * params.def (PARAM_MAX_INLINE_INSNS): Change default to 600. diff -Nrc3pad gcc-3.0.1/gcc/Makefile.in gcc-3.0.2/gcc/Makefile.in *** gcc-3.0.1/gcc/Makefile.in Wed Aug 8 19:26:11 2001 --- gcc-3.0.2/gcc/Makefile.in Thu Oct 4 15:59:02 2001 *************** fixinc.sh: $(FIXINCSRCDIR)/mkfixinc.sh $ *** 2157,2163 **** $(FIXINCSRCDIR)/server.c $(FIXINCSRCDIR)/gnu-regex.h \ $(FIXINCSRCDIR)/server.h $(FIXINCSRCDIR)/inclhack.def specs.ready (MAKE="$(MAKE)"; srcdir=`cd $(srcdir)/fixinc && pwd` ; \ ! CC="$(CC)"; CFLAGS="$(CFLAGS)"; LDFLAGS="$(LDFLAGS)"; \ WARN_CFLAGS="$(WARN_CFLAGS)"; \ export MAKE srcdir CC CFLAGS LDFLAGS WARN_CFLAGS; cd ./fixinc && \ $(SHELL) $${srcdir}/mkfixinc.sh $(build_canonical) $(target)) --- 2157,2163 ---- $(FIXINCSRCDIR)/server.c $(FIXINCSRCDIR)/gnu-regex.h \ $(FIXINCSRCDIR)/server.h $(FIXINCSRCDIR)/inclhack.def specs.ready (MAKE="$(MAKE)"; srcdir=`cd $(srcdir)/fixinc && pwd` ; \ ! CC="$(HOST_CC)"; CFLAGS="$(HOST_CFLAGS)"; LDFLAGS="$(HOST_LDFLAGS)"; \ WARN_CFLAGS="$(WARN_CFLAGS)"; \ export MAKE srcdir CC CFLAGS LDFLAGS WARN_CFLAGS; cd ./fixinc && \ $(SHELL) $${srcdir}/mkfixinc.sh $(build_canonical) $(target)) diff -Nrc3pad gcc-3.0.1/gcc/NEWS gcc-3.0.2/gcc/NEWS *** gcc-3.0.1/gcc/NEWS Sun Aug 19 17:45:13 2001 --- gcc-3.0.2/gcc/NEWS Tue Oct 23 10:56:23 2001 *************** on the line of development that led to G *** 7,26 **** ====================================================================== http://gcc.gnu.org/gcc-3.0/gcc-3.0.html ! GCC 3.0 ! June 18, 2001 The [1]GNU project and the GCC developers are pleased to announce the ! release of GCC version 3.0. GCC used to stand for the GNU C Compiler, but since the compiler supports several other languages aside from C, it now stands for the GNU Compiler Collection. ! GCC 3.0 has several new optimizations, new targets, new languages and ! many other new features. See the [2]new features page for a more ! complete list. A list of [3]successful builds is updated as new information becomes available. --- 7,30 ---- ====================================================================== http://gcc.gnu.org/gcc-3.0/gcc-3.0.html ! June 18, 2001: GCC 3.0 has been released. ! _________________________________________________________________ ! ! GCC 3.0.1 ! August 20, 2001 The [1]GNU project and the GCC developers are pleased to announce the ! release of GCC 3.0.1, which is a bug-fix release following GCC 3.0 ! released on June 18, 2001. GCC used to stand for the GNU C Compiler, but since the compiler supports several other languages aside from C, it now stands for the GNU Compiler Collection. ! GCC 3.0.x has several new optimizations, new targets, new languages ! and many other new features, relative to GCC 2.95.x. See the [2]new ! features page for a more complete list. A list of [3]successful builds is updated as new information becomes available. *************** http://gcc.gnu.org/gcc-3.0/gcc-3.0.html *** 30,36 **** [4]amazing group of volunteers is what makes GCC successful. And finally, we can't in good conscience fail to mention some ! [5]caveats to using GCC 3.0. For additional information about GCC please refer to the [6]GCC project web site or contact the [7]GCC development mailing list. --- 34,40 ---- [4]amazing group of volunteers is what makes GCC successful. And finally, we can't in good conscience fail to mention some ! [5]caveats to using GCC 3.0.x. For additional information about GCC please refer to the [6]GCC project web site or contact the [7]GCC development mailing list. *************** http://gcc.gnu.org/gcc-3.0/gcc-3.0.html *** 49,55 **** Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-08-19. References --- 53,59 ---- Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** http://gcc.gnu.org/gcc-3.0/features.html *** 133,151 **** + HPUX 11 support contributed. + Improved PowerPC code generation, including scheduled prologue and epilogue. ! + Port of gcc to Intel's IA-64 processor contributed. ! + Port of gcc to Motorola's MCore 210 and 340 contributed. + New unified back-end for Arm, Thumb and StrongArm contributed. ! + Port of gcc to Intel's XScale processor contributed. ! + Port of gcc to Atmel's AVR microcontrollers contributed. ! + Port of gcc to Mitsubishi's D30V processor contributed. ! + Port of gcc to Matsushita's AM33 processor (a member of the MN10300 processor family) contributed. ! + Port of gcc to Fujitsu's FR30 processor contributed. ! + Port of gcc to Motorola's 68HC11 and 68HC12 processors contributed. ! + Port of gcc to Sun's picoJava processor core contributed. * Documentation improvements: + Substantially rewritten and improved C preprocessor manual. + Many improvements to other documentation. --- 137,155 ---- + HPUX 11 support contributed. + Improved PowerPC code generation, including scheduled prologue and epilogue. ! + Port of GCC to Intel's IA-64 processor contributed. ! + Port of GCC to Motorola's MCore 210 and 340 contributed. + New unified back-end for Arm, Thumb and StrongArm contributed. ! + Port of GCC to Intel's XScale processor contributed. ! + Port of GCC to Atmel's AVR microcontrollers contributed. ! + Port of GCC to Mitsubishi's D30V processor contributed. ! + Port of GCC to Matsushita's AM33 processor (a member of the MN10300 processor family) contributed. ! + Port of GCC to Fujitsu's FR30 processor contributed. ! + Port of GCC to Motorola's 68HC11 and 68HC12 processors contributed. ! + Port of GCC to Sun's picoJava processor core contributed. * Documentation improvements: + Substantially rewritten and improved C preprocessor manual. + Many improvements to other documentation. *************** http://gcc.gnu.org/gcc-3.0/features.html *** 183,188 **** --- 187,200 ---- and -falign-jumps. * Plus a great many bugfixes and almost all the [12]features found in GCC 2.95. + * Additional changes in GCC 3.0.1 + + C++ fixes for incorrect code-generation. + + Improved cross-compiling support for the C++ standard + library. + + Fixes for some embedded targets that worked in GCC 2.95.3, + but not in GCC 3.0. + + Fixes for various exception-handling bugs. + + A port to the S/390 architecture. _________________________________________________________________ *************** http://gcc.gnu.org/gcc-3.0/features.html *** 195,201 **** Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-08-19. References --- 207,213 ---- Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** http://gcc.gnu.org/gcc-3.0/caveats.html *** 260,266 **** Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-08-19. References --- 272,278 ---- Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** http://gcc.gnu.org/gcc-2.95/gcc-2.95.3.h *** 353,359 **** Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-08-19. References --- 365,371 ---- Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** References *** 361,367 **** 2. http://gcc.gnu.org/gcc-2.95/regress.html 3. http://gcc.gnu.org/gcc-2.95/othertest.html 4. http://gcc.gnu.org/gcc-2.95/features.html ! 5. http://gcc.gnu.org/install/index.html 6. http://gcc.gnu.org/gcc-2.95/buildstat.html 7. http://gcc.gnu.org/thanks.html 8. http://gcc.gnu.org/gcc-2.95/caveats.html --- 373,379 ---- 2. http://gcc.gnu.org/gcc-2.95/regress.html 3. http://gcc.gnu.org/gcc-2.95/othertest.html 4. http://gcc.gnu.org/gcc-2.95/features.html ! 5. http://gcc.gnu.org/install/ 6. http://gcc.gnu.org/gcc-2.95/buildstat.html 7. http://gcc.gnu.org/thanks.html 8. http://gcc.gnu.org/gcc-2.95/caveats.html *************** http://gcc.gnu.org/gcc-2.95/gcc-2.95.2.h *** 513,519 **** Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-08-19. References --- 525,531 ---- Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** http://gcc.gnu.org/gcc-2.95/gcc-2.95.1.h *** 628,637 **** [7]caveats to using GCC 2.95.1. Download GCC 2.95.1 from the [8]GNU FTP server (ftp://ftp.gnu.org) ! Download GCC 2.95.1 from the [9]GCC/EGCS FTP server ! (ftp://go.cygnus.com) [10]Find a GNU mirror site ! [11]Find a GCC/EGCS mirror site For additional information about GCC please see the [12]GCC project web server or contact the [13]GCC development mailing list. --- 640,648 ---- [7]caveats to using GCC 2.95.1. Download GCC 2.95.1 from the [8]GNU FTP server (ftp://ftp.gnu.org) ! Download GCC 2.95.1 from the [9]GCC FTP server [10]Find a GNU mirror site ! [11]Find a GCC mirror site For additional information about GCC please see the [12]GCC project web server or contact the [13]GCC development mailing list. *************** http://gcc.gnu.org/gcc-2.95/gcc-2.95.1.h *** 647,653 **** Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-08-19. References --- 658,664 ---- Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** References *** 659,665 **** 6. http://gcc.gnu.org/thanks.html 7. http://gcc.gnu.org/gcc-2.95/caveats.html 8. ftp://ftp.gnu.org/pub/gnu/gcc/ ! 9. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html 10. http://www.gnu.org/order/ftp.html 11. http://gcc.gnu.org/mirrors.html 12. http://gcc.gnu.org/index.html --- 670,676 ---- 6. http://gcc.gnu.org/thanks.html 7. http://gcc.gnu.org/gcc-2.95/caveats.html 8. ftp://ftp.gnu.org/pub/gnu/gcc/ ! 9. ftp://gcc.gnu.org/pub/gcc/releases/index.html 10. http://www.gnu.org/order/ftp.html 11. http://gcc.gnu.org/mirrors.html 12. http://gcc.gnu.org/index.html *************** http://gcc.gnu.org/gcc-2.95/gcc-2.95.htm *** 726,732 **** Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-08-19. References --- 737,743 ---- Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** http://gcc.gnu.org/gcc-2.95/features.htm *** 770,776 **** * New Languages and Language specific improvements + [9]Many C++ improvements. + [10]Many Fortran improvements. ! + [11]Java front-end has been integrated. A [12]runtime library is available separately. + [13]ISO C99 support + [14]Chill front-end and runtime has been integrated. --- 781,787 ---- * New Languages and Language specific improvements + [9]Many C++ improvements. + [10]Many Fortran improvements. ! + [11]Java front-end has been integrated. [12]runtime library is available separately. + [13]ISO C99 support + [14]Chill front-end and runtime has been integrated. *************** http://gcc.gnu.org/gcc-2.95/features.htm *** 827,833 **** Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-08-19. References --- 838,844 ---- Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** References *** 841,847 **** 8. http://gcc.gnu.org/fom_serv/cache/24.html 9. http://gcc.gnu.org/gcc-2.95/c++features.html 10. http://gcc.gnu.org/onlinedocs/g77_news.html ! 11. http://sources.redhat.com/java/gcj-announce.txt 12. http://gcc.gnu.org/news/javaannounce.html 13. http://gcc.gnu.org/c99status.html 14. http://gcc.gnu.org/news/chill.html --- 852,858 ---- 8. http://gcc.gnu.org/fom_serv/cache/24.html 9. http://gcc.gnu.org/gcc-2.95/c++features.html 10. http://gcc.gnu.org/onlinedocs/g77_news.html ! 11. http://gcc.gnu.org/java/gcj-announce.txt 12. http://gcc.gnu.org/news/javaannounce.html 13. http://gcc.gnu.org/c99status.html 14. http://gcc.gnu.org/news/chill.html *************** http://gcc.gnu.org/gcc-2.95/caveats.html *** 909,915 **** Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-08-19. References --- 920,926 ---- Suite 330, Boston, MA 02111, USA. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** http://gcc.gnu.org/egcs-1.1/egcs-1.1.2.h *** 1045,1060 **** group of volunteers is what makes EGCS successful. And finally, we can't in good conscience fail to mention some ! [5]caveats to using EGCS 1.1.2. [6]Download EGCS 1.1.2 from ! egcs.cygnus.com (USA California) --> ! [7]Download EGCS 1.1.2 from go.cygnus.com (USA California - High speed ! link provided by Stanford) ! The EGCS 1.1.2 release is also available on many [8]mirror sites. _________________________________________________________________ ! Last modified on July 28, 1999. References --- 1056,1080 ---- group of volunteers is what makes EGCS successful. And finally, we can't in good conscience fail to mention some ! [5]caveats to using EGCS 1.1.2. ! Download EGCS from egcs.cygnus.com (USA California) ! . ! The EGCS 1.1.2 release is also available on many [6]mirror sites. _________________________________________________________________ ! ! Please send FSF & GNU inquiries & questions to [7]gnu@gnu.org. There ! are also [8]other ways to contact the FSF. ! These pages are maintained by [9]The GCC team. ! Please send comments on these web pages and GCC to ! [10]gcc@gcc.gnu.org, send other questions to [11]gnu@gnu.org. ! Copyright (C) Free Software Foundation, Inc., 59 Temple Place - ! Suite 330, Boston, MA 02111, USA. ! Verbatim copying and distribution of this entire article is ! permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** References *** 1063,1071 **** 3. http://gcc.gnu.org/egcs-1.1/buildstat.html 4. http://gcc.gnu.org/thanks.html 5. http://gcc.gnu.org/egcs-1.1/caveats.html ! 6. ftp://egcs.cygnus.com/pub/egcs/releases/index.html ! 7. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html ! 8. http://gcc.gnu.org/mirrors.html ====================================================================== http://gcc.gnu.org/egcs-1.1/egcs-1.1.1.html --- 1083,1094 ---- 3. http://gcc.gnu.org/egcs-1.1/buildstat.html 4. http://gcc.gnu.org/thanks.html 5. http://gcc.gnu.org/egcs-1.1/caveats.html ! 6. http://gcc.gnu.org/mirrors.html ! 7. mailto:gnu@gnu.org ! 8. http://www.gnu.org/home.html#ContactInfo ! 9. http://gcc.gnu.org/about.html ! 10. mailto:gcc@gcc.gnu.org ! 11. mailto:gnu@gnu.org ====================================================================== http://gcc.gnu.org/egcs-1.1/egcs-1.1.1.html *************** http://gcc.gnu.org/egcs-1.1/egcs-1.1.1.h *** 1162,1174 **** And finally, we can't in good conscience fail to mention some [5]caveats to using EGCS 1.1.1. ! [6]Download EGCS 1.1.1 from egcs.cygnus.com (USA California) The EGCS 1.1.1 release is also available on many mirror sites. ! [7]Goto mirror list to find a closer site _________________________________________________________________ ! Last modified on July 28, 1999. References --- 1185,1208 ---- And finally, we can't in good conscience fail to mention some [5]caveats to using EGCS 1.1.1. ! Download EGCS from egcs.cygnus.com (USA California) ! . The EGCS 1.1.1 release is also available on many mirror sites. ! [6]Goto mirror list to find a closer site _________________________________________________________________ ! ! Please send FSF & GNU inquiries & questions to [7]gnu@gnu.org. There ! are also [8]other ways to contact the FSF. ! These pages are maintained by [9]The GCC team. ! Please send comments on these web pages and GCC to ! [10]gcc@gcc.gnu.org, send other questions to [11]gnu@gnu.org. ! Copyright (C) Free Software Foundation, Inc., 59 Temple Place - ! Suite 330, Boston, MA 02111, USA. ! Verbatim copying and distribution of this entire article is ! permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** References *** 1177,1184 **** 3. http://gcc.gnu.org/egcs-1.1/buildstat.html 4. http://gcc.gnu.org/thanks.html 5. http://gcc.gnu.org/egcs-1.1/caveats.html ! 6. ftp://egcs.cygnus.com/pub/egcs/releases/index.html ! 7. http://gcc.gnu.org/mirrors.html ====================================================================== http://gcc.gnu.org/egcs-1.1/egcs-1.1.html --- 1211,1222 ---- 3. http://gcc.gnu.org/egcs-1.1/buildstat.html 4. http://gcc.gnu.org/thanks.html 5. http://gcc.gnu.org/egcs-1.1/caveats.html ! 6. http://gcc.gnu.org/mirrors.html ! 7. mailto:gnu@gnu.org ! 8. http://www.gnu.org/home.html#ContactInfo ! 9. http://gcc.gnu.org/about.html ! 10. mailto:gcc@gcc.gnu.org ! 11. mailto:gnu@gnu.org ====================================================================== http://gcc.gnu.org/egcs-1.1/egcs-1.1.html *************** http://gcc.gnu.org/egcs-1.1/egcs-1.1.htm *** 1210,1244 **** * Fixes for the /tmp symlink race security problems. * New targets including mips16, arm-thumb and 64 bit PowerPC. * Improvements to GNU Fortran (g77) compiler and runtime library ! made since [5]g77 version 0.5.23. ! See the [6]new features page for a more complete list of new features found in EGCS 1.1 releases. The EGCS 1.1 release includes installation instructions in both HTML and plaintext forms (see the INSTALL directory in the toplevel directory of the EGCS 1.1 distribution). However, we also keep the ! most up to date [7]installation instructions and [8]build/test status on our web page. We will update those pages as new information becomes available. The EGCS project would like to thank the numerous people that have ! contributed new features, test results, bugfixes, etc. This [9]amazing group of volunteers is what makes EGCS successful. And finally, we can't in good conscience fail to mention some ! [10]caveats to using EGCS 1.1. ! ! [11]Download EGCS 1.1 from egcs.cygnus.com (USA California) ! [12]Download EGCS 1.1 from go.cygnus.com (USA California -- High speed ! link provided by Stanford) The EGCS 1.1 release is also available on many mirror sites. ! [13]Goto mirror list to find a closer site _________________________________________________________________ ! Last modified on September 4, 1999. References --- 1248,1290 ---- * Fixes for the /tmp symlink race security problems. * New targets including mips16, arm-thumb and 64 bit PowerPC. * Improvements to GNU Fortran (g77) compiler and runtime library ! made since g77 version 0.5.23. ! See the [5]new features page for a more complete list of new features found in EGCS 1.1 releases. The EGCS 1.1 release includes installation instructions in both HTML and plaintext forms (see the INSTALL directory in the toplevel directory of the EGCS 1.1 distribution). However, we also keep the ! most up to date [6]installation instructions and [7]build/test status on our web page. We will update those pages as new information becomes available. The EGCS project would like to thank the numerous people that have ! contributed new features, test results, bugfixes, etc. This [8]amazing group of volunteers is what makes EGCS successful. And finally, we can't in good conscience fail to mention some ! [9]caveats to using EGCS 1.1. ! Download EGCS from egcs.cygnus.com (USA California) ! . The EGCS 1.1 release is also available on many mirror sites. ! [10]Goto mirror list to find a closer site _________________________________________________________________ ! ! Please send FSF & GNU inquiries & questions to [11]gnu@gnu.org. ! There are also [12]other ways to contact the FSF. ! These pages are maintained by [13]The GCC team. ! Please send comments on these web pages and GCC to ! [14]gcc@gcc.gnu.org, send other questions to [15]gnu@gnu.org. ! Copyright (C) Free Software Foundation, Inc., 59 Temple Place - ! Suite 330, Boston, MA 02111, USA. ! Verbatim copying and distribution of this entire article is ! permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** References *** 1246,1260 **** 2. http://gcc.gnu.org/news/gcse.html 3. http://gcc.gnu.org/news/alias.html 4. http://gcc.gnu.org/egcs-1.1/c++features.html ! 5. http://gcc.gnu.org/onlinedocs/g77_news.html ! 6. http://gcc.gnu.org/egcs-1.1/features.html ! 7. http://gcc.gnu.org/install/index.html ! 8. http://gcc.gnu.org/egcs-1.1/buildstat.html ! 9. http://gcc.gnu.org/thanks.html ! 10. http://gcc.gnu.org/egcs-1.1/caveats.html ! 11. ftp://egcs.cygnus.com/pub/egcs/releases/index.html ! 12. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html ! 13. http://gcc.gnu.org/mirrors.html ====================================================================== http://gcc.gnu.org/egcs-1.1/features.html --- 1292,1308 ---- 2. http://gcc.gnu.org/news/gcse.html 3. http://gcc.gnu.org/news/alias.html 4. http://gcc.gnu.org/egcs-1.1/c++features.html ! 5. http://gcc.gnu.org/egcs-1.1/features.html ! 6. http://gcc.gnu.org/install/index.html ! 7. http://gcc.gnu.org/egcs-1.1/buildstat.html ! 8. http://gcc.gnu.org/thanks.html ! 9. http://gcc.gnu.org/egcs-1.1/caveats.html ! 10. http://gcc.gnu.org/mirrors.html ! 11. mailto:gnu@gnu.org ! 12. http://www.gnu.org/home.html#ContactInfo ! 13. http://gcc.gnu.org/about.html ! 14. mailto:gcc@gcc.gnu.org ! 15. mailto:gnu@gnu.org ====================================================================== http://gcc.gnu.org/egcs-1.1/features.html *************** http://gcc.gnu.org/egcs-1.1/features.htm *** 1323,1332 **** + M68k has many micro-optimizations and Coldfire fixes. * Core compiler is based on the GCC development tree from June 9, 1998, so we have all of the [5]features found in GCC 2.8. ! ! [6]Return to the EGCS home page ! Last modified: September 4, 1999 References --- 1371,1389 ---- + M68k has many micro-optimizations and Coldfire fixes. * Core compiler is based on the GCC development tree from June 9, 1998, so we have all of the [5]features found in GCC 2.8. ! _________________________________________________________________ ! ! Please send FSF & GNU inquiries & questions to [6]gnu@gnu.org. There ! are also [7]other ways to contact the FSF. ! These pages are maintained by [8]The GCC team. ! Please send comments on these web pages and GCC to ! [9]gcc@gcc.gnu.org, send other questions to [10]gnu@gnu.org. ! Copyright (C) Free Software Foundation, Inc., 59 Temple Place - ! Suite 330, Boston, MA 02111, USA. ! Verbatim copying and distribution of this entire article is ! permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** References *** 1335,1341 **** 3. http://gcc.gnu.org/news/gcse.html 4. http://gcc.gnu.org/news/alias.html 5. http://gcc.gnu.org/egcs-1.0/features-2.8.html ! 6. http://gcc.gnu.org/index.html ====================================================================== http://gcc.gnu.org/egcs-1.1/caveats.html --- 1392,1402 ---- 3. http://gcc.gnu.org/news/gcse.html 4. http://gcc.gnu.org/news/alias.html 5. http://gcc.gnu.org/egcs-1.0/features-2.8.html ! 6. mailto:gnu@gnu.org ! 7. http://www.gnu.org/home.html#ContactInfo ! 8. http://gcc.gnu.org/about.html ! 9. mailto:gcc@gcc.gnu.org ! 10. mailto:gnu@gnu.org ====================================================================== http://gcc.gnu.org/egcs-1.1/caveats.html *************** http://gcc.gnu.org/egcs-1.1/caveats.html *** 1343,1350 **** * EGCS has an integrated libstdc++, but does not have an integrated libg++. Furthermore old libg++ releases will not work with EGCS; ! HJ Lu has made a [1]libg++ snapshot available which may work with ! EGCS. Note most C++ programs only need libstdc++. * Exception handling may not work with shared libraries, particularly on alphas, hppas, rs6000/powerpc and mips based --- 1404,1411 ---- * EGCS has an integrated libstdc++, but does not have an integrated libg++. Furthermore old libg++ releases will not work with EGCS; ! HJ Lu has made a libg++-2.8.1.2 snapshot available which may work ! with EGCS. Note most C++ programs only need libstdc++. * Exception handling may not work with shared libraries, particularly on alphas, hppas, rs6000/powerpc and mips based *************** http://gcc.gnu.org/egcs-1.1/caveats.html *** 1352,1358 **** platforms with shared libraries. * Some versions of the Linux kernel have bugs which prevent them from being compiled or from running when compiled by EGCS. See ! [2]the FAQ for additional information. * In general, EGCS is more rigorous about rejecting invalid C++ code or deprecated C++ constructs than g++-2.7, g++-2.8 or EGCS 1.0. As a result it may be necessary to fix C++ code before it will --- 1413,1419 ---- platforms with shared libraries. * Some versions of the Linux kernel have bugs which prevent them from being compiled or from running when compiled by EGCS. See ! [1]the FAQ for additional information. * In general, EGCS is more rigorous about rejecting invalid C++ code or deprecated C++ constructs than g++-2.7, g++-2.8 or EGCS 1.0. As a result it may be necessary to fix C++ code before it will *************** http://gcc.gnu.org/egcs-1.1/caveats.html *** 1363,1378 **** * EGCS 1.1 compiled C++ code is not binary compatible with EGCS 1.0.x or GCC 2.8.x due to changes necessary to support thread safe exception handling. ! ! [3]Return to the GCC home page ! Last modified: July 28, 1999 References ! 1. ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1.2.tar.gz ! 2. http://gcc.gnu.org/fom_serv/cache/24.html ! 3. http://gcc.gnu.org/index.html ====================================================================== http://gcc.gnu.org/egcs-1.0/egcs-1.0.3.html --- 1424,1451 ---- * EGCS 1.1 compiled C++ code is not binary compatible with EGCS 1.0.x or GCC 2.8.x due to changes necessary to support thread safe exception handling. ! _________________________________________________________________ ! ! Please send FSF & GNU inquiries & questions to [2]gnu@gnu.org. There ! are also [3]other ways to contact the FSF. ! These pages are maintained by [4]The GCC team. ! Please send comments on these web pages and GCC to ! [5]gcc@gcc.gnu.org, send other questions to [6]gnu@gnu.org. ! Copyright (C) Free Software Foundation, Inc., 59 Temple Place - ! Suite 330, Boston, MA 02111, USA. ! Verbatim copying and distribution of this entire article is ! permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References ! 1. http://gcc.gnu.org/fom_serv/cache/24.html ! 2. mailto:gnu@gnu.org ! 3. http://www.gnu.org/home.html#ContactInfo ! 4. http://gcc.gnu.org/about.html ! 5. mailto:gcc@gcc.gnu.org ! 6. mailto:gnu@gnu.org ====================================================================== http://gcc.gnu.org/egcs-1.0/egcs-1.0.3.html *************** http://gcc.gnu.org/egcs-1.0/egcs-1.0.3.h *** 1439,1458 **** Update: Big thanks to Stanford for providing a high speed link for downloading EGCS (go.cygnus.com)! ! [6]Download EGCS 1.0.3 from ftp.cygnus.com (USA California) ! ! [7]Download EGCS 1.0.3 from go.cygnus.com (USA California -- High ! speed link provided by Stanford) The EGCS 1.0.3 release is also available on many mirror sites. ! [8]Goto mirror list to find a closer site We'd like to thank the numerous people that have contributed new features, test results, bugfixes, etc. Unfortunately, they're far too numerous to mention by name. _________________________________________________________________ ! Last modified on February 22, 1999. References --- 1512,1539 ---- Update: Big thanks to Stanford for providing a high speed link for downloading EGCS (go.cygnus.com)! ! Download EGCS from ftp.cygnus.com (USA California) or go.cygnus.com ! (USA California -- High speed link provided by Stanford). The EGCS 1.0.3 release is also available on many mirror sites. ! [6]Goto mirror list to find a closer site We'd like to thank the numerous people that have contributed new features, test results, bugfixes, etc. Unfortunately, they're far too numerous to mention by name. _________________________________________________________________ ! ! Please send FSF & GNU inquiries & questions to [7]gnu@gnu.org. There ! are also [8]other ways to contact the FSF. ! These pages are maintained by [9]The GCC team. ! Please send comments on these web pages and GCC to ! [10]gcc@gcc.gnu.org, send other questions to [11]gnu@gnu.org. ! Copyright (C) Free Software Foundation, Inc., 59 Temple Place - ! Suite 330, Boston, MA 02111, USA. ! Verbatim copying and distribution of this entire article is ! permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** References *** 1461,1469 **** 3. http://gcc.gnu.org/install/index.html 4. http://gcc.gnu.org/egcs-1.0/buildstat.html 5. http://gcc.gnu.org/egcs-1.0/caveats.html ! 6. ftp://egcs.cygnus.com/pub/egcs/releases/index.html ! 7. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html ! 8. http://gcc.gnu.org/mirrors.html ====================================================================== http://gcc.gnu.org/egcs-1.0/egcs-1.0.2.html --- 1542,1553 ---- 3. http://gcc.gnu.org/install/index.html 4. http://gcc.gnu.org/egcs-1.0/buildstat.html 5. http://gcc.gnu.org/egcs-1.0/caveats.html ! 6. http://gcc.gnu.org/mirrors.html ! 7. mailto:gnu@gnu.org ! 8. http://www.gnu.org/home.html#ContactInfo ! 9. http://gcc.gnu.org/about.html ! 10. mailto:gcc@gcc.gnu.org ! 11. mailto:gnu@gnu.org ====================================================================== http://gcc.gnu.org/egcs-1.0/egcs-1.0.2.html *************** http://gcc.gnu.org/egcs-1.0/egcs-1.0.2.h *** 1561,1580 **** Update: Big thanks to Stanford for providing a high speed link for downloading EGCS (go.cygnus.com)! ! [6]Download EGCS 1.0.2 from ftp.cygnus.com (USA California) ! ! [7]Download EGCS 1.0.2 from go.cygnus.com (USA California -- High ! speed link provided by Stanford) The EGCS 1.0.2 release is also available on many mirror sites. ! [8]Goto mirror list to find a closer site We'd like to thank the numerous people that have contributed new features, test results, bugfixes, etc. Unfortunately, they're far too numerous to mention by name. _________________________________________________________________ ! Last modified on July 28, 1999. References --- 1645,1672 ---- Update: Big thanks to Stanford for providing a high speed link for downloading EGCS (go.cygnus.com)! ! Download EGCS from ftp.cygnus.com (USA California) or go.cygnus.com ! (USA California -- High speed link provided by Stanford). The EGCS 1.0.2 release is also available on many mirror sites. ! [6]Goto mirror list to find a closer site We'd like to thank the numerous people that have contributed new features, test results, bugfixes, etc. Unfortunately, they're far too numerous to mention by name. _________________________________________________________________ ! ! Please send FSF & GNU inquiries & questions to [7]gnu@gnu.org. There ! are also [8]other ways to contact the FSF. ! These pages are maintained by [9]The GCC team. ! Please send comments on these web pages and GCC to ! [10]gcc@gcc.gnu.org, send other questions to [11]gnu@gnu.org. ! Copyright (C) Free Software Foundation, Inc., 59 Temple Place - ! Suite 330, Boston, MA 02111, USA. ! Verbatim copying and distribution of this entire article is ! permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** References *** 1583,1591 **** 3. http://gcc.gnu.org/install/index.html 4. http://gcc.gnu.org/egcs-1.0/buildstat.html 5. http://gcc.gnu.org/egcs-1.0/caveats.html ! 6. ftp://egcs.cygnus.com/pub/egcs/releases/index.html ! 7. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html ! 8. http://gcc.gnu.org/mirrors.html ====================================================================== http://gcc.gnu.org/egcs-1.0/egcs-1.0.1.html --- 1675,1686 ---- 3. http://gcc.gnu.org/install/index.html 4. http://gcc.gnu.org/egcs-1.0/buildstat.html 5. http://gcc.gnu.org/egcs-1.0/caveats.html ! 6. http://gcc.gnu.org/mirrors.html ! 7. mailto:gnu@gnu.org ! 8. http://www.gnu.org/home.html#ContactInfo ! 9. http://gcc.gnu.org/about.html ! 10. mailto:gcc@gcc.gnu.org ! 11. mailto:gnu@gnu.org ====================================================================== http://gcc.gnu.org/egcs-1.0/egcs-1.0.1.html *************** http://gcc.gnu.org/egcs-1.0/egcs-1.0.1.h *** 1683,1702 **** Update: Big thanks to Stanford for providing a high speed link for downloading EGCS (go.cygnus.com)! ! [6]Download EGCS 1.0.1 from ftp.cygnus.com (USA California) ! ! [7]Download EGCS 1.0.1 from go.cygnus.com (USA California -- High ! speed link provided by Stanford) The EGCS 1.0.1 release is also available on many mirror sites. ! [8]Goto mirror list to find a closer site We'd like to thank the numerous people that have contributed new features, test results, bugfixes, etc. Unfortunately, they're far too numerous to mention by name. _________________________________________________________________ ! Last modified on July 28, 1999. References --- 1778,1805 ---- Update: Big thanks to Stanford for providing a high speed link for downloading EGCS (go.cygnus.com)! ! Download EGCS from ftp.cygnus.com (USA California) or go.cygnus.com ! (USA California -- High speed link provided by Stanford). The EGCS 1.0.1 release is also available on many mirror sites. ! [6]Goto mirror list to find a closer site We'd like to thank the numerous people that have contributed new features, test results, bugfixes, etc. Unfortunately, they're far too numerous to mention by name. _________________________________________________________________ ! ! Please send FSF & GNU inquiries & questions to [7]gnu@gnu.org. There ! are also [8]other ways to contact the FSF. ! These pages are maintained by [9]The GCC team. ! Please send comments on these web pages and GCC to ! [10]gcc@gcc.gnu.org, send other questions to [11]gnu@gnu.org. ! Copyright (C) Free Software Foundation, Inc., 59 Temple Place - ! Suite 330, Boston, MA 02111, USA. ! Verbatim copying and distribution of this entire article is ! permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** References *** 1705,1713 **** 3. http://gcc.gnu.org/install/index.html 4. http://gcc.gnu.org/egcs-1.0/buildstat.html 5. http://gcc.gnu.org/egcs-1.0/caveats.html ! 6. ftp://egcs.cygnus.com/pub/egcs/releases/index.html ! 7. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html ! 8. http://gcc.gnu.org/mirrors.html ====================================================================== http://gcc.gnu.org/egcs-1.0/egcs-1.0.html --- 1808,1819 ---- 3. http://gcc.gnu.org/install/index.html 4. http://gcc.gnu.org/egcs-1.0/buildstat.html 5. http://gcc.gnu.org/egcs-1.0/caveats.html ! 6. http://gcc.gnu.org/mirrors.html ! 7. mailto:gnu@gnu.org ! 8. http://www.gnu.org/home.html#ContactInfo ! 9. http://gcc.gnu.org/about.html ! 10. mailto:gcc@gcc.gnu.org ! 11. mailto:gnu@gnu.org ====================================================================== http://gcc.gnu.org/egcs-1.0/egcs-1.0.html *************** http://gcc.gnu.org/egcs-1.0/egcs-1.0.htm *** 1760,1781 **** world. Update: Big thanks to Stanford for providing a high speed link for ! downloading EGCS! (go.cygnus.com) ! ! [6]Download EGCS 1.0 from ftp.cygnus.com (USA California) ! [7]Download EGCS 1.0 from go.cygnus.com (USA California -- High speed ! link provided by Stanford) The EGCS 1.0 release should be available on most mirror sites by now. ! [8]Goto mirror list to find a closer site We'd like to thank the numerous people that have contributed new features, test results, bugfixes, etc. Unfortunately, they're far too numerous to mention by name. _________________________________________________________________ ! Last modified on July 28, 1999. References --- 1866,1895 ---- world. Update: Big thanks to Stanford for providing a high speed link for ! downloading EGCS (go.cygnus.com)! ! Download EGCS from ftp.cygnus.com (USA California) or go.cygnus.com ! (USA California -- High speed link provided by Stanford). The EGCS 1.0 release should be available on most mirror sites by now. ! [6]Goto mirror list to find a closer site We'd like to thank the numerous people that have contributed new features, test results, bugfixes, etc. Unfortunately, they're far too numerous to mention by name. _________________________________________________________________ ! ! Please send FSF & GNU inquiries & questions to [7]gnu@gnu.org. There ! are also [8]other ways to contact the FSF. ! These pages are maintained by [9]The GCC team. ! Please send comments on these web pages and GCC to ! [10]gcc@gcc.gnu.org, send other questions to [11]gnu@gnu.org. ! Copyright (C) Free Software Foundation, Inc., 59 Temple Place - ! Suite 330, Boston, MA 02111, USA. ! Verbatim copying and distribution of this entire article is ! permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References *************** References *** 1784,1792 **** 3. http://gcc.gnu.org/install/index.html 4. http://gcc.gnu.org/egcs-1.0/buildstat.html 5. http://gcc.gnu.org/egcs-1.0/caveats.html ! 6. ftp://egcs.cygnus.com/pub/egcs/releases/index.html ! 7. ftp://go.cygnus.com/pub/sourceware.cygnus.com/pub/egcs/releases/index.html ! 8. http://gcc.gnu.org/mirrors.html ====================================================================== http://gcc.gnu.org/egcs-1.0/features.html --- 1898,1909 ---- 3. http://gcc.gnu.org/install/index.html 4. http://gcc.gnu.org/egcs-1.0/buildstat.html 5. http://gcc.gnu.org/egcs-1.0/caveats.html ! 6. http://gcc.gnu.org/mirrors.html ! 7. mailto:gnu@gnu.org ! 8. http://www.gnu.org/home.html#ContactInfo ! 9. http://gcc.gnu.org/about.html ! 10. mailto:gcc@gcc.gnu.org ! 11. mailto:gnu@gnu.org ====================================================================== http://gcc.gnu.org/egcs-1.0/features.html *************** http://gcc.gnu.org/egcs-1.0/features.htm *** 1827,1842 **** new template code makes repo obsolete for ELF systems using gnu-ld such as Linux. * Plus the usual assortment of bugfixes and improvements. ! ! [3]Return to the egcs home page ! Last modified: July 28, 1999 References 1. http://gcc.gnu.org/egcs-1.0/features-2.8.html 2. http://gcc.gnu.org/egcs-1.0/c++features.html ! 3. http://gcc.gnu.org/index.html ====================================================================== http://gcc.gnu.org/egcs-1.0/caveats.html --- 1944,1972 ---- new template code makes repo obsolete for ELF systems using gnu-ld such as Linux. * Plus the usual assortment of bugfixes and improvements. ! _________________________________________________________________ ! ! Please send FSF & GNU inquiries & questions to [3]gnu@gnu.org. There ! are also [4]other ways to contact the FSF. ! These pages are maintained by [5]The GCC team. ! Please send comments on these web pages and GCC to ! [6]gcc@gcc.gnu.org, send other questions to [7]gnu@gnu.org. ! Copyright (C) Free Software Foundation, Inc., 59 Temple Place - ! Suite 330, Boston, MA 02111, USA. ! Verbatim copying and distribution of this entire article is ! permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References 1. http://gcc.gnu.org/egcs-1.0/features-2.8.html 2. http://gcc.gnu.org/egcs-1.0/c++features.html ! 3. mailto:gnu@gnu.org ! 4. http://www.gnu.org/home.html#ContactInfo ! 5. http://gcc.gnu.org/about.html ! 6. mailto:gcc@gcc.gnu.org ! 7. mailto:gnu@gnu.org ====================================================================== http://gcc.gnu.org/egcs-1.0/caveats.html *************** http://gcc.gnu.org/egcs-1.0/caveats.html *** 1844,1851 **** * EGCS has an integrated libstdc++, but does not have an integrated libg++. Furthermore old libg++ releases will not work with egc; HJ ! Lu has made a [1]libg++ snapshot available which may work with ! EGCS. Note most C++ programs only need libstdc++. * Note that using -pedantic or -Wreturn-type can cause an explosion in the amount of memory needed for template-heavy C++ code, such --- 1974,1980 ---- * EGCS has an integrated libstdc++, but does not have an integrated libg++. Furthermore old libg++ releases will not work with egc; HJ ! Lu has made a libg++-2.8.1.2 available which may work with EGCS. Note most C++ programs only need libstdc++. * Note that using -pedantic or -Wreturn-type can cause an explosion in the amount of memory needed for template-heavy C++ code, such *************** http://gcc.gnu.org/egcs-1.0/caveats.html *** 1858,1864 **** libraries. * Some versions of the Linux kernel have bugs which prevent them from being compiled or from running when compiled by EGCS. See ! [2]the FAQ for additional information. * In general, EGCS is more rigorous about rejecting invalid C++ code or deprecated C++ constructs than G++ 2.7. As a result it may be necessary to fix C++ code before it will compile with EGCS. --- 1987,1993 ---- libraries. * Some versions of the Linux kernel have bugs which prevent them from being compiled or from running when compiled by EGCS. See ! [1]the FAQ for additional information. * In general, EGCS is more rigorous about rejecting invalid C++ code or deprecated C++ constructs than G++ 2.7. As a result it may be necessary to fix C++ code before it will compile with EGCS. *************** http://gcc.gnu.org/egcs-1.0/caveats.html *** 1867,1880 **** compilers and older versions of G++) may no longer be accepted. * EGCS 1.0 may not work with Red Hat Linux 5.0 on all targets. EGCS 1.0.x and later releases should work with Red Hat Linux 5.0. ! ! [3]Return to the GCC home page ! Last modified: August 27, 1998 References ! 1. ftp://ftp.yggdrasil.com/private/hjl/libg++-2.8.1.2.tar.gz ! 2. http://gcc.gnu.org/fom_serv/cache/24.html ! 3. http://gcc.gnu.org/index.html ====================================================================== --- 1996,2021 ---- compilers and older versions of G++) may no longer be accepted. * EGCS 1.0 may not work with Red Hat Linux 5.0 on all targets. EGCS 1.0.x and later releases should work with Red Hat Linux 5.0. ! _________________________________________________________________ ! ! Please send FSF & GNU inquiries & questions to [2]gnu@gnu.org. There ! are also [3]other ways to contact the FSF. ! These pages are maintained by [4]The GCC team. ! Please send comments on these web pages and GCC to ! [5]gcc@gcc.gnu.org, send other questions to [6]gnu@gnu.org. ! Copyright (C) Free Software Foundation, Inc., 59 Temple Place - ! Suite 330, Boston, MA 02111, USA. ! Verbatim copying and distribution of this entire article is ! permitted in any medium, provided this notice is preserved. ! Last modified 2001-10-18. References ! 1. http://gcc.gnu.org/fom_serv/cache/24.html ! 2. mailto:gnu@gnu.org ! 3. http://www.gnu.org/home.html#ContactInfo ! 4. http://gcc.gnu.org/about.html ! 5. mailto:gcc@gcc.gnu.org ! 6. mailto:gnu@gnu.org ====================================================================== diff -Nrc3pad gcc-3.0.1/gcc/alias.c gcc-3.0.2/gcc/alias.c *** gcc-3.0.1/gcc/alias.c Sat May 12 13:32:21 2001 --- gcc-3.0.2/gcc/alias.c Tue Sep 11 14:39:24 2001 *************** record_base_value (regno, val, invariant *** 937,942 **** --- 937,957 ---- reg_base_value[regno] = find_base_value (val); } + /* Clear alias info for a register. This is used if an RTL transformation + changes the value of a register. This is used in flow by AUTO_INC_DEC + optimizations. We don't need to clear reg_base_value, since flow only + changes the offset. */ + + void + clear_reg_alias_info (reg) + rtx reg; + { + unsigned int regno = REGNO (reg); + + if (regno < reg_known_value_size && regno >= FIRST_PSEUDO_REGISTER) + reg_known_value[regno] = reg; + } + /* Returns a canonical version of X, from the point of view alias analysis. (For example, if X is a MEM whose address is a register, and the register has a known value (say a SYMBOL_REF), then a MEM diff -Nrc3pad gcc-3.0.1/gcc/c-parse.c gcc-3.0.2/gcc/c-parse.c *** gcc-3.0.1/gcc/c-parse.c Sun Aug 19 17:53:44 2001 --- gcc-3.0.2/gcc/c-parse.c Tue Oct 23 10:57:23 2001 *************** *** 1,7 **** /* A Bison parser, made from c-parse.y ! by GNU Bison version 1.27 ! */ #define YYBISON 1 /* Identify Bison output. */ --- 1,6 ---- /* A Bison parser, made from c-parse.y ! by GNU Bison version 1.28 */ #define YYBISON 1 /* Identify Bison output. */ *************** static const short yycheck[] = { 38, *** 1315,1321 **** }; /* -*-C-*- Note some compilers choke on comments on `#line' lines. */ #line 3 "/usr/lib/bison.simple" ! /* This file comes from bison-1.27. */ /* Skeleton output parser for bison, Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. --- 1314,1320 ---- }; /* -*-C-*- Note some compilers choke on comments on `#line' lines. */ #line 3 "/usr/lib/bison.simple" ! /* This file comes from bison-1.28. */ /* Skeleton output parser for bison, Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. *************** __yy_memcpy (char *to, char *from, unsig *** 1528,1534 **** #endif #endif ! #line 216 "/usr/lib/bison.simple" /* The user can define YYPARSE_PARAM as the name of an argument to be passed into yyparse. The argument should have type void *. --- 1527,1533 ---- #endif #endif ! #line 217 "/usr/lib/bison.simple" /* The user can define YYPARSE_PARAM as the name of an argument to be passed into yyparse. The argument should have type void *. *************** case 425: *** 3730,3736 **** break;} } /* the action file gets copied in in place of this dollarsign */ ! #line 542 "/usr/lib/bison.simple" yyvsp -= yylen; yyssp -= yylen; --- 3729,3735 ---- break;} } /* the action file gets copied in in place of this dollarsign */ ! #line 543 "/usr/lib/bison.simple" yyvsp -= yylen; yyssp -= yylen; diff -Nrc3pad gcc-3.0.1/gcc/c-typeck.c gcc-3.0.2/gcc/c-typeck.c *** gcc-3.0.1/gcc/c-typeck.c Tue Jun 12 05:19:55 2001 --- gcc-3.0.2/gcc/c-typeck.c Mon Sep 17 12:56:35 2001 *************** comptypes (type1, type2) *** 508,513 **** --- 508,515 ---- { tree d1 = TYPE_DOMAIN (t1); tree d2 = TYPE_DOMAIN (t2); + bool d1_variable, d2_variable; + bool d1_zero, d2_zero; val = 1; /* Target types must match incl. qualifiers. */ *************** comptypes (type1, type2) *** 516,529 **** return 0; /* Sizes must match unless one is missing or variable. */ ! if (d1 == 0 || d2 == 0 || d1 == d2 ! || TREE_CODE (TYPE_MIN_VALUE (d1)) != INTEGER_CST ! || TREE_CODE (TYPE_MIN_VALUE (d2)) != INTEGER_CST ! || TREE_CODE (TYPE_MAX_VALUE (d1)) != INTEGER_CST ! || TREE_CODE (TYPE_MAX_VALUE (d2)) != INTEGER_CST) break; ! if (! tree_int_cst_equal (TYPE_MIN_VALUE (d1), TYPE_MIN_VALUE (d2)) || ! tree_int_cst_equal (TYPE_MAX_VALUE (d1), TYPE_MAX_VALUE (d2))) val = 0; --- 518,542 ---- return 0; /* Sizes must match unless one is missing or variable. */ ! if (d1 == 0 || d2 == 0 || d1 == d2) break; ! d1_zero = ! TYPE_MAX_VALUE (d1); ! d2_zero = ! TYPE_MAX_VALUE (d2); ! ! d1_variable = (! d1_zero ! && (TREE_CODE (TYPE_MIN_VALUE (d1)) != INTEGER_CST ! || TREE_CODE (TYPE_MAX_VALUE (d1)) != INTEGER_CST)); ! d2_variable = (! d2_zero ! && (TREE_CODE (TYPE_MIN_VALUE (d2)) != INTEGER_CST ! || TREE_CODE (TYPE_MAX_VALUE (d2)) != INTEGER_CST)); ! ! if (d1_variable || d2_variable) ! break; ! if (d1_zero && d2_zero) ! break; ! if (d1_zero || d2_zero ! || ! tree_int_cst_equal (TYPE_MIN_VALUE (d1), TYPE_MIN_VALUE (d2)) || ! tree_int_cst_equal (TYPE_MAX_VALUE (d1), TYPE_MAX_VALUE (d2))) val = 0; diff -Nrc3pad gcc-3.0.1/gcc/config/arm/lib1funcs.asm gcc-3.0.2/gcc/config/arm/lib1funcs.asm *** gcc-3.0.1/gcc/config/arm/lib1funcs.asm Mon Dec 4 15:05:17 2000 --- gcc-3.0.2/gcc/config/arm/lib1funcs.asm Tue Sep 18 03:09:55 2001 *************** Lover12: *** 630,639 **** #ifdef L_dvmd_lnx @ GNU/Linux division-by zero handler. Used in place of L_dvmd_tls ! #include ! ! #define SIGFPE 8 @ cant use as it ! @ contains too much C rubbish FUNC_START div0 stmfd sp!, {r1, lr} --- 630,641 ---- #ifdef L_dvmd_lnx @ GNU/Linux division-by zero handler. Used in place of L_dvmd_tls ! /* Constants taken from and */ ! #define SIGFPE 8 ! #define __NR_SYSCALL_BASE 0x900000 ! #define __NR_getpid (__NR_SYSCALL_BASE+ 20) ! #define __NR_kill (__NR_SYSCALL_BASE+ 37) ! FUNC_START div0 stmfd sp!, {r1, lr} diff -Nrc3pad gcc-3.0.1/gcc/config/float-i128.h gcc-3.0.2/gcc/config/float-i128.h *** gcc-3.0.1/gcc/config/float-i128.h Wed Jan 31 11:49:00 2001 --- gcc-3.0.2/gcc/config/float-i128.h Wed Oct 10 12:03:47 2001 *************** *** 93,99 **** #undef LDBL_MAX_10_EXP #define LDBL_MAX_10_EXP 4932 ! #if __STDC_VERSION__ >= 199901L /* The floating-point expression evaluation method. -1 indeterminate 0 evaluate all operations and constants just to the range and --- 93,99 ---- #undef LDBL_MAX_10_EXP #define LDBL_MAX_10_EXP 4932 ! #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* The floating-point expression evaluation method. -1 indeterminate 0 evaluate all operations and constants just to the range and diff -Nrc3pad gcc-3.0.1/gcc/config/float-i32.h gcc-3.0.2/gcc/config/float-i32.h *** gcc-3.0.1/gcc/config/float-i32.h Wed Jan 31 11:49:00 2001 --- gcc-3.0.2/gcc/config/float-i32.h Wed Oct 10 12:03:47 2001 *************** *** 93,99 **** #undef LDBL_MAX_10_EXP #define LDBL_MAX_10_EXP 38 ! #if __STDC_VERSION__ >= 199901L /* The floating-point expression evaluation method. -1 indeterminate 0 evaluate all operations and constants just to the range and --- 93,99 ---- #undef LDBL_MAX_10_EXP #define LDBL_MAX_10_EXP 38 ! #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* The floating-point expression evaluation method. -1 indeterminate 0 evaluate all operations and constants just to the range and diff -Nrc3pad gcc-3.0.1/gcc/config/float-i386.h gcc-3.0.2/gcc/config/float-i386.h *** gcc-3.0.1/gcc/config/float-i386.h Thu Jan 11 21:28:26 2001 --- gcc-3.0.2/gcc/config/float-i386.h Wed Oct 10 12:03:47 2001 *************** *** 94,100 **** #undef LDBL_MAX_10_EXP #define LDBL_MAX_10_EXP 4932 ! #if __STDC_VERSION__ >= 199901L /* The floating-point expression evaluation method. -1 indeterminate 0 evaluate all operations and constants just to the range and --- 94,100 ---- #undef LDBL_MAX_10_EXP #define LDBL_MAX_10_EXP 4932 ! #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* The floating-point expression evaluation method. -1 indeterminate 0 evaluate all operations and constants just to the range and diff -Nrc3pad gcc-3.0.1/gcc/config/float-i64.h gcc-3.0.2/gcc/config/float-i64.h *** gcc-3.0.1/gcc/config/float-i64.h Wed Jan 31 11:49:00 2001 --- gcc-3.0.2/gcc/config/float-i64.h Wed Oct 10 12:03:47 2001 *************** *** 93,99 **** #undef LDBL_MAX_10_EXP #define LDBL_MAX_10_EXP 308 ! #if __STDC_VERSION__ >= 199901L /* The floating-point expression evaluation method. -1 indeterminate 0 evaluate all operations and constants just to the range and --- 93,99 ---- #undef LDBL_MAX_10_EXP #define LDBL_MAX_10_EXP 308 ! #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* The floating-point expression evaluation method. -1 indeterminate 0 evaluate all operations and constants just to the range and diff -Nrc3pad gcc-3.0.1/gcc/config/float-m68k.h gcc-3.0.2/gcc/config/float-m68k.h *** gcc-3.0.1/gcc/config/float-m68k.h Wed Jan 31 11:49:00 2001 --- gcc-3.0.2/gcc/config/float-m68k.h Wed Oct 10 12:03:47 2001 *************** *** 94,100 **** --- 94,127 ---- #undef LDBL_MAX_10_EXP #define LDBL_MAX_10_EXP 4932 + #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L + /* The floating-point expression evaluation method. + -1 indeterminate + 0 evaluate all operations and constants just to the range and + precision of the type + 1 evaluate operations and constants of type float and double + to the range and precision of the double type, evaluate + long double operations and constants to the range and + precision of the long double type + 2 evaluate all operations and constants to the range and + precision of the long double type + */ + /* ??? FLT_EVAL_METHOD depends on TARGET_68040_ONLY. We do not currently have a preprocessor token that we can use to tell that this is on. */ + # undef FLT_EVAL_METHOD + # define FLT_EVAL_METHOD -1 + + /* Number of decimal digits to enable rounding to the given number of + decimal digits without loss of precision. + if FLT_RADIX == 10^n: #mantissa * log10 (FLT_RADIX) + else : ceil (1 + #mantissa * log10 (FLT_RADIX)) + where #mantissa is the number of bits in the mantissa of the widest + supported floating-point type. + */ + # undef DECIMAL_DIG + # define DECIMAL_DIG 21 + + #endif /* C99 */ #endif /* _FLOAT_H_ */ diff -Nrc3pad gcc-3.0.1/gcc/config/float-sh.h gcc-3.0.2/gcc/config/float-sh.h *** gcc-3.0.1/gcc/config/float-sh.h Fri Feb 2 09:57:57 2001 --- gcc-3.0.2/gcc/config/float-sh.h Wed Oct 10 12:03:47 2001 *************** *** 130,136 **** #undef LDBL_MAX_10_EXP #define LDBL_MAX_10_EXP 308 ! #if __STDC_VERSION__ >= 199901L /* The floating-point expression evaluation method. -1 indeterminate 0 evaluate all operations and constants just to the range and --- 130,136 ---- #undef LDBL_MAX_10_EXP #define LDBL_MAX_10_EXP 308 ! #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* The floating-point expression evaluation method. -1 indeterminate 0 evaluate all operations and constants just to the range and diff -Nrc3pad gcc-3.0.1/gcc/config/float-sparc.h gcc-3.0.2/gcc/config/float-sparc.h *** gcc-3.0.1/gcc/config/float-sparc.h Wed Jan 31 11:49:00 2001 --- gcc-3.0.2/gcc/config/float-sparc.h Wed Oct 10 12:03:47 2001 *************** *** 119,125 **** #endif /* sparc32 */ ! #if __STDC_VERSION__ >= 199901L /* The floating-point expression evaluation method. -1 indeterminate 0 evaluate all operations and constants just to the range and --- 119,125 ---- #endif /* sparc32 */ ! #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L /* The floating-point expression evaluation method. -1 indeterminate 0 evaluate all operations and constants just to the range and diff -Nrc3pad gcc-3.0.1/gcc/config/h8300/fixunssfsi.c gcc-3.0.2/gcc/config/h8300/fixunssfsi.c *** gcc-3.0.1/gcc/config/h8300/fixunssfsi.c Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/config/h8300/fixunssfsi.c Thu Aug 30 18:12:21 2001 *************** *** 0 **** --- 1,43 ---- + /* More subroutines needed by GCC output code on some machines. */ + /* Compile this one with gcc. */ + /* Copyright (C) 1989, 1992, 2001 Free Software Foundation, Inc. + + This file is part of GNU CC. + + GNU CC is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + In addition to the permissions in the GNU General Public License, the + Free Software Foundation gives you unlimited permission to link the + compiled version of this file into combinations with other programs, + and to distribute those combinations without any restriction coming + from the use of this file. (The General Public License restrictions + do apply in other respects; for example, they cover modification of + the file, and distribution when not linked into a combine + executable.) + + GNU CC is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with GNU CC; see the file COPYING. If not, write to + the Free Software Foundation, 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + + /* The libgcc2.c implementation gets confused by our type setup and creates + a directly recursive call, so we do our own implementation. For the h8300, + that's in lib1funcs.asm, for h8300h / h8s, it's here. */ + + #ifndef __H8300__ + long + __fixunssfsi (float a) + { + if (a >= (float) 32768L) + return (long) (a -32768L) +32768L; + return (long) a; + } + #endif diff -Nrc3pad gcc-3.0.1/gcc/config/h8300/h8300.c gcc-3.0.2/gcc/config/h8300/h8300.c *** gcc-3.0.1/gcc/config/h8300/h8300.c Wed Jul 4 14:56:14 2001 --- gcc-3.0.2/gcc/config/h8300/h8300.c Thu Aug 30 11:06:05 2001 *************** dosize (file, op, size) *** 168,174 **** if ((TARGET_H8300 && size <= 4) || ((TARGET_H8300H || TARGET_H8300S) && size <= 8) || (TARGET_H8300 && current_function_needs_context ! && strcmp (op, "sub"))) { unsigned HOST_WIDE_INT amount; --- 168,174 ---- if ((TARGET_H8300 && size <= 4) || ((TARGET_H8300H || TARGET_H8300S) && size <= 8) || (TARGET_H8300 && current_function_needs_context ! && ! strcmp (op, "sub"))) { unsigned HOST_WIDE_INT amount; diff -Nrc3pad gcc-3.0.1/gcc/config/h8300/h8300.h gcc-3.0.2/gcc/config/h8300/h8300.h *** gcc-3.0.1/gcc/config/h8300/h8300.h Wed Jun 13 10:39:34 2001 --- gcc-3.0.2/gcc/config/h8300/h8300.h Wed Aug 29 09:06:26 2001 *************** enum reg_class { *** 495,500 **** --- 495,509 ---- #define STARTING_FRAME_OFFSET 0 + /* We do not know if the caller has a frame pointer, so we cannot go + beyond level 0. */ + + #define RETURN_ADDR_RTX(COUNT, FRAME) \ + ((COUNT) == 0 \ + ? gen_rtx_MEM (Pmode, \ + plus_constant (arg_pointer_rtx, -GET_MODE_SIZE (Pmode))) \ + : 0) + /* If we generate an insn to push BYTES bytes, this says how many the stack pointer really advances by. diff -Nrc3pad gcc-3.0.1/gcc/config/h8300/h8300.md gcc-3.0.2/gcc/config/h8300/h8300.md *** gcc-3.0.1/gcc/config/h8300/h8300.md Wed Jun 13 10:39:34 2001 --- gcc-3.0.2/gcc/config/h8300/h8300.md Wed Aug 29 09:22:51 2001 *************** *** 187,194 **** (define_insn "" [(set (match_operand:HI 0 "general_operand_dst" "=r,r,<,r,r,m") (match_operand:HI 1 "general_operand_src" "I,r>,r,i,m,r"))] ! "register_operand (operands[0],HImode) ! || register_operand (operands[1], HImode)" "@ sub.w %T0,%T0 mov.w %T1,%T0 --- 187,199 ---- (define_insn "" [(set (match_operand:HI 0 "general_operand_dst" "=r,r,<,r,r,m") (match_operand:HI 1 "general_operand_src" "I,r>,r,i,m,r"))] ! "(register_operand (operands[0],HImode) ! || register_operand (operands[1], HImode)) ! && !(GET_CODE (operands[0]) == MEM ! && GET_CODE (XEXP (operands[0], 0)) == PRE_DEC ! && GET_CODE (XEXP (XEXP (operands[0], 0), 0)) == REG ! && GET_CODE (operands[1]) == REG ! && REGNO (XEXP (XEXP (operands[0], 0), 0)) == REGNO (operands[1]))" "@ sub.w %T0,%T0 mov.w %T1,%T0 *************** *** 403,409 **** (match_operand:SI 1 "general_operand_src" "I,r,i,m,r,r,>,I,r,*a"))] "(TARGET_H8300S || TARGET_H8300H) && (register_operand (operands[0], SImode) ! || register_operand (operands[1], SImode))" "* { switch (which_alternative) --- 408,419 ---- (match_operand:SI 1 "general_operand_src" "I,r,i,m,r,r,>,I,r,*a"))] "(TARGET_H8300S || TARGET_H8300H) && (register_operand (operands[0], SImode) ! || register_operand (operands[1], SImode)) ! && !(GET_CODE (operands[0]) == MEM ! && GET_CODE (XEXP (operands[0], 0)) == PRE_DEC ! && GET_CODE (XEXP (XEXP (operands[0], 0), 0)) == REG ! && GET_CODE (operands[1]) == REG ! && REGNO (XEXP (XEXP (operands[0], 0), 0)) == REGNO (operands[1]))" "* { switch (which_alternative) *************** *** 1611,1617 **** "@ mov.b #0,%t0 mov.b %R1,%s0\;mov.b #0,%t0" ! [(set_attr "length" "2,4") (set_attr "cc" "clobber,clobber")]) ;; The compiler can synthesize a 300H variant of this which is --- 1621,1627 ---- "@ mov.b #0,%t0 mov.b %R1,%s0\;mov.b #0,%t0" ! [(set_attr "length" "2,10") (set_attr "cc" "clobber,clobber")]) ;; The compiler can synthesize a 300H variant of this which is diff -Nrc3pad gcc-3.0.1/gcc/config/h8300/lib1funcs.asm gcc-3.0.2/gcc/config/h8300/lib1funcs.asm *** gcc-3.0.1/gcc/config/h8300/lib1funcs.asm Thu Sep 7 15:11:31 2000 --- gcc-3.0.2/gcc/config/h8300/lib1funcs.asm Thu Aug 30 18:13:48 2001 *************** *** 1,7 **** ;; libgcc1 routines for the Hitachi H8/300 CPU. ;; Contributed by Steve Chamberlain ! /* Copyright (C) 1994, 2000 Free Software Foundation, Inc. This file is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the --- 1,7 ---- ;; libgcc1 routines for the Hitachi H8/300 CPU. ;; Contributed by Steve Chamberlain ! /* Copyright (C) 1994, 2000, 2001 Free Software Foundation, Inc. This file is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the *************** ___umodhi3: *** 251,257 **** ; q low 8 bits of quot ; P preserve ! ; The h8 only has a 16/8 bit divide, so we look at the incoming and ; see how to partition up the expression. .global ___udivhi3 --- 251,257 ---- ; q low 8 bits of quot ; P preserve ! ; The H8/300 only has a 16/8 bit divide, so we look at the incoming and ; see how to partition up the expression. .global ___udivhi3 *************** reti: *** 502,511 **** POPP S2P rts ! ; takes A0/A1 numerator (A0P for 300h) ! ; A2/A3 denominator (A1P for 300h) ! ; returns A0/A1 quotient (A0P for 300h) ! ; S0/S1 remainder (S0P for 300h) ; trashes S2 #ifdef __H8300__ --- 502,511 ---- POPP S2P rts ! ; takes A0/A1 numerator (A0P for 300H) ! ; A2/A3 denominator (A1P for 300H) ! ; returns A0/A1 quotient (A0P for 300H) ! ; S0/S1 remainder (S0P for 300H) ; trashes S2 #ifdef __H8300__ *************** setone: *** 634,640 **** #ifdef L_mulhi3 ;; HImode multiply. ! ; The h8 only has an 8*8->16 multiply. ; The answer is the same as: ; ; product = (srca.l * srcb.l) + ((srca.h * srcb.l) + (srcb.h * srca.l)) * 256 --- 634,640 ---- #ifdef L_mulhi3 ;; HImode multiply. ! ; The H8/300 only has an 8*8->16 multiply. ; The answer is the same as: ; ; product = (srca.l * srcb.l) + ((srca.h * srcb.l) + (srcb.h * srca.l)) * 256 *************** _done: *** 764,766 **** --- 764,794 ---- #endif #endif /* L_mulsi3 */ + #ifdef L_fixunssfsi_asm + /* For the h8300 we use asm to save some bytes, to + allow more programs to fit into the tiny address + space. For h8300h / h8s, the C version is good enough. */ + #ifdef __H8300__ + /* We still treat NANs different than libgcc2.c, but then, the + behaviour is undefined anyways. */ + .global ___fixunssfsi + ___fixunssfsi: + cmp.b #0x47,r0h + bge Large_num + jmp @___fixsfsi + Large_num: + bhi L_huge_num + xor.b #0x80,A0L + bmi L_shift8 + L_huge_num: + mov.w #65535,A0 + mov.w A0,A1 + rts + L_shift8: + mov.b A0L,A0H + mov.b A1H,A0L + mov.b A1L,A1H + mov.b #0,A1L + rts + #endif + #endif /* L_fixunssfsi_asm */ diff -Nrc3pad gcc-3.0.1/gcc/config/h8300/t-h8300 gcc-3.0.2/gcc/config/h8300/t-h8300 *** gcc-3.0.1/gcc/config/h8300/t-h8300 Mon Jul 9 15:03:17 2001 --- gcc-3.0.2/gcc/config/h8300/t-h8300 Thu Aug 30 18:12:21 2001 *************** *** 1,7 **** CROSS_LIBGCC1 = libgcc1-asm.a LIB1ASMSRC = h8300/lib1funcs.asm LIB1ASMFUNCS = _cmpsi2 _ucmpsi2 _divhi3 _divsi3 _mulhi3 _mulsi3 \ ! _floatdisf _fixsfdi # We do not have DF or DI types, so fake out the libgcc2 compilation. TARGET_LIBGCC2_CFLAGS = -DDF=SF -DDI=SI --- 1,12 ---- + # The three first floating point functions listed in LIB1ASMFUNCS (_fixsfdi, + # _floatdisf, and _fixunssfdi) are used to disable the inclusion of those + # from libgcc2.c. They do not actually exist in lib1funcs.asm. CROSS_LIBGCC1 = libgcc1-asm.a LIB1ASMSRC = h8300/lib1funcs.asm LIB1ASMFUNCS = _cmpsi2 _ucmpsi2 _divhi3 _divsi3 _mulhi3 _mulsi3 \ ! _floatdisf _fixsfdi _fixunssfdi _fixunssfsi_asm ! ! LIB2FUNCS_EXTRA = $(srcdir)/config/h8300/fixunssfsi.c # We do not have DF or DI types, so fake out the libgcc2 compilation. TARGET_LIBGCC2_CFLAGS = -DDF=SF -DDI=SI diff -Nrc3pad gcc-3.0.1/gcc/config/i386/cygwin.h gcc-3.0.2/gcc/config/i386/cygwin.h *** gcc-3.0.1/gcc/config/i386/cygwin.h Sun May 20 12:49:17 2001 --- gcc-3.0.2/gcc/config/i386/cygwin.h Sun Oct 14 08:45:00 2001 *************** Boston, MA 02111-1307, USA. */ *** 80,86 **** #define MINGW_LIBS "-L/usr/local/lib/mingw -L/usr/lib/mingw" #define MINGW_INCLUDES "-isystem /usr/include/mingw/g++-3 "\ "-isystem /usr/include/mingw/g++ "\ ! "-isystem /usr/local/include/mingw" \ "-idirafter /usr/include/mingw" #endif --- 80,86 ---- #define MINGW_LIBS "-L/usr/local/lib/mingw -L/usr/lib/mingw" #define MINGW_INCLUDES "-isystem /usr/include/mingw/g++-3 "\ "-isystem /usr/include/mingw/g++ "\ ! "-isystem /usr/local/include/mingw " \ "-idirafter /usr/include/mingw" #endif *************** extern int i386_pe_dllimport_name_p PARA *** 563,568 **** --- 563,572 ---- #undef BIGGEST_ALIGNMENT #define BIGGEST_ALIGNMENT 128 + /* Native complier aligns internal doubles in structures on dword boundaries. */ + #undef BIGGEST_FIELD_ALIGNMENT + #define BIGGEST_FIELD_ALIGNMENT 64 + /* A bitfield declared as `int' forces `int' alignment for the struct. */ #undef PCC_BITFIELDS_TYPE_MATTERS #define PCC_BITFIELDS_TYPE_MATTERS 1 *************** extern int i386_pe_dllimport_name_p PARA *** 574,579 **** --- 578,586 ---- #define SET_ASM_OP "\t.set\t" #endif + /* Override GCC's relative pathname lookup unless otherwise told + by other subtargets. */ + #ifndef WIN32_NO_ABSOLUTE_INST_DIRS #undef MD_STARTFILE_PREFIX #define MD_STARTFILE_PREFIX "/usr/lib/" *************** extern int i386_pe_dllimport_name_p PARA *** 586,592 **** #undef SYSTEM_INCLUDE_DIR #undef STANDARD_INCLUDE_DIR #define STANDARD_INCLUDE_DIR 0 ! #endif #undef TREE --- 593,600 ---- #undef SYSTEM_INCLUDE_DIR #undef STANDARD_INCLUDE_DIR #define STANDARD_INCLUDE_DIR 0 ! #endif /* not CROSS_COMPILE */ ! #endif /* not WIN32_NO_ABSOLUTE_INST_DIRS */ #undef TREE diff -Nrc3pad gcc-3.0.1/gcc/config/i386/i386.c gcc-3.0.2/gcc/config/i386/i386.c *** gcc-3.0.1/gcc/config/i386/i386.c Mon Aug 6 14:26:24 2001 --- gcc-3.0.2/gcc/config/i386/i386.c Fri Sep 14 10:11:12 2001 *************** int ix86_align_loops; *** 417,423 **** --- 417,428 ---- /* Power of two alignment for non-loop jumps. */ int ix86_align_jumps; + + /* Prefix built by ASM_GENERATE_INTERNAL_LABEL. */ + static char internal_label_prefix[16]; + static int internal_label_prefix_len; + static int local_symbolic_operand PARAMS ((rtx, enum machine_mode)); static void output_pic_addr_const PARAMS ((FILE *, rtx, int)); static void put_condition_code PARAMS ((enum rtx_code, enum machine_mode, int, int, FILE *)); *************** override_options () *** 693,698 **** --- 698,712 ---- on by -msse. */ if (TARGET_SSE) target_flags |= MASK_MMX; + + /* Figure out what ASM_GENERATE_INTERNAL_LABEL builds as a prefix. */ + { + char *p; + ASM_GENERATE_INTERNAL_LABEL (internal_label_prefix, "LX", 0); + p = strchr (internal_label_prefix, 'X'); + internal_label_prefix_len = p - internal_label_prefix; + *p = '\0'; + } } /* A C statement (sans semicolon) to choose the order in which to *************** pic_symbolic_operand (op, mode) *** 1128,1133 **** --- 1142,1181 ---- return 0; } + /* Return true if OP is a symbolic operand that resolves locally. */ + + static int + local_symbolic_operand (op, mode) + rtx op; + enum machine_mode mode ATTRIBUTE_UNUSED; + { + if (GET_CODE (op) == LABEL_REF) + return 1; + + if (GET_CODE (op) == CONST + && GET_CODE (XEXP (op, 0)) == PLUS + && GET_CODE (XEXP (XEXP (op, 0), 1)) == CONST_INT) + op = XEXP (XEXP (op, 0), 0); + + if (GET_CODE (op) != SYMBOL_REF) + return 0; + + /* These we've been told are local by varasm and encode_section_info + respectively. */ + if (CONSTANT_POOL_ADDRESS_P (op) || SYMBOL_REF_FLAG (op)) + return 1; + + /* There is, however, a not insubstantial body of code in the rest of + the compiler that assumes it can just stick the results of + ASM_GENERATE_INTERNAL_LABEL in a symbol_ref and have done. */ + + if (strncmp (XSTR (op, 0), internal_label_prefix, + internal_label_prefix_len) == 0) + return 1; + + return 0; + } + /* Test for a valid operand for a call instruction. Don't allow the arg pointer register or virtual regs since they may decay into reg + const, which the patterns can't handle. */ *************** legitimate_pic_address_disp_p (disp) *** 2530,2544 **** return 0; /* Must be @GOT or @GOTOFF. */ ! if (XINT (disp, 1) != 6 ! && XINT (disp, 1) != 7) ! return 0; ! ! if (GET_CODE (XVECEXP (disp, 0, 0)) != SYMBOL_REF ! && GET_CODE (XVECEXP (disp, 0, 0)) != LABEL_REF) ! return 0; ! return 1; } /* GO_IF_LEGITIMATE_ADDRESS recognizes an RTL expression that is a valid --- 2578,2593 ---- return 0; /* Must be @GOT or @GOTOFF. */ ! switch (XINT (disp, 1)) ! { ! case 6: /* @GOT */ ! return GET_CODE (XVECEXP (disp, 0, 0)) == SYMBOL_REF; ! case 7: /* @GOTOFF */ ! return local_symbolic_operand (XVECEXP (disp, 0, 0), Pmode); ! } ! ! return 0; } /* GO_IF_LEGITIMATE_ADDRESS recognizes an RTL expression that is a valid *************** legitimize_pic_address (orig, reg) *** 2767,2776 **** rtx new = orig; rtx base; ! if (GET_CODE (addr) == LABEL_REF ! || (GET_CODE (addr) == SYMBOL_REF ! && (CONSTANT_POOL_ADDRESS_P (addr) ! || SYMBOL_REF_FLAG (addr)))) { /* This symbol may be referenced via a displacement from the PIC base address (@GOTOFF). */ --- 2816,2822 ---- rtx new = orig; rtx base; ! if (local_symbolic_operand (addr, Pmode)) { /* This symbol may be referenced via a displacement from the PIC base address (@GOTOFF). */ *************** legitimize_pic_address (orig, reg) *** 2822,2831 **** /* Check first to see if this is a constant offset from a @GOTOFF symbol reference. */ ! if ((GET_CODE (op0) == LABEL_REF ! || (GET_CODE (op0) == SYMBOL_REF ! && (CONSTANT_POOL_ADDRESS_P (op0) ! || SYMBOL_REF_FLAG (op0)))) && GET_CODE (op1) == CONST_INT) { current_function_uses_pic_offset_table = 1; --- 2868,2874 ---- /* Check first to see if this is a constant offset from a @GOTOFF symbol reference. */ ! if (local_symbolic_operand (op0, Pmode) && GET_CODE (op1) == CONST_INT) { current_function_uses_pic_offset_table = 1; diff -Nrc3pad gcc-3.0.1/gcc/config/i386/i386.md gcc-3.0.2/gcc/config/i386/i386.md *** gcc-3.0.1/gcc/config/i386/i386.md Mon Aug 6 13:33:40 2001 --- gcc-3.0.2/gcc/config/i386/i386.md Fri Oct 5 12:45:34 2001 *************** *** 1581,1587 **** [(set_attr "type" "pop") (set_attr "mode" "SI")]) ! (define_insn "*movsi_xor" [(set (match_operand:SI 0 "register_operand" "=r") (match_operand:SI 1 "const0_operand" "i")) (clobber (reg:CC 17))] --- 1581,1587 ---- [(set_attr "type" "pop") (set_attr "mode" "SI")]) ! (define_insn "movsi_xor" [(set (match_operand:SI 0 "register_operand" "=r") (match_operand:SI 1 "const0_operand" "i")) (clobber (reg:CC 17))] *************** *** 9606,9618 **** (zero_extend (match_dup 1)))] "peep2_reg_dead_p (3, operands[1]) && ! reg_overlap_mentioned_p (operands[3], operands[0])" ! [(parallel [(set (match_dup 3) (const_int 0)) ! (clobber (reg:CC 17))]) ! (set (match_dup 4) (match_dup 0)) (set (strict_low_part (match_dup 5)) (match_dup 2))] ! "operands[4] = gen_rtx_REG (GET_MODE (operands[0]), 17); ! operands[5] = gen_rtx_REG (QImode, REGNO (operands[3]));") ;; Call instructions. --- 9606,9623 ---- (zero_extend (match_dup 1)))] "peep2_reg_dead_p (3, operands[1]) && ! reg_overlap_mentioned_p (operands[3], operands[0])" ! [(set (match_dup 4) (match_dup 0)) (set (strict_low_part (match_dup 5)) (match_dup 2))] ! " ! { ! operands[4] = gen_rtx_REG (GET_MODE (operands[0]), 17); ! operands[5] = gen_rtx_REG (QImode, REGNO (operands[3])); ! if (HAVE_movsi_xor) ! emit_insn (gen_movsi_xor (operands[3], const0_rtx)); ! else ! emit_insn (gen_movsi (operands[3], const0_rtx)); ! }") ;; Call instructions. diff -Nrc3pad gcc-3.0.1/gcc/config/i386/mingw32.h gcc-3.0.2/gcc/config/i386/mingw32.h *** gcc-3.0.1/gcc/config/i386/mingw32.h Mon Jan 29 13:41:46 2001 --- gcc-3.0.2/gcc/config/i386/mingw32.h Wed Oct 10 13:38:56 2001 *************** Boston, MA 02111-1307, USA. */ *** 24,44 **** /* Most of this is the same as for cygwin, except for changing some specs. */ #include "i386/cygwin.h" /* Please keep changes to CPP_PREDEFINES in sync with i386/crtdll. The only difference between the two should be __MSVCRT__ needed to distinguish MSVC from CRTDLL runtime in mingw headers. */ #undef CPP_PREDEFINES ! #define CPP_PREDEFINES "-D_WIN32 -DWIN32 \ ! -D__MINGW32__=0.2 -D__MSVCRT__ -DWINNT -D_X86_=1 \ -Asystem=winnt" /* Specific a different directory for the standard include files. */ #undef STANDARD_INCLUDE_DIR ! #define STANDARD_INCLUDE_DIR "/usr/local/i386-mingw32/include" ! ! #define STANDARD_INCLUDE_COMPONENT "MINGW32" #undef CPP_SPEC #define CPP_SPEC \ --- 24,50 ---- /* Most of this is the same as for cygwin, except for changing some specs. */ + /* Mingw GCC, unlike Cygwin's, must be relocatable. This macro must + be defined before any other files are included. */ + #ifndef WIN32_NO_ABSOLUTE_INST_DIRS + #define WIN32_NO_ABSOLUTE_INST_DIRS 1 + #endif + #include "i386/cygwin.h" /* Please keep changes to CPP_PREDEFINES in sync with i386/crtdll. The only difference between the two should be __MSVCRT__ needed to distinguish MSVC from CRTDLL runtime in mingw headers. */ #undef CPP_PREDEFINES ! #define CPP_PREDEFINES "-D_WIN32 -D__WIN32 -D__WIN32__ -DWIN32 \ ! -D__MINGW32__ -D__MSVCRT__ -DWINNT -D_X86_=1 \ -Asystem=winnt" /* Specific a different directory for the standard include files. */ #undef STANDARD_INCLUDE_DIR ! #define STANDARD_INCLUDE_DIR "/usr/local/mingw32/include" ! #undef STANDARD_INCLUDE_COMPONENT ! #define STANDARD_INCLUDE_COMPONENT "MINGW" #undef CPP_SPEC #define CPP_SPEC \ *************** Boston, MA 02111-1307, USA. */ *** 75,84 **** %{!shared:%{!mdll:crt2%O%s}} %{pg:gcrt2%O%s}" /* MS runtime does not need a separate math library. */ #define MATH_LIBRARY "" ! /* Output STRING, a string representing a filename, to FILE. We canonicalize ! it to be in MS-DOS format. */ #define OUTPUT_QUOTED_STRING(FILE, STRING) \ do { \ char c; \ --- 81,92 ---- %{!shared:%{!mdll:crt2%O%s}} %{pg:gcrt2%O%s}" /* MS runtime does not need a separate math library. */ + #undef MATH_LIBRARY #define MATH_LIBRARY "" ! /* Output STRING, a string representing a filename, to FILE. ! We canonicalize it to be in MS-DOS format. */ ! #undef OUTPUT_QUOTED_STRING #define OUTPUT_QUOTED_STRING(FILE, STRING) \ do { \ char c; \ diff -Nrc3pad gcc-3.0.1/gcc/config/i386/sol2.h gcc-3.0.2/gcc/config/i386/sol2.h *** gcc-3.0.1/gcc/config/i386/sol2.h Tue Jul 3 05:33:09 2001 --- gcc-3.0.2/gcc/config/i386/sol2.h Fri Sep 28 14:31:01 2001 *************** Boston, MA 02111-1307, USA. */ *** 83,88 **** --- 83,96 ---- %{!pthreads:%{threads:-D_REENTRANT -D_SOLARIS_THREADS}} \ %{compat-bsd:-iwithprefixbefore ucbinclude -I/usr/ucbinclude}" + /* For C++ we need to add some additional macro definitions required + by the C++ standard library. */ + #define CPLUSPLUS_CPP_SPEC "\ + -D_XOPEN_SOURCE=500 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 \ + -D__EXTENSIONS__ \ + %(cpp) \ + " + #undef LIB_SPEC #define LIB_SPEC \ "%{compat-bsd:-lucb -lsocket -lnsl -lelf -laio} \ diff -Nrc3pad gcc-3.0.1/gcc/config/i386/unix.h gcc-3.0.2/gcc/config/i386/unix.h *** gcc-3.0.1/gcc/config/i386/unix.h Sat Dec 16 08:07:25 2000 --- gcc-3.0.2/gcc/config/i386/unix.h Fri Sep 14 09:42:30 2001 *************** Boston, MA 02111-1307, USA. */ *** 87,93 **** #define ASM_OUTPUT_MI_THUNK(FILE, THUNK_FNDECL, DELTA, FUNCTION) \ do { \ tree parm; \ ! rtx xops[2]; \ \ if (ix86_regparm > 0) \ parm = TYPE_ARG_TYPES (TREE_TYPE (function)); \ --- 87,93 ---- #define ASM_OUTPUT_MI_THUNK(FILE, THUNK_FNDECL, DELTA, FUNCTION) \ do { \ tree parm; \ ! rtx xops[3]; \ \ if (ix86_regparm > 0) \ parm = TYPE_ARG_TYPES (TREE_TYPE (function)); \ *************** do { \ *** 110,115 **** --- 110,116 ---- { \ xops[0] = pic_offset_table_rtx; \ xops[1] = gen_label_rtx (); \ + xops[2] = gen_rtx_SYMBOL_REF (Pmode, "_GLOBAL_OFFSET_TABLE_"); \ \ if (ix86_regparm > 2) \ abort (); \ *************** do { \ *** 117,123 **** output_asm_insn ("call\t%P1", xops); \ ASM_OUTPUT_INTERNAL_LABEL (FILE, "L", CODE_LABEL_NUMBER (xops[1])); \ output_asm_insn ("pop{l}\t%0", xops); \ ! output_asm_insn ("add{l}\t{$_GLOBAL_OFFSET_TABLE_+[.-%P1], %0|%0, OFFSET FLAT: _GLOBAL_OFFSET_TABLE_+[.-%P1]}", xops); \ xops[0] = gen_rtx_MEM (SImode, XEXP (DECL_RTL (FUNCTION), 0)); \ output_asm_insn ("mov{l}\t{%0@GOT(%%ebx), %%ecx|%%ecx, %0@GOT[%%ebx]}",\ xops); \ --- 118,124 ---- output_asm_insn ("call\t%P1", xops); \ ASM_OUTPUT_INTERNAL_LABEL (FILE, "L", CODE_LABEL_NUMBER (xops[1])); \ output_asm_insn ("pop{l}\t%0", xops); \ ! output_asm_insn ("add{l}\t{%2+[.-%P1], %0|%0, OFFSET FLAT: %2+[.-%P1]}", xops); \ xops[0] = gen_rtx_MEM (SImode, XEXP (DECL_RTL (FUNCTION), 0)); \ output_asm_insn ("mov{l}\t{%0@GOT(%%ebx), %%ecx|%%ecx, %0@GOT[%%ebx]}",\ xops); \ diff -Nrc3pad gcc-3.0.1/gcc/config/ia64/ia64.c gcc-3.0.2/gcc/config/ia64/ia64.c *** gcc-3.0.1/gcc/config/ia64/ia64.c Fri Jun 8 10:18:43 2001 --- gcc-3.0.2/gcc/config/ia64/ia64.c Wed Sep 19 12:17:21 2001 *************** ia64_return_in_memory (valtype) *** 3105,3115 **** { enum machine_mode mode; enum machine_mode hfa_mode; ! int byte_size; mode = TYPE_MODE (valtype); ! byte_size = ((mode == BLKmode) ! ? int_size_in_bytes (valtype) : GET_MODE_SIZE (mode)); /* Hfa's with up to 8 elements are returned in the FP argument registers. */ --- 3105,3120 ---- { enum machine_mode mode; enum machine_mode hfa_mode; ! HOST_WIDE_INT byte_size; mode = TYPE_MODE (valtype); ! byte_size = GET_MODE_SIZE (mode); ! if (mode == BLKmode) ! { ! byte_size = int_size_in_bytes (valtype); ! if (byte_size < 0) ! return 1; ! } /* Hfa's with up to 8 elements are returned in the FP argument registers. */ *************** ia64_return_in_memory (valtype) *** 3123,3129 **** else return 0; } - else if (byte_size > UNITS_PER_WORD * MAX_INT_RETURN_SLOTS) return 1; else --- 3128,3133 ---- diff -Nrc3pad gcc-3.0.1/gcc/config/ia64/ia64.h gcc-3.0.2/gcc/config/ia64/ia64.h *** gcc-3.0.1/gcc/config/ia64/ia64.h Wed Jul 25 06:24:46 2001 --- gcc-3.0.2/gcc/config/ia64/ia64.h Fri Sep 21 18:33:20 2001 *************** while (0) *** 422,427 **** --- 422,434 ---- If you do not define this macro, the default for `-fvtable-thunk' is 0. */ #define DEFAULT_VTABLE_THUNKS 1 + /* By default, the C++ compiler will use function addresses in the + vtable entries. Setting this non-zero tells the compiler to use + function descriptors instead. The value of this macro says how + many words wide the descriptor is (normally 2). It is assumed + that the address of a function descriptor may be treated as a + pointer to a function. */ + #define TARGET_VTABLE_USES_DESCRIPTORS 2 /* Layout of Source Language Data Types */ *************** do { \ *** 1523,1528 **** --- 1530,1546 ---- fprintf (FILE, "\n"); \ } while (0) + /* Output part N of a function descriptor for DECL. For ia64, both + words are emitted with a single relocation, so ignore N > 0. */ + #define ASM_OUTPUT_FDESC(FILE, DECL, PART) \ + do { \ + if ((PART) == 0) \ + { \ + fputs ("\tdata16.ua @iplt(", FILE); \ + assemble_name (FILE, XSTR (XEXP (DECL_RTL (DECL), 0), 0)); \ + fputs (")\n", FILE); \ + } \ + } while (0) /* Generating Code for Profiling. */ diff -Nrc3pad gcc-3.0.1/gcc/config/ia64/ia64.md gcc-3.0.2/gcc/config/ia64/ia64.md *** gcc-3.0.1/gcc/config/ia64/ia64.md Wed Jul 25 06:35:00 2001 --- gcc-3.0.2/gcc/config/ia64/ia64.md Tue Aug 28 14:56:01 2001 *************** *** 1194,1204 **** "" "@ # ! tbit.z.and.orcm %0, %I0 = %2, 0 andcm %0 = %2, %1" "reload_completed && GET_CODE (operands[0]) == REG && PR_REGNO_P (REGNO (operands[0])) ! && GET_CODE (operands[2]) == REG && PR_REGNO_P (REGNO (operands[2]))" [(cond_exec (ne (match_dup 1) (const_int 0)) (set (match_dup 0) (and:BI (ne:BI (const_int 0) (const_int 0)) (match_dup 0))))] --- 1194,1204 ---- "" "@ # ! tbit.z.and.orcm %0, %I0 = %1, 0 andcm %0 = %2, %1" "reload_completed && GET_CODE (operands[0]) == REG && PR_REGNO_P (REGNO (operands[0])) ! && GET_CODE (operands[1]) == REG && PR_REGNO_P (REGNO (operands[1]))" [(cond_exec (ne (match_dup 1) (const_int 0)) (set (match_dup 0) (and:BI (ne:BI (const_int 0) (const_int 0)) (match_dup 0))))] *************** *** 1230,1239 **** "" "@ # ! tbit.z.or.andcm %0, %I0 = %2, 0" "reload_completed && GET_CODE (operands[0]) == REG && PR_REGNO_P (REGNO (operands[0])) ! && GET_CODE (operands[2]) == REG && PR_REGNO_P (REGNO (operands[2]))" [(cond_exec (eq (match_dup 1) (const_int 0)) (set (match_dup 0) (ior:BI (eq:BI (const_int 0) (const_int 0)) (match_dup 0))))] --- 1230,1239 ---- "" "@ # ! tbit.z.or.andcm %0, %I0 = %1, 0" "reload_completed && GET_CODE (operands[0]) == REG && PR_REGNO_P (REGNO (operands[0])) ! && GET_CODE (operands[1]) == REG && PR_REGNO_P (REGNO (operands[1]))" [(cond_exec (eq (match_dup 1) (const_int 0)) (set (match_dup 0) (ior:BI (eq:BI (const_int 0) (const_int 0)) (match_dup 0))))] *************** *** 1258,1264 **** (clobber (match_scratch:BI 2 ""))] "reload_completed && GET_CODE (operands[0]) == REG && PR_REGNO_P (REGNO (operands[0])) - && GET_CODE (operands[1]) == REG && PR_REGNO_P (REGNO (operands[1])) && rtx_equal_p (operands[0], operands[1])" [(set (match_dup 4) (match_dup 3)) (set (match_dup 0) (const_int 1)) --- 1258,1263 ---- diff -Nrc3pad gcc-3.0.1/gcc/config/m68hc11/m68hc11.c gcc-3.0.2/gcc/config/m68hc11/m68hc11.c *** gcc-3.0.1/gcc/config/m68hc11/m68hc11.c Fri Jul 20 12:38:15 2001 --- gcc-3.0.2/gcc/config/m68hc11/m68hc11.c Sun Sep 30 05:53:26 2001 *************** m68hc11_gen_movhi (insn, operands) *** 3310,3316 **** if (ix_reg == 0) create_regs_rtx (); ! if (reg_mentioned_p (ix_reg, operands[0])) { output_asm_insn ("sty\t%t0", operands); output_asm_insn ("tsy", operands); --- 3310,3326 ---- if (ix_reg == 0) create_regs_rtx (); ! if (REG_P (operands[0]) && REGNO (operands[0]) == SOFT_TMP_REGNUM) ! { ! output_asm_insn ("pshx", operands); ! output_asm_insn ("tsx", operands); ! output_asm_insn ("inx", operands); ! output_asm_insn ("inx", operands); ! output_asm_insn ("stx\t%0", operands); ! output_asm_insn ("pulx", operands); ! } ! ! else if (reg_mentioned_p (ix_reg, operands[0])) { output_asm_insn ("sty\t%t0", operands); output_asm_insn ("tsy", operands); diff -Nrc3pad gcc-3.0.1/gcc/config/m68hc11/m68hc11.h gcc-3.0.2/gcc/config/m68hc11/m68hc11.h *** gcc-3.0.1/gcc/config/m68hc11/m68hc11.h Fri Aug 3 14:05:49 2001 --- gcc-3.0.2/gcc/config/m68hc11/m68hc11.h Sun Sep 30 05:47:16 2001 *************** extern enum reg_class m68hc11_tmp_regs_c *** 883,898 **** #define FIRST_PARM_OFFSET(FNDECL) 2 - /* A C expression whose value is RTL representing the location of the - incoming return address at the beginning of any function, before the - prologue. This RTL is either a REG, indicating that the return - value is saved in REG, or a MEM representing a location in - the stack. - - Before the prologue, RA is at 0(sp). */ - #define INCOMING_RETURN_ADDR_RTX \ - gen_rtx_MEM (VOIDmode, gen_rtx_REG (VOIDmode, STACK_POINTER_REGNUM)) - /* After the prologue, RA is at 0(AP) in the current frame. */ #define RETURN_ADDR_RTX(COUNT, FRAME) \ ((COUNT) == 0 \ --- 883,888 ---- diff -Nrc3pad gcc-3.0.1/gcc/config/m68hc11/m68hc11.md gcc-3.0.2/gcc/config/m68hc11/m68hc11.md *** gcc-3.0.1/gcc/config/m68hc11/m68hc11.md Sat Aug 4 04:30:00 2001 --- gcc-3.0.2/gcc/config/m68hc11/m68hc11.md Mon Oct 1 06:38:13 2001 *************** *** 170,176 **** (define_insn "tsthi_1" [(set (cc0) ! (match_operand:HI 0 "tst_operand" "dx,y"))] "" "* { --- 170,176 ---- (define_insn "tsthi_1" [(set (cc0) ! (match_operand:HI 0 "tst_operand" "dx,*y"))] "" "* { *************** *** 484,491 **** (define_insn "cmpqi_1" [(set (cc0) ! (compare (match_operand:QI 0 "tst_operand" "d,m,d,!u,*B,d") ! (match_operand:QI 1 "cmp_operand" "im,d,!u,d,?dim*B,*u")))] "" "* { --- 484,491 ---- (define_insn "cmpqi_1" [(set (cc0) ! (compare (match_operand:QI 0 "tst_operand" "d,m,d,!u,*B,d*B") ! (match_operand:QI 1 "cmp_operand" "im,d,!u,d,dim*A,*u")))] "" "* { *************** *** 1002,1009 **** }") (define_insn "*movqi_68hc12" ! [(set (match_operand:QI 0 "nonimmediate_operand" "=d*AuU*q,d*A*qu,d*A*q,m,m") ! (match_operand:QI 1 "general_operand" "rui*q,U,m,d*q,!A"))] "TARGET_M6812" "* { --- 1002,1011 ---- }") (define_insn "*movqi_68hc12" ! [(set (match_operand:QI 0 "nonimmediate_operand" ! "=d*AU*q,d*A*q,*u,d*A*q,m,m") ! (match_operand:QI 1 "general_operand" ! "*ri*q,U,*ri*qU,m,d*q,!A"))] "TARGET_M6812" "* { *************** *** 1270,1278 **** }") (define_insn "zero_extendqisi2" ! [(set (match_operand:SI 0 "non_push_operand" "=D,m,u") (zero_extend:SI ! (match_operand:QI 1 "nonimmediate_operand" "dxymu,dxy,dxy")))] "" "#") --- 1272,1280 ---- }") (define_insn "zero_extendqisi2" ! [(set (match_operand:SI 0 "non_push_operand" "=D,D,m,m,u") (zero_extend:SI ! (match_operand:QI 1 "nonimmediate_operand" "dmu,xy,d,xy,dxy")))] "" "#") *************** *** 2307,2313 **** "") (define_insn "*addhi3" ! [(set (match_operand:HI 0 "hard_reg_operand" "=A,d,!A,d*A,!d") (plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0,0") (match_operand:HI 2 "general_operand" "N,i,I,mi*A*d,!u*d*w")))] "TARGET_M6811" --- 2309,2315 ---- "") (define_insn "*addhi3" ! [(set (match_operand:HI 0 "hard_reg_operand" "=A,d,!A,d*A,!d*A") (plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0,0") (match_operand:HI 2 "general_operand" "N,i,I,mi*A*d,!u*d*w")))] "TARGET_M6811" *************** *** 2430,2438 **** "") (define_insn "addqi3" ! [(set (match_operand:QI 0 "nonimmediate_operand" "=!*rm,dq*A") ! (plus:QI (match_operand:QI 1 "nonimmediate_operand" "%0,0") ! (match_operand:QI 2 "general_operand" "N,ium*A*d")))] "" "* { --- 2432,2440 ---- "") (define_insn "addqi3" ! [(set (match_operand:QI 0 "nonimmediate_operand" "=!d*rm,dq,!*A") ! (plus:QI (match_operand:QI 1 "nonimmediate_operand" "%0,0,0") ! (match_operand:QI 2 "general_operand" "N,ium*A*d,ium*A*d")))] "" "* { *************** *** 3451,3461 **** "#") (define_insn "*logicalhi3_zexthi" ! [(set (match_operand:HI 0 "register_operand" "=d") (match_operator:HI 3 "m68hc11_logical_operator" [(zero_extend:HI ! (match_operand:QI 1 "general_operand" "imud")) ! (match_operand:HI 2 "general_operand" "dimu")]))] "" "#") --- 3453,3463 ---- "#") (define_insn "*logicalhi3_zexthi" ! [(set (match_operand:HI 0 "register_operand" "=d,d") (match_operator:HI 3 "m68hc11_logical_operator" [(zero_extend:HI ! (match_operand:QI 1 "general_operand" "imd*A,?u")) ! (match_operand:HI 2 "general_operand" "dim,?dimu")]))] "" "#") *************** *** 3655,3662 **** (set (match_dup 0) (reg:HI D_REGNUM))])] " /* Save the operand2 in a temporary location and use it. */ ! if (H_REG_P (operands[2]) ! || reg_mentioned_p (operands[0], operands[2])) { operands[4] = gen_rtx (REG, HImode, SOFT_TMP_REGNUM); operands[6] = operands[4]; --- 3657,3665 ---- (set (match_dup 0) (reg:HI D_REGNUM))])] " /* Save the operand2 in a temporary location and use it. */ ! if ((H_REG_P (operands[2]) ! || reg_mentioned_p (operands[0], operands[2])) ! && !(SP_REG_P (operands[2]) && GET_CODE (operands[3]) == PLUS)) { operands[4] = gen_rtx (REG, HImode, SOFT_TMP_REGNUM); operands[6] = operands[4]; *************** *** 6119,6127 **** { int value_loaded = 1; ! if (X_REG_P (operands[0])) { ! output_asm_insn (\"ldx\\t%2\\n\\txgdx\", operands); } else if (Y_REG_P (operands[0])) { --- 6122,6135 ---- { int value_loaded = 1; ! if (X_REG_P (operands[0]) || SP_REG_P (operands[2])) { ! rtx ops[2]; ! ! ops[0] = operands[0]; ! ops[1] = operands[2]; ! m68hc11_gen_movhi (insn, ops); ! output_asm_insn (\"xgd%0\", operands); } else if (Y_REG_P (operands[0])) { diff -Nrc3pad gcc-3.0.1/gcc/config/rs6000/rs6000-protos.h gcc-3.0.2/gcc/config/rs6000/rs6000-protos.h *** gcc-3.0.1/gcc/config/rs6000/rs6000-protos.h Sat Jul 14 15:50:31 2001 --- gcc-3.0.2/gcc/config/rs6000/rs6000-protos.h Mon Sep 10 11:06:28 2001 *************** extern int reg_or_arith_cint_operand PAR *** 45,50 **** --- 45,51 ---- extern int reg_or_add_cint64_operand PARAMS ((rtx, enum machine_mode)); extern int reg_or_sub_cint64_operand PARAMS ((rtx, enum machine_mode)); extern int reg_or_logical_cint_operand PARAMS ((rtx, enum machine_mode)); + extern int scc_eq_operand PARAMS ((rtx, enum machine_mode)); extern int got_operand PARAMS ((rtx, enum machine_mode)); extern int got_no_const_operand PARAMS ((rtx, enum machine_mode)); extern int num_insns_constant PARAMS ((rtx, enum machine_mode)); *************** extern int non_logical_cint_operand PARA *** 59,65 **** extern int logical_operand PARAMS ((rtx, enum machine_mode)); extern int mask_operand PARAMS ((rtx, enum machine_mode)); extern int mask64_operand PARAMS ((rtx, enum machine_mode)); - extern int rldic_operand PARAMS ((rtx, enum machine_mode)); extern int and64_operand PARAMS ((rtx, enum machine_mode)); extern int and_operand PARAMS ((rtx, enum machine_mode)); extern int count_register_operand PARAMS ((rtx, enum machine_mode)); --- 60,65 ---- *************** extern int boolean_or_operator PARAMS (( *** 85,91 **** extern int min_max_operator PARAMS ((rtx, enum machine_mode)); extern int includes_lshift_p PARAMS ((rtx, rtx)); extern int includes_rshift_p PARAMS ((rtx, rtx)); ! extern int includes_lshift64_p PARAMS ((rtx, rtx)); extern int registers_ok_for_quad_peep PARAMS ((rtx, rtx)); extern int addrs_ok_for_quad_peep PARAMS ((rtx, rtx)); extern enum reg_class secondary_reload_class PARAMS ((enum reg_class, --- 85,92 ---- extern int min_max_operator PARAMS ((rtx, enum machine_mode)); extern int includes_lshift_p PARAMS ((rtx, rtx)); extern int includes_rshift_p PARAMS ((rtx, rtx)); ! extern int includes_rldic_lshift_p PARAMS ((rtx, rtx)); ! extern int includes_rldicr_lshift_p PARAMS ((rtx, rtx)); extern int registers_ok_for_quad_peep PARAMS ((rtx, rtx)); extern int addrs_ok_for_quad_peep PARAMS ((rtx, rtx)); extern enum reg_class secondary_reload_class PARAMS ((enum reg_class, diff -Nrc3pad gcc-3.0.1/gcc/config/rs6000/rs6000.c gcc-3.0.2/gcc/config/rs6000/rs6000.c *** gcc-3.0.1/gcc/config/rs6000/rs6000.c Sat Jul 14 15:50:30 2001 --- gcc-3.0.2/gcc/config/rs6000/rs6000.c Tue Sep 25 10:59:04 2001 *************** reg_or_logical_cint_operand (op, mode) *** 749,755 **** return gpc_reg_operand (op, mode); } ! /* Return 1 if the operand is an operand that can be loaded via the GOT */ int got_operand (op, mode) --- 749,766 ---- return gpc_reg_operand (op, mode); } ! /* Return 1 if the operand is valid for SCC eq. */ ! ! int ! scc_eq_operand (op, mode) ! register rtx op; ! enum machine_mode mode ATTRIBUTE_UNUSED; ! { ! return (short_cint_operand (op, mode) ! || reg_or_logical_cint_operand (op, mode)); ! } ! ! /* Return 1 if the operand is an operand that can be loaded via the GOT. */ int got_operand (op, mode) *************** mask_operand (op, mode) *** 1089,1114 **** register rtx op; enum machine_mode mode ATTRIBUTE_UNUSED; { ! HOST_WIDE_INT c; ! int i; ! int last_bit_value; ! int transitions = 0; if (GET_CODE (op) != CONST_INT) return 0; c = INTVAL (op); ! if (c == 0 || c == ~0) return 0; ! last_bit_value = c & 1; ! for (i = 1; i < 32; i++) ! if (((c >>= 1) & 1) != last_bit_value) ! last_bit_value ^= 1, transitions++; ! return transitions <= 2; } /* Return 1 if the operand is a constant that is a PowerPC64 mask. --- 1100,1135 ---- register rtx op; enum machine_mode mode ATTRIBUTE_UNUSED; { ! HOST_WIDE_INT c, lsb; if (GET_CODE (op) != CONST_INT) return 0; c = INTVAL (op); ! /* We don't change the number of transitions by inverting, ! so make sure we start with the LS bit zero. */ ! if (c & 1) ! c = ~c; ! ! /* Reject all zeros or all ones. */ ! if (c == 0) return 0; ! /* Find the first transition. */ ! lsb = c & -c; ! /* Invert to look for a second transition. */ ! c = ~c; ! /* Erase first transition. */ ! c &= -lsb; ! ! /* Find the second transition (if any). */ ! lsb = c & -c; ! ! /* Match if all the bits above are 1's (or c is zero). */ ! return c == -lsb; } /* Return 1 if the operand is a constant that is a PowerPC64 mask. *************** mask64_operand (op, mode) *** 1123,1255 **** { if (GET_CODE (op) == CONST_INT) { ! HOST_WIDE_INT c = INTVAL (op); ! int i; ! int last_bit_value; ! int transitions = 0; ! ! if (c == 0 || c == ~0) ! return 0; ! ! last_bit_value = c & 1; ! ! for (i = 1; i < HOST_BITS_PER_WIDE_INT; i++) ! if (((c >>= 1) & 1) != last_bit_value) ! last_bit_value ^= 1, transitions++; ! ! return transitions <= 1; ! } ! else if (GET_CODE (op) == CONST_DOUBLE ! && (mode == VOIDmode || mode == DImode)) ! { ! HOST_WIDE_INT low = CONST_DOUBLE_LOW (op); ! #if HOST_BITS_PER_WIDE_INT == 32 ! HOST_WIDE_INT high = CONST_DOUBLE_HIGH (op); ! #endif ! int i; ! int last_bit_value; ! int transitions = 0; ! ! if ((low == 0 ! #if HOST_BITS_PER_WIDE_INT == 32 ! && high == 0 ! #endif ! ) ! || (low == ~0 ! #if HOST_BITS_PER_WIDE_INT == 32 ! && high == ~0 ! #endif ! )) ! return 0; ! ! last_bit_value = low & 1; ! ! for (i = 1; i < HOST_BITS_PER_WIDE_INT; i++) ! if (((low >>= 1) & 1) != last_bit_value) ! last_bit_value ^= 1, transitions++; ! ! #if HOST_BITS_PER_WIDE_INT == 32 ! if ((high & 1) != last_bit_value) ! last_bit_value ^= 1, transitions++; ! ! for (i = 1; i < HOST_BITS_PER_WIDE_INT; i++) ! if (((high >>= 1) & 1) != last_bit_value) ! last_bit_value ^= 1, transitions++; ! #endif ! ! return transitions <= 1; ! } ! else ! return 0; ! } ! ! /* Return 1 if the operand is a constant that is a PowerPC64 mask. ! It is if there are no more than two 1->0 or 0->1 transitions. ! Reject all ones and all zeros, since these should have been optimized ! away and confuse the making of MB and ME. */ ! int ! rldic_operand (op, mode) ! register rtx op; ! enum machine_mode mode; ! { ! if (GET_CODE (op) == CONST_INT) ! { ! HOST_WIDE_INT c = INTVAL (op); ! int i; ! int last_bit_value; ! int transitions = 0; ! if (c == 0 || c == ~0) return 0; ! last_bit_value = c & 1; ! ! for (i = 1; i < HOST_BITS_PER_WIDE_INT; i++) ! if (((c >>= 1) & 1) != last_bit_value) ! last_bit_value ^= 1, transitions++; ! ! return transitions <= 2; } else if (GET_CODE (op) == CONST_DOUBLE && (mode == VOIDmode || mode == DImode)) { ! HOST_WIDE_INT low = CONST_DOUBLE_LOW (op); ! #if HOST_BITS_PER_WIDE_INT == 32 ! HOST_WIDE_INT high = CONST_DOUBLE_HIGH (op); ! #endif ! int i; ! int last_bit_value; ! int transitions = 0; ! ! if ((low == 0 ! #if HOST_BITS_PER_WIDE_INT == 32 ! && high == 0 ! #endif ! ) ! || (low == ~0 ! #if HOST_BITS_PER_WIDE_INT == 32 ! && high == ~0 ! #endif ! )) ! return 0; ! last_bit_value = low & 1; ! for (i = 1; i < HOST_BITS_PER_WIDE_INT; i++) ! if (((low >>= 1) & 1) != last_bit_value) ! last_bit_value ^= 1, transitions++; ! #if HOST_BITS_PER_WIDE_INT == 32 ! if ((high & 1) != last_bit_value) ! last_bit_value ^= 1, transitions++; ! for (i = 1; i < HOST_BITS_PER_WIDE_INT; i++) ! if (((high >>= 1) & 1) != last_bit_value) ! last_bit_value ^= 1, transitions++; ! #endif ! return transitions <= 2; } else return 0; --- 1144,1192 ---- { if (GET_CODE (op) == CONST_INT) { ! HOST_WIDE_INT c, lsb; ! /* We don't change the number of transitions by inverting, ! so make sure we start with the LS bit zero. */ ! c = INTVAL (op); ! if (c & 1) ! c = ~c; ! /* Reject all zeros or all ones. */ ! if (c == 0) return 0; ! /* Find the transition, and check that all bits above are 1's. */ ! lsb = c & -c; ! return c == -lsb; } else if (GET_CODE (op) == CONST_DOUBLE && (mode == VOIDmode || mode == DImode)) { ! HOST_WIDE_INT low, high, lsb; ! if (HOST_BITS_PER_WIDE_INT < 64) ! high = CONST_DOUBLE_HIGH (op); ! low = CONST_DOUBLE_LOW (op); ! if (low & 1) ! { ! if (HOST_BITS_PER_WIDE_INT < 64) ! high = ~high; ! low = ~low; ! } ! if (low == 0) ! { ! if (HOST_BITS_PER_WIDE_INT >= 64 || high == 0) ! return 0; ! lsb = high & -high; ! return high == -lsb; ! } ! lsb = low & -low; ! return low == -lsb && (HOST_BITS_PER_WIDE_INT >= 64 || high == ~0); } else return 0; *************** lwa_operand (op, mode) *** 1312,1318 **** return gpc_reg_operand (inner, mode) || (memory_operand (inner, mode) && GET_CODE (XEXP (inner, 0)) != PRE_INC ! && GET_CODE (XEXP (inner, 0)) != PRE_DEC); } /* Return 1 if the operand, used inside a MEM, is a valid first argument --- 1249,1258 ---- return gpc_reg_operand (inner, mode) || (memory_operand (inner, mode) && GET_CODE (XEXP (inner, 0)) != PRE_INC ! && GET_CODE (XEXP (inner, 0)) != PRE_DEC ! && (GET_CODE (XEXP (inner, 0)) != PLUS ! || GET_CODE (XEXP (XEXP (inner, 0), 1)) != CONST_INT ! || INTVAL (XEXP (XEXP (inner, 0), 1)) % 4 == 0)); } /* Return 1 if the operand, used inside a MEM, is a valid first argument *************** includes_rshift_p (shiftop, andop) *** 3481,3516 **** return (INTVAL (andop) & ~shift_mask) == 0; } ! /* Return 1 if ANDOP is a mask that has no bits on that are not in the ! mask required to convert the result of a rotate insn into a shift ! left insn of SHIFTOP bits. */ int ! includes_lshift64_p (shiftop, andop) register rtx shiftop; register rtx andop; { ! #if HOST_BITS_PER_WIDE_INT == 64 ! unsigned HOST_WIDE_INT shift_mask = ~(unsigned HOST_WIDE_INT) 0; ! shift_mask <<= INTVAL (shiftop); ! return (INTVAL (andop) & ~shift_mask) == 0; ! #else ! unsigned HOST_WIDE_INT shift_mask_low = ~(unsigned HOST_WIDE_INT) 0; ! unsigned HOST_WIDE_INT shift_mask_high = ~(unsigned HOST_WIDE_INT) 0; ! shift_mask_low <<= INTVAL (shiftop); ! if (INTVAL (shiftop) > 32) ! shift_mask_high <<= (INTVAL (shiftop) - 32); if (GET_CODE (andop) == CONST_INT) ! return (INTVAL (andop) & ~shift_mask_low) == 0; else ! return ((CONST_DOUBLE_HIGH (andop) & ~shift_mask_high) == 0 ! && (CONST_DOUBLE_LOW (andop) & ~shift_mask_low) == 0); ! #endif } /* Return 1 if REGNO (reg1) == REGNO (reg2) - 1 making them candidates --- 3421,3591 ---- return (INTVAL (andop) & ~shift_mask) == 0; } ! /* Return 1 if ANDOP is a mask suitable for use with an rldic insn ! to perform a left shift. It must have exactly SHIFTOP least ! signifigant 0's, then one or more 1's, then zero or more 0's. */ int ! includes_rldic_lshift_p (shiftop, andop) register rtx shiftop; register rtx andop; { ! if (GET_CODE (andop) == CONST_INT) ! { ! HOST_WIDE_INT c, lsb, shift_mask; ! c = INTVAL (andop); ! if (c == 0 || c == ~0) ! return 0; ! shift_mask = ~0; ! shift_mask <<= INTVAL (shiftop); ! /* Find the least signifigant one bit. */ ! lsb = c & -c; ! /* It must coincide with the LSB of the shift mask. */ ! if (-lsb != shift_mask) ! return 0; ! ! /* Invert to look for the next transition (if any). */ ! c = ~c; ! ! /* Remove the low group of ones (originally low group of zeros). */ ! c &= -lsb; ! ! /* Again find the lsb, and check we have all 1's above. */ ! lsb = c & -c; ! return c == -lsb; ! } ! else if (GET_CODE (andop) == CONST_DOUBLE ! && (GET_MODE (andop) == VOIDmode || GET_MODE (andop) == DImode)) ! { ! HOST_WIDE_INT low, high, lsb; ! HOST_WIDE_INT shift_mask_low, shift_mask_high; ! ! low = CONST_DOUBLE_LOW (andop); ! if (HOST_BITS_PER_WIDE_INT < 64) ! high = CONST_DOUBLE_HIGH (andop); ! ! if ((low == 0 && (HOST_BITS_PER_WIDE_INT >= 64 || high == 0)) ! || (low == ~0 && (HOST_BITS_PER_WIDE_INT >= 64 || high == ~0))) ! return 0; ! ! if (HOST_BITS_PER_WIDE_INT < 64 && low == 0) ! { ! shift_mask_high = ~0; ! if (INTVAL (shiftop) > 32) ! shift_mask_high <<= INTVAL (shiftop) - 32; ! ! lsb = high & -high; ! ! if (-lsb != shift_mask_high || INTVAL (shiftop) < 32) ! return 0; ! ! high = ~high; ! high &= -lsb; ! ! lsb = high & -high; ! return high == -lsb; ! } ! ! shift_mask_low = ~0; ! shift_mask_low <<= INTVAL (shiftop); ! ! lsb = low & -low; ! ! if (-lsb != shift_mask_low) ! return 0; ! ! if (HOST_BITS_PER_WIDE_INT < 64) ! high = ~high; ! low = ~low; ! low &= -lsb; ! ! if (HOST_BITS_PER_WIDE_INT < 64 && low == 0) ! { ! lsb = high & -high; ! return high == -lsb; ! } ! ! lsb = low & -low; ! return low == -lsb && (HOST_BITS_PER_WIDE_INT >= 64 || high == ~0); ! } ! else ! return 0; ! } ! ! /* Return 1 if ANDOP is a mask suitable for use with an rldicr insn ! to perform a left shift. It must have SHIFTOP or more least ! signifigant 0's, with the remainder of the word 1's. */ + int + includes_rldicr_lshift_p (shiftop, andop) + register rtx shiftop; + register rtx andop; + { if (GET_CODE (andop) == CONST_INT) ! { ! HOST_WIDE_INT c, lsb, shift_mask; ! ! shift_mask = ~0; ! shift_mask <<= INTVAL (shiftop); ! c = INTVAL (andop); ! ! /* Find the least signifigant one bit. */ ! lsb = c & -c; ! ! /* It must be covered by the shift mask. ! This test also rejects c == 0. */ ! if ((lsb & shift_mask) == 0) ! return 0; ! ! /* Check we have all 1's above the transition, and reject all 1's. */ ! return c == -lsb && lsb != 1; ! } ! else if (GET_CODE (andop) == CONST_DOUBLE ! && (GET_MODE (andop) == VOIDmode || GET_MODE (andop) == DImode)) ! { ! HOST_WIDE_INT low, lsb, shift_mask_low; ! ! low = CONST_DOUBLE_LOW (andop); ! ! if (HOST_BITS_PER_WIDE_INT < 64) ! { ! HOST_WIDE_INT high, shift_mask_high; ! ! high = CONST_DOUBLE_HIGH (andop); ! ! if (low == 0) ! { ! shift_mask_high = ~0; ! if (INTVAL (shiftop) > 32) ! shift_mask_high <<= INTVAL (shiftop) - 32; ! ! lsb = high & -high; ! ! if ((lsb & shift_mask_high) == 0) ! return 0; ! ! return high == -lsb; ! } ! if (high != ~0) ! return 0; ! } ! ! shift_mask_low = ~0; ! shift_mask_low <<= INTVAL (shiftop); ! ! lsb = low & -low; ! ! if ((lsb & shift_mask_low) == 0) ! return 0; ! ! return low == -lsb && lsb != 1; ! } else ! return 0; } /* Return 1 if REGNO (reg1) == REGNO (reg2) - 1 making them candidates *************** print_operand (file, x, code) *** 4314,4322 **** case 'W': /* MB value for a PowerPC64 rldic operand. */ - if (! rldic_operand (x, VOIDmode)) - output_operand_lossage ("invalid %%W value"); - val = (GET_CODE (x) == CONST_INT ? INTVAL (x) : CONST_DOUBLE_HIGH (x)); --- 4389,4394 ---- *************** rs6000_emit_prologue () *** 6098,6106 **** to understand '(unspec:SI [(reg:CC 68) ...] 19)'. But that's OK. All we have to do is specify that _one_ condition code register is saved in this stack slot. The thrower's epilogue ! will then restore all the call-saved registers. */ rs6000_frame_related (insn, frame_ptr_rtx, info->total_size, ! cr_save_rtx, gen_rtx_REG (SImode, CR0_REGNO)); } /* Update stack and set back pointer unless this is V.4, --- 6170,6179 ---- to understand '(unspec:SI [(reg:CC 68) ...] 19)'. But that's OK. All we have to do is specify that _one_ condition code register is saved in this stack slot. The thrower's epilogue ! will then restore all the call-saved registers. ! We use CR2_REGNO (70) to be compatible with gcc-2.95 on Linux. */ rs6000_frame_related (insn, frame_ptr_rtx, info->total_size, ! cr_save_rtx, gen_rtx_REG (SImode, CR2_REGNO)); } /* Update stack and set back pointer unless this is V.4, *************** rs6000_adjust_priority (insn, priority) *** 7657,7663 **** } /* Return how many instructions the machine can issue per cycle */ ! int get_issue_rate() { switch (rs6000_cpu_attr) { case CPU_RIOS1: /* ? */ --- 7730,7737 ---- } /* Return how many instructions the machine can issue per cycle */ ! int ! get_issue_rate () { switch (rs6000_cpu_attr) { case CPU_RIOS1: /* ? */ *************** rs6000_initialize_trampoline (addr, fnad *** 7735,7741 **** rtx fn_reg = gen_reg_rtx (pmode); rtx toc_reg = gen_reg_rtx (pmode); emit_move_insn (fn_reg, MEM_DEREF (fnaddr)); ! emit_move_insn (toc_reg, MEM_PLUS (fnaddr, 4)); emit_move_insn (MEM_DEREF (addr), fn_reg); emit_move_insn (MEM_PLUS (addr, regsize), toc_reg); emit_move_insn (MEM_PLUS (addr, 2*regsize), ctx_reg); --- 7809,7815 ---- rtx fn_reg = gen_reg_rtx (pmode); rtx toc_reg = gen_reg_rtx (pmode); emit_move_insn (fn_reg, MEM_DEREF (fnaddr)); ! emit_move_insn (toc_reg, MEM_PLUS (fnaddr, regsize)); emit_move_insn (MEM_DEREF (addr), fn_reg); emit_move_insn (MEM_PLUS (addr, regsize), toc_reg); emit_move_insn (MEM_PLUS (addr, 2*regsize), ctx_reg); diff -Nrc3pad gcc-3.0.1/gcc/config/rs6000/rs6000.h gcc-3.0.2/gcc/config/rs6000/rs6000.h *** gcc-3.0.1/gcc/config/rs6000/rs6000.h Sat Jul 14 15:50:30 2001 --- gcc-3.0.2/gcc/config/rs6000/rs6000.h Mon Sep 10 11:06:28 2001 *************** do { \ *** 2678,2683 **** --- 2678,2684 ---- {"reg_or_add_cint64_operand", {SUBREG, REG, CONST_INT}}, \ {"reg_or_sub_cint64_operand", {SUBREG, REG, CONST_INT}}, \ {"reg_or_logical_cint_operand", {SUBREG, REG, CONST_INT, CONST_DOUBLE}}, \ + {"scc_eq_operand", {SUBREG, REG, CONST_INT, CONST_DOUBLE}}, \ {"got_operand", {SYMBOL_REF, CONST, LABEL_REF}}, \ {"got_no_const_operand", {SYMBOL_REF, LABEL_REF}}, \ {"easy_fp_constant", {CONST_DOUBLE}}, \ *************** do { \ *** 2695,2701 **** {"non_logical_cint_operand", {CONST_INT, CONST_DOUBLE}}, \ {"mask_operand", {CONST_INT}}, \ {"mask64_operand", {CONST_INT, CONST_DOUBLE}}, \ - {"rldic_operand", {CONST_INT, CONST_DOUBLE}}, \ {"count_register_operand", {REG}}, \ {"xer_operand", {REG}}, \ {"call_operand", {SYMBOL_REF, REG}}, \ --- 2696,2701 ---- diff -Nrc3pad gcc-3.0.1/gcc/config/rs6000/rs6000.md gcc-3.0.2/gcc/config/rs6000/rs6000.md *** gcc-3.0.1/gcc/config/rs6000/rs6000.md Sat Jul 14 15:50:31 2001 --- gcc-3.0.2/gcc/config/rs6000/rs6000.md Mon Sep 10 11:06:29 2001 *************** *** 6558,6565 **** [(set (match_operand:DI 0 "gpc_reg_operand" "=r") (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "r") (match_operand:SI 2 "const_int_operand" "i")) ! (match_operand:DI 3 "rldic_operand" "n")))] ! "TARGET_POWERPC64 && includes_lshift64_p (operands[2], operands[3])" "rldic %0,%1,%H2,%W3") (define_insn "ashldi3_internal5" --- 6558,6565 ---- [(set (match_operand:DI 0 "gpc_reg_operand" "=r") (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "r") (match_operand:SI 2 "const_int_operand" "i")) ! (match_operand:DI 3 "const_int_operand" "n")))] ! "TARGET_POWERPC64 && includes_rldic_lshift_p (operands[2], operands[3])" "rldic %0,%1,%H2,%W3") (define_insn "ashldi3_internal5" *************** *** 6567,6576 **** (compare:CC (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "r,r") (match_operand:SI 2 "const_int_operand" "i,i")) ! (match_operand:DI 3 "rldic_operand" "n,n")) (const_int 0))) (clobber (match_scratch:DI 4 "=r,r"))] ! "TARGET_POWERPC64 && includes_lshift64_p (operands[2], operands[3])" "@ rldic. %4,%1,%H2,%W3 #" --- 6567,6576 ---- (compare:CC (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "r,r") (match_operand:SI 2 "const_int_operand" "i,i")) ! (match_operand:DI 3 "const_int_operand" "n,n")) (const_int 0))) (clobber (match_scratch:DI 4 "=r,r"))] ! "TARGET_POWERPC64 && includes_rldic_lshift_p (operands[2], operands[3])" "@ rldic. %4,%1,%H2,%W3 #" *************** *** 6582,6591 **** (compare:CC (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "") (match_operand:SI 2 "const_int_operand" "")) ! (match_operand:DI 3 "rldic_operand" "")) (const_int 0))) (clobber (match_scratch:DI 4 ""))] ! "TARGET_POWERPC64 && includes_lshift64_p (operands[2], operands[3]) && reload_completed" [(set (match_dup 4) (and:DI (ashift:DI (match_dup 1) (match_dup 2)) (match_dup 3))) --- 6582,6592 ---- (compare:CC (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "") (match_operand:SI 2 "const_int_operand" "")) ! (match_operand:DI 3 "const_int_operand" "")) (const_int 0))) (clobber (match_scratch:DI 4 ""))] ! "TARGET_POWERPC64 && reload_completed ! && includes_rldic_lshift_p (operands[2], operands[3])" [(set (match_dup 4) (and:DI (ashift:DI (match_dup 1) (match_dup 2)) (match_dup 3))) *************** *** 6599,6609 **** (compare:CC (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "r,r") (match_operand:SI 2 "const_int_operand" "i,i")) ! (match_operand:DI 3 "rldic_operand" "n,n")) (const_int 0))) (set (match_operand:DI 0 "gpc_reg_operand" "=r,r") (and:DI (ashift:DI (match_dup 1) (match_dup 2)) (match_dup 3)))] ! "TARGET_POWERPC64 && includes_lshift64_p (operands[2], operands[3])" "@ rldic. %0,%1,%H2,%W3 #" --- 6600,6610 ---- (compare:CC (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "r,r") (match_operand:SI 2 "const_int_operand" "i,i")) ! (match_operand:DI 3 "const_int_operand" "n,n")) (const_int 0))) (set (match_operand:DI 0 "gpc_reg_operand" "=r,r") (and:DI (ashift:DI (match_dup 1) (match_dup 2)) (match_dup 3)))] ! "TARGET_POWERPC64 && includes_rldic_lshift_p (operands[2], operands[3])" "@ rldic. %0,%1,%H2,%W3 #" *************** *** 6615,6625 **** (compare:CC (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "") (match_operand:SI 2 "const_int_operand" "")) ! (match_operand:DI 3 "rldic_operand" "")) (const_int 0))) (set (match_operand:DI 0 "gpc_reg_operand" "") (and:DI (ashift:DI (match_dup 1) (match_dup 2)) (match_dup 3)))] ! "TARGET_POWERPC64 && includes_lshift64_p (operands[2], operands[3]) && reload_completed" [(set (match_dup 0) (and:DI (ashift:DI (match_dup 1) (match_dup 2)) (match_dup 3))) --- 6616,6703 ---- (compare:CC (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "") (match_operand:SI 2 "const_int_operand" "")) ! (match_operand:DI 3 "const_int_operand" "")) (const_int 0))) (set (match_operand:DI 0 "gpc_reg_operand" "") (and:DI (ashift:DI (match_dup 1) (match_dup 2)) (match_dup 3)))] ! "TARGET_POWERPC64 && reload_completed ! && includes_rldic_lshift_p (operands[2], operands[3])" ! [(set (match_dup 0) ! (and:DI (ashift:DI (match_dup 1) (match_dup 2)) ! (match_dup 3))) ! (set (match_dup 4) ! (compare:CC (match_dup 0) ! (const_int 0)))] ! "") ! ! (define_insn "*ashldi3_internal7" ! [(set (match_operand:DI 0 "gpc_reg_operand" "=r") ! (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "r") ! (match_operand:SI 2 "const_int_operand" "i")) ! (match_operand:DI 3 "mask64_operand" "S")))] ! "TARGET_POWERPC64 && includes_rldicr_lshift_p (operands[2], operands[3])" ! "rldicr %0,%1,%H2,%S3") ! ! (define_insn "ashldi3_internal8" ! [(set (match_operand:CC 0 "cc_reg_operand" "=x,?y") ! (compare:CC ! (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "r,r") ! (match_operand:SI 2 "const_int_operand" "i,i")) ! (match_operand:DI 3 "mask64_operand" "S,S")) ! (const_int 0))) ! (clobber (match_scratch:DI 4 "=r,r"))] ! "TARGET_POWERPC64 && includes_rldicr_lshift_p (operands[2], operands[3])" ! "@ ! rldicr. %4,%1,%H2,%S3 ! #" ! [(set_attr "type" "delayed_compare") ! (set_attr "length" "4,8")]) ! ! (define_split ! [(set (match_operand:CC 0 "cc_reg_not_cr0_operand" "") ! (compare:CC ! (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "") ! (match_operand:SI 2 "const_int_operand" "")) ! (match_operand:DI 3 "mask64_operand" "")) ! (const_int 0))) ! (clobber (match_scratch:DI 4 ""))] ! "TARGET_POWERPC64 && reload_completed ! && includes_rldicr_lshift_p (operands[2], operands[3])" ! [(set (match_dup 4) ! (and:DI (ashift:DI (match_dup 1) (match_dup 2)) ! (match_dup 3))) ! (set (match_dup 0) ! (compare:CC (match_dup 4) ! (const_int 0)))] ! "") ! ! (define_insn "*ashldi3_internal9" ! [(set (match_operand:CC 4 "cc_reg_operand" "=x,?y") ! (compare:CC ! (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "r,r") ! (match_operand:SI 2 "const_int_operand" "i,i")) ! (match_operand:DI 3 "mask64_operand" "S,S")) ! (const_int 0))) ! (set (match_operand:DI 0 "gpc_reg_operand" "=r,r") ! (and:DI (ashift:DI (match_dup 1) (match_dup 2)) (match_dup 3)))] ! "TARGET_POWERPC64 && includes_rldicr_lshift_p (operands[2], operands[3])" ! "@ ! rldicr. %0,%1,%H2,%S3 ! #" ! [(set_attr "type" "delayed_compare") ! (set_attr "length" "4,8")]) ! ! (define_split ! [(set (match_operand:CC 4 "cc_reg_not_cr0_operand" "") ! (compare:CC ! (and:DI (ashift:DI (match_operand:DI 1 "gpc_reg_operand" "") ! (match_operand:SI 2 "const_int_operand" "")) ! (match_operand:DI 3 "mask64_operand" "")) ! (const_int 0))) ! (set (match_operand:DI 0 "gpc_reg_operand" "") ! (and:DI (ashift:DI (match_dup 1) (match_dup 2)) (match_dup 3)))] ! "TARGET_POWERPC64 && reload_completed ! && includes_rldicr_lshift_p (operands[2], operands[3])" [(set (match_dup 0) (and:DI (ashift:DI (match_dup 1) (match_dup 2)) (match_dup 3))) *************** operands[2] = GEN_INT (INTVAL (operands[ *** 10182,10188 **** (define_insn "" [(set (match_operand:DI 0 "gpc_reg_operand" "=r,r,r,r,r") (eq:DI (match_operand:DI 1 "gpc_reg_operand" "%r,r,r,r,r") ! (match_operand:DI 2 "reg_or_cint_operand" "r,O,K,J,I"))) (clobber (match_scratch:DI 3 "=r,&r,r,r,r"))] "TARGET_POWERPC64" "@ --- 10260,10266 ---- (define_insn "" [(set (match_operand:DI 0 "gpc_reg_operand" "=r,r,r,r,r") (eq:DI (match_operand:DI 1 "gpc_reg_operand" "%r,r,r,r,r") ! (match_operand:DI 2 "scc_eq_operand" "r,O,K,J,I"))) (clobber (match_scratch:DI 3 "=r,&r,r,r,r"))] "TARGET_POWERPC64" "@ *************** operands[2] = GEN_INT (INTVAL (operands[ *** 10239,10245 **** [(set (match_operand:CC 4 "cc_reg_operand" "=x,x,x,x,x,?y,?y,?y,?y,?y") (compare:CC (eq:DI (match_operand:DI 1 "gpc_reg_operand" "%r,r,r,r,r,r,r,r,r,r") ! (match_operand:DI 2 "reg_or_cint_operand" "r,O,K,J,I,r,O,K,J,I")) (const_int 0))) (set (match_operand:DI 0 "gpc_reg_operand" "=r,r,r,r,r,r,r,r,r,r") (eq:DI (match_dup 1) (match_dup 2))) --- 10317,10323 ---- [(set (match_operand:CC 4 "cc_reg_operand" "=x,x,x,x,x,?y,?y,?y,?y,?y") (compare:CC (eq:DI (match_operand:DI 1 "gpc_reg_operand" "%r,r,r,r,r,r,r,r,r,r") ! (match_operand:DI 2 "scc_eq_operand" "r,O,K,J,I,r,O,K,J,I")) (const_int 0))) (set (match_operand:DI 0 "gpc_reg_operand" "=r,r,r,r,r,r,r,r,r,r") (eq:DI (match_dup 1) (match_dup 2))) *************** operands[2] = GEN_INT (INTVAL (operands[ *** 10263,10269 **** [(set (match_operand:CC 4 "cc_reg_not_cr0_operand" "") (compare:CC (eq:DI (match_operand:DI 1 "gpc_reg_operand" "") ! (match_operand:DI 2 "reg_or_cint_operand" "")) (const_int 0))) (set (match_operand:DI 0 "gpc_reg_operand" "") (eq:DI (match_dup 1) (match_dup 2))) --- 10341,10347 ---- [(set (match_operand:CC 4 "cc_reg_not_cr0_operand" "") (compare:CC (eq:DI (match_operand:DI 1 "gpc_reg_operand" "") ! (match_operand:DI 2 "scc_eq_operand" "")) (const_int 0))) (set (match_operand:DI 0 "gpc_reg_operand" "") (eq:DI (match_dup 1) (match_dup 2))) diff -Nrc3pad gcc-3.0.1/gcc/config/rs6000/t-aix43 gcc-3.0.2/gcc/config/rs6000/t-aix43 *** gcc-3.0.1/gcc/config/rs6000/t-aix43 Sun Jan 7 13:55:10 2001 --- gcc-3.0.2/gcc/config/rs6000/t-aix43 Mon Sep 10 13:53:11 2001 *************** SHLIB_LINK = $(GCC_FOR_TARGET) $(LIBGCC2 *** 62,68 **** rm -f @multilib_dir@/shr.o # $(slibdir) double quoted to protect it from expansion while building # libgcc.mk. We want this delayed until actual install time. ! SHLIB_INSTALL = $(INSTALL_DATA) @shlib_base_name@.a $$(slibdir)/ SHLIB_LIBS = -lc `case @shlib_base_name@ in *pthread*) echo -lpthread ;; esac` SHLIB_MKMAP = $(srcdir)/mkmap-flat.awk SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver --- 62,70 ---- rm -f @multilib_dir@/shr.o # $(slibdir) double quoted to protect it from expansion while building # libgcc.mk. We want this delayed until actual install time. ! # Install the shared library without read-other permission so that it ! # is loaded into the process private segment. ! SHLIB_INSTALL = $(INSTALL) -m 751 @shlib_base_name@.a $$(slibdir)/ SHLIB_LIBS = -lc `case @shlib_base_name@ in *pthread*) echo -lpthread ;; esac` SHLIB_MKMAP = $(srcdir)/mkmap-flat.awk SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver diff -Nrc3pad gcc-3.0.1/gcc/config/s390/s390-protos.h gcc-3.0.2/gcc/config/s390/s390-protos.h *** gcc-3.0.1/gcc/config/s390/s390-protos.h Fri Aug 3 11:50:11 2001 --- gcc-3.0.2/gcc/config/s390/s390-protos.h Sat Sep 29 15:48:08 2001 *************** extern int bras_sym_operand PARAMS ((rtx *** 39,44 **** --- 39,45 ---- extern int dead_p PARAMS ((rtx, rtx)); extern void print_operand PARAMS ((FILE *, rtx, char)); extern void print_operand_address PARAMS ((FILE *, rtx)); + extern int legitimate_la_operand_p PARAMS ((rtx)); extern int legitimate_pic_operand_p PARAMS ((rtx)); extern int legitimate_constant_p PARAMS ((rtx)); diff -Nrc3pad gcc-3.0.1/gcc/config/s390/s390.c gcc-3.0.2/gcc/config/s390/s390.c *** gcc-3.0.1/gcc/config/s390/s390.c Fri Aug 10 15:19:19 2001 --- gcc-3.0.2/gcc/config/s390/s390.c Sat Sep 29 15:48:08 2001 *************** legitimate_address_p (mode, addr, strict *** 813,818 **** --- 813,852 ---- return s390_decompose_address (addr, NULL, strict); } + /* Return 1 if OP is a valid operand for the LA instruction. + In 31-bit, we need to prove that the result is used as an + address, as LA performs only a 31-bit addition. */ + + int + legitimate_la_operand_p (op) + register rtx op; + { + struct s390_address addr; + if (!s390_decompose_address (op, &addr, FALSE)) + return FALSE; + + if (TARGET_64BIT) + return TRUE; + + /* Use of the base or stack pointer implies address. */ + + if (addr.base && GET_CODE (addr.base) == REG) + { + if (REGNO (addr.base) == BASE_REGISTER + || REGNO (addr.base) == STACK_POINTER_REGNUM) + return TRUE; + } + + if (addr.indx && GET_CODE (addr.indx) == REG) + { + if (REGNO (addr.indx) == BASE_REGISTER + || REGNO (addr.indx) == STACK_POINTER_REGNUM) + return TRUE; + } + + return FALSE; + } + /* Return a legitimate reference for ORIG (an address) using the register REG. If REG is 0, a new pseudo is generated. *************** legitimize_address (x, oldx, mode) *** 1130,1137 **** register rtx oldx ATTRIBUTE_UNUSED; enum machine_mode mode; { ! if (flag_pic && SYMBOLIC_CONST (x)) ! return legitimize_pic_address (x, 0); return x; } --- 1164,1210 ---- register rtx oldx ATTRIBUTE_UNUSED; enum machine_mode mode; { ! rtx constant_term = const0_rtx; ! ! if (flag_pic) ! { ! if (SYMBOLIC_CONST (x) ! || (GET_CODE (x) == PLUS ! && (SYMBOLIC_CONST (XEXP (x, 0)) ! || SYMBOLIC_CONST (XEXP (x, 1))))) ! x = legitimize_pic_address (x, 0); ! ! if (legitimate_address_p (mode, x, FALSE)) ! return x; ! } ! ! x = eliminate_constant_term (x, &constant_term); ! ! if (GET_CODE (x) == PLUS) ! { ! if (GET_CODE (XEXP (x, 0)) == REG) ! { ! register rtx temp = gen_reg_rtx (Pmode); ! register rtx val = force_operand (XEXP (x, 1), temp); ! if (val != temp) ! emit_move_insn (temp, val); ! ! x = gen_rtx_PLUS (Pmode, XEXP (x, 0), temp); ! } ! ! else if (GET_CODE (XEXP (x, 1)) == REG) ! { ! register rtx temp = gen_reg_rtx (Pmode); ! register rtx val = force_operand (XEXP (x, 0), temp); ! if (val != temp) ! emit_move_insn (temp, val); ! ! x = gen_rtx_PLUS (Pmode, temp, XEXP (x, 1)); ! } ! } ! ! if (constant_term != const0_rtx) ! x = gen_rtx_PLUS (Pmode, x, constant_term); return x; } *************** s390_adjust_cost (rtx insn, rtx link, rt *** 1522,1534 **** if (recog_memoized (insn) < 0 || recog_memoized (dep_insn) < 0) return cost; - /* If cost equal 1 nothing needs to be checked. */ - - if (cost == 1) - { - return cost; - } - dep_rtx = PATTERN (dep_insn); if (GET_CODE (dep_rtx) == SET) --- 1595,1600 ---- *************** s390_adjust_cost (rtx insn, rtx link, rt *** 1542,1548 **** debug_rtx (dep_insn); debug_rtx (insn); } ! return cost; } } --- 1608,1614 ---- debug_rtx (dep_insn); debug_rtx (insn); } ! return cost + 4; } } *************** s390_adjust_cost (rtx insn, rtx link, rt *** 1560,1572 **** debug_rtx (dep_insn); debug_rtx (insn); } ! return cost; } } } /* default cost. */ ! return 1; } /* Pool concept for Linux 390: --- 1626,1638 ---- debug_rtx (dep_insn); debug_rtx (insn); } ! return cost + 4; } } } /* default cost. */ ! return cost; } /* Pool concept for Linux 390: *************** s390_function_prologue (FILE * file, int *** 2381,2388 **** /* Decrement stack. */ ! if (TARGET_BACKCHAIN || (STARTING_FRAME_OFFSET + ! lsize + STACK_POINTER_OFFSET > 4095 || frame_pointer_needed || current_function_calls_alloca)) { --- 2447,2453 ---- /* Decrement stack. */ ! if (TARGET_BACKCHAIN || (frame_size + STACK_POINTER_OFFSET > 4095 || frame_pointer_needed || current_function_calls_alloca)) { *************** s390_function_prologue (FILE * file, int *** 2422,2429 **** /* Generate backchain. */ ! if (TARGET_BACKCHAIN || (STARTING_FRAME_OFFSET + ! lsize + STACK_POINTER_OFFSET > 4095 || frame_pointer_needed || current_function_calls_alloca)) { --- 2487,2493 ---- /* Generate backchain. */ ! if (TARGET_BACKCHAIN || (frame_size + STACK_POINTER_OFFSET > 4095 || frame_pointer_needed || current_function_calls_alloca)) { diff -Nrc3pad gcc-3.0.1/gcc/config/s390/s390.md gcc-3.0.2/gcc/config/s390/s390.md *** gcc-3.0.1/gcc/config/s390/s390.md Fri Aug 10 15:19:19 2001 --- gcc-3.0.2/gcc/config/s390/s390.md Sat Sep 29 15:48:08 2001 *************** *** 77,126 **** (define_attr "type" "set,xset,la" (const_string "xset")) ; ! ; Set operations changing a target register, which could be used for ! ; address generation. Adjust cost will check, if realy applicable. ! ; ! ! (define_function_unit "memory" 1 0 ! (and (eq_attr "type" "set") ! (eq_attr "cycle" "1")) ! 5 1 [(eq_attr "atype" "mem")] ) ! ! (define_function_unit "memory" 1 0 ! (and (eq_attr "type" "set") ! (eq_attr "cycle" "2")) 5 2) ! ! (define_function_unit "memory" 1 0 ! (and (eq_attr "type" "set") ! (eq_attr "cycle" "3")) 5 3) ! ! (define_function_unit "memory" 1 0 ! (and (eq_attr "type" "set") ! (eq_attr "cycle" "n")) 5 4) ! ! (define_function_unit "memory" 1 0 ! (eq_attr "type" "la") 2 1) ! ; - ; xset insns, which don't set any valid address register. - ; Only the issue delay matters. - ; (define_function_unit "memory" 1 0 ! (and (eq_attr "type" "xset") ! (eq_attr "cycle" "1")) 1 1) (define_function_unit "memory" 1 0 ! (and (eq_attr "type" "xset") ! (eq_attr "cycle" "2")) 1 2) (define_function_unit "memory" 1 0 ! (and (eq_attr "type" "xset") ! (eq_attr "cycle" "3")) 1 3) (define_function_unit "memory" 1 0 ! (and (eq_attr "type" "xset") ! (eq_attr "cycle" "n")) 1 4) ; Operand type. Used to default length attribute values --- 77,97 ---- (define_attr "type" "set,xset,la" (const_string "xset")) ; ! ; Dummy function unit. We only care for the cycle count. ! ; Everthing else is done by ADJUST_COST. ; (define_function_unit "memory" 1 0 ! (eq_attr "cycle" "1") 1 1) (define_function_unit "memory" 1 0 ! (eq_attr "cycle" "2") 2 2) (define_function_unit "memory" 1 0 ! (eq_attr "cycle" "3") 3 3) (define_function_unit "memory" 1 0 ! (eq_attr "cycle" "n") 4 4) ; Operand type. Used to default length attribute values *************** *** 387,393 **** (define_insn "*cmpsi_cct" [(set (reg 33) ! (compare (zero_extract:SI (match_operand:SI 0 "register_operand" "%d") (match_operand:SI 1 "const1_operand" "") (match_operand:SI 2 "immediate_operand" "I")) (const_int 0)))] --- 358,364 ---- (define_insn "*cmpsi_cct" [(set (reg 33) ! (compare (zero_extract:SI (match_operand:SI 0 "register_operand" "d") (match_operand:SI 1 "const1_operand" "") (match_operand:SI 2 "immediate_operand" "I")) (const_int 0)))] *************** *** 900,905 **** --- 871,889 ---- if (flag_pic && SYMBOLIC_CONST (operands[1])) emit_pic_move (operands, SImode); + + /* expr.c tries to load an effective address using + force_reg. This fails because we don't have a + generic load_address pattern. Convert the move + to a proper arithmetic operation instead, unless + it is guaranteed to be OK. */ + if (GET_CODE (operands[1]) == PLUS + && !legitimate_la_operand_p (operands[1])) + { + operands[1] = force_operand (operands[1], operands[0]); + if (operands[1] == operands[0]) + DONE; + } }") (define_insn "*movsi" *************** *** 2973,3052 **** (set_attr "atype" "mem") (set_attr "type" "la")]) - (define_insn "*addaddr_picR" - [(set (match_operand:SI 0 "register_operand" "=d") - (plus:SI (match_operand:SI 1 "register_operand" "a") - (unspec:SI [(match_operand:SI 2 "register_operand" "a")] 101)))] - "" - "la\\t%0,0(%1,%2)" - [(set_attr "op_type" "RX") - (set_attr "atype" "mem") - (set_attr "type" "la")]) - - (define_insn "*addaddr_picL" - [(set (match_operand:SI 0 "register_operand" "=d") - (plus:SI (unspec:SI [(match_operand:SI 2 "register_operand" "a")] 101) - (match_operand:SI 1 "register_operand" "a")))] - "" - "la\\t%0,0(%1,%2)" - [(set_attr "op_type" "RX") - (set_attr "atype" "mem") - (set_attr "type" "la")]) - - (define_insn "*addaddr_picN" - [(set (match_operand:SI 0 "register_operand" "=d") - (unspec:SI [(match_operand:SI 1 "register_operand" "a")] 101))] - "" - "la\\t%0,0(%1)" - [(set_attr "op_type" "RX") - (set_attr "atype" "mem") - (set_attr "type" "la")]) - - (define_insn "*addsi3_cc" - [(set (reg 33) - (compare (plus:SI (match_operand:SI 1 "register_operand" "%0,0,0") - (match_operand:SI 2 "general_operand" "d,K,m")) - (const_int 0))) - (set (match_operand:SI 0 "register_operand" "=d,d,d") - (plus:SI (match_dup 1) (match_dup 2)))] - "s390_match_ccmode(insn, CCSmode)" - "@ - ar\\t%0,%2 - ahi\\t%0,%h2 - a\\t%0,%2" - [(set_attr "op_type" "RR,RI,RX") - (set_attr "atype" "reg,reg,mem") - (set_attr "type" "set")]) - - (define_insn "*addsi3_cconly" - [(set (reg 33) - (compare (plus:SI (match_operand:SI 1 "register_operand" "%0,0,0") - (match_operand:SI 2 "general_operand" "d,K,m")) - (const_int 0))) - (clobber (match_scratch:SI 0 "=d,d,d"))] - "s390_match_ccmode(insn, CCSmode)" - "@ - ar\\t%0,%2 - ahi\\t%0,%h2 - a\\t%0,%2" - [(set_attr "op_type" "RR,RI,RX") - (set_attr "atype" "reg,reg,mem") - (set_attr "type" "set")]) - - (define_insn "*addsi3_cconly2" - [(set (reg 33) - (compare (match_operand:SI 1 "register_operand" "%0,0,0") - (neg:SI (match_operand:SI 2 "general_operand" "d,K,m")))) - (clobber (match_scratch:SI 0 "=d,d,d"))] - "s390_match_ccmode(insn, CCSmode)" - "@ - ar\\t%0,%2 - ahi\\t%0,%h2 - a\\t%0,%2" - [(set_attr "op_type" "RR,RI,RX") - (set_attr "atype" "reg,reg,mem") - (set_attr "type" "set")]) - (define_insn "addsi3" [(set (match_operand:SI 0 "register_operand" "=d,d,d") (plus:SI (match_operand:SI 1 "register_operand" "%0,0,0") --- 2957,2962 ---- *************** *** 3061,3070 **** (set_attr "atype" "reg,reg,mem") (set_attr "type" "set")]) ! (define_insn "do_la" [(set (match_operand:SI 0 "register_operand" "=a") (match_operand:QI 1 "address_operand" "p"))] ! "volatile_ok" "la\\t%0,%a1" [(set_attr "op_type" "RX") (set_attr "atype" "mem") --- 2971,2981 ---- (set_attr "atype" "reg,reg,mem") (set_attr "type" "set")]) ! (define_insn "*do_la" [(set (match_operand:SI 0 "register_operand" "=a") (match_operand:QI 1 "address_operand" "p"))] ! "reload_in_progress || reload_completed ! || legitimate_la_operand_p (operands[1])" "la\\t%0,%a1" [(set_attr "op_type" "RX") (set_attr "atype" "mem") *************** *** 3074,3080 **** [(set (match_operand:SI 0 "register_operand" "=d") (plus:SI (match_operand:SI 1 "register_operand" "%0") (match_operand:SI 2 "register_operand" "d")))] ! "" "brxle\\t%0,%2,.+4" [(set_attr "op_type" "RSI") (set_attr "atype" "reg") --- 2985,2991 ---- [(set (match_operand:SI 0 "register_operand" "=d") (plus:SI (match_operand:SI 1 "register_operand" "%0") (match_operand:SI 2 "register_operand" "d")))] ! "reload_in_progress || reload_completed" "brxle\\t%0,%2,.+4" [(set_attr "op_type" "RSI") (set_attr "atype" "reg") *************** *** 3284,3318 **** ; ; subsi3 instruction pattern(s). ; - - (define_insn "*subsi3_cc" - [(set (reg 33) - (compare (minus:SI (match_operand:SI 1 "register_operand" "0,0") - (match_operand:SI 2 "general_operand" "d,m")) - (const_int 0))) - (set (match_operand:SI 0 "register_operand" "=d,d") - (minus:SI (match_dup 1) (match_dup 2)))] - "s390_match_ccmode(insn, CCSmode)" - "@ - sr\\t%0,%2 - s\\t%0,%2" - [(set_attr "op_type" "RR,RX") - (set_attr "atype" "reg,mem") - (set_attr "type" "set")]) - - (define_insn "*subsi3_cconly" - [(set (reg 33) - (compare (minus:SI (match_operand:SI 1 "register_operand" "0,0") - (match_operand:SI 2 "general_operand" "d,m")) - (const_int 0))) - (clobber (match_scratch:SI 0 "=d,d"))] - "s390_match_ccmode(insn, CCSmode)" - "@ - sr\\t%0,%2 - s\\t%0,%2" - [(set_attr "op_type" "RR,RX") - (set_attr "atype" "reg,mem") - (set_attr "type" "set")]) (define_insn "subsi3" [(set (match_operand:SI 0 "register_operand" "=d,d") --- 3195,3200 ---- diff -Nrc3pad gcc-3.0.1/gcc/config/sh/sh.c gcc-3.0.2/gcc/config/sh/sh.c *** gcc-3.0.1/gcc/config/sh/sh.c Tue Jun 26 04:08:31 2001 --- gcc-3.0.2/gcc/config/sh/sh.c Thu Sep 20 07:11:01 2001 *************** shiftcosts (x) *** 1005,1010 **** --- 1005,1020 ---- { int value; + if (GET_MODE_SIZE (GET_MODE (x)) > UNITS_PER_WORD) + { + if (GET_MODE (x) == DImode + && GET_CODE (XEXP (x, 1)) == CONST_INT + && INTVAL (XEXP (x, 1)) == 1) + return 2; + + /* Everything else is invalid, because there is no pattern for it. */ + return 10000; + } /* If shift by a non constant, then this will be expensive. */ if (GET_CODE (XEXP (x, 1)) != CONST_INT) return SH_DYNAMIC_SHIFT_COST; *************** initial_elimination_offset (from, to) *** 4538,4543 **** --- 4548,4560 ---- int save_flags = target_flags; int live_regs_mask, live_regs_mask2; + + if (from == RETURN_ADDRESS_POINTER_REGNUM) + /* Kludge: since we assume that the return address is on the stack, + make it so. N.B. We rely on RETURN_ADDRESS_POINTER_REGNUM being + processed before ARG_POINTER_REGNUM here. */ + regs_ever_live[PR_REG] = 1; + live_regs_mask = calc_live_regs (®s_saved, &live_regs_mask2); total_auto_space = rounded_frame_size (regs_saved); target_flags = save_flags; *************** initial_elimination_offset (from, to) *** 4556,4568 **** if (from == RETURN_ADDRESS_POINTER_REGNUM && (to == FRAME_POINTER_REGNUM || to == STACK_POINTER_REGNUM)) ! { ! int i, n = total_saved_regs_space; ! for (i = PR_REG-1; i >= 0; i--) ! if (live_regs_mask & (1 << i)) ! n -= 4; ! return n + total_auto_space; ! } abort (); } --- 4573,4579 ---- if (from == RETURN_ADDRESS_POINTER_REGNUM && (to == FRAME_POINTER_REGNUM || to == STACK_POINTER_REGNUM)) ! return total_auto_space; abort (); } diff -Nrc3pad gcc-3.0.1/gcc/config/sparc/linux.h gcc-3.0.2/gcc/config/sparc/linux.h *** gcc-3.0.1/gcc/config/sparc/linux.h Mon Apr 16 11:25:52 2001 --- gcc-3.0.2/gcc/config/sparc/linux.h Wed Sep 5 01:55:14 2001 *************** Boston, MA 02111-1307, USA. */ *** 32,37 **** --- 32,41 ---- #define MULTIBYTE_CHARS 1 #endif + /* The GNU C++ standard library requires that these macros be defined. */ + #undef CPLUSPLUS_CPP_SPEC + #define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE %(cpp)" + #ifndef USE_GNULIBC_1 #undef DEFAULT_VTABLE_THUNKS #define DEFAULT_VTABLE_THUNKS 1 diff -Nrc3pad gcc-3.0.1/gcc/config/sparc/linux64.h gcc-3.0.2/gcc/config/sparc/linux64.h *** gcc-3.0.1/gcc/config/sparc/linux64.h Mon Apr 16 11:25:52 2001 --- gcc-3.0.2/gcc/config/sparc/linux64.h Wed Sep 5 01:55:14 2001 *************** Boston, MA 02111-1307, USA. */ *** 26,31 **** --- 26,35 ---- /* Don't assume anything about the header files. */ #define NO_IMPLICIT_EXTERN_C + /* The GNU C++ standard library requires that these macros be defined. */ + #undef CPLUSPLUS_CPP_SPEC + #define CPLUSPLUS_CPP_SPEC "-D_GNU_SOURCE %(cpp)" + #undef DEFAULT_VTABLE_THUNKS #define DEFAULT_VTABLE_THUNKS 1 diff -Nrc3pad gcc-3.0.1/gcc/config.gcc gcc-3.0.2/gcc/config.gcc *** gcc-3.0.1/gcc/config.gcc Mon Aug 13 08:34:14 2001 --- gcc-3.0.2/gcc/config.gcc Tue Oct 9 17:25:25 2001 *************** i[34567]86-*-mingw32*) *** 1497,1506 **** fi exeext=.exe case $machine in ! *mingw32msv*) ! ;; ! *minwg32crt* | *mingw32*) tm_file="${tm_file} i386/crtdll.h" ;; esac ;; --- 1497,1506 ---- fi exeext=.exe case $machine in ! *mingw32crt*) tm_file="${tm_file} i386/crtdll.h" + ;; + *minwg32msv* | *mingw32*) ;; esac ;; diff -Nrc3pad gcc-3.0.1/gcc/cp/ChangeLog gcc-3.0.2/gcc/cp/ChangeLog *** gcc-3.0.1/gcc/cp/ChangeLog Sun Aug 19 14:08:14 2001 --- gcc-3.0.2/gcc/cp/ChangeLog Tue Oct 23 10:19:31 2001 *************** *** 1,3 **** --- 1,64 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + + 2001-10-03 John David Anglin + + * rtti.c (get_tinfo_decl): Call typeinfo_in_lib_p with the type used + to build the declaration instead of the declaration itself. + + 2001-09-28 Craig Rodrigues + + PR c++/4095 + * rtti.c (create_pseudo_type_info): Fix parameter. + + 2001-09-21 Richard Henderson + + * class.c (set_vindex): Mind TARGET_VTABLE_USES_DESCRIPTORS. + (build_vtbl_initializer): Likewise. + (build_vfn_ref): New. + * cp-tree.h: Declare it. + * call.c (build_over_call): Use it. + * decl2.c (mark_vtable_entries): Mark FDESC_EXPR. + * typeck.c (get_member_function_from_ptrfunc): Mind descriptors. + * rtti.c (get_tinfo_decl_dynamic): Use build_vtbl_ref instead + of build_vfn_ref. + + 2001-09-15 Gabriel Dos Reis + + * Make-lang.in (cp/error.o): Depend on real.h + * error.c: #include "real.h" + + 2001-09-06 Nathan Sidwell + + PR c++/3986 + * class.c (force_canonical_binfo_r): Check & move an indirect + primary base first. + (force_canonical_binfo): Check that it's not already + canonical. + (mark_primary_virtual_base): Remove BINFO parameter. + (mark_primary_bases): Adjust, set BINFO_LOST_PRIMARY_P here. + + (binfo_ctor_vtable): Add prototype. + (get_primary_binfo): Initialize RESULT. + + 2001-09-04 Nathan Sidwell + + PR c++/4203 + * call.c (build_over_call): Do not optimize any empty base + construction. + + 2001-08-30 Kurt Garloff + + * optimize.c (inlinable_function_p): Allow only smaller single + functions. Halve inline limit after reaching recursive limit. + + 2001-08-23 Kriang Lerdsuwanakij + + * pt.c (maybe_fold_nontype_arg): Use TREE_TYPE of ARG as the + criterion to avoid rebuilding expression tree instead of + processing_template_decl. + 2001-08-19 Release Manager * GCC 3.0.1 Released. *************** *** 101,107 **** * cvt.c (convert_lvalue): New fn. * cp-tree.h: Declare it. * method.c (do_build_assign_ref): Use it. ! (do_build_copy_constructor): Convert parm to base types before calling base constructors. 2001-07-25 Nathan Sidwell --- 162,168 ---- * cvt.c (convert_lvalue): New fn. * cp-tree.h: Declare it. * method.c (do_build_assign_ref): Use it. ! (do_build_copy_constructor): Convert parm to base types before calling base constructors. 2001-07-25 Nathan Sidwell *************** *** 121,127 **** params.h. 2001-07-18 Xavier Delacour , ! Gerald Pfeifer * NEWS (Changes in GCC 3.0): Fix typo. --- 182,188 ---- params.h. 2001-07-18 Xavier Delacour , ! Gerald Pfeifer * NEWS (Changes in GCC 3.0): Fix typo. *************** *** 160,166 **** 20010617 Release Manager ! * GCC 3.0 Released. 2001-06-14 Jason Merrill --- 221,227 ---- 20010617 Release Manager ! * GCC 3.0 Released. 2001-06-14 Jason Merrill *************** *** 433,494 **** EH merge from mainline: 2001-04-23 Jason Merrill ! * except.c (build_throw): Wrap the initialization of the exception ! object in a MUST_NOT_THROW_EXPR. ! (do_free_exception): #if 0. ! * cp-tree.def (EH_SPEC_BLOCK): New. ! (MUST_NOT_THROW_EXPR): New. ! * cp-tree.h: Update changed function declarations. ! (CPTI_PUSH_EXCEPTION_IDENTIFIER): Remove. ! (CPTI_CALL_UNEXPECTED): New. ! (struct cp_language_function): Rename x_eh_spec_try_block ! to x_eh_spec_block. ! (EH_SPEC_STMTS, EH_SPEC_RAISES): New. ! * decl.c (current_binding_level): If no current function ! bindings, revert to scope_chain. ! (initialize_predefined_identifiers): Remove __cp_push_exception. ! (store_parm_decls): Use begin_eh_spec_block. ! (finish_function): Use finish_eh_spec_block. ! (mark_lang_function): Update for name changes. ! * decl2.c (finish_file): No mark_all_runtime_matches. ! * dump.c (cp_dump_tree): Handle new tree codes. ! * error.c (dump_expr) [BIND_EXPR]: Fix typo. ! * except.c (catch_language_init, catch_language): Remove. ! (init_exception_processing): Don't set language code. ! Initialize call_unexpected_node, protect_cleanup_actions, ! eh_personality_libfunc, lang_eh_runtime_type. ! (call_eh_info, push_eh_info, get_eh_info, get_eh_value): Remove. ! (get_eh_type, get_eh_caught, get_eh_handlers): Remove. ! (prepare_eh_type): Split out type canonicalizations ... ! (build_eh_type_type): ... from here. ! (build_eh_type_type_ref): Remove. ! (mark_all_runtime_matches): Remove. ! (build_exc_ptr): New. ! (do_begin_catch, do_end_catch): New. ! (do_pop_exception): Remove. ! (build_terminate_handler): Remove. ! (choose_personality_routine): Split out language choice from ... ! (initialize_handler_parm): ... here. ! Use MUST_NOT_THROW_EXPR. ! (expand_start_catch_block): Use do_begin_catch. Simplify Java ! exception object handling. ! (expand_start_eh_spec, expand_end_eh_spec): Remove. ! (expand_exception_blocks, alloc_eh_object): Remove. ! (begin_eh_spec_block, finish_eh_spec_block): New. ! (do_allocate_exception, do_free_exception): New. ! (expand_throw): Merge into ... ! (build_throw): ... here. Update for abi. ! * expr.c (cplus_expand_expr): No expand_internal_throw. ! Handle MUST_NOT_THROW_EXPR. ! * pt.c (tsubst_expr): Handle EH_SPEC_BLOCK. ! * semantics.c (*) Update for except.h name changes. ! (genrtl_try_block): No protect_with_terminate. ! (genrtl_eh_spec_block): New. ! (genrtl_handler): Don't emit the goto here. ! (cp_expand_stmt): Handle EH_SPEC_BLOCK. ! (genrtl_finish_function): Don't expand_exception_blocks. ! * tree.c (cp_statement_code_p): Handle EH_SPEC_BLOCK. * decl.c (struct named_label_list): Rename eh_region to in_try_scope, add in_catch_scope. --- 494,555 ---- EH merge from mainline: 2001-04-23 Jason Merrill ! * except.c (build_throw): Wrap the initialization of the exception ! object in a MUST_NOT_THROW_EXPR. ! (do_free_exception): #if 0. ! * cp-tree.def (EH_SPEC_BLOCK): New. ! (MUST_NOT_THROW_EXPR): New. ! * cp-tree.h: Update changed function declarations. ! (CPTI_PUSH_EXCEPTION_IDENTIFIER): Remove. ! (CPTI_CALL_UNEXPECTED): New. ! (struct cp_language_function): Rename x_eh_spec_try_block ! to x_eh_spec_block. ! (EH_SPEC_STMTS, EH_SPEC_RAISES): New. ! * decl.c (current_binding_level): If no current function ! bindings, revert to scope_chain. ! (initialize_predefined_identifiers): Remove __cp_push_exception. ! (store_parm_decls): Use begin_eh_spec_block. ! (finish_function): Use finish_eh_spec_block. ! (mark_lang_function): Update for name changes. ! * decl2.c (finish_file): No mark_all_runtime_matches. ! * dump.c (cp_dump_tree): Handle new tree codes. ! * error.c (dump_expr) [BIND_EXPR]: Fix typo. ! * except.c (catch_language_init, catch_language): Remove. ! (init_exception_processing): Don't set language code. ! Initialize call_unexpected_node, protect_cleanup_actions, ! eh_personality_libfunc, lang_eh_runtime_type. ! (call_eh_info, push_eh_info, get_eh_info, get_eh_value): Remove. ! (get_eh_type, get_eh_caught, get_eh_handlers): Remove. ! (prepare_eh_type): Split out type canonicalizations ... ! (build_eh_type_type): ... from here. ! (build_eh_type_type_ref): Remove. ! (mark_all_runtime_matches): Remove. ! (build_exc_ptr): New. ! (do_begin_catch, do_end_catch): New. ! (do_pop_exception): Remove. ! (build_terminate_handler): Remove. ! (choose_personality_routine): Split out language choice from ... ! (initialize_handler_parm): ... here. ! Use MUST_NOT_THROW_EXPR. ! (expand_start_catch_block): Use do_begin_catch. Simplify Java ! exception object handling. ! (expand_start_eh_spec, expand_end_eh_spec): Remove. ! (expand_exception_blocks, alloc_eh_object): Remove. ! (begin_eh_spec_block, finish_eh_spec_block): New. ! (do_allocate_exception, do_free_exception): New. ! (expand_throw): Merge into ... ! (build_throw): ... here. Update for abi. ! * expr.c (cplus_expand_expr): No expand_internal_throw. ! Handle MUST_NOT_THROW_EXPR. ! * pt.c (tsubst_expr): Handle EH_SPEC_BLOCK. ! * semantics.c (*) Update for except.h name changes. ! (genrtl_try_block): No protect_with_terminate. ! (genrtl_eh_spec_block): New. ! (genrtl_handler): Don't emit the goto here. ! (cp_expand_stmt): Handle EH_SPEC_BLOCK. ! (genrtl_finish_function): Don't expand_exception_blocks. ! * tree.c (cp_statement_code_p): Handle EH_SPEC_BLOCK. * decl.c (struct named_label_list): Rename eh_region to in_try_scope, add in_catch_scope. diff -Nrc3pad gcc-3.0.1/gcc/cp/Make-lang.in gcc-3.0.2/gcc/cp/Make-lang.in *** gcc-3.0.1/gcc/cp/Make-lang.in Fri Jul 20 12:29:06 2001 --- gcc-3.0.2/gcc/cp/Make-lang.in Fri Sep 21 18:33:22 2001 *************** cp/lex.o: cp/lex.c $(CXX_TREE_H) cp/pars *** 241,247 **** toplev.h output.h mbchar.h $(GGC_H) input.h diagnostic.h cp/operators.def \ $(TM_P_H) cp/decl.o: cp/decl.c $(CXX_TREE_H) flags.h cp/lex.h cp/decl.h stack.h \ ! output.h $(EXPR_H) except.h toplev.h hash.h $(GGC_H) $(RTL_H) cp/operators.def cp/decl2.o: cp/decl2.c $(CXX_TREE_H) flags.h cp/lex.h cp/decl.h $(EXPR_H) \ output.h except.h toplev.h dwarf2out.h dwarfout.h $(GGC_H) $(RTL_H) cp/typeck2.o: cp/typeck2.c $(CXX_TREE_H) flags.h toplev.h output.h $(TM_P_H) --- 241,248 ---- toplev.h output.h mbchar.h $(GGC_H) input.h diagnostic.h cp/operators.def \ $(TM_P_H) cp/decl.o: cp/decl.c $(CXX_TREE_H) flags.h cp/lex.h cp/decl.h stack.h \ ! output.h $(EXPR_H) except.h toplev.h hash.h $(GGC_H) $(RTL_H) \ ! $(TM_P_H) cp/operators.def cp/decl2.o: cp/decl2.c $(CXX_TREE_H) flags.h cp/lex.h cp/decl.h $(EXPR_H) \ output.h except.h toplev.h dwarf2out.h dwarfout.h $(GGC_H) $(RTL_H) cp/typeck2.o: cp/typeck2.c $(CXX_TREE_H) flags.h toplev.h output.h $(TM_P_H) *************** cp/expr.o: cp/expr.c $(CXX_TREE_H) $(RTL *** 266,272 **** cp/xref.o: cp/xref.c $(CXX_TREE_H) input.h toplev.h cp/pt.o: cp/pt.c $(CXX_TREE_H) cp/decl.h cp/parse.h cp/lex.h toplev.h \ $(GGC_H) $(RTL_H) except.h ! cp/error.o: cp/error.c $(CXX_TREE_H) toplev.h diagnostic.h cp/errfn.o: cp/errfn.c $(CXX_TREE_H) toplev.h cp/repo.o: cp/repo.c $(CXX_TREE_H) toplev.h $(GGC_H) cp/semantics.o: cp/semantics.c $(CXX_TREE_H) cp/lex.h except.h toplev.h \ --- 267,273 ---- cp/xref.o: cp/xref.c $(CXX_TREE_H) input.h toplev.h cp/pt.o: cp/pt.c $(CXX_TREE_H) cp/decl.h cp/parse.h cp/lex.h toplev.h \ $(GGC_H) $(RTL_H) except.h ! cp/error.o: cp/error.c $(CXX_TREE_H) toplev.h diagnostic.h real.h cp/errfn.o: cp/errfn.c $(CXX_TREE_H) toplev.h cp/repo.o: cp/repo.c $(CXX_TREE_H) toplev.h $(GGC_H) cp/semantics.o: cp/semantics.c $(CXX_TREE_H) cp/lex.h except.h toplev.h \ diff -Nrc3pad gcc-3.0.1/gcc/cp/call.c gcc-3.0.2/gcc/cp/call.c *** gcc-3.0.1/gcc/cp/call.c Mon Aug 13 13:54:14 2001 --- gcc-3.0.2/gcc/cp/call.c Tue Sep 4 06:03:03 2001 *************** build_over_call (cand, args, flags) *** 4244,4257 **** else if (TYPE_HAS_TRIVIAL_INIT_REF (DECL_CONTEXT (fn))) return build_target_expr_with_type (arg, DECL_CONTEXT (fn)); } ! else if (! real_lvalue_p (arg) /* Empty classes have padding which can be hidden inside an (empty) base of the class. This must not be touched as it might overlay things. When the gcc core learns about empty classes, we can treat it like other classes. */ ! || (!is_empty_class (DECL_CONTEXT (fn)) ! && TYPE_HAS_TRIVIAL_INIT_REF (DECL_CONTEXT (fn)))) { tree address; tree to = stabilize_reference --- 4244,4257 ---- else if (TYPE_HAS_TRIVIAL_INIT_REF (DECL_CONTEXT (fn))) return build_target_expr_with_type (arg, DECL_CONTEXT (fn)); } ! else if ((!real_lvalue_p (arg) ! || TYPE_HAS_TRIVIAL_INIT_REF (DECL_CONTEXT (fn))) /* Empty classes have padding which can be hidden inside an (empty) base of the class. This must not be touched as it might overlay things. When the gcc core learns about empty classes, we can treat it like other classes. */ ! && !is_empty_class (DECL_CONTEXT (fn))) { tree address; tree to = stabilize_reference diff -Nrc3pad gcc-3.0.1/gcc/cp/class.c gcc-3.0.2/gcc/cp/class.c *** gcc-3.0.1/gcc/cp/class.c Tue Aug 7 06:06:42 2001 --- gcc-3.0.2/gcc/cp/class.c Fri Sep 21 18:33:22 2001 *************** static void force_canonical_binfo_r PARA *** 195,207 **** static void force_canonical_binfo PARAMS ((tree, tree, tree, tree)); static tree dfs_unshared_virtual_bases PARAMS ((tree, void *)); static void mark_primary_bases PARAMS ((tree)); ! static tree mark_primary_virtual_base PARAMS ((tree, tree, tree)); static void clone_constructors_and_destructors PARAMS ((tree)); static tree build_clone PARAMS ((tree, tree)); static void update_vtable_entry_for_fn PARAMS ((tree, tree, tree, tree *)); static tree copy_virtuals PARAMS ((tree)); static void build_ctor_vtbl_group PARAMS ((tree, tree)); static void build_vtt PARAMS ((tree)); static tree *build_vtt_inits PARAMS ((tree, tree, tree *, tree *)); static tree dfs_build_secondary_vptr_vtt_inits PARAMS ((tree, void *)); static tree dfs_ctor_vtable_bases_queue_p PARAMS ((tree, void *data)); --- 195,208 ---- static void force_canonical_binfo PARAMS ((tree, tree, tree, tree)); static tree dfs_unshared_virtual_bases PARAMS ((tree, void *)); static void mark_primary_bases PARAMS ((tree)); ! static tree mark_primary_virtual_base PARAMS ((tree, tree)); static void clone_constructors_and_destructors PARAMS ((tree)); static tree build_clone PARAMS ((tree, tree)); static void update_vtable_entry_for_fn PARAMS ((tree, tree, tree, tree *)); static tree copy_virtuals PARAMS ((tree)); static void build_ctor_vtbl_group PARAMS ((tree, tree)); static void build_vtt PARAMS ((tree)); + static tree binfo_ctor_vtable PARAMS ((tree)); static tree *build_vtt_inits PARAMS ((tree, tree, tree *, tree *)); static tree dfs_build_secondary_vptr_vtt_inits PARAMS ((tree, void *)); static tree dfs_ctor_vtable_bases_queue_p PARAMS ((tree, void *data)); *************** build_vtable_entry_ref (basetype, vtbl, *** 547,555 **** } /* Given an object INSTANCE, return an expression which yields the ! virtual function vtable element corresponding to INDEX. There are ! many special cases for INSTANCE which we take care of here, mainly ! to avoid creating extra tree nodes when we don't have to. */ tree build_vtbl_ref (instance, idx) --- 548,556 ---- } /* Given an object INSTANCE, return an expression which yields the ! vtable element corresponding to INDEX. There are many special ! cases for INSTANCE which we take care of here, mainly to avoid ! creating extra tree nodes when we don't have to. */ tree build_vtbl_ref (instance, idx) *************** build_vfn_ref (ptr_to_instptr, instance, *** 646,652 **** /* When using thunks, there is no extra delta, and we get the pfn directly. */ if (flag_vtable_thunks) ! return aref; if (ptr_to_instptr) { --- 647,661 ---- /* When using thunks, there is no extra delta, and we get the pfn directly. */ if (flag_vtable_thunks) ! { ! /* When using function descriptors, the address of the ! vtable entry is treated as a function pointer. */ ! if (TARGET_VTABLE_USES_DESCRIPTORS) ! return build1 (NOP_EXPR, TREE_TYPE (aref), ! build_unary_op (ADDR_EXPR, aref, /*noconvert=*/1)); ! ! return aref; ! } if (ptr_to_instptr) { *************** set_vindex (decl, vfuns_p) *** 1060,1066 **** { int vindex; ! vindex = (*vfuns_p)++; DECL_VINDEX (decl) = build_shared_int_cst (vindex); } --- 1069,1077 ---- { int vindex; ! vindex = *vfuns_p; ! *vfuns_p += (TARGET_VTABLE_USES_DESCRIPTORS ! ? TARGET_VTABLE_USES_DESCRIPTORS : 1); DECL_VINDEX (decl) = build_shared_int_cst (vindex); } *************** force_canonical_binfo_r (to, from, type, *** 1687,1693 **** tree mappings; { int i, n_baseclasses = BINFO_N_BASETYPES (from); ! BINFO_INDIRECT_PRIMARY_P (to) = BINFO_INDIRECT_PRIMARY_P (from); BINFO_INDIRECT_PRIMARY_P (from) = 0; --- 1698,1705 ---- tree mappings; { int i, n_baseclasses = BINFO_N_BASETYPES (from); ! ! my_friendly_assert (to != from, 20010905); BINFO_INDIRECT_PRIMARY_P (to) = BINFO_INDIRECT_PRIMARY_P (from); BINFO_INDIRECT_PRIMARY_P (from) = 0; *************** force_canonical_binfo_r (to, from, type, *** 1711,1721 **** my_friendly_assert (same_type_p (BINFO_TYPE (to), BINFO_TYPE (from)), 20010104); mappings = tree_cons (from, to, mappings); for (i = 0; i != n_baseclasses; i++) { tree from_binfo = BINFO_BASETYPE (from, i); tree to_binfo = BINFO_BASETYPE (to, i); ! if (TREE_VIA_VIRTUAL (from_binfo)) { if (BINFO_PRIMARY_P (from_binfo) && --- 1723,1744 ---- my_friendly_assert (same_type_p (BINFO_TYPE (to), BINFO_TYPE (from)), 20010104); mappings = tree_cons (from, to, mappings); + + if (CLASSTYPE_HAS_PRIMARY_BASE_P (BINFO_TYPE (from)) + && TREE_VIA_VIRTUAL (CLASSTYPE_PRIMARY_BINFO (BINFO_TYPE (from)))) + { + tree from_primary = get_primary_binfo (from); + + if (BINFO_PRIMARY_BASE_OF (from_primary) == from) + force_canonical_binfo (get_primary_binfo (to), from_primary, + type, mappings); + } + for (i = 0; i != n_baseclasses; i++) { tree from_binfo = BINFO_BASETYPE (from, i); tree to_binfo = BINFO_BASETYPE (to, i); ! if (TREE_VIA_VIRTUAL (from_binfo)) { if (BINFO_PRIMARY_P (from_binfo) && *************** force_canonical_binfo (to, from, type, m *** 1748,1764 **** { tree assoc = purpose_member (BINFO_TYPE (to), CLASSTYPE_VBASECLASSES (type)); ! TREE_VALUE (assoc) = to; ! force_canonical_binfo_r (to, from, type, mappings); } ! /* Make BASE_BINFO the primary virtual base of BINFO within the hierarchy ! dominated by TYPE. Returns BASE_BINFO, if it can be made so, NULL otherwise (because something else has already made it primary). */ static tree ! mark_primary_virtual_base (binfo, base_binfo, type) ! tree binfo; tree base_binfo; tree type; { --- 1771,1789 ---- { tree assoc = purpose_member (BINFO_TYPE (to), CLASSTYPE_VBASECLASSES (type)); ! if (TREE_VALUE (assoc) != to) ! { ! TREE_VALUE (assoc) = to; ! force_canonical_binfo_r (to, from, type, mappings); ! } } ! /* Make BASE_BINFO the a primary virtual base within the hierarchy ! dominated by TYPE. Returns BASE_BINFO, if it is not already one, NULL otherwise (because something else has already made it primary). */ static tree ! mark_primary_virtual_base (base_binfo, type) tree base_binfo; tree type; { *************** mark_primary_virtual_base (binfo, base_b *** 1769,1776 **** /* It's already allocated in the hierarchy. BINFO won't have a primary base in this hierachy, even though the complete object BINFO is for, would do. */ - BINFO_LOST_PRIMARY_P (binfo) = 1; - return NULL_TREE; } --- 1794,1799 ---- *************** mark_primary_bases (type) *** 1858,1867 **** base_binfo = get_primary_binfo (binfo); if (TREE_VIA_VIRTUAL (base_binfo)) ! base_binfo = mark_primary_virtual_base (binfo, base_binfo, type); if (base_binfo) BINFO_PRIMARY_BASE_OF (base_binfo) = binfo; BINFO_UNSHARED_MARKED (binfo) = 1; } --- 1881,1892 ---- base_binfo = get_primary_binfo (binfo); if (TREE_VIA_VIRTUAL (base_binfo)) ! base_binfo = mark_primary_virtual_base (base_binfo, type); if (base_binfo) BINFO_PRIMARY_BASE_OF (base_binfo) = binfo; + else + BINFO_LOST_PRIMARY_P (binfo) = 1; BINFO_UNSHARED_MARKED (binfo) = 1; } *************** get_primary_binfo (binfo) *** 6812,6818 **** tree binfo; { tree primary_base; ! tree result; tree virtuals; primary_base = CLASSTYPE_PRIMARY_BINFO (BINFO_TYPE (binfo)); --- 6837,6843 ---- tree binfo; { tree primary_base; ! tree result = NULL_TREE; tree virtuals; primary_base = CLASSTYPE_PRIMARY_BINFO (BINFO_TYPE (binfo)); *************** build_vtbl_initializer (binfo, orig_binf *** 7878,7884 **** } /* And add it to the chain of initializers. */ ! vfun_inits = tree_cons (NULL_TREE, init, vfun_inits); } /* The initializers for virtual functions were built up in reverse --- 7903,7927 ---- } /* And add it to the chain of initializers. */ ! if (TARGET_VTABLE_USES_DESCRIPTORS) ! { ! int i; ! if (init == size_zero_node) ! for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i) ! vfun_inits = tree_cons (NULL_TREE, init, vfun_inits); ! else ! for (i = 0; i < TARGET_VTABLE_USES_DESCRIPTORS; ++i) ! { ! tree fdesc = build (FDESC_EXPR, vfunc_ptr_type_node, ! TREE_OPERAND (init, 0), ! build_int_2 (i, 0)); ! TREE_CONSTANT (fdesc) = 1; ! ! vfun_inits = tree_cons (NULL_TREE, fdesc, vfun_inits); ! } ! } ! else ! vfun_inits = tree_cons (NULL_TREE, init, vfun_inits); } /* The initializers for virtual functions were built up in reverse diff -Nrc3pad gcc-3.0.1/gcc/cp/decl2.c gcc-3.0.2/gcc/cp/decl2.c *** gcc-3.0.1/gcc/cp/decl2.c Thu Aug 2 07:23:11 2001 --- gcc-3.0.2/gcc/cp/decl2.c Fri Sep 21 18:33:23 2001 *************** mark_vtable_entries (decl) *** 2268,2274 **** fnaddr = (flag_vtable_thunks ? TREE_VALUE (entries) : FNADDR_FROM_VTABLE_ENTRY (TREE_VALUE (entries))); ! if (TREE_CODE (fnaddr) != ADDR_EXPR) /* This entry is an offset: a virtual base class offset, a virtual call offset, and RTTI offset, etc. */ continue; --- 2268,2275 ---- fnaddr = (flag_vtable_thunks ? TREE_VALUE (entries) : FNADDR_FROM_VTABLE_ENTRY (TREE_VALUE (entries))); ! if (TREE_CODE (fnaddr) != ADDR_EXPR ! && TREE_CODE (fnaddr) != FDESC_EXPR) /* This entry is an offset: a virtual base class offset, a virtual call offset, and RTTI offset, etc. */ continue; diff -Nrc3pad gcc-3.0.1/gcc/cp/error.c gcc-3.0.2/gcc/cp/error.c *** gcc-3.0.1/gcc/cp/error.c Sun May 13 00:10:21 2001 --- gcc-3.0.2/gcc/cp/error.c Sat Sep 15 12:43:41 2001 *************** Boston, MA 02111-1307, USA. */ *** 23,28 **** --- 23,29 ---- #include "system.h" #include "tree.h" #include "cp-tree.h" + #include "real.h" #include "obstack.h" #include "toplev.h" #include "diagnostic.h" diff -Nrc3pad gcc-3.0.1/gcc/cp/optimize.c gcc-3.0.2/gcc/cp/optimize.c *** gcc-3.0.1/gcc/cp/optimize.c Tue Jun 5 00:47:06 2001 --- gcc-3.0.2/gcc/cp/optimize.c Thu Aug 30 07:43:42 2001 *************** inlinable_function_p (fn, id) *** 640,647 **** /* We can't inline varargs functions. */ else if (varargs_function_p (fn)) ; ! /* We can't inline functions that are too big. */ ! else if (DECL_NUM_STMTS (fn) * INSNS_PER_STMT > MAX_INLINE_INSNS) ; /* All is well. We can inline this function. Traditionally, GCC has refused to inline functions using alloca, or functions whose --- 640,648 ---- /* We can't inline varargs functions. */ else if (varargs_function_p (fn)) ; ! /* We can't inline functions that are too big. ! * Only allow a single function to eat up half of our budget. */ ! else if (DECL_NUM_STMTS (fn) * INSNS_PER_STMT > MAX_INLINE_INSNS / 2) ; /* All is well. We can inline this function. Traditionally, GCC has refused to inline functions using alloca, or functions whose *************** inlinable_function_p (fn, id) *** 655,663 **** /* Even if this function is not itself too big to inline, it might be that we've done so much inlining already that we don't want to ! risk inlining any more. */ ! if ((DECL_NUM_STMTS (fn) + id->inlined_stmts) * INSNS_PER_STMT ! > MAX_INLINE_INSNS) inlinable = 0; /* We can inline a template instantiation only if it's fully --- 656,665 ---- /* Even if this function is not itself too big to inline, it might be that we've done so much inlining already that we don't want to ! risk too much inlining any more and thus halve the acceptable size. */ ! if ((DECL_NUM_STMTS (fn) + id->inlined_stmts) * INSNS_PER_STMT ! > MAX_INLINE_INSNS ! && DECL_NUM_STMTS (fn) * INSNS_PER_STMT > MAX_INLINE_INSNS / 4) inlinable = 0; /* We can inline a template instantiation only if it's fully diff -Nrc3pad gcc-3.0.1/gcc/cp/parse.c gcc-3.0.2/gcc/cp/parse.c *** gcc-3.0.1/gcc/cp/parse.c Sun Aug 19 17:53:32 2001 --- gcc-3.0.2/gcc/cp/parse.c Tue Oct 23 10:57:18 2001 *************** *** 1,7 **** /* A Bison parser, made from parse.y ! by GNU Bison version 1.27 ! */ #define YYBISON 1 /* Identify Bison output. */ --- 1,6 ---- /* A Bison parser, made from parse.y ! by GNU Bison version 1.28 */ #define YYBISON 1 /* Identify Bison output. */ *************** static const short yycheck[] = { 4, *** 4133,4139 **** }; /* -*-C-*- Note some compilers choke on comments on `#line' lines. */ #line 3 "/usr/lib/bison.simple" ! /* This file comes from bison-1.27. */ /* Skeleton output parser for bison, Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. --- 4132,4138 ---- }; /* -*-C-*- Note some compilers choke on comments on `#line' lines. */ #line 3 "/usr/lib/bison.simple" ! /* This file comes from bison-1.28. */ /* Skeleton output parser for bison, Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. *************** __yy_memcpy (char *to, char *from, unsig *** 4346,4352 **** #endif #endif ! #line 216 "/usr/lib/bison.simple" /* The user can define YYPARSE_PARAM as the name of an argument to be passed into yyparse. The argument should have type void *. --- 4345,4351 ---- #endif #endif ! #line 217 "/usr/lib/bison.simple" /* The user can define YYPARSE_PARAM as the name of an argument to be passed into yyparse. The argument should have type void *. *************** case 917: *** 8578,8584 **** break;} } /* the action file gets copied in in place of this dollarsign */ ! #line 542 "/usr/lib/bison.simple" yyvsp -= yylen; yyssp -= yylen; --- 8577,8583 ---- break;} } /* the action file gets copied in in place of this dollarsign */ ! #line 543 "/usr/lib/bison.simple" yyvsp -= yylen; yyssp -= yylen; diff -Nrc3pad gcc-3.0.1/gcc/cp/pt.c gcc-3.0.2/gcc/cp/pt.c *** gcc-3.0.1/gcc/cp/pt.c Tue Jul 10 23:13:26 2001 --- gcc-3.0.2/gcc/cp/pt.c Thu Aug 23 06:50:35 2001 *************** static tree *** 5294,5305 **** maybe_fold_nontype_arg (arg) tree arg; { ! /* If we're not in a template, ARG is already as simple as it's going to ! get, and trying to reprocess the trees will break. */ ! if (! processing_template_decl) ! return arg; ! ! if (!TYPE_P (arg) && !uses_template_parms (arg)) { /* Sometimes, one of the args was an expression involving a template constant parameter, like N - 1. Now that we've --- 5294,5300 ---- maybe_fold_nontype_arg (arg) tree arg; { ! if (arg && !TYPE_P (arg) && !uses_template_parms (arg)) { /* Sometimes, one of the args was an expression involving a template constant parameter, like N - 1. Now that we've *************** maybe_fold_nontype_arg (arg) *** 5309,5318 **** fool build_expr_from_tree() into building an actual tree. */ ! int saved_processing_template_decl = processing_template_decl; ! processing_template_decl = 0; ! arg = fold (build_expr_from_tree (arg)); ! processing_template_decl = saved_processing_template_decl; } return arg; } --- 5304,5321 ---- fool build_expr_from_tree() into building an actual tree. */ ! /* If the TREE_TYPE of ARG is not NULL_TREE, ARG is already ! as simple as it's going to get, and trying to reprocess ! the trees will break. */ ! if (!TREE_TYPE (arg)) ! { ! int saved_processing_template_decl = processing_template_decl; ! processing_template_decl = 0; ! arg = build_expr_from_tree (arg); ! processing_template_decl = saved_processing_template_decl; ! } ! ! arg = fold (arg); } return arg; } diff -Nrc3pad gcc-3.0.1/gcc/cp/rtti.c gcc-3.0.2/gcc/cp/rtti.c *** gcc-3.0.1/gcc/cp/rtti.c Tue Apr 3 21:17:07 2001 --- gcc-3.0.2/gcc/cp/rtti.c Wed Oct 3 10:02:28 2001 *************** get_tinfo_decl_dynamic (exp) *** 238,244 **** /* The RTTI information is at index -1. */ index = integer_minus_one_node; ! t = build_vfn_ref ((tree *) 0, exp, index); TREE_TYPE (t) = build_pointer_type (tinfo_decl_type); return t; } --- 238,244 ---- /* The RTTI information is at index -1. */ index = integer_minus_one_node; ! t = build_vtbl_ref (exp, index); TREE_TYPE (t) = build_pointer_type (tinfo_decl_type); return t; } *************** get_tinfo_decl (type) *** 360,366 **** TREE_STATIC (d) = 1; DECL_EXTERNAL (d) = 1; TREE_PUBLIC (d) = 1; ! if (flag_weak || !typeinfo_in_lib_p (d)) comdat_linkage (d); SET_DECL_ASSEMBLER_NAME (d, name); cp_finish_decl (d, NULL_TREE, NULL_TREE, 0); --- 360,366 ---- TREE_STATIC (d) = 1; DECL_EXTERNAL (d) = 1; TREE_PUBLIC (d) = 1; ! if (flag_weak || !typeinfo_in_lib_p (type)) comdat_linkage (d); SET_DECL_ASSEMBLER_NAME (d, name); cp_finish_decl (d, NULL_TREE, NULL_TREE, 0); *************** create_pseudo_type_info VPARAMS((const c *** 1290,1296 **** VA_START (ap, ident); #ifndef ANSI_PROTOTYPES real_name = va_arg (ap, char const *); ! ident = va_arg (app, int); #endif /* Generate the pseudo type name. */ --- 1290,1296 ---- VA_START (ap, ident); #ifndef ANSI_PROTOTYPES real_name = va_arg (ap, char const *); ! ident = va_arg (ap, int); #endif /* Generate the pseudo type name. */ diff -Nrc3pad gcc-3.0.1/gcc/cp/typeck.c gcc-3.0.2/gcc/cp/typeck.c *** gcc-3.0.1/gcc/cp/typeck.c Wed Jul 25 02:37:26 2001 --- gcc-3.0.2/gcc/cp/typeck.c Fri Sep 21 18:33:24 2001 *************** get_member_function_from_ptrfunc (instan *** 2970,2975 **** --- 2970,2982 ---- e2 = aref; else e2 = build_component_ref (aref, pfn_identifier, NULL_TREE, 0); + + /* When using function descriptors, the address of the + vtable entry is treated as a function pointer. */ + if (TARGET_VTABLE_USES_DESCRIPTORS) + e2 = build1 (NOP_EXPR, TREE_TYPE (e2), + build_unary_op (ADDR_EXPR, e2, /*noconvert=*/1)); + TREE_TYPE (e2) = TREE_TYPE (e3); e1 = build_conditional_expr (e1, e2, e3); diff -Nrc3pad gcc-3.0.1/gcc/cpplex.c gcc-3.0.2/gcc/cpplex.c *** gcc-3.0.1/gcc/cpplex.c Fri Aug 3 11:05:10 2001 --- gcc-3.0.2/gcc/cpplex.c Mon Oct 8 14:56:36 2001 *************** _cpp_lex_token (pfile, result) *** 1033,1039 **** } /* Skipping the comment has updated buffer->read_ahead. */ ! if (!pfile->state.save_comments) { result->flags |= PREV_WHITE; goto next_char; --- 1033,1039 ---- } /* Skipping the comment has updated buffer->read_ahead. */ ! if (!pfile->state.save_comments || pfile->skipping) { result->flags |= PREV_WHITE; goto next_char; diff -Nrc3pad gcc-3.0.1/gcc/cpplib.c gcc-3.0.2/gcc/cpplib.c *** gcc-3.0.1/gcc/cpplib.c Fri Aug 3 11:05:10 2001 --- gcc-3.0.2/gcc/cpplib.c Sat Sep 15 11:22:50 2001 *************** do_pragma (pfile) *** 1070,1079 **** } cpp_stop_lookahead (pfile, drop); - pfile->state.prevent_expansion--; - if (!drop && pfile->cb.def_pragma) (*pfile->cb.def_pragma) (pfile); } static void --- 1070,1078 ---- } cpp_stop_lookahead (pfile, drop); if (!drop && pfile->cb.def_pragma) (*pfile->cb.def_pragma) (pfile); + pfile->state.prevent_expansion--; } static void diff -Nrc3pad gcc-3.0.1/gcc/cppmacro.c gcc-3.0.2/gcc/cppmacro.c *** gcc-3.0.1/gcc/cppmacro.c Mon Jun 25 10:43:17 2001 --- gcc-3.0.2/gcc/cppmacro.c Mon Oct 8 14:56:36 2001 *************** enter_macro_context (pfile, node) *** 668,683 **** list.limit = macro->expansion + macro->count; } ! /* Only push a macro context for non-empty replacement lists. */ ! if (list.first != list.limit) ! { ! context = next_context (pfile); ! context->list = list; ! context->macro = macro; ! /* Disable the macro within its expansion. */ ! macro->disabled = 1; ! } return 1; } --- 668,679 ---- list.limit = macro->expansion + macro->count; } ! context = next_context (pfile); ! context->list = list; ! context->macro = macro; ! /* Disable the macro within its expansion. */ ! macro->disabled = 1; return 1; } *************** _cpp_create_definition (pfile, node) *** 1399,1407 **** } else if (token->type != CPP_EOF && !(token->flags & PREV_WHITE)) cpp_pedwarn (pfile, "ISO C requires whitespace after the macro name"); - - /* Setting it here means we don't catch leading comments. */ - pfile->state.save_comments = ! CPP_OPTION (pfile, discard_comments); for (;;) { --- 1395,1400 ---- diff -Nrc3pad gcc-3.0.1/gcc/cse.c gcc-3.0.2/gcc/cse.c *** gcc-3.0.1/gcc/cse.c Thu Jul 26 11:27:52 2001 --- gcc-3.0.2/gcc/cse.c Wed Sep 12 13:55:19 2001 *************** cse_insn (insn, libcall_insn) *** 5060,5077 **** sets[i].src_in_memory = hash_arg_in_memory; /* If SRC is a MEM, there is a REG_EQUIV note for SRC, and DEST is ! a pseudo that is set more than once, do not record SRC. Using ! SRC as a replacement for anything else will be incorrect in that ! situation. Note that this usually occurs only for stack slots, ! in which case all the RTL would be referring to SRC, so we don't ! lose any optimization opportunities by not having SRC in the ! hash table. */ if (GET_CODE (src) == MEM ! && find_reg_note (insn, REG_EQUIV, src) != 0 && GET_CODE (dest) == REG ! && REGNO (dest) >= FIRST_PSEUDO_REGISTER ! && REG_N_SETS (REGNO (dest)) != 1) sets[i].src_volatile = 1; #if 0 --- 5060,5075 ---- sets[i].src_in_memory = hash_arg_in_memory; /* If SRC is a MEM, there is a REG_EQUIV note for SRC, and DEST is ! a pseudo, do not record SRC. Using SRC as a replacement for ! anything else will be incorrect in that situation. Note that ! this usually occurs only for stack slots, in which case all the ! RTL would be referring to SRC, so we don't lose any optimization ! opportunities by not having SRC in the hash table. */ if (GET_CODE (src) == MEM ! && find_reg_note (insn, REG_EQUIV, NULL_RTX) != 0 && GET_CODE (dest) == REG ! && REGNO (dest) >= FIRST_PSEUDO_REGISTER) sets[i].src_volatile = 1; #if 0 diff -Nrc3pad gcc-3.0.1/gcc/defaults.h gcc-3.0.2/gcc/defaults.h *** gcc-3.0.1/gcc/defaults.h Wed Jul 18 13:45:47 2001 --- gcc-3.0.2/gcc/defaults.h Fri Sep 21 18:33:19 2001 *************** do { \ *** 326,331 **** --- 326,341 ---- ? ptrmemfunc_vbit_in_pfn : ptrmemfunc_vbit_in_delta) #endif + /* By default, the C++ compiler will use function addresses in the + vtable entries. Setting this non-zero tells the compiler to use + function descriptors instead. The value of this macro says how + many words wide the descriptor is (normally 2). It is assumed + that the address of a function descriptor may be treated as a + pointer to a function. */ + #ifndef TARGET_VTABLE_USES_DESCRIPTORS + #define TARGET_VTABLE_USES_DESCRIPTORS 0 + #endif + /* Select a format to encode pointers in exception handling data. We prefer those that result in fewer dynamic relocations. Assume no special support here and encode direct references. */ diff -Nrc3pad gcc-3.0.1/gcc/doc/c-tree.texi gcc-3.0.2/gcc/doc/c-tree.texi *** gcc-3.0.1/gcc/doc/c-tree.texi Sun Jul 8 16:13:37 2001 --- gcc-3.0.2/gcc/doc/c-tree.texi Wed Oct 17 02:06:42 2001 *************** int i = (TEST_P (t) != 0); *** 110,116 **** @noindent are legal. Macros that return @code{int} values now may be changed to return @code{tree} values, or other pointers in the future. Even those ! that continue to return @code{int} may return multiple non-zero codes where previously they returned only zero and one. Therefore, you should not write code like @example --- 110,116 ---- @noindent are legal. Macros that return @code{int} values now may be changed to return @code{tree} values, or other pointers in the future. Even those ! that continue to return @code{int} may return multiple nonzero codes where previously they returned only zero and one. Therefore, you should not write code like @example *************** arguments. *** 500,506 **** Note that in C (but not in C++) a function declared like @code{void f()} is an unprototyped function taking a variable number of arguments; the ! @code{TYPE_ARG_TYPES} of such a function will be NULL@. @item METHOD_TYPE Used to represent the type of a non-static member function. Like a --- 500,506 ---- Note that in C (but not in C++) a function declared like @code{void f()} is an unprototyped function taking a variable number of arguments; the ! @code{TYPE_ARG_TYPES} of such a function will be @code{NULL}. @item METHOD_TYPE Used to represent the type of a non-static member function. Like a *************** returning to the thunk. The first param *** 1201,1207 **** value. (The @code{THUNK_DELTA} is an @code{int}, not an @code{INTEGER_CST}.) ! Then, if @code{THUNK_VCALL_OFFSET} (an @code{INTEGER_CST}) is non-zero the adjusted @code{this} pointer must be adjusted again. The complete calculation is given by the following pseudo-code: --- 1201,1207 ---- value. (The @code{THUNK_DELTA} is an @code{int}, not an @code{INTEGER_CST}.) ! Then, if @code{THUNK_VCALL_OFFSET} (an @code{INTEGER_CST}) is nonzero the adjusted @code{this} pointer must be adjusted again. The complete calculation is given by the following pseudo-code: *************** This predicate holds if the function an *** 1328,1334 **** @findex WHILE_COND A function that has a definition in the current translation unit will ! have a non-NULL @code{DECL_INITIAL}. However, back ends should not make use of the particular value given by @code{DECL_INITIAL}. The @code{DECL_SAVED_TREE} macro will give the complete body of the --- 1328,1334 ---- @findex WHILE_COND A function that has a definition in the current translation unit will ! have a non-@code{NULL} @code{DECL_INITIAL}. However, back ends should not make use of the particular value given by @code{DECL_INITIAL}. The @code{DECL_SAVED_TREE} macro will give the complete body of the *************** fields. *** 1443,1450 **** @item CASE_LABEL Use to represent a @code{case} label, range of @code{case} labels, or a ! @code{default} label. If @code{CASE_LOW} is NULL_TREE, then this is a a ! @code{default} label. Otherwise, if @code{CASE_HIGH} is NULL_TREE, then this is an ordinary @code{case} label. In this case, @code{CASE_LOW} is an expression giving the value of the label. Both @code{CASE_LOW} and @code{CASE_HIGH} are @code{INTEGER_CST} nodes. These values will have --- 1443,1450 ---- @item CASE_LABEL Use to represent a @code{case} label, range of @code{case} labels, or a ! @code{default} label. If @code{CASE_LOW} is @code{NULL_TREE}, then this is a ! @code{default} label. Otherwise, if @code{CASE_HIGH} is @code{NULL_TREE}, then this is an ordinary @code{case} label. In this case, @code{CASE_LOW} is an expression giving the value of the label. Both @code{CASE_LOW} and @code{CASE_HIGH} are @code{INTEGER_CST} nodes. These values will have *************** as a signed or unsigned quantity dependi *** 1821,1827 **** In general, the expression given above will overflow, so it should not be used to calculate the value of the constant. ! The variable @code{integer_zero_node} is a integer constant with value zero. Similarly, @code{integer_one_node} is an integer constant with value one. The @code{size_zero_node} and @code{size_one_node} variables are analogous, but have type @code{size_t} rather than @code{int}. --- 1821,1827 ---- In general, the expression given above will overflow, so it should not be used to calculate the value of the constant. ! The variable @code{integer_zero_node} is an integer constant with value zero. Similarly, @code{integer_one_node} is an integer constant with value one. The @code{size_zero_node} and @code{size_one_node} variables are analogous, but have type @code{size_t} rather than @code{int}. *************** These nodes are used to represent pointe *** 1875,1881 **** or @code{UNION_TYPE} within which the pointer points), and the @code{PTRMEM_CST_MEMBER} is the declaration for the pointed to object. Note that the @code{DECL_CONTEXT} for the @code{PTRMEM_CST_MEMBER} is in ! general different from from the @code{PTRMEM_CST_CLASS}. For example, given: @example struct B @{ int i; @}; --- 1875,1881 ---- or @code{UNION_TYPE} within which the pointer points), and the @code{PTRMEM_CST_MEMBER} is the declaration for the pointed to object. Note that the @code{DECL_CONTEXT} for the @code{PTRMEM_CST_MEMBER} is in ! general different from the @code{PTRMEM_CST_CLASS}. For example, given: @example struct B @{ int i; @}; *************** the value of the second operand. *** 2097,2103 **** @item COND_EXPR These nodes represent @code{?:} expressions. The first operand ! is of boolean or integral type. If it evaluates to a non-zero value, the second operand should be evaluated, and returned as the value of the expression. Otherwise, the third operand is evaluated, and returned as the value of the expression. As a GNU extension, the middle operand of --- 2097,2103 ---- @item COND_EXPR These nodes represent @code{?:} expressions. The first operand ! is of boolean or integral type. If it evaluates to a nonzero value, the second operand should be evaluated, and returned as the value of the expression. Otherwise, the third operand is evaluated, and returned as the value of the expression. As a GNU extension, the middle operand of *************** an @code{EXIT_EXPR} is encountered. *** 2175,2181 **** @item EXIT_EXPR These nodes represent conditional exits from the nearest enclosing @code{LOOP_EXPR}. The single operand is the condition; if it is ! non-zero, then the loop should be exited. An @code{EXIT_EXPR} will only appear within a @code{LOOP_EXPR}. @item CLEANUP_POINT_EXPR --- 2175,2181 ---- @item EXIT_EXPR These nodes represent conditional exits from the nearest enclosing @code{LOOP_EXPR}. The single operand is the condition; if it is ! nonzero, then the loop should be exited. An @code{EXIT_EXPR} will only appear within a @code{LOOP_EXPR}. @item CLEANUP_POINT_EXPR diff -Nrc3pad gcc-3.0.1/gcc/doc/cpp.1 gcc-3.0.2/gcc/doc/cpp.1 *** gcc-3.0.1/gcc/doc/cpp.1 Mon Jul 2 17:50:55 2001 --- gcc-3.0.2/gcc/doc/cpp.1 Tue Oct 23 10:56:01 2001 *************** *** 1,8 **** ! .\" Automatically generated by Pod::Man version 1.16 ! .\" Tue Jul 3 00:41:06 2001 .\" .\" Standard preamble: ! .\" ====================================================================== .de Sh \" Subsection heading .br .if t .Sp --- 1,8 ---- ! .\" Automatically generated by Pod::Man version 1.19 ! .\" Fri Oct 12 11:20:12 2001 .\" .\" Standard preamble: ! .\" ======================================================================== .de Sh \" Subsection heading .br .if t .Sp *************** *** 15,26 **** .if t .sp .5v .if n .sp .. - .de Ip \" List item - .br - .ie \\n(.$>=3 .ne \\$3 - .el .ne 3 - .IP "\\$1" \\$2 - .. .de Vb \" Begin verbatim text .ft CW .nf --- 15,20 ---- *************** *** 34,42 **** .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. | will give a ! .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used ! .\" to do unbreakable dashes and therefore won't be available. \*(C` and ! .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> .tr \(*W-|\(bv\*(Tr .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ --- 28,36 ---- .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. | will give a ! .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to ! .\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' ! .\" expand to `' in nroff, nothing in troff, for use with C<>. .tr \(*W-|\(bv\*(Tr .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ *************** *** 56,65 **** . ds R" '' 'br\} .\" ! .\" If the F register is turned on, we'll generate index entries on stderr ! .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and ! .\" index entries marked with X<> in POD. Of course, you'll have to process ! .\" the output yourself in some meaningful fashion. .if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" --- 50,59 ---- . ds R" '' 'br\} .\" ! .\" If the F register is turned on, we'll generate index entries on stderr for ! .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index ! .\" entries marked with X<> in POD. Of course, you'll have to process the ! .\" output yourself in some meaningful fashion. .if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" *************** *** 68,81 **** . rr F .\} .\" ! .\" For nroff, turn off justification. Always turn off hyphenation; it ! .\" makes way too many mistakes in technical documents. .hy 0 .if n .na .\" .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). .\" Fear. Run. Save yourself. No user-serviceable parts. - .bd B 3 . \" fudge factors for nroff and troff .if n \{\ . ds #H 0 --- 62,74 ---- . rr F .\} .\" ! .\" For nroff, turn off justification. Always turn off hyphenation; it makes ! .\" way too many mistakes in technical documents. .hy 0 .if n .na .\" .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). .\" Fear. Run. Save yourself. No user-serviceable parts. . \" fudge factors for nroff and troff .if n \{\ . ds #H 0 *************** *** 135,144 **** . ds Ae AE .\} .rm #[ #] #H #V #F C ! .\" ====================================================================== .\" .IX Title "CPP 1" ! .TH CPP 1 "gcc-3.0.1" "2001-07-03" "GNU" .UC .SH "NAME" cpp \- The C Preprocessor --- 128,137 ---- . ds Ae AE .\} .rm #[ #] #H #V #F C ! .\" ======================================================================== .\" .IX Title "CPP 1" ! .TH CPP 1 "gcc-3.0.2" "2001-10-12" "GNU" .UC .SH "NAME" cpp \- The C Preprocessor *************** after the option, or with a space betwee *** 211,220 **** Many options have multi-letter names; therefore multiple single-letter options may \fInot\fR be grouped: \fB\-dM\fR is very different from \&\fB\-d\ \-M\fR. ! .Ip "\fB\-D\fR \fIname\fR" 4 .IX Item "-D name" ! Predefine \fIname\fR as a macro, with definition \f(CW\*(C`1\*(C'\fR. ! .Ip "\fB\-D\fR \fIname\fR\fB=\fR\fIdefinition\fR" 4 .IX Item "-D name=definition" Predefine \fIname\fR as a macro, with definition \fIdefinition\fR. There are no restrictions on the contents of \fIdefinition\fR, but if --- 204,213 ---- Many options have multi-letter names; therefore multiple single-letter options may \fInot\fR be grouped: \fB\-dM\fR is very different from \&\fB\-d\ \-M\fR. ! .IP "\fB\-D\fR \fIname\fR" 4 .IX Item "-D name" ! Predefine \fIname\fR as a macro, with definition \f(CW1\fR. ! .IP "\fB\-D\fR \fIname\fR\fB=\fR\fIdefinition\fR" 4 .IX Item "-D name=definition" Predefine \fIname\fR as a macro, with definition \fIdefinition\fR. There are no restrictions on the contents of \fIdefinition\fR, but if *************** its argument list with surrounding paren *** 229,246 **** (if any). Parentheses are meaningful to most shells, so you will need to quote the option. With \fBsh\fR and \fBcsh\fR, \&\fB\-D'\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB'\fR works. ! .Ip "\fB\-U\fR \fIname\fR" 4 .IX Item "-U name" Cancel any previous definition of \fIname\fR, either built in or provided with a \fB\-D\fR option. .Sp All \fB\-imacros\fR \fIfile\fR and \fB\-include\fR \fIfile\fR options are processed after all \fB\-D\fR and \fB\-U\fR options. ! .Ip "\fB\-undef\fR" 4 .IX Item "-undef" Do not predefine any system-specific macros. The common predefined macros remain defined. ! .Ip "\fB\-I\fR \fIdir\fR" 4 .IX Item "-I dir" Add the directory \fIdir\fR to the list of directories to be searched for header files. Directories named by \fB\-I\fR --- 222,239 ---- (if any). Parentheses are meaningful to most shells, so you will need to quote the option. With \fBsh\fR and \fBcsh\fR, \&\fB\-D'\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB'\fR works. ! .IP "\fB\-U\fR \fIname\fR" 4 .IX Item "-U name" Cancel any previous definition of \fIname\fR, either built in or provided with a \fB\-D\fR option. .Sp All \fB\-imacros\fR \fIfile\fR and \fB\-include\fR \fIfile\fR options are processed after all \fB\-D\fR and \fB\-U\fR options. ! .IP "\fB\-undef\fR" 4 .IX Item "-undef" Do not predefine any system-specific macros. The common predefined macros remain defined. ! .IP "\fB\-I\fR \fIdir\fR" 4 .IX Item "-I dir" Add the directory \fIdir\fR to the list of directories to be searched for header files. Directories named by \fB\-I\fR *************** It is dangerous to specify a standard sy *** 250,318 **** \&\fB\-I\fR option. This defeats the special treatment of system headers. It can also defeat the repairs to buggy system headers which \s-1GCC\s0 makes when it is installed. ! .Ip "\fB\-o\fR \fIfile\fR" 4 .IX Item "-o file" Write output to \fIfile\fR. This is the same as specifying \fIfile\fR as the second non-option argument to \fBcpp\fR. \fBgcc\fR has a different interpretation of a second non-option argument, so you must use \fB\-o\fR to specify the output file. ! .Ip "\fB\-Wall\fR" 4 .IX Item "-Wall" Turns on all optional warnings which are desirable for normal code. At present this is \fB\-Wcomment\fR and \fB\-Wtrigraphs\fR. Note that many of the preprocessor's warnings are on by default and have no options to control them. ! .Ip "\fB\-Wcomment\fR" 4 .IX Item "-Wcomment" .PD 0 ! .Ip "\fB\-Wcomments\fR" 4 .IX Item "-Wcomments" .PD Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR comment, or whenever a backslash-newline appears in a \fB//\fR comment. (Both forms have the same effect.) ! .Ip "\fB\-Wtrigraphs\fR" 4 .IX Item "-Wtrigraphs" Warn if any trigraphs are encountered. This option used to take effect only if \fB\-trigraphs\fR was also specified, but now works independently. Warnings are not given for trigraphs within comments, as they do not affect the meaning of the program. ! .Ip "\fB\-Wtraditional\fR" 4 .IX Item "-Wtraditional" Warn about certain constructs that behave differently in traditional and \&\s-1ISO\s0 C. Also warn about \s-1ISO\s0 C constructs that have no traditional C equivalent, and problematic constructs which should be avoided. ! .Ip "\fB\-Wimport\fR" 4 .IX Item "-Wimport" Warn the first time \fB#import\fR is used. ! .Ip "\fB\-Wundef\fR" 4 .IX Item "-Wundef" Warn whenever an identifier which is not a macro is encountered in an \&\fB#if\fR directive, outside of \fBdefined\fR. Such identifiers are replaced with zero. ! .Ip "\fB\-Werror\fR" 4 .IX Item "-Werror" Make all warnings into hard errors. Source code which triggers warnings will be rejected. ! .Ip "\fB\-Wsystem-headers\fR" 4 .IX Item "-Wsystem-headers" Issue warnings for code in system headers. These are normally unhelpful in finding bugs in your own code, therefore suppressed. If you are responsible for the system library, you may want to see them. ! .Ip "\fB\-w\fR" 4 .IX Item "-w" Suppress all warnings, including those which \s-1GNU\s0 \s-1CPP\s0 issues by default. ! .Ip "\fB\-pedantic\fR" 4 .IX Item "-pedantic" Issue all the mandatory diagnostics listed in the C standard. Some of them are left out by default, since they trigger frequently on harmless code. ! .Ip "\fB\-pedantic-errors\fR" 4 .IX Item "-pedantic-errors" Issue all the mandatory diagnostics, and make all mandatory diagnostics into errors. This includes mandatory diagnostics that \s-1GCC\s0 issues without \fB\-pedantic\fR but treats as warnings. ! .Ip "\fB\-M\fR" 4 .IX Item "-M" Instead of outputting the result of preprocessing, output a rule suitable for \fBmake\fR describing the dependencies of the main --- 243,311 ---- \&\fB\-I\fR option. This defeats the special treatment of system headers. It can also defeat the repairs to buggy system headers which \s-1GCC\s0 makes when it is installed. ! .IP "\fB\-o\fR \fIfile\fR" 4 .IX Item "-o file" Write output to \fIfile\fR. This is the same as specifying \fIfile\fR as the second non-option argument to \fBcpp\fR. \fBgcc\fR has a different interpretation of a second non-option argument, so you must use \fB\-o\fR to specify the output file. ! .IP "\fB\-Wall\fR" 4 .IX Item "-Wall" Turns on all optional warnings which are desirable for normal code. At present this is \fB\-Wcomment\fR and \fB\-Wtrigraphs\fR. Note that many of the preprocessor's warnings are on by default and have no options to control them. ! .IP "\fB\-Wcomment\fR" 4 .IX Item "-Wcomment" .PD 0 ! .IP "\fB\-Wcomments\fR" 4 .IX Item "-Wcomments" .PD Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR comment, or whenever a backslash-newline appears in a \fB//\fR comment. (Both forms have the same effect.) ! .IP "\fB\-Wtrigraphs\fR" 4 .IX Item "-Wtrigraphs" Warn if any trigraphs are encountered. This option used to take effect only if \fB\-trigraphs\fR was also specified, but now works independently. Warnings are not given for trigraphs within comments, as they do not affect the meaning of the program. ! .IP "\fB\-Wtraditional\fR" 4 .IX Item "-Wtraditional" Warn about certain constructs that behave differently in traditional and \&\s-1ISO\s0 C. Also warn about \s-1ISO\s0 C constructs that have no traditional C equivalent, and problematic constructs which should be avoided. ! .IP "\fB\-Wimport\fR" 4 .IX Item "-Wimport" Warn the first time \fB#import\fR is used. ! .IP "\fB\-Wundef\fR" 4 .IX Item "-Wundef" Warn whenever an identifier which is not a macro is encountered in an \&\fB#if\fR directive, outside of \fBdefined\fR. Such identifiers are replaced with zero. ! .IP "\fB\-Werror\fR" 4 .IX Item "-Werror" Make all warnings into hard errors. Source code which triggers warnings will be rejected. ! .IP "\fB\-Wsystem-headers\fR" 4 .IX Item "-Wsystem-headers" Issue warnings for code in system headers. These are normally unhelpful in finding bugs in your own code, therefore suppressed. If you are responsible for the system library, you may want to see them. ! .IP "\fB\-w\fR" 4 .IX Item "-w" Suppress all warnings, including those which \s-1GNU\s0 \s-1CPP\s0 issues by default. ! .IP "\fB\-pedantic\fR" 4 .IX Item "-pedantic" Issue all the mandatory diagnostics listed in the C standard. Some of them are left out by default, since they trigger frequently on harmless code. ! .IP "\fB\-pedantic-errors\fR" 4 .IX Item "-pedantic-errors" Issue all the mandatory diagnostics, and make all mandatory diagnostics into errors. This includes mandatory diagnostics that \s-1GCC\s0 issues without \fB\-pedantic\fR but treats as warnings. ! .IP "\fB\-M\fR" 4 .IX Item "-M" Instead of outputting the result of preprocessing, output a rule suitable for \fBmake\fR describing the dependencies of the main *************** object file name consists of the basenam *** 326,343 **** suffix replaced with object file suffix. If there are many included files then the rule is split into several lines using \fB\e\fR\-newline. The rule has no commands. ! .Ip "\fB\-MM\fR" 4 .IX Item "-MM" Like \fB\-M\fR, but mention only the files included with \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR or with \fB\-include\fR or \fB\-imacros\fR command line options. System header files included with \f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR are omitted. ! .Ip "\fB\-MF\fR \fIfile\fR" 4 .IX Item "-MF file" When used with \fB\-M\fR or \fB\-MM\fR, specifies a file to write the dependencies to. This allows the preprocessor to write the preprocessed file to stdout normally. If no \fB\-MF\fR switch is given, \s-1CPP\s0 sends the rules to stdout and suppresses normal preprocessed output. ! .Ip "\fB\-MG\fR" 4 .IX Item "-MG" When used with \fB\-M\fR or \fB\-MM\fR, \fB\-MG\fR says to treat missing header files as generated files and assume they live in the same --- 319,336 ---- suffix replaced with object file suffix. If there are many included files then the rule is split into several lines using \fB\e\fR\-newline. The rule has no commands. ! .IP "\fB\-MM\fR" 4 .IX Item "-MM" Like \fB\-M\fR, but mention only the files included with \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR or with \fB\-include\fR or \fB\-imacros\fR command line options. System header files included with \f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR are omitted. ! .IP "\fB\-MF\fR \fIfile\fR" 4 .IX Item "-MF file" When used with \fB\-M\fR or \fB\-MM\fR, specifies a file to write the dependencies to. This allows the preprocessor to write the preprocessed file to stdout normally. If no \fB\-MF\fR switch is given, \s-1CPP\s0 sends the rules to stdout and suppresses normal preprocessed output. ! .IP "\fB\-MG\fR" 4 .IX Item "-MG" When used with \fB\-M\fR or \fB\-MM\fR, \fB\-MG\fR says to treat missing header files as generated files and assume they live in the same *************** directory as the source file. It suppre *** 345,351 **** missing header file is ordinarily an error. .Sp This feature is used in automatic updating of makefiles. ! .Ip "\fB\-MP\fR" 4 .IX Item "-MP" This option instructs \s-1CPP\s0 to add a phony target for each dependency other than the main file, causing each to depend on nothing. These --- 338,344 ---- missing header file is ordinarily an error. .Sp This feature is used in automatic updating of makefiles. ! .IP "\fB\-MP\fR" 4 .IX Item "-MP" This option instructs \s-1CPP\s0 to add a phony target for each dependency other than the main file, causing each to depend on nothing. These *************** This is typical output: *** 360,366 **** .Vb 1 \& test.h: .Ve ! .Ip "\fB\-MT\fR \fItarget\fR" 4 .IX Item "-MT target" Change the target of the rule emitted by dependency generation. By default \s-1CPP\s0 takes the name of the main input file, including any path, --- 353,359 ---- .Vb 1 \& test.h: .Ve ! .IP "\fB\-MT\fR \fItarget\fR" 4 .IX Item "-MT target" Change the target of the rule emitted by dependency generation. By default \s-1CPP\s0 takes the name of the main input file, including any path, *************** For example, \fB\-MT\ '$(objpfx)foo.o'\f *** 376,382 **** .Vb 1 \& $(objpfx)foo.o: foo.c .Ve ! .Ip "\fB\-MQ\fR \fItarget\fR" 4 .IX Item "-MQ target" Same as \fB\-MT\fR, but it quotes any characters which are special to Make. \fB\-MQ\ '$(objpfx)foo.o'\fR gives --- 369,375 ---- .Vb 1 \& $(objpfx)foo.o: foo.c .Ve ! .IP "\fB\-MQ\fR \fItarget\fR" 4 .IX Item "-MQ target" Same as \fB\-MT\fR, but it quotes any characters which are special to Make. \fB\-MQ\ '$(objpfx)foo.o'\fR gives *************** Make. \fB\-MQ\ '$(objpfx)foo.o'\fR give *** 386,395 **** .Ve The default target is automatically quoted, as if it were given with \&\fB\-MQ\fR. ! .Ip "\fB\-MD\fR \fIfile\fR" 4 .IX Item "-MD file" .PD 0 ! .Ip "\fB\-MMD\fR \fIfile\fR" 4 .IX Item "-MMD file" .PD \&\fB\-MD\fR \fIfile\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, and --- 379,388 ---- .Ve The default target is automatically quoted, as if it were given with \&\fB\-MQ\fR. ! .IP "\fB\-MD\fR \fIfile\fR" 4 .IX Item "-MD file" .PD 0 ! .IP "\fB\-MMD\fR \fIfile\fR" 4 .IX Item "-MMD file" .PD \&\fB\-MD\fR \fIfile\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, and *************** The default target is automatically quot *** 398,411 **** Due to limitations in the compiler driver, you must use these switches when you want to generate a dependency file as a side-effect of normal compilation. ! .Ip "\fB\-x c\fR" 4 .IX Item "-x c" .PD 0 ! .Ip "\fB\-x c++\fR" 4 .IX Item "-x c++" ! .Ip "\fB\-x objective-c\fR" 4 .IX Item "-x objective-c" ! .Ip "\fB\-x assembler-with-cpp\fR" 4 .IX Item "-x assembler-with-cpp" .PD Specify the source language: C, \*(C+, Objective-C, or assembly. This has --- 391,404 ---- Due to limitations in the compiler driver, you must use these switches when you want to generate a dependency file as a side-effect of normal compilation. ! .IP "\fB\-x c\fR" 4 .IX Item "-x c" .PD 0 ! .IP "\fB\-x c++\fR" 4 .IX Item "-x c++" ! .IP "\fB\-x objective-c\fR" 4 .IX Item "-x objective-c" ! .IP "\fB\-x assembler-with-cpp\fR" 4 .IX Item "-x assembler-with-cpp" .PD Specify the source language: C, \*(C+, Objective-C, or assembly. This has *************** generic mode. *** 421,430 **** which selected both the language and the standards conformance level. This option has been removed, because it conflicts with the \fB\-l\fR option. ! .Ip "\fB\-std=\fR\fIstandard\fR" 4 .IX Item "-std=standard" .PD 0 ! .Ip "\fB\-ansi\fR" 4 .IX Item "-ansi" .PD Specify the standard to which the code should conform. Currently cpp --- 414,423 ---- which selected both the language and the standards conformance level. This option has been removed, because it conflicts with the \fB\-l\fR option. ! .IP "\fB\-std=\fR\fIstandard\fR" 4 .IX Item "-std=standard" .PD 0 ! .IP "\fB\-ansi\fR" 4 .IX Item "-ansi" .PD Specify the standard to which the code should conform. Currently cpp *************** added in the future. *** 434,488 **** \&\fIstandard\fR may be one of: .RS 4 ! .if n .Ip "\f(CW""""iso9899:1990""""\fR" 4 ! .el .Ip "\f(CWiso9899:1990\fR" 4 .IX Item "iso9899:1990" .PD 0 ! .if n .Ip "\f(CW""""c89""""\fR" 4 ! .el .Ip "\f(CWc89\fR" 4 .IX Item "c89" .PD The \s-1ISO\s0 C standard from 1990. \fBc89\fR is the customary shorthand for this version of the standard. .Sp The \fB\-ansi\fR option is equivalent to \fB\-std=c89\fR. ! .if n .Ip "\f(CW""""iso9899:199409""""\fR" 4 ! .el .Ip "\f(CWiso9899:199409\fR" 4 .IX Item "iso9899:199409" The 1990 C standard, as amended in 1994. ! .if n .Ip "\f(CW""""iso9899:1999""""\fR" 4 ! .el .Ip "\f(CWiso9899:1999\fR" 4 .IX Item "iso9899:1999" .PD 0 ! .if n .Ip "\f(CW""""c99""""\fR" 4 ! .el .Ip "\f(CWc99\fR" 4 .IX Item "c99" ! .if n .Ip "\f(CW""""iso9899:199x""""\fR" 4 ! .el .Ip "\f(CWiso9899:199x\fR" 4 .IX Item "iso9899:199x" ! .if n .Ip "\f(CW""""c9x""""\fR" 4 ! .el .Ip "\f(CWc9x\fR" 4 .IX Item "c9x" .PD The revised \s-1ISO\s0 C standard, published in December 1999. Before publication, this was known as C9X. ! .if n .Ip "\f(CW""""gnu89""""\fR" 4 ! .el .Ip "\f(CWgnu89\fR" 4 .IX Item "gnu89" The 1990 C standard plus \s-1GNU\s0 extensions. This is the default. ! .if n .Ip "\f(CW""""gnu99""""\fR" 4 ! .el .Ip "\f(CWgnu99\fR" 4 .IX Item "gnu99" .PD 0 ! .if n .Ip "\f(CW""""gnu9x""""\fR" 4 ! .el .Ip "\f(CWgnu9x\fR" 4 .IX Item "gnu9x" .PD The 1999 C standard plus \s-1GNU\s0 extensions. .RE .RS 4 .RE ! .Ip "\fB\-I-\fR" 4 .IX Item "-I-" Split the include path. Any directories specified with \fB\-I\fR options before \fB\-I-\fR are searched only for headers requested with --- 427,481 ---- \&\fIstandard\fR may be one of: .RS 4 ! .if n .IP """iso9899:1990""" 4 ! .el .IP "\f(CWiso9899:1990\fR" 4 .IX Item "iso9899:1990" .PD 0 ! .if n .IP """c89""" 4 ! .el .IP "\f(CWc89\fR" 4 .IX Item "c89" .PD The \s-1ISO\s0 C standard from 1990. \fBc89\fR is the customary shorthand for this version of the standard. .Sp The \fB\-ansi\fR option is equivalent to \fB\-std=c89\fR. ! .if n .IP """iso9899:199409""" 4 ! .el .IP "\f(CWiso9899:199409\fR" 4 .IX Item "iso9899:199409" The 1990 C standard, as amended in 1994. ! .if n .IP """iso9899:1999""" 4 ! .el .IP "\f(CWiso9899:1999\fR" 4 .IX Item "iso9899:1999" .PD 0 ! .if n .IP """c99""" 4 ! .el .IP "\f(CWc99\fR" 4 .IX Item "c99" ! .if n .IP """iso9899:199x""" 4 ! .el .IP "\f(CWiso9899:199x\fR" 4 .IX Item "iso9899:199x" ! .if n .IP """c9x""" 4 ! .el .IP "\f(CWc9x\fR" 4 .IX Item "c9x" .PD The revised \s-1ISO\s0 C standard, published in December 1999. Before publication, this was known as C9X. ! .if n .IP """gnu89""" 4 ! .el .IP "\f(CWgnu89\fR" 4 .IX Item "gnu89" The 1990 C standard plus \s-1GNU\s0 extensions. This is the default. ! .if n .IP """gnu99""" 4 ! .el .IP "\f(CWgnu99\fR" 4 .IX Item "gnu99" .PD 0 ! .if n .IP """gnu9x""" 4 ! .el .IP "\f(CWgnu9x\fR" 4 .IX Item "gnu9x" .PD The 1999 C standard plus \s-1GNU\s0 extensions. .RE .RS 4 .RE ! .IP "\fB\-I-\fR" 4 .IX Item "-I-" Split the include path. Any directories specified with \fB\-I\fR options before \fB\-I-\fR are searched only for headers requested with *************** directories are searched for all \fB#inc *** 493,509 **** .Sp In addition, \fB\-I-\fR inhibits the use of the directory of the current file directory as the first search directory for \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR. ! .Ip "\fB\-nostdinc\fR" 4 .IX Item "-nostdinc" Do not search the standard system directories for header files. Only the directories you have specified with \fB\-I\fR options (and the directory of the current file, if appropriate) are searched. ! .Ip "\fB\-nostdinc++\fR" 4 .IX Item "-nostdinc++" Do not search for header files in the \*(C+\-specific standard directories, but do still search the other standard directories. (This option is used when building the \*(C+ library.) ! .Ip "\fB\-include\fR \fIfile\fR" 4 .IX Item "-include file" Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first line of the primary source file. However, the first directory searched --- 486,502 ---- .Sp In addition, \fB\-I-\fR inhibits the use of the directory of the current file directory as the first search directory for \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR. ! .IP "\fB\-nostdinc\fR" 4 .IX Item "-nostdinc" Do not search the standard system directories for header files. Only the directories you have specified with \fB\-I\fR options (and the directory of the current file, if appropriate) are searched. ! .IP "\fB\-nostdinc++\fR" 4 .IX Item "-nostdinc++" Do not search for header files in the \*(C+\-specific standard directories, but do still search the other standard directories. (This option is used when building the \*(C+ library.) ! .IP "\fB\-include\fR \fIfile\fR" 4 .IX Item "-include file" Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first line of the primary source file. However, the first directory searched *************** chain as normal. *** 514,520 **** .Sp If multiple \fB\-include\fR options are given, the files are included in the order they appear on the command line. ! .Ip "\fB\-imacros\fR \fIfile\fR" 4 .IX Item "-imacros file" Exactly like \fB\-include\fR, except that any output produced by scanning \fIfile\fR is thrown away. Macros it defines remain defined. --- 507,513 ---- .Sp If multiple \fB\-include\fR options are given, the files are included in the order they appear on the command line. ! .IP "\fB\-imacros\fR \fIfile\fR" 4 .IX Item "-imacros file" Exactly like \fB\-include\fR, except that any output produced by scanning \fIfile\fR is thrown away. Macros it defines remain defined. *************** processing its declarations. *** 523,542 **** .Sp All files specified by \fB\-imacros\fR are processed before all files specified by \fB\-include\fR. ! .Ip "\fB\-idirafter\fR \fIdir\fR" 4 .IX Item "-idirafter dir" Search \fIdir\fR for header files, but do it \fIafter\fR all directories specified with \fB\-I\fR and the standard system directories have been exhausted. \fIdir\fR is treated as a system include directory. ! .Ip "\fB\-iprefix\fR \fIprefix\fR" 4 .IX Item "-iprefix prefix" Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR options. If the prefix represents a directory, you should include the final \fB/\fR. ! .Ip "\fB\-iwithprefix\fR \fIdir\fR" 4 .IX Item "-iwithprefix dir" .PD 0 ! .Ip "\fB\-iwithprefixbefore\fR \fIdir\fR" 4 .IX Item "-iwithprefixbefore dir" .PD Append \fIdir\fR to the prefix specified previously with --- 516,535 ---- .Sp All files specified by \fB\-imacros\fR are processed before all files specified by \fB\-include\fR. ! .IP "\fB\-idirafter\fR \fIdir\fR" 4 .IX Item "-idirafter dir" Search \fIdir\fR for header files, but do it \fIafter\fR all directories specified with \fB\-I\fR and the standard system directories have been exhausted. \fIdir\fR is treated as a system include directory. ! .IP "\fB\-iprefix\fR \fIprefix\fR" 4 .IX Item "-iprefix prefix" Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR options. If the prefix represents a directory, you should include the final \fB/\fR. ! .IP "\fB\-iwithprefix\fR \fIdir\fR" 4 .IX Item "-iwithprefix dir" .PD 0 ! .IP "\fB\-iwithprefixbefore\fR \fIdir\fR" 4 .IX Item "-iwithprefixbefore dir" .PD Append \fIdir\fR to the prefix specified previously with *************** path. \fB\-iwithprefixbefore\fR puts it *** 545,557 **** would; \fB\-iwithprefix\fR puts it where \fB\-idirafter\fR would. .Sp Use of these options is discouraged. ! .Ip "\fB\-isystem\fR \fIdir\fR" 4 .IX Item "-isystem dir" Search \fIdir\fR for header files, after all directories specified by \&\fB\-I\fR but before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. ! .Ip "\fB\-fpreprocessed\fR" 4 .IX Item "-fpreprocessed" Indicate to the preprocessor that the input file has already been preprocessed. This suppresses things like macro expansion, trigraph --- 538,550 ---- would; \fB\-iwithprefix\fR puts it where \fB\-idirafter\fR would. .Sp Use of these options is discouraged. ! .IP "\fB\-isystem\fR \fIdir\fR" 4 .IX Item "-isystem dir" Search \fIdir\fR for header files, after all directories specified by \&\fB\-I\fR but before the standard system directories. Mark it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. ! .IP "\fB\-fpreprocessed\fR" 4 .IX Item "-fpreprocessed" Indicate to the preprocessor that the input file has already been preprocessed. This suppresses things like macro expansion, trigraph *************** a tokenizer for the front ends. *** 565,598 **** extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR. These are the extensions that \s-1GCC\s0 uses for preprocessed files created by \&\fB\-save-temps\fR. ! .Ip "\fB\-ftabstop=\fR\fIwidth\fR" 4 .IX Item "-ftabstop=width" Set the distance between tab stops. This helps the preprocessor report correct column numbers in warnings or errors, even if tabs appear on the line. If the value is less than 1 or greater than 100, the option is ignored. The default is 8. ! .Ip "\fB\-fno-show-column\fR" 4 .IX Item "-fno-show-column" Do not print column numbers in diagnostics. This may be necessary if diagnostics are being scanned by a program that does not understand the column numbers, such as \fBdejagnu\fR. ! .Ip "\fB\-A\fR \fIpredicate\fR\fB=\fR\fIanswer\fR" 4 .IX Item "-A predicate=answer" Make an assertion with the predicate \fIpredicate\fR and answer \&\fIanswer\fR. This form is preferred to the older form \fB\-A\fR \&\fIpredicate\fR\fB(\fR\fIanswer\fR\fB)\fR, which is still supported, because it does not use shell special characters. ! .Ip "\fB\-A -\fR\fIpredicate\fR\fB=\fR\fIanswer\fR" 4 .IX Item "-A -predicate=answer" Cancel an assertion with the predicate \fIpredicate\fR and answer \&\fIanswer\fR. ! .Ip "\fB\-A-\fR" 4 .IX Item "-A-" Cancel all predefined assertions and all assertions preceding it on the command line. Also, undefine all predefined macros and all macros preceding it on the command line. (This is a historical wart and may change in the future.) ! .Ip "\fB\-dCHARS\fR" 4 .IX Item "-dCHARS" \&\fI\s-1CHARS\s0\fR is a sequence of one or more of the following characters, and must not be preceded by a space. Other characters are interpreted --- 558,591 ---- extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR. These are the extensions that \s-1GCC\s0 uses for preprocessed files created by \&\fB\-save-temps\fR. ! .IP "\fB\-ftabstop=\fR\fIwidth\fR" 4 .IX Item "-ftabstop=width" Set the distance between tab stops. This helps the preprocessor report correct column numbers in warnings or errors, even if tabs appear on the line. If the value is less than 1 or greater than 100, the option is ignored. The default is 8. ! .IP "\fB\-fno-show-column\fR" 4 .IX Item "-fno-show-column" Do not print column numbers in diagnostics. This may be necessary if diagnostics are being scanned by a program that does not understand the column numbers, such as \fBdejagnu\fR. ! .IP "\fB\-A\fR \fIpredicate\fR\fB=\fR\fIanswer\fR" 4 .IX Item "-A predicate=answer" Make an assertion with the predicate \fIpredicate\fR and answer \&\fIanswer\fR. This form is preferred to the older form \fB\-A\fR \&\fIpredicate\fR\fB(\fR\fIanswer\fR\fB)\fR, which is still supported, because it does not use shell special characters. ! .IP "\fB\-A -\fR\fIpredicate\fR\fB=\fR\fIanswer\fR" 4 .IX Item "-A -predicate=answer" Cancel an assertion with the predicate \fIpredicate\fR and answer \&\fIanswer\fR. ! .IP "\fB\-A-\fR" 4 .IX Item "-A-" Cancel all predefined assertions and all assertions preceding it on the command line. Also, undefine all predefined macros and all macros preceding it on the command line. (This is a historical wart and may change in the future.) ! .IP "\fB\-dCHARS\fR" 4 .IX Item "-dCHARS" \&\fI\s-1CHARS\s0\fR is a sequence of one or more of the following characters, and must not be preceded by a space. Other characters are interpreted *************** by the compiler proper, or reserved for *** 600,606 **** are silently ignored. If you specify characters whose behavior conflicts, the result is undefined. .RS 4 ! .Ip "\fBM\fR" 4 .IX Item "M" Instead of the normal output, generate a list of \fB#define\fR directives for all the macros defined during the execution of the --- 593,599 ---- are silently ignored. If you specify characters whose behavior conflicts, the result is undefined. .RS 4 ! .IP "\fBM\fR" 4 .IX Item "M" Instead of the normal output, generate a list of \fB#define\fR directives for all the macros defined during the execution of the *************** Assuming you have no file \fIfoo.h\fR, t *** 612,699 **** \& touch foo.h; cpp -dM foo.h .Ve will show all the predefined macros. ! .Ip "\fBD\fR" 4 .IX Item "D" Like \fBM\fR except in two respects: it does \fInot\fR include the predefined macros, and it outputs \fIboth\fR the \fB#define\fR directives and the result of preprocessing. Both kinds of output go to the standard output file. ! .Ip "\fBN\fR" 4 .IX Item "N" Like \fBD\fR, but emit only the macro names, not their expansions. ! .Ip "\fBI\fR" 4 .IX Item "I" Output \fB#include\fR directives in addition to the result of preprocessing. .RE .RS 4 .RE ! .Ip "\fB\-P\fR" 4 .IX Item "-P" Inhibit generation of linemarkers in the output from the preprocessor. This might be useful when running the preprocessor on something that is not C code, and will be sent to a program which might be confused by the linemarkers. ! .Ip "\fB\-C\fR" 4 .IX Item "-C" Do not discard comments. All comments are passed through to the output file, except for comments in processed directives, which are deleted ! along with the directive. Comments appearing in the expansion list of a ! macro will be preserved, and appear in place wherever the macro is ! invoked. .Sp ! You should be prepared for side effects when using \fB\-C\fR; it causes ! the preprocessor to treat comments as tokens in their own right. For ! example, macro redefinitions that were trivial when comments were ! replaced by a single space might become significant when comments are ! retained. Also, comments appearing at the start of what would be a directive line have the effect of turning that line into an ordinary source line, since the first token on the line is no longer a \fB#\fR. ! .Ip "\fB\-gcc\fR" 4 .IX Item "-gcc" Define the macros _\|_GNUC_\|_, _\|_GNUC_MINOR_\|_ and _\|_GNUC_PATCHLEVEL_\|_. These are defined automatically when you use \&\fBgcc \-E\fR; you can turn them off in that case with \&\fB\-no-gcc\fR. ! .Ip "\fB\-traditional\fR" 4 .IX Item "-traditional" Try to imitate the behavior of old-fashioned C, as opposed to \s-1ISO\s0 C. ! .Ip "\fB\-trigraphs\fR" 4 .IX Item "-trigraphs" Process trigraph sequences. ! .Ip "\fB\-remap\fR" 4 .IX Item "-remap" Enable special code to work around file systems which only permit very short file names, such as \s-1MS-DOS\s0. ! .Ip "\fB\-$\fR" 4 .IX Item "-$" Forbid the use of \fB$\fR in identifiers. The C standard allows implementations to define extra characters that can appear in identifiers. By default \s-1GNU\s0 \s-1CPP\s0 permits \fB$\fR, a common extension. ! .Ip "\fB\-h\fR" 4 .IX Item "-h" .PD 0 ! .Ip "\fB\*(--help\fR" 4 .IX Item "help" ! .Ip "\fB\*(--target-help\fR" 4 .IX Item "target-help" .PD Print text describing all the command line options instead of preprocessing anything. ! .Ip "\fB\-v\fR" 4 .IX Item "-v" Verbose mode. Print out \s-1GNU\s0 \s-1CPP\s0's version number at the beginning of execution, and report the final form of the include path. ! .Ip "\fB\-H\fR" 4 .IX Item "-H" Print the name of each header file used, in addition to other normal activities. Each name is indented to show how deep in the \&\fB#include\fR stack it is. ! .Ip "\fB\-version\fR" 4 .IX Item "-version" .PD 0 ! .Ip "\fB\*(--version\fR" 4 .IX Item "version" .PD Print out \s-1GNU\s0 \s-1CPP\s0's version number. With one dash, proceed to --- 605,688 ---- \& touch foo.h; cpp -dM foo.h .Ve will show all the predefined macros. ! .IP "\fBD\fR" 4 .IX Item "D" Like \fBM\fR except in two respects: it does \fInot\fR include the predefined macros, and it outputs \fIboth\fR the \fB#define\fR directives and the result of preprocessing. Both kinds of output go to the standard output file. ! .IP "\fBN\fR" 4 .IX Item "N" Like \fBD\fR, but emit only the macro names, not their expansions. ! .IP "\fBI\fR" 4 .IX Item "I" Output \fB#include\fR directives in addition to the result of preprocessing. .RE .RS 4 .RE ! .IP "\fB\-P\fR" 4 .IX Item "-P" Inhibit generation of linemarkers in the output from the preprocessor. This might be useful when running the preprocessor on something that is not C code, and will be sent to a program which might be confused by the linemarkers. ! .IP "\fB\-C\fR" 4 .IX Item "-C" Do not discard comments. All comments are passed through to the output file, except for comments in processed directives, which are deleted ! along with the directive. .Sp ! You should be prepared for side effects when using \fB\-C\fR; it ! causes the preprocessor to treat comments as tokens in their own right. ! For example, comments appearing at the start of what would be a directive line have the effect of turning that line into an ordinary source line, since the first token on the line is no longer a \fB#\fR. ! .IP "\fB\-gcc\fR" 4 .IX Item "-gcc" Define the macros _\|_GNUC_\|_, _\|_GNUC_MINOR_\|_ and _\|_GNUC_PATCHLEVEL_\|_. These are defined automatically when you use \&\fBgcc \-E\fR; you can turn them off in that case with \&\fB\-no-gcc\fR. ! .IP "\fB\-traditional\fR" 4 .IX Item "-traditional" Try to imitate the behavior of old-fashioned C, as opposed to \s-1ISO\s0 C. ! .IP "\fB\-trigraphs\fR" 4 .IX Item "-trigraphs" Process trigraph sequences. ! .IP "\fB\-remap\fR" 4 .IX Item "-remap" Enable special code to work around file systems which only permit very short file names, such as \s-1MS-DOS\s0. ! .IP "\fB\-$\fR" 4 .IX Item "-$" Forbid the use of \fB$\fR in identifiers. The C standard allows implementations to define extra characters that can appear in identifiers. By default \s-1GNU\s0 \s-1CPP\s0 permits \fB$\fR, a common extension. ! .IP "\fB\-h\fR" 4 .IX Item "-h" .PD 0 ! .IP "\fB\*(--help\fR" 4 .IX Item "help" ! .IP "\fB\*(--target-help\fR" 4 .IX Item "target-help" .PD Print text describing all the command line options instead of preprocessing anything. ! .IP "\fB\-v\fR" 4 .IX Item "-v" Verbose mode. Print out \s-1GNU\s0 \s-1CPP\s0's version number at the beginning of execution, and report the final form of the include path. ! .IP "\fB\-H\fR" 4 .IX Item "-H" Print the name of each header file used, in addition to other normal activities. Each name is indented to show how deep in the \&\fB#include\fR stack it is. ! .IP "\fB\-version\fR" 4 .IX Item "-version" .PD 0 ! .IP "\fB\*(--version\fR" 4 .IX Item "version" .PD Print out \s-1GNU\s0 \s-1CPP\s0's version number. With one dash, proceed to diff -Nrc3pad gcc-3.0.1/gcc/doc/cpp.info gcc-3.0.2/gcc/doc/cpp.info *** gcc-3.0.1/gcc/doc/cpp.info Sun Aug 19 18:05:16 2001 --- gcc-3.0.2/gcc/doc/cpp.info Tue Oct 23 11:00:26 2001 *************** END-INFO-DIR-ENTRY *** 9,80 ****  Indirect: cpp.info-1: 191 ! cpp.info-2: 49183 ! cpp.info-3: 98499 ! cpp.info-4: 138493  Tag Table: (Indirect) Node: Top191 ! Node: Overview2749 ! Node: Initial processing5117 ! Node: Tokenization11574 ! Ref: Tokenization-Footnote-118694 ! Node: The preprocessing language18805 ! Node: Header Files21678 ! Node: Include Syntax23556 ! Node: Include Operation25058 ! Node: Search Path26954 ! Node: Once-Only Headers29506 ! Node: Computed Includes31160 ! Node: Wrapper Headers34299 ! Node: System Headers36718 ! Node: Macros38742 ! Node: Object-like Macros39842 ! Node: Function-like Macros43428 ! Node: Macro Arguments45038 ! Node: Stringification49183 ! Node: Concatenation52384 ! Node: Variadic Macros55483 ! Node: Predefined Macros59820 ! Node: Standard Predefined Macros60403 ! Node: Common Predefined Macros65825 ! Node: System-specific Predefined Macros72028 ! Node: C++ Named Operators74040 ! Node: Undefining and Redefining Macros74995 ! Node: Macro Pitfalls77073 ! Node: Misnesting77598 ! Node: Operator Precedence Problems78699 ! Node: Swallowing the Semicolon80554 ! Node: Duplication of Side Effects82566 ! Node: Self-Referential Macros84738 ! Node: Argument Prescan87148 ! Node: Newlines in Arguments90891 ! Node: Conditionals91836 ! Node: Conditional Uses93665 ! Node: Conditional Syntax95018 ! Node: Ifdef95333 ! Node: If98499 ! Node: Defined100912 ! Node: Else102185 ! Node: Elif102746 ! Node: Deleted Code104026 ! Node: Diagnostics105273 ! Node: Line Control106890 ! Node: Pragmas109004 ! Node: Other Directives113272 ! Node: Preprocessor Output114466 ! Node: Traditional Mode117565 ! Node: Implementation Details123144 ! Node: Implementation-defined behavior123767 ! Node: Implementation limits126040 ! Node: Obsolete Features128747 ! Node: Assertions129234 ! Node: Obsolete once-only headers131769 ! Node: Miscellaneous obsolete features133537 ! Node: Differences from previous versions134870 ! Node: Invocation138493 ! Node: Index of Directives157292 ! Node: Concept Index158653  End Tag Table --- 9,80 ----  Indirect: cpp.info-1: 191 ! cpp.info-2: 49230 ! cpp.info-3: 98558 ! cpp.info-4: 138540  Tag Table: (Indirect) Node: Top191 ! Node: Overview2745 ! Node: Initial processing5113 ! Node: Tokenization11570 ! Ref: Tokenization-Footnote-118741 ! Node: The preprocessing language18852 ! Node: Header Files21725 ! Node: Include Syntax23603 ! Node: Include Operation25105 ! Node: Search Path27001 ! Node: Once-Only Headers29553 ! Node: Computed Includes31207 ! Node: Wrapper Headers34346 ! Node: System Headers36765 ! Node: Macros38789 ! Node: Object-like Macros39889 ! Node: Function-like Macros43475 ! Node: Macro Arguments45085 ! Node: Stringification49230 ! Node: Concatenation52431 ! Node: Variadic Macros55545 ! Node: Predefined Macros59882 ! Node: Standard Predefined Macros60465 ! Node: Common Predefined Macros65887 ! Node: System-specific Predefined Macros72087 ! Node: C++ Named Operators74099 ! Node: Undefining and Redefining Macros75054 ! Node: Macro Pitfalls77132 ! Node: Misnesting77657 ! Node: Operator Precedence Problems78758 ! Node: Swallowing the Semicolon80613 ! Node: Duplication of Side Effects82625 ! Node: Self-Referential Macros84797 ! Node: Argument Prescan87207 ! Node: Newlines in Arguments90950 ! Node: Conditionals91895 ! Node: Conditional Uses93724 ! Node: Conditional Syntax95077 ! Node: Ifdef95392 ! Node: If98558 ! Node: Defined100971 ! Node: Else102244 ! Node: Elif102805 ! Node: Deleted Code104085 ! Node: Diagnostics105327 ! Node: Line Control106944 ! Node: Pragmas109058 ! Node: Other Directives113326 ! Node: Preprocessor Output114520 ! Node: Traditional Mode117616 ! Node: Implementation Details123195 ! Node: Implementation-defined behavior123818 ! Node: Implementation limits126091 ! Node: Obsolete Features128798 ! Node: Assertions129285 ! Node: Obsolete once-only headers131816 ! Node: Miscellaneous obsolete features133584 ! Node: Differences from previous versions134917 ! Node: Invocation138540 ! Node: Index of Directives157052 ! Node: Concept Index158413  End Tag Table diff -Nrc3pad gcc-3.0.1/gcc/doc/cpp.info-1 gcc-3.0.2/gcc/doc/cpp.info-1 *** gcc-3.0.1/gcc/doc/cpp.info-1 Sun Aug 19 18:05:16 2001 --- gcc-3.0.2/gcc/doc/cpp.info-1 Tue Oct 23 11:00:26 2001 *************** the license is included in the accompany *** 116,122 **** section "GNU Free Documentation License". This manual contains no Invariant Sections. The Front-Cover Texts ! are (a) (see below), and the the Back-Cover Texts are (b) (see below). (a) The FSF's Front-Cover Text is: --- 116,122 ---- section "GNU Free Documentation License". This manual contains no Invariant Sections. The Front-Cover Texts ! are (a) (see below), and the Back-Cover Texts are (b) (see below). (a) The FSF's Front-Cover Text is: *************** versions::. *** 442,449 **** meaningful to C and C++. All but three of the punctuation characters in ASCII are C punctuators. The exceptions are `@', `$', and ``'. In addition, all the two- and three-character operators are punctuators. ! There are also six "digraphs", which are merely alternate ways to spell ! other punctuators. This is a second attempt to work around missing punctuation in obsolete systems. It has no negative side effects, unlike trigraphs, but does not cover as much ground. The digraphs and their corresponding normal punctuators are: --- 442,450 ---- meaningful to C and C++. All but three of the punctuation characters in ASCII are C punctuators. The exceptions are `@', `$', and ``'. In addition, all the two- and three-character operators are punctuators. ! There are also six "digraphs", which the C++ standard calls ! "alternative tokens", which are merely alternate ways to spell other ! punctuators. This is a second attempt to work around missing punctuation in obsolete systems. It has no negative side effects, unlike trigraphs, but does not cover as much ground. The digraphs and their corresponding normal punctuators are: diff -Nrc3pad gcc-3.0.1/gcc/doc/cpp.info-2 gcc-3.0.2/gcc/doc/cpp.info-2 *** gcc-3.0.1/gcc/doc/cpp.info-2 Sun Aug 19 18:05:16 2001 --- gcc-3.0.2/gcc/doc/cpp.info-2 Tue Oct 23 11:00:26 2001 *************** multi-character operators such as `+=' c *** 105,113 **** However, two tokens that don't together form a valid token cannot be pasted together. For example, you cannot concatenate `x' with `+' in either order. If you try, the preprocessor issues a warning and emits ! the two tokens as if they had been written next to each other. It is ! common to find unnecessary uses of `##' in complex macros. If you get ! this warning, it is likely that you can simply remove the `##'. Both the tokens combined by `##' could come from the macro body, but you could just as well write them as one token in the first place. --- 105,114 ---- However, two tokens that don't together form a valid token cannot be pasted together. For example, you cannot concatenate `x' with `+' in either order. If you try, the preprocessor issues a warning and emits ! the two tokens. Whether it puts white space between the tokens is ! undefined. It is common to find unnecessary uses of `##' in complex ! macros. If you get this warning, it is likely that you can simply ! remove the `##'. Both the tokens combined by `##' could come from the macro body, but you could just as well write them as one token in the first place. *************** underscores. *** 505,514 **** environment it expands to a single `%'. `__USER_LABEL_PREFIX__' ! This macro expands to a single token which is the the prefix ! applied to user labels (symbols visible to C code) in assembly. ! For example, in the `m68k-aout' environment it expands to an `_', ! but in the `m68k-coff' environment it expands to nothing. This macro will have the correct definition even if `-f(no-)underscores' is in use, but it will not be correct if --- 506,515 ---- environment it expands to a single `%'. `__USER_LABEL_PREFIX__' ! This macro expands to a single token which is the prefix applied to ! user labels (symbols visible to C code) in assembly. For example, ! in the `m68k-aout' environment it expands to an `_', but in the ! `m68k-coff' environment it expands to nothing. This macro will have the correct definition even if `-f(no-)underscores' is in use, but it will not be correct if diff -Nrc3pad gcc-3.0.1/gcc/doc/cpp.info-3 gcc-3.0.2/gcc/doc/cpp.info-3 *** gcc-3.0.1/gcc/doc/cpp.info-3 Sun Aug 19 18:05:16 2001 --- gcc-3.0.2/gcc/doc/cpp.info-3 Tue Oct 23 11:00:26 2001 *************** syntax errors. *** 182,188 **** One way to avoid this problem is to use an always-false conditional instead. For instance, put `#if 0' before the deleted code and ! `#endif' after it. This This works even if the code being turned off contains conditionals, but they must be entire conditionals (balanced `#if' and `#endif'). --- 182,188 ---- One way to avoid this problem is to use an always-false conditional instead. For instance, put `#if 0' before the deleted code and ! `#endif' after it. This works even if the code being turned off contains conditionals, but they must be entire conditionals (balanced `#if' and `#endif'). *************** used as the error message. *** 209,218 **** You would use `#error' inside of a conditional that detects a combination of parameters which you know the program does not properly support. For example, if you know that the program will not run ! properly on a Vax, you might write #ifdef __vax__ ! #error "Won't work on Vaxen. See comments at get_last_object." #endif If you have several configuration parameters that must be set up by --- 209,218 ---- You would use `#error' inside of a conditional that detects a combination of parameters which you know the program does not properly support. For example, if you know that the program will not run ! properly on a VAX, you might write #ifdef __vax__ ! #error "Won't work on VAXen. See comments at get_last_object." #endif If you have several configuration parameters that must be set up by *************** a preprocessor preserves whitespace betw *** 427,433 **** e.g. a single space. In GNU CPP, whitespace between tokens is collapsed to become a single space, with the exception that the first token on a non-directive line is preceded with sufficient spaces that it appears in ! the same column in the preprocessed output that it appeared in in the original source file. This is so the output is easy to read. *Note Differences from previous versions::. CPP does not insert any whitespace where there was none in the original source, except where --- 427,433 ---- e.g. a single space. In GNU CPP, whitespace between tokens is collapsed to become a single space, with the exception that the first token on a non-directive line is preceded with sufficient spaces that it appears in ! the same column in the preprocessed output that it appeared in the original source file. This is so the output is easy to read. *Note Differences from previous versions::. CPP does not insert any whitespace where there was none in the original source, except where *************** answers. Subsequent assertions do not o *** 808,818 **** same predicate. All the answers for any given predicate are simultaneously true. ! Assertions can be cancelled with the the `#unassert' directive. It ! has the same syntax as `#assert'. In that form it cancels only the ! answer which was specified on the `#unassert' line; other answers for ! that predicate remain true. You can cancel an entire predicate by ! leaving out the answer: #unassert PREDICATE --- 808,818 ---- same predicate. All the answers for any given predicate are simultaneously true. ! Assertions can be cancelled with the `#unassert' directive. It has ! the same syntax as `#assert'. In that form it cancels only the answer ! which was specified on the `#unassert' line; other answers for that ! predicate remain true. You can cancel an entire predicate by leaving ! out the answer: #unassert PREDICATE diff -Nrc3pad gcc-3.0.1/gcc/doc/cpp.info-4 gcc-3.0.2/gcc/doc/cpp.info-4 *** gcc-3.0.1/gcc/doc/cpp.info-4 Sun Aug 19 18:05:16 2001 --- gcc-3.0.2/gcc/doc/cpp.info-4 Tue Oct 23 11:00:26 2001 *************** single-letter options may _not_ be group *** 422,439 **** `-C' Do not discard comments. All comments are passed through to the output file, except for comments in processed directives, which ! are deleted along with the directive. Comments appearing in the ! expansion list of a macro will be preserved, and appear in place ! wherever the macro is invoked. You should be prepared for side effects when using `-C'; it causes the preprocessor to treat comments as tokens in their own right. ! For example, macro redefinitions that were trivial when comments ! were replaced by a single space might become significant when ! comments are retained. Also, comments appearing at the start of ! what would be a directive line have the effect of turning that ! line into an ordinary source line, since the first token on the ! line is no longer a `#'. `-gcc' Define the macros __GNUC__, __GNUC_MINOR__ and --- 422,435 ---- `-C' Do not discard comments. All comments are passed through to the output file, except for comments in processed directives, which ! are deleted along with the directive. You should be prepared for side effects when using `-C'; it causes the preprocessor to treat comments as tokens in their own right. ! For example, comments appearing at the start of what would be a ! directive line have the effect of turning that line into an ! ordinary source line, since the first token on the line is no ! longer a `#'. `-gcc' Define the macros __GNUC__, __GNUC_MINOR__ and *************** Concept Index *** 518,523 **** --- 514,520 ---- * # operator: Stringification. * ## operator: Concatenation. * _Pragma: Pragmas. + * alternative tokens: Tokenization. * arguments: Macro Arguments. * arguments in macro definitions: Macro Arguments. * assertions: Assertions. *************** Concept Index *** 540,545 **** --- 537,543 ---- * defined: Defined. * diagnostic: Diagnostics. * differences from previous versions: Differences from previous versions. + * digraphs: Tokenization. * directive line: The preprocessing language. * directive name: The preprocessing language. * directives: The preprocessing language. diff -Nrc3pad gcc-3.0.1/gcc/doc/cpp.texi gcc-3.0.2/gcc/doc/cpp.texi *** gcc-3.0.1/gcc/doc/cpp.texi Wed Jun 27 08:08:23 2001 --- gcc-3.0.2/gcc/doc/cpp.texi Wed Oct 17 02:06:42 2001 *************** or Back-Cover Texts. *** 32,38 **** @macro covertexts This manual contains no Invariant Sections. The Front-Cover Texts are ! (a) (see below), and the the Back-Cover Texts are (b) (see below). (a) The FSF's Front-Cover Text is: --- 32,38 ---- @macro covertexts This manual contains no Invariant Sections. The Front-Cover Texts are ! (a) (see below), and the Back-Cover Texts are (b) (see below). (a) The FSF's Front-Cover Text is: *************** be removed in GCC 3.1. You may use cont *** 536,550 **** constant concatenation. @xref{Differences from previous versions}. @cindex punctuators @dfn{Punctuators} are all the usual bits of punctuation which are meaningful to C and C++. All but three of the punctuation characters in ASCII are C punctuators. The exceptions are @samp{@@}, @samp{$}, and @samp{`}. In addition, all the two- and three-character operators are ! punctuators. There are also six @dfn{digraphs}, which are merely ! alternate ways to spell other punctuators. This is a second attempt to ! work around missing punctuation in obsolete systems. It has no negative ! side effects, unlike trigraphs, but does not cover as much ground. The ! digraphs and their corresponding normal punctuators are: @example Digraph: <% %> <: :> %: %:%: --- 536,553 ---- constant concatenation. @xref{Differences from previous versions}. @cindex punctuators + @cindex digraphs + @cindex alternative tokens @dfn{Punctuators} are all the usual bits of punctuation which are meaningful to C and C++. All but three of the punctuation characters in ASCII are C punctuators. The exceptions are @samp{@@}, @samp{$}, and @samp{`}. In addition, all the two- and three-character operators are ! punctuators. There are also six @dfn{digraphs}, which the C++ standard ! calls @dfn{alternative tokens}, which are merely alternate ways to spell ! other punctuators. This is a second attempt to work around missing ! punctuation in obsolete systems. It has no negative side effects, ! unlike trigraphs, but does not cover as much ground. The digraphs and ! their corresponding normal punctuators are: @example Digraph: <% %> <: :> %: %:%: *************** token pasting. *** 1506,1515 **** However, two tokens that don't together form a valid token cannot be pasted together. For example, you cannot concatenate @code{x} with @code{+} in either order. If you try, the preprocessor issues a warning ! and emits the two tokens as if they had been written next to each other. ! It is common to find unnecessary uses of @samp{##} in complex macros. ! If you get this warning, it is likely that you can simply remove the ! @samp{##}. Both the tokens combined by @samp{##} could come from the macro body, but you could just as well write them as one token in the first place. --- 1509,1518 ---- However, two tokens that don't together form a valid token cannot be pasted together. For example, you cannot concatenate @code{x} with @code{+} in either order. If you try, the preprocessor issues a warning ! and emits the two tokens. Whether it puts white space between the ! tokens is undefined. It is common to find unnecessary uses of @samp{##} ! in complex macros. If you get this warning, it is likely that you can ! simply remove the @samp{##}. Both the tokens combined by @samp{##} could come from the macro body, but you could just as well write them as one token in the first place. *************** expands to nothing, but in the @code{m68 *** 1947,1953 **** to a single @samp{%}. @item __USER_LABEL_PREFIX__ ! This macro expands to a single token which is the the prefix applied to user labels (symbols visible to C code) in assembly. For example, in the @code{m68k-aout} environment it expands to an @samp{_}, but in the @code{m68k-coff} environment it expands to nothing. --- 1950,1956 ---- to a single @samp{%}. @item __USER_LABEL_PREFIX__ ! This macro expands to a single token which is the prefix applied to user labels (symbols visible to C code) in assembly. For example, in the @code{m68k-aout} environment it expands to an @samp{_}, but in the @code{m68k-coff} environment it expands to nothing. *************** syntax errors. *** 2920,2926 **** One way to avoid this problem is to use an always-false conditional instead. For instance, put @code{#if 0} before the deleted code and ! @code{#endif} after it. This This works even if the code being turned off contains conditionals, but they must be entire conditionals (balanced @samp{#if} and @samp{#endif}). --- 2923,2929 ---- One way to avoid this problem is to use an always-false conditional instead. For instance, put @code{#if 0} before the deleted code and ! @code{#endif} after it. This works even if the code being turned off contains conditionals, but they must be entire conditionals (balanced @samp{#if} and @samp{#endif}). *************** are used as the error message. *** 2949,2960 **** You would use @samp{#error} inside of a conditional that detects a combination of parameters which you know the program does not properly support. For example, if you know that the program will not run ! properly on a Vax, you might write @example @group #ifdef __vax__ ! #error "Won't work on Vaxen. See comments at get_last_object." #endif @end group @end example --- 2952,2963 ---- You would use @samp{#error} inside of a conditional that detects a combination of parameters which you know the program does not properly support. For example, if you know that the program will not run ! properly on a VAX, you might write @example @group #ifdef __vax__ ! #error "Won't work on VAXen. See comments at get_last_object." #endif @end group @end example *************** preprocessor preserves whitespace betwee *** 3190,3196 **** e.g.@: a single space. In GNU CPP, whitespace between tokens is collapsed to become a single space, with the exception that the first token on a non-directive line is preceded with sufficient spaces that it appears in ! the same column in the preprocessed output that it appeared in in the original source file. This is so the output is easy to read. @xref{Differences from previous versions}. CPP does not insert any whitespace where there was none in the original source, except where --- 3193,3199 ---- e.g.@: a single space. In GNU CPP, whitespace between tokens is collapsed to become a single space, with the exception that the first token on a non-directive line is preceded with sufficient spaces that it appears in ! the same column in the preprocessed output that it appeared in the original source file. This is so the output is easy to read. @xref{Differences from previous versions}. CPP does not insert any whitespace where there was none in the original source, except where *************** simultaneously true. *** 3601,3607 **** @cindex assertions, cancelling @findex #unassert ! Assertions can be cancelled with the the @samp{#unassert} directive. It has the same syntax as @samp{#assert}. In that form it cancels only the answer which was specified on the @samp{#unassert} line; other answers for that predicate remain true. You can cancel an entire predicate by --- 3604,3610 ---- @cindex assertions, cancelling @findex #unassert ! Assertions can be cancelled with the @samp{#unassert} directive. It has the same syntax as @samp{#assert}. In that form it cancels only the answer which was specified on the @samp{#unassert} line; other answers for that predicate remain true. You can cancel an entire predicate by *************** linemarkers. @xref{Preprocessor Output} *** 4219,4233 **** @item -C Do not discard comments. All comments are passed through to the output file, except for comments in processed directives, which are deleted ! along with the directive. Comments appearing in the expansion list of a ! macro will be preserved, and appear in place wherever the macro is ! invoked. ! You should be prepared for side effects when using @option{-C}; it causes ! the preprocessor to treat comments as tokens in their own right. For ! example, macro redefinitions that were trivial when comments were ! replaced by a single space might become significant when comments are ! retained. Also, comments appearing at the start of what would be a directive line have the effect of turning that line into an ordinary source line, since the first token on the line is no longer a @samp{#}. --- 4222,4232 ---- @item -C Do not discard comments. All comments are passed through to the output file, except for comments in processed directives, which are deleted ! along with the directive. ! You should be prepared for side effects when using @option{-C}; it ! causes the preprocessor to treat comments as tokens in their own right. ! For example, comments appearing at the start of what would be a directive line have the effect of turning that line into an ordinary source line, since the first token on the line is no longer a @samp{#}. diff -Nrc3pad gcc-3.0.1/gcc/doc/extend.texi gcc-3.0.2/gcc/doc/extend.texi *** gcc-3.0.1/gcc/doc/extend.texi Sat Aug 4 04:40:55 2001 --- gcc-3.0.2/gcc/doc/extend.texi Tue Oct 9 16:14:16 2001 *************** to relate to the structure, union or enu *** 2150,2156 **** enclosing declaration the type specifier appears in, and the type defined is not complete until after the attribute specifiers. @c Otherwise, there would be the following problems: a shift/reduce ! @c conflict between attributes binding the the struct/union/enum and @c binding to the list of specifiers/qualifiers; and "aligned" @c attributes could use sizeof for the structure, but the size could be @c changed later by "packed" attributes. --- 2150,2156 ---- enclosing declaration the type specifier appears in, and the type defined is not complete until after the attribute specifiers. @c Otherwise, there would be the following problems: a shift/reduce ! @c conflict between attributes binding the struct/union/enum and @c binding to the list of specifiers/qualifiers; and "aligned" @c attributes could use sizeof for the structure, but the size could be @c changed later by "packed" attributes. *************** On some machines it may be impossible to *** 3701,3707 **** any function other than the current one; in such cases, or when the top of the stack has been reached, this function will return @code{0}. ! This function should only be used with a non-zero argument for debugging purposes. @end deftypefn --- 3701,3707 ---- any function other than the current one; in such cases, or when the top of the stack has been reached, this function will return @code{0}. ! This function should only be used with a nonzero argument for debugging purposes. @end deftypefn diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.1 gcc-3.0.2/gcc/doc/gcc.1 *** gcc-3.0.1/gcc/doc/gcc.1 Sun Aug 19 17:45:03 2001 --- gcc-3.0.2/gcc/doc/gcc.1 Wed Oct 17 06:14:31 2001 *************** *** 1,8 **** ! .\" Automatically generated by Pod::Man version 1.16 ! .\" Tue Jul 3 00:41:07 2001 .\" .\" Standard preamble: ! .\" ====================================================================== .de Sh \" Subsection heading .br .if t .Sp --- 1,8 ---- ! .\" Automatically generated by Pod::Man version 1.19 ! .\" Wed Oct 17 11:39:25 2001 .\" .\" Standard preamble: ! .\" ======================================================================== .de Sh \" Subsection heading .br .if t .Sp *************** *** 15,26 **** .if t .sp .5v .if n .sp .. - .de Ip \" List item - .br - .ie \\n(.$>=3 .ne \\$3 - .el .ne 3 - .IP "\\$1" \\$2 - .. .de Vb \" Begin verbatim text .ft CW .nf --- 15,20 ---- *************** *** 34,42 **** .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. | will give a ! .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used ! .\" to do unbreakable dashes and therefore won't be available. \*(C` and ! .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> .tr \(*W-|\(bv\*(Tr .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ --- 28,36 ---- .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. | will give a ! .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to ! .\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' ! .\" expand to `' in nroff, nothing in troff, for use with C<>. .tr \(*W-|\(bv\*(Tr .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ *************** *** 56,65 **** . ds R" '' 'br\} .\" ! .\" If the F register is turned on, we'll generate index entries on stderr ! .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and ! .\" index entries marked with X<> in POD. Of course, you'll have to process ! .\" the output yourself in some meaningful fashion. .if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" --- 50,59 ---- . ds R" '' 'br\} .\" ! .\" If the F register is turned on, we'll generate index entries on stderr for ! .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index ! .\" entries marked with X<> in POD. Of course, you'll have to process the ! .\" output yourself in some meaningful fashion. .if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" *************** *** 68,81 **** . rr F .\} .\" ! .\" For nroff, turn off justification. Always turn off hyphenation; it ! .\" makes way too many mistakes in technical documents. .hy 0 .if n .na .\" .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). .\" Fear. Run. Save yourself. No user-serviceable parts. - .bd B 3 . \" fudge factors for nroff and troff .if n \{\ . ds #H 0 --- 62,74 ---- . rr F .\} .\" ! .\" For nroff, turn off justification. Always turn off hyphenation; it makes ! .\" way too many mistakes in technical documents. .hy 0 .if n .na .\" .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). .\" Fear. Run. Save yourself. No user-serviceable parts. . \" fudge factors for nroff and troff .if n \{\ . ds #H 0 *************** *** 135,144 **** . ds Ae AE .\} .rm #[ #] #H #V #F C ! .\" ====================================================================== .\" .IX Title "GCC 1" ! .TH GCC 1 "gcc-3.0.1" "2001-07-03" "GNU" .UC .SH "NAME" gcc \- \s-1GNU\s0 project C and \*(C+ compiler --- 128,137 ---- . ds Ae AE .\} .rm #[ #] #H #V #F C ! .\" ======================================================================== .\" .IX Title "GCC 1" ! .TH GCC 1 "gcc-3.0.2" "2001-10-17" "GNU" .UC .SH "NAME" gcc \- \s-1GNU\s0 project C and \*(C+ compiler *************** only one of these two forms, whichever o *** 194,204 **** .IX Subsection "Option Summary" Here is a summary of all the options, grouped by type. Explanations are in the following sections. ! .Ip "\fIOverall Options\fR" 4 .IX Item "Overall Options" \&\fB\-c \-S \-E \-o\fR \fIfile\fR \fB\-pipe \-pass-exit-codes \-x\fR \fIlanguage\fR \&\fB\-v \-\-target-help \-\-help\fR ! .Ip "\fIC Language Options\fR" 4 .IX Item "C Language Options" \&\fB\-ansi \-std=\fR\fIstandard\fR \fB\-aux-info\fR \fIfilename\fR \&\fB\-fno-asm \-fno-builtin --- 187,197 ---- .IX Subsection "Option Summary" Here is a summary of all the options, grouped by type. Explanations are in the following sections. ! .IP "\fIOverall Options\fR" 4 .IX Item "Overall Options" \&\fB\-c \-S \-E \-o\fR \fIfile\fR \fB\-pipe \-pass-exit-codes \-x\fR \fIlanguage\fR \&\fB\-v \-\-target-help \-\-help\fR ! .IP "\fIC Language Options\fR" 4 .IX Item "C Language Options" \&\fB\-ansi \-std=\fR\fIstandard\fR \fB\-aux-info\fR \fIfilename\fR \&\fB\-fno-asm \-fno-builtin *************** in the following sections. *** 208,244 **** \&\-fsigned-bitfields \-fsigned-char \&\-funsigned-bitfields \-funsigned-char \&\-fwritable-strings \-fshort-wchar\fR ! .Ip "\fI\*(C+ Language Options\fR" 4 .IX Item " Language Options" \&\fB\-fno-access-control \-fcheck-new \-fconserve-space \&\-fno-const-strings \-fdollars-in-identifiers \&\-fno-elide-constructors \&\-fno-enforce-eh-specs \-fexternal-templates \&\-falt-external-templates ! \&\-ffor-scope \-fno-for-scope \-fno-gnu-keywords \-fno-honor-std \&\-fno-implicit-templates \&\-fno-implicit-inline-templates \&\-fno-implement-inlines \-fms-extensions \&\-fno-nonansi-builtins \-fno-operator-names \&\-fno-optional-diags \-fpermissive \&\-frepo \-fno-rtti \-fstats \-ftemplate-depth-\fR\fIn\fR ! \&\fB\-fuse-cxa-atexit \-fvtable-gc \-fno-weak \-nostdinc++ \&\-fno-default-inline \-Wctor-dtor-privacy \&\-Wnon-virtual-dtor \-Wreorder \&\-Weffc++ \-Wno-deprecated \&\-Wno-non-template-friend \-Wold-style-cast \&\-Woverloaded-virtual \-Wno-pmf-conversions \&\-Wsign-promo \-Wsynth\fR ! .Ip "\fIObjective-C Language Options\fR" 4 .IX Item "Objective-C Language Options" \&\fB\-fconstant-string-class=\fR\fIclass-name\fR \&\fB\-fgnu-runtime \-fnext-runtime \-gen-decls \&\-Wno-protocol \-Wselector\fR ! .Ip "\fILanguage Independent Options\fR" 4 .IX Item "Language Independent Options" \&\fB\-fmessage-length=\fR\fIn\fR \&\fB\-fdiagnostics-show-location=\fR[\fBonce\fR|\fBevery-line\fR] ! .Ip "\fIWarning Options\fR" 4 .IX Item "Warning Options" \&\fB\-fsyntax-only \-pedantic \-pedantic-errors \&\-w \-W \-Wall \-Waggregate-return --- 201,237 ---- \&\-fsigned-bitfields \-fsigned-char \&\-funsigned-bitfields \-funsigned-char \&\-fwritable-strings \-fshort-wchar\fR ! .IP "\fI\*(C+ Language Options\fR" 4 .IX Item " Language Options" \&\fB\-fno-access-control \-fcheck-new \-fconserve-space \&\-fno-const-strings \-fdollars-in-identifiers \&\-fno-elide-constructors \&\-fno-enforce-eh-specs \-fexternal-templates \&\-falt-external-templates ! \&\-ffor-scope \-fno-for-scope \-fno-gnu-keywords \&\-fno-implicit-templates \&\-fno-implicit-inline-templates \&\-fno-implement-inlines \-fms-extensions \&\-fno-nonansi-builtins \-fno-operator-names \&\-fno-optional-diags \-fpermissive \&\-frepo \-fno-rtti \-fstats \-ftemplate-depth-\fR\fIn\fR ! \&\fB\-fuse-cxa-atexit \-fno-weak \-nostdinc++ \&\-fno-default-inline \-Wctor-dtor-privacy \&\-Wnon-virtual-dtor \-Wreorder \&\-Weffc++ \-Wno-deprecated \&\-Wno-non-template-friend \-Wold-style-cast \&\-Woverloaded-virtual \-Wno-pmf-conversions \&\-Wsign-promo \-Wsynth\fR ! .IP "\fIObjective-C Language Options\fR" 4 .IX Item "Objective-C Language Options" \&\fB\-fconstant-string-class=\fR\fIclass-name\fR \&\fB\-fgnu-runtime \-fnext-runtime \-gen-decls \&\-Wno-protocol \-Wselector\fR ! .IP "\fILanguage Independent Options\fR" 4 .IX Item "Language Independent Options" \&\fB\-fmessage-length=\fR\fIn\fR \&\fB\-fdiagnostics-show-location=\fR[\fBonce\fR|\fBevery-line\fR] ! .IP "\fIWarning Options\fR" 4 .IX Item "Warning Options" \&\fB\-fsyntax-only \-pedantic \-pedantic-errors \&\-w \-W \-Wall \-Waggregate-return *************** in the following sections. *** 262,272 **** \&\-Wunknown-pragmas \-Wunreachable-code \&\-Wunused \-Wunused-function \-Wunused-label \-Wunused-parameter \&\-Wunused-value \-Wunused-variable \-Wwrite-strings\fR ! .Ip "\fIC-only Warning Options\fR" 4 .IX Item "C-only Warning Options" \&\fB\-Wbad-function-cast \-Wmissing-prototypes \-Wnested-externs \&\-Wstrict-prototypes \-Wtraditional\fR ! .Ip "\fIDebugging Options\fR" 4 .IX Item "Debugging Options" \&\fB\-a \-ax \-d\fR\fIletters\fR \fB\-dumpspecs \-dumpmachine \-dumpversion \&\-fdump-unnumbered \-fdump-translation-unit\fR[\fB-\fR\fIn\fR] --- 255,265 ---- \&\-Wunknown-pragmas \-Wunreachable-code \&\-Wunused \-Wunused-function \-Wunused-label \-Wunused-parameter \&\-Wunused-value \-Wunused-variable \-Wwrite-strings\fR ! .IP "\fIC-only Warning Options\fR" 4 .IX Item "C-only Warning Options" \&\fB\-Wbad-function-cast \-Wmissing-prototypes \-Wnested-externs \&\-Wstrict-prototypes \-Wtraditional\fR ! .IP "\fIDebugging Options\fR" 4 .IX Item "Debugging Options" \&\fB\-a \-ax \-d\fR\fIletters\fR \fB\-dumpspecs \-dumpmachine \-dumpversion \&\-fdump-unnumbered \-fdump-translation-unit\fR[\fB-\fR\fIn\fR] *************** in the following sections. *** 280,286 **** \&\-print-multi-directory \-print-multi-lib \&\-print-prog-name=\fR\fIprogram\fR \fB\-print-search-dirs \-Q \&\-save-temps \-time\fR ! .Ip "\fIOptimization Options\fR" 4 .IX Item "Optimization Options" \&\fB\-falign-functions=\fR\fIn\fR \fB\-falign-jumps=\fR\fIn\fR \&\fB\-falign-labels=\fR\fIn\fR \fB\-falign-loops=\fR\fIn\fR --- 273,279 ---- \&\-print-multi-directory \-print-multi-lib \&\-print-prog-name=\fR\fIprogram\fR \fB\-print-search-dirs \-Q \&\-save-temps \-time\fR ! .IP "\fIOptimization Options\fR" 4 .IX Item "Optimization Options" \&\fB\-falign-functions=\fR\fIn\fR \fB\-falign-jumps=\fR\fIn\fR \&\fB\-falign-labels=\fR\fIn\fR \fB\-falign-loops=\fR\fIn\fR *************** in the following sections. *** 304,310 **** \&\-funroll-all-loops \-funroll-loops \&\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR \&\fB\-O \-O0 \-O1 \-O2 \-O3 \-Os\fR ! .Ip "\fIPreprocessor Options\fR" 4 .IX Item "Preprocessor Options" \&\fB\-$ \-A\fR\fIquestion\fR\fB=\fR\fIanswer\fR \fB\-A-\fR\fIquestion\fR[\fB=\fR\fIanswer\fR] \&\fB\-C \-dD \-dI \-dM \-dN --- 297,303 ---- \&\-funroll-all-loops \-funroll-loops \&\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR \&\fB\-O \-O0 \-O1 \-O2 \-O3 \-Os\fR ! .IP "\fIPreprocessor Options\fR" 4 .IX Item "Preprocessor Options" \&\fB\-$ \-A\fR\fIquestion\fR\fB=\fR\fIanswer\fR \fB\-A-\fR\fIquestion\fR[\fB=\fR\fIanswer\fR] \&\fB\-C \-dD \-dI \-dM \-dN *************** in the following sections. *** 315,324 **** \&\fB\-iwithprefixbefore\fR \fIdir\fR \fB\-isystem\fR \fIdir\fR \&\fB\-M \-MM \-MF \-MG \-MP \-MQ \-MT \-nostdinc \-P \-remap \&\-trigraphs \-undef \-U\fR\fImacro\fR \fB\-Wp,\fR\fIoption\fR ! .Ip "\fIAssembler Option\fR" 4 .IX Item "Assembler Option" \&\fB\-Wa,\fR\fIoption\fR ! .Ip "\fILinker Options\fR" 4 .IX Item "Linker Options" \&\fB \&\fR\fIobject-file-name\fR \fB\-l\fR\fIlibrary\fR --- 308,317 ---- \&\fB\-iwithprefixbefore\fR \fIdir\fR \fB\-isystem\fR \fIdir\fR \&\fB\-M \-MM \-MF \-MG \-MP \-MQ \-MT \-nostdinc \-P \-remap \&\-trigraphs \-undef \-U\fR\fImacro\fR \fB\-Wp,\fR\fIoption\fR ! .IP "\fIAssembler Option\fR" 4 .IX Item "Assembler Option" \&\fB\-Wa,\fR\fIoption\fR ! .IP "\fILinker Options\fR" 4 .IX Item "Linker Options" \&\fB \&\fR\fIobject-file-name\fR \fB\-l\fR\fIlibrary\fR *************** in the following sections. *** 326,338 **** \&\-s \-static \-static-libgcc \-shared \-shared-libgcc \-symbolic \&\-Wl,\fR\fIoption\fR \fB\-Xlinker\fR \fIoption\fR \&\fB\-u\fR \fIsymbol\fR ! .Ip "\fIDirectory Options\fR" 4 .IX Item "Directory Options" \&\fB\-B\fR\fIprefix\fR \fB\-I\fR\fIdir\fR \fB\-I- \-L\fR\fIdir\fR \fB\-specs=\fR\fIfile\fR ! .Ip "\fITarget Options\fR" 4 .IX Item "Target Options" \&\fB\-b\fR \fImachine\fR \fB\-V\fR \fIversion\fR ! .Ip "\fIMachine Dependent Options\fR" 4 .IX Item "Machine Dependent Options" \&\fIM680x0 Options\fR .Sp --- 319,331 ---- \&\-s \-static \-static-libgcc \-shared \-shared-libgcc \-symbolic \&\-Wl,\fR\fIoption\fR \fB\-Xlinker\fR \fIoption\fR \&\fB\-u\fR \fIsymbol\fR ! .IP "\fIDirectory Options\fR" 4 .IX Item "Directory Options" \&\fB\-B\fR\fIprefix\fR \fB\-I\fR\fIdir\fR \fB\-I- \-L\fR\fIdir\fR \fB\-specs=\fR\fIfile\fR ! .IP "\fITarget Options\fR" 4 .IX Item "Target Options" \&\fB\-b\fR \fImachine\fR \fB\-V\fR \fIversion\fR ! .IP "\fIMachine Dependent Options\fR" 4 .IX Item "Machine Dependent Options" \&\fIM680x0 Options\fR .Sp *************** in the following sections. *** 594,600 **** \&\-mconstant-gp \-mauto-pic \-minline-divide-min-latency \&\-minline-divide-max-throughput \-mno-dwarf2\-asm \&\-mfixed-range=\fR\fIregister-range\fR ! .Ip "\fICode Generation Options\fR" 4 .IX Item "Code Generation Options" \&\fB\-fcall-saved-\fR\fIreg\fR \fB\-fcall-used-\fR\fIreg\fR \&\fB\-ffixed-\fR\fIreg\fR \fB\-fexceptions --- 587,599 ---- \&\-mconstant-gp \-mauto-pic \-minline-divide-min-latency \&\-minline-divide-max-throughput \-mno-dwarf2\-asm \&\-mfixed-range=\fR\fIregister-range\fR ! .Sp ! \&\fIS/390 and zSeries Options\fR ! .Sp ! \&\fB\-mhard-float \-msoft-float \-mbackchain \-mno-backchain ! \&\-msmall-exec \-mno-small-exec \-mmvcle \-mno-mvcle ! \&\-m64 \-m31 \-mdebug \-mno-debug\fR ! .IP "\fICode Generation Options\fR" 4 .IX Item "Code Generation Options" \&\fB\-fcall-saved-\fR\fIreg\fR \fB\-fcall-used-\fR\fIreg\fR \&\fB\-ffixed-\fR\fIreg\fR \fB\-fexceptions *************** compiled, and those specified as input) *** 620,697 **** .PP For any given input file, the file name suffix determines what kind of compilation is done: ! .Ip "\fIfile\fR\fB.c\fR" 4 .IX Item "file.c" C source code which must be preprocessed. ! .Ip "\fIfile\fR\fB.i\fR" 4 .IX Item "file.i" C source code which should not be preprocessed. ! .Ip "\fIfile\fR\fB.ii\fR" 4 .IX Item "file.ii" \&\*(C+ source code which should not be preprocessed. ! .Ip "\fIfile\fR\fB.m\fR" 4 .IX Item "file.m" Objective-C source code. Note that you must link with the library \&\fIlibobjc.a\fR to make an Objective-C program work. ! .Ip "\fIfile\fR\fB.mi\fR" 4 .IX Item "file.mi" Objective-C source code which should not be preprocessed. ! .Ip "\fIfile\fR\fB.h\fR" 4 .IX Item "file.h" C header file (not to be compiled or linked). ! .Ip "\fIfile\fR\fB.cc\fR" 4 .IX Item "file.cc" .PD 0 ! .Ip "\fIfile\fR\fB.cp\fR" 4 .IX Item "file.cp" ! .Ip "\fIfile\fR\fB.cxx\fR" 4 .IX Item "file.cxx" ! .Ip "\fIfile\fR\fB.cpp\fR" 4 .IX Item "file.cpp" ! .Ip "\fIfile\fR\fB.c++\fR" 4 .IX Item "file.c++" ! .Ip "\fIfile\fR\fB.C\fR" 4 .IX Item "file.C" .PD \&\*(C+ source code which must be preprocessed. Note that in \fB.cxx\fR, the last two letters must both be literally \fBx\fR. Likewise, \&\fB.C\fR refers to a literal capital C. ! .Ip "\fIfile\fR\fB.f\fR" 4 .IX Item "file.f" .PD 0 ! .Ip "\fIfile\fR\fB.for\fR" 4 .IX Item "file.for" ! .Ip "\fIfile\fR\fB.FOR\fR" 4 .IX Item "file.FOR" .PD Fortran source code which should not be preprocessed. ! .Ip "\fIfile\fR\fB.F\fR" 4 .IX Item "file.F" .PD 0 ! .Ip "\fIfile\fR\fB.fpp\fR" 4 .IX Item "file.fpp" ! .Ip "\fIfile\fR\fB.FPP\fR" 4 .IX Item "file.FPP" .PD Fortran source code which must be preprocessed (with the traditional preprocessor). ! .Ip "\fIfile\fR\fB.r\fR" 4 .IX Item "file.r" Fortran source code which must be preprocessed with a \s-1RATFOR\s0 preprocessor (not included with \s-1GCC\s0). ! .Ip "\fIfile\fR\fB.s\fR" 4 .IX Item "file.s" Assembler code. ! .Ip "\fIfile\fR\fB.S\fR" 4 .IX Item "file.S" Assembler code which must be preprocessed. ! .Ip "\fIother\fR" 4 .IX Item "other" An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way. .PP You can specify the input language explicitly with the \fB\-x\fR option: ! .Ip "\fB\-x\fR \fIlanguage\fR" 4 .IX Item "-x language" Specify explicitly the \fIlanguage\fR for the following input files (rather than letting the compiler choose a default based on the file --- 619,696 ---- .PP For any given input file, the file name suffix determines what kind of compilation is done: ! .IP "\fIfile\fR\fB.c\fR" 4 .IX Item "file.c" C source code which must be preprocessed. ! .IP "\fIfile\fR\fB.i\fR" 4 .IX Item "file.i" C source code which should not be preprocessed. ! .IP "\fIfile\fR\fB.ii\fR" 4 .IX Item "file.ii" \&\*(C+ source code which should not be preprocessed. ! .IP "\fIfile\fR\fB.m\fR" 4 .IX Item "file.m" Objective-C source code. Note that you must link with the library \&\fIlibobjc.a\fR to make an Objective-C program work. ! .IP "\fIfile\fR\fB.mi\fR" 4 .IX Item "file.mi" Objective-C source code which should not be preprocessed. ! .IP "\fIfile\fR\fB.h\fR" 4 .IX Item "file.h" C header file (not to be compiled or linked). ! .IP "\fIfile\fR\fB.cc\fR" 4 .IX Item "file.cc" .PD 0 ! .IP "\fIfile\fR\fB.cp\fR" 4 .IX Item "file.cp" ! .IP "\fIfile\fR\fB.cxx\fR" 4 .IX Item "file.cxx" ! .IP "\fIfile\fR\fB.cpp\fR" 4 .IX Item "file.cpp" ! .IP "\fIfile\fR\fB.c++\fR" 4 .IX Item "file.c++" ! .IP "\fIfile\fR\fB.C\fR" 4 .IX Item "file.C" .PD \&\*(C+ source code which must be preprocessed. Note that in \fB.cxx\fR, the last two letters must both be literally \fBx\fR. Likewise, \&\fB.C\fR refers to a literal capital C. ! .IP "\fIfile\fR\fB.f\fR" 4 .IX Item "file.f" .PD 0 ! .IP "\fIfile\fR\fB.for\fR" 4 .IX Item "file.for" ! .IP "\fIfile\fR\fB.FOR\fR" 4 .IX Item "file.FOR" .PD Fortran source code which should not be preprocessed. ! .IP "\fIfile\fR\fB.F\fR" 4 .IX Item "file.F" .PD 0 ! .IP "\fIfile\fR\fB.fpp\fR" 4 .IX Item "file.fpp" ! .IP "\fIfile\fR\fB.FPP\fR" 4 .IX Item "file.FPP" .PD Fortran source code which must be preprocessed (with the traditional preprocessor). ! .IP "\fIfile\fR\fB.r\fR" 4 .IX Item "file.r" Fortran source code which must be preprocessed with a \s-1RATFOR\s0 preprocessor (not included with \s-1GCC\s0). ! .IP "\fIfile\fR\fB.s\fR" 4 .IX Item "file.s" Assembler code. ! .IP "\fIfile\fR\fB.S\fR" 4 .IX Item "file.S" Assembler code which must be preprocessed. ! .IP "\fIother\fR" 4 .IX Item "other" An object file to be fed straight into linking. Any file name with no recognized suffix is treated this way. .PP You can specify the input language explicitly with the \fB\-x\fR option: ! .IP "\fB\-x\fR \fIlanguage\fR" 4 .IX Item "-x language" Specify explicitly the \fIlanguage\fR for the following input files (rather than letting the compiler choose a default based on the file *************** the next \fB\-x\fR option. Possible val *** 706,717 **** \& f77 f77-cpp-input ratfor \& java .Ve ! .Ip "\fB\-x none\fR" 4 .IX Item "-x none" Turn off any specification of a language, so that subsequent files are handled according to their file name suffixes (as they are if \fB\-x\fR has not been used at all). ! .Ip "\fB\-pass-exit-codes\fR" 4 .IX Item "-pass-exit-codes" Normally the \fBgcc\fR program will exit with the code of 1 if any phase of the compiler returns a non-success return code. If you specify --- 705,716 ---- \& f77 f77-cpp-input ratfor \& java .Ve ! .IP "\fB\-x none\fR" 4 .IX Item "-x none" Turn off any specification of a language, so that subsequent files are handled according to their file name suffixes (as they are if \fB\-x\fR has not been used at all). ! .IP "\fB\-pass-exit-codes\fR" 4 .IX Item "-pass-exit-codes" Normally the \fBgcc\fR program will exit with the code of 1 if any phase of the compiler returns a non-success return code. If you specify *************** If you only want some of the stages of c *** 724,730 **** one of the options \fB\-c\fR, \fB\-S\fR, or \fB\-E\fR to say where \&\fBgcc\fR is to stop. Note that some combinations (for example, \&\fB\-x cpp-output \-E\fR) instruct \fBgcc\fR to do nothing at all. ! .Ip "\fB\-c\fR" 4 .IX Item "-c" Compile or assemble the source files, but do not link. The linking stage simply is not done. The ultimate output is in the form of an --- 723,729 ---- one of the options \fB\-c\fR, \fB\-S\fR, or \fB\-E\fR to say where \&\fBgcc\fR is to stop. Note that some combinations (for example, \&\fB\-x cpp-output \-E\fR) instruct \fBgcc\fR to do nothing at all. ! .IP "\fB\-c\fR" 4 .IX Item "-c" Compile or assemble the source files, but do not link. The linking stage simply is not done. The ultimate output is in the form of an *************** the suffix \fB.c\fR, \fB.i\fR, \fB.s\fR, *** 735,741 **** .Sp Unrecognized input files, not requiring compilation or assembly, are ignored. ! .Ip "\fB\-S\fR" 4 .IX Item "-S" Stop after the stage of compilation proper; do not assemble. The output is in the form of an assembler code file for each non-assembler input --- 734,740 ---- .Sp Unrecognized input files, not requiring compilation or assembly, are ignored. ! .IP "\fB\-S\fR" 4 .IX Item "-S" Stop after the stage of compilation proper; do not assemble. The output is in the form of an assembler code file for each non-assembler input *************** By default, the assembler file name for *** 745,758 **** replacing the suffix \fB.c\fR, \fB.i\fR, etc., with \fB.s\fR. .Sp Input files that don't require compilation are ignored. ! .Ip "\fB\-E\fR" 4 .IX Item "-E" Stop after the preprocessing stage; do not run the compiler proper. The output is in the form of preprocessed source code, which is sent to the standard output. .Sp Input files which don't require preprocessing are ignored. ! .Ip "\fB\-o\fR \fIfile\fR" 4 .IX Item "-o file" Place output in file \fIfile\fR. This applies regardless to whatever sort of output is being produced, whether it be an executable file, --- 744,757 ---- replacing the suffix \fB.c\fR, \fB.i\fR, etc., with \fB.s\fR. .Sp Input files that don't require compilation are ignored. ! .IP "\fB\-E\fR" 4 .IX Item "-E" Stop after the preprocessing stage; do not run the compiler proper. The output is in the form of preprocessed source code, which is sent to the standard output. .Sp Input files which don't require preprocessing are ignored. ! .IP "\fB\-o\fR \fIfile\fR" 4 .IX Item "-o file" Place output in file \fIfile\fR. This applies regardless to whatever sort of output is being produced, whether it be an executable file, *************** If \fB\-o\fR is not specified, the defau *** 766,783 **** in \fIa.out\fR, the object file for \fI\fIsource\fI.\fIsuffix\fI\fR in \&\fI\fIsource\fI.o\fR, its assembler file in \fI\fIsource\fI.s\fR, and all preprocessed C source on standard output. ! .Ip "\fB\-v\fR" 4 .IX Item "-v" Print (on standard error output) the commands executed to run the stages of compilation. Also print the version number of the compiler driver program and of the preprocessor and the compiler proper. ! .Ip "\fB\-pipe\fR" 4 .IX Item "-pipe" Use pipes rather than temporary files for communication between the various stages of compilation. This fails to work on some systems where the assembler is unable to read from a pipe; but the \s-1GNU\s0 assembler has no trouble. ! .Ip "\fB\*(--help\fR" 4 .IX Item "help" Print (on the standard output) a description of the command line options understood by \fBgcc\fR. If the \fB\-v\fR option is also specified --- 765,782 ---- in \fIa.out\fR, the object file for \fI\fIsource\fI.\fIsuffix\fI\fR in \&\fI\fIsource\fI.o\fR, its assembler file in \fI\fIsource\fI.s\fR, and all preprocessed C source on standard output. ! .IP "\fB\-v\fR" 4 .IX Item "-v" Print (on standard error output) the commands executed to run the stages of compilation. Also print the version number of the compiler driver program and of the preprocessor and the compiler proper. ! .IP "\fB\-pipe\fR" 4 .IX Item "-pipe" Use pipes rather than temporary files for communication between the various stages of compilation. This fails to work on some systems where the assembler is unable to read from a pipe; but the \s-1GNU\s0 assembler has no trouble. ! .IP "\fB\*(--help\fR" 4 .IX Item "help" Print (on the standard output) a description of the command line options understood by \fBgcc\fR. If the \fB\-v\fR option is also specified *************** invoked by \fBgcc\fR, so that they can d *** 786,792 **** they accept. If the \fB\-W\fR option is also specified then command line options which have no documentation associated with them will also be displayed. ! .Ip "\fB\*(--target-help\fR" 4 .IX Item "target-help" Print (on the standard output) a description of target specific command line options for each tool. --- 785,791 ---- they accept. If the \fB\-W\fR option is also specified then command line options which have no documentation associated with them will also be displayed. ! .IP "\fB\*(--target-help\fR" 4 .IX Item "target-help" Print (on the standard output) a description of target specific command line options for each tool. *************** languages; or options that are meaningfu *** 816,822 **** .IX Subsection "Options Controlling C Dialect" The following options control the dialect of C (or languages derived from C, such as \*(C+ and Objective C) that the compiler accepts: ! .Ip "\fB\-ansi\fR" 4 .IX Item "-ansi" In C mode, support all \s-1ISO\s0 C89 programs. In \*(C+ mode, remove \s-1GNU\s0 extensions that conflict with \s-1ISO\s0 \*(C+. --- 815,821 ---- .IX Subsection "Options Controlling C Dialect" The following options control the dialect of C (or languages derived from C, such as \*(C+ and Objective C) that the compiler accepts: ! .IP "\fB\-ansi\fR" 4 .IX Item "-ansi" In C mode, support all \s-1ISO\s0 C89 programs. In \*(C+ mode, remove \s-1GNU\s0 extensions that conflict with \s-1ISO\s0 \*(C+. *************** programs that might use these names for *** 851,892 **** Functions which would normally be built in but do not have semantics defined by \s-1ISO\s0 C (such as \f(CW\*(C`alloca\*(C'\fR and \f(CW\*(C`ffs\*(C'\fR) are not built-in functions with \fB\-ansi\fR is used. ! .Ip "\fB\-std=\fR" 4 .IX Item "-std=" Determine the language standard. This option is currently only supported when compiling C. A value for this option must be provided; possible values are .RS 4 ! .Ip "\fBc89\fR" 4 .IX Item "c89" .PD 0 ! .Ip "\fBiso9899:1990\fR" 4 .IX Item "iso9899:1990" .PD \&\s-1ISO\s0 C89 (same as \fB\-ansi\fR). ! .Ip "\fBiso9899:199409\fR" 4 .IX Item "iso9899:199409" \&\s-1ISO\s0 C89 as modified in amendment 1. ! .Ip "\fBc99\fR" 4 .IX Item "c99" .PD 0 ! .Ip "\fBc9x\fR" 4 .IX Item "c9x" ! .Ip "\fBiso9899:1999\fR" 4 .IX Item "iso9899:1999" ! .Ip "\fBiso9899:199x\fR" 4 .IX Item "iso9899:199x" .PD \&\s-1ISO\s0 C99. Note that this standard is not yet fully supported; see <\fBhttp://gcc.gnu.org/c99status.html\fR> for more information. The names \fBc9x\fR and \fBiso9899:199x\fR are deprecated. ! .Ip "\fBgnu89\fR" 4 .IX Item "gnu89" Default, \s-1ISO\s0 C89 plus \s-1GNU\s0 extensions (including some C99 features). ! .Ip "\fBgnu99\fR" 4 .IX Item "gnu99" .PD 0 ! .Ip "\fBgnu9x\fR" 4 .IX Item "gnu9x" .PD \&\s-1ISO\s0 C99 plus \s-1GNU\s0 extensions. When \s-1ISO\s0 C99 is fully implemented in \s-1GCC\s0, --- 850,891 ---- Functions which would normally be built in but do not have semantics defined by \s-1ISO\s0 C (such as \f(CW\*(C`alloca\*(C'\fR and \f(CW\*(C`ffs\*(C'\fR) are not built-in functions with \fB\-ansi\fR is used. ! .IP "\fB\-std=\fR" 4 .IX Item "-std=" Determine the language standard. This option is currently only supported when compiling C. A value for this option must be provided; possible values are .RS 4 ! .IP "\fBc89\fR" 4 .IX Item "c89" .PD 0 ! .IP "\fBiso9899:1990\fR" 4 .IX Item "iso9899:1990" .PD \&\s-1ISO\s0 C89 (same as \fB\-ansi\fR). ! .IP "\fBiso9899:199409\fR" 4 .IX Item "iso9899:199409" \&\s-1ISO\s0 C89 as modified in amendment 1. ! .IP "\fBc99\fR" 4 .IX Item "c99" .PD 0 ! .IP "\fBc9x\fR" 4 .IX Item "c9x" ! .IP "\fBiso9899:1999\fR" 4 .IX Item "iso9899:1999" ! .IP "\fBiso9899:199x\fR" 4 .IX Item "iso9899:199x" .PD \&\s-1ISO\s0 C99. Note that this standard is not yet fully supported; see <\fBhttp://gcc.gnu.org/c99status.html\fR> for more information. The names \fBc9x\fR and \fBiso9899:199x\fR are deprecated. ! .IP "\fBgnu89\fR" 4 .IX Item "gnu89" Default, \s-1ISO\s0 C89 plus \s-1GNU\s0 extensions (including some C99 features). ! .IP "\fBgnu99\fR" 4 .IX Item "gnu99" .PD 0 ! .IP "\fBgnu9x\fR" 4 .IX Item "gnu9x" .PD \&\s-1ISO\s0 C99 plus \s-1GNU\s0 extensions. When \s-1ISO\s0 C99 is fully implemented in \s-1GCC\s0, *************** effects as \fB\-ansi\fR, except that fea *** 904,910 **** but are in the specified version (for example, \fB//\fR comments and the \f(CW\*(C`inline\*(C'\fR keyword in \s-1ISO\s0 C99) are not disabled. .RE ! .Ip "\fB\-aux-info\fR \fIfilename\fR" 4 .IX Item "-aux-info filename" Output to the given filename prototyped declarations for all functions declared and/or defined in a translation unit, including those in header --- 903,909 ---- but are in the specified version (for example, \fB//\fR comments and the \f(CW\*(C`inline\*(C'\fR keyword in \s-1ISO\s0 C99) are not disabled. .RE ! .IP "\fB\-aux-info\fR \fIfilename\fR" 4 .IX Item "-aux-info filename" Output to the given filename prototyped declarations for all functions declared and/or defined in a translation unit, including those in header *************** definition (\fBC\fR or \fBF\fR, respecti *** 919,925 **** character). In the case of function definitions, a K&R-style list of arguments followed by their declarations is also provided, inside comments, after the declaration. ! .Ip "\fB\-fno-asm\fR" 4 .IX Item "-fno-asm" Do not recognize \f(CW\*(C`asm\*(C'\fR, \f(CW\*(C`inline\*(C'\fR or \f(CW\*(C`typeof\*(C'\fR as a keyword, so that code can use these words as identifiers. You can use --- 918,924 ---- character). In the case of function definitions, a K&R-style list of arguments followed by their declarations is also provided, inside comments, after the declaration. ! .IP "\fB\-fno-asm\fR" 4 .IX Item "-fno-asm" Do not recognize \f(CW\*(C`asm\*(C'\fR, \f(CW\*(C`inline\*(C'\fR or \f(CW\*(C`typeof\*(C'\fR as a keyword, so that code can use these words as identifiers. You can use *************** use the \fB\-fno-gnu-keywords\fR flag in *** 932,938 **** effect. In C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR), this switch only affects the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, since \&\f(CW\*(C`inline\*(C'\fR is a standard keyword in \s-1ISO\s0 C99. ! .Ip "\fB\-fno-builtin\fR" 4 .IX Item "-fno-builtin" Don't recognize built-in functions that do not begin with \&\fB_\|_builtin_\fR as prefix. --- 931,937 ---- effect. In C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR), this switch only affects the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, since \&\f(CW\*(C`inline\*(C'\fR is a standard keyword in \s-1ISO\s0 C99. ! .IP "\fB\-fno-builtin\fR" 4 .IX Item "-fno-builtin" Don't recognize built-in functions that do not begin with \&\fB_\|_builtin_\fR as prefix. *************** optimization benefits of built-in functi *** 951,1008 **** using the \fB_\|_builtin_\fR prefix. The \s-1GNU\s0 \*(C+ Standard Library uses built-in functions to implement many functions (like \&\f(CW\*(C`std::strchr\*(C'\fR), so that you automatically get efficient code. ! .Ip "\fB\-fhosted\fR" 4 .IX Item "-fhosted" Assert that compilation takes place in a hosted environment. This implies \&\fB\-fbuiltin\fR. A hosted environment is one in which the entire standard library is available, and in which \f(CW\*(C`main\*(C'\fR has a return type of \f(CW\*(C`int\*(C'\fR. Examples are nearly everything except a kernel. This is equivalent to \fB\-fno-freestanding\fR. ! .Ip "\fB\-ffreestanding\fR" 4 .IX Item "-ffreestanding" Assert that compilation takes place in a freestanding environment. This implies \fB\-fno-builtin\fR. A freestanding environment is one in which the standard library may not exist, and program startup may not necessarily be at \f(CW\*(C`main\*(C'\fR. The most obvious example is an \s-1OS\s0 kernel. This is equivalent to \fB\-fno-hosted\fR. ! .Ip "\fB\-trigraphs\fR" 4 .IX Item "-trigraphs" Support \s-1ISO\s0 C trigraphs. The \fB\-ansi\fR option (and \fB\-std\fR options for strict \s-1ISO\s0 C conformance) implies \fB\-trigraphs\fR. ! .Ip "\fB\-traditional\fR" 4 .IX Item "-traditional" Attempt to support some aspects of traditional C compilers. Specifically: .RS 4 ! .Ip "\(bu" 4 All \f(CW\*(C`extern\*(C'\fR declarations take effect globally even if they are written inside of a function definition. This includes implicit declarations of functions. ! .Ip "\(bu" 4 The newer keywords \f(CW\*(C`typeof\*(C'\fR, \f(CW\*(C`inline\*(C'\fR, \f(CW\*(C`signed\*(C'\fR, \f(CW\*(C`const\*(C'\fR and \f(CW\*(C`volatile\*(C'\fR are not recognized. (You can still use the alternative keywords such as \f(CW\*(C`_\|_typeof_\|_\*(C'\fR, \f(CW\*(C`_\|_inline_\|_\*(C'\fR, and so on.) ! .Ip "\(bu" 4 Comparisons between pointers and integers are always allowed. ! .Ip "\(bu" 4 Integer types \f(CW\*(C`unsigned short\*(C'\fR and \f(CW\*(C`unsigned char\*(C'\fR promote to \f(CW\*(C`unsigned int\*(C'\fR. ! .Ip "\(bu" 4 Out-of-range floating point literals are not an error. ! .Ip "\(bu" 4 Certain constructs which \s-1ISO\s0 regards as a single invalid preprocessing number, such as \fB0xe-0xd\fR, are treated as expressions instead. ! .Ip "\(bu" 4 String ``constants'' are not necessarily constant; they are stored in writable space, and identical looking constants are allocated separately. (This is the same as the effect of \&\fB\-fwritable-strings\fR.) ! .Ip "\(bu" 4 All automatic variables not declared \f(CW\*(C`register\*(C'\fR are preserved by \&\f(CW\*(C`longjmp\*(C'\fR. Ordinarily, \s-1GNU\s0 C follows \s-1ISO\s0 C: automatic variables not declared \f(CW\*(C`volatile\*(C'\fR may be clobbered. ! .Ip "\(bu" 4 The character escape sequences \fB\ex\fR and \fB\ea\fR evaluate as the literal characters \fBx\fR and \fBa\fR respectively. Without \&\fB\-traditional\fR, \fB\ex\fR is a prefix for the hexadecimal --- 950,1007 ---- using the \fB_\|_builtin_\fR prefix. The \s-1GNU\s0 \*(C+ Standard Library uses built-in functions to implement many functions (like \&\f(CW\*(C`std::strchr\*(C'\fR), so that you automatically get efficient code. ! .IP "\fB\-fhosted\fR" 4 .IX Item "-fhosted" Assert that compilation takes place in a hosted environment. This implies \&\fB\-fbuiltin\fR. A hosted environment is one in which the entire standard library is available, and in which \f(CW\*(C`main\*(C'\fR has a return type of \f(CW\*(C`int\*(C'\fR. Examples are nearly everything except a kernel. This is equivalent to \fB\-fno-freestanding\fR. ! .IP "\fB\-ffreestanding\fR" 4 .IX Item "-ffreestanding" Assert that compilation takes place in a freestanding environment. This implies \fB\-fno-builtin\fR. A freestanding environment is one in which the standard library may not exist, and program startup may not necessarily be at \f(CW\*(C`main\*(C'\fR. The most obvious example is an \s-1OS\s0 kernel. This is equivalent to \fB\-fno-hosted\fR. ! .IP "\fB\-trigraphs\fR" 4 .IX Item "-trigraphs" Support \s-1ISO\s0 C trigraphs. The \fB\-ansi\fR option (and \fB\-std\fR options for strict \s-1ISO\s0 C conformance) implies \fB\-trigraphs\fR. ! .IP "\fB\-traditional\fR" 4 .IX Item "-traditional" Attempt to support some aspects of traditional C compilers. Specifically: .RS 4 ! .IP "\(bu" 4 All \f(CW\*(C`extern\*(C'\fR declarations take effect globally even if they are written inside of a function definition. This includes implicit declarations of functions. ! .IP "\(bu" 4 The newer keywords \f(CW\*(C`typeof\*(C'\fR, \f(CW\*(C`inline\*(C'\fR, \f(CW\*(C`signed\*(C'\fR, \f(CW\*(C`const\*(C'\fR and \f(CW\*(C`volatile\*(C'\fR are not recognized. (You can still use the alternative keywords such as \f(CW\*(C`_\|_typeof_\|_\*(C'\fR, \f(CW\*(C`_\|_inline_\|_\*(C'\fR, and so on.) ! .IP "\(bu" 4 Comparisons between pointers and integers are always allowed. ! .IP "\(bu" 4 Integer types \f(CW\*(C`unsigned short\*(C'\fR and \f(CW\*(C`unsigned char\*(C'\fR promote to \f(CW\*(C`unsigned int\*(C'\fR. ! .IP "\(bu" 4 Out-of-range floating point literals are not an error. ! .IP "\(bu" 4 Certain constructs which \s-1ISO\s0 regards as a single invalid preprocessing number, such as \fB0xe-0xd\fR, are treated as expressions instead. ! .IP "\(bu" 4 String ``constants'' are not necessarily constant; they are stored in writable space, and identical looking constants are allocated separately. (This is the same as the effect of \&\fB\-fwritable-strings\fR.) ! .IP "\(bu" 4 All automatic variables not declared \f(CW\*(C`register\*(C'\fR are preserved by \&\f(CW\*(C`longjmp\*(C'\fR. Ordinarily, \s-1GNU\s0 C follows \s-1ISO\s0 C: automatic variables not declared \f(CW\*(C`volatile\*(C'\fR may be clobbered. ! .IP "\(bu" 4 The character escape sequences \fB\ex\fR and \fB\ea\fR evaluate as the literal characters \fBx\fR and \fBa\fR respectively. Without \&\fB\-traditional\fR, \fB\ex\fR is a prefix for the hexadecimal *************** systems to compile files that include an *** 1022,1044 **** The \fB\-traditional\fR option also enables \fB\-traditional-cpp\fR, which is described next. .RE ! .Ip "\fB\-traditional-cpp\fR" 4 .IX Item "-traditional-cpp" Attempt to support some aspects of traditional C preprocessors. Specifically: .RS 4 ! .Ip "\(bu" 4 Comments convert to nothing at all, rather than to a space. This allows traditional token concatenation. ! .Ip "\(bu" 4 In a preprocessing directive, the \fB#\fR symbol must appear as the first character of a line. ! .Ip "\(bu" 4 Macro arguments are recognized within string constants in a macro definition (and their values are stringified, though without additional quote marks, when they appear in such a context). The preprocessor always considers a string constant to end at a newline. ! .Ip "\(bu" 4 The predefined macro \f(CW\*(C`_\|_STDC_\|_\*(C'\fR is not defined when you use \&\fB\-traditional\fR, but \f(CW\*(C`_\|_GNUC_\|_\*(C'\fR is (since the \s-1GNU\s0 extensions which \f(CW\*(C`_\|_GNUC_\|_\*(C'\fR indicates are not affected by --- 1021,1043 ---- The \fB\-traditional\fR option also enables \fB\-traditional-cpp\fR, which is described next. .RE ! .IP "\fB\-traditional-cpp\fR" 4 .IX Item "-traditional-cpp" Attempt to support some aspects of traditional C preprocessors. Specifically: .RS 4 ! .IP "\(bu" 4 Comments convert to nothing at all, rather than to a space. This allows traditional token concatenation. ! .IP "\(bu" 4 In a preprocessing directive, the \fB#\fR symbol must appear as the first character of a line. ! .IP "\(bu" 4 Macro arguments are recognized within string constants in a macro definition (and their values are stringified, though without additional quote marks, when they appear in such a context). The preprocessor always considers a string constant to end at a newline. ! .IP "\(bu" 4 The predefined macro \f(CW\*(C`_\|_STDC_\|_\*(C'\fR is not defined when you use \&\fB\-traditional\fR, but \f(CW\*(C`_\|_GNUC_\|_\*(C'\fR is (since the \s-1GNU\s0 extensions which \f(CW\*(C`_\|_GNUC_\|_\*(C'\fR indicates are not affected by *************** testing both of these predefined macros *** 1048,1066 **** situations: \s-1GNU\s0 C, traditional \s-1GNU\s0 C, other \s-1ISO\s0 C compilers, and other old C compilers. The predefined macro \f(CW\*(C`_\|_STDC_VERSION_\|_\*(C'\fR is also not defined when you use \fB\-traditional\fR. ! .Ip "\(bu" 4 The preprocessor considers a string constant to end at a newline (unless the newline is escaped with \fB\e\fR). (Without \fB\-traditional\fR, string constants can contain the newline character as typed.) .RE .RS 4 .RE ! .Ip "\fB\-fcond-mismatch\fR" 4 .IX Item "-fcond-mismatch" Allow conditional expressions with mismatched types in the second and third arguments. The value of such an expression is void. This option is not supported for \*(C+. ! .Ip "\fB\-funsigned-char\fR" 4 .IX Item "-funsigned-char" Let the type \f(CW\*(C`char\*(C'\fR be unsigned, like \f(CW\*(C`unsigned char\*(C'\fR. .Sp --- 1047,1065 ---- situations: \s-1GNU\s0 C, traditional \s-1GNU\s0 C, other \s-1ISO\s0 C compilers, and other old C compilers. The predefined macro \f(CW\*(C`_\|_STDC_VERSION_\|_\*(C'\fR is also not defined when you use \fB\-traditional\fR. ! .IP "\(bu" 4 The preprocessor considers a string constant to end at a newline (unless the newline is escaped with \fB\e\fR). (Without \fB\-traditional\fR, string constants can contain the newline character as typed.) .RE .RS 4 .RE ! .IP "\fB\-fcond-mismatch\fR" 4 .IX Item "-fcond-mismatch" Allow conditional expressions with mismatched types in the second and third arguments. The value of such an expression is void. This option is not supported for \*(C+. ! .IP "\fB\-funsigned-char\fR" 4 .IX Item "-funsigned-char" Let the type \f(CW\*(C`char\*(C'\fR be unsigned, like \f(CW\*(C`unsigned char\*(C'\fR. .Sp *************** make such a program work with the opposi *** 1078,1098 **** The type \f(CW\*(C`char\*(C'\fR is always a distinct type from each of \&\f(CW\*(C`signed char\*(C'\fR or \f(CW\*(C`unsigned char\*(C'\fR, even though its behavior is always just like one of those two. ! .Ip "\fB\-fsigned-char\fR" 4 .IX Item "-fsigned-char" Let the type \f(CW\*(C`char\*(C'\fR be signed, like \f(CW\*(C`signed char\*(C'\fR. .Sp Note that this is equivalent to \fB\-fno-unsigned-char\fR, which is the negative form of \fB\-funsigned-char\fR. Likewise, the option \&\fB\-fno-signed-char\fR is equivalent to \fB\-funsigned-char\fR. ! .Ip "\fB\-fsigned-bitfields\fR" 4 .IX Item "-fsigned-bitfields" .PD 0 ! .Ip "\fB\-funsigned-bitfields\fR" 4 .IX Item "-funsigned-bitfields" ! .Ip "\fB\-fno-signed-bitfields\fR" 4 .IX Item "-fno-signed-bitfields" ! .Ip "\fB\-fno-unsigned-bitfields\fR" 4 .IX Item "-fno-unsigned-bitfields" .PD These options control whether a bit-field is signed or unsigned, when the --- 1077,1097 ---- The type \f(CW\*(C`char\*(C'\fR is always a distinct type from each of \&\f(CW\*(C`signed char\*(C'\fR or \f(CW\*(C`unsigned char\*(C'\fR, even though its behavior is always just like one of those two. ! .IP "\fB\-fsigned-char\fR" 4 .IX Item "-fsigned-char" Let the type \f(CW\*(C`char\*(C'\fR be signed, like \f(CW\*(C`signed char\*(C'\fR. .Sp Note that this is equivalent to \fB\-fno-unsigned-char\fR, which is the negative form of \fB\-funsigned-char\fR. Likewise, the option \&\fB\-fno-signed-char\fR is equivalent to \fB\-funsigned-char\fR. ! .IP "\fB\-fsigned-bitfields\fR" 4 .IX Item "-fsigned-bitfields" .PD 0 ! .IP "\fB\-funsigned-bitfields\fR" 4 .IX Item "-funsigned-bitfields" ! .IP "\fB\-fno-signed-bitfields\fR" 4 .IX Item "-fno-signed-bitfields" ! .IP "\fB\-fno-unsigned-bitfields\fR" 4 .IX Item "-fno-unsigned-bitfields" .PD These options control whether a bit-field is signed or unsigned, when the *************** basic integer types such as \f(CW\*(C`in *** 1102,1108 **** .Sp However, when \fB\-traditional\fR is used, bit-fields are all unsigned no matter what. ! .Ip "\fB\-fwritable-strings\fR" 4 .IX Item "-fwritable-strings" Store string constants in the writable data segment and don't uniquize them. This is for compatibility with old programs which assume they can --- 1101,1107 ---- .Sp However, when \fB\-traditional\fR is used, bit-fields are all unsigned no matter what. ! .IP "\fB\-fwritable-strings\fR" 4 .IX Item "-fwritable-strings" Store string constants in the writable data segment and don't uniquize them. This is for compatibility with old programs which assume they can *************** this effect. *** 1111,1117 **** .Sp Writing into string constants is a very bad idea; ``constants'' should be constant. ! .Ip "\fB\-fallow-single-precision\fR" 4 .IX Item "-fallow-single-precision" Do not promote single precision math operations to double precision, even when compiling with \fB\-traditional\fR. --- 1110,1116 ---- .Sp Writing into string constants is a very bad idea; ``constants'' should be constant. ! .IP "\fB\-fallow-single-precision\fR" 4 .IX Item "-fallow-single-precision" Do not promote single precision math operations to double precision, even when compiling with \fB\-traditional\fR. *************** than double precision. If you must use *** 1123,1129 **** to use single precision operations when the operands are single precision, use this option. This option has no effect when compiling with \s-1ISO\s0 or \s-1GNU\s0 C conventions (the default). ! .Ip "\fB\-fshort-wchar\fR" 4 .IX Item "-fshort-wchar" Override the underlying type for \fBwchar_t\fR to be \fBshort unsigned int\fR instead of the default for the target. This option is --- 1122,1128 ---- to use single precision operations when the operands are single precision, use this option. This option has no effect when compiling with \s-1ISO\s0 or \s-1GNU\s0 C conventions (the default). ! .IP "\fB\-fshort-wchar\fR" 4 .IX Item "-fshort-wchar" Override the underlying type for \fBwchar_t\fR to be \fBshort unsigned int\fR instead of the default for the target. This option is *************** only for \*(C+ programs; you can use the *** 1143,1153 **** language supported by \s-1GCC\s0. .PP Here is a list of options that are \fIonly\fR for compiling \*(C+ programs: ! .Ip "\fB\-fno-access-control\fR" 4 .IX Item "-fno-access-control" Turn off all access checking. This switch is mainly useful for working around bugs in the access control code. ! .Ip "\fB\-fcheck-new\fR" 4 .IX Item "-fcheck-new" Check that the pointer returned by \f(CW\*(C`operator new\*(C'\fR is non-null before attempting to modify the storage allocated. The current Working --- 1142,1152 ---- language supported by \s-1GCC\s0. .PP Here is a list of options that are \fIonly\fR for compiling \*(C+ programs: ! .IP "\fB\-fno-access-control\fR" 4 .IX Item "-fno-access-control" Turn off all access checking. This switch is mainly useful for working around bugs in the access control code. ! .IP "\fB\-fcheck-new\fR" 4 .IX Item "-fcheck-new" Check that the pointer returned by \f(CW\*(C`operator new\*(C'\fR is non-null before attempting to modify the storage allocated. The current Working *************** An alternative to using this option is t *** 1158,1164 **** \&\f(CW\*(C`operator new\*(C'\fR does not throw any exceptions; if you declare it \&\fB\f(BIthrow()\fB\fR, G++ will check the return value. See also \fBnew (nothrow)\fR. ! .Ip "\fB\-fconserve-space\fR" 4 .IX Item "-fconserve-space" Put uninitialized or runtime-initialized global variables into the common segment, as C does. This saves space in the executable at the --- 1157,1163 ---- \&\f(CW\*(C`operator new\*(C'\fR does not throw any exceptions; if you declare it \&\fB\f(BIthrow()\fB\fR, G++ will check the return value. See also \fBnew (nothrow)\fR. ! .IP "\fB\-fconserve-space\fR" 4 .IX Item "-fconserve-space" Put uninitialized or runtime-initialized global variables into the common segment, as C does. This saves space in the executable at the *************** two definitions were merged. *** 1169,1175 **** .Sp This option is no longer useful on most targets, now that support has been added for putting variables into \s-1BSS\s0 without making them common. ! .Ip "\fB\-fno-const-strings\fR" 4 .IX Item "-fno-const-strings" Give string constants type \f(CW\*(C`char *\*(C'\fR instead of type \f(CW\*(C`const char *\*(C'\fR. By default, G++ uses type \f(CW\*(C`const char *\*(C'\fR as required by --- 1168,1174 ---- .Sp This option is no longer useful on most targets, now that support has been added for putting variables into \s-1BSS\s0 without making them common. ! .IP "\fB\-fno-const-strings\fR" 4 .IX Item "-fno-const-strings" Give string constants type \f(CW\*(C`char *\*(C'\fR instead of type \f(CW\*(C`const char *\*(C'\fR. By default, G++ uses type \f(CW\*(C`const char *\*(C'\fR as required by *************** actually modify the value of a string co *** 1180,1221 **** This option might be removed in a future release of G++. For maximum portability, you should structure your code so that it works with string constants that have type \f(CW\*(C`const char *\*(C'\fR. ! .Ip "\fB\-fdollars-in-identifiers\fR" 4 .IX Item "-fdollars-in-identifiers" Accept \fB$\fR in identifiers. You can also explicitly prohibit use of \&\fB$\fR with the option \fB\-fno-dollars-in-identifiers\fR. (\s-1GNU\s0 C allows \&\fB$\fR by default on most target systems, but there are a few exceptions.) Traditional C allowed the character \fB$\fR to form part of identifiers. However, \s-1ISO\s0 C and \*(C+ forbid \fB$\fR in identifiers. ! .Ip "\fB\-fno-elide-constructors\fR" 4 .IX Item "-fno-elide-constructors" The \*(C+ standard allows an implementation to omit creating a temporary which is only used to initialize another object of the same type. Specifying this option disables that optimization, and forces G++ to call the copy constructor in all cases. ! .Ip "\fB\-fno-enforce-eh-specs\fR" 4 .IX Item "-fno-enforce-eh-specs" Don't check for violation of exception specifications at runtime. This option violates the \*(C+ standard, but may be useful for reducing code size in production builds, much like defining \fB\s-1NDEBUG\s0\fR. The compiler will still optimize based on the exception specifications. ! .Ip "\fB\-fexternal-templates\fR" 4 .IX Item "-fexternal-templates" Cause template instantiations to obey \fB#pragma interface\fR and \&\fBimplementation\fR; template instances are emitted or not according to the location of the template definition. .Sp This option is deprecated. ! .Ip "\fB\-falt-external-templates\fR" 4 .IX Item "-falt-external-templates" Similar to \fB\-fexternal-templates\fR, but template instances are emitted or not according to the place where they are first instantiated. .Sp This option is deprecated. ! .Ip "\fB\-ffor-scope\fR" 4 .IX Item "-ffor-scope" .PD 0 ! .Ip "\fB\-fno-for-scope\fR" 4 .IX Item "-fno-for-scope" .PD If \fB\-ffor-scope\fR is specified, the scope of variables declared in --- 1179,1220 ---- This option might be removed in a future release of G++. For maximum portability, you should structure your code so that it works with string constants that have type \f(CW\*(C`const char *\*(C'\fR. ! .IP "\fB\-fdollars-in-identifiers\fR" 4 .IX Item "-fdollars-in-identifiers" Accept \fB$\fR in identifiers. You can also explicitly prohibit use of \&\fB$\fR with the option \fB\-fno-dollars-in-identifiers\fR. (\s-1GNU\s0 C allows \&\fB$\fR by default on most target systems, but there are a few exceptions.) Traditional C allowed the character \fB$\fR to form part of identifiers. However, \s-1ISO\s0 C and \*(C+ forbid \fB$\fR in identifiers. ! .IP "\fB\-fno-elide-constructors\fR" 4 .IX Item "-fno-elide-constructors" The \*(C+ standard allows an implementation to omit creating a temporary which is only used to initialize another object of the same type. Specifying this option disables that optimization, and forces G++ to call the copy constructor in all cases. ! .IP "\fB\-fno-enforce-eh-specs\fR" 4 .IX Item "-fno-enforce-eh-specs" Don't check for violation of exception specifications at runtime. This option violates the \*(C+ standard, but may be useful for reducing code size in production builds, much like defining \fB\s-1NDEBUG\s0\fR. The compiler will still optimize based on the exception specifications. ! .IP "\fB\-fexternal-templates\fR" 4 .IX Item "-fexternal-templates" Cause template instantiations to obey \fB#pragma interface\fR and \&\fBimplementation\fR; template instances are emitted or not according to the location of the template definition. .Sp This option is deprecated. ! .IP "\fB\-falt-external-templates\fR" 4 .IX Item "-falt-external-templates" Similar to \fB\-fexternal-templates\fR, but template instances are emitted or not according to the place where they are first instantiated. .Sp This option is deprecated. ! .IP "\fB\-ffor-scope\fR" 4 .IX Item "-ffor-scope" .PD 0 ! .IP "\fB\-fno-for-scope\fR" 4 .IX Item "-fno-for-scope" .PD If \fB\-ffor-scope\fR is specified, the scope of variables declared in *************** implementations of \*(C+. *** 1229,1295 **** The default if neither flag is given to follow the standard, but to allow and give a warning for old-style code that would otherwise be invalid, or have different behavior. ! .Ip "\fB\-fno-gnu-keywords\fR" 4 .IX Item "-fno-gnu-keywords" Do not recognize \f(CW\*(C`typeof\*(C'\fR as a keyword, so that code can use this word as an identifier. You can use the keyword \f(CW\*(C`_\|_typeof_\|_\*(C'\fR instead. \&\fB\-ansi\fR implies \fB\-fno-gnu-keywords\fR. ! .Ip "\fB\-fno-honor-std\fR" 4 ! .IX Item "-fno-honor-std" ! Ignore \f(CW\*(C`namespace std\*(C'\fR, instead of treating it as a real namespace. ! With this switch, the compiler will ignore ! \&\f(CW\*(C`namespace\-declarations\*(C'\fR, \f(CW\*(C`using\-declarations\*(C'\fR, ! \&\f(CW\*(C`using\-directives\*(C'\fR, and \f(CW\*(C`namespace\-names\*(C'\fR, if they involve ! \&\f(CW\*(C`std\*(C'\fR. ! .Sp ! This option is only useful if you have manually compiled the \*(C+ ! run-time library with the same switch. Otherwise, your programs will ! not link. The use of this option is not recommended, and the option may ! be removed from a future version of G++. ! .Ip "\fB\-fno-implicit-templates\fR" 4 .IX Item "-fno-implicit-templates" Never emit code for non-inline templates which are instantiated implicitly (i.e. by use); only emit code for explicit instantiations. ! .Ip "\fB\-fno-implicit-inline-templates\fR" 4 .IX Item "-fno-implicit-inline-templates" Don't emit code for implicit instantiations of inline templates, either. The default is to handle inlines differently so that compiles with and without optimization will need the same set of explicit instantiations. ! .Ip "\fB\-fno-implement-inlines\fR" 4 .IX Item "-fno-implement-inlines" To save space, do not emit out-of-line copies of inline functions controlled by \fB#pragma implementation\fR. This will cause linker errors if these functions are not inlined everywhere they are called. ! .Ip "\fB\-fms-extensions\fR" 4 .IX Item "-fms-extensions" Disable pedantic warnings about constructs used in \s-1MFC\s0, such as implicit int and getting a pointer to member function via non-standard syntax. ! .Ip "\fB\-fno-nonansi-builtins\fR" 4 .IX Item "-fno-nonansi-builtins" Disable built-in declarations of functions that are not mandated by \&\s-1ANSI/ISO\s0 C. These include \f(CW\*(C`ffs\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`_exit\*(C'\fR, \&\f(CW\*(C`index\*(C'\fR, \f(CW\*(C`bzero\*(C'\fR, \f(CW\*(C`conjf\*(C'\fR, and other related functions. ! .Ip "\fB\-fno-operator-names\fR" 4 .IX Item "-fno-operator-names" Do not treat the operator name keywords \f(CW\*(C`and\*(C'\fR, \f(CW\*(C`bitand\*(C'\fR, \&\f(CW\*(C`bitor\*(C'\fR, \f(CW\*(C`compl\*(C'\fR, \f(CW\*(C`not\*(C'\fR, \f(CW\*(C`or\*(C'\fR and \f(CW\*(C`xor\*(C'\fR as synonyms as keywords. ! .Ip "\fB\-fno-optional-diags\fR" 4 .IX Item "-fno-optional-diags" Disable diagnostics that the standard says a compiler does not need to issue. Currently, the only such diagnostic issued by G++ is the one for a name having multiple meanings within a class. ! .Ip "\fB\-fpermissive\fR" 4 .IX Item "-fpermissive" Downgrade messages about nonconformant code from errors to warnings. By default, G++ effectively sets \fB\-pedantic-errors\fR without \&\fB\-pedantic\fR; this option reverses that. This behavior and this option are superseded by \fB\-pedantic\fR, which works as it does for \s-1GNU\s0 C. ! .Ip "\fB\-frepo\fR" 4 .IX Item "-frepo" Enable automatic template instantiation. This option also implies \&\fB\-fno-implicit-templates\fR. ! .Ip "\fB\-fno-rtti\fR" 4 .IX Item "-fno-rtti" Disable generation of information about every class with virtual functions for use by the \*(C+ runtime type identification features --- 1228,1282 ---- The default if neither flag is given to follow the standard, but to allow and give a warning for old-style code that would otherwise be invalid, or have different behavior. ! .IP "\fB\-fno-gnu-keywords\fR" 4 .IX Item "-fno-gnu-keywords" Do not recognize \f(CW\*(C`typeof\*(C'\fR as a keyword, so that code can use this word as an identifier. You can use the keyword \f(CW\*(C`_\|_typeof_\|_\*(C'\fR instead. \&\fB\-ansi\fR implies \fB\-fno-gnu-keywords\fR. ! .IP "\fB\-fno-implicit-templates\fR" 4 .IX Item "-fno-implicit-templates" Never emit code for non-inline templates which are instantiated implicitly (i.e. by use); only emit code for explicit instantiations. ! .IP "\fB\-fno-implicit-inline-templates\fR" 4 .IX Item "-fno-implicit-inline-templates" Don't emit code for implicit instantiations of inline templates, either. The default is to handle inlines differently so that compiles with and without optimization will need the same set of explicit instantiations. ! .IP "\fB\-fno-implement-inlines\fR" 4 .IX Item "-fno-implement-inlines" To save space, do not emit out-of-line copies of inline functions controlled by \fB#pragma implementation\fR. This will cause linker errors if these functions are not inlined everywhere they are called. ! .IP "\fB\-fms-extensions\fR" 4 .IX Item "-fms-extensions" Disable pedantic warnings about constructs used in \s-1MFC\s0, such as implicit int and getting a pointer to member function via non-standard syntax. ! .IP "\fB\-fno-nonansi-builtins\fR" 4 .IX Item "-fno-nonansi-builtins" Disable built-in declarations of functions that are not mandated by \&\s-1ANSI/ISO\s0 C. These include \f(CW\*(C`ffs\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`_exit\*(C'\fR, \&\f(CW\*(C`index\*(C'\fR, \f(CW\*(C`bzero\*(C'\fR, \f(CW\*(C`conjf\*(C'\fR, and other related functions. ! .IP "\fB\-fno-operator-names\fR" 4 .IX Item "-fno-operator-names" Do not treat the operator name keywords \f(CW\*(C`and\*(C'\fR, \f(CW\*(C`bitand\*(C'\fR, \&\f(CW\*(C`bitor\*(C'\fR, \f(CW\*(C`compl\*(C'\fR, \f(CW\*(C`not\*(C'\fR, \f(CW\*(C`or\*(C'\fR and \f(CW\*(C`xor\*(C'\fR as synonyms as keywords. ! .IP "\fB\-fno-optional-diags\fR" 4 .IX Item "-fno-optional-diags" Disable diagnostics that the standard says a compiler does not need to issue. Currently, the only such diagnostic issued by G++ is the one for a name having multiple meanings within a class. ! .IP "\fB\-fpermissive\fR" 4 .IX Item "-fpermissive" Downgrade messages about nonconformant code from errors to warnings. By default, G++ effectively sets \fB\-pedantic-errors\fR without \&\fB\-pedantic\fR; this option reverses that. This behavior and this option are superseded by \fB\-pedantic\fR, which works as it does for \s-1GNU\s0 C. ! .IP "\fB\-frepo\fR" 4 .IX Item "-frepo" Enable automatic template instantiation. This option also implies \&\fB\-fno-implicit-templates\fR. ! .IP "\fB\-fno-rtti\fR" 4 .IX Item "-fno-rtti" Disable generation of information about every class with virtual functions for use by the \*(C+ runtime type identification features *************** functions for use by the \*(C+ runtime t *** 1297,1327 **** of the language, you can save some space by using this flag. Note that exception handling uses the same information, but it will generate it as needed. ! .Ip "\fB\-fstats\fR" 4 .IX Item "-fstats" Emit statistics about front-end processing at the end of the compilation. This information is generally only useful to the G++ development team. ! .Ip "\fB\-ftemplate-depth-\fR\fIn\fR" 4 .IX Item "-ftemplate-depth-n" Set the maximum instantiation depth for template classes to \fIn\fR. A limit on the template instantiation depth is needed to detect endless recursions during template class instantiation. \s-1ANSI/ISO\s0 \*(C+ conforming programs must not rely on a maximum depth greater than 17. ! .Ip "\fB\-fuse-cxa-atexit\fR" 4 .IX Item "-fuse-cxa-atexit" Register destructors for objects with static storage duration with the \&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR function rather than the \f(CW\*(C`atexit\*(C'\fR function. This option is required for fully standards-compliant handling of static destructors, but will only work if your C library supports \&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR. ! .Ip "\fB\-fno-weak\fR" 4 .IX Item "-fno-weak" Do not use weak symbol support, even if it is provided by the linker. By default, G++ will use weak symbols if they are available. This option exists only for testing, and should not be used by end-users; it will result in inferior code and has no benefits. This option may be removed in a future release of G++. ! .Ip "\fB\-nostdinc++\fR" 4 .IX Item "-nostdinc++" Do not search for header files in the standard directories specific to \&\*(C+, but do still search the other standard directories. (This option --- 1284,1314 ---- of the language, you can save some space by using this flag. Note that exception handling uses the same information, but it will generate it as needed. ! .IP "\fB\-fstats\fR" 4 .IX Item "-fstats" Emit statistics about front-end processing at the end of the compilation. This information is generally only useful to the G++ development team. ! .IP "\fB\-ftemplate-depth-\fR\fIn\fR" 4 .IX Item "-ftemplate-depth-n" Set the maximum instantiation depth for template classes to \fIn\fR. A limit on the template instantiation depth is needed to detect endless recursions during template class instantiation. \s-1ANSI/ISO\s0 \*(C+ conforming programs must not rely on a maximum depth greater than 17. ! .IP "\fB\-fuse-cxa-atexit\fR" 4 .IX Item "-fuse-cxa-atexit" Register destructors for objects with static storage duration with the \&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR function rather than the \f(CW\*(C`atexit\*(C'\fR function. This option is required for fully standards-compliant handling of static destructors, but will only work if your C library supports \&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR. ! .IP "\fB\-fno-weak\fR" 4 .IX Item "-fno-weak" Do not use weak symbol support, even if it is provided by the linker. By default, G++ will use weak symbols if they are available. This option exists only for testing, and should not be used by end-users; it will result in inferior code and has no benefits. This option may be removed in a future release of G++. ! .IP "\fB\-nostdinc++\fR" 4 .IX Item "-nostdinc++" Do not search for header files in the standard directories specific to \&\*(C+, but do still search the other standard directories. (This option *************** is used when building the \*(C+ library. *** 1329,1350 **** .PP In addition, these optimization, warning, and code generation options have meanings only for \*(C+ programs: ! .Ip "\fB\-fno-default-inline\fR" 4 .IX Item "-fno-default-inline" Do not assume \fBinline\fR for functions defined inside a class scope. Note that these functions will have linkage like inline functions; they just won't be inlined by default. ! .Ip "\fB\-Wctor-dtor-privacy\fR (\*(C+ only)" 4 .IX Item "-Wctor-dtor-privacy ( only)" Warn when a class seems unusable, because all the constructors or destructors in a class are private and the class has no friends or public static member functions. ! .Ip "\fB\-Wnon-virtual-dtor\fR (\*(C+ only)" 4 .IX Item "-Wnon-virtual-dtor ( only)" Warn when a class declares a non-virtual destructor that should probably be virtual, because it looks like the class will be used polymorphically. ! .Ip "\fB\-Wreorder\fR (\*(C+ only)" 4 .IX Item "-Wreorder ( only)" Warn when the order of member initializers given in the code does not match the order in which they must be executed. For instance: --- 1316,1337 ---- .PP In addition, these optimization, warning, and code generation options have meanings only for \*(C+ programs: ! .IP "\fB\-fno-default-inline\fR" 4 .IX Item "-fno-default-inline" Do not assume \fBinline\fR for functions defined inside a class scope. Note that these functions will have linkage like inline functions; they just won't be inlined by default. ! .IP "\fB\-Wctor-dtor-privacy\fR (\*(C+ only)" 4 .IX Item "-Wctor-dtor-privacy ( only)" Warn when a class seems unusable, because all the constructors or destructors in a class are private and the class has no friends or public static member functions. ! .IP "\fB\-Wnon-virtual-dtor\fR (\*(C+ only)" 4 .IX Item "-Wnon-virtual-dtor ( only)" Warn when a class declares a non-virtual destructor that should probably be virtual, because it looks like the class will be used polymorphically. ! .IP "\fB\-Wreorder\fR (\*(C+ only)" 4 .IX Item "-Wreorder ( only)" Warn when the order of member initializers given in the code does not match the order in which they must be executed. For instance: *************** and \fBj\fR will be rearranged to match *** 1361,1376 **** members. .PP The following \fB\-W...\fR options are not affected by \fB\-Wall\fR. ! .Ip "\fB\-Weffc++\fR (\*(C+ only)" 4 .IX Item "-Weffc++ ( only)" Warn about violations of various style guidelines from Scott Meyers' \&\fIEffective \*(C+\fR books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use \fBgrep \-v\fR to filter out those warnings. ! .Ip "\fB\-Wno-deprecated\fR (\*(C+ only)" 4 .IX Item "-Wno-deprecated ( only)" Do not warn about usage of deprecated features. ! .Ip "\fB\-Wno-non-template-friend\fR (\*(C+ only)" 4 .IX Item "-Wno-non-template-friend ( only)" Disable warnings when non-templatized friend functions are declared within a template. With the advent of explicit template specification --- 1348,1363 ---- members. .PP The following \fB\-W...\fR options are not affected by \fB\-Wall\fR. ! .IP "\fB\-Weffc++\fR (\*(C+ only)" 4 .IX Item "-Weffc++ ( only)" Warn about violations of various style guidelines from Scott Meyers' \&\fIEffective \*(C+\fR books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use \fBgrep \-v\fR to filter out those warnings. ! .IP "\fB\-Wno-deprecated\fR (\*(C+ only)" 4 .IX Item "-Wno-deprecated ( only)" Do not warn about usage of deprecated features. ! .IP "\fB\-Wno-non-template-friend\fR (\*(C+ only)" 4 .IX Item "-Wno-non-template-friend ( only)" Disable warnings when non-templatized friend functions are declared within a template. With the advent of explicit template specification *************** check existing code for potential troubl *** 1385,1397 **** This new compiler behavior can be turned off with \&\fB\-Wno-non-template-friend\fR which keeps the conformant compiler code but disables the helpful warning. ! .Ip "\fB\-Wold-style-cast\fR (\*(C+ only)" 4 .IX Item "-Wold-style-cast ( only)" Warn if an old-style (C-style) cast is used within a \*(C+ program. The new-style casts (\fBstatic_cast\fR, \fBreinterpret_cast\fR, and \&\fBconst_cast\fR) are less vulnerable to unintended effects, and much easier to grep for. ! .Ip "\fB\-Woverloaded-virtual\fR (\*(C+ only)" 4 .IX Item "-Woverloaded-virtual ( only)" Warn when a derived class function declaration may be an error in defining a virtual function. In a derived class, the --- 1372,1384 ---- This new compiler behavior can be turned off with \&\fB\-Wno-non-template-friend\fR which keeps the conformant compiler code but disables the helpful warning. ! .IP "\fB\-Wold-style-cast\fR (\*(C+ only)" 4 .IX Item "-Wold-style-cast ( only)" Warn if an old-style (C-style) cast is used within a \*(C+ program. The new-style casts (\fBstatic_cast\fR, \fBreinterpret_cast\fR, and \&\fBconst_cast\fR) are less vulnerable to unintended effects, and much easier to grep for. ! .IP "\fB\-Woverloaded-virtual\fR (\*(C+ only)" 4 .IX Item "-Woverloaded-virtual ( only)" Warn when a derived class function declaration may be an error in defining a virtual function. In a derived class, the *************** virtual function declared in the base cl *** 1400,1416 **** compiler warns when you define a function with the same name as a virtual function, but with a type signature that does not match any declarations from the base class. ! .Ip "\fB\-Wno-pmf-conversions\fR (\*(C+ only)" 4 .IX Item "-Wno-pmf-conversions ( only)" Disable the diagnostic for converting a bound pointer to member function to a plain pointer. ! .Ip "\fB\-Wsign-promo\fR (\*(C+ only)" 4 .IX Item "-Wsign-promo ( only)" Warn when overload resolution chooses a promotion from unsigned or enumeral type to a signed type over a conversion to an unsigned type of the same size. Previous versions of G++ would try to preserve unsignedness, but the standard mandates the current behavior. ! .Ip "\fB\-Wsynth\fR (\*(C+ only)" 4 .IX Item "-Wsynth ( only)" Warn when G++'s synthesis behavior does not match that of cfront. For instance: --- 1387,1403 ---- compiler warns when you define a function with the same name as a virtual function, but with a type signature that does not match any declarations from the base class. ! .IP "\fB\-Wno-pmf-conversions\fR (\*(C+ only)" 4 .IX Item "-Wno-pmf-conversions ( only)" Disable the diagnostic for converting a bound pointer to member function to a plain pointer. ! .IP "\fB\-Wsign-promo\fR (\*(C+ only)" 4 .IX Item "-Wsign-promo ( only)" Warn when overload resolution chooses a promotion from unsigned or enumeral type to a signed type over a conversion to an unsigned type of the same size. Previous versions of G++ would try to preserve unsignedness, but the standard mandates the current behavior. ! .IP "\fB\-Wsynth\fR (\*(C+ only)" 4 .IX Item "-Wsynth ( only)" Warn when G++'s synthesis behavior does not match that of cfront. For instance: *************** supported by \s-1GCC\s0. *** 1446,1473 **** .PP Here is a list of options that are \fIonly\fR for compiling Objective-C programs: ! .Ip "\fB\-fconstant-string-class=\fR\fIclass-name\fR" 4 .IX Item "-fconstant-string-class=class-name" Use \fIclass-name\fR as the name of the class to instantiate for each literal string specified with the syntax \f(CW\*(C`@"..."\*(C'\fR. The default class name is \f(CW\*(C`NXConstantString\*(C'\fR. ! .Ip "\fB\-fgnu-runtime\fR" 4 .IX Item "-fgnu-runtime" Generate object code compatible with the standard \s-1GNU\s0 Objective-C runtime. This is the default for most types of systems. ! .Ip "\fB\-fnext-runtime\fR" 4 .IX Item "-fnext-runtime" Generate output compatible with the NeXT runtime. This is the default for NeXT-based systems, including Darwin and Mac \s-1OS\s0 X. ! .Ip "\fB\-gen-decls\fR" 4 .IX Item "-gen-decls" Dump interface declarations for all classes seen in the source file to a file named \fI\fIsourcename\fI.decl\fR. ! .Ip "\fB\-Wno-protocol\fR" 4 .IX Item "-Wno-protocol" Do not warn if methods required by a protocol are not implemented in the class adopting it. ! .Ip "\fB\-Wselector\fR" 4 .IX Item "-Wselector" Warn if a selector has multiple methods of different types defined. .Sh "Options to Control Diagnostic Messages Formatting" --- 1433,1460 ---- .PP Here is a list of options that are \fIonly\fR for compiling Objective-C programs: ! .IP "\fB\-fconstant-string-class=\fR\fIclass-name\fR" 4 .IX Item "-fconstant-string-class=class-name" Use \fIclass-name\fR as the name of the class to instantiate for each literal string specified with the syntax \f(CW\*(C`@"..."\*(C'\fR. The default class name is \f(CW\*(C`NXConstantString\*(C'\fR. ! .IP "\fB\-fgnu-runtime\fR" 4 .IX Item "-fgnu-runtime" Generate object code compatible with the standard \s-1GNU\s0 Objective-C runtime. This is the default for most types of systems. ! .IP "\fB\-fnext-runtime\fR" 4 .IX Item "-fnext-runtime" Generate output compatible with the NeXT runtime. This is the default for NeXT-based systems, including Darwin and Mac \s-1OS\s0 X. ! .IP "\fB\-gen-decls\fR" 4 .IX Item "-gen-decls" Dump interface declarations for all classes seen in the source file to a file named \fI\fIsourcename\fI.decl\fR. ! .IP "\fB\-Wno-protocol\fR" 4 .IX Item "-Wno-protocol" Do not warn if methods required by a protocol are not implemented in the class adopting it. ! .IP "\fB\-Wselector\fR" 4 .IX Item "-Wselector" Warn if a selector has multiple methods of different types defined. .Sh "Options to Control Diagnostic Messages Formatting" *************** algorithm, e.g. how many characters per *** 1479,1492 **** information should be reported. Right now, only the \*(C+ front end can honor these options. However it is expected, in the near future, that the remaining front ends would be able to digest them correctly. ! .Ip "\fB\-fmessage-length=\fR\fIn\fR" 4 .IX Item "-fmessage-length=n" Try to format error messages so that they fit on lines of about \fIn\fR characters. The default is 72 characters for \fBg++\fR and 0 for the rest of the front ends supported by \s-1GCC\s0. If \fIn\fR is zero, then no line-wrapping will be done; each error message will appear on a single line. ! .Ip "\fB\-fdiagnostics-show-location=once\fR" 4 .IX Item "-fdiagnostics-show-location=once" Only meaningful in line-wrapping mode. Instructs the diagnostic messages reporter to emit \fIonce\fR source location information; that is, in --- 1466,1479 ---- information should be reported. Right now, only the \*(C+ front end can honor these options. However it is expected, in the near future, that the remaining front ends would be able to digest them correctly. ! .IP "\fB\-fmessage-length=\fR\fIn\fR" 4 .IX Item "-fmessage-length=n" Try to format error messages so that they fit on lines of about \fIn\fR characters. The default is 72 characters for \fBg++\fR and 0 for the rest of the front ends supported by \s-1GCC\s0. If \fIn\fR is zero, then no line-wrapping will be done; each error message will appear on a single line. ! .IP "\fB\-fdiagnostics-show-location=once\fR" 4 .IX Item "-fdiagnostics-show-location=once" Only meaningful in line-wrapping mode. Instructs the diagnostic messages reporter to emit \fIonce\fR source location information; that is, in *************** case the message is too long to fit on a *** 1494,1504 **** be wrapped, the source location won't be emitted (as prefix) again, over and over, in subsequent continuation lines. This is the default behaviour. ! .Ip "\fB\-fdiagnostics-show-location=every-line\fR" 4 .IX Item "-fdiagnostics-show-location=every-line" Only meaningful in line-wrapping mode. Instructs the diagnostic messages reporter to emit the same source location information (as ! prefix) for physical lines that result from the process of breaking a a message which is too long to fit on a single line. .Sh "Options to Request or Suppress Warnings" .IX Subsection "Options to Request or Suppress Warnings" --- 1481,1491 ---- be wrapped, the source location won't be emitted (as prefix) again, over and over, in subsequent continuation lines. This is the default behaviour. ! .IP "\fB\-fdiagnostics-show-location=every-line\fR" 4 .IX Item "-fdiagnostics-show-location=every-line" Only meaningful in line-wrapping mode. Instructs the diagnostic messages reporter to emit the same source location information (as ! prefix) for physical lines that result from the process of breaking a message which is too long to fit on a single line. .Sh "Options to Request or Suppress Warnings" .IX Subsection "Options to Request or Suppress Warnings" *************** for example, \fB\-Wno-implicit\fR. This *** 1514,1523 **** two forms, whichever is not the default. .PP These options control the amount and kinds of warnings produced by \s-1GCC:\s0 ! .Ip "\fB\-fsyntax-only\fR" 4 .IX Item "-fsyntax-only" Check the code for syntax errors, but don't do anything beyond that. ! .Ip "\fB\-pedantic\fR" 4 .IX Item "-pedantic" Issue all the warnings demanded by strict \s-1ISO\s0 C and \s-1ISO\s0 \*(C+; reject all programs that use forbidden extensions, and some other --- 1501,1510 ---- two forms, whichever is not the default. .PP These options control the amount and kinds of warnings produced by \s-1GCC:\s0 ! .IP "\fB\-fsyntax-only\fR" 4 .IX Item "-fsyntax-only" Check the code for syntax errors, but don't do anything beyond that. ! .IP "\fB\-pedantic\fR" 4 .IX Item "-pedantic" Issue all the warnings demanded by strict \s-1ISO\s0 C and \s-1ISO\s0 \*(C+; reject all programs that use forbidden extensions, and some other *************** for such warnings to be given only for f *** 1556,1581 **** C dialect, since by definition the \s-1GNU\s0 dialects of C include all features the compiler supports with the given option, and there would be nothing to warn about.) ! .Ip "\fB\-pedantic-errors\fR" 4 .IX Item "-pedantic-errors" Like \fB\-pedantic\fR, except that errors are produced rather than warnings. ! .Ip "\fB\-w\fR" 4 .IX Item "-w" Inhibit all warning messages. ! .Ip "\fB\-Wno-import\fR" 4 .IX Item "-Wno-import" Inhibit warning messages about the use of \fB#import\fR. ! .Ip "\fB\-Wchar-subscripts\fR" 4 .IX Item "-Wchar-subscripts" Warn if an array subscript has type \f(CW\*(C`char\*(C'\fR. This is a common cause of error, as programmers often forget that this type is signed on some machines. ! .Ip "\fB\-Wcomment\fR" 4 .IX Item "-Wcomment" Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR comment, or whenever a Backslash-Newline appears in a \fB//\fR comment. ! .Ip "\fB\-Wformat\fR" 4 .IX Item "-Wformat" Check calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR, etc., to make sure that the arguments supplied have types appropriate to the format string --- 1543,1568 ---- C dialect, since by definition the \s-1GNU\s0 dialects of C include all features the compiler supports with the given option, and there would be nothing to warn about.) ! .IP "\fB\-pedantic-errors\fR" 4 .IX Item "-pedantic-errors" Like \fB\-pedantic\fR, except that errors are produced rather than warnings. ! .IP "\fB\-w\fR" 4 .IX Item "-w" Inhibit all warning messages. ! .IP "\fB\-Wno-import\fR" 4 .IX Item "-Wno-import" Inhibit warning messages about the use of \fB#import\fR. ! .IP "\fB\-Wchar-subscripts\fR" 4 .IX Item "-Wchar-subscripts" Warn if an array subscript has type \f(CW\*(C`char\*(C'\fR. This is a common cause of error, as programmers often forget that this type is signed on some machines. ! .IP "\fB\-Wcomment\fR" 4 .IX Item "-Wcomment" Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR comment, or whenever a Backslash-Newline appears in a \fB//\fR comment. ! .IP "\fB\-Wformat\fR" 4 .IX Item "-Wformat" Check calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR, etc., to make sure that the arguments supplied have types appropriate to the format string *************** aspects of format checking, the options *** 1600,1620 **** \&\fB\-Wno-format-extra-args\fR, \fB\-Wformat-nonliteral\fR, \&\fB\-Wformat-security\fR and \fB\-Wformat=2\fR are available, but are not included in \fB\-Wall\fR. ! .Ip "\fB\-Wno-format-y2k\fR" 4 .IX Item "-Wno-format-y2k" If \fB\-Wformat\fR is specified, do not warn about \f(CW\*(C`strftime\*(C'\fR formats which may yield only a two-digit year. ! .Ip "\fB\-Wno-format-extra-args\fR" 4 .IX Item "-Wno-format-extra-args" If \fB\-Wformat\fR is specified, do not warn about excess arguments to a \&\f(CW\*(C`printf\*(C'\fR or \f(CW\*(C`scanf\*(C'\fR format function. The C standard specifies that such arguments are ignored. ! .Ip "\fB\-Wformat-nonliteral\fR" 4 .IX Item "-Wformat-nonliteral" If \fB\-Wformat\fR is specified, also warn if the format string is not a string literal and so cannot be checked, unless the format function takes its format arguments as a \f(CW\*(C`va_list\*(C'\fR. ! .Ip "\fB\-Wformat-security\fR" 4 .IX Item "-Wformat-security" If \fB\-Wformat\fR is specified, also warn about uses of format functions that represent possible security problems. At present, this --- 1587,1607 ---- \&\fB\-Wno-format-extra-args\fR, \fB\-Wformat-nonliteral\fR, \&\fB\-Wformat-security\fR and \fB\-Wformat=2\fR are available, but are not included in \fB\-Wall\fR. ! .IP "\fB\-Wno-format-y2k\fR" 4 .IX Item "-Wno-format-y2k" If \fB\-Wformat\fR is specified, do not warn about \f(CW\*(C`strftime\*(C'\fR formats which may yield only a two-digit year. ! .IP "\fB\-Wno-format-extra-args\fR" 4 .IX Item "-Wno-format-extra-args" If \fB\-Wformat\fR is specified, do not warn about excess arguments to a \&\f(CW\*(C`printf\*(C'\fR or \f(CW\*(C`scanf\*(C'\fR format function. The C standard specifies that such arguments are ignored. ! .IP "\fB\-Wformat-nonliteral\fR" 4 .IX Item "-Wformat-nonliteral" If \fB\-Wformat\fR is specified, also warn if the format string is not a string literal and so cannot be checked, unless the format function takes its format arguments as a \f(CW\*(C`va_list\*(C'\fR. ! .IP "\fB\-Wformat-security\fR" 4 .IX Item "-Wformat-security" If \fB\-Wformat\fR is specified, also warn about uses of format functions that represent possible security problems. At present, this *************** string came from untrusted input and con *** 1625,1655 **** currently a subset of what \fB\-Wformat-nonliteral\fR warns about, but in future warnings may be added to \fB\-Wformat-security\fR that are not included in \fB\-Wformat-nonliteral\fR.) ! .Ip "\fB\-Wformat=2\fR" 4 .IX Item "-Wformat=2" Enable \fB\-Wformat\fR plus format checks not included in \&\fB\-Wformat\fR. Currently equivalent to \fB\-Wformat \&\-Wformat-nonliteral \-Wformat-security\fR. ! .Ip "\fB\-Wimplicit-int\fR" 4 .IX Item "-Wimplicit-int" Warn when a declaration does not specify a type. ! .Ip "\fB\-Wimplicit-function-declaration\fR" 4 .IX Item "-Wimplicit-function-declaration" .PD 0 ! .Ip "\fB\-Werror-implicit-function-declaration\fR" 4 .IX Item "-Werror-implicit-function-declaration" .PD Give a warning (or error) whenever a function is used before being declared. ! .Ip "\fB\-Wimplicit\fR" 4 .IX Item "-Wimplicit" Same as \fB\-Wimplicit-int\fR and \fB\-Wimplicit-function-declaration\fR. ! .Ip "\fB\-Wmain\fR" 4 .IX Item "-Wmain" Warn if the type of \fBmain\fR is suspicious. \fBmain\fR should be a function with external linkage, returning int, taking either zero arguments, two, or three arguments of appropriate types. ! .Ip "\fB\-Wmissing-braces\fR" 4 .IX Item "-Wmissing-braces" Warn if an aggregate or union initializer is not fully bracketed. In the following example, the initializer for \fBa\fR is not fully --- 1612,1642 ---- currently a subset of what \fB\-Wformat-nonliteral\fR warns about, but in future warnings may be added to \fB\-Wformat-security\fR that are not included in \fB\-Wformat-nonliteral\fR.) ! .IP "\fB\-Wformat=2\fR" 4 .IX Item "-Wformat=2" Enable \fB\-Wformat\fR plus format checks not included in \&\fB\-Wformat\fR. Currently equivalent to \fB\-Wformat \&\-Wformat-nonliteral \-Wformat-security\fR. ! .IP "\fB\-Wimplicit-int\fR" 4 .IX Item "-Wimplicit-int" Warn when a declaration does not specify a type. ! .IP "\fB\-Wimplicit-function-declaration\fR" 4 .IX Item "-Wimplicit-function-declaration" .PD 0 ! .IP "\fB\-Werror-implicit-function-declaration\fR" 4 .IX Item "-Werror-implicit-function-declaration" .PD Give a warning (or error) whenever a function is used before being declared. ! .IP "\fB\-Wimplicit\fR" 4 .IX Item "-Wimplicit" Same as \fB\-Wimplicit-int\fR and \fB\-Wimplicit-function-declaration\fR. ! .IP "\fB\-Wmain\fR" 4 .IX Item "-Wmain" Warn if the type of \fBmain\fR is suspicious. \fBmain\fR should be a function with external linkage, returning int, taking either zero arguments, two, or three arguments of appropriate types. ! .IP "\fB\-Wmissing-braces\fR" 4 .IX Item "-Wmissing-braces" Warn if an aggregate or union initializer is not fully bracketed. In the following example, the initializer for \fBa\fR is not fully *************** bracketed, but that for \fBb\fR is fully *** 1659,1670 **** \& int a[2][2] = { 0, 1, 2, 3 }; \& int b[2][2] = { { 0, 1 }, { 2, 3 } }; .Ve ! .Ip "\fB\-Wmultichar\fR" 4 .IX Item "-Wmultichar" Warn if a multicharacter constant (\fB'\s-1FOOF\s0'\fR) is used. Usually they indicate a typo in the user's code, as they have implementation-defined values, and should not be used in portable code. ! .Ip "\fB\-Wparentheses\fR" 4 .IX Item "-Wparentheses" Warn if parentheses are omitted in certain contexts, such as when there is an assignment in a context where a truth value --- 1646,1657 ---- \& int a[2][2] = { 0, 1, 2, 3 }; \& int b[2][2] = { { 0, 1 }, { 2, 3 } }; .Ve ! .IP "\fB\-Wmultichar\fR" 4 .IX Item "-Wmultichar" Warn if a multicharacter constant (\fB'\s-1FOOF\s0'\fR) is used. Usually they indicate a typo in the user's code, as they have implementation-defined values, and should not be used in portable code. ! .IP "\fB\-Wparentheses\fR" 4 .IX Item "-Wparentheses" Warn if parentheses are omitted in certain contexts, such as when there is an assignment in a context where a truth value *************** the enclosing \f(CW\*(C`if\*(C'\fR. The *** 1704,1710 **** \& } \& } .Ve ! .Ip "\fB\-Wsequence-point\fR" 4 .IX Item "-Wsequence-point" Warn about code that may have undefined semantics because of violations of sequence point rules in the C standard. --- 1691,1697 ---- \& } \& } .Ve ! .IP "\fB\-Wsequence-point\fR" 4 .IX Item "-Wsequence-point" Warn about code that may have undefined semantics because of violations of sequence point rules in the C standard. *************** There is some controversy over the preci *** 1748,1754 **** rules in subtle cases. Links to papers with alternative formal definitions and other related discussions may be found on our readings page <\fBhttp://gcc.gnu.org/readings.html\fR>. ! .Ip "\fB\-Wreturn-type\fR" 4 .IX Item "-Wreturn-type" Warn whenever a function is defined with a return-type that defaults to \&\f(CW\*(C`int\*(C'\fR. Also warn about any \f(CW\*(C`return\*(C'\fR statement with no --- 1735,1741 ---- rules in subtle cases. Links to papers with alternative formal definitions and other related discussions may be found on our readings page <\fBhttp://gcc.gnu.org/readings.html\fR>. ! .IP "\fB\-Wreturn-type\fR" 4 .IX Item "-Wreturn-type" Warn whenever a function is defined with a return-type that defaults to \&\f(CW\*(C`int\*(C'\fR. Also warn about any \f(CW\*(C`return\*(C'\fR statement with no *************** return-value in a function whose return- *** 1757,1806 **** For \*(C+, a function without return type always produces a diagnostic message, even when \fB\-Wno-return-type\fR is specified. The only exceptions are \fBmain\fR and functions defined in system headers. ! .Ip "\fB\-Wswitch\fR" 4 .IX Item "-Wswitch" Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumeral type and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that enumeration. (The presence of a \f(CW\*(C`default\*(C'\fR label prevents this warning.) \f(CW\*(C`case\*(C'\fR labels outside the enumeration range also provoke warnings when this option is used. ! .Ip "\fB\-Wtrigraphs\fR" 4 .IX Item "-Wtrigraphs" Warn if any trigraphs are encountered that might change the meaning of the program (trigraphs within comments are not warned about). ! .Ip "\fB\-Wunused-function\fR" 4 .IX Item "-Wunused-function" Warn whenever a static function is declared but not defined or a non\e-inline static function is unused. ! .Ip "\fB\-Wunused-label\fR" 4 .IX Item "-Wunused-label" Warn whenever a label is declared but not used. .Sp To suppress this warning use the \fBunused\fR attribute. ! .Ip "\fB\-Wunused-parameter\fR" 4 .IX Item "-Wunused-parameter" Warn whenever a function parameter is unused aside from its declaration. .Sp To suppress this warning use the \fBunused\fR attribute. ! .Ip "\fB\-Wunused-variable\fR" 4 .IX Item "-Wunused-variable" Warn whenever a local variable or non-constant static variable is unused aside from its declaration .Sp To suppress this warning use the \fBunused\fR attribute. ! .Ip "\fB\-Wunused-value\fR" 4 .IX Item "-Wunused-value" Warn whenever a statement computes a result that is explicitly not used. .Sp To suppress this warning cast the expression to \fBvoid\fR. ! .Ip "\fB\-Wunused\fR" 4 .IX Item "-Wunused" All all the above \fB\-Wunused\fR options combined. .Sp In order to get a warning about an unused function parameter, you must either specify \fB\-W \-Wunused\fR or separately specify \&\fB\-Wunused-parameter\fR. ! .Ip "\fB\-Wuninitialized\fR" 4 .IX Item "-Wuninitialized" Warn if an automatic variable is used without first being initialized or if a variable may be clobbered by a \f(CW\*(C`setjmp\*(C'\fR call. --- 1744,1793 ---- For \*(C+, a function without return type always produces a diagnostic message, even when \fB\-Wno-return-type\fR is specified. The only exceptions are \fBmain\fR and functions defined in system headers. ! .IP "\fB\-Wswitch\fR" 4 .IX Item "-Wswitch" Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumeral type and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that enumeration. (The presence of a \f(CW\*(C`default\*(C'\fR label prevents this warning.) \f(CW\*(C`case\*(C'\fR labels outside the enumeration range also provoke warnings when this option is used. ! .IP "\fB\-Wtrigraphs\fR" 4 .IX Item "-Wtrigraphs" Warn if any trigraphs are encountered that might change the meaning of the program (trigraphs within comments are not warned about). ! .IP "\fB\-Wunused-function\fR" 4 .IX Item "-Wunused-function" Warn whenever a static function is declared but not defined or a non\e-inline static function is unused. ! .IP "\fB\-Wunused-label\fR" 4 .IX Item "-Wunused-label" Warn whenever a label is declared but not used. .Sp To suppress this warning use the \fBunused\fR attribute. ! .IP "\fB\-Wunused-parameter\fR" 4 .IX Item "-Wunused-parameter" Warn whenever a function parameter is unused aside from its declaration. .Sp To suppress this warning use the \fBunused\fR attribute. ! .IP "\fB\-Wunused-variable\fR" 4 .IX Item "-Wunused-variable" Warn whenever a local variable or non-constant static variable is unused aside from its declaration .Sp To suppress this warning use the \fBunused\fR attribute. ! .IP "\fB\-Wunused-value\fR" 4 .IX Item "-Wunused-value" Warn whenever a statement computes a result that is explicitly not used. .Sp To suppress this warning cast the expression to \fBvoid\fR. ! .IP "\fB\-Wunused\fR" 4 .IX Item "-Wunused" All all the above \fB\-Wunused\fR options combined. .Sp In order to get a warning about an unused function parameter, you must either specify \fB\-W \-Wunused\fR or separately specify \&\fB\-Wunused-parameter\fR. ! .IP "\fB\-Wuninitialized\fR" 4 .IX Item "-Wuninitialized" Warn if an automatic variable is used without first being initialized or if a variable may be clobbered by a \f(CW\*(C`setjmp\*(C'\fR call. *************** in fact be called at the place which wou *** 1866,1888 **** .Sp Some spurious warnings can be avoided if you declare all the functions you use that never return as \f(CW\*(C`noreturn\*(C'\fR. ! .Ip "\fB\-Wreorder\fR (\*(C+ only)" 4 .IX Item "-Wreorder ( only)" Warn when the order of member initializers given in the code does not match the order in which they must be executed. For instance: ! .Ip "\fB\-Wunknown-pragmas\fR" 4 .IX Item "-Wunknown-pragmas" Warn when a #pragma directive is encountered which is not understood by \&\s-1GCC\s0. If this command line option is used, warnings will even be issued for unknown pragmas in system header files. This is not the case if the warnings were only enabled by the \fB\-Wall\fR command line option. ! .Ip "\fB\-Wall\fR" 4 .IX Item "-Wall" All of the above \fB\-W\fR options combined. This enables all the warnings about constructions that some users consider questionable, and that are easy to avoid (or modify to prevent the warning), even in conjunction with macros. ! .Ip "\fB\-Wsystem-headers\fR" 4 .IX Item "-Wsystem-headers" Print warning messages for constructs found in system header files. Warnings from system headers are normally suppressed, on the assumption --- 1853,1875 ---- .Sp Some spurious warnings can be avoided if you declare all the functions you use that never return as \f(CW\*(C`noreturn\*(C'\fR. ! .IP "\fB\-Wreorder\fR (\*(C+ only)" 4 .IX Item "-Wreorder ( only)" Warn when the order of member initializers given in the code does not match the order in which they must be executed. For instance: ! .IP "\fB\-Wunknown-pragmas\fR" 4 .IX Item "-Wunknown-pragmas" Warn when a #pragma directive is encountered which is not understood by \&\s-1GCC\s0. If this command line option is used, warnings will even be issued for unknown pragmas in system header files. This is not the case if the warnings were only enabled by the \fB\-Wall\fR command line option. ! .IP "\fB\-Wall\fR" 4 .IX Item "-Wall" All of the above \fB\-W\fR options combined. This enables all the warnings about constructions that some users consider questionable, and that are easy to avoid (or modify to prevent the warning), even in conjunction with macros. ! .IP "\fB\-Wsystem-headers\fR" 4 .IX Item "-Wsystem-headers" Print warning messages for constructs found in system header files. Warnings from system headers are normally suppressed, on the assumption *************** consider questionable, but which occasio *** 1899,1909 **** for; others warn about constructions that are necessary or hard to avoid in some cases, and there is no simple way to modify the code to suppress the warning. ! .Ip "\fB\-W\fR" 4 .IX Item "-W" Print extra warning messages for these events: .RS 4 ! .Ip "\(bu" 4 A function can return either with or without a value. (Falling off the end of the function body is considered returning without a value.) For example, this function would evoke such a --- 1886,1896 ---- for; others warn about constructions that are necessary or hard to avoid in some cases, and there is no simple way to modify the code to suppress the warning. ! .IP "\fB\-W\fR" 4 .IX Item "-W" Print extra warning messages for these events: .RS 4 ! .IP "\(bu" 4 A function can return either with or without a value. (Falling off the end of the function body is considered returning without a value.) For example, this function would evoke such a *************** warning: *** 1916,1950 **** \& return a; \& } .Ve ! .Ip "\(bu" 4 An expression-statement or the left-hand side of a comma expression contains no side effects. To suppress the warning, cast the unused expression to void. For example, an expression such as \fBx[i,j]\fR will cause a warning, but \fBx[(void)i,j]\fR will not. ! .Ip "\(bu" 4 An unsigned value is compared against zero with \fB<\fR or \fB<=\fR. ! .Ip "\(bu" 4 A comparison like \fBx<=y<=z\fR appears; this is equivalent to \&\fB(x<=y ? 1 : 0) <= z\fR, which is a different interpretation from that of ordinary mathematical notation. ! .Ip "\(bu" 4 Storage-class specifiers like \f(CW\*(C`static\*(C'\fR are not the first things in a declaration. According to the C Standard, this usage is obsolescent. ! .Ip "\(bu" 4 The return type of a function has a type qualifier such as \f(CW\*(C`const\*(C'\fR. Such a type qualifier has no effect, since the value returned by a function is not an lvalue. (But don't warn about the \s-1GNU\s0 extension of \&\f(CW\*(C`volatile void\*(C'\fR return types. That extension will be warned about if \fB\-pedantic\fR is specified.) ! .Ip "\(bu" 4 If \fB\-Wall\fR or \fB\-Wunused\fR is also specified, warn about unused arguments. ! .Ip "\(bu" 4 A comparison between signed and unsigned values could produce an incorrect result when the signed value is converted to unsigned. (But don't warn if \fB\-Wno-sign-compare\fR is also specified.) ! .Ip "\(bu" 4 An aggregate has a partly bracketed initializer. For example, the following code would evoke such a warning, because braces are missing around the initializer for \f(CW\*(C`x.h\*(C'\fR: --- 1903,1937 ---- \& return a; \& } .Ve ! .IP "\(bu" 4 An expression-statement or the left-hand side of a comma expression contains no side effects. To suppress the warning, cast the unused expression to void. For example, an expression such as \fBx[i,j]\fR will cause a warning, but \fBx[(void)i,j]\fR will not. ! .IP "\(bu" 4 An unsigned value is compared against zero with \fB<\fR or \fB<=\fR. ! .IP "\(bu" 4 A comparison like \fBx<=y<=z\fR appears; this is equivalent to \&\fB(x<=y ? 1 : 0) <= z\fR, which is a different interpretation from that of ordinary mathematical notation. ! .IP "\(bu" 4 Storage-class specifiers like \f(CW\*(C`static\*(C'\fR are not the first things in a declaration. According to the C Standard, this usage is obsolescent. ! .IP "\(bu" 4 The return type of a function has a type qualifier such as \f(CW\*(C`const\*(C'\fR. Such a type qualifier has no effect, since the value returned by a function is not an lvalue. (But don't warn about the \s-1GNU\s0 extension of \&\f(CW\*(C`volatile void\*(C'\fR return types. That extension will be warned about if \fB\-pedantic\fR is specified.) ! .IP "\(bu" 4 If \fB\-Wall\fR or \fB\-Wunused\fR is also specified, warn about unused arguments. ! .IP "\(bu" 4 A comparison between signed and unsigned values could produce an incorrect result when the signed value is converted to unsigned. (But don't warn if \fB\-Wno-sign-compare\fR is also specified.) ! .IP "\(bu" 4 An aggregate has a partly bracketed initializer. For example, the following code would evoke such a warning, because braces are missing around the initializer for \f(CW\*(C`x.h\*(C'\fR: *************** because braces are missing around the in *** 1954,1960 **** \& struct t { struct s h; int i; }; \& struct t x = { 1, 2, 3 }; .Ve ! .Ip "\(bu" 4 An aggregate has an initializer which does not initialize all members. For example, the following code would cause such a warning, because \&\f(CW\*(C`x.h\*(C'\fR would be implicitly initialized to zero: --- 1941,1947 ---- \& struct t { struct s h; int i; }; \& struct t x = { 1, 2, 3 }; .Ve ! .IP "\(bu" 4 An aggregate has an initializer which does not initialize all members. For example, the following code would cause such a warning, because \&\f(CW\*(C`x.h\*(C'\fR would be implicitly initialized to zero: *************** For example, the following code would ca *** 1966,1972 **** .RE .RS 4 .RE ! .Ip "\fB\-Wfloat-equal\fR" 4 .IX Item "-Wfloat-equal" Warn if floating point values are used in equality comparisons. .Sp --- 1953,1959 ---- .RE .RS 4 .RE ! .IP "\fB\-Wfloat-equal\fR" 4 .IX Item "-Wfloat-equal" Warn if floating point values are used in equality comparisons. .Sp *************** different problem). In particular, inst *** 1980,1996 **** would check to see whether the two values have ranges that overlap; and this is done with the relational operators, so equality comparisons are probably mistaken. ! .Ip "\fB\-Wtraditional\fR (C only)" 4 .IX Item "-Wtraditional (C only)" Warn about certain constructs that behave differently in traditional and \&\s-1ISO\s0 C. Also warn about \s-1ISO\s0 C constructs that have no traditional C equivalent, and/or problematic constructs which should be avoided. .RS 4 ! .Ip "\(bu" 4 Macro parameters that appear within string literals in the macro body. In traditional C macro replacement takes place within string literals, but does not in \s-1ISO\s0 C. ! .Ip "\(bu" 4 In traditional C, some preprocessor directives did not exist. Traditional preprocessors would only consider a line to be a directive if the \fB#\fR appeared in column 1 on the line. Therefore --- 1967,1983 ---- would check to see whether the two values have ranges that overlap; and this is done with the relational operators, so equality comparisons are probably mistaken. ! .IP "\fB\-Wtraditional\fR (C only)" 4 .IX Item "-Wtraditional (C only)" Warn about certain constructs that behave differently in traditional and \&\s-1ISO\s0 C. Also warn about \s-1ISO\s0 C constructs that have no traditional C equivalent, and/or problematic constructs which should be avoided. .RS 4 ! .IP "\(bu" 4 Macro parameters that appear within string literals in the macro body. In traditional C macro replacement takes place within string literals, but does not in \s-1ISO\s0 C. ! .IP "\(bu" 4 In traditional C, some preprocessor directives did not exist. Traditional preprocessors would only consider a line to be a directive if the \fB#\fR appeared in column 1 on the line. Therefore *************** first character on the line. It also su *** 2000,2010 **** \&\fB#pragma\fR not understood by traditional C by indenting them. Some traditional implementations would not recognise \fB#elif\fR, so it suggests avoiding it altogether. ! .Ip "\(bu" 4 A function-like macro that appears without arguments. ! .Ip "\(bu" 4 The unary plus operator. ! .Ip "\(bu" 4 The \fBU\fR integer constant suffix, or the \fBF\fR or \fBL\fR floating point constant suffixes. (Traditional C does support the \fBL\fR suffix on integer constants.) Note, these suffixes appear in macros defined in the system --- 1987,1997 ---- \&\fB#pragma\fR not understood by traditional C by indenting them. Some traditional implementations would not recognise \fB#elif\fR, so it suggests avoiding it altogether. ! .IP "\(bu" 4 A function-like macro that appears without arguments. ! .IP "\(bu" 4 The unary plus operator. ! .IP "\(bu" 4 The \fBU\fR integer constant suffix, or the \fBF\fR or \fBL\fR floating point constant suffixes. (Traditional C does support the \fBL\fR suffix on integer constants.) Note, these suffixes appear in macros defined in the system *************** headers of most modern systems, e.g. the *** 2012,2044 **** Use of these macros in user code might normally lead to spurious warnings, however gcc's integrated preprocessor has enough context to avoid warning in these cases. ! .Ip "\(bu" 4 A function declared external in one block and then used after the end of the block. ! .Ip "\(bu" 4 A \f(CW\*(C`switch\*(C'\fR statement has an operand of type \f(CW\*(C`long\*(C'\fR. ! .Ip "\(bu" 4 A non-\f(CW\*(C`static\*(C'\fR function declaration follows a \f(CW\*(C`static\*(C'\fR one. This construct is not accepted by some traditional C compilers. ! .Ip "\(bu" 4 The \s-1ISO\s0 type of an integer constant has a different width or signedness from its traditional type. This warning is only issued if the base of the constant is ten. I.e. hexadecimal or octal values, which typically represent bit patterns, are not warned about. ! .Ip "\(bu" 4 Usage of \s-1ISO\s0 string concatenation is detected. ! .Ip "\(bu" 4 Initialization of automatic aggregates. ! .Ip "\(bu" 4 Identifier conflicts with labels. Traditional C lacks a separate namespace for labels. ! .Ip "\(bu" 4 Initialization of unions. If the initializer is zero, the warning is omitted. This is done under the assumption that the zero initializer in user code appears conditioned on e.g. \f(CW\*(C`_\|_STDC_\|_\*(C'\fR to avoid missing initializer warnings and relies on default initialization to zero in the traditional C case. ! .Ip "\(bu" 4 Conversions by prototypes between fixed/floating point values and vice versa. The absence of these prototypes when compiling with traditional C would cause serious problems. This is a subset of the possible --- 1999,2031 ---- Use of these macros in user code might normally lead to spurious warnings, however gcc's integrated preprocessor has enough context to avoid warning in these cases. ! .IP "\(bu" 4 A function declared external in one block and then used after the end of the block. ! .IP "\(bu" 4 A \f(CW\*(C`switch\*(C'\fR statement has an operand of type \f(CW\*(C`long\*(C'\fR. ! .IP "\(bu" 4 A non-\f(CW\*(C`static\*(C'\fR function declaration follows a \f(CW\*(C`static\*(C'\fR one. This construct is not accepted by some traditional C compilers. ! .IP "\(bu" 4 The \s-1ISO\s0 type of an integer constant has a different width or signedness from its traditional type. This warning is only issued if the base of the constant is ten. I.e. hexadecimal or octal values, which typically represent bit patterns, are not warned about. ! .IP "\(bu" 4 Usage of \s-1ISO\s0 string concatenation is detected. ! .IP "\(bu" 4 Initialization of automatic aggregates. ! .IP "\(bu" 4 Identifier conflicts with labels. Traditional C lacks a separate namespace for labels. ! .IP "\(bu" 4 Initialization of unions. If the initializer is zero, the warning is omitted. This is done under the assumption that the zero initializer in user code appears conditioned on e.g. \f(CW\*(C`_\|_STDC_\|_\*(C'\fR to avoid missing initializer warnings and relies on default initialization to zero in the traditional C case. ! .IP "\(bu" 4 Conversions by prototypes between fixed/floating point values and vice versa. The absence of these prototypes when compiling with traditional C would cause serious problems. This is a subset of the possible *************** conversion warnings, for the full set us *** 2046,2088 **** .RE .RS 4 .RE ! .Ip "\fB\-Wundef\fR" 4 .IX Item "-Wundef" Warn if an undefined identifier is evaluated in an \fB#if\fR directive. ! .Ip "\fB\-Wshadow\fR" 4 .IX Item "-Wshadow" Warn whenever a local variable shadows another local variable, parameter or global variable or whenever a built-in function is shadowed. ! .Ip "\fB\-Wid-clash-\fR\fIlen\fR" 4 .IX Item "-Wid-clash-len" Warn whenever two distinct identifiers match in the first \fIlen\fR characters. This may help you prepare a program that will compile with certain obsolete, brain-damaged compilers. ! .Ip "\fB\-Wlarger-than-\fR\fIlen\fR" 4 .IX Item "-Wlarger-than-len" Warn whenever an object of larger than \fIlen\fR bytes is defined. ! .Ip "\fB\-Wpointer-arith\fR" 4 .IX Item "-Wpointer-arith" Warn about anything that depends on the ``size of'' a function type or of \f(CW\*(C`void\*(C'\fR. \s-1GNU\s0 C assigns these types a size of 1, for convenience in calculations with \f(CW\*(C`void *\*(C'\fR pointers and pointers to functions. ! .Ip "\fB\-Wbad-function-cast\fR (C only)" 4 .IX Item "-Wbad-function-cast (C only)" Warn whenever a function call is cast to a non-matching type. For example, warn if \f(CW\*(C`int malloc()\*(C'\fR is cast to \f(CW\*(C`anything *\*(C'\fR. ! .Ip "\fB\-Wcast-qual\fR" 4 .IX Item "-Wcast-qual" Warn whenever a pointer is cast so as to remove a type qualifier from the target type. For example, warn if a \f(CW\*(C`const char *\*(C'\fR is cast to an ordinary \f(CW\*(C`char *\*(C'\fR. ! .Ip "\fB\-Wcast-align\fR" 4 .IX Item "-Wcast-align" Warn whenever a pointer is cast such that the required alignment of the target is increased. For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to an \f(CW\*(C`int *\*(C'\fR on machines where integers can only be accessed at two- or four-byte boundaries. ! .Ip "\fB\-Wwrite-strings\fR" 4 .IX Item "-Wwrite-strings" When compiling C, give string constants the type \f(CW\*(C`const char[\f(CIlength\f(CW]\*(C'\fR so that --- 2033,2075 ---- .RE .RS 4 .RE ! .IP "\fB\-Wundef\fR" 4 .IX Item "-Wundef" Warn if an undefined identifier is evaluated in an \fB#if\fR directive. ! .IP "\fB\-Wshadow\fR" 4 .IX Item "-Wshadow" Warn whenever a local variable shadows another local variable, parameter or global variable or whenever a built-in function is shadowed. ! .IP "\fB\-Wid-clash-\fR\fIlen\fR" 4 .IX Item "-Wid-clash-len" Warn whenever two distinct identifiers match in the first \fIlen\fR characters. This may help you prepare a program that will compile with certain obsolete, brain-damaged compilers. ! .IP "\fB\-Wlarger-than-\fR\fIlen\fR" 4 .IX Item "-Wlarger-than-len" Warn whenever an object of larger than \fIlen\fR bytes is defined. ! .IP "\fB\-Wpointer-arith\fR" 4 .IX Item "-Wpointer-arith" Warn about anything that depends on the ``size of'' a function type or of \f(CW\*(C`void\*(C'\fR. \s-1GNU\s0 C assigns these types a size of 1, for convenience in calculations with \f(CW\*(C`void *\*(C'\fR pointers and pointers to functions. ! .IP "\fB\-Wbad-function-cast\fR (C only)" 4 .IX Item "-Wbad-function-cast (C only)" Warn whenever a function call is cast to a non-matching type. For example, warn if \f(CW\*(C`int malloc()\*(C'\fR is cast to \f(CW\*(C`anything *\*(C'\fR. ! .IP "\fB\-Wcast-qual\fR" 4 .IX Item "-Wcast-qual" Warn whenever a pointer is cast so as to remove a type qualifier from the target type. For example, warn if a \f(CW\*(C`const char *\*(C'\fR is cast to an ordinary \f(CW\*(C`char *\*(C'\fR. ! .IP "\fB\-Wcast-align\fR" 4 .IX Item "-Wcast-align" Warn whenever a pointer is cast such that the required alignment of the target is increased. For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to an \f(CW\*(C`int *\*(C'\fR on machines where integers can only be accessed at two- or four-byte boundaries. ! .IP "\fB\-Wwrite-strings\fR" 4 .IX Item "-Wwrite-strings" When compiling C, give string constants the type \f(CW\*(C`const char[\f(CIlength\f(CW]\*(C'\fR so that *************** compile time code that can try to write *** 2094,2100 **** only if you have been very careful about using \f(CW\*(C`const\*(C'\fR in declarations and prototypes. Otherwise, it will just be a nuisance; this is why we did not make \fB\-Wall\fR request these warnings. ! .Ip "\fB\-Wconversion\fR" 4 .IX Item "-Wconversion" Warn if a prototype causes a type conversion that is different from what would happen to the same argument in the absence of a prototype. This --- 2081,2087 ---- only if you have been very careful about using \f(CW\*(C`const\*(C'\fR in declarations and prototypes. Otherwise, it will just be a nuisance; this is why we did not make \fB\-Wall\fR request these warnings. ! .IP "\fB\-Wconversion\fR" 4 .IX Item "-Wconversion" Warn if a prototype causes a type conversion that is different from what would happen to the same argument in the absence of a prototype. This *************** Also, warn if a negative integer constan *** 2106,2141 **** converted to an unsigned type. For example, warn about the assignment \&\f(CW\*(C`x = \-1\*(C'\fR if \f(CW\*(C`x\*(C'\fR is unsigned. But do not warn about explicit casts like \f(CW\*(C`(unsigned) \-1\*(C'\fR. ! .Ip "\fB\-Wsign-compare\fR" 4 .IX Item "-Wsign-compare" Warn when a comparison between signed and unsigned values could produce an incorrect result when the signed value is converted to unsigned. This warning is also enabled by \fB\-W\fR; to get the other warnings of \fB\-W\fR without this warning, use \fB\-W \-Wno-sign-compare\fR. ! .Ip "\fB\-Waggregate-return\fR" 4 .IX Item "-Waggregate-return" Warn if any functions that return structures or unions are defined or called. (In languages where you can return an array, this also elicits a warning.) ! .Ip "\fB\-Wstrict-prototypes\fR (C only)" 4 .IX Item "-Wstrict-prototypes (C only)" Warn if a function is declared or defined without specifying the argument types. (An old-style function definition is permitted without a warning if preceded by a declaration which specifies the argument types.) ! .Ip "\fB\-Wmissing-prototypes\fR (C only)" 4 .IX Item "-Wmissing-prototypes (C only)" Warn if a global function is defined without a previous prototype declaration. This warning is issued even if the definition itself provides a prototype. The aim is to detect global functions that fail to be declared in header files. ! .Ip "\fB\-Wmissing-declarations\fR" 4 .IX Item "-Wmissing-declarations" Warn if a global function is defined without a previous declaration. Do so even if the definition itself provides a prototype. Use this option to detect global functions that are not declared in header files. ! .Ip "\fB\-Wmissing-noreturn\fR" 4 .IX Item "-Wmissing-noreturn" Warn about functions which might be candidates for attribute \f(CW\*(C`noreturn\*(C'\fR. Note these are only possible candidates, not absolute ones. Care should --- 2093,2128 ---- converted to an unsigned type. For example, warn about the assignment \&\f(CW\*(C`x = \-1\*(C'\fR if \f(CW\*(C`x\*(C'\fR is unsigned. But do not warn about explicit casts like \f(CW\*(C`(unsigned) \-1\*(C'\fR. ! .IP "\fB\-Wsign-compare\fR" 4 .IX Item "-Wsign-compare" Warn when a comparison between signed and unsigned values could produce an incorrect result when the signed value is converted to unsigned. This warning is also enabled by \fB\-W\fR; to get the other warnings of \fB\-W\fR without this warning, use \fB\-W \-Wno-sign-compare\fR. ! .IP "\fB\-Waggregate-return\fR" 4 .IX Item "-Waggregate-return" Warn if any functions that return structures or unions are defined or called. (In languages where you can return an array, this also elicits a warning.) ! .IP "\fB\-Wstrict-prototypes\fR (C only)" 4 .IX Item "-Wstrict-prototypes (C only)" Warn if a function is declared or defined without specifying the argument types. (An old-style function definition is permitted without a warning if preceded by a declaration which specifies the argument types.) ! .IP "\fB\-Wmissing-prototypes\fR (C only)" 4 .IX Item "-Wmissing-prototypes (C only)" Warn if a global function is defined without a previous prototype declaration. This warning is issued even if the definition itself provides a prototype. The aim is to detect global functions that fail to be declared in header files. ! .IP "\fB\-Wmissing-declarations\fR" 4 .IX Item "-Wmissing-declarations" Warn if a global function is defined without a previous declaration. Do so even if the definition itself provides a prototype. Use this option to detect global functions that are not declared in header files. ! .IP "\fB\-Wmissing-noreturn\fR" 4 .IX Item "-Wmissing-noreturn" Warn about functions which might be candidates for attribute \f(CW\*(C`noreturn\*(C'\fR. Note these are only possible candidates, not absolute ones. Care should *************** be taken to manually verify functions ac *** 2143,2149 **** adding the \f(CW\*(C`noreturn\*(C'\fR attribute, otherwise subtle code generation bugs could be introduced. You will not get a warning for \f(CW\*(C`main\*(C'\fR in hosted C environments. ! .Ip "\fB\-Wmissing-format-attribute\fR" 4 .IX Item "-Wmissing-format-attribute" If \fB\-Wformat\fR is enabled, also warn about functions which might be candidates for \f(CW\*(C`format\*(C'\fR attributes. Note these are only possible --- 2130,2136 ---- adding the \f(CW\*(C`noreturn\*(C'\fR attribute, otherwise subtle code generation bugs could be introduced. You will not get a warning for \f(CW\*(C`main\*(C'\fR in hosted C environments. ! .IP "\fB\-Wmissing-format-attribute\fR" 4 .IX Item "-Wmissing-format-attribute" If \fB\-Wformat\fR is enabled, also warn about functions which might be candidates for \f(CW\*(C`format\*(C'\fR attributes. Note these are only possible *************** like \f(CW\*(C`vprintf\*(C'\fR or \f(CW\ *** 2153,2159 **** case, and some functions for which \f(CW\*(C`format\*(C'\fR attributes are appropriate may not be detected. This option has no effect unless \&\fB\-Wformat\fR is enabled (possibly by \fB\-Wall\fR). ! .Ip "\fB\-Wpacked\fR" 4 .IX Item "-Wpacked" Warn if a structure is given the packed attribute, but the packed attribute has no effect on the layout or size of the structure. --- 2140,2146 ---- case, and some functions for which \f(CW\*(C`format\*(C'\fR attributes are appropriate may not be detected. This option has no effect unless \&\fB\-Wformat\fR is enabled (possibly by \fB\-Wall\fR). ! .IP "\fB\-Wpacked\fR" 4 .IX Item "-Wpacked" Warn if a structure is given the packed attribute, but the packed attribute has no effect on the layout or size of the structure. *************** have the packed attribute: *** 2172,2191 **** \& struct foo f; \& }; .Ve ! .Ip "\fB\-Wpadded\fR" 4 .IX Item "-Wpadded" Warn if padding is included in a structure, either to align an element of the structure or to align the whole structure. Sometimes when this happens it is possible to rearrange the fields of the structure to reduce the padding and so make the structure smaller. ! .Ip "\fB\-Wredundant-decls\fR" 4 .IX Item "-Wredundant-decls" Warn if anything is declared more than once in the same scope, even in cases where multiple declaration is valid and changes nothing. ! .Ip "\fB\-Wnested-externs\fR (C only)" 4 .IX Item "-Wnested-externs (C only)" Warn if an \f(CW\*(C`extern\*(C'\fR declaration is encountered within a function. ! .Ip "\fB\-Wunreachable-code\fR" 4 .IX Item "-Wunreachable-code" Warn if the compiler detects that code will never be executed. .Sp --- 2159,2178 ---- \& struct foo f; \& }; .Ve ! .IP "\fB\-Wpadded\fR" 4 .IX Item "-Wpadded" Warn if padding is included in a structure, either to align an element of the structure or to align the whole structure. Sometimes when this happens it is possible to rearrange the fields of the structure to reduce the padding and so make the structure smaller. ! .IP "\fB\-Wredundant-decls\fR" 4 .IX Item "-Wredundant-decls" Warn if anything is declared more than once in the same scope, even in cases where multiple declaration is valid and changes nothing. ! .IP "\fB\-Wnested-externs\fR (C only)" 4 .IX Item "-Wnested-externs (C only)" Warn if an \f(CW\*(C`extern\*(C'\fR declaration is encountered within a function. ! .IP "\fB\-Wunreachable-code\fR" 4 .IX Item "-Wunreachable-code" Warn if the compiler detects that code will never be executed. .Sp *************** version of a program there is often subs *** 2206,2221 **** correct functioning of the program and is, hopefully, unreachable because the program does work. Another common use of unreachable code is to provide behaviour which is selectable at compile-time. ! .Ip "\fB\-Winline\fR" 4 .IX Item "-Winline" Warn if a function can not be inlined and it was declared as inline. ! .Ip "\fB\-Wlong-long\fR" 4 .IX Item "-Wlong-long" Warn if \fBlong long\fR type is used. This is default. To inhibit the warning messages, use \fB\-Wno-long-long\fR. Flags \&\fB\-Wlong-long\fR and \fB\-Wno-long-long\fR are taken into account only when \fB\-pedantic\fR flag is used. ! .Ip "\fB\-Wdisabled-optimization\fR" 4 .IX Item "-Wdisabled-optimization" Warn if a requested optimization pass is disabled. This warning does not generally indicate that there is anything wrong with your code; it --- 2193,2208 ---- correct functioning of the program and is, hopefully, unreachable because the program does work. Another common use of unreachable code is to provide behaviour which is selectable at compile-time. ! .IP "\fB\-Winline\fR" 4 .IX Item "-Winline" Warn if a function can not be inlined and it was declared as inline. ! .IP "\fB\-Wlong-long\fR" 4 .IX Item "-Wlong-long" Warn if \fBlong long\fR type is used. This is default. To inhibit the warning messages, use \fB\-Wno-long-long\fR. Flags \&\fB\-Wlong-long\fR and \fB\-Wno-long-long\fR are taken into account only when \fB\-pedantic\fR flag is used. ! .IP "\fB\-Wdisabled-optimization\fR" 4 .IX Item "-Wdisabled-optimization" Warn if a requested optimization pass is disabled. This warning does not generally indicate that there is anything wrong with your code; it *************** merely indicates that \s-1GCC\s0's optim *** 2223,2236 **** effectively. Often, the problem is that your code is too big or too complex; \s-1GCC\s0 will refuse to optimize programs when the optimization itself is likely to take inordinate amounts of time. ! .Ip "\fB\-Werror\fR" 4 .IX Item "-Werror" Make all warnings into errors. .Sh "Options for Debugging Your Program or \s-1GCC\s0" .IX Subsection "Options for Debugging Your Program or GCC" \&\s-1GCC\s0 has various special options that are used for debugging either your program or \s-1GCC:\s0 ! .Ip "\fB\-g\fR" 4 .IX Item "-g" Produce debugging information in the operating system's native format (stabs, \s-1COFF\s0, \s-1XCOFF\s0, or \s-1DWARF\s0). \s-1GDB\s0 can work with this debugging --- 2210,2223 ---- effectively. Often, the problem is that your code is too big or too complex; \s-1GCC\s0 will refuse to optimize programs when the optimization itself is likely to take inordinate amounts of time. ! .IP "\fB\-Werror\fR" 4 .IX Item "-Werror" Make all warnings into errors. .Sh "Options for Debugging Your Program or \s-1GCC\s0" .IX Subsection "Options for Debugging Your Program or GCC" \&\s-1GCC\s0 has various special options that are used for debugging either your program or \s-1GCC:\s0 ! .IP "\fB\-g\fR" 4 .IX Item "-g" Produce debugging information in the operating system's native format (stabs, \s-1COFF\s0, \s-1XCOFF\s0, or \s-1DWARF\s0). \s-1GDB\s0 can work with this debugging *************** it reasonable to use the optimizer for p *** 2258,2327 **** .Sp The following options are useful when \s-1GCC\s0 is generated with the capability for more than one debugging format. ! .Ip "\fB\-ggdb\fR" 4 .IX Item "-ggdb" Produce debugging information for use by \s-1GDB\s0. This means to use the most expressive format available (\s-1DWARF\s0 2, stabs, or the native format if neither of those are supported), including \s-1GDB\s0 extensions if at all possible. ! .Ip "\fB\-gstabs\fR" 4 .IX Item "-gstabs" Produce debugging information in stabs format (if that is supported), without \s-1GDB\s0 extensions. This is the format used by \s-1DBX\s0 on most \s-1BSD\s0 systems. On \s-1MIPS\s0, Alpha and System V Release 4 systems this option produces stabs debugging output which is not understood by \s-1DBX\s0 or \s-1SDB\s0. On System V Release 4 systems this option requires the \s-1GNU\s0 assembler. ! .Ip "\fB\-gstabs+\fR" 4 .IX Item "-gstabs+" Produce debugging information in stabs format (if that is supported), using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0). The use of these extensions is likely to make other debuggers crash or refuse to read the program. ! .Ip "\fB\-gcoff\fR" 4 .IX Item "-gcoff" Produce debugging information in \s-1COFF\s0 format (if that is supported). This is the format used by \s-1SDB\s0 on most System V systems prior to System V Release 4. ! .Ip "\fB\-gxcoff\fR" 4 .IX Item "-gxcoff" Produce debugging information in \s-1XCOFF\s0 format (if that is supported). This is the format used by the \s-1DBX\s0 debugger on \s-1IBM\s0 \s-1RS/6000\s0 systems. ! .Ip "\fB\-gxcoff+\fR" 4 .IX Item "-gxcoff+" Produce debugging information in \s-1XCOFF\s0 format (if that is supported), using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0). The use of these extensions is likely to make other debuggers crash or refuse to read the program, and may cause assemblers other than the \s-1GNU\s0 assembler (\s-1GAS\s0) to fail with an error. ! .Ip "\fB\-gdwarf\fR" 4 .IX Item "-gdwarf" Produce debugging information in \s-1DWARF\s0 version 1 format (if that is supported). This is the format used by \s-1SDB\s0 on most System V Release 4 systems. ! .Ip "\fB\-gdwarf+\fR" 4 .IX Item "-gdwarf+" Produce debugging information in \s-1DWARF\s0 version 1 format (if that is supported), using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0). The use of these extensions is likely to make other debuggers crash or refuse to read the program. ! .Ip "\fB\-gdwarf-2\fR" 4 .IX Item "-gdwarf-2" Produce debugging information in \s-1DWARF\s0 version 2 format (if that is supported). This is the format used by \s-1DBX\s0 on \s-1IRIX\s0 6. ! .Ip "\fB\-g\fR\fIlevel\fR" 4 .IX Item "-glevel" .PD 0 ! .Ip "\fB\-ggdb\fR\fIlevel\fR" 4 .IX Item "-ggdblevel" ! .Ip "\fB\-gstabs\fR\fIlevel\fR" 4 .IX Item "-gstabslevel" ! .Ip "\fB\-gcoff\fR\fIlevel\fR" 4 .IX Item "-gcofflevel" ! .Ip "\fB\-gxcoff\fR\fIlevel\fR" 4 .IX Item "-gxcofflevel" ! .Ip "\fB\-gdwarf\fR\fIlevel\fR" 4 .IX Item "-gdwarflevel" ! .Ip "\fB\-gdwarf-2\fR\fIlevel\fR" 4 .IX Item "-gdwarf-2level" .PD Request debugging information and also use \fIlevel\fR to specify how --- 2245,2314 ---- .Sp The following options are useful when \s-1GCC\s0 is generated with the capability for more than one debugging format. ! .IP "\fB\-ggdb\fR" 4 .IX Item "-ggdb" Produce debugging information for use by \s-1GDB\s0. This means to use the most expressive format available (\s-1DWARF\s0 2, stabs, or the native format if neither of those are supported), including \s-1GDB\s0 extensions if at all possible. ! .IP "\fB\-gstabs\fR" 4 .IX Item "-gstabs" Produce debugging information in stabs format (if that is supported), without \s-1GDB\s0 extensions. This is the format used by \s-1DBX\s0 on most \s-1BSD\s0 systems. On \s-1MIPS\s0, Alpha and System V Release 4 systems this option produces stabs debugging output which is not understood by \s-1DBX\s0 or \s-1SDB\s0. On System V Release 4 systems this option requires the \s-1GNU\s0 assembler. ! .IP "\fB\-gstabs+\fR" 4 .IX Item "-gstabs+" Produce debugging information in stabs format (if that is supported), using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0). The use of these extensions is likely to make other debuggers crash or refuse to read the program. ! .IP "\fB\-gcoff\fR" 4 .IX Item "-gcoff" Produce debugging information in \s-1COFF\s0 format (if that is supported). This is the format used by \s-1SDB\s0 on most System V systems prior to System V Release 4. ! .IP "\fB\-gxcoff\fR" 4 .IX Item "-gxcoff" Produce debugging information in \s-1XCOFF\s0 format (if that is supported). This is the format used by the \s-1DBX\s0 debugger on \s-1IBM\s0 \s-1RS/6000\s0 systems. ! .IP "\fB\-gxcoff+\fR" 4 .IX Item "-gxcoff+" Produce debugging information in \s-1XCOFF\s0 format (if that is supported), using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0). The use of these extensions is likely to make other debuggers crash or refuse to read the program, and may cause assemblers other than the \s-1GNU\s0 assembler (\s-1GAS\s0) to fail with an error. ! .IP "\fB\-gdwarf\fR" 4 .IX Item "-gdwarf" Produce debugging information in \s-1DWARF\s0 version 1 format (if that is supported). This is the format used by \s-1SDB\s0 on most System V Release 4 systems. ! .IP "\fB\-gdwarf+\fR" 4 .IX Item "-gdwarf+" Produce debugging information in \s-1DWARF\s0 version 1 format (if that is supported), using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0). The use of these extensions is likely to make other debuggers crash or refuse to read the program. ! .IP "\fB\-gdwarf-2\fR" 4 .IX Item "-gdwarf-2" Produce debugging information in \s-1DWARF\s0 version 2 format (if that is supported). This is the format used by \s-1DBX\s0 on \s-1IRIX\s0 6. ! .IP "\fB\-g\fR\fIlevel\fR" 4 .IX Item "-glevel" .PD 0 ! .IP "\fB\-ggdb\fR\fIlevel\fR" 4 .IX Item "-ggdblevel" ! .IP "\fB\-gstabs\fR\fIlevel\fR" 4 .IX Item "-gstabslevel" ! .IP "\fB\-gcoff\fR\fIlevel\fR" 4 .IX Item "-gcofflevel" ! .IP "\fB\-gxcoff\fR\fIlevel\fR" 4 .IX Item "-gxcofflevel" ! .IP "\fB\-gdwarf\fR\fIlevel\fR" 4 .IX Item "-gdwarflevel" ! .IP "\fB\-gdwarf-2\fR\fIlevel\fR" 4 .IX Item "-gdwarf-2level" .PD Request debugging information and also use \fIlevel\fR to specify how *************** about local variables and no line number *** 2335,2353 **** Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you use \fB\-g3\fR. ! .Ip "\fB\-p\fR" 4 .IX Item "-p" Generate extra code to write profile information suitable for the analysis program \f(CW\*(C`prof\*(C'\fR. You must use this option when compiling the source files you want data about, and you must also use it when linking. ! .Ip "\fB\-pg\fR" 4 .IX Item "-pg" Generate extra code to write profile information suitable for the analysis program \f(CW\*(C`gprof\*(C'\fR. You must use this option when compiling the source files you want data about, and you must also use it when linking. ! .Ip "\fB\-a\fR" 4 .IX Item "-a" Generate extra code to write profile information for basic blocks, which will record the number of times each basic block is executed, the basic block start --- 2322,2340 ---- Level 3 includes extra information, such as all the macro definitions present in the program. Some debuggers support macro expansion when you use \fB\-g3\fR. ! .IP "\fB\-p\fR" 4 .IX Item "-p" Generate extra code to write profile information suitable for the analysis program \f(CW\*(C`prof\*(C'\fR. You must use this option when compiling the source files you want data about, and you must also use it when linking. ! .IP "\fB\-pg\fR" 4 .IX Item "-pg" Generate extra code to write profile information suitable for the analysis program \f(CW\*(C`gprof\*(C'\fR. You must use this option when compiling the source files you want data about, and you must also use it when linking. ! .IP "\fB\-a\fR" 4 .IX Item "-a" Generate extra code to write profile information for basic blocks, which will record the number of times each basic block is executed, the basic block start *************** to append to the text file \fIbb.out\fR. *** 2359,2377 **** This data could be analyzed by a program like \f(CW\*(C`tcov\*(C'\fR. Note, however, that the format of the data is not what \f(CW\*(C`tcov\*(C'\fR expects. Eventually \s-1GNU\s0 \f(CW\*(C`gprof\*(C'\fR should be extended to process this data. ! .Ip "\fB\-Q\fR" 4 .IX Item "-Q" Makes the compiler print out each function name as it is compiled, and print some statistics about each pass when it finishes. ! .Ip "\fB\-ftime-report\fR" 4 .IX Item "-ftime-report" Makes the compiler print some statistics about the time consumed by each pass when it finishes. ! .Ip "\fB\-fmem-report\fR" 4 .IX Item "-fmem-report" Makes the compiler print some statistics about permanent memory allocation when it finishes. ! .Ip "\fB\-ax\fR" 4 .IX Item "-ax" Generate extra code to profile basic blocks. Your executable will produce output that is a superset of that produced when \fB\-a\fR is --- 2346,2364 ---- This data could be analyzed by a program like \f(CW\*(C`tcov\*(C'\fR. Note, however, that the format of the data is not what \f(CW\*(C`tcov\*(C'\fR expects. Eventually \s-1GNU\s0 \f(CW\*(C`gprof\*(C'\fR should be extended to process this data. ! .IP "\fB\-Q\fR" 4 .IX Item "-Q" Makes the compiler print out each function name as it is compiled, and print some statistics about each pass when it finishes. ! .IP "\fB\-ftime-report\fR" 4 .IX Item "-ftime-report" Makes the compiler print some statistics about the time consumed by each pass when it finishes. ! .IP "\fB\-fmem-report\fR" 4 .IX Item "-fmem-report" Makes the compiler print some statistics about permanent memory allocation when it finishes. ! .IP "\fB\-ax\fR" 4 .IX Item "-ax" Generate extra code to profile basic blocks. Your executable will produce output that is a superset of that produced when \fB\-a\fR is *************** available paths and filenames in file \f *** 2391,2410 **** .Sp Several function names have a special meaning: .RS 4 ! .if n .Ip "\f(CW""""_\|_bb_jumps_\|_""""\fR" 4 ! .el .Ip "\f(CW_\|_bb_jumps_\|_\fR" 4 .IX Item "__bb_jumps__" Write source, target and frequency of jumps to file \fIbb.out\fR. ! .if n .Ip "\f(CW""""_\|_bb_hidecall_\|_""""\fR" 4 ! .el .Ip "\f(CW_\|_bb_hidecall_\|_\fR" 4 .IX Item "__bb_hidecall__" Exclude function calls from frequency count. ! .if n .Ip "\f(CW""""_\|_bb_showret_\|_""""\fR" 4 ! .el .Ip "\f(CW_\|_bb_showret_\|_\fR" 4 .IX Item "__bb_showret__" Include function returns in frequency count. ! .if n .Ip "\f(CW""""_\|_bb_trace_\|_""""\fR" 4 ! .el .Ip "\f(CW_\|_bb_trace_\|_\fR" 4 .IX Item "__bb_trace__" Write the sequence of basic blocks executed to file \fIbbtrace.gz\fR. The file will be compressed using the program \fBgzip\fR, which must --- 2378,2397 ---- .Sp Several function names have a special meaning: .RS 4 ! .if n .IP """_\|_bb_jumps_\|_""" 4 ! .el .IP "\f(CW_\|_bb_jumps_\|_\fR" 4 .IX Item "__bb_jumps__" Write source, target and frequency of jumps to file \fIbb.out\fR. ! .if n .IP """_\|_bb_hidecall_\|_""" 4 ! .el .IP "\f(CW_\|_bb_hidecall_\|_\fR" 4 .IX Item "__bb_hidecall__" Exclude function calls from frequency count. ! .if n .IP """_\|_bb_showret_\|_""" 4 ! .el .IP "\f(CW_\|_bb_showret_\|_\fR" 4 .IX Item "__bb_showret__" Include function returns in frequency count. ! .if n .IP """_\|_bb_trace_\|_""" 4 ! .el .IP "\f(CW_\|_bb_trace_\|_\fR" 4 .IX Item "__bb_trace__" Write the sequence of basic blocks executed to file \fIbbtrace.gz\fR. The file will be compressed using the program \fBgzip\fR, which must *************** to return instructions is added to the t *** 2453,2459 **** written to \fIbbtrace.gz\fR. It is solely used for counting jump frequencies. .RE ! .Ip "\fB\-fprofile-arcs\fR" 4 .IX Item "-fprofile-arcs" Instrument \fIarcs\fR during compilation. For each function of your program, \s-1GCC\s0 creates a program flow graph, then finds a spanning tree --- 2440,2446 ---- written to \fIbbtrace.gz\fR. It is solely used for counting jump frequencies. .RE ! .IP "\fB\-fprofile-arcs\fR" 4 .IX Item "-fprofile-arcs" Instrument \fIarcs\fR during compilation. For each function of your program, \s-1GCC\s0 creates a program flow graph, then finds a spanning tree *************** saves the arc execution counts to a file *** 2481,2496 **** \&\fI\fIsourcename\fI.da\fR. Use the compiler option \&\fB\-fbranch-probabilities\fR when recompiling, to optimize using estimated branch probabilities. ! .Ip "\fB\-ftest-coverage\fR" 4 .IX Item "-ftest-coverage" Create data files for the \f(CW\*(C`gcov\*(C'\fR code-coverage utility. The data file names begin with the name of your source file: .RS 4 ! .Ip "\fIsourcename\fR\fB.bb\fR" 4 .IX Item "sourcename.bb" A mapping from basic blocks to line numbers, which \f(CW\*(C`gcov\*(C'\fR uses to associate basic block execution counts with line numbers. ! .Ip "\fIsourcename\fR\fB.bbg\fR" 4 .IX Item "sourcename.bbg" A list of all arcs in the program flow graph. This allows \f(CW\*(C`gcov\*(C'\fR to reconstruct the program flow graph, so that it can compute all basic --- 2468,2483 ---- \&\fI\fIsourcename\fI.da\fR. Use the compiler option \&\fB\-fbranch-probabilities\fR when recompiling, to optimize using estimated branch probabilities. ! .IP "\fB\-ftest-coverage\fR" 4 .IX Item "-ftest-coverage" Create data files for the \f(CW\*(C`gcov\*(C'\fR code-coverage utility. The data file names begin with the name of your source file: .RS 4 ! .IP "\fIsourcename\fR\fB.bb\fR" 4 .IX Item "sourcename.bb" A mapping from basic blocks to line numbers, which \f(CW\*(C`gcov\*(C'\fR uses to associate basic block execution counts with line numbers. ! .IP "\fIsourcename\fR\fB.bbg\fR" 4 .IX Item "sourcename.bbg" A list of all arcs in the program flow graph. This allows \f(CW\*(C`gcov\*(C'\fR to reconstruct the program flow graph, so that it can compute all basic *************** block and arc execution counts from the *** 2500,2506 **** .RE .RS 4 .RE ! .Ip "\fB\-d\fR\fIletters\fR" 4 .IX Item "-dletters" Says to make debugging dumps during compilation at times specified by \&\fIletters\fR. This is used for debugging the compiler. The file names --- 2487,2493 ---- .RE .RS 4 .RE ! .IP "\fB\-d\fR\fIletters\fR" 4 .IX Item "-dletters" Says to make debugging dumps during compilation at times specified by \&\fIletters\fR. This is used for debugging the compiler. The file names *************** for most of the dumps are made by append *** 2508,2664 **** the source file name (e.g. \fIfoo.c.00.rtl\fR or \fIfoo.c.01.sibling\fR). Here are the possible letters for use in \fIletters\fR, and their meanings: .RS 4 ! .Ip "\fBA\fR" 4 .IX Item "A" Annotate the assembler output with miscellaneous debugging information. ! .Ip "\fBb\fR" 4 .IX Item "b" Dump after computing branch probabilities, to \fI\fIfile\fI.11.bp\fR. ! .Ip "\fBB\fR" 4 .IX Item "B" Dump after block reordering, to \fI\fIfile\fI.26.bbro\fR. ! .Ip "\fBc\fR" 4 .IX Item "c" Dump after instruction combination, to the file \fI\fIfile\fI.14.combine\fR. ! .Ip "\fBC\fR" 4 .IX Item "C" Dump after the first if conversion, to the file \fI\fIfile\fI.15.ce\fR. ! .Ip "\fBd\fR" 4 .IX Item "d" Dump after delayed branch scheduling, to \fI\fIfile\fI.29.dbr\fR. ! .Ip "\fBD\fR" 4 .IX Item "D" Dump all macro definitions, at the end of preprocessing, in addition to normal output. ! .Ip "\fBe\fR" 4 .IX Item "e" Dump after \s-1SSA\s0 optimizations, to \fI\fIfile\fI.05.ssa\fR and \&\fI\fIfile\fI.06.ussa\fR. ! .Ip "\fBE\fR" 4 .IX Item "E" Dump after the second if conversion, to \fI\fIfile\fI.24.ce2\fR. ! .Ip "\fBf\fR" 4 .IX Item "f" Dump after life analysis, to \fI\fIfile\fI.13.life\fR. ! .Ip "\fBF\fR" 4 .IX Item "F" Dump after purging \f(CW\*(C`ADDRESSOF\*(C'\fR codes, to \fI\fIfile\fI.04.addressof\fR. ! .Ip "\fBg\fR" 4 .IX Item "g" Dump after global register allocation, to \fI\fIfile\fI.19.greg\fR. ! .Ip "\fBo\fR" 4 .IX Item "o" Dump after post-reload \s-1CSE\s0 and other optimizations, to \fI\fIfile\fI.20.postreload\fR. ! .Ip "\fBG\fR" 4 .IX Item "G" Dump after \s-1GCSE\s0, to \fI\fIfile\fI.08.gcse\fR. ! .Ip "\fBi\fR" 4 .IX Item "i" Dump after sibling call optimizations, to \fI\fIfile\fI.01.sibling\fR. ! .Ip "\fBj\fR" 4 .IX Item "j" Dump after the first jump optimization, to \fI\fIfile\fI.02.jump\fR. ! .Ip "\fBJ\fR" 4 .IX Item "J" Dump after the last jump optimization, to \fI\fIfile\fI.27.jump2\fR. ! .Ip "\fBk\fR" 4 .IX Item "k" Dump after conversion from registers to stack, to \fI\fIfile\fI.29.stack\fR. ! .Ip "\fBl\fR" 4 .IX Item "l" Dump after local register allocation, to \fI\fIfile\fI.18.lreg\fR. ! .Ip "\fBL\fR" 4 .IX Item "L" Dump after loop optimization, to \fI\fIfile\fI.09.loop\fR. ! .Ip "\fBM\fR" 4 .IX Item "M" Dump after performing the machine dependent reorganisation pass, to \&\fI\fIfile\fI.28.mach\fR. ! .Ip "\fBn\fR" 4 .IX Item "n" Dump after register renumbering, to \fI\fIfile\fI.23.rnreg\fR. ! .Ip "\fBN\fR" 4 .IX Item "N" Dump after the register move pass, to \fI\fIfile\fI.16.regmove\fR. ! .Ip "\fBr\fR" 4 .IX Item "r" Dump after \s-1RTL\s0 generation, to \fI\fIfile\fI.00.rtl\fR. ! .Ip "\fBR\fR" 4 .IX Item "R" Dump after the second instruction scheduling pass, to \&\fI\fIfile\fI.25.sched2\fR. ! .Ip "\fBs\fR" 4 .IX Item "s" Dump after \s-1CSE\s0 (including the jump optimization that sometimes follows \&\s-1CSE\s0), to \fI\fIfile\fI.03.cse\fR. ! .Ip "\fBS\fR" 4 .IX Item "S" Dump after the first instruction scheduling pass, to \&\fI\fIfile\fI.17.sched\fR. ! .Ip "\fBt\fR" 4 .IX Item "t" Dump after the second \s-1CSE\s0 pass (including the jump optimization that sometimes follows \s-1CSE\s0), to \fI\fIfile\fI.10.cse2\fR. ! .Ip "\fBw\fR" 4 .IX Item "w" Dump after the second flow pass, to \fI\fIfile\fI.21.flow2\fR. ! .Ip "\fBX\fR" 4 .IX Item "X" Dump after dead code elimination, to \fI\fIfile\fI.06.dce\fR. ! .Ip "\fBz\fR" 4 .IX Item "z" Dump after the peephole pass, to \fI\fIfile\fI.22.peephole2\fR. ! .Ip "\fBa\fR" 4 .IX Item "a" Produce all the dumps listed above. ! .Ip "\fBm\fR" 4 .IX Item "m" Print statistics on memory usage, at the end of the run, to standard error. ! .Ip "\fBp\fR" 4 .IX Item "p" Annotate the assembler output with a comment indicating which pattern and alternative was used. The length of each instruction is also printed. ! .Ip "\fBP\fR" 4 .IX Item "P" Dump the \s-1RTL\s0 in the assembler output as a comment before each instruction. Also turns on \fB\-dp\fR annotation. ! .Ip "\fBv\fR" 4 .IX Item "v" For each of the other indicated dump files (except for \&\fI\fIfile\fI.00.rtl\fR), dump a representation of the control flow graph suitable for viewing with \s-1VCG\s0 to \fI\fIfile\fI.\fIpass\fI.vcg\fR. ! .Ip "\fBx\fR" 4 .IX Item "x" Just generate \s-1RTL\s0 for a function instead of compiling it. Usually used with \fBr\fR. ! .Ip "\fBy\fR" 4 .IX Item "y" Dump debugging information during parsing, to standard error. .RE .RS 4 .RE ! .Ip "\fB\-fdump-unnumbered\fR" 4 .IX Item "-fdump-unnumbered" When doing debugging dumps (see \fB\-d\fR option above), suppress instruction numbers and line number note output. This makes it more feasible to use diff on debugging dumps for compiler invocations with different options, in particular with and without \fB\-g\fR. ! .Ip "\fB\-fdump-translation-unit\fR (C and \*(C+ only)" 4 .IX Item "-fdump-translation-unit (C and only)" .PD 0 ! .Ip "\fB\-fdump-translation-unit-\fR\fInumber\fR\fB \fR(C and \*(C+ only)" 4 .IX Item "-fdump-translation-unit-number (C and only)" .PD Dump a representation of the tree structure for the entire translation unit to a file. The file name is made by appending \fI.tu\fR to the source file name. If the \fB-\fR\fInumber\fR form is used, \fInumber\fR controls the details of the dump as described for the \fB\-fdump-tree\fR options. ! .Ip "\fB\-fdump-class-hierarchy\fR (\*(C+ only)" 4 .IX Item "-fdump-class-hierarchy ( only)" .PD 0 ! .Ip "\fB\-fdump-class-hierarchy-\fR\fInumber\fR\fB \fR(\*(C+ only)" 4 .IX Item "-fdump-class-hierarchy-number ( only)" .PD Dump a representation of each class's hierarchy and virtual function --- 2495,2651 ---- the source file name (e.g. \fIfoo.c.00.rtl\fR or \fIfoo.c.01.sibling\fR). Here are the possible letters for use in \fIletters\fR, and their meanings: .RS 4 ! .IP "\fBA\fR" 4 .IX Item "A" Annotate the assembler output with miscellaneous debugging information. ! .IP "\fBb\fR" 4 .IX Item "b" Dump after computing branch probabilities, to \fI\fIfile\fI.11.bp\fR. ! .IP "\fBB\fR" 4 .IX Item "B" Dump after block reordering, to \fI\fIfile\fI.26.bbro\fR. ! .IP "\fBc\fR" 4 .IX Item "c" Dump after instruction combination, to the file \fI\fIfile\fI.14.combine\fR. ! .IP "\fBC\fR" 4 .IX Item "C" Dump after the first if conversion, to the file \fI\fIfile\fI.15.ce\fR. ! .IP "\fBd\fR" 4 .IX Item "d" Dump after delayed branch scheduling, to \fI\fIfile\fI.29.dbr\fR. ! .IP "\fBD\fR" 4 .IX Item "D" Dump all macro definitions, at the end of preprocessing, in addition to normal output. ! .IP "\fBe\fR" 4 .IX Item "e" Dump after \s-1SSA\s0 optimizations, to \fI\fIfile\fI.05.ssa\fR and \&\fI\fIfile\fI.06.ussa\fR. ! .IP "\fBE\fR" 4 .IX Item "E" Dump after the second if conversion, to \fI\fIfile\fI.24.ce2\fR. ! .IP "\fBf\fR" 4 .IX Item "f" Dump after life analysis, to \fI\fIfile\fI.13.life\fR. ! .IP "\fBF\fR" 4 .IX Item "F" Dump after purging \f(CW\*(C`ADDRESSOF\*(C'\fR codes, to \fI\fIfile\fI.04.addressof\fR. ! .IP "\fBg\fR" 4 .IX Item "g" Dump after global register allocation, to \fI\fIfile\fI.19.greg\fR. ! .IP "\fBo\fR" 4 .IX Item "o" Dump after post-reload \s-1CSE\s0 and other optimizations, to \fI\fIfile\fI.20.postreload\fR. ! .IP "\fBG\fR" 4 .IX Item "G" Dump after \s-1GCSE\s0, to \fI\fIfile\fI.08.gcse\fR. ! .IP "\fBi\fR" 4 .IX Item "i" Dump after sibling call optimizations, to \fI\fIfile\fI.01.sibling\fR. ! .IP "\fBj\fR" 4 .IX Item "j" Dump after the first jump optimization, to \fI\fIfile\fI.02.jump\fR. ! .IP "\fBJ\fR" 4 .IX Item "J" Dump after the last jump optimization, to \fI\fIfile\fI.27.jump2\fR. ! .IP "\fBk\fR" 4 .IX Item "k" Dump after conversion from registers to stack, to \fI\fIfile\fI.29.stack\fR. ! .IP "\fBl\fR" 4 .IX Item "l" Dump after local register allocation, to \fI\fIfile\fI.18.lreg\fR. ! .IP "\fBL\fR" 4 .IX Item "L" Dump after loop optimization, to \fI\fIfile\fI.09.loop\fR. ! .IP "\fBM\fR" 4 .IX Item "M" Dump after performing the machine dependent reorganisation pass, to \&\fI\fIfile\fI.28.mach\fR. ! .IP "\fBn\fR" 4 .IX Item "n" Dump after register renumbering, to \fI\fIfile\fI.23.rnreg\fR. ! .IP "\fBN\fR" 4 .IX Item "N" Dump after the register move pass, to \fI\fIfile\fI.16.regmove\fR. ! .IP "\fBr\fR" 4 .IX Item "r" Dump after \s-1RTL\s0 generation, to \fI\fIfile\fI.00.rtl\fR. ! .IP "\fBR\fR" 4 .IX Item "R" Dump after the second instruction scheduling pass, to \&\fI\fIfile\fI.25.sched2\fR. ! .IP "\fBs\fR" 4 .IX Item "s" Dump after \s-1CSE\s0 (including the jump optimization that sometimes follows \&\s-1CSE\s0), to \fI\fIfile\fI.03.cse\fR. ! .IP "\fBS\fR" 4 .IX Item "S" Dump after the first instruction scheduling pass, to \&\fI\fIfile\fI.17.sched\fR. ! .IP "\fBt\fR" 4 .IX Item "t" Dump after the second \s-1CSE\s0 pass (including the jump optimization that sometimes follows \s-1CSE\s0), to \fI\fIfile\fI.10.cse2\fR. ! .IP "\fBw\fR" 4 .IX Item "w" Dump after the second flow pass, to \fI\fIfile\fI.21.flow2\fR. ! .IP "\fBX\fR" 4 .IX Item "X" Dump after dead code elimination, to \fI\fIfile\fI.06.dce\fR. ! .IP "\fBz\fR" 4 .IX Item "z" Dump after the peephole pass, to \fI\fIfile\fI.22.peephole2\fR. ! .IP "\fBa\fR" 4 .IX Item "a" Produce all the dumps listed above. ! .IP "\fBm\fR" 4 .IX Item "m" Print statistics on memory usage, at the end of the run, to standard error. ! .IP "\fBp\fR" 4 .IX Item "p" Annotate the assembler output with a comment indicating which pattern and alternative was used. The length of each instruction is also printed. ! .IP "\fBP\fR" 4 .IX Item "P" Dump the \s-1RTL\s0 in the assembler output as a comment before each instruction. Also turns on \fB\-dp\fR annotation. ! .IP "\fBv\fR" 4 .IX Item "v" For each of the other indicated dump files (except for \&\fI\fIfile\fI.00.rtl\fR), dump a representation of the control flow graph suitable for viewing with \s-1VCG\s0 to \fI\fIfile\fI.\fIpass\fI.vcg\fR. ! .IP "\fBx\fR" 4 .IX Item "x" Just generate \s-1RTL\s0 for a function instead of compiling it. Usually used with \fBr\fR. ! .IP "\fBy\fR" 4 .IX Item "y" Dump debugging information during parsing, to standard error. .RE .RS 4 .RE ! .IP "\fB\-fdump-unnumbered\fR" 4 .IX Item "-fdump-unnumbered" When doing debugging dumps (see \fB\-d\fR option above), suppress instruction numbers and line number note output. This makes it more feasible to use diff on debugging dumps for compiler invocations with different options, in particular with and without \fB\-g\fR. ! .IP "\fB\-fdump-translation-unit\fR (C and \*(C+ only)" 4 .IX Item "-fdump-translation-unit (C and only)" .PD 0 ! .IP "\fB\-fdump-translation-unit-\fR\fInumber\fR\fB \fR(C and \*(C+ only)" 4 .IX Item "-fdump-translation-unit-number (C and only)" .PD Dump a representation of the tree structure for the entire translation unit to a file. The file name is made by appending \fI.tu\fR to the source file name. If the \fB-\fR\fInumber\fR form is used, \fInumber\fR controls the details of the dump as described for the \fB\-fdump-tree\fR options. ! .IP "\fB\-fdump-class-hierarchy\fR (\*(C+ only)" 4 .IX Item "-fdump-class-hierarchy ( only)" .PD 0 ! .IP "\fB\-fdump-class-hierarchy-\fR\fInumber\fR\fB \fR(\*(C+ only)" 4 .IX Item "-fdump-class-hierarchy-number ( only)" .PD Dump a representation of each class's hierarchy and virtual function *************** table layout to a file. The file name i *** 2666,2675 **** to the source file name. If the \fB-\fR\fInumber\fR form is used, \fInumber\fR controls the details of the dump as described for the \fB\-fdump-tree\fR options. ! .Ip "\fB\-fdump-ast-\fR\fIswitch\fR\fB \fR(\*(C+ only)" 4 .IX Item "-fdump-ast-switch ( only)" .PD 0 ! .Ip "\fB\-fdump-ast-\fR\fIswitch\fR\fB-\fR\fInumber\fR\fB \fR(\*(C+ only)" 4 .IX Item "-fdump-ast-switch-number ( only)" .PD Control the dumping at various stages of processing the abstract syntax --- 2653,2662 ---- to the source file name. If the \fB-\fR\fInumber\fR form is used, \fInumber\fR controls the details of the dump as described for the \fB\-fdump-tree\fR options. ! .IP "\fB\-fdump-ast-\fR\fIswitch\fR\fB \fR(\*(C+ only)" 4 .IX Item "-fdump-ast-switch ( only)" .PD 0 ! .IP "\fB\-fdump-ast-\fR\fIswitch\fR\fB-\fR\fInumber\fR\fB \fR(\*(C+ only)" 4 .IX Item "-fdump-ast-switch-number ( only)" .PD Control the dumping at various stages of processing the abstract syntax *************** used, \fInumber\fR is a bit mask which c *** 2679,2689 **** dump. The following bits are meaningful (these are not set symbolically, as the primary function of these dumps is for debugging gcc itself): .RS 4 ! .Ip "\fBbit0 (1)\fR" 4 .IX Item "bit0 (1)" Print the address of each node. Usually this is not meaningful as it changes according to the environment and source file. ! .Ip "\fBbit1 (2)\fR" 4 .IX Item "bit1 (2)" Inhibit dumping of members of a scope or body of a function, unless they are reachable by some other path. --- 2666,2676 ---- dump. The following bits are meaningful (these are not set symbolically, as the primary function of these dumps is for debugging gcc itself): .RS 4 ! .IP "\fBbit0 (1)\fR" 4 .IX Item "bit0 (1)" Print the address of each node. Usually this is not meaningful as it changes according to the environment and source file. ! .IP "\fBbit1 (2)\fR" 4 .IX Item "bit1 (2)" Inhibit dumping of members of a scope or body of a function, unless they are reachable by some other path. *************** are reachable by some other path. *** 2693,2715 **** The following tree dumps are possible: .RS 4 .RE ! .Ip "\fBoriginal\fR" 4 .IX Item "original" Dump before any tree based optimization, to \fI\fIfile\fI.original\fR. ! .Ip "\fBoptimized\fR" 4 .IX Item "optimized" Dump after all tree based optimization, to \fI\fIfile\fI.optimized\fR. .RE .RS 4 .RE ! .Ip "\fB\-fpretend-float\fR" 4 .IX Item "-fpretend-float" When running a cross-compiler, pretend that the target machine uses the same floating point format as the host machine. This causes incorrect output of the actual floating constants, but the actual instruction sequence will probably be the same as \s-1GCC\s0 would make when running on the target machine. ! .Ip "\fB\-save-temps\fR" 4 .IX Item "-save-temps" Store the usual ``temporary'' intermediate files permanently; place them in the current directory and name them based on the source file. Thus, --- 2680,2702 ---- The following tree dumps are possible: .RS 4 .RE ! .IP "\fBoriginal\fR" 4 .IX Item "original" Dump before any tree based optimization, to \fI\fIfile\fI.original\fR. ! .IP "\fBoptimized\fR" 4 .IX Item "optimized" Dump after all tree based optimization, to \fI\fIfile\fI.optimized\fR. .RE .RS 4 .RE ! .IP "\fB\-fpretend-float\fR" 4 .IX Item "-fpretend-float" When running a cross-compiler, pretend that the target machine uses the same floating point format as the host machine. This causes incorrect output of the actual floating constants, but the actual instruction sequence will probably be the same as \s-1GCC\s0 would make when running on the target machine. ! .IP "\fB\-save-temps\fR" 4 .IX Item "-save-temps" Store the usual ``temporary'' intermediate files permanently; place them in the current directory and name them based on the source file. Thus, *************** compiling \fIfoo.c\fR with \fB\-c \-save *** 2717,2723 **** \&\fIfoo.i\fR and \fIfoo.s\fR, as well as \fIfoo.o\fR. This creates a preprocessed \fIfoo.i\fR output file even though the compiler now normally uses an integrated preprocessor. ! .Ip "\fB\-time\fR" 4 .IX Item "-time" Report the \s-1CPU\s0 time taken by each subprocess in the compilation sequence. For C source files, this is the compiler proper and assembler --- 2704,2710 ---- \&\fIfoo.i\fR and \fIfoo.s\fR, as well as \fIfoo.o\fR. This creates a preprocessed \fIfoo.i\fR output file even though the compiler now normally uses an integrated preprocessor. ! .IP "\fB\-time\fR" 4 .IX Item "-time" Report the \s-1CPU\s0 time taken by each subprocess in the compilation sequence. For C source files, this is the compiler proper and assembler *************** The first number on each line is the ``u *** 2731,2758 **** executing the program itself. The second number is ``system time,'' time spent executing operating system routines on behalf of the program. Both numbers are in seconds. ! .Ip "\fB\-print-file-name=\fR\fIlibrary\fR" 4 .IX Item "-print-file-name=library" Print the full absolute name of the library file \fIlibrary\fR that would be used when linking\-\-\-and don't do anything else. With this option, \s-1GCC\s0 does not compile or link anything; it just prints the file name. ! .Ip "\fB\-print-multi-directory\fR" 4 .IX Item "-print-multi-directory" Print the directory name corresponding to the multilib selected by any other switches present in the command line. This directory is supposed to exist in \fB\s-1GCC_EXEC_PREFIX\s0\fR. ! .Ip "\fB\-print-multi-lib\fR" 4 .IX Item "-print-multi-lib" Print the mapping from multilib directory names to compiler switches that enable them. The directory name is separated from the switches by \&\fB;\fR, and each switch starts with an \fB@} instead of the \&\f(CB@samp\fB{-\fR, without spaces between multiple switches. This is supposed to ease shell-processing. ! .Ip "\fB\-print-prog-name=\fR\fIprogram\fR" 4 .IX Item "-print-prog-name=program" Like \fB\-print-file-name\fR, but searches for a program such as \fBcpp\fR. ! .Ip "\fB\-print-libgcc-file-name\fR" 4 .IX Item "-print-libgcc-file-name" Same as \fB\-print-file-name=libgcc.a\fR. .Sp --- 2718,2745 ---- executing the program itself. The second number is ``system time,'' time spent executing operating system routines on behalf of the program. Both numbers are in seconds. ! .IP "\fB\-print-file-name=\fR\fIlibrary\fR" 4 .IX Item "-print-file-name=library" Print the full absolute name of the library file \fIlibrary\fR that would be used when linking\-\-\-and don't do anything else. With this option, \s-1GCC\s0 does not compile or link anything; it just prints the file name. ! .IP "\fB\-print-multi-directory\fR" 4 .IX Item "-print-multi-directory" Print the directory name corresponding to the multilib selected by any other switches present in the command line. This directory is supposed to exist in \fB\s-1GCC_EXEC_PREFIX\s0\fR. ! .IP "\fB\-print-multi-lib\fR" 4 .IX Item "-print-multi-lib" Print the mapping from multilib directory names to compiler switches that enable them. The directory name is separated from the switches by \&\fB;\fR, and each switch starts with an \fB@} instead of the \&\f(CB@samp\fB{-\fR, without spaces between multiple switches. This is supposed to ease shell-processing. ! .IP "\fB\-print-prog-name=\fR\fIprogram\fR" 4 .IX Item "-print-prog-name=program" Like \fB\-print-file-name\fR, but searches for a program such as \fBcpp\fR. ! .IP "\fB\-print-libgcc-file-name\fR" 4 .IX Item "-print-libgcc-file-name" Same as \fB\-print-file-name=libgcc.a\fR. .Sp *************** but you do want to link with \fIlibgcc.a *** 2762,2768 **** .Vb 1 \& gcc -nostdlib I... `gcc -print-libgcc-file-name` .Ve ! .Ip "\fB\-print-search-dirs\fR" 4 .IX Item "-print-search-dirs" Print the name of the configured installation directory and a list of program and library directories gcc will search\-\-\-and don't do anything else. --- 2749,2755 ---- .Vb 1 \& gcc -nostdlib I... `gcc -print-libgcc-file-name` .Ve ! .IP "\fB\-print-search-dirs\fR" 4 .IX Item "-print-search-dirs" Print the name of the configured installation directory and a list of program and library directories gcc will search\-\-\-and don't do anything else. *************** To resolve this you either need to put \ *** 2773,2797 **** components where gcc expects to find them, or you can set the environment variable \fB\s-1GCC_EXEC_PREFIX\s0\fR to the directory where you installed them. Don't forget the trailing '/'. ! .Ip "\fB\-dumpmachine\fR" 4 .IX Item "-dumpmachine" Print the compiler's target machine (for example, \&\fBi686\-pc-linux-gnu\fR)\-\-\-and don't do anything else. ! .Ip "\fB\-dumpversion\fR" 4 .IX Item "-dumpversion" Print the compiler version (for example, \fB3.0\fR)\-\-\-and don't do anything else. ! .Ip "\fB\-dumpspecs\fR" 4 .IX Item "-dumpspecs" Print the compiler's built-in specs\-\-\-and don't do anything else. (This is used when \s-1GCC\s0 itself is being built.) .Sh "Options That Control Optimization" .IX Subsection "Options That Control Optimization" These options control various sorts of optimizations: ! .Ip "\fB\-O\fR" 4 .IX Item "-O" .PD 0 ! .Ip "\fB\-O1\fR" 4 .IX Item "-O1" .PD Optimize. Optimizing compilation takes somewhat more time, and a lot --- 2760,2784 ---- components where gcc expects to find them, or you can set the environment variable \fB\s-1GCC_EXEC_PREFIX\s0\fR to the directory where you installed them. Don't forget the trailing '/'. ! .IP "\fB\-dumpmachine\fR" 4 .IX Item "-dumpmachine" Print the compiler's target machine (for example, \&\fBi686\-pc-linux-gnu\fR)\-\-\-and don't do anything else. ! .IP "\fB\-dumpversion\fR" 4 .IX Item "-dumpversion" Print the compiler version (for example, \fB3.0\fR)\-\-\-and don't do anything else. ! .IP "\fB\-dumpspecs\fR" 4 .IX Item "-dumpspecs" Print the compiler's built-in specs\-\-\-and don't do anything else. (This is used when \s-1GCC\s0 itself is being built.) .Sh "Options That Control Optimization" .IX Subsection "Options That Control Optimization" These options control various sorts of optimizations: ! .IP "\fB\-O\fR" 4 .IX Item "-O" .PD 0 ! .IP "\fB\-O1\fR" 4 .IX Item "-O1" .PD Optimize. Optimizing compilation takes somewhat more time, and a lot *************** and \fB\-fdefer-pop\fR on all machines. *** 2817,2823 **** \&\fB\-fomit-frame-pointer\fR on machines that can support debugging even without a frame pointer. On some machines the compiler also turns on other flags. ! .Ip "\fB\-O2\fR" 4 .IX Item "-O2" Optimize even more. \s-1GCC\s0 performs nearly all supported optimizations that do not involve a space-speed tradeoff. The compiler does not --- 2804,2810 ---- \&\fB\-fomit-frame-pointer\fR on machines that can support debugging even without a frame pointer. On some machines the compiler also turns on other flags. ! .IP "\fB\-O2\fR" 4 .IX Item "-O2" Optimize even more. \s-1GCC\s0 performs nearly all supported optimizations that do not involve a space-speed tradeoff. The compiler does not *************** and the performance of the generated cod *** 2829,2843 **** function inlining, and register renaming. It also turns on the \&\fB\-fforce-mem\fR option on all machines and frame pointer elimination on machines where doing so does not interfere with debugging. ! .Ip "\fB\-O3\fR" 4 .IX Item "-O3" Optimize yet more. \fB\-O3\fR turns on all optimizations specified by \&\fB\-O2\fR and also turns on the \fB\-finline-functions\fR and \&\fB\-frename-registers\fR options. ! .Ip "\fB\-O0\fR" 4 .IX Item "-O0" Do not optimize. ! .Ip "\fB\-Os\fR" 4 .IX Item "-Os" Optimize for size. \fB\-Os\fR enables all \fB\-O2\fR optimizations that do not typically increase code size. It also performs further --- 2816,2833 ---- function inlining, and register renaming. It also turns on the \&\fB\-fforce-mem\fR option on all machines and frame pointer elimination on machines where doing so does not interfere with debugging. ! .Sp ! Please note the warning under \fB\-fgcse\fR about ! invoking \fB\-O2\fR on programs that use computed gotos. ! .IP "\fB\-O3\fR" 4 .IX Item "-O3" Optimize yet more. \fB\-O3\fR turns on all optimizations specified by \&\fB\-O2\fR and also turns on the \fB\-finline-functions\fR and \&\fB\-frename-registers\fR options. ! .IP "\fB\-O0\fR" 4 .IX Item "-O0" Do not optimize. ! .IP "\fB\-Os\fR" 4 .IX Item "-Os" Optimize for size. \fB\-Os\fR enables all \fB\-O2\fR optimizations that do not typically increase code size. It also performs further *************** form of \fB\-ffoo\fR would be \fB\-fno-f *** 2852,2858 **** only one of the forms is listed\-\-\-the one which is not the default. You can figure out the other form by either removing \fBno-\fR or adding it. ! .Ip "\fB\-ffloat-store\fR" 4 .IX Item "-ffloat-store" Do not store floating point variables in registers, and inhibit other options that might change whether a floating point value is taken from a --- 2842,2848 ---- only one of the forms is listed\-\-\-the one which is not the default. You can figure out the other form by either removing \fBno-\fR or adding it. ! .IP "\fB\-ffloat-store\fR" 4 .IX Item "-ffloat-store" Do not store floating point variables in registers, and inhibit other options that might change whether a floating point value is taken from a *************** x86 architecture. For most programs, th *** 2865,2896 **** good, but a few programs rely on the precise definition of \s-1IEEE\s0 floating point. Use \fB\-ffloat-store\fR for such programs, after modifying them to store all pertinent intermediate computations into variables. ! .Ip "\fB\-fno-default-inline\fR" 4 .IX Item "-fno-default-inline" Do not make member functions inline by default merely because they are defined inside the class scope (\*(C+ only). Otherwise, when you specify \&\fB\-O\fR, member functions defined inside class scope are compiled inline by default; i.e., you don't need to add \fBinline\fR in front of the member function name. ! .Ip "\fB\-fno-defer-pop\fR" 4 .IX Item "-fno-defer-pop" Always pop the arguments to each function call as soon as that function returns. For machines which must pop arguments after a function call, the compiler normally lets arguments accumulate on the stack for several function calls and pops them all at once. ! .Ip "\fB\-fforce-mem\fR" 4 .IX Item "-fforce-mem" Force memory operands to be copied into registers before doing arithmetic on them. This produces better code by making all memory references potential common subexpressions. When they are not common subexpressions, instruction combination should eliminate the separate register-load. The \fB\-O2\fR option turns on this option. ! .Ip "\fB\-fforce-addr\fR" 4 .IX Item "-fforce-addr" Force memory address constants to be copied into registers before doing arithmetic on them. This may produce better code just as \&\fB\-fforce-mem\fR may. ! .Ip "\fB\-fomit-frame-pointer\fR" 4 .IX Item "-fomit-frame-pointer" Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and --- 2855,2886 ---- good, but a few programs rely on the precise definition of \s-1IEEE\s0 floating point. Use \fB\-ffloat-store\fR for such programs, after modifying them to store all pertinent intermediate computations into variables. ! .IP "\fB\-fno-default-inline\fR" 4 .IX Item "-fno-default-inline" Do not make member functions inline by default merely because they are defined inside the class scope (\*(C+ only). Otherwise, when you specify \&\fB\-O\fR, member functions defined inside class scope are compiled inline by default; i.e., you don't need to add \fBinline\fR in front of the member function name. ! .IP "\fB\-fno-defer-pop\fR" 4 .IX Item "-fno-defer-pop" Always pop the arguments to each function call as soon as that function returns. For machines which must pop arguments after a function call, the compiler normally lets arguments accumulate on the stack for several function calls and pops them all at once. ! .IP "\fB\-fforce-mem\fR" 4 .IX Item "-fforce-mem" Force memory operands to be copied into registers before doing arithmetic on them. This produces better code by making all memory references potential common subexpressions. When they are not common subexpressions, instruction combination should eliminate the separate register-load. The \fB\-O2\fR option turns on this option. ! .IP "\fB\-fforce-addr\fR" 4 .IX Item "-fforce-addr" Force memory address constants to be copied into registers before doing arithmetic on them. This may produce better code just as \&\fB\-fforce-mem\fR may. ! .IP "\fB\-fomit-frame-pointer\fR" 4 .IX Item "-fomit-frame-pointer" Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and *************** the standard calling sequence automatica *** 2903,2921 **** and nothing is saved by pretending it doesn't exist. The machine-description macro \f(CW\*(C`FRAME_POINTER_REQUIRED\*(C'\fR controls whether a target machine supports this flag. ! .Ip "\fB\-foptimize-sibling-calls\fR" 4 .IX Item "-foptimize-sibling-calls" Optimize sibling and tail recursive calls. ! .Ip "\fB\-ftrapv\fR" 4 .IX Item "-ftrapv" This option generates traps for signed overflow on addition, subtraction, multiplication operations. ! .Ip "\fB\-fno-inline\fR" 4 .IX Item "-fno-inline" Don't pay attention to the \f(CW\*(C`inline\*(C'\fR keyword. Normally this option is used to keep the compiler from expanding any functions inline. Note that if you are not optimizing, no functions can be expanded inline. ! .Ip "\fB\-finline-functions\fR" 4 .IX Item "-finline-functions" Integrate all simple functions into their callers. The compiler heuristically decides which functions are simple enough to be worth --- 2893,2911 ---- and nothing is saved by pretending it doesn't exist. The machine-description macro \f(CW\*(C`FRAME_POINTER_REQUIRED\*(C'\fR controls whether a target machine supports this flag. ! .IP "\fB\-foptimize-sibling-calls\fR" 4 .IX Item "-foptimize-sibling-calls" Optimize sibling and tail recursive calls. ! .IP "\fB\-ftrapv\fR" 4 .IX Item "-ftrapv" This option generates traps for signed overflow on addition, subtraction, multiplication operations. ! .IP "\fB\-fno-inline\fR" 4 .IX Item "-fno-inline" Don't pay attention to the \f(CW\*(C`inline\*(C'\fR keyword. Normally this option is used to keep the compiler from expanding any functions inline. Note that if you are not optimizing, no functions can be expanded inline. ! .IP "\fB\-finline-functions\fR" 4 .IX Item "-finline-functions" Integrate all simple functions into their callers. The compiler heuristically decides which functions are simple enough to be worth *************** integrating in this way. *** 2924,2937 **** If all calls to a given function are integrated, and the function is declared \f(CW\*(C`static\*(C'\fR, then the function is normally not output as assembler code in its own right. ! .Ip "\fB\-finline-limit=\fR\fIn\fR" 4 .IX Item "-finline-limit=n" By default, gcc limits the size of functions that can be inlined. This flag allows the control of this limit for functions that are explicitly marked as inline (ie marked with the inline keyword or defined within the class definition in c++). \fIn\fR is the size of functions that can be inlined in number of pseudo instructions (not counting parameter handling). The default ! value of \fIn\fR is 10000. Increasing this value can result in more inlined code at the cost of compilation time and memory consumption. Decreasing usually makes the compilation faster and less code will be inlined (which presumably means slower programs). This option is particularly useful for programs that --- 2914,2928 ---- If all calls to a given function are integrated, and the function is declared \f(CW\*(C`static\*(C'\fR, then the function is normally not output as assembler code in its own right. ! .IP "\fB\-finline-limit=\fR\fIn\fR" 4 .IX Item "-finline-limit=n" By default, gcc limits the size of functions that can be inlined. This flag allows the control of this limit for functions that are explicitly marked as inline (ie marked with the inline keyword or defined within the class definition in c++). \fIn\fR is the size of functions that can be inlined in number of pseudo instructions (not counting parameter handling). The default ! value of \fIn\fR is 600. ! Increasing this value can result in more inlined code at the cost of compilation time and memory consumption. Decreasing usually makes the compilation faster and less code will be inlined (which presumably means slower programs). This option is particularly useful for programs that *************** use inlining heavily such as those based *** 2941,2953 **** abstract measurement of function's size. In no way, it represents a count of assembly instructions and as such its exact meaning might change from one release to an another. ! .Ip "\fB\-fkeep-inline-functions\fR" 4 .IX Item "-fkeep-inline-functions" Even if all calls to a given function are integrated, and the function is declared \f(CW\*(C`static\*(C'\fR, nevertheless output a separate run-time callable version of the function. This switch does not affect \&\f(CW\*(C`extern inline\*(C'\fR functions. ! .Ip "\fB\-fkeep-static-consts\fR" 4 .IX Item "-fkeep-static-consts" Emit variables declared \f(CW\*(C`static const\*(C'\fR when optimization isn't turned on, even if the variables aren't referenced. --- 2932,2944 ---- abstract measurement of function's size. In no way, it represents a count of assembly instructions and as such its exact meaning might change from one release to an another. ! .IP "\fB\-fkeep-inline-functions\fR" 4 .IX Item "-fkeep-inline-functions" Even if all calls to a given function are integrated, and the function is declared \f(CW\*(C`static\*(C'\fR, nevertheless output a separate run-time callable version of the function. This switch does not affect \&\f(CW\*(C`extern inline\*(C'\fR functions. ! .IP "\fB\-fkeep-static-consts\fR" 4 .IX Item "-fkeep-static-consts" Emit variables declared \f(CW\*(C`static const\*(C'\fR when optimization isn't turned on, even if the variables aren't referenced. *************** on, even if the variables aren't referen *** 2955,2961 **** \&\s-1GCC\s0 enables this option by default. If you want to force the compiler to check if the variable was referenced, regardless of whether or not optimization is turned on, use the \fB\-fno-keep-static-consts\fR option. ! .Ip "\fB\-fno-function-cse\fR" 4 .IX Item "-fno-function-cse" Do not put function addresses in registers; make each instruction that calls a constant function contain the function's address explicitly. --- 2946,2952 ---- \&\s-1GCC\s0 enables this option by default. If you want to force the compiler to check if the variable was referenced, regardless of whether or not optimization is turned on, use the \fB\-fno-keep-static-consts\fR option. ! .IP "\fB\-fno-function-cse\fR" 4 .IX Item "-fno-function-cse" Do not put function addresses in registers; make each instruction that calls a constant function contain the function's address explicitly. *************** calls a constant function contain the fu *** 2963,2969 **** This option results in less efficient code, but some strange hacks that alter the assembler output may be confused by the optimizations performed when this option is not used. ! .Ip "\fB\-ffast-math\fR" 4 .IX Item "-ffast-math" This option allows \s-1GCC\s0 to violate some \s-1ISO\s0 or \s-1IEEE\s0 rules and/or specifications in the interest of optimizing code for speed. For --- 2954,2960 ---- This option results in less efficient code, but some strange hacks that alter the assembler output may be confused by the optimizations performed when this option is not used. ! .IP "\fB\-ffast-math\fR" 4 .IX Item "-ffast-math" This option allows \s-1GCC\s0 to violate some \s-1ISO\s0 or \s-1IEEE\s0 rules and/or specifications in the interest of optimizing code for speed. For *************** This option should never be turned on by *** 2977,2983 **** it can result in incorrect output for programs which depend on an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for math functions. ! .Ip "\fB\-fno-math-errno\fR" 4 .IX Item "-fno-math-errno" Do not set \s-1ERRNO\s0 after calling math functions that are executed with a single instruction, e.g., sqrt. A program that relies on --- 2968,2974 ---- it can result in incorrect output for programs which depend on an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for math functions. ! .IP "\fB\-fno-math-errno\fR" 4 .IX Item "-fno-math-errno" Do not set \s-1ERRNO\s0 after calling math functions that are executed with a single instruction, e.g., sqrt. A program that relies on *************** but specific machines may handle it diff *** 2995,3050 **** .PP You can use the following flags in the rare cases when ``fine-tuning'' of optimizations to be performed is desired. ! .Ip "\fB\-fstrength-reduce\fR" 4 .IX Item "-fstrength-reduce" Perform the optimizations of loop strength reduction and elimination of iteration variables. ! .Ip "\fB\-fthread-jumps\fR" 4 .IX Item "-fthread-jumps" Perform optimizations where we check to see if a jump branches to a location where another comparison subsumed by the first is found. If so, the first branch is redirected to either the destination of the second branch or a point immediately following it, depending on whether the condition is known to be true or false. ! .Ip "\fB\-fcse-follow-jumps\fR" 4 .IX Item "-fcse-follow-jumps" In common subexpression elimination, scan through jump instructions when the target of the jump is not reached by any other path. For example, when \s-1CSE\s0 encounters an \f(CW\*(C`if\*(C'\fR statement with an \&\f(CW\*(C`else\*(C'\fR clause, \s-1CSE\s0 will follow the jump when the condition tested is false. ! .Ip "\fB\-fcse-skip-blocks\fR" 4 .IX Item "-fcse-skip-blocks" This is similar to \fB\-fcse-follow-jumps\fR, but causes \s-1CSE\s0 to follow jumps which conditionally skip over blocks. When \s-1CSE\s0 encounters a simple \f(CW\*(C`if\*(C'\fR statement with no else clause, \&\fB\-fcse-skip-blocks\fR causes \s-1CSE\s0 to follow the jump around the body of the \f(CW\*(C`if\*(C'\fR. ! .Ip "\fB\-frerun-cse-after-loop\fR" 4 .IX Item "-frerun-cse-after-loop" Re-run common subexpression elimination after loop optimizations has been performed. ! .Ip "\fB\-frerun-loop-opt\fR" 4 .IX Item "-frerun-loop-opt" Run the loop optimizer twice. ! .Ip "\fB\-fgcse\fR" 4 .IX Item "-fgcse" Perform a global common subexpression elimination pass. This pass also performs global constant and copy propagation. ! .Ip "\fB\-fdelete-null-pointer-checks\fR" 4 .IX Item "-fdelete-null-pointer-checks" Use global dataflow analysis to identify and eliminate useless null pointer checks. Programs which rely on \s-1NULL\s0 pointer dereferences \fInot\fR halting the program may not work properly with this option. Use \&\fB\-fno-delete-null-pointer-checks\fR to disable this optimizing for programs which depend on that behavior. ! .Ip "\fB\-fexpensive-optimizations\fR" 4 .IX Item "-fexpensive-optimizations" Perform a number of minor optimizations that are relatively expensive. ! .Ip "\fB\-foptimize-register-move\fR" 4 .IX Item "-foptimize-register-move" .PD 0 ! .Ip "\fB\-fregmove\fR" 4 .IX Item "-fregmove" .PD Attempt to reassign register numbers in move instructions and as --- 2986,3046 ---- .PP You can use the following flags in the rare cases when ``fine-tuning'' of optimizations to be performed is desired. ! .IP "\fB\-fstrength-reduce\fR" 4 .IX Item "-fstrength-reduce" Perform the optimizations of loop strength reduction and elimination of iteration variables. ! .IP "\fB\-fthread-jumps\fR" 4 .IX Item "-fthread-jumps" Perform optimizations where we check to see if a jump branches to a location where another comparison subsumed by the first is found. If so, the first branch is redirected to either the destination of the second branch or a point immediately following it, depending on whether the condition is known to be true or false. ! .IP "\fB\-fcse-follow-jumps\fR" 4 .IX Item "-fcse-follow-jumps" In common subexpression elimination, scan through jump instructions when the target of the jump is not reached by any other path. For example, when \s-1CSE\s0 encounters an \f(CW\*(C`if\*(C'\fR statement with an \&\f(CW\*(C`else\*(C'\fR clause, \s-1CSE\s0 will follow the jump when the condition tested is false. ! .IP "\fB\-fcse-skip-blocks\fR" 4 .IX Item "-fcse-skip-blocks" This is similar to \fB\-fcse-follow-jumps\fR, but causes \s-1CSE\s0 to follow jumps which conditionally skip over blocks. When \s-1CSE\s0 encounters a simple \f(CW\*(C`if\*(C'\fR statement with no else clause, \&\fB\-fcse-skip-blocks\fR causes \s-1CSE\s0 to follow the jump around the body of the \f(CW\*(C`if\*(C'\fR. ! .IP "\fB\-frerun-cse-after-loop\fR" 4 .IX Item "-frerun-cse-after-loop" Re-run common subexpression elimination after loop optimizations has been performed. ! .IP "\fB\-frerun-loop-opt\fR" 4 .IX Item "-frerun-loop-opt" Run the loop optimizer twice. ! .IP "\fB\-fgcse\fR" 4 .IX Item "-fgcse" Perform a global common subexpression elimination pass. This pass also performs global constant and copy propagation. ! .Sp ! \&\fINote:\fR When compiling a program using computed gotos, a \s-1GCC\s0 ! extension, you may get better runtime performance if you disable ! the global common subexpression elmination pass by adding ! \&\fB\-fno-gcse\fR to the command line. ! .IP "\fB\-fdelete-null-pointer-checks\fR" 4 .IX Item "-fdelete-null-pointer-checks" Use global dataflow analysis to identify and eliminate useless null pointer checks. Programs which rely on \s-1NULL\s0 pointer dereferences \fInot\fR halting the program may not work properly with this option. Use \&\fB\-fno-delete-null-pointer-checks\fR to disable this optimizing for programs which depend on that behavior. ! .IP "\fB\-fexpensive-optimizations\fR" 4 .IX Item "-fexpensive-optimizations" Perform a number of minor optimizations that are relatively expensive. ! .IP "\fB\-foptimize-register-move\fR" 4 .IX Item "-foptimize-register-move" .PD 0 ! .IP "\fB\-fregmove\fR" 4 .IX Item "-fregmove" .PD Attempt to reassign register numbers in move instructions and as *************** or higher. *** 3055,3082 **** .Sp Note \fB\-fregmove\fR and \fB\-foptimize-register-move\fR are the same optimization. ! .Ip "\fB\-fdelayed-branch\fR" 4 .IX Item "-fdelayed-branch" If supported for the target machine, attempt to reorder instructions to exploit instruction slots available after delayed branch instructions. ! .Ip "\fB\-fschedule-insns\fR" 4 .IX Item "-fschedule-insns" If supported for the target machine, attempt to reorder instructions to eliminate execution stalls due to required data being unavailable. This helps machines that have slow floating point or memory load instructions by allowing other instructions to be issued until the result of the load or floating point instruction is required. ! .Ip "\fB\-fschedule-insns2\fR" 4 .IX Item "-fschedule-insns2" Similar to \fB\-fschedule-insns\fR, but requests an additional pass of instruction scheduling after register allocation has been done. This is especially useful on machines with a relatively small number of registers and where memory load instructions take more than one cycle. ! .Ip "\fB\-ffunction-sections\fR" 4 .IX Item "-ffunction-sections" .PD 0 ! .Ip "\fB\-fdata-sections\fR" 4 .IX Item "-fdata-sections" .PD Place each function or data item into its own section in the output --- 3051,3078 ---- .Sp Note \fB\-fregmove\fR and \fB\-foptimize-register-move\fR are the same optimization. ! .IP "\fB\-fdelayed-branch\fR" 4 .IX Item "-fdelayed-branch" If supported for the target machine, attempt to reorder instructions to exploit instruction slots available after delayed branch instructions. ! .IP "\fB\-fschedule-insns\fR" 4 .IX Item "-fschedule-insns" If supported for the target machine, attempt to reorder instructions to eliminate execution stalls due to required data being unavailable. This helps machines that have slow floating point or memory load instructions by allowing other instructions to be issued until the result of the load or floating point instruction is required. ! .IP "\fB\-fschedule-insns2\fR" 4 .IX Item "-fschedule-insns2" Similar to \fB\-fschedule-insns\fR, but requests an additional pass of instruction scheduling after register allocation has been done. This is especially useful on machines with a relatively small number of registers and where memory load instructions take more than one cycle. ! .IP "\fB\-ffunction-sections\fR" 4 .IX Item "-ffunction-sections" .PD 0 ! .IP "\fB\-fdata-sections\fR" 4 .IX Item "-fdata-sections" .PD Place each function or data item into its own section in the output *************** create larger object and executable file *** 3096,3102 **** You will not be able to use \f(CW\*(C`gprof\*(C'\fR on all systems if you specify this option and you may have problems with debugging if you specify both this option and \fB\-g\fR. ! .Ip "\fB\-fcaller-saves\fR" 4 .IX Item "-fcaller-saves" Enable values to be allocated in registers that will be clobbered by function calls, by emitting extra instructions to save and restore the --- 3092,3098 ---- You will not be able to use \f(CW\*(C`gprof\*(C'\fR on all systems if you specify this option and you may have problems with debugging if you specify both this option and \fB\-g\fR. ! .IP "\fB\-fcaller-saves\fR" 4 .IX Item "-fcaller-saves" Enable values to be allocated in registers that will be clobbered by function calls, by emitting extra instructions to save and restore the *************** those which have no call-preserved regis *** 3108,3129 **** .Sp For all machines, optimization level 2 and higher enables this flag by default. ! .Ip "\fB\-funroll-loops\fR" 4 .IX Item "-funroll-loops" Perform the optimization of loop unrolling. This is only done for loops whose number of iterations can be determined at compile time or run time. \&\fB\-funroll-loops\fR implies both \fB\-fstrength-reduce\fR and \&\fB\-frerun-cse-after-loop\fR. ! .Ip "\fB\-funroll-all-loops\fR" 4 .IX Item "-funroll-all-loops" Perform the optimization of loop unrolling. This is done for all loops and usually makes programs run more slowly. \fB\-funroll-all-loops\fR implies \fB\-fstrength-reduce\fR as well as \fB\-frerun-cse-after-loop\fR. ! .Ip "\fB\-fmove-all-movables\fR" 4 .IX Item "-fmove-all-movables" Forces all invariant computations in loops to be moved outside the loop. ! .Ip "\fB\-freduce-all-givs\fR" 4 .IX Item "-freduce-all-givs" Forces all general-induction variables in loops to be strength-reduced. --- 3104,3125 ---- .Sp For all machines, optimization level 2 and higher enables this flag by default. ! .IP "\fB\-funroll-loops\fR" 4 .IX Item "-funroll-loops" Perform the optimization of loop unrolling. This is only done for loops whose number of iterations can be determined at compile time or run time. \&\fB\-funroll-loops\fR implies both \fB\-fstrength-reduce\fR and \&\fB\-frerun-cse-after-loop\fR. ! .IP "\fB\-funroll-all-loops\fR" 4 .IX Item "-funroll-all-loops" Perform the optimization of loop unrolling. This is done for all loops and usually makes programs run more slowly. \fB\-funroll-all-loops\fR implies \fB\-fstrength-reduce\fR as well as \fB\-frerun-cse-after-loop\fR. ! .IP "\fB\-fmove-all-movables\fR" 4 .IX Item "-fmove-all-movables" Forces all invariant computations in loops to be moved outside the loop. ! .IP "\fB\-freduce-all-givs\fR" 4 .IX Item "-freduce-all-givs" Forces all general-induction variables in loops to be strength-reduced. *************** know how use of these options affects *** 3144,3165 **** the performance of your production code. We're very interested in code that runs \fIslower\fR when these options are \fIenabled\fR. ! .Ip "\fB\-fno-peephole\fR" 4 .IX Item "-fno-peephole" .PD 0 ! .Ip "\fB\-fno-peephole2\fR" 4 .IX Item "-fno-peephole2" .PD Disable any machine-specific peephole optimizations. The difference between \fB\-fno-peephole\fR and \fB\-fno-peephole2\fR is in how they are implemented in the compiler; some targets use one, some use the other, a few use both. ! .Ip "\fB\-fbranch-probabilities\fR" 4 .IX Item "-fbranch-probabilities" After running a program compiled with \fB\-fprofile-arcs\fR, you can compile it a second time using \&\fB\-fbranch-probabilities\fR, to improve optimizations based on guessing the path a branch might take. ! .Ip "\fB\-fno-guess-branch-probability\fR" 4 .IX Item "-fno-guess-branch-probability" Sometimes gcc will opt to guess branch probabilities when none are available from either profile directed feedback (\fB\-fprofile-arcs\fR) --- 3140,3161 ---- the performance of your production code. We're very interested in code that runs \fIslower\fR when these options are \fIenabled\fR. ! .IP "\fB\-fno-peephole\fR" 4 .IX Item "-fno-peephole" .PD 0 ! .IP "\fB\-fno-peephole2\fR" 4 .IX Item "-fno-peephole2" .PD Disable any machine-specific peephole optimizations. The difference between \fB\-fno-peephole\fR and \fB\-fno-peephole2\fR is in how they are implemented in the compiler; some targets use one, some use the other, a few use both. ! .IP "\fB\-fbranch-probabilities\fR" 4 .IX Item "-fbranch-probabilities" After running a program compiled with \fB\-fprofile-arcs\fR, you can compile it a second time using \&\fB\-fbranch-probabilities\fR, to improve optimizations based on guessing the path a branch might take. ! .IP "\fB\-fno-guess-branch-probability\fR" 4 .IX Item "-fno-guess-branch-probability" Sometimes gcc will opt to guess branch probabilities when none are available from either profile directed feedback (\fB\-fprofile-arcs\fR) *************** want different runs of the compiler to p *** 3168,3174 **** behavior; minimizing non-determinism is of paramount import. This switch allows users to reduce non-determinism, possibly at the expense of inferior optimization. ! .Ip "\fB\-fstrict-aliasing\fR" 4 .IX Item "-fstrict-aliasing" Allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and \*(C+), this activates --- 3164,3170 ---- behavior; minimizing non-determinism is of paramount import. This switch allows users to reduce non-determinism, possibly at the expense of inferior optimization. ! .IP "\fB\-fstrict-aliasing\fR" 4 .IX Item "-fstrict-aliasing" Allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and \*(C+), this activates *************** expected. However, this code might not: *** 3209,3218 **** \& return *ip; \& } .Ve ! .Ip "\fB\-falign-functions\fR" 4 .IX Item "-falign-functions" .PD 0 ! .Ip "\fB\-falign-functions=\fR\fIn\fR" 4 .IX Item "-falign-functions=n" .PD Align the start of functions to the next power-of-two greater than --- 3205,3214 ---- \& return *ip; \& } .Ve ! .IP "\fB\-falign-functions\fR" 4 .IX Item "-falign-functions" .PD 0 ! .IP "\fB\-falign-functions=\fR\fIn\fR" 4 .IX Item "-falign-functions=n" .PD Align the start of functions to the next power-of-two greater than *************** Some assemblers only support this flag w *** 3228,3237 **** in that case, it is rounded up. .Sp If \fIn\fR is not specified, use a machine-dependent default. ! .Ip "\fB\-falign-labels\fR" 4 .IX Item "-falign-labels" .PD 0 ! .Ip "\fB\-falign-labels=\fR\fIn\fR" 4 .IX Item "-falign-labels=n" .PD Align all branch targets to a power-of-two boundary, skipping up to --- 3224,3233 ---- in that case, it is rounded up. .Sp If \fIn\fR is not specified, use a machine-dependent default. ! .IP "\fB\-falign-labels\fR" 4 .IX Item "-falign-labels" .PD 0 ! .IP "\fB\-falign-labels=\fR\fIn\fR" 4 .IX Item "-falign-labels=n" .PD Align all branch targets to a power-of-two boundary, skipping up to *************** are greater than this value, then their *** 3244,3253 **** .Sp If \fIn\fR is not specified, use a machine-dependent default which is very likely to be \fB1\fR, meaning no alignment. ! .Ip "\fB\-falign-loops\fR" 4 .IX Item "-falign-loops" .PD 0 ! .Ip "\fB\-falign-loops=\fR\fIn\fR" 4 .IX Item "-falign-loops=n" .PD Align loops to a power-of-two boundary, skipping up to \fIn\fR bytes --- 3240,3249 ---- .Sp If \fIn\fR is not specified, use a machine-dependent default which is very likely to be \fB1\fR, meaning no alignment. ! .IP "\fB\-falign-loops\fR" 4 .IX Item "-falign-loops" .PD 0 ! .IP "\fB\-falign-loops=\fR\fIn\fR" 4 .IX Item "-falign-loops=n" .PD Align loops to a power-of-two boundary, skipping up to \fIn\fR bytes *************** executed many times, which will make up *** 3256,3265 **** operations. .Sp If \fIn\fR is not specified, use a machine-dependent default. ! .Ip "\fB\-falign-jumps\fR" 4 .IX Item "-falign-jumps" .PD 0 ! .Ip "\fB\-falign-jumps=\fR\fIn\fR" 4 .IX Item "-falign-jumps=n" .PD Align branch targets to a power-of-two boundary, for branch targets --- 3252,3261 ---- operations. .Sp If \fIn\fR is not specified, use a machine-dependent default. ! .IP "\fB\-falign-jumps\fR" 4 .IX Item "-falign-jumps" .PD 0 ! .IP "\fB\-falign-jumps=\fR\fIn\fR" 4 .IX Item "-falign-jumps=n" .PD Align branch targets to a power-of-two boundary, for branch targets *************** bytes like \fB\-falign-functions\fR. In *** 3268,3295 **** need be executed. .Sp If \fIn\fR is not specified, use a machine-dependent default. ! .Ip "\fB\-fssa\fR" 4 .IX Item "-fssa" Perform optimizations in static single assignment form. Each function's flow graph is translated into \s-1SSA\s0 form, optimizations are performed, and the flow graph is translated back from \s-1SSA\s0 form. Users should not specify this option, since it is not yet ready for production use. ! .Ip "\fB\-fdce\fR" 4 .IX Item "-fdce" Perform dead-code elimination in \s-1SSA\s0 form. Requires \fB\-fssa\fR. Like \&\fB\-fssa\fR, this is an experimental feature. ! .Ip "\fB\-fsingle-precision-constant\fR" 4 .IX Item "-fsingle-precision-constant" Treat floating point constant as single precision constant instead of implicitly converting it to double precision constant. ! .Ip "\fB\-frename-registers\fR" 4 .IX Item "-frename-registers" Attempt to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization will most benefit processors with lots of registers. It can, however, make debugging impossible, since variables will no longer stay in a ``home register''. ! .Ip "\fB\*(--param\fR \fIname\fR\fB=\fR\fIvalue\fR" 4 .IX Item "param name=value" In some places, \s-1GCC\s0 uses various constants to control the amount of optimization that is done. For example, \s-1GCC\s0 will not inline functions --- 3264,3291 ---- need be executed. .Sp If \fIn\fR is not specified, use a machine-dependent default. ! .IP "\fB\-fssa\fR" 4 .IX Item "-fssa" Perform optimizations in static single assignment form. Each function's flow graph is translated into \s-1SSA\s0 form, optimizations are performed, and the flow graph is translated back from \s-1SSA\s0 form. Users should not specify this option, since it is not yet ready for production use. ! .IP "\fB\-fdce\fR" 4 .IX Item "-fdce" Perform dead-code elimination in \s-1SSA\s0 form. Requires \fB\-fssa\fR. Like \&\fB\-fssa\fR, this is an experimental feature. ! .IP "\fB\-fsingle-precision-constant\fR" 4 .IX Item "-fsingle-precision-constant" Treat floating point constant as single precision constant instead of implicitly converting it to double precision constant. ! .IP "\fB\-frename-registers\fR" 4 .IX Item "-frename-registers" Attempt to avoid false dependencies in scheduled code by making use of registers left over after register allocation. This optimization will most benefit processors with lots of registers. It can, however, make debugging impossible, since variables will no longer stay in a ``home register''. ! .IP "\fB\*(--param\fR \fIname\fR\fB=\fR\fIvalue\fR" 4 .IX Item "param name=value" In some places, \s-1GCC\s0 uses various constants to control the amount of optimization that is done. For example, \s-1GCC\s0 will not inline functions *************** that contain more that a certain number *** 3297,3306 **** control some of these constants on the command-line using the \&\fB\*(--param\fR option. .Sp ! In each case, the \fIvalue\fR is a integer. The allowable choices for \&\fIname\fR are given in the following table: .RS 4 ! .Ip "\fBmax-delay-slot-insn-search\fR" 4 .IX Item "max-delay-slot-insn-search" The maximum number of instructions to consider when looking for an instruction to fill a delay slot. If more than this arbitrary number of --- 3293,3302 ---- control some of these constants on the command-line using the \&\fB\*(--param\fR option. .Sp ! In each case, the \fIvalue\fR is an integer. The allowable choices for \&\fIname\fR are given in the following table: .RS 4 ! .IP "\fBmax-delay-slot-insn-search\fR" 4 .IX Item "max-delay-slot-insn-search" The maximum number of instructions to consider when looking for an instruction to fill a delay slot. If more than this arbitrary number of *************** instructions is searched, the time savin *** 3308,3314 **** will be minimal so stop searching. Increasing values mean more aggressive optimization, making the compile time increase with probably small improvement in executable run time. ! .Ip "\fBmax-delay-slot-live-search\fR" 4 .IX Item "max-delay-slot-live-search" When trying to fill delay slots, the maximum number of instructions to consider when searching for a block with valid live register --- 3304,3310 ---- will be minimal so stop searching. Increasing values mean more aggressive optimization, making the compile time increase with probably small improvement in executable run time. ! .IP "\fBmax-delay-slot-live-search\fR" 4 .IX Item "max-delay-slot-live-search" When trying to fill delay slots, the maximum number of instructions to consider when searching for a block with valid live register *************** information. Increasing this arbitraril *** 3316,3328 **** aggressive optimization, increasing the compile time. This parameter should be removed when the delay slot code is rewritten to maintain the control-flow graph. ! .Ip "\fBmax-gcse-memory\fR" 4 .IX Item "max-gcse-memory" The approximate maximum amount of memory that will be allocated in order to perform the global common subexpression elimination optimization. If more memory than specified is required, the optimization will not be done. ! .Ip "\fBmax-inline-insns\fR" 4 .IX Item "max-inline-insns" If an function contains more than this many instructions, it will not be inlined. This option is precisely equivalent to --- 3312,3330 ---- aggressive optimization, increasing the compile time. This parameter should be removed when the delay slot code is rewritten to maintain the control-flow graph. ! .IP "\fBmax-gcse-memory\fR" 4 .IX Item "max-gcse-memory" The approximate maximum amount of memory that will be allocated in order to perform the global common subexpression elimination optimization. If more memory than specified is required, the optimization will not be done. ! .IP "\fBmax-pending-list-length\fR" 4 ! .IX Item "max-pending-list-length" ! The maximum number of pending dependancies scheduling will allow ! before flushing the current state and starting over. Large functions ! with few branches or calls can create excessively large lists which ! needlessly consume memory and resources. ! .IP "\fBmax-inline-insns\fR" 4 .IX Item "max-inline-insns" If an function contains more than this many instructions, it will not be inlined. This option is precisely equivalent to *************** If you use the \fB\-E\fR option, nothing *** 3339,3345 **** Some of these options make sense only together with \fB\-E\fR because they cause the preprocessor output to be unsuitable for actual compilation. ! .Ip "\fB\-include\fR \fIfile\fR" 4 .IX Item "-include file" Process \fIfile\fR as input before processing the regular input file. In effect, the contents of \fIfile\fR are compiled first. Any \fB\-D\fR --- 3341,3347 ---- Some of these options make sense only together with \fB\-E\fR because they cause the preprocessor output to be unsuitable for actual compilation. ! .IP "\fB\-include\fR \fIfile\fR" 4 .IX Item "-include file" Process \fIfile\fR as input before processing the regular input file. In effect, the contents of \fIfile\fR are compiled first. Any \fB\-D\fR *************** and \fB\-U\fR options on the command lin *** 3347,3353 **** \&\fB\-include\fR \fIfile\fR, regardless of the order in which they are written. All the \fB\-include\fR and \fB\-imacros\fR options are processed in the order in which they are written. ! .Ip "\fB\-imacros\fR \fIfile\fR" 4 .IX Item "-imacros file" Process \fIfile\fR as input, discarding the resulting output, before processing the regular input file. Because the output generated from --- 3349,3355 ---- \&\fB\-include\fR \fIfile\fR, regardless of the order in which they are written. All the \fB\-include\fR and \fB\-imacros\fR options are processed in the order in which they are written. ! .IP "\fB\-imacros\fR \fIfile\fR" 4 .IX Item "-imacros file" Process \fIfile\fR as input, discarding the resulting output, before processing the regular input file. Because the output generated from *************** processing the regular input file. Beca *** 3355,3388 **** is to make the macros defined in \fIfile\fR available for use in the main input. All the \fB\-include\fR and \fB\-imacros\fR options are processed in the order in which they are written. ! .Ip "\fB\-idirafter\fR \fIdir\fR" 4 .IX Item "-idirafter dir" Add the directory \fIdir\fR to the second include path. The directories on the second include path are searched when a header file is not found in any of the directories in the main include path (the one that \&\fB\-I\fR adds to). ! .Ip "\fB\-iprefix\fR \fIprefix\fR" 4 .IX Item "-iprefix prefix" Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR options. ! .Ip "\fB\-iwithprefix\fR \fIdir\fR" 4 .IX Item "-iwithprefix dir" Add a directory to the second include path. The directory's name is made by concatenating \fIprefix\fR and \fIdir\fR, where \fIprefix\fR was specified previously with \fB\-iprefix\fR. If you have not specified a prefix yet, the directory containing the installed passes of the compiler is used as the default. ! .Ip "\fB\-iwithprefixbefore\fR \fIdir\fR" 4 .IX Item "-iwithprefixbefore dir" Add a directory to the main include path. The directory's name is made by concatenating \fIprefix\fR and \fIdir\fR, as in the case of \&\fB\-iwithprefix\fR. ! .Ip "\fB\-isystem\fR \fIdir\fR" 4 .IX Item "-isystem dir" Add a directory to the beginning of the second include path, marking it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. ! .Ip "\fB\-nostdinc\fR" 4 .IX Item "-nostdinc" Do not search the standard system directories for header files. Only the directories you have specified with \fB\-I\fR options (and the --- 3357,3390 ---- is to make the macros defined in \fIfile\fR available for use in the main input. All the \fB\-include\fR and \fB\-imacros\fR options are processed in the order in which they are written. ! .IP "\fB\-idirafter\fR \fIdir\fR" 4 .IX Item "-idirafter dir" Add the directory \fIdir\fR to the second include path. The directories on the second include path are searched when a header file is not found in any of the directories in the main include path (the one that \&\fB\-I\fR adds to). ! .IP "\fB\-iprefix\fR \fIprefix\fR" 4 .IX Item "-iprefix prefix" Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR options. ! .IP "\fB\-iwithprefix\fR \fIdir\fR" 4 .IX Item "-iwithprefix dir" Add a directory to the second include path. The directory's name is made by concatenating \fIprefix\fR and \fIdir\fR, where \fIprefix\fR was specified previously with \fB\-iprefix\fR. If you have not specified a prefix yet, the directory containing the installed passes of the compiler is used as the default. ! .IP "\fB\-iwithprefixbefore\fR \fIdir\fR" 4 .IX Item "-iwithprefixbefore dir" Add a directory to the main include path. The directory's name is made by concatenating \fIprefix\fR and \fIdir\fR, as in the case of \&\fB\-iwithprefix\fR. ! .IP "\fB\-isystem\fR \fIdir\fR" 4 .IX Item "-isystem dir" Add a directory to the beginning of the second include path, marking it as a system directory, so that it gets the same special treatment as is applied to the standard system directories. ! .IP "\fB\-nostdinc\fR" 4 .IX Item "-nostdinc" Do not search the standard system directories for header files. Only the directories you have specified with \fB\-I\fR options (and the *************** current directory, if appropriate) are s *** 3390,3396 **** .Sp By using both \fB\-nostdinc\fR and \fB\-I-\fR, you can limit the include-file search path to only those directories you specify explicitly. ! .Ip "\fB\-remap\fR" 4 .IX Item "-remap" When searching for a header file in a directory, remap file names if a file named \fIheader.gcc\fR exists in that directory. This can be used --- 3392,3398 ---- .Sp By using both \fB\-nostdinc\fR and \fB\-I-\fR, you can limit the include-file search path to only those directories you specify explicitly. ! .IP "\fB\-remap\fR" 4 .IX Item "-remap" When searching for a header file in a directory, remap file names if a file named \fIheader.gcc\fR exists in that directory. This can be used *************** to work around limitations of file syste *** 3398,3420 **** The \fIheader.gcc\fR file should contain a series of lines with two tokens on each line: the first token is the name to map, and the second token is the actual name to use. ! .Ip "\fB\-undef\fR" 4 .IX Item "-undef" Do not predefine any nonstandard macros. (Including architecture flags). ! .Ip "\fB\-E\fR" 4 .IX Item "-E" Run only the C preprocessor. Preprocess all the C source files specified and output the results to standard output or to the specified output file. ! .Ip "\fB\-C\fR" 4 .IX Item "-C" Tell the preprocessor not to discard comments. Used with the \&\fB\-E\fR option. ! .Ip "\fB\-P\fR" 4 .IX Item "-P" Tell the preprocessor not to generate \fB#line\fR directives. Used with the \fB\-E\fR option. ! .Ip "\fB\-M\fR" 4 .IX Item "-M" Instead of outputting the result of preprocessing, output a rule suitable for \f(CW\*(C`make\*(C'\fR describing the dependencies of the main source --- 3400,3422 ---- The \fIheader.gcc\fR file should contain a series of lines with two tokens on each line: the first token is the name to map, and the second token is the actual name to use. ! .IP "\fB\-undef\fR" 4 .IX Item "-undef" Do not predefine any nonstandard macros. (Including architecture flags). ! .IP "\fB\-E\fR" 4 .IX Item "-E" Run only the C preprocessor. Preprocess all the C source files specified and output the results to standard output or to the specified output file. ! .IP "\fB\-C\fR" 4 .IX Item "-C" Tell the preprocessor not to discard comments. Used with the \&\fB\-E\fR option. ! .IP "\fB\-P\fR" 4 .IX Item "-P" Tell the preprocessor not to generate \fB#line\fR directives. Used with the \fB\-E\fR option. ! .IP "\fB\-M\fR" 4 .IX Item "-M" Instead of outputting the result of preprocessing, output a rule suitable for \f(CW\*(C`make\*(C'\fR describing the dependencies of the main source *************** object file suffix. If there are many i *** 3426,3437 **** rule is split into several lines using \fB\e\fR\-newline. .Sp \&\fB\-M\fR implies \fB\-E\fR. ! .Ip "\fB\-MM\fR" 4 .IX Item "-MM" Like \fB\-M\fR, but mention only the files included with \fB#include "\fR\fIfile\fR\fB"\fR. System header files included with \fB#include <\fR\fIfile\fR\fB>\fR are omitted. ! .Ip "\fB\-MD\fR" 4 .IX Item "-MD" Like \fB\-M\fR but the dependency information is written to a file rather than stdout. \f(CW\*(C`gcc\*(C'\fR will use the same file name and --- 3428,3439 ---- rule is split into several lines using \fB\e\fR\-newline. .Sp \&\fB\-M\fR implies \fB\-E\fR. ! .IP "\fB\-MM\fR" 4 .IX Item "-MM" Like \fB\-M\fR, but mention only the files included with \fB#include "\fR\fIfile\fR\fB"\fR. System header files included with \fB#include <\fR\fIfile\fR\fB>\fR are omitted. ! .IP "\fB\-MD\fR" 4 .IX Item "-MD" Like \fB\-M\fR but the dependency information is written to a file rather than stdout. \f(CW\*(C`gcc\*(C'\fR will use the same file name and *************** unless you also specify \fB\-MG\fR. *** 3444,3454 **** With Mach, you can use the utility \f(CW\*(C`md\*(C'\fR to merge multiple dependency files into a single dependency file suitable for using with the \fBmake\fR command. ! .Ip "\fB\-MMD\fR" 4 .IX Item "-MMD" Like \fB\-MD\fR except mention only user header files, not system \&\-header files. ! .Ip "\fB\-MF\fR \fIfile\fR" 4 .IX Item "-MF file" When used with \fB\-M\fR or \fB\-MM\fR, specifies a file to write the dependencies to. This allows the preprocessor to write the preprocessed --- 3446,3456 ---- With Mach, you can use the utility \f(CW\*(C`md\*(C'\fR to merge multiple dependency files into a single dependency file suitable for using with the \fBmake\fR command. ! .IP "\fB\-MMD\fR" 4 .IX Item "-MMD" Like \fB\-MD\fR except mention only user header files, not system \&\-header files. ! .IP "\fB\-MF\fR \fIfile\fR" 4 .IX Item "-MF file" When used with \fB\-M\fR or \fB\-MM\fR, specifies a file to write the dependencies to. This allows the preprocessor to write the preprocessed *************** the rules to stdout and suppresses norma *** 3457,3463 **** .Sp Another way to specify output of a \f(CW\*(C`make\*(C'\fR rule is by setting the environment variable \fB\s-1DEPENDENCIES_OUTPUT\s0\fR. ! .Ip "\fB\-MG\fR" 4 .IX Item "-MG" When used with \fB\-M\fR or \fB\-MM\fR, \fB\-MG\fR says to treat missing header files as generated files and assume they live in the same --- 3459,3465 ---- .Sp Another way to specify output of a \f(CW\*(C`make\*(C'\fR rule is by setting the environment variable \fB\s-1DEPENDENCIES_OUTPUT\s0\fR. ! .IP "\fB\-MG\fR" 4 .IX Item "-MG" When used with \fB\-M\fR or \fB\-MM\fR, \fB\-MG\fR says to treat missing header files as generated files and assume they live in the same *************** directory as the source file. It suppre *** 3465,3471 **** missing header file is ordinarily an error. .Sp This feature is used in automatic updating of makefiles. ! .Ip "\fB\-MP\fR" 4 .IX Item "-MP" This option instructs \s-1CPP\s0 to add a phony target for each dependency other than the main file, causing each to depend on nothing. These --- 3467,3473 ---- missing header file is ordinarily an error. .Sp This feature is used in automatic updating of makefiles. ! .IP "\fB\-MP\fR" 4 .IX Item "-MP" This option instructs \s-1CPP\s0 to add a phony target for each dependency other than the main file, causing each to depend on nothing. These *************** This is typical output:\- *** 3480,3489 **** .Vb 1 \& /tmp/test.h: .Ve ! .Ip "\fB\-MQ\fR \fItarget\fR" 4 .IX Item "-MQ target" .PD 0 ! .Ip "\fB\-MT\fR \fItarget\fR" 4 .IX Item "-MT target" .PD By default \s-1CPP\s0 uses the main file name, including any path, and appends --- 3482,3491 ---- .Vb 1 \& /tmp/test.h: .Ve ! .IP "\fB\-MQ\fR \fItarget\fR" 4 .IX Item "-MQ target" .PD 0 ! .IP "\fB\-MT\fR \fItarget\fR" 4 .IX Item "-MT target" .PD By default \s-1CPP\s0 uses the main file name, including any path, and appends *************** but \fB\-MQ '$(objpfx)foo.o'\fR gives *** 3509,3528 **** .Ve The default target is automatically quoted, as if it were given with \&\fB\-MQ\fR. ! .Ip "\fB\-H\fR" 4 .IX Item "-H" Print the name of each header file used, in addition to other normal activities. ! .Ip "\fB\-A\fR\fIquestion\fR\fB(\fR\fIanswer\fR\fB)\fR" 4 .IX Item "-Aquestion(answer)" Assert the answer \fIanswer\fR for \fIquestion\fR, in case it is tested with a preprocessing conditional such as \fB#if #\fR\fIquestion\fR\fB(\fR\fIanswer\fR\fB)\fR. \fB\-A-\fR disables the standard assertions that normally describe the target machine. ! .Ip "\fB\-D\fR\fImacro\fR" 4 .IX Item "-Dmacro" Define macro \fImacro\fR with the string \fB1\fR as its definition. ! .Ip "\fB\-D\fR\fImacro\fR\fB=\fR\fIdefn\fR" 4 .IX Item "-Dmacro=defn" Define macro \fImacro\fR as \fIdefn\fR. All instances of \fB\-D\fR on the command line are processed before any \fB\-U\fR options. --- 3511,3530 ---- .Ve The default target is automatically quoted, as if it were given with \&\fB\-MQ\fR. ! .IP "\fB\-H\fR" 4 .IX Item "-H" Print the name of each header file used, in addition to other normal activities. ! .IP "\fB\-A\fR\fIquestion\fR\fB(\fR\fIanswer\fR\fB)\fR" 4 .IX Item "-Aquestion(answer)" Assert the answer \fIanswer\fR for \fIquestion\fR, in case it is tested with a preprocessing conditional such as \fB#if #\fR\fIquestion\fR\fB(\fR\fIanswer\fR\fB)\fR. \fB\-A-\fR disables the standard assertions that normally describe the target machine. ! .IP "\fB\-D\fR\fImacro\fR" 4 .IX Item "-Dmacro" Define macro \fImacro\fR with the string \fB1\fR as its definition. ! .IP "\fB\-D\fR\fImacro\fR\fB=\fR\fIdefn\fR" 4 .IX Item "-Dmacro=defn" Define macro \fImacro\fR as \fIdefn\fR. All instances of \fB\-D\fR on the command line are processed before any \fB\-U\fR options. *************** the command line are processed before an *** 3530,3536 **** Any \fB\-D\fR and \fB\-U\fR options on the command line are processed in order, and always before \fB\-imacros\fR \fIfile\fR, regardless of the order in which they are written. ! .Ip "\fB\-U\fR\fImacro\fR" 4 .IX Item "-Umacro" Undefine macro \fImacro\fR. \fB\-U\fR options are evaluated after all \&\fB\-D\fR options, but before any \fB\-include\fR and \fB\-imacros\fR --- 3532,3538 ---- Any \fB\-D\fR and \fB\-U\fR options on the command line are processed in order, and always before \fB\-imacros\fR \fIfile\fR, regardless of the order in which they are written. ! .IP "\fB\-U\fR\fImacro\fR" 4 .IX Item "-Umacro" Undefine macro \fImacro\fR. \fB\-U\fR options are evaluated after all \&\fB\-D\fR options, but before any \fB\-include\fR and \fB\-imacros\fR *************** options. *** 3539,3562 **** Any \fB\-D\fR and \fB\-U\fR options on the command line are processed in order, and always before \fB\-imacros\fR \fIfile\fR, regardless of the order in which they are written. ! .Ip "\fB\-dM\fR" 4 .IX Item "-dM" Tell the preprocessor to output only a list of the macro definitions that are in effect at the end of preprocessing. Used with the \fB\-E\fR option. ! .Ip "\fB\-dD\fR" 4 .IX Item "-dD" Tell the preprocessing to pass all macro definitions into the output, in their proper sequence in the rest of the output. ! .Ip "\fB\-dN\fR" 4 .IX Item "-dN" Like \fB\-dD\fR except that the macro arguments and contents are omitted. Only \fB#define\fR \fIname\fR is included in the output. ! .Ip "\fB\-dI\fR" 4 .IX Item "-dI" Output \fB#include\fR directives in addition to the result of preprocessing. ! .Ip "\fB\-fpreprocessed\fR" 4 .IX Item "-fpreprocessed" Indicate to the preprocessor that the input file has already been preprocessed. This suppresses things like macro expansion, trigraph --- 3541,3564 ---- Any \fB\-D\fR and \fB\-U\fR options on the command line are processed in order, and always before \fB\-imacros\fR \fIfile\fR, regardless of the order in which they are written. ! .IP "\fB\-dM\fR" 4 .IX Item "-dM" Tell the preprocessor to output only a list of the macro definitions that are in effect at the end of preprocessing. Used with the \fB\-E\fR option. ! .IP "\fB\-dD\fR" 4 .IX Item "-dD" Tell the preprocessing to pass all macro definitions into the output, in their proper sequence in the rest of the output. ! .IP "\fB\-dN\fR" 4 .IX Item "-dN" Like \fB\-dD\fR except that the macro arguments and contents are omitted. Only \fB#define\fR \fIname\fR is included in the output. ! .IP "\fB\-dI\fR" 4 .IX Item "-dI" Output \fB#include\fR directives in addition to the result of preprocessing. ! .IP "\fB\-fpreprocessed\fR" 4 .IX Item "-fpreprocessed" Indicate to the preprocessor that the input file has already been preprocessed. This suppresses things like macro expansion, trigraph *************** for the front ends. *** 3567,3573 **** \&\fB\-fpreprocessed\fR is implicit if the input file has one of the extensions \fBi\fR, \fBii\fR or \fBmi\fR indicating it has already been preprocessed. ! .Ip "\fB\-trigraphs\fR" 4 .IX Item "-trigraphs" Process \s-1ISO\s0 standard trigraph sequences. These are three-character sequences, all starting with \fB??\fR, that are defined by \s-1ISO\s0 C to --- 3569,3575 ---- \&\fB\-fpreprocessed\fR is implicit if the input file has one of the extensions \fBi\fR, \fBii\fR or \fBmi\fR indicating it has already been preprocessed. ! .IP "\fB\-trigraphs\fR" 4 .IX Item "-trigraphs" Process \s-1ISO\s0 standard trigraph sequences. These are three-character sequences, all starting with \fB??\fR, that are defined by \s-1ISO\s0 C to *************** converts them. See the \fB\-std\fR and *** 3578,3608 **** .Sp The nine trigraph sequences are .RS 4 ! .Ip "\fB??(\fR" 4 .IX Item "??(" @expansion{} \fB[\fR ! .Ip "\fB??)\fR" 4 .IX Item "??)" @expansion{} \fB]\fR ! .Ip "\fB??<\fR" 4 .IX Item "??<" @expansion{} \fB{\fR ! .Ip "\fB??>\fR" 4 .IX Item "??>" @expansion{} \fB}\fR ! .Ip "\fB??=\fR" 4 .IX Item "??=" @expansion{} \fB#\fR ! .Ip "\fB??/\fR" 4 .IX Item "??/" @expansion{} \fB\e\fR ! .Ip "\fB??'\fR" 4 .IX Item "??'" @expansion{} \fB^\fR ! .Ip "\fB??!\fR" 4 .IX Item "??!" @expansion{} \fB|\fR ! .Ip "\fB??-\fR" 4 .IX Item "??-" @expansion{} \fB~\fR .RE --- 3580,3610 ---- .Sp The nine trigraph sequences are .RS 4 ! .IP "\fB??(\fR" 4 .IX Item "??(" @expansion{} \fB[\fR ! .IP "\fB??)\fR" 4 .IX Item "??)" @expansion{} \fB]\fR ! .IP "\fB??<\fR" 4 .IX Item "??<" @expansion{} \fB{\fR ! .IP "\fB??>\fR" 4 .IX Item "??>" @expansion{} \fB}\fR ! .IP "\fB??=\fR" 4 .IX Item "??=" @expansion{} \fB#\fR ! .IP "\fB??/\fR" 4 .IX Item "??/" @expansion{} \fB\e\fR ! .IP "\fB??'\fR" 4 .IX Item "??'" @expansion{} \fB^\fR ! .IP "\fB??!\fR" 4 .IX Item "??!" @expansion{} \fB|\fR ! .IP "\fB??-\fR" 4 .IX Item "??-" @expansion{} \fB~\fR .RE *************** Trigraph support is not popular, so many *** 3612,3625 **** properly. Portable code should not rely on trigraphs being either converted or ignored. .RE ! .Ip "\fB\-Wp,\fR\fIoption\fR" 4 .IX Item "-Wp,option" Pass \fIoption\fR as an option to the preprocessor. If \fIoption\fR contains commas, it is split into multiple options at the commas. .Sh "Passing Options to the Assembler" .IX Subsection "Passing Options to the Assembler" You can pass options to the assembler. ! .Ip "\fB\-Wa,\fR\fIoption\fR" 4 .IX Item "-Wa,option" Pass \fIoption\fR as an option to the assembler. If \fIoption\fR contains commas, it is split into multiple options at the commas. --- 3614,3627 ---- properly. Portable code should not rely on trigraphs being either converted or ignored. .RE ! .IP "\fB\-Wp,\fR\fIoption\fR" 4 .IX Item "-Wp,option" Pass \fIoption\fR as an option to the preprocessor. If \fIoption\fR contains commas, it is split into multiple options at the commas. .Sh "Passing Options to the Assembler" .IX Subsection "Passing Options to the Assembler" You can pass options to the assembler. ! .IP "\fB\-Wa,\fR\fIoption\fR" 4 .IX Item "-Wa,option" Pass \fIoption\fR as an option to the assembler. If \fIoption\fR contains commas, it is split into multiple options at the commas. *************** contains commas, it is split into multip *** 3628,3651 **** These options come into play when the compiler links object files into an executable output file. They are meaningless if the compiler is not doing a link step. ! .Ip "\fIobject-file-name\fR" 4 .IX Item "object-file-name" A file name that does not end in a special recognized suffix is considered to name an object file or library. (Object files are distinguished from libraries by the linker according to the file contents.) If linking is done, these object files are used as input to the linker. ! .Ip "\fB\-c\fR" 4 .IX Item "-c" .PD 0 ! .Ip "\fB\-S\fR" 4 .IX Item "-S" ! .Ip "\fB\-E\fR" 4 .IX Item "-E" .PD If any of these options is used, then the linker is not run, and object file names should not be used as arguments. ! .Ip "\fB\-l\fR\fIlibrary\fR" 4 .IX Item "-llibrary" Search the library named \fIlibrary\fR when linking. .Sp --- 3630,3653 ---- These options come into play when the compiler links object files into an executable output file. They are meaningless if the compiler is not doing a link step. ! .IP "\fIobject-file-name\fR" 4 .IX Item "object-file-name" A file name that does not end in a special recognized suffix is considered to name an object file or library. (Object files are distinguished from libraries by the linker according to the file contents.) If linking is done, these object files are used as input to the linker. ! .IP "\fB\-c\fR" 4 .IX Item "-c" .PD 0 ! .IP "\fB\-S\fR" 4 .IX Item "-S" ! .IP "\fB\-E\fR" 4 .IX Item "-E" .PD If any of these options is used, then the linker is not run, and object file names should not be used as arguments. ! .IP "\fB\-l\fR\fIlibrary\fR" 4 .IX Item "-llibrary" Search the library named \fIlibrary\fR when linking. .Sp *************** ordinary object file, it is linked in th *** 3670,3685 **** difference between using an \fB\-l\fR option and specifying a file name is that \fB\-l\fR surrounds \fIlibrary\fR with \fBlib\fR and \fB.a\fR and searches several directories. ! .Ip "\fB\-lobjc\fR" 4 .IX Item "-lobjc" You need this special case of the \fB\-l\fR option in order to link an Objective C program. ! .Ip "\fB\-nostartfiles\fR" 4 .IX Item "-nostartfiles" Do not use the standard system startup files when linking. The standard system libraries are used normally, unless \fB\-nostdlib\fR or \fB\-nodefaultlibs\fR is used. ! .Ip "\fB\-nodefaultlibs\fR" 4 .IX Item "-nodefaultlibs" Do not use the standard system libraries when linking. Only the libraries you specify will be passed to the linker. --- 3672,3687 ---- difference between using an \fB\-l\fR option and specifying a file name is that \fB\-l\fR surrounds \fIlibrary\fR with \fBlib\fR and \fB.a\fR and searches several directories. ! .IP "\fB\-lobjc\fR" 4 .IX Item "-lobjc" You need this special case of the \fB\-l\fR option in order to link an Objective C program. ! .IP "\fB\-nostartfiles\fR" 4 .IX Item "-nostartfiles" Do not use the standard system startup files when linking. The standard system libraries are used normally, unless \fB\-nostdlib\fR or \fB\-nodefaultlibs\fR is used. ! .IP "\fB\-nodefaultlibs\fR" 4 .IX Item "-nodefaultlibs" Do not use the standard system libraries when linking. Only the libraries you specify will be passed to the linker. *************** for System V (and \s-1ISO\s0 C) environm *** 3689,3695 **** \&\s-1BSD\s0 environments. These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified. ! .Ip "\fB\-nostdlib\fR" 4 .IX Item "-nostdlib" Do not use the standard system startup files or libraries when linking. No startup files and only the libraries you specify will be passed to --- 3691,3697 ---- \&\s-1BSD\s0 environments. These entries are usually resolved by entries in libc. These entry points should be supplied through some other mechanism when this option is specified. ! .IP "\fB\-nostdlib\fR" 4 .IX Item "-nostdlib" Do not use the standard system startup files or libraries when linking. No startup files and only the libraries you specify will be passed to *************** or \fB\-nodefaultlibs\fR you should usua *** 3710,3733 **** This ensures that you have no unresolved references to internal \s-1GCC\s0 library subroutines. (For example, \fB_\|_main\fR, used to ensure \*(C+ constructors will be called.) ! .Ip "\fB\-s\fR" 4 .IX Item "-s" Remove all symbol table and relocation information from the executable. ! .Ip "\fB\-static\fR" 4 .IX Item "-static" On systems that support dynamic linking, this prevents linking with the shared libraries. On other systems, this option has no effect. ! .Ip "\fB\-shared\fR" 4 .IX Item "-shared" Produce a shared object which can then be linked with other objects to form an executable. Not all systems support this option. For predictable results, you must also specify the same set of options that were used to generate code (\fB\-fpic\fR, \fB\-fPIC\fR, or model suboptions) when you specify this option.[1] ! .Ip "\fB\-shared-libgcc\fR" 4 .IX Item "-shared-libgcc" .PD 0 ! .Ip "\fB\-static-libgcc\fR" 4 .IX Item "-static-libgcc" .PD On systems that provide \fIlibgcc\fR as a shared library, these options --- 3712,3735 ---- This ensures that you have no unresolved references to internal \s-1GCC\s0 library subroutines. (For example, \fB_\|_main\fR, used to ensure \*(C+ constructors will be called.) ! .IP "\fB\-s\fR" 4 .IX Item "-s" Remove all symbol table and relocation information from the executable. ! .IP "\fB\-static\fR" 4 .IX Item "-static" On systems that support dynamic linking, this prevents linking with the shared libraries. On other systems, this option has no effect. ! .IP "\fB\-shared\fR" 4 .IX Item "-shared" Produce a shared object which can then be linked with other objects to form an executable. Not all systems support this option. For predictable results, you must also specify the same set of options that were used to generate code (\fB\-fpic\fR, \fB\-fPIC\fR, or model suboptions) when you specify this option.[1] ! .IP "\fB\-shared-libgcc\fR" 4 .IX Item "-shared-libgcc" .PD 0 ! .IP "\fB\-static-libgcc\fR" 4 .IX Item "-static-libgcc" .PD On systems that provide \fIlibgcc\fR as a shared library, these options *************** for \*(C+ programs that is typically the *** 3751,3763 **** However, when linking a main executable written in C, you must explicitly say \fB\-shared-libgcc\fR if you want to use the shared \&\fIlibgcc\fR. ! .Ip "\fB\-symbolic\fR" 4 .IX Item "-symbolic" Bind references to global symbols when building a shared object. Warn about any unresolved references (unless overridden by the link editor option \fB\-Xlinker \-z \-Xlinker defs\fR). Only a few systems support this option. ! .Ip "\fB\-Xlinker\fR \fIoption\fR" 4 .IX Item "-Xlinker option" Pass \fIoption\fR as an option to the linker. You can use this to supply system-specific linker options which \s-1GCC\s0 does not know how to --- 3753,3765 ---- However, when linking a main executable written in C, you must explicitly say \fB\-shared-libgcc\fR if you want to use the shared \&\fIlibgcc\fR. ! .IP "\fB\-symbolic\fR" 4 .IX Item "-symbolic" Bind references to global symbols when building a shared object. Warn about any unresolved references (unless overridden by the link editor option \fB\-Xlinker \-z \-Xlinker defs\fR). Only a few systems support this option. ! .IP "\fB\-Xlinker\fR \fIoption\fR" 4 .IX Item "-Xlinker option" Pass \fIoption\fR as an option to the linker. You can use this to supply system-specific linker options which \s-1GCC\s0 does not know how to *************** For example, to pass \fB\-assert definit *** 3769,3779 **** \&\fB\-Xlinker \-assert \-Xlinker definitions\fR. It does not work to write \&\fB\-Xlinker \*(L"\-assert definitions\*(R"\fR, because this passes the entire string as a single argument, which is not what the linker expects. ! .Ip "\fB\-Wl,\fR\fIoption\fR" 4 .IX Item "-Wl,option" Pass \fIoption\fR as an option to the linker. If \fIoption\fR contains commas, it is split into multiple options at the commas. ! .Ip "\fB\-u\fR \fIsymbol\fR" 4 .IX Item "-u symbol" Pretend the symbol \fIsymbol\fR is undefined, to force linking of library modules to define it. You can use \fB\-u\fR multiple times with --- 3771,3781 ---- \&\fB\-Xlinker \-assert \-Xlinker definitions\fR. It does not work to write \&\fB\-Xlinker \*(L"\-assert definitions\*(R"\fR, because this passes the entire string as a single argument, which is not what the linker expects. ! .IP "\fB\-Wl,\fR\fIoption\fR" 4 .IX Item "-Wl,option" Pass \fIoption\fR as an option to the linker. If \fIoption\fR contains commas, it is split into multiple options at the commas. ! .IP "\fB\-u\fR \fIsymbol\fR" 4 .IX Item "-u symbol" Pretend the symbol \fIsymbol\fR is undefined, to force linking of library modules to define it. You can use \fB\-u\fR multiple times with *************** different symbols to force loading of ad *** 3782,3788 **** .IX Subsection "Options for Directory Search" These options specify directories to search for header files, for libraries and for parts of the compiler: ! .Ip "\fB\-I\fR\fIdir\fR" 4 .IX Item "-Idir" Add the directory \fIdir\fR to the head of the list of directories to be searched for header files. This can be used to override a system header --- 3784,3790 ---- .IX Subsection "Options for Directory Search" These options specify directories to search for header files, for libraries and for parts of the compiler: ! .IP "\fB\-I\fR\fIdir\fR" 4 .IX Item "-Idir" Add the directory \fIdir\fR to the head of the list of directories to be searched for header files. This can be used to override a system header *************** not use this option to add directories t *** 3792,3798 **** system header files (use \fB\-isystem\fR for that). If you use more than one \fB\-I\fR option, the directories are scanned in left-to-right order; the standard system directories come after. ! .Ip "\fB\-I-\fR" 4 .IX Item "-I-" Any directories you specify with \fB\-I\fR options before the \fB\-I-\fR option are searched only for the case of \fB#include "\fR\fIfile\fR\fB"\fR; --- 3794,3800 ---- system header files (use \fB\-isystem\fR for that). If you use more than one \fB\-I\fR option, the directories are scanned in left-to-right order; the standard system directories come after. ! .IP "\fB\-I-\fR" 4 .IX Item "-I-" Any directories you specify with \fB\-I\fR options before the \fB\-I-\fR option are searched only for the case of \fB#include "\fR\fIfile\fR\fB"\fR; *************** by default, but it is often satisfactory *** 3814,3824 **** \&\fB\-I-\fR does not inhibit the use of the standard system directories for header files. Thus, \fB\-I-\fR and \fB\-nostdinc\fR are independent. ! .Ip "\fB\-L\fR\fIdir\fR" 4 .IX Item "-Ldir" Add directory \fIdir\fR to the list of directories to be searched for \fB\-l\fR. ! .Ip "\fB\-B\fR\fIprefix\fR" 4 .IX Item "-Bprefix" This option specifies where to find the executables, libraries, include files, and data files of the compiler itself. --- 3816,3826 ---- \&\fB\-I-\fR does not inhibit the use of the standard system directories for header files. Thus, \fB\-I-\fR and \fB\-nostdinc\fR are independent. ! .IP "\fB\-L\fR\fIdir\fR" 4 .IX Item "-Ldir" Add directory \fIdir\fR to the list of directories to be searched for \fB\-l\fR. ! .IP "\fB\-B\fR\fIprefix\fR" 4 .IX Item "-Bprefix" This option specifies where to find the executables, libraries, include files, and data files of the compiler itself. *************** out of the link if it is not found by th *** 3850,3856 **** .Sp Another way to specify a prefix much like the \fB\-B\fR prefix is to use the environment variable \fB\s-1GCC_EXEC_PREFIX\s0\fR. ! .Ip "\fB\-specs=\fR\fIfile\fR" 4 .IX Item "-specs=file" Process \fIfile\fR after the compiler reads in the standard \fIspecs\fR file, in order to override the defaults that the \fIgcc\fR driver --- 3852,3858 ---- .Sp Another way to specify a prefix much like the \fB\-B\fR prefix is to use the environment variable \fB\s-1GCC_EXEC_PREFIX\s0\fR. ! .IP "\fB\-specs=\fR\fIfile\fR" 4 .IX Item "-specs=file" Process \fIfile\fR after the compiler reads in the standard \fIspecs\fR file, in order to override the defaults that the \fIgcc\fR driver *************** installed side by side. Then you specif *** 3870,3876 **** In addition, older and newer versions of \s-1GCC\s0 can be installed side by side. One of them (probably the newest) will be the default, but you may sometimes wish to use another. ! .Ip "\fB\-b\fR \fImachine\fR" 4 .IX Item "-b machine" The argument \fImachine\fR specifies the target machine for compilation. This is useful when you have installed \s-1GCC\s0 as a cross-compiler. --- 3872,3878 ---- In addition, older and newer versions of \s-1GCC\s0 can be installed side by side. One of them (probably the newest) will be the default, but you may sometimes wish to use another. ! .IP "\fB\-b\fR \fImachine\fR" 4 .IX Item "-b machine" The argument \fImachine\fR specifies the target machine for compilation. This is useful when you have installed \s-1GCC\s0 as a cross-compiler. *************** would specify \fB\-b i386v\fR to run tha *** 3883,3889 **** .Sp When you do not specify \fB\-b\fR, it normally means to compile for the same type of machine that you are using. ! .Ip "\fB\-V\fR \fIversion\fR" 4 .IX Item "-V version" The argument \fIversion\fR specifies which version of \s-1GCC\s0 to run. This is useful when multiple versions are installed. For example, --- 3885,3891 ---- .Sp When you do not specify \fB\-b\fR, it normally means to compile for the same type of machine that you are using. ! .IP "\fB\-V\fR \fIversion\fR" 4 .IX Item "-V version" The argument \fIversion\fR specifies which version of \s-1GCC\s0 to run. This is useful when multiple versions are installed. For example, *************** These are the \fB\-m\fR options defined *** 3958,3967 **** values for these options depends on which style of 68000 was selected when the compiler was configured; the defaults for the most common choices are given below. ! .Ip "\fB\-m68000\fR" 4 .IX Item "-m68000" .PD 0 ! .Ip "\fB\-mc68000\fR" 4 .IX Item "-mc68000" .PD Generate output for a 68000. This is the default --- 3960,3969 ---- values for these options depends on which style of 68000 was selected when the compiler was configured; the defaults for the most common choices are given below. ! .IP "\fB\-m68000\fR" 4 .IX Item "-m68000" .PD 0 ! .IP "\fB\-mc68000\fR" 4 .IX Item "-mc68000" .PD Generate output for a 68000. This is the default *************** when the compiler is configured for 6800 *** 3969,3992 **** .Sp Use this option for microcontrollers with a 68000 or \s-1EC000\s0 core, including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356. ! .Ip "\fB\-m68020\fR" 4 .IX Item "-m68020" .PD 0 ! .Ip "\fB\-mc68020\fR" 4 .IX Item "-mc68020" .PD Generate output for a 68020. This is the default when the compiler is configured for 68020\-based systems. ! .Ip "\fB\-m68881\fR" 4 .IX Item "-m68881" Generate output containing 68881 instructions for floating point. This is the default for most 68020 systems unless \fB\*(--nfp\fR was specified when the compiler was configured. ! .Ip "\fB\-m68030\fR" 4 .IX Item "-m68030" Generate output for a 68030. This is the default when the compiler is configured for 68030\-based systems. ! .Ip "\fB\-m68040\fR" 4 .IX Item "-m68040" Generate output for a 68040. This is the default when the compiler is configured for 68040\-based systems. --- 3971,3994 ---- .Sp Use this option for microcontrollers with a 68000 or \s-1EC000\s0 core, including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356. ! .IP "\fB\-m68020\fR" 4 .IX Item "-m68020" .PD 0 ! .IP "\fB\-mc68020\fR" 4 .IX Item "-mc68020" .PD Generate output for a 68020. This is the default when the compiler is configured for 68020\-based systems. ! .IP "\fB\-m68881\fR" 4 .IX Item "-m68881" Generate output containing 68881 instructions for floating point. This is the default for most 68020 systems unless \fB\*(--nfp\fR was specified when the compiler was configured. ! .IP "\fB\-m68030\fR" 4 .IX Item "-m68030" Generate output for a 68030. This is the default when the compiler is configured for 68030\-based systems. ! .IP "\fB\-m68040\fR" 4 .IX Item "-m68040" Generate output for a 68040. This is the default when the compiler is configured for 68040\-based systems. *************** configured for 68040\-based systems. *** 3994,4000 **** This option inhibits the use of 68881/68882 instructions that have to be emulated by software on the 68040. Use this option if your 68040 does not have code to emulate those instructions. ! .Ip "\fB\-m68060\fR" 4 .IX Item "-m68060" Generate output for a 68060. This is the default when the compiler is configured for 68060\-based systems. --- 3996,4002 ---- This option inhibits the use of 68881/68882 instructions that have to be emulated by software on the 68040. Use this option if your 68040 does not have code to emulate those instructions. ! .IP "\fB\-m68060\fR" 4 .IX Item "-m68060" Generate output for a 68060. This is the default when the compiler is configured for 68060\-based systems. *************** configured for 68060\-based systems. *** 4002,4008 **** This option inhibits the use of 68020 and 68881/68882 instructions that have to be emulated by software on the 68060. Use this option if your 68060 does not have code to emulate those instructions. ! .Ip "\fB\-mcpu32\fR" 4 .IX Item "-mcpu32" Generate output for a \s-1CPU32\s0. This is the default when the compiler is configured for CPU32\-based systems. --- 4004,4010 ---- This option inhibits the use of 68020 and 68881/68882 instructions that have to be emulated by software on the 68060. Use this option if your 68060 does not have code to emulate those instructions. ! .IP "\fB\-mcpu32\fR" 4 .IX Item "-mcpu32" Generate output for a \s-1CPU32\s0. This is the default when the compiler is configured for CPU32\-based systems. *************** when the compiler is configured for CPU3 *** 4010,4038 **** Use this option for microcontrollers with a \&\s-1CPU32\s0 or \s-1CPU32+\s0 core, including the 68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349 and 68360. ! .Ip "\fB\-m5200\fR" 4 .IX Item "-m5200" Generate output for a 520X ``coldfire'' family cpu. This is the default when the compiler is configured for 520X-based systems. .Sp Use this option for microcontroller with a 5200 core, including the \s-1MCF5202\s0, \s-1MCF5203\s0, \s-1MCF5204\s0 and \s-1MCF5202\s0. ! .Ip "\fB\-m68020\-40\fR" 4 .IX Item "-m68020-40" Generate output for a 68040, without using any of the new instructions. This results in code which can run relatively efficiently on either a 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68040. ! .Ip "\fB\-m68020\-60\fR" 4 .IX Item "-m68020-60" Generate output for a 68060, without using any of the new instructions. This results in code which can run relatively efficiently on either a 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68060. ! .Ip "\fB\-mfpa\fR" 4 .IX Item "-mfpa" Generate output containing Sun \s-1FPA\s0 instructions for floating point. ! .Ip "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries are not available for all m68k --- 4012,4040 ---- Use this option for microcontrollers with a \&\s-1CPU32\s0 or \s-1CPU32+\s0 core, including the 68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349 and 68360. ! .IP "\fB\-m5200\fR" 4 .IX Item "-m5200" Generate output for a 520X ``coldfire'' family cpu. This is the default when the compiler is configured for 520X-based systems. .Sp Use this option for microcontroller with a 5200 core, including the \s-1MCF5202\s0, \s-1MCF5203\s0, \s-1MCF5204\s0 and \s-1MCF5202\s0. ! .IP "\fB\-m68020\-40\fR" 4 .IX Item "-m68020-40" Generate output for a 68040, without using any of the new instructions. This results in code which can run relatively efficiently on either a 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68040. ! .IP "\fB\-m68020\-60\fR" 4 .IX Item "-m68020-60" Generate output for a 68060, without using any of the new instructions. This results in code which can run relatively efficiently on either a 68020/68881 or a 68030 or a 68040. The generated code does use the 68881 instructions that are emulated on the 68060. ! .IP "\fB\-mfpa\fR" 4 .IX Item "-mfpa" Generate output containing Sun \s-1FPA\s0 instructions for floating point. ! .IP "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries are not available for all m68k *************** used, but this can't be done directly in *** 4041,4059 **** make your own arrangements to provide suitable library functions for cross-compilation. The embedded targets \fBm68k-*\-aout\fR and \&\fBm68k-*\-coff\fR do provide software floating point support. ! .Ip "\fB\-mshort\fR" 4 .IX Item "-mshort" Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR. ! .Ip "\fB\-mnobitfield\fR" 4 .IX Item "-mnobitfield" Do not use the bit-field instructions. The \fB\-m68000\fR, \fB\-mcpu32\fR and \fB\-m5200\fR options imply \fB\-mnobitfield\fR. ! .Ip "\fB\-mbitfield\fR" 4 .IX Item "-mbitfield" Do use the bit-field instructions. The \fB\-m68020\fR option implies \&\fB\-mbitfield\fR. This is the default if you use a configuration designed for a 68020. ! .Ip "\fB\-mrtd\fR" 4 .IX Item "-mrtd" Use a different function-calling convention, in which functions that take a fixed number of arguments return with the \f(CW\*(C`rtd\*(C'\fR --- 4043,4061 ---- make your own arrangements to provide suitable library functions for cross-compilation. The embedded targets \fBm68k-*\-aout\fR and \&\fBm68k-*\-coff\fR do provide software floating point support. ! .IP "\fB\-mshort\fR" 4 .IX Item "-mshort" Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR. ! .IP "\fB\-mnobitfield\fR" 4 .IX Item "-mnobitfield" Do not use the bit-field instructions. The \fB\-m68000\fR, \fB\-mcpu32\fR and \fB\-m5200\fR options imply \fB\-mnobitfield\fR. ! .IP "\fB\-mbitfield\fR" 4 .IX Item "-mbitfield" Do use the bit-field instructions. The \fB\-m68020\fR option implies \&\fB\-mbitfield\fR. This is the default if you use a configuration designed for a 68020. ! .IP "\fB\-mrtd\fR" 4 .IX Item "-mrtd" Use a different function-calling convention, in which functions that take a fixed number of arguments return with the \f(CW\*(C`rtd\*(C'\fR *************** harmlessly ignored.) *** 4076,4085 **** .Sp The \f(CW\*(C`rtd\*(C'\fR instruction is supported by the 68010, 68020, 68030, 68040, 68060 and \s-1CPU32\s0 processors, but not by the 68000 or 5200. ! .Ip "\fB\-malign-int\fR" 4 .IX Item "-malign-int" .PD 0 ! .Ip "\fB\-mno-align-int\fR" 4 .IX Item "-mno-align-int" .PD Control whether \s-1GCC\s0 aligns \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`long long\*(C'\fR, --- 4078,4087 ---- .Sp The \f(CW\*(C`rtd\*(C'\fR instruction is supported by the 68010, 68020, 68030, 68040, 68060 and \s-1CPU32\s0 processors, but not by the 68000 or 5200. ! .IP "\fB\-malign-int\fR" 4 .IX Item "-malign-int" .PD 0 ! .IP "\fB\-mno-align-int\fR" 4 .IX Item "-mno-align-int" .PD Control whether \s-1GCC\s0 aligns \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`long long\*(C'\fR, *************** faster on processors with 32\-bit busses *** 4091,4107 **** \&\fBWarning:\fR if you use the \fB\-malign-int\fR switch, \s-1GCC\s0 will align structures containing the above types differently than most published application binary interface specifications for the m68k. ! .Ip "\fB\-mpcrel\fR" 4 .IX Item "-mpcrel" Use the pc-relative addressing mode of the 68000 directly, instead of using a global offset table. At present, this option implies \fB\-fpic\fR, allowing at most a 16\-bit offset for pc-relative addressing. \fB\-fPIC\fR is not presently supported with \fB\-mpcrel\fR, though this could be supported for 68020 and higher processors. ! .Ip "\fB\-mno-strict-align\fR" 4 .IX Item "-mno-strict-align" .PD 0 ! .Ip "\fB\-mstrict-align\fR" 4 .IX Item "-mstrict-align" .PD Do not (do) assume that unaligned memory references will be handled by --- 4093,4109 ---- \&\fBWarning:\fR if you use the \fB\-malign-int\fR switch, \s-1GCC\s0 will align structures containing the above types differently than most published application binary interface specifications for the m68k. ! .IP "\fB\-mpcrel\fR" 4 .IX Item "-mpcrel" Use the pc-relative addressing mode of the 68000 directly, instead of using a global offset table. At present, this option implies \fB\-fpic\fR, allowing at most a 16\-bit offset for pc-relative addressing. \fB\-fPIC\fR is not presently supported with \fB\-mpcrel\fR, though this could be supported for 68020 and higher processors. ! .IP "\fB\-mno-strict-align\fR" 4 .IX Item "-mno-strict-align" .PD 0 ! .IP "\fB\-mstrict-align\fR" 4 .IX Item "-mstrict-align" .PD Do not (do) assume that unaligned memory references will be handled by *************** These are the \fB\-m\fR options defined *** 4114,4143 **** microcontrollers. The default values for these options depends on which style of microcontroller was selected when the compiler was configured; the defaults for the most common choices are given below. ! .Ip "\fB\-m6811\fR" 4 .IX Item "-m6811" .PD 0 ! .Ip "\fB\-m68hc11\fR" 4 .IX Item "-m68hc11" .PD Generate output for a 68HC11. This is the default when the compiler is configured for 68HC11\-based systems. ! .Ip "\fB\-m6812\fR" 4 .IX Item "-m6812" .PD 0 ! .Ip "\fB\-m68hc12\fR" 4 .IX Item "-m68hc12" .PD Generate output for a 68HC12. This is the default when the compiler is configured for 68HC12\-based systems. ! .Ip "\fB\-mauto-incdec\fR" 4 .IX Item "-mauto-incdec" Enable the use of 68HC12 pre and post auto-increment and auto-decrement addressing modes. ! .Ip "\fB\-mshort\fR" 4 .IX Item "-mshort" Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR. ! .Ip "\fB\-msoft-reg-count=\fR\fIcount\fR" 4 .IX Item "-msoft-reg-count=count" Specify the number of pseudo-soft registers which are used for the code generation. The maximum number is 32. Using more pseudo-soft --- 4116,4145 ---- microcontrollers. The default values for these options depends on which style of microcontroller was selected when the compiler was configured; the defaults for the most common choices are given below. ! .IP "\fB\-m6811\fR" 4 .IX Item "-m6811" .PD 0 ! .IP "\fB\-m68hc11\fR" 4 .IX Item "-m68hc11" .PD Generate output for a 68HC11. This is the default when the compiler is configured for 68HC11\-based systems. ! .IP "\fB\-m6812\fR" 4 .IX Item "-m6812" .PD 0 ! .IP "\fB\-m68hc12\fR" 4 .IX Item "-m68hc12" .PD Generate output for a 68HC12. This is the default when the compiler is configured for 68HC12\-based systems. ! .IP "\fB\-mauto-incdec\fR" 4 .IX Item "-mauto-incdec" Enable the use of 68HC12 pre and post auto-increment and auto-decrement addressing modes. ! .IP "\fB\-mshort\fR" 4 .IX Item "-mshort" Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR. ! .IP "\fB\-msoft-reg-count=\fR\fIcount\fR" 4 .IX Item "-msoft-reg-count=count" Specify the number of pseudo-soft registers which are used for the code generation. The maximum number is 32. Using more pseudo-soft *************** The default is 4 for 68HC11 and 2 for 68 *** 4148,4163 **** .IX Subsection "VAX Options" .PP These \fB\-m\fR options are defined for the Vax: ! .Ip "\fB\-munix\fR" 4 .IX Item "-munix" Do not output certain jump instructions (\f(CW\*(C`aobleq\*(C'\fR and so on) that the Unix assembler for the Vax cannot handle across long ranges. ! .Ip "\fB\-mgnu\fR" 4 .IX Item "-mgnu" Do output those jump instructions, on the assumption that you will assemble with the \s-1GNU\s0 assembler. ! .Ip "\fB\-mg\fR" 4 .IX Item "-mg" Output code for g-format floating point numbers instead of d-format. .PP --- 4150,4165 ---- .IX Subsection "VAX Options" .PP These \fB\-m\fR options are defined for the Vax: ! .IP "\fB\-munix\fR" 4 .IX Item "-munix" Do not output certain jump instructions (\f(CW\*(C`aobleq\*(C'\fR and so on) that the Unix assembler for the Vax cannot handle across long ranges. ! .IP "\fB\-mgnu\fR" 4 .IX Item "-mgnu" Do output those jump instructions, on the assumption that you will assemble with the \s-1GNU\s0 assembler. ! .IP "\fB\-mg\fR" 4 .IX Item "-mg" Output code for g-format floating point numbers instead of d-format. .PP *************** Output code for g-format floating point *** 4165,4174 **** .IX Subsection "SPARC Options" .PP These \fB\-m\fR switches are supported on the \s-1SPARC:\s0 ! .Ip "\fB\-mno-app-regs\fR" 4 .IX Item "-mno-app-regs" .PD 0 ! .Ip "\fB\-mapp-regs\fR" 4 .IX Item "-mapp-regs" .PD Specify \fB\-mapp-regs\fR to generate output using the global registers --- 4167,4176 ---- .IX Subsection "SPARC Options" .PP These \fB\-m\fR switches are supported on the \s-1SPARC:\s0 ! .IP "\fB\-mno-app-regs\fR" 4 .IX Item "-mno-app-regs" .PD 0 ! .IP "\fB\-mapp-regs\fR" 4 .IX Item "-mapp-regs" .PD Specify \fB\-mapp-regs\fR to generate output using the global registers *************** is the default. *** 4178,4195 **** To be fully \s-1SVR4\s0 \s-1ABI\s0 compliant at the cost of some performance loss, specify \fB\-mno-app-regs\fR. You should compile libraries and system software with this option. ! .Ip "\fB\-mfpu\fR" 4 .IX Item "-mfpu" .PD 0 ! .Ip "\fB\-mhard-float\fR" 4 .IX Item "-mhard-float" .PD Generate output containing floating point instructions. This is the default. ! .Ip "\fB\-mno-fpu\fR" 4 .IX Item "-mno-fpu" .PD 0 ! .Ip "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" .PD Generate output containing library calls for floating point. --- 4180,4197 ---- To be fully \s-1SVR4\s0 \s-1ABI\s0 compliant at the cost of some performance loss, specify \fB\-mno-app-regs\fR. You should compile libraries and system software with this option. ! .IP "\fB\-mfpu\fR" 4 .IX Item "-mfpu" .PD 0 ! .IP "\fB\-mhard-float\fR" 4 .IX Item "-mhard-float" .PD Generate output containing floating point instructions. This is the default. ! .IP "\fB\-mno-fpu\fR" 4 .IX Item "-mno-fpu" .PD 0 ! .IP "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" .PD Generate output containing library calls for floating point. *************** therefore, it is only useful if you comp *** 4205,4215 **** this option. In particular, you need to compile \fIlibgcc.a\fR, the library that comes with \s-1GCC\s0, with \fB\-msoft-float\fR in order for this to work. ! .Ip "\fB\-mhard-quad-float\fR" 4 .IX Item "-mhard-quad-float" Generate output containing quad-word (long double) floating point instructions. ! .Ip "\fB\-msoft-quad-float\fR" 4 .IX Item "-msoft-quad-float" Generate output containing library calls for quad-word (long double) floating point instructions. The functions called are those specified --- 4207,4217 ---- this option. In particular, you need to compile \fIlibgcc.a\fR, the library that comes with \s-1GCC\s0, with \fB\-msoft-float\fR in order for this to work. ! .IP "\fB\-mhard-quad-float\fR" 4 .IX Item "-mhard-quad-float" Generate output containing quad-word (long double) floating point instructions. ! .IP "\fB\-msoft-quad-float\fR" 4 .IX Item "-msoft-quad-float" Generate output containing library calls for quad-word (long double) floating point instructions. The functions called are those specified *************** a trap handler for one of these instruct *** 4221,4230 **** emulates the effect of the instruction. Because of the trap handler overhead, this is much slower than calling the \s-1ABI\s0 library routines. Thus the \&\fB\-msoft-quad-float\fR option is the default. ! .Ip "\fB\-mno-epilogue\fR" 4 .IX Item "-mno-epilogue" .PD 0 ! .Ip "\fB\-mepilogue\fR" 4 .IX Item "-mepilogue" .PD With \fB\-mepilogue\fR (the default), the compiler always emits code for --- 4223,4232 ---- emulates the effect of the instruction. Because of the trap handler overhead, this is much slower than calling the \s-1ABI\s0 library routines. Thus the \&\fB\-msoft-quad-float\fR option is the default. ! .IP "\fB\-mno-epilogue\fR" 4 .IX Item "-mno-epilogue" .PD 0 ! .IP "\fB\-mepilogue\fR" 4 .IX Item "-mepilogue" .PD With \fB\-mepilogue\fR (the default), the compiler always emits code for *************** generate a jump to the exit code at the *** 4234,4243 **** .Sp With \fB\-mno-epilogue\fR, the compiler tries to emit exit code inline at every function exit. ! .Ip "\fB\-mno-flat\fR" 4 .IX Item "-mno-flat" .PD 0 ! .Ip "\fB\-mflat\fR" 4 .IX Item "-mflat" .PD With \fB\-mflat\fR, the compiler does not generate save/restore instructions --- 4236,4245 ---- .Sp With \fB\-mno-epilogue\fR, the compiler tries to emit exit code inline at every function exit. ! .IP "\fB\-mno-flat\fR" 4 .IX Item "-mno-flat" .PD 0 ! .IP "\fB\-mflat\fR" 4 .IX Item "-mflat" .PD With \fB\-mflat\fR, the compiler does not generate save/restore instructions *************** The local registers and the input regist *** 4249,4258 **** .Sp With \fB\-mno-flat\fR (the default), the compiler emits save/restore instructions (except for leaf functions) and is the normal mode of operation. ! .Ip "\fB\-mno-unaligned-doubles\fR" 4 .IX Item "-mno-unaligned-doubles" .PD 0 ! .Ip "\fB\-munaligned-doubles\fR" 4 .IX Item "-munaligned-doubles" .PD Assume that doubles have 8 byte alignment. This is the default. --- 4251,4260 ---- .Sp With \fB\-mno-flat\fR (the default), the compiler emits save/restore instructions (except for leaf functions) and is the normal mode of operation. ! .IP "\fB\-mno-unaligned-doubles\fR" 4 .IX Item "-mno-unaligned-doubles" .PD 0 ! .IP "\fB\-munaligned-doubles\fR" 4 .IX Item "-munaligned-doubles" .PD Assume that doubles have 8 byte alignment. This is the default. *************** absolute address. Otherwise, it assumes *** 4263,4272 **** Specifying this option avoids some rare compatibility problems with code generated by other compilers. It is not the default because it results in a performance loss, especially for floating point code. ! .Ip "\fB\-mno-faster-structs\fR" 4 .IX Item "-mno-faster-structs" .PD 0 ! .Ip "\fB\-mfaster-structs\fR" 4 .IX Item "-mfaster-structs" .PD With \fB\-mfaster-structs\fR, the compiler assumes that structures --- 4265,4274 ---- Specifying this option avoids some rare compatibility problems with code generated by other compilers. It is not the default because it results in a performance loss, especially for floating point code. ! .IP "\fB\-mno-faster-structs\fR" 4 .IX Item "-mno-faster-structs" .PD 0 ! .IP "\fB\-mfaster-structs\fR" 4 .IX Item "-mfaster-structs" .PD With \fB\-mfaster-structs\fR, the compiler assumes that structures *************** However, the use of this changed alignme *** 4277,4286 **** \&\s-1ABI\s0. Thus, it's intended only for use on targets where the developer acknowledges that their resulting code will not be directly in line with the rules of the \s-1ABI\s0. ! .Ip "\fB\-mv8\fR" 4 .IX Item "-mv8" .PD 0 ! .Ip "\fB\-msparclite\fR" 4 .IX Item "-msparclite" .PD These two options select variations on the \s-1SPARC\s0 architecture. --- 4279,4288 ---- \&\s-1ABI\s0. Thus, it's intended only for use on targets where the developer acknowledges that their resulting code will not be directly in line with the rules of the \s-1ABI\s0. ! .IP "\fB\-mv8\fR" 4 .IX Item "-mv8" .PD 0 ! .IP "\fB\-msparclite\fR" 4 .IX Item "-msparclite" .PD These two options select variations on the \s-1SPARC\s0 architecture. *************** exist in SPARClite but not in \s-1SPARC\ *** 4298,4307 **** .Sp These options are deprecated and will be deleted in a future \s-1GCC\s0 release. They have been replaced with \fB\-mcpu=xxx\fR. ! .Ip "\fB\-mcypress\fR" 4 .IX Item "-mcypress" .PD 0 ! .Ip "\fB\-msupersparc\fR" 4 .IX Item "-msupersparc" .PD These two options select the processor for which the code is optimised. --- 4300,4309 ---- .Sp These options are deprecated and will be deleted in a future \s-1GCC\s0 release. They have been replaced with \fB\-mcpu=xxx\fR. ! .IP "\fB\-mcypress\fR" 4 .IX Item "-mcypress" .PD 0 ! .IP "\fB\-msupersparc\fR" 4 .IX Item "-msupersparc" .PD These two options select the processor for which the code is optimised. *************** of the full \s-1SPARC\s0 v8 instruction *** 4316,4322 **** .Sp These options are deprecated and will be deleted in a future \s-1GCC\s0 release. They have been replaced with \fB\-mcpu=xxx\fR. ! .Ip "\fB\-mcpu=\fR\fIcpu_type\fR" 4 .IX Item "-mcpu=cpu_type" Set the instruction set, register set, and instruction scheduling parameters for machine type \fIcpu_type\fR. Supported values for \fIcpu_type\fR are --- 4318,4324 ---- .Sp These options are deprecated and will be deleted in a future \s-1GCC\s0 release. They have been replaced with \fB\-mcpu=xxx\fR. ! .IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4 .IX Item "-mcpu=cpu_type" Set the instruction set, register set, and instruction scheduling parameters for machine type \fIcpu_type\fR. Supported values for \fIcpu_type\fR are *************** implementations. *** 4338,4344 **** \& sparclet: tsc701 \& v9: ultrasparc .Ve ! .Ip "\fB\-mtune=\fR\fIcpu_type\fR" 4 .IX Item "-mtune=cpu_type" Set the instruction scheduling parameters for machine type \&\fIcpu_type\fR, but do not set the instruction set or register set that the --- 4340,4346 ---- \& sparclet: tsc701 \& v9: ultrasparc .Ve ! .IP "\fB\-mtune=\fR\fIcpu_type\fR" 4 .IX Item "-mtune=cpu_type" Set the instruction scheduling parameters for machine type \&\fIcpu_type\fR, but do not set the instruction set or register set that the *************** select a particular cpu implementation: *** 4352,4366 **** .PP These \fB\-m\fR switches are supported in addition to the above on the \s-1SPARCLET\s0 processor. ! .Ip "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" Generate code for a processor running in little-endian mode. ! .Ip "\fB\-mlive-g0\fR" 4 .IX Item "-mlive-g0" ! Treat register \f(CW\*(C`%g0\*(C'\fR as a normal register. \&\s-1GCC\s0 will continue to clobber it as necessary but will not assume it always reads as 0. ! .Ip "\fB\-mbroken-saverestore\fR" 4 .IX Item "-mbroken-saverestore" Generate code that does not use non-trivial forms of the \f(CW\*(C`save\*(C'\fR and \&\f(CW\*(C`restore\*(C'\fR instructions. Early versions of the \s-1SPARCLET\s0 processor do --- 4354,4368 ---- .PP These \fB\-m\fR switches are supported in addition to the above on the \s-1SPARCLET\s0 processor. ! .IP "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" Generate code for a processor running in little-endian mode. ! .IP "\fB\-mlive-g0\fR" 4 .IX Item "-mlive-g0" ! Treat register \f(CW%g0\fR as a normal register. \&\s-1GCC\s0 will continue to clobber it as necessary but will not assume it always reads as 0. ! .IP "\fB\-mbroken-saverestore\fR" 4 .IX Item "-mbroken-saverestore" Generate code that does not use non-trivial forms of the \f(CW\*(C`save\*(C'\fR and \&\f(CW\*(C`restore\*(C'\fR instructions. Early versions of the \s-1SPARCLET\s0 processor do *************** handlers. *** 4373,4419 **** .PP These \fB\-m\fR switches are supported in addition to the above on \s-1SPARC\s0 V9 processors in 64\-bit environments. ! .Ip "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" Generate code for a processor running in little-endian mode. ! .Ip "\fB\-m32\fR" 4 .IX Item "-m32" .PD 0 ! .Ip "\fB\-m64\fR" 4 .IX Item "-m64" .PD Generate code for a 32\-bit or 64\-bit environment. The 32\-bit environment sets int, long and pointer to 32 bits. The 64\-bit environment sets int to 32 bits and long and pointer to 64 bits. ! .Ip "\fB\-mcmodel=medlow\fR" 4 .IX Item "-mcmodel=medlow" Generate code for the Medium/Low code model: the program must be linked in the low 32 bits of the address space. Pointers are 64 bits. Programs can be statically or dynamically linked. ! .Ip "\fB\-mcmodel=medmid\fR" 4 .IX Item "-mcmodel=medmid" Generate code for the Medium/Middle code model: the program must be linked in the low 44 bits of the address space, the text segment must be less than 2G bytes, and data segment must be within 2G of the text segment. Pointers are 64 bits. ! .Ip "\fB\-mcmodel=medany\fR" 4 .IX Item "-mcmodel=medany" Generate code for the Medium/Anywhere code model: the program may be linked anywhere in the address space, the text segment must be less than 2G bytes, and data segment must be within 2G of the text segment. Pointers are 64 bits. ! .Ip "\fB\-mcmodel=embmedany\fR" 4 .IX Item "-mcmodel=embmedany" Generate code for the Medium/Anywhere code model for embedded systems: assume a 32\-bit text and a 32\-bit data segment, both starting anywhere (determined at link time). Register \f(CW%g4\fR points to the base of the data segment. Pointers are still 64 bits. Programs are statically linked, \s-1PIC\s0 is not supported. ! .Ip "\fB\-mstack-bias\fR" 4 .IX Item "-mstack-bias" .PD 0 ! .Ip "\fB\-mno-stack-bias\fR" 4 .IX Item "-mno-stack-bias" .PD With \fB\-mstack-bias\fR, \s-1GCC\s0 assumes that the stack pointer, and --- 4375,4421 ---- .PP These \fB\-m\fR switches are supported in addition to the above on \s-1SPARC\s0 V9 processors in 64\-bit environments. ! .IP "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" Generate code for a processor running in little-endian mode. ! .IP "\fB\-m32\fR" 4 .IX Item "-m32" .PD 0 ! .IP "\fB\-m64\fR" 4 .IX Item "-m64" .PD Generate code for a 32\-bit or 64\-bit environment. The 32\-bit environment sets int, long and pointer to 32 bits. The 64\-bit environment sets int to 32 bits and long and pointer to 64 bits. ! .IP "\fB\-mcmodel=medlow\fR" 4 .IX Item "-mcmodel=medlow" Generate code for the Medium/Low code model: the program must be linked in the low 32 bits of the address space. Pointers are 64 bits. Programs can be statically or dynamically linked. ! .IP "\fB\-mcmodel=medmid\fR" 4 .IX Item "-mcmodel=medmid" Generate code for the Medium/Middle code model: the program must be linked in the low 44 bits of the address space, the text segment must be less than 2G bytes, and data segment must be within 2G of the text segment. Pointers are 64 bits. ! .IP "\fB\-mcmodel=medany\fR" 4 .IX Item "-mcmodel=medany" Generate code for the Medium/Anywhere code model: the program may be linked anywhere in the address space, the text segment must be less than 2G bytes, and data segment must be within 2G of the text segment. Pointers are 64 bits. ! .IP "\fB\-mcmodel=embmedany\fR" 4 .IX Item "-mcmodel=embmedany" Generate code for the Medium/Anywhere code model for embedded systems: assume a 32\-bit text and a 32\-bit data segment, both starting anywhere (determined at link time). Register \f(CW%g4\fR points to the base of the data segment. Pointers are still 64 bits. Programs are statically linked, \s-1PIC\s0 is not supported. ! .IP "\fB\-mstack-bias\fR" 4 .IX Item "-mstack-bias" .PD 0 ! .IP "\fB\-mno-stack-bias\fR" 4 .IX Item "-mno-stack-bias" .PD With \fB\-mstack-bias\fR, \s-1GCC\s0 assumes that the stack pointer, and *************** Otherwise, assume no such offset is pres *** 4425,4476 **** .IX Subsection "Convex Options" .PP These \fB\-m\fR options are defined for Convex: ! .Ip "\fB\-mc1\fR" 4 .IX Item "-mc1" Generate output for C1. The code will run on any Convex machine. The preprocessor symbol \f(CW\*(C`_\|_convex_\|_c1_\|_\*(C'\fR is defined. ! .Ip "\fB\-mc2\fR" 4 .IX Item "-mc2" Generate output for C2. Uses instructions not available on C1. Scheduling and other optimizations are chosen for max performance on C2. The preprocessor symbol \f(CW\*(C`_\|_convex_c2_\|_\*(C'\fR is defined. ! .Ip "\fB\-mc32\fR" 4 .IX Item "-mc32" Generate output for C32xx. Uses instructions not available on C1. Scheduling and other optimizations are chosen for max performance on C32. The preprocessor symbol \f(CW\*(C`_\|_convex_c32_\|_\*(C'\fR is defined. ! .Ip "\fB\-mc34\fR" 4 .IX Item "-mc34" Generate output for C34xx. Uses instructions not available on C1. Scheduling and other optimizations are chosen for max performance on C34. The preprocessor symbol \f(CW\*(C`_\|_convex_c34_\|_\*(C'\fR is defined. ! .Ip "\fB\-mc38\fR" 4 .IX Item "-mc38" Generate output for C38xx. Uses instructions not available on C1. Scheduling and other optimizations are chosen for max performance on C38. The preprocessor symbol \f(CW\*(C`_\|_convex_c38_\|_\*(C'\fR is defined. ! .Ip "\fB\-margcount\fR" 4 .IX Item "-margcount" Generate code which puts an argument count in the word preceding each argument list. This is compatible with regular \s-1CC\s0, and a few programs may need the argument count word. \s-1GDB\s0 and other source-level debuggers do not need it; this info is in the symbol table. ! .Ip "\fB\-mnoargcount\fR" 4 .IX Item "-mnoargcount" Omit the argument count word. This is the default. ! .Ip "\fB\-mvolatile-cache\fR" 4 .IX Item "-mvolatile-cache" Allow volatile references to be cached. This is the default. ! .Ip "\fB\-mvolatile-nocache\fR" 4 .IX Item "-mvolatile-nocache" Volatile references bypass the data cache, going all the way to memory. This is only needed for multi-processor code that does not use standard synchronization instructions. Making non-volatile references to volatile locations will not necessarily work. ! .Ip "\fB\-mlong32\fR" 4 .IX Item "-mlong32" Type long is 32 bits, the same as type int. This is the default. ! .Ip "\fB\-mlong64\fR" 4 .IX Item "-mlong64" Type long is 64 bits, the same as type long long. This option is useless, because no library support exists for it. --- 4427,4478 ---- .IX Subsection "Convex Options" .PP These \fB\-m\fR options are defined for Convex: ! .IP "\fB\-mc1\fR" 4 .IX Item "-mc1" Generate output for C1. The code will run on any Convex machine. The preprocessor symbol \f(CW\*(C`_\|_convex_\|_c1_\|_\*(C'\fR is defined. ! .IP "\fB\-mc2\fR" 4 .IX Item "-mc2" Generate output for C2. Uses instructions not available on C1. Scheduling and other optimizations are chosen for max performance on C2. The preprocessor symbol \f(CW\*(C`_\|_convex_c2_\|_\*(C'\fR is defined. ! .IP "\fB\-mc32\fR" 4 .IX Item "-mc32" Generate output for C32xx. Uses instructions not available on C1. Scheduling and other optimizations are chosen for max performance on C32. The preprocessor symbol \f(CW\*(C`_\|_convex_c32_\|_\*(C'\fR is defined. ! .IP "\fB\-mc34\fR" 4 .IX Item "-mc34" Generate output for C34xx. Uses instructions not available on C1. Scheduling and other optimizations are chosen for max performance on C34. The preprocessor symbol \f(CW\*(C`_\|_convex_c34_\|_\*(C'\fR is defined. ! .IP "\fB\-mc38\fR" 4 .IX Item "-mc38" Generate output for C38xx. Uses instructions not available on C1. Scheduling and other optimizations are chosen for max performance on C38. The preprocessor symbol \f(CW\*(C`_\|_convex_c38_\|_\*(C'\fR is defined. ! .IP "\fB\-margcount\fR" 4 .IX Item "-margcount" Generate code which puts an argument count in the word preceding each argument list. This is compatible with regular \s-1CC\s0, and a few programs may need the argument count word. \s-1GDB\s0 and other source-level debuggers do not need it; this info is in the symbol table. ! .IP "\fB\-mnoargcount\fR" 4 .IX Item "-mnoargcount" Omit the argument count word. This is the default. ! .IP "\fB\-mvolatile-cache\fR" 4 .IX Item "-mvolatile-cache" Allow volatile references to be cached. This is the default. ! .IP "\fB\-mvolatile-nocache\fR" 4 .IX Item "-mvolatile-nocache" Volatile references bypass the data cache, going all the way to memory. This is only needed for multi-processor code that does not use standard synchronization instructions. Making non-volatile references to volatile locations will not necessarily work. ! .IP "\fB\-mlong32\fR" 4 .IX Item "-mlong32" Type long is 32 bits, the same as type int. This is the default. ! .IP "\fB\-mlong64\fR" 4 .IX Item "-mlong64" Type long is 64 bits, the same as type long long. This option is useless, because no library support exists for it. *************** because no library support exists for it *** 4479,4523 **** .IX Subsection "AMD29K Options" .PP These \fB\-m\fR options are defined for the \s-1AMD\s0 Am29000: ! .Ip "\fB\-mdw\fR" 4 .IX Item "-mdw" Generate code that assumes the \f(CW\*(C`DW\*(C'\fR bit is set, i.e., that byte and halfword operations are directly supported by the hardware. This is the default. ! .Ip "\fB\-mndw\fR" 4 .IX Item "-mndw" Generate code that assumes the \f(CW\*(C`DW\*(C'\fR bit is not set. ! .Ip "\fB\-mbw\fR" 4 .IX Item "-mbw" Generate code that assumes the system supports byte and halfword write operations. This is the default. ! .Ip "\fB\-mnbw\fR" 4 .IX Item "-mnbw" Generate code that assumes the systems does not support byte and halfword write operations. \fB\-mnbw\fR implies \fB\-mndw\fR. ! .Ip "\fB\-msmall\fR" 4 .IX Item "-msmall" Use a small memory model that assumes that all function addresses are either within a single 256 \s-1KB\s0 segment or at an absolute address of less than 256k. This allows the \f(CW\*(C`call\*(C'\fR instruction to be used instead of a \f(CW\*(C`const\*(C'\fR, \f(CW\*(C`consth\*(C'\fR, \f(CW\*(C`calli\*(C'\fR sequence. ! .Ip "\fB\-mnormal\fR" 4 .IX Item "-mnormal" Use the normal memory model: Generate \f(CW\*(C`call\*(C'\fR instructions only when calling functions in the same file and \f(CW\*(C`calli\*(C'\fR instructions otherwise. This works if each file occupies less than 256 \s-1KB\s0 but allows the entire executable to be larger than 256 \s-1KB\s0. This is the default. ! .Ip "\fB\-mlarge\fR" 4 .IX Item "-mlarge" Always use \f(CW\*(C`calli\*(C'\fR instructions. Specify this option if you expect a single file to compile into more than 256 \s-1KB\s0 of code. ! .Ip "\fB\-m29050\fR" 4 .IX Item "-m29050" Generate code for the Am29050. ! .Ip "\fB\-m29000\fR" 4 .IX Item "-m29000" Generate code for the Am29000. This is the default. ! .Ip "\fB\-mkernel-registers\fR" 4 .IX Item "-mkernel-registers" Generate references to registers \f(CW\*(C`gr64\-gr95\*(C'\fR instead of to registers \f(CW\*(C`gr96\-gr127\*(C'\fR. This option can be used when compiling --- 4481,4525 ---- .IX Subsection "AMD29K Options" .PP These \fB\-m\fR options are defined for the \s-1AMD\s0 Am29000: ! .IP "\fB\-mdw\fR" 4 .IX Item "-mdw" Generate code that assumes the \f(CW\*(C`DW\*(C'\fR bit is set, i.e., that byte and halfword operations are directly supported by the hardware. This is the default. ! .IP "\fB\-mndw\fR" 4 .IX Item "-mndw" Generate code that assumes the \f(CW\*(C`DW\*(C'\fR bit is not set. ! .IP "\fB\-mbw\fR" 4 .IX Item "-mbw" Generate code that assumes the system supports byte and halfword write operations. This is the default. ! .IP "\fB\-mnbw\fR" 4 .IX Item "-mnbw" Generate code that assumes the systems does not support byte and halfword write operations. \fB\-mnbw\fR implies \fB\-mndw\fR. ! .IP "\fB\-msmall\fR" 4 .IX Item "-msmall" Use a small memory model that assumes that all function addresses are either within a single 256 \s-1KB\s0 segment or at an absolute address of less than 256k. This allows the \f(CW\*(C`call\*(C'\fR instruction to be used instead of a \f(CW\*(C`const\*(C'\fR, \f(CW\*(C`consth\*(C'\fR, \f(CW\*(C`calli\*(C'\fR sequence. ! .IP "\fB\-mnormal\fR" 4 .IX Item "-mnormal" Use the normal memory model: Generate \f(CW\*(C`call\*(C'\fR instructions only when calling functions in the same file and \f(CW\*(C`calli\*(C'\fR instructions otherwise. This works if each file occupies less than 256 \s-1KB\s0 but allows the entire executable to be larger than 256 \s-1KB\s0. This is the default. ! .IP "\fB\-mlarge\fR" 4 .IX Item "-mlarge" Always use \f(CW\*(C`calli\*(C'\fR instructions. Specify this option if you expect a single file to compile into more than 256 \s-1KB\s0 of code. ! .IP "\fB\-m29050\fR" 4 .IX Item "-m29050" Generate code for the Am29050. ! .IP "\fB\-m29000\fR" 4 .IX Item "-m29000" Generate code for the Am29000. This is the default. ! .IP "\fB\-mkernel-registers\fR" 4 .IX Item "-mkernel-registers" Generate references to registers \f(CW\*(C`gr64\-gr95\*(C'\fR instead of to registers \f(CW\*(C`gr96\-gr127\*(C'\fR. This option can be used when compiling *************** by user-mode code. *** 4526,4570 **** .Sp Note that when this option is used, register names in \fB\-f\fR flags must use the normal, user-mode, names. ! .Ip "\fB\-muser-registers\fR" 4 .IX Item "-muser-registers" Use the normal set of global registers, \f(CW\*(C`gr96\-gr127\*(C'\fR. This is the default. ! .Ip "\fB\-mstack-check\fR" 4 .IX Item "-mstack-check" .PD 0 ! .Ip "\fB\-mno-stack-check\fR" 4 .IX Item "-mno-stack-check" .PD Insert (or do not insert) a call to \f(CW\*(C`_\|_msp_check\*(C'\fR after each stack adjustment. This is often used for kernel code. ! .Ip "\fB\-mstorem-bug\fR" 4 .IX Item "-mstorem-bug" .PD 0 ! .Ip "\fB\-mno-storem-bug\fR" 4 .IX Item "-mno-storem-bug" .PD \&\fB\-mstorem-bug\fR handles 29k processors which cannot handle the separation of a mtsrim insn and a storem instruction (most 29000 chips to date, but not the 29050). ! .Ip "\fB\-mno-reuse-arg-regs\fR" 4 .IX Item "-mno-reuse-arg-regs" .PD 0 ! .Ip "\fB\-mreuse-arg-regs\fR" 4 .IX Item "-mreuse-arg-regs" .PD \&\fB\-mno-reuse-arg-regs\fR tells the compiler to only use incoming argument registers for copying out arguments. This helps detect calling a function with fewer arguments than it was declared with. ! .Ip "\fB\-mno-impure-text\fR" 4 .IX Item "-mno-impure-text" .PD 0 ! .Ip "\fB\-mimpure-text\fR" 4 .IX Item "-mimpure-text" .PD \&\fB\-mimpure-text\fR, used in addition to \fB\-shared\fR, tells the compiler to not pass \fB\-assert pure-text\fR to the linker when linking a shared object. ! .Ip "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries are not part of \s-1GCC\s0. --- 4528,4572 ---- .Sp Note that when this option is used, register names in \fB\-f\fR flags must use the normal, user-mode, names. ! .IP "\fB\-muser-registers\fR" 4 .IX Item "-muser-registers" Use the normal set of global registers, \f(CW\*(C`gr96\-gr127\*(C'\fR. This is the default. ! .IP "\fB\-mstack-check\fR" 4 .IX Item "-mstack-check" .PD 0 ! .IP "\fB\-mno-stack-check\fR" 4 .IX Item "-mno-stack-check" .PD Insert (or do not insert) a call to \f(CW\*(C`_\|_msp_check\*(C'\fR after each stack adjustment. This is often used for kernel code. ! .IP "\fB\-mstorem-bug\fR" 4 .IX Item "-mstorem-bug" .PD 0 ! .IP "\fB\-mno-storem-bug\fR" 4 .IX Item "-mno-storem-bug" .PD \&\fB\-mstorem-bug\fR handles 29k processors which cannot handle the separation of a mtsrim insn and a storem instruction (most 29000 chips to date, but not the 29050). ! .IP "\fB\-mno-reuse-arg-regs\fR" 4 .IX Item "-mno-reuse-arg-regs" .PD 0 ! .IP "\fB\-mreuse-arg-regs\fR" 4 .IX Item "-mreuse-arg-regs" .PD \&\fB\-mno-reuse-arg-regs\fR tells the compiler to only use incoming argument registers for copying out arguments. This helps detect calling a function with fewer arguments than it was declared with. ! .IP "\fB\-mno-impure-text\fR" 4 .IX Item "-mno-impure-text" .PD 0 ! .IP "\fB\-mimpure-text\fR" 4 .IX Item "-mimpure-text" .PD \&\fB\-mimpure-text\fR, used in addition to \fB\-shared\fR, tells the compiler to not pass \fB\-assert pure-text\fR to the linker when linking a shared object. ! .IP "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries are not part of \s-1GCC\s0. *************** Normally the facilities of the machine's *** 4572,4578 **** this can't be done directly in cross-compilation. You must make your own arrangements to provide suitable library functions for cross-compilation. ! .Ip "\fB\-mno-multm\fR" 4 .IX Item "-mno-multm" Do not generate multm or multmu instructions. This is useful for some embedded systems which do not have trap handlers for these instructions. --- 4574,4580 ---- this can't be done directly in cross-compilation. You must make your own arrangements to provide suitable library functions for cross-compilation. ! .IP "\fB\-mno-multm\fR" 4 .IX Item "-mno-multm" Do not generate multm or multmu instructions. This is useful for some embedded systems which do not have trap handlers for these instructions. *************** systems which do not have trap handlers *** 4582,4617 **** .PP These \fB\-m\fR options are defined for Advanced \s-1RISC\s0 Machines (\s-1ARM\s0) architectures: ! .Ip "\fB\-mapcs-frame\fR" 4 .IX Item "-mapcs-frame" Generate a stack frame that is compliant with the \s-1ARM\s0 Procedure Call Standard for all functions, even if this is not strictly necessary for correct execution of the code. Specifying \fB\-fomit-frame-pointer\fR with this option will cause the stack frames not to be generated for leaf functions. The default is \fB\-mno-apcs-frame\fR. ! .Ip "\fB\-mapcs\fR" 4 .IX Item "-mapcs" This is a synonym for \fB\-mapcs-frame\fR. ! .Ip "\fB\-mapcs-26\fR" 4 .IX Item "-mapcs-26" Generate code for a processor running with a 26\-bit program counter, and conforming to the function calling standards for the \s-1APCS\s0 26\-bit option. This option replaces the \fB\-m2\fR and \fB\-m3\fR options of previous releases of the compiler. ! .Ip "\fB\-mapcs-32\fR" 4 .IX Item "-mapcs-32" Generate code for a processor running with a 32\-bit program counter, and conforming to the function calling standards for the \s-1APCS\s0 32\-bit option. This option replaces the \fB\-m6\fR option of previous releases of the compiler. ! .Ip "\fB\-mthumb-interwork\fR" 4 .IX Item "-mthumb-interwork" Generate code which supports calling between the \s-1ARM\s0 and Thumb instruction sets. Without this option the two instruction sets cannot be reliably used inside one program. The default is \&\fB\-mno-thumb-interwork\fR, since slightly larger code is generated when \fB\-mthumb-interwork\fR is specified. ! .Ip "\fB\-mno-sched-prolog\fR" 4 .IX Item "-mno-sched-prolog" Prevent the reordering of instructions in the function prolog, or the merging of those instruction with the instructions in the function's --- 4584,4619 ---- .PP These \fB\-m\fR options are defined for Advanced \s-1RISC\s0 Machines (\s-1ARM\s0) architectures: ! .IP "\fB\-mapcs-frame\fR" 4 .IX Item "-mapcs-frame" Generate a stack frame that is compliant with the \s-1ARM\s0 Procedure Call Standard for all functions, even if this is not strictly necessary for correct execution of the code. Specifying \fB\-fomit-frame-pointer\fR with this option will cause the stack frames not to be generated for leaf functions. The default is \fB\-mno-apcs-frame\fR. ! .IP "\fB\-mapcs\fR" 4 .IX Item "-mapcs" This is a synonym for \fB\-mapcs-frame\fR. ! .IP "\fB\-mapcs-26\fR" 4 .IX Item "-mapcs-26" Generate code for a processor running with a 26\-bit program counter, and conforming to the function calling standards for the \s-1APCS\s0 26\-bit option. This option replaces the \fB\-m2\fR and \fB\-m3\fR options of previous releases of the compiler. ! .IP "\fB\-mapcs-32\fR" 4 .IX Item "-mapcs-32" Generate code for a processor running with a 32\-bit program counter, and conforming to the function calling standards for the \s-1APCS\s0 32\-bit option. This option replaces the \fB\-m6\fR option of previous releases of the compiler. ! .IP "\fB\-mthumb-interwork\fR" 4 .IX Item "-mthumb-interwork" Generate code which supports calling between the \s-1ARM\s0 and Thumb instruction sets. Without this option the two instruction sets cannot be reliably used inside one program. The default is \&\fB\-mno-thumb-interwork\fR, since slightly larger code is generated when \fB\-mthumb-interwork\fR is specified. ! .IP "\fB\-mno-sched-prolog\fR" 4 .IX Item "-mno-sched-prolog" Prevent the reordering of instructions in the function prolog, or the merging of those instruction with the instructions in the function's *************** of instructions (or in fact one of a cho *** 4620,4630 **** different function prologues), and this information can be used to locate the start if functions inside an executable piece of code. The default is \fB\-msched-prolog\fR. ! .Ip "\fB\-mhard-float\fR" 4 .IX Item "-mhard-float" Generate output containing floating point instructions. This is the default. ! .Ip "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries are not available for all \s-1ARM\s0 --- 4622,4632 ---- different function prologues), and this information can be used to locate the start if functions inside an executable piece of code. The default is \fB\-msched-prolog\fR. ! .IP "\fB\-mhard-float\fR" 4 .IX Item "-mhard-float" Generate output containing floating point instructions. This is the default. ! .IP "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries are not available for all \s-1ARM\s0 *************** therefore, it is only useful if you comp *** 4638,4652 **** this option. In particular, you need to compile \fIlibgcc.a\fR, the library that comes with \s-1GCC\s0, with \fB\-msoft-float\fR in order for this to work. ! .Ip "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" Generate code for a processor running in little-endian mode. This is the default for all standard configurations. ! .Ip "\fB\-mbig-endian\fR" 4 .IX Item "-mbig-endian" Generate code for a processor running in big-endian mode; the default is to compile code for a little-endian processor. ! .Ip "\fB\-mwords-little-endian\fR" 4 .IX Item "-mwords-little-endian" This option only applies when generating code for big-endian processors. Generate code for a little-endian word order but a big-endian byte --- 4640,4654 ---- this option. In particular, you need to compile \fIlibgcc.a\fR, the library that comes with \s-1GCC\s0, with \fB\-msoft-float\fR in order for this to work. ! .IP "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" Generate code for a processor running in little-endian mode. This is the default for all standard configurations. ! .IP "\fB\-mbig-endian\fR" 4 .IX Item "-mbig-endian" Generate code for a processor running in big-endian mode; the default is to compile code for a little-endian processor. ! .IP "\fB\-mwords-little-endian\fR" 4 .IX Item "-mwords-little-endian" This option only applies when generating code for big-endian processors. Generate code for a little-endian word order but a big-endian byte *************** order. That is, a byte order of the for *** 4654,4660 **** option should only be used if you require compatibility with code for big-endian \s-1ARM\s0 processors generated by versions of the compiler prior to 2.8. ! .Ip "\fB\-malignment-traps\fR" 4 .IX Item "-malignment-traps" Generate code that will not trap if the \s-1MMU\s0 has alignment traps enabled. On \s-1ARM\s0 architectures prior to ARMv4, there were no instructions to --- 4656,4662 ---- option should only be used if you require compatibility with code for big-endian \s-1ARM\s0 processors generated by versions of the compiler prior to 2.8. ! .IP "\fB\-malignment-traps\fR" 4 .IX Item "-malignment-traps" Generate code that will not trap if the \s-1MMU\s0 has alignment traps enabled. On \s-1ARM\s0 architectures prior to ARMv4, there were no instructions to *************** address is aligned to a word boundary. *** 4670,4676 **** This option is ignored when compiling for \s-1ARM\s0 architecture 4 or later, since these processors have instructions to directly access half-word objects in memory. ! .Ip "\fB\-mno-alignment-traps\fR" 4 .IX Item "-mno-alignment-traps" Generate code that assumes that the \s-1MMU\s0 will not trap unaligned accesses. This produces better code when the target instruction set --- 4672,4678 ---- This option is ignored when compiling for \s-1ARM\s0 architecture 4 or later, since these processors have instructions to directly access half-word objects in memory. ! .IP "\fB\-mno-alignment-traps\fR" 4 .IX Item "-mno-alignment-traps" Generate code that assumes that the \s-1MMU\s0 will not trap unaligned accesses. This produces better code when the target instruction set *************** memory. *** 4684,4712 **** The default setting for most targets is \fB\-mno-alignment-traps\fR, since this produces better code when there are no half-word memory instructions available. ! .Ip "\fB\-mshort-load-bytes\fR" 4 .IX Item "-mshort-load-bytes" .PD 0 ! .Ip "\fB\-mno-short-load-words\fR" 4 .IX Item "-mno-short-load-words" .PD These are deprecated aliases for \fB\-malignment-traps\fR. ! .Ip "\fB\-mno-short-load-bytes\fR" 4 .IX Item "-mno-short-load-bytes" .PD 0 ! .Ip "\fB\-mshort-load-words\fR" 4 .IX Item "-mshort-load-words" .PD This are deprecated aliases for \fB\-mno-alignment-traps\fR. ! .Ip "\fB\-mbsd\fR" 4 .IX Item "-mbsd" This option only applies to \s-1RISC\s0 iX. Emulate the native BSD-mode compiler. This is the default if \fB\-ansi\fR is not specified. ! .Ip "\fB\-mxopen\fR" 4 .IX Item "-mxopen" This option only applies to \s-1RISC\s0 iX. Emulate the native X/Open-mode compiler. ! .Ip "\fB\-mno-symrename\fR" 4 .IX Item "-mno-symrename" This option only applies to \s-1RISC\s0 iX. Do not run the assembler post-processor, \fBsymrename\fR, after code has been assembled. --- 4686,4714 ---- The default setting for most targets is \fB\-mno-alignment-traps\fR, since this produces better code when there are no half-word memory instructions available. ! .IP "\fB\-mshort-load-bytes\fR" 4 .IX Item "-mshort-load-bytes" .PD 0 ! .IP "\fB\-mno-short-load-words\fR" 4 .IX Item "-mno-short-load-words" .PD These are deprecated aliases for \fB\-malignment-traps\fR. ! .IP "\fB\-mno-short-load-bytes\fR" 4 .IX Item "-mno-short-load-bytes" .PD 0 ! .IP "\fB\-mshort-load-words\fR" 4 .IX Item "-mshort-load-words" .PD This are deprecated aliases for \fB\-mno-alignment-traps\fR. ! .IP "\fB\-mbsd\fR" 4 .IX Item "-mbsd" This option only applies to \s-1RISC\s0 iX. Emulate the native BSD-mode compiler. This is the default if \fB\-ansi\fR is not specified. ! .IP "\fB\-mxopen\fR" 4 .IX Item "-mxopen" This option only applies to \s-1RISC\s0 iX. Emulate the native X/Open-mode compiler. ! .IP "\fB\-mno-symrename\fR" 4 .IX Item "-mno-symrename" This option only applies to \s-1RISC\s0 iX. Do not run the assembler post-processor, \fBsymrename\fR, after code has been assembled. *************** Normally it is necessary to modify some *** 4714,4720 **** preparation for linking with the \s-1RISC\s0 iX C library; this option suppresses this pass. The post-processor is never run when the compiler is built for cross-compilation. ! .Ip "\fB\-mcpu=\fR\fIname\fR" 4 .IX Item "-mcpu=name" This specifies the name of the target \s-1ARM\s0 processor. \s-1GCC\s0 uses this name to determine what kind of instructions it can emit when generating --- 4716,4722 ---- preparation for linking with the \s-1RISC\s0 iX C library; this option suppresses this pass. The post-processor is never run when the compiler is built for cross-compilation. ! .IP "\fB\-mcpu=\fR\fIname\fR" 4 .IX Item "-mcpu=name" This specifies the name of the target \s-1ARM\s0 processor. \s-1GCC\s0 uses this name to determine what kind of instructions it can emit when generating *************** assembly code. Permissible names are: \ *** 4728,4734 **** \&\fBarm8\fR, \fBarm810\fR, \fBarm9\fR, \fBarm9e\fR, \fBarm920\fR, \&\fBarm920t\fR, \fBarm940t\fR, \fBarm9tdmi\fR, \fBarm10tdmi\fR, \&\fBarm1020t\fR, \fBxscale\fR. ! .Ip "\fB\-mtune=\fR\fIname\fR" 4 .IX Item "-mtune=name" This option is very similar to the \fB\-mcpu=\fR option, except that instead of specifying the actual target processor type, and hence --- 4730,4736 ---- \&\fBarm8\fR, \fBarm810\fR, \fBarm9\fR, \fBarm9e\fR, \fBarm920\fR, \&\fBarm920t\fR, \fBarm940t\fR, \fBarm9tdmi\fR, \fBarm10tdmi\fR, \&\fBarm1020t\fR, \fBxscale\fR. ! .IP "\fB\-mtune=\fR\fIname\fR" 4 .IX Item "-mtune=name" This option is very similar to the \fB\-mcpu=\fR option, except that instead of specifying the actual target processor type, and hence *************** specified in this option, but still choo *** 4738,4744 **** will generate based on the cpu specified by a \fB\-mcpu=\fR option. For some \s-1ARM\s0 implementations better performance can be obtained by using this option. ! .Ip "\fB\-march=\fR\fIname\fR" 4 .IX Item "-march=name" This specifies the name of the target \s-1ARM\s0 architecture. \s-1GCC\s0 uses this name to determine what kind of instructions it can emit when generating --- 4740,4746 ---- will generate based on the cpu specified by a \fB\-mcpu=\fR option. For some \s-1ARM\s0 implementations better performance can be obtained by using this option. ! .IP "\fB\-march=\fR\fIname\fR" 4 .IX Item "-march=name" This specifies the name of the target \s-1ARM\s0 architecture. \s-1GCC\s0 uses this name to determine what kind of instructions it can emit when generating *************** assembly code. This option can be used *** 4746,4761 **** of the \fB\-mcpu=\fR option. Permissible names are: \fBarmv2\fR, \&\fBarmv2a\fR, \fBarmv3\fR, \fBarmv3m\fR, \fBarmv4\fR, \fBarmv4t\fR, \&\fBarmv5\fR, \fBarmv5t\fR, \fBarmv5te\fR. ! .Ip "\fB\-mfpe=\fR\fInumber\fR" 4 .IX Item "-mfpe=number" .PD 0 ! .Ip "\fB\-mfp=\fR\fInumber\fR" 4 .IX Item "-mfp=number" .PD This specifies the version of the floating point emulation available on the target. Permissible values are 2 and 3. \fB\-mfp=\fR is a synonym for \fB\-mfpe=\fR, for compatibility with older versions of \s-1GCC\s0. ! .Ip "\fB\-mstructure-size-boundary=\fR\fIn\fR" 4 .IX Item "-mstructure-size-boundary=n" The size of all structures and unions will be rounded up to a multiple of the number of bits set by this option. Permissible values are 8 and --- 4748,4763 ---- of the \fB\-mcpu=\fR option. Permissible names are: \fBarmv2\fR, \&\fBarmv2a\fR, \fBarmv3\fR, \fBarmv3m\fR, \fBarmv4\fR, \fBarmv4t\fR, \&\fBarmv5\fR, \fBarmv5t\fR, \fBarmv5te\fR. ! .IP "\fB\-mfpe=\fR\fInumber\fR" 4 .IX Item "-mfpe=number" .PD 0 ! .IP "\fB\-mfp=\fR\fInumber\fR" 4 .IX Item "-mfp=number" .PD This specifies the version of the floating point emulation available on the target. Permissible values are 2 and 3. \fB\-mfp=\fR is a synonym for \fB\-mfpe=\fR, for compatibility with older versions of \s-1GCC\s0. ! .IP "\fB\-mstructure-size-boundary=\fR\fIn\fR" 4 .IX Item "-mstructure-size-boundary=n" The size of all structures and unions will be rounded up to a multiple of the number of bits set by this option. Permissible values are 8 and *************** of the program. The two values are pote *** 4766,4780 **** compiled with one value cannot necessarily expect to work with code or libraries compiled with the other value, if they exchange information using structures or unions. ! .Ip "\fB\-mabort-on-noreturn\fR" 4 .IX Item "-mabort-on-noreturn" Generate a call to the function \f(CW\*(C`abort\*(C'\fR at the end of a \&\f(CW\*(C`noreturn\*(C'\fR function. It will be executed if the function tries to return. ! .Ip "\fB\-mlong-calls\fR" 4 .IX Item "-mlong-calls" .PD 0 ! .Ip "\fB\-mno-long-calls\fR" 4 .IX Item "-mno-long-calls" .PD Tells the compiler to perform function calls by first loading the --- 4768,4782 ---- compiled with one value cannot necessarily expect to work with code or libraries compiled with the other value, if they exchange information using structures or unions. ! .IP "\fB\-mabort-on-noreturn\fR" 4 .IX Item "-mabort-on-noreturn" Generate a call to the function \f(CW\*(C`abort\*(C'\fR at the end of a \&\f(CW\*(C`noreturn\*(C'\fR function. It will be executed if the function tries to return. ! .IP "\fB\-mlong-calls\fR" 4 .IX Item "-mlong-calls" .PD 0 ! .IP "\fB\-mno-long-calls\fR" 4 .IX Item "-mno-long-calls" .PD Tells the compiler to perform function calls by first loading the *************** placing the function calls within the sc *** 4800,4819 **** long_calls_off\fR directive. Note these switches have no effect on how the compiler generates code to handle function calls via function pointers. ! .Ip "\fB\-mnop-fun-dllimport\fR" 4 .IX Item "-mnop-fun-dllimport" Disable support for the \f(CW\*(C`dllimport\*(C'\fR attribute. ! .Ip "\fB\-msingle-pic-base\fR" 4 .IX Item "-msingle-pic-base" Treat the register used for \s-1PIC\s0 addressing as read-only, rather than loading it in the prologue for each function. The run-time system is responsible for initialising this register with an appropriate value before execution begins. ! .Ip "\fB\-mpic-register=\fR\fIreg\fR" 4 .IX Item "-mpic-register=reg" Specify the register to be used for \s-1PIC\s0 addressing. The default is R10 unless stack-checking is enabled, when R9 is used. ! .Ip "\fB\-mpoke-function-name\fR" 4 .IX Item "-mpoke-function-name" Write the name of each function into the text section, directly preceding the function prologue. The generated code is similar to this: --- 4802,4821 ---- long_calls_off\fR directive. Note these switches have no effect on how the compiler generates code to handle function calls via function pointers. ! .IP "\fB\-mnop-fun-dllimport\fR" 4 .IX Item "-mnop-fun-dllimport" Disable support for the \f(CW\*(C`dllimport\*(C'\fR attribute. ! .IP "\fB\-msingle-pic-base\fR" 4 .IX Item "-msingle-pic-base" Treat the register used for \s-1PIC\s0 addressing as read-only, rather than loading it in the prologue for each function. The run-time system is responsible for initialising this register with an appropriate value before execution begins. ! .IP "\fB\-mpic-register=\fR\fIreg\fR" 4 .IX Item "-mpic-register=reg" Specify the register to be used for \s-1PIC\s0 addressing. The default is R10 unless stack-checking is enabled, when R9 is used. ! .IP "\fB\-mpoke-function-name\fR" 4 .IX Item "-mpoke-function-name" Write the name of each function into the text section, directly preceding the function prologue. The generated code is similar to this: *************** When performing a stack backtrace, code *** 4834,4860 **** location \f(CW\*(C`pc \- 12\*(C'\fR and the top 8 bits are set, then we know that there is a function name embedded immediately preceding this location and has length \f(CW\*(C`((pc[\-3]) & 0xff000000)\*(C'\fR. ! .Ip "\fB\-mthumb\fR" 4 .IX Item "-mthumb" Generate code for the 16\-bit Thumb instruction set. The default is to use the 32\-bit \s-1ARM\s0 instruction set. ! .Ip "\fB\-mtpcs-frame\fR" 4 .IX Item "-mtpcs-frame" Generate a stack frame that is compliant with the Thumb Procedure Call Standard for all non-leaf functions. (A leaf function is one that does not call any other functions.) The default is \fB\-mno-tpcs-frame\fR. ! .Ip "\fB\-mtpcs-leaf-frame\fR" 4 .IX Item "-mtpcs-leaf-frame" Generate a stack frame that is compliant with the Thumb Procedure Call Standard for all leaf functions. (A leaf function is one that does not call any other functions.) The default is \fB\-mno-apcs-leaf-frame\fR. ! .Ip "\fB\-mcallee-super-interworking\fR" 4 .IX Item "-mcallee-super-interworking" Gives all externally visible functions in the file being compiled an \s-1ARM\s0 instruction set header which switches to Thumb mode before executing the rest of the function. This allows these functions to be called from non-interworking code. ! .Ip "\fB\-mcaller-super-interworking\fR" 4 .IX Item "-mcaller-super-interworking" Allows calls via function pointers (including virtual functions) to execute correctly regardless of whether the target code has been --- 4836,4862 ---- location \f(CW\*(C`pc \- 12\*(C'\fR and the top 8 bits are set, then we know that there is a function name embedded immediately preceding this location and has length \f(CW\*(C`((pc[\-3]) & 0xff000000)\*(C'\fR. ! .IP "\fB\-mthumb\fR" 4 .IX Item "-mthumb" Generate code for the 16\-bit Thumb instruction set. The default is to use the 32\-bit \s-1ARM\s0 instruction set. ! .IP "\fB\-mtpcs-frame\fR" 4 .IX Item "-mtpcs-frame" Generate a stack frame that is compliant with the Thumb Procedure Call Standard for all non-leaf functions. (A leaf function is one that does not call any other functions.) The default is \fB\-mno-tpcs-frame\fR. ! .IP "\fB\-mtpcs-leaf-frame\fR" 4 .IX Item "-mtpcs-leaf-frame" Generate a stack frame that is compliant with the Thumb Procedure Call Standard for all leaf functions. (A leaf function is one that does not call any other functions.) The default is \fB\-mno-apcs-leaf-frame\fR. ! .IP "\fB\-mcallee-super-interworking\fR" 4 .IX Item "-mcallee-super-interworking" Gives all externally visible functions in the file being compiled an \s-1ARM\s0 instruction set header which switches to Thumb mode before executing the rest of the function. This allows these functions to be called from non-interworking code. ! .IP "\fB\-mcaller-super-interworking\fR" 4 .IX Item "-mcaller-super-interworking" Allows calls via function pointers (including virtual functions) to execute correctly regardless of whether the target code has been *************** of executing a function pointer if this *** 4865,4871 **** .IX Subsection "MN10200 Options" .PP These \fB\-m\fR options are defined for Matsushita \s-1MN10200\s0 architectures: ! .Ip "\fB\-mrelax\fR" 4 .IX Item "-mrelax" Indicate to the linker that it should perform a relaxation optimization pass to shorten branches, calls and absolute memory addresses. This option only --- 4867,4873 ---- .IX Subsection "MN10200 Options" .PP These \fB\-m\fR options are defined for Matsushita \s-1MN10200\s0 architectures: ! .IP "\fB\-mrelax\fR" 4 .IX Item "-mrelax" Indicate to the linker that it should perform a relaxation optimization pass to shorten branches, calls and absolute memory addresses. This option only *************** This option makes symbolic debugging imp *** 4877,4901 **** .IX Subsection "MN10300 Options" .PP These \fB\-m\fR options are defined for Matsushita \s-1MN10300\s0 architectures: ! .Ip "\fB\-mmult-bug\fR" 4 .IX Item "-mmult-bug" Generate code to avoid bugs in the multiply instructions for the \s-1MN10300\s0 processors. This is the default. ! .Ip "\fB\-mno-mult-bug\fR" 4 .IX Item "-mno-mult-bug" Do not generate code to avoid bugs in the multiply instructions for the \&\s-1MN10300\s0 processors. ! .Ip "\fB\-mam33\fR" 4 .IX Item "-mam33" Generate code which uses features specific to the \s-1AM33\s0 processor. ! .Ip "\fB\-mno-am33\fR" 4 .IX Item "-mno-am33" Do not generate code which uses features specific to the \s-1AM33\s0 processor. This is the default. ! .Ip "\fB\-mno-crt0\fR" 4 .IX Item "-mno-crt0" Do not link in the C run-time initialization object file. ! .Ip "\fB\-mrelax\fR" 4 .IX Item "-mrelax" Indicate to the linker that it should perform a relaxation optimization pass to shorten branches, calls and absolute memory addresses. This option only --- 4879,4903 ---- .IX Subsection "MN10300 Options" .PP These \fB\-m\fR options are defined for Matsushita \s-1MN10300\s0 architectures: ! .IP "\fB\-mmult-bug\fR" 4 .IX Item "-mmult-bug" Generate code to avoid bugs in the multiply instructions for the \s-1MN10300\s0 processors. This is the default. ! .IP "\fB\-mno-mult-bug\fR" 4 .IX Item "-mno-mult-bug" Do not generate code to avoid bugs in the multiply instructions for the \&\s-1MN10300\s0 processors. ! .IP "\fB\-mam33\fR" 4 .IX Item "-mam33" Generate code which uses features specific to the \s-1AM33\s0 processor. ! .IP "\fB\-mno-am33\fR" 4 .IX Item "-mno-am33" Do not generate code which uses features specific to the \s-1AM33\s0 processor. This is the default. ! .IP "\fB\-mno-crt0\fR" 4 .IX Item "-mno-crt0" Do not link in the C run-time initialization object file. ! .IP "\fB\-mrelax\fR" 4 .IX Item "-mrelax" Indicate to the linker that it should perform a relaxation optimization pass to shorten branches, calls and absolute memory addresses. This option only *************** This option makes symbolic debugging imp *** 4907,4913 **** .IX Subsection "M32R/D Options" .PP These \fB\-m\fR options are defined for Mitsubishi M32R/D architectures: ! .Ip "\fB\-mcode-model=small\fR" 4 .IX Item "-mcode-model=small" Assume all objects live in the lower 16MB of memory (so that their addresses can be loaded with the \f(CW\*(C`ld24\*(C'\fR instruction), and assume all subroutines --- 4909,4915 ---- .IX Subsection "M32R/D Options" .PP These \fB\-m\fR options are defined for Mitsubishi M32R/D architectures: ! .IP "\fB\-mcode-model=small\fR" 4 .IX Item "-mcode-model=small" Assume all objects live in the lower 16MB of memory (so that their addresses can be loaded with the \f(CW\*(C`ld24\*(C'\fR instruction), and assume all subroutines *************** This is the default. *** 4916,4934 **** .Sp The addressability of a particular object can be set with the \&\f(CW\*(C`model\*(C'\fR attribute. ! .Ip "\fB\-mcode-model=medium\fR" 4 .IX Item "-mcode-model=medium" Assume objects may be anywhere in the 32\-bit address space (the compiler will generate \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and assume all subroutines are reachable with the \f(CW\*(C`bl\*(C'\fR instruction. ! .Ip "\fB\-mcode-model=large\fR" 4 .IX Item "-mcode-model=large" Assume objects may be anywhere in the 32\-bit address space (the compiler will generate \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and assume subroutines may not be reachable with the \f(CW\*(C`bl\*(C'\fR instruction (the compiler will generate the much slower \f(CW\*(C`seth/add3/jl\*(C'\fR instruction sequence). ! .Ip "\fB\-msdata=none\fR" 4 .IX Item "-msdata=none" Disable use of the small data area. Variables will be put into one of \fB.data\fR, \fBbss\fR, or \fB.rodata\fR (unless the --- 4918,4936 ---- .Sp The addressability of a particular object can be set with the \&\f(CW\*(C`model\*(C'\fR attribute. ! .IP "\fB\-mcode-model=medium\fR" 4 .IX Item "-mcode-model=medium" Assume objects may be anywhere in the 32\-bit address space (the compiler will generate \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and assume all subroutines are reachable with the \f(CW\*(C`bl\*(C'\fR instruction. ! .IP "\fB\-mcode-model=large\fR" 4 .IX Item "-mcode-model=large" Assume objects may be anywhere in the 32\-bit address space (the compiler will generate \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and assume subroutines may not be reachable with the \f(CW\*(C`bl\*(C'\fR instruction (the compiler will generate the much slower \f(CW\*(C`seth/add3/jl\*(C'\fR instruction sequence). ! .IP "\fB\-msdata=none\fR" 4 .IX Item "-msdata=none" Disable use of the small data area. Variables will be put into one of \fB.data\fR, \fBbss\fR, or \fB.rodata\fR (unless the *************** This is the default. *** 4938,4952 **** The small data area consists of sections \fB.sdata\fR and \fB.sbss\fR. Objects may be explicitly put in the small data area with the \&\f(CW\*(C`section\*(C'\fR attribute using one of these sections. ! .Ip "\fB\-msdata=sdata\fR" 4 .IX Item "-msdata=sdata" Put small global and static data in the small data area, but do not generate special code to reference them. ! .Ip "\fB\-msdata=use\fR" 4 .IX Item "-msdata=use" Put small global and static data in the small data area, and generate special instructions to reference them. ! .Ip "\fB\-G\fR \fInum\fR" 4 .IX Item "-G num" Put global and static objects less than or equal to \fInum\fR bytes into the small data or bss sections instead of the normal data or bss --- 4940,4954 ---- The small data area consists of sections \fB.sdata\fR and \fB.sbss\fR. Objects may be explicitly put in the small data area with the \&\f(CW\*(C`section\*(C'\fR attribute using one of these sections. ! .IP "\fB\-msdata=sdata\fR" 4 .IX Item "-msdata=sdata" Put small global and static data in the small data area, but do not generate special code to reference them. ! .IP "\fB\-msdata=use\fR" 4 .IX Item "-msdata=use" Put small global and static data in the small data area, and generate special instructions to reference them. ! .IP "\fB\-G\fR \fInum\fR" 4 .IX Item "-G num" Put global and static objects less than or equal to \fInum\fR bytes into the small data or bss sections instead of the normal data or bss *************** generated. *** 4963,4998 **** .IX Subsection "M88K Options" .PP These \fB\-m\fR options are defined for Motorola 88k architectures: ! .Ip "\fB\-m88000\fR" 4 .IX Item "-m88000" Generate code that works well on both the m88100 and the m88110. ! .Ip "\fB\-m88100\fR" 4 .IX Item "-m88100" Generate code that works best for the m88100, but that also runs on the m88110. ! .Ip "\fB\-m88110\fR" 4 .IX Item "-m88110" Generate code that works best for the m88110, and may not run on the m88100. ! .Ip "\fB\-mbig-pic\fR" 4 .IX Item "-mbig-pic" Obsolete option to be removed from the next revision. Use \fB\-fPIC\fR. ! .Ip "\fB\-midentify-revision\fR" 4 .IX Item "-midentify-revision" Include an \f(CW\*(C`ident\*(C'\fR directive in the assembler output recording the source file name, compiler name and version, timestamp, and compilation flags used. ! .Ip "\fB\-mno-underscores\fR" 4 .IX Item "-mno-underscores" In assembler output, emit symbol names without adding an underscore character at the beginning of each name. The default is to use an underscore as prefix on each name. ! .Ip "\fB\-mocs-debug-info\fR" 4 .IX Item "-mocs-debug-info" .PD 0 ! .Ip "\fB\-mno-ocs-debug-info\fR" 4 .IX Item "-mno-ocs-debug-info" .PD Include (or omit) additional debugging information (about registers used --- 4965,5000 ---- .IX Subsection "M88K Options" .PP These \fB\-m\fR options are defined for Motorola 88k architectures: ! .IP "\fB\-m88000\fR" 4 .IX Item "-m88000" Generate code that works well on both the m88100 and the m88110. ! .IP "\fB\-m88100\fR" 4 .IX Item "-m88100" Generate code that works best for the m88100, but that also runs on the m88110. ! .IP "\fB\-m88110\fR" 4 .IX Item "-m88110" Generate code that works best for the m88110, and may not run on the m88100. ! .IP "\fB\-mbig-pic\fR" 4 .IX Item "-mbig-pic" Obsolete option to be removed from the next revision. Use \fB\-fPIC\fR. ! .IP "\fB\-midentify-revision\fR" 4 .IX Item "-midentify-revision" Include an \f(CW\*(C`ident\*(C'\fR directive in the assembler output recording the source file name, compiler name and version, timestamp, and compilation flags used. ! .IP "\fB\-mno-underscores\fR" 4 .IX Item "-mno-underscores" In assembler output, emit symbol names without adding an underscore character at the beginning of each name. The default is to use an underscore as prefix on each name. ! .IP "\fB\-mocs-debug-info\fR" 4 .IX Item "-mocs-debug-info" .PD 0 ! .IP "\fB\-mno-ocs-debug-info\fR" 4 .IX Item "-mno-ocs-debug-info" .PD Include (or omit) additional debugging information (about registers used *************** Standard, ``\s-1OCS\s0''. This extra in *** 5001,5007 **** has had the frame pointer eliminated. The default for \s-1DG/UX\s0, SVr4, and Delta 88 SVr3.2 is to include this information; other 88k configurations omit this information by default. ! .Ip "\fB\-mocs-frame-position\fR" 4 .IX Item "-mocs-frame-position" When emitting \s-1COFF\s0 debugging information for automatic variables and parameters stored on the stack, use the offset from the canonical frame --- 5003,5009 ---- has had the frame pointer eliminated. The default for \s-1DG/UX\s0, SVr4, and Delta 88 SVr3.2 is to include this information; other 88k configurations omit this information by default. ! .IP "\fB\-mocs-frame-position\fR" 4 .IX Item "-mocs-frame-position" When emitting \s-1COFF\s0 debugging information for automatic variables and parameters stored on the stack, use the offset from the canonical frame *************** address, which is the stack pointer (reg *** 5009,5025 **** function. The \s-1DG/UX\s0, SVr4, Delta88 SVr3.2, and \s-1BCS\s0 configurations use \&\fB\-mocs-frame-position\fR; other 88k configurations have the default \&\fB\-mno-ocs-frame-position\fR. ! .Ip "\fB\-mno-ocs-frame-position\fR" 4 .IX Item "-mno-ocs-frame-position" When emitting \s-1COFF\s0 debugging information for automatic variables and parameters stored on the stack, use the offset from the frame pointer register (register 30). When this option is in effect, the frame pointer is not eliminated when debugging information is selected by the \&\-g switch. ! .Ip "\fB\-moptimize-arg-area\fR" 4 .IX Item "-moptimize-arg-area" .PD 0 ! .Ip "\fB\-mno-optimize-arg-area\fR" 4 .IX Item "-mno-optimize-arg-area" .PD Control how function arguments are stored in stack frames. --- 5011,5027 ---- function. The \s-1DG/UX\s0, SVr4, Delta88 SVr3.2, and \s-1BCS\s0 configurations use \&\fB\-mocs-frame-position\fR; other 88k configurations have the default \&\fB\-mno-ocs-frame-position\fR. ! .IP "\fB\-mno-ocs-frame-position\fR" 4 .IX Item "-mno-ocs-frame-position" When emitting \s-1COFF\s0 debugging information for automatic variables and parameters stored on the stack, use the offset from the frame pointer register (register 30). When this option is in effect, the frame pointer is not eliminated when debugging information is selected by the \&\-g switch. ! .IP "\fB\-moptimize-arg-area\fR" 4 .IX Item "-moptimize-arg-area" .PD 0 ! .IP "\fB\-mno-optimize-arg-area\fR" 4 .IX Item "-mno-optimize-arg-area" .PD Control how function arguments are stored in stack frames. *************** Control how function arguments are store *** 5027,5033 **** conflicts with the 88open specifications. The opposite alternative, \&\fB\-mno-optimize-arg-area\fR, agrees with 88open standards. By default \&\s-1GCC\s0 does not optimize the argument area. ! .Ip "\fB\-mshort-data-\fR\fInum\fR" 4 .IX Item "-mshort-data-num" Generate smaller data references by making them relative to \f(CW\*(C`r0\*(C'\fR, which allows loading a value using a single instruction (rather than the --- 5029,5035 ---- conflicts with the 88open specifications. The opposite alternative, \&\fB\-mno-optimize-arg-area\fR, agrees with 88open standards. By default \&\s-1GCC\s0 does not optimize the argument area. ! .IP "\fB\-mshort-data-\fR\fInum\fR" 4 .IX Item "-mshort-data-num" Generate smaller data references by making them relative to \f(CW\*(C`r0\*(C'\fR, which allows loading a value using a single instruction (rather than the *************** specifying \fInum\fR with this option. *** 5037,5046 **** involving displacements of less than 512 bytes. \&\fB\-mshort-data-\fR\fInum\fR is not effective for \fInum\fR greater than 64k. ! .Ip "\fB\-mserialize-volatile\fR" 4 .IX Item "-mserialize-volatile" .PD 0 ! .Ip "\fB\-mno-serialize-volatile\fR" 4 .IX Item "-mno-serialize-volatile" .PD Do, or don't, generate code to guarantee sequential consistency --- 5039,5048 ---- involving displacements of less than 512 bytes. \&\fB\-mshort-data-\fR\fInum\fR is not effective for \fInum\fR greater than 64k. ! .IP "\fB\-mserialize-volatile\fR" 4 .IX Item "-mserialize-volatile" .PD 0 ! .IP "\fB\-mno-serialize-volatile\fR" 4 .IX Item "-mno-serialize-volatile" .PD Do, or don't, generate code to guarantee sequential consistency *************** even when you use \fB\-m88100\fR, so tha *** 5066,5086 **** The extra code generated to guarantee consistency may affect the performance of your application. If you know that you can safely forgo this guarantee, you may use \fB\-mno-serialize-volatile\fR. ! .Ip "\fB\-msvr4\fR" 4 .IX Item "-msvr4" .PD 0 ! .Ip "\fB\-msvr3\fR" 4 .IX Item "-msvr3" .PD Turn on (\fB\-msvr4\fR) or off (\fB\-msvr3\fR) compiler extensions related to System V release 4 (SVr4). This controls the following: .RS 4 ! .Ip "1." 4 Which variant of the assembler syntax to emit. ! .Ip "2." 4 \&\fB\-msvr4\fR makes the C preprocessor recognize \fB#pragma weak\fR that is used on System V release 4. ! .Ip "3." 4 \&\fB\-msvr4\fR makes \s-1GCC\s0 issue additional declaration directives used in SVr4. .RE --- 5068,5088 ---- The extra code generated to guarantee consistency may affect the performance of your application. If you know that you can safely forgo this guarantee, you may use \fB\-mno-serialize-volatile\fR. ! .IP "\fB\-msvr4\fR" 4 .IX Item "-msvr4" .PD 0 ! .IP "\fB\-msvr3\fR" 4 .IX Item "-msvr3" .PD Turn on (\fB\-msvr4\fR) or off (\fB\-msvr3\fR) compiler extensions related to System V release 4 (SVr4). This controls the following: .RS 4 ! .IP "1." 4 Which variant of the assembler syntax to emit. ! .IP "2." 4 \&\fB\-msvr4\fR makes the C preprocessor recognize \fB#pragma weak\fR that is used on System V release 4. ! .IP "3." 4 \&\fB\-msvr4\fR makes \s-1GCC\s0 issue additional declaration directives used in SVr4. .RE *************** SVr4. *** 5090,5102 **** m88k-dg-dgux m88k configurations. \fB\-msvr3\fR is the default for all other m88k configurations. .RE ! .Ip "\fB\-mversion-03.00\fR" 4 .IX Item "-mversion-03.00" This option is obsolete, and is ignored. ! .Ip "\fB\-mno-check-zero-division\fR" 4 .IX Item "-mno-check-zero-division" .PD 0 ! .Ip "\fB\-mcheck-zero-division\fR" 4 .IX Item "-mcheck-zero-division" .PD Do, or don't, generate code to guarantee that integer division by --- 5092,5104 ---- m88k-dg-dgux m88k configurations. \fB\-msvr3\fR is the default for all other m88k configurations. .RE ! .IP "\fB\-mversion-03.00\fR" 4 .IX Item "-mversion-03.00" This option is obsolete, and is ignored. ! .IP "\fB\-mno-check-zero-division\fR" 4 .IX Item "-mno-check-zero-division" .PD 0 ! .IP "\fB\-mcheck-zero-division\fR" 4 .IX Item "-mcheck-zero-division" .PD Do, or don't, generate code to guarantee that integer division by *************** instances of integer division by zero. *** 5115,5121 **** specified, both \fB\-mcheck-zero-division\fR and \&\fB\-mno-check-zero-division\fR are ignored, and no explicit checks for zero-valued divisors are generated. ! .Ip "\fB\-muse-div-instruction\fR" 4 .IX Item "-muse-div-instruction" Use the div instruction for signed integer division on the \&\s-1MC88100\s0 processor. By default, the div instruction is not used. --- 5117,5123 ---- specified, both \fB\-mcheck-zero-division\fR and \&\fB\-mno-check-zero-division\fR are ignored, and no explicit checks for zero-valued divisors are generated. ! .IP "\fB\-muse-div-instruction\fR" 4 .IX Item "-muse-div-instruction" Use the div instruction for signed integer division on the \&\s-1MC88100\s0 processor. By default, the div instruction is not used. *************** for signed integer division. *** 5142,5157 **** Note that the result of dividing \f(CW\*(C`INT_MIN\*(C'\fR by \-1 is undefined. In particular, the behavior of such a division with and without \&\fB\-muse-div-instruction\fR may differ. ! .Ip "\fB\-mtrap-large-shift\fR" 4 .IX Item "-mtrap-large-shift" .PD 0 ! .Ip "\fB\-mhandle-large-shift\fR" 4 .IX Item "-mhandle-large-shift" .PD Include code to detect bit-shifts of more than 31 bits; respectively, trap such shifts or emit code to handle them properly. By default \s-1GCC\s0 makes no special provision for large bit shifts. ! .Ip "\fB\-mwarn-passed-structs\fR" 4 .IX Item "-mwarn-passed-structs" Warn when a function passes a struct as an argument or result. Structure-passing conventions have changed during the evolution of the C --- 5144,5159 ---- Note that the result of dividing \f(CW\*(C`INT_MIN\*(C'\fR by \-1 is undefined. In particular, the behavior of such a division with and without \&\fB\-muse-div-instruction\fR may differ. ! .IP "\fB\-mtrap-large-shift\fR" 4 .IX Item "-mtrap-large-shift" .PD 0 ! .IP "\fB\-mhandle-large-shift\fR" 4 .IX Item "-mhandle-large-shift" .PD Include code to detect bit-shifts of more than 31 bits; respectively, trap such shifts or emit code to handle them properly. By default \s-1GCC\s0 makes no special provision for large bit shifts. ! .IP "\fB\-mwarn-passed-structs\fR" 4 .IX Item "-mwarn-passed-structs" Warn when a function passes a struct as an argument or result. Structure-passing conventions have changed during the evolution of the C *************** language, and are often the source of po *** 5162,5191 **** .IX Subsection "IBM RS/6000 and PowerPC Options" .PP These \fB\-m\fR options are defined for the \s-1IBM\s0 \s-1RS/6000\s0 and PowerPC: ! .Ip "\fB\-mpower\fR" 4 .IX Item "-mpower" .PD 0 ! .Ip "\fB\-mno-power\fR" 4 .IX Item "-mno-power" ! .Ip "\fB\-mpower2\fR" 4 .IX Item "-mpower2" ! .Ip "\fB\-mno-power2\fR" 4 .IX Item "-mno-power2" ! .Ip "\fB\-mpowerpc\fR" 4 .IX Item "-mpowerpc" ! .Ip "\fB\-mno-powerpc\fR" 4 .IX Item "-mno-powerpc" ! .Ip "\fB\-mpowerpc-gpopt\fR" 4 .IX Item "-mpowerpc-gpopt" ! .Ip "\fB\-mno-powerpc-gpopt\fR" 4 .IX Item "-mno-powerpc-gpopt" ! .Ip "\fB\-mpowerpc-gfxopt\fR" 4 .IX Item "-mpowerpc-gfxopt" ! .Ip "\fB\-mno-powerpc-gfxopt\fR" 4 .IX Item "-mno-powerpc-gfxopt" ! .Ip "\fB\-mpowerpc64\fR" 4 .IX Item "-mpowerpc64" ! .Ip "\fB\-mno-powerpc64\fR" 4 .IX Item "-mno-powerpc64" .PD \&\s-1GCC\s0 supports two related instruction set architectures for the --- 5164,5193 ---- .IX Subsection "IBM RS/6000 and PowerPC Options" .PP These \fB\-m\fR options are defined for the \s-1IBM\s0 \s-1RS/6000\s0 and PowerPC: ! .IP "\fB\-mpower\fR" 4 .IX Item "-mpower" .PD 0 ! .IP "\fB\-mno-power\fR" 4 .IX Item "-mno-power" ! .IP "\fB\-mpower2\fR" 4 .IX Item "-mpower2" ! .IP "\fB\-mno-power2\fR" 4 .IX Item "-mno-power2" ! .IP "\fB\-mpowerpc\fR" 4 .IX Item "-mpowerpc" ! .IP "\fB\-mno-powerpc\fR" 4 .IX Item "-mno-powerpc" ! .IP "\fB\-mpowerpc-gpopt\fR" 4 .IX Item "-mpowerpc-gpopt" ! .IP "\fB\-mno-powerpc-gpopt\fR" 4 .IX Item "-mno-powerpc-gpopt" ! .IP "\fB\-mpowerpc-gfxopt\fR" 4 .IX Item "-mpowerpc-gfxopt" ! .IP "\fB\-mno-powerpc-gfxopt\fR" 4 .IX Item "-mno-powerpc-gfxopt" ! .IP "\fB\-mpowerpc64\fR" 4 .IX Item "-mpowerpc64" ! .IP "\fB\-mno-powerpc64\fR" 4 .IX Item "-mno-powerpc64" .PD \&\s-1GCC\s0 supports two related instruction set architectures for the *************** architectures plus some special \s-1AIX\ *** 5232,5241 **** the \s-1MQ\s0 register. Specifying both \fB\-mpower\fR and \fB\-mpowerpc\fR permits \s-1GCC\s0 to use any instruction from either architecture and to allow use of the \s-1MQ\s0 register; specify this for the Motorola \s-1MPC601\s0. ! .Ip "\fB\-mnew-mnemonics\fR" 4 .IX Item "-mnew-mnemonics" .PD 0 ! .Ip "\fB\-mold-mnemonics\fR" 4 .IX Item "-mold-mnemonics" .PD Select which mnemonics to use in the generated assembler code. --- 5234,5243 ---- the \s-1MQ\s0 register. Specifying both \fB\-mpower\fR and \fB\-mpowerpc\fR permits \s-1GCC\s0 to use any instruction from either architecture and to allow use of the \s-1MQ\s0 register; specify this for the Motorola \s-1MPC601\s0. ! .IP "\fB\-mnew-mnemonics\fR" 4 .IX Item "-mnew-mnemonics" .PD 0 ! .IP "\fB\-mold-mnemonics\fR" 4 .IX Item "-mold-mnemonics" .PD Select which mnemonics to use in the generated assembler code. *************** use. Specifying \fB\-mcpu=\fR\fIcpu_typ *** 5251,5257 **** value of these option. Unless you are building a cross-compiler, you should normally not specify either \fB\-mnew-mnemonics\fR or \&\fB\-mold-mnemonics\fR, but should instead accept the default. ! .Ip "\fB\-mcpu=\fR\fIcpu_type\fR" 4 .IX Item "-mcpu=cpu_type" Set architecture type, register usage, choice of mnemonics, and instruction scheduling parameters for machine type \fIcpu_type\fR. --- 5253,5259 ---- value of these option. Unless you are building a cross-compiler, you should normally not specify either \fB\-mnew-mnemonics\fR or \&\fB\-mold-mnemonics\fR, but should instead accept the default. ! .IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4 .IX Item "-mcpu=cpu_type" Set architecture type, register usage, choice of mnemonics, and instruction scheduling parameters for machine type \fIcpu_type\fR. *************** the \fBnew-mnemonics\fR option. *** 5298,5304 **** .Sp Specifying \fB\-mcpu=403\fR, \fB\-mcpu=821\fR, or \fB\-mcpu=860\fR also enables the \fB\-msoft-float\fR option. ! .Ip "\fB\-mtune=\fR\fIcpu_type\fR" 4 .IX Item "-mtune=cpu_type" Set the instruction scheduling parameters for machine type \&\fIcpu_type\fR, but do not set the architecture type, register usage, --- 5300,5306 ---- .Sp Specifying \fB\-mcpu=403\fR, \fB\-mcpu=821\fR, or \fB\-mcpu=860\fR also enables the \fB\-msoft-float\fR option. ! .IP "\fB\-mtune=\fR\fIcpu_type\fR" 4 .IX Item "-mtune=cpu_type" Set the instruction scheduling parameters for machine type \&\fIcpu_type\fR, but do not set the architecture type, register usage, *************** values for \fIcpu_type\fR are used for \ *** 5307,5320 **** for \fB\-mcpu=\fR\fIcpu_type\fR. The \fB\-mtune=\fR\fIcpu_type\fR option overrides the \fB\-mcpu=\fR\fIcpu_type\fR option in terms of instruction scheduling parameters. ! .Ip "\fB\-mfull-toc\fR" 4 .IX Item "-mfull-toc" .PD 0 ! .Ip "\fB\-mno-fp-in-toc\fR" 4 .IX Item "-mno-fp-in-toc" ! .Ip "\fB\-mno-sum-in-toc\fR" 4 .IX Item "-mno-sum-in-toc" ! .Ip "\fB\-mminimal-toc\fR" 4 .IX Item "-mminimal-toc" .PD Modify generation of the \s-1TOC\s0 (Table Of Contents), which is created for --- 5309,5322 ---- for \fB\-mcpu=\fR\fIcpu_type\fR. The \fB\-mtune=\fR\fIcpu_type\fR option overrides the \fB\-mcpu=\fR\fIcpu_type\fR option in terms of instruction scheduling parameters. ! .IP "\fB\-mfull-toc\fR" 4 .IX Item "-mfull-toc" .PD 0 ! .IP "\fB\-mno-fp-in-toc\fR" 4 .IX Item "-mno-fp-in-toc" ! .IP "\fB\-mno-sum-in-toc\fR" 4 .IX Item "-mno-sum-in-toc" ! .IP "\fB\-mminimal-toc\fR" 4 .IX Item "-mminimal-toc" .PD Modify generation of the \s-1TOC\s0 (Table Of Contents), which is created for *************** these options, specify \fB\-mminimal-toc *** 5340,5349 **** option, \s-1GCC\s0 will produce code that is slower and larger but which uses extremely little \s-1TOC\s0 space. You may wish to use this option only on files that contain less frequently executed code. ! .Ip "\fB\-maix64\fR" 4 .IX Item "-maix64" .PD 0 ! .Ip "\fB\-maix32\fR" 4 .IX Item "-maix32" .PD Enable 64\-bit \s-1AIX\s0 \s-1ABI\s0 and calling convention: 64\-bit pointers, 64\-bit --- 5342,5351 ---- option, \s-1GCC\s0 will produce code that is slower and larger but which uses extremely little \s-1TOC\s0 space. You may wish to use this option only on files that contain less frequently executed code. ! .IP "\fB\-maix64\fR" 4 .IX Item "-maix64" .PD 0 ! .IP "\fB\-maix32\fR" 4 .IX Item "-maix32" .PD Enable 64\-bit \s-1AIX\s0 \s-1ABI\s0 and calling convention: 64\-bit pointers, 64\-bit *************** Enable 64\-bit \s-1AIX\s0 \s-1ABI\s0 and *** 5351,5360 **** Specifying \fB\-maix64\fR implies \fB\-mpowerpc64\fR and \&\fB\-mpowerpc\fR, while \fB\-maix32\fR disables the 64\-bit \s-1ABI\s0 and implies \fB\-mno-powerpc64\fR. \s-1GCC\s0 defaults to \fB\-maix32\fR. ! .Ip "\fB\-mxl-call\fR" 4 .IX Item "-mxl-call" .PD 0 ! .Ip "\fB\-mno-xl-call\fR" 4 .IX Item "-mno-xl-call" .PD On \s-1AIX\s0, pass floating-point arguments to prototyped functions beyond the --- 5353,5362 ---- Specifying \fB\-maix64\fR implies \fB\-mpowerpc64\fR and \&\fB\-mpowerpc\fR, while \fB\-maix32\fR disables the 64\-bit \s-1ABI\s0 and implies \fB\-mno-powerpc64\fR. \s-1GCC\s0 defaults to \fB\-maix32\fR. ! .IP "\fB\-mxl-call\fR" 4 .IX Item "-mxl-call" .PD 0 ! .IP "\fB\-mno-xl-call\fR" 4 .IX Item "-mno-xl-call" .PD On \s-1AIX\s0, pass floating-point arguments to prototyped functions beyond the *************** optimization. Because always storing fl *** 5368,5379 **** stack is inefficient and rarely needed, this option is not enabled by default and only is necessary when calling subroutines compiled by \s-1AIX\s0 \&\s-1XL\s0 compilers without optimization. ! .Ip "\fB\-mthreads\fR" 4 .IX Item "-mthreads" Support \fI\s-1AIX\s0 Threads\fR. Link an application written to use \&\fIpthreads\fR with special libraries and startup code to enable the application to run. ! .Ip "\fB\-mpe\fR" 4 .IX Item "-mpe" Support \fI\s-1IBM\s0 \s-1RS/6000\s0 \s-1SP\s0\fR \fIParallel Environment\fR (\s-1PE\s0). Link an application written to use message passing with special startup code to --- 5370,5381 ---- stack is inefficient and rarely needed, this option is not enabled by default and only is necessary when calling subroutines compiled by \s-1AIX\s0 \&\s-1XL\s0 compilers without optimization. ! .IP "\fB\-mthreads\fR" 4 .IX Item "-mthreads" Support \fI\s-1AIX\s0 Threads\fR. Link an application written to use \&\fIpthreads\fR with special libraries and startup code to enable the application to run. ! .IP "\fB\-mpe\fR" 4 .IX Item "-mpe" Support \fI\s-1IBM\s0 \s-1RS/6000\s0 \s-1SP\s0\fR \fIParallel Environment\fR (\s-1PE\s0). Link an application written to use message passing with special startup code to *************** must be overridden with the \fB\-specs=\ *** 5383,5401 **** appropriate directory location. The Parallel Environment does not support threads, so the \fB\-mpe\fR option and the \fB\-mthreads\fR option are incompatible. ! .Ip "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" .PD 0 ! .Ip "\fB\-mhard-float\fR" 4 .IX Item "-mhard-float" .PD Generate code that does not use (uses) the floating-point register set. Software floating point emulation is provided if you use the \&\fB\-msoft-float\fR option, and pass the option to \s-1GCC\s0 when linking. ! .Ip "\fB\-mmultiple\fR" 4 .IX Item "-mmultiple" .PD 0 ! .Ip "\fB\-mno-multiple\fR" 4 .IX Item "-mno-multiple" .PD Generate code that uses (does not use) the load multiple word --- 5385,5403 ---- appropriate directory location. The Parallel Environment does not support threads, so the \fB\-mpe\fR option and the \fB\-mthreads\fR option are incompatible. ! .IP "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" .PD 0 ! .IP "\fB\-mhard-float\fR" 4 .IX Item "-mhard-float" .PD Generate code that does not use (uses) the floating-point register set. Software floating point emulation is provided if you use the \&\fB\-msoft-float\fR option, and pass the option to \s-1GCC\s0 when linking. ! .IP "\fB\-mmultiple\fR" 4 .IX Item "-mmultiple" .PD 0 ! .IP "\fB\-mno-multiple\fR" 4 .IX Item "-mno-multiple" .PD Generate code that uses (does not use) the load multiple word *************** generated on PowerPC systems. Do not us *** 5405,5414 **** endian PowerPC systems, since those instructions do not work when the processor is in little endian mode. The exceptions are \s-1PPC740\s0 and \&\s-1PPC750\s0 which permit the instructions usage in little endian mode. ! .Ip "\fB\-mstring\fR" 4 .IX Item "-mstring" .PD 0 ! .Ip "\fB\-mno-string\fR" 4 .IX Item "-mno-string" .PD Generate code that uses (does not use) the load string instructions --- 5407,5416 ---- endian PowerPC systems, since those instructions do not work when the processor is in little endian mode. The exceptions are \s-1PPC740\s0 and \&\s-1PPC750\s0 which permit the instructions usage in little endian mode. ! .IP "\fB\-mstring\fR" 4 .IX Item "-mstring" .PD 0 ! .IP "\fB\-mno-string\fR" 4 .IX Item "-mno-string" .PD Generate code that uses (does not use) the load string instructions *************** do small block moves. These instruction *** 5419,5428 **** instructions do not work when the processor is in little endian mode. The exceptions are \s-1PPC740\s0 and \s-1PPC750\s0 which permit the instructions usage in little endian mode. ! .Ip "\fB\-mupdate\fR" 4 .IX Item "-mupdate" .PD 0 ! .Ip "\fB\-mno-update\fR" 4 .IX Item "-mno-update" .PD Generate code that uses (does not use) the load or store instructions --- 5421,5430 ---- instructions do not work when the processor is in little endian mode. The exceptions are \s-1PPC740\s0 and \s-1PPC750\s0 which permit the instructions usage in little endian mode. ! .IP "\fB\-mupdate\fR" 4 .IX Item "-mupdate" .PD 0 ! .IP "\fB\-mno-update\fR" 4 .IX Item "-mno-update" .PD Generate code that uses (does not use) the load or store instructions *************** location. These instructions are genera *** 5432,5450 **** stack pointer is updated and the address of the previous frame is stored, which means code that walks the stack frame across interrupts or signals may get corrupted data. ! .Ip "\fB\-mfused-madd\fR" 4 .IX Item "-mfused-madd" .PD 0 ! .Ip "\fB\-mno-fused-madd\fR" 4 .IX Item "-mno-fused-madd" .PD Generate code that uses (does not use) the floating point multiply and accumulate instructions. These instructions are generated by default if hardware floating is used. ! .Ip "\fB\-mno-bit-align\fR" 4 .IX Item "-mno-bit-align" .PD 0 ! .Ip "\fB\-mbit-align\fR" 4 .IX Item "-mbit-align" .PD On System V.4 and embedded PowerPC systems do not (do) force structures --- 5434,5452 ---- stack pointer is updated and the address of the previous frame is stored, which means code that walks the stack frame across interrupts or signals may get corrupted data. ! .IP "\fB\-mfused-madd\fR" 4 .IX Item "-mfused-madd" .PD 0 ! .IP "\fB\-mno-fused-madd\fR" 4 .IX Item "-mno-fused-madd" .PD Generate code that uses (does not use) the floating point multiply and accumulate instructions. These instructions are generated by default if hardware floating is used. ! .IP "\fB\-mno-bit-align\fR" 4 .IX Item "-mno-bit-align" .PD 0 ! .IP "\fB\-mbit-align\fR" 4 .IX Item "-mbit-align" .PD On System V.4 and embedded PowerPC systems do not (do) force structures *************** For example, by default a structure cont *** 5456,5483 **** boundary and have a size of 4 bytes. By using \fB\-mno-bit-align\fR, the structure would be aligned to a 1 byte boundary and be one byte in size. ! .Ip "\fB\-mno-strict-align\fR" 4 .IX Item "-mno-strict-align" .PD 0 ! .Ip "\fB\-mstrict-align\fR" 4 .IX Item "-mstrict-align" .PD On System V.4 and embedded PowerPC systems do not (do) assume that unaligned memory references will be handled by the system. ! .Ip "\fB\-mrelocatable\fR" 4 .IX Item "-mrelocatable" .PD 0 ! .Ip "\fB\-mno-relocatable\fR" 4 .IX Item "-mno-relocatable" .PD On embedded PowerPC systems generate code that allows (does not allow) the program to be relocated to a different address at runtime. If you use \fB\-mrelocatable\fR on any module, all objects linked together must be compiled with \fB\-mrelocatable\fR or \fB\-mrelocatable-lib\fR. ! .Ip "\fB\-mrelocatable-lib\fR" 4 .IX Item "-mrelocatable-lib" .PD 0 ! .Ip "\fB\-mno-relocatable-lib\fR" 4 .IX Item "-mno-relocatable-lib" .PD On embedded PowerPC systems generate code that allows (does not allow) --- 5458,5485 ---- boundary and have a size of 4 bytes. By using \fB\-mno-bit-align\fR, the structure would be aligned to a 1 byte boundary and be one byte in size. ! .IP "\fB\-mno-strict-align\fR" 4 .IX Item "-mno-strict-align" .PD 0 ! .IP "\fB\-mstrict-align\fR" 4 .IX Item "-mstrict-align" .PD On System V.4 and embedded PowerPC systems do not (do) assume that unaligned memory references will be handled by the system. ! .IP "\fB\-mrelocatable\fR" 4 .IX Item "-mrelocatable" .PD 0 ! .IP "\fB\-mno-relocatable\fR" 4 .IX Item "-mno-relocatable" .PD On embedded PowerPC systems generate code that allows (does not allow) the program to be relocated to a different address at runtime. If you use \fB\-mrelocatable\fR on any module, all objects linked together must be compiled with \fB\-mrelocatable\fR or \fB\-mrelocatable-lib\fR. ! .IP "\fB\-mrelocatable-lib\fR" 4 .IX Item "-mrelocatable-lib" .PD 0 ! .IP "\fB\-mno-relocatable-lib\fR" 4 .IX Item "-mno-relocatable-lib" .PD On embedded PowerPC systems generate code that allows (does not allow) *************** the program to be relocated to a differe *** 5485,5546 **** compiled with \fB\-mrelocatable-lib\fR can be linked with either modules compiled without \fB\-mrelocatable\fR and \fB\-mrelocatable-lib\fR or with modules compiled with the \fB\-mrelocatable\fR options. ! .Ip "\fB\-mno-toc\fR" 4 .IX Item "-mno-toc" .PD 0 ! .Ip "\fB\-mtoc\fR" 4 .IX Item "-mtoc" .PD On System V.4 and embedded PowerPC systems do not (do) assume that register 2 contains a pointer to a global area pointing to the addresses used in the program. ! .Ip "\fB\-mlittle\fR" 4 .IX Item "-mlittle" .PD 0 ! .Ip "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" .PD On System V.4 and embedded PowerPC systems compile code for the processor in little endian mode. The \fB\-mlittle-endian\fR option is the same as \fB\-mlittle\fR. ! .Ip "\fB\-mbig\fR" 4 .IX Item "-mbig" .PD 0 ! .Ip "\fB\-mbig-endian\fR" 4 .IX Item "-mbig-endian" .PD On System V.4 and embedded PowerPC systems compile code for the processor in big endian mode. The \fB\-mbig-endian\fR option is the same as \fB\-mbig\fR. ! .Ip "\fB\-mcall-sysv\fR" 4 .IX Item "-mcall-sysv" On System V.4 and embedded PowerPC systems compile code using calling conventions that adheres to the March 1995 draft of the System V Application Binary Interface, PowerPC processor supplement. This is the default unless you configured \s-1GCC\s0 using \fBpowerpc-*\-eabiaix\fR. ! .Ip "\fB\-mcall-sysv-eabi\fR" 4 .IX Item "-mcall-sysv-eabi" Specify both \fB\-mcall-sysv\fR and \fB\-meabi\fR options. ! .Ip "\fB\-mcall-sysv-noeabi\fR" 4 .IX Item "-mcall-sysv-noeabi" Specify both \fB\-mcall-sysv\fR and \fB\-mno-eabi\fR options. ! .Ip "\fB\-mcall-aix\fR" 4 .IX Item "-mcall-aix" On System V.4 and embedded PowerPC systems compile code using calling conventions that are similar to those used on \s-1AIX\s0. This is the default if you configured \s-1GCC\s0 using \fBpowerpc-*\-eabiaix\fR. ! .Ip "\fB\-mcall-solaris\fR" 4 .IX Item "-mcall-solaris" On System V.4 and embedded PowerPC systems compile code for the Solaris operating system. ! .Ip "\fB\-mcall-linux\fR" 4 .IX Item "-mcall-linux" On System V.4 and embedded PowerPC systems compile code for the Linux-based \s-1GNU\s0 system. ! .Ip "\fB\-mprototype\fR" 4 .IX Item "-mprototype" .PD 0 ! .Ip "\fB\-mno-prototype\fR" 4 .IX Item "-mno-prototype" .PD On System V.4 and embedded PowerPC systems assume that all calls to --- 5487,5548 ---- compiled with \fB\-mrelocatable-lib\fR can be linked with either modules compiled without \fB\-mrelocatable\fR and \fB\-mrelocatable-lib\fR or with modules compiled with the \fB\-mrelocatable\fR options. ! .IP "\fB\-mno-toc\fR" 4 .IX Item "-mno-toc" .PD 0 ! .IP "\fB\-mtoc\fR" 4 .IX Item "-mtoc" .PD On System V.4 and embedded PowerPC systems do not (do) assume that register 2 contains a pointer to a global area pointing to the addresses used in the program. ! .IP "\fB\-mlittle\fR" 4 .IX Item "-mlittle" .PD 0 ! .IP "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" .PD On System V.4 and embedded PowerPC systems compile code for the processor in little endian mode. The \fB\-mlittle-endian\fR option is the same as \fB\-mlittle\fR. ! .IP "\fB\-mbig\fR" 4 .IX Item "-mbig" .PD 0 ! .IP "\fB\-mbig-endian\fR" 4 .IX Item "-mbig-endian" .PD On System V.4 and embedded PowerPC systems compile code for the processor in big endian mode. The \fB\-mbig-endian\fR option is the same as \fB\-mbig\fR. ! .IP "\fB\-mcall-sysv\fR" 4 .IX Item "-mcall-sysv" On System V.4 and embedded PowerPC systems compile code using calling conventions that adheres to the March 1995 draft of the System V Application Binary Interface, PowerPC processor supplement. This is the default unless you configured \s-1GCC\s0 using \fBpowerpc-*\-eabiaix\fR. ! .IP "\fB\-mcall-sysv-eabi\fR" 4 .IX Item "-mcall-sysv-eabi" Specify both \fB\-mcall-sysv\fR and \fB\-meabi\fR options. ! .IP "\fB\-mcall-sysv-noeabi\fR" 4 .IX Item "-mcall-sysv-noeabi" Specify both \fB\-mcall-sysv\fR and \fB\-mno-eabi\fR options. ! .IP "\fB\-mcall-aix\fR" 4 .IX Item "-mcall-aix" On System V.4 and embedded PowerPC systems compile code using calling conventions that are similar to those used on \s-1AIX\s0. This is the default if you configured \s-1GCC\s0 using \fBpowerpc-*\-eabiaix\fR. ! .IP "\fB\-mcall-solaris\fR" 4 .IX Item "-mcall-solaris" On System V.4 and embedded PowerPC systems compile code for the Solaris operating system. ! .IP "\fB\-mcall-linux\fR" 4 .IX Item "-mcall-linux" On System V.4 and embedded PowerPC systems compile code for the Linux-based \s-1GNU\s0 system. ! .IP "\fB\-mprototype\fR" 4 .IX Item "-mprototype" .PD 0 ! .IP "\fB\-mno-prototype\fR" 4 .IX Item "-mno-prototype" .PD On System V.4 and embedded PowerPC systems assume that all calls to *************** indicate whether floating point values w *** 5551,5589 **** registers in case the function takes a variable arguments. With \&\fB\-mprototype\fR, only calls to prototyped variable argument functions will set or clear the bit. ! .Ip "\fB\-msim\fR" 4 .IX Item "-msim" On embedded PowerPC systems, assume that the startup module is called \&\fIsim-crt0.o\fR and that the standard C libraries are \fIlibsim.a\fR and \&\fIlibc.a\fR. This is the default for \fBpowerpc-*\-eabisim\fR. configurations. ! .Ip "\fB\-mmvme\fR" 4 .IX Item "-mmvme" On embedded PowerPC systems, assume that the startup module is called \&\fIcrt0.o\fR and the standard C libraries are \fIlibmvme.a\fR and \&\fIlibc.a\fR. ! .Ip "\fB\-mads\fR" 4 .IX Item "-mads" On embedded PowerPC systems, assume that the startup module is called \&\fIcrt0.o\fR and the standard C libraries are \fIlibads.a\fR and \&\fIlibc.a\fR. ! .Ip "\fB\-myellowknife\fR" 4 .IX Item "-myellowknife" On embedded PowerPC systems, assume that the startup module is called \&\fIcrt0.o\fR and the standard C libraries are \fIlibyk.a\fR and \&\fIlibc.a\fR. ! .Ip "\fB\-mvxworks\fR" 4 .IX Item "-mvxworks" On System V.4 and embedded PowerPC systems, specify that you are compiling for a VxWorks system. ! .Ip "\fB\-memb\fR" 4 .IX Item "-memb" On embedded PowerPC systems, set the \fI\s-1PPC_EMB\s0\fR bit in the \s-1ELF\s0 flags header to indicate that \fBeabi\fR extended relocations are used. ! .Ip "\fB\-meabi\fR" 4 .IX Item "-meabi" .PD 0 ! .Ip "\fB\-mno-eabi\fR" 4 .IX Item "-mno-eabi" .PD On System V.4 and embedded PowerPC systems do (do not) adhere to the --- 5553,5591 ---- registers in case the function takes a variable arguments. With \&\fB\-mprototype\fR, only calls to prototyped variable argument functions will set or clear the bit. ! .IP "\fB\-msim\fR" 4 .IX Item "-msim" On embedded PowerPC systems, assume that the startup module is called \&\fIsim-crt0.o\fR and that the standard C libraries are \fIlibsim.a\fR and \&\fIlibc.a\fR. This is the default for \fBpowerpc-*\-eabisim\fR. configurations. ! .IP "\fB\-mmvme\fR" 4 .IX Item "-mmvme" On embedded PowerPC systems, assume that the startup module is called \&\fIcrt0.o\fR and the standard C libraries are \fIlibmvme.a\fR and \&\fIlibc.a\fR. ! .IP "\fB\-mads\fR" 4 .IX Item "-mads" On embedded PowerPC systems, assume that the startup module is called \&\fIcrt0.o\fR and the standard C libraries are \fIlibads.a\fR and \&\fIlibc.a\fR. ! .IP "\fB\-myellowknife\fR" 4 .IX Item "-myellowknife" On embedded PowerPC systems, assume that the startup module is called \&\fIcrt0.o\fR and the standard C libraries are \fIlibyk.a\fR and \&\fIlibc.a\fR. ! .IP "\fB\-mvxworks\fR" 4 .IX Item "-mvxworks" On System V.4 and embedded PowerPC systems, specify that you are compiling for a VxWorks system. ! .IP "\fB\-memb\fR" 4 .IX Item "-memb" On embedded PowerPC systems, set the \fI\s-1PPC_EMB\s0\fR bit in the \s-1ELF\s0 flags header to indicate that \fBeabi\fR extended relocations are used. ! .IP "\fB\-meabi\fR" 4 .IX Item "-meabi" .PD 0 ! .IP "\fB\-mno-eabi\fR" 4 .IX Item "-mno-eabi" .PD On System V.4 and embedded PowerPC systems do (do not) adhere to the *************** do not call an initialization function f *** 5598,5604 **** \&\fB\-msdata\fR option will only use \f(CW\*(C`r13\*(C'\fR to point to a single small data area. The \fB\-meabi\fR option is on by default if you configured \s-1GCC\s0 using one of the \fBpowerpc*\-*\-eabi*\fR options. ! .Ip "\fB\-msdata=eabi\fR" 4 .IX Item "-msdata=eabi" On System V.4 and embedded PowerPC systems, put small initialized \&\f(CW\*(C`const\*(C'\fR global and static data in the \fB.sdata2\fR section, which --- 5600,5606 ---- \&\fB\-msdata\fR option will only use \f(CW\*(C`r13\*(C'\fR to point to a single small data area. The \fB\-meabi\fR option is on by default if you configured \s-1GCC\s0 using one of the \fBpowerpc*\-*\-eabi*\fR options. ! .IP "\fB\-msdata=eabi\fR" 4 .IX Item "-msdata=eabi" On System V.4 and embedded PowerPC systems, put small initialized \&\f(CW\*(C`const\*(C'\fR global and static data in the \fB.sdata2\fR section, which *************** global and static data in the \fB.sbss\f *** 5609,5615 **** the \fB.sdata\fR section. The \fB\-msdata=eabi\fR option is incompatible with the \fB\-mrelocatable\fR option. The \&\fB\-msdata=eabi\fR option also sets the \fB\-memb\fR option. ! .Ip "\fB\-msdata=sysv\fR" 4 .IX Item "-msdata=sysv" On System V.4 and embedded PowerPC systems, put small global and static data in the \fB.sdata\fR section, which is pointed to by register --- 5611,5617 ---- the \fB.sdata\fR section. The \fB\-msdata=eabi\fR option is incompatible with the \fB\-mrelocatable\fR option. The \&\fB\-msdata=eabi\fR option also sets the \fB\-memb\fR option. ! .IP "\fB\-msdata=sysv\fR" 4 .IX Item "-msdata=sysv" On System V.4 and embedded PowerPC systems, put small global and static data in the \fB.sdata\fR section, which is pointed to by register *************** data in the \fB.sdata\fR section, which *** 5617,5658 **** \&\fB.sbss\fR section, which is adjacent to the \fB.sdata\fR section. The \fB\-msdata=sysv\fR option is incompatible with the \&\fB\-mrelocatable\fR option. ! .Ip "\fB\-msdata=default\fR" 4 .IX Item "-msdata=default" .PD 0 ! .Ip "\fB\-msdata\fR" 4 .IX Item "-msdata" .PD On System V.4 and embedded PowerPC systems, if \fB\-meabi\fR is used, compile code the same as \fB\-msdata=eabi\fR, otherwise compile code the same as \fB\-msdata=sysv\fR. ! .Ip "\fB\-msdata-data\fR" 4 .IX Item "-msdata-data" On System V.4 and embedded PowerPC systems, put small global and static data in the \fB.sdata\fR section. Put small uninitialized global and static data in the \fB.sbss\fR section. Do not use register \f(CW\*(C`r13\*(C'\fR to address small data however. This is the default behavior unless other \fB\-msdata\fR options are used. ! .Ip "\fB\-msdata=none\fR" 4 .IX Item "-msdata=none" .PD 0 ! .Ip "\fB\-mno-sdata\fR" 4 .IX Item "-mno-sdata" .PD On embedded PowerPC systems, put all initialized global and static data in the \fB.data\fR section, and all uninitialized data in the \&\fB.bss\fR section. ! .Ip "\fB\-G\fR \fInum\fR" 4 .IX Item "-G num" On embedded PowerPC systems, put global and static items less than or equal to \fInum\fR bytes into the small data or bss sections instead of the normal data or bss section. By default, \fInum\fR is 8. The \&\fB\-G\fR \fInum\fR switch is also passed to the linker. All modules should be compiled with the same \fB\-G\fR \fInum\fR value. ! .Ip "\fB\-mregnames\fR" 4 .IX Item "-mregnames" .PD 0 ! .Ip "\fB\-mno-regnames\fR" 4 .IX Item "-mno-regnames" .PD On System V.4 and embedded PowerPC systems do (do not) emit register --- 5619,5660 ---- \&\fB.sbss\fR section, which is adjacent to the \fB.sdata\fR section. The \fB\-msdata=sysv\fR option is incompatible with the \&\fB\-mrelocatable\fR option. ! .IP "\fB\-msdata=default\fR" 4 .IX Item "-msdata=default" .PD 0 ! .IP "\fB\-msdata\fR" 4 .IX Item "-msdata" .PD On System V.4 and embedded PowerPC systems, if \fB\-meabi\fR is used, compile code the same as \fB\-msdata=eabi\fR, otherwise compile code the same as \fB\-msdata=sysv\fR. ! .IP "\fB\-msdata-data\fR" 4 .IX Item "-msdata-data" On System V.4 and embedded PowerPC systems, put small global and static data in the \fB.sdata\fR section. Put small uninitialized global and static data in the \fB.sbss\fR section. Do not use register \f(CW\*(C`r13\*(C'\fR to address small data however. This is the default behavior unless other \fB\-msdata\fR options are used. ! .IP "\fB\-msdata=none\fR" 4 .IX Item "-msdata=none" .PD 0 ! .IP "\fB\-mno-sdata\fR" 4 .IX Item "-mno-sdata" .PD On embedded PowerPC systems, put all initialized global and static data in the \fB.data\fR section, and all uninitialized data in the \&\fB.bss\fR section. ! .IP "\fB\-G\fR \fInum\fR" 4 .IX Item "-G num" On embedded PowerPC systems, put global and static items less than or equal to \fInum\fR bytes into the small data or bss sections instead of the normal data or bss section. By default, \fInum\fR is 8. The \&\fB\-G\fR \fInum\fR switch is also passed to the linker. All modules should be compiled with the same \fB\-G\fR \fInum\fR value. ! .IP "\fB\-mregnames\fR" 4 .IX Item "-mregnames" .PD 0 ! .IP "\fB\-mno-regnames\fR" 4 .IX Item "-mno-regnames" .PD On System V.4 and embedded PowerPC systems do (do not) emit register *************** names in the assembly language output us *** 5662,5700 **** .IX Subsection "IBM RT Options" .PP These \fB\-m\fR options are defined for the \s-1IBM\s0 \s-1RT\s0 \s-1PC:\s0 ! .Ip "\fB\-min-line-mul\fR" 4 .IX Item "-min-line-mul" Use an in-line code sequence for integer multiplies. This is the default. ! .Ip "\fB\-mcall-lib-mul\fR" 4 .IX Item "-mcall-lib-mul" Call \f(CW\*(C`lmul$$\*(C'\fR for integer multiples. ! .Ip "\fB\-mfull-fp-blocks\fR" 4 .IX Item "-mfull-fp-blocks" Generate full-size floating point data blocks, including the minimum amount of scratch space recommended by \s-1IBM\s0. This is the default. ! .Ip "\fB\-mminimum-fp-blocks\fR" 4 .IX Item "-mminimum-fp-blocks" Do not include extra scratch space in floating point data blocks. This results in smaller code, but slower execution, since scratch space must be allocated dynamically. ! .Ip "\fB\-mfp-arg-in-fpregs\fR" 4 .IX Item "-mfp-arg-in-fpregs" Use a calling sequence incompatible with the \s-1IBM\s0 calling convention in which floating point arguments are passed in floating point registers. Note that \f(CW\*(C`varargs.h\*(C'\fR and \f(CW\*(C`stdarg.h\*(C'\fR will not work with floating point operands if this option is specified. ! .Ip "\fB\-mfp-arg-in-gregs\fR" 4 .IX Item "-mfp-arg-in-gregs" Use the normal calling convention for floating point arguments. This is the default. ! .Ip "\fB\-mhc-struct-return\fR" 4 .IX Item "-mhc-struct-return" Return structures of more than one word in memory, rather than in a register. This provides compatibility with the MetaWare HighC (hc) compiler. Use the option \fB\-fpcc-struct-return\fR for compatibility with the Portable C Compiler (pcc). ! .Ip "\fB\-mnohc-struct-return\fR" 4 .IX Item "-mnohc-struct-return" Return some structures of more than one word in registers, when convenient. This is the default. For compatibility with the --- 5664,5702 ---- .IX Subsection "IBM RT Options" .PP These \fB\-m\fR options are defined for the \s-1IBM\s0 \s-1RT\s0 \s-1PC:\s0 ! .IP "\fB\-min-line-mul\fR" 4 .IX Item "-min-line-mul" Use an in-line code sequence for integer multiplies. This is the default. ! .IP "\fB\-mcall-lib-mul\fR" 4 .IX Item "-mcall-lib-mul" Call \f(CW\*(C`lmul$$\*(C'\fR for integer multiples. ! .IP "\fB\-mfull-fp-blocks\fR" 4 .IX Item "-mfull-fp-blocks" Generate full-size floating point data blocks, including the minimum amount of scratch space recommended by \s-1IBM\s0. This is the default. ! .IP "\fB\-mminimum-fp-blocks\fR" 4 .IX Item "-mminimum-fp-blocks" Do not include extra scratch space in floating point data blocks. This results in smaller code, but slower execution, since scratch space must be allocated dynamically. ! .IP "\fB\-mfp-arg-in-fpregs\fR" 4 .IX Item "-mfp-arg-in-fpregs" Use a calling sequence incompatible with the \s-1IBM\s0 calling convention in which floating point arguments are passed in floating point registers. Note that \f(CW\*(C`varargs.h\*(C'\fR and \f(CW\*(C`stdarg.h\*(C'\fR will not work with floating point operands if this option is specified. ! .IP "\fB\-mfp-arg-in-gregs\fR" 4 .IX Item "-mfp-arg-in-gregs" Use the normal calling convention for floating point arguments. This is the default. ! .IP "\fB\-mhc-struct-return\fR" 4 .IX Item "-mhc-struct-return" Return structures of more than one word in memory, rather than in a register. This provides compatibility with the MetaWare HighC (hc) compiler. Use the option \fB\-fpcc-struct-return\fR for compatibility with the Portable C Compiler (pcc). ! .IP "\fB\-mnohc-struct-return\fR" 4 .IX Item "-mnohc-struct-return" Return some structures of more than one word in registers, when convenient. This is the default. For compatibility with the *************** option \fB\-mhc-struct-return\fR. *** 5705,5711 **** .IX Subsection "MIPS Options" .PP These \fB\-m\fR options are defined for the \s-1MIPS\s0 family of computers: ! .Ip "\fB\-mcpu=\fR\fIcpu-type\fR" 4 .IX Item "-mcpu=cpu-type" Assume the defaults for the machine type \fIcpu-type\fR when scheduling instructions. The choices for \fIcpu-type\fR are \fBr2000\fR, \fBr3000\fR, --- 5707,5713 ---- .IX Subsection "MIPS Options" .PP These \fB\-m\fR options are defined for the \s-1MIPS\s0 family of computers: ! .IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4 .IX Item "-mcpu=cpu-type" Assume the defaults for the machine type \fIcpu-type\fR when scheduling instructions. The choices for \fIcpu-type\fR are \fBr2000\fR, \fBr3000\fR, *************** and \fBorion\fR. Additionally, the \fBr *** 5718,5766 **** chip, the compiler will not generate any code that does not meet level 1 of the \s-1MIPS\s0 \s-1ISA\s0 (instruction set architecture) without a \fB\-mipsX\fR or \fB\-mabi\fR switch being used. ! .Ip "\fB\-mips1\fR" 4 .IX Item "-mips1" Issue instructions from level 1 of the \s-1MIPS\s0 \s-1ISA\s0. This is the default. \&\fBr3000\fR is the default \fIcpu-type\fR at this \s-1ISA\s0 level. ! .Ip "\fB\-mips2\fR" 4 .IX Item "-mips2" Issue instructions from level 2 of the \s-1MIPS\s0 \s-1ISA\s0 (branch likely, square root instructions). \fBr6000\fR is the default \fIcpu-type\fR at this \&\s-1ISA\s0 level. ! .Ip "\fB\-mips3\fR" 4 .IX Item "-mips3" Issue instructions from level 3 of the \s-1MIPS\s0 \s-1ISA\s0 (64\-bit instructions). \&\fBr4000\fR is the default \fIcpu-type\fR at this \s-1ISA\s0 level. ! .Ip "\fB\-mips4\fR" 4 .IX Item "-mips4" Issue instructions from level 4 of the \s-1MIPS\s0 \s-1ISA\s0 (conditional move, prefetch, enhanced \s-1FPU\s0 instructions). \fBr8000\fR is the default \&\fIcpu-type\fR at this \s-1ISA\s0 level. ! .Ip "\fB\-mfp32\fR" 4 .IX Item "-mfp32" Assume that 32 32\-bit floating point registers are available. This is the default. ! .Ip "\fB\-mfp64\fR" 4 .IX Item "-mfp64" Assume that 32 64\-bit floating point registers are available. This is the default when the \fB\-mips3\fR option is used. ! .Ip "\fB\-mgp32\fR" 4 .IX Item "-mgp32" Assume that 32 32\-bit general purpose registers are available. This is the default. ! .Ip "\fB\-mgp64\fR" 4 .IX Item "-mgp64" Assume that 32 64\-bit general purpose registers are available. This is the default when the \fB\-mips3\fR option is used. ! .Ip "\fB\-mint64\fR" 4 .IX Item "-mint64" Force int and long types to be 64 bits wide. See \fB\-mlong32\fR for an explanation of the default, and the width of pointers. ! .Ip "\fB\-mlong64\fR" 4 .IX Item "-mlong64" Force long types to be 64 bits wide. See \fB\-mlong32\fR for an explanation of the default, and the width of pointers. ! .Ip "\fB\-mlong32\fR" 4 .IX Item "-mlong32" Force long, int, and pointer types to be 32 bits wide. .Sp --- 5720,5768 ---- chip, the compiler will not generate any code that does not meet level 1 of the \s-1MIPS\s0 \s-1ISA\s0 (instruction set architecture) without a \fB\-mipsX\fR or \fB\-mabi\fR switch being used. ! .IP "\fB\-mips1\fR" 4 .IX Item "-mips1" Issue instructions from level 1 of the \s-1MIPS\s0 \s-1ISA\s0. This is the default. \&\fBr3000\fR is the default \fIcpu-type\fR at this \s-1ISA\s0 level. ! .IP "\fB\-mips2\fR" 4 .IX Item "-mips2" Issue instructions from level 2 of the \s-1MIPS\s0 \s-1ISA\s0 (branch likely, square root instructions). \fBr6000\fR is the default \fIcpu-type\fR at this \&\s-1ISA\s0 level. ! .IP "\fB\-mips3\fR" 4 .IX Item "-mips3" Issue instructions from level 3 of the \s-1MIPS\s0 \s-1ISA\s0 (64\-bit instructions). \&\fBr4000\fR is the default \fIcpu-type\fR at this \s-1ISA\s0 level. ! .IP "\fB\-mips4\fR" 4 .IX Item "-mips4" Issue instructions from level 4 of the \s-1MIPS\s0 \s-1ISA\s0 (conditional move, prefetch, enhanced \s-1FPU\s0 instructions). \fBr8000\fR is the default \&\fIcpu-type\fR at this \s-1ISA\s0 level. ! .IP "\fB\-mfp32\fR" 4 .IX Item "-mfp32" Assume that 32 32\-bit floating point registers are available. This is the default. ! .IP "\fB\-mfp64\fR" 4 .IX Item "-mfp64" Assume that 32 64\-bit floating point registers are available. This is the default when the \fB\-mips3\fR option is used. ! .IP "\fB\-mgp32\fR" 4 .IX Item "-mgp32" Assume that 32 32\-bit general purpose registers are available. This is the default. ! .IP "\fB\-mgp64\fR" 4 .IX Item "-mgp64" Assume that 32 64\-bit general purpose registers are available. This is the default when the \fB\-mips3\fR option is used. ! .IP "\fB\-mint64\fR" 4 .IX Item "-mint64" Force int and long types to be 64 bits wide. See \fB\-mlong32\fR for an explanation of the default, and the width of pointers. ! .IP "\fB\-mlong64\fR" 4 .IX Item "-mlong64" Force long types to be 64 bits wide. See \fB\-mlong32\fR for an explanation of the default, and the width of pointers. ! .IP "\fB\-mlong32\fR" 4 .IX Item "-mlong32" Force long, int, and pointer types to be 32 bits wide. .Sp *************** and longs are 32 bits wide. For \fB\-ma *** 5773,5788 **** are 32 bits, and longs are 64 bits wide. The width of pointer types is the smaller of the width of longs or the width of general purpose registers (which in turn depends on the \s-1ISA\s0). ! .Ip "\fB\-mabi=32\fR" 4 .IX Item "-mabi=32" .PD 0 ! .Ip "\fB\-mabi=o64\fR" 4 .IX Item "-mabi=o64" ! .Ip "\fB\-mabi=n32\fR" 4 .IX Item "-mabi=n32" ! .Ip "\fB\-mabi=64\fR" 4 .IX Item "-mabi=64" ! .Ip "\fB\-mabi=eabi\fR" 4 .IX Item "-mabi=eabi" .PD Generate code for the indicated \s-1ABI\s0. The default instruction level is --- 5775,5790 ---- are 32 bits, and longs are 64 bits wide. The width of pointer types is the smaller of the width of longs or the width of general purpose registers (which in turn depends on the \s-1ISA\s0). ! .IP "\fB\-mabi=32\fR" 4 .IX Item "-mabi=32" .PD 0 ! .IP "\fB\-mabi=o64\fR" 4 .IX Item "-mabi=o64" ! .IP "\fB\-mabi=n32\fR" 4 .IX Item "-mabi=n32" ! .IP "\fB\-mabi=64\fR" 4 .IX Item "-mabi=64" ! .IP "\fB\-mabi=eabi\fR" 4 .IX Item "-mabi=eabi" .PD Generate code for the indicated \s-1ABI\s0. The default instruction level is *************** Generate code for the indicated \s-1ABI\ *** 5790,5796 **** \&\fB\-mips4\fR otherwise. Conversely, with \fB\-mips1\fR or \&\fB\-mips2\fR, the default \s-1ABI\s0 is \fB32\fR; otherwise, the default \s-1ABI\s0 is \fB64\fR. ! .Ip "\fB\-mmips-as\fR" 4 .IX Item "-mmips-as" Generate code for the \s-1MIPS\s0 assembler, and invoke \fImips-tfile\fR to add normal debug information. This is the default for all --- 5792,5798 ---- \&\fB\-mips4\fR otherwise. Conversely, with \fB\-mips1\fR or \&\fB\-mips2\fR, the default \s-1ABI\s0 is \fB32\fR; otherwise, the default \s-1ABI\s0 is \fB64\fR. ! .IP "\fB\-mmips-as\fR" 4 .IX Item "-mmips-as" Generate code for the \s-1MIPS\s0 assembler, and invoke \fImips-tfile\fR to add normal debug information. This is the default for all *************** platforms except for the \s-1OSF/1\s0 re *** 5798,5812 **** object format. If the either of the \fB\-gstabs\fR or \fB\-gstabs+\fR switches are used, the \fImips-tfile\fR program will encapsulate the stabs within \s-1MIPS\s0 \s-1ECOFF\s0. ! .Ip "\fB\-mgas\fR" 4 .IX Item "-mgas" Generate code for the \s-1GNU\s0 assembler. This is the default on the \s-1OSF/1\s0 reference platform, using the OSF/rose object format. Also, this is the default if the configure option \fB\*(--with-gnu-as\fR is used. ! .Ip "\fB\-msplit-addresses\fR" 4 .IX Item "-msplit-addresses" .PD 0 ! .Ip "\fB\-mno-split-addresses\fR" 4 .IX Item "-mno-split-addresses" .PD Generate code to load the high and low parts of address constants separately. --- 5800,5814 ---- object format. If the either of the \fB\-gstabs\fR or \fB\-gstabs+\fR switches are used, the \fImips-tfile\fR program will encapsulate the stabs within \s-1MIPS\s0 \s-1ECOFF\s0. ! .IP "\fB\-mgas\fR" 4 .IX Item "-mgas" Generate code for the \s-1GNU\s0 assembler. This is the default on the \s-1OSF/1\s0 reference platform, using the OSF/rose object format. Also, this is the default if the configure option \fB\*(--with-gnu-as\fR is used. ! .IP "\fB\-msplit-addresses\fR" 4 .IX Item "-msplit-addresses" .PD 0 ! .IP "\fB\-mno-split-addresses\fR" 4 .IX Item "-mno-split-addresses" .PD Generate code to load the high and low parts of address constants separately. *************** This allows \s-1GCC\s0 to optimize away *** 5814,5833 **** bits of addresses. This optimization requires \s-1GNU\s0 as and \s-1GNU\s0 ld. This optimization is enabled by default for some embedded targets where \&\s-1GNU\s0 as and \s-1GNU\s0 ld are standard. ! .Ip "\fB\-mrnames\fR" 4 .IX Item "-mrnames" .PD 0 ! .Ip "\fB\-mno-rnames\fR" 4 .IX Item "-mno-rnames" .PD The \fB\-mrnames\fR switch says to output code using the \s-1MIPS\s0 software names for the registers, instead of the hardware names (ie, \fIa0\fR instead of \fI$4\fR). The only known assembler that supports this option is the Algorithmics assembler. ! .Ip "\fB\-mgpopt\fR" 4 .IX Item "-mgpopt" .PD 0 ! .Ip "\fB\-mno-gpopt\fR" 4 .IX Item "-mno-gpopt" .PD The \fB\-mgpopt\fR switch says to write all of the data declarations --- 5816,5835 ---- bits of addresses. This optimization requires \s-1GNU\s0 as and \s-1GNU\s0 ld. This optimization is enabled by default for some embedded targets where \&\s-1GNU\s0 as and \s-1GNU\s0 ld are standard. ! .IP "\fB\-mrnames\fR" 4 .IX Item "-mrnames" .PD 0 ! .IP "\fB\-mno-rnames\fR" 4 .IX Item "-mno-rnames" .PD The \fB\-mrnames\fR switch says to output code using the \s-1MIPS\s0 software names for the registers, instead of the hardware names (ie, \fIa0\fR instead of \fI$4\fR). The only known assembler that supports this option is the Algorithmics assembler. ! .IP "\fB\-mgpopt\fR" 4 .IX Item "-mgpopt" .PD 0 ! .IP "\fB\-mno-gpopt\fR" 4 .IX Item "-mno-gpopt" .PD The \fB\-mgpopt\fR switch says to write all of the data declarations *************** before the instructions in the text sect *** 5835,5863 **** assembler to generate one word memory references instead of using two words for short global or static data items. This is on by default if optimization is selected. ! .Ip "\fB\-mstats\fR" 4 .IX Item "-mstats" .PD 0 ! .Ip "\fB\-mno-stats\fR" 4 .IX Item "-mno-stats" .PD For each non-inline function processed, the \fB\-mstats\fR switch causes the compiler to emit one line to the standard error file to print statistics about the program (number of registers saved, stack size, etc.). ! .Ip "\fB\-mmemcpy\fR" 4 .IX Item "-mmemcpy" .PD 0 ! .Ip "\fB\-mno-memcpy\fR" 4 .IX Item "-mno-memcpy" .PD The \fB\-mmemcpy\fR switch makes all block moves call the appropriate string function (\fBmemcpy\fR or \fBbcopy\fR) instead of possibly generating inline code. ! .Ip "\fB\-mmips-tfile\fR" 4 .IX Item "-mmips-tfile" .PD 0 ! .Ip "\fB\-mno-mips-tfile\fR" 4 .IX Item "-mno-mips-tfile" .PD The \fB\-mno-mips-tfile\fR switch causes the compiler not --- 5837,5865 ---- assembler to generate one word memory references instead of using two words for short global or static data items. This is on by default if optimization is selected. ! .IP "\fB\-mstats\fR" 4 .IX Item "-mstats" .PD 0 ! .IP "\fB\-mno-stats\fR" 4 .IX Item "-mno-stats" .PD For each non-inline function processed, the \fB\-mstats\fR switch causes the compiler to emit one line to the standard error file to print statistics about the program (number of registers saved, stack size, etc.). ! .IP "\fB\-mmemcpy\fR" 4 .IX Item "-mmemcpy" .PD 0 ! .IP "\fB\-mno-memcpy\fR" 4 .IX Item "-mno-memcpy" .PD The \fB\-mmemcpy\fR switch makes all block moves call the appropriate string function (\fBmemcpy\fR or \fBbcopy\fR) instead of possibly generating inline code. ! .IP "\fB\-mmips-tfile\fR" 4 .IX Item "-mmips-tfile" .PD 0 ! .IP "\fB\-mno-mips-tfile\fR" 4 .IX Item "-mno-mips-tfile" .PD The \fB\-mno-mips-tfile\fR switch causes the compiler not *************** assembler embedded in the object file, w *** 5870,5876 **** not compare the same. The \fB\-mno-mips-tfile\fR switch should only be used when there are bugs in the \fImips-tfile\fR program that prevents compilation. ! .Ip "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries are not part of \s-1GCC\s0. --- 5872,5878 ---- not compare the same. The \fB\-mno-mips-tfile\fR switch should only be used when there are bugs in the \fImips-tfile\fR program that prevents compilation. ! .IP "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries are not part of \s-1GCC\s0. *************** Normally the facilities of the machine's *** 5878,5918 **** this can't be done directly in cross-compilation. You must make your own arrangements to provide suitable library functions for cross-compilation. ! .Ip "\fB\-mhard-float\fR" 4 .IX Item "-mhard-float" Generate output containing floating point instructions. This is the default if you use the unmodified sources. ! .Ip "\fB\-mabicalls\fR" 4 .IX Item "-mabicalls" .PD 0 ! .Ip "\fB\-mno-abicalls\fR" 4 .IX Item "-mno-abicalls" .PD Emit (or do not emit) the pseudo operations \fB.abicalls\fR, \&\fB.cpload\fR, and \fB.cprestore\fR that some System V.4 ports use for position independent code. ! .Ip "\fB\-mlong-calls\fR" 4 .IX Item "-mlong-calls" .PD 0 ! .Ip "\fB\-mno-long-calls\fR" 4 .IX Item "-mno-long-calls" .PD Do all calls with the \fB\s-1JALR\s0\fR instruction, which requires loading up a function's address into a register before the call. You need to use this switch, if you call outside of the current 512 megabyte segment to functions that are not through pointers. ! .Ip "\fB\-mhalf-pic\fR" 4 .IX Item "-mhalf-pic" .PD 0 ! .Ip "\fB\-mno-half-pic\fR" 4 .IX Item "-mno-half-pic" .PD Put pointers to extern references into the data section and load them up, rather than put the references in the text section. ! .Ip "\fB\-membedded-pic\fR" 4 .IX Item "-membedded-pic" .PD 0 ! .Ip "\fB\-mno-embedded-pic\fR" 4 .IX Item "-mno-embedded-pic" .PD Generate \s-1PIC\s0 code suitable for some embedded systems. All calls are --- 5880,5920 ---- this can't be done directly in cross-compilation. You must make your own arrangements to provide suitable library functions for cross-compilation. ! .IP "\fB\-mhard-float\fR" 4 .IX Item "-mhard-float" Generate output containing floating point instructions. This is the default if you use the unmodified sources. ! .IP "\fB\-mabicalls\fR" 4 .IX Item "-mabicalls" .PD 0 ! .IP "\fB\-mno-abicalls\fR" 4 .IX Item "-mno-abicalls" .PD Emit (or do not emit) the pseudo operations \fB.abicalls\fR, \&\fB.cpload\fR, and \fB.cprestore\fR that some System V.4 ports use for position independent code. ! .IP "\fB\-mlong-calls\fR" 4 .IX Item "-mlong-calls" .PD 0 ! .IP "\fB\-mno-long-calls\fR" 4 .IX Item "-mno-long-calls" .PD Do all calls with the \fB\s-1JALR\s0\fR instruction, which requires loading up a function's address into a register before the call. You need to use this switch, if you call outside of the current 512 megabyte segment to functions that are not through pointers. ! .IP "\fB\-mhalf-pic\fR" 4 .IX Item "-mhalf-pic" .PD 0 ! .IP "\fB\-mno-half-pic\fR" 4 .IX Item "-mno-half-pic" .PD Put pointers to extern references into the data section and load them up, rather than put the references in the text section. ! .IP "\fB\-membedded-pic\fR" 4 .IX Item "-membedded-pic" .PD 0 ! .IP "\fB\-mno-embedded-pic\fR" 4 .IX Item "-mno-embedded-pic" .PD Generate \s-1PIC\s0 code suitable for some embedded systems. All calls are *************** made using \s-1PC\s0 relative address, a *** 5920,5985 **** register. No more than 65536 bytes of global data may be used. This requires \s-1GNU\s0 as and \s-1GNU\s0 ld which do most of the work. This currently only works on targets which use \s-1ECOFF\s0; it does not work with \s-1ELF\s0. ! .Ip "\fB\-membedded-data\fR" 4 .IX Item "-membedded-data" .PD 0 ! .Ip "\fB\-mno-embedded-data\fR" 4 .IX Item "-mno-embedded-data" .PD Allocate variables to the read-only data section first if possible, then next in the small data section if possible, otherwise in data. This gives slightly slower code than the default, but reduces the amount of \s-1RAM\s0 required when executing, and thus may be preferred for some embedded systems. ! .Ip "\fB\-muninit-const-in-rodata\fR" 4 .IX Item "-muninit-const-in-rodata" .PD 0 ! .Ip "\fB\-mno-uninit-const-in-rodata\fR" 4 .IX Item "-mno-uninit-const-in-rodata" .PD When used together with \fB\-membedded-data\fR, it will always store uninitialized const variables in the read-only data section. ! .Ip "\fB\-msingle-float\fR" 4 .IX Item "-msingle-float" .PD 0 ! .Ip "\fB\-mdouble-float\fR" 4 .IX Item "-mdouble-float" .PD The \fB\-msingle-float\fR switch tells gcc to assume that the floating point coprocessor only supports single precision operations, as on the \&\fBr4650\fR chip. The \fB\-mdouble-float\fR switch permits gcc to use double precision operations. This is the default. ! .Ip "\fB\-mmad\fR" 4 .IX Item "-mmad" .PD 0 ! .Ip "\fB\-mno-mad\fR" 4 .IX Item "-mno-mad" .PD Permit use of the \fBmad\fR, \fBmadu\fR and \fBmul\fR instructions, as on the \fBr4650\fR chip. ! .Ip "\fB\-m4650\fR" 4 .IX Item "-m4650" Turns on \fB\-msingle-float\fR, \fB\-mmad\fR, and, at least for now, \&\fB\-mcpu=r4650\fR. ! .Ip "\fB\-mips16\fR" 4 .IX Item "-mips16" .PD 0 ! .Ip "\fB\-mno-mips16\fR" 4 .IX Item "-mno-mips16" .PD Enable 16\-bit instructions. ! .Ip "\fB\-mentry\fR" 4 .IX Item "-mentry" Use the entry and exit pseudo ops. This option can only be used with \&\fB\-mips16\fR. ! .Ip "\fB\-EL\fR" 4 .IX Item "-EL" Compile code for the processor in little endian mode. The requisite libraries are assumed to exist. ! .Ip "\fB\-EB\fR" 4 .IX Item "-EB" Compile code for the processor in big endian mode. The requisite libraries are assumed to exist. ! .Ip "\fB\-G\fR \fInum\fR" 4 .IX Item "-G num" Put global and static items less than or equal to \fInum\fR bytes into the small data or bss sections instead of the normal data or bss --- 5922,5987 ---- register. No more than 65536 bytes of global data may be used. This requires \s-1GNU\s0 as and \s-1GNU\s0 ld which do most of the work. This currently only works on targets which use \s-1ECOFF\s0; it does not work with \s-1ELF\s0. ! .IP "\fB\-membedded-data\fR" 4 .IX Item "-membedded-data" .PD 0 ! .IP "\fB\-mno-embedded-data\fR" 4 .IX Item "-mno-embedded-data" .PD Allocate variables to the read-only data section first if possible, then next in the small data section if possible, otherwise in data. This gives slightly slower code than the default, but reduces the amount of \s-1RAM\s0 required when executing, and thus may be preferred for some embedded systems. ! .IP "\fB\-muninit-const-in-rodata\fR" 4 .IX Item "-muninit-const-in-rodata" .PD 0 ! .IP "\fB\-mno-uninit-const-in-rodata\fR" 4 .IX Item "-mno-uninit-const-in-rodata" .PD When used together with \fB\-membedded-data\fR, it will always store uninitialized const variables in the read-only data section. ! .IP "\fB\-msingle-float\fR" 4 .IX Item "-msingle-float" .PD 0 ! .IP "\fB\-mdouble-float\fR" 4 .IX Item "-mdouble-float" .PD The \fB\-msingle-float\fR switch tells gcc to assume that the floating point coprocessor only supports single precision operations, as on the \&\fBr4650\fR chip. The \fB\-mdouble-float\fR switch permits gcc to use double precision operations. This is the default. ! .IP "\fB\-mmad\fR" 4 .IX Item "-mmad" .PD 0 ! .IP "\fB\-mno-mad\fR" 4 .IX Item "-mno-mad" .PD Permit use of the \fBmad\fR, \fBmadu\fR and \fBmul\fR instructions, as on the \fBr4650\fR chip. ! .IP "\fB\-m4650\fR" 4 .IX Item "-m4650" Turns on \fB\-msingle-float\fR, \fB\-mmad\fR, and, at least for now, \&\fB\-mcpu=r4650\fR. ! .IP "\fB\-mips16\fR" 4 .IX Item "-mips16" .PD 0 ! .IP "\fB\-mno-mips16\fR" 4 .IX Item "-mno-mips16" .PD Enable 16\-bit instructions. ! .IP "\fB\-mentry\fR" 4 .IX Item "-mentry" Use the entry and exit pseudo ops. This option can only be used with \&\fB\-mips16\fR. ! .IP "\fB\-EL\fR" 4 .IX Item "-EL" Compile code for the processor in little endian mode. The requisite libraries are assumed to exist. ! .IP "\fB\-EB\fR" 4 .IX Item "-EB" Compile code for the processor in big endian mode. The requisite libraries are assumed to exist. ! .IP "\fB\-G\fR \fInum\fR" 4 .IX Item "-G num" Put global and static items less than or equal to \fInum\fR bytes into the small data or bss sections instead of the normal data or bss *************** the \s-1MIPS\s0 assembler is used, and 0 *** 5990,6005 **** \&\fB\-G\fR \fInum\fR switch is also passed to the assembler and linker. All modules should be compiled with the same \fB\-G\fR \fInum\fR value. ! .Ip "\fB\-nocpp\fR" 4 .IX Item "-nocpp" Tell the \s-1MIPS\s0 assembler to not run its preprocessor over user assembler files (with a \fB.s\fR suffix) when assembling them. ! .Ip "\fB\-mfix7000\fR" 4 .IX Item "-mfix7000" Pass an option to gas which will cause nops to be inserted if the read of the destination register of an mfhi or mflo instruction occurs in the following two instructions. ! .Ip "\fB\-no-crt0\fR" 4 .IX Item "-no-crt0" Do not include the default crt0. .PP --- 5992,6007 ---- \&\fB\-G\fR \fInum\fR switch is also passed to the assembler and linker. All modules should be compiled with the same \fB\-G\fR \fInum\fR value. ! .IP "\fB\-nocpp\fR" 4 .IX Item "-nocpp" Tell the \s-1MIPS\s0 assembler to not run its preprocessor over user assembler files (with a \fB.s\fR suffix) when assembling them. ! .IP "\fB\-mfix7000\fR" 4 .IX Item "-mfix7000" Pass an option to gas which will cause nops to be inserted if the read of the destination register of an mfhi or mflo instruction occurs in the following two instructions. ! .IP "\fB\-no-crt0\fR" 4 .IX Item "-no-crt0" Do not include the default crt0. .PP *************** Do not include the default crt0. *** 6007,6013 **** .IX Subsection "Intel 386 Options" .PP These \fB\-m\fR options are defined for the i386 family of computers: ! .Ip "\fB\-mcpu=\fR\fIcpu-type\fR" 4 .IX Item "-mcpu=cpu-type" Assume the defaults for the machine type \fIcpu-type\fR when scheduling instructions. The choices for \fIcpu-type\fR are \fBi386\fR, --- 6009,6015 ---- .IX Subsection "Intel 386 Options" .PP These \fB\-m\fR options are defined for the i386 family of computers: ! .IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4 .IX Item "-mcpu=cpu-type" Assume the defaults for the machine type \fIcpu-type\fR when scheduling instructions. The choices for \fIcpu-type\fR are \fBi386\fR, *************** does not run on the i386 without the \fB *** 6020,6055 **** being used. \fBi586\fR is equivalent to \fBpentium\fR and \fBi686\fR is equivalent to \fBpentiumpro\fR. \fBk6\fR is the \s-1AMD\s0 chip as opposed to the Intel ones. ! .Ip "\fB\-march=\fR\fIcpu-type\fR" 4 .IX Item "-march=cpu-type" Generate instructions for the machine type \fIcpu-type\fR. The choices for \fIcpu-type\fR are the same as for \fB\-mcpu\fR. Moreover, specifying \fB\-march=\fR\fIcpu-type\fR implies \fB\-mcpu=\fR\fIcpu-type\fR. ! .Ip "\fB\-m386\fR" 4 .IX Item "-m386" .PD 0 ! .Ip "\fB\-m486\fR" 4 .IX Item "-m486" ! .Ip "\fB\-mpentium\fR" 4 .IX Item "-mpentium" ! .Ip "\fB\-mpentiumpro\fR" 4 .IX Item "-mpentiumpro" .PD Synonyms for \fB\-mcpu=i386\fR, \fB\-mcpu=i486\fR, \fB\-mcpu=pentium\fR, and \fB\-mcpu=pentiumpro\fR respectively. These synonyms are deprecated. ! .Ip "\fB\-mintel-syntax\fR" 4 .IX Item "-mintel-syntax" Emit assembly using Intel syntax opcodes instead of \s-1AT&T\s0 syntax. ! .Ip "\fB\-mieee-fp\fR" 4 .IX Item "-mieee-fp" .PD 0 ! .Ip "\fB\-mno-ieee-fp\fR" 4 .IX Item "-mno-ieee-fp" .PD Control whether or not the compiler uses \s-1IEEE\s0 floating point comparisons. These handle correctly the case where the result of a comparison is unordered. ! .Ip "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries are not part of \s-1GCC\s0. --- 6022,6057 ---- being used. \fBi586\fR is equivalent to \fBpentium\fR and \fBi686\fR is equivalent to \fBpentiumpro\fR. \fBk6\fR is the \s-1AMD\s0 chip as opposed to the Intel ones. ! .IP "\fB\-march=\fR\fIcpu-type\fR" 4 .IX Item "-march=cpu-type" Generate instructions for the machine type \fIcpu-type\fR. The choices for \fIcpu-type\fR are the same as for \fB\-mcpu\fR. Moreover, specifying \fB\-march=\fR\fIcpu-type\fR implies \fB\-mcpu=\fR\fIcpu-type\fR. ! .IP "\fB\-m386\fR" 4 .IX Item "-m386" .PD 0 ! .IP "\fB\-m486\fR" 4 .IX Item "-m486" ! .IP "\fB\-mpentium\fR" 4 .IX Item "-mpentium" ! .IP "\fB\-mpentiumpro\fR" 4 .IX Item "-mpentiumpro" .PD Synonyms for \fB\-mcpu=i386\fR, \fB\-mcpu=i486\fR, \fB\-mcpu=pentium\fR, and \fB\-mcpu=pentiumpro\fR respectively. These synonyms are deprecated. ! .IP "\fB\-mintel-syntax\fR" 4 .IX Item "-mintel-syntax" Emit assembly using Intel syntax opcodes instead of \s-1AT&T\s0 syntax. ! .IP "\fB\-mieee-fp\fR" 4 .IX Item "-mieee-fp" .PD 0 ! .IP "\fB\-mno-ieee-fp\fR" 4 .IX Item "-mno-ieee-fp" .PD Control whether or not the compiler uses \s-1IEEE\s0 floating point comparisons. These handle correctly the case where the result of a comparison is unordered. ! .IP "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries are not part of \s-1GCC\s0. *************** cross-compilation. *** 6061,6067 **** On machines where a function returns floating point results in the 80387 register stack, some floating point opcodes may be emitted even if \&\fB\-msoft-float\fR is used. ! .Ip "\fB\-mno-fp-ret-in-387\fR" 4 .IX Item "-mno-fp-ret-in-387" Do not use the \s-1FPU\s0 registers for return values of functions. .Sp --- 6063,6069 ---- On machines where a function returns floating point results in the 80387 register stack, some floating point opcodes may be emitted even if \&\fB\-msoft-float\fR is used. ! .IP "\fB\-mno-fp-ret-in-387\fR" 4 .IX Item "-mno-fp-ret-in-387" Do not use the \s-1FPU\s0 registers for return values of functions. .Sp *************** an \s-1FPU\s0. *** 6072,6088 **** .Sp The option \fB\-mno-fp-ret-in-387\fR causes such values to be returned in ordinary \s-1CPU\s0 registers instead. ! .Ip "\fB\-mno-fancy-math-387\fR" 4 .IX Item "-mno-fancy-math-387" Some 387 emulators do not support the \f(CW\*(C`sin\*(C'\fR, \f(CW\*(C`cos\*(C'\fR and \&\f(CW\*(C`sqrt\*(C'\fR instructions for the 387. Specify this option to avoid generating those instructions. This option is the default on FreeBSD. As of revision 2.6.1, these instructions are not generated unless you also use the \fB\-ffast-math\fR switch. ! .Ip "\fB\-malign-double\fR" 4 .IX Item "-malign-double" .PD 0 ! .Ip "\fB\-mno-align-double\fR" 4 .IX Item "-mno-align-double" .PD Control whether \s-1GCC\s0 aligns \f(CW\*(C`double\*(C'\fR, \f(CW\*(C`long double\*(C'\fR, and --- 6074,6090 ---- .Sp The option \fB\-mno-fp-ret-in-387\fR causes such values to be returned in ordinary \s-1CPU\s0 registers instead. ! .IP "\fB\-mno-fancy-math-387\fR" 4 .IX Item "-mno-fancy-math-387" Some 387 emulators do not support the \f(CW\*(C`sin\*(C'\fR, \f(CW\*(C`cos\*(C'\fR and \&\f(CW\*(C`sqrt\*(C'\fR instructions for the 387. Specify this option to avoid generating those instructions. This option is the default on FreeBSD. As of revision 2.6.1, these instructions are not generated unless you also use the \fB\-ffast-math\fR switch. ! .IP "\fB\-malign-double\fR" 4 .IX Item "-malign-double" .PD 0 ! .IP "\fB\-mno-align-double\fR" 4 .IX Item "-mno-align-double" .PD Control whether \s-1GCC\s0 aligns \f(CW\*(C`double\*(C'\fR, \f(CW\*(C`long double\*(C'\fR, and *************** Control whether \s-1GCC\s0 aligns \f(CW\ *** 6090,6101 **** boundary. Aligning \f(CW\*(C`double\*(C'\fR variables on a two word boundary will produce code that runs somewhat faster on a \fBPentium\fR at the expense of more memory. ! .Ip "\fB\-m128bit-long-double\fR" 4 ! .IX Item "-m128bit-long-double" ! .PD 0 ! .Ip "\fB\-m128bit-long-double\fR" 4 .IX Item "-m128bit-long-double" - .PD Control the size of \f(CW\*(C`long double\*(C'\fR type. i386 application binary interface specify the size to be 12 bytes, while modern architectures (Pentium and newer) prefer \f(CW\*(C`long double\*(C'\fR aligned to 8 or 16 byte boundary. This is --- 6092,6099 ---- boundary. Aligning \f(CW\*(C`double\*(C'\fR variables on a two word boundary will produce code that runs somewhat faster on a \fBPentium\fR at the expense of more memory. ! .IP "\fB\-m128bit-long-double\fR" 4 .IX Item "-m128bit-long-double" Control the size of \f(CW\*(C`long double\*(C'\fR type. i386 application binary interface specify the size to be 12 bytes, while modern architectures (Pentium and newer) prefer \f(CW\*(C`long double\*(C'\fR aligned to 8 or 16 byte boundary. This is *************** impossible to reach with 12 byte long do *** 6105,6137 **** structures and arrays containing \f(CW\*(C`long double\*(C'\fR will change their size as well as function calling convention for function taking \f(CW\*(C`long double\*(C'\fR will be modified. ! .Ip "\fB\-m96bit-long-double\fR" 4 ! .IX Item "-m96bit-long-double" ! .PD 0 ! .Ip "\fB\-m96bit-long-double\fR" 4 .IX Item "-m96bit-long-double" - .PD Set the size of \f(CW\*(C`long double\*(C'\fR to 96 bits as required by the i386 application binary interface. This is the default. ! .Ip "\fB\-msvr3\-shlib\fR" 4 .IX Item "-msvr3-shlib" .PD 0 ! .Ip "\fB\-mno-svr3\-shlib\fR" 4 .IX Item "-mno-svr3-shlib" .PD Control whether \s-1GCC\s0 places uninitialized locals into \f(CW\*(C`bss\*(C'\fR or \&\f(CW\*(C`data\*(C'\fR. \fB\-msvr3\-shlib\fR places these locals into \f(CW\*(C`bss\*(C'\fR. These options are meaningful only on System V Release 3. ! .Ip "\fB\-mno-wide-multiply\fR" 4 ! .IX Item "-mno-wide-multiply" ! .PD 0 ! .Ip "\fB\-mwide-multiply\fR" 4 ! .IX Item "-mwide-multiply" ! .PD ! Control whether \s-1GCC\s0 uses the \f(CW\*(C`mul\*(C'\fR and \f(CW\*(C`imul\*(C'\fR that produce ! 64\-bit results in \f(CW\*(C`eax:edx\*(C'\fR from 32\-bit operands to do \f(CW\*(C`long ! long\*(C'\fR multiplies and 32\-bit division by constants. ! .Ip "\fB\-mrtd\fR" 4 .IX Item "-mrtd" Use a different function-calling convention, in which functions that take a fixed number of arguments return with the \f(CW\*(C`ret\*(C'\fR \fInum\fR --- 6103,6122 ---- structures and arrays containing \f(CW\*(C`long double\*(C'\fR will change their size as well as function calling convention for function taking \f(CW\*(C`long double\*(C'\fR will be modified. ! .IP "\fB\-m96bit-long-double\fR" 4 .IX Item "-m96bit-long-double" Set the size of \f(CW\*(C`long double\*(C'\fR to 96 bits as required by the i386 application binary interface. This is the default. ! .IP "\fB\-msvr3\-shlib\fR" 4 .IX Item "-msvr3-shlib" .PD 0 ! .IP "\fB\-mno-svr3\-shlib\fR" 4 .IX Item "-mno-svr3-shlib" .PD Control whether \s-1GCC\s0 places uninitialized locals into \f(CW\*(C`bss\*(C'\fR or \&\f(CW\*(C`data\*(C'\fR. \fB\-msvr3\-shlib\fR places these locals into \f(CW\*(C`bss\*(C'\fR. These options are meaningful only on System V Release 3. ! .IP "\fB\-mrtd\fR" 4 .IX Item "-mrtd" Use a different function-calling convention, in which functions that take a fixed number of arguments return with the \f(CW\*(C`ret\*(C'\fR \fInum\fR *************** functions. *** 6156,6162 **** In addition, seriously incorrect code will result if you call a function with too many arguments. (Normally, extra arguments are harmlessly ignored.) ! .Ip "\fB\-mreg-alloc=\fR\fIregs\fR" 4 .IX Item "-mreg-alloc=regs" Control the default allocation order of integer registers. The string \fIregs\fR is a series of letters specifying a register. The --- 6141,6147 ---- In addition, seriously incorrect code will result if you call a function with too many arguments. (Normally, extra arguments are harmlessly ignored.) ! .IP "\fB\-mreg-alloc=\fR\fIregs\fR" 4 .IX Item "-mreg-alloc=regs" Control the default allocation order of integer registers. The string \fIregs\fR is a series of letters specifying a register. The *************** supported letters are: \f(CW\*(C`a\*(C'\ *** 6165,6171 **** \&\f(CW\*(C`D\*(C'\fR allocate \s-1EDI\s0; \f(CW\*(C`B\*(C'\fR allocate \s-1EBP\s0. This option is deprecated and will not be supported by future releases of gcc. ! .Ip "\fB\-mregparm=\fR\fInum\fR" 4 .IX Item "-mregparm=num" Control how many registers are used to pass integer arguments. By default, no registers are used to pass arguments, and at most 3 --- 6150,6156 ---- \&\f(CW\*(C`D\*(C'\fR allocate \s-1EDI\s0; \f(CW\*(C`B\*(C'\fR allocate \s-1EBP\s0. This option is deprecated and will not be supported by future releases of gcc. ! .IP "\fB\-mregparm=\fR\fInum\fR" 4 .IX Item "-mregparm=num" Control how many registers are used to pass integer arguments. By default, no registers are used to pass arguments, and at most 3 *************** function by using the function attribute *** 6176,6189 **** \&\fInum\fR is nonzero, then you must build all modules with the same value, including any libraries. This includes the system libraries and startup modules. ! .Ip "\fB\-malign-loops=\fR\fInum\fR" 4 .IX Item "-malign-loops=num" Align loops to a 2 raised to a \fInum\fR byte boundary. If \&\fB\-malign-loops\fR is not specified, the default is 2 unless gas 2.8 (or later) is being used in which case the default is to align the loop on a 16 byte boundary if it is less than 8 bytes away. ! .Ip "\fB\-malign-jumps=\fR\fInum\fR" 4 .IX Item "-malign-jumps=num" Align instructions that are only jumped to to a 2 raised to a \fInum\fR byte boundary. If \fB\-malign-jumps\fR is not specified, the default is --- 6161,6174 ---- \&\fInum\fR is nonzero, then you must build all modules with the same value, including any libraries. This includes the system libraries and startup modules. ! .IP "\fB\-malign-loops=\fR\fInum\fR" 4 .IX Item "-malign-loops=num" Align loops to a 2 raised to a \fInum\fR byte boundary. If \&\fB\-malign-loops\fR is not specified, the default is 2 unless gas 2.8 (or later) is being used in which case the default is to align the loop on a 16 byte boundary if it is less than 8 bytes away. ! .IP "\fB\-malign-jumps=\fR\fInum\fR" 4 .IX Item "-malign-jumps=num" Align instructions that are only jumped to to a 2 raised to a \fInum\fR byte boundary. If \fB\-malign-jumps\fR is not specified, the default is *************** byte boundary. If \fB\-malign-jumps\fR *** 6191,6202 **** gas 2.8 (or later) is being used in which case the default is to align the instruction on a 16 byte boundary if it is less than 8 bytes away. ! .Ip "\fB\-malign-functions=\fR\fInum\fR" 4 .IX Item "-malign-functions=num" Align the start of functions to a 2 raised to \fInum\fR byte boundary. If \fB\-malign-functions\fR is not specified, the default is 2 if optimizing for a 386, and 4 if optimizing for a 486. ! .Ip "\fB\-mpreferred-stack-boundary=\fR\fInum\fR" 4 .IX Item "-mpreferred-stack-boundary=num" Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR byte boundary. If \fB\-mpreferred-stack-boundary\fR is not specified, --- 6176,6187 ---- gas 2.8 (or later) is being used in which case the default is to align the instruction on a 16 byte boundary if it is less than 8 bytes away. ! .IP "\fB\-malign-functions=\fR\fInum\fR" 4 .IX Item "-malign-functions=num" Align the start of functions to a 2 raised to \fInum\fR byte boundary. If \fB\-malign-functions\fR is not specified, the default is 2 if optimizing for a 386, and 4 if optimizing for a 486. ! .IP "\fB\-mpreferred-stack-boundary=\fR\fInum\fR" 4 .IX Item "-mpreferred-stack-boundary=num" Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR byte boundary. If \fB\-mpreferred-stack-boundary\fR is not specified, *************** This extra alignment does consume extra *** 6221,6258 **** to stack space usage, such as embedded systems and operating system kernels, may want to reduce the preferred alignment to \&\fB\-mpreferred-stack-boundary=2\fR. ! .Ip "\fB\-mpush-args\fR" 4 .IX Item "-mpush-args" Use \s-1PUSH\s0 operations to store outgoing parameters. This method is shorter and usually equally fast as method using \s-1SUB/MOV\s0 operations and is enabled by default. In some cases disabling it may improve performance because of improved scheduling and reduced dependencies. ! .Ip "\fB\-maccumulate-outgoing-args\fR" 4 .IX Item "-maccumulate-outgoing-args" If enabled, the maximum amount of space required for outgoing arguments will be ! computed in the function prologue. This in faster on most modern CPUs because of reduced dependencies, improved scheduling and reduced stack usage when preferred stack boundary is not equal to 2. The drawback is a notable increase in code size. This switch implies \fB\-mno-push-args\fR. ! .Ip "\fB\-mthreads\fR" 4 .IX Item "-mthreads" Support thread-safe exception handling on \fBMingw32\fR. Code that relies on thread-safe exception handling must compile and link all code with the \&\fB\-mthreads\fR option. When compiling, \fB\-mthreads\fR defines \&\fB\-D_MT\fR; when linking, it links in a special thread helper library \&\fB\-lmingwthrd\fR which cleans up per thread exception handling data. ! .Ip "\fB\-mno-align-stringops\fR" 4 .IX Item "-mno-align-stringops" Do not align destination of inlined string operations. This switch reduces code size and improves performance in case the destination is already aligned, but gcc don't know about it. ! .Ip "\fB\-minline-all-stringops\fR" 4 .IX Item "-minline-all-stringops" By default \s-1GCC\s0 inlines string operations only when destination is known to be aligned at least to 4 byte boundary. This enables more inlining, increase code size, but may improve performance of code that depends on fast memcpy, strlen and memset for short lengths. ! .Ip "\fB\-momit-leaf-frame-pointer\fR" 4 .IX Item "-momit-leaf-frame-pointer" Don't keep the frame pointer in a register for leaf functions. This avoids the instructions to save, set up and restore frame pointers and --- 6206,6247 ---- to stack space usage, such as embedded systems and operating system kernels, may want to reduce the preferred alignment to \&\fB\-mpreferred-stack-boundary=2\fR. ! .IP "\fB\-mpush-args\fR" 4 .IX Item "-mpush-args" + .PD 0 + .IP "\fB\-mno-push-args\fR" 4 + .IX Item "-mno-push-args" + .PD Use \s-1PUSH\s0 operations to store outgoing parameters. This method is shorter and usually equally fast as method using \s-1SUB/MOV\s0 operations and is enabled by default. In some cases disabling it may improve performance because of improved scheduling and reduced dependencies. ! .IP "\fB\-maccumulate-outgoing-args\fR" 4 .IX Item "-maccumulate-outgoing-args" If enabled, the maximum amount of space required for outgoing arguments will be ! computed in the function prologue. This is faster on most modern CPUs because of reduced dependencies, improved scheduling and reduced stack usage when preferred stack boundary is not equal to 2. The drawback is a notable increase in code size. This switch implies \fB\-mno-push-args\fR. ! .IP "\fB\-mthreads\fR" 4 .IX Item "-mthreads" Support thread-safe exception handling on \fBMingw32\fR. Code that relies on thread-safe exception handling must compile and link all code with the \&\fB\-mthreads\fR option. When compiling, \fB\-mthreads\fR defines \&\fB\-D_MT\fR; when linking, it links in a special thread helper library \&\fB\-lmingwthrd\fR which cleans up per thread exception handling data. ! .IP "\fB\-mno-align-stringops\fR" 4 .IX Item "-mno-align-stringops" Do not align destination of inlined string operations. This switch reduces code size and improves performance in case the destination is already aligned, but gcc don't know about it. ! .IP "\fB\-minline-all-stringops\fR" 4 .IX Item "-minline-all-stringops" By default \s-1GCC\s0 inlines string operations only when destination is known to be aligned at least to 4 byte boundary. This enables more inlining, increase code size, but may improve performance of code that depends on fast memcpy, strlen and memset for short lengths. ! .IP "\fB\-momit-leaf-frame-pointer\fR" 4 .IX Item "-momit-leaf-frame-pointer" Don't keep the frame pointer in a register for leaf functions. This avoids the instructions to save, set up and restore frame pointers and *************** which might make debugging harder. *** 6264,6270 **** .IX Subsection "HPPA Options" .PP These \fB\-m\fR options are defined for the \s-1HPPA\s0 family of computers: ! .Ip "\fB\-march=\fR\fIarchitecture-type\fR" 4 .IX Item "-march=architecture-type" Generate code for the specified architecture. The choices for \&\fIarchitecture-type\fR are \fB1.0\fR for \s-1PA\s0 1.0, \fB1.1\fR for \s-1PA\s0 --- 6253,6259 ---- .IX Subsection "HPPA Options" .PP These \fB\-m\fR options are defined for the \s-1HPPA\s0 family of computers: ! .IP "\fB\-march=\fR\fIarchitecture-type\fR" 4 .IX Item "-march=architecture-type" Generate code for the specified architecture. The choices for \&\fIarchitecture-type\fR are \fB1.0\fR for \s-1PA\s0 1.0, \fB1.1\fR for \s-1PA\s0 *************** other way around. *** 6277,6348 **** \&\s-1PA\s0 2.0 support currently requires gas snapshot 19990413 or later. The next release of binutils (current is 2.9.1) will probably contain \s-1PA\s0 2.0 support. ! .Ip "\fB\-mpa-risc-1\-0\fR" 4 .IX Item "-mpa-risc-1-0" .PD 0 ! .Ip "\fB\-mpa-risc-1\-1\fR" 4 .IX Item "-mpa-risc-1-1" ! .Ip "\fB\-mpa-risc-2\-0\fR" 4 .IX Item "-mpa-risc-2-0" .PD Synonyms for \fB\-march=1.0\fR, \fB\-march=1.1\fR, and \fB\-march=2.0\fR respectively. ! .Ip "\fB\-mbig-switch\fR" 4 .IX Item "-mbig-switch" Generate code suitable for big switch tables. Use this option only if the assembler/linker complain about out of range branches within a switch table. ! .Ip "\fB\-mjump-in-delay\fR" 4 .IX Item "-mjump-in-delay" Fill delay slots of function calls with unconditional jump instructions by modifying the return pointer for the function call to be the target of the conditional jump. ! .Ip "\fB\-mdisable-fpregs\fR" 4 .IX Item "-mdisable-fpregs" Prevent floating point registers from being used in any manner. This is necessary for compiling kernels which perform lazy context switching of floating point registers. If you use this option and attempt to perform floating point operations, the compiler will abort. ! .Ip "\fB\-mdisable-indexing\fR" 4 .IX Item "-mdisable-indexing" Prevent the compiler from using indexing address modes. This avoids some rather obscure problems when compiling \s-1MIG\s0 generated code under \s-1MACH\s0. ! .Ip "\fB\-mno-space-regs\fR" 4 .IX Item "-mno-space-regs" Generate code that assumes the target has no space registers. This allows \&\s-1GCC\s0 to generate faster indirect calls and use unscaled index address modes. .Sp Such code is suitable for level 0 \s-1PA\s0 systems and kernels. ! .Ip "\fB\-mfast-indirect-calls\fR" 4 .IX Item "-mfast-indirect-calls" Generate code that assumes calls never cross space boundaries. This allows \s-1GCC\s0 to emit code which performs faster indirect calls. .Sp This option will not work in the presence of shared libraries or nested functions. ! .Ip "\fB\-mlong-load-store\fR" 4 .IX Item "-mlong-load-store" Generate 3\-instruction load and store sequences as sometimes required by the \s-1HP-UX\s0 10 linker. This is equivalent to the \fB+k\fR option to the \s-1HP\s0 compilers. ! .Ip "\fB\-mportable-runtime\fR" 4 .IX Item "-mportable-runtime" Use the portable calling conventions proposed by \s-1HP\s0 for \s-1ELF\s0 systems. ! .Ip "\fB\-mgas\fR" 4 .IX Item "-mgas" Enable the use of assembler directives only \s-1GAS\s0 understands. ! .Ip "\fB\-mschedule=\fR\fIcpu-type\fR" 4 .IX Item "-mschedule=cpu-type" Schedule code according to the constraints for the machine type \&\fIcpu-type\fR. The choices for \fIcpu-type\fR are \fB700\fR \&\fB7100\fR, \fB7100LC\fR, \fB7200\fR, and \fB8000\fR. Refer to \&\fI/usr/lib/sched.models\fR on an \s-1HP-UX\s0 system to determine the proper scheduling option for your machine. ! .Ip "\fB\-mlinker-opt\fR" 4 .IX Item "-mlinker-opt" Enable the optimization pass in the \s-1HPUX\s0 linker. Note this makes symbolic debugging impossible. It also triggers a bug in the \s-1HPUX\s0 8 and \s-1HPUX\s0 9 linkers in which they give bogus error messages when linking some programs. ! .Ip "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries are not available for all \s-1HPPA\s0 --- 6266,6337 ---- \&\s-1PA\s0 2.0 support currently requires gas snapshot 19990413 or later. The next release of binutils (current is 2.9.1) will probably contain \s-1PA\s0 2.0 support. ! .IP "\fB\-mpa-risc-1\-0\fR" 4 .IX Item "-mpa-risc-1-0" .PD 0 ! .IP "\fB\-mpa-risc-1\-1\fR" 4 .IX Item "-mpa-risc-1-1" ! .IP "\fB\-mpa-risc-2\-0\fR" 4 .IX Item "-mpa-risc-2-0" .PD Synonyms for \fB\-march=1.0\fR, \fB\-march=1.1\fR, and \fB\-march=2.0\fR respectively. ! .IP "\fB\-mbig-switch\fR" 4 .IX Item "-mbig-switch" Generate code suitable for big switch tables. Use this option only if the assembler/linker complain about out of range branches within a switch table. ! .IP "\fB\-mjump-in-delay\fR" 4 .IX Item "-mjump-in-delay" Fill delay slots of function calls with unconditional jump instructions by modifying the return pointer for the function call to be the target of the conditional jump. ! .IP "\fB\-mdisable-fpregs\fR" 4 .IX Item "-mdisable-fpregs" Prevent floating point registers from being used in any manner. This is necessary for compiling kernels which perform lazy context switching of floating point registers. If you use this option and attempt to perform floating point operations, the compiler will abort. ! .IP "\fB\-mdisable-indexing\fR" 4 .IX Item "-mdisable-indexing" Prevent the compiler from using indexing address modes. This avoids some rather obscure problems when compiling \s-1MIG\s0 generated code under \s-1MACH\s0. ! .IP "\fB\-mno-space-regs\fR" 4 .IX Item "-mno-space-regs" Generate code that assumes the target has no space registers. This allows \&\s-1GCC\s0 to generate faster indirect calls and use unscaled index address modes. .Sp Such code is suitable for level 0 \s-1PA\s0 systems and kernels. ! .IP "\fB\-mfast-indirect-calls\fR" 4 .IX Item "-mfast-indirect-calls" Generate code that assumes calls never cross space boundaries. This allows \s-1GCC\s0 to emit code which performs faster indirect calls. .Sp This option will not work in the presence of shared libraries or nested functions. ! .IP "\fB\-mlong-load-store\fR" 4 .IX Item "-mlong-load-store" Generate 3\-instruction load and store sequences as sometimes required by the \s-1HP-UX\s0 10 linker. This is equivalent to the \fB+k\fR option to the \s-1HP\s0 compilers. ! .IP "\fB\-mportable-runtime\fR" 4 .IX Item "-mportable-runtime" Use the portable calling conventions proposed by \s-1HP\s0 for \s-1ELF\s0 systems. ! .IP "\fB\-mgas\fR" 4 .IX Item "-mgas" Enable the use of assembler directives only \s-1GAS\s0 understands. ! .IP "\fB\-mschedule=\fR\fIcpu-type\fR" 4 .IX Item "-mschedule=cpu-type" Schedule code according to the constraints for the machine type \&\fIcpu-type\fR. The choices for \fIcpu-type\fR are \fB700\fR \&\fB7100\fR, \fB7100LC\fR, \fB7200\fR, and \fB8000\fR. Refer to \&\fI/usr/lib/sched.models\fR on an \s-1HP-UX\s0 system to determine the proper scheduling option for your machine. ! .IP "\fB\-mlinker-opt\fR" 4 .IX Item "-mlinker-opt" Enable the optimization pass in the \s-1HPUX\s0 linker. Note this makes symbolic debugging impossible. It also triggers a bug in the \s-1HPUX\s0 8 and \s-1HPUX\s0 9 linkers in which they give bogus error messages when linking some programs. ! .IP "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries are not available for all \s-1HPPA\s0 *************** this to work. *** 6362,6368 **** .IX Subsection "Intel 960 Options" .PP These \fB\-m\fR options are defined for the Intel 960 implementations: ! .Ip "\fB\-m\fR\fIcpu-type\fR" 4 .IX Item "-mcpu-type" Assume the defaults for the machine type \fIcpu-type\fR for some of the other options, including instruction scheduling, floating point --- 6351,6357 ---- .IX Subsection "Intel 960 Options" .PP These \fB\-m\fR options are defined for the Intel 960 implementations: ! .IP "\fB\-m\fR\fIcpu-type\fR" 4 .IX Item "-mcpu-type" Assume the defaults for the machine type \fIcpu-type\fR for some of the other options, including instruction scheduling, floating point *************** support, and addressing modes. The choi *** 6371,6389 **** \&\fBsa\fR, and \fBsb\fR. The default is \&\fBkb\fR. ! .Ip "\fB\-mnumerics\fR" 4 .IX Item "-mnumerics" .PD 0 ! .Ip "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" .PD The \fB\-mnumerics\fR option indicates that the processor does support floating-point instructions. The \fB\-msoft-float\fR option indicates that floating-point support should not be assumed. ! .Ip "\fB\-mleaf-procedures\fR" 4 .IX Item "-mleaf-procedures" .PD 0 ! .Ip "\fB\-mno-leaf-procedures\fR" 4 .IX Item "-mno-leaf-procedures" .PD Do (or do not) attempt to alter leaf procedures to be callable with the --- 6360,6378 ---- \&\fBsa\fR, and \fBsb\fR. The default is \&\fBkb\fR. ! .IP "\fB\-mnumerics\fR" 4 .IX Item "-mnumerics" .PD 0 ! .IP "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" .PD The \fB\-mnumerics\fR option indicates that the processor does support floating-point instructions. The \fB\-msoft-float\fR option indicates that floating-point support should not be assumed. ! .IP "\fB\-mleaf-procedures\fR" 4 .IX Item "-mleaf-procedures" .PD 0 ! .IP "\fB\-mno-leaf-procedures\fR" 4 .IX Item "-mno-leaf-procedures" .PD Do (or do not) attempt to alter leaf procedures to be callable with the *************** efficient code for explicit calls when t *** 6392,6401 **** substituted by the assembler or linker, but less efficient code in other cases, such as calls via function pointers, or using a linker that doesn't support this optimization. ! .Ip "\fB\-mtail-call\fR" 4 .IX Item "-mtail-call" .PD 0 ! .Ip "\fB\-mno-tail-call\fR" 4 .IX Item "-mno-tail-call" .PD Do (or do not) make additional attempts (beyond those of the --- 6381,6390 ---- substituted by the assembler or linker, but less efficient code in other cases, such as calls via function pointers, or using a linker that doesn't support this optimization. ! .IP "\fB\-mtail-call\fR" 4 .IX Item "-mtail-call" .PD 0 ! .IP "\fB\-mno-tail-call\fR" 4 .IX Item "-mno-tail-call" .PD Do (or do not) make additional attempts (beyond those of the *************** machine-independent portions of the comp *** 6403,6412 **** calls into branches. You may not want to do this because the detection of cases where this is not valid is not totally complete. The default is \&\fB\-mno-tail-call\fR. ! .Ip "\fB\-mcomplex-addr\fR" 4 .IX Item "-mcomplex-addr" .PD 0 ! .Ip "\fB\-mno-complex-addr\fR" 4 .IX Item "-mno-complex-addr" .PD Assume (or do not assume) that the use of a complex addressing mode is a --- 6392,6401 ---- calls into branches. You may not want to do this because the detection of cases where this is not valid is not totally complete. The default is \&\fB\-mno-tail-call\fR. ! .IP "\fB\-mcomplex-addr\fR" 4 .IX Item "-mcomplex-addr" .PD 0 ! .IP "\fB\-mno-complex-addr\fR" 4 .IX Item "-mno-complex-addr" .PD Assume (or do not assume) that the use of a complex addressing mode is a *************** win on this implementation of the i960. *** 6414,6455 **** be worthwhile on the K-series, but they definitely are on the C-series. The default is currently \fB\-mcomplex-addr\fR for all processors except the \s-1CB\s0 and \s-1CC\s0. ! .Ip "\fB\-mcode-align\fR" 4 .IX Item "-mcode-align" .PD 0 ! .Ip "\fB\-mno-code-align\fR" 4 .IX Item "-mno-code-align" .PD Align code to 8\-byte boundaries for faster fetching (or don't bother). Currently turned on by default for C-series implementations only. ! .Ip "\fB\-mic-compat\fR" 4 .IX Item "-mic-compat" .PD 0 ! .Ip "\fB\-mic2.0\-compat\fR" 4 .IX Item "-mic2.0-compat" ! .Ip "\fB\-mic3.0\-compat\fR" 4 .IX Item "-mic3.0-compat" .PD Enable compatibility with iC960 v2.0 or v3.0. ! .Ip "\fB\-masm-compat\fR" 4 .IX Item "-masm-compat" .PD 0 ! .Ip "\fB\-mintel-asm\fR" 4 .IX Item "-mintel-asm" .PD Enable compatibility with the iC960 assembler. ! .Ip "\fB\-mstrict-align\fR" 4 .IX Item "-mstrict-align" .PD 0 ! .Ip "\fB\-mno-strict-align\fR" 4 .IX Item "-mno-strict-align" .PD Do not permit (do permit) unaligned accesses. ! .Ip "\fB\-mold-align\fR" 4 .IX Item "-mold-align" Enable structure-alignment compatibility with Intel's gcc release version 1.3 (based on gcc 1.37). This option implies \fB\-mstrict-align\fR. ! .Ip "\fB\-mlong-double-64\fR" 4 .IX Item "-mlong-double-64" Implement type \fBlong double\fR as 64\-bit floating point numbers. Without the option \fBlong double\fR is implemented by 80\-bit --- 6403,6444 ---- be worthwhile on the K-series, but they definitely are on the C-series. The default is currently \fB\-mcomplex-addr\fR for all processors except the \s-1CB\s0 and \s-1CC\s0. ! .IP "\fB\-mcode-align\fR" 4 .IX Item "-mcode-align" .PD 0 ! .IP "\fB\-mno-code-align\fR" 4 .IX Item "-mno-code-align" .PD Align code to 8\-byte boundaries for faster fetching (or don't bother). Currently turned on by default for C-series implementations only. ! .IP "\fB\-mic-compat\fR" 4 .IX Item "-mic-compat" .PD 0 ! .IP "\fB\-mic2.0\-compat\fR" 4 .IX Item "-mic2.0-compat" ! .IP "\fB\-mic3.0\-compat\fR" 4 .IX Item "-mic3.0-compat" .PD Enable compatibility with iC960 v2.0 or v3.0. ! .IP "\fB\-masm-compat\fR" 4 .IX Item "-masm-compat" .PD 0 ! .IP "\fB\-mintel-asm\fR" 4 .IX Item "-mintel-asm" .PD Enable compatibility with the iC960 assembler. ! .IP "\fB\-mstrict-align\fR" 4 .IX Item "-mstrict-align" .PD 0 ! .IP "\fB\-mno-strict-align\fR" 4 .IX Item "-mno-strict-align" .PD Do not permit (do permit) unaligned accesses. ! .IP "\fB\-mold-align\fR" 4 .IX Item "-mold-align" Enable structure-alignment compatibility with Intel's gcc release version 1.3 (based on gcc 1.37). This option implies \fB\-mstrict-align\fR. ! .IP "\fB\-mlong-double-64\fR" 4 .IX Item "-mlong-double-64" Implement type \fBlong double\fR as 64\-bit floating point numbers. Without the option \fBlong double\fR is implemented by 80\-bit *************** should recommend against use of it. *** 6462,6471 **** .IX Subsection "DEC Alpha Options" .PP These \fB\-m\fR options are defined for the \s-1DEC\s0 Alpha implementations: ! .Ip "\fB\-mno-soft-float\fR" 4 .IX Item "-mno-soft-float" .PD 0 ! .Ip "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" .PD Use (do not use) the hardware floating-point instructions for --- 6451,6460 ---- .IX Subsection "DEC Alpha Options" .PP These \fB\-m\fR options are defined for the \s-1DEC\s0 Alpha implementations: ! .IP "\fB\-mno-soft-float\fR" 4 .IX Item "-mno-soft-float" .PD 0 ! .IP "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" .PD Use (do not use) the hardware floating-point instructions for *************** them. *** 6480,6489 **** .Sp Note that Alpha implementations without floating-point operations are required to have floating-point registers. ! .Ip "\fB\-mfp-reg\fR" 4 .IX Item "-mfp-reg" .PD 0 ! .Ip "\fB\-mno-fp-regs\fR" 4 .IX Item "-mno-fp-regs" .PD Generate code that uses (does not use) the floating-point register set. --- 6469,6478 ---- .Sp Note that Alpha implementations without floating-point operations are required to have floating-point registers. ! .IP "\fB\-mfp-reg\fR" 4 .IX Item "-mfp-reg" .PD 0 ! .IP "\fB\-mno-fp-regs\fR" 4 .IX Item "-mno-fp-regs" .PD Generate code that uses (does not use) the floating-point register set. *************** option. *** 6497,6503 **** .Sp A typical use of this option is building a kernel that does not use, and hence need not save and restore, any floating-point registers. ! .Ip "\fB\-mieee\fR" 4 .IX Item "-mieee" The Alpha architecture implements floating-point hardware optimized for maximum performance. It is mostly compliant with the \s-1IEEE\s0 floating --- 6486,6492 ---- .Sp A typical use of this option is building a kernel that does not use, and hence need not save and restore, any floating-point registers. ! .IP "\fB\-mieee\fR" 4 .IX Item "-mieee" The Alpha architecture implements floating-point hardware optimized for maximum performance. It is mostly compliant with the \s-1IEEE\s0 floating *************** code is less efficient but is able to co *** 6511,6517 **** numbers and exceptional \s-1IEEE\s0 values such as not-a-number and plus/minus infinity. Other Alpha compilers call this option \&\fB\-ieee_with_no_inexact\fR. ! .Ip "\fB\-mieee-with-inexact\fR" 4 .IX Item "-mieee-with-inexact" This is like \fB\-mieee\fR except the generated code also maintains the \&\s-1IEEE\s0 \fIinexact-flag\fR. Turning on this option causes the generated --- 6500,6506 ---- numbers and exceptional \s-1IEEE\s0 values such as not-a-number and plus/minus infinity. Other Alpha compilers call this option \&\fB\-ieee_with_no_inexact\fR. ! .IP "\fB\-mieee-with-inexact\fR" 4 .IX Item "-mieee-with-inexact" This is like \fB\-mieee\fR except the generated code also maintains the \&\s-1IEEE\s0 \fIinexact-flag\fR. Turning on this option causes the generated *************** significantly slower than the code gener *** 6525,6573 **** is very little code that depends on the \fIinexact-flag\fR, you should normally not specify this option. Other Alpha compilers call this option \fB\-ieee_with_inexact\fR. ! .Ip "\fB\-mfp-trap-mode=\fR\fItrap-mode\fR" 4 .IX Item "-mfp-trap-mode=trap-mode" This option controls what floating-point related traps are enabled. Other Alpha compilers call this option \fB\-fptm\fR \fItrap-mode\fR. The trap mode can be set to one of four values: .RS 4 ! .Ip "\fBn\fR" 4 .IX Item "n" This is the default (normal) setting. The only traps that are enabled are the ones that cannot be disabled in software (e.g., division by zero trap). ! .Ip "\fBu\fR" 4 .IX Item "u" In addition to the traps enabled by \fBn\fR, underflow traps are enabled as well. ! .Ip "\fBsu\fR" 4 .IX Item "su" Like \fBsu\fR, but the instructions are marked to be safe for software completion (see Alpha architecture manual for details). ! .Ip "\fBsui\fR" 4 .IX Item "sui" Like \fBsu\fR, but inexact traps are enabled as well. .RE .RS 4 .RE ! .Ip "\fB\-mfp-rounding-mode=\fR\fIrounding-mode\fR" 4 .IX Item "-mfp-rounding-mode=rounding-mode" Selects the \s-1IEEE\s0 rounding mode. Other Alpha compilers call this option \&\fB\-fprm\fR \fIrounding-mode\fR. The \fIrounding-mode\fR can be one of: .RS 4 ! .Ip "\fBn\fR" 4 .IX Item "n" Normal \s-1IEEE\s0 rounding mode. Floating point numbers are rounded towards the nearest machine number or towards the even machine number in case of a tie. ! .Ip "\fBm\fR" 4 .IX Item "m" Round towards minus infinity. ! .Ip "\fBc\fR" 4 .IX Item "c" Chopped rounding mode. Floating point numbers are rounded towards zero. ! .Ip "\fBd\fR" 4 .IX Item "d" Dynamic rounding mode. A field in the floating point control register (\fIfpcr\fR, see Alpha architecture reference manual) controls the --- 6514,6562 ---- is very little code that depends on the \fIinexact-flag\fR, you should normally not specify this option. Other Alpha compilers call this option \fB\-ieee_with_inexact\fR. ! .IP "\fB\-mfp-trap-mode=\fR\fItrap-mode\fR" 4 .IX Item "-mfp-trap-mode=trap-mode" This option controls what floating-point related traps are enabled. Other Alpha compilers call this option \fB\-fptm\fR \fItrap-mode\fR. The trap mode can be set to one of four values: .RS 4 ! .IP "\fBn\fR" 4 .IX Item "n" This is the default (normal) setting. The only traps that are enabled are the ones that cannot be disabled in software (e.g., division by zero trap). ! .IP "\fBu\fR" 4 .IX Item "u" In addition to the traps enabled by \fBn\fR, underflow traps are enabled as well. ! .IP "\fBsu\fR" 4 .IX Item "su" Like \fBsu\fR, but the instructions are marked to be safe for software completion (see Alpha architecture manual for details). ! .IP "\fBsui\fR" 4 .IX Item "sui" Like \fBsu\fR, but inexact traps are enabled as well. .RE .RS 4 .RE ! .IP "\fB\-mfp-rounding-mode=\fR\fIrounding-mode\fR" 4 .IX Item "-mfp-rounding-mode=rounding-mode" Selects the \s-1IEEE\s0 rounding mode. Other Alpha compilers call this option \&\fB\-fprm\fR \fIrounding-mode\fR. The \fIrounding-mode\fR can be one of: .RS 4 ! .IP "\fBn\fR" 4 .IX Item "n" Normal \s-1IEEE\s0 rounding mode. Floating point numbers are rounded towards the nearest machine number or towards the even machine number in case of a tie. ! .IP "\fBm\fR" 4 .IX Item "m" Round towards minus infinity. ! .IP "\fBc\fR" 4 .IX Item "c" Chopped rounding mode. Floating point numbers are rounded towards zero. ! .IP "\fBd\fR" 4 .IX Item "d" Dynamic rounding mode. A field in the floating point control register (\fIfpcr\fR, see Alpha architecture reference manual) controls the *************** rounding towards plus infinity. Thus, u *** 6577,6583 **** .RE .RS 4 .RE ! .Ip "\fB\-mtrap-precision=\fR\fItrap-precision\fR" 4 .IX Item "-mtrap-precision=trap-precision" In the Alpha architecture, floating point traps are imprecise. This means without software assistance it is impossible to recover from a --- 6566,6572 ---- .RE .RS 4 .RE ! .IP "\fB\-mtrap-precision=\fR\fItrap-precision\fR" 4 .IX Item "-mtrap-precision=trap-precision" In the Alpha architecture, floating point traps are imprecise. This means without software assistance it is impossible to recover from a *************** in determining the exact location that c *** 6587,6601 **** Depending on the requirements of an application, different levels of precisions can be selected: .RS 4 ! .Ip "\fBp\fR" 4 .IX Item "p" Program precision. This option is the default and means a trap handler can only identify which program caused a floating point exception. ! .Ip "\fBf\fR" 4 .IX Item "f" Function precision. The trap handler can determine the function that caused a floating point exception. ! .Ip "\fBi\fR" 4 .IX Item "i" Instruction precision. The trap handler can determine the exact instruction that caused a floating point exception. --- 6576,6590 ---- Depending on the requirements of an application, different levels of precisions can be selected: .RS 4 ! .IP "\fBp\fR" 4 .IX Item "p" Program precision. This option is the default and means a trap handler can only identify which program caused a floating point exception. ! .IP "\fBf\fR" 4 .IX Item "f" Function precision. The trap handler can determine the function that caused a floating point exception. ! .IP "\fBi\fR" 4 .IX Item "i" Instruction precision. The trap handler can determine the exact instruction that caused a floating point exception. *************** instruction that caused a floating point *** 6605,6611 **** Other Alpha compilers provide the equivalent options called \&\fB\-scope_safe\fR and \fB\-resumption_safe\fR. .RE ! .Ip "\fB\-mieee-conformant\fR" 4 .IX Item "-mieee-conformant" This option marks the generated code as \s-1IEEE\s0 conformant. You must not use this option unless you also specify \fB\-mtrap-precision=i\fR and either --- 6594,6600 ---- Other Alpha compilers provide the equivalent options called \&\fB\-scope_safe\fR and \fB\-resumption_safe\fR. .RE ! .IP "\fB\-mieee-conformant\fR" 4 .IX Item "-mieee-conformant" This option marks the generated code as \s-1IEEE\s0 conformant. You must not use this option unless you also specify \fB\-mtrap-precision=i\fR and either *************** use this option unless you also specify *** 6613,6619 **** is to emit the line \fB.eflag 48\fR in the function prologue of the generated assembly file. Under \s-1DEC\s0 Unix, this has the effect that IEEE-conformant math library routines will be linked in. ! .Ip "\fB\-mbuild-constants\fR" 4 .IX Item "-mbuild-constants" Normally \s-1GCC\s0 examines a 32\- or 64\-bit integer constant to see if it can construct it from smaller constants in two or three --- 6602,6608 ---- is to emit the line \fB.eflag 48\fR in the function prologue of the generated assembly file. Under \s-1DEC\s0 Unix, this has the effect that IEEE-conformant math library routines will be linked in. ! .IP "\fB\-mbuild-constants\fR" 4 .IX Item "-mbuild-constants" Normally \s-1GCC\s0 examines a 32\- or 64\-bit integer constant to see if it can construct it from smaller constants in two or three *************** using code, even if it takes more instru *** 6626,6658 **** You would typically use this option to build a shared library dynamic loader. Itself a shared library, it must relocate itself in memory before it can find the variables and constants in its own data segment. ! .Ip "\fB\-malpha-as\fR" 4 .IX Item "-malpha-as" .PD 0 ! .Ip "\fB\-mgas\fR" 4 .IX Item "-mgas" .PD Select whether to generate code to be assembled by the vendor-supplied assembler (\fB\-malpha-as\fR) or by the \s-1GNU\s0 assembler \fB\-mgas\fR. ! .Ip "\fB\-mbwx\fR" 4 .IX Item "-mbwx" .PD 0 ! .Ip "\fB\-mno-bwx\fR" 4 .IX Item "-mno-bwx" ! .Ip "\fB\-mcix\fR" 4 .IX Item "-mcix" ! .Ip "\fB\-mno-cix\fR" 4 .IX Item "-mno-cix" ! .Ip "\fB\-mmax\fR" 4 .IX Item "-mmax" ! .Ip "\fB\-mno-max\fR" 4 .IX Item "-mno-max" .PD Indicate whether \s-1GCC\s0 should generate code to use the optional \s-1BWX\s0, \&\s-1CIX\s0, and \s-1MAX\s0 instruction sets. The default is to use the instruction sets supported by the \s-1CPU\s0 type specified via \fB\-mcpu=\fR option or that of the \s-1CPU\s0 on which \s-1GCC\s0 was built if none was specified. ! .Ip "\fB\-mcpu=\fR\fIcpu_type\fR" 4 .IX Item "-mcpu=cpu_type" Set the instruction set, register set, and instruction scheduling parameters for machine type \fIcpu_type\fR. You can specify either the --- 6615,6647 ---- You would typically use this option to build a shared library dynamic loader. Itself a shared library, it must relocate itself in memory before it can find the variables and constants in its own data segment. ! .IP "\fB\-malpha-as\fR" 4 .IX Item "-malpha-as" .PD 0 ! .IP "\fB\-mgas\fR" 4 .IX Item "-mgas" .PD Select whether to generate code to be assembled by the vendor-supplied assembler (\fB\-malpha-as\fR) or by the \s-1GNU\s0 assembler \fB\-mgas\fR. ! .IP "\fB\-mbwx\fR" 4 .IX Item "-mbwx" .PD 0 ! .IP "\fB\-mno-bwx\fR" 4 .IX Item "-mno-bwx" ! .IP "\fB\-mcix\fR" 4 .IX Item "-mcix" ! .IP "\fB\-mno-cix\fR" 4 .IX Item "-mno-cix" ! .IP "\fB\-mmax\fR" 4 .IX Item "-mmax" ! .IP "\fB\-mno-max\fR" 4 .IX Item "-mno-max" .PD Indicate whether \s-1GCC\s0 should generate code to use the optional \s-1BWX\s0, \&\s-1CIX\s0, and \s-1MAX\s0 instruction sets. The default is to use the instruction sets supported by the \s-1CPU\s0 type specified via \fB\-mcpu=\fR option or that of the \s-1CPU\s0 on which \s-1GCC\s0 was built if none was specified. ! .IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4 .IX Item "-mcpu=cpu_type" Set the instruction set, register set, and instruction scheduling parameters for machine type \fIcpu_type\fR. You can specify either the *************** the processor you specify. If you do no *** 6664,6703 **** .Sp Supported values for \fIcpu_type\fR are .RS 4 ! .Ip "\fBev4\fR" 4 .IX Item "ev4" .PD 0 ! .Ip "\fB21064\fR" 4 .IX Item "21064" .PD Schedules as an \s-1EV4\s0 and has no instruction set extensions. ! .Ip "\fBev5\fR" 4 .IX Item "ev5" .PD 0 ! .Ip "\fB21164\fR" 4 .IX Item "21164" .PD Schedules as an \s-1EV5\s0 and has no instruction set extensions. ! .Ip "\fBev56\fR" 4 .IX Item "ev56" .PD 0 ! .Ip "\fB21164a\fR" 4 .IX Item "21164a" .PD Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 extension. ! .Ip "\fBpca56\fR" 4 .IX Item "pca56" .PD 0 ! .Ip "\fB21164pc\fR" 4 .IX Item "21164pc" ! .Ip "\fB21164PC\fR" 4 .IX Item "21164PC" .PD Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 and \s-1MAX\s0 extensions. ! .Ip "\fBev6\fR" 4 .IX Item "ev6" .PD 0 ! .Ip "\fB21264\fR" 4 .IX Item "21264" .PD Schedules as an \s-1EV5\s0 (until Digital releases the scheduling parameters --- 6653,6692 ---- .Sp Supported values for \fIcpu_type\fR are .RS 4 ! .IP "\fBev4\fR" 4 .IX Item "ev4" .PD 0 ! .IP "\fB21064\fR" 4 .IX Item "21064" .PD Schedules as an \s-1EV4\s0 and has no instruction set extensions. ! .IP "\fBev5\fR" 4 .IX Item "ev5" .PD 0 ! .IP "\fB21164\fR" 4 .IX Item "21164" .PD Schedules as an \s-1EV5\s0 and has no instruction set extensions. ! .IP "\fBev56\fR" 4 .IX Item "ev56" .PD 0 ! .IP "\fB21164a\fR" 4 .IX Item "21164a" .PD Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 extension. ! .IP "\fBpca56\fR" 4 .IX Item "pca56" .PD 0 ! .IP "\fB21164pc\fR" 4 .IX Item "21164pc" ! .IP "\fB21164PC\fR" 4 .IX Item "21164PC" .PD Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 and \s-1MAX\s0 extensions. ! .IP "\fBev6\fR" 4 .IX Item "ev6" .PD 0 ! .IP "\fB21264\fR" 4 .IX Item "21264" .PD Schedules as an \s-1EV5\s0 (until Digital releases the scheduling parameters *************** for the \s-1EV6\s0) and supports the \s- *** 6705,6711 **** .RE .RS 4 .RE ! .Ip "\fB\-mmemory-latency=\fR\fItime\fR" 4 .IX Item "-mmemory-latency=time" Sets the latency the scheduler should assume for typical memory references as seen by the application. This number is highly --- 6694,6700 ---- .RE .RS 4 .RE ! .IP "\fB\-mmemory-latency=\fR\fItime\fR" 4 .IX Item "-mmemory-latency=time" Sets the latency the scheduler should assume for typical memory references as seen by the application. This number is highly *************** and the size of the external cache on th *** 6714,6730 **** .Sp Valid options for \fItime\fR are .RS 4 ! .Ip "\fInumber\fR" 4 .IX Item "number" A decimal number representing clock cycles. ! .Ip "\fBL1\fR" 4 .IX Item "L1" .PD 0 ! .Ip "\fBL2\fR" 4 .IX Item "L2" ! .Ip "\fBL3\fR" 4 .IX Item "L3" ! .Ip "\fBmain\fR" 4 .IX Item "main" .PD The compiler contains estimates of the number of clock cycles for --- 6703,6719 ---- .Sp Valid options for \fItime\fR are .RS 4 ! .IP "\fInumber\fR" 4 .IX Item "number" A decimal number representing clock cycles. ! .IP "\fBL1\fR" 4 .IX Item "L1" .PD 0 ! .IP "\fBL2\fR" 4 .IX Item "L2" ! .IP "\fBL3\fR" 4 .IX Item "L3" ! .IP "\fBmain\fR" 4 .IX Item "main" .PD The compiler contains estimates of the number of clock cycles for *************** Note that L3 is only valid for \s-1EV5\s *** 6739,6748 **** .IX Subsection "Clipper Options" .PP These \fB\-m\fR options are defined for the Clipper implementations: ! .Ip "\fB\-mc300\fR" 4 .IX Item "-mc300" Produce code for a C300 Clipper processor. This is the default. ! .Ip "\fB\-mc400\fR" 4 .IX Item "-mc400" Produce code for a C400 Clipper processor i.e. use floating point registers f8\-\-\-f15. --- 6728,6737 ---- .IX Subsection "Clipper Options" .PP These \fB\-m\fR options are defined for the Clipper implementations: ! .IP "\fB\-mc300\fR" 4 .IX Item "-mc300" Produce code for a C300 Clipper processor. This is the default. ! .IP "\fB\-mc400\fR" 4 .IX Item "-mc400" Produce code for a C400 Clipper processor i.e. use floating point registers f8\-\-\-f15. *************** registers f8\-\-\-f15. *** 6751,6773 **** .IX Subsection "H8/300 Options" .PP These \fB\-m\fR options are defined for the H8/300 implementations: ! .Ip "\fB\-mrelax\fR" 4 .IX Item "-mrelax" Shorten some address references at link time, when possible; uses the linker option \fB\-relax\fR. ! .Ip "\fB\-mh\fR" 4 .IX Item "-mh" Generate code for the H8/300H. ! .Ip "\fB\-ms\fR" 4 .IX Item "-ms" Generate code for the H8/S. ! .Ip "\fB\-ms2600\fR" 4 .IX Item "-ms2600" Generate code for the H8/S2600. This switch must be used with \fB\-ms\fR. ! .Ip "\fB\-mint32\fR" 4 .IX Item "-mint32" Make \f(CW\*(C`int\*(C'\fR data 32 bits by default. ! .Ip "\fB\-malign-300\fR" 4 .IX Item "-malign-300" On the H8/300H and H8/S, use the same alignment rules as for the H8/300. The default for the H8/300H and H8/S is to align longs and floats on 4 --- 6740,6762 ---- .IX Subsection "H8/300 Options" .PP These \fB\-m\fR options are defined for the H8/300 implementations: ! .IP "\fB\-mrelax\fR" 4 .IX Item "-mrelax" Shorten some address references at link time, when possible; uses the linker option \fB\-relax\fR. ! .IP "\fB\-mh\fR" 4 .IX Item "-mh" Generate code for the H8/300H. ! .IP "\fB\-ms\fR" 4 .IX Item "-ms" Generate code for the H8/S. ! .IP "\fB\-ms2600\fR" 4 .IX Item "-ms2600" Generate code for the H8/S2600. This switch must be used with \fB\-ms\fR. ! .IP "\fB\-mint32\fR" 4 .IX Item "-mint32" Make \f(CW\*(C`int\*(C'\fR data 32 bits by default. ! .IP "\fB\-malign-300\fR" 4 .IX Item "-malign-300" On the H8/300H and H8/S, use the same alignment rules as for the H8/300. The default for the H8/300H and H8/S is to align longs and floats on 4 *************** This option has no effect on the H8/300. *** 6779,6857 **** .IX Subsection "SH Options" .PP These \fB\-m\fR options are defined for the \s-1SH\s0 implementations: ! .Ip "\fB\-m1\fR" 4 .IX Item "-m1" Generate code for the \s-1SH1\s0. ! .Ip "\fB\-m2\fR" 4 .IX Item "-m2" Generate code for the \s-1SH2\s0. ! .Ip "\fB\-m3\fR" 4 .IX Item "-m3" Generate code for the \s-1SH3\s0. ! .Ip "\fB\-m3e\fR" 4 .IX Item "-m3e" Generate code for the SH3e. ! .Ip "\fB\-m4\-nofpu\fR" 4 .IX Item "-m4-nofpu" Generate code for the \s-1SH4\s0 without a floating-point unit. ! .Ip "\fB\-m4\-single-only\fR" 4 .IX Item "-m4-single-only" Generate code for the \s-1SH4\s0 with a floating-point unit that only supports single-precision arithmetic. ! .Ip "\fB\-m4\-single\fR" 4 .IX Item "-m4-single" Generate code for the \s-1SH4\s0 assuming the floating-point unit is in single-precision mode by default. ! .Ip "\fB\-m4\fR" 4 .IX Item "-m4" Generate code for the \s-1SH4\s0. ! .Ip "\fB\-mb\fR" 4 .IX Item "-mb" Compile code for the processor in big endian mode. ! .Ip "\fB\-ml\fR" 4 .IX Item "-ml" Compile code for the processor in little endian mode. ! .Ip "\fB\-mdalign\fR" 4 .IX Item "-mdalign" Align doubles at 64\-bit boundaries. Note that this changes the calling conventions, and thus some functions from the standard C library will not work unless you recompile it first with \fB\-mdalign\fR. ! .Ip "\fB\-mrelax\fR" 4 .IX Item "-mrelax" Shorten some address references at link time, when possible; uses the linker option \fB\-relax\fR. ! .Ip "\fB\-mbigtable\fR" 4 .IX Item "-mbigtable" Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables. The default is to use 16\-bit offsets. ! .Ip "\fB\-mfmovd\fR" 4 .IX Item "-mfmovd" Enable the use of the instruction \f(CW\*(C`fmovd\*(C'\fR. ! .Ip "\fB\-mhitachi\fR" 4 .IX Item "-mhitachi" Comply with the calling conventions defined by Hitachi. ! .Ip "\fB\-mnomacsave\fR" 4 .IX Item "-mnomacsave" Mark the \f(CW\*(C`MAC\*(C'\fR register as call-clobbered, even if \&\fB\-mhitachi\fR is given. ! .Ip "\fB\-mieee\fR" 4 .IX Item "-mieee" Increase IEEE-compliance of floating-point code. ! .Ip "\fB\-misize\fR" 4 .IX Item "-misize" Dump instruction size and location in the assembly code. ! .Ip "\fB\-mpadstruct\fR" 4 .IX Item "-mpadstruct" This option is deprecated. It pads structures to multiple of 4 bytes, which is incompatible with the \s-1SH\s0 \s-1ABI\s0. ! .Ip "\fB\-mspace\fR" 4 .IX Item "-mspace" Optimize for space instead of speed. Implied by \fB\-Os\fR. ! .Ip "\fB\-mprefergot\fR" 4 .IX Item "-mprefergot" When generating position-independent code, emit function calls using the Global Offset Table instead of the Procedure Linkage Table. ! .Ip "\fB\-musermode\fR" 4 .IX Item "-musermode" Generate a library function call to invalidate instruction cache entries, after fixing up a trampoline. This library function call --- 6768,6846 ---- .IX Subsection "SH Options" .PP These \fB\-m\fR options are defined for the \s-1SH\s0 implementations: ! .IP "\fB\-m1\fR" 4 .IX Item "-m1" Generate code for the \s-1SH1\s0. ! .IP "\fB\-m2\fR" 4 .IX Item "-m2" Generate code for the \s-1SH2\s0. ! .IP "\fB\-m3\fR" 4 .IX Item "-m3" Generate code for the \s-1SH3\s0. ! .IP "\fB\-m3e\fR" 4 .IX Item "-m3e" Generate code for the SH3e. ! .IP "\fB\-m4\-nofpu\fR" 4 .IX Item "-m4-nofpu" Generate code for the \s-1SH4\s0 without a floating-point unit. ! .IP "\fB\-m4\-single-only\fR" 4 .IX Item "-m4-single-only" Generate code for the \s-1SH4\s0 with a floating-point unit that only supports single-precision arithmetic. ! .IP "\fB\-m4\-single\fR" 4 .IX Item "-m4-single" Generate code for the \s-1SH4\s0 assuming the floating-point unit is in single-precision mode by default. ! .IP "\fB\-m4\fR" 4 .IX Item "-m4" Generate code for the \s-1SH4\s0. ! .IP "\fB\-mb\fR" 4 .IX Item "-mb" Compile code for the processor in big endian mode. ! .IP "\fB\-ml\fR" 4 .IX Item "-ml" Compile code for the processor in little endian mode. ! .IP "\fB\-mdalign\fR" 4 .IX Item "-mdalign" Align doubles at 64\-bit boundaries. Note that this changes the calling conventions, and thus some functions from the standard C library will not work unless you recompile it first with \fB\-mdalign\fR. ! .IP "\fB\-mrelax\fR" 4 .IX Item "-mrelax" Shorten some address references at link time, when possible; uses the linker option \fB\-relax\fR. ! .IP "\fB\-mbigtable\fR" 4 .IX Item "-mbigtable" Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables. The default is to use 16\-bit offsets. ! .IP "\fB\-mfmovd\fR" 4 .IX Item "-mfmovd" Enable the use of the instruction \f(CW\*(C`fmovd\*(C'\fR. ! .IP "\fB\-mhitachi\fR" 4 .IX Item "-mhitachi" Comply with the calling conventions defined by Hitachi. ! .IP "\fB\-mnomacsave\fR" 4 .IX Item "-mnomacsave" Mark the \f(CW\*(C`MAC\*(C'\fR register as call-clobbered, even if \&\fB\-mhitachi\fR is given. ! .IP "\fB\-mieee\fR" 4 .IX Item "-mieee" Increase IEEE-compliance of floating-point code. ! .IP "\fB\-misize\fR" 4 .IX Item "-misize" Dump instruction size and location in the assembly code. ! .IP "\fB\-mpadstruct\fR" 4 .IX Item "-mpadstruct" This option is deprecated. It pads structures to multiple of 4 bytes, which is incompatible with the \s-1SH\s0 \s-1ABI\s0. ! .IP "\fB\-mspace\fR" 4 .IX Item "-mspace" Optimize for space instead of speed. Implied by \fB\-Os\fR. ! .IP "\fB\-mprefergot\fR" 4 .IX Item "-mprefergot" When generating position-independent code, emit function calls using the Global Offset Table instead of the Procedure Linkage Table. ! .IP "\fB\-musermode\fR" 4 .IX Item "-musermode" Generate a library function call to invalidate instruction cache entries, after fixing up a trampoline. This library function call *************** is the default when the target is \f(CW\ *** 6863,6885 **** .PP These additional options are available on System V Release 4 for compatibility with other compilers on those systems: ! .Ip "\fB\-G\fR" 4 .IX Item "-G" Create a shared object. It is recommended that \fB\-symbolic\fR or \fB\-shared\fR be used instead. ! .Ip "\fB\-Qy\fR" 4 .IX Item "-Qy" Identify the versions of each tool used by the compiler, in a \&\f(CW\*(C`.ident\*(C'\fR assembler directive in the output. ! .Ip "\fB\-Qn\fR" 4 .IX Item "-Qn" Refrain from adding \f(CW\*(C`.ident\*(C'\fR directives to the output file (this is the default). ! .Ip "\fB\-YP,\fR\fIdirs\fR" 4 .IX Item "-YP,dirs" Search the directories \fIdirs\fR, and no others, for libraries specified with \fB\-l\fR. ! .Ip "\fB\-Ym,\fR\fIdir\fR" 4 .IX Item "-Ym,dir" Look in the directory \fIdir\fR to find the M4 preprocessor. The assembler uses this option. --- 6852,6874 ---- .PP These additional options are available on System V Release 4 for compatibility with other compilers on those systems: ! .IP "\fB\-G\fR" 4 .IX Item "-G" Create a shared object. It is recommended that \fB\-symbolic\fR or \fB\-shared\fR be used instead. ! .IP "\fB\-Qy\fR" 4 .IX Item "-Qy" Identify the versions of each tool used by the compiler, in a \&\f(CW\*(C`.ident\*(C'\fR assembler directive in the output. ! .IP "\fB\-Qn\fR" 4 .IX Item "-Qn" Refrain from adding \f(CW\*(C`.ident\*(C'\fR directives to the output file (this is the default). ! .IP "\fB\-YP,\fR\fIdirs\fR" 4 .IX Item "-YP,dirs" Search the directories \fIdirs\fR, and no others, for libraries specified with \fB\-l\fR. ! .IP "\fB\-Ym,\fR\fIdir\fR" 4 .IX Item "-Ym,dir" Look in the directory \fIdir\fR to find the M4 preprocessor. The assembler uses this option. *************** The assembler uses this option. *** 6888,6908 **** .IX Subsection "TMS320C3x/C4x Options" .PP These \fB\-m\fR options are defined for TMS320C3x/C4x implementations: ! .Ip "\fB\-mcpu=\fR\fIcpu_type\fR" 4 .IX Item "-mcpu=cpu_type" Set the instruction set, register set, and instruction scheduling parameters for machine type \fIcpu_type\fR. Supported values for \&\fIcpu_type\fR are \fBc30\fR, \fBc31\fR, \fBc32\fR, \fBc40\fR, and \&\fBc44\fR. The default is \fBc40\fR to generate code for the \&\s-1TMS320C40\s0. ! .Ip "\fB\-mbig-memory\fR" 4 .IX Item "-mbig-memory" .PD 0 ! .Ip "\fB\-mbig\fR" 4 .IX Item "-mbig" ! .Ip "\fB\-msmall-memory\fR" 4 .IX Item "-msmall-memory" ! .Ip "\fB\-msmall\fR" 4 .IX Item "-msmall" .PD Generates code for the big or small memory model. The small memory --- 6877,6897 ---- .IX Subsection "TMS320C3x/C4x Options" .PP These \fB\-m\fR options are defined for TMS320C3x/C4x implementations: ! .IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4 .IX Item "-mcpu=cpu_type" Set the instruction set, register set, and instruction scheduling parameters for machine type \fIcpu_type\fR. Supported values for \&\fIcpu_type\fR are \fBc30\fR, \fBc31\fR, \fBc32\fR, \fBc40\fR, and \&\fBc44\fR. The default is \fBc40\fR to generate code for the \&\s-1TMS320C40\s0. ! .IP "\fB\-mbig-memory\fR" 4 .IX Item "-mbig-memory" .PD 0 ! .IP "\fB\-mbig\fR" 4 .IX Item "-mbig" ! .IP "\fB\-msmall-memory\fR" 4 .IX Item "-msmall-memory" ! .IP "\fB\-msmall\fR" 4 .IX Item "-msmall" .PD Generates code for the big or small memory model. The small memory *************** the data page (\s-1DP\s0) register must *** 6911,6928 **** containing the .bss and .data program sections. The big memory model is the default and requires reloading of the \s-1DP\s0 register for every direct memory access. ! .Ip "\fB\-mbk\fR" 4 .IX Item "-mbk" .PD 0 ! .Ip "\fB\-mno-bk\fR" 4 .IX Item "-mno-bk" .PD Allow (disallow) allocation of general integer operands into the block count register \s-1BK\s0. ! .Ip "\fB\-mdb\fR" 4 .IX Item "-mdb" .PD 0 ! .Ip "\fB\-mno-db\fR" 4 .IX Item "-mno-db" .PD Enable (disable) generation of code using decrement and branch, --- 6900,6917 ---- containing the .bss and .data program sections. The big memory model is the default and requires reloading of the \s-1DP\s0 register for every direct memory access. ! .IP "\fB\-mbk\fR" 4 .IX Item "-mbk" .PD 0 ! .IP "\fB\-mno-bk\fR" 4 .IX Item "-mno-bk" .PD Allow (disallow) allocation of general integer operands into the block count register \s-1BK\s0. ! .IP "\fB\-mdb\fR" 4 .IX Item "-mdb" .PD 0 ! .IP "\fB\-mno-db\fR" 4 .IX Item "-mno-db" .PD Enable (disable) generation of code using decrement and branch, *************** that it can utilise the decrement and br *** 6934,6943 **** up if there is more than one memory reference in the loop. Thus a loop where the loop counter is decremented can generate slightly more efficient code, in cases where the \s-1RPTB\s0 instruction cannot be utilised. ! .Ip "\fB\-mdp-isr-reload\fR" 4 .IX Item "-mdp-isr-reload" .PD 0 ! .Ip "\fB\-mparanoid\fR" 4 .IX Item "-mparanoid" .PD Force the \s-1DP\s0 register to be saved on entry to an interrupt service --- 6923,6932 ---- up if there is more than one memory reference in the loop. Thus a loop where the loop counter is decremented can generate slightly more efficient code, in cases where the \s-1RPTB\s0 instruction cannot be utilised. ! .IP "\fB\-mdp-isr-reload\fR" 4 .IX Item "-mdp-isr-reload" .PD 0 ! .IP "\fB\-mparanoid\fR" 4 .IX Item "-mparanoid" .PD Force the \s-1DP\s0 register to be saved on entry to an interrupt service *************** routine (\s-1ISR\s0), reloaded to point *** 6945,6954 **** exit from the \s-1ISR\s0. This should not be required unless someone has violated the small memory model by modifying the \s-1DP\s0 register, say within an object library. ! .Ip "\fB\-mmpyi\fR" 4 .IX Item "-mmpyi" .PD 0 ! .Ip "\fB\-mno-mpyi\fR" 4 .IX Item "-mno-mpyi" .PD For the C3x use the 24\-bit \s-1MPYI\s0 instruction for integer multiplies --- 6934,6943 ---- exit from the \s-1ISR\s0. This should not be required unless someone has violated the small memory model by modifying the \s-1DP\s0 register, say within an object library. ! .IP "\fB\-mmpyi\fR" 4 .IX Item "-mmpyi" .PD 0 ! .IP "\fB\-mno-mpyi\fR" 4 .IX Item "-mno-mpyi" .PD For the C3x use the 24\-bit \s-1MPYI\s0 instruction for integer multiplies *************** instead of a library call to guarantee 3 *** 6956,6965 **** of the operands is a constant, then the multiplication will be performed using shifts and adds. If the \fB\-mmpyi\fR option is not specified for the C3x, then squaring operations are performed inline instead of a library call. ! .Ip "\fB\-mfast-fix\fR" 4 .IX Item "-mfast-fix" .PD 0 ! .Ip "\fB\-mno-fast-fix\fR" 4 .IX Item "-mno-fast-fix" .PD The C3x/C4x \s-1FIX\s0 instruction to convert a floating point value to an --- 6945,6954 ---- of the operands is a constant, then the multiplication will be performed using shifts and adds. If the \fB\-mmpyi\fR option is not specified for the C3x, then squaring operations are performed inline instead of a library call. ! .IP "\fB\-mfast-fix\fR" 4 .IX Item "-mfast-fix" .PD 0 ! .IP "\fB\-mno-fast-fix\fR" 4 .IX Item "-mno-fast-fix" .PD The C3x/C4x \s-1FIX\s0 instruction to convert a floating point value to an *************** floating point number is negative, the r *** 6969,6978 **** truncated an additional code is necessary to detect and correct this case. This option can be used to disable generation of the additional code required to correct the result. ! .Ip "\fB\-mrptb\fR" 4 .IX Item "-mrptb" .PD 0 ! .Ip "\fB\-mno-rptb\fR" 4 .IX Item "-mno-rptb" .PD Enable (disable) generation of repeat block sequences using the \s-1RPTB\s0 --- 6958,6967 ---- truncated an additional code is necessary to detect and correct this case. This option can be used to disable generation of the additional code required to correct the result. ! .IP "\fB\-mrptb\fR" 4 .IX Item "-mrptb" .PD 0 ! .IP "\fB\-mno-rptb\fR" 4 .IX Item "-mno-rptb" .PD Enable (disable) generation of repeat block sequences using the \s-1RPTB\s0 *************** for innermost loops that do not call fun *** 6981,6990 **** boundaries. There is no advantage having nested \s-1RPTB\s0 loops due to the overhead required to save and restore the \s-1RC\s0, \s-1RS\s0, and \s-1RE\s0 registers. This is enabled by default with \fB\-O2\fR. ! .Ip "\fB\-mrpts=\fR\fIcount\fR" 4 .IX Item "-mrpts=count" .PD 0 ! .Ip "\fB\-mno-rpts\fR" 4 .IX Item "-mno-rpts" .PD Enable (disable) the use of the single instruction repeat instruction --- 6970,6979 ---- boundaries. There is no advantage having nested \s-1RPTB\s0 loops due to the overhead required to save and restore the \s-1RC\s0, \s-1RS\s0, and \s-1RE\s0 registers. This is enabled by default with \fB\-O2\fR. ! .IP "\fB\-mrpts=\fR\fIcount\fR" 4 .IX Item "-mrpts=count" .PD 0 ! .IP "\fB\-mno-rpts\fR" 4 .IX Item "-mno-rpts" .PD Enable (disable) the use of the single instruction repeat instruction *************** at compile time. Note that the repeated *** 6996,7005 **** not have to be reloaded from memory each iteration, thus freeing up the \&\s-1CPU\s0 buses for operands. However, since interrupts are blocked by this instruction, it is disabled by default. ! .Ip "\fB\-mloop-unsigned\fR" 4 .IX Item "-mloop-unsigned" .PD 0 ! .Ip "\fB\-mno-loop-unsigned\fR" 4 .IX Item "-mno-loop-unsigned" .PD The maximum iteration count when using \s-1RPTS\s0 and \s-1RPTB\s0 (and \s-1DB\s0 on the C40) --- 6985,6994 ---- not have to be reloaded from memory each iteration, thus freeing up the \&\s-1CPU\s0 buses for operands. However, since interrupts are blocked by this instruction, it is disabled by default. ! .IP "\fB\-mloop-unsigned\fR" 4 .IX Item "-mloop-unsigned" .PD 0 ! .IP "\fB\-mno-loop-unsigned\fR" 4 .IX Item "-mno-loop-unsigned" .PD The maximum iteration count when using \s-1RPTS\s0 and \s-1RPTB\s0 (and \s-1DB\s0 on the C40) *************** is 2^31 + 1 since these instructions tes *** 7007,7039 **** negative to terminate the loop. If the iteration count is unsigned there is a possibility than the 2^31 + 1 maximum iteration count may be exceeded. This switch allows an unsigned iteration count. ! .Ip "\fB\-mti\fR" 4 .IX Item "-mti" Try to emit an assembler syntax that the \s-1TI\s0 assembler (asm30) is happy with. This also enforces compatibility with the \s-1API\s0 employed by the \s-1TI\s0 C3x C compiler. For example, long doubles are passed as structures rather than in floating point registers. ! .Ip "\fB\-mregparm\fR" 4 .IX Item "-mregparm" .PD 0 ! .Ip "\fB\-mmemparm\fR" 4 .IX Item "-mmemparm" .PD Generate code that uses registers (stack) for passing arguments to functions. By default, arguments are passed in registers where possible rather than by pushing arguments on to the stack. ! .Ip "\fB\-mparallel-insns\fR" 4 .IX Item "-mparallel-insns" .PD 0 ! .Ip "\fB\-mno-parallel-insns\fR" 4 .IX Item "-mno-parallel-insns" .PD Allow the generation of parallel instructions. This is enabled by default with \fB\-O2\fR. ! .Ip "\fB\-mparallel-mpy\fR" 4 .IX Item "-mparallel-mpy" .PD 0 ! .Ip "\fB\-mno-parallel-mpy\fR" 4 .IX Item "-mno-parallel-mpy" .PD Allow the generation of MPY||ADD and MPY||SUB parallel instructions, --- 6996,7028 ---- negative to terminate the loop. If the iteration count is unsigned there is a possibility than the 2^31 + 1 maximum iteration count may be exceeded. This switch allows an unsigned iteration count. ! .IP "\fB\-mti\fR" 4 .IX Item "-mti" Try to emit an assembler syntax that the \s-1TI\s0 assembler (asm30) is happy with. This also enforces compatibility with the \s-1API\s0 employed by the \s-1TI\s0 C3x C compiler. For example, long doubles are passed as structures rather than in floating point registers. ! .IP "\fB\-mregparm\fR" 4 .IX Item "-mregparm" .PD 0 ! .IP "\fB\-mmemparm\fR" 4 .IX Item "-mmemparm" .PD Generate code that uses registers (stack) for passing arguments to functions. By default, arguments are passed in registers where possible rather than by pushing arguments on to the stack. ! .IP "\fB\-mparallel-insns\fR" 4 .IX Item "-mparallel-insns" .PD 0 ! .IP "\fB\-mno-parallel-insns\fR" 4 .IX Item "-mno-parallel-insns" .PD Allow the generation of parallel instructions. This is enabled by default with \fB\-O2\fR. ! .IP "\fB\-mparallel-mpy\fR" 4 .IX Item "-mparallel-mpy" .PD 0 ! .IP "\fB\-mno-parallel-mpy\fR" 4 .IX Item "-mno-parallel-mpy" .PD Allow the generation of MPY||ADD and MPY||SUB parallel instructions, *************** of large functions. *** 7045,7073 **** .IX Subsection "V850 Options" .PP These \fB\-m\fR options are defined for V850 implementations: ! .Ip "\fB\-mlong-calls\fR" 4 .IX Item "-mlong-calls" .PD 0 ! .Ip "\fB\-mno-long-calls\fR" 4 .IX Item "-mno-long-calls" .PD Treat all calls as being far away (near). If calls are assumed to be far away, the compiler will always load the functions address up into a register, and call indirect through the pointer. ! .Ip "\fB\-mno-ep\fR" 4 .IX Item "-mno-ep" .PD 0 ! .Ip "\fB\-mep\fR" 4 .IX Item "-mep" .PD Do not optimize (do optimize) basic blocks that use the same index pointer 4 or more times to copy pointer into the \f(CW\*(C`ep\*(C'\fR register, and use the shorter \f(CW\*(C`sld\*(C'\fR and \f(CW\*(C`sst\*(C'\fR instructions. The \fB\-mep\fR option is on by default if you optimize. ! .Ip "\fB\-mno-prolog-function\fR" 4 .IX Item "-mno-prolog-function" .PD 0 ! .Ip "\fB\-mprolog-function\fR" 4 .IX Item "-mprolog-function" .PD Do not use (do use) external functions to save and restore registers at --- 7034,7062 ---- .IX Subsection "V850 Options" .PP These \fB\-m\fR options are defined for V850 implementations: ! .IP "\fB\-mlong-calls\fR" 4 .IX Item "-mlong-calls" .PD 0 ! .IP "\fB\-mno-long-calls\fR" 4 .IX Item "-mno-long-calls" .PD Treat all calls as being far away (near). If calls are assumed to be far away, the compiler will always load the functions address up into a register, and call indirect through the pointer. ! .IP "\fB\-mno-ep\fR" 4 .IX Item "-mno-ep" .PD 0 ! .IP "\fB\-mep\fR" 4 .IX Item "-mep" .PD Do not optimize (do optimize) basic blocks that use the same index pointer 4 or more times to copy pointer into the \f(CW\*(C`ep\*(C'\fR register, and use the shorter \f(CW\*(C`sld\*(C'\fR and \f(CW\*(C`sst\*(C'\fR instructions. The \fB\-mep\fR option is on by default if you optimize. ! .IP "\fB\-mno-prolog-function\fR" 4 .IX Item "-mno-prolog-function" .PD 0 ! .IP "\fB\-mprolog-function\fR" 4 .IX Item "-mprolog-function" .PD Do not use (do use) external functions to save and restore registers at *************** the prolog and epilog of a function. Th *** 7075,7102 **** but use less code space if more than one function saves the same number of registers. The \fB\-mprolog-function\fR option is on by default if you optimize. ! .Ip "\fB\-mspace\fR" 4 .IX Item "-mspace" Try to make the code as small as possible. At present, this just turns on the \fB\-mep\fR and \fB\-mprolog-function\fR options. ! .Ip "\fB\-mtda=\fR\fIn\fR" 4 .IX Item "-mtda=n" Put static or global variables whose size is \fIn\fR bytes or less into the tiny data area that register \f(CW\*(C`ep\*(C'\fR points to. The tiny data area can hold up to 256 bytes in total (128 bytes for byte references). ! .Ip "\fB\-msda=\fR\fIn\fR" 4 .IX Item "-msda=n" Put static or global variables whose size is \fIn\fR bytes or less into the small data area that register \f(CW\*(C`gp\*(C'\fR points to. The small data area can hold up to 64 kilobytes. ! .Ip "\fB\-mzda=\fR\fIn\fR" 4 .IX Item "-mzda=n" Put static or global variables whose size is \fIn\fR bytes or less into the first 32 kilobytes of memory. ! .Ip "\fB\-mv850\fR" 4 .IX Item "-mv850" Specify that the target processor is the V850. ! .Ip "\fB\-mbig-switch\fR" 4 .IX Item "-mbig-switch" Generate code suitable for big switch tables. Use this option only if the assembler/linker complain about out of range branches within a switch --- 7064,7091 ---- but use less code space if more than one function saves the same number of registers. The \fB\-mprolog-function\fR option is on by default if you optimize. ! .IP "\fB\-mspace\fR" 4 .IX Item "-mspace" Try to make the code as small as possible. At present, this just turns on the \fB\-mep\fR and \fB\-mprolog-function\fR options. ! .IP "\fB\-mtda=\fR\fIn\fR" 4 .IX Item "-mtda=n" Put static or global variables whose size is \fIn\fR bytes or less into the tiny data area that register \f(CW\*(C`ep\*(C'\fR points to. The tiny data area can hold up to 256 bytes in total (128 bytes for byte references). ! .IP "\fB\-msda=\fR\fIn\fR" 4 .IX Item "-msda=n" Put static or global variables whose size is \fIn\fR bytes or less into the small data area that register \f(CW\*(C`gp\*(C'\fR points to. The small data area can hold up to 64 kilobytes. ! .IP "\fB\-mzda=\fR\fIn\fR" 4 .IX Item "-mzda=n" Put static or global variables whose size is \fIn\fR bytes or less into the first 32 kilobytes of memory. ! .IP "\fB\-mv850\fR" 4 .IX Item "-mv850" Specify that the target processor is the V850. ! .IP "\fB\-mbig-switch\fR" 4 .IX Item "-mbig-switch" Generate code suitable for big switch tables. Use this option only if the assembler/linker complain about out of range branches within a switch *************** table. *** 7106,7118 **** .IX Subsection "ARC Options" .PP These options are defined for \s-1ARC\s0 implementations: ! .Ip "\fB\-EL\fR" 4 .IX Item "-EL" Compile code for little endian mode. This is the default. ! .Ip "\fB\-EB\fR" 4 .IX Item "-EB" Compile code for big endian mode. ! .Ip "\fB\-mmangle-cpu\fR" 4 .IX Item "-mmangle-cpu" Prepend the name of the cpu to all public symbol names. In multiple-processor systems, there are many \s-1ARC\s0 variants with different --- 7095,7107 ---- .IX Subsection "ARC Options" .PP These options are defined for \s-1ARC\s0 implementations: ! .IP "\fB\-EL\fR" 4 .IX Item "-EL" Compile code for little endian mode. This is the default. ! .IP "\fB\-EB\fR" 4 .IX Item "-EB" Compile code for big endian mode. ! .IP "\fB\-mmangle-cpu\fR" 4 .IX Item "-mmangle-cpu" Prepend the name of the cpu to all public symbol names. In multiple-processor systems, there are many \s-1ARC\s0 variants with different *************** instruction and register set characteris *** 7120,7136 **** compiled for one cpu to be linked with code compiled for another. No facility exists for handling variants that are ``almost identical''. This is an all or nothing option. ! .Ip "\fB\-mcpu=\fR\fIcpu\fR" 4 .IX Item "-mcpu=cpu" Compile code for \s-1ARC\s0 variant \fIcpu\fR. Which variants are supported depend on the configuration. All variants support \fB\-mcpu=base\fR, this is the default. ! .Ip "\fB\-mtext=\fR\fItext-section\fR" 4 .IX Item "-mtext=text-section" .PD 0 ! .Ip "\fB\-mdata=\fR\fIdata-section\fR" 4 .IX Item "-mdata=data-section" ! .Ip "\fB\-mrodata=\fR\fIreadonly-data-section\fR" 4 .IX Item "-mrodata=readonly-data-section" .PD Put functions, data, and readonly data in \fItext-section\fR, --- 7109,7125 ---- compiled for one cpu to be linked with code compiled for another. No facility exists for handling variants that are ``almost identical''. This is an all or nothing option. ! .IP "\fB\-mcpu=\fR\fIcpu\fR" 4 .IX Item "-mcpu=cpu" Compile code for \s-1ARC\s0 variant \fIcpu\fR. Which variants are supported depend on the configuration. All variants support \fB\-mcpu=base\fR, this is the default. ! .IP "\fB\-mtext=\fR\fItext-section\fR" 4 .IX Item "-mtext=text-section" .PD 0 ! .IP "\fB\-mdata=\fR\fIdata-section\fR" 4 .IX Item "-mdata=data-section" ! .IP "\fB\-mrodata=\fR\fIreadonly-data-section\fR" 4 .IX Item "-mrodata=readonly-data-section" .PD Put functions, data, and readonly data in \fItext-section\fR, *************** These are the \fB\-m\fR options defined *** 7144,7207 **** values for these options depends on which style of 32000 was selected when the compiler was configured; the defaults for the most common choices are given below. ! .Ip "\fB\-m32032\fR" 4 .IX Item "-m32032" .PD 0 ! .Ip "\fB\-m32032\fR" 4 .IX Item "-m32032" .PD Generate output for a 32032. This is the default when the compiler is configured for 32032 and 32016 based systems. ! .Ip "\fB\-m32332\fR" 4 .IX Item "-m32332" .PD 0 ! .Ip "\fB\-m32332\fR" 4 .IX Item "-m32332" .PD Generate output for a 32332. This is the default when the compiler is configured for 32332\-based systems. ! .Ip "\fB\-m32532\fR" 4 .IX Item "-m32532" .PD 0 ! .Ip "\fB\-m32532\fR" 4 .IX Item "-m32532" .PD Generate output for a 32532. This is the default when the compiler is configured for 32532\-based systems. ! .Ip "\fB\-m32081\fR" 4 .IX Item "-m32081" Generate output containing 32081 instructions for floating point. This is the default for all systems. ! .Ip "\fB\-m32381\fR" 4 .IX Item "-m32381" Generate output containing 32381 instructions for floating point. This also implies \fB\-m32081\fR. The 32381 is only compatible with the 32332 and 32532 cpus. This is the default for the pc532\-netbsd configuration. ! .Ip "\fB\-mmulti-add\fR" 4 .IX Item "-mmulti-add" Try and generate multiply-add floating point instructions \f(CW\*(C`polyF\*(C'\fR and \f(CW\*(C`dotF\*(C'\fR. This option is only available if the \fB\-m32381\fR ! option is in effect. Using these instructions requires changes to to register allocation which generally has a negative impact on performance. This option should only be enabled when compiling code particularly likely to make heavy use of multiply-add instructions. ! .Ip "\fB\-mnomulti-add\fR" 4 .IX Item "-mnomulti-add" Do not try and generate multiply-add floating point instructions \&\f(CW\*(C`polyF\*(C'\fR and \f(CW\*(C`dotF\*(C'\fR. This is the default on all platforms. ! .Ip "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries may not be available. ! .Ip "\fB\-mnobitfield\fR" 4 .IX Item "-mnobitfield" Do not use the bit-field instructions. On some machines it is faster to use shifting and masking operations. This is the default for the pc532. ! .Ip "\fB\-mbitfield\fR" 4 .IX Item "-mbitfield" Do use the bit-field instructions. This is the default for all platforms except the pc532. ! .Ip "\fB\-mrtd\fR" 4 .IX Item "-mrtd" Use a different function-calling convention, in which functions that take a fixed number of arguments return pop their --- 7133,7196 ---- values for these options depends on which style of 32000 was selected when the compiler was configured; the defaults for the most common choices are given below. ! .IP "\fB\-m32032\fR" 4 .IX Item "-m32032" .PD 0 ! .IP "\fB\-m32032\fR" 4 .IX Item "-m32032" .PD Generate output for a 32032. This is the default when the compiler is configured for 32032 and 32016 based systems. ! .IP "\fB\-m32332\fR" 4 .IX Item "-m32332" .PD 0 ! .IP "\fB\-m32332\fR" 4 .IX Item "-m32332" .PD Generate output for a 32332. This is the default when the compiler is configured for 32332\-based systems. ! .IP "\fB\-m32532\fR" 4 .IX Item "-m32532" .PD 0 ! .IP "\fB\-m32532\fR" 4 .IX Item "-m32532" .PD Generate output for a 32532. This is the default when the compiler is configured for 32532\-based systems. ! .IP "\fB\-m32081\fR" 4 .IX Item "-m32081" Generate output containing 32081 instructions for floating point. This is the default for all systems. ! .IP "\fB\-m32381\fR" 4 .IX Item "-m32381" Generate output containing 32381 instructions for floating point. This also implies \fB\-m32081\fR. The 32381 is only compatible with the 32332 and 32532 cpus. This is the default for the pc532\-netbsd configuration. ! .IP "\fB\-mmulti-add\fR" 4 .IX Item "-mmulti-add" Try and generate multiply-add floating point instructions \f(CW\*(C`polyF\*(C'\fR and \f(CW\*(C`dotF\*(C'\fR. This option is only available if the \fB\-m32381\fR ! option is in effect. Using these instructions requires changes to register allocation which generally has a negative impact on performance. This option should only be enabled when compiling code particularly likely to make heavy use of multiply-add instructions. ! .IP "\fB\-mnomulti-add\fR" 4 .IX Item "-mnomulti-add" Do not try and generate multiply-add floating point instructions \&\f(CW\*(C`polyF\*(C'\fR and \f(CW\*(C`dotF\*(C'\fR. This is the default on all platforms. ! .IP "\fB\-msoft-float\fR" 4 .IX Item "-msoft-float" Generate output containing library calls for floating point. \&\fBWarning:\fR the requisite libraries may not be available. ! .IP "\fB\-mnobitfield\fR" 4 .IX Item "-mnobitfield" Do not use the bit-field instructions. On some machines it is faster to use shifting and masking operations. This is the default for the pc532. ! .IP "\fB\-mbitfield\fR" 4 .IX Item "-mbitfield" Do use the bit-field instructions. This is the default for all platforms except the pc532. ! .IP "\fB\-mrtd\fR" 4 .IX Item "-mrtd" Use a different function-calling convention, in which functions that take a fixed number of arguments return pop their *************** function with too many arguments. (Norm *** 7221,7227 **** harmlessly ignored.) .Sp This option takes its name from the 680x0 \f(CW\*(C`rtd\*(C'\fR instruction. ! .Ip "\fB\-mregparam\fR" 4 .IX Item "-mregparam" Use a different function-calling convention where the first two arguments are passed in registers. --- 7210,7216 ---- harmlessly ignored.) .Sp This option takes its name from the 680x0 \f(CW\*(C`rtd\*(C'\fR instruction. ! .IP "\fB\-mregparam\fR" 4 .IX Item "-mregparam" Use a different function-calling convention where the first two arguments are passed in registers. *************** are passed in registers. *** 7229,7255 **** This calling convention is incompatible with the one normally used on Unix, so you cannot use it if you need to call libraries compiled with the Unix compiler. ! .Ip "\fB\-mnoregparam\fR" 4 .IX Item "-mnoregparam" Do not pass any arguments in registers. This is the default for all targets. ! .Ip "\fB\-msb\fR" 4 .IX Item "-msb" It is \s-1OK\s0 to use the sb as an index register which is always loaded with zero. This is the default for the pc532\-netbsd target. ! .Ip "\fB\-mnosb\fR" 4 .IX Item "-mnosb" The sb register is not available for use or has not been initialized to zero by the run time system. This is the default for all targets except the pc532\-netbsd. It is also implied whenever \fB\-mhimem\fR or \&\fB\-fpic\fR is set. ! .Ip "\fB\-mhimem\fR" 4 .IX Item "-mhimem" Many ns32000 series addressing modes use displacements of up to 512MB. If an address is above 512MB then displacements from zero can not be used. This option causes code to be generated which can be loaded above 512MB. This may be useful for operating systems or \s-1ROM\s0 code. ! .Ip "\fB\-mnohimem\fR" 4 .IX Item "-mnohimem" Assume code will be loaded in the first 512MB of virtual address space. This is the default for all platforms. --- 7218,7244 ---- This calling convention is incompatible with the one normally used on Unix, so you cannot use it if you need to call libraries compiled with the Unix compiler. ! .IP "\fB\-mnoregparam\fR" 4 .IX Item "-mnoregparam" Do not pass any arguments in registers. This is the default for all targets. ! .IP "\fB\-msb\fR" 4 .IX Item "-msb" It is \s-1OK\s0 to use the sb as an index register which is always loaded with zero. This is the default for the pc532\-netbsd target. ! .IP "\fB\-mnosb\fR" 4 .IX Item "-mnosb" The sb register is not available for use or has not been initialized to zero by the run time system. This is the default for all targets except the pc532\-netbsd. It is also implied whenever \fB\-mhimem\fR or \&\fB\-fpic\fR is set. ! .IP "\fB\-mhimem\fR" 4 .IX Item "-mhimem" Many ns32000 series addressing modes use displacements of up to 512MB. If an address is above 512MB then displacements from zero can not be used. This option causes code to be generated which can be loaded above 512MB. This may be useful for operating systems or \s-1ROM\s0 code. ! .IP "\fB\-mnohimem\fR" 4 .IX Item "-mnohimem" Assume code will be loaded in the first 512MB of virtual address space. This is the default for all platforms. *************** This is the default for all platforms. *** 7258,7264 **** .IX Subsection "AVR Options" .PP These options are defined for \s-1AVR\s0 implementations: ! .Ip "\fB\-mmcu=\fR\fImcu\fR" 4 .IX Item "-mmcu=mcu" Specify \s-1ATMEL\s0 \s-1AVR\s0 instruction set or \s-1MCU\s0 type. .Sp --- 7247,7253 ---- .IX Subsection "AVR Options" .PP These options are defined for \s-1AVR\s0 implementations: ! .IP "\fB\-mmcu=\fR\fImcu\fR" 4 .IX Item "-mmcu=mcu" Specify \s-1ATMEL\s0 \s-1AVR\s0 instruction set or \s-1MCU\s0 type. .Sp *************** memory space (\s-1MCU\s0 types: atmega83 *** 7279,7303 **** .Sp Instruction set avr5 is for the enhanced \s-1AVR\s0 core with up to 128K program memory space (\s-1MCU\s0 types: atmega161, atmega163, atmega32, at94k). ! .Ip "\fB\-msize\fR" 4 .IX Item "-msize" Output instruction sizes to the asm file. ! .Ip "\fB\-minit-stack=\fR\fIN\fR" 4 .IX Item "-minit-stack=N" Specify the initial stack address, which may be a symbol or numeric value, \&\fB_\|_stack\fR is the default. ! .Ip "\fB\-mno-interrupts\fR" 4 .IX Item "-mno-interrupts" Generated code is not compatible with hardware interrupts. Code size will be smaller. ! .Ip "\fB\-mcall-prologues\fR" 4 .IX Item "-mcall-prologues" Functions prologues/epilogues expanded as call to appropriate subroutines. Code size will be smaller. ! .Ip "\fB\-mno-tablejump\fR" 4 .IX Item "-mno-tablejump" Do not generate tablejump insns which sometimes increase code size. ! .Ip "\fB\-mtiny-stack\fR" 4 .IX Item "-mtiny-stack" Change only the low 8 bits of the stack pointer. .PP --- 7268,7292 ---- .Sp Instruction set avr5 is for the enhanced \s-1AVR\s0 core with up to 128K program memory space (\s-1MCU\s0 types: atmega161, atmega163, atmega32, at94k). ! .IP "\fB\-msize\fR" 4 .IX Item "-msize" Output instruction sizes to the asm file. ! .IP "\fB\-minit-stack=\fR\fIN\fR" 4 .IX Item "-minit-stack=N" Specify the initial stack address, which may be a symbol or numeric value, \&\fB_\|_stack\fR is the default. ! .IP "\fB\-mno-interrupts\fR" 4 .IX Item "-mno-interrupts" Generated code is not compatible with hardware interrupts. Code size will be smaller. ! .IP "\fB\-mcall-prologues\fR" 4 .IX Item "-mcall-prologues" Functions prologues/epilogues expanded as call to appropriate subroutines. Code size will be smaller. ! .IP "\fB\-mno-tablejump\fR" 4 .IX Item "-mno-tablejump" Do not generate tablejump insns which sometimes increase code size. ! .IP "\fB\-mtiny-stack\fR" 4 .IX Item "-mtiny-stack" Change only the low 8 bits of the stack pointer. .PP *************** Change only the low 8 bits of the stack *** 7306,7390 **** .PP These are the \fB\-m\fR options defined for the Motorola M*Core processors. ! .Ip "\fB\-mhardlit\fR" 4 .IX Item "-mhardlit" .PD 0 ! .Ip "\fB\-mhardlit\fR" 4 .IX Item "-mhardlit" ! .Ip "\fB\-mno-hardlit\fR" 4 .IX Item "-mno-hardlit" .PD Inline constants into the code stream if it can be done in two instructions or less. ! .Ip "\fB\-mdiv\fR" 4 .IX Item "-mdiv" .PD 0 ! .Ip "\fB\-mdiv\fR" 4 .IX Item "-mdiv" ! .Ip "\fB\-mno-div\fR" 4 .IX Item "-mno-div" .PD Use the divide instruction. (Enabled by default). ! .Ip "\fB\-mrelax-immediate\fR" 4 .IX Item "-mrelax-immediate" .PD 0 ! .Ip "\fB\-mrelax-immediate\fR" 4 .IX Item "-mrelax-immediate" ! .Ip "\fB\-mno-relax-immediate\fR" 4 .IX Item "-mno-relax-immediate" .PD Allow arbitrary sized immediates in bit operations. ! .Ip "\fB\-mwide-bitfields\fR" 4 .IX Item "-mwide-bitfields" .PD 0 ! .Ip "\fB\-mwide-bitfields\fR" 4 .IX Item "-mwide-bitfields" ! .Ip "\fB\-mno-wide-bitfields\fR" 4 .IX Item "-mno-wide-bitfields" .PD Always treat bit-fields as int-sized. ! .Ip "\fB\-m4byte-functions\fR" 4 .IX Item "-m4byte-functions" .PD 0 ! .Ip "\fB\-m4byte-functions\fR" 4 .IX Item "-m4byte-functions" ! .Ip "\fB\-mno-4byte-functions\fR" 4 .IX Item "-mno-4byte-functions" .PD Force all functions to be aligned to a four byte boundary. ! .Ip "\fB\-mcallgraph-data\fR" 4 .IX Item "-mcallgraph-data" .PD 0 ! .Ip "\fB\-mcallgraph-data\fR" 4 .IX Item "-mcallgraph-data" ! .Ip "\fB\-mno-callgraph-data\fR" 4 .IX Item "-mno-callgraph-data" .PD Emit callgraph information. ! .Ip "\fB\-mslow-bytes\fR" 4 .IX Item "-mslow-bytes" .PD 0 ! .Ip "\fB\-mslow-bytes\fR" 4 .IX Item "-mslow-bytes" ! .Ip "\fB\-mno-slow-bytes\fR" 4 .IX Item "-mno-slow-bytes" .PD Prefer word access when reading byte quantities. ! .Ip "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" .PD 0 ! .Ip "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" ! .Ip "\fB\-mbig-endian\fR" 4 .IX Item "-mbig-endian" .PD Generate code for a little endian target. ! .Ip "\fB\-m210\fR" 4 .IX Item "-m210" .PD 0 ! .Ip "\fB\-m210\fR" 4 .IX Item "-m210" ! .Ip "\fB\-m340\fR" 4 .IX Item "-m340" .PD Generate code for the 210 processor. --- 7295,7379 ---- .PP These are the \fB\-m\fR options defined for the Motorola M*Core processors. ! .IP "\fB\-mhardlit\fR" 4 .IX Item "-mhardlit" .PD 0 ! .IP "\fB\-mhardlit\fR" 4 .IX Item "-mhardlit" ! .IP "\fB\-mno-hardlit\fR" 4 .IX Item "-mno-hardlit" .PD Inline constants into the code stream if it can be done in two instructions or less. ! .IP "\fB\-mdiv\fR" 4 .IX Item "-mdiv" .PD 0 ! .IP "\fB\-mdiv\fR" 4 .IX Item "-mdiv" ! .IP "\fB\-mno-div\fR" 4 .IX Item "-mno-div" .PD Use the divide instruction. (Enabled by default). ! .IP "\fB\-mrelax-immediate\fR" 4 .IX Item "-mrelax-immediate" .PD 0 ! .IP "\fB\-mrelax-immediate\fR" 4 .IX Item "-mrelax-immediate" ! .IP "\fB\-mno-relax-immediate\fR" 4 .IX Item "-mno-relax-immediate" .PD Allow arbitrary sized immediates in bit operations. ! .IP "\fB\-mwide-bitfields\fR" 4 .IX Item "-mwide-bitfields" .PD 0 ! .IP "\fB\-mwide-bitfields\fR" 4 .IX Item "-mwide-bitfields" ! .IP "\fB\-mno-wide-bitfields\fR" 4 .IX Item "-mno-wide-bitfields" .PD Always treat bit-fields as int-sized. ! .IP "\fB\-m4byte-functions\fR" 4 .IX Item "-m4byte-functions" .PD 0 ! .IP "\fB\-m4byte-functions\fR" 4 .IX Item "-m4byte-functions" ! .IP "\fB\-mno-4byte-functions\fR" 4 .IX Item "-mno-4byte-functions" .PD Force all functions to be aligned to a four byte boundary. ! .IP "\fB\-mcallgraph-data\fR" 4 .IX Item "-mcallgraph-data" .PD 0 ! .IP "\fB\-mcallgraph-data\fR" 4 .IX Item "-mcallgraph-data" ! .IP "\fB\-mno-callgraph-data\fR" 4 .IX Item "-mno-callgraph-data" .PD Emit callgraph information. ! .IP "\fB\-mslow-bytes\fR" 4 .IX Item "-mslow-bytes" .PD 0 ! .IP "\fB\-mslow-bytes\fR" 4 .IX Item "-mslow-bytes" ! .IP "\fB\-mno-slow-bytes\fR" 4 .IX Item "-mno-slow-bytes" .PD Prefer word access when reading byte quantities. ! .IP "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" .PD 0 ! .IP "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" ! .IP "\fB\-mbig-endian\fR" 4 .IX Item "-mbig-endian" .PD Generate code for a little endian target. ! .IP "\fB\-m210\fR" 4 .IX Item "-m210" .PD 0 ! .IP "\fB\-m210\fR" 4 .IX Item "-m210" ! .IP "\fB\-m340\fR" 4 .IX Item "-m340" .PD Generate code for the 210 processor. *************** Generate code for the 210 processor. *** 7393,7473 **** .IX Subsection "IA-64 Options" .PP These are the \fB\-m\fR options defined for the Intel \s-1IA-64\s0 architecture. ! .Ip "\fB\-mbig-endian\fR" 4 .IX Item "-mbig-endian" Generate code for a big endian target. This is the default for \s-1HPUX\s0. ! .Ip "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" Generate code for a little endian target. This is the default for \s-1AIX5\s0 and Linux. ! .Ip "\fB\-mgnu-as\fR" 4 .IX Item "-mgnu-as" .PD 0 ! .Ip "\fB\-mno-gnu-as\fR" 4 .IX Item "-mno-gnu-as" .PD Generate (or don't) code for the \s-1GNU\s0 assembler. This is the default. ! .Ip "\fB\-mgnu-ld\fR" 4 .IX Item "-mgnu-ld" .PD 0 ! .Ip "\fB\-mno-gnu-ld\fR" 4 .IX Item "-mno-gnu-ld" .PD Generate (or don't) code for the \s-1GNU\s0 linker. This is the default. ! .Ip "\fB\-mno-pic\fR" 4 .IX Item "-mno-pic" Generate code that does not use a global pointer register. The result is not position independent code, and violates the \s-1IA-64\s0 \s-1ABI\s0. ! .Ip "\fB\-mvolatile-asm-stop\fR" 4 .IX Item "-mvolatile-asm-stop" .PD 0 ! .Ip "\fB\-mno-volatile-asm-stop\fR" 4 .IX Item "-mno-volatile-asm-stop" .PD Generate (or don't) a stop bit immediately before and after volatile asm statements. ! .Ip "\fB\-mb-step\fR" 4 .IX Item "-mb-step" Generate code that works around Itanium B step errata. ! .Ip "\fB\-mregister-names\fR" 4 .IX Item "-mregister-names" .PD 0 ! .Ip "\fB\-mno-register-names\fR" 4 .IX Item "-mno-register-names" .PD Generate (or don't) \fBin\fR, \fBloc\fR, and \fBout\fR register names for the stacked registers. This may make assembler output more readable. ! .Ip "\fB\-mno-sdata\fR" 4 .IX Item "-mno-sdata" .PD 0 ! .Ip "\fB\-msdata\fR" 4 .IX Item "-msdata" .PD Disable (or enable) optimizations that use the small data section. This may be useful for working around optimizer bugs. ! .Ip "\fB\-mconstant-gp\fR" 4 .IX Item "-mconstant-gp" Generate code that uses a single constant global pointer value. This is useful when compiling kernel code. ! .Ip "\fB\-mauto-pic\fR" 4 .IX Item "-mauto-pic" Generate code that is self-relocatable. This implies \fB\-mconstant-gp\fR. This is useful when compiling firmware code. ! .Ip "\fB\-minline-divide-min-latency\fR" 4 .IX Item "-minline-divide-min-latency" Generate code for inline divides using the minimum latency algorithm. ! .Ip "\fB\-minline-divide-max-throughput\fR" 4 .IX Item "-minline-divide-max-throughput" Generate code for inline divides using the maximum throughput algorithm. ! .Ip "\fB\-mno-dwarf2\-asm\fR" 4 .IX Item "-mno-dwarf2-asm" .PD 0 ! .Ip "\fB\-mdwarf2\-asm\fR" 4 .IX Item "-mdwarf2-asm" .PD Don't (or do) generate assembler code for the \s-1DWARF2\s0 line number debugging info. This may be useful when not using the \s-1GNU\s0 assembler. ! .Ip "\fB\-mfixed-range=\fR\fIregister-range\fR" 4 .IX Item "-mfixed-range=register-range" Generate code treating the given register range as fixed registers. A fixed register is one that the register allocator can not use. This is --- 7382,7462 ---- .IX Subsection "IA-64 Options" .PP These are the \fB\-m\fR options defined for the Intel \s-1IA-64\s0 architecture. ! .IP "\fB\-mbig-endian\fR" 4 .IX Item "-mbig-endian" Generate code for a big endian target. This is the default for \s-1HPUX\s0. ! .IP "\fB\-mlittle-endian\fR" 4 .IX Item "-mlittle-endian" Generate code for a little endian target. This is the default for \s-1AIX5\s0 and Linux. ! .IP "\fB\-mgnu-as\fR" 4 .IX Item "-mgnu-as" .PD 0 ! .IP "\fB\-mno-gnu-as\fR" 4 .IX Item "-mno-gnu-as" .PD Generate (or don't) code for the \s-1GNU\s0 assembler. This is the default. ! .IP "\fB\-mgnu-ld\fR" 4 .IX Item "-mgnu-ld" .PD 0 ! .IP "\fB\-mno-gnu-ld\fR" 4 .IX Item "-mno-gnu-ld" .PD Generate (or don't) code for the \s-1GNU\s0 linker. This is the default. ! .IP "\fB\-mno-pic\fR" 4 .IX Item "-mno-pic" Generate code that does not use a global pointer register. The result is not position independent code, and violates the \s-1IA-64\s0 \s-1ABI\s0. ! .IP "\fB\-mvolatile-asm-stop\fR" 4 .IX Item "-mvolatile-asm-stop" .PD 0 ! .IP "\fB\-mno-volatile-asm-stop\fR" 4 .IX Item "-mno-volatile-asm-stop" .PD Generate (or don't) a stop bit immediately before and after volatile asm statements. ! .IP "\fB\-mb-step\fR" 4 .IX Item "-mb-step" Generate code that works around Itanium B step errata. ! .IP "\fB\-mregister-names\fR" 4 .IX Item "-mregister-names" .PD 0 ! .IP "\fB\-mno-register-names\fR" 4 .IX Item "-mno-register-names" .PD Generate (or don't) \fBin\fR, \fBloc\fR, and \fBout\fR register names for the stacked registers. This may make assembler output more readable. ! .IP "\fB\-mno-sdata\fR" 4 .IX Item "-mno-sdata" .PD 0 ! .IP "\fB\-msdata\fR" 4 .IX Item "-msdata" .PD Disable (or enable) optimizations that use the small data section. This may be useful for working around optimizer bugs. ! .IP "\fB\-mconstant-gp\fR" 4 .IX Item "-mconstant-gp" Generate code that uses a single constant global pointer value. This is useful when compiling kernel code. ! .IP "\fB\-mauto-pic\fR" 4 .IX Item "-mauto-pic" Generate code that is self-relocatable. This implies \fB\-mconstant-gp\fR. This is useful when compiling firmware code. ! .IP "\fB\-minline-divide-min-latency\fR" 4 .IX Item "-minline-divide-min-latency" Generate code for inline divides using the minimum latency algorithm. ! .IP "\fB\-minline-divide-max-throughput\fR" 4 .IX Item "-minline-divide-max-throughput" Generate code for inline divides using the maximum throughput algorithm. ! .IP "\fB\-mno-dwarf2\-asm\fR" 4 .IX Item "-mno-dwarf2-asm" .PD 0 ! .IP "\fB\-mdwarf2\-asm\fR" 4 .IX Item "-mdwarf2-asm" .PD Don't (or do) generate assembler code for the \s-1DWARF2\s0 line number debugging info. This may be useful when not using the \s-1GNU\s0 assembler. ! .IP "\fB\-mfixed-range=\fR\fIregister-range\fR" 4 .IX Item "-mfixed-range=register-range" Generate code treating the given register range as fixed registers. A fixed register is one that the register allocator can not use. This is *************** specified separated by a comma. *** 7479,7516 **** .IX Subsection "D30V Options" .PP These \fB\-m\fR options are defined for D30V implementations: ! .Ip "\fB\-mextmem\fR" 4 .IX Item "-mextmem" Link the \fB.text\fR, \fB.data\fR, \fB.bss\fR, \fB.strings\fR, \&\fB.rodata\fR, \fB.rodata1\fR, \fB.data1\fR sections into external ! memory, which starts at location \f(CW\*(C`0x80000000\*(C'\fR. ! .Ip "\fB\-mextmemory\fR" 4 .IX Item "-mextmemory" Same as the \fB\-mextmem\fR switch. ! .Ip "\fB\-monchip\fR" 4 .IX Item "-monchip" Link the \fB.text\fR section into onchip text memory, which starts at ! location \f(CW\*(C`0x0\*(C'\fR. Also link \fB.data\fR, \fB.bss\fR, \&\fB.strings\fR, \fB.rodata\fR, \fB.rodata1\fR, \fB.data1\fR sections ! into onchip data memory, which starts at location \f(CW\*(C`0x20000000\*(C'\fR. ! .Ip "\fB\-mno-asm-optimize\fR" 4 .IX Item "-mno-asm-optimize" .PD 0 ! .Ip "\fB\-masm-optimize\fR" 4 .IX Item "-masm-optimize" .PD Disable (enable) passing \fB\-O\fR to the assembler when optimizing. The assembler uses the \fB\-O\fR option to automatically parallelize adjacent short instructions where possible. ! .Ip "\fB\-mbranch-cost=\fR\fIn\fR" 4 .IX Item "-mbranch-cost=n" Increase the internal costs of branches to \fIn\fR. Higher costs means that the compiler will issue more instructions to avoid doing a branch. The default is 2. ! .Ip "\fB\-mcond-exec=\fR\fIn\fR" 4 .IX Item "-mcond-exec=n" Specify the maximum number of conditionally executed instructions that replace a branch. The default is 4. .Sh "Options for Code Generation Conventions" .IX Subsection "Options for Code Generation Conventions" These machine-independent options control the interface conventions --- 7468,7571 ---- .IX Subsection "D30V Options" .PP These \fB\-m\fR options are defined for D30V implementations: ! .IP "\fB\-mextmem\fR" 4 .IX Item "-mextmem" Link the \fB.text\fR, \fB.data\fR, \fB.bss\fR, \fB.strings\fR, \&\fB.rodata\fR, \fB.rodata1\fR, \fB.data1\fR sections into external ! memory, which starts at location \f(CW0x80000000\fR. ! .IP "\fB\-mextmemory\fR" 4 .IX Item "-mextmemory" Same as the \fB\-mextmem\fR switch. ! .IP "\fB\-monchip\fR" 4 .IX Item "-monchip" Link the \fB.text\fR section into onchip text memory, which starts at ! location \f(CW0x0\fR. Also link \fB.data\fR, \fB.bss\fR, \&\fB.strings\fR, \fB.rodata\fR, \fB.rodata1\fR, \fB.data1\fR sections ! into onchip data memory, which starts at location \f(CW0x20000000\fR. ! .IP "\fB\-mno-asm-optimize\fR" 4 .IX Item "-mno-asm-optimize" .PD 0 ! .IP "\fB\-masm-optimize\fR" 4 .IX Item "-masm-optimize" .PD Disable (enable) passing \fB\-O\fR to the assembler when optimizing. The assembler uses the \fB\-O\fR option to automatically parallelize adjacent short instructions where possible. ! .IP "\fB\-mbranch-cost=\fR\fIn\fR" 4 .IX Item "-mbranch-cost=n" Increase the internal costs of branches to \fIn\fR. Higher costs means that the compiler will issue more instructions to avoid doing a branch. The default is 2. ! .IP "\fB\-mcond-exec=\fR\fIn\fR" 4 .IX Item "-mcond-exec=n" Specify the maximum number of conditionally executed instructions that replace a branch. The default is 4. + .PP + .I "S/390 and zSeries Options" + .IX Subsection "S/390 and zSeries Options" + .PP + These are the \fB\-m\fR options defined for the S/390 and zSeries architecture. + .IP "\fB\-mhard-float\fR" 4 + .IX Item "-mhard-float" + .PD 0 + .IP "\fB\-msoft-float\fR" 4 + .IX Item "-msoft-float" + .PD + Use (do not use) the hardware floating-point instructions and registers + for floating-point operations. When \fB\-msoft-float\fR is specified, + functions in \fIlibgcc.a\fR will be used to perform floating-point + operations. When \fB\-mhard-float\fR is specified, the compiler + generates \s-1IEEE\s0 floating-point instructions. This is the default. + .IP "\fB\-mbackchain\fR" 4 + .IX Item "-mbackchain" + .PD 0 + .IP "\fB\-mno-backchain\fR" 4 + .IX Item "-mno-backchain" + .PD + Generate (or do not generate) code which maintains an explicit + backchain within the stack frame that points to the caller's frame. + This is currently needed to allow debugging. The default is to + generate the backchain. + .IP "\fB\-msmall-exec\fR" 4 + .IX Item "-msmall-exec" + .PD 0 + .IP "\fB\-mno-small-exec\fR" 4 + .IX Item "-mno-small-exec" + .PD + Generate (or do not generate) code using the \f(CW\*(C`bras\*(C'\fR instruction + to do subroutine calls. + This only works reliably if the total executable size does not + exceed 64k. The default is to use the \f(CW\*(C`basr\*(C'\fR instruction instead, + which does not have this limitation. + .IP "\fB\-m64\fR" 4 + .IX Item "-m64" + .PD 0 + .IP "\fB\-m31\fR" 4 + .IX Item "-m31" + .PD + When \fB\-m31\fR is specified, generate code compliant to the + Linux for S/390 \s-1ABI\s0. When \fB\-m64\fR is specified, generate + code compliant to the Linux for zSeries \s-1ABI\s0. This allows \s-1GCC\s0 in + particular to generate 64\-bit instructions. For the \fBs390\fR + targets, the default is \fB\-m31\fR, while the \fBs390x\fR + targets default to \fB\-m64\fR. + .IP "\fB\-mmvcle\fR" 4 + .IX Item "-mmvcle" + .PD 0 + .IP "\fB\-mno-mvcle\fR" 4 + .IX Item "-mno-mvcle" + .PD + Generate (or do not generate) code using the \f(CW\*(C`mvcle\*(C'\fR instruction + to perform block moves. When \fB\-mno-mvcle\fR is specifed, + use a \f(CW\*(C`mvc\*(C'\fR loop instead. This is the default. + .IP "\fB\-mdebug\fR" 4 + .IX Item "-mdebug" + .PD 0 + .IP "\fB\-mno-debug\fR" 4 + .IX Item "-mno-debug" + .PD + Print (or do not print) additional debug information when compiling. + The default is to not print debug information. .Sh "Options for Code Generation Conventions" .IX Subsection "Options for Code Generation Conventions" These machine-independent options control the interface conventions *************** of \fB\-ffoo\fR would be \fB\-fno-foo\fR *** 7521,7527 **** one of the forms is listed\-\-\-the one which is not the default. You can figure out the other form by either removing \fBno-\fR or adding it. ! .Ip "\fB\-fexceptions\fR" 4 .IX Item "-fexceptions" Enable exception handling. Generates extra code needed to propagate exceptions. For some targets, this implies \s-1GCC\s0 will generate frame --- 7576,7582 ---- one of the forms is listed\-\-\-the one which is not the default. You can figure out the other form by either removing \fBno-\fR or adding it. ! .IP "\fB\-fexceptions\fR" 4 .IX Item "-fexceptions" Enable exception handling. Generates extra code needed to propagate exceptions. For some targets, this implies \s-1GCC\s0 will generate frame *************** to enable this option when compiling C c *** 7534,7540 **** properly with exception handlers written in \*(C+. You may also wish to disable this option if you are compiling older \*(C+ programs that don't use exception handling. ! .Ip "\fB\-fnon-call-exceptions\fR" 4 .IX Item "-fnon-call-exceptions" Generate code that allows trapping instructions to throw exceptions. Note that this requires platform-specific runtime support that does --- 7589,7595 ---- properly with exception handlers written in \*(C+. You may also wish to disable this option if you are compiling older \*(C+ programs that don't use exception handling. ! .IP "\fB\-fnon-call-exceptions\fR" 4 .IX Item "-fnon-call-exceptions" Generate code that allows trapping instructions to throw exceptions. Note that this requires platform-specific runtime support that does *************** not exist everywhere. Moreover, it only *** 7542,7554 **** instructions to throw exceptions, i.e. memory references or floating point instructions. It does not allow exceptions to be thrown from arbitrary signal handlers such as \f(CW\*(C`SIGALRM\*(C'\fR. ! .Ip "\fB\-funwind-tables\fR" 4 .IX Item "-funwind-tables" Similar to \fB\-fexceptions\fR, except that it will just generate any needed static data, but will not affect the generated code in any other way. You will normally not enable this option; instead, a language processor that needs this handling would enable it on your behalf. ! .Ip "\fB\-fpcc-struct-return\fR" 4 .IX Item "-fpcc-struct-return" Return ``short'' \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in memory like longer ones, rather than in registers. This convention is less --- 7597,7609 ---- instructions to throw exceptions, i.e. memory references or floating point instructions. It does not allow exceptions to be thrown from arbitrary signal handlers such as \f(CW\*(C`SIGALRM\*(C'\fR. ! .IP "\fB\-funwind-tables\fR" 4 .IX Item "-funwind-tables" Similar to \fB\-fexceptions\fR, except that it will just generate any needed static data, but will not affect the generated code in any other way. You will normally not enable this option; instead, a language processor that needs this handling would enable it on your behalf. ! .IP "\fB\-fpcc-struct-return\fR" 4 .IX Item "-fpcc-struct-return" Return ``short'' \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in memory like longer ones, rather than in registers. This convention is less *************** on the target configuration macros. *** 7560,7566 **** .Sp Short structures and unions are those whose size and alignment match that of some integer type. ! .Ip "\fB\-freg-struct-return\fR" 4 .IX Item "-freg-struct-return" Use the convention that \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values are returned in registers when possible. This is more efficient for small --- 7615,7621 ---- .Sp Short structures and unions are those whose size and alignment match that of some integer type. ! .IP "\fB\-freg-struct-return\fR" 4 .IX Item "-freg-struct-return" Use the convention that \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values are returned in registers when possible. This is more efficient for small *************** standard for the target. If there is no *** 7572,7593 **** defaults to \fB\-fpcc-struct-return\fR, except on targets where \s-1GCC\s0 is the principal compiler. In those cases, we can choose the standard, and we chose the more efficient register return alternative. ! .Ip "\fB\-fshort-enums\fR" 4 .IX Item "-fshort-enums" Allocate to an \f(CW\*(C`enum\*(C'\fR type only as many bytes as it needs for the declared range of possible values. Specifically, the \f(CW\*(C`enum\*(C'\fR type will be equivalent to the smallest integer type which has enough room. ! .Ip "\fB\-fshort-double\fR" 4 .IX Item "-fshort-double" Use the same size for \f(CW\*(C`double\*(C'\fR as for \f(CW\*(C`float\*(C'\fR. ! .Ip "\fB\-fshared-data\fR" 4 .IX Item "-fshared-data" Requests that the data and non-\f(CW\*(C`const\*(C'\fR variables of this compilation be shared data rather than private data. The distinction makes sense only on certain operating systems, where shared data is shared between processes running the same program, while private data exists in one copy per process. ! .Ip "\fB\-fno-common\fR" 4 .IX Item "-fno-common" In C, allocate even uninitialized global variables in the data section of the object file, rather than generating them as common blocks. This has the --- 7627,7648 ---- defaults to \fB\-fpcc-struct-return\fR, except on targets where \s-1GCC\s0 is the principal compiler. In those cases, we can choose the standard, and we chose the more efficient register return alternative. ! .IP "\fB\-fshort-enums\fR" 4 .IX Item "-fshort-enums" Allocate to an \f(CW\*(C`enum\*(C'\fR type only as many bytes as it needs for the declared range of possible values. Specifically, the \f(CW\*(C`enum\*(C'\fR type will be equivalent to the smallest integer type which has enough room. ! .IP "\fB\-fshort-double\fR" 4 .IX Item "-fshort-double" Use the same size for \f(CW\*(C`double\*(C'\fR as for \f(CW\*(C`float\*(C'\fR. ! .IP "\fB\-fshared-data\fR" 4 .IX Item "-fshared-data" Requests that the data and non-\f(CW\*(C`const\*(C'\fR variables of this compilation be shared data rather than private data. The distinction makes sense only on certain operating systems, where shared data is shared between processes running the same program, while private data exists in one copy per process. ! .IP "\fB\-fno-common\fR" 4 .IX Item "-fno-common" In C, allocate even uninitialized global variables in the data section of the object file, rather than generating them as common blocks. This has the *************** effect that if the same variable is decl *** 7595,7604 **** two different compilations, you will get an error when you link them. The only reason this might be useful is if you wish to verify that the program will work on other systems which always work this way. ! .Ip "\fB\-fno-ident\fR" 4 .IX Item "-fno-ident" Ignore the \fB#ident\fR directive. ! .Ip "\fB\-fno-gnu-linker\fR" 4 .IX Item "-fno-gnu-linker" Do not output global initializations (such as \*(C+ constructors and destructors) in the form used by the \s-1GNU\s0 linker (on systems where the \s-1GNU\s0 --- 7650,7659 ---- two different compilations, you will get an error when you link them. The only reason this might be useful is if you wish to verify that the program will work on other systems which always work this way. ! .IP "\fB\-fno-ident\fR" 4 .IX Item "-fno-ident" Ignore the \fB#ident\fR directive. ! .IP "\fB\-fno-gnu-linker\fR" 4 .IX Item "-fno-gnu-linker" Do not output global initializations (such as \*(C+ constructors and destructors) in the form used by the \s-1GNU\s0 linker (on systems where the \s-1GNU\s0 *************** you want to use a non-GNU linker, which *** 7608,7621 **** constructors and destructors. (\fBcollect2\fR is included in the \s-1GCC\s0 distribution.) For systems which \fImust\fR use \fBcollect2\fR, the compiler driver \fBgcc\fR is configured to do this automatically. ! .Ip "\fB\-finhibit-size-directive\fR" 4 .IX Item "-finhibit-size-directive" Don't output a \f(CW\*(C`.size\*(C'\fR assembler directive, or anything else that would cause trouble if the function is split in the middle, and the two halves are placed at locations far apart in memory. This option is used when compiling \fIcrtstuff.c\fR; you should not need to use it for anything else. ! .Ip "\fB\-fverbose-asm\fR" 4 .IX Item "-fverbose-asm" Put extra commentary information in the generated assembly code to make it more readable. This option is generally only of use to those --- 7663,7676 ---- constructors and destructors. (\fBcollect2\fR is included in the \s-1GCC\s0 distribution.) For systems which \fImust\fR use \fBcollect2\fR, the compiler driver \fBgcc\fR is configured to do this automatically. ! .IP "\fB\-finhibit-size-directive\fR" 4 .IX Item "-finhibit-size-directive" Don't output a \f(CW\*(C`.size\*(C'\fR assembler directive, or anything else that would cause trouble if the function is split in the middle, and the two halves are placed at locations far apart in memory. This option is used when compiling \fIcrtstuff.c\fR; you should not need to use it for anything else. ! .IP "\fB\-fverbose-asm\fR" 4 .IX Item "-fverbose-asm" Put extra commentary information in the generated assembly code to make it more readable. This option is generally only of use to those *************** debugging the compiler itself). *** 7625,7642 **** \&\fB\-fno-verbose-asm\fR, the default, causes the extra information to be omitted and is useful when comparing two assembler files. ! .Ip "\fB\-fvolatile\fR" 4 .IX Item "-fvolatile" Consider all memory references through pointers to be volatile. ! .Ip "\fB\-fvolatile-global\fR" 4 .IX Item "-fvolatile-global" Consider all memory references to extern and global data items to be volatile. \s-1GCC\s0 does not consider static data items to be volatile because of this switch. ! .Ip "\fB\-fvolatile-static\fR" 4 .IX Item "-fvolatile-static" Consider all memory references to static data to be volatile. ! .Ip "\fB\-fpic\fR" 4 .IX Item "-fpic" Generate position-independent code (\s-1PIC\s0) suitable for use in a shared library, if supported for the target machine. Such code accesses all --- 7680,7697 ---- \&\fB\-fno-verbose-asm\fR, the default, causes the extra information to be omitted and is useful when comparing two assembler files. ! .IP "\fB\-fvolatile\fR" 4 .IX Item "-fvolatile" Consider all memory references through pointers to be volatile. ! .IP "\fB\-fvolatile-global\fR" 4 .IX Item "-fvolatile-global" Consider all memory references to extern and global data items to be volatile. \s-1GCC\s0 does not consider static data items to be volatile because of this switch. ! .IP "\fB\-fvolatile-static\fR" 4 .IX Item "-fvolatile-static" Consider all memory references to static data to be volatile. ! .IP "\fB\-fpic\fR" 4 .IX Item "-fpic" Generate position-independent code (\s-1PIC\s0) suitable for use in a shared library, if supported for the target machine. Such code accesses all *************** Position-independent code requires speci *** 7653,7659 **** only on certain machines. For the 386, \s-1GCC\s0 supports \s-1PIC\s0 for System V but not for the Sun 386i. Code generated for the \s-1IBM\s0 \s-1RS/6000\s0 is always position-independent. ! .Ip "\fB\-fPIC\fR" 4 .IX Item "-fPIC" If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the --- 7708,7714 ---- only on certain machines. For the 386, \s-1GCC\s0 supports \s-1PIC\s0 for System V but not for the Sun 386i. Code generated for the \s-1IBM\s0 \s-1RS/6000\s0 is always position-independent. ! .IP "\fB\-fPIC\fR" 4 .IX Item "-fPIC" If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the *************** and the Sparc. *** 7662,7668 **** .Sp Position-independent code requires special support, and therefore works only on certain machines. ! .Ip "\fB\-ffixed-\fR\fIreg\fR" 4 .IX Item "-ffixed-reg" Treat the register named \fIreg\fR as a fixed register; generated code should never refer to it (except perhaps as a stack pointer, frame --- 7717,7723 ---- .Sp Position-independent code requires special support, and therefore works only on certain machines. ! .IP "\fB\-ffixed-\fR\fIreg\fR" 4 .IX Item "-ffixed-reg" Treat the register named \fIreg\fR as a fixed register; generated code should never refer to it (except perhaps as a stack pointer, frame *************** macro in the machine description macro f *** 7674,7680 **** .Sp This flag does not have a negative form, because it specifies a three-way choice. ! .Ip "\fB\-fcall-used-\fR\fIreg\fR" 4 .IX Item "-fcall-used-reg" Treat the register named \fIreg\fR as an allocable register that is clobbered by function calls. It may be allocated for temporaries or --- 7729,7735 ---- .Sp This flag does not have a negative form, because it specifies a three-way choice. ! .IP "\fB\-fcall-used-\fR\fIreg\fR" 4 .IX Item "-fcall-used-reg" Treat the register named \fIreg\fR as an allocable register that is clobbered by function calls. It may be allocated for temporaries or *************** the machine's execution model will produ *** 7687,7693 **** .Sp This flag does not have a negative form, because it specifies a three-way choice. ! .Ip "\fB\-fcall-saved-\fR\fIreg\fR" 4 .IX Item "-fcall-saved-reg" Treat the register named \fIreg\fR as an allocable register saved by functions. It may be allocated even for temporaries or variables that --- 7742,7748 ---- .Sp This flag does not have a negative form, because it specifies a three-way choice. ! .IP "\fB\-fcall-saved-\fR\fIreg\fR" 4 .IX Item "-fcall-saved-reg" Treat the register named \fIreg\fR as an allocable register saved by functions. It may be allocated even for temporaries or variables that *************** a register in which function values may *** 7703,7714 **** .Sp This flag does not have a negative form, because it specifies a three-way choice. ! .Ip "\fB\-fpack-struct\fR" 4 .IX Item "-fpack-struct" Pack all structure members together without holes. Usually you would not want to use this option, since it makes the code suboptimal, and the offsets of structure members won't agree with system libraries. ! .Ip "\fB\-fcheck-memory-usage\fR" 4 .IX Item "-fcheck-memory-usage" Generate extra code to check each memory access. \s-1GCC\s0 will generate code that is suitable for a detector of bad memory accesses such as --- 7758,7769 ---- .Sp This flag does not have a negative form, because it specifies a three-way choice. ! .IP "\fB\-fpack-struct\fR" 4 .IX Item "-fpack-struct" Pack all structure members together without holes. Usually you would not want to use this option, since it makes the code suboptimal, and the offsets of structure members won't agree with system libraries. ! .IP "\fB\-fcheck-memory-usage\fR" 4 .IX Item "-fcheck-memory-usage" Generate extra code to check each memory access. \s-1GCC\s0 will generate code that is suitable for a detector of bad memory accesses such as *************** If you move your \f(CW\*(C`asm\*(C'\fR s *** 7746,7752 **** and they do access memory, you can add calls to the support code in your inline function, to indicate any reads, writes, or copies being done. These calls would be similar to those done in the stubs described above. ! .Ip "\fB\-fprefix-function-name\fR" 4 .IX Item "-fprefix-function-name" Request \s-1GCC\s0 to add a prefix to the symbols generated for function names. \&\s-1GCC\s0 adds a prefix to the names of functions defined as well as --- 7801,7807 ---- and they do access memory, you can add calls to the support code in your inline function, to indicate any reads, writes, or copies being done. These calls would be similar to those done in the stubs described above. ! .IP "\fB\-fprefix-function-name\fR" 4 .IX Item "-fprefix-function-name" Request \s-1GCC\s0 to add a prefix to the symbols generated for function names. \&\s-1GCC\s0 adds a prefix to the names of functions defined as well as *************** If you compile the following code with \ *** 7774,7780 **** \& } .Ve This option is designed to be used with \fB\-fcheck-memory-usage\fR. ! .Ip "\fB\-finstrument-functions\fR" 4 .IX Item "-finstrument-functions" Generate instrumentation calls for entry and exit to functions. Just after function entry and just before function exit, the following --- 7829,7835 ---- \& } .Ve This option is designed to be used with \fB\-fcheck-memory-usage\fR. ! .IP "\fB\-finstrument-functions\fR" 4 .IX Item "-finstrument-functions" Generate instrumentation calls for entry and exit to functions. Just after function entry and just before function exit, the following *************** example, for the profiling functions lis *** 7810,7816 **** interrupt routines, and any functions from which the profiling functions cannot safely be called (perhaps signal handlers, if the profiling routines generate output or allocate memory). ! .Ip "\fB\-fstack-check\fR" 4 .IX Item "-fstack-check" Generate code to verify that you do not go beyond the boundary of the stack. You should specify this flag if you are running in an --- 7865,7871 ---- interrupt routines, and any functions from which the profiling functions cannot safely be called (perhaps signal handlers, if the profiling routines generate output or allocate memory). ! .IP "\fB\-fstack-check\fR" 4 .IX Item "-fstack-check" Generate code to verify that you do not go beyond the boundary of the stack. You should specify this flag if you are running in an *************** detected on nearly all systems if there *** 7821,7832 **** Note that this switch does not actually cause checking to be done; the operating system must do that. The switch causes generation of code to ensure that the operating system sees the stack being extended. ! .Ip "\fB\-fstack-limit-register=\fR\fIreg\fR" 4 .IX Item "-fstack-limit-register=reg" .PD 0 ! .Ip "\fB\-fstack-limit-symbol=\fR\fIsym\fR" 4 .IX Item "-fstack-limit-symbol=sym" ! .Ip "\fB\-fno-stack-limit\fR" 4 .IX Item "-fno-stack-limit" .PD Generate code to ensure that the stack does not grow beyond a certain value, --- 7876,7887 ---- Note that this switch does not actually cause checking to be done; the operating system must do that. The switch causes generation of code to ensure that the operating system sees the stack being extended. ! .IP "\fB\-fstack-limit-register=\fR\fIreg\fR" 4 .IX Item "-fstack-limit-register=reg" .PD 0 ! .IP "\fB\-fstack-limit-symbol=\fR\fIsym\fR" 4 .IX Item "-fstack-limit-symbol=sym" ! .IP "\fB\-fno-stack-limit\fR" 4 .IX Item "-fno-stack-limit" .PD Generate code to ensure that the stack does not grow beyond a certain value, *************** downwards you can use the flags *** 7840,7851 **** \&\fB\-fstack-limit-symbol=_\|_stack_limit \&\-Wl,\-\-defsym,_\|_stack_limit=0x7ffe0000\fR which will enforce a stack limit of 128K. ! .Ip "\fB\-fargument-alias\fR" 4 .IX Item "-fargument-alias" .PD 0 ! .Ip "\fB\-fargument-noalias\fR" 4 .IX Item "-fargument-noalias" ! .Ip "\fB\-fargument-noalias-global\fR" 4 .IX Item "-fargument-noalias-global" .PD Specify the possible relationships among parameters and between --- 7895,7906 ---- \&\fB\-fstack-limit-symbol=_\|_stack_limit \&\-Wl,\-\-defsym,_\|_stack_limit=0x7ffe0000\fR which will enforce a stack limit of 128K. ! .IP "\fB\-fargument-alias\fR" 4 .IX Item "-fargument-alias" .PD 0 ! .IP "\fB\-fargument-noalias\fR" 4 .IX Item "-fargument-noalias" ! .IP "\fB\-fargument-noalias-global\fR" 4 .IX Item "-fargument-noalias-global" .PD Specify the possible relationships among parameters and between *************** alias each other and do not alias global *** 7860,7866 **** .Sp Each language will automatically use whatever option is required by the language standard. You should not need to use these options yourself. ! .Ip "\fB\-fleading-underscore\fR" 4 .IX Item "-fleading-underscore" This option and its counterpart, \fB\-fno-leading-underscore\fR, forcibly change the way C symbols are represented in the object file. One use --- 7915,7921 ---- .Sp Each language will automatically use whatever option is required by the language standard. You should not need to use these options yourself. ! .IP "\fB\-fleading-underscore\fR" 4 .IX Item "-fleading-underscore" This option and its counterpart, \fB\-fno-leading-underscore\fR, forcibly change the way C symbols are represented in the object file. One use *************** Note that you can also specify places to *** 7879,7892 **** \&\fB\-B\fR, \fB\-I\fR and \fB\-L\fR. These take precedence over places specified using environment variables, which in turn take precedence over those specified by the configuration of \s-1GCC\s0. ! .Ip "\fB\s-1LANG\s0\fR" 4 .IX Item "LANG" .PD 0 ! .Ip "\fB\s-1LC_CTYPE\s0\fR" 4 .IX Item "LC_CTYPE" ! .Ip "\fB\s-1LC_MESSAGES\s0\fR" 4 .IX Item "LC_MESSAGES" ! .Ip "\fB\s-1LC_ALL\s0\fR" 4 .IX Item "LC_ALL" .PD These environment variables control the way that \s-1GCC\s0 uses --- 7934,7947 ---- \&\fB\-B\fR, \fB\-I\fR and \fB\-L\fR. These take precedence over places specified using environment variables, which in turn take precedence over those specified by the configuration of \s-1GCC\s0. ! .IP "\fB\s-1LANG\s0\fR" 4 .IX Item "LANG" .PD 0 ! .IP "\fB\s-1LC_CTYPE\s0\fR" 4 .IX Item "LC_CTYPE" ! .IP "\fB\s-1LC_MESSAGES\s0\fR" 4 .IX Item "LC_MESSAGES" ! .IP "\fB\s-1LC_ALL\s0\fR" 4 .IX Item "LC_ALL" .PD These environment variables control the way that \s-1GCC\s0 uses *************** of \fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_M *** 7911,7924 **** and \fB\s-1LC_MESSAGES\s0\fR default to the value of the \fB\s-1LANG\s0\fR environment variable. If none of these variables are set, \s-1GCC\s0 defaults to traditional C English behavior. ! .Ip "\fB\s-1TMPDIR\s0\fR" 4 .IX Item "TMPDIR" If \fB\s-1TMPDIR\s0\fR is set, it specifies the directory to use for temporary files. \s-1GCC\s0 uses temporary files to hold the output of one stage of compilation which is to be used as input to the next stage: for example, the output of the preprocessor, which is the input to the compiler proper. ! .Ip "\fB\s-1GCC_EXEC_PREFIX\s0\fR" 4 .IX Item "GCC_EXEC_PREFIX" If \fB\s-1GCC_EXEC_PREFIX\s0\fR is set, it specifies a prefix to use in the names of the subprograms executed by the compiler. No slash is added --- 7966,7979 ---- and \fB\s-1LC_MESSAGES\s0\fR default to the value of the \fB\s-1LANG\s0\fR environment variable. If none of these variables are set, \s-1GCC\s0 defaults to traditional C English behavior. ! .IP "\fB\s-1TMPDIR\s0\fR" 4 .IX Item "TMPDIR" If \fB\s-1TMPDIR\s0\fR is set, it specifies the directory to use for temporary files. \s-1GCC\s0 uses temporary files to hold the output of one stage of compilation which is to be used as input to the next stage: for example, the output of the preprocessor, which is the input to the compiler proper. ! .IP "\fB\s-1GCC_EXEC_PREFIX\s0\fR" 4 .IX Item "GCC_EXEC_PREFIX" If \fB\s-1GCC_EXEC_PREFIX\s0\fR is set, it specifies a prefix to use in the names of the subprograms executed by the compiler. No slash is added *************** alternate directory name. Thus, with \f *** 7949,7961 **** \&\fIfoo/bar\fR where it would normally search \fI/usr/local/lib/bar\fR. These alternate directories are searched first; the standard directories come next. ! .Ip "\fB\s-1COMPILER_PATH\s0\fR" 4 .IX Item "COMPILER_PATH" The value of \fB\s-1COMPILER_PATH\s0\fR is a colon-separated list of directories, much like \fB\s-1PATH\s0\fR. \s-1GCC\s0 tries the directories thus specified when searching for subprograms, if it can't find the subprograms using \fB\s-1GCC_EXEC_PREFIX\s0\fR. ! .Ip "\fB\s-1LIBRARY_PATH\s0\fR" 4 .IX Item "LIBRARY_PATH" The value of \fB\s-1LIBRARY_PATH\s0\fR is a colon-separated list of directories, much like \fB\s-1PATH\s0\fR. When configured as a native compiler, --- 8004,8016 ---- \&\fIfoo/bar\fR where it would normally search \fI/usr/local/lib/bar\fR. These alternate directories are searched first; the standard directories come next. ! .IP "\fB\s-1COMPILER_PATH\s0\fR" 4 .IX Item "COMPILER_PATH" The value of \fB\s-1COMPILER_PATH\s0\fR is a colon-separated list of directories, much like \fB\s-1PATH\s0\fR. \s-1GCC\s0 tries the directories thus specified when searching for subprograms, if it can't find the subprograms using \fB\s-1GCC_EXEC_PREFIX\s0\fR. ! .IP "\fB\s-1LIBRARY_PATH\s0\fR" 4 .IX Item "LIBRARY_PATH" The value of \fB\s-1LIBRARY_PATH\s0\fR is a colon-separated list of directories, much like \fB\s-1PATH\s0\fR. When configured as a native compiler, *************** linker files, if it can't find them usin *** 7964,7975 **** using \s-1GCC\s0 also uses these directories when searching for ordinary libraries for the \fB\-l\fR option (but directories specified with \&\fB\-L\fR come first). ! .Ip "\fBC_INCLUDE_PATH\fR" 4 .IX Item "C_INCLUDE_PATH" .PD 0 ! .Ip "\fB\s-1CPLUS_INCLUDE_PATH\s0\fR" 4 .IX Item "CPLUS_INCLUDE_PATH" ! .Ip "\fB\s-1OBJC_INCLUDE_PATH\s0\fR" 4 .IX Item "OBJC_INCLUDE_PATH" .PD These environment variables pertain to particular languages. Each --- 8019,8030 ---- using \s-1GCC\s0 also uses these directories when searching for ordinary libraries for the \fB\-l\fR option (but directories specified with \&\fB\-L\fR come first). ! .IP "\fBC_INCLUDE_PATH\fR" 4 .IX Item "C_INCLUDE_PATH" .PD 0 ! .IP "\fB\s-1CPLUS_INCLUDE_PATH\s0\fR" 4 .IX Item "CPLUS_INCLUDE_PATH" ! .IP "\fB\s-1OBJC_INCLUDE_PATH\s0\fR" 4 .IX Item "OBJC_INCLUDE_PATH" .PD These environment variables pertain to particular languages. Each *************** variable's value is a colon-separated li *** 7978,7984 **** directories listed in the variable for the language you are using, after the directories specified with \fB\-I\fR but before the standard header file directories. ! .Ip "\fB\s-1DEPENDENCIES_OUTPUT\s0\fR" 4 .IX Item "DEPENDENCIES_OUTPUT" If this variable is set, its value specifies how to output dependencies for Make based on the header files processed by the compiler. This --- 8033,8039 ---- directories listed in the variable for the language you are using, after the directories specified with \fB\-I\fR but before the standard header file directories. ! .IP "\fB\s-1DEPENDENCIES_OUTPUT\s0\fR" 4 .IX Item "DEPENDENCIES_OUTPUT" If this variable is set, its value specifies how to output dependencies for Make based on the header files processed by the compiler. This *************** which case the Make rules are written to *** 7990,7996 **** name from the source file name. Or the value can have the form \&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to file \fIfile\fR using \fItarget\fR as the target name. ! .Ip "\fB\s-1LANG\s0\fR" 4 .IX Item "LANG" This variable is used to pass locale information to the compiler. One way in which this information is used is to determine the character set to be used --- 8045,8051 ---- name from the source file name. Or the value can have the form \&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to file \fIfile\fR using \fItarget\fR as the target name. ! .IP "\fB\s-1LANG\s0\fR" 4 .IX Item "LANG" This variable is used to pass locale information to the compiler. One way in which this information is used is to determine the character set to be used *************** when character literals, string literals *** 7998,8010 **** When the compiler is configured to allow multibyte characters, the following values for \fB\s-1LANG\s0\fR are recognized: .RS 4 ! .Ip "\fBC-JIS\fR" 4 .IX Item "C-JIS" Recognize \s-1JIS\s0 characters. ! .Ip "\fBC-SJIS\fR" 4 .IX Item "C-SJIS" Recognize \s-1SJIS\s0 characters. ! .Ip "\fBC-EUCJP\fR" 4 .IX Item "C-EUCJP" Recognize \s-1EUCJP\s0 characters. .RE --- 8053,8065 ---- When the compiler is configured to allow multibyte characters, the following values for \fB\s-1LANG\s0\fR are recognized: .RS 4 ! .IP "\fBC-JIS\fR" 4 .IX Item "C-JIS" Recognize \s-1JIS\s0 characters. ! .IP "\fBC-SJIS\fR" 4 .IX Item "C-SJIS" Recognize \s-1SJIS\s0 characters. ! .IP "\fBC-EUCJP\fR" 4 .IX Item "C-EUCJP" Recognize \s-1EUCJP\s0 characters. .RE *************** For instructions on reporting bugs, see *** 8021,8027 **** script to report bugs is recommended. .SH "FOOTNOTES" .IX Header "FOOTNOTES" ! .Ip "1." 4 On some systems, \fBgcc \-shared\fR needs to build supplementary stub code for constructors to work. On multi-libbed systems, \fBgcc \-shared\fR must select the correct support --- 8076,8082 ---- script to report bugs is recommended. .SH "FOOTNOTES" .IX Header "FOOTNOTES" ! .IP "1." 4 On some systems, \fBgcc \-shared\fR needs to build supplementary stub code for constructors to work. On multi-libbed systems, \fBgcc \-shared\fR must select the correct support diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info gcc-3.0.2/gcc/doc/gcc.info *** gcc-3.0.1/gcc/doc/gcc.info Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info Tue Oct 23 11:00:26 2001 *************** funds for GNU development. *** 38,80 ****  Indirect: gcc.info-1: 1239 ! gcc.info-2: 42119 ! gcc.info-3: 72711 ! gcc.info-4: 104892 ! gcc.info-5: 151185 ! gcc.info-6: 196528 ! gcc.info-7: 244085 ! gcc.info-8: 293130 ! gcc.info-9: 328359 ! gcc.info-10: 376749 ! gcc.info-11: 425179 ! gcc.info-12: 473554 ! gcc.info-13: 522836 ! gcc.info-14: 572322 ! gcc.info-15: 615541 ! gcc.info-16: 658935 ! gcc.info-17: 704531 ! gcc.info-18: 753534 ! gcc.info-19: 788268 ! gcc.info-20: 834234 ! gcc.info-21: 877530 ! gcc.info-22: 927462 ! gcc.info-23: 977431 ! gcc.info-24: 991062 ! gcc.info-25: 1035536 ! gcc.info-26: 1079932 ! gcc.info-27: 1113057 ! gcc.info-28: 1160438 ! gcc.info-29: 1207663 ! gcc.info-30: 1257340 ! gcc.info-31: 1300944 ! gcc.info-32: 1347226 ! gcc.info-33: 1396417 ! gcc.info-34: 1431110 ! gcc.info-35: 1479373 ! gcc.info-36: 1523784 ! gcc.info-37: 1540656 ! gcc.info-38: 1600898  Tag Table: (Indirect) --- 38,80 ----  Indirect: gcc.info-1: 1239 ! gcc.info-2: 42106 ! gcc.info-3: 72696 ! gcc.info-4: 104877 ! gcc.info-5: 151171 ! gcc.info-6: 196514 ! gcc.info-7: 244071 ! gcc.info-8: 292862 ! gcc.info-9: 328088 ! gcc.info-10: 376478 ! gcc.info-11: 424908 ! gcc.info-12: 473283 ! gcc.info-13: 522565 ! gcc.info-14: 572050 ! gcc.info-15: 615270 ! gcc.info-16: 658606 ! gcc.info-17: 698828 ! gcc.info-18: 747832 ! gcc.info-19: 782569 ! gcc.info-20: 828524 ! gcc.info-21: 871818 ! gcc.info-22: 921750 ! gcc.info-23: 971719 ! gcc.info-24: 985350 ! gcc.info-25: 1029817 ! gcc.info-26: 1074211 ! gcc.info-27: 1107334 ! gcc.info-28: 1154724 ! gcc.info-29: 1201943 ! gcc.info-30: 1251618 ! gcc.info-31: 1295221 ! gcc.info-32: 1341493 ! gcc.info-33: 1390685 ! gcc.info-34: 1425372 ! gcc.info-35: 1473633 ! gcc.info-36: 1518044 ! gcc.info-37: 1534916 ! gcc.info-38: 1595103  Tag Table: (Indirect) *************** Node: G++ and GCC3383 *** 83,392 **** Node: Standards5794 Node: Invoking GCC12244 Node: Option Summary15889 ! Node: Overall Options34553 ! Node: Invoking G++40673 ! Node: C Dialect Options42119 ! Node: C++ Dialect Options56342 ! Node: Objective-C Dialect Options69298 ! Node: Language Independent Options70921 ! Node: Warning Options72711 ! Node: Debugging Options104892 ! Node: Optimize Options126602 ! Node: Preprocessor Options151185 ! Node: Assembler Options161422 ! Node: Link Options161789 ! Ref: Link Options-Footnote-1169042 ! Node: Directory Options169378 ! Node: Spec Files173384 ! Node: Target Options190890 ! Node: Submodel Options194877 ! Node: M680x0 Options196528 ! Node: M68hc1x Options202535 ! Node: VAX Options203715 ! Node: SPARC Options204251 ! Node: Convex Options214135 ! Node: AMD29K Options216316 ! Node: ARM Options219712 ! Node: MN10200 Options232233 ! Node: MN10300 Options232755 ! Node: M32R/D Options233806 ! Node: M88K Options236155 ! Node: RS/6000 and PowerPC Options244085 ! Node: RT Options263517 ! Node: MIPS Options265220 ! Node: i386 Options275405 ! Node: HPPA Options286123 ! Node: Intel 960 Options290188 ! Node: DEC Alpha Options293130 ! Node: Clipper Options302524 ! Node: H8/300 Options302924 ! Node: SH Options303853 ! Node: System V Options306169 ! Node: TMS320C3x/C4x Options306987 ! Node: V850 Options312499 ! Node: ARC Options314508 ! Node: NS32K Options315709 ! Node: AVR Options319961 ! Node: MCore Options321672 ! Node: IA-64 Options322816 ! Node: D30V Options325204 ! Node: S/390 and zSeries Options326447 ! Node: Code Gen Options328359 ! Node: Environment Variables345189 ! Node: Running Protoize351527 ! Node: Installation357884 ! Node: Configuration Files361465 ! Node: Configurations363069 ! Node: Cross-Compiler367293 ! Node: Steps of Cross369052 ! Node: Configure Cross370170 ! Node: Tools and Libraries370807 ! Node: Cross Headers373246 ! Node: Build Cross375243 ! Node: VMS Install376749 ! Node: Collect2386682 ! Node: Header Dirs389247 ! Node: C Extensions390670 ! Node: Statement Exprs394492 ! Node: Local Labels397584 ! Node: Labels as Values399649 ! Ref: Labels as Values-Footnote-1401708 ! Node: Nested Functions401893 ! Node: Constructing Calls405732 ! Node: Naming Types407819 ! Node: Typeof408913 ! Node: Lvalues410789 ! Node: Conditionals413229 ! Node: Long Long414120 ! Node: Complex415619 ! Node: Hex Floats418287 ! Node: Zero Length419316 ! Node: Variable Length422417 ! Node: Variadic Macros425179 ! Node: Escaped Newlines427569 ! Node: Multi-line Strings428452 ! Node: Subscripting429056 ! Node: Pointer Arith429689 ! Node: Initializers430254 ! Node: Compound Literals430737 ! Node: Designated Inits432776 ! Node: Case Ranges436450 ! Node: Cast to Union437130 ! Node: Mixed Declarations438213 ! Node: Function Attributes438708 ! Node: Attribute Syntax460068 ! Node: Function Prototypes468879 ! Node: C++ Comments470675 ! Node: Dollar Signs471270 ! Node: Character Escapes471728 ! Node: Alignment472015 ! Node: Variable Attributes473554 ! Node: Type Attributes483187 ! Node: Inline492475 ! Node: Extended Asm497211 ! Node: Asm Labels513340 ! Node: Explicit Reg Vars515017 ! Node: Global Reg Vars516471 ! Node: Local Reg Vars521036 ! Node: Alternate Keywords522836 ! Node: Incomplete Enums524523 ! Node: Function Names525279 ! Node: Return Address527606 ! Node: Other Builtins529749 ! Node: C++ Extensions535820 ! Node: Min and Max537381 ! Node: Volatiles538787 ! Node: Restricted Pointers542157 ! Node: Vague Linkage543727 ! Node: C++ Interface547385 ! Ref: C++ Interface-Footnote-1552473 ! Node: Template Instantiation552612 ! Node: Bound member functions561442 ! Node: C++ Attributes562993 ! Node: Java Exceptions564597 ! Node: Deprecated Features566002 ! Node: Backwards Compatibility567766 ! Node: Objective C569114 ! Node: Executing code before main569684 ! Node: What you can and what you cannot do in +load572322 ! Node: Type encoding574488 ! Node: Garbage Collection577739 ! Node: Constant string objects580403 ! Node: compatibility_alias582037 ! Node: Gcov582916 ! Node: Gcov Intro583433 ! Node: Invoking Gcov586108 ! Node: Gcov and Optimization591846 ! Node: Gcov Data Files593263 ! Node: Trouble596828 ! Node: Actual Bugs598422 ! Node: Cross-Compiler Problems599330 ! Node: Interoperation600791 ! Node: External Bugs614049 ! Node: Incompatibilities615541 ! Node: Fixed Headers625149 ! Node: Standard Libraries627458 ! Node: Disappointments628828 ! Node: C++ Misunderstandings633366 ! Node: Static Definitions634092 ! Node: Temporaries635139 ! Node: Copy Assignment637116 ! Node: Protoize Caveats638934 ! Node: Non-bugs642889 ! Node: Warnings and Errors652781 ! Node: Bugs654541 ! Node: Bug Criteria655952 ! Node: Bug Lists658376 ! Node: Bug Reporting658935 ! Node: gccbug671022 ! Node: Sending Patches671866 ! Node: Service677232 ! Node: Contributing677978 ! Node: VMS678683 ! Node: Include Files and VMS679066 ! Node: Global Declarations682931 ! Node: VMS Misc687235 ! Node: Makefile691538 ! Node: Portability698197 ! Node: Interface699951 ! Node: Passes704531 ! Node: Trees727382 ! Node: Deficiencies730122 ! Node: Tree overview730352 ! Node: Macros and Functions734488 ! Node: Identifiers734622 ! Node: Containers736138 ! Node: Types737282 ! Node: Scopes749060 ! Node: Namespaces749816 ! Node: Classes753534 ! Node: Declarations758177 ! Node: Functions764231 ! Node: Function Basics766761 ! Node: Function Bodies773508 ! Node: Attributes786879 ! Node: Expression trees788268 ! Node: RTL810728 ! Node: RTL Objects812759 ! Node: RTL Classes815792 ! Node: Accessors820298 ! Node: Flags822678 ! Node: Machine Modes834234 ! Node: Constants842018 ! Node: Regs and Memory847199 ! Node: Arithmetic859839 ! Node: Comparisons866100 ! Node: Bit-Fields870222 ! Node: Vector Operations871640 ! Node: Conversions873414 ! Node: RTL Declarations876721 ! Node: Side Effects877530 ! Node: Incdec892380 ! Node: Assembler895933 ! Node: Insns897455 ! Node: Calls921903 ! Node: Sharing924497 ! Node: Reading RTL927462 ! Node: Machine Desc928405 ! Node: Overview930609 ! Node: Patterns932648 ! Node: Example935884 ! Node: RTL Template937012 ! Node: Output Template949477 ! Node: Output Statement953459 ! Node: Constraints957171 ! Node: Simple Constraints958102 ! Node: Multi-Alternative970058 ! Node: Class Preferences972893 ! Node: Modifiers973773 ! Node: Machine Constraints977431 ! Node: Standard Names991062 ! Node: Pattern Ordering1031494 ! Node: Dependent Patterns1032721 ! Node: Jump Patterns1035536 ! Node: Looping Patterns1041283 ! Node: Insn Canonicalizations1045876 ! Node: Expander Definitions1049374 ! Node: Insn Splitting1057506 ! Node: Peephole Definitions1066158 ! Node: define_peephole1067401 ! Node: define_peephole21073776 ! Node: Insn Attributes1076837 ! Node: Defining Attributes1077920 ! Node: Expressions1079932 ! Node: Tagging Insns1086523 ! Node: Attr Example1090885 ! Node: Insn Lengths1093261 ! Node: Constant Attributes1096554 ! Node: Delay Slots1097714 ! Node: Function Units1100925 ! Node: Conditional Execution1106595 ! Node: Constant Definitions1109451 ! Node: Target Macros1111029 ! Node: Driver1113057 ! Node: Run-time Target1131493 ! Node: Per-Function Data1138524 ! Node: Storage Layout1141774 ! Node: Type Layout1160438 ! Node: Registers1170284 ! Node: Register Basics1171199 ! Node: Allocation Order1176400 ! Node: Values in Registers1177813 ! Node: Leaf Functions1182930 ! Node: Stack Registers1185695 ! Node: Register Classes1186492 ! Node: Stack and Calling1207178 ! Node: Frame Layout1207663 ! Node: Stack Checking1217433 ! Node: Frame Registers1220965 ! Node: Elimination1225379 ! Node: Stack Arguments1229635 ! Node: Register Arguments1236608 ! Node: Scalar Return1247851 ! Node: Aggregate Return1252089 ! Node: Caller Saves1255803 ! Node: Function Entry1257340 ! Node: Profiling1268261 ! Node: Inlining1276499 ! Node: Tail Calling1277052 ! Node: Varargs1277641 ! Node: Trampolines1285316 ! Node: Library Calls1292521 ! Node: Addressing Modes1300944 ! Node: Condition Code1312221 ! Node: Costs1319078 ! Node: Sections1331998 ! Node: PIC1339314 ! Node: Assembler Format1342023 ! Node: File Framework1343090 ! Node: Data Output1347226 ! Node: Uninitialized Data1355001 ! Node: Label Output1360398 ! Node: Initialization1373569 ! Node: Macros for Initialization1379709 ! Node: Instruction Output1384966 ! Node: Dispatch Tables1393865 ! Node: Exception Region Output1396417 ! Node: Alignment Output1399916 ! Node: Debugging Info1403473 ! Node: All Debuggers1404082 ! Node: DBX Options1406891 ! Node: DBX Hooks1412263 ! Node: File Names and DBX1415909 ! Node: SDB and DWARF1417882 ! Node: Cross-compilation1421291 ! Node: Mode Switching1427867 ! Node: Misc1431110 ! Node: Config1463080 ! Node: Fragments1470764 ! Node: Target Fragment1471359 ! Node: Host Fragment1476272 ! Node: Funding1476874 ! Node: GNU/Linux1479373 ! Node: Copying1484688 ! Node: GNU Free Documentation License1503899 ! Node: Contributors1523784 ! Node: Option Index1540656 ! Node: Index1600898  End Tag Table --- 83,391 ---- Node: Standards5794 Node: Invoking GCC12244 Node: Option Summary15889 ! Node: Overall Options34540 ! Node: Invoking G++40660 ! Node: C Dialect Options42106 ! Node: C++ Dialect Options56329 ! Node: Objective-C Dialect Options69285 ! Node: Language Independent Options70908 ! Node: Warning Options72696 ! Node: Debugging Options104877 ! Node: Optimize Options126587 ! Node: Preprocessor Options151171 ! Node: Assembler Options161408 ! Node: Link Options161775 ! Ref: Link Options-Footnote-1169028 ! Node: Directory Options169364 ! Node: Spec Files173370 ! Node: Target Options190876 ! Node: Submodel Options194863 ! Node: M680x0 Options196514 ! Node: M68hc1x Options202521 ! Node: VAX Options203701 ! Node: SPARC Options204237 ! Node: Convex Options214121 ! Node: AMD29K Options216302 ! Node: ARM Options219698 ! Node: MN10200 Options232219 ! Node: MN10300 Options232741 ! Node: M32R/D Options233792 ! Node: M88K Options236141 ! Node: RS/6000 and PowerPC Options244071 ! Node: RT Options263503 ! Node: MIPS Options265206 ! Node: i386 Options275391 ! Node: HPPA Options285855 ! Node: Intel 960 Options289920 ! Node: DEC Alpha Options292862 ! Node: Clipper Options302256 ! Node: H8/300 Options302656 ! Node: SH Options303585 ! Node: System V Options305901 ! Node: TMS320C3x/C4x Options306719 ! Node: V850 Options312231 ! Node: ARC Options314240 ! Node: NS32K Options315441 ! Node: AVR Options319690 ! Node: MCore Options321401 ! Node: IA-64 Options322545 ! Node: D30V Options324933 ! Node: S/390 and zSeries Options326176 ! Node: Code Gen Options328088 ! Node: Environment Variables344918 ! Node: Running Protoize351256 ! Node: Installation357613 ! Node: Configuration Files361194 ! Node: Configurations362798 ! Node: Cross-Compiler367022 ! Node: Steps of Cross368781 ! Node: Configure Cross369899 ! Node: Tools and Libraries370536 ! Node: Cross Headers372975 ! Node: Build Cross374972 ! Node: VMS Install376478 ! Node: Collect2386411 ! Node: Header Dirs388976 ! Node: C Extensions390399 ! Node: Statement Exprs394221 ! Node: Local Labels397313 ! Node: Labels as Values399378 ! Ref: Labels as Values-Footnote-1401437 ! Node: Nested Functions401622 ! Node: Constructing Calls405461 ! Node: Naming Types407548 ! Node: Typeof408642 ! Node: Lvalues410518 ! Node: Conditionals412958 ! Node: Long Long413849 ! Node: Complex415348 ! Node: Hex Floats418016 ! Node: Zero Length419045 ! Node: Variable Length422146 ! Node: Variadic Macros424908 ! Node: Escaped Newlines427298 ! Node: Multi-line Strings428181 ! Node: Subscripting428785 ! Node: Pointer Arith429418 ! Node: Initializers429983 ! Node: Compound Literals430466 ! Node: Designated Inits432505 ! Node: Case Ranges436179 ! Node: Cast to Union436859 ! Node: Mixed Declarations437942 ! Node: Function Attributes438437 ! Node: Attribute Syntax459797 ! Node: Function Prototypes468608 ! Node: C++ Comments470404 ! Node: Dollar Signs470999 ! Node: Character Escapes471457 ! Node: Alignment471744 ! Node: Variable Attributes473283 ! Node: Type Attributes482916 ! Node: Inline492204 ! Node: Extended Asm496940 ! Node: Asm Labels513069 ! Node: Explicit Reg Vars514746 ! Node: Global Reg Vars516200 ! Node: Local Reg Vars520765 ! Node: Alternate Keywords522565 ! Node: Incomplete Enums524252 ! Node: Function Names525008 ! Node: Return Address527335 ! Node: Other Builtins529477 ! Node: C++ Extensions535548 ! Node: Min and Max537109 ! Node: Volatiles538515 ! Node: Restricted Pointers541885 ! Node: Vague Linkage543455 ! Node: C++ Interface547113 ! Ref: C++ Interface-Footnote-1552201 ! Node: Template Instantiation552340 ! Node: Bound member functions561170 ! Node: C++ Attributes562721 ! Node: Java Exceptions564325 ! Node: Deprecated Features565730 ! Node: Backwards Compatibility567494 ! Node: Objective C568842 ! Node: Executing code before main569412 ! Node: What you can and what you cannot do in +load572050 ! Node: Type encoding574216 ! Node: Garbage Collection577468 ! Node: Constant string objects580132 ! Node: compatibility_alias581766 ! Node: Gcov582645 ! Node: Gcov Intro583162 ! Node: Invoking Gcov585837 ! Node: Gcov and Optimization591575 ! Node: Gcov Data Files592992 ! Node: Trouble596557 ! Node: Actual Bugs598151 ! Node: Cross-Compiler Problems599059 ! Node: Interoperation600520 ! Node: External Bugs613778 ! Node: Incompatibilities615270 ! Node: Fixed Headers624878 ! Node: Standard Libraries627187 ! Node: Disappointments628557 ! Node: C++ Misunderstandings633095 ! Node: Static Definitions633821 ! Node: Temporaries634868 ! Node: Copy Assignment636845 ! Node: Protoize Caveats638663 ! Node: Non-bugs642618 ! Node: Warnings and Errors652510 ! Node: Bugs654270 ! Node: Bug Criteria655623 ! Node: Bug Lists658047 ! Node: Bug Reporting658606 ! Node: gccbug670709 ! Node: Service671529 ! Node: Contributing672275 ! Node: VMS672980 ! Node: Include Files and VMS673363 ! Node: Global Declarations677228 ! Node: VMS Misc681532 ! Node: Makefile685835 ! Node: Portability692494 ! Node: Interface694248 ! Node: Passes698828 ! Node: Trees721679 ! Node: Deficiencies724419 ! Node: Tree overview724649 ! Node: Macros and Functions728784 ! Node: Identifiers728918 ! Node: Containers730434 ! Node: Types731578 ! Node: Scopes743358 ! Node: Namespaces744114 ! Node: Classes747832 ! Node: Declarations752475 ! Node: Functions758529 ! Node: Function Basics761059 ! Node: Function Bodies767805 ! Node: Attributes781180 ! Node: Expression trees782569 ! Node: RTL805018 ! Node: RTL Objects807049 ! Node: RTL Classes810082 ! Node: Accessors814588 ! Node: Flags816968 ! Node: Machine Modes828524 ! Node: Constants836308 ! Node: Regs and Memory841489 ! Node: Arithmetic854129 ! Node: Comparisons860390 ! Node: Bit-Fields864510 ! Node: Vector Operations865928 ! Node: Conversions867702 ! Node: RTL Declarations871009 ! Node: Side Effects871818 ! Node: Incdec886668 ! Node: Assembler890221 ! Node: Insns891743 ! Node: Calls916191 ! Node: Sharing918785 ! Node: Reading RTL921750 ! Node: Machine Desc922693 ! Node: Overview924897 ! Node: Patterns926936 ! Node: Example930172 ! Node: RTL Template931300 ! Node: Output Template943765 ! Node: Output Statement947747 ! Node: Constraints951459 ! Node: Simple Constraints952390 ! Node: Multi-Alternative964346 ! Node: Class Preferences967181 ! Node: Modifiers968061 ! Node: Machine Constraints971719 ! Node: Standard Names985350 ! Node: Pattern Ordering1025775 ! Node: Dependent Patterns1027002 ! Node: Jump Patterns1029817 ! Node: Looping Patterns1035564 ! Node: Insn Canonicalizations1040157 ! Node: Expander Definitions1043655 ! Node: Insn Splitting1051787 ! Node: Peephole Definitions1060437 ! Node: define_peephole1061680 ! Node: define_peephole21068055 ! Node: Insn Attributes1071116 ! Node: Defining Attributes1072199 ! Node: Expressions1074211 ! Node: Tagging Insns1080800 ! Node: Attr Example1085162 ! Node: Insn Lengths1087538 ! Node: Constant Attributes1090831 ! Node: Delay Slots1091991 ! Node: Function Units1095202 ! Node: Conditional Execution1100872 ! Node: Constant Definitions1103728 ! Node: Target Macros1105306 ! Node: Driver1107334 ! Node: Run-time Target1125769 ! Node: Per-Function Data1132799 ! Node: Storage Layout1136060 ! Node: Type Layout1154724 ! Node: Registers1164570 ! Node: Register Basics1165485 ! Node: Allocation Order1170685 ! Node: Values in Registers1172098 ! Node: Leaf Functions1177215 ! Node: Stack Registers1179980 ! Node: Register Classes1180777 ! Node: Stack and Calling1201458 ! Node: Frame Layout1201943 ! Node: Stack Checking1211713 ! Node: Frame Registers1215245 ! Node: Elimination1219659 ! Node: Stack Arguments1223914 ! Node: Register Arguments1230887 ! Node: Scalar Return1242129 ! Node: Aggregate Return1246367 ! Node: Caller Saves1250081 ! Node: Function Entry1251618 ! Node: Profiling1262539 ! Node: Inlining1270777 ! Node: Tail Calling1271329 ! Node: Varargs1271918 ! Node: Trampolines1279593 ! Node: Library Calls1286798 ! Node: Addressing Modes1295221 ! Node: Condition Code1306495 ! Node: Costs1313352 ! Node: Sections1326266 ! Node: PIC1333581 ! Node: Assembler Format1336290 ! Node: File Framework1337357 ! Node: Data Output1341493 ! Node: Uninitialized Data1349267 ! Node: Label Output1354664 ! Node: Initialization1367837 ! Node: Macros for Initialization1373977 ! Node: Instruction Output1379234 ! Node: Dispatch Tables1388133 ! Node: Exception Region Output1390685 ! Node: Alignment Output1394184 ! Node: Debugging Info1397741 ! Node: All Debuggers1398350 ! Node: DBX Options1401159 ! Node: DBX Hooks1406531 ! Node: File Names and DBX1410177 ! Node: SDB and DWARF1412150 ! Node: Cross-compilation1415559 ! Node: Mode Switching1422135 ! Node: Misc1425372 ! Node: Config1457340 ! Node: Fragments1465024 ! Node: Target Fragment1465619 ! Node: Host Fragment1470532 ! Node: Funding1471134 ! Node: GNU/Linux1473633 ! Node: Copying1478948 ! Node: GNU Free Documentation License1498159 ! Node: Contributors1518044 ! Node: Option Index1534916 ! Node: Index1595103  End Tag Table diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-1 gcc-3.0.2/gcc/doc/gcc.info-1 *** gcc-3.0.1/gcc/doc/gcc.info-1 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-1 Tue Oct 23 11:00:26 2001 *************** _C++ Language Options_ *** 365,371 **** -fno-nonansi-builtins -fno-operator-names -fno-optional-diags -fpermissive -frepo -fno-rtti -fstats -ftemplate-depth-N ! -fuse-cxa-atexit -fvtable-gc -fno-weak -nostdinc++ -fno-default-inline -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder -Weffc++ -Wno-deprecated --- 365,371 ---- -fno-nonansi-builtins -fno-operator-names -fno-optional-diags -fpermissive -frepo -fno-rtti -fstats -ftemplate-depth-N ! -fuse-cxa-atexit -fno-weak -nostdinc++ -fno-default-inline -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder -Weffc++ -Wno-deprecated diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-13 gcc-3.0.2/gcc/doc/gcc.info-13 *** gcc-3.0.1/gcc/doc/gcc.info-13 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-13 Tue Oct 23 11:00:26 2001 *************** function. *** 186,192 **** or when the top of the stack has been reached, this function will return `0'. ! This function should only be used with a non-zero argument for debugging purposes. - Built-in Function: void * __builtin_frame_address (unsigned int --- 186,192 ---- or when the top of the stack has been reached, this function will return `0'. ! This function should only be used with a nonzero argument for debugging purposes. - Built-in Function: void * __builtin_frame_address (unsigned int diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-14 gcc-3.0.2/gcc/doc/gcc.info-14 *** gcc-3.0.1/gcc/doc/gcc.info-14 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-14 Tue Oct 23 11:00:26 2001 *************** unions `(' followed by the name *** 150,156 **** followed by `)' Here are some types and their encodings, as they are generated by the ! compiler on a i386 machine: Objective-C type Compiler encoding --- 150,156 ---- followed by `)' Here are some types and their encodings, as they are generated by the ! compiler on an i386 machine: Objective-C type Compiler encoding diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-15 gcc-3.0.2/gcc/doc/gcc.info-15 *** gcc-3.0.1/gcc/doc/gcc.info-15 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-15 Tue Oct 23 11:00:26 2001 *************** information that makes for fixing the bu *** 942,948 **** * Where: Bug Lists. Where to send your bug report. * Reporting: Bug Reporting. How to report a bug effectively. * GNATS: gccbug. You can use a bug reporting tool. - * Patches: Sending Patches. How to send a patch for GCC. * Known: Trouble. Known problems. * Help: Service. Where to ask for help. --- 942,947 ---- diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-16 gcc-3.0.2/gcc/doc/gcc.info-16 *** gcc-3.0.1/gcc/doc/gcc.info-16 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-16 Tue Oct 23 11:00:26 2001 *************** these things: *** 271,278 **** your patch should be an improvement, we won't install it. A test case will help us to understand. ! *Note Sending Patches::, for guidelines on how to make it easy for ! us to understand and install your patches. * A guess about what the bug is or what it depends on. --- 271,278 ---- your patch should be an improvement, we won't install it. A test case will help us to understand. ! See `http://gcc.gnu.org/contribute.html' for guidelines on how to ! make it easy for us to understand and install your patches. * A guess about what the bug is or what it depends on. *************** these things: *** 286,292 **** should be able to reproduce the crash ourselves.  ! File: gcc.info, Node: gccbug, Next: Sending Patches, Prev: Bug Reporting, Up: Bugs The gccbug script ================= --- 286,292 ---- should be able to reproduce the crash ourselves.  ! File: gcc.info, Node: gccbug, Prev: Bug Reporting, Up: Bugs The gccbug script ================= *************** reporting address. *** 305,425 **** A number of fields in this bug report form are specific to GCC, and are explained at `http://gcc.gnu.org/gnats.html'. - -  - File: gcc.info, Node: Sending Patches, Prev: gccbug, Up: Bugs - - Sending Patches for GCC - ======================= - - If you would like to write bug fixes or improvements for the GNU C - compiler, that is very helpful. Send suggested fixes to the patches - mailing list, . - - Please follow these guidelines so we can study your patches - efficiently. If you don't follow these guidelines, your information - might still be useful, but using it will take extra work. Maintaining - GCC is a lot of work in the best of circumstances, and we can't keep up - unless you do your best to help. - - * Send an explanation with your changes of what problem they fix or - what improvement they bring about. For a bug fix, just include a - copy of the bug report, and explain why the change fixes the bug. - - (Referring to a bug report is not as good as including it, because - then we will have to look it up, and we have probably already - deleted it if we've already fixed the bug.) - - * Always include a proper bug report for the problem you think you - have fixed. We need to convince ourselves that the change is - right before installing it. Even if it is right, we might have - trouble judging it if we don't have a way to reproduce the problem. - - * Include all the comments that are appropriate to help people - reading the source in the future understand why this change was - needed. - - * Don't mix together changes made for different reasons. Send them - _individually_. - - If you make two changes for separate reasons, then we might not - want to install them both. We might want to install just one. If - you send them all jumbled together in a single set of diffs, we - have to do extra work to disentangle them--to figure out which - parts of the change serve which purpose. If we don't have time - for this, we might have to ignore your changes entirely. - - If you send each change as soon as you have written it, with its - own explanation, then the two changes never get tangled up, and we - can consider each one properly without any extra work to - disentangle them. - - Ideally, each change you send should be impossible to subdivide - into parts that we might want to consider separately, because each - of its parts gets its motivation from the other parts. - - * Send each change as soon as that change is finished. Sometimes - people think they are helping us by accumulating many changes to - send them all together. As explained above, this is absolutely - the worst thing you could do. - - Since you should send each change separately, you might as well - send it right away. That gives us the option of installing it - immediately if it is important. - - * Use `diff -c' to make your diffs. Diffs without context are hard - for us to install reliably. More than that, they make it hard for - us to study the diffs to decide whether we want to install them. - Unidiff format is better than contextless diffs, but not as easy - to read as `-c' format. - - If you have GNU diff, use `diff -cp', which shows the name of the - function that each change occurs in. - - * Write the change log entries for your changes. We get lots of - changes, and we don't have time to do all the change log writing - ourselves. - - Read the `ChangeLog' file to see what sorts of information to put - in, and to learn the style that we use. The purpose of the change - log is to show people where to find what was changed. So you need - to be specific about what functions you changed; in large - functions, it's often helpful to indicate where within the - function the change was. - - On the other hand, once you have shown people where to find the - change, you need not explain its purpose. Thus, if you add a new - function, all you need to say about it is that it is new. If you - feel that the purpose needs explaining, it probably does--but the - explanation will be much more useful if you put it in comments in - the code. - - If you would like your name to appear in the header line for who - made the change, send us the header line. - - * When you write the fix, keep in mind that we can't install a - change that would break other systems. - - People often suggest fixing a problem by changing - machine-independent files such as `toplev.c' to do something - special that a particular system needs. Sometimes it is totally - obvious that such changes would break GCC for almost all users. - We can't possibly make a change like that. At best it might tell - us how to write another patch that would solve the problem - acceptably. - - Sometimes people send fixes that _might_ be an improvement in - general--but it is hard to be sure of this. It's hard to install - such changes because we have to study them very carefully. Of - course, a good explanation of the reasoning by which you concluded - the change was correct can help convince us. - - The safest changes are changes to the configuration files for a - particular machine. These are safe because they can't create new - bugs on other machines. - - Please help us keep up with the workload by designing the patch in - a form that is good to install.  File: gcc.info, Node: Service, Next: Contributing, Prev: Bugs, Up: Top --- 305,310 ---- diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-17 gcc-3.0.2/gcc/doc/gcc.info-17 *** gcc-3.0.1/gcc/doc/gcc.info-17 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-17 Tue Oct 23 11:00:26 2001 *************** requested with `-d' options. *** 88,94 **** the tree representation. C Preprocessing, for language front ends, that want or require it, ! is performed by cpplib, which is covered in seperate documentation. In particular, the internals are covered in *Note Cpplib internals: (cppinternals)Top. --- 88,94 ---- the tree representation. C Preprocessing, for language front ends, that want or require it, ! is performed by cpplib, which is covered in separate documentation. In particular, the internals are covered in *Note Cpplib internals: (cppinternals)Top. *************** and *** 593,599 **** are legal. Macros that return `int' values now may be changed to return `tree' values, or other pointers in the future. Even those that ! continue to return `int' may return multiple non-zero codes where previously they returned only zero and one. Therefore, you should not write code like if (TEST_P (t) == 1) --- 593,599 ---- are legal. Macros that return `int' values now may be changed to return `tree' values, or other pointers in the future. Even those that ! continue to return `int' may return multiple nonzero codes where previously they returned only zero and one. Therefore, you should not write code like if (TEST_P (t) == 1) *************** will encounter while examining the inter *** 908,914 **** Note that in C (but not in C++) a function declared like `void f()' is an unprototyped function taking a variable number of arguments; ! the `TYPE_ARG_TYPES' of such a function will be NULL. `METHOD_TYPE' Used to represent the type of a non-static member function. Like a --- 908,914 ---- Note that in C (but not in C++) a function declared like `void f()' is an unprototyped function taking a variable number of arguments; ! the `TYPE_ARG_TYPES' of such a function will be `NULL'. `METHOD_TYPE' Used to represent the type of a non-static member function. Like a diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-18 gcc-3.0.2/gcc/doc/gcc.info-18 *** gcc-3.0.1/gcc/doc/gcc.info-18 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-18 Tue Oct 23 11:00:26 2001 *************** Function Basics *** 465,471 **** always the `this' pointer; the thunk should add `THUNK_DELTA' to this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.) ! Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is non-zero the adjusted `this' pointer must be adjusted again. The complete calculation is given by the following pseudo-code: --- 465,471 ---- always the `this' pointer; the thunk should add `THUNK_DELTA' to this value. (The `THUNK_DELTA' is an `int', not an `INTEGER_CST'.) ! Then, if `THUNK_VCALL_OFFSET' (an `INTEGER_CST') is nonzero the adjusted `this' pointer must be adjusted again. The complete calculation is given by the following pseudo-code: *************** Function Bodies *** 528,535 **** --------------- A function that has a definition in the current translation unit will ! have a non-NULL `DECL_INITIAL'. However, back ends should not make use ! of the particular value given by `DECL_INITIAL'. The `DECL_SAVED_TREE' macro will give the complete body of the function. This node will usually be a `COMPOUND_STMT' representing the --- 528,535 ---- --------------- A function that has a definition in the current translation unit will ! have a non-`NULL' `DECL_INITIAL'. However, back ends should not make ! use of the particular value given by `DECL_INITIAL'. The `DECL_SAVED_TREE' macro will give the complete body of the function. This node will usually be a `COMPOUND_STMT' representing the *************** several statements chained together. *** 631,638 **** `CASE_LABEL' Use to represent a `case' label, range of `case' labels, or a ! `default' label. If `CASE_LOW' is NULL_TREE, then this is a a ! `default' label. Otherwise, if `CASE_HIGH' is NULL_TREE, then this is an ordinary `case' label. In this case, `CASE_LOW' is an expression giving the value of the label. Both `CASE_LOW' and `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the --- 631,638 ---- `CASE_LABEL' Use to represent a `case' label, range of `case' labels, or a ! `default' label. If `CASE_LOW' is `NULL_TREE', then this is a ! `default' label. Otherwise, if `CASE_HIGH' is `NULL_TREE', then this is an ordinary `case' label. In this case, `CASE_LOW' is an expression giving the value of the label. Both `CASE_LOW' and `CASE_HIGH' are `INTEGER_CST' nodes. These values will have the diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-19 gcc-3.0.2/gcc/doc/gcc.info-19 *** gcc-3.0.1/gcc/doc/gcc.info-19 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-19 Tue Oct 23 11:00:26 2001 *************** kinds of expressions: *** 94,100 **** constant. In general, the expression given above will overflow, so it should not be used to calculate the value of the constant. ! The variable `integer_zero_node' is a integer constant with value zero. Similarly, `integer_one_node' is an integer constant with value one. The `size_zero_node' and `size_one_node' variables are analogous, but have type `size_t' rather than `int'. --- 94,100 ---- constant. In general, the expression given above will overflow, so it should not be used to calculate the value of the constant. ! The variable `integer_zero_node' is an integer constant with value zero. Similarly, `integer_one_node' is an integer constant with value one. The `size_zero_node' and `size_one_node' variables are analogous, but have type `size_t' rather than `int'. *************** kinds of expressions: *** 147,154 **** `UNION_TYPE' within which the pointer points), and the `PTRMEM_CST_MEMBER' is the declaration for the pointed to object. Note that the `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is in ! general different from from the `PTRMEM_CST_CLASS'. For example, ! given: struct B { int i; }; struct D : public B {}; int D::*dp = &D::i; --- 147,153 ---- `UNION_TYPE' within which the pointer points), and the `PTRMEM_CST_MEMBER' is the declaration for the pointed to object. Note that the `DECL_CONTEXT' for the `PTRMEM_CST_MEMBER' is in ! general different from the `PTRMEM_CST_CLASS'. For example, given: struct B { int i; }; struct D : public B {}; int D::*dp = &D::i; *************** kinds of expressions: *** 371,379 **** `COND_EXPR' These nodes represent `?:' expressions. The first operand is of ! boolean or integral type. If it evaluates to a non-zero value, ! the second operand should be evaluated, and returned as the value ! of the expression. Otherwise, the third operand is evaluated, and returned as the value of the expression. As a GNU extension, the middle operand of the `?:' operator may be omitted in the source, like this: --- 370,378 ---- `COND_EXPR' These nodes represent `?:' expressions. The first operand is of ! boolean or integral type. If it evaluates to a nonzero value, the ! second operand should be evaluated, and returned as the value of ! the expression. Otherwise, the third operand is evaluated, and returned as the value of the expression. As a GNU extension, the middle operand of the `?:' operator may be omitted in the source, like this: *************** kinds of expressions: *** 439,445 **** `EXIT_EXPR' These nodes represent conditional exits from the nearest enclosing `LOOP_EXPR'. The single operand is the condition; if it is ! non-zero, then the loop should be exited. An `EXIT_EXPR' will only appear within a `LOOP_EXPR'. `CLEANUP_POINT_EXPR' --- 438,444 ---- `EXIT_EXPR' These nodes represent conditional exits from the nearest enclosing `LOOP_EXPR'. The single operand is the condition; if it is ! nonzero, then the loop should be exited. An `EXIT_EXPR' will only appear within a `LOOP_EXPR'. `CLEANUP_POINT_EXPR' diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-2 gcc-3.0.2/gcc/doc/gcc.info-2 *** gcc-3.0.1/gcc/doc/gcc.info-2 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-2 Tue Oct 23 11:00:26 2001 *************** correctly. *** 731,736 **** `-fdiagnostics-show-location=every-line' Only meaningful in line-wrapping mode. Instructs the diagnostic messages reporter to emit the same source location information (as ! prefix) for physical lines that result from the process of ! breaking a a message which is too long to fit on a single line. --- 731,736 ---- `-fdiagnostics-show-location=every-line' Only meaningful in line-wrapping mode. Instructs the diagnostic messages reporter to emit the same source location information (as ! prefix) for physical lines that result from the process of breaking ! a message which is too long to fit on a single line. diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-20 gcc-3.0.2/gcc/doc/gcc.info-20 *** gcc-3.0.1/gcc/doc/gcc.info-20 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-20 Tue Oct 23 11:00:26 2001 *************** the operands. *** 876,883 **** `(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' Similar to `if_then_else', but more general. Each of TEST1, TEST2, ... is performed in turn. The result of this expression is ! the VALUE corresponding to the first non-zero test, or DEFAULT if ! none of the tests are non-zero expressions. This is currently not valid for instruction patterns and is supported only for insn attributes. *Note Insn Attributes::. --- 876,883 ---- `(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)' Similar to `if_then_else', but more general. Each of TEST1, TEST2, ... is performed in turn. The result of this expression is ! the VALUE corresponding to the first nonzero test, or DEFAULT if ! none of the tests are nonzero expressions. This is currently not valid for instruction patterns and is supported only for insn attributes. *Note Insn Attributes::. diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-24 gcc-3.0.2/gcc/doc/gcc.info-24 *** gcc-3.0.1/gcc/doc/gcc.info-24 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-24 Tue Oct 23 11:00:26 2001 *************** pattern to accomplish a certain task. *** 511,521 **** `call_pop', `call_value_pop' Similar to `call' and `call_value', except used if defined and if ! `RETURN_POPS_ARGS' is non-zero. They should emit a `parallel' ! that contains both the function call and a `set' to indicate the adjustment made to the frame pointer. ! For machines where `RETURN_POPS_ARGS' can be non-zero, the use of these patterns increases the number of functions for which the frame pointer can be eliminated, if desired. --- 511,521 ---- `call_pop', `call_value_pop' Similar to `call' and `call_value', except used if defined and if ! `RETURN_POPS_ARGS' is nonzero. They should emit a `parallel' that ! contains both the function call and a `set' to indicate the adjustment made to the frame pointer. ! For machines where `RETURN_POPS_ARGS' can be nonzero, the use of these patterns increases the number of functions for which the frame pointer can be eliminated, if desired. *************** pattern to accomplish a certain task. *** 548,554 **** allocate stack space. For such machines, the condition specified in this pattern should ! only be true when `reload_completed' is non-zero and the function's epilogue would only be a single instruction. For machines with register windows, the routine `leaf_function_p' may be used to determine if a register window push is required. --- 548,554 ---- allocate stack space. For such machines, the condition specified in this pattern should ! only be true when `reload_completed' is nonzero and the function's epilogue would only be a single instruction. For machines with register windows, the routine `leaf_function_p' may be used to determine if a register window push is required. *************** pattern to accomplish a certain task. *** 634,642 **** `decrement_and_branch_until_zero' Conditional branch instruction that decrements a register and ! jumps if the register is non-zero. Operand 0 is the register to decrement and test; operand 1 is the label to jump to if the ! register is non-zero. *Note Looping Patterns::. This optional instruction pattern is only used by the combiner, typically for loops reversed by the loop optimizer when strength --- 634,642 ---- `decrement_and_branch_until_zero' Conditional branch instruction that decrements a register and ! jumps if the register is nonzero. Operand 0 is the register to decrement and test; operand 1 is the label to jump to if the ! register is nonzero. *Note Looping Patterns::. This optional instruction pattern is only used by the combiner, typically for loops reversed by the loop optimizer when strength *************** pattern to accomplish a certain task. *** 644,657 **** `doloop_end' Conditional branch instruction that decrements a register and ! jumps if the register is non-zero. This instruction takes five operands: Operand 0 is the register to decrement and test; operand 1 is the number of loop iterations as a `const_int' or `const0_rtx' if this cannot be determined until run-time; operand 2 is the actual or estimated maximum number of iterations as a `const_int'; operand 3 is the number of enclosed loops as a `const_int' (an innermost loop has a value of 1); operand 4 is the ! label to jump to if the register is non-zero. *Note Looping Patterns::. This optional instruction pattern should be defined for machines --- 644,657 ---- `doloop_end' Conditional branch instruction that decrements a register and ! jumps if the register is nonzero. This instruction takes five operands: Operand 0 is the register to decrement and test; operand 1 is the number of loop iterations as a `const_int' or `const0_rtx' if this cannot be determined until run-time; operand 2 is the actual or estimated maximum number of iterations as a `const_int'; operand 3 is the number of enclosed loops as a `const_int' (an innermost loop has a value of 1); operand 4 is the ! label to jump to if the register is nonzero. *Note Looping Patterns::. This optional instruction pattern should be defined for machines diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-25 gcc-3.0.2/gcc/doc/gcc.info-25 *** gcc-3.0.1/gcc/doc/gcc.info-25 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-25 Tue Oct 23 11:00:26 2001 *************** allocate any space in the stack frame. *** 570,579 **** circumstances. If an insn needs to be split for delay slot scheduling or insn scheduling, the insn is already known to be valid, which means that it must have been matched by some `define_insn' and, if ! `reload_completed' is non-zero, is known to satisfy the constraints of that `define_insn'. In that case, the new insn patterns must also be insns that are matched by some `define_insn' and, if `reload_completed' ! is non-zero, must also satisfy the constraints of those definitions. As an example of this usage of `define_split', consider the following example from `a29k.md', which splits a `sign_extend' from `HImode' to --- 570,579 ---- circumstances. If an insn needs to be split for delay slot scheduling or insn scheduling, the insn is already known to be valid, which means that it must have been matched by some `define_insn' and, if ! `reload_completed' is nonzero, is known to satisfy the constraints of that `define_insn'. In that case, the new insn patterns must also be insns that are matched by some `define_insn' and, if `reload_completed' ! is nonzero, must also satisfy the constraints of those definitions. As an example of this usage of `define_split', consider the following example from `a29k.md', which splits a `sign_extend' from `HImode' to diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-26 gcc-3.0.2/gcc/doc/gcc.info-26 *** gcc-3.0.1/gcc/doc/gcc.info-26 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-26 Tue Oct 23 11:00:26 2001 *************** forms: *** 84,90 **** TEST expressions can have one of the following forms: `(const_int I)' ! This test is true if I is non-zero and false otherwise. `(not TEST)' `(ior TEST1 TEST2)' --- 84,90 ---- TEST expressions can have one of the following forms: `(const_int I)' ! This test is true if I is nonzero and false otherwise. `(not TEST)' `(ior TEST1 TEST2)' *************** forms: *** 95,101 **** This test is true if operand N of the insn whose attribute value is being determined has mode M (this part of the test is ignored if M is `VOIDmode') and the function specified by the string PRED ! returns a non-zero value when passed operand N and mode M (this part of the test is ignored if PRED is the null string). The CONSTRAINTS operand is ignored and should be the null string. --- 95,101 ---- This test is true if operand N of the insn whose attribute value is being determined has mode M (this part of the test is ignored if M is `VOIDmode') and the function specified by the string PRED ! returns a nonzero value when passed operand N and mode M (this part of the test is ignored if PRED is the null string). The CONSTRAINTS operand is ignored and should be the null string. diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-27 gcc-3.0.2/gcc/doc/gcc.info-27 *** gcc-3.0.1/gcc/doc/gcc.info-27 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-27 Tue Oct 23 11:00:26 2001 *************** Controlling the Compilation Driver, `gcc *** 70,76 **** `SWITCH_CURTAILS_COMPILATION (CHAR)' A C expression which determines whether the option `-CHAR' stops compilation before the generation of an executable. The value is ! boolean, non-zero if the option does stop an executable from being generated, zero otherwise. By default, this macro is defined as --- 70,76 ---- `SWITCH_CURTAILS_COMPILATION (CHAR)' A C expression which determines whether the option `-CHAR' stops compilation before the generation of an executable. The value is ! boolean, nonzero if the option does stop an executable from being generated, zero otherwise. By default, this macro is defined as *************** Run-time Target Specification *** 618,624 **** LEVEL is the optimization level specified; 2 if `-O2' is specified, 1 if `-O' is specified, and 0 if neither is specified. ! SIZE is non-zero if `-Os' is specified and zero otherwise. You should not use this macro to change options that are not machine-specific. These should uniformly selected by the same --- 618,624 ---- LEVEL is the optimization level specified; 2 if `-O2' is specified, 1 if `-O' is specified, and 0 if neither is specified. ! SIZE is nonzero if `-Os' is specified and zero otherwise. You should not use this macro to change options that are not machine-specific. These should uniformly selected by the same *************** supported. *** 682,688 **** `init_machine_status' This is a `void (*)(struct function *)' function pointer. If this ! pointer is non-NULL it will be called once per function, before function compilation starts, in order to allow the target to perform any target specific initialisation of the `struct function' structure. It is intended that this would be used to --- 682,688 ---- `init_machine_status' This is a `void (*)(struct function *)' function pointer. If this ! pointer is non-`NULL' it will be called once per function, before function compilation starts, in order to allow the target to perform any target specific initialisation of the `struct function' structure. It is intended that this would be used to *************** supported. *** 690,702 **** `free_machine_status' This is a `void (*)(struct function *)' function pointer. If this ! pointer is non-NULL it will be called once per function, after the ! function has been compiled, in order to allow any memory allocated ! during the `init_machine_status' function call to be freed. `mark_machine_status' This is a `void (*)(struct function *)' function pointer. If this ! pointer is non-NULL it will be called once per function in order to mark any data items in the `struct machine_function' structure which need garbage collection. --- 690,703 ---- `free_machine_status' This is a `void (*)(struct function *)' function pointer. If this ! pointer is non-`NULL' it will be called once per function, after ! the function has been compiled, in order to allow any memory ! allocated during the `init_machine_status' function call to be ! freed. `mark_machine_status' This is a `void (*)(struct function *)' function pointer. If this ! pointer is non-`NULL' it will be called once per function in order to mark any data items in the `struct machine_function' structure which need garbage collection. diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-28 gcc-3.0.2/gcc/doc/gcc.info-28 *** gcc-3.0.1/gcc/doc/gcc.info-28 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-28 Tue Oct 23 11:00:26 2001 *************** Basic Characteristics of Registers *** 345,351 **** function exit, if the register is used within the function. `HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE)' ! A C expression that is non-zero if it is not permissible to store a value of mode MODE in hard register number REGNO across a call without some part of it being clobbered. For most machines this macro need not be defined. It is only required for machines that --- 345,351 ---- function exit, if the register is used within the function. `HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE)' ! A C expression that is nonzero if it is not permissible to store a value of mode MODE in hard register number REGNO across a call without some part of it being clobbered. For most machines this macro need not be defined. It is only required for machines that *************** return. *** 903,909 **** `SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)' Certain machines have the property that some registers cannot be copied to some other registers without using memory. Define this ! macro on those machines to be a C expression that is non-zero if objects of mode M in registers of CLASS1 can only be copied to registers of class CLASS2 by storing a register of CLASS1 into memory and loading that memory location into a register of CLASS2. --- 903,909 ---- `SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)' Certain machines have the property that some registers cannot be copied to some other registers without using memory. Define this ! macro on those machines to be a C expression that is nonzero if objects of mode M in registers of CLASS1 can only be copied to registers of class CLASS2 by storing a register of CLASS1 into memory and loading that memory location into a register of CLASS2. *************** return. *** 949,962 **** and reload will fail if the required hard register is used for another purpose across such an insn. ! Define `SMALL_REGISTER_CLASSES' to be an expression with a non-zero ! value on these machines. When this macro has a non-zero value, the compiler will try to minimize the lifetime of hard registers. ! It is always safe to define this macro with a non-zero value, but if you unnecessarily define it, you will reduce the amount of optimizations that can be performed in some cases. If you do not ! define this macro with a non-zero value when it is required, the compiler will run out of spill registers and print a fatal error message. For most machines, you should not define this macro at all. --- 949,962 ---- and reload will fail if the required hard register is used for another purpose across such an insn. ! Define `SMALL_REGISTER_CLASSES' to be an expression with a nonzero ! value on these machines. When this macro has a nonzero value, the compiler will try to minimize the lifetime of hard registers. ! It is always safe to define this macro with a nonzero value, but if you unnecessarily define it, you will reduce the amount of optimizations that can be performed in some cases. If you do not ! define this macro with a nonzero value when it is required, the compiler will run out of spill registers and print a fatal error message. For most machines, you should not define this macro at all. diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-29 gcc-3.0.2/gcc/doc/gcc.info-29 *** gcc-3.0.1/gcc/doc/gcc.info-29 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-29 Tue Oct 23 11:00:26 2001 *************** Eliminating Frame Pointer and Arg Pointe *** 494,500 **** pointer is specified first since that is the preferred elimination. `CAN_ELIMINATE (FROM-REG, TO-REG)' ! A C expression that returns non-zero if the compiler is allowed to try to replace register number FROM-REG with register number TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is defined, and will usually be the constant 1, since most of the --- 494,500 ---- pointer is specified first since that is the preferred elimination. `CAN_ELIMINATE (FROM-REG, TO-REG)' ! A C expression that returns nonzero if the compiler is allowed to try to replace register number FROM-REG with register number TO-REG. This macro need only be defined if `ELIMINABLE_REGS' is defined, and will usually be the constant 1, since most of the *************** the stack. *** 714,720 **** You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the definition of this macro to determine if this argument is of a type that must be passed in the stack. If `REG_PARM_STACK_SPACE' ! is not defined and `FUNCTION_ARG' returns non-zero for such an argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is defined, the argument will be computed in the stack and then loaded into a register. --- 714,720 ---- You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the definition of this macro to determine if this argument is of a type that must be passed in the stack. If `REG_PARM_STACK_SPACE' ! is not defined and `FUNCTION_ARG' returns nonzero for such an argument, the compiler will abort. If `REG_PARM_STACK_SPACE' is defined, the argument will be computed in the stack and then loaded into a register. diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-30 gcc-3.0.2/gcc/doc/gcc.info-30 *** gcc-3.0.1/gcc/doc/gcc.info-30 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-30 Tue Oct 23 11:00:26 2001 *************** Permitting inlining of functions with at *** 440,446 **** it, it will not be inlined. This behaviour can be overridden if the target defines the `FUNCTION_ATTRIBUTE_INLINABLE_P' macro. This macro takes one argument, a `DECL' describing the function. It should return ! non-zero if the function can be inlined, otherwise it should return 0.  File: gcc.info, Node: Tail Calling, Prev: Inlining, Up: Stack and Calling --- 440,446 ---- it, it will not be inlined. This behaviour can be overridden if the target defines the `FUNCTION_ATTRIBUTE_INLINABLE_P' macro. This macro takes one argument, a `DECL' describing the function. It should return ! nonzero if the function can be inlined, otherwise it should return 0.  File: gcc.info, Node: Tail Calling, Prev: Inlining, Up: Stack and Calling diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-31 gcc-3.0.2/gcc/doc/gcc.info-31 *** gcc-3.0.1/gcc/doc/gcc.info-31 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-31 Tue Oct 23 11:00:26 2001 *************** Addressing Modes *** 47,65 **** `HAVE_PRE_DECREMENT' `HAVE_POST_INCREMENT' `HAVE_POST_DECREMENT' ! A C expression that is non-zero if the machine supports pre-increment, pre-decrement, post-increment, or post-decrement addressing respectively. `HAVE_PRE_MODIFY_DISP' `HAVE_POST_MODIFY_DISP' ! A C expression that is non-zero if the machine supports pre- or post-address side-effect generation involving constants other than the size of the memory operand. `HAVE_PRE_MODIFY_REG' `HAVE_POST_MODIFY_REG' ! A C expression that is non-zero if the machine supports pre- or post-address side-effect generation involving a register displacement. --- 47,65 ---- `HAVE_PRE_DECREMENT' `HAVE_POST_INCREMENT' `HAVE_POST_DECREMENT' ! A C expression that is nonzero if the machine supports pre-increment, pre-decrement, post-increment, or post-decrement addressing respectively. `HAVE_PRE_MODIFY_DISP' `HAVE_POST_MODIFY_DISP' ! A C expression that is nonzero if the machine supports pre- or post-address side-effect generation involving constants other than the size of the memory operand. `HAVE_PRE_MODIFY_REG' `HAVE_POST_MODIFY_REG' ! A C expression that is nonzero if the machine supports pre- or post-address side-effect generation involving a register displacement. *************** operations on the target machine. *** 526,532 **** `MEMORY_MOVE_COST (MODE, CLASS, IN)' A C expression for the cost of moving data of mode MODE between a register of class CLASS and memory; IN is zero if the value is to ! be written to memory, non-zero if it is to be read in. This cost is relative to those in `REGISTER_MOVE_COST'. If moving between registers and memory is more expensive than between two registers, you should define this macro to express the relative cost. --- 526,532 ---- `MEMORY_MOVE_COST (MODE, CLASS, IN)' A C expression for the cost of moving data of mode MODE between a register of class CLASS and memory; IN is zero if the value is to ! be written to memory, nonzero if it is to be read in. This cost is relative to those in `REGISTER_MOVE_COST'. If moving between registers and memory is more expensive than between two registers, you should define this macro to express the relative cost. *************** ordinarily expect. *** 587,601 **** than aligned accesses, for example if they are emulated in a trap handler. ! When this macro is non-zero, the compiler will act as if ! `STRICT_ALIGNMENT' were non-zero when generating code for block moves. This can cause significantly more instructions to be ! produced. Therefore, do not set this macro non-zero if unaligned accesses only add a cycle or two to the time for a memory access. If the value of this macro is always zero, it need not be defined. ! If this macro is defined, it should produce a non-zero value when ! `STRICT_ALIGNMENT' is non-zero. `DONT_REDUCE_ADDR' Define this macro to inhibit strength reduction of memory --- 587,601 ---- than aligned accesses, for example if they are emulated in a trap handler. ! When this macro is nonzero, the compiler will act as if ! `STRICT_ALIGNMENT' were nonzero when generating code for block moves. This can cause significantly more instructions to be ! produced. Therefore, do not set this macro nonzero if unaligned accesses only add a cycle or two to the time for a memory access. If the value of this macro is always zero, it need not be defined. ! If this macro is defined, it should produce a nonzero value when ! `STRICT_ALIGNMENT' is nonzero. `DONT_REDUCE_ADDR' Define this macro to inhibit strength reduction of memory *************** can also define additional sections. *** 803,809 **** data section. `JUMP_TABLES_IN_TEXT_SECTION' ! Define this macro to be an expression with a non-zero value if jump tables (for `tablejump' insns) should be output in the text section, along with the assembler instructions. Otherwise, the readonly data section is used. --- 803,809 ---- data section. `JUMP_TABLES_IN_TEXT_SECTION' ! Define this macro to be an expression with a nonzero value if jump tables (for `tablejump' insns) should be output in the text section, along with the assembler instructions. Otherwise, the readonly data section is used. diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-32 gcc-3.0.2/gcc/doc/gcc.info-32 *** gcc-3.0.1/gcc/doc/gcc.info-32 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-32 Tue Oct 23 11:00:26 2001 *************** Output of Data *** 105,111 **** `CONSTANT_POOL_BEFORE_FUNCTION' You may define this macro as a C expression. You should define the ! expression to have a non-zero value if GCC should output the constant pool for a function before the code for the function, or a zero value if GCC should output the constant pool after the function. If you do not define this macro, the usual case, GCC --- 105,111 ---- `CONSTANT_POOL_BEFORE_FUNCTION' You may define this macro as a C expression. You should define the ! expression to have a nonzero value if GCC should output the constant pool for a function before the code for the function, or a zero value if GCC should output the constant pool after the function. If you do not define this macro, the usual case, GCC *************** Output and Generation of Labels *** 591,598 **** The argument IS_INST specifies whether the method is an instance method or a class method; CLASS_NAME is the name of the class; ! CAT_NAME is the name of the category (or NULL if the method is not ! in a category); and SEL_NAME is the name of the selector. On systems where the assembler can handle quoted names, you can use this macro to provide more human-readable names. --- 591,598 ---- The argument IS_INST specifies whether the method is an instance method or a class method; CLASS_NAME is the name of the class; ! CAT_NAME is the name of the category (or `NULL' if the method is ! not in a category); and SEL_NAME is the name of the selector. On systems where the assembler can handle quoted names, you can use this macro to provide more human-readable names. diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-33 gcc-3.0.2/gcc/doc/gcc.info-33 *** gcc-3.0.1/gcc/doc/gcc.info-33 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-33 Tue Oct 23 11:00:26 2001 *************** Mode Switching Instructions *** 791,799 **** You can have multiple entities that are mode-switched, and select at run time which entities actually need it. ! `OPTIMIZE_MODE_SWITCHING' should return non-zero for any ENTITY ! that that needs mode-switching. If you define this macro, you ! also have to define `NUM_MODES_FOR_MODE_SWITCHING', `MODE_NEEDED', `MODE_PRIORITY_TO_MODE' and `EMIT_MODE_SET'. `NORMAL_MODE' is optional. --- 791,799 ---- You can have multiple entities that are mode-switched, and select at run time which entities actually need it. ! `OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY ! that needs mode-switching. If you define this macro, you also ! have to define `NUM_MODES_FOR_MODE_SWITCHING', `MODE_NEEDED', `MODE_PRIORITY_TO_MODE' and `EMIT_MODE_SET'. `NORMAL_MODE' is optional. diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-34 gcc-3.0.2/gcc/doc/gcc.info-34 *** gcc-3.0.1/gcc/doc/gcc.info-34 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-34 Tue Oct 23 11:00:26 2001 *************** Miscellaneous Parameters *** 170,176 **** A C expression that is nonzero if on this machine the number of bits actually used for the count of a shift operation is equal to the number of bits needed to represent the size of the object ! being shifted. When this macro is non-zero, the compiler will assume that it is safe to omit a sign-extend, zero-extend, and certain bitwise `and' instructions that truncates the count of a shift operation. On machines that have instructions that act on --- 170,176 ---- A C expression that is nonzero if on this machine the number of bits actually used for the count of a shift operation is equal to the number of bits needed to represent the size of the object ! being shifted. When this macro is nonzero, the compiler will assume that it is safe to omit a sign-extend, zero-extend, and certain bitwise `and' instructions that truncates the count of a shift operation. On machines that have instructions that act on *************** Miscellaneous Parameters *** 290,298 **** store-flag instructions. `FLOAT_STORE_FLAG_VALUE (MODE)' ! A C expression that gives a non-zero `REAL_VALUE_TYPE' value that ! is returned when comparison operators with floating-point results ! are true. Define this macro on machine that have comparison operations that return floating-point values. If there are no such operations, do not define this macro. --- 290,298 ---- store-flag instructions. `FLOAT_STORE_FLAG_VALUE (MODE)' ! A C expression that gives a nonzero `REAL_VALUE_TYPE' value that is ! returned when comparison operators with floating-point results are ! true. Define this macro on machine that have comparison operations that return floating-point values. If there are no such operations, do not define this macro. diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-37 gcc-3.0.2/gcc/doc/gcc.info-37 *** gcc-3.0.1/gcc/doc/gcc.info-37 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-37 Tue Oct 23 11:00:26 2001 *************** look up both forms. *** 695,700 **** --- 695,701 ---- * mno-powerpc64: RS/6000 and PowerPC Options. * mno-prolog-function: V850 Options. * mno-prototype: RS/6000 and PowerPC Options. + * mno-push-args: i386 Options. * mno-register-names: IA-64 Options. * mno-regnames: RS/6000 and PowerPC Options. * mno-relax-immediate: MCore Options. *************** look up both forms. *** 736,742 **** * mno-update: RS/6000 and PowerPC Options. * mno-volatile-asm-stop: IA-64 Options. * mno-wide-bitfields: MCore Options. - * mno-wide-multiply: i386 Options. * mno-xl-call: RS/6000 and PowerPC Options. * mnoargcount: Convex Options. * mnobitfield <1>: NS32K Options. --- 737,742 ---- *************** look up both forms. *** 904,910 **** * mvxworks: RS/6000 and PowerPC Options. * mwarn-passed-structs: M88K Options. * mwide-bitfields: MCore Options. - * mwide-multiply: i386 Options. * mwords-little-endian: ARM Options. * mxl-call: RS/6000 and PowerPC Options. * mxopen: ARM Options. --- 904,909 ---- diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-4 gcc-3.0.2/gcc/doc/gcc.info-4 *** gcc-3.0.1/gcc/doc/gcc.info-4 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-4 Tue Oct 23 11:00:26 2001 *************** of optimizations to be performed is desi *** 1095,1101 **** You can control some of these constants on the command-line using the `--param' option. ! In each case, the VALUE is a integer. The allowable choices for NAME are given in the following table: `max-delay-slot-insn-search' --- 1095,1101 ---- You can control some of these constants on the command-line using the `--param' option. ! In each case, the VALUE is an integer. The allowable choices for NAME are given in the following table: `max-delay-slot-insn-search' diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-7 gcc-3.0.2/gcc/doc/gcc.info-7 *** gcc-3.0.1/gcc/doc/gcc.info-7 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-7 Tue Oct 23 11:00:26 2001 *************** Intel 386 Options *** 845,851 **** more memory. `-m128bit-long-double' - `-m128bit-long-double' Control the size of `long double' type. i386 application binary interface specify the size to be 12 bytes, while modern architectures (Pentium and newer) prefer `long double' aligned to --- 845,850 ---- *************** Intel 386 Options *** 858,864 **** `long double' will be modified. `-m96bit-long-double' - `-m96bit-long-double' Set the size of `long double' to 96 bits as required by the i386 application binary interface. This is the default. --- 857,862 ---- *************** Intel 386 Options *** 868,879 **** `data'. `-msvr3-shlib' places these locals into `bss'. These options are meaningful only on System V Release 3. - `-mno-wide-multiply' - `-mwide-multiply' - Control whether GCC uses the `mul' and `imul' that produce 64-bit - results in `eax:edx' from 32-bit operands to do `long long' - multiplies and 32-bit division by constants. - `-mrtd' Use a different function-calling convention, in which functions that take a fixed number of arguments return with the `ret' NUM --- 866,871 ---- *************** Intel 386 Options *** 963,968 **** --- 955,961 ---- alignment to `-mpreferred-stack-boundary=2'. `-mpush-args' + `-mno-push-args' Use PUSH operations to store outgoing parameters. This method is shorter and usually equally fast as method using SUB/MOV operations and is enabled by default. In some cases disabling it *************** Intel 386 Options *** 971,977 **** `-maccumulate-outgoing-args' If enabled, the maximum amount of space required for outgoing ! arguments will be computed in the function prologue. This in faster on most modern CPUs because of reduced dependencies, improved scheduling and reduced stack usage when preferred stack boundary is not equal to 2. The drawback is a notable increase in --- 964,970 ---- `-maccumulate-outgoing-args' If enabled, the maximum amount of space required for outgoing ! arguments will be computed in the function prologue. This is faster on most modern CPUs because of reduced dependencies, improved scheduling and reduced stack usage when preferred stack boundary is not equal to 2. The drawback is a notable increase in diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.info-8 gcc-3.0.2/gcc/doc/gcc.info-8 *** gcc-3.0.1/gcc/doc/gcc.info-8 Sun Aug 19 18:05:18 2001 --- gcc-3.0.2/gcc/doc/gcc.info-8 Tue Oct 23 11:00:26 2001 *************** choices are given below. *** 687,693 **** `-mmulti-add' Try and generate multiply-add floating point instructions `polyF' and `dotF'. This option is only available if the `-m32381' option ! is in effect. Using these instructions requires changes to to register allocation which generally has a negative impact on performance. This option should only be enabled when compiling code particularly likely to make heavy use of multiply-add --- 687,693 ---- `-mmulti-add' Try and generate multiply-add floating point instructions `polyF' and `dotF'. This option is only available if the `-m32381' option ! is in effect. Using these instructions requires changes to register allocation which generally has a negative impact on performance. This option should only be enabled when compiling code particularly likely to make heavy use of multiply-add diff -Nrc3pad gcc-3.0.1/gcc/doc/gcc.texi gcc-3.0.2/gcc/doc/gcc.texi *** gcc-3.0.1/gcc/doc/gcc.texi Fri Jul 6 12:29:44 2001 --- gcc-3.0.2/gcc/doc/gcc.texi Mon Oct 22 17:23:34 2001 *************** *** 42,47 **** --- 42,48 ---- @c anything else? --mew 10feb93 @c For consistency, use the following: + @c - "32-bit" rather than "32 bit" as an adjective. @c - "back end" as a noun, "back-end" as an adjective. @c - "bit-field" not "bitfield" or "bit field" (following the C and C++ @c standards). *************** *** 54,59 **** --- 55,63 ---- @c marked up with @command, for the commands for compilation when the @c emphasis is on those; "GNU C" and "GNU C++" for language dialects; @c and try to avoid the older term "GNU CC". + @c - "nonzero" rather than "non-zero". + @c - "@code{NULL}" rather than "NULL". + @c - "Objective-C" rather than "Objective C". @macro gcctabopt{body} @code{\body\} *************** information that makes for fixing the bu *** 2039,2045 **** * Where: Bug Lists. Where to send your bug report. * Reporting: Bug Reporting. How to report a bug effectively. * GNATS: gccbug. You can use a bug reporting tool. - * Patches: Sending Patches. How to send a patch for GCC. * Known: Trouble. Known problems. * Help: Service. Where to ask for help. @end menu --- 2043,2048 ---- *************** And if we can't understand what bug you *** 2364,2370 **** patch should be an improvement, we won't install it. A test case will help us to understand. ! @xref{Sending Patches}, for guidelines on how to make it easy for us to understand and install your patches. @item --- 2367,2374 ---- patch should be an improvement, we won't install it. A test case will help us to understand. ! See @uref{http://gcc.gnu.org/contribute.html} ! for guidelines on how to make it easy for us to understand and install your patches. @item *************** unless we have an identical system---and *** 2381,2387 **** we should be able to reproduce the crash ourselves. @end itemize ! @node gccbug,Sending Patches, Bug Reporting, Bugs @section The gccbug script @cindex gccbug script --- 2385,2391 ---- we should be able to reproduce the crash ourselves. @end itemize ! @node gccbug,, Bug Reporting, Bugs @section The gccbug script @cindex gccbug script *************** send to the bug reporting address. *** 2400,2521 **** A number of fields in this bug report form are specific to GCC, and are explained at @uref{http://gcc.gnu.org/gnats.html}. - @node Sending Patches,, gccbug, Bugs - @section Sending Patches for GCC - - If you would like to write bug fixes or improvements for the GNU C - compiler, that is very helpful. Send suggested fixes to the patches - mailing list, @email{gcc-patches@@gcc.gnu.org}. - - Please follow these guidelines so we can study your patches efficiently. - If you don't follow these guidelines, your information might still be - useful, but using it will take extra work. Maintaining GCC is a lot - of work in the best of circumstances, and we can't keep up unless you do - your best to help. - - @itemize @bullet - @item - Send an explanation with your changes of what problem they fix or what - improvement they bring about. For a bug fix, just include a copy of the - bug report, and explain why the change fixes the bug. - - (Referring to a bug report is not as good as including it, because then - we will have to look it up, and we have probably already deleted it if - we've already fixed the bug.) - - @item - Always include a proper bug report for the problem you think you have - fixed. We need to convince ourselves that the change is right before - installing it. Even if it is right, we might have trouble judging it if - we don't have a way to reproduce the problem. - - @item - Include all the comments that are appropriate to help people reading the - source in the future understand why this change was needed. - - @item - Don't mix together changes made for different reasons. - Send them @emph{individually}. - - If you make two changes for separate reasons, then we might not want to - install them both. We might want to install just one. If you send them - all jumbled together in a single set of diffs, we have to do extra work - to disentangle them---to figure out which parts of the change serve - which purpose. If we don't have time for this, we might have to ignore - your changes entirely. - - If you send each change as soon as you have written it, with its own - explanation, then the two changes never get tangled up, and we can - consider each one properly without any extra work to disentangle them. - - Ideally, each change you send should be impossible to subdivide into - parts that we might want to consider separately, because each of its - parts gets its motivation from the other parts. - - @item - Send each change as soon as that change is finished. Sometimes people - think they are helping us by accumulating many changes to send them all - together. As explained above, this is absolutely the worst thing you - could do. - - Since you should send each change separately, you might as well send it - right away. That gives us the option of installing it immediately if it - is important. - - @item - Use @samp{diff -c} to make your diffs. Diffs without context are hard - for us to install reliably. More than that, they make it hard for us to - study the diffs to decide whether we want to install them. Unidiff - format is better than contextless diffs, but not as easy to read as - @option{-c} format. - - If you have GNU diff, use @samp{diff -cp}, which shows the name of the - function that each change occurs in. - - @item - Write the change log entries for your changes. We get lots of changes, - and we don't have time to do all the change log writing ourselves. - - Read the @file{ChangeLog} file to see what sorts of information to put - in, and to learn the style that we use. The purpose of the change log - is to show people where to find what was changed. So you need to be - specific about what functions you changed; in large functions, it's - often helpful to indicate where within the function the change was. - - On the other hand, once you have shown people where to find the change, - you need not explain its purpose. Thus, if you add a new function, all - you need to say about it is that it is new. If you feel that the - purpose needs explaining, it probably does---but the explanation will be - much more useful if you put it in comments in the code. - - If you would like your name to appear in the header line for who made - the change, send us the header line. - - @item - When you write the fix, keep in mind that we can't install a change that - would break other systems. - - People often suggest fixing a problem by changing machine-independent - files such as @file{toplev.c} to do something special that a particular - system needs. Sometimes it is totally obvious that such changes would - break GCC for almost all users. We can't possibly make a change like - that. At best it might tell us how to write another patch that would - solve the problem acceptably. - - Sometimes people send fixes that @emph{might} be an improvement in - general---but it is hard to be sure of this. It's hard to install - such changes because we have to study them very carefully. Of course, - a good explanation of the reasoning by which you concluded the change - was correct can help convince us. - - The safest changes are changes to the configuration files for a - particular machine. These are safe because they can't create new bugs - on other machines. - - Please help us keep up with the workload by designing the patch in a - form that is good to install. - @end itemize - @node Service @chapter How To Get Help with GCC --- 2404,2409 ---- *************** There are also header files @file{tree.h *** 3262,3268 **** which define the format of the tree representation. C Preprocessing, for language front ends, that want or require it, is ! performed by cpplib, which is covered in seperate documentation. In particular, the internals are covered in @xref{Top, ,Cpplib internals, cppinternals, Cpplib Internals}. --- 3150,3156 ---- which define the format of the tree representation. C Preprocessing, for language front ends, that want or require it, is ! performed by cpplib, which is covered in separate documentation. In particular, the internals are covered in @xref{Top, ,Cpplib internals, cppinternals, Cpplib Internals}. diff -Nrc3pad gcc-3.0.1/gcc/doc/gcov.1 gcc-3.0.2/gcc/doc/gcov.1 *** gcc-3.0.1/gcc/doc/gcov.1 Sun Aug 19 17:45:03 2001 --- gcc-3.0.2/gcc/doc/gcov.1 Fri Oct 12 04:29:34 2001 *************** *** 1,8 **** ! .\" Automatically generated by Pod::Man version 1.16 ! .\" Mon Jun 25 00:16:01 2001 .\" .\" Standard preamble: ! .\" ====================================================================== .de Sh \" Subsection heading .br .if t .Sp --- 1,8 ---- ! .\" Automatically generated by Pod::Man version 1.19 ! .\" Fri Oct 12 11:20:12 2001 .\" .\" Standard preamble: ! .\" ======================================================================== .de Sh \" Subsection heading .br .if t .Sp *************** *** 15,26 **** .if t .sp .5v .if n .sp .. - .de Ip \" List item - .br - .ie \\n(.$>=3 .ne \\$3 - .el .ne 3 - .IP "\\$1" \\$2 - .. .de Vb \" Begin verbatim text .ft CW .nf --- 15,20 ---- *************** *** 34,42 **** .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. | will give a ! .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used ! .\" to do unbreakable dashes and therefore won't be available. \*(C` and ! .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> .tr \(*W-|\(bv\*(Tr .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ --- 28,36 ---- .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. | will give a ! .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to ! .\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' ! .\" expand to `' in nroff, nothing in troff, for use with C<>. .tr \(*W-|\(bv\*(Tr .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ *************** *** 56,65 **** . ds R" '' 'br\} .\" ! .\" If the F register is turned on, we'll generate index entries on stderr ! .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and ! .\" index entries marked with X<> in POD. Of course, you'll have to process ! .\" the output yourself in some meaningful fashion. .if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" --- 50,59 ---- . ds R" '' 'br\} .\" ! .\" If the F register is turned on, we'll generate index entries on stderr for ! .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index ! .\" entries marked with X<> in POD. Of course, you'll have to process the ! .\" output yourself in some meaningful fashion. .if \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" *************** *** 68,81 **** . rr F .\} .\" ! .\" For nroff, turn off justification. Always turn off hyphenation; it ! .\" makes way too many mistakes in technical documents. .hy 0 .if n .na .\" .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). .\" Fear. Run. Save yourself. No user-serviceable parts. - .bd B 3 . \" fudge factors for nroff and troff .if n \{\ . ds #H 0 --- 62,74 ---- . rr F .\} .\" ! .\" For nroff, turn off justification. Always turn off hyphenation; it makes ! .\" way too many mistakes in technical documents. .hy 0 .if n .na .\" .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). .\" Fear. Run. Save yourself. No user-serviceable parts. . \" fudge factors for nroff and troff .if n \{\ . ds #H 0 *************** *** 135,144 **** . ds Ae AE .\} .rm #[ #] #H #V #F C ! .\" ====================================================================== .\" .IX Title "GCOV 1" ! .TH GCOV 1 "gcc-3.0.1" "2001-06-25" "GNU" .UC .SH "NAME" gcov \- coverage testing tool --- 128,137 ---- . ds Ae AE .\} .rm #[ #] #H #V #F C ! .\" ======================================================================== .\" .IX Title "GCOV 1" ! .TH GCOV 1 "gcc-3.0.2" "2001-10-12" "GNU" .UC .SH "NAME" gcov \- coverage testing tool *************** of computing time. *** 158,168 **** Profiling tools help you analyze your code's performance. Using a profiler such as \fBgcov\fR or \fBgprof\fR, you can find out some basic performance statistics, such as: ! .Ip "\(bu" 4 how often each line of code executes ! .Ip "\(bu" 4 what lines of code are actually executed ! .Ip "\(bu" 4 how much computing time each section of code uses .PP Once you know these things about how your code works when compiled, you --- 151,161 ---- Profiling tools help you analyze your code's performance. Using a profiler such as \fBgcov\fR or \fBgprof\fR, you can find out some basic performance statistics, such as: ! .IP "\(bu" 4 how often each line of code executes ! .IP "\(bu" 4 what lines of code are actually executed ! .IP "\(bu" 4 how much computing time each section of code uses .PP Once you know these things about how your code works when compiled, you *************** timing information you can use along wit *** 200,231 **** compatible with any other profiling or test coverage mechanism. .SH "OPTIONS" .IX Header "OPTIONS" ! .Ip "\fB\-b\fR" 4 .IX Item "-b" Write branch frequencies to the output file, and write branch summary info to the standard output. This option allows you to see how often each branch in your program was taken. ! .Ip "\fB\-c\fR" 4 .IX Item "-c" Write branch frequencies as the number of branches taken, rather than the percentage of branches taken. ! .Ip "\fB\-v\fR" 4 .IX Item "-v" Display the \fBgcov\fR version number (on the standard error stream). ! .Ip "\fB\-n\fR" 4 .IX Item "-n" Do not create the \fBgcov\fR output file. ! .Ip "\fB\-l\fR" 4 .IX Item "-l" Create long file names for included source files. For example, if the header file \fIx.h\fR contains code, and was included in the file \&\fIa.c\fR, then running \fBgcov\fR on the file \fIa.c\fR will produce an output file called \fIa.c.x.h.gcov\fR instead of \fIx.h.gcov\fR. This can be useful if \fIx.h\fR is included in multiple source files. ! .Ip "\fB\-f\fR" 4 .IX Item "-f" Output summaries for each function in addition to the file level summary. ! .Ip "\fB\-o\fR" 4 .IX Item "-o" The directory where the object files live. Gcov will search for \fI.bb\fR, \&\fI.bbg\fR, and \fI.da\fR files in this directory. --- 193,224 ---- compatible with any other profiling or test coverage mechanism. .SH "OPTIONS" .IX Header "OPTIONS" ! .IP "\fB\-b\fR" 4 .IX Item "-b" Write branch frequencies to the output file, and write branch summary info to the standard output. This option allows you to see how often each branch in your program was taken. ! .IP "\fB\-c\fR" 4 .IX Item "-c" Write branch frequencies as the number of branches taken, rather than the percentage of branches taken. ! .IP "\fB\-v\fR" 4 .IX Item "-v" Display the \fBgcov\fR version number (on the standard error stream). ! .IP "\fB\-n\fR" 4 .IX Item "-n" Do not create the \fBgcov\fR output file. ! .IP "\fB\-l\fR" 4 .IX Item "-l" Create long file names for included source files. For example, if the header file \fIx.h\fR contains code, and was included in the file \&\fIa.c\fR, then running \fBgcov\fR on the file \fIa.c\fR will produce an output file called \fIa.c.x.h.gcov\fR instead of \fIx.h.gcov\fR. This can be useful if \fIx.h\fR is included in multiple source files. ! .IP "\fB\-f\fR" 4 .IX Item "-f" Output summaries for each function in addition to the file level summary. ! .IP "\fB\-o\fR" 4 .IX Item "-o" The directory where the object files live. Gcov will search for \fI.bb\fR, \&\fI.bbg\fR, and \fI.da\fR files in this directory. diff -Nrc3pad gcc-3.0.1/gcc/doc/install.texi gcc-3.0.2/gcc/doc/install.texi *** gcc-3.0.1/gcc/doc/install.texi Fri Aug 17 16:32:52 2001 --- gcc-3.0.2/gcc/doc/install.texi Wed Oct 17 02:06:43 2001 *************** target system triple, such as @samp{spar *** 455,461 **** @var{version} denotes the GCC version, such as 3.0. @item Check operating system specific directories (e.g.@: @file{/usr/ccs/bin} on ! Sun Solaris). @end itemize Note that these rules do not check for the value of @env{PATH}. You may want to use @option{--with-as} if no assembler is installed in the --- 455,461 ---- @var{version} denotes the GCC version, such as 3.0. @item Check operating system specific directories (e.g.@: @file{/usr/ccs/bin} on ! Sun Solaris 2). @end itemize Note that these rules do not check for the value of @env{PATH}. You may want to use @option{--with-as} if no assembler is installed in the *************** Other broken versions may recompile part *** 770,776 **** installing the compiler.) Some commands executed when making the compiler may fail (return a ! non-zero status) and be ignored by @code{make}. These failures, which are often due to files that were not found, are expected, and can safely be ignored. --- 770,776 ---- installing the compiler.) Some commands executed when making the compiler may fail (return a ! nonzero status) and be ignored by @code{make}. These failures, which are often due to files that were not found, are expected, and can safely be ignored. *************** that you successfully built and installe *** 1107,1112 **** --- 1107,1117 ---- Include the output from running @file{@var{srcdir}/config.guess}. (Do not send us the @file{config.guess} file itself, just the one-line output from running it!) Also specify which version you built. + If the build was for GNU/Linux, also include the distribution name and version + (e.g., Red Hat 7.1 or Debian 2.2.3, available from @file{/etc/issue}) + and the version of glibc you used; for RPM-based systems like Red Hat, + Mandrake, and SuSE type @samp{rpm -q glibc} to get the glibc version, + and on systems like Debian and Progeny use @samp{dpkg -l libc6}. We'd also like to know if the @ifnothtml *************** AIX: *** 1179,1192 **** DOS---@uref{http://www.delorie.com/djgpp/,,DJGPP}; @item @uref{http://hpux.cae.wisc.edu/,,HP-UX Porting Center}; @item @uref{http://www.sco.com/skunkware/devtools/index.html#gcc,,SCO OpenServer/Unixware}; @item ! Solaris (SPARC, Intel)---@uref{http://www.sunfreeware.com/,,Sunfreeware}; @item SGI---@uref{http://freeware.sgi.com/,,SGI Freeware}; --- 1184,1204 ---- DOS---@uref{http://www.delorie.com/djgpp/,,DJGPP}; @item + HP-UX: + @itemize + @item @uref{http://hpux.cae.wisc.edu/,,HP-UX Porting Center}; @item + @uref{ftp://sunsite.informatik.rwth-aachen.de/pub/packages/gcc_hpux/,,Binaries for HP-UX 11.00 at Aachen University of Technology}. + @end itemize + + @item @uref{http://www.sco.com/skunkware/devtools/index.html#gcc,,SCO OpenServer/Unixware}; @item ! Solaris 2 (SPARC, Intel)---@uref{http://www.sunfreeware.com/,,Sunfreeware}; @item SGI---@uref{http://freeware.sgi.com/,,SGI Freeware}; *************** as new information becomes available. *** 1333,1338 **** --- 1345,1352 ---- @item @uref{#i860-intel-osf*,,i860-intel-osf*} @item + @uref{#ia64-*-linux,,ia64-*-linux} + @item @uref{#*-lynx-lynxos,,*-lynx-lynxos} @item @uref{#*-ibm-aix*,,*-ibm-aix*} *************** as new information becomes available. *** 1421,1435 **** @item @uref{#s390x-*-linux*} @item ! @uref{#*-*-solaris*,,*-*-solaris*} @item ! @uref{#sparc-sun-solaris*,,sparc-sun-solaris*} @item @uref{#sparc-sun-solaris2.7,,sparc-sun-solaris2.7} @item ! @uref{#*-sun-solaris2.8,,*-sun-solaris2.8} @item ! @uref{#sparc-sun-sunos*,,sparc-sun-sunos*} @item @uref{#sparc-unknown-linux-gnulibc1,,sparc-unknown-linux-gnulibc1} @item --- 1435,1449 ---- @item @uref{#s390x-*-linux*} @item ! @uref{#*-*-solaris2*,,*-*-solaris2*} @item ! @uref{#sparc-sun-solaris2*,,sparc-sun-solaris2*} @item @uref{#sparc-sun-solaris2.7,,sparc-sun-solaris2.7} @item ! @uref{#*-*-solaris2.8,,*-*-solaris2.8} @item ! @uref{#sparc-sun-sunos4*,,sparc-sun-sunos4*} @item @uref{#sparc-unknown-linux-gnulibc1,,sparc-unknown-linux-gnulibc1} @item *************** as new information becomes available. *** 1450,1456 **** @itemize @item ! @uref{#elf_targets,,all ELF targets} (SVR4, Solaris, etc.) @end itemize @end ifhtml --- 1464,1470 ---- @itemize @item ! @uref{#elf_targets,,all ELF targets} (SVR4, Solaris 2, etc.) @end itemize @end ifhtml *************** These problems don't exist in operating *** 2174,2179 **** --- 2188,2218 ----


        @end html + @heading @anchor{ia64-*-linux}ia64-*-linux + IA-64 processor (also known as IPF, or Itanium Processor Family) + running GNU/Linux. + + The toolchain is not completely finished, so requirements will continue + to change. + GCC 3.0.1 and later require glibc 2.2.4. + GCC 3.0.2 requires binutils from 2001-09-05 or later. + GCC 3.0.1 requires binutils 2.11.1 or later. + + None of the following versions of GCC has an ABI that is compatible + with any of the other versions in this list, with the exception that + Red Hat 2.96 and Trillian 000171 are compatible with each other: + 3.0.2, 3.0.1, 3.0, Red Hat 2.96, and Trillian 000717. + This primarily affects C++ programs and programs that create shared libraries. + Because of these ABI incompatibilities, GCC 3.0.2 is not recommended for + user programs on GNU/Linux systems built using earlier compiler releases. + GCC 3.0.2 is recommended for compiling linux, the kernel. + GCC 3.0.2 is believed to be fully ABI compliant, and hence no more major + ABI changes are expected. + + @html +

        +
        + @end html @heading @anchor{*-lynx-lynxos}*-lynx-lynxos LynxOS 2.2 and earlier comes with GCC 1.x already installed as @file{/bin/gcc}. You should compile with this instead of @file{/bin/cc}. *************** and function declarations in the origina *** 2218,2223 **** --- 2257,2273 ---- not prevent the linker from producing a correct library or runnable executable. + GCC's exception handling implementation stores process-specific data in + the shared library which prevents exception handling from working + correctly on AIX in a default installation. To work around this, the + shared objects need to be loaded in the process private segment to + prevent them from being shared and marked read-only. This is + accomplished on AIX by installing the shared libraries + (@file{libgcc_s.a} and @file{libstdc++.a}) with file permissions + disallowing read-other (@samp{chmod a+x,o-r}). If the shared libraries + have been used, the shared library segment can be cleaned using the + @samp{/usr/sbin/slibclean} command. + AIX 4.3 utilizes a ``large format'' archive to support both 32-bit and 64-bit object modules. The routines provided in AIX 4.3.0 and AIX 4.3.1 to parse archive libraries did not handle the new format correctly. *************** linking such as ``not a COFF file''. Th *** 2226,2251 **** with AIX 4.3.1 should work for a 32-bit environment. The @option{-g} option of the archive command may be used to create archives of 32-bit objects using the original ``small format''. A correct version of the ! routines is shipped with AIX 4.3.2. Some versions of the AIX binder (linker) can fail with a relocation overflow severe error when the @option{-bbigtoc} option is used to link GCC-produced object files into an executable that overflows the TOC@. A fix for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is available from IBM Customer Support and from its ! @uref{http://service.boulder.ibm.com/,,service.boulder.ibm.com} website as PTF U455193. The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core with a segmentation fault when invoked by any version of GCC@. A fix for APAR IX87327 is available from IBM Customer Support and from its ! @uref{http://service.boulder.ibm.com/,,service.boulder.ibm.com} website as PTF U461879. This fix is incorporated in AIX 4.3.3 and above. The initial assembler shipped with AIX 4.3.0 generates incorrect object files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS TO ASSEMBLE/BIND) is available from IBM Customer Support and from its ! @uref{http://service.boulder.ibm.com/,,service.boulder.ibm.com} website as PTF U453956. This fix is incorporated in AIX 4.3.1 and above. AIX provides National Language Support (NLS)@. Compilers and assemblers --- 2276,2301 ---- with AIX 4.3.1 should work for a 32-bit environment. The @option{-g} option of the archive command may be used to create archives of 32-bit objects using the original ``small format''. A correct version of the ! routines is shipped with AIX 4.3.2 and above. Some versions of the AIX binder (linker) can fail with a relocation overflow severe error when the @option{-bbigtoc} option is used to link GCC-produced object files into an executable that overflows the TOC@. A fix for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is available from IBM Customer Support and from its ! @uref{http://techsupport.services.ibm.com/,,techsupport.services.ibm.com} website as PTF U455193. The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core with a segmentation fault when invoked by any version of GCC@. A fix for APAR IX87327 is available from IBM Customer Support and from its ! @uref{http://techsupport.services.ibm.com/,,techsupport.services.ibm.com} website as PTF U461879. This fix is incorporated in AIX 4.3.3 and above. The initial assembler shipped with AIX 4.3.0 generates incorrect object files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS TO ASSEMBLE/BIND) is available from IBM Customer Support and from its ! @uref{http://techsupport.services.ibm.com/,,techsupport.services.ibm.com} website as PTF U453956. This fix is incorporated in AIX 4.3.1 and above. AIX provides National Language Support (NLS)@. Compilers and assemblers *************** environment variable to @samp{C} or @sam *** 2259,2266 **** By default, GCC for AIX 4.1 and above produces code that can be used on both Power or PowerPC processors. ! You can specify a default version for the @option{-mcpu=@var{cpu_type}} ! switch by using the configure option @option{--with-cpu-@var{cpu_type}}. @html

        --- 2309,2316 ---- By default, GCC for AIX 4.1 and above produces code that can be used on both Power or PowerPC processors. ! A default can be specified with the @option{-mcpu=@var{cpu_type}} ! switch and using the configure option @option{--with-cpu-@var{cpu_type}}. @html

        *************** IBM zSeries system (64 bit) running Linu *** 3013,3071 ****


        @end html ! @heading @anchor{*-*-solaris*}*-*-solaris* ! Sun does not ship a C compiler with Solaris. To bootstrap and install GCC you first have to install a pre-built compiler, see our @uref{binaries.html,,binaries page} for details. ! Solaris' @file{/bin/sh} will often fail to configure @file{libstdc++-v3}, @file{boehm-gc} or @file{libjava}. If you encounter this problem, set @env{CONFIG_SHELL} to ! @file{/bin/ksh} in your environment and run @command{make bootstrap} again. Another possibility that sometimes helps is to remove ! @file{*-*-solaris*/config.cache}. Solaris 2 comes with a number of optional OS packages. Some of these packages are needed to use GCC fully, namely @code{SUNWarc}, @code{SUNWbtool}, @code{SUNWesu}, @code{SUNWhea}, @code{SUNWlibm}, @code{SUNWsprot}, and @code{SUNWtoo}. If you did not install all ! optional packages when installing Solaris, you will need to verify that the packages that GCC needs are installed. To check whether an optional package is installed, use the @command{pkginfo} command. To add an optional package, use the ! @command{pkgadd} command. For further details, see the Solaris documentation. ! On some versions of Solaris, trying to use the linker and other tools in @file{/usr/ucb} to install GCC has been observed to cause trouble. For example, the linker may hang indefinitely. The fix is to remove ! @file{/usr/ucb} from your @code{PATH}. All releases of GNU binutils prior to 2.11.2 have known bugs on this platform. We recommend the use of GNU binutils 2.11.2 or the vendor tools (Sun @command{as}, Sun @command{ld}). ! Unfortunately, C++ shared libraries, including @samp{libstdc++}, won't work ! properly if assembled with Sun @command{as}: the linker will complain about ! relocations in read-only sections, in the definition of virtual ! tables. Also, Sun @command{as} fails to process long symbols resulting from ! mangling template-heavy C++ function names. @html


        @end html ! @heading @anchor{sparc-sun-solaris*}sparc-sun-solaris* ! Sun @command{as} 4.X is broken in that it cannot cope with long symbol names. A typical error message might look similar to the following: @samp{/usr/ccs/bin/as: "/var/tmp/ccMsw135.s", line 11041: error: can't compute value of an expression involving an external symbol.} ! This is Sun bug 4237974. This is fixed with patch 108908-02 and has ! been fixed in later (5.x) versions of the assembler. @html

        --- 3063,3147 ----


        @end html ! @c Please use Solaris 2 to refer to all release of Solaris, starting ! @c with 2.0 until 2.6, 7, and 8. Solaris 1 was a marketing name for ! @c SunOS 4 releases which we don't use to avoid confusion. Solaris ! @c alone is too unspecific and must be avoided. ! @heading @anchor{*-*-solaris2*}*-*-solaris2* ! Sun does not ship a C compiler with Solaris 2. To bootstrap and install GCC you first have to install a pre-built compiler, see our @uref{binaries.html,,binaries page} for details. ! The Solaris 2 @command{/bin/sh} will often fail to configure ! @file{libstdc++-v3}, @file{boehm-gc} or @file{libjava}. If you encounter this problem, set @env{CONFIG_SHELL} to ! @command{/bin/ksh} in your environment and run @command{make bootstrap} again. Another possibility that sometimes helps is to remove ! @file{*-*-solaris2*/config.cache}. Solaris 2 comes with a number of optional OS packages. Some of these packages are needed to use GCC fully, namely @code{SUNWarc}, @code{SUNWbtool}, @code{SUNWesu}, @code{SUNWhea}, @code{SUNWlibm}, @code{SUNWsprot}, and @code{SUNWtoo}. If you did not install all ! optional packages when installing Solaris 2, you will need to verify that the packages that GCC needs are installed. To check whether an optional package is installed, use the @command{pkginfo} command. To add an optional package, use the ! @command{pkgadd} command. For further details, see the Solaris 2 documentation. ! Trying to use the linker and other tools in @file{/usr/ucb} to install GCC has been observed to cause trouble. For example, the linker may hang indefinitely. The fix is to remove ! @file{/usr/ucb} from your @env{PATH}. All releases of GNU binutils prior to 2.11.2 have known bugs on this platform. We recommend the use of GNU binutils 2.11.2 or the vendor tools (Sun @command{as}, Sun @command{ld}). ! Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or ! newer: @command{g++} will complain that types are missing. These headers assume ! that omitting the type means @code{int}; this assumption worked for C89 but ! is wrong for C++, and is now wrong for C99 also. ! ! @command{g++} accepts such (illegal) constructs with the option ! @option{-fpermissive}; it ! will assume that any missing type is @code{int} (as defined by C89). ! ! There are patches for Solaris 2.6 (105633-56 or newer for SPARC, ! 106248-42 or newer for Intel), Solaris 7 (108376-21 or newer for SPARC, ! 108377-20 for Intel), and Solaris 8 (108652-24 or newer for SPARC, ! 108653-22 for Intel) that fix this bug. @html


        @end html ! @heading @anchor{sparc-sun-solaris2*}sparc-sun-solaris2* ! Sun @command{as} 4.x is broken in that it cannot cope with long symbol names. A typical error message might look similar to the following: @samp{/usr/ccs/bin/as: "/var/tmp/ccMsw135.s", line 11041: error: can't compute value of an expression involving an external symbol.} ! This is Sun bug 4237974. This is fixed with patch 108908-02 for Solaris ! 2.6 and has been fixed in later (5.x) versions of the assembler, ! starting with Solaris 7. ! ! Starting with Solaris 7, the operating system is capable of executing ! 64-bit SPARC V9 binaries. GCC 3.0 doesn't properly support this yet. ! Although some patches or recipes to enable this support have been posted ! to various newsgroups and mailing lists, we recommend against using ! them, since the compiler may either crash or, worse, silently generate ! bad code. If you really need this capability now, you might try a CVS ! version of GCC 3.1, which will fully support this. If all you want is ! code tuned for the UltraSPARC CPU, you should try the ! @option{-mtune=ultrasparc} option instead, which should be safe from ! those bugs and produce code that, unlike full 64-bit code, can still run ! on non-UltraSPARC machines. @html

        *************** been fixed in later (5.x) versions of th *** 3073,3079 **** @end html @heading @anchor{sparc-sun-solaris2.7}sparc-sun-solaris2.7 ! Sun patch 107058-01 (1999-01-13) for SPARC Solaris 7 triggers a bug in the dynamic linker. This problem (Sun bug 4210064) affects GCC 2.8 and later, including all EGCS releases. Sun formerly recommended 107058-01 for all Solaris 7 users, but around 1999-09-01 it started to --- 3149,3155 ---- @end html @heading @anchor{sparc-sun-solaris2.7}sparc-sun-solaris2.7 ! Sun patch 107058-01 (1999-01-13) for Solaris 7/SPARC triggers a bug in the dynamic linker. This problem (Sun bug 4210064) affects GCC 2.8 and later, including all EGCS releases. Sun formerly recommended 107058-01 for all Solaris 7 users, but around 1999-09-01 it started to *************** Here are some workarounds to this proble *** 3085,3091 **** Do not install Sun patch 107058-01 until after Sun releases a complete patch for bug 4210064. This is the simplest course to take, unless you must also use Sun's C compiler. Unfortunately 107058-01 ! is preinstalled on some new Solaris-based hosts, so you may have to back it out. @item --- 3161,3167 ---- Do not install Sun patch 107058-01 until after Sun releases a complete patch for bug 4210064. This is the simplest course to take, unless you must also use Sun's C compiler. Unfortunately 107058-01 ! is preinstalled on some new Solaris 7-based hosts, so you may have to back it out. @item *************** run code generated by GCC; it doesn't su *** 3104,3135 **** the hosts that run GCC itself. Second, Sun says that 106950-03 is only a partial fix for bug 4210064, but Sun doesn't know whether the partial fix is adequate for GCC@. Revision -08 or later should fix ! the bug, but (as of 1999-10-06) it is still being tested. @end itemize @html


        - @end html ! @heading @anchor{*-sun-solaris2.8}*-sun-solaris2.8 ! ! Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or ! newer: @command{g++} will complain that types are missing. These headers assume ! that omitting the type means @code{int}; this assumption worked for C89 but ! is wrong for C++, and is now wrong for C99 also. ! ! @command{g++} accepts such (illegal) constructs with the option @option{-fpermissive}; it ! will assume that any missing type is @code{int} (as defined by C89). ! ! For Solaris 8, this is fixed by revision 24 or later of patch 108652 ! (for SPARCs) or 108653 (for Intels). ! Solaris 8's linker fails to link some @samp{libjava} programs if previously-installed GCC java libraries already exist in the configured prefix. For this reason, @samp{libgcj} is disabled by default on Solaris 8. ! If you use GNU ld, or if you don't have a previously-installed @samp{libgcj} in the same prefix, use @option{--enable-libgcj} to build and install the Java libraries. --- 3180,3200 ---- the hosts that run GCC itself. Second, Sun says that 106950-03 is only a partial fix for bug 4210064, but Sun doesn't know whether the partial fix is adequate for GCC@. Revision -08 or later should fix ! the bug. The current (as of 2001-09-24) revision is -14, and is included in ! the Solaris 7 Recommended Patch Cluster. @end itemize @html


        @end html ! @heading @anchor{*-*-solaris2.8}*-*-solaris2.8 ! The Solaris 8 linker fails to link some @samp{libjava} programs if previously-installed GCC java libraries already exist in the configured prefix. For this reason, @samp{libgcj} is disabled by default on Solaris 8. ! If you use GNU @command{ld}, or if you don't have a previously-installed @samp{libgcj} in the same prefix, use @option{--enable-libgcj} to build and install the Java libraries. *************** Java libraries. *** 3137,3143 ****


        @end html ! @heading @anchor{sparc-sun-sunos*}sparc-sun-sunos* A bug in the SunOS 4 linker will cause it to crash when linking @option{-fPIC} compiled objects (and will therefore not allow you to build --- 3202,3208 ----


        @end html ! @heading @anchor{sparc-sun-sunos4*}sparc-sun-sunos4* A bug in the SunOS 4 linker will cause it to crash when linking @option{-fPIC} compiled objects (and will therefore not allow you to build *************** without modification. *** 3277,3283 **** @heading @anchor{os2}OS/2 GCC does not currently support OS/2. However, Andrew Zabolotny has been ! working on a generic OS/2 port with pgcc. The current code code can be found at @uref{http://www.goof.com/pcg/os2/,,http://www.goof.com/pcg/os2/}. An older copy of GCC 2.8.1 is included with the EMX tools available at --- 3342,3348 ---- @heading @anchor{os2}OS/2 GCC does not currently support OS/2. However, Andrew Zabolotny has been ! working on a generic OS/2 port with pgcc. The current code can be found at @uref{http://www.goof.com/pcg/os2/,,http://www.goof.com/pcg/os2/}. An older copy of GCC 2.8.1 is included with the EMX tools available at *************** current GCC) is to be found in the GCC t *** 3332,3338 ****


        @end html ! @heading @anchor{elf_targets}all ELF targets (SVR4, Solaris, etc.) C++ support is significantly better on ELF targets if you use the @uref{./configure.html#with-gnu-ld,,GNU linker}; duplicate copies of --- 3397,3403 ----


        @end html ! @heading @anchor{elf_targets}all ELF targets (SVR4, Solaris 2, etc.) C++ support is significantly better on ELF targets if you use the @uref{./configure.html#with-gnu-ld,,GNU linker}; duplicate copies of diff -Nrc3pad gcc-3.0.1/gcc/doc/invoke.texi gcc-3.0.2/gcc/doc/invoke.texi *** gcc-3.0.1/gcc/doc/invoke.texi Fri Aug 17 12:20:39 2001 --- gcc-3.0.2/gcc/doc/invoke.texi Wed Oct 17 02:06:44 2001 *************** in the following sections. *** 181,187 **** -fno-nonansi-builtins -fno-operator-names @gol -fno-optional-diags -fpermissive @gol -frepo -fno-rtti -fstats -ftemplate-depth-@var{n} @gol ! -fuse-cxa-atexit -fvtable-gc -fno-weak -nostdinc++ @gol -fno-default-inline -Wctor-dtor-privacy @gol -Wnon-virtual-dtor -Wreorder @gol -Weffc++ -Wno-deprecated @gol --- 181,187 ---- -fno-nonansi-builtins -fno-operator-names @gol -fno-optional-diags -fpermissive @gol -frepo -fno-rtti -fstats -ftemplate-depth-@var{n} @gol ! -fuse-cxa-atexit -fno-weak -nostdinc++ @gol -fno-default-inline -Wctor-dtor-privacy @gol -Wnon-virtual-dtor -Wreorder @gol -Weffc++ -Wno-deprecated @gol *************** behaviour. *** 1670,1676 **** @item -fdiagnostics-show-location=every-line Only meaningful in line-wrapping mode. Instructs the diagnostic messages reporter to emit the same source location information (as ! prefix) for physical lines that result from the process of breaking a a message which is too long to fit on a single line. @end table --- 1670,1676 ---- @item -fdiagnostics-show-location=every-line Only meaningful in line-wrapping mode. Instructs the diagnostic messages reporter to emit the same source location information (as ! prefix) for physical lines that result from the process of breaking a message which is too long to fit on a single line. @end table *************** that contain more that a certain number *** 3693,3699 **** control some of these constants on the command-line using the @option{--param} option. ! In each case, the @var{value} is a integer. The allowable choices for @var{name} are given in the following table: @table @gcctabopt --- 3693,3699 ---- control some of these constants on the command-line using the @option{--param} option. ! In each case, the @var{value} is an integer. The allowable choices for @var{name} are given in the following table: @table @gcctabopt *************** produce code that runs somewhat faster o *** 7336,7343 **** expense of more memory. @item -m128bit-long-double - @itemx -m128bit-long-double - @opindex m128bit-long-double @opindex m128bit-long-double Control the size of @code{long double} type. i386 application binary interface specify the size to be 12 bytes, while modern architectures (Pentium and newer) --- 7336,7341 ---- *************** well as function calling convention for *** 7350,7357 **** will be modified. @item -m96bit-long-double - @itemx -m96bit-long-double - @opindex m96bit-long-double @opindex m96bit-long-double Set the size of @code{long double} to 96 bits as required by the i386 application binary interface. This is the default. --- 7348,7353 ---- *************** Control whether GCC places uninitialized *** 7364,7377 **** @code{data}. @option{-msvr3-shlib} places these locals into @code{bss}. These options are meaningful only on System V Release 3. - @item -mno-wide-multiply - @itemx -mwide-multiply - @opindex mno-wide-multiply - @opindex mwide-multiply - Control whether GCC uses the @code{mul} and @code{imul} that produce - 64-bit results in @code{eax:edx} from 32-bit operands to do @code{long - long} multiplies and 32-bit division by constants. - @item -mrtd @opindex mrtd Use a different function-calling convention, in which functions that --- 7360,7365 ---- *************** may want to reduce the preferred alignme *** 7471,7477 **** --- 7459,7467 ---- @option{-mpreferred-stack-boundary=2}. @item -mpush-args + @itemx -mno-push-args @opindex mpush-args + @opindex mno-push-args Use PUSH operations to store outgoing parameters. This method is shorter and usually equally fast as method using SUB/MOV operations and is enabled by default. In some cases disabling it may improve performance because of *************** improved scheduling and reduced dependen *** 7480,7486 **** @item -maccumulate-outgoing-args @opindex maccumulate-outgoing-args If enabled, the maximum amount of space required for outgoing arguments will be ! computed in the function prologue. This in faster on most modern CPUs because of reduced dependencies, improved scheduling and reduced stack usage when preferred stack boundary is not equal to 2. The drawback is a notable increase in code size. This switch implies @option{-mno-push-args}. --- 7470,7476 ---- @item -maccumulate-outgoing-args @opindex maccumulate-outgoing-args If enabled, the maximum amount of space required for outgoing arguments will be ! computed in the function prologue. This is faster on most modern CPUs because of reduced dependencies, improved scheduling and reduced stack usage when preferred stack boundary is not equal to 2. The drawback is a notable increase in code size. This switch implies @option{-mno-push-args}. *************** and 32532 cpus. This is the default for *** 8513,8519 **** @opindex mmulti-add Try and generate multiply-add floating point instructions @code{polyF} and @code{dotF}. This option is only available if the @option{-m32381} ! option is in effect. Using these instructions requires changes to to register allocation which generally has a negative impact on performance. This option should only be enabled when compiling code particularly likely to make heavy use of multiply-add instructions. --- 8503,8509 ---- @opindex mmulti-add Try and generate multiply-add floating point instructions @code{polyF} and @code{dotF}. This option is only available if the @option{-m32381} ! option is in effect. Using these instructions requires changes to register allocation which generally has a negative impact on performance. This option should only be enabled when compiling code particularly likely to make heavy use of multiply-add instructions. diff -Nrc3pad gcc-3.0.1/gcc/doc/md.texi gcc-3.0.2/gcc/doc/md.texi *** gcc-3.0.1/gcc/doc/md.texi Fri Aug 3 11:50:15 2001 --- gcc-3.0.2/gcc/doc/md.texi Tue Oct 9 16:14:18 2001 *************** insn. *** 2499,2509 **** @cindex @code{call_value_pop} instruction pattern @item @samp{call_pop}, @samp{call_value_pop} Similar to @samp{call} and @samp{call_value}, except used if defined and ! if @code{RETURN_POPS_ARGS} is non-zero. They should emit a @code{parallel} that contains both the function call and a @code{set} to indicate the adjustment made to the frame pointer. ! For machines where @code{RETURN_POPS_ARGS} can be non-zero, the use of these patterns increases the number of functions for which the frame pointer can be eliminated, if desired. --- 2499,2509 ---- @cindex @code{call_value_pop} instruction pattern @item @samp{call_pop}, @samp{call_value_pop} Similar to @samp{call} and @samp{call_value}, except used if defined and ! if @code{RETURN_POPS_ARGS} is nonzero. They should emit a @code{parallel} that contains both the function call and a @code{set} to indicate the adjustment made to the frame pointer. ! For machines where @code{RETURN_POPS_ARGS} can be nonzero, the use of these patterns increases the number of functions for which the frame pointer can be eliminated, if desired. *************** to save any registers or allocate stack *** 2538,2544 **** @findex reload_completed @findex leaf_function_p For such machines, the condition specified in this pattern should only ! be true when @code{reload_completed} is non-zero and the function's epilogue would only be a single instruction. For machines with register windows, the routine @code{leaf_function_p} may be used to determine if a register window push is required. --- 2538,2544 ---- @findex reload_completed @findex leaf_function_p For such machines, the condition specified in this pattern should only ! be true when @code{reload_completed} is nonzero and the function's epilogue would only be a single instruction. For machines with register windows, the routine @code{leaf_function_p} may be used to determine if a register window push is required. *************** that the jump optimizer will not delete *** 2637,2645 **** @cindex @code{decrement_and_branch_until_zero} instruction pattern @item @samp{decrement_and_branch_until_zero} Conditional branch instruction that decrements a register and ! jumps if the register is non-zero. Operand 0 is the register to decrement and test; operand 1 is the label to jump to if the ! register is non-zero. @xref{Looping Patterns}. This optional instruction pattern is only used by the combiner, typically for loops reversed by the loop optimizer when strength --- 2637,2645 ---- @cindex @code{decrement_and_branch_until_zero} instruction pattern @item @samp{decrement_and_branch_until_zero} Conditional branch instruction that decrements a register and ! jumps if the register is nonzero. Operand 0 is the register to decrement and test; operand 1 is the label to jump to if the ! register is nonzero. @xref{Looping Patterns}. This optional instruction pattern is only used by the combiner, typically for loops reversed by the loop optimizer when strength *************** reduction is enabled. *** 2648,2660 **** @cindex @code{doloop_end} instruction pattern @item @samp{doloop_end} Conditional branch instruction that decrements a register and jumps if ! the register is non-zero. This instruction takes five operands: Operand 0 is the register to decrement and test; operand 1 is the number of loop iterations as a @code{const_int} or @code{const0_rtx} if this cannot be determined until run-time; operand 2 is the actual or estimated maximum number of iterations as a @code{const_int}; operand 3 is the number of enclosed loops as a @code{const_int} (an innermost loop has a value of ! 1); operand 4 is the label to jump to if the register is non-zero. @xref{Looping Patterns}. This optional instruction pattern should be defined for machines with --- 2648,2660 ---- @cindex @code{doloop_end} instruction pattern @item @samp{doloop_end} Conditional branch instruction that decrements a register and jumps if ! the register is nonzero. This instruction takes five operands: Operand 0 is the register to decrement and test; operand 1 is the number of loop iterations as a @code{const_int} or @code{const0_rtx} if this cannot be determined until run-time; operand 2 is the actual or estimated maximum number of iterations as a @code{const_int}; operand 3 is the number of enclosed loops as a @code{const_int} (an innermost loop has a value of ! 1); operand 4 is the label to jump to if the register is nonzero. @xref{Looping Patterns}. This optional instruction pattern should be defined for machines with *************** Patterns are matched against @var{insn-p *** 3662,3671 **** circumstances. If an insn needs to be split for delay slot scheduling or insn scheduling, the insn is already known to be valid, which means that it must have been matched by some @code{define_insn} and, if ! @code{reload_completed} is non-zero, is known to satisfy the constraints of that @code{define_insn}. In that case, the new insn patterns must also be insns that are matched by some @code{define_insn} and, if ! @code{reload_completed} is non-zero, must also satisfy the constraints of those definitions. As an example of this usage of @code{define_split}, consider the following --- 3662,3671 ---- circumstances. If an insn needs to be split for delay slot scheduling or insn scheduling, the insn is already known to be valid, which means that it must have been matched by some @code{define_insn} and, if ! @code{reload_completed} is nonzero, is known to satisfy the constraints of that @code{define_insn}. In that case, the new insn patterns must also be insns that are matched by some @code{define_insn} and, if ! @code{reload_completed} is nonzero, must also satisfy the constraints of those definitions. As an example of this usage of @code{define_split}, consider the following *************** expression is that of the @var{default} *** 4261,4267 **** @table @code @cindex @code{const_int} and attribute tests @item (const_int @var{i}) ! This test is true if @var{i} is non-zero and false otherwise. @cindex @code{not} and attributes @cindex @code{ior} and attributes --- 4261,4267 ---- @table @code @cindex @code{const_int} and attribute tests @item (const_int @var{i}) ! This test is true if @var{i} is nonzero and false otherwise. @cindex @code{not} and attributes @cindex @code{ior} and attributes *************** These tests are true if the indicated lo *** 4276,4282 **** This test is true if operand @var{n} of the insn whose attribute value is being determined has mode @var{m} (this part of the test is ignored if @var{m} is @code{VOIDmode}) and the function specified by the string ! @var{pred} returns a non-zero value when passed operand @var{n} and mode @var{m} (this part of the test is ignored if @var{pred} is the null string). --- 4276,4282 ---- This test is true if operand @var{n} of the insn whose attribute value is being determined has mode @var{m} (this part of the test is ignored if @var{m} is @code{VOIDmode}) and the function specified by the string ! @var{pred} returns a nonzero value when passed operand @var{n} and mode @var{m} (this part of the test is ignored if @var{pred} is the null string). diff -Nrc3pad gcc-3.0.1/gcc/doc/objc.texi gcc-3.0.2/gcc/doc/objc.texi *** gcc-3.0.1/gcc/doc/objc.texi Tue Jun 26 15:51:19 2001 --- gcc-3.0.2/gcc/doc/objc.texi Tue Oct 9 06:37:35 2001 *************** The non-atomic types are encoded as foll *** 251,257 **** @end multitable Here are some types and their encodings, as they are generated by the ! compiler on a i386 machine: @sp 1 --- 251,257 ---- @end multitable Here are some types and their encodings, as they are generated by the ! compiler on an i386 machine: @sp 1 diff -Nrc3pad gcc-3.0.1/gcc/doc/rtl.texi gcc-3.0.2/gcc/doc/rtl.texi *** gcc-3.0.1/gcc/doc/rtl.texi Mon Jul 2 17:50:54 2001 --- gcc-3.0.2/gcc/doc/rtl.texi Tue Oct 9 16:14:18 2001 *************** to express conditional jumps. *** 1714,1721 **** @item (cond [@var{test1} @var{value1} @var{test2} @var{value2} @dots{}] @var{default}) Similar to @code{if_then_else}, but more general. Each of @var{test1}, @var{test2}, @dots{} is performed in turn. The result of this expression is ! the @var{value} corresponding to the first non-zero test, or @var{default} if ! none of the tests are non-zero expressions. This is currently not valid for instruction patterns and is supported only for insn attributes. @xref{Insn Attributes}. --- 1714,1721 ---- @item (cond [@var{test1} @var{value1} @var{test2} @var{value2} @dots{}] @var{default}) Similar to @code{if_then_else}, but more general. Each of @var{test1}, @var{test2}, @dots{} is performed in turn. The result of this expression is ! the @var{value} corresponding to the first nonzero test, or @var{default} if ! none of the tests are nonzero expressions. This is currently not valid for instruction patterns and is supported only for insn attributes. @xref{Insn Attributes}. diff -Nrc3pad gcc-3.0.1/gcc/doc/tm.texi gcc-3.0.2/gcc/doc/tm.texi *** gcc-3.0.1/gcc/doc/tm.texi Mon Aug 6 14:26:25 2001 --- gcc-3.0.2/gcc/doc/tm.texi Wed Oct 17 02:06:48 2001 *************** additional options. *** 83,89 **** @item SWITCH_CURTAILS_COMPILATION (@var{char}) A C expression which determines whether the option @option{-@var{char}} stops compilation before the generation of an executable. The value is ! boolean, non-zero if the option does stop an executable from being generated, zero otherwise. By default, this macro is defined as --- 83,89 ---- @item SWITCH_CURTAILS_COMPILATION (@var{char}) A C expression which determines whether the option @option{-@var{char}} stops compilation before the generation of an executable. The value is ! boolean, nonzero if the option does stop an executable from being generated, zero otherwise. By default, this macro is defined as *************** used as the default values for the other *** 718,724 **** @var{level} is the optimization level specified; 2 if @option{-O2} is specified, 1 if @option{-O} is specified, and 0 if neither is specified. ! @var{size} is non-zero if @option{-Os} is specified and zero otherwise. You should not use this macro to change options that are not machine-specific. These should uniformly selected by the same --- 718,724 ---- @var{level} is the optimization level specified; 2 if @option{-O2} is specified, 1 if @option{-O} is specified, and 0 if neither is specified. ! @var{size} is nonzero if @option{-Os} is specified and zero otherwise. You should not use this macro to change options that are not machine-specific. These should uniformly selected by the same *************** function pointers below. *** 788,794 **** @findex init_machine_status @item init_machine_status This is a @code{void (*)(struct function *)} function pointer. If this ! pointer is non-NULL it will be called once per function, before function compilation starts, in order to allow the target to perform any target specific initialisation of the @code{struct function} structure. It is intended that this would be used to initialise the @code{machine} of --- 788,794 ---- @findex init_machine_status @item init_machine_status This is a @code{void (*)(struct function *)} function pointer. If this ! pointer is non-@code{NULL} it will be called once per function, before function compilation starts, in order to allow the target to perform any target specific initialisation of the @code{struct function} structure. It is intended that this would be used to initialise the @code{machine} of *************** that structure. *** 797,810 **** @findex free_machine_status @item free_machine_status This is a @code{void (*)(struct function *)} function pointer. If this ! pointer is non-NULL it will be called once per function, after the function has been compiled, in order to allow any memory allocated during the @code{init_machine_status} function call to be freed. @findex mark_machine_status @item mark_machine_status This is a @code{void (*)(struct function *)} function pointer. If this ! pointer is non-NULL it will be called once per function in order to mark any data items in the @code{struct machine_function} structure which need garbage collection. --- 797,810 ---- @findex free_machine_status @item free_machine_status This is a @code{void (*)(struct function *)} function pointer. If this ! pointer is non-@code{NULL} it will be called once per function, after the function has been compiled, in order to allow any memory allocated during the @code{init_machine_status} function call to be freed. @findex mark_machine_status @item mark_machine_status This is a @code{void (*)(struct function *)} function pointer. If this ! pointer is non-@code{NULL} it will be called once per function in order to mark any data items in the @code{struct machine_function} structure which need garbage collection. *************** exit, if the register is used within the *** 1636,1642 **** @cindex call-used register @cindex call-clobbered register @cindex call-saved register ! A C expression that is non-zero if it is not permissible to store a value of mode @var{mode} in hard register number @var{regno} across a call without some part of it being clobbered. For most machines this macro need not be defined. It is only required for machines that do not --- 1636,1642 ---- @cindex call-used register @cindex call-clobbered register @cindex call-saved register ! A C expression that is nonzero if it is not permissible to store a value of mode @var{mode} in hard register number @var{regno} across a call without some part of it being clobbered. For most machines this macro need not be defined. It is only required for machines that do not *************** general registers. *** 2248,2254 **** @item SECONDARY_MEMORY_NEEDED (@var{class1}, @var{class2}, @var{m}) Certain machines have the property that some registers cannot be copied to some other registers without using memory. Define this macro on ! those machines to be a C expression that is non-zero if objects of mode @var{m} in registers of @var{class1} can only be copied to registers of class @var{class2} by storing a register of @var{class1} into memory and loading that memory location into a register of @var{class2}. --- 2248,2254 ---- @item SECONDARY_MEMORY_NEEDED (@var{class1}, @var{class2}, @var{m}) Certain machines have the property that some registers cannot be copied to some other registers without using memory. Define this macro on ! those machines to be a C expression that is nonzero if objects of mode @var{m} in registers of @var{class1} can only be copied to registers of class @var{class2} by storing a register of @var{class1} into memory and loading that memory location into a register of @var{class2}. *************** to be in specific registers (like an acc *** 2297,2310 **** if the required hard register is used for another purpose across such an insn. ! Define @code{SMALL_REGISTER_CLASSES} to be an expression with a non-zero ! value on these machines. When this macro has a non-zero value, the compiler will try to minimize the lifetime of hard registers. ! It is always safe to define this macro with a non-zero value, but if you unnecessarily define it, you will reduce the amount of optimizations that can be performed in some cases. If you do not define this macro ! with a non-zero value when it is required, the compiler will run out of spill registers and print a fatal error message. For most machines, you should not define this macro at all. --- 2297,2310 ---- if the required hard register is used for another purpose across such an insn. ! Define @code{SMALL_REGISTER_CLASSES} to be an expression with a nonzero ! value on these machines. When this macro has a nonzero value, the compiler will try to minimize the lifetime of hard registers. ! It is always safe to define this macro with a nonzero value, but if you unnecessarily define it, you will reduce the amount of optimizations that can be performed in some cases. If you do not define this macro ! with a nonzero value when it is required, the compiler will run out of spill registers and print a fatal error message. For most machines, you should not define this macro at all. *************** specified first since that is the prefer *** 2928,2934 **** @findex CAN_ELIMINATE @item CAN_ELIMINATE (@var{from-reg}, @var{to-reg}) ! A C expression that returns non-zero if the compiler is allowed to try to replace register number @var{from-reg} with register number @var{to-reg}. This macro need only be defined if @code{ELIMINABLE_REGS} is defined, and will usually be the constant 1, since most of the cases --- 2928,2934 ---- @findex CAN_ELIMINATE @item CAN_ELIMINATE (@var{from-reg}, @var{to-reg}) ! A C expression that returns nonzero if the compiler is allowed to try to replace register number @var{from-reg} with register number @var{to-reg}. This macro need only be defined if @code{ELIMINABLE_REGS} is defined, and will usually be the constant 1, since most of the cases *************** by making @code{FUNCTION_ARG} return 0 w *** 3172,3178 **** You may use the macro @code{MUST_PASS_IN_STACK (@var{mode}, @var{type})} in the definition of this macro to determine if this argument is of a type that must be passed in the stack. If @code{REG_PARM_STACK_SPACE} ! is not defined and @code{FUNCTION_ARG} returns non-zero for such an argument, the compiler will abort. If @code{REG_PARM_STACK_SPACE} is defined, the argument will be computed in the stack and then loaded into a register. --- 3172,3178 ---- You may use the macro @code{MUST_PASS_IN_STACK (@var{mode}, @var{type})} in the definition of this macro to determine if this argument is of a type that must be passed in the stack. If @code{REG_PARM_STACK_SPACE} ! is not defined and @code{FUNCTION_ARG} returns nonzero for such an argument, the compiler will abort. If @code{REG_PARM_STACK_SPACE} is defined, the argument will be computed in the stack and then loaded into a register. *************** By default if a function has a target sp *** 4051,4057 **** it will not be inlined. This behaviour can be overridden if the target defines the @samp{FUNCTION_ATTRIBUTE_INLINABLE_P} macro. This macro takes one argument, a @samp{DECL} describing the function. It should ! return non-zero if the function can be inlined, otherwise it should return 0. @node Tail Calling --- 4051,4057 ---- it will not be inlined. This behaviour can be overridden if the target defines the @samp{FUNCTION_ATTRIBUTE_INLINABLE_P} macro. This macro takes one argument, a @samp{DECL} describing the function. It should ! return nonzero if the function can be inlined, otherwise it should return 0. @node Tail Calling *************** This is about addressing modes. *** 4644,4657 **** @itemx HAVE_PRE_DECREMENT @itemx HAVE_POST_INCREMENT @itemx HAVE_POST_DECREMENT ! A C expression that is non-zero if the machine supports pre-increment, pre-decrement, post-increment, or post-decrement addressing respectively. @findex HAVE_POST_MODIFY_DISP @findex HAVE_PRE_MODIFY_DISP @item HAVE_PRE_MODIFY_DISP @itemx HAVE_POST_MODIFY_DISP ! A C expression that is non-zero if the machine supports pre- or post-address side-effect generation involving constants other than the size of the memory operand. --- 4644,4657 ---- @itemx HAVE_PRE_DECREMENT @itemx HAVE_POST_INCREMENT @itemx HAVE_POST_DECREMENT ! A C expression that is nonzero if the machine supports pre-increment, pre-decrement, post-increment, or post-decrement addressing respectively. @findex HAVE_POST_MODIFY_DISP @findex HAVE_PRE_MODIFY_DISP @item HAVE_PRE_MODIFY_DISP @itemx HAVE_POST_MODIFY_DISP ! A C expression that is nonzero if the machine supports pre- or post-address side-effect generation involving constants other than the size of the memory operand. *************** the size of the memory operand. *** 4659,4665 **** @findex HAVE_PRE_MODIFY_REG @item HAVE_PRE_MODIFY_REG @itemx HAVE_POST_MODIFY_REG ! A C expression that is non-zero if the machine supports pre- or post-address side-effect generation involving a register displacement. @findex CONSTANT_ADDRESS_P --- 4659,4665 ---- @findex HAVE_PRE_MODIFY_REG @item HAVE_PRE_MODIFY_REG @itemx HAVE_POST_MODIFY_REG ! A C expression that is nonzero if the machine supports pre- or post-address side-effect generation involving a register displacement. @findex CONSTANT_ADDRESS_P *************** if the @samp{mov@var{m}} pattern's const *** 5174,5180 **** @item MEMORY_MOVE_COST (@var{mode}, @var{class}, @var{in}) A C expression for the cost of moving data of mode @var{mode} between a register of class @var{class} and memory; @var{in} is zero if the value ! is to be written to memory, non-zero if it is to be read in. This cost is relative to those in @code{REGISTER_MOVE_COST}. If moving between registers and memory is more expensive than between two registers, you should define this macro to express the relative cost. --- 5174,5180 ---- @item MEMORY_MOVE_COST (@var{mode}, @var{class}, @var{in}) A C expression for the cost of moving data of mode @var{mode} between a register of class @var{class} and memory; @var{in} is zero if the value ! is to be written to memory, nonzero if it is to be read in. This cost is relative to those in @code{REGISTER_MOVE_COST}. If moving between registers and memory is more expensive than between two registers, you should define this macro to express the relative cost. *************** Define this macro to be the value 1 if m *** 5243,5257 **** than aligned accesses, for example if they are emulated in a trap handler. ! When this macro is non-zero, the compiler will act as if ! @code{STRICT_ALIGNMENT} were non-zero when generating code for block moves. This can cause significantly more instructions to be produced. ! Therefore, do not set this macro non-zero if unaligned accesses only add a cycle or two to the time for a memory access. If the value of this macro is always zero, it need not be defined. If ! this macro is defined, it should produce a non-zero value when ! @code{STRICT_ALIGNMENT} is non-zero. @findex DONT_REDUCE_ADDR @item DONT_REDUCE_ADDR --- 5243,5257 ---- than aligned accesses, for example if they are emulated in a trap handler. ! When this macro is nonzero, the compiler will act as if ! @code{STRICT_ALIGNMENT} were nonzero when generating code for block moves. This can cause significantly more instructions to be produced. ! Therefore, do not set this macro nonzero if unaligned accesses only add a cycle or two to the time for a memory access. If the value of this macro is always zero, it need not be defined. If ! this macro is defined, it should produce a nonzero value when ! @code{STRICT_ALIGNMENT} is nonzero. @findex DONT_REDUCE_ADDR @item DONT_REDUCE_ADDR *************** data section. *** 5492,5498 **** @findex JUMP_TABLES_IN_TEXT_SECTION @item JUMP_TABLES_IN_TEXT_SECTION ! Define this macro to be an expression with a non-zero value if jump tables (for @code{tablejump} insns) should be output in the text section, along with the assembler instructions. Otherwise, the readonly data section is used. --- 5492,5498 ---- @findex JUMP_TABLES_IN_TEXT_SECTION @item JUMP_TABLES_IN_TEXT_SECTION ! Define this macro to be an expression with a nonzero value if jump tables (for @code{tablejump} insns) should be output in the text section, along with the assembler instructions. Otherwise, the readonly data section is used. *************** Berkeley Unix assembler, do not define t *** 5818,5824 **** @findex CONSTANT_POOL_BEFORE_FUNCTION @item CONSTANT_POOL_BEFORE_FUNCTION You may define this macro as a C expression. You should define the ! expression to have a non-zero value if GCC should output the constant pool for a function before the code for the function, or a zero value if GCC should output the constant pool after the function. If you do not define this macro, the usual case, GCC will output the constant --- 5818,5824 ---- @findex CONSTANT_POOL_BEFORE_FUNCTION @item CONSTANT_POOL_BEFORE_FUNCTION You may define this macro as a C expression. You should define the ! expression to have a nonzero value if GCC should output the constant pool for a function before the code for the function, or a zero value if GCC should output the constant pool after the function. If you do not define this macro, the usual case, GCC will output the constant *************** buffer in which to store the name; its l *** 6367,6373 **** The argument @var{is_inst} specifies whether the method is an instance method or a class method; @var{class_name} is the name of the class; ! @var{cat_name} is the name of the category (or NULL if the method is not in a category); and @var{sel_name} is the name of the selector. On systems where the assembler can handle quoted names, you can use this --- 6367,6373 ---- The argument @var{is_inst} specifies whether the method is an instance method or a class method; @var{class_name} is the name of the class; ! @var{cat_name} is the name of the category (or @code{NULL} if the method is not in a category); and @var{sel_name} is the name of the selector. On systems where the assembler can handle quoted names, you can use this *************** or @code{MACHINE_DEPENDENT_REORG}. *** 7768,7774 **** You can have multiple entities that are mode-switched, and select at run time which entities actually need it. @code{OPTIMIZE_MODE_SWITCHING} should ! return non-zero for any @var{entity} that that needs mode-switching. If you define this macro, you also have to define @code{NUM_MODES_FOR_MODE_SWITCHING}, @code{MODE_NEEDED}, @code{MODE_PRIORITY_TO_MODE} and @code{EMIT_MODE_SET}. --- 7768,7774 ---- You can have multiple entities that are mode-switched, and select at run time which entities actually need it. @code{OPTIMIZE_MODE_SWITCHING} should ! return nonzero for any @var{entity} that needs mode-switching. If you define this macro, you also have to define @code{NUM_MODES_FOR_MODE_SWITCHING}, @code{MODE_NEEDED}, @code{MODE_PRIORITY_TO_MODE} and @code{EMIT_MODE_SET}. *************** at run-time. *** 7970,7976 **** A C expression that is nonzero if on this machine the number of bits actually used for the count of a shift operation is equal to the number of bits needed to represent the size of the object being shifted. When ! this macro is non-zero, the compiler will assume that it is safe to omit a sign-extend, zero-extend, and certain bitwise `and' instructions that truncates the count of a shift operation. On machines that have instructions that act on bit-fields at variable positions, which may --- 7970,7976 ---- A C expression that is nonzero if on this machine the number of bits actually used for the count of a shift operation is equal to the number of bits needed to represent the size of the object being shifted. When ! this macro is nonzero, the compiler will assume that it is safe to omit a sign-extend, zero-extend, and certain bitwise `and' instructions that truncates the count of a shift operation. On machines that have instructions that act on bit-fields at variable positions, which may *************** instructions. *** 8111,8117 **** @findex FLOAT_STORE_FLAG_VALUE @item FLOAT_STORE_FLAG_VALUE (@var{mode}) ! A C expression that gives a non-zero @code{REAL_VALUE_TYPE} value that is returned when comparison operators with floating-point results are true. Define this macro on machine that have comparison operations that return floating-point values. If there are no such operations, do not define --- 8111,8117 ---- @findex FLOAT_STORE_FLAG_VALUE @item FLOAT_STORE_FLAG_VALUE (@var{mode}) ! A C expression that gives a nonzero @code{REAL_VALUE_TYPE} value that is returned when comparison operators with floating-point results are true. Define this macro on machine that have comparison operations that return floating-point values. If there are no such operations, do not define diff -Nrc3pad gcc-3.0.1/gcc/dwarf2out.c gcc-3.0.2/gcc/dwarf2out.c *** gcc-3.0.1/gcc/dwarf2out.c Wed Jul 18 21:51:51 2001 --- gcc-3.0.2/gcc/dwarf2out.c Fri Oct 5 11:02:02 2001 *************** static void def_cfa_1 PARAMS ((const *** 293,298 **** --- 293,299 ---- #ifndef FUNC_END_LABEL #define FUNC_END_LABEL "LFE" #endif + #define FRAME_BEGIN_LABEL "Lframe" #define CIE_AFTER_SIZE_LABEL "LSCIE" #define CIE_END_LABEL "LECIE" #define CIE_LENGTH_LABEL "LLCIE" *************** output_call_frame_info (for_eh) *** 1720,1726 **** register unsigned long i; register dw_fde_ref fde; register dw_cfi_ref cfi; ! char l1[20], l2[20]; int any_lsda_needed = 0; char augmentation[6]; int augmentation_size; --- 1721,1727 ---- register unsigned long i; register dw_fde_ref fde; register dw_cfi_ref cfi; ! char l1[20], l2[20], section_start_label[20]; int any_lsda_needed = 0; char augmentation[6]; int augmentation_size; *************** output_call_frame_info (for_eh) *** 1759,1769 **** ASM_GLOBALIZE_LABEL (asm_out_file, IDENTIFIER_POINTER (label)); ASM_OUTPUT_LABEL (asm_out_file, IDENTIFIER_POINTER (label)); #endif - assemble_label ("__FRAME_BEGIN__"); } else ASM_OUTPUT_SECTION (asm_out_file, FRAME_SECTION); /* Output the CIE. */ ASM_GENERATE_INTERNAL_LABEL (l1, CIE_AFTER_SIZE_LABEL, for_eh); ASM_GENERATE_INTERNAL_LABEL (l2, CIE_END_LABEL, for_eh); --- 1760,1772 ---- ASM_GLOBALIZE_LABEL (asm_out_file, IDENTIFIER_POINTER (label)); ASM_OUTPUT_LABEL (asm_out_file, IDENTIFIER_POINTER (label)); #endif } else ASM_OUTPUT_SECTION (asm_out_file, FRAME_SECTION); + ASM_GENERATE_INTERNAL_LABEL (section_start_label, FRAME_BEGIN_LABEL, for_eh); + ASM_OUTPUT_LABEL (asm_out_file, section_start_label); + /* Output the CIE. */ ASM_GENERATE_INTERNAL_LABEL (l1, CIE_AFTER_SIZE_LABEL, for_eh); ASM_GENERATE_INTERNAL_LABEL (l2, CIE_END_LABEL, for_eh); *************** output_call_frame_info (for_eh) *** 1894,1912 **** "FDE Length"); ASM_OUTPUT_LABEL (asm_out_file, l1); - /* ??? This always emits a 4 byte offset when for_eh is true, but it - emits a target dependent sized offset when for_eh is not true. - This inconsistency may confuse gdb. The only case where we need a - non-4 byte offset is for the Irix6 N64 ABI, so we may lose SGI - compatibility if we emit a 4 byte offset. We need a 4 byte offset - though in order to be compatible with the dwarf_fde struct in frame.c. - If the for_eh case is changed, then the struct in frame.c has - to be adjusted appropriately. */ if (for_eh) ! dw2_asm_output_delta (4, l1, "__FRAME_BEGIN__", "FDE CIE offset"); else ! dw2_asm_output_offset (DWARF_OFFSET_SIZE, ! stripattributes (FRAME_SECTION), "FDE CIE offset"); if (for_eh) --- 1897,1906 ---- "FDE Length"); ASM_OUTPUT_LABEL (asm_out_file, l1); if (for_eh) ! dw2_asm_output_delta (4, l1, section_start_label, "FDE CIE offset"); else ! dw2_asm_output_offset (DWARF_OFFSET_SIZE, section_start_label, "FDE CIE offset"); if (for_eh) *************** void *** 2098,2113 **** dwarf2out_frame_finish () { /* Output call frame information. */ - #ifdef MIPS_DEBUGGING_INFO if (write_symbols == DWARF2_DEBUG) output_call_frame_info (0); ! if (flag_unwind_tables || (flag_exceptions && ! USING_SJLJ_EXCEPTIONS)) ! output_call_frame_info (1); ! #else ! if (write_symbols == DWARF2_DEBUG ! || flag_unwind_tables || (flag_exceptions && ! USING_SJLJ_EXCEPTIONS)) output_call_frame_info (1); - #endif } /* And now, the subset of the debugging information support code necessary --- 2092,2101 ---- dwarf2out_frame_finish () { /* Output call frame information. */ if (write_symbols == DWARF2_DEBUG) output_call_frame_info (0); ! if (! USING_SJLJ_EXCEPTIONS && (flag_unwind_tables || flag_exceptions)) output_call_frame_info (1); } /* And now, the subset of the debugging information support code necessary *************** static unsigned decl_die_table_in_use; *** 3210,3226 **** of declaration scopes at the current scope and containing scopes. This table is used to find the proper place to define type declaration DIE's. */ ! static tree *decl_scope_table; ! ! /* Number of elements currently allocated for the decl_scope_table. */ ! static int decl_scope_table_allocated; ! ! /* Current level of nesting of declaration scopes. */ ! static int decl_scope_depth; ! ! /* Size (in elements) of increments by which we may expand the ! decl_scope_table. */ ! #define DECL_SCOPE_TABLE_INCREMENT 64 /* A pointer to the base of a list of references to DIE's that are uniquely identified by their tag, presence/absence of --- 3198,3204 ---- of declaration scopes at the current scope and containing scopes. This table is used to find the proper place to define type declaration DIE's. */ ! varray_type decl_scope_table; /* A pointer to the base of a list of references to DIE's that are uniquely identified by their tag, presence/absence of *************** static unsigned arange_table_in_use; *** 3290,3309 **** #define ARANGE_TABLE_INCREMENT 64 /* A pointer to the base of a list of incomplete types which might be ! completed at some later time. */ ! ! static tree *incomplete_types_list; ! ! /* Number of elements currently allocated for the incomplete_types_list. */ ! static unsigned incomplete_types_allocated; ! ! /* Number of elements of incomplete_types_list currently in use. */ ! static unsigned incomplete_types; ! ! /* Size (in elements) of increments by which we may expand the incomplete ! types list. Actually, a single hunk of space of this size should ! be enough for most typical programs. */ ! #define INCOMPLETE_TYPES_INCREMENT 64 /* Record whether the function being analyzed contains inlined functions. */ static int current_function_has_inlines; --- 3268,3278 ---- #define ARANGE_TABLE_INCREMENT 64 /* A pointer to the base of a list of incomplete types which might be ! completed at some later time. incomplete_types_list needs to be a VARRAY ! because we want to tell the garbage collector about it. If we don't tell ! the garbage collector about it, we can garbage collect live data. ! Bug 4215.*/ ! varray_type incomplete_types; /* Record whether the function being analyzed contains inlined functions. */ static int current_function_has_inlines; *************** static void *** 8789,8814 **** push_decl_scope (scope) tree scope; { ! /* Make room in the decl_scope_table, if necessary. */ ! if (decl_scope_table_allocated == decl_scope_depth) ! { ! decl_scope_table_allocated += DECL_SCOPE_TABLE_INCREMENT; ! decl_scope_table ! = (tree *) xrealloc (decl_scope_table, ! decl_scope_table_allocated * sizeof (tree)); ! } ! ! decl_scope_table[decl_scope_depth] = scope; ! decl_scope_depth++; } /* Pop a declaration scope. */ static inline void pop_decl_scope () { ! if (decl_scope_depth <= 0) abort (); ! --decl_scope_depth; } /* Return the DIE for the scope that immediately contains this type. --- 8758,8773 ---- push_decl_scope (scope) tree scope; { ! VARRAY_PUSH_TREE (decl_scope_table, scope); } /* Pop a declaration scope. */ static inline void pop_decl_scope () { ! if (VARRAY_ACTIVE_SIZE (decl_scope_table) <= 0) abort (); ! VARRAY_POP (decl_scope_table); } /* Return the DIE for the scope that immediately contains this type. *************** scope_die_for (t, context_die) *** 8850,8857 **** first we check to see if we're in the middle of emitting it so we know where the new DIE should go. */ ! for (i = decl_scope_depth - 1; i >= 0; --i) ! if (decl_scope_table[i] == containing_scope) break; if (i < 0) --- 8809,8816 ---- first we check to see if we're in the middle of emitting it so we know where the new DIE should go. */ ! for (i = VARRAY_ACTIVE_SIZE (decl_scope_table) - 1; i >= 0; --i) ! if (VARRAY_TREE (decl_scope_table, i) == containing_scope) break; if (i < 0) *************** gen_entry_point_die (decl, context_die) *** 9105,9124 **** #endif /* Remember a type in the incomplete_types_list. */ - static void add_incomplete_type (type) tree type; { ! if (incomplete_types == incomplete_types_allocated) ! { ! incomplete_types_allocated += INCOMPLETE_TYPES_INCREMENT; ! incomplete_types_list ! = (tree *) xrealloc (incomplete_types_list, ! sizeof (tree) * incomplete_types_allocated); ! } ! ! incomplete_types_list[incomplete_types++] = type; } /* Walk through the list of incomplete types again, trying once more to --- 9064,9074 ---- #endif /* Remember a type in the incomplete_types_list. */ static void add_incomplete_type (type) tree type; { ! VARRAY_PUSH_TREE (incomplete_types, type); } /* Walk through the list of incomplete types again, trying once more to *************** add_incomplete_type (type) *** 9127,9139 **** static void retry_incomplete_types () { ! register tree type; ! ! while (incomplete_types) { ! --incomplete_types; ! type = incomplete_types_list[incomplete_types]; ! gen_type_die (type, comp_unit_die); } } --- 9077,9086 ---- static void retry_incomplete_types () { ! int i; ! for (i = VARRAY_ACTIVE_SIZE (incomplete_types) - 1; i >= 0; i--) { ! gen_type_die (VARRAY_TREE (incomplete_types, i), comp_unit_die); } } *************** dwarf2out_init (asm_out_file, main_input *** 11195,11204 **** decl_die_table_in_use = 0; /* Allocate the initial hunk of the decl_scope_table. */ ! decl_scope_table ! = (tree *) xcalloc (DECL_SCOPE_TABLE_INCREMENT, sizeof (tree)); ! decl_scope_table_allocated = DECL_SCOPE_TABLE_INCREMENT; ! decl_scope_depth = 0; /* Allocate the initial hunk of the abbrev_die_table. */ abbrev_die_table --- 11142,11149 ---- decl_die_table_in_use = 0; /* Allocate the initial hunk of the decl_scope_table. */ ! VARRAY_TREE_INIT (decl_scope_table, 256, "decl_scope_table"); ! ggc_add_tree_varray_root (&decl_scope_table, 1); /* Allocate the initial hunk of the abbrev_die_table. */ abbrev_die_table *************** dwarf2out_init (asm_out_file, main_input *** 11222,11227 **** --- 11167,11175 ---- taken as being relative to the directory from which the compiler was invoked when the given (base) source file was compiled. */ comp_unit_die = gen_compile_unit_die (main_input_filename); + + VARRAY_TREE_INIT (incomplete_types, 64, "incomplete_types"); + ggc_add_tree_varray_root (&incomplete_types, 1); VARRAY_RTX_INIT (used_rtx_varray, 32, "used_rtx_varray"); ggc_add_rtx_varray_root (&used_rtx_varray, 1); diff -Nrc3pad gcc-3.0.1/gcc/except.c gcc-3.0.2/gcc/except.c *** gcc-3.0.1/gcc/except.c Wed Aug 8 14:19:56 2001 --- gcc-3.0.2/gcc/except.c Mon Sep 17 16:12:47 2001 *************** dw2_build_landing_pads () *** 1865,1870 **** --- 1865,1871 ---- { struct eh_region *region = cfun->eh->region_array[i]; rtx seq; + bool clobbers_hard_regs = false; /* Mind we don't process a region more than once. */ if (!region || region->region_number != i) *************** dw2_build_landing_pads () *** 1901,1907 **** if (r == INVALID_REGNUM) break; if (! call_used_regs[r]) ! emit_insn (gen_rtx_CLOBBER (VOIDmode, gen_rtx_REG (Pmode, r))); } emit_move_insn (cfun->eh->exc_ptr, --- 1902,1920 ---- if (r == INVALID_REGNUM) break; if (! call_used_regs[r]) ! { ! emit_insn (gen_rtx_CLOBBER (VOIDmode, gen_rtx_REG (Pmode, r))); ! clobbers_hard_regs = true; ! } ! } ! ! if (clobbers_hard_regs) ! { ! /* @@@ This is a kludge. Not all machine descriptions define a ! blockage insn, but we must not allow the code we just generated ! to be reordered by scheduling. So emit an ASM_INPUT to act as ! blockage insn. */ ! emit_insn (gen_rtx_ASM_INPUT (VOIDmode, "")); } emit_move_insn (cfun->eh->exc_ptr, diff -Nrc3pad gcc-3.0.1/gcc/expr.c gcc-3.0.2/gcc/expr.c *** gcc-3.0.1/gcc/expr.c Sun Jul 1 13:48:02 2001 --- gcc-3.0.2/gcc/expr.c Fri Sep 21 18:33:19 2001 *************** expand_expr (exp, target, tmode, modifie *** 8706,8711 **** --- 8706,8716 ---- case EXC_PTR_EXPR: return get_exception_pointer (cfun); + case FDESC_EXPR: + /* Function descriptors are not valid except for as + initialization constants, and should not be expanded. */ + abort (); + default: return (*lang_expand_expr) (exp, original_target, tmode, modifier); } diff -Nrc3pad gcc-3.0.1/gcc/f/ChangeLog gcc-3.0.2/gcc/f/ChangeLog *** gcc-3.0.1/gcc/f/ChangeLog Sun Aug 19 14:08:16 2001 --- gcc-3.0.2/gcc/f/ChangeLog Tue Oct 23 10:19:41 2001 *************** *** 1,3 **** --- 1,11 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + + 2001-10-23 Joseph S. Myers + + * g77.texi (Sending Patches): Remove. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/gcc/f/g77.info gcc-3.0.2/gcc/f/g77.info *** gcc-3.0.1/gcc/f/g77.info Sun Aug 19 18:52:16 2001 --- gcc-3.0.2/gcc/f/g77.info Tue Oct 23 11:11:05 2001 *************** g77.info-14: 616496 *** 54,63 **** g77.info-15: 665589 g77.info-16: 715152 g77.info-17: 763614 ! g77.info-18: 813392 ! g77.info-19: 860952 ! g77.info-20: 909228 ! g77.info-21: 912866  Tag Table: (Indirect) --- 54,62 ---- g77.info-15: 665589 g77.info-16: 715152 g77.info-17: 763614 ! g77.info-18: 812675 ! g77.info-19: 862453 ! g77.info-20: 907306  Tag Table: (Indirect) *************** Node: Order of Side Effects769613 *** 711,767 **** Node: Warnings and Errors771341 Node: Open Questions773025 Node: Bugs773494 ! Node: Bug Criteria774999 ! Node: Bug Lists781232 ! Node: Bug Reporting782021 ! Node: Sending Patches795645 ! Node: Service801131 ! Node: Adding Options801597 ! Node: Projects806190 ! Node: Efficiency807125 ! Node: Better Optimization810022 ! Node: Simplify Porting813392 ! Node: More Extensions815147 ! Node: Machine Model818235 ! Node: Internals Documentation819521 ! Node: Internals Improvements819910 ! Node: Better Diagnostics823454 ! Node: Front End824371 ! Node: Overview of Sources825307 ! Node: Overview of Translation Process832696 ! Node: g77stripcard836974 ! Node: lex.c839451 ! Node: sta.c849227 ! Node: sti.c849338 ! Node: stq.c849449 ! Node: stb.c849560 ! Node: expr.c849672 ! Node: stc.c849786 ! Node: std.c849898 ! Node: ste.c850009 ! Node: Gotchas (Transforming)850137 ! Node: TBD (Transforming)858256 ! Node: Philosophy of Code Generation860952 ! Node: Two-pass Design866856 ! Node: Two-pass Code868013 ! Node: Why Two Passes868746 ! Node: Challenges Posed874814 ! Node: Transforming Statements877298 ! Node: Statements Needing Temporaries878148 ! Node: Transforming DO WHILE880912 ! Node: Transforming Iterative DO882095 ! Node: Transforming Block IF882924 ! Node: Transforming SELECT CASE884289 ! Node: Transforming Expressions887511 ! Node: Internal Naming Conventions889500 ! Node: Diagnostics892500 ! Node: CMPAMBIG893890 ! Node: EXPIMP900307 ! Node: INTGLOB901543 ! Node: LEX903787 ! Node: GLOBALS909228 ! Node: LINKFAIL911892 ! Node: Y2KBAD912516 ! Node: Index912866  End Tag Table --- 710,765 ---- Node: Warnings and Errors771341 Node: Open Questions773025 Node: Bugs773494 ! Node: Bug Criteria774933 ! Node: Bug Lists781166 ! Node: Bug Reporting781955 ! Node: Service795571 ! Node: Adding Options796037 ! Node: Projects800630 ! Node: Efficiency801565 ! Node: Better Optimization804462 ! Node: Simplify Porting807832 ! Node: More Extensions809587 ! Node: Machine Model812675 ! Node: Internals Documentation813961 ! Node: Internals Improvements814350 ! Node: Better Diagnostics817894 ! Node: Front End818811 ! Node: Overview of Sources819747 ! Node: Overview of Translation Process827136 ! Node: g77stripcard831414 ! Node: lex.c833891 ! Node: sta.c843667 ! Node: sti.c843778 ! Node: stq.c843889 ! Node: stb.c844000 ! Node: expr.c844112 ! Node: stc.c844226 ! Node: std.c844338 ! Node: ste.c844449 ! Node: Gotchas (Transforming)844577 ! Node: TBD (Transforming)852696 ! Node: Philosophy of Code Generation855392 ! Node: Two-pass Design861296 ! Node: Two-pass Code862453 ! Node: Why Two Passes863186 ! Node: Challenges Posed869254 ! Node: Transforming Statements871738 ! Node: Statements Needing Temporaries872588 ! Node: Transforming DO WHILE875352 ! Node: Transforming Iterative DO876535 ! Node: Transforming Block IF877364 ! Node: Transforming SELECT CASE878729 ! Node: Transforming Expressions881951 ! Node: Internal Naming Conventions883940 ! Node: Diagnostics886940 ! Node: CMPAMBIG888330 ! Node: EXPIMP894747 ! Node: INTGLOB895983 ! Node: LEX898227 ! Node: GLOBALS903668 ! Node: LINKFAIL906332 ! Node: Y2KBAD906956 ! Node: Index907306  End Tag Table diff -Nrc3pad gcc-3.0.1/gcc/f/g77.info-17 gcc-3.0.2/gcc/f/g77.info-17 *** gcc-3.0.1/gcc/f/g77.info-17 Sun Aug 19 18:52:16 2001 --- gcc-3.0.2/gcc/f/g77.info-17 Tue Oct 23 11:11:05 2001 *************** information that makes for fixing the bu *** 296,302 **** * Criteria: Bug Criteria. Have you really found a bug? * Where: Bug Lists. Where to send your bug report. * Reporting: Bug Reporting. How to report a bug effectively. - * Patches: Sending Patches. How to send a patch for GNU Fortran. *Note Known Causes of Trouble with GNU Fortran: Trouble, for information on problems we already know about. --- 296,301 ---- *************** bug reports by mail to the proper mailin *** 479,485 **** Boston, MA 02111-1307, USA  ! File: g77.info, Node: Bug Reporting, Next: Sending Patches, Prev: Bug Lists, Up: Bugs How to Report Bugs ================== --- 478,484 ---- Boston, MA 02111-1307, USA  ! File: g77.info, Node: Bug Reporting, Prev: Bug Lists, Up: Bugs How to Report Bugs ================== *************** these things: *** 739,746 **** your patch should be an improvement, we won't install it. A test case will help us to understand. ! *Note Sending Patches::, for guidelines on how to make it easy for ! us to understand and install your patches. * A guess about what the bug is or what it depends on. --- 738,745 ---- your patch should be an improvement, we won't install it. A test case will help us to understand. ! See `http://gcc.gnu.org/contribute.html' for guidelines on how to ! make it easy for us to understand and install your patches. * A guess about what the bug is or what it depends on. *************** these things: *** 755,876 **** should be able to reproduce the crash ourselves.  - File: g77.info, Node: Sending Patches, Prev: Bug Reporting, Up: Bugs - - Sending Patches for GNU Fortran - =============================== - - If you would like to write bug fixes or improvements for the GNU - Fortran compiler, that is very helpful. Send suggested fixes to the - mailing list for patches, . - - Please follow these guidelines so we can study your patches - efficiently. If you don't follow these guidelines, your information - might still be useful, but using it will take extra work. Maintaining - GNU Fortran is a lot of work in the best of circumstances, and we can't - keep up unless you do your best to help. - - * Send an explanation with your changes of what problem they fix or - what improvement they bring about. For a bug fix, just include a - copy of the bug report, and explain why the change fixes the bug. - - (Referring to a bug report is not as good as including it, because - then we will have to look it up, and we have probably already - deleted it if we've already fixed the bug.) - - * Always include a proper bug report for the problem you think you - have fixed. We need to convince ourselves that the change is - right before installing it. Even if it is right, we might have - trouble judging it if we don't have a way to reproduce the problem. - - * Include all the comments that are appropriate to help people - reading the source in the future understand why this change was - needed. - - * Don't mix together changes made for different reasons. Send them - _individually_. - - If you make two changes for separate reasons, then we might not - want to install them both. We might want to install just one. If - you send them all jumbled together in a single set of diffs, we - have to do extra work to disentangle them--to figure out which - parts of the change serve which purpose. If we don't have time - for this, we might have to ignore your changes entirely. - - If you send each change as soon as you have written it, with its - own explanation, then the two changes never get tangled up, and we - can consider each one properly without any extra work to - disentangle them. - - Ideally, each change you send should be impossible to subdivide - into parts that we might want to consider separately, because each - of its parts gets its motivation from the other parts. - - * Send each change as soon as that change is finished. Sometimes - people think they are helping us by accumulating many changes to - send them all together. As explained above, this is absolutely - the worst thing you could do. - - Since you should send each change separately, you might as well - send it right away. That gives us the option of installing it - immediately if it is important. - - * Use `diff -c' to make your diffs. Diffs without context are hard - for us to install reliably. More than that, they make it hard for - us to study the diffs to decide whether we want to install them. - Unidiff format is better than contextless diffs, but not as easy - to read as `-c' format. - - If you have GNU `diff', use `diff -cp', which shows the name of the - function that each change occurs in. (The maintainer of GNU - Fortran currently uses `diff -rcp2N'.) - - * Write the change log entries for your changes. We get lots of - changes, and we don't have time to do all the change log writing - ourselves. - - Read the `ChangeLog' file to see what sorts of information to put - in, and to learn the style that we use. The purpose of the change - log is to show people where to find what was changed. So you need - to be specific about what functions you changed; in large - functions, it's often helpful to indicate where within the - function the change was. - - On the other hand, once you have shown people where to find the - change, you need not explain its purpose. Thus, if you add a new - function, all you need to say about it is that it is new. If you - feel that the purpose needs explaining, it probably does--but the - explanation will be much more useful if you put it in comments in - the code. - - If you would like your name to appear in the header line for who - made the change, send us the header line. - - * When you write the fix, keep in mind that we can't install a - change that would break other systems. - - People often suggest fixing a problem by changing - machine-independent files such as `toplev.c' to do something - special that a particular system needs. Sometimes it is totally - obvious that such changes would break GNU Fortran for almost all - users. We can't possibly make a change like that. At best it - might tell us how to write another patch that would solve the - problem acceptably. - - Sometimes people send fixes that _might_ be an improvement in - general--but it is hard to be sure of this. It's hard to install - such changes because we have to study them very carefully. Of - course, a good explanation of the reasoning by which you concluded - the change was correct can help convince us. - - The safest changes are changes to the configuration files for a - particular machine. These are safe because they can't create new - bugs on other machines. - - Please help us keep up with the workload by designing the patch in - a form that is good to install. - -  File: g77.info, Node: Service, Next: Adding Options, Prev: Bugs, Up: Top How To Get Help with GNU Fortran --- 754,759 ---- *************** the feature-adding work. *** 1133,1136 **** --- 1016,1124 ---- back into a register after the call. (It normally has to do that, unless it knows `FOO' never modifies its passed-by-reference argument, which is rarely the case for Fortran-77 code.) + +  + File: g77.info, Node: Simplify Porting, Next: More Extensions, Prev: Better Optimization, Up: Projects + + Simplify Porting + ================ + + Making `g77' easier to configure, port, build, and install, either + as a single-system compiler or as a cross-compiler, would be very + useful. + + * A new library (replacing `libg2c') should improve portability as + well as produce more optimal code. Further, `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 `FILE *' descriptors. + + * Possibly related to a new library, `g77' should produce the + equivalent of a `gcc' `main(argc, argv)' function when it compiles + a main program unit, instead of compiling something that must be + called by a library implementation of `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 `breakpoint + MAIN__' followed by `run', and so on. + + * The GBE needs to understand the difference between alignment + requirements and desires. For example, on Intel x86 machines, + `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 _recommendations_ as long + as they don't violate the actual processor _requirements_. + +  + File: g77.info, Node: More Extensions, Next: Machine Model, Prev: Simplify Porting, Up: Projects + + More Extensions + =============== + + These extensions are not the sort of things users ask for "by name", + but they might improve the usability of `g77', and Fortran in general, + in the long run. Some of these items really pertain to improving `g77' + internals so that some popular extensions can be more easily supported. + + * 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. + + * Consider adding a `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 `PARAMETER' statement when people really need + typelessness in a maintainable, portable, clearly documented way. + Maybe `TYPELESS' would include `CHARACTER', `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.) + + * Support `OPEN(...,KEY=(...),...)'. + + * Support arbitrary file unit numbers, instead of limiting them to 0 + through `MXUNIT-1'. (This is a `libg2c' issue.) + + * `OPEN(NOSPANBLOCKS,...)' is treated as + `OPEN(UNIT=NOSPANBLOCKS,...)', so a later `UNIT=' in the first + example is invalid. Make sure this is what users of this feature + would expect. + + * Currently `g77' disallows `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. + + * Support `STRUCTURE', `UNION', `MAP', and `RECORD' fully. + Currently there is no support at all for `%FILL' in `STRUCTURE' + and related syntax, whereas the rest of the stuff has at least + some parsing support. This requires either major changes to + `libg2c' or its replacement. + + * F90 and `g77' probably disagree about label scoping relative to + `INTERFACE' and `END INTERFACE', and their contained procedure + interface bodies (blocks?). + + * `ENTRY' doesn't support F90 `RESULT()' yet, since that was added + after S8.112. + + * Empty-statement handling (10 ;;CONTINUE;;) probably isn't + consistent with the final form of the standard (it was vague at + S8.112). + + * It seems to be an "open" question whether a file, immediately + after being `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 `CLOSE') to + assist in making applications port to systems (some IBM?) that + `OPEN' to the end of a file or some such thing. diff -Nrc3pad gcc-3.0.1/gcc/f/g77.info-18 gcc-3.0.2/gcc/f/g77.info-18 *** gcc-3.0.1/gcc/f/g77.info-18 Sun Aug 19 18:52:16 2001 --- gcc-3.0.2/gcc/f/g77.info-18 Tue Oct 23 11:11:05 2001 *************** a first pass at translating `g77-0.5.16/ *** 36,146 **** Craig by David Ronis ().  - File: g77.info, Node: Simplify Porting, Next: More Extensions, Prev: Better Optimization, Up: Projects - - Simplify Porting - ================ - - Making `g77' easier to configure, port, build, and install, either - as a single-system compiler or as a cross-compiler, would be very - useful. - - * A new library (replacing `libg2c') should improve portability as - well as produce more optimal code. Further, `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 `FILE *' descriptors. - - * Possibly related to a new library, `g77' should produce the - equivalent of a `gcc' `main(argc, argv)' function when it compiles - a main program unit, instead of compiling something that must be - called by a library implementation of `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 `breakpoint - MAIN__' followed by `run', and so on. - - * The GBE needs to understand the difference between alignment - requirements and desires. For example, on Intel x86 machines, - `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 _recommendations_ as long - as they don't violate the actual processor _requirements_. - -  - File: g77.info, Node: More Extensions, Next: Machine Model, Prev: Simplify Porting, Up: Projects - - More Extensions - =============== - - These extensions are not the sort of things users ask for "by name", - but they might improve the usability of `g77', and Fortran in general, - in the long run. Some of these items really pertain to improving `g77' - internals so that some popular extensions can be more easily supported. - - * 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. - - * Consider adding a `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 `PARAMETER' statement when people really need - typelessness in a maintainable, portable, clearly documented way. - Maybe `TYPELESS' would include `CHARACTER', `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.) - - * Support `OPEN(...,KEY=(...),...)'. - - * Support arbitrary file unit numbers, instead of limiting them to 0 - through `MXUNIT-1'. (This is a `libg2c' issue.) - - * `OPEN(NOSPANBLOCKS,...)' is treated as - `OPEN(UNIT=NOSPANBLOCKS,...)', so a later `UNIT=' in the first - example is invalid. Make sure this is what users of this feature - would expect. - - * Currently `g77' disallows `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. - - * Support `STRUCTURE', `UNION', `MAP', and `RECORD' fully. - Currently there is no support at all for `%FILL' in `STRUCTURE' - and related syntax, whereas the rest of the stuff has at least - some parsing support. This requires either major changes to - `libg2c' or its replacement. - - * F90 and `g77' probably disagree about label scoping relative to - `INTERFACE' and `END INTERFACE', and their contained procedure - interface bodies (blocks?). - - * `ENTRY' doesn't support F90 `RESULT()' yet, since that was added - after S8.112. - - * Empty-statement handling (10 ;;CONTINUE;;) probably isn't - consistent with the final form of the standard (it was vague at - S8.112). - - * It seems to be an "open" question whether a file, immediately - after being `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 `CLOSE') to - assist in making applications port to systems (some IBM?) that - `OPEN' to the end of a file or some such thing. - -  File: g77.info, Node: Machine Model, Next: Internals Documentation, Prev: More Extensions, Up: Projects Machine Model --- 36,41 ---- *************** and implementing it. *** 1228,1231 **** --- 1123,1285 ---- The consensus to date (1999-11-17) has been to drop this support. Can't recall anybody saying they're using it, in fact. + +  + File: g77.info, Node: Philosophy of Code Generation, Next: Two-pass Design, Prev: Overview of Translation Process, Up: Front End + + Philosophy of Code Generation + ============================= + + Don't poke the bear. + + The `g77' front end generates code via the `gcc' back end. + + The `gcc' back end (GBE) is a large, complex labyrinth of intricate + code written in a combination of the C language and specialized + languages internal to `gcc'. + + While the _code_ that implements the GBE is written in a combination + of languages, the GBE itself is, to the front end for a language like + Fortran, best viewed as a _compiler_ that compiles its own, unique, + language. + + The GBE's "source", then, is written in this language, which + consists primarily of a combination of calls to GBE functions and + "tree" nodes (which are, themselves, created by calling GBE functions). + + So, the `g77' generates code by, in effect, translating the Fortran + code it reads into a form "written" in the "language" of the `gcc' back + end. + + This language will heretofore be referred to as "GBEL", for GNU Back + End Language. + + GBEL is an evolving language, not fully specified in any published + form as of this writing. It offers many facilities, but its "core" + facilities are those that corresponding most directly to those needed + to support `gcc' (compiling code written in GNU C). + + The `g77' Fortran Front End (FFE) is designed and implemented to + navigate the currents and eddies of ongoing GBEL and `gcc' development + while also delivering on the potential of an integrated FFE (as + compared to using a converter like `f2c' and feeding the output into + `gcc'). + + Goals of the FFE's code-generation strategy include: + + * High likelihood of generation of correct code, or, failing that, + producing a fatal diagnostic or crashing. + + * Generation of highly optimized code, as directed by the user via + GBE-specific (versus `g77'-specific) constructs, such as + command-line options. + + * Fast overall (FFE plus GBE) compilation. + + * Preservation of source-level debugging information. + + The strategies historically, and currently, used by the FFE to + achieve these goals include: + + * Use of GBEL constructs that most faithfully encapsulate the + semantics of Fortran. + + * Avoidance of GBEL constructs that are so rarely used, or limited + to use in specialized situations not related to Fortran, that + their reliability and performance has not yet been established as + sufficient for use by the FFE. + + * Flexible design, to readily accommodate changes to specific + code-generation strategies, perhaps governed by command-line + options. + + "Don't poke the bear" somewhat summarizes the above strategies. The + GBE is the bear. The FFE is designed and implemented to avoid poking it + in ways that are likely to just annoy it. The FFE usually either + tackles it head-on, or avoids treating it in ways dissimilar to how the + `gcc' front end treats it. + + For example, the FFE uses the native array facility in the back end + instead of the lower-level pointer-arithmetic facility used by `gcc' + when compiling `f2c' output). Theoretically, this presents more + opportunities for optimization, faster compile times, and the + production of more faithful debugging information. These benefits were + not, however, immediately realized, mainly because `gcc' itself makes + little or no use of the native array facility. + + Complex arithmetic is a case study of the evolution of this strategy. + When originally implemented, the GBEL had just evolved its own native + complex-arithmetic facility, so the FFE took advantage of that. + + When porting `g77' to 64-bit systems, it was discovered that the GBE + didn't really implement its native complex-arithmetic facility properly. + + The short-term solution was to rewrite the FFE to instead use the + lower-level facilities that'd be used by `gcc'-compiled code (assuming + that code, itself, didn't use the native complex type provided, as an + extension, by `gcc'), since these were known to work, and, in any case, + if shown to not work, would likely be rapidly fixed (since they'd + likely not work for vanilla C code in similar circumstances). + + However, the rewrite accommodated the original, native approach as + well by offering a command-line option to select it over the emulated + approach. This allowed users, and especially GBE maintainers, to try + out fixes to complex-arithmetic support in the GBE while `g77' + continued to default to compiling more code correctly, albeit producing + (typically) slower executables. + + As of April 1999, it appeared that the last few bugs in the GBE's + support of its native complex-arithmetic facility were worked out. The + FFE was changed back to default to using that native facility, leaving + emulation as an option. + + Later during the release cycle (which was called EGCS 1.2, but soon + became GCC 2.95), bugs in the native facility were found. Reactions + among various people included "the last thing we should do is change + the default back", "we must change the default back", and "let's figure + out whether we can narrow down the bugs to few enough cases to allow + the now-months-long-tested default to remain the same". The latter + viewpoint won that particular time. The bugs exposed other concerns + regarding ABI compliance when the ABI specified treatment of complex + data as different from treatment of what Fortran and GNU C consider the + equivalent aggregation (structure) of real (or float) pairs. + + Other Fortran constructs--arrays, character strings, complex + division, `COMMON' and `EQUIVALENCE' aggregates, and so on--involve + issues similar to those pertaining to complex arithmetic. + + So, it is possible that the history of how the FFE handled complex + arithmetic will be repeated, probably in modified form (and hopefully + over shorter timeframes), for some of these other facilities. + +  + File: g77.info, Node: Two-pass Design, Next: Challenges Posed, Prev: Philosophy of Code Generation, Up: Front End + + Two-pass Design + =============== + + The FFE does not tell the GBE anything about a program unit until + after the last statement in that unit has been parsed. (A program unit + is a Fortran concept that corresponds, in the C world, mostly closely + to functions definitions in ISO C. That is, a program unit in Fortran + is like a top-level function in C. Nested functions, found among the + extensions offered by GNU C, correspond roughly to Fortran's statement + functions.) + + So, while parsing the code in a program unit, the FFE saves up all + the information on statements, expressions, names, and so on, until it + has seen the last statement. + + At that point, the FFE revisits the saved information (in what + amounts to a second "pass" over the program unit) to perform the actual + translation of the program unit into GBEL, ultimating in the generation + of assembly code for it. + + Some lookahead is performed during this second pass, so the FFE + could be viewed as a "two-plus-pass" design. + + * Menu: + + * Two-pass Code:: + * Why Two Passes:: diff -Nrc3pad gcc-3.0.1/gcc/f/g77.info-19 gcc-3.0.2/gcc/f/g77.info-19 *** gcc-3.0.1/gcc/f/g77.info-19 Sun Aug 19 18:52:16 2001 --- gcc-3.0.2/gcc/f/g77.info-19 Tue Oct 23 11:11:05 2001 *************** a first pass at translating `g77-0.5.16/ *** 36,200 **** Craig by David Ronis ().  - File: g77.info, Node: Philosophy of Code Generation, Next: Two-pass Design, Prev: Overview of Translation Process, Up: Front End - - Philosophy of Code Generation - ============================= - - Don't poke the bear. - - The `g77' front end generates code via the `gcc' back end. - - The `gcc' back end (GBE) is a large, complex labyrinth of intricate - code written in a combination of the C language and specialized - languages internal to `gcc'. - - While the _code_ that implements the GBE is written in a combination - of languages, the GBE itself is, to the front end for a language like - Fortran, best viewed as a _compiler_ that compiles its own, unique, - language. - - The GBE's "source", then, is written in this language, which - consists primarily of a combination of calls to GBE functions and - "tree" nodes (which are, themselves, created by calling GBE functions). - - So, the `g77' generates code by, in effect, translating the Fortran - code it reads into a form "written" in the "language" of the `gcc' back - end. - - This language will heretofore be referred to as "GBEL", for GNU Back - End Language. - - GBEL is an evolving language, not fully specified in any published - form as of this writing. It offers many facilities, but its "core" - facilities are those that corresponding most directly to those needed - to support `gcc' (compiling code written in GNU C). - - The `g77' Fortran Front End (FFE) is designed and implemented to - navigate the currents and eddies of ongoing GBEL and `gcc' development - while also delivering on the potential of an integrated FFE (as - compared to using a converter like `f2c' and feeding the output into - `gcc'). - - Goals of the FFE's code-generation strategy include: - - * High likelihood of generation of correct code, or, failing that, - producing a fatal diagnostic or crashing. - - * Generation of highly optimized code, as directed by the user via - GBE-specific (versus `g77'-specific) constructs, such as - command-line options. - - * Fast overall (FFE plus GBE) compilation. - - * Preservation of source-level debugging information. - - The strategies historically, and currently, used by the FFE to - achieve these goals include: - - * Use of GBEL constructs that most faithfully encapsulate the - semantics of Fortran. - - * Avoidance of GBEL constructs that are so rarely used, or limited - to use in specialized situations not related to Fortran, that - their reliability and performance has not yet been established as - sufficient for use by the FFE. - - * Flexible design, to readily accommodate changes to specific - code-generation strategies, perhaps governed by command-line - options. - - "Don't poke the bear" somewhat summarizes the above strategies. The - GBE is the bear. The FFE is designed and implemented to avoid poking it - in ways that are likely to just annoy it. The FFE usually either - tackles it head-on, or avoids treating it in ways dissimilar to how the - `gcc' front end treats it. - - For example, the FFE uses the native array facility in the back end - instead of the lower-level pointer-arithmetic facility used by `gcc' - when compiling `f2c' output). Theoretically, this presents more - opportunities for optimization, faster compile times, and the - production of more faithful debugging information. These benefits were - not, however, immediately realized, mainly because `gcc' itself makes - little or no use of the native array facility. - - Complex arithmetic is a case study of the evolution of this strategy. - When originally implemented, the GBEL had just evolved its own native - complex-arithmetic facility, so the FFE took advantage of that. - - When porting `g77' to 64-bit systems, it was discovered that the GBE - didn't really implement its native complex-arithmetic facility properly. - - The short-term solution was to rewrite the FFE to instead use the - lower-level facilities that'd be used by `gcc'-compiled code (assuming - that code, itself, didn't use the native complex type provided, as an - extension, by `gcc'), since these were known to work, and, in any case, - if shown to not work, would likely be rapidly fixed (since they'd - likely not work for vanilla C code in similar circumstances). - - However, the rewrite accommodated the original, native approach as - well by offering a command-line option to select it over the emulated - approach. This allowed users, and especially GBE maintainers, to try - out fixes to complex-arithmetic support in the GBE while `g77' - continued to default to compiling more code correctly, albeit producing - (typically) slower executables. - - As of April 1999, it appeared that the last few bugs in the GBE's - support of its native complex-arithmetic facility were worked out. The - FFE was changed back to default to using that native facility, leaving - emulation as an option. - - Later during the release cycle (which was called EGCS 1.2, but soon - became GCC 2.95), bugs in the native facility were found. Reactions - among various people included "the last thing we should do is change - the default back", "we must change the default back", and "let's figure - out whether we can narrow down the bugs to few enough cases to allow - the now-months-long-tested default to remain the same". The latter - viewpoint won that particular time. The bugs exposed other concerns - regarding ABI compliance when the ABI specified treatment of complex - data as different from treatment of what Fortran and GNU C consider the - equivalent aggregation (structure) of real (or float) pairs. - - Other Fortran constructs--arrays, character strings, complex - division, `COMMON' and `EQUIVALENCE' aggregates, and so on--involve - issues similar to those pertaining to complex arithmetic. - - So, it is possible that the history of how the FFE handled complex - arithmetic will be repeated, probably in modified form (and hopefully - over shorter timeframes), for some of these other facilities. - -  - File: g77.info, Node: Two-pass Design, Next: Challenges Posed, Prev: Philosophy of Code Generation, Up: Front End - - Two-pass Design - =============== - - The FFE does not tell the GBE anything about a program unit until - after the last statement in that unit has been parsed. (A program unit - is a Fortran concept that corresponds, in the C world, mostly closely - to functions definitions in ISO C. That is, a program unit in Fortran - is like a top-level function in C. Nested functions, found among the - extensions offered by GNU C, correspond roughly to Fortran's statement - functions.) - - So, while parsing the code in a program unit, the FFE saves up all - the information on statements, expressions, names, and so on, until it - has seen the last statement. - - At that point, the FFE revisits the saved information (in what - amounts to a second "pass" over the program unit) to perform the actual - translation of the program unit into GBEL, ultimating in the generation - of assembly code for it. - - Some lookahead is performed during this second pass, so the FFE - could be viewed as a "two-plus-pass" design. - - * Menu: - - * Two-pass Code:: - * Why Two Passes:: - -  File: g77.info, Node: Two-pass Code, Next: Why Two Passes, Up: Two-pass Design Two-pass Code --- 36,41 ---- *************** produced when general problems such as t *** 1292,1295 **** --- 1133,1227 ---- *Note Options Controlling the Kind of Output: Overall Options, for suggestions about how to use, and not use, preprocessing for Fortran code. + +  + File: g77.info, Node: GLOBALS, Next: LINKFAIL, Prev: LEX, Up: Diagnostics + + `GLOBALS' + ========= + + Global name NAME defined at ... already defined... + Global name NAME at ... has different type... + Too many arguments passed to NAME at ... + Too few arguments passed to NAME at ... + Argument #N of NAME is ... + + These messages all identify disagreements about the global procedure + named NAME among different program units (usually including 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 _subsequent_ + procedure itself are, usually, diagnosed as errors when the procedure + itself _precedes_ the invocation. Other disagreements are diagnosed + via warnings. + + This distinction, between warnings and errors, is due primarily to + the present tendency of the `gcc' back end to inline only those + procedure invocations that are _preceded_ by the corresponding + procedure definitions. If the `gcc' back end is changed to inline + "forward references", in which invocations precede definitions, the + `g77' front end will be changed to treat both orderings as errors, + accordingly. + + The sorts of disagreements that are diagnosed by `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 _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 `-fno-globals' + option. + + The `-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 + `-Wno-globals' option as well as `-fno-globals' suppresses all of these + diagnostics. (`-Wno-globals' by itself disables only the warnings, not + the errors.) + + After using `-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. + +  + File: g77.info, Node: LINKFAIL, Next: Y2KBAD, Prev: GLOBALS, Up: Diagnostics + + `LINKFAIL' + ========== + + On AIX 4.1, `g77' might not build with the native (non-GNU) tools due + to a linker bug in coping with the `-bbigtoc' option which leads to a + `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 `-mminimal-toc' might solve this problem, e.g. by + adding + BOOT_CFLAGS='-mminimal-toc -O2 -g' + to the `make bootstrap' command line. + +  + File: g77.info, Node: Y2KBAD, Prev: LINKFAIL, Up: Diagnostics + + `Y2KBAD' + ======== + + Intrinsic `NAME', invoked at (^), known to be non-Y2K-compliant... + + This diagnostic indicates that the specific intrinsic invoked by the + name NAME is known to have an interface that is not Year-2000 (Y2K) + compliant. + + *Note Year 2000 (Y2K) Problems::. diff -Nrc3pad gcc-3.0.1/gcc/f/g77.info-20 gcc-3.0.2/gcc/f/g77.info-20 *** gcc-3.0.1/gcc/f/g77.info-20 Sun Aug 19 18:52:16 2001 --- gcc-3.0.2/gcc/f/g77.info-20 Tue Oct 23 11:11:05 2001 *************** a first pass at translating `g77-0.5.16/ *** 36,128 **** Craig by David Ronis ().  ! File: g77.info, Node: GLOBALS, Next: LINKFAIL, Prev: LEX, Up: Diagnostics ! ! `GLOBALS' ! ========= ! ! Global name NAME defined at ... already defined... ! Global name NAME at ... has different type... ! Too many arguments passed to NAME at ... ! Too few arguments passed to NAME at ... ! Argument #N of NAME is ... ! ! These messages all identify disagreements about the global procedure ! named NAME among different program units (usually including 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 _subsequent_ ! procedure itself are, usually, diagnosed as errors when the procedure ! itself _precedes_ the invocation. Other disagreements are diagnosed ! via warnings. ! ! This distinction, between warnings and errors, is due primarily to ! the present tendency of the `gcc' back end to inline only those ! procedure invocations that are _preceded_ by the corresponding ! procedure definitions. If the `gcc' back end is changed to inline ! "forward references", in which invocations precede definitions, the ! `g77' front end will be changed to treat both orderings as errors, ! accordingly. ! ! The sorts of disagreements that are diagnosed by `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 _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 `-fno-globals' ! option. ! ! The `-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 ! `-Wno-globals' option as well as `-fno-globals' suppresses all of these ! diagnostics. (`-Wno-globals' by itself disables only the warnings, not ! the errors.) ! ! After using `-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. ! !  ! File: g77.info, Node: LINKFAIL, Next: Y2KBAD, Prev: GLOBALS, Up: Diagnostics ! ! `LINKFAIL' ! ========== ! ! On AIX 4.1, `g77' might not build with the native (non-GNU) tools due ! to a linker bug in coping with the `-bbigtoc' option which leads to a ! `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 `-mminimal-toc' might solve this problem, e.g. by ! adding ! BOOT_CFLAGS='-mminimal-toc -O2 -g' ! to the `make bootstrap' command line. ! !  ! File: g77.info, Node: Y2KBAD, Prev: LINKFAIL, Up: Diagnostics ! `Y2KBAD' ! ======== ! Intrinsic `NAME', invoked at (^), known to be non-Y2K-compliant... ! This diagnostic indicates that the specific intrinsic invoked by the ! name NAME is known to have an interface that is not Year-2000 (Y2K) ! compliant. - *Note Year 2000 (Y2K) Problems::. --- 36,2273 ---- Craig by David Ronis ().  ! File: g77.info, Node: Index, Prev: Diagnostics, Up: Top ! Index ! ***** ! * Menu: ! * ! <1>: LEX. ! * ! <2>: Exclamation Point. ! * ! <3>: Trailing Comment. ! * ! <4>: Character Set. ! * !: Statements Comments Lines. ! * ": Character Set. ! * # <1>: Cpp-style directives. ! * #: Character Set. ! * #define: Overall Options. ! * #if: Overall Options. ! * #include: Overall Options. ! * #include directive: Bug Reporting. ! * $: Dollar Signs. ! * %: Character Set. ! * %DESCR() construct: %DESCR(). ! * %LOC() construct: %LOC(). ! * %REF() construct: %REF(). ! * %VAL() construct: %VAL(). ! * &: Character Set. ! * *: LEX. ! * *N notation <1>: Compiler Types. ! * *N notation: Star Notation. ! * --driver option <1>: Changes. ! * --driver option: News. ! * -falias-check option <1>: Aliasing Assumed To Work. ! * -falias-check option: Code Gen Options. ! * -fargument-alias option <1>: Aliasing Assumed To Work. ! * -fargument-alias option: Code Gen Options. ! * -fargument-noalias option <1>: Aliasing Assumed To Work. ! * -fargument-noalias option: Code Gen Options. ! * -fbadu77-intrinsics-delete option: Fortran Dialect Options. ! * -fbadu77-intrinsics-disable option: Fortran Dialect Options. ! * -fbadu77-intrinsics-enable option: Fortran Dialect Options. ! * -fbadu77-intrinsics-hide option: Fortran Dialect Options. ! * -fbounds-check option: Code Gen Options. ! * -fcaller-saves option: Optimize Options. ! * -fcase-initcap option: Fortran Dialect Options. ! * -fcase-lower option: Fortran Dialect Options. ! * -fcase-preserve option: Fortran Dialect Options. ! * -fcase-strict-lower option: Fortran Dialect Options. ! * -fcase-strict-upper option: Fortran Dialect Options. ! * -fcase-upper option: Fortran Dialect Options. ! * -fdebug-kludge option: Code Gen Options. ! * -fdelayed-branch option: Optimize Options. ! * -fdollar-ok option: Fortran Dialect Options. ! * -femulate-complex option: Code Gen Options. ! * -fexpensive-optimizations option: Optimize Options. ! * -ff2c-intrinsics-delete option: Fortran Dialect Options. ! * -ff2c-intrinsics-disable option: Fortran Dialect Options. ! * -ff2c-intrinsics-enable option: Fortran Dialect Options. ! * -ff2c-intrinsics-hide option: Fortran Dialect Options. ! * -ff2c-library option: Code Gen Options. ! * -ff66 option: Shorthand Options. ! * -ff77 option: Shorthand Options. ! * -ff90: Fortran 90 Features. ! * -ff90 option: Fortran Dialect Options. ! * -ff90-intrinsics-delete option: Fortran Dialect Options. ! * -ff90-intrinsics-disable option: Fortran Dialect Options. ! * -ff90-intrinsics-enable option: Fortran Dialect Options. ! * -ff90-intrinsics-hide option: Fortran Dialect Options. ! * -ffast-math option: Optimize Options. ! * -ffixed-line-length-N option: Fortran Dialect Options. ! * -fflatten-arrays option: Code Gen Options. ! * -ffloat-store option: Optimize Options. ! * -fforce-addr option: Optimize Options. ! * -fforce-mem option: Optimize Options. ! * -ffortran-bounds-check option: Code Gen Options. ! * -ffree-form: Fortran 90 Features. ! * -ffree-form option: Fortran Dialect Options. ! * -fgnu-intrinsics-delete option: Fortran Dialect Options. ! * -fgnu-intrinsics-disable option: Fortran Dialect Options. ! * -fgnu-intrinsics-enable option: Fortran Dialect Options. ! * -fgnu-intrinsics-hide option: Fortran Dialect Options. ! * -fGROUP-intrinsics-hide option: Overly Convenient Options. ! * -finit-local-zero option <1>: Overly Convenient Options. ! * -finit-local-zero option: Code Gen Options. ! * -fintrin-case-any option: Fortran Dialect Options. ! * -fintrin-case-initcap option: Fortran Dialect Options. ! * -fintrin-case-lower option: Fortran Dialect Options. ! * -fintrin-case-upper option: Fortran Dialect Options. ! * -fmatch-case-any option: Fortran Dialect Options. ! * -fmatch-case-initcap option: Fortran Dialect Options. ! * -fmatch-case-lower option: Fortran Dialect Options. ! * -fmatch-case-upper option: Fortran Dialect Options. ! * -fmil-intrinsics-delete option: Fortran Dialect Options. ! * -fmil-intrinsics-disable option: Fortran Dialect Options. ! * -fmil-intrinsics-enable option: Fortran Dialect Options. ! * -fmil-intrinsics-hide option: Fortran Dialect Options. ! * -fno-argument-noalias-global option <1>: Aliasing Assumed To Work. ! * -fno-argument-noalias-global option: Code Gen Options. ! * -fno-automatic option <1>: Overly Convenient Options. ! * -fno-automatic option: Code Gen Options. ! * -fno-backslash option: Fortran Dialect Options. ! * -fno-common option: Code Gen Options. ! * -fno-f2c option <1>: Avoid f2c Compatibility. ! * -fno-f2c option: Code Gen Options. ! * -fno-f77 option: Shorthand Options. ! * -fno-fixed-form option: Fortran Dialect Options. ! * -fno-globals option: Code Gen Options. ! * -fno-ident option: Code Gen Options. ! * -fno-inline option: Optimize Options. ! * -fno-move-all-movables option: Optimize Options. ! * -fno-reduce-all-givs option: Optimize Options. ! * -fno-rerun-loop-opt option: Optimize Options. ! * -fno-second-underscore: f2c Skeletons and Prototypes. ! * -fno-second-underscore option <1>: Names. ! * -fno-second-underscore option: Code Gen Options. ! * -fno-silent option: Overall Options. ! * -fno-ugly option: Shorthand Options. ! * -fno-ugly-args option: Fortran Dialect Options. ! * -fno-ugly-init option: Fortran Dialect Options. ! * -fno-underscoring option <1>: Names. ! * -fno-underscoring option: Code Gen Options. ! * -fonetrip option: Fortran Dialect Options. ! * -fpack-struct option: Code Gen Options. ! * -fpcc-struct-return option: Code Gen Options. ! * -fpedantic option: Warning Options. ! * -fPIC option: News. ! * -freg-struct-return option: Code Gen Options. ! * -frerun-cse-after-loop option: Optimize Options. ! * -fschedule-insns option: Optimize Options. ! * -fschedule-insns2 option: Optimize Options. ! * -fset-g77-defaults option: Overall Options. ! * -fshort-double option: Code Gen Options. ! * -fsource-case-lower option: Fortran Dialect Options. ! * -fsource-case-preserve option: Fortran Dialect Options. ! * -fsource-case-upper option: Fortran Dialect Options. ! * -fstrength-reduce option: Optimize Options. ! * -fsymbol-case-any option: Fortran Dialect Options. ! * -fsymbol-case-initcap option: Fortran Dialect Options. ! * -fsymbol-case-lower option: Fortran Dialect Options. ! * -fsymbol-case-upper option: Fortran Dialect Options. ! * -fsyntax-only option: Warning Options. ! * -ftypeless-boz option: Fortran Dialect Options. ! * -fugly option: Shorthand Options. ! * -fugly-assign option: Fortran Dialect Options. ! * -fugly-assumed option: Fortran Dialect Options. ! * -fugly-comma option: Fortran Dialect Options. ! * -fugly-complex option: Fortran Dialect Options. ! * -fugly-logint option: Fortran Dialect Options. ! * -funix-intrinsics-delete option: Fortran Dialect Options. ! * -funix-intrinsics-disable option: Fortran Dialect Options. ! * -funix-intrinsics-enable option: Fortran Dialect Options. ! * -funix-intrinsics-hide option: Fortran Dialect Options. ! * -funroll-all-loops option: Optimize Options. ! * -funroll-loops option: Optimize Options. ! * -fversion option: Overall Options. ! * -fvxt option: Fortran Dialect Options. ! * -fvxt-intrinsics-delete option: Fortran Dialect Options. ! * -fvxt-intrinsics-disable option: Fortran Dialect Options. ! * -fvxt-intrinsics-enable option: Fortran Dialect Options. ! * -fvxt-intrinsics-hide option: Fortran Dialect Options. ! * -fzeros option: Code Gen Options. ! * -g option: Debugging Options. ! * -I- option: Directory Options. ! * -i8: Increasing Precision/Range. ! * -Idir option: Directory Options. ! * -malign-double <1>: Changes. ! * -malign-double: News. ! * -malign-double option <1>: Aligned Data. ! * -malign-double option: Optimize Options. ! * -Nl option: Compiler Limits. ! * -Nx option: Compiler Limits. ! * -O2: News. ! * -pedantic option: Warning Options. ! * -pedantic-errors option: Warning Options. ! * -qrealsize=8: Increasing Precision/Range. ! * -r8: Increasing Precision/Range. ! * -u option: Warning Options. ! * -v option: G77 and GCC. ! * -W option: Warning Options. ! * -w option: Warning Options. ! * -Waggregate-return option: Warning Options. ! * -Wall option: Warning Options. ! * -Wcomment option: Warning Options. ! * -Wconversion option: Warning Options. ! * -Werror option: Warning Options. ! * -Wformat option: Warning Options. ! * -Wid-clash-LEN option: Warning Options. ! * -Wimplicit option: Warning Options. ! * -Wlarger-than-LEN option: Warning Options. ! * -Wno-globals option: Warning Options. ! * -Wparentheses option: Warning Options. ! * -Wredundant-decls option: Warning Options. ! * -Wshadow option: Warning Options. ! * -Wsurprising option: Warning Options. ! * -Wswitch option: Warning Options. ! * -Wtraditional option: Warning Options. ! * -Wuninitialized option: Warning Options. ! * -Wunused option: Warning Options. ! * -x f77-cpp-input option: LEX. ! * .EQV., with integer operands: Equivalence Versus Equality. ! * .F filename suffix: Overall Options. ! * .f filename suffix: Overall Options. ! * .FOR filename suffix: Overall Options. ! * .for filename suffix: Overall Options. ! * .FPP filename suffix: Overall Options. ! * .fpp filename suffix: Overall Options. ! * .gdbinit: Main Program Unit. ! * .r filename suffix: Overall Options. ! * /* <1>: Trailing Comment. ! * /*: Overall Options. ! * /WARNINGS=DECLARATIONS switch: Warning Options. ! * 80-bit spills: Floating-point Errors. ! * ; <1>: Character Set. ! * ;: Statements Comments Lines. ! * <: Character Set. ! * <> edit descriptor: I/O. ! * >: Character Set. ! * ?: Character Set. ! * \: Character Set. ! * _: Character Set. ! * Abort intrinsic: Abort Intrinsic. ! * Abs intrinsic: Abs Intrinsic. ! * ACCEPT statement: TYPE and ACCEPT I/O Statements. ! * Access intrinsic: Access Intrinsic. ! * AChar intrinsic: AChar Intrinsic. ! * ACos intrinsic: ACos Intrinsic. ! * ACosD intrinsic: ACosD Intrinsic. ! * adding options: Adding Options. ! * adjustable arrays: Adjustable Arrays. ! * AdjustL intrinsic: AdjustL Intrinsic. ! * AdjustR intrinsic: AdjustR Intrinsic. ! * AImag intrinsic <1>: AImag Intrinsic. ! * AImag intrinsic: REAL() and AIMAG() of Complex. ! * AIMax0 intrinsic: AIMax0 Intrinsic. ! * AIMin0 intrinsic: AIMin0 Intrinsic. ! * AInt intrinsic: AInt Intrinsic. ! * AJMax0 intrinsic: AJMax0 Intrinsic. ! * AJMin0 intrinsic: AJMin0 Intrinsic. ! * Alarm intrinsic: Alarm Intrinsic. ! * aliasing <1>: Known Bugs. ! * aliasing: Aliasing Assumed To Work. ! * aligned data: Aligned Data. ! * aligned stack: Aligned Data. ! * alignment <1>: Aligned Data. ! * alignment <2>: Changes. ! * alignment: News. ! * alignment testing: Aligned Data. ! * All intrinsic: All Intrinsic. ! * all warnings: Warning Options. ! * Allocated intrinsic: Allocated Intrinsic. ! * ALog intrinsic: ALog Intrinsic. ! * ALog10 intrinsic: ALog10 Intrinsic. ! * Alpha, support: Known Bugs. ! * alternate entry points: Alternate Entry Points. ! * alternate returns: Alternate Returns. ! * ALWAYS_FLUSH: Output Assumed To Flush. ! * AMax0 intrinsic: AMax0 Intrinsic. ! * AMax1 intrinsic: AMax1 Intrinsic. ! * AMin0 intrinsic: AMin0 Intrinsic. ! * AMin1 intrinsic: AMin1 Intrinsic. ! * AMod intrinsic: AMod Intrinsic. ! * ampersand: Character Set. ! * ampersand continuation line: Ampersands. ! * And intrinsic <1>: Bit Operations on Floating-point Data. ! * And intrinsic: And Intrinsic. ! * ANInt intrinsic: ANInt Intrinsic. ! * ANS carriage control: OPEN CLOSE and INQUIRE Keywords. ! * ANSI FORTRAN 77 standard: Language. ! * ANSI FORTRAN 77 support: Standard Support. ! * anti-aliasing: Aliasing Assumed To Work. ! * Any intrinsic: Any Intrinsic. ! * arguments, null: Ugly Null Arguments. ! * arguments, omitting: Ugly Null Arguments. ! * arguments, unused <1>: Unused Arguments. ! * arguments, unused: Warning Options. ! * array bounds checking: Code Gen Options. ! * array bounds, adjustable: Array Bounds Expressions. ! * array elements, in adjustable array bounds: Array Bounds Expressions. ! * array ordering: Arrays. ! * array performance: Code Gen Options. ! * array size: Array Size. ! * arrays: Arrays. ! * arrays, adjustable: Adjustable Arrays. ! * arrays, assumed-size: Ugly Assumed-Size Arrays. ! * arrays, automatic <1>: Large Automatic Arrays. ! * arrays, automatic <2>: Stack Overflow. ! * arrays, automatic <3>: Overly Convenient Options. ! * arrays, automatic: Adjustable Arrays. ! * arrays, dimensioning <1>: Adjustable Arrays. ! * arrays, dimensioning: Array Size. ! * arrays, flattening: Code Gen Options. ! * as command: What is GNU Fortran?. ! * ASin intrinsic: ASin Intrinsic. ! * ASinD intrinsic: ASinD Intrinsic. ! * assembler: What is GNU Fortran?. ! * assembly code: What is GNU Fortran?. ! * assembly code, invalid: Bug Criteria. ! * ASSIGN statement <1>: Assigned Statement Labels. ! * ASSIGN statement: Ugly Assigned Labels. ! * assigned labels: Ugly Assigned Labels. ! * assigned statement labels: Assigned Statement Labels. ! * Associated intrinsic: Associated Intrinsic. ! * association, storage: Aliasing Assumed To Work. ! * assumed-size arrays: Ugly Assumed-Size Arrays. ! * asterisk: LEX. ! * ATan intrinsic: ATan Intrinsic. ! * ATan2 intrinsic: ATan2 Intrinsic. ! * ATan2D intrinsic: ATan2D Intrinsic. ! * ATanD intrinsic: ATanD Intrinsic. ! * automatic arrays <1>: Large Automatic Arrays. ! * automatic arrays <2>: Stack Overflow. ! * automatic arrays <3>: Overly Convenient Options. ! * automatic arrays: Adjustable Arrays. ! * AUTOMATIC statement: AUTOMATIC Statement. ! * automatic variables: AUTOMATIC Statement. ! * back end, gcc <1>: Philosophy of Code Generation. ! * back end, gcc: What is GNU Fortran?. ! * backslash <1>: Backslash in Constants. ! * backslash <2>: Character Set. ! * backslash: Fortran Dialect Options. ! * backtrace for bug reports: Bug Reporting. ! * badu77 intrinsics: Fortran Dialect Options. ! * badu77 intrinsics group: Intrinsic Groups. ! * basic concepts: What is GNU Fortran?. ! * Bear-poking: Philosophy of Code Generation. ! * beginners: Getting Started. ! * BesJ0 intrinsic: BesJ0 Intrinsic. ! * BesJ1 intrinsic: BesJ1 Intrinsic. ! * BesJN intrinsic: BesJN Intrinsic. ! * BesY0 intrinsic: BesY0 Intrinsic. ! * BesY1 intrinsic: BesY1 Intrinsic. ! * BesYN intrinsic: BesYN Intrinsic. ! * binary data: Portable Unformatted Files. ! * Bit_Size intrinsic: Bit_Size Intrinsic. ! * BITest intrinsic: BITest Intrinsic. ! * BJTest intrinsic: BJTest Intrinsic. ! * blank <1>: Lines. ! * blank: Character Set. ! * block data: Multiple Definitions of External Names. ! * block data and libraries: Block Data and Libraries. ! * BLOCK DATA statement <1>: Multiple Definitions of External Names. ! * BLOCK DATA statement: Block Data and Libraries. ! * bounds checking: Code Gen Options. ! * BTest intrinsic: BTest Intrinsic. ! * bug criteria: Bug Criteria. ! * bug report mailing lists: Bug Lists. ! * bugs: Bugs. ! * bugs, finding: What is GNU Fortran?. ! * bugs, known: Trouble. ! * bus error <1>: Strange Behavior at Run Time. ! * bus error: NeXTStep Problems. ! * but-bugs: But-bugs. ! * byte ordering: Portable Unformatted Files. ! * C library: Strange Behavior at Run Time. ! * C preprocessor: Overall Options. ! * C routines calling Fortran: Debugging and Interfacing. ! * C++: C++ Considerations. ! * C++, linking with: Interoperating with C and C++. ! * C, linking with: Interoperating with C and C++. ! * CAbs intrinsic: CAbs Intrinsic. ! * calling C routines: Debugging and Interfacing. ! * card image: Fortran Dialect Options. ! * carriage control: OPEN CLOSE and INQUIRE Keywords. ! * carriage returns: Carriage Returns. ! * case sensitivity: Case Sensitivity. ! * cc1 program: What is GNU Fortran?. ! * cc1plus program: What is GNU Fortran?. ! * CCos intrinsic: CCos Intrinsic. ! * CDAbs intrinsic: CDAbs Intrinsic. ! * CDCos intrinsic: CDCos Intrinsic. ! * CDExp intrinsic: CDExp Intrinsic. ! * CDLog intrinsic: CDLog Intrinsic. ! * CDSin intrinsic: CDSin Intrinsic. ! * CDSqRt intrinsic: CDSqRt Intrinsic. ! * Ceiling intrinsic: Ceiling Intrinsic. ! * CExp intrinsic: CExp Intrinsic. ! * cfortran.h: C Interfacing Tools. ! * changes, user-visible: Changes. ! * Char intrinsic: Char Intrinsic. ! * character assignments: Fortran 90 Features. ! * character constants <1>: Character and Hollerith Constants. ! * character constants <2>: Ugly Conversion of Initializers. ! * character constants <3>: Double Quote Meaning. ! * character constants: Fortran Dialect Options. ! * character set: Fortran Dialect Options. ! * CHARACTER*(*): Arbitrary Concatenation. ! * CHARACTER, null: Character Type. ! * character-variable length: Character-variable Length. ! * characters: Character Set. ! * characters, comma: Ugly Null Arguments. ! * characters, comment <1>: LEX. ! * characters, comment <2>: Exclamation Point. ! * characters, comment <3>: Trailing Comment. ! * characters, comment: Statements Comments Lines. ! * characters, continuation <1>: LEX. ! * characters, continuation <2>: Exclamation Point. ! * characters, continuation: Statements Comments Lines. ! * ChDir intrinsic <1>: ChDir Intrinsic (function). ! * ChDir intrinsic: ChDir Intrinsic (subroutine). ! * checking subscripts: Code Gen Options. ! * checking substrings: Code Gen Options. ! * checks, of internal consistency: Overall Options. ! * ChMod intrinsic <1>: ChMod Intrinsic (function). ! * ChMod intrinsic: ChMod Intrinsic (subroutine). ! * CLog intrinsic: CLog Intrinsic. ! * close angle: Character Set. ! * close bracket: Character Set. ! * CLOSE statement: OPEN CLOSE and INQUIRE Keywords. ! * Cmplx intrinsic <1>: Cmplx Intrinsic. ! * Cmplx intrinsic: CMPLX() of DOUBLE PRECISION. ! * code generation, conventions: Code Gen Options. ! * code generation, improving: Better Optimization. ! * code generator <1>: Philosophy of Code Generation. ! * code generator: What is GNU Fortran?. ! * code, assembly: What is GNU Fortran?. ! * code, displaying main source: Known Bugs. ! * code, in-line: What is GNU Fortran?. ! * code, legacy: Collected Fortran Wisdom. ! * code, machine: What is GNU Fortran?. ! * code, modifying: Overall Options. ! * code, source <1>: Case Sensitivity. ! * code, source <2>: Source Form. ! * code, source <3>: Lines. ! * code, source: What is GNU Fortran?. ! * code, user: Cannot Link Fortran Programs. ! * code, writing: Collected Fortran Wisdom. ! * column-major ordering: Arrays. ! * columns 73 through 80: Better Source Model. ! * comma, trailing: Ugly Null Arguments. ! * command options: Invoking G77. ! * commands, as: What is GNU Fortran?. ! * commands, g77 <1>: G77 and GCC. ! * commands, g77: What is GNU Fortran?. ! * commands, gcc <1>: G77 and GCC. ! * commands, gcc: What is GNU Fortran?. ! * commands, gdb: What is GNU Fortran?. ! * commands, ld: What is GNU Fortran?. ! * comment <1>: LEX. ! * comment <2>: Trailing Comment. ! * comment: Statements Comments Lines. ! * comment character: Exclamation Point. ! * comment line, debug <1>: Enabling Debug Lines. ! * comment line, debug: Debug Line. ! * common blocks <1>: Mangling of Names. ! * common blocks <2>: Known Bugs. ! * common blocks <3>: Common Blocks. ! * common blocks: Debugging Options. ! * common blocks, large: Large Common Blocks. ! * COMMON layout: Aligned Data. ! * COMMON statement <1>: Multiple Definitions of External Names. ! * COMMON statement: Common Blocks. ! * comparing logical expressions: Equivalence Versus Equality. ! * compatibility, f2c <1>: Avoid f2c Compatibility. ! * compatibility, f2c <2>: Block Data and Libraries. ! * compatibility, f2c <3>: Code Gen Options. ! * compatibility, f2c <4>: Shorthand Options. ! * compatibility, f2c: Overall Options. ! * compatibility, f77: Shorthand Options. ! * compatibility, FORTRAN 66 <1>: Fortran Dialect Options. ! * compatibility, FORTRAN 66: Shorthand Options. ! * compatibility, FORTRAN 77: Standard Support. ! * compatibility, Fortran 90: Fortran 90. ! * compilation, in-line <1>: GLOBALS. ! * compilation, in-line <2>: Code Gen Options. ! * compilation, in-line: Optimize Options. ! * compilation, pedantic: Pedantic Compilation. ! * compilation, status: Overall Options. ! * compiler bugs, reporting: Bug Reporting. ! * compiler limits: Compiler Limits. ! * compiler memory usage: Known Bugs. ! * compiler speed: Known Bugs. ! * compilers: What is GNU Fortran?. ! * compiling programs: G77 and GCC. ! * Complex intrinsic: Complex Intrinsic. ! * COMPLEX intrinsics: Fortran Dialect Options. ! * complex performance: Known Bugs. ! * COMPLEX statement: Complex Variables. ! * complex values: Ugly Complex Part Extraction. ! * complex variables: Complex Variables. ! * COMPLEX(KIND=1) type: Compiler Types. ! * COMPLEX(KIND=2) type: Compiler Types. ! * components of g77: What is GNU Fortran?. ! * concatenation: Arbitrary Concatenation. ! * concepts, basic: What is GNU Fortran?. ! * conformance, IEEE 754 <1>: Floating-point precision. ! * conformance, IEEE 754: Optimize Options. ! * Conjg intrinsic: Conjg Intrinsic. ! * consistency checks: Overall Options. ! * constants <1>: Compiler Constants. ! * constants: Constants. ! * constants, character <1>: Character and Hollerith Constants. ! * constants, character <2>: Ugly Conversion of Initializers. ! * constants, character: Double Quote Meaning. ! * constants, context-sensitive: Context-Sensitive Constants. ! * constants, Hollerith <1>: Character and Hollerith Constants. ! * constants, Hollerith <2>: Ugly Conversion of Initializers. ! * constants, Hollerith: Ugly Implicit Argument Conversion. ! * constants, integer: Known Bugs. ! * constants, octal: Double Quote Meaning. ! * constants, prefix-radix: Fortran Dialect Options. ! * constants, types: Fortran Dialect Options. ! * construct names: Construct Names. ! * context-sensitive constants: Context-Sensitive Constants. ! * context-sensitive intrinsics: Context-Sensitive Intrinsicness. ! * continuation character <1>: LEX. ! * continuation character <2>: Exclamation Point. ! * continuation character: Statements Comments Lines. ! * continuation line, ampersand: Ampersands. ! * continuation line, number of: Continuation Line. ! * contributors: Contributors. ! * conversions, nonportable: Nonportable Conversions. ! * core dump: Bug Criteria. ! * Cos intrinsic: Cos Intrinsic. ! * CosD intrinsic: CosD Intrinsic. ! * CosH intrinsic: CosH Intrinsic. ! * Count intrinsic: Count Intrinsic. ! * cpp preprocessor: Overall Options. ! * cpp program <1>: LEX. ! * cpp program <2>: Bug Reporting. ! * cpp program <3>: Preprocessor Options. ! * cpp program <4>: Overall Options. ! * cpp program: What is GNU Fortran?. ! * CPU_Time intrinsic: CPU_Time Intrinsic. ! * Cray pointers: POINTER Statements. ! * credits: Contributors. ! * CShift intrinsic: CShift Intrinsic. ! * CSin intrinsic: CSin Intrinsic. ! * CSqRt intrinsic: CSqRt Intrinsic. ! * CTime intrinsic <1>: CTime Intrinsic (function). ! * CTime intrinsic: CTime Intrinsic (subroutine). ! * CYCLE statement: CYCLE and EXIT. ! * DAbs intrinsic: DAbs Intrinsic. ! * DACos intrinsic: DACos Intrinsic. ! * DACosD intrinsic: DACosD Intrinsic. ! * DASin intrinsic: DASin Intrinsic. ! * DASinD intrinsic: DASinD Intrinsic. ! * DATA statement <1>: Known Bugs. ! * DATA statement: Code Gen Options. ! * data types: Compiler Types. ! * data, aligned: Aligned Data. ! * data, overwritten: Strange Behavior at Run Time. ! * DATan intrinsic: DATan Intrinsic. ! * DATan2 intrinsic: DATan2 Intrinsic. ! * DATan2D intrinsic: DATan2D Intrinsic. ! * DATanD intrinsic: DATanD Intrinsic. ! * Date intrinsic: Date Intrinsic. ! * Date_and_Time intrinsic: Date_and_Time Intrinsic. ! * date_y2kbuggy_0: Year 2000 (Y2K) Problems. ! * DbesJ0 intrinsic: DbesJ0 Intrinsic. ! * DbesJ1 intrinsic: DbesJ1 Intrinsic. ! * DbesJN intrinsic: DbesJN Intrinsic. ! * DbesY0 intrinsic: DbesY0 Intrinsic. ! * DbesY1 intrinsic: DbesY1 Intrinsic. ! * DbesYN intrinsic: DbesYN Intrinsic. ! * Dble intrinsic: Dble Intrinsic. ! * DbleQ intrinsic: DbleQ Intrinsic. ! * DCmplx intrinsic: DCmplx Intrinsic. ! * DConjg intrinsic: DConjg Intrinsic. ! * DCos intrinsic: DCos Intrinsic. ! * DCosD intrinsic: DCosD Intrinsic. ! * DCosH intrinsic: DCosH Intrinsic. ! * DDiM intrinsic: DDiM Intrinsic. ! * debug line <1>: Enabling Debug Lines. ! * debug line: Debug Line. ! * debug_rtx: Bug Reporting. ! * debugger <1>: Known Bugs. ! * debugger: What is GNU Fortran?. ! * debugging <1>: Known Bugs. ! * debugging <2>: Names. ! * debugging <3>: Main Program Unit. ! * debugging: Debugging and Interfacing. ! * debugging information options: Debugging Options. ! * debugging main source code: Known Bugs. ! * DECODE statement: ENCODE and DECODE. ! * deleted intrinsics: Intrinsic Groups. ! * DErF intrinsic: DErF Intrinsic. ! * DErFC intrinsic: DErFC Intrinsic. ! * DExp intrinsic: DExp Intrinsic. ! * DFloat intrinsic: DFloat Intrinsic. ! * DFlotI intrinsic: DFlotI Intrinsic. ! * DFlotJ intrinsic: DFlotJ Intrinsic. ! * diagnostics: Diagnostics. ! * diagnostics, incorrect: What is GNU Fortran?. ! * dialect options: Fortran Dialect Options. ! * Digital Fortran features: Fortran Dialect Options. ! * Digits intrinsic: Digits Intrinsic. ! * DiM intrinsic: DiM Intrinsic. ! * DImag intrinsic: DImag Intrinsic. ! * DIMENSION statement <1>: Array Bounds Expressions. ! * DIMENSION statement <2>: Adjustable Arrays. ! * DIMENSION statement: Arrays. ! * DIMENSION X(1): Ugly Assumed-Size Arrays. ! * dimensioning arrays: Adjustable Arrays. ! * DInt intrinsic: DInt Intrinsic. ! * direction of language development: Direction of Language Development. ! * directive, #include: Bug Reporting. ! * directive, INCLUDE <1>: Bug Reporting. ! * directive, INCLUDE <2>: Directory Options. ! * directive, INCLUDE: Preprocessor Options. ! * directory, options: Directory Options. ! * directory, search paths for inclusion: Directory Options. ! * disabled intrinsics: Intrinsic Groups. ! * disk full: Output Assumed To Flush. ! * displaying main source code: Known Bugs. ! * disposition of files: OPEN CLOSE and INQUIRE Keywords. ! * distensions: Distensions. ! * DLog intrinsic: DLog Intrinsic. ! * DLog10 intrinsic: DLog10 Intrinsic. ! * DMax1 intrinsic: DMax1 Intrinsic. ! * DMin1 intrinsic: DMin1 Intrinsic. ! * DMod intrinsic: DMod Intrinsic. ! * DNInt intrinsic: DNInt Intrinsic. ! * DNRM2: News. ! * DO: DO WHILE. ! * DO loops, one-trip: Fortran Dialect Options. ! * DO loops, zero-trip: Fortran Dialect Options. ! * DO statement <1>: Loops. ! * DO statement: Warning Options. ! * DO WHILE <1>: DO WHILE. ! * DO WHILE: Optimize Options. ! * dollar sign <1>: Dollar Signs. ! * dollar sign <2>: I/O. ! * dollar sign: Fortran Dialect Options. ! * Dot_Product intrinsic: Dot_Product Intrinsic. ! * DOUBLE COMPLEX: DOUBLE COMPLEX. ! * DOUBLE COMPLEX type: Compiler Types. ! * DOUBLE PRECISION type: Compiler Types. ! * double quote: Character Set. ! * double quoted character constants <1>: Fortran 90 Features. ! * double quoted character constants: Character Type. ! * double quotes: Double Quote Meaning. ! * double-precision performance <1>: Changes. ! * double-precision performance: News. ! * DProd intrinsic: DProd Intrinsic. ! * DReal intrinsic: DReal Intrinsic. ! * driver, gcc command as: What is GNU Fortran?. ! * DSign intrinsic: DSign Intrinsic. ! * DSin intrinsic: DSin Intrinsic. ! * DSinD intrinsic: DSinD Intrinsic. ! * DSinH intrinsic: DSinH Intrinsic. ! * DSqRt intrinsic: DSqRt Intrinsic. ! * DTan intrinsic: DTan Intrinsic. ! * DTanD intrinsic: DTanD Intrinsic. ! * DTanH intrinsic: DTanH Intrinsic. ! * DTime intrinsic <1>: DTime Intrinsic (function). ! * DTime intrinsic: DTime Intrinsic (subroutine). ! * dummies, unused: Warning Options. ! * edit descriptor, <>: I/O. ! * edit descriptor, O: I/O. ! * edit descriptor, Q: Q Edit Descriptor. ! * edit descriptor, Z <1>: Fortran 90 Features. ! * edit descriptor, Z: I/O. ! * effecting IMPLICIT NONE: Warning Options. ! * efficiency: Efficiency. ! * ELF support: News. ! * empty CHARACTER strings: Character Type. ! * enabled intrinsics: Intrinsic Groups. ! * ENCODE statement: ENCODE and DECODE. ! * END DO: END DO. ! * entry points: Alternate Entry Points. ! * ENTRY statement: Alternate Entry Points. ! * environment variables: Environment Variables. ! * EOShift intrinsic: EOShift Intrinsic. ! * Epsilon intrinsic: Epsilon Intrinsic. ! * equivalence areas <1>: Known Bugs. ! * equivalence areas <2>: Local Equivalence Areas. ! * equivalence areas: Debugging Options. ! * EQUIVALENCE statement: Local Equivalence Areas. ! * ErF intrinsic: ErF Intrinsic. ! * ErFC intrinsic: ErFC Intrinsic. ! * error messages <1>: Warnings and Errors. ! * error messages: Run-time Library Errors. ! * error messages, incorrect: What is GNU Fortran?. ! * error values: Run-time Library Errors. ! * errors, linker: Large Common Blocks. ! * ETime intrinsic <1>: ETime Intrinsic (function). ! * ETime intrinsic: ETime Intrinsic (subroutine). ! * exceptions, floating-point: Floating-point Exception Handling. ! * exclamation point <1>: LEX. ! * exclamation point <2>: Exclamation Point. ! * exclamation point <3>: Trailing Comment. ! * exclamation point <4>: Character Set. ! * exclamation point: Statements Comments Lines. ! * executable file: What is GNU Fortran?. ! * Exit intrinsic: Exit Intrinsic. ! * EXIT statement: CYCLE and EXIT. ! * Exp intrinsic: Exp Intrinsic. ! * Exponent intrinsic: Exponent Intrinsic. ! * extended-source option: Fortran Dialect Options. ! * extensions, file name: Overall Options. ! * extensions, from Fortran 90: Fortran 90 Features. ! * extensions, more: More Extensions. ! * extensions, VXT: VXT Fortran. ! * external names: Mangling of Names. ! * extra warnings: Warning Options. ! * f2c: Increasing Precision/Range. ! * f2c compatibility <1>: Avoid f2c Compatibility. ! * f2c compatibility <2>: Block Data and Libraries. ! * f2c compatibility <3>: Debugging and Interfacing. ! * f2c compatibility <4>: Code Gen Options. ! * f2c compatibility <5>: Shorthand Options. ! * f2c compatibility: Overall Options. ! * f2c intrinsics: Fortran Dialect Options. ! * f2c intrinsics group: Intrinsic Groups. ! * f77 compatibility: Shorthand Options. ! * f77 support: Backslash in Constants. ! * f771, program: What is GNU Fortran?. ! * f90 intrinsics group: Intrinsic Groups. ! * fatal signal: Bug Criteria. ! * FDate intrinsic <1>: FDate Intrinsic (function). ! * FDate intrinsic: FDate Intrinsic (subroutine). ! * FDL, GNU Free Documentation License: GNU Free Documentation License. ! * features, language: Direction of Language Development. ! * features, ugly <1>: Distensions. ! * features, ugly: Shorthand Options. ! * FFE <1>: Front End. ! * FFE: What is GNU Fortran?. ! * fflush(): Output Assumed To Flush. ! * FGet intrinsic <1>: FGet Intrinsic (function). ! * FGet intrinsic: FGet Intrinsic (subroutine). ! * FGetC intrinsic <1>: FGetC Intrinsic (function). ! * FGetC intrinsic: FGetC Intrinsic (subroutine). ! * file format not recognized: What is GNU Fortran?. ! * file formats: Portable Unformatted Files. ! * file name extension: Overall Options. ! * file name suffix: Overall Options. ! * file type: Overall Options. ! * file, source <1>: Source Form. ! * file, source <2>: Lines. ! * file, source: What is GNU Fortran?. ! * files, executable: What is GNU Fortran?. ! * fixed form <1>: Source Form. ! * fixed form <2>: Lines. ! * fixed form: Fortran Dialect Options. ! * Float intrinsic: Float Intrinsic. ! * FloatI intrinsic: FloatI Intrinsic. ! * floating-point errors: Floating-point Errors. ! * floating-point, errors: Inconsistent Calling Sequences. ! * floating-point, exceptions: Floating-point Exception Handling. ! * floating-point, precision <1>: Floating-point precision. ! * floating-point, precision: Optimize Options. ! * FloatJ intrinsic: FloatJ Intrinsic. ! * Floor intrinsic: Floor Intrinsic. ! * Flush intrinsic: Flush Intrinsic. ! * flushing output: Output Assumed To Flush. ! * FNum intrinsic: FNum Intrinsic. ! * FORM='PRINT': OPEN CLOSE and INQUIRE Keywords. ! * FORMAT descriptors <1>: Fortran 90 Features. ! * FORMAT descriptors: I/O. ! * FORMAT statement <1>: Q Edit Descriptor. ! * FORMAT statement: Expressions in FORMAT Statements. ! * FORTRAN 66 <1>: Fortran Dialect Options. ! * FORTRAN 66: Shorthand Options. ! * FORTRAN 77 compatibility: Standard Support. ! * Fortran 90: Fortran 90 Features. ! * Fortran 90, compatibility: Fortran 90. ! * Fortran 90, features: Fortran Dialect Options. ! * Fortran 90, intrinsics: Fortran Dialect Options. ! * Fortran 90, support: Fortran 90 Support. ! * Fortran preprocessor: Overall Options. ! * forward references: GLOBALS. ! * FPE handling: Floating-point Exception Handling. ! * FPut intrinsic <1>: FPut Intrinsic (function). ! * FPut intrinsic: FPut Intrinsic (subroutine). ! * FPutC intrinsic <1>: FPutC Intrinsic (function). ! * FPutC intrinsic: FPutC Intrinsic (subroutine). ! * Fraction intrinsic: Fraction Intrinsic. ! * free form <1>: Source Form. ! * free form <2>: Lines. ! * free form: Fortran Dialect Options. ! * front end, g77 <1>: Front End. ! * front end, g77: What is GNU Fortran?. ! * FSeek intrinsic: FSeek Intrinsic. ! * FSF, funding the: Funding GNU Fortran. ! * FStat intrinsic <1>: FStat Intrinsic (function). ! * FStat intrinsic: FStat Intrinsic (subroutine). ! * FTell intrinsic <1>: FTell Intrinsic (function). ! * FTell intrinsic: FTell Intrinsic (subroutine). ! * function references, in adjustable array bounds: Array Bounds Expressions. ! * FUNCTION statement <1>: Functions. ! * FUNCTION statement: Procedures. ! * functions: Functions. ! * functions, mistyped: Not My Type. ! * funding improvements: Funding GNU Fortran. ! * funding the FSF: Funding GNU Fortran. ! * g77 options, --driver <1>: Changes. ! * g77 options, --driver: News. ! * g77 options, -v: G77 and GCC. ! * g77, command <1>: G77 and GCC. ! * g77, command: What is GNU Fortran?. ! * g77, components of: What is GNU Fortran?. ! * g77, front end <1>: Front End. ! * g77, front end: What is GNU Fortran?. ! * G77_date_y2kbuggy_0: Year 2000 (Y2K) Problems. ! * G77_vxtidate_y2kbuggy_0: Year 2000 (Y2K) Problems. ! * GBE <1>: Philosophy of Code Generation. ! * GBE: What is GNU Fortran?. ! * GBEL: Philosophy of Code Generation. ! * gcc, back end <1>: Philosophy of Code Generation. ! * gcc, back end: What is GNU Fortran?. ! * gcc, command <1>: G77 and GCC. ! * gcc, command: What is GNU Fortran?. ! * gcc, command as driver: What is GNU Fortran?. ! * gcc, not recognizing Fortran source: What is GNU Fortran?. ! * gdb, command: What is GNU Fortran?. ! * gdb, support: Debugger Problems. ! * generic intrinsics: Generics and Specifics. ! * GError intrinsic: GError Intrinsic. ! * GetArg intrinsic <1>: Main Program Unit. ! * GetArg intrinsic: GetArg Intrinsic. ! * GetCWD intrinsic <1>: GetCWD Intrinsic (function). ! * GetCWD intrinsic: GetCWD Intrinsic (subroutine). ! * GetEnv intrinsic: GetEnv Intrinsic. ! * GetGId intrinsic: GetGId Intrinsic. ! * GetLog intrinsic: GetLog Intrinsic. ! * GetPId intrinsic: GetPId Intrinsic. ! * getting started: Getting Started. ! * GetUId intrinsic: GetUId Intrinsic. ! * global names, warning <1>: Code Gen Options. ! * global names, warning: Warning Options. ! * GMTime intrinsic: GMTime Intrinsic. ! * GNU Back End (GBE) <1>: Philosophy of Code Generation. ! * GNU Back End (GBE): What is GNU Fortran?. ! * GNU Back End Language (GBEL): Philosophy of Code Generation. ! * GNU Fortran command options: Invoking G77. ! * GNU Fortran Front End (FFE) <1>: Front End. ! * GNU Fortran Front End (FFE): What is GNU Fortran?. ! * gnu intrinsics group: Intrinsic Groups. ! * GOTO statement: Assigned Statement Labels. ! * groups of intrinsics: Intrinsic Groups. ! * hardware errors: Signal 11 and Friends. ! * hash mark: Character Set. ! * HDF: Portable Unformatted Files. ! * hidden intrinsics: Intrinsic Groups. ! * Hollerith constants <1>: Character and Hollerith Constants. ! * Hollerith constants <2>: Ugly Conversion of Initializers. ! * Hollerith constants <3>: Ugly Implicit Argument Conversion. ! * Hollerith constants: Fortran Dialect Options. ! * horizontal tab: Tabs. ! * HostNm intrinsic <1>: HostNm Intrinsic (function). ! * HostNm intrinsic: HostNm Intrinsic (subroutine). ! * Huge intrinsic: Huge Intrinsic. ! * I/O, errors: Run-time Library Errors. ! * I/O, flushing: Output Assumed To Flush. ! * IAbs intrinsic: IAbs Intrinsic. ! * IAChar intrinsic: IAChar Intrinsic. ! * IAnd intrinsic: IAnd Intrinsic. ! * IArgC intrinsic <1>: Main Program Unit. ! * IArgC intrinsic: IArgC Intrinsic. ! * IBClr intrinsic: IBClr Intrinsic. ! * IBits intrinsic: IBits Intrinsic. ! * IBSet intrinsic: IBSet Intrinsic. ! * IChar intrinsic: IChar Intrinsic. ! * IDate intrinsic <1>: IDate Intrinsic (VXT). ! * IDate intrinsic: IDate Intrinsic (UNIX). ! * IDiM intrinsic: IDiM Intrinsic. ! * IDInt intrinsic: IDInt Intrinsic. ! * IDNInt intrinsic: IDNInt Intrinsic. ! * IEEE 754 conformance <1>: Floating-point precision. ! * IEEE 754 conformance: Optimize Options. ! * IEOr intrinsic: IEOr Intrinsic. ! * IErrNo intrinsic: IErrNo Intrinsic. ! * IFix intrinsic: IFix Intrinsic. ! * IIAbs intrinsic: IIAbs Intrinsic. ! * IIAnd intrinsic: IIAnd Intrinsic. ! * IIBClr intrinsic: IIBClr Intrinsic. ! * IIBits intrinsic: IIBits Intrinsic. ! * IIBSet intrinsic: IIBSet Intrinsic. ! * IIDiM intrinsic: IIDiM Intrinsic. ! * IIDInt intrinsic: IIDInt Intrinsic. ! * IIDNnt intrinsic: IIDNnt Intrinsic. ! * IIEOr intrinsic: IIEOr Intrinsic. ! * IIFix intrinsic: IIFix Intrinsic. ! * IInt intrinsic: IInt Intrinsic. ! * IIOr intrinsic: IIOr Intrinsic. ! * IIQint intrinsic: IIQint Intrinsic. ! * IIQNnt intrinsic: IIQNnt Intrinsic. ! * IIShftC intrinsic: IIShftC Intrinsic. ! * IISign intrinsic: IISign Intrinsic. ! * illegal unit number: Large File Unit Numbers. ! * Imag intrinsic: Imag Intrinsic. ! * imaginary part <1>: Complex Variables. ! * imaginary part: Ugly Complex Part Extraction. ! * ImagPart intrinsic: ImagPart Intrinsic. ! * IMax0 intrinsic: IMax0 Intrinsic. ! * IMax1 intrinsic: IMax1 Intrinsic. ! * IMin0 intrinsic: IMin0 Intrinsic. ! * IMin1 intrinsic: IMin1 Intrinsic. ! * IMod intrinsic: IMod Intrinsic. ! * IMPLICIT CHARACTER*(*) statement: Limitation on Implicit Declarations. ! * implicit declaration, warning: Warning Options. ! * IMPLICIT NONE, similar effect: Warning Options. ! * implicit typing: Not My Type. ! * improvements, funding: Funding GNU Fortran. ! * in-line code <1>: GLOBALS. ! * in-line code <2>: Code Gen Options. ! * in-line code <3>: Optimize Options. ! * in-line code: What is GNU Fortran?. ! * INCLUDE directive <1>: Bug Reporting. ! * INCLUDE directive <2>: INCLUDE. ! * INCLUDE directive <3>: Directory Options. ! * INCLUDE directive: Preprocessor Options. ! * included files: Bug Reporting. ! * inclusion, directory search paths for: Directory Options. ! * inconsistent floating-point results: Floating-point Errors. ! * incorrect diagnostics: What is GNU Fortran?. ! * incorrect error messages: What is GNU Fortran?. ! * incorrect use of language: What is GNU Fortran?. ! * increasing maximum unit number: Large File Unit Numbers. ! * increasing precision: Increasing Precision/Range. ! * increasing range: Increasing Precision/Range. ! * Index intrinsic: Index Intrinsic. ! * indexed (iterative) DO: Optimize Options. ! * infinite spaces printed: Strange Behavior at Run Time. ! * INInt intrinsic: INInt Intrinsic. ! * initialization, bug: Known Bugs. ! * initialization, of local variables: Code Gen Options. ! * initialization, run-time: Startup Code. ! * initialization, statement placement: Initializing Before Specifying. ! * INot intrinsic: INot Intrinsic. ! * INQUIRE statement: OPEN CLOSE and INQUIRE Keywords. ! * installation trouble: Trouble. ! * installing, GNU Fortran: Installation. ! * Int intrinsic: Int Intrinsic. ! * Int2 intrinsic: Int2 Intrinsic. ! * Int8 intrinsic: Int8 Intrinsic. ! * integer constants: Known Bugs. ! * INTEGER(KIND=1) type: Compiler Types. ! * INTEGER(KIND=2) type: Compiler Types. ! * INTEGER(KIND=3) type: Compiler Types. ! * INTEGER(KIND=6) type: Compiler Types. ! * INTEGER*2 support: Popular Non-standard Types. ! * INTEGER*8 support: Full Support for Compiler Types. ! * Intel x86: News. ! * interfacing: Debugging and Interfacing. ! * internal consistency checks: Overall Options. ! * intrinsics, Abort: Abort Intrinsic. ! * intrinsics, Abs: Abs Intrinsic. ! * intrinsics, Access: Access Intrinsic. ! * intrinsics, AChar: AChar Intrinsic. ! * intrinsics, ACos: ACos Intrinsic. ! * intrinsics, ACosD: ACosD Intrinsic. ! * intrinsics, AdjustL: AdjustL Intrinsic. ! * intrinsics, AdjustR: AdjustR Intrinsic. ! * intrinsics, AImag <1>: AImag Intrinsic. ! * intrinsics, AImag: REAL() and AIMAG() of Complex. ! * intrinsics, AIMax0: AIMax0 Intrinsic. ! * intrinsics, AIMin0: AIMin0 Intrinsic. ! * intrinsics, AInt: AInt Intrinsic. ! * intrinsics, AJMax0: AJMax0 Intrinsic. ! * intrinsics, AJMin0: AJMin0 Intrinsic. ! * intrinsics, Alarm: Alarm Intrinsic. ! * intrinsics, All: All Intrinsic. ! * intrinsics, Allocated: Allocated Intrinsic. ! * intrinsics, ALog: ALog Intrinsic. ! * intrinsics, ALog10: ALog10 Intrinsic. ! * intrinsics, AMax0: AMax0 Intrinsic. ! * intrinsics, AMax1: AMax1 Intrinsic. ! * intrinsics, AMin0: AMin0 Intrinsic. ! * intrinsics, AMin1: AMin1 Intrinsic. ! * intrinsics, AMod: AMod Intrinsic. ! * intrinsics, And <1>: Bit Operations on Floating-point Data. ! * intrinsics, And: And Intrinsic. ! * intrinsics, ANInt: ANInt Intrinsic. ! * intrinsics, Any: Any Intrinsic. ! * intrinsics, ASin: ASin Intrinsic. ! * intrinsics, ASinD: ASinD Intrinsic. ! * intrinsics, Associated: Associated Intrinsic. ! * intrinsics, ATan: ATan Intrinsic. ! * intrinsics, ATan2: ATan2 Intrinsic. ! * intrinsics, ATan2D: ATan2D Intrinsic. ! * intrinsics, ATanD: ATanD Intrinsic. ! * intrinsics, badu77: Fortran Dialect Options. ! * intrinsics, BesJ0: BesJ0 Intrinsic. ! * intrinsics, BesJ1: BesJ1 Intrinsic. ! * intrinsics, BesJN: BesJN Intrinsic. ! * intrinsics, BesY0: BesY0 Intrinsic. ! * intrinsics, BesY1: BesY1 Intrinsic. ! * intrinsics, BesYN: BesYN Intrinsic. ! * intrinsics, Bit_Size: Bit_Size Intrinsic. ! * intrinsics, BITest: BITest Intrinsic. ! * intrinsics, BJTest: BJTest Intrinsic. ! * intrinsics, BTest: BTest Intrinsic. ! * intrinsics, CAbs: CAbs Intrinsic. ! * intrinsics, CCos: CCos Intrinsic. ! * intrinsics, CDAbs: CDAbs Intrinsic. ! * intrinsics, CDCos: CDCos Intrinsic. ! * intrinsics, CDExp: CDExp Intrinsic. ! * intrinsics, CDLog: CDLog Intrinsic. ! * intrinsics, CDSin: CDSin Intrinsic. ! * intrinsics, CDSqRt: CDSqRt Intrinsic. ! * intrinsics, Ceiling: Ceiling Intrinsic. ! * intrinsics, CExp: CExp Intrinsic. ! * intrinsics, Char: Char Intrinsic. ! * intrinsics, ChDir <1>: ChDir Intrinsic (function). ! * intrinsics, ChDir: ChDir Intrinsic (subroutine). ! * intrinsics, ChMod <1>: ChMod Intrinsic (function). ! * intrinsics, ChMod: ChMod Intrinsic (subroutine). ! * intrinsics, CLog: CLog Intrinsic. ! * intrinsics, Cmplx <1>: Cmplx Intrinsic. ! * intrinsics, Cmplx: CMPLX() of DOUBLE PRECISION. ! * intrinsics, Complex: Complex Intrinsic. ! * intrinsics, COMPLEX: Fortran Dialect Options. ! * intrinsics, Conjg: Conjg Intrinsic. ! * intrinsics, context-sensitive: Context-Sensitive Intrinsicness. ! * intrinsics, Cos: Cos Intrinsic. ! * intrinsics, CosD: CosD Intrinsic. ! * intrinsics, CosH: CosH Intrinsic. ! * intrinsics, Count: Count Intrinsic. ! * intrinsics, CPU_Time: CPU_Time Intrinsic. ! * intrinsics, CShift: CShift Intrinsic. ! * intrinsics, CSin: CSin Intrinsic. ! * intrinsics, CSqRt: CSqRt Intrinsic. ! * intrinsics, CTime <1>: CTime Intrinsic (function). ! * intrinsics, CTime: CTime Intrinsic (subroutine). ! * intrinsics, DAbs: DAbs Intrinsic. ! * intrinsics, DACos: DACos Intrinsic. ! * intrinsics, DACosD: DACosD Intrinsic. ! * intrinsics, DASin: DASin Intrinsic. ! * intrinsics, DASinD: DASinD Intrinsic. ! * intrinsics, DATan: DATan Intrinsic. ! * intrinsics, DATan2: DATan2 Intrinsic. ! * intrinsics, DATan2D: DATan2D Intrinsic. ! * intrinsics, DATanD: DATanD Intrinsic. ! * intrinsics, Date: Date Intrinsic. ! * intrinsics, Date_and_Time: Date_and_Time Intrinsic. ! * intrinsics, DbesJ0: DbesJ0 Intrinsic. ! * intrinsics, DbesJ1: DbesJ1 Intrinsic. ! * intrinsics, DbesJN: DbesJN Intrinsic. ! * intrinsics, DbesY0: DbesY0 Intrinsic. ! * intrinsics, DbesY1: DbesY1 Intrinsic. ! * intrinsics, DbesYN: DbesYN Intrinsic. ! * intrinsics, Dble: Dble Intrinsic. ! * intrinsics, DbleQ: DbleQ Intrinsic. ! * intrinsics, DCmplx: DCmplx Intrinsic. ! * intrinsics, DConjg: DConjg Intrinsic. ! * intrinsics, DCos: DCos Intrinsic. ! * intrinsics, DCosD: DCosD Intrinsic. ! * intrinsics, DCosH: DCosH Intrinsic. ! * intrinsics, DDiM: DDiM Intrinsic. ! * intrinsics, deleted: Intrinsic Groups. ! * intrinsics, DErF: DErF Intrinsic. ! * intrinsics, DErFC: DErFC Intrinsic. ! * intrinsics, DExp: DExp Intrinsic. ! * intrinsics, DFloat: DFloat Intrinsic. ! * intrinsics, DFlotI: DFlotI Intrinsic. ! * intrinsics, DFlotJ: DFlotJ Intrinsic. ! * intrinsics, Digits: Digits Intrinsic. ! * intrinsics, DiM: DiM Intrinsic. ! * intrinsics, DImag: DImag Intrinsic. ! * intrinsics, DInt: DInt Intrinsic. ! * intrinsics, disabled: Intrinsic Groups. ! * intrinsics, DLog: DLog Intrinsic. ! * intrinsics, DLog10: DLog10 Intrinsic. ! * intrinsics, DMax1: DMax1 Intrinsic. ! * intrinsics, DMin1: DMin1 Intrinsic. ! * intrinsics, DMod: DMod Intrinsic. ! * intrinsics, DNInt: DNInt Intrinsic. ! * intrinsics, Dot_Product: Dot_Product Intrinsic. ! * intrinsics, DProd: DProd Intrinsic. ! * intrinsics, DReal: DReal Intrinsic. ! * intrinsics, DSign: DSign Intrinsic. ! * intrinsics, DSin: DSin Intrinsic. ! * intrinsics, DSinD: DSinD Intrinsic. ! * intrinsics, DSinH: DSinH Intrinsic. ! * intrinsics, DSqRt: DSqRt Intrinsic. ! * intrinsics, DTan: DTan Intrinsic. ! * intrinsics, DTanD: DTanD Intrinsic. ! * intrinsics, DTanH: DTanH Intrinsic. ! * intrinsics, DTime <1>: DTime Intrinsic (function). ! * intrinsics, DTime: DTime Intrinsic (subroutine). ! * intrinsics, enabled: Intrinsic Groups. ! * intrinsics, EOShift: EOShift Intrinsic. ! * intrinsics, Epsilon: Epsilon Intrinsic. ! * intrinsics, ErF: ErF Intrinsic. ! * intrinsics, ErFC: ErFC Intrinsic. ! * intrinsics, ETime <1>: ETime Intrinsic (function). ! * intrinsics, ETime: ETime Intrinsic (subroutine). ! * intrinsics, Exit: Exit Intrinsic. ! * intrinsics, Exp: Exp Intrinsic. ! * intrinsics, Exponent: Exponent Intrinsic. ! * intrinsics, f2c: Fortran Dialect Options. ! * intrinsics, FDate <1>: FDate Intrinsic (function). ! * intrinsics, FDate: FDate Intrinsic (subroutine). ! * intrinsics, FGet <1>: FGet Intrinsic (function). ! * intrinsics, FGet: FGet Intrinsic (subroutine). ! * intrinsics, FGetC <1>: FGetC Intrinsic (function). ! * intrinsics, FGetC: FGetC Intrinsic (subroutine). ! * intrinsics, Float: Float Intrinsic. ! * intrinsics, FloatI: FloatI Intrinsic. ! * intrinsics, FloatJ: FloatJ Intrinsic. ! * intrinsics, Floor: Floor Intrinsic. ! * intrinsics, Flush: Flush Intrinsic. ! * intrinsics, FNum: FNum Intrinsic. ! * intrinsics, Fortran 90: Fortran Dialect Options. ! * intrinsics, FPut <1>: FPut Intrinsic (function). ! * intrinsics, FPut: FPut Intrinsic (subroutine). ! * intrinsics, FPutC <1>: FPutC Intrinsic (function). ! * intrinsics, FPutC: FPutC Intrinsic (subroutine). ! * intrinsics, Fraction: Fraction Intrinsic. ! * intrinsics, FSeek: FSeek Intrinsic. ! * intrinsics, FStat <1>: FStat Intrinsic (function). ! * intrinsics, FStat: FStat Intrinsic (subroutine). ! * intrinsics, FTell <1>: FTell Intrinsic (function). ! * intrinsics, FTell: FTell Intrinsic (subroutine). ! * intrinsics, generic: Generics and Specifics. ! * intrinsics, GError: GError Intrinsic. ! * intrinsics, GetArg <1>: Main Program Unit. ! * intrinsics, GetArg: GetArg Intrinsic. ! * intrinsics, GetCWD <1>: GetCWD Intrinsic (function). ! * intrinsics, GetCWD: GetCWD Intrinsic (subroutine). ! * intrinsics, GetEnv: GetEnv Intrinsic. ! * intrinsics, GetGId: GetGId Intrinsic. ! * intrinsics, GetLog: GetLog Intrinsic. ! * intrinsics, GetPId: GetPId Intrinsic. ! * intrinsics, GetUId: GetUId Intrinsic. ! * intrinsics, GMTime: GMTime Intrinsic. ! * intrinsics, groups: Intrinsic Groups. ! * intrinsics, groups of: Intrinsic Groups. ! * intrinsics, hidden: Intrinsic Groups. ! * intrinsics, HostNm <1>: HostNm Intrinsic (function). ! * intrinsics, HostNm: HostNm Intrinsic (subroutine). ! * intrinsics, Huge: Huge Intrinsic. ! * intrinsics, IAbs: IAbs Intrinsic. ! * intrinsics, IAChar: IAChar Intrinsic. ! * intrinsics, IAnd: IAnd Intrinsic. ! * intrinsics, IArgC <1>: Main Program Unit. ! * intrinsics, IArgC: IArgC Intrinsic. ! * intrinsics, IBClr: IBClr Intrinsic. ! * intrinsics, IBits: IBits Intrinsic. ! * intrinsics, IBSet: IBSet Intrinsic. ! * intrinsics, IChar: IChar Intrinsic. ! * intrinsics, IDate <1>: IDate Intrinsic (VXT). ! * intrinsics, IDate: IDate Intrinsic (UNIX). ! * intrinsics, IDiM: IDiM Intrinsic. ! * intrinsics, IDInt: IDInt Intrinsic. ! * intrinsics, IDNInt: IDNInt Intrinsic. ! * intrinsics, IEOr: IEOr Intrinsic. ! * intrinsics, IErrNo: IErrNo Intrinsic. ! * intrinsics, IFix: IFix Intrinsic. ! * intrinsics, IIAbs: IIAbs Intrinsic. ! * intrinsics, IIAnd: IIAnd Intrinsic. ! * intrinsics, IIBClr: IIBClr Intrinsic. ! * intrinsics, IIBits: IIBits Intrinsic. ! * intrinsics, IIBSet: IIBSet Intrinsic. ! * intrinsics, IIDiM: IIDiM Intrinsic. ! * intrinsics, IIDInt: IIDInt Intrinsic. ! * intrinsics, IIDNnt: IIDNnt Intrinsic. ! * intrinsics, IIEOr: IIEOr Intrinsic. ! * intrinsics, IIFix: IIFix Intrinsic. ! * intrinsics, IInt: IInt Intrinsic. ! * intrinsics, IIOr: IIOr Intrinsic. ! * intrinsics, IIQint: IIQint Intrinsic. ! * intrinsics, IIQNnt: IIQNnt Intrinsic. ! * intrinsics, IIShftC: IIShftC Intrinsic. ! * intrinsics, IISign: IISign Intrinsic. ! * intrinsics, Imag: Imag Intrinsic. ! * intrinsics, ImagPart: ImagPart Intrinsic. ! * intrinsics, IMax0: IMax0 Intrinsic. ! * intrinsics, IMax1: IMax1 Intrinsic. ! * intrinsics, IMin0: IMin0 Intrinsic. ! * intrinsics, IMin1: IMin1 Intrinsic. ! * intrinsics, IMod: IMod Intrinsic. ! * intrinsics, Index: Index Intrinsic. ! * intrinsics, INInt: INInt Intrinsic. ! * intrinsics, INot: INot Intrinsic. ! * intrinsics, Int: Int Intrinsic. ! * intrinsics, Int2: Int2 Intrinsic. ! * intrinsics, Int8: Int8 Intrinsic. ! * intrinsics, IOr: IOr Intrinsic. ! * intrinsics, IRand: IRand Intrinsic. ! * intrinsics, IsaTty: IsaTty Intrinsic. ! * intrinsics, IShft: IShft Intrinsic. ! * intrinsics, IShftC: IShftC Intrinsic. ! * intrinsics, ISign: ISign Intrinsic. ! * intrinsics, ITime: ITime Intrinsic. ! * intrinsics, IZExt: IZExt Intrinsic. ! * intrinsics, JIAbs: JIAbs Intrinsic. ! * intrinsics, JIAnd: JIAnd Intrinsic. ! * intrinsics, JIBClr: JIBClr Intrinsic. ! * intrinsics, JIBits: JIBits Intrinsic. ! * intrinsics, JIBSet: JIBSet Intrinsic. ! * intrinsics, JIDiM: JIDiM Intrinsic. ! * intrinsics, JIDInt: JIDInt Intrinsic. ! * intrinsics, JIDNnt: JIDNnt Intrinsic. ! * intrinsics, JIEOr: JIEOr Intrinsic. ! * intrinsics, JIFix: JIFix Intrinsic. ! * intrinsics, JInt: JInt Intrinsic. ! * intrinsics, JIOr: JIOr Intrinsic. ! * intrinsics, JIQint: JIQint Intrinsic. ! * intrinsics, JIQNnt: JIQNnt Intrinsic. ! * intrinsics, JIShft: JIShft Intrinsic. ! * intrinsics, JIShftC: JIShftC Intrinsic. ! * intrinsics, JISign: JISign Intrinsic. ! * intrinsics, JMax0: JMax0 Intrinsic. ! * intrinsics, JMax1: JMax1 Intrinsic. ! * intrinsics, JMin0: JMin0 Intrinsic. ! * intrinsics, JMin1: JMin1 Intrinsic. ! * intrinsics, JMod: JMod Intrinsic. ! * intrinsics, JNInt: JNInt Intrinsic. ! * intrinsics, JNot: JNot Intrinsic. ! * intrinsics, JZExt: JZExt Intrinsic. ! * intrinsics, Kill <1>: Kill Intrinsic (function). ! * intrinsics, Kill: Kill Intrinsic (subroutine). ! * intrinsics, Kind: Kind Intrinsic. ! * intrinsics, LBound: LBound Intrinsic. ! * intrinsics, Len: Len Intrinsic. ! * intrinsics, Len_Trim: Len_Trim Intrinsic. ! * intrinsics, LGe: LGe Intrinsic. ! * intrinsics, LGt: LGt Intrinsic. ! * intrinsics, Link <1>: Link Intrinsic (function). ! * intrinsics, Link: Link Intrinsic (subroutine). ! * intrinsics, LLe: LLe Intrinsic. ! * intrinsics, LLt: LLt Intrinsic. ! * intrinsics, LnBlnk: LnBlnk Intrinsic. ! * intrinsics, Loc: Loc Intrinsic. ! * intrinsics, Log: Log Intrinsic. ! * intrinsics, Log10: Log10 Intrinsic. ! * intrinsics, Logical: Logical Intrinsic. ! * intrinsics, Long: Long Intrinsic. ! * intrinsics, LShift: LShift Intrinsic. ! * intrinsics, LStat <1>: LStat Intrinsic (function). ! * intrinsics, LStat: LStat Intrinsic (subroutine). ! * intrinsics, LTime: LTime Intrinsic. ! * intrinsics, MatMul: MatMul Intrinsic. ! * intrinsics, Max: Max Intrinsic. ! * intrinsics, Max0: Max0 Intrinsic. ! * intrinsics, Max1: Max1 Intrinsic. ! * intrinsics, MaxExponent: MaxExponent Intrinsic. ! * intrinsics, MaxLoc: MaxLoc Intrinsic. ! * intrinsics, MaxVal: MaxVal Intrinsic. ! * intrinsics, MClock: MClock Intrinsic. ! * intrinsics, MClock8: MClock8 Intrinsic. ! * intrinsics, Merge: Merge Intrinsic. ! * intrinsics, MIL-STD 1753: Fortran Dialect Options. ! * intrinsics, Min: Min Intrinsic. ! * intrinsics, Min0: Min0 Intrinsic. ! * intrinsics, Min1: Min1 Intrinsic. ! * intrinsics, MinExponent: MinExponent Intrinsic. ! * intrinsics, MinLoc: MinLoc Intrinsic. ! * intrinsics, MinVal: MinVal Intrinsic. ! * intrinsics, Mod: Mod Intrinsic. ! * intrinsics, Modulo: Modulo Intrinsic. ! * intrinsics, MvBits: MvBits Intrinsic. ! * intrinsics, Nearest: Nearest Intrinsic. ! * intrinsics, NInt: NInt Intrinsic. ! * intrinsics, Not: Not Intrinsic. ! * intrinsics, Or <1>: Bit Operations on Floating-point Data. ! * intrinsics, Or: Or Intrinsic. ! * intrinsics, others: Other Intrinsics. ! * intrinsics, Pack: Pack Intrinsic. ! * intrinsics, PError: PError Intrinsic. ! * intrinsics, Precision: Precision Intrinsic. ! * intrinsics, Present: Present Intrinsic. ! * intrinsics, Product: Product Intrinsic. ! * intrinsics, QAbs: QAbs Intrinsic. ! * intrinsics, QACos: QACos Intrinsic. ! * intrinsics, QACosD: QACosD Intrinsic. ! * intrinsics, QASin: QASin Intrinsic. ! * intrinsics, QASinD: QASinD Intrinsic. ! * intrinsics, QATan: QATan Intrinsic. ! * intrinsics, QATan2: QATan2 Intrinsic. ! * intrinsics, QATan2D: QATan2D Intrinsic. ! * intrinsics, QATanD: QATanD Intrinsic. ! * intrinsics, QCos: QCos Intrinsic. ! * intrinsics, QCosD: QCosD Intrinsic. ! * intrinsics, QCosH: QCosH Intrinsic. ! * intrinsics, QDiM: QDiM Intrinsic. ! * intrinsics, QExp: QExp Intrinsic. ! * intrinsics, QExt: QExt Intrinsic. ! * intrinsics, QExtD: QExtD Intrinsic. ! * intrinsics, QFloat: QFloat Intrinsic. ! * intrinsics, QInt: QInt Intrinsic. ! * intrinsics, QLog: QLog Intrinsic. ! * intrinsics, QLog10: QLog10 Intrinsic. ! * intrinsics, QMax1: QMax1 Intrinsic. ! * intrinsics, QMin1: QMin1 Intrinsic. ! * intrinsics, QMod: QMod Intrinsic. ! * intrinsics, QNInt: QNInt Intrinsic. ! * intrinsics, QSin: QSin Intrinsic. ! * intrinsics, QSinD: QSinD Intrinsic. ! * intrinsics, QSinH: QSinH Intrinsic. ! * intrinsics, QSqRt: QSqRt Intrinsic. ! * intrinsics, QTan: QTan Intrinsic. ! * intrinsics, QTanD: QTanD Intrinsic. ! * intrinsics, QTanH: QTanH Intrinsic. ! * intrinsics, Radix: Radix Intrinsic. ! * intrinsics, Rand: Rand Intrinsic. ! * intrinsics, Random_Number: Random_Number Intrinsic. ! * intrinsics, Random_Seed: Random_Seed Intrinsic. ! * intrinsics, Range: Range Intrinsic. ! * intrinsics, Real <1>: Real Intrinsic. ! * intrinsics, Real: REAL() and AIMAG() of Complex. ! * intrinsics, RealPart: RealPart Intrinsic. ! * intrinsics, Rename <1>: Rename Intrinsic (function). ! * intrinsics, Rename: Rename Intrinsic (subroutine). ! * intrinsics, Repeat: Repeat Intrinsic. ! * intrinsics, Reshape: Reshape Intrinsic. ! * intrinsics, RRSpacing: RRSpacing Intrinsic. ! * intrinsics, RShift: RShift Intrinsic. ! * intrinsics, Scale: Scale Intrinsic. ! * intrinsics, Scan: Scan Intrinsic. ! * intrinsics, Secnds: Secnds Intrinsic. ! * intrinsics, Second <1>: Second Intrinsic (subroutine). ! * intrinsics, Second: Second Intrinsic (function). ! * intrinsics, Selected_Int_Kind: Selected_Int_Kind Intrinsic. ! * intrinsics, Selected_Real_Kind: Selected_Real_Kind Intrinsic. ! * intrinsics, Set_Exponent: Set_Exponent Intrinsic. ! * intrinsics, Shape: Shape Intrinsic. ! * intrinsics, Shift: Bit Operations on Floating-point Data. ! * intrinsics, Short: Short Intrinsic. ! * intrinsics, Sign: Sign Intrinsic. ! * intrinsics, Signal <1>: Signal Intrinsic (function). ! * intrinsics, Signal: Signal Intrinsic (subroutine). ! * intrinsics, Sin: Sin Intrinsic. ! * intrinsics, SinD: SinD Intrinsic. ! * intrinsics, SinH: SinH Intrinsic. ! * intrinsics, Sleep: Sleep Intrinsic. ! * intrinsics, Sngl: Sngl Intrinsic. ! * intrinsics, SnglQ: SnglQ Intrinsic. ! * intrinsics, Spacing: Spacing Intrinsic. ! * intrinsics, Spread: Spread Intrinsic. ! * intrinsics, SqRt: SqRt Intrinsic. ! * intrinsics, SRand: SRand Intrinsic. ! * intrinsics, Stat <1>: Stat Intrinsic (function). ! * intrinsics, Stat: Stat Intrinsic (subroutine). ! * intrinsics, Sum: Sum Intrinsic. ! * intrinsics, SymLnk <1>: SymLnk Intrinsic (function). ! * intrinsics, SymLnk: SymLnk Intrinsic (subroutine). ! * intrinsics, System <1>: System Intrinsic (function). ! * intrinsics, System: System Intrinsic (subroutine). ! * intrinsics, System_Clock: System_Clock Intrinsic. ! * intrinsics, table of: Table of Intrinsic Functions. ! * intrinsics, Tan: Tan Intrinsic. ! * intrinsics, TanD: TanD Intrinsic. ! * intrinsics, TanH: TanH Intrinsic. ! * intrinsics, Time <1>: Time Intrinsic (VXT). ! * intrinsics, Time: Time Intrinsic (UNIX). ! * intrinsics, Time8: Time8 Intrinsic. ! * intrinsics, Tiny: Tiny Intrinsic. ! * intrinsics, Transfer: Transfer Intrinsic. ! * intrinsics, Transpose: Transpose Intrinsic. ! * intrinsics, Trim: Trim Intrinsic. ! * intrinsics, TtyNam <1>: TtyNam Intrinsic (function). ! * intrinsics, TtyNam: TtyNam Intrinsic (subroutine). ! * intrinsics, UBound: UBound Intrinsic. ! * intrinsics, UMask <1>: UMask Intrinsic (function). ! * intrinsics, UMask: UMask Intrinsic (subroutine). ! * intrinsics, UNIX: Fortran Dialect Options. ! * intrinsics, Unlink <1>: Unlink Intrinsic (function). ! * intrinsics, Unlink: Unlink Intrinsic (subroutine). ! * intrinsics, Unpack: Unpack Intrinsic. ! * intrinsics, Verify: Verify Intrinsic. ! * intrinsics, VXT: Fortran Dialect Options. ! * intrinsics, XOr: XOr Intrinsic. ! * intrinsics, ZAbs: ZAbs Intrinsic. ! * intrinsics, ZCos: ZCos Intrinsic. ! * intrinsics, ZExp: ZExp Intrinsic. ! * intrinsics, ZExt: ZExt Intrinsic. ! * intrinsics, ZLog: ZLog Intrinsic. ! * intrinsics, ZSin: ZSin Intrinsic. ! * intrinsics, ZSqRt: ZSqRt Intrinsic. ! * Introduction: Top. ! * invalid assembly code: Bug Criteria. ! * invalid input: Bug Criteria. ! * IOr intrinsic: IOr Intrinsic. ! * IOSTAT=: Run-time Library Errors. ! * IRand intrinsic: IRand Intrinsic. ! * IsaTty intrinsic: IsaTty Intrinsic. ! * IShft intrinsic: IShft Intrinsic. ! * IShftC intrinsic: IShftC Intrinsic. ! * ISign intrinsic: ISign Intrinsic. ! * iterative DO: Optimize Options. ! * ITime intrinsic: ITime Intrinsic. ! * ix86 floating-point: Floating-point precision. ! * ix86 FPU stack: Inconsistent Calling Sequences. ! * IZExt intrinsic: IZExt Intrinsic. ! * JCB002 program: Generics and Specifics. ! * JCB003 program: CMPAMBIG. ! * JIAbs intrinsic: JIAbs Intrinsic. ! * JIAnd intrinsic: JIAnd Intrinsic. ! * JIBClr intrinsic: JIBClr Intrinsic. ! * JIBits intrinsic: JIBits Intrinsic. ! * JIBSet intrinsic: JIBSet Intrinsic. ! * JIDiM intrinsic: JIDiM Intrinsic. ! * JIDInt intrinsic: JIDInt Intrinsic. ! * JIDNnt intrinsic: JIDNnt Intrinsic. ! * JIEOr intrinsic: JIEOr Intrinsic. ! * JIFix intrinsic: JIFix Intrinsic. ! * JInt intrinsic: JInt Intrinsic. ! * JIOr intrinsic: JIOr Intrinsic. ! * JIQint intrinsic: JIQint Intrinsic. ! * JIQNnt intrinsic: JIQNnt Intrinsic. ! * JIShft intrinsic: JIShft Intrinsic. ! * JIShftC intrinsic: JIShftC Intrinsic. ! * JISign intrinsic: JISign Intrinsic. ! * JMax0 intrinsic: JMax0 Intrinsic. ! * JMax1 intrinsic: JMax1 Intrinsic. ! * JMin0 intrinsic: JMin0 Intrinsic. ! * JMin1 intrinsic: JMin1 Intrinsic. ! * JMod intrinsic: JMod Intrinsic. ! * JNInt intrinsic: JNInt Intrinsic. ! * JNot intrinsic: JNot Intrinsic. ! * JZExt intrinsic: JZExt Intrinsic. ! * keywords, RECURSIVE: RECURSIVE Keyword. ! * Kill intrinsic <1>: Kill Intrinsic (function). ! * Kill intrinsic: Kill Intrinsic (subroutine). ! * Kind intrinsic: Kind Intrinsic. ! * KIND= notation: Kind Notation. ! * known causes of trouble: Trouble. ! * lack of recursion: RECURSIVE Keyword. ! * language, dialect options: Fortran Dialect Options. ! * language, features: Direction of Language Development. ! * language, incorrect use of: What is GNU Fortran?. ! * large aggregate areas: Known Bugs. ! * large common blocks: Large Common Blocks. ! * layout of COMMON blocks: Aligned Data. ! * LBound intrinsic: LBound Intrinsic. ! * ld command: What is GNU Fortran?. ! * ld, can't find _main: Cannot Link Fortran Programs. ! * ld, can't find strange names: Cannot Link Fortran Programs. ! * ld, error linking user code: Cannot Link Fortran Programs. ! * ld, errors: Large Common Blocks. ! * left angle: Character Set. ! * left bracket: Character Set. ! * legacy code: Collected Fortran Wisdom. ! * Len intrinsic: Len Intrinsic. ! * Len_Trim intrinsic: Len_Trim Intrinsic. ! * length of source lines: Fortran Dialect Options. ! * letters, lowercase: Case Sensitivity. ! * letters, uppercase: Case Sensitivity. ! * LGe intrinsic: LGe Intrinsic. ! * LGt intrinsic: LGt Intrinsic. ! * libc, non-ANSI or non-default: Strange Behavior at Run Time. ! * libf2c library: What is GNU Fortran?. ! * libg2c library: What is GNU Fortran?. ! * libraries: What is GNU Fortran?. ! * libraries, containing BLOCK DATA: Block Data and Libraries. ! * libraries, libf2c: What is GNU Fortran?. ! * libraries, libg2c: What is GNU Fortran?. ! * limits, array dimensions: Compiler Limits. ! * limits, array size: Array Size. ! * limits, compiler: Compiler Limits. ! * limits, continuation lines <1>: Compiler Limits. ! * limits, continuation lines: Continuation Line. ! * limits, lengths of names <1>: Compiler Limits. ! * limits, lengths of names: Syntactic Items. ! * limits, lengths of source lines: Fortran Dialect Options. ! * limits, multi-dimension arrays: Array Size. ! * limits, on character-variable length: Character-variable Length. ! * limits, rank: Compiler Limits. ! * limits, run-time library: Run-time Environment Limits. ! * limits, timings <1>: Secnds Intrinsic. ! * limits, timings <2>: DTime Intrinsic (function). ! * limits, timings <3>: Time8 Intrinsic. ! * limits, timings <4>: Time Intrinsic (UNIX). ! * limits, timings <5>: System_Clock Intrinsic. ! * limits, timings <6>: Second Intrinsic (subroutine). ! * limits, timings <7>: Second Intrinsic (function). ! * limits, timings <8>: MClock8 Intrinsic. ! * limits, timings <9>: MClock Intrinsic. ! * limits, timings <10>: ETime Intrinsic (function). ! * limits, timings <11>: ETime Intrinsic (subroutine). ! * limits, timings <12>: DTime Intrinsic (subroutine). ! * limits, timings: CPU_Time Intrinsic. ! * limits, Y10K <1>: Time Intrinsic (VXT). ! * limits, Y10K <2>: IDate Intrinsic (UNIX). ! * limits, Y10K <3>: FDate Intrinsic (function). ! * limits, Y10K <4>: FDate Intrinsic (subroutine). ! * limits, Y10K: Date_and_Time Intrinsic. ! * limits, Y2K: IDate Intrinsic (VXT). ! * lines: Lines. ! * lines, continuation: Continuation Line. ! * lines, length: Fortran Dialect Options. ! * lines, long: Long Lines. ! * lines, short: Short Lines. ! * Link intrinsic <1>: Link Intrinsic (function). ! * Link intrinsic: Link Intrinsic (subroutine). ! * linking: What is GNU Fortran?. ! * linking against non-standard library: Strange Behavior at Run Time. ! * linking error for user code: Cannot Link Fortran Programs. ! * linking error, user code: Cannot Link Fortran Programs. ! * linking with C: Interoperating with C and C++. ! * linking, errors: Large Common Blocks. ! * LLe intrinsic: LLe Intrinsic. ! * LLt intrinsic: LLt Intrinsic. ! * LnBlnk intrinsic: LnBlnk Intrinsic. ! * Loc intrinsic: Loc Intrinsic. ! * local equivalence areas <1>: Known Bugs. ! * local equivalence areas: Local Equivalence Areas. ! * Log intrinsic: Log Intrinsic. ! * Log10 intrinsic: Log10 Intrinsic. ! * logical expressions, comparing: Equivalence Versus Equality. ! * Logical intrinsic: Logical Intrinsic. ! * LOGICAL(KIND=1) type: Compiler Types. ! * LOGICAL(KIND=2) type: Compiler Types. ! * LOGICAL(KIND=3) type: Compiler Types. ! * LOGICAL(KIND=6) type: Compiler Types. ! * LOGICAL*1 support: Popular Non-standard Types. ! * Long intrinsic: Long Intrinsic. ! * long source lines: Long Lines. ! * long time: Timer Wraparounds. ! * loops, optimizing: Optimize Options. ! * loops, speeding up: Optimize Options. ! * loops, unrolling: Optimize Options. ! * lowercase letters: Case Sensitivity. ! * LShift intrinsic: LShift Intrinsic. ! * LStat intrinsic <1>: LStat Intrinsic (function). ! * LStat intrinsic: LStat Intrinsic (subroutine). ! * LTime intrinsic: LTime Intrinsic. ! * machine code: What is GNU Fortran?. ! * macro options: Shorthand Options. ! * main program unit, debugging: Main Program Unit. ! * main(): Main Program Unit. ! * MAIN__(): Main Program Unit. ! * Makefile example: Bug Criteria. ! * MAP statement: STRUCTURE UNION RECORD MAP. ! * MatMul intrinsic: MatMul Intrinsic. ! * Max intrinsic: Max Intrinsic. ! * Max0 intrinsic: Max0 Intrinsic. ! * Max1 intrinsic: Max1 Intrinsic. ! * MaxExponent intrinsic: MaxExponent Intrinsic. ! * maximum number of dimensions: Compiler Limits. ! * maximum rank: Compiler Limits. ! * maximum unit number: Large File Unit Numbers. ! * MaxLoc intrinsic: MaxLoc Intrinsic. ! * MaxVal intrinsic: MaxVal Intrinsic. ! * MClock intrinsic: MClock Intrinsic. ! * MClock8 intrinsic: MClock8 Intrinsic. ! * memory usage, of compiler: Known Bugs. ! * Merge intrinsic: Merge Intrinsic. ! * messages, run-time: Run-time Library Errors. ! * messages, warning: Warning Options. ! * messages, warning and error: Warnings and Errors. ! * mil intrinsics group: Intrinsic Groups. ! * MIL-STD 1753 <1>: MIL-STD 1753. ! * MIL-STD 1753 <2>: END DO. ! * MIL-STD 1753 <3>: DO WHILE. ! * MIL-STD 1753: Fortran Dialect Options. ! * Min intrinsic: Min Intrinsic. ! * Min0 intrinsic: Min0 Intrinsic. ! * Min1 intrinsic: Min1 Intrinsic. ! * MinExponent intrinsic: MinExponent Intrinsic. ! * MinLoc intrinsic: MinLoc Intrinsic. ! * MinVal intrinsic: MinVal Intrinsic. ! * missing debug features: Debugging Options. ! * mistakes: What is GNU Fortran?. ! * mistyped functions: Not My Type. ! * mistyped variables: Not My Type. ! * Mod intrinsic: Mod Intrinsic. ! * modifying g77: Overall Options. ! * Modulo intrinsic: Modulo Intrinsic. ! * multi-dimension arrays: Array Size. ! * MvBits intrinsic: MvBits Intrinsic. ! * MXUNIT: Large File Unit Numbers. ! * name space: Mangling of Names. ! * NAMELIST statement: NAMELIST. ! * naming conflicts: Multiple Definitions of External Names. ! * naming issues: Mangling of Names. ! * naming programs: Nothing Happens. ! * NaN values: Floating-point Exception Handling. ! * Nearest intrinsic: Nearest Intrinsic. ! * negative forms of options: Invoking G77. ! * negative time: Timer Wraparounds. ! * Netlib <1>: Increasing Precision/Range. ! * Netlib: C Interfacing Tools. ! * network file system: Output Assumed To Flush. ! * new users: Getting Started. ! * newbies: Getting Started. ! * NeXTStep problems: NeXTStep Problems. ! * NFS: Output Assumed To Flush. ! * NInt intrinsic: NInt Intrinsic. ! * nonportable conversions: Nonportable Conversions. ! * Not intrinsic: Not Intrinsic. ! * nothing happens: Nothing Happens. ! * null arguments: Ugly Null Arguments. ! * null byte, trailing: Character and Hollerith Constants. ! * null CHARACTER strings: Character Type. ! * number of continuation lines: Continuation Line. ! * number of dimensions, maximum: Compiler Limits. ! * number of trips: Loops. ! * O edit descriptor: I/O. ! * octal constants: Double Quote Meaning. ! * omitting arguments: Ugly Null Arguments. ! * one-trip DO loops: Fortran Dialect Options. ! * open angle: Character Set. ! * open bracket: Character Set. ! * OPEN statement: OPEN CLOSE and INQUIRE Keywords. ! * optimization, better: Better Optimization. ! * optimization, for Pentium: Aligned Data. ! * optimize options: Optimize Options. ! * options, --driver <1>: Changes. ! * options, --driver: News. ! * options, -falias-check <1>: Aliasing Assumed To Work. ! * options, -falias-check: Code Gen Options. ! * options, -fargument-alias <1>: Aliasing Assumed To Work. ! * options, -fargument-alias: Code Gen Options. ! * options, -fargument-noalias <1>: Aliasing Assumed To Work. ! * options, -fargument-noalias: Code Gen Options. ! * options, -fbadu77-intrinsics-delete: Fortran Dialect Options. ! * options, -fbadu77-intrinsics-disable: Fortran Dialect Options. ! * options, -fbadu77-intrinsics-enable: Fortran Dialect Options. ! * options, -fbadu77-intrinsics-hide: Fortran Dialect Options. ! * options, -fcaller-saves: Optimize Options. ! * options, -fcase-initcap: Fortran Dialect Options. ! * options, -fcase-lower: Fortran Dialect Options. ! * options, -fcase-preserve: Fortran Dialect Options. ! * options, -fcase-strict-lower: Fortran Dialect Options. ! * options, -fcase-strict-upper: Fortran Dialect Options. ! * options, -fcase-upper: Fortran Dialect Options. ! * options, -fdebug-kludge: Code Gen Options. ! * options, -fdelayed-branch: Optimize Options. ! * options, -fdollar-ok: Fortran Dialect Options. ! * options, -femulate-complex: Code Gen Options. ! * options, -fexpensive-optimizations: Optimize Options. ! * options, -ff2c-intrinsics-delete: Fortran Dialect Options. ! * options, -ff2c-intrinsics-disable: Fortran Dialect Options. ! * options, -ff2c-intrinsics-enable: Fortran Dialect Options. ! * options, -ff2c-intrinsics-hide: Fortran Dialect Options. ! * options, -ff2c-library: Code Gen Options. ! * options, -ff66: Shorthand Options. ! * options, -ff77: Shorthand Options. ! * options, -ff90: Fortran Dialect Options. ! * options, -ff90-intrinsics-delete: Fortran Dialect Options. ! * options, -ff90-intrinsics-disable: Fortran Dialect Options. ! * options, -ff90-intrinsics-enable: Fortran Dialect Options. ! * options, -ff90-intrinsics-hide: Fortran Dialect Options. ! * options, -ffast-math: Optimize Options. ! * options, -ffixed-line-length-N: Fortran Dialect Options. ! * options, -ffloat-store: Optimize Options. ! * options, -fforce-addr: Optimize Options. ! * options, -fforce-mem: Optimize Options. ! * options, -ffree-form: Fortran Dialect Options. ! * options, -fgnu-intrinsics-delete: Fortran Dialect Options. ! * options, -fgnu-intrinsics-disable: Fortran Dialect Options. ! * options, -fgnu-intrinsics-enable: Fortran Dialect Options. ! * options, -fgnu-intrinsics-hide: Fortran Dialect Options. ! * options, -fGROUP-intrinsics-hide: Overly Convenient Options. ! * options, -finit-local-zero <1>: Overly Convenient Options. ! * options, -finit-local-zero: Code Gen Options. ! * options, -fintrin-case-any: Fortran Dialect Options. ! * options, -fintrin-case-initcap: Fortran Dialect Options. ! * options, -fintrin-case-lower: Fortran Dialect Options. ! * options, -fintrin-case-upper: Fortran Dialect Options. ! * options, -fmatch-case-any: Fortran Dialect Options. ! * options, -fmatch-case-initcap: Fortran Dialect Options. ! * options, -fmatch-case-lower: Fortran Dialect Options. ! * options, -fmatch-case-upper: Fortran Dialect Options. ! * options, -fmil-intrinsics-delete: Fortran Dialect Options. ! * options, -fmil-intrinsics-disable: Fortran Dialect Options. ! * options, -fmil-intrinsics-enable: Fortran Dialect Options. ! * options, -fmil-intrinsics-hide: Fortran Dialect Options. ! * options, -fno-argument-noalias-global <1>: Aliasing Assumed To Work. ! * options, -fno-argument-noalias-global: Code Gen Options. ! * options, -fno-automatic <1>: Overly Convenient Options. ! * options, -fno-automatic: Code Gen Options. ! * options, -fno-backslash: Fortran Dialect Options. ! * options, -fno-common: Code Gen Options. ! * options, -fno-f2c <1>: Avoid f2c Compatibility. ! * options, -fno-f2c: Code Gen Options. ! * options, -fno-f77: Shorthand Options. ! * options, -fno-fixed-form: Fortran Dialect Options. ! * options, -fno-globals: Code Gen Options. ! * options, -fno-ident: Code Gen Options. ! * options, -fno-inline: Optimize Options. ! * options, -fno-move-all-movables: Optimize Options. ! * options, -fno-reduce-all-givs: Optimize Options. ! * options, -fno-rerun-loop-opt: Optimize Options. ! * options, -fno-second-underscore: Code Gen Options. ! * options, -fno-silent: Overall Options. ! * options, -fno-ugly: Shorthand Options. ! * options, -fno-ugly-args: Fortran Dialect Options. ! * options, -fno-ugly-init: Fortran Dialect Options. ! * options, -fno-underscoring <1>: Names. ! * options, -fno-underscoring: Code Gen Options. ! * options, -fonetrip: Fortran Dialect Options. ! * options, -fpack-struct: Code Gen Options. ! * options, -fpcc-struct-return: Code Gen Options. ! * options, -fpedantic: Warning Options. ! * options, -fPIC: News. ! * options, -freg-struct-return: Code Gen Options. ! * options, -frerun-cse-after-loop: Optimize Options. ! * options, -fschedule-insns: Optimize Options. ! * options, -fschedule-insns2: Optimize Options. ! * options, -fset-g77-defaults: Overall Options. ! * options, -fshort-double: Code Gen Options. ! * options, -fsource-case-lower: Fortran Dialect Options. ! * options, -fsource-case-preserve: Fortran Dialect Options. ! * options, -fsource-case-upper: Fortran Dialect Options. ! * options, -fstrength-reduce: Optimize Options. ! * options, -fsymbol-case-any: Fortran Dialect Options. ! * options, -fsymbol-case-initcap: Fortran Dialect Options. ! * options, -fsymbol-case-lower: Fortran Dialect Options. ! * options, -fsymbol-case-upper: Fortran Dialect Options. ! * options, -fsyntax-only: Warning Options. ! * options, -ftypeless-boz: Fortran Dialect Options. ! * options, -fugly: Shorthand Options. ! * options, -fugly-assign: Fortran Dialect Options. ! * options, -fugly-assumed: Fortran Dialect Options. ! * options, -fugly-comma: Fortran Dialect Options. ! * options, -fugly-complex: Fortran Dialect Options. ! * options, -fugly-logint: Fortran Dialect Options. ! * options, -funix-intrinsics-delete: Fortran Dialect Options. ! * options, -funix-intrinsics-disable: Fortran Dialect Options. ! * options, -funix-intrinsics-enable: Fortran Dialect Options. ! * options, -funix-intrinsics-hide: Fortran Dialect Options. ! * options, -funroll-all-loops: Optimize Options. ! * options, -funroll-loops: Optimize Options. ! * options, -fversion: Overall Options. ! * options, -fvxt: Fortran Dialect Options. ! * options, -fvxt-intrinsics-delete: Fortran Dialect Options. ! * options, -fvxt-intrinsics-disable: Fortran Dialect Options. ! * options, -fvxt-intrinsics-enable: Fortran Dialect Options. ! * options, -fvxt-intrinsics-hide: Fortran Dialect Options. ! * options, -fzeros: Code Gen Options. ! * options, -g: Debugging Options. ! * options, -I-: Directory Options. ! * options, -Idir: Directory Options. ! * options, -malign-double <1>: Aligned Data. ! * options, -malign-double: Optimize Options. ! * options, -Nl: Compiler Limits. ! * options, -Nx: Compiler Limits. ! * options, -pedantic: Warning Options. ! * options, -pedantic-errors: Warning Options. ! * options, -v: G77 and GCC. ! * options, -W: Warning Options. ! * options, -w: Warning Options. ! * options, -Waggregate-return: Warning Options. ! * options, -Wall: Warning Options. ! * options, -Wcomment: Warning Options. ! * options, -Wconversion: Warning Options. ! * options, -Werror: Warning Options. ! * options, -Wformat: Warning Options. ! * options, -Wid-clash-LEN: Warning Options. ! * options, -Wimplicit: Warning Options. ! * options, -Wlarger-than-LEN: Warning Options. ! * options, -Wno-globals: Warning Options. ! * options, -Wparentheses: Warning Options. ! * options, -Wredundant-decls: Warning Options. ! * options, -Wshadow: Warning Options. ! * options, -Wsurprising: Warning Options. ! * options, -Wswitch: Warning Options. ! * options, -Wtraditional: Warning Options. ! * options, -Wuninitialized: Warning Options. ! * options, -Wunused: Warning Options. ! * options, -x f77-cpp-input: LEX. ! * options, adding: Adding Options. ! * options, code generation: Code Gen Options. ! * options, debugging: Debugging Options. ! * options, dialect: Fortran Dialect Options. ! * options, directory search: Directory Options. ! * options, GNU Fortran command: Invoking G77. ! * options, macro: Shorthand Options. ! * options, negative forms: Invoking G77. ! * options, optimization: Optimize Options. ! * options, overall: Overall Options. ! * options, overly convenient: Overly Convenient Options. ! * options, preprocessor: Preprocessor Options. ! * options, shorthand: Shorthand Options. ! * options, warnings: Warning Options. ! * Or intrinsic <1>: Bit Operations on Floating-point Data. ! * Or intrinsic: Or Intrinsic. ! * order of evaluation, side effects: Order of Side Effects. ! * ordering, array: Arrays. ! * other intrinsics: Other Intrinsics. ! * output, flushing: Output Assumed To Flush. ! * overall options: Overall Options. ! * overflow: Warning Options. ! * overlapping arguments: Aliasing Assumed To Work. ! * overlays: Aliasing Assumed To Work. ! * overly convenient options: Overly Convenient Options. ! * overwritten data: Strange Behavior at Run Time. ! * Pack intrinsic: Pack Intrinsic. ! * padding: Known Bugs. ! * parallel processing: Support for Threads. ! * PARAMETER statement <1>: Old-style PARAMETER Statements. ! * PARAMETER statement: Intrinsics in PARAMETER Statements. ! * parameters, unused: Warning Options. ! * paths, search: Directory Options. ! * PDB: Portable Unformatted Files. ! * pedantic compilation: Pedantic Compilation. ! * Pentium optimizations: Aligned Data. ! * percent sign: Character Set. ! * PError intrinsic: PError Intrinsic. ! * placing initialization statements: Initializing Before Specifying. ! * POINTER statement: POINTER Statements. ! * pointers <1>: Ugly Assigned Labels. ! * pointers: Kind Notation. ! * Poking the bear: Philosophy of Code Generation. ! * porting, simplify: Simplify Porting. ! * pound sign: Character Set. ! * Precision intrinsic: Precision Intrinsic. ! * precision, increasing: Increasing Precision/Range. ! * prefix-radix constants: Fortran Dialect Options. ! * preprocessor <1>: LEX. ! * preprocessor <2>: Bug Reporting. ! * preprocessor <3>: Cpp-style directives. ! * preprocessor <4>: Overall Options. ! * preprocessor: What is GNU Fortran?. ! * preprocessor options: Preprocessor Options. ! * Present intrinsic: Present Intrinsic. ! * printing compilation status: Overall Options. ! * printing main source: Known Bugs. ! * printing version information <1>: Overall Options. ! * printing version information: What is GNU Fortran?. ! * procedures: Procedures. ! * Product intrinsic: Product Intrinsic. ! * PROGRAM statement: Main Program Unit. ! * programs, cc1: What is GNU Fortran?. ! * programs, cc1plus: What is GNU Fortran?. ! * programs, compiling: G77 and GCC. ! * programs, cpp <1>: LEX. ! * programs, cpp <2>: Bug Reporting. ! * programs, cpp <3>: Preprocessor Options. ! * programs, cpp <4>: Overall Options. ! * programs, cpp: What is GNU Fortran?. ! * programs, f771: What is GNU Fortran?. ! * programs, ratfor: Overall Options. ! * programs, speeding up: Faster Programs. ! * programs, test: Nothing Happens. ! * projects: Projects. ! * Q edit descriptor: Q Edit Descriptor. ! * QAbs intrinsic: QAbs Intrinsic. ! * QACos intrinsic: QACos Intrinsic. ! * QACosD intrinsic: QACosD Intrinsic. ! * QASin intrinsic: QASin Intrinsic. ! * QASinD intrinsic: QASinD Intrinsic. ! * QATan intrinsic: QATan Intrinsic. ! * QATan2 intrinsic: QATan2 Intrinsic. ! * QATan2D intrinsic: QATan2D Intrinsic. ! * QATanD intrinsic: QATanD Intrinsic. ! * QCos intrinsic: QCos Intrinsic. ! * QCosD intrinsic: QCosD Intrinsic. ! * QCosH intrinsic: QCosH Intrinsic. ! * QDiM intrinsic: QDiM Intrinsic. ! * QExp intrinsic: QExp Intrinsic. ! * QExt intrinsic: QExt Intrinsic. ! * QExtD intrinsic: QExtD Intrinsic. ! * QFloat intrinsic: QFloat Intrinsic. ! * QInt intrinsic: QInt Intrinsic. ! * QLog intrinsic: QLog Intrinsic. ! * QLog10 intrinsic: QLog10 Intrinsic. ! * QMax1 intrinsic: QMax1 Intrinsic. ! * QMin1 intrinsic: QMin1 Intrinsic. ! * QMod intrinsic: QMod Intrinsic. ! * QNInt intrinsic: QNInt Intrinsic. ! * QSin intrinsic: QSin Intrinsic. ! * QSinD intrinsic: QSinD Intrinsic. ! * QSinH intrinsic: QSinH Intrinsic. ! * QSqRt intrinsic: QSqRt Intrinsic. ! * QTan intrinsic: QTan Intrinsic. ! * QTanD intrinsic: QTanD Intrinsic. ! * QTanH intrinsic: QTanH Intrinsic. ! * question mark: Character Set. ! * questionable instructions: What is GNU Fortran?. ! * Radix intrinsic: Radix Intrinsic. ! * Rand intrinsic: Rand Intrinsic. ! * Random_Number intrinsic: Random_Number Intrinsic. ! * Random_Seed intrinsic: Random_Seed Intrinsic. ! * range checking: Code Gen Options. ! * Range intrinsic: Range Intrinsic. ! * range, increasing: Increasing Precision/Range. ! * rank, maximum: Compiler Limits. ! * ratfor: Overall Options. ! * Ratfor preprocessor: Overall Options. ! * READONLY: READONLY Keyword. ! * reads and writes, scheduling: Aliasing Assumed To Work. ! * Real intrinsic <1>: Real Intrinsic. ! * Real intrinsic: REAL() and AIMAG() of Complex. ! * real part: Ugly Complex Part Extraction. ! * REAL(KIND=1) type: Compiler Types. ! * REAL(KIND=2) type: Compiler Types. ! * REAL*16 support: Full Support for Compiler Types. ! * RealPart intrinsic: RealPart Intrinsic. ! * recent versions <1>: Changes. ! * recent versions: News. ! * RECORD statement: STRUCTURE UNION RECORD MAP. ! * recursion, lack of: RECURSIVE Keyword. ! * RECURSIVE keyword: RECURSIVE Keyword. ! * reference works: Language. ! * Rename intrinsic <1>: Rename Intrinsic (function). ! * Rename intrinsic: Rename Intrinsic (subroutine). ! * Repeat intrinsic: Repeat Intrinsic. ! * reporting bugs: Bugs. ! * reporting compilation status: Overall Options. ! * Reshape intrinsic: Reshape Intrinsic. ! * results, inconsistent: Floating-point Errors. ! * RETURN statement <1>: Alternate Returns. ! * RETURN statement: Functions. ! * return type of functions: Functions. ! * right angle: Character Set. ! * right bracket: Character Set. ! * rounding errors: Floating-point Errors. ! * row-major ordering: Arrays. ! * RRSpacing intrinsic: RRSpacing Intrinsic. ! * RShift intrinsic: RShift Intrinsic. ! * run-time, dynamic allocation: Arbitrary Concatenation. ! * run-time, initialization: Startup Code. ! * run-time, library: What is GNU Fortran?. ! * run-time, options: Code Gen Options. ! * SAVE statement: Code Gen Options. ! * saved variables: Variables Assumed To Be Saved. ! * Scale intrinsic: Scale Intrinsic. ! * Scan intrinsic: Scan Intrinsic. ! * scheduling of reads and writes: Aliasing Assumed To Work. ! * scope <1>: Scope and Classes of Names. ! * scope: Scope of Names and Labels. ! * search path: Directory Options. ! * search paths, for included files: Directory Options. ! * Secnds intrinsic: Secnds Intrinsic. ! * Second intrinsic <1>: Second Intrinsic (subroutine). ! * Second intrinsic: Second Intrinsic (function). ! * segmentation violation <1>: Strange Behavior at Run Time. ! * segmentation violation <2>: Stack Overflow. ! * segmentation violation: NeXTStep Problems. ! * Selected_Int_Kind intrinsic: Selected_Int_Kind Intrinsic. ! * Selected_Real_Kind intrinsic: Selected_Real_Kind Intrinsic. ! * semicolon <1>: Character Set. ! * semicolon: Statements Comments Lines. ! * sequence numbers: Better Source Model. ! * Set_Exponent intrinsic: Set_Exponent Intrinsic. ! * Shape intrinsic: Shape Intrinsic. ! * SHARED: READONLY Keyword. ! * Shift intrinsic: Bit Operations on Floating-point Data. ! * Short intrinsic: Short Intrinsic. ! * short source lines: Short Lines. ! * short time: Timer Wraparounds. ! * shorthand options: Shorthand Options. ! * side effects, order of evaluation: Order of Side Effects. ! * Sign intrinsic: Sign Intrinsic. ! * signal 11: Signal 11 and Friends. ! * Signal intrinsic <1>: Signal Intrinsic (function). ! * Signal intrinsic: Signal Intrinsic (subroutine). ! * signature of procedures: Procedures. ! * simplify porting: Simplify Porting. ! * Sin intrinsic: Sin Intrinsic. ! * SinD intrinsic: SinD Intrinsic. ! * SinH intrinsic: SinH Intrinsic. ! * Sleep intrinsic: Sleep Intrinsic. ! * Sngl intrinsic: Sngl Intrinsic. ! * SnglQ intrinsic: SnglQ Intrinsic. ! * Solaris: Strange Behavior at Run Time. ! * source code <1>: Case Sensitivity. ! * source code <2>: Source Form. ! * source code <3>: Lines. ! * source code: What is GNU Fortran?. ! * source file: What is GNU Fortran?. ! * source file format <1>: Case Sensitivity. ! * source file format <2>: Source Form. ! * source file format <3>: Lines. ! * source file format: Fortran Dialect Options. ! * source format <1>: Source Form. ! * source format: Lines. ! * source lines, long: Long Lines. ! * source lines, short: Short Lines. ! * space <1>: Lines. ! * space: Character Set. ! * space, endless printing of: Strange Behavior at Run Time. ! * space, padding with: Short Lines. ! * Spacing intrinsic: Spacing Intrinsic. ! * SPC <1>: Lines. ! * SPC: Character Set. ! * speed, of compiler: Known Bugs. ! * speed, of loops: Optimize Options. ! * speed, of programs: Faster Programs. ! * spills of floating-point results: Floating-point Errors. ! * Spread intrinsic: Spread Intrinsic. ! * SqRt intrinsic: SqRt Intrinsic. ! * SRand intrinsic: SRand Intrinsic. ! * stack, 387 coprocessor: News. ! * stack, aligned: Aligned Data. ! * stack, overflow: Stack Overflow. ! * standard, ANSI FORTRAN 77: Language. ! * standard, support for: Standard Support. ! * startup code: Startup Code. ! * Stat intrinsic <1>: Stat Intrinsic (function). ! * Stat intrinsic: Stat Intrinsic (subroutine). ! * statement labels, assigned: Assigned Statement Labels. ! * statements, ACCEPT: TYPE and ACCEPT I/O Statements. ! * statements, ASSIGN <1>: Assigned Statement Labels. ! * statements, ASSIGN: Ugly Assigned Labels. ! * statements, AUTOMATIC: AUTOMATIC Statement. ! * statements, BLOCK DATA <1>: Multiple Definitions of External Names. ! * statements, BLOCK DATA: Block Data and Libraries. ! * statements, CLOSE: OPEN CLOSE and INQUIRE Keywords. ! * statements, COMMON <1>: Multiple Definitions of External Names. ! * statements, COMMON: Common Blocks. ! * statements, COMPLEX: Complex Variables. ! * statements, CYCLE: CYCLE and EXIT. ! * statements, DATA <1>: Known Bugs. ! * statements, DATA: Code Gen Options. ! * statements, DECODE: ENCODE and DECODE. ! * statements, DIMENSION <1>: Array Bounds Expressions. ! * statements, DIMENSION <2>: Adjustable Arrays. ! * statements, DIMENSION: Arrays. ! * statements, DO <1>: Loops. ! * statements, DO: Warning Options. ! * statements, ENCODE: ENCODE and DECODE. ! * statements, ENTRY: Alternate Entry Points. ! * statements, EQUIVALENCE: Local Equivalence Areas. ! * statements, EXIT: CYCLE and EXIT. ! * statements, FORMAT: Expressions in FORMAT Statements. ! * statements, FUNCTION <1>: Functions. ! * statements, FUNCTION: Procedures. ! * statements, GOTO: Assigned Statement Labels. ! * statements, IMPLICIT CHARACTER*(*): Limitation on Implicit Declarations. ! * statements, INQUIRE: OPEN CLOSE and INQUIRE Keywords. ! * statements, MAP: STRUCTURE UNION RECORD MAP. ! * statements, NAMELIST: NAMELIST. ! * statements, OPEN: OPEN CLOSE and INQUIRE Keywords. ! * statements, PARAMETER <1>: Old-style PARAMETER Statements. ! * statements, PARAMETER: Intrinsics in PARAMETER Statements. ! * statements, POINTER: POINTER Statements. ! * statements, PROGRAM: Main Program Unit. ! * statements, RECORD: STRUCTURE UNION RECORD MAP. ! * statements, RETURN <1>: Alternate Returns. ! * statements, RETURN: Functions. ! * statements, SAVE: Code Gen Options. ! * statements, separated by semicolon: Statements Comments Lines. ! * statements, STRUCTURE: STRUCTURE UNION RECORD MAP. ! * statements, SUBROUTINE <1>: Alternate Returns. ! * statements, SUBROUTINE: Procedures. ! * statements, TYPE: TYPE and ACCEPT I/O Statements. ! * statements, UNION: STRUCTURE UNION RECORD MAP. ! * STATIC: AUTOMATIC Statement. ! * static variables: Variables Assumed To Be Saved. ! * status, compilation: Overall Options. ! * storage association: Aliasing Assumed To Work. ! * strings, empty: Character Type. ! * STRUCTURE statement: STRUCTURE UNION RECORD MAP. ! * structures: Known Bugs. ! * submodels: Use Submodel Options. ! * SUBROUTINE statement <1>: Alternate Returns. ! * SUBROUTINE statement: Procedures. ! * subroutines: Alternate Returns. ! * subscript checking: Code Gen Options. ! * substring checking: Code Gen Options. ! * suffixes, file name: Overall Options. ! * Sum intrinsic: Sum Intrinsic. ! * support, Alpha: Known Bugs. ! * support, ELF: News. ! * support, f77: Backslash in Constants. ! * support, FORTRAN 77: Standard Support. ! * support, Fortran 90: Fortran 90 Support. ! * support, gdb: Debugger Problems. ! * suppressing warnings: Warning Options. ! * symbol names <1>: Names. ! * symbol names: Fortran Dialect Options. ! * symbol names, scope and classes: Scope and Classes of Names. ! * symbol names, transforming: Code Gen Options. ! * symbol names, underscores: Code Gen Options. ! * SymLnk intrinsic <1>: SymLnk Intrinsic (function). ! * SymLnk intrinsic: SymLnk Intrinsic (subroutine). ! * synchronous write errors: Output Assumed To Flush. ! * syntax checking: Warning Options. ! * System intrinsic <1>: System Intrinsic (function). ! * System intrinsic: System Intrinsic (subroutine). ! * System_Clock intrinsic: System_Clock Intrinsic. ! * tab character: Tabs. ! * table of intrinsics: Table of Intrinsic Functions. ! * Tan intrinsic: Tan Intrinsic. ! * TanD intrinsic: TanD Intrinsic. ! * TanH intrinsic: TanH Intrinsic. ! * test programs: Nothing Happens. ! * testing alignment: Aligned Data. ! * textbooks: Language. ! * threads: Support for Threads. ! * Time intrinsic <1>: Time Intrinsic (VXT). ! * Time intrinsic: Time Intrinsic (UNIX). ! * Time8 intrinsic: Time8 Intrinsic. ! * Tiny intrinsic: Tiny Intrinsic. ! * Toolpack: Increasing Precision/Range. ! * trailing comma: Ugly Null Arguments. ! * trailing comment <1>: LEX. ! * trailing comment <2>: Trailing Comment. ! * trailing comment: Statements Comments Lines. ! * trailing null byte: Character and Hollerith Constants. ! * Transfer intrinsic: Transfer Intrinsic. ! * transforming symbol names <1>: Names. ! * transforming symbol names: Code Gen Options. ! * translation of user programs: What is GNU Fortran?. ! * Transpose intrinsic: Transpose Intrinsic. ! * Trim intrinsic: Trim Intrinsic. ! * trips, number of: Loops. ! * truncation, of floating-point values: Floating-point Errors. ! * truncation, of long lines: Long Lines. ! * TtyNam intrinsic <1>: TtyNam Intrinsic (function). ! * TtyNam intrinsic: TtyNam Intrinsic (subroutine). ! * TYPE statement: TYPE and ACCEPT I/O Statements. ! * types, COMPLEX(KIND=1): Compiler Types. ! * types, COMPLEX(KIND=2): Compiler Types. ! * types, constants <1>: Compiler Constants. ! * types, constants <2>: Constants. ! * types, constants: Fortran Dialect Options. ! * types, DOUBLE COMPLEX: Compiler Types. ! * types, DOUBLE PRECISION: Compiler Types. ! * types, file: Overall Options. ! * types, Fortran/C: C Access to Type Information. ! * types, INTEGER(KIND=1): Compiler Types. ! * types, INTEGER(KIND=2): Compiler Types. ! * types, INTEGER(KIND=3): Compiler Types. ! * types, INTEGER(KIND=6): Compiler Types. ! * types, INTEGER*2: Popular Non-standard Types. ! * types, INTEGER*8: Full Support for Compiler Types. ! * types, LOGICAL(KIND=1): Compiler Types. ! * types, LOGICAL(KIND=2): Compiler Types. ! * types, LOGICAL(KIND=3): Compiler Types. ! * types, LOGICAL(KIND=6): Compiler Types. ! * types, LOGICAL*1: Popular Non-standard Types. ! * types, of data: Compiler Types. ! * types, REAL(KIND=1): Compiler Types. ! * types, REAL(KIND=2): Compiler Types. ! * types, REAL*16: Full Support for Compiler Types. ! * UBound intrinsic: UBound Intrinsic. ! * ugly features <1>: Distensions. ! * ugly features: Shorthand Options. ! * UMask intrinsic <1>: UMask Intrinsic (function). ! * UMask intrinsic: UMask Intrinsic (subroutine). ! * undefined behavior: Bug Criteria. ! * undefined function value: Bug Criteria. ! * undefined reference (_main): Cannot Link Fortran Programs. ! * underscore <1>: Mangling of Names. ! * underscore <2>: Underscores in Symbol Names. ! * underscore <3>: Character Set. ! * underscore: Code Gen Options. ! * unformatted files: Portable Unformatted Files. ! * uninitialized variables <1>: Variables Assumed To Be Zero. ! * uninitialized variables <2>: Code Gen Options. ! * uninitialized variables: Warning Options. ! * UNION statement: STRUCTURE UNION RECORD MAP. ! * unit numbers: Large File Unit Numbers. ! * UNIX f77: Shorthand Options. ! * UNIX intrinsics: Fortran Dialect Options. ! * Unlink intrinsic <1>: Unlink Intrinsic (function). ! * Unlink intrinsic: Unlink Intrinsic (subroutine). ! * Unpack intrinsic: Unpack Intrinsic. ! * unrecognized file format: What is GNU Fortran?. ! * unresolved reference (various): Cannot Link Fortran Programs. ! * unrolling loops: Optimize Options. ! * UNSAVE: AUTOMATIC Statement. ! * unsupported warnings: Warning Options. ! * unused arguments <1>: Unused Arguments. ! * unused arguments: Warning Options. ! * unused dummies: Warning Options. ! * unused parameters: Warning Options. ! * unused variables: Warning Options. ! * uppercase letters: Case Sensitivity. ! * user-visible changes: Changes. ! * variables, assumed to be zero: Variables Assumed To Be Zero. ! * variables, automatic: AUTOMATIC Statement. ! * variables, initialization of: Code Gen Options. ! * variables, mistyped: Not My Type. ! * variables, retaining values across calls: Variables Assumed To Be Saved. ! * variables, uninitialized <1>: Code Gen Options. ! * variables, uninitialized: Warning Options. ! * variables, unused: Warning Options. ! * Verify intrinsic: Verify Intrinsic. ! * version information, printing <1>: Overall Options. ! * version information, printing: What is GNU Fortran?. ! * versions, recent <1>: Changes. ! * versions, recent: News. ! * VXT extensions <1>: VXT Fortran. ! * VXT extensions: Fortran Dialect Options. ! * VXT intrinsics: Fortran Dialect Options. ! * vxtidate_y2kbuggy_0: Year 2000 (Y2K) Problems. ! * warnings: What is GNU Fortran?. ! * warnings vs errors: Warnings and Errors. ! * warnings, all: Warning Options. ! * warnings, extra: Warning Options. ! * warnings, global names <1>: Code Gen Options. ! * warnings, global names: Warning Options. ! * warnings, implicit declaration: Warning Options. ! * warnings, suppressing: Warning Options. ! * warnings, unsupported: Warning Options. ! * wisdom: Collected Fortran Wisdom. ! * wraparound: Run-time Environment Limits. ! * wraparound, timings <1>: Secnds Intrinsic. ! * wraparound, timings <2>: DTime Intrinsic (function). ! * wraparound, timings <3>: Time8 Intrinsic. ! * wraparound, timings <4>: Time Intrinsic (UNIX). ! * wraparound, timings <5>: System_Clock Intrinsic. ! * wraparound, timings <6>: Second Intrinsic (subroutine). ! * wraparound, timings <7>: Second Intrinsic (function). ! * wraparound, timings <8>: MClock8 Intrinsic. ! * wraparound, timings <9>: MClock Intrinsic. ! * wraparound, timings <10>: ETime Intrinsic (function). ! * wraparound, timings <11>: ETime Intrinsic (subroutine). ! * wraparound, timings <12>: DTime Intrinsic (subroutine). ! * wraparound, timings: CPU_Time Intrinsic. ! * wraparound, Y10K <1>: Time Intrinsic (VXT). ! * wraparound, Y10K <2>: IDate Intrinsic (UNIX). ! * wraparound, Y10K <3>: FDate Intrinsic (function). ! * wraparound, Y10K <4>: FDate Intrinsic (subroutine). ! * wraparound, Y10K: Date_and_Time Intrinsic. ! * wraparound, Y2K: IDate Intrinsic (VXT). ! * writes, flushing: Output Assumed To Flush. ! * writing code: Collected Fortran Wisdom. ! * x86 floating-point: Floating-point precision. ! * x86 FPU stack: Inconsistent Calling Sequences. ! * XOr intrinsic: XOr Intrinsic. ! * Y10K compliance <1>: Time Intrinsic (VXT). ! * Y10K compliance <2>: Year 10000 (Y10K) Problems. ! * Y10K compliance <3>: IDate Intrinsic (UNIX). ! * Y10K compliance <4>: FDate Intrinsic (function). ! * Y10K compliance <5>: FDate Intrinsic (subroutine). ! * Y10K compliance: Date_and_Time Intrinsic. ! * Y2K compliance <1>: Y2KBAD. ! * Y2K compliance <2>: IDate Intrinsic (VXT). ! * Y2K compliance <3>: Date Intrinsic. ! * Y2K compliance: Year 2000 (Y2K) Problems. ! * y2kbuggy: Year 2000 (Y2K) Problems. ! * Year 10000 compliance <1>: Time Intrinsic (VXT). ! * Year 10000 compliance <2>: Year 10000 (Y10K) Problems. ! * Year 10000 compliance <3>: IDate Intrinsic (UNIX). ! * Year 10000 compliance <4>: FDate Intrinsic (function). ! * Year 10000 compliance <5>: FDate Intrinsic (subroutine). ! * Year 10000 compliance: Date_and_Time Intrinsic. ! * Year 2000 compliance <1>: Y2KBAD. ! * Year 2000 compliance <2>: IDate Intrinsic (VXT). ! * Year 2000 compliance <3>: Date Intrinsic. ! * Year 2000 compliance: Year 2000 (Y2K) Problems. ! * Z edit descriptor <1>: Fortran 90 Features. ! * Z edit descriptor: I/O. ! * ZAbs intrinsic: ZAbs Intrinsic. ! * ZCos intrinsic: ZCos Intrinsic. ! * zero byte, trailing: Character and Hollerith Constants. ! * zero-initialized variables: Variables Assumed To Be Zero. ! * zero-length CHARACTER: Character Type. ! * zero-trip DO loops: Fortran Dialect Options. ! * ZExp intrinsic: ZExp Intrinsic. ! * ZExt intrinsic: ZExt Intrinsic. ! * ZLog intrinsic: ZLog Intrinsic. ! * ZSin intrinsic: ZSin Intrinsic. ! * ZSqRt intrinsic: ZSqRt Intrinsic. diff -Nrc3pad gcc-3.0.1/gcc/f/g77.info-21 gcc-3.0.2/gcc/f/g77.info-21 *** gcc-3.0.1/gcc/f/g77.info-21 Sun Aug 19 18:52:16 2001 --- gcc-3.0.2/gcc/f/g77.info-21 Wed Dec 31 16:00:00 1969 *************** *** 1,2273 **** - This is g77.info, produced by makeinfo version 4.0 from g77.texi. - - INFO-DIR-SECTION Programming - START-INFO-DIR-ENTRY - * g77: (g77). The GNU Fortran compiler. - END-INFO-DIR-ENTRY - This file documents the use and the internals of the GNU Fortran - (`g77') compiler. It corresponds to the GCC-3.0 version of `g77'. - - Published by the Free Software Foundation 59 Temple Place - Suite 330 - Boston, MA 02111-1307 USA - - Copyright (C) 1995,1996,1997,1998,1999,2000,2001 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.1 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. - - Contributed by James Craig Burley (). Inspired by - a first pass at translating `g77-0.5.16/f/DOC' that was contributed to - Craig by David Ronis (). - -  - File: g77.info, Node: Index, Prev: Diagnostics, Up: Top - - Index - ***** - - * Menu: - - * ! <1>: LEX. - * ! <2>: Exclamation Point. - * ! <3>: Trailing Comment. - * ! <4>: Character Set. - * !: Statements Comments Lines. - * ": Character Set. - * # <1>: Cpp-style directives. - * #: Character Set. - * #define: Overall Options. - * #if: Overall Options. - * #include: Overall Options. - * #include directive: Bug Reporting. - * $: Dollar Signs. - * %: Character Set. - * %DESCR() construct: %DESCR(). - * %LOC() construct: %LOC(). - * %REF() construct: %REF(). - * %VAL() construct: %VAL(). - * &: Character Set. - * *: LEX. - * *N notation <1>: Compiler Types. - * *N notation: Star Notation. - * --driver option <1>: Changes. - * --driver option: News. - * -falias-check option <1>: Aliasing Assumed To Work. - * -falias-check option: Code Gen Options. - * -fargument-alias option <1>: Aliasing Assumed To Work. - * -fargument-alias option: Code Gen Options. - * -fargument-noalias option <1>: Aliasing Assumed To Work. - * -fargument-noalias option: Code Gen Options. - * -fbadu77-intrinsics-delete option: Fortran Dialect Options. - * -fbadu77-intrinsics-disable option: Fortran Dialect Options. - * -fbadu77-intrinsics-enable option: Fortran Dialect Options. - * -fbadu77-intrinsics-hide option: Fortran Dialect Options. - * -fbounds-check option: Code Gen Options. - * -fcaller-saves option: Optimize Options. - * -fcase-initcap option: Fortran Dialect Options. - * -fcase-lower option: Fortran Dialect Options. - * -fcase-preserve option: Fortran Dialect Options. - * -fcase-strict-lower option: Fortran Dialect Options. - * -fcase-strict-upper option: Fortran Dialect Options. - * -fcase-upper option: Fortran Dialect Options. - * -fdebug-kludge option: Code Gen Options. - * -fdelayed-branch option: Optimize Options. - * -fdollar-ok option: Fortran Dialect Options. - * -femulate-complex option: Code Gen Options. - * -fexpensive-optimizations option: Optimize Options. - * -ff2c-intrinsics-delete option: Fortran Dialect Options. - * -ff2c-intrinsics-disable option: Fortran Dialect Options. - * -ff2c-intrinsics-enable option: Fortran Dialect Options. - * -ff2c-intrinsics-hide option: Fortran Dialect Options. - * -ff2c-library option: Code Gen Options. - * -ff66 option: Shorthand Options. - * -ff77 option: Shorthand Options. - * -ff90: Fortran 90 Features. - * -ff90 option: Fortran Dialect Options. - * -ff90-intrinsics-delete option: Fortran Dialect Options. - * -ff90-intrinsics-disable option: Fortran Dialect Options. - * -ff90-intrinsics-enable option: Fortran Dialect Options. - * -ff90-intrinsics-hide option: Fortran Dialect Options. - * -ffast-math option: Optimize Options. - * -ffixed-line-length-N option: Fortran Dialect Options. - * -fflatten-arrays option: Code Gen Options. - * -ffloat-store option: Optimize Options. - * -fforce-addr option: Optimize Options. - * -fforce-mem option: Optimize Options. - * -ffortran-bounds-check option: Code Gen Options. - * -ffree-form: Fortran 90 Features. - * -ffree-form option: Fortran Dialect Options. - * -fgnu-intrinsics-delete option: Fortran Dialect Options. - * -fgnu-intrinsics-disable option: Fortran Dialect Options. - * -fgnu-intrinsics-enable option: Fortran Dialect Options. - * -fgnu-intrinsics-hide option: Fortran Dialect Options. - * -fGROUP-intrinsics-hide option: Overly Convenient Options. - * -finit-local-zero option <1>: Overly Convenient Options. - * -finit-local-zero option: Code Gen Options. - * -fintrin-case-any option: Fortran Dialect Options. - * -fintrin-case-initcap option: Fortran Dialect Options. - * -fintrin-case-lower option: Fortran Dialect Options. - * -fintrin-case-upper option: Fortran Dialect Options. - * -fmatch-case-any option: Fortran Dialect Options. - * -fmatch-case-initcap option: Fortran Dialect Options. - * -fmatch-case-lower option: Fortran Dialect Options. - * -fmatch-case-upper option: Fortran Dialect Options. - * -fmil-intrinsics-delete option: Fortran Dialect Options. - * -fmil-intrinsics-disable option: Fortran Dialect Options. - * -fmil-intrinsics-enable option: Fortran Dialect Options. - * -fmil-intrinsics-hide option: Fortran Dialect Options. - * -fno-argument-noalias-global option <1>: Aliasing Assumed To Work. - * -fno-argument-noalias-global option: Code Gen Options. - * -fno-automatic option <1>: Overly Convenient Options. - * -fno-automatic option: Code Gen Options. - * -fno-backslash option: Fortran Dialect Options. - * -fno-common option: Code Gen Options. - * -fno-f2c option <1>: Avoid f2c Compatibility. - * -fno-f2c option: Code Gen Options. - * -fno-f77 option: Shorthand Options. - * -fno-fixed-form option: Fortran Dialect Options. - * -fno-globals option: Code Gen Options. - * -fno-ident option: Code Gen Options. - * -fno-inline option: Optimize Options. - * -fno-move-all-movables option: Optimize Options. - * -fno-reduce-all-givs option: Optimize Options. - * -fno-rerun-loop-opt option: Optimize Options. - * -fno-second-underscore: f2c Skeletons and Prototypes. - * -fno-second-underscore option <1>: Names. - * -fno-second-underscore option: Code Gen Options. - * -fno-silent option: Overall Options. - * -fno-ugly option: Shorthand Options. - * -fno-ugly-args option: Fortran Dialect Options. - * -fno-ugly-init option: Fortran Dialect Options. - * -fno-underscoring option <1>: Names. - * -fno-underscoring option: Code Gen Options. - * -fonetrip option: Fortran Dialect Options. - * -fpack-struct option: Code Gen Options. - * -fpcc-struct-return option: Code Gen Options. - * -fpedantic option: Warning Options. - * -fPIC option: News. - * -freg-struct-return option: Code Gen Options. - * -frerun-cse-after-loop option: Optimize Options. - * -fschedule-insns option: Optimize Options. - * -fschedule-insns2 option: Optimize Options. - * -fset-g77-defaults option: Overall Options. - * -fshort-double option: Code Gen Options. - * -fsource-case-lower option: Fortran Dialect Options. - * -fsource-case-preserve option: Fortran Dialect Options. - * -fsource-case-upper option: Fortran Dialect Options. - * -fstrength-reduce option: Optimize Options. - * -fsymbol-case-any option: Fortran Dialect Options. - * -fsymbol-case-initcap option: Fortran Dialect Options. - * -fsymbol-case-lower option: Fortran Dialect Options. - * -fsymbol-case-upper option: Fortran Dialect Options. - * -fsyntax-only option: Warning Options. - * -ftypeless-boz option: Fortran Dialect Options. - * -fugly option: Shorthand Options. - * -fugly-assign option: Fortran Dialect Options. - * -fugly-assumed option: Fortran Dialect Options. - * -fugly-comma option: Fortran Dialect Options. - * -fugly-complex option: Fortran Dialect Options. - * -fugly-logint option: Fortran Dialect Options. - * -funix-intrinsics-delete option: Fortran Dialect Options. - * -funix-intrinsics-disable option: Fortran Dialect Options. - * -funix-intrinsics-enable option: Fortran Dialect Options. - * -funix-intrinsics-hide option: Fortran Dialect Options. - * -funroll-all-loops option: Optimize Options. - * -funroll-loops option: Optimize Options. - * -fversion option: Overall Options. - * -fvxt option: Fortran Dialect Options. - * -fvxt-intrinsics-delete option: Fortran Dialect Options. - * -fvxt-intrinsics-disable option: Fortran Dialect Options. - * -fvxt-intrinsics-enable option: Fortran Dialect Options. - * -fvxt-intrinsics-hide option: Fortran Dialect Options. - * -fzeros option: Code Gen Options. - * -g option: Debugging Options. - * -I- option: Directory Options. - * -i8: Increasing Precision/Range. - * -Idir option: Directory Options. - * -malign-double <1>: Changes. - * -malign-double: News. - * -malign-double option <1>: Aligned Data. - * -malign-double option: Optimize Options. - * -Nl option: Compiler Limits. - * -Nx option: Compiler Limits. - * -O2: News. - * -pedantic option: Warning Options. - * -pedantic-errors option: Warning Options. - * -qrealsize=8: Increasing Precision/Range. - * -r8: Increasing Precision/Range. - * -u option: Warning Options. - * -v option: G77 and GCC. - * -W option: Warning Options. - * -w option: Warning Options. - * -Waggregate-return option: Warning Options. - * -Wall option: Warning Options. - * -Wcomment option: Warning Options. - * -Wconversion option: Warning Options. - * -Werror option: Warning Options. - * -Wformat option: Warning Options. - * -Wid-clash-LEN option: Warning Options. - * -Wimplicit option: Warning Options. - * -Wlarger-than-LEN option: Warning Options. - * -Wno-globals option: Warning Options. - * -Wparentheses option: Warning Options. - * -Wredundant-decls option: Warning Options. - * -Wshadow option: Warning Options. - * -Wsurprising option: Warning Options. - * -Wswitch option: Warning Options. - * -Wtraditional option: Warning Options. - * -Wuninitialized option: Warning Options. - * -Wunused option: Warning Options. - * -x f77-cpp-input option: LEX. - * .EQV., with integer operands: Equivalence Versus Equality. - * .F filename suffix: Overall Options. - * .f filename suffix: Overall Options. - * .FOR filename suffix: Overall Options. - * .for filename suffix: Overall Options. - * .FPP filename suffix: Overall Options. - * .fpp filename suffix: Overall Options. - * .gdbinit: Main Program Unit. - * .r filename suffix: Overall Options. - * /* <1>: Trailing Comment. - * /*: Overall Options. - * /WARNINGS=DECLARATIONS switch: Warning Options. - * 80-bit spills: Floating-point Errors. - * ; <1>: Character Set. - * ;: Statements Comments Lines. - * <: Character Set. - * <> edit descriptor: I/O. - * >: Character Set. - * ?: Character Set. - * \: Character Set. - * _: Character Set. - * Abort intrinsic: Abort Intrinsic. - * Abs intrinsic: Abs Intrinsic. - * ACCEPT statement: TYPE and ACCEPT I/O Statements. - * Access intrinsic: Access Intrinsic. - * AChar intrinsic: AChar Intrinsic. - * ACos intrinsic: ACos Intrinsic. - * ACosD intrinsic: ACosD Intrinsic. - * adding options: Adding Options. - * adjustable arrays: Adjustable Arrays. - * AdjustL intrinsic: AdjustL Intrinsic. - * AdjustR intrinsic: AdjustR Intrinsic. - * AImag intrinsic <1>: AImag Intrinsic. - * AImag intrinsic: REAL() and AIMAG() of Complex. - * AIMax0 intrinsic: AIMax0 Intrinsic. - * AIMin0 intrinsic: AIMin0 Intrinsic. - * AInt intrinsic: AInt Intrinsic. - * AJMax0 intrinsic: AJMax0 Intrinsic. - * AJMin0 intrinsic: AJMin0 Intrinsic. - * Alarm intrinsic: Alarm Intrinsic. - * aliasing <1>: Known Bugs. - * aliasing: Aliasing Assumed To Work. - * aligned data: Aligned Data. - * aligned stack: Aligned Data. - * alignment <1>: Aligned Data. - * alignment <2>: Changes. - * alignment: News. - * alignment testing: Aligned Data. - * All intrinsic: All Intrinsic. - * all warnings: Warning Options. - * Allocated intrinsic: Allocated Intrinsic. - * ALog intrinsic: ALog Intrinsic. - * ALog10 intrinsic: ALog10 Intrinsic. - * Alpha, support: Known Bugs. - * alternate entry points: Alternate Entry Points. - * alternate returns: Alternate Returns. - * ALWAYS_FLUSH: Output Assumed To Flush. - * AMax0 intrinsic: AMax0 Intrinsic. - * AMax1 intrinsic: AMax1 Intrinsic. - * AMin0 intrinsic: AMin0 Intrinsic. - * AMin1 intrinsic: AMin1 Intrinsic. - * AMod intrinsic: AMod Intrinsic. - * ampersand: Character Set. - * ampersand continuation line: Ampersands. - * And intrinsic <1>: Bit Operations on Floating-point Data. - * And intrinsic: And Intrinsic. - * ANInt intrinsic: ANInt Intrinsic. - * ANS carriage control: OPEN CLOSE and INQUIRE Keywords. - * ANSI FORTRAN 77 standard: Language. - * ANSI FORTRAN 77 support: Standard Support. - * anti-aliasing: Aliasing Assumed To Work. - * Any intrinsic: Any Intrinsic. - * arguments, null: Ugly Null Arguments. - * arguments, omitting: Ugly Null Arguments. - * arguments, unused <1>: Unused Arguments. - * arguments, unused: Warning Options. - * array bounds checking: Code Gen Options. - * array bounds, adjustable: Array Bounds Expressions. - * array elements, in adjustable array bounds: Array Bounds Expressions. - * array ordering: Arrays. - * array performance: Code Gen Options. - * array size: Array Size. - * arrays: Arrays. - * arrays, adjustable: Adjustable Arrays. - * arrays, assumed-size: Ugly Assumed-Size Arrays. - * arrays, automatic <1>: Large Automatic Arrays. - * arrays, automatic <2>: Stack Overflow. - * arrays, automatic <3>: Overly Convenient Options. - * arrays, automatic: Adjustable Arrays. - * arrays, dimensioning <1>: Adjustable Arrays. - * arrays, dimensioning: Array Size. - * arrays, flattening: Code Gen Options. - * as command: What is GNU Fortran?. - * ASin intrinsic: ASin Intrinsic. - * ASinD intrinsic: ASinD Intrinsic. - * assembler: What is GNU Fortran?. - * assembly code: What is GNU Fortran?. - * assembly code, invalid: Bug Criteria. - * ASSIGN statement <1>: Assigned Statement Labels. - * ASSIGN statement: Ugly Assigned Labels. - * assigned labels: Ugly Assigned Labels. - * assigned statement labels: Assigned Statement Labels. - * Associated intrinsic: Associated Intrinsic. - * association, storage: Aliasing Assumed To Work. - * assumed-size arrays: Ugly Assumed-Size Arrays. - * asterisk: LEX. - * ATan intrinsic: ATan Intrinsic. - * ATan2 intrinsic: ATan2 Intrinsic. - * ATan2D intrinsic: ATan2D Intrinsic. - * ATanD intrinsic: ATanD Intrinsic. - * automatic arrays <1>: Large Automatic Arrays. - * automatic arrays <2>: Stack Overflow. - * automatic arrays <3>: Overly Convenient Options. - * automatic arrays: Adjustable Arrays. - * AUTOMATIC statement: AUTOMATIC Statement. - * automatic variables: AUTOMATIC Statement. - * back end, gcc <1>: Philosophy of Code Generation. - * back end, gcc: What is GNU Fortran?. - * backslash <1>: Backslash in Constants. - * backslash <2>: Character Set. - * backslash: Fortran Dialect Options. - * backtrace for bug reports: Bug Reporting. - * badu77 intrinsics: Fortran Dialect Options. - * badu77 intrinsics group: Intrinsic Groups. - * basic concepts: What is GNU Fortran?. - * Bear-poking: Philosophy of Code Generation. - * beginners: Getting Started. - * BesJ0 intrinsic: BesJ0 Intrinsic. - * BesJ1 intrinsic: BesJ1 Intrinsic. - * BesJN intrinsic: BesJN Intrinsic. - * BesY0 intrinsic: BesY0 Intrinsic. - * BesY1 intrinsic: BesY1 Intrinsic. - * BesYN intrinsic: BesYN Intrinsic. - * binary data: Portable Unformatted Files. - * Bit_Size intrinsic: Bit_Size Intrinsic. - * BITest intrinsic: BITest Intrinsic. - * BJTest intrinsic: BJTest Intrinsic. - * blank <1>: Lines. - * blank: Character Set. - * block data: Multiple Definitions of External Names. - * block data and libraries: Block Data and Libraries. - * BLOCK DATA statement <1>: Multiple Definitions of External Names. - * BLOCK DATA statement: Block Data and Libraries. - * bounds checking: Code Gen Options. - * BTest intrinsic: BTest Intrinsic. - * bug criteria: Bug Criteria. - * bug report mailing lists: Bug Lists. - * bugs: Bugs. - * bugs, finding: What is GNU Fortran?. - * bugs, known: Trouble. - * bus error <1>: Strange Behavior at Run Time. - * bus error: NeXTStep Problems. - * but-bugs: But-bugs. - * byte ordering: Portable Unformatted Files. - * C library: Strange Behavior at Run Time. - * C preprocessor: Overall Options. - * C routines calling Fortran: Debugging and Interfacing. - * C++: C++ Considerations. - * C++, linking with: Interoperating with C and C++. - * C, linking with: Interoperating with C and C++. - * CAbs intrinsic: CAbs Intrinsic. - * calling C routines: Debugging and Interfacing. - * card image: Fortran Dialect Options. - * carriage control: OPEN CLOSE and INQUIRE Keywords. - * carriage returns: Carriage Returns. - * case sensitivity: Case Sensitivity. - * cc1 program: What is GNU Fortran?. - * cc1plus program: What is GNU Fortran?. - * CCos intrinsic: CCos Intrinsic. - * CDAbs intrinsic: CDAbs Intrinsic. - * CDCos intrinsic: CDCos Intrinsic. - * CDExp intrinsic: CDExp Intrinsic. - * CDLog intrinsic: CDLog Intrinsic. - * CDSin intrinsic: CDSin Intrinsic. - * CDSqRt intrinsic: CDSqRt Intrinsic. - * Ceiling intrinsic: Ceiling Intrinsic. - * CExp intrinsic: CExp Intrinsic. - * cfortran.h: C Interfacing Tools. - * changes, user-visible: Changes. - * Char intrinsic: Char Intrinsic. - * character assignments: Fortran 90 Features. - * character constants <1>: Character and Hollerith Constants. - * character constants <2>: Ugly Conversion of Initializers. - * character constants <3>: Double Quote Meaning. - * character constants: Fortran Dialect Options. - * character set: Fortran Dialect Options. - * CHARACTER*(*): Arbitrary Concatenation. - * CHARACTER, null: Character Type. - * character-variable length: Character-variable Length. - * characters: Character Set. - * characters, comma: Ugly Null Arguments. - * characters, comment <1>: LEX. - * characters, comment <2>: Exclamation Point. - * characters, comment <3>: Trailing Comment. - * characters, comment: Statements Comments Lines. - * characters, continuation <1>: LEX. - * characters, continuation <2>: Exclamation Point. - * characters, continuation: Statements Comments Lines. - * ChDir intrinsic <1>: ChDir Intrinsic (function). - * ChDir intrinsic: ChDir Intrinsic (subroutine). - * checking subscripts: Code Gen Options. - * checking substrings: Code Gen Options. - * checks, of internal consistency: Overall Options. - * ChMod intrinsic <1>: ChMod Intrinsic (function). - * ChMod intrinsic: ChMod Intrinsic (subroutine). - * CLog intrinsic: CLog Intrinsic. - * close angle: Character Set. - * close bracket: Character Set. - * CLOSE statement: OPEN CLOSE and INQUIRE Keywords. - * Cmplx intrinsic <1>: Cmplx Intrinsic. - * Cmplx intrinsic: CMPLX() of DOUBLE PRECISION. - * code generation, conventions: Code Gen Options. - * code generation, improving: Better Optimization. - * code generator <1>: Philosophy of Code Generation. - * code generator: What is GNU Fortran?. - * code, assembly: What is GNU Fortran?. - * code, displaying main source: Known Bugs. - * code, in-line: What is GNU Fortran?. - * code, legacy: Collected Fortran Wisdom. - * code, machine: What is GNU Fortran?. - * code, modifying: Overall Options. - * code, source <1>: Case Sensitivity. - * code, source <2>: Source Form. - * code, source <3>: Lines. - * code, source: What is GNU Fortran?. - * code, user: Cannot Link Fortran Programs. - * code, writing: Collected Fortran Wisdom. - * column-major ordering: Arrays. - * columns 73 through 80: Better Source Model. - * comma, trailing: Ugly Null Arguments. - * command options: Invoking G77. - * commands, as: What is GNU Fortran?. - * commands, g77 <1>: G77 and GCC. - * commands, g77: What is GNU Fortran?. - * commands, gcc <1>: G77 and GCC. - * commands, gcc: What is GNU Fortran?. - * commands, gdb: What is GNU Fortran?. - * commands, ld: What is GNU Fortran?. - * comment <1>: LEX. - * comment <2>: Trailing Comment. - * comment: Statements Comments Lines. - * comment character: Exclamation Point. - * comment line, debug <1>: Enabling Debug Lines. - * comment line, debug: Debug Line. - * common blocks <1>: Mangling of Names. - * common blocks <2>: Known Bugs. - * common blocks <3>: Common Blocks. - * common blocks: Debugging Options. - * common blocks, large: Large Common Blocks. - * COMMON layout: Aligned Data. - * COMMON statement <1>: Multiple Definitions of External Names. - * COMMON statement: Common Blocks. - * comparing logical expressions: Equivalence Versus Equality. - * compatibility, f2c <1>: Avoid f2c Compatibility. - * compatibility, f2c <2>: Block Data and Libraries. - * compatibility, f2c <3>: Code Gen Options. - * compatibility, f2c <4>: Shorthand Options. - * compatibility, f2c: Overall Options. - * compatibility, f77: Shorthand Options. - * compatibility, FORTRAN 66 <1>: Fortran Dialect Options. - * compatibility, FORTRAN 66: Shorthand Options. - * compatibility, FORTRAN 77: Standard Support. - * compatibility, Fortran 90: Fortran 90. - * compilation, in-line <1>: GLOBALS. - * compilation, in-line <2>: Code Gen Options. - * compilation, in-line: Optimize Options. - * compilation, pedantic: Pedantic Compilation. - * compilation, status: Overall Options. - * compiler bugs, reporting: Bug Reporting. - * compiler limits: Compiler Limits. - * compiler memory usage: Known Bugs. - * compiler speed: Known Bugs. - * compilers: What is GNU Fortran?. - * compiling programs: G77 and GCC. - * Complex intrinsic: Complex Intrinsic. - * COMPLEX intrinsics: Fortran Dialect Options. - * complex performance: Known Bugs. - * COMPLEX statement: Complex Variables. - * complex values: Ugly Complex Part Extraction. - * complex variables: Complex Variables. - * COMPLEX(KIND=1) type: Compiler Types. - * COMPLEX(KIND=2) type: Compiler Types. - * components of g77: What is GNU Fortran?. - * concatenation: Arbitrary Concatenation. - * concepts, basic: What is GNU Fortran?. - * conformance, IEEE 754 <1>: Floating-point precision. - * conformance, IEEE 754: Optimize Options. - * Conjg intrinsic: Conjg Intrinsic. - * consistency checks: Overall Options. - * constants <1>: Compiler Constants. - * constants: Constants. - * constants, character <1>: Character and Hollerith Constants. - * constants, character <2>: Ugly Conversion of Initializers. - * constants, character: Double Quote Meaning. - * constants, context-sensitive: Context-Sensitive Constants. - * constants, Hollerith <1>: Character and Hollerith Constants. - * constants, Hollerith <2>: Ugly Conversion of Initializers. - * constants, Hollerith: Ugly Implicit Argument Conversion. - * constants, integer: Known Bugs. - * constants, octal: Double Quote Meaning. - * constants, prefix-radix: Fortran Dialect Options. - * constants, types: Fortran Dialect Options. - * construct names: Construct Names. - * context-sensitive constants: Context-Sensitive Constants. - * context-sensitive intrinsics: Context-Sensitive Intrinsicness. - * continuation character <1>: LEX. - * continuation character <2>: Exclamation Point. - * continuation character: Statements Comments Lines. - * continuation line, ampersand: Ampersands. - * continuation line, number of: Continuation Line. - * contributors: Contributors. - * conversions, nonportable: Nonportable Conversions. - * core dump: Bug Criteria. - * Cos intrinsic: Cos Intrinsic. - * CosD intrinsic: CosD Intrinsic. - * CosH intrinsic: CosH Intrinsic. - * Count intrinsic: Count Intrinsic. - * cpp preprocessor: Overall Options. - * cpp program <1>: LEX. - * cpp program <2>: Bug Reporting. - * cpp program <3>: Preprocessor Options. - * cpp program <4>: Overall Options. - * cpp program: What is GNU Fortran?. - * CPU_Time intrinsic: CPU_Time Intrinsic. - * Cray pointers: POINTER Statements. - * credits: Contributors. - * CShift intrinsic: CShift Intrinsic. - * CSin intrinsic: CSin Intrinsic. - * CSqRt intrinsic: CSqRt Intrinsic. - * CTime intrinsic <1>: CTime Intrinsic (function). - * CTime intrinsic: CTime Intrinsic (subroutine). - * CYCLE statement: CYCLE and EXIT. - * DAbs intrinsic: DAbs Intrinsic. - * DACos intrinsic: DACos Intrinsic. - * DACosD intrinsic: DACosD Intrinsic. - * DASin intrinsic: DASin Intrinsic. - * DASinD intrinsic: DASinD Intrinsic. - * DATA statement <1>: Known Bugs. - * DATA statement: Code Gen Options. - * data types: Compiler Types. - * data, aligned: Aligned Data. - * data, overwritten: Strange Behavior at Run Time. - * DATan intrinsic: DATan Intrinsic. - * DATan2 intrinsic: DATan2 Intrinsic. - * DATan2D intrinsic: DATan2D Intrinsic. - * DATanD intrinsic: DATanD Intrinsic. - * Date intrinsic: Date Intrinsic. - * Date_and_Time intrinsic: Date_and_Time Intrinsic. - * date_y2kbuggy_0: Year 2000 (Y2K) Problems. - * DbesJ0 intrinsic: DbesJ0 Intrinsic. - * DbesJ1 intrinsic: DbesJ1 Intrinsic. - * DbesJN intrinsic: DbesJN Intrinsic. - * DbesY0 intrinsic: DbesY0 Intrinsic. - * DbesY1 intrinsic: DbesY1 Intrinsic. - * DbesYN intrinsic: DbesYN Intrinsic. - * Dble intrinsic: Dble Intrinsic. - * DbleQ intrinsic: DbleQ Intrinsic. - * DCmplx intrinsic: DCmplx Intrinsic. - * DConjg intrinsic: DConjg Intrinsic. - * DCos intrinsic: DCos Intrinsic. - * DCosD intrinsic: DCosD Intrinsic. - * DCosH intrinsic: DCosH Intrinsic. - * DDiM intrinsic: DDiM Intrinsic. - * debug line <1>: Enabling Debug Lines. - * debug line: Debug Line. - * debug_rtx: Bug Reporting. - * debugger <1>: Known Bugs. - * debugger: What is GNU Fortran?. - * debugging <1>: Known Bugs. - * debugging <2>: Names. - * debugging <3>: Main Program Unit. - * debugging: Debugging and Interfacing. - * debugging information options: Debugging Options. - * debugging main source code: Known Bugs. - * DECODE statement: ENCODE and DECODE. - * deleted intrinsics: Intrinsic Groups. - * DErF intrinsic: DErF Intrinsic. - * DErFC intrinsic: DErFC Intrinsic. - * DExp intrinsic: DExp Intrinsic. - * DFloat intrinsic: DFloat Intrinsic. - * DFlotI intrinsic: DFlotI Intrinsic. - * DFlotJ intrinsic: DFlotJ Intrinsic. - * diagnostics: Diagnostics. - * diagnostics, incorrect: What is GNU Fortran?. - * dialect options: Fortran Dialect Options. - * Digital Fortran features: Fortran Dialect Options. - * Digits intrinsic: Digits Intrinsic. - * DiM intrinsic: DiM Intrinsic. - * DImag intrinsic: DImag Intrinsic. - * DIMENSION statement <1>: Array Bounds Expressions. - * DIMENSION statement <2>: Adjustable Arrays. - * DIMENSION statement: Arrays. - * DIMENSION X(1): Ugly Assumed-Size Arrays. - * dimensioning arrays: Adjustable Arrays. - * DInt intrinsic: DInt Intrinsic. - * direction of language development: Direction of Language Development. - * directive, #include: Bug Reporting. - * directive, INCLUDE <1>: Bug Reporting. - * directive, INCLUDE <2>: Directory Options. - * directive, INCLUDE: Preprocessor Options. - * directory, options: Directory Options. - * directory, search paths for inclusion: Directory Options. - * disabled intrinsics: Intrinsic Groups. - * disk full: Output Assumed To Flush. - * displaying main source code: Known Bugs. - * disposition of files: OPEN CLOSE and INQUIRE Keywords. - * distensions: Distensions. - * DLog intrinsic: DLog Intrinsic. - * DLog10 intrinsic: DLog10 Intrinsic. - * DMax1 intrinsic: DMax1 Intrinsic. - * DMin1 intrinsic: DMin1 Intrinsic. - * DMod intrinsic: DMod Intrinsic. - * DNInt intrinsic: DNInt Intrinsic. - * DNRM2: News. - * DO: DO WHILE. - * DO loops, one-trip: Fortran Dialect Options. - * DO loops, zero-trip: Fortran Dialect Options. - * DO statement <1>: Loops. - * DO statement: Warning Options. - * DO WHILE <1>: DO WHILE. - * DO WHILE: Optimize Options. - * dollar sign <1>: Dollar Signs. - * dollar sign <2>: I/O. - * dollar sign: Fortran Dialect Options. - * Dot_Product intrinsic: Dot_Product Intrinsic. - * DOUBLE COMPLEX: DOUBLE COMPLEX. - * DOUBLE COMPLEX type: Compiler Types. - * DOUBLE PRECISION type: Compiler Types. - * double quote: Character Set. - * double quoted character constants <1>: Fortran 90 Features. - * double quoted character constants: Character Type. - * double quotes: Double Quote Meaning. - * double-precision performance <1>: Changes. - * double-precision performance: News. - * DProd intrinsic: DProd Intrinsic. - * DReal intrinsic: DReal Intrinsic. - * driver, gcc command as: What is GNU Fortran?. - * DSign intrinsic: DSign Intrinsic. - * DSin intrinsic: DSin Intrinsic. - * DSinD intrinsic: DSinD Intrinsic. - * DSinH intrinsic: DSinH Intrinsic. - * DSqRt intrinsic: DSqRt Intrinsic. - * DTan intrinsic: DTan Intrinsic. - * DTanD intrinsic: DTanD Intrinsic. - * DTanH intrinsic: DTanH Intrinsic. - * DTime intrinsic <1>: DTime Intrinsic (function). - * DTime intrinsic: DTime Intrinsic (subroutine). - * dummies, unused: Warning Options. - * edit descriptor, <>: I/O. - * edit descriptor, O: I/O. - * edit descriptor, Q: Q Edit Descriptor. - * edit descriptor, Z <1>: Fortran 90 Features. - * edit descriptor, Z: I/O. - * effecting IMPLICIT NONE: Warning Options. - * efficiency: Efficiency. - * ELF support: News. - * empty CHARACTER strings: Character Type. - * enabled intrinsics: Intrinsic Groups. - * ENCODE statement: ENCODE and DECODE. - * END DO: END DO. - * entry points: Alternate Entry Points. - * ENTRY statement: Alternate Entry Points. - * environment variables: Environment Variables. - * EOShift intrinsic: EOShift Intrinsic. - * Epsilon intrinsic: Epsilon Intrinsic. - * equivalence areas <1>: Known Bugs. - * equivalence areas <2>: Local Equivalence Areas. - * equivalence areas: Debugging Options. - * EQUIVALENCE statement: Local Equivalence Areas. - * ErF intrinsic: ErF Intrinsic. - * ErFC intrinsic: ErFC Intrinsic. - * error messages <1>: Warnings and Errors. - * error messages: Run-time Library Errors. - * error messages, incorrect: What is GNU Fortran?. - * error values: Run-time Library Errors. - * errors, linker: Large Common Blocks. - * ETime intrinsic <1>: ETime Intrinsic (function). - * ETime intrinsic: ETime Intrinsic (subroutine). - * exceptions, floating-point: Floating-point Exception Handling. - * exclamation point <1>: LEX. - * exclamation point <2>: Exclamation Point. - * exclamation point <3>: Trailing Comment. - * exclamation point <4>: Character Set. - * exclamation point: Statements Comments Lines. - * executable file: What is GNU Fortran?. - * Exit intrinsic: Exit Intrinsic. - * EXIT statement: CYCLE and EXIT. - * Exp intrinsic: Exp Intrinsic. - * Exponent intrinsic: Exponent Intrinsic. - * extended-source option: Fortran Dialect Options. - * extensions, file name: Overall Options. - * extensions, from Fortran 90: Fortran 90 Features. - * extensions, more: More Extensions. - * extensions, VXT: VXT Fortran. - * external names: Mangling of Names. - * extra warnings: Warning Options. - * f2c: Increasing Precision/Range. - * f2c compatibility <1>: Avoid f2c Compatibility. - * f2c compatibility <2>: Block Data and Libraries. - * f2c compatibility <3>: Debugging and Interfacing. - * f2c compatibility <4>: Code Gen Options. - * f2c compatibility <5>: Shorthand Options. - * f2c compatibility: Overall Options. - * f2c intrinsics: Fortran Dialect Options. - * f2c intrinsics group: Intrinsic Groups. - * f77 compatibility: Shorthand Options. - * f77 support: Backslash in Constants. - * f771, program: What is GNU Fortran?. - * f90 intrinsics group: Intrinsic Groups. - * fatal signal: Bug Criteria. - * FDate intrinsic <1>: FDate Intrinsic (function). - * FDate intrinsic: FDate Intrinsic (subroutine). - * FDL, GNU Free Documentation License: GNU Free Documentation License. - * features, language: Direction of Language Development. - * features, ugly <1>: Distensions. - * features, ugly: Shorthand Options. - * FFE <1>: Front End. - * FFE: What is GNU Fortran?. - * fflush(): Output Assumed To Flush. - * FGet intrinsic <1>: FGet Intrinsic (function). - * FGet intrinsic: FGet Intrinsic (subroutine). - * FGetC intrinsic <1>: FGetC Intrinsic (function). - * FGetC intrinsic: FGetC Intrinsic (subroutine). - * file format not recognized: What is GNU Fortran?. - * file formats: Portable Unformatted Files. - * file name extension: Overall Options. - * file name suffix: Overall Options. - * file type: Overall Options. - * file, source <1>: Source Form. - * file, source <2>: Lines. - * file, source: What is GNU Fortran?. - * files, executable: What is GNU Fortran?. - * fixed form <1>: Source Form. - * fixed form <2>: Lines. - * fixed form: Fortran Dialect Options. - * Float intrinsic: Float Intrinsic. - * FloatI intrinsic: FloatI Intrinsic. - * floating-point errors: Floating-point Errors. - * floating-point, errors: Inconsistent Calling Sequences. - * floating-point, exceptions: Floating-point Exception Handling. - * floating-point, precision <1>: Floating-point precision. - * floating-point, precision: Optimize Options. - * FloatJ intrinsic: FloatJ Intrinsic. - * Floor intrinsic: Floor Intrinsic. - * Flush intrinsic: Flush Intrinsic. - * flushing output: Output Assumed To Flush. - * FNum intrinsic: FNum Intrinsic. - * FORM='PRINT': OPEN CLOSE and INQUIRE Keywords. - * FORMAT descriptors <1>: Fortran 90 Features. - * FORMAT descriptors: I/O. - * FORMAT statement <1>: Q Edit Descriptor. - * FORMAT statement: Expressions in FORMAT Statements. - * FORTRAN 66 <1>: Fortran Dialect Options. - * FORTRAN 66: Shorthand Options. - * FORTRAN 77 compatibility: Standard Support. - * Fortran 90: Fortran 90 Features. - * Fortran 90, compatibility: Fortran 90. - * Fortran 90, features: Fortran Dialect Options. - * Fortran 90, intrinsics: Fortran Dialect Options. - * Fortran 90, support: Fortran 90 Support. - * Fortran preprocessor: Overall Options. - * forward references: GLOBALS. - * FPE handling: Floating-point Exception Handling. - * FPut intrinsic <1>: FPut Intrinsic (function). - * FPut intrinsic: FPut Intrinsic (subroutine). - * FPutC intrinsic <1>: FPutC Intrinsic (function). - * FPutC intrinsic: FPutC Intrinsic (subroutine). - * Fraction intrinsic: Fraction Intrinsic. - * free form <1>: Source Form. - * free form <2>: Lines. - * free form: Fortran Dialect Options. - * front end, g77 <1>: Front End. - * front end, g77: What is GNU Fortran?. - * FSeek intrinsic: FSeek Intrinsic. - * FSF, funding the: Funding GNU Fortran. - * FStat intrinsic <1>: FStat Intrinsic (function). - * FStat intrinsic: FStat Intrinsic (subroutine). - * FTell intrinsic <1>: FTell Intrinsic (function). - * FTell intrinsic: FTell Intrinsic (subroutine). - * function references, in adjustable array bounds: Array Bounds Expressions. - * FUNCTION statement <1>: Functions. - * FUNCTION statement: Procedures. - * functions: Functions. - * functions, mistyped: Not My Type. - * funding improvements: Funding GNU Fortran. - * funding the FSF: Funding GNU Fortran. - * g77 options, --driver <1>: Changes. - * g77 options, --driver: News. - * g77 options, -v: G77 and GCC. - * g77, command <1>: G77 and GCC. - * g77, command: What is GNU Fortran?. - * g77, components of: What is GNU Fortran?. - * g77, front end <1>: Front End. - * g77, front end: What is GNU Fortran?. - * G77_date_y2kbuggy_0: Year 2000 (Y2K) Problems. - * G77_vxtidate_y2kbuggy_0: Year 2000 (Y2K) Problems. - * GBE <1>: Philosophy of Code Generation. - * GBE: What is GNU Fortran?. - * GBEL: Philosophy of Code Generation. - * gcc, back end <1>: Philosophy of Code Generation. - * gcc, back end: What is GNU Fortran?. - * gcc, command <1>: G77 and GCC. - * gcc, command: What is GNU Fortran?. - * gcc, command as driver: What is GNU Fortran?. - * gcc, not recognizing Fortran source: What is GNU Fortran?. - * gdb, command: What is GNU Fortran?. - * gdb, support: Debugger Problems. - * generic intrinsics: Generics and Specifics. - * GError intrinsic: GError Intrinsic. - * GetArg intrinsic <1>: Main Program Unit. - * GetArg intrinsic: GetArg Intrinsic. - * GetCWD intrinsic <1>: GetCWD Intrinsic (function). - * GetCWD intrinsic: GetCWD Intrinsic (subroutine). - * GetEnv intrinsic: GetEnv Intrinsic. - * GetGId intrinsic: GetGId Intrinsic. - * GetLog intrinsic: GetLog Intrinsic. - * GetPId intrinsic: GetPId Intrinsic. - * getting started: Getting Started. - * GetUId intrinsic: GetUId Intrinsic. - * global names, warning <1>: Code Gen Options. - * global names, warning: Warning Options. - * GMTime intrinsic: GMTime Intrinsic. - * GNU Back End (GBE) <1>: Philosophy of Code Generation. - * GNU Back End (GBE): What is GNU Fortran?. - * GNU Back End Language (GBEL): Philosophy of Code Generation. - * GNU Fortran command options: Invoking G77. - * GNU Fortran Front End (FFE) <1>: Front End. - * GNU Fortran Front End (FFE): What is GNU Fortran?. - * gnu intrinsics group: Intrinsic Groups. - * GOTO statement: Assigned Statement Labels. - * groups of intrinsics: Intrinsic Groups. - * hardware errors: Signal 11 and Friends. - * hash mark: Character Set. - * HDF: Portable Unformatted Files. - * hidden intrinsics: Intrinsic Groups. - * Hollerith constants <1>: Character and Hollerith Constants. - * Hollerith constants <2>: Ugly Conversion of Initializers. - * Hollerith constants <3>: Ugly Implicit Argument Conversion. - * Hollerith constants: Fortran Dialect Options. - * horizontal tab: Tabs. - * HostNm intrinsic <1>: HostNm Intrinsic (function). - * HostNm intrinsic: HostNm Intrinsic (subroutine). - * Huge intrinsic: Huge Intrinsic. - * I/O, errors: Run-time Library Errors. - * I/O, flushing: Output Assumed To Flush. - * IAbs intrinsic: IAbs Intrinsic. - * IAChar intrinsic: IAChar Intrinsic. - * IAnd intrinsic: IAnd Intrinsic. - * IArgC intrinsic <1>: Main Program Unit. - * IArgC intrinsic: IArgC Intrinsic. - * IBClr intrinsic: IBClr Intrinsic. - * IBits intrinsic: IBits Intrinsic. - * IBSet intrinsic: IBSet Intrinsic. - * IChar intrinsic: IChar Intrinsic. - * IDate intrinsic <1>: IDate Intrinsic (VXT). - * IDate intrinsic: IDate Intrinsic (UNIX). - * IDiM intrinsic: IDiM Intrinsic. - * IDInt intrinsic: IDInt Intrinsic. - * IDNInt intrinsic: IDNInt Intrinsic. - * IEEE 754 conformance <1>: Floating-point precision. - * IEEE 754 conformance: Optimize Options. - * IEOr intrinsic: IEOr Intrinsic. - * IErrNo intrinsic: IErrNo Intrinsic. - * IFix intrinsic: IFix Intrinsic. - * IIAbs intrinsic: IIAbs Intrinsic. - * IIAnd intrinsic: IIAnd Intrinsic. - * IIBClr intrinsic: IIBClr Intrinsic. - * IIBits intrinsic: IIBits Intrinsic. - * IIBSet intrinsic: IIBSet Intrinsic. - * IIDiM intrinsic: IIDiM Intrinsic. - * IIDInt intrinsic: IIDInt Intrinsic. - * IIDNnt intrinsic: IIDNnt Intrinsic. - * IIEOr intrinsic: IIEOr Intrinsic. - * IIFix intrinsic: IIFix Intrinsic. - * IInt intrinsic: IInt Intrinsic. - * IIOr intrinsic: IIOr Intrinsic. - * IIQint intrinsic: IIQint Intrinsic. - * IIQNnt intrinsic: IIQNnt Intrinsic. - * IIShftC intrinsic: IIShftC Intrinsic. - * IISign intrinsic: IISign Intrinsic. - * illegal unit number: Large File Unit Numbers. - * Imag intrinsic: Imag Intrinsic. - * imaginary part <1>: Complex Variables. - * imaginary part: Ugly Complex Part Extraction. - * ImagPart intrinsic: ImagPart Intrinsic. - * IMax0 intrinsic: IMax0 Intrinsic. - * IMax1 intrinsic: IMax1 Intrinsic. - * IMin0 intrinsic: IMin0 Intrinsic. - * IMin1 intrinsic: IMin1 Intrinsic. - * IMod intrinsic: IMod Intrinsic. - * IMPLICIT CHARACTER*(*) statement: Limitation on Implicit Declarations. - * implicit declaration, warning: Warning Options. - * IMPLICIT NONE, similar effect: Warning Options. - * implicit typing: Not My Type. - * improvements, funding: Funding GNU Fortran. - * in-line code <1>: GLOBALS. - * in-line code <2>: Code Gen Options. - * in-line code <3>: Optimize Options. - * in-line code: What is GNU Fortran?. - * INCLUDE directive <1>: Bug Reporting. - * INCLUDE directive <2>: INCLUDE. - * INCLUDE directive <3>: Directory Options. - * INCLUDE directive: Preprocessor Options. - * included files: Bug Reporting. - * inclusion, directory search paths for: Directory Options. - * inconsistent floating-point results: Floating-point Errors. - * incorrect diagnostics: What is GNU Fortran?. - * incorrect error messages: What is GNU Fortran?. - * incorrect use of language: What is GNU Fortran?. - * increasing maximum unit number: Large File Unit Numbers. - * increasing precision: Increasing Precision/Range. - * increasing range: Increasing Precision/Range. - * Index intrinsic: Index Intrinsic. - * indexed (iterative) DO: Optimize Options. - * infinite spaces printed: Strange Behavior at Run Time. - * INInt intrinsic: INInt Intrinsic. - * initialization, bug: Known Bugs. - * initialization, of local variables: Code Gen Options. - * initialization, run-time: Startup Code. - * initialization, statement placement: Initializing Before Specifying. - * INot intrinsic: INot Intrinsic. - * INQUIRE statement: OPEN CLOSE and INQUIRE Keywords. - * installation trouble: Trouble. - * installing, GNU Fortran: Installation. - * Int intrinsic: Int Intrinsic. - * Int2 intrinsic: Int2 Intrinsic. - * Int8 intrinsic: Int8 Intrinsic. - * integer constants: Known Bugs. - * INTEGER(KIND=1) type: Compiler Types. - * INTEGER(KIND=2) type: Compiler Types. - * INTEGER(KIND=3) type: Compiler Types. - * INTEGER(KIND=6) type: Compiler Types. - * INTEGER*2 support: Popular Non-standard Types. - * INTEGER*8 support: Full Support for Compiler Types. - * Intel x86: News. - * interfacing: Debugging and Interfacing. - * internal consistency checks: Overall Options. - * intrinsics, Abort: Abort Intrinsic. - * intrinsics, Abs: Abs Intrinsic. - * intrinsics, Access: Access Intrinsic. - * intrinsics, AChar: AChar Intrinsic. - * intrinsics, ACos: ACos Intrinsic. - * intrinsics, ACosD: ACosD Intrinsic. - * intrinsics, AdjustL: AdjustL Intrinsic. - * intrinsics, AdjustR: AdjustR Intrinsic. - * intrinsics, AImag <1>: AImag Intrinsic. - * intrinsics, AImag: REAL() and AIMAG() of Complex. - * intrinsics, AIMax0: AIMax0 Intrinsic. - * intrinsics, AIMin0: AIMin0 Intrinsic. - * intrinsics, AInt: AInt Intrinsic. - * intrinsics, AJMax0: AJMax0 Intrinsic. - * intrinsics, AJMin0: AJMin0 Intrinsic. - * intrinsics, Alarm: Alarm Intrinsic. - * intrinsics, All: All Intrinsic. - * intrinsics, Allocated: Allocated Intrinsic. - * intrinsics, ALog: ALog Intrinsic. - * intrinsics, ALog10: ALog10 Intrinsic. - * intrinsics, AMax0: AMax0 Intrinsic. - * intrinsics, AMax1: AMax1 Intrinsic. - * intrinsics, AMin0: AMin0 Intrinsic. - * intrinsics, AMin1: AMin1 Intrinsic. - * intrinsics, AMod: AMod Intrinsic. - * intrinsics, And <1>: Bit Operations on Floating-point Data. - * intrinsics, And: And Intrinsic. - * intrinsics, ANInt: ANInt Intrinsic. - * intrinsics, Any: Any Intrinsic. - * intrinsics, ASin: ASin Intrinsic. - * intrinsics, ASinD: ASinD Intrinsic. - * intrinsics, Associated: Associated Intrinsic. - * intrinsics, ATan: ATan Intrinsic. - * intrinsics, ATan2: ATan2 Intrinsic. - * intrinsics, ATan2D: ATan2D Intrinsic. - * intrinsics, ATanD: ATanD Intrinsic. - * intrinsics, badu77: Fortran Dialect Options. - * intrinsics, BesJ0: BesJ0 Intrinsic. - * intrinsics, BesJ1: BesJ1 Intrinsic. - * intrinsics, BesJN: BesJN Intrinsic. - * intrinsics, BesY0: BesY0 Intrinsic. - * intrinsics, BesY1: BesY1 Intrinsic. - * intrinsics, BesYN: BesYN Intrinsic. - * intrinsics, Bit_Size: Bit_Size Intrinsic. - * intrinsics, BITest: BITest Intrinsic. - * intrinsics, BJTest: BJTest Intrinsic. - * intrinsics, BTest: BTest Intrinsic. - * intrinsics, CAbs: CAbs Intrinsic. - * intrinsics, CCos: CCos Intrinsic. - * intrinsics, CDAbs: CDAbs Intrinsic. - * intrinsics, CDCos: CDCos Intrinsic. - * intrinsics, CDExp: CDExp Intrinsic. - * intrinsics, CDLog: CDLog Intrinsic. - * intrinsics, CDSin: CDSin Intrinsic. - * intrinsics, CDSqRt: CDSqRt Intrinsic. - * intrinsics, Ceiling: Ceiling Intrinsic. - * intrinsics, CExp: CExp Intrinsic. - * intrinsics, Char: Char Intrinsic. - * intrinsics, ChDir <1>: ChDir Intrinsic (function). - * intrinsics, ChDir: ChDir Intrinsic (subroutine). - * intrinsics, ChMod <1>: ChMod Intrinsic (function). - * intrinsics, ChMod: ChMod Intrinsic (subroutine). - * intrinsics, CLog: CLog Intrinsic. - * intrinsics, Cmplx <1>: Cmplx Intrinsic. - * intrinsics, Cmplx: CMPLX() of DOUBLE PRECISION. - * intrinsics, Complex: Complex Intrinsic. - * intrinsics, COMPLEX: Fortran Dialect Options. - * intrinsics, Conjg: Conjg Intrinsic. - * intrinsics, context-sensitive: Context-Sensitive Intrinsicness. - * intrinsics, Cos: Cos Intrinsic. - * intrinsics, CosD: CosD Intrinsic. - * intrinsics, CosH: CosH Intrinsic. - * intrinsics, Count: Count Intrinsic. - * intrinsics, CPU_Time: CPU_Time Intrinsic. - * intrinsics, CShift: CShift Intrinsic. - * intrinsics, CSin: CSin Intrinsic. - * intrinsics, CSqRt: CSqRt Intrinsic. - * intrinsics, CTime <1>: CTime Intrinsic (function). - * intrinsics, CTime: CTime Intrinsic (subroutine). - * intrinsics, DAbs: DAbs Intrinsic. - * intrinsics, DACos: DACos Intrinsic. - * intrinsics, DACosD: DACosD Intrinsic. - * intrinsics, DASin: DASin Intrinsic. - * intrinsics, DASinD: DASinD Intrinsic. - * intrinsics, DATan: DATan Intrinsic. - * intrinsics, DATan2: DATan2 Intrinsic. - * intrinsics, DATan2D: DATan2D Intrinsic. - * intrinsics, DATanD: DATanD Intrinsic. - * intrinsics, Date: Date Intrinsic. - * intrinsics, Date_and_Time: Date_and_Time Intrinsic. - * intrinsics, DbesJ0: DbesJ0 Intrinsic. - * intrinsics, DbesJ1: DbesJ1 Intrinsic. - * intrinsics, DbesJN: DbesJN Intrinsic. - * intrinsics, DbesY0: DbesY0 Intrinsic. - * intrinsics, DbesY1: DbesY1 Intrinsic. - * intrinsics, DbesYN: DbesYN Intrinsic. - * intrinsics, Dble: Dble Intrinsic. - * intrinsics, DbleQ: DbleQ Intrinsic. - * intrinsics, DCmplx: DCmplx Intrinsic. - * intrinsics, DConjg: DConjg Intrinsic. - * intrinsics, DCos: DCos Intrinsic. - * intrinsics, DCosD: DCosD Intrinsic. - * intrinsics, DCosH: DCosH Intrinsic. - * intrinsics, DDiM: DDiM Intrinsic. - * intrinsics, deleted: Intrinsic Groups. - * intrinsics, DErF: DErF Intrinsic. - * intrinsics, DErFC: DErFC Intrinsic. - * intrinsics, DExp: DExp Intrinsic. - * intrinsics, DFloat: DFloat Intrinsic. - * intrinsics, DFlotI: DFlotI Intrinsic. - * intrinsics, DFlotJ: DFlotJ Intrinsic. - * intrinsics, Digits: Digits Intrinsic. - * intrinsics, DiM: DiM Intrinsic. - * intrinsics, DImag: DImag Intrinsic. - * intrinsics, DInt: DInt Intrinsic. - * intrinsics, disabled: Intrinsic Groups. - * intrinsics, DLog: DLog Intrinsic. - * intrinsics, DLog10: DLog10 Intrinsic. - * intrinsics, DMax1: DMax1 Intrinsic. - * intrinsics, DMin1: DMin1 Intrinsic. - * intrinsics, DMod: DMod Intrinsic. - * intrinsics, DNInt: DNInt Intrinsic. - * intrinsics, Dot_Product: Dot_Product Intrinsic. - * intrinsics, DProd: DProd Intrinsic. - * intrinsics, DReal: DReal Intrinsic. - * intrinsics, DSign: DSign Intrinsic. - * intrinsics, DSin: DSin Intrinsic. - * intrinsics, DSinD: DSinD Intrinsic. - * intrinsics, DSinH: DSinH Intrinsic. - * intrinsics, DSqRt: DSqRt Intrinsic. - * intrinsics, DTan: DTan Intrinsic. - * intrinsics, DTanD: DTanD Intrinsic. - * intrinsics, DTanH: DTanH Intrinsic. - * intrinsics, DTime <1>: DTime Intrinsic (function). - * intrinsics, DTime: DTime Intrinsic (subroutine). - * intrinsics, enabled: Intrinsic Groups. - * intrinsics, EOShift: EOShift Intrinsic. - * intrinsics, Epsilon: Epsilon Intrinsic. - * intrinsics, ErF: ErF Intrinsic. - * intrinsics, ErFC: ErFC Intrinsic. - * intrinsics, ETime <1>: ETime Intrinsic (function). - * intrinsics, ETime: ETime Intrinsic (subroutine). - * intrinsics, Exit: Exit Intrinsic. - * intrinsics, Exp: Exp Intrinsic. - * intrinsics, Exponent: Exponent Intrinsic. - * intrinsics, f2c: Fortran Dialect Options. - * intrinsics, FDate <1>: FDate Intrinsic (function). - * intrinsics, FDate: FDate Intrinsic (subroutine). - * intrinsics, FGet <1>: FGet Intrinsic (function). - * intrinsics, FGet: FGet Intrinsic (subroutine). - * intrinsics, FGetC <1>: FGetC Intrinsic (function). - * intrinsics, FGetC: FGetC Intrinsic (subroutine). - * intrinsics, Float: Float Intrinsic. - * intrinsics, FloatI: FloatI Intrinsic. - * intrinsics, FloatJ: FloatJ Intrinsic. - * intrinsics, Floor: Floor Intrinsic. - * intrinsics, Flush: Flush Intrinsic. - * intrinsics, FNum: FNum Intrinsic. - * intrinsics, Fortran 90: Fortran Dialect Options. - * intrinsics, FPut <1>: FPut Intrinsic (function). - * intrinsics, FPut: FPut Intrinsic (subroutine). - * intrinsics, FPutC <1>: FPutC Intrinsic (function). - * intrinsics, FPutC: FPutC Intrinsic (subroutine). - * intrinsics, Fraction: Fraction Intrinsic. - * intrinsics, FSeek: FSeek Intrinsic. - * intrinsics, FStat <1>: FStat Intrinsic (function). - * intrinsics, FStat: FStat Intrinsic (subroutine). - * intrinsics, FTell <1>: FTell Intrinsic (function). - * intrinsics, FTell: FTell Intrinsic (subroutine). - * intrinsics, generic: Generics and Specifics. - * intrinsics, GError: GError Intrinsic. - * intrinsics, GetArg <1>: Main Program Unit. - * intrinsics, GetArg: GetArg Intrinsic. - * intrinsics, GetCWD <1>: GetCWD Intrinsic (function). - * intrinsics, GetCWD: GetCWD Intrinsic (subroutine). - * intrinsics, GetEnv: GetEnv Intrinsic. - * intrinsics, GetGId: GetGId Intrinsic. - * intrinsics, GetLog: GetLog Intrinsic. - * intrinsics, GetPId: GetPId Intrinsic. - * intrinsics, GetUId: GetUId Intrinsic. - * intrinsics, GMTime: GMTime Intrinsic. - * intrinsics, groups: Intrinsic Groups. - * intrinsics, groups of: Intrinsic Groups. - * intrinsics, hidden: Intrinsic Groups. - * intrinsics, HostNm <1>: HostNm Intrinsic (function). - * intrinsics, HostNm: HostNm Intrinsic (subroutine). - * intrinsics, Huge: Huge Intrinsic. - * intrinsics, IAbs: IAbs Intrinsic. - * intrinsics, IAChar: IAChar Intrinsic. - * intrinsics, IAnd: IAnd Intrinsic. - * intrinsics, IArgC <1>: Main Program Unit. - * intrinsics, IArgC: IArgC Intrinsic. - * intrinsics, IBClr: IBClr Intrinsic. - * intrinsics, IBits: IBits Intrinsic. - * intrinsics, IBSet: IBSet Intrinsic. - * intrinsics, IChar: IChar Intrinsic. - * intrinsics, IDate <1>: IDate Intrinsic (VXT). - * intrinsics, IDate: IDate Intrinsic (UNIX). - * intrinsics, IDiM: IDiM Intrinsic. - * intrinsics, IDInt: IDInt Intrinsic. - * intrinsics, IDNInt: IDNInt Intrinsic. - * intrinsics, IEOr: IEOr Intrinsic. - * intrinsics, IErrNo: IErrNo Intrinsic. - * intrinsics, IFix: IFix Intrinsic. - * intrinsics, IIAbs: IIAbs Intrinsic. - * intrinsics, IIAnd: IIAnd Intrinsic. - * intrinsics, IIBClr: IIBClr Intrinsic. - * intrinsics, IIBits: IIBits Intrinsic. - * intrinsics, IIBSet: IIBSet Intrinsic. - * intrinsics, IIDiM: IIDiM Intrinsic. - * intrinsics, IIDInt: IIDInt Intrinsic. - * intrinsics, IIDNnt: IIDNnt Intrinsic. - * intrinsics, IIEOr: IIEOr Intrinsic. - * intrinsics, IIFix: IIFix Intrinsic. - * intrinsics, IInt: IInt Intrinsic. - * intrinsics, IIOr: IIOr Intrinsic. - * intrinsics, IIQint: IIQint Intrinsic. - * intrinsics, IIQNnt: IIQNnt Intrinsic. - * intrinsics, IIShftC: IIShftC Intrinsic. - * intrinsics, IISign: IISign Intrinsic. - * intrinsics, Imag: Imag Intrinsic. - * intrinsics, ImagPart: ImagPart Intrinsic. - * intrinsics, IMax0: IMax0 Intrinsic. - * intrinsics, IMax1: IMax1 Intrinsic. - * intrinsics, IMin0: IMin0 Intrinsic. - * intrinsics, IMin1: IMin1 Intrinsic. - * intrinsics, IMod: IMod Intrinsic. - * intrinsics, Index: Index Intrinsic. - * intrinsics, INInt: INInt Intrinsic. - * intrinsics, INot: INot Intrinsic. - * intrinsics, Int: Int Intrinsic. - * intrinsics, Int2: Int2 Intrinsic. - * intrinsics, Int8: Int8 Intrinsic. - * intrinsics, IOr: IOr Intrinsic. - * intrinsics, IRand: IRand Intrinsic. - * intrinsics, IsaTty: IsaTty Intrinsic. - * intrinsics, IShft: IShft Intrinsic. - * intrinsics, IShftC: IShftC Intrinsic. - * intrinsics, ISign: ISign Intrinsic. - * intrinsics, ITime: ITime Intrinsic. - * intrinsics, IZExt: IZExt Intrinsic. - * intrinsics, JIAbs: JIAbs Intrinsic. - * intrinsics, JIAnd: JIAnd Intrinsic. - * intrinsics, JIBClr: JIBClr Intrinsic. - * intrinsics, JIBits: JIBits Intrinsic. - * intrinsics, JIBSet: JIBSet Intrinsic. - * intrinsics, JIDiM: JIDiM Intrinsic. - * intrinsics, JIDInt: JIDInt Intrinsic. - * intrinsics, JIDNnt: JIDNnt Intrinsic. - * intrinsics, JIEOr: JIEOr Intrinsic. - * intrinsics, JIFix: JIFix Intrinsic. - * intrinsics, JInt: JInt Intrinsic. - * intrinsics, JIOr: JIOr Intrinsic. - * intrinsics, JIQint: JIQint Intrinsic. - * intrinsics, JIQNnt: JIQNnt Intrinsic. - * intrinsics, JIShft: JIShft Intrinsic. - * intrinsics, JIShftC: JIShftC Intrinsic. - * intrinsics, JISign: JISign Intrinsic. - * intrinsics, JMax0: JMax0 Intrinsic. - * intrinsics, JMax1: JMax1 Intrinsic. - * intrinsics, JMin0: JMin0 Intrinsic. - * intrinsics, JMin1: JMin1 Intrinsic. - * intrinsics, JMod: JMod Intrinsic. - * intrinsics, JNInt: JNInt Intrinsic. - * intrinsics, JNot: JNot Intrinsic. - * intrinsics, JZExt: JZExt Intrinsic. - * intrinsics, Kill <1>: Kill Intrinsic (function). - * intrinsics, Kill: Kill Intrinsic (subroutine). - * intrinsics, Kind: Kind Intrinsic. - * intrinsics, LBound: LBound Intrinsic. - * intrinsics, Len: Len Intrinsic. - * intrinsics, Len_Trim: Len_Trim Intrinsic. - * intrinsics, LGe: LGe Intrinsic. - * intrinsics, LGt: LGt Intrinsic. - * intrinsics, Link <1>: Link Intrinsic (function). - * intrinsics, Link: Link Intrinsic (subroutine). - * intrinsics, LLe: LLe Intrinsic. - * intrinsics, LLt: LLt Intrinsic. - * intrinsics, LnBlnk: LnBlnk Intrinsic. - * intrinsics, Loc: Loc Intrinsic. - * intrinsics, Log: Log Intrinsic. - * intrinsics, Log10: Log10 Intrinsic. - * intrinsics, Logical: Logical Intrinsic. - * intrinsics, Long: Long Intrinsic. - * intrinsics, LShift: LShift Intrinsic. - * intrinsics, LStat <1>: LStat Intrinsic (function). - * intrinsics, LStat: LStat Intrinsic (subroutine). - * intrinsics, LTime: LTime Intrinsic. - * intrinsics, MatMul: MatMul Intrinsic. - * intrinsics, Max: Max Intrinsic. - * intrinsics, Max0: Max0 Intrinsic. - * intrinsics, Max1: Max1 Intrinsic. - * intrinsics, MaxExponent: MaxExponent Intrinsic. - * intrinsics, MaxLoc: MaxLoc Intrinsic. - * intrinsics, MaxVal: MaxVal Intrinsic. - * intrinsics, MClock: MClock Intrinsic. - * intrinsics, MClock8: MClock8 Intrinsic. - * intrinsics, Merge: Merge Intrinsic. - * intrinsics, MIL-STD 1753: Fortran Dialect Options. - * intrinsics, Min: Min Intrinsic. - * intrinsics, Min0: Min0 Intrinsic. - * intrinsics, Min1: Min1 Intrinsic. - * intrinsics, MinExponent: MinExponent Intrinsic. - * intrinsics, MinLoc: MinLoc Intrinsic. - * intrinsics, MinVal: MinVal Intrinsic. - * intrinsics, Mod: Mod Intrinsic. - * intrinsics, Modulo: Modulo Intrinsic. - * intrinsics, MvBits: MvBits Intrinsic. - * intrinsics, Nearest: Nearest Intrinsic. - * intrinsics, NInt: NInt Intrinsic. - * intrinsics, Not: Not Intrinsic. - * intrinsics, Or <1>: Bit Operations on Floating-point Data. - * intrinsics, Or: Or Intrinsic. - * intrinsics, others: Other Intrinsics. - * intrinsics, Pack: Pack Intrinsic. - * intrinsics, PError: PError Intrinsic. - * intrinsics, Precision: Precision Intrinsic. - * intrinsics, Present: Present Intrinsic. - * intrinsics, Product: Product Intrinsic. - * intrinsics, QAbs: QAbs Intrinsic. - * intrinsics, QACos: QACos Intrinsic. - * intrinsics, QACosD: QACosD Intrinsic. - * intrinsics, QASin: QASin Intrinsic. - * intrinsics, QASinD: QASinD Intrinsic. - * intrinsics, QATan: QATan Intrinsic. - * intrinsics, QATan2: QATan2 Intrinsic. - * intrinsics, QATan2D: QATan2D Intrinsic. - * intrinsics, QATanD: QATanD Intrinsic. - * intrinsics, QCos: QCos Intrinsic. - * intrinsics, QCosD: QCosD Intrinsic. - * intrinsics, QCosH: QCosH Intrinsic. - * intrinsics, QDiM: QDiM Intrinsic. - * intrinsics, QExp: QExp Intrinsic. - * intrinsics, QExt: QExt Intrinsic. - * intrinsics, QExtD: QExtD Intrinsic. - * intrinsics, QFloat: QFloat Intrinsic. - * intrinsics, QInt: QInt Intrinsic. - * intrinsics, QLog: QLog Intrinsic. - * intrinsics, QLog10: QLog10 Intrinsic. - * intrinsics, QMax1: QMax1 Intrinsic. - * intrinsics, QMin1: QMin1 Intrinsic. - * intrinsics, QMod: QMod Intrinsic. - * intrinsics, QNInt: QNInt Intrinsic. - * intrinsics, QSin: QSin Intrinsic. - * intrinsics, QSinD: QSinD Intrinsic. - * intrinsics, QSinH: QSinH Intrinsic. - * intrinsics, QSqRt: QSqRt Intrinsic. - * intrinsics, QTan: QTan Intrinsic. - * intrinsics, QTanD: QTanD Intrinsic. - * intrinsics, QTanH: QTanH Intrinsic. - * intrinsics, Radix: Radix Intrinsic. - * intrinsics, Rand: Rand Intrinsic. - * intrinsics, Random_Number: Random_Number Intrinsic. - * intrinsics, Random_Seed: Random_Seed Intrinsic. - * intrinsics, Range: Range Intrinsic. - * intrinsics, Real <1>: Real Intrinsic. - * intrinsics, Real: REAL() and AIMAG() of Complex. - * intrinsics, RealPart: RealPart Intrinsic. - * intrinsics, Rename <1>: Rename Intrinsic (function). - * intrinsics, Rename: Rename Intrinsic (subroutine). - * intrinsics, Repeat: Repeat Intrinsic. - * intrinsics, Reshape: Reshape Intrinsic. - * intrinsics, RRSpacing: RRSpacing Intrinsic. - * intrinsics, RShift: RShift Intrinsic. - * intrinsics, Scale: Scale Intrinsic. - * intrinsics, Scan: Scan Intrinsic. - * intrinsics, Secnds: Secnds Intrinsic. - * intrinsics, Second <1>: Second Intrinsic (subroutine). - * intrinsics, Second: Second Intrinsic (function). - * intrinsics, Selected_Int_Kind: Selected_Int_Kind Intrinsic. - * intrinsics, Selected_Real_Kind: Selected_Real_Kind Intrinsic. - * intrinsics, Set_Exponent: Set_Exponent Intrinsic. - * intrinsics, Shape: Shape Intrinsic. - * intrinsics, Shift: Bit Operations on Floating-point Data. - * intrinsics, Short: Short Intrinsic. - * intrinsics, Sign: Sign Intrinsic. - * intrinsics, Signal <1>: Signal Intrinsic (function). - * intrinsics, Signal: Signal Intrinsic (subroutine). - * intrinsics, Sin: Sin Intrinsic. - * intrinsics, SinD: SinD Intrinsic. - * intrinsics, SinH: SinH Intrinsic. - * intrinsics, Sleep: Sleep Intrinsic. - * intrinsics, Sngl: Sngl Intrinsic. - * intrinsics, SnglQ: SnglQ Intrinsic. - * intrinsics, Spacing: Spacing Intrinsic. - * intrinsics, Spread: Spread Intrinsic. - * intrinsics, SqRt: SqRt Intrinsic. - * intrinsics, SRand: SRand Intrinsic. - * intrinsics, Stat <1>: Stat Intrinsic (function). - * intrinsics, Stat: Stat Intrinsic (subroutine). - * intrinsics, Sum: Sum Intrinsic. - * intrinsics, SymLnk <1>: SymLnk Intrinsic (function). - * intrinsics, SymLnk: SymLnk Intrinsic (subroutine). - * intrinsics, System <1>: System Intrinsic (function). - * intrinsics, System: System Intrinsic (subroutine). - * intrinsics, System_Clock: System_Clock Intrinsic. - * intrinsics, table of: Table of Intrinsic Functions. - * intrinsics, Tan: Tan Intrinsic. - * intrinsics, TanD: TanD Intrinsic. - * intrinsics, TanH: TanH Intrinsic. - * intrinsics, Time <1>: Time Intrinsic (VXT). - * intrinsics, Time: Time Intrinsic (UNIX). - * intrinsics, Time8: Time8 Intrinsic. - * intrinsics, Tiny: Tiny Intrinsic. - * intrinsics, Transfer: Transfer Intrinsic. - * intrinsics, Transpose: Transpose Intrinsic. - * intrinsics, Trim: Trim Intrinsic. - * intrinsics, TtyNam <1>: TtyNam Intrinsic (function). - * intrinsics, TtyNam: TtyNam Intrinsic (subroutine). - * intrinsics, UBound: UBound Intrinsic. - * intrinsics, UMask <1>: UMask Intrinsic (function). - * intrinsics, UMask: UMask Intrinsic (subroutine). - * intrinsics, UNIX: Fortran Dialect Options. - * intrinsics, Unlink <1>: Unlink Intrinsic (function). - * intrinsics, Unlink: Unlink Intrinsic (subroutine). - * intrinsics, Unpack: Unpack Intrinsic. - * intrinsics, Verify: Verify Intrinsic. - * intrinsics, VXT: Fortran Dialect Options. - * intrinsics, XOr: XOr Intrinsic. - * intrinsics, ZAbs: ZAbs Intrinsic. - * intrinsics, ZCos: ZCos Intrinsic. - * intrinsics, ZExp: ZExp Intrinsic. - * intrinsics, ZExt: ZExt Intrinsic. - * intrinsics, ZLog: ZLog Intrinsic. - * intrinsics, ZSin: ZSin Intrinsic. - * intrinsics, ZSqRt: ZSqRt Intrinsic. - * Introduction: Top. - * invalid assembly code: Bug Criteria. - * invalid input: Bug Criteria. - * IOr intrinsic: IOr Intrinsic. - * IOSTAT=: Run-time Library Errors. - * IRand intrinsic: IRand Intrinsic. - * IsaTty intrinsic: IsaTty Intrinsic. - * IShft intrinsic: IShft Intrinsic. - * IShftC intrinsic: IShftC Intrinsic. - * ISign intrinsic: ISign Intrinsic. - * iterative DO: Optimize Options. - * ITime intrinsic: ITime Intrinsic. - * ix86 floating-point: Floating-point precision. - * ix86 FPU stack: Inconsistent Calling Sequences. - * IZExt intrinsic: IZExt Intrinsic. - * JCB002 program: Generics and Specifics. - * JCB003 program: CMPAMBIG. - * JIAbs intrinsic: JIAbs Intrinsic. - * JIAnd intrinsic: JIAnd Intrinsic. - * JIBClr intrinsic: JIBClr Intrinsic. - * JIBits intrinsic: JIBits Intrinsic. - * JIBSet intrinsic: JIBSet Intrinsic. - * JIDiM intrinsic: JIDiM Intrinsic. - * JIDInt intrinsic: JIDInt Intrinsic. - * JIDNnt intrinsic: JIDNnt Intrinsic. - * JIEOr intrinsic: JIEOr Intrinsic. - * JIFix intrinsic: JIFix Intrinsic. - * JInt intrinsic: JInt Intrinsic. - * JIOr intrinsic: JIOr Intrinsic. - * JIQint intrinsic: JIQint Intrinsic. - * JIQNnt intrinsic: JIQNnt Intrinsic. - * JIShft intrinsic: JIShft Intrinsic. - * JIShftC intrinsic: JIShftC Intrinsic. - * JISign intrinsic: JISign Intrinsic. - * JMax0 intrinsic: JMax0 Intrinsic. - * JMax1 intrinsic: JMax1 Intrinsic. - * JMin0 intrinsic: JMin0 Intrinsic. - * JMin1 intrinsic: JMin1 Intrinsic. - * JMod intrinsic: JMod Intrinsic. - * JNInt intrinsic: JNInt Intrinsic. - * JNot intrinsic: JNot Intrinsic. - * JZExt intrinsic: JZExt Intrinsic. - * keywords, RECURSIVE: RECURSIVE Keyword. - * Kill intrinsic <1>: Kill Intrinsic (function). - * Kill intrinsic: Kill Intrinsic (subroutine). - * Kind intrinsic: Kind Intrinsic. - * KIND= notation: Kind Notation. - * known causes of trouble: Trouble. - * lack of recursion: RECURSIVE Keyword. - * language, dialect options: Fortran Dialect Options. - * language, features: Direction of Language Development. - * language, incorrect use of: What is GNU Fortran?. - * large aggregate areas: Known Bugs. - * large common blocks: Large Common Blocks. - * layout of COMMON blocks: Aligned Data. - * LBound intrinsic: LBound Intrinsic. - * ld command: What is GNU Fortran?. - * ld, can't find _main: Cannot Link Fortran Programs. - * ld, can't find strange names: Cannot Link Fortran Programs. - * ld, error linking user code: Cannot Link Fortran Programs. - * ld, errors: Large Common Blocks. - * left angle: Character Set. - * left bracket: Character Set. - * legacy code: Collected Fortran Wisdom. - * Len intrinsic: Len Intrinsic. - * Len_Trim intrinsic: Len_Trim Intrinsic. - * length of source lines: Fortran Dialect Options. - * letters, lowercase: Case Sensitivity. - * letters, uppercase: Case Sensitivity. - * LGe intrinsic: LGe Intrinsic. - * LGt intrinsic: LGt Intrinsic. - * libc, non-ANSI or non-default: Strange Behavior at Run Time. - * libf2c library: What is GNU Fortran?. - * libg2c library: What is GNU Fortran?. - * libraries: What is GNU Fortran?. - * libraries, containing BLOCK DATA: Block Data and Libraries. - * libraries, libf2c: What is GNU Fortran?. - * libraries, libg2c: What is GNU Fortran?. - * limits, array dimensions: Compiler Limits. - * limits, array size: Array Size. - * limits, compiler: Compiler Limits. - * limits, continuation lines <1>: Compiler Limits. - * limits, continuation lines: Continuation Line. - * limits, lengths of names <1>: Compiler Limits. - * limits, lengths of names: Syntactic Items. - * limits, lengths of source lines: Fortran Dialect Options. - * limits, multi-dimension arrays: Array Size. - * limits, on character-variable length: Character-variable Length. - * limits, rank: Compiler Limits. - * limits, run-time library: Run-time Environment Limits. - * limits, timings <1>: Secnds Intrinsic. - * limits, timings <2>: DTime Intrinsic (function). - * limits, timings <3>: Time8 Intrinsic. - * limits, timings <4>: Time Intrinsic (UNIX). - * limits, timings <5>: System_Clock Intrinsic. - * limits, timings <6>: Second Intrinsic (subroutine). - * limits, timings <7>: Second Intrinsic (function). - * limits, timings <8>: MClock8 Intrinsic. - * limits, timings <9>: MClock Intrinsic. - * limits, timings <10>: ETime Intrinsic (function). - * limits, timings <11>: ETime Intrinsic (subroutine). - * limits, timings <12>: DTime Intrinsic (subroutine). - * limits, timings: CPU_Time Intrinsic. - * limits, Y10K <1>: Time Intrinsic (VXT). - * limits, Y10K <2>: IDate Intrinsic (UNIX). - * limits, Y10K <3>: FDate Intrinsic (function). - * limits, Y10K <4>: FDate Intrinsic (subroutine). - * limits, Y10K: Date_and_Time Intrinsic. - * limits, Y2K: IDate Intrinsic (VXT). - * lines: Lines. - * lines, continuation: Continuation Line. - * lines, length: Fortran Dialect Options. - * lines, long: Long Lines. - * lines, short: Short Lines. - * Link intrinsic <1>: Link Intrinsic (function). - * Link intrinsic: Link Intrinsic (subroutine). - * linking: What is GNU Fortran?. - * linking against non-standard library: Strange Behavior at Run Time. - * linking error for user code: Cannot Link Fortran Programs. - * linking error, user code: Cannot Link Fortran Programs. - * linking with C: Interoperating with C and C++. - * linking, errors: Large Common Blocks. - * LLe intrinsic: LLe Intrinsic. - * LLt intrinsic: LLt Intrinsic. - * LnBlnk intrinsic: LnBlnk Intrinsic. - * Loc intrinsic: Loc Intrinsic. - * local equivalence areas <1>: Known Bugs. - * local equivalence areas: Local Equivalence Areas. - * Log intrinsic: Log Intrinsic. - * Log10 intrinsic: Log10 Intrinsic. - * logical expressions, comparing: Equivalence Versus Equality. - * Logical intrinsic: Logical Intrinsic. - * LOGICAL(KIND=1) type: Compiler Types. - * LOGICAL(KIND=2) type: Compiler Types. - * LOGICAL(KIND=3) type: Compiler Types. - * LOGICAL(KIND=6) type: Compiler Types. - * LOGICAL*1 support: Popular Non-standard Types. - * Long intrinsic: Long Intrinsic. - * long source lines: Long Lines. - * long time: Timer Wraparounds. - * loops, optimizing: Optimize Options. - * loops, speeding up: Optimize Options. - * loops, unrolling: Optimize Options. - * lowercase letters: Case Sensitivity. - * LShift intrinsic: LShift Intrinsic. - * LStat intrinsic <1>: LStat Intrinsic (function). - * LStat intrinsic: LStat Intrinsic (subroutine). - * LTime intrinsic: LTime Intrinsic. - * machine code: What is GNU Fortran?. - * macro options: Shorthand Options. - * main program unit, debugging: Main Program Unit. - * main(): Main Program Unit. - * MAIN__(): Main Program Unit. - * Makefile example: Bug Criteria. - * MAP statement: STRUCTURE UNION RECORD MAP. - * MatMul intrinsic: MatMul Intrinsic. - * Max intrinsic: Max Intrinsic. - * Max0 intrinsic: Max0 Intrinsic. - * Max1 intrinsic: Max1 Intrinsic. - * MaxExponent intrinsic: MaxExponent Intrinsic. - * maximum number of dimensions: Compiler Limits. - * maximum rank: Compiler Limits. - * maximum unit number: Large File Unit Numbers. - * MaxLoc intrinsic: MaxLoc Intrinsic. - * MaxVal intrinsic: MaxVal Intrinsic. - * MClock intrinsic: MClock Intrinsic. - * MClock8 intrinsic: MClock8 Intrinsic. - * memory usage, of compiler: Known Bugs. - * Merge intrinsic: Merge Intrinsic. - * messages, run-time: Run-time Library Errors. - * messages, warning: Warning Options. - * messages, warning and error: Warnings and Errors. - * mil intrinsics group: Intrinsic Groups. - * MIL-STD 1753 <1>: MIL-STD 1753. - * MIL-STD 1753 <2>: END DO. - * MIL-STD 1753 <3>: DO WHILE. - * MIL-STD 1753: Fortran Dialect Options. - * Min intrinsic: Min Intrinsic. - * Min0 intrinsic: Min0 Intrinsic. - * Min1 intrinsic: Min1 Intrinsic. - * MinExponent intrinsic: MinExponent Intrinsic. - * MinLoc intrinsic: MinLoc Intrinsic. - * MinVal intrinsic: MinVal Intrinsic. - * missing debug features: Debugging Options. - * mistakes: What is GNU Fortran?. - * mistyped functions: Not My Type. - * mistyped variables: Not My Type. - * Mod intrinsic: Mod Intrinsic. - * modifying g77: Overall Options. - * Modulo intrinsic: Modulo Intrinsic. - * multi-dimension arrays: Array Size. - * MvBits intrinsic: MvBits Intrinsic. - * MXUNIT: Large File Unit Numbers. - * name space: Mangling of Names. - * NAMELIST statement: NAMELIST. - * naming conflicts: Multiple Definitions of External Names. - * naming issues: Mangling of Names. - * naming programs: Nothing Happens. - * NaN values: Floating-point Exception Handling. - * Nearest intrinsic: Nearest Intrinsic. - * negative forms of options: Invoking G77. - * negative time: Timer Wraparounds. - * Netlib <1>: Increasing Precision/Range. - * Netlib: C Interfacing Tools. - * network file system: Output Assumed To Flush. - * new users: Getting Started. - * newbies: Getting Started. - * NeXTStep problems: NeXTStep Problems. - * NFS: Output Assumed To Flush. - * NInt intrinsic: NInt Intrinsic. - * nonportable conversions: Nonportable Conversions. - * Not intrinsic: Not Intrinsic. - * nothing happens: Nothing Happens. - * null arguments: Ugly Null Arguments. - * null byte, trailing: Character and Hollerith Constants. - * null CHARACTER strings: Character Type. - * number of continuation lines: Continuation Line. - * number of dimensions, maximum: Compiler Limits. - * number of trips: Loops. - * O edit descriptor: I/O. - * octal constants: Double Quote Meaning. - * omitting arguments: Ugly Null Arguments. - * one-trip DO loops: Fortran Dialect Options. - * open angle: Character Set. - * open bracket: Character Set. - * OPEN statement: OPEN CLOSE and INQUIRE Keywords. - * optimization, better: Better Optimization. - * optimization, for Pentium: Aligned Data. - * optimize options: Optimize Options. - * options, --driver <1>: Changes. - * options, --driver: News. - * options, -falias-check <1>: Aliasing Assumed To Work. - * options, -falias-check: Code Gen Options. - * options, -fargument-alias <1>: Aliasing Assumed To Work. - * options, -fargument-alias: Code Gen Options. - * options, -fargument-noalias <1>: Aliasing Assumed To Work. - * options, -fargument-noalias: Code Gen Options. - * options, -fbadu77-intrinsics-delete: Fortran Dialect Options. - * options, -fbadu77-intrinsics-disable: Fortran Dialect Options. - * options, -fbadu77-intrinsics-enable: Fortran Dialect Options. - * options, -fbadu77-intrinsics-hide: Fortran Dialect Options. - * options, -fcaller-saves: Optimize Options. - * options, -fcase-initcap: Fortran Dialect Options. - * options, -fcase-lower: Fortran Dialect Options. - * options, -fcase-preserve: Fortran Dialect Options. - * options, -fcase-strict-lower: Fortran Dialect Options. - * options, -fcase-strict-upper: Fortran Dialect Options. - * options, -fcase-upper: Fortran Dialect Options. - * options, -fdebug-kludge: Code Gen Options. - * options, -fdelayed-branch: Optimize Options. - * options, -fdollar-ok: Fortran Dialect Options. - * options, -femulate-complex: Code Gen Options. - * options, -fexpensive-optimizations: Optimize Options. - * options, -ff2c-intrinsics-delete: Fortran Dialect Options. - * options, -ff2c-intrinsics-disable: Fortran Dialect Options. - * options, -ff2c-intrinsics-enable: Fortran Dialect Options. - * options, -ff2c-intrinsics-hide: Fortran Dialect Options. - * options, -ff2c-library: Code Gen Options. - * options, -ff66: Shorthand Options. - * options, -ff77: Shorthand Options. - * options, -ff90: Fortran Dialect Options. - * options, -ff90-intrinsics-delete: Fortran Dialect Options. - * options, -ff90-intrinsics-disable: Fortran Dialect Options. - * options, -ff90-intrinsics-enable: Fortran Dialect Options. - * options, -ff90-intrinsics-hide: Fortran Dialect Options. - * options, -ffast-math: Optimize Options. - * options, -ffixed-line-length-N: Fortran Dialect Options. - * options, -ffloat-store: Optimize Options. - * options, -fforce-addr: Optimize Options. - * options, -fforce-mem: Optimize Options. - * options, -ffree-form: Fortran Dialect Options. - * options, -fgnu-intrinsics-delete: Fortran Dialect Options. - * options, -fgnu-intrinsics-disable: Fortran Dialect Options. - * options, -fgnu-intrinsics-enable: Fortran Dialect Options. - * options, -fgnu-intrinsics-hide: Fortran Dialect Options. - * options, -fGROUP-intrinsics-hide: Overly Convenient Options. - * options, -finit-local-zero <1>: Overly Convenient Options. - * options, -finit-local-zero: Code Gen Options. - * options, -fintrin-case-any: Fortran Dialect Options. - * options, -fintrin-case-initcap: Fortran Dialect Options. - * options, -fintrin-case-lower: Fortran Dialect Options. - * options, -fintrin-case-upper: Fortran Dialect Options. - * options, -fmatch-case-any: Fortran Dialect Options. - * options, -fmatch-case-initcap: Fortran Dialect Options. - * options, -fmatch-case-lower: Fortran Dialect Options. - * options, -fmatch-case-upper: Fortran Dialect Options. - * options, -fmil-intrinsics-delete: Fortran Dialect Options. - * options, -fmil-intrinsics-disable: Fortran Dialect Options. - * options, -fmil-intrinsics-enable: Fortran Dialect Options. - * options, -fmil-intrinsics-hide: Fortran Dialect Options. - * options, -fno-argument-noalias-global <1>: Aliasing Assumed To Work. - * options, -fno-argument-noalias-global: Code Gen Options. - * options, -fno-automatic <1>: Overly Convenient Options. - * options, -fno-automatic: Code Gen Options. - * options, -fno-backslash: Fortran Dialect Options. - * options, -fno-common: Code Gen Options. - * options, -fno-f2c <1>: Avoid f2c Compatibility. - * options, -fno-f2c: Code Gen Options. - * options, -fno-f77: Shorthand Options. - * options, -fno-fixed-form: Fortran Dialect Options. - * options, -fno-globals: Code Gen Options. - * options, -fno-ident: Code Gen Options. - * options, -fno-inline: Optimize Options. - * options, -fno-move-all-movables: Optimize Options. - * options, -fno-reduce-all-givs: Optimize Options. - * options, -fno-rerun-loop-opt: Optimize Options. - * options, -fno-second-underscore: Code Gen Options. - * options, -fno-silent: Overall Options. - * options, -fno-ugly: Shorthand Options. - * options, -fno-ugly-args: Fortran Dialect Options. - * options, -fno-ugly-init: Fortran Dialect Options. - * options, -fno-underscoring <1>: Names. - * options, -fno-underscoring: Code Gen Options. - * options, -fonetrip: Fortran Dialect Options. - * options, -fpack-struct: Code Gen Options. - * options, -fpcc-struct-return: Code Gen Options. - * options, -fpedantic: Warning Options. - * options, -fPIC: News. - * options, -freg-struct-return: Code Gen Options. - * options, -frerun-cse-after-loop: Optimize Options. - * options, -fschedule-insns: Optimize Options. - * options, -fschedule-insns2: Optimize Options. - * options, -fset-g77-defaults: Overall Options. - * options, -fshort-double: Code Gen Options. - * options, -fsource-case-lower: Fortran Dialect Options. - * options, -fsource-case-preserve: Fortran Dialect Options. - * options, -fsource-case-upper: Fortran Dialect Options. - * options, -fstrength-reduce: Optimize Options. - * options, -fsymbol-case-any: Fortran Dialect Options. - * options, -fsymbol-case-initcap: Fortran Dialect Options. - * options, -fsymbol-case-lower: Fortran Dialect Options. - * options, -fsymbol-case-upper: Fortran Dialect Options. - * options, -fsyntax-only: Warning Options. - * options, -ftypeless-boz: Fortran Dialect Options. - * options, -fugly: Shorthand Options. - * options, -fugly-assign: Fortran Dialect Options. - * options, -fugly-assumed: Fortran Dialect Options. - * options, -fugly-comma: Fortran Dialect Options. - * options, -fugly-complex: Fortran Dialect Options. - * options, -fugly-logint: Fortran Dialect Options. - * options, -funix-intrinsics-delete: Fortran Dialect Options. - * options, -funix-intrinsics-disable: Fortran Dialect Options. - * options, -funix-intrinsics-enable: Fortran Dialect Options. - * options, -funix-intrinsics-hide: Fortran Dialect Options. - * options, -funroll-all-loops: Optimize Options. - * options, -funroll-loops: Optimize Options. - * options, -fversion: Overall Options. - * options, -fvxt: Fortran Dialect Options. - * options, -fvxt-intrinsics-delete: Fortran Dialect Options. - * options, -fvxt-intrinsics-disable: Fortran Dialect Options. - * options, -fvxt-intrinsics-enable: Fortran Dialect Options. - * options, -fvxt-intrinsics-hide: Fortran Dialect Options. - * options, -fzeros: Code Gen Options. - * options, -g: Debugging Options. - * options, -I-: Directory Options. - * options, -Idir: Directory Options. - * options, -malign-double <1>: Aligned Data. - * options, -malign-double: Optimize Options. - * options, -Nl: Compiler Limits. - * options, -Nx: Compiler Limits. - * options, -pedantic: Warning Options. - * options, -pedantic-errors: Warning Options. - * options, -v: G77 and GCC. - * options, -W: Warning Options. - * options, -w: Warning Options. - * options, -Waggregate-return: Warning Options. - * options, -Wall: Warning Options. - * options, -Wcomment: Warning Options. - * options, -Wconversion: Warning Options. - * options, -Werror: Warning Options. - * options, -Wformat: Warning Options. - * options, -Wid-clash-LEN: Warning Options. - * options, -Wimplicit: Warning Options. - * options, -Wlarger-than-LEN: Warning Options. - * options, -Wno-globals: Warning Options. - * options, -Wparentheses: Warning Options. - * options, -Wredundant-decls: Warning Options. - * options, -Wshadow: Warning Options. - * options, -Wsurprising: Warning Options. - * options, -Wswitch: Warning Options. - * options, -Wtraditional: Warning Options. - * options, -Wuninitialized: Warning Options. - * options, -Wunused: Warning Options. - * options, -x f77-cpp-input: LEX. - * options, adding: Adding Options. - * options, code generation: Code Gen Options. - * options, debugging: Debugging Options. - * options, dialect: Fortran Dialect Options. - * options, directory search: Directory Options. - * options, GNU Fortran command: Invoking G77. - * options, macro: Shorthand Options. - * options, negative forms: Invoking G77. - * options, optimization: Optimize Options. - * options, overall: Overall Options. - * options, overly convenient: Overly Convenient Options. - * options, preprocessor: Preprocessor Options. - * options, shorthand: Shorthand Options. - * options, warnings: Warning Options. - * Or intrinsic <1>: Bit Operations on Floating-point Data. - * Or intrinsic: Or Intrinsic. - * order of evaluation, side effects: Order of Side Effects. - * ordering, array: Arrays. - * other intrinsics: Other Intrinsics. - * output, flushing: Output Assumed To Flush. - * overall options: Overall Options. - * overflow: Warning Options. - * overlapping arguments: Aliasing Assumed To Work. - * overlays: Aliasing Assumed To Work. - * overly convenient options: Overly Convenient Options. - * overwritten data: Strange Behavior at Run Time. - * Pack intrinsic: Pack Intrinsic. - * padding: Known Bugs. - * parallel processing: Support for Threads. - * PARAMETER statement <1>: Old-style PARAMETER Statements. - * PARAMETER statement: Intrinsics in PARAMETER Statements. - * parameters, unused: Warning Options. - * paths, search: Directory Options. - * PDB: Portable Unformatted Files. - * pedantic compilation: Pedantic Compilation. - * Pentium optimizations: Aligned Data. - * percent sign: Character Set. - * PError intrinsic: PError Intrinsic. - * placing initialization statements: Initializing Before Specifying. - * POINTER statement: POINTER Statements. - * pointers <1>: Ugly Assigned Labels. - * pointers: Kind Notation. - * Poking the bear: Philosophy of Code Generation. - * porting, simplify: Simplify Porting. - * pound sign: Character Set. - * Precision intrinsic: Precision Intrinsic. - * precision, increasing: Increasing Precision/Range. - * prefix-radix constants: Fortran Dialect Options. - * preprocessor <1>: LEX. - * preprocessor <2>: Bug Reporting. - * preprocessor <3>: Cpp-style directives. - * preprocessor <4>: Overall Options. - * preprocessor: What is GNU Fortran?. - * preprocessor options: Preprocessor Options. - * Present intrinsic: Present Intrinsic. - * printing compilation status: Overall Options. - * printing main source: Known Bugs. - * printing version information <1>: Overall Options. - * printing version information: What is GNU Fortran?. - * procedures: Procedures. - * Product intrinsic: Product Intrinsic. - * PROGRAM statement: Main Program Unit. - * programs, cc1: What is GNU Fortran?. - * programs, cc1plus: What is GNU Fortran?. - * programs, compiling: G77 and GCC. - * programs, cpp <1>: LEX. - * programs, cpp <2>: Bug Reporting. - * programs, cpp <3>: Preprocessor Options. - * programs, cpp <4>: Overall Options. - * programs, cpp: What is GNU Fortran?. - * programs, f771: What is GNU Fortran?. - * programs, ratfor: Overall Options. - * programs, speeding up: Faster Programs. - * programs, test: Nothing Happens. - * projects: Projects. - * Q edit descriptor: Q Edit Descriptor. - * QAbs intrinsic: QAbs Intrinsic. - * QACos intrinsic: QACos Intrinsic. - * QACosD intrinsic: QACosD Intrinsic. - * QASin intrinsic: QASin Intrinsic. - * QASinD intrinsic: QASinD Intrinsic. - * QATan intrinsic: QATan Intrinsic. - * QATan2 intrinsic: QATan2 Intrinsic. - * QATan2D intrinsic: QATan2D Intrinsic. - * QATanD intrinsic: QATanD Intrinsic. - * QCos intrinsic: QCos Intrinsic. - * QCosD intrinsic: QCosD Intrinsic. - * QCosH intrinsic: QCosH Intrinsic. - * QDiM intrinsic: QDiM Intrinsic. - * QExp intrinsic: QExp Intrinsic. - * QExt intrinsic: QExt Intrinsic. - * QExtD intrinsic: QExtD Intrinsic. - * QFloat intrinsic: QFloat Intrinsic. - * QInt intrinsic: QInt Intrinsic. - * QLog intrinsic: QLog Intrinsic. - * QLog10 intrinsic: QLog10 Intrinsic. - * QMax1 intrinsic: QMax1 Intrinsic. - * QMin1 intrinsic: QMin1 Intrinsic. - * QMod intrinsic: QMod Intrinsic. - * QNInt intrinsic: QNInt Intrinsic. - * QSin intrinsic: QSin Intrinsic. - * QSinD intrinsic: QSinD Intrinsic. - * QSinH intrinsic: QSinH Intrinsic. - * QSqRt intrinsic: QSqRt Intrinsic. - * QTan intrinsic: QTan Intrinsic. - * QTanD intrinsic: QTanD Intrinsic. - * QTanH intrinsic: QTanH Intrinsic. - * question mark: Character Set. - * questionable instructions: What is GNU Fortran?. - * Radix intrinsic: Radix Intrinsic. - * Rand intrinsic: Rand Intrinsic. - * Random_Number intrinsic: Random_Number Intrinsic. - * Random_Seed intrinsic: Random_Seed Intrinsic. - * range checking: Code Gen Options. - * Range intrinsic: Range Intrinsic. - * range, increasing: Increasing Precision/Range. - * rank, maximum: Compiler Limits. - * ratfor: Overall Options. - * Ratfor preprocessor: Overall Options. - * READONLY: READONLY Keyword. - * reads and writes, scheduling: Aliasing Assumed To Work. - * Real intrinsic <1>: Real Intrinsic. - * Real intrinsic: REAL() and AIMAG() of Complex. - * real part: Ugly Complex Part Extraction. - * REAL(KIND=1) type: Compiler Types. - * REAL(KIND=2) type: Compiler Types. - * REAL*16 support: Full Support for Compiler Types. - * RealPart intrinsic: RealPart Intrinsic. - * recent versions <1>: Changes. - * recent versions: News. - * RECORD statement: STRUCTURE UNION RECORD MAP. - * recursion, lack of: RECURSIVE Keyword. - * RECURSIVE keyword: RECURSIVE Keyword. - * reference works: Language. - * Rename intrinsic <1>: Rename Intrinsic (function). - * Rename intrinsic: Rename Intrinsic (subroutine). - * Repeat intrinsic: Repeat Intrinsic. - * reporting bugs: Bugs. - * reporting compilation status: Overall Options. - * Reshape intrinsic: Reshape Intrinsic. - * results, inconsistent: Floating-point Errors. - * RETURN statement <1>: Alternate Returns. - * RETURN statement: Functions. - * return type of functions: Functions. - * right angle: Character Set. - * right bracket: Character Set. - * rounding errors: Floating-point Errors. - * row-major ordering: Arrays. - * RRSpacing intrinsic: RRSpacing Intrinsic. - * RShift intrinsic: RShift Intrinsic. - * run-time, dynamic allocation: Arbitrary Concatenation. - * run-time, initialization: Startup Code. - * run-time, library: What is GNU Fortran?. - * run-time, options: Code Gen Options. - * SAVE statement: Code Gen Options. - * saved variables: Variables Assumed To Be Saved. - * Scale intrinsic: Scale Intrinsic. - * Scan intrinsic: Scan Intrinsic. - * scheduling of reads and writes: Aliasing Assumed To Work. - * scope <1>: Scope and Classes of Names. - * scope: Scope of Names and Labels. - * search path: Directory Options. - * search paths, for included files: Directory Options. - * Secnds intrinsic: Secnds Intrinsic. - * Second intrinsic <1>: Second Intrinsic (subroutine). - * Second intrinsic: Second Intrinsic (function). - * segmentation violation <1>: Strange Behavior at Run Time. - * segmentation violation <2>: Stack Overflow. - * segmentation violation: NeXTStep Problems. - * Selected_Int_Kind intrinsic: Selected_Int_Kind Intrinsic. - * Selected_Real_Kind intrinsic: Selected_Real_Kind Intrinsic. - * semicolon <1>: Character Set. - * semicolon: Statements Comments Lines. - * sequence numbers: Better Source Model. - * Set_Exponent intrinsic: Set_Exponent Intrinsic. - * Shape intrinsic: Shape Intrinsic. - * SHARED: READONLY Keyword. - * Shift intrinsic: Bit Operations on Floating-point Data. - * Short intrinsic: Short Intrinsic. - * short source lines: Short Lines. - * short time: Timer Wraparounds. - * shorthand options: Shorthand Options. - * side effects, order of evaluation: Order of Side Effects. - * Sign intrinsic: Sign Intrinsic. - * signal 11: Signal 11 and Friends. - * Signal intrinsic <1>: Signal Intrinsic (function). - * Signal intrinsic: Signal Intrinsic (subroutine). - * signature of procedures: Procedures. - * simplify porting: Simplify Porting. - * Sin intrinsic: Sin Intrinsic. - * SinD intrinsic: SinD Intrinsic. - * SinH intrinsic: SinH Intrinsic. - * Sleep intrinsic: Sleep Intrinsic. - * Sngl intrinsic: Sngl Intrinsic. - * SnglQ intrinsic: SnglQ Intrinsic. - * Solaris: Strange Behavior at Run Time. - * source code <1>: Case Sensitivity. - * source code <2>: Source Form. - * source code <3>: Lines. - * source code: What is GNU Fortran?. - * source file: What is GNU Fortran?. - * source file format <1>: Case Sensitivity. - * source file format <2>: Source Form. - * source file format <3>: Lines. - * source file format: Fortran Dialect Options. - * source format <1>: Source Form. - * source format: Lines. - * source lines, long: Long Lines. - * source lines, short: Short Lines. - * space <1>: Lines. - * space: Character Set. - * space, endless printing of: Strange Behavior at Run Time. - * space, padding with: Short Lines. - * Spacing intrinsic: Spacing Intrinsic. - * SPC <1>: Lines. - * SPC: Character Set. - * speed, of compiler: Known Bugs. - * speed, of loops: Optimize Options. - * speed, of programs: Faster Programs. - * spills of floating-point results: Floating-point Errors. - * Spread intrinsic: Spread Intrinsic. - * SqRt intrinsic: SqRt Intrinsic. - * SRand intrinsic: SRand Intrinsic. - * stack, 387 coprocessor: News. - * stack, aligned: Aligned Data. - * stack, overflow: Stack Overflow. - * standard, ANSI FORTRAN 77: Language. - * standard, support for: Standard Support. - * startup code: Startup Code. - * Stat intrinsic <1>: Stat Intrinsic (function). - * Stat intrinsic: Stat Intrinsic (subroutine). - * statement labels, assigned: Assigned Statement Labels. - * statements, ACCEPT: TYPE and ACCEPT I/O Statements. - * statements, ASSIGN <1>: Assigned Statement Labels. - * statements, ASSIGN: Ugly Assigned Labels. - * statements, AUTOMATIC: AUTOMATIC Statement. - * statements, BLOCK DATA <1>: Multiple Definitions of External Names. - * statements, BLOCK DATA: Block Data and Libraries. - * statements, CLOSE: OPEN CLOSE and INQUIRE Keywords. - * statements, COMMON <1>: Multiple Definitions of External Names. - * statements, COMMON: Common Blocks. - * statements, COMPLEX: Complex Variables. - * statements, CYCLE: CYCLE and EXIT. - * statements, DATA <1>: Known Bugs. - * statements, DATA: Code Gen Options. - * statements, DECODE: ENCODE and DECODE. - * statements, DIMENSION <1>: Array Bounds Expressions. - * statements, DIMENSION <2>: Adjustable Arrays. - * statements, DIMENSION: Arrays. - * statements, DO <1>: Loops. - * statements, DO: Warning Options. - * statements, ENCODE: ENCODE and DECODE. - * statements, ENTRY: Alternate Entry Points. - * statements, EQUIVALENCE: Local Equivalence Areas. - * statements, EXIT: CYCLE and EXIT. - * statements, FORMAT: Expressions in FORMAT Statements. - * statements, FUNCTION <1>: Functions. - * statements, FUNCTION: Procedures. - * statements, GOTO: Assigned Statement Labels. - * statements, IMPLICIT CHARACTER*(*): Limitation on Implicit Declarations. - * statements, INQUIRE: OPEN CLOSE and INQUIRE Keywords. - * statements, MAP: STRUCTURE UNION RECORD MAP. - * statements, NAMELIST: NAMELIST. - * statements, OPEN: OPEN CLOSE and INQUIRE Keywords. - * statements, PARAMETER <1>: Old-style PARAMETER Statements. - * statements, PARAMETER: Intrinsics in PARAMETER Statements. - * statements, POINTER: POINTER Statements. - * statements, PROGRAM: Main Program Unit. - * statements, RECORD: STRUCTURE UNION RECORD MAP. - * statements, RETURN <1>: Alternate Returns. - * statements, RETURN: Functions. - * statements, SAVE: Code Gen Options. - * statements, separated by semicolon: Statements Comments Lines. - * statements, STRUCTURE: STRUCTURE UNION RECORD MAP. - * statements, SUBROUTINE <1>: Alternate Returns. - * statements, SUBROUTINE: Procedures. - * statements, TYPE: TYPE and ACCEPT I/O Statements. - * statements, UNION: STRUCTURE UNION RECORD MAP. - * STATIC: AUTOMATIC Statement. - * static variables: Variables Assumed To Be Saved. - * status, compilation: Overall Options. - * storage association: Aliasing Assumed To Work. - * strings, empty: Character Type. - * STRUCTURE statement: STRUCTURE UNION RECORD MAP. - * structures: Known Bugs. - * submodels: Use Submodel Options. - * SUBROUTINE statement <1>: Alternate Returns. - * SUBROUTINE statement: Procedures. - * subroutines: Alternate Returns. - * subscript checking: Code Gen Options. - * substring checking: Code Gen Options. - * suffixes, file name: Overall Options. - * Sum intrinsic: Sum Intrinsic. - * support, Alpha: Known Bugs. - * support, ELF: News. - * support, f77: Backslash in Constants. - * support, FORTRAN 77: Standard Support. - * support, Fortran 90: Fortran 90 Support. - * support, gdb: Debugger Problems. - * suppressing warnings: Warning Options. - * symbol names <1>: Names. - * symbol names: Fortran Dialect Options. - * symbol names, scope and classes: Scope and Classes of Names. - * symbol names, transforming: Code Gen Options. - * symbol names, underscores: Code Gen Options. - * SymLnk intrinsic <1>: SymLnk Intrinsic (function). - * SymLnk intrinsic: SymLnk Intrinsic (subroutine). - * synchronous write errors: Output Assumed To Flush. - * syntax checking: Warning Options. - * System intrinsic <1>: System Intrinsic (function). - * System intrinsic: System Intrinsic (subroutine). - * System_Clock intrinsic: System_Clock Intrinsic. - * tab character: Tabs. - * table of intrinsics: Table of Intrinsic Functions. - * Tan intrinsic: Tan Intrinsic. - * TanD intrinsic: TanD Intrinsic. - * TanH intrinsic: TanH Intrinsic. - * test programs: Nothing Happens. - * testing alignment: Aligned Data. - * textbooks: Language. - * threads: Support for Threads. - * Time intrinsic <1>: Time Intrinsic (VXT). - * Time intrinsic: Time Intrinsic (UNIX). - * Time8 intrinsic: Time8 Intrinsic. - * Tiny intrinsic: Tiny Intrinsic. - * Toolpack: Increasing Precision/Range. - * trailing comma: Ugly Null Arguments. - * trailing comment <1>: LEX. - * trailing comment <2>: Trailing Comment. - * trailing comment: Statements Comments Lines. - * trailing null byte: Character and Hollerith Constants. - * Transfer intrinsic: Transfer Intrinsic. - * transforming symbol names <1>: Names. - * transforming symbol names: Code Gen Options. - * translation of user programs: What is GNU Fortran?. - * Transpose intrinsic: Transpose Intrinsic. - * Trim intrinsic: Trim Intrinsic. - * trips, number of: Loops. - * truncation, of floating-point values: Floating-point Errors. - * truncation, of long lines: Long Lines. - * TtyNam intrinsic <1>: TtyNam Intrinsic (function). - * TtyNam intrinsic: TtyNam Intrinsic (subroutine). - * TYPE statement: TYPE and ACCEPT I/O Statements. - * types, COMPLEX(KIND=1): Compiler Types. - * types, COMPLEX(KIND=2): Compiler Types. - * types, constants <1>: Compiler Constants. - * types, constants <2>: Constants. - * types, constants: Fortran Dialect Options. - * types, DOUBLE COMPLEX: Compiler Types. - * types, DOUBLE PRECISION: Compiler Types. - * types, file: Overall Options. - * types, Fortran/C: C Access to Type Information. - * types, INTEGER(KIND=1): Compiler Types. - * types, INTEGER(KIND=2): Compiler Types. - * types, INTEGER(KIND=3): Compiler Types. - * types, INTEGER(KIND=6): Compiler Types. - * types, INTEGER*2: Popular Non-standard Types. - * types, INTEGER*8: Full Support for Compiler Types. - * types, LOGICAL(KIND=1): Compiler Types. - * types, LOGICAL(KIND=2): Compiler Types. - * types, LOGICAL(KIND=3): Compiler Types. - * types, LOGICAL(KIND=6): Compiler Types. - * types, LOGICAL*1: Popular Non-standard Types. - * types, of data: Compiler Types. - * types, REAL(KIND=1): Compiler Types. - * types, REAL(KIND=2): Compiler Types. - * types, REAL*16: Full Support for Compiler Types. - * UBound intrinsic: UBound Intrinsic. - * ugly features <1>: Distensions. - * ugly features: Shorthand Options. - * UMask intrinsic <1>: UMask Intrinsic (function). - * UMask intrinsic: UMask Intrinsic (subroutine). - * undefined behavior: Bug Criteria. - * undefined function value: Bug Criteria. - * undefined reference (_main): Cannot Link Fortran Programs. - * underscore <1>: Mangling of Names. - * underscore <2>: Underscores in Symbol Names. - * underscore <3>: Character Set. - * underscore: Code Gen Options. - * unformatted files: Portable Unformatted Files. - * uninitialized variables <1>: Variables Assumed To Be Zero. - * uninitialized variables <2>: Code Gen Options. - * uninitialized variables: Warning Options. - * UNION statement: STRUCTURE UNION RECORD MAP. - * unit numbers: Large File Unit Numbers. - * UNIX f77: Shorthand Options. - * UNIX intrinsics: Fortran Dialect Options. - * Unlink intrinsic <1>: Unlink Intrinsic (function). - * Unlink intrinsic: Unlink Intrinsic (subroutine). - * Unpack intrinsic: Unpack Intrinsic. - * unrecognized file format: What is GNU Fortran?. - * unresolved reference (various): Cannot Link Fortran Programs. - * unrolling loops: Optimize Options. - * UNSAVE: AUTOMATIC Statement. - * unsupported warnings: Warning Options. - * unused arguments <1>: Unused Arguments. - * unused arguments: Warning Options. - * unused dummies: Warning Options. - * unused parameters: Warning Options. - * unused variables: Warning Options. - * uppercase letters: Case Sensitivity. - * user-visible changes: Changes. - * variables, assumed to be zero: Variables Assumed To Be Zero. - * variables, automatic: AUTOMATIC Statement. - * variables, initialization of: Code Gen Options. - * variables, mistyped: Not My Type. - * variables, retaining values across calls: Variables Assumed To Be Saved. - * variables, uninitialized <1>: Code Gen Options. - * variables, uninitialized: Warning Options. - * variables, unused: Warning Options. - * Verify intrinsic: Verify Intrinsic. - * version information, printing <1>: Overall Options. - * version information, printing: What is GNU Fortran?. - * versions, recent <1>: Changes. - * versions, recent: News. - * VXT extensions <1>: VXT Fortran. - * VXT extensions: Fortran Dialect Options. - * VXT intrinsics: Fortran Dialect Options. - * vxtidate_y2kbuggy_0: Year 2000 (Y2K) Problems. - * warnings: What is GNU Fortran?. - * warnings vs errors: Warnings and Errors. - * warnings, all: Warning Options. - * warnings, extra: Warning Options. - * warnings, global names <1>: Code Gen Options. - * warnings, global names: Warning Options. - * warnings, implicit declaration: Warning Options. - * warnings, suppressing: Warning Options. - * warnings, unsupported: Warning Options. - * wisdom: Collected Fortran Wisdom. - * wraparound: Run-time Environment Limits. - * wraparound, timings <1>: Secnds Intrinsic. - * wraparound, timings <2>: DTime Intrinsic (function). - * wraparound, timings <3>: Time8 Intrinsic. - * wraparound, timings <4>: Time Intrinsic (UNIX). - * wraparound, timings <5>: System_Clock Intrinsic. - * wraparound, timings <6>: Second Intrinsic (subroutine). - * wraparound, timings <7>: Second Intrinsic (function). - * wraparound, timings <8>: MClock8 Intrinsic. - * wraparound, timings <9>: MClock Intrinsic. - * wraparound, timings <10>: ETime Intrinsic (function). - * wraparound, timings <11>: ETime Intrinsic (subroutine). - * wraparound, timings <12>: DTime Intrinsic (subroutine). - * wraparound, timings: CPU_Time Intrinsic. - * wraparound, Y10K <1>: Time Intrinsic (VXT). - * wraparound, Y10K <2>: IDate Intrinsic (UNIX). - * wraparound, Y10K <3>: FDate Intrinsic (function). - * wraparound, Y10K <4>: FDate Intrinsic (subroutine). - * wraparound, Y10K: Date_and_Time Intrinsic. - * wraparound, Y2K: IDate Intrinsic (VXT). - * writes, flushing: Output Assumed To Flush. - * writing code: Collected Fortran Wisdom. - * x86 floating-point: Floating-point precision. - * x86 FPU stack: Inconsistent Calling Sequences. - * XOr intrinsic: XOr Intrinsic. - * Y10K compliance <1>: Time Intrinsic (VXT). - * Y10K compliance <2>: Year 10000 (Y10K) Problems. - * Y10K compliance <3>: IDate Intrinsic (UNIX). - * Y10K compliance <4>: FDate Intrinsic (function). - * Y10K compliance <5>: FDate Intrinsic (subroutine). - * Y10K compliance: Date_and_Time Intrinsic. - * Y2K compliance <1>: Y2KBAD. - * Y2K compliance <2>: IDate Intrinsic (VXT). - * Y2K compliance <3>: Date Intrinsic. - * Y2K compliance: Year 2000 (Y2K) Problems. - * y2kbuggy: Year 2000 (Y2K) Problems. - * Year 10000 compliance <1>: Time Intrinsic (VXT). - * Year 10000 compliance <2>: Year 10000 (Y10K) Problems. - * Year 10000 compliance <3>: IDate Intrinsic (UNIX). - * Year 10000 compliance <4>: FDate Intrinsic (function). - * Year 10000 compliance <5>: FDate Intrinsic (subroutine). - * Year 10000 compliance: Date_and_Time Intrinsic. - * Year 2000 compliance <1>: Y2KBAD. - * Year 2000 compliance <2>: IDate Intrinsic (VXT). - * Year 2000 compliance <3>: Date Intrinsic. - * Year 2000 compliance: Year 2000 (Y2K) Problems. - * Z edit descriptor <1>: Fortran 90 Features. - * Z edit descriptor: I/O. - * ZAbs intrinsic: ZAbs Intrinsic. - * ZCos intrinsic: ZCos Intrinsic. - * zero byte, trailing: Character and Hollerith Constants. - * zero-initialized variables: Variables Assumed To Be Zero. - * zero-length CHARACTER: Character Type. - * zero-trip DO loops: Fortran Dialect Options. - * ZExp intrinsic: ZExp Intrinsic. - * ZExt intrinsic: ZExt Intrinsic. - * ZLog intrinsic: ZLog Intrinsic. - * ZSin intrinsic: ZSin Intrinsic. - * ZSqRt intrinsic: ZSqRt Intrinsic. - - --- 0 ---- diff -Nrc3pad gcc-3.0.1/gcc/f/g77.texi gcc-3.0.2/gcc/f/g77.texi *** gcc-3.0.1/gcc/f/g77.texi Wed Jul 4 09:23:07 2001 --- gcc-3.0.2/gcc/f/g77.texi Mon Oct 22 17:23:35 2001 *************** information that makes for fixing the bu *** 12788,12794 **** * Criteria: Bug Criteria. Have you really found a bug? * Where: Bug Lists. Where to send your bug report. * Reporting: Bug Reporting. How to report a bug effectively. - * Patches: Sending Patches. How to send a patch for GNU Fortran. @end menu @xref{Trouble,,Known Causes of Trouble with GNU Fortran}, --- 12788,12793 ---- *************** And if we can't understand what bug you *** 13303,13309 **** patch should be an improvement, we won't install it. A test case will help us to understand. ! @xref{Sending Patches}, for guidelines on how to make it easy for us to understand and install your patches. @item --- 13302,13309 ---- patch should be an improvement, we won't install it. A test case will help us to understand. ! See @uref{http://gcc.gnu.org/contribute.html} ! for guidelines on how to make it easy for us to understand and install your patches. @item *************** A core dump file. *** 13318,13441 **** We have no way of examining a core dump for your type of machine unless we have an identical system---and if we do have one, we should be able to reproduce the crash ourselves. - @end itemize - - @node Sending Patches - @section Sending Patches for GNU Fortran - - If you would like to write bug fixes or improvements for the GNU Fortran - compiler, that is very helpful. - Send suggested fixes to the mailing list for patches, - @email{@value{email-patch}}. - - Please follow these guidelines so we can study your patches efficiently. - If you don't follow these guidelines, your information might still be - useful, but using it will take extra work. Maintaining GNU Fortran is a lot - of work in the best of circumstances, and we can't keep up unless you do - your best to help. - - @itemize @bullet - @item - Send an explanation with your changes of what problem they fix or what - improvement they bring about. For a bug fix, just include a copy of the - bug report, and explain why the change fixes the bug. - - (Referring to a bug report is not as good as including it, because then - we will have to look it up, and we have probably already deleted it if - we've already fixed the bug.) - - @item - Always include a proper bug report for the problem you think you have - fixed. We need to convince ourselves that the change is right before - installing it. Even if it is right, we might have trouble judging it if - we don't have a way to reproduce the problem. - - @item - Include all the comments that are appropriate to help people reading the - source in the future understand why this change was needed. - - @item - Don't mix together changes made for different reasons. - Send them @emph{individually}. - - If you make two changes for separate reasons, then we might not want to - install them both. We might want to install just one. If you send them - all jumbled together in a single set of diffs, we have to do extra work - to disentangle them---to figure out which parts of the change serve - which purpose. If we don't have time for this, we might have to ignore - your changes entirely. - - If you send each change as soon as you have written it, with its own - explanation, then the two changes never get tangled up, and we can - consider each one properly without any extra work to disentangle them. - - Ideally, each change you send should be impossible to subdivide into - parts that we might want to consider separately, because each of its - parts gets its motivation from the other parts. - - @item - Send each change as soon as that change is finished. Sometimes people - think they are helping us by accumulating many changes to send them all - together. As explained above, this is absolutely the worst thing you - could do. - - Since you should send each change separately, you might as well send it - right away. That gives us the option of installing it immediately if it - is important. - - @item - Use @samp{diff -c} to make your diffs. Diffs without context are hard - for us to install reliably. More than that, they make it hard for us to - study the diffs to decide whether we want to install them. Unidiff - format is better than contextless diffs, but not as easy to read as - @samp{-c} format. - - If you have GNU @code{diff}, use @samp{diff -cp}, which shows the name of the - function that each change occurs in. - (The maintainer of GNU Fortran currently uses @samp{diff -rcp2N}.) - - @item - Write the change log entries for your changes. We get lots of changes, - and we don't have time to do all the change log writing ourselves. - - Read the @file{ChangeLog} file to see what sorts of information to put - in, and to learn the style that we use. The purpose of the change log - is to show people where to find what was changed. So you need to be - specific about what functions you changed; in large functions, it's - often helpful to indicate where within the function the change was. - - On the other hand, once you have shown people where to find the change, - you need not explain its purpose. Thus, if you add a new function, all - you need to say about it is that it is new. If you feel that the - purpose needs explaining, it probably does---but the explanation will be - much more useful if you put it in comments in the code. - - If you would like your name to appear in the header line for who made - the change, send us the header line. - - @item - When you write the fix, keep in mind that we can't install a change that - would break other systems. - - People often suggest fixing a problem by changing machine-independent - files such as @file{toplev.c} to do something special that a particular - system needs. Sometimes it is totally obvious that such changes would - break GNU Fortran for almost all users. We can't possibly make a change like - that. At best it might tell us how to write another patch that would - solve the problem acceptably. - - Sometimes people send fixes that @emph{might} be an improvement in - general---but it is hard to be sure of this. It's hard to install - such changes because we have to study them very carefully. Of course, - a good explanation of the reasoning by which you concluded the change - was correct can help convince us. - - The safest changes are changes to the configuration files for a - particular machine. These are safe because they can't create new bugs - on other machines. - - Please help us keep up with the workload by designing the patch in a - form that is good to install. @end itemize @node Service --- 13318,13323 ---- diff -Nrc3pad gcc-3.0.1/gcc/f/version.c gcc-3.0.2/gcc/f/version.c *** gcc-3.0.1/gcc/f/version.c Sun Aug 19 13:27:47 2001 --- gcc-3.0.2/gcc/f/version.c Tue Oct 23 10:21:29 2001 *************** *** 1 **** ! const char *ffe_version_string = "0.5.26 20010819 (release)"; --- 1 ---- ! const char *ffe_version_string = "0.5.26 20011023 (release)"; diff -Nrc3pad gcc-3.0.1/gcc/fixinc/fixincl.x gcc-3.0.2/gcc/fixinc/fixincl.x *** gcc-3.0.1/gcc/fixinc/fixincl.x Thu Jul 19 21:05:11 2001 --- gcc-3.0.2/gcc/fixinc/fixincl.x Wed Sep 12 19:38:30 2001 *************** *** 5,11 **** * files which are fixed to work correctly with ANSI C and placed in a * directory that GNU C will search. * ! * This file contains 143 fixup descriptions. * * See README for more information. * --- 5,11 ---- * files which are fixed to work correctly with ANSI C and placed in a * directory that GNU C will search. * ! * This file contains 145 fixup descriptions. * * See README for more information. * *************** static const char* apzHpux11_FabsfPatch[ *** 2068,2073 **** --- 2068,2110 ---- /* * * * * * * * * * * * * * * * * * * * * * * * * * * + * Description of Hpux11_Size_T fix + */ + tSCC zHpux11_Size_TName[] = + "hpux11_size_t"; + + /* + * File name selection pattern + */ + #define zHpux11_Size_TList (char*)NULL + /* + * Machine/OS name selection pattern + */ + tSCC* apzHpux11_Size_TMachs[] = { + "*-hp-hpux*", + (const char*)NULL }; + + /* + * content selection pattern - do fix if pattern found + */ + tSCC zHpux11_Size_TSelect0[] = + "^#define __size_t size_t"; + + #define HPUX11_SIZE_T_TEST_CT 1 + static tTestDesc aHpux11_Size_TTests[] = { + { TT_EGREP, zHpux11_Size_TSelect0, (regex_t*)NULL }, }; + + /* + * Fix Command Arguments for Hpux11_Size_T + */ + static const char* apzHpux11_Size_TPatch[] = { + "format", + "_hpux_size_t", + "__size_t", + (char*)NULL }; + + /* * * * * * * * * * * * * * * * * * * * * * * * * * + * * Description of Hpux11_Uint32_C fix */ tSCC zHpux11_Uint32_CName[] = *************** static const char* apzUndefine_NullPatch *** 5107,5112 **** --- 5144,5186 ---- /* * * * * * * * * * * * * * * * * * * * * * * * * * * + * Description of Unicosmk_Restrict fix + */ + tSCC zUnicosmk_RestrictName[] = + "unicosmk_restrict"; + + /* + * File name selection pattern + */ + tSCC zUnicosmk_RestrictList[] = + "|stdio.h|stdlib.h|wchar.h|"; + /* + * Machine/OS name selection pattern + */ + tSCC* apzUnicosmk_RestrictMachs[] = { + "*-*-unicosmk*", + (const char*)NULL }; + + /* + * content selection pattern - do fix if pattern found + */ + tSCC zUnicosmk_RestrictSelect0[] = + "(\\*[ \t]*)restrict([ \t]+)"; + + #define UNICOSMK_RESTRICT_TEST_CT 1 + static tTestDesc aUnicosmk_RestrictTests[] = { + { TT_EGREP, zUnicosmk_RestrictSelect0, (regex_t*)NULL }, }; + + /* + * Fix Command Arguments for Unicosmk_Restrict + */ + static const char* apzUnicosmk_RestrictPatch[] = { + "format", + "%1__restrict__%2", + (char*)NULL }; + + /* * * * * * * * * * * * * * * * * * * * * * * * * * + * * Description of Uw7_Byteorder_Fix fix */ tSCC zUw7_Byteorder_FixName[] = *************** static const char* apzX11_SprintfPatch[] *** 5577,5585 **** * * List of all fixes */ ! #define REGEX_COUNT 150 #define MACH_LIST_SIZE_LIMIT 279 ! #define FIX_COUNT 143 /* * Enumerate the fixes --- 5651,5659 ---- * * List of all fixes */ ! #define REGEX_COUNT 152 #define MACH_LIST_SIZE_LIMIT 279 ! #define FIX_COUNT 145 /* * Enumerate the fixes *************** typedef enum { *** 5636,5641 **** --- 5710,5716 ---- HPUX10_CPP_POW_INLINE_FIXIDX, HPUX11_CPP_POW_INLINE_FIXIDX, HPUX11_FABSF_FIXIDX, + HPUX11_SIZE_T_FIXIDX, HPUX11_UINT32_C_FIXIDX, HPUX11_VSNPRINTF_FIXIDX, HPUX8_BOGUS_INLINES_FIXIDX, *************** typedef enum { *** 5717,5722 **** --- 5792,5798 ---- ULTRIX_STATIC_FIXIDX, ULTRIX_STRINGS_FIXIDX, UNDEFINE_NULL_FIXIDX, + UNICOSMK_RESTRICT_FIXIDX, UW7_BYTEORDER_FIX_FIXIDX, VA_I960_MACRO_FIXIDX, VOID_NULL_FIXIDX, *************** tFixDesc fixDescList[ FIX_COUNT ] = { *** 5986,5991 **** --- 6062,6072 ---- HPUX11_FABSF_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE, aHpux11_FabsfTests, apzHpux11_FabsfPatch, 0 }, + { zHpux11_Size_TName, zHpux11_Size_TList, + apzHpux11_Size_TMachs, + HPUX11_SIZE_T_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE, + aHpux11_Size_TTests, apzHpux11_Size_TPatch, 0 }, + { zHpux11_Uint32_CName, zHpux11_Uint32_CList, apzHpux11_Uint32_CMachs, HPUX11_UINT32_C_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE, *************** tFixDesc fixDescList[ FIX_COUNT ] = { *** 6390,6395 **** --- 6471,6481 ---- apzUndefine_NullMachs, UNDEFINE_NULL_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE, aUndefine_NullTests, apzUndefine_NullPatch, 0 }, + + { zUnicosmk_RestrictName, zUnicosmk_RestrictList, + apzUnicosmk_RestrictMachs, + UNICOSMK_RESTRICT_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE, + aUnicosmk_RestrictTests, apzUnicosmk_RestrictPatch, 0 }, { zUw7_Byteorder_FixName, zUw7_Byteorder_FixList, apzUw7_Byteorder_FixMachs, diff -Nrc3pad gcc-3.0.1/gcc/fixinc/inclhack.def gcc-3.0.2/gcc/fixinc/inclhack.def *** gcc-3.0.1/gcc/fixinc/inclhack.def Thu Jul 19 21:04:48 2001 --- gcc-3.0.2/gcc/fixinc/inclhack.def Wed Sep 12 19:38:12 2001 *************** fix = { *** 1195,1200 **** --- 1195,1201 ---- " }\n"; }; + /* * Keep HP-UX 11 from stomping on C++ math namespace * with defines for fabsf. *************** fix = { *** 1216,1221 **** --- 1217,1241 ---- /* + * Prevent HP-UX 11 from defining __size_t and preventing size_t from + * being defined by having it define _hpux_size_t instead. + */ + fix = { + hackname = hpux11_size_t; + mach = "*-hp-hpux*"; + select = "^#define __size_t size_t"; + + c_fix = format; + c_fix_arg = "_hpux_size_t"; + c_fix_arg = "__size_t"; + + test_text = + "#define __size_t size_t\n" + " extern int getpwuid_r( char *, __size_t, struct passwd **);\n"; + }; + + + /* * In inttypes.h on HPUX 11, the use of __CONCAT__ in the definition * of UINT32_C has undefined behavior according to ISO/ANSI: * the arguments to __CONCAT__ are not macro expanded before the *************** fix = { *** 3102,3107 **** --- 3122,3144 ---- test_text = "#define NULL 0UL\r\n#define NULL\t((void*)0)\n"; }; + /* + * On Cray Unicos/Mk some standard headers use the C99 keyword "restrict" + * which must be replaced by __restrict__ for GCC. + */ + fix = { + hackname = unicosmk_restrict; + files = stdio.h; + files = stdlib.h; + files = wchar.h; + mach = "*-*-unicosmk*"; + select = "(\\*[ \t]*)restrict([ \t]+)"; + + c_fix = format; + c_fix_arg = "%1__restrict__%2"; + + test_text = "void f (char * restrict x);"; + }; /* * If arpa/inet.h prototypes are incompatible with the ones we just diff -Nrc3pad gcc-3.0.1/gcc/flow.c gcc-3.0.2/gcc/flow.c *** gcc-3.0.1/gcc/flow.c Wed Jun 6 00:32:24 2001 --- gcc-3.0.2/gcc/flow.c Fri Sep 7 16:28:52 2001 *************** attempt_auto_inc (pbi, inc, insn, mem, i *** 5345,5350 **** --- 5345,5353 ---- for (temp = insn; temp != incr; temp = NEXT_INSN (temp)) if (GET_CODE (temp) == CALL_INSN) REG_N_CALLS_CROSSED (regno)++; + + /* Invalidate alias info for Q since we just changed its value. */ + clear_reg_alias_info (q); } else return; diff -Nrc3pad gcc-3.0.1/gcc/function.c gcc-3.0.2/gcc/function.c *** gcc-3.0.1/gcc/function.c Mon Aug 6 14:26:24 2001 --- gcc-3.0.2/gcc/function.c Wed Sep 12 13:55:20 2001 *************** fixup_var_refs_insns_with_hash (ht, var, *** 1680,1686 **** rtx insn = XEXP (insn_list, 0); if (INSN_P (insn)) ! fixup_var_refs_insn (insn, var, promoted_mode, unsignedp, 0); insn_list = XEXP (insn_list, 1); } --- 1680,1686 ---- rtx insn = XEXP (insn_list, 0); if (INSN_P (insn)) ! fixup_var_refs_insn (insn, var, promoted_mode, unsignedp, 1); insn_list = XEXP (insn_list, 1); } diff -Nrc3pad gcc-3.0.1/gcc/gcc.c gcc-3.0.2/gcc/gcc.c *** gcc-3.0.1/gcc/gcc.c Sun Aug 12 13:22:17 2001 --- gcc-3.0.2/gcc/gcc.c Tue Oct 2 16:12:34 2001 *************** main (argc, argv) *** 5885,5895 **** /* Ok, we found an applicable compiler. Run its spec. */ if (input_file_compiler->spec[0] == '#') ! error ("%s: %s compiler not installed on this system", ! input_filename, &input_file_compiler->spec[1]); ! value = do_spec (input_file_compiler->spec); ! if (value < 0) ! this_file_error = 1; } /* If this file's name does not contain a recognized suffix, --- 5885,5901 ---- /* Ok, we found an applicable compiler. Run its spec. */ if (input_file_compiler->spec[0] == '#') ! { ! error ("%s: %s compiler not installed on this system", ! input_filename, &input_file_compiler->spec[1]); ! this_file_error = 1; ! } ! else ! { ! value = do_spec (input_file_compiler->spec); ! if (value < 0) ! this_file_error = 1; ! } } /* If this file's name does not contain a recognized suffix, diff -Nrc3pad gcc-3.0.1/gcc/gcse.c gcc-3.0.2/gcc/gcse.c *** gcc-3.0.1/gcc/gcse.c Wed Apr 11 11:06:52 2001 --- gcc-3.0.2/gcc/gcse.c Mon Sep 17 14:29:55 2001 *************** gcse_main (f, file) *** 681,687 **** a high connectivity will take a long time and is unlikely to be particularly useful. ! In normal circumstances a cfg should have about twice has many edges as blocks. But we do not want to punish small functions which have a couple switch statements. So we require a relatively large number of basic blocks and the ratio of edges to blocks to be high. */ --- 681,687 ---- a high connectivity will take a long time and is unlikely to be particularly useful. ! In normal circumstances a cfg should have about twice as many edges as blocks. But we do not want to punish small functions which have a couple switch statements. So we require a relatively large number of basic blocks and the ratio of edges to blocks to be high. */ *************** hash_scan_set (pat, insn, set_p) *** 1931,1937 **** if (GET_CODE (dest) == REG) { int regno = REGNO (dest); ! rtx tmp; /* Only record sets of pseudo-regs in the hash table. */ if (! set_p --- 1931,1937 ---- if (GET_CODE (dest) == REG) { int regno = REGNO (dest); ! rtx tmp, note; /* Only record sets of pseudo-regs in the hash table. */ if (! set_p *************** hash_scan_set (pat, insn, set_p) *** 1939,1945 **** /* Don't GCSE something if we can't do a reg/reg copy. */ && can_copy_p [GET_MODE (dest)] /* Is SET_SRC something we want to gcse? */ ! && want_to_gcse_p (src)) { /* An expression is not anticipatable if its operands are modified before this insn. */ --- 1939,1952 ---- /* Don't GCSE something if we can't do a reg/reg copy. */ && can_copy_p [GET_MODE (dest)] /* Is SET_SRC something we want to gcse? */ ! && want_to_gcse_p (src) ! /* Don't GCSE if it has attached REG_EQUIV note. ! At this point this only function parameters should have ! REG_EQUIV notes and if the argument slot is used somewhere ! explicitely, it means address of parameter has been taken, ! so we should not extend the lifetime of the pseudo. */ ! && ((note = find_reg_note (insn, REG_EQUIV, NULL_RTX)) == 0 ! || GET_CODE (XEXP (note, 0)) != MEM)) { /* An expression is not anticipatable if its operands are modified before this insn. */ *************** delete_null_pointer_checks (f) *** 5173,5179 **** a high connectivity will take a long time and is unlikely to be particularly useful. ! In normal circumstances a cfg should have about twice has many edges as blocks. But we do not want to punish small functions which have a couple switch statements. So we require a relatively large number of basic blocks and the ratio of edges to blocks to be high. */ --- 5180,5186 ---- a high connectivity will take a long time and is unlikely to be particularly useful. ! In normal circumstances a cfg should have about twice as many edges as blocks. But we do not want to punish small functions which have a couple switch statements. So we require a relatively large number of basic blocks and the ratio of edges to blocks to be high. */ diff -Nrc3pad gcc-3.0.1/gcc/intl/ChangeLog gcc-3.0.2/gcc/intl/ChangeLog *** gcc-3.0.1/gcc/intl/ChangeLog Sun Aug 19 14:08:17 2001 --- gcc-3.0.2/gcc/intl/ChangeLog Tue Oct 23 10:19:46 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/gcc/java/ChangeLog gcc-3.0.2/gcc/java/ChangeLog *** gcc-3.0.1/gcc/java/ChangeLog Sun Aug 19 14:08:19 2001 --- gcc-3.0.2/gcc/java/ChangeLog Tue Oct 23 10:19:55 2001 *************** *** 1,3 **** --- 1,13 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + + 2001-09-21 Richard Henderson + + * class.c (get_dispatch_table): Handle function descriptors. + (build_dtable_decl): Likewise. + * expr.c (build_invokevirtual): Likewise. + 2001-08-19 Release Manager * GCC 3.0.1 Released. *************** *** 47,53 **** 20010617 Release Manager ! * GCC 3.0 Released. 2001-06-07 Theodore Papadopoulo --- 57,63 ---- 20010617 Release Manager ! * GCC 3.0 Released. 2001-06-07 Theodore Papadopoulo *************** *** 92,99 **** 2001-05-17 Per Bothner ! * jvspec.c (lang_specific_pre_link): Re-arrange the linker ! command line so the jvgenmain-generated main program comes first. 2001-05-15 Tom Tromey --- 102,109 ---- 2001-05-17 Per Bothner ! * jvspec.c (lang_specific_pre_link): Re-arrange the linker ! command line so the jvgenmain-generated main program comes first. 2001-05-15 Tom Tromey diff -Nrc3pad gcc-3.0.1/gcc/java/class.c gcc-3.0.2/gcc/java/class.c *** gcc-3.0.1/gcc/java/class.c Tue May 15 11:18:04 2001 --- gcc-3.0.2/gcc/java/class.c Fri Sep 21 18:33:25 2001 *************** get_dispatch_table (type, this_class_add *** 1190,1198 **** { int abstract_p = CLASS_ABSTRACT (TYPE_NAME (type)); tree vtable = get_dispatch_vector (type); ! int i; tree list = NULL_TREE; int nvirtuals = TREE_VEC_LENGTH (vtable); for (i = nvirtuals; --i >= 0; ) { tree method = TREE_VEC_ELT (vtable, i); --- 1190,1200 ---- { int abstract_p = CLASS_ABSTRACT (TYPE_NAME (type)); tree vtable = get_dispatch_vector (type); ! int i, j; tree list = NULL_TREE; int nvirtuals = TREE_VEC_LENGTH (vtable); + int arraysize; + for (i = nvirtuals; --i >= 0; ) { tree method = TREE_VEC_ELT (vtable, i); *************** get_dispatch_table (type, this_class_add *** 1201,1227 **** if (! abstract_p) warning_with_decl (method, "abstract method in non-abstract class"); ! method = null_pointer_node; } else { if (!DECL_RTL_SET_P (method)) make_decl_rtl (method, NULL); ! method = build1 (ADDR_EXPR, nativecode_ptr_type_node, method); } - list = tree_cons (NULL_TREE /*DECL_VINDEX (method) + 2*/, - method, list); } /* Dummy entry for compatibility with G++ -fvtable-thunks. When using the Boehm GC we sometimes stash a GC type descriptor there. We set the PURPOSE to NULL_TREE not to interfere (reset) the emitted byte count during the output to the assembly file. */ ! list = tree_cons (NULL_TREE, get_boehm_type_descriptor (type), ! list); list = tree_cons (integer_zero_node, this_class_addr, list); ! return build (CONSTRUCTOR, build_prim_array_type (nativecode_ptr_type_node, ! nvirtuals + 2), ! NULL_TREE, list); } void --- 1203,1254 ---- if (! abstract_p) warning_with_decl (method, "abstract method in non-abstract class"); ! ! if (TARGET_VTABLE_USES_DESCRIPTORS) ! for (j = 0; j < TARGET_VTABLE_USES_DESCRIPTORS; ++j) ! list = tree_cons (NULL_TREE, null_pointer_node, list); ! else ! list = tree_cons (NULL_TREE, null_pointer_node, list); } else { if (!DECL_RTL_SET_P (method)) make_decl_rtl (method, NULL); ! ! if (TARGET_VTABLE_USES_DESCRIPTORS) ! for (j = 0; j < TARGET_VTABLE_USES_DESCRIPTORS; ++j) ! { ! tree fdesc = build (FDESC_EXPR, nativecode_ptr_type_node, ! method, build_int_2 (j, 0)); ! TREE_CONSTANT (fdesc) = 1; ! list = tree_cons (NULL_TREE, fdesc, list); ! } ! else ! list = tree_cons (NULL_TREE, ! build1 (ADDR_EXPR, nativecode_ptr_type_node, ! method), ! list); } } + /* Dummy entry for compatibility with G++ -fvtable-thunks. When using the Boehm GC we sometimes stash a GC type descriptor there. We set the PURPOSE to NULL_TREE not to interfere (reset) the emitted byte count during the output to the assembly file. */ ! for (j = 1; j < TARGET_VTABLE_USES_DESCRIPTORS; ++j) ! list = tree_cons (NULL_TREE, null_pointer_node, list); ! list = tree_cons (NULL_TREE, get_boehm_type_descriptor (type), list); ! ! for (j = 1; j < TARGET_VTABLE_USES_DESCRIPTORS; ++j) ! list = tree_cons (NULL_TREE, null_pointer_node, list); list = tree_cons (integer_zero_node, this_class_addr, list); ! ! arraysize = nvirtuals + 2; ! if (TARGET_VTABLE_USES_DESCRIPTORS) ! arraysize *= TARGET_VTABLE_USES_DESCRIPTORS; ! return build (CONSTRUCTOR, ! build_prim_array_type (nativecode_ptr_type_node, arraysize), ! NULL_TREE, list); } void *************** build_dtable_decl (type) *** 1557,1569 **** TYPE. */ if (current_class == type) { ! tree dummy = NULL_TREE, aomt, n; dtype = make_node (RECORD_TYPE); PUSH_FIELD (dtype, dummy, "class", class_ptr_type); ! n = build_int_2 (TREE_VEC_LENGTH (get_dispatch_vector (type)), 0); ! aomt = build_array_type (ptr_type_node, build_index_type (n)); ! PUSH_FIELD (dtype, dummy, "methods", aomt); layout_type (dtype); } else --- 1584,1620 ---- TYPE. */ if (current_class == type) { ! tree dummy = NULL_TREE; ! int n; dtype = make_node (RECORD_TYPE); + PUSH_FIELD (dtype, dummy, "class", class_ptr_type); ! for (n = 1; n < TARGET_VTABLE_USES_DESCRIPTORS; ++n) ! { ! tree tmp_field = build_decl (FIELD_DECL, NULL_TREE, ptr_type_node); ! TREE_CHAIN (dummy) = tmp_field; ! DECL_CONTEXT (tmp_field) = dtype; ! DECL_ARTIFICIAL (tmp_field) = 1; ! dummy = tmp_field; ! } ! ! PUSH_FIELD (dtype, dummy, "gc_descr", ptr_type_node); ! for (n = 1; n < TARGET_VTABLE_USES_DESCRIPTORS; ++n) ! { ! tree tmp_field = build_decl (FIELD_DECL, NULL_TREE, ptr_type_node); ! TREE_CHAIN (dummy) = tmp_field; ! DECL_CONTEXT (tmp_field) = dtype; ! DECL_ARTIFICIAL (tmp_field) = 1; ! dummy = tmp_field; ! } ! ! n = TREE_VEC_LENGTH (get_dispatch_vector (type)); ! if (TARGET_VTABLE_USES_DESCRIPTORS) ! n *= TARGET_VTABLE_USES_DESCRIPTORS; ! ! PUSH_FIELD (dtype, dummy, "methods", ! build_prim_array_type (nativecode_ptr_type_node, n)); layout_type (dtype); } else diff -Nrc3pad gcc-3.0.1/gcc/java/expr.c gcc-3.0.2/gcc/java/expr.c *** gcc-3.0.1/gcc/java/expr.c Tue Jun 5 08:39:04 2001 --- gcc-3.0.2/gcc/java/expr.c Fri Sep 21 18:33:25 2001 *************** build_invokevirtual (dtable, method) *** 1801,1809 **** method_index = size_binop (PLUS_EXPR, method_index, size_int (2)); method_index = size_binop (MULT_EXPR, method_index, TYPE_SIZE_UNIT (nativecode_ptr_ptr_type_node)); func = fold (build (PLUS_EXPR, nativecode_ptr_ptr_type_node, dtable, convert (nativecode_ptr_ptr_type_node, method_index))); ! func = build1 (INDIRECT_REF, nativecode_ptr_type_node, func); return func; } --- 1801,1818 ---- method_index = size_binop (PLUS_EXPR, method_index, size_int (2)); method_index = size_binop (MULT_EXPR, method_index, TYPE_SIZE_UNIT (nativecode_ptr_ptr_type_node)); + + if (TARGET_VTABLE_USES_DESCRIPTORS) + method_index = size_binop (MULT_EXPR, method_index, + size_int (TARGET_VTABLE_USES_DESCRIPTORS)); + func = fold (build (PLUS_EXPR, nativecode_ptr_ptr_type_node, dtable, convert (nativecode_ptr_ptr_type_node, method_index))); ! ! if (TARGET_VTABLE_USES_DESCRIPTORS) ! func = build1 (NOP_EXPR, nativecode_ptr_type_node, func); ! else ! func = build1 (INDIRECT_REF, nativecode_ptr_type_node, func); return func; } diff -Nrc3pad gcc-3.0.1/gcc/java/parse-scan.c gcc-3.0.2/gcc/java/parse-scan.c *** gcc-3.0.1/gcc/java/parse-scan.c Sun Aug 19 17:53:33 2001 --- gcc-3.0.2/gcc/java/parse-scan.c Tue Oct 23 10:57:19 2001 *************** *** 1,7 **** ! /* A Bison parser, made from /sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y ! by GNU Bison version 1.27 ! */ #define YYBISON 1 /* Identify Bison output. */ --- 1,6 ---- ! /* A Bison parser, made from /nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y ! by GNU Bison version 1.28 */ #define YYBISON 1 /* Identify Bison output. */ *************** *** 114,120 **** #define BOOL_LIT_TK 363 #define NULL_TK 364 ! #line 37 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" #define JC1_LITE --- 113,119 ---- #define BOOL_LIT_TK 363 #define NULL_TK 364 ! #line 37 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" #define JC1_LITE *************** void report PARAMS ((void)); *** 190,202 **** #include "lex.h" #include "parse.h" ! #line 113 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" typedef union { char *node; struct method_declarator *declarator; int value; /* For modifiers */ } YYSTYPE; ! #line 119 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" #include "lex.c" #ifndef YYDEBUG --- 189,201 ---- #include "lex.h" #include "parse.h" ! #line 113 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" typedef union { char *node; struct method_declarator *declarator; int value; /* For modifiers */ } YYSTYPE; ! #line 119 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" #include "lex.c" #ifndef YYDEBUG *************** static const short yycheck[] = { 3, *** 1398,1404 **** /* -*-C-*- Note some compilers choke on comments on `#line' lines. */ #line 3 "/usr/lib/bison.simple" ! /* This file comes from bison-1.27. */ /* Skeleton output parser for bison, Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. --- 1397,1403 ---- /* -*-C-*- Note some compilers choke on comments on `#line' lines. */ #line 3 "/usr/lib/bison.simple" ! /* This file comes from bison-1.28. */ /* Skeleton output parser for bison, Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. *************** __yy_memcpy (char *to, char *from, unsig *** 1611,1617 **** #endif #endif ! #line 216 "/usr/lib/bison.simple" /* The user can define YYPARSE_PARAM as the name of an argument to be passed into yyparse. The argument should have type void *. --- 1610,1616 ---- #endif #endif ! #line 217 "/usr/lib/bison.simple" /* The user can define YYPARSE_PARAM as the name of an argument to be passed into yyparse. The argument should have type void *. *************** yyreduce: *** 1940,1991 **** switch (yyn) { case 10: ! #line 211 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { /* use preset global here. FIXME */ yyval.node = xstrdup ("int"); ; break;} case 11: ! #line 216 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { /* use preset global here. FIXME */ yyval.node = xstrdup ("double"); ; break;} case 12: ! #line 221 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { /* use preset global here. FIXME */ yyval.node = xstrdup ("boolean"); ; break;} case 18: ! #line 246 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { while (bracket_count-- > 0) yyval.node = concat ("[", yyvsp[-1].node, NULL); ; break;} case 19: ! #line 251 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { while (bracket_count-- > 0) yyval.node = concat ("[", yyvsp[-1].node, NULL); ; break;} case 23: ! #line 269 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { yyval.node = concat (yyvsp[-2].node, ".", yyvsp[0].node, NULL); ; break;} case 37: ! #line 301 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { package_name = yyvsp[-1].node; ; break;} case 45: ! #line 328 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { if (yyvsp[0].value == PUBLIC_TK) modifier_value++; --- 1939,1990 ---- switch (yyn) { case 10: ! #line 211 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { /* use preset global here. FIXME */ yyval.node = xstrdup ("int"); ; break;} case 11: ! #line 216 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { /* use preset global here. FIXME */ yyval.node = xstrdup ("double"); ; break;} case 12: ! #line 221 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { /* use preset global here. FIXME */ yyval.node = xstrdup ("boolean"); ; break;} case 18: ! #line 246 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { while (bracket_count-- > 0) yyval.node = concat ("[", yyvsp[-1].node, NULL); ; break;} case 19: ! #line 251 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { while (bracket_count-- > 0) yyval.node = concat ("[", yyvsp[-1].node, NULL); ; break;} case 23: ! #line 269 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { yyval.node = concat (yyvsp[-2].node, ".", yyvsp[0].node, NULL); ; break;} case 37: ! #line 301 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { package_name = yyvsp[-1].node; ; break;} case 45: ! #line 328 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { if (yyvsp[0].value == PUBLIC_TK) modifier_value++; *************** case 45: *** 1995,2001 **** ; break;} case 46: ! #line 336 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { if (yyvsp[0].value == PUBLIC_TK) modifier_value++; --- 1994,2000 ---- ; break;} case 46: ! #line 336 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { if (yyvsp[0].value == PUBLIC_TK) modifier_value++; *************** case 46: *** 2005,2069 **** ; break;} case 47: ! #line 348 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { report_class_declaration(yyvsp[-2].node); modifier_value = 0; ; break;} case 49: ! #line 354 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { report_class_declaration(yyvsp[-2].node); ; break;} case 55: ! #line 368 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 56: ! #line 370 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 57: ! #line 375 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { pop_class_context (); ; break;} case 58: ! #line 377 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { pop_class_context (); ; break;} case 70: ! #line 403 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 71: ! #line 405 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { modifier_value = 0; ; break;} case 76: ! #line 421 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { bracket_count = 0; USE_ABSORBER; ; break;} case 77: ! #line 423 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++bracket_count; ; break;} case 81: ! #line 438 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 83: ! #line 441 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { modifier_value = 0; ; break;} case 84: ! #line 443 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { report_main_declaration (yyvsp[-1].declarator); modifier_value = 0; ; break;} case 85: ! #line 451 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { struct method_declarator *d; NEW_METHOD_DECLARATOR (d, yyvsp[-2].node, NULL); --- 2004,2068 ---- ; break;} case 47: ! #line 348 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { report_class_declaration(yyvsp[-2].node); modifier_value = 0; ; break;} case 49: ! #line 354 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { report_class_declaration(yyvsp[-2].node); ; break;} case 55: ! #line 368 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 56: ! #line 370 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 57: ! #line 375 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { pop_class_context (); ; break;} case 58: ! #line 377 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { pop_class_context (); ; break;} case 70: ! #line 403 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 71: ! #line 405 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { modifier_value = 0; ; break;} case 76: ! #line 421 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { bracket_count = 0; USE_ABSORBER; ; break;} case 77: ! #line 423 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++bracket_count; ; break;} case 81: ! #line 438 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 83: ! #line 441 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { modifier_value = 0; ; break;} case 84: ! #line 443 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { report_main_declaration (yyvsp[-1].declarator); modifier_value = 0; ; break;} case 85: ! #line 451 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { struct method_declarator *d; NEW_METHOD_DECLARATOR (d, yyvsp[-2].node, NULL); *************** case 85: *** 2071,2077 **** ; break;} case 86: ! #line 457 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { struct method_declarator *d; NEW_METHOD_DECLARATOR (d, yyvsp[-3].node, yyvsp[-1].node); --- 2070,2076 ---- ; break;} case 86: ! #line 457 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { struct method_declarator *d; NEW_METHOD_DECLARATOR (d, yyvsp[-3].node, yyvsp[-1].node); *************** case 86: *** 2079,2091 **** ; break;} case 89: ! #line 468 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { yyval.node = concat (yyvsp[-2].node, ",", yyvsp[0].node, NULL); ; break;} case 90: ! #line 475 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; if (bracket_count) --- 2078,2090 ---- ; break;} case 89: ! #line 468 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { yyval.node = concat (yyvsp[-2].node, ",", yyvsp[0].node, NULL); ; break;} case 90: ! #line 475 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; if (bracket_count) *************** case 90: *** 2102,2108 **** ; break;} case 91: ! #line 490 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { if (bracket_count) { --- 2101,2107 ---- ; break;} case 91: ! #line 490 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { if (bracket_count) { *************** case 91: *** 2118,2333 **** ; break;} case 94: ! #line 511 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 95: ! #line 513 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 99: ! #line 528 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 101: ! #line 539 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { modifier_value = 0; ; break;} case 103: ! #line 544 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { modifier_value = 0; ; break;} case 104: ! #line 551 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 105: ! #line 553 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 112: ! #line 570 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 113: ! #line 572 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 116: ! #line 584 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { report_class_declaration (yyvsp[0].node); modifier_value = 0; ; break;} case 118: ! #line 587 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { report_class_declaration (yyvsp[0].node); modifier_value = 0; ; break;} case 120: ! #line 590 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { report_class_declaration (yyvsp[-1].node); modifier_value = 0; ; break;} case 122: ! #line 593 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { report_class_declaration (yyvsp[-1].node); modifier_value = 0; ; break;} case 126: ! #line 604 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { pop_class_context (); ; break;} case 127: ! #line 606 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { pop_class_context (); ; break;} case 150: ! #line 665 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 151: ! #line 667 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { modifier_value = 0; ; break;} case 175: ! #line 707 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 186: ! #line 735 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 187: ! #line 740 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 188: ! #line 745 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 196: ! #line 765 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 201: ! #line 780 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 205: ! #line 797 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 211: ! #line 815 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 222: ! #line 840 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 225: ! #line 849 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 228: ! #line 859 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 234: ! #line 874 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 235: ! #line 878 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 246: ! #line 900 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 247: ! #line 905 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 248: ! #line 907 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 249: ! #line 909 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 250: ! #line 911 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 258: ! #line 926 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { report_class_declaration (NULL); ; break;} case 260: ! #line 929 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { report_class_declaration (NULL); ; break;} case 262: ! #line 935 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 276: ! #line 967 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { bracket_count = 1; ; break;} case 277: ! #line 969 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { bracket_count++; ; break;} case 280: ! #line 982 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ++complexity; ; break;} case 281: ! #line 984 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ++complexity; ; break;} case 282: ! #line 985 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 283: ! #line 986 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 284: ! #line 987 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 285: ! #line 988 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 286: ! #line 993 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 289: ! #line 1000 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 336: ! #line 1096 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 338: ! #line 1102 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 340: ! #line 1108 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { ++complexity; ; break;} case 344: ! #line 1122 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} } /* the action file gets copied in in place of this dollarsign */ ! #line 542 "/usr/lib/bison.simple" yyvsp -= yylen; yyssp -= yylen; --- 2117,2332 ---- ; break;} case 94: ! #line 511 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 95: ! #line 513 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 99: ! #line 528 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 101: ! #line 539 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { modifier_value = 0; ; break;} case 103: ! #line 544 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { modifier_value = 0; ; break;} case 104: ! #line 551 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 105: ! #line 553 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 112: ! #line 570 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 113: ! #line 572 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 116: ! #line 584 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { report_class_declaration (yyvsp[0].node); modifier_value = 0; ; break;} case 118: ! #line 587 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { report_class_declaration (yyvsp[0].node); modifier_value = 0; ; break;} case 120: ! #line 590 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { report_class_declaration (yyvsp[-1].node); modifier_value = 0; ; break;} case 122: ! #line 593 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { report_class_declaration (yyvsp[-1].node); modifier_value = 0; ; break;} case 126: ! #line 604 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { pop_class_context (); ; break;} case 127: ! #line 606 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { pop_class_context (); ; break;} case 150: ! #line 665 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 151: ! #line 667 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { modifier_value = 0; ; break;} case 175: ! #line 707 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 186: ! #line 735 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 187: ! #line 740 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 188: ! #line 745 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 196: ! #line 765 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 201: ! #line 780 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 205: ! #line 797 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 211: ! #line 815 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 222: ! #line 840 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 225: ! #line 849 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 228: ! #line 859 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 234: ! #line 874 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 235: ! #line 878 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 246: ! #line 900 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 247: ! #line 905 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 248: ! #line 907 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 249: ! #line 909 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 250: ! #line 911 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 258: ! #line 926 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { report_class_declaration (NULL); ; break;} case 260: ! #line 929 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { report_class_declaration (NULL); ; break;} case 262: ! #line 935 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 276: ! #line 967 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { bracket_count = 1; ; break;} case 277: ! #line 969 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { bracket_count++; ; break;} case 280: ! #line 982 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ++complexity; ; break;} case 281: ! #line 984 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ++complexity; ; break;} case 282: ! #line 985 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 283: ! #line 986 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 284: ! #line 987 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 285: ! #line 988 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 286: ! #line 993 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 289: ! #line 1000 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} case 336: ! #line 1096 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 338: ! #line 1102 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 340: ! #line 1108 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { ++complexity; ; break;} case 344: ! #line 1122 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" { USE_ABSORBER; ; break;} } /* the action file gets copied in in place of this dollarsign */ ! #line 543 "/usr/lib/bison.simple" yyvsp -= yylen; yyssp -= yylen; *************** yyerrhandle: *** 2547,2553 **** } return 1; } ! #line 1140 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse-scan.y" /* Create a new parser context */ --- 2546,2552 ---- } return 1; } ! #line 1140 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse-scan.y" /* Create a new parser context */ diff -Nrc3pad gcc-3.0.1/gcc/java/parse.c gcc-3.0.2/gcc/java/parse.c *** gcc-3.0.1/gcc/java/parse.c Sun Aug 19 17:53:32 2001 --- gcc-3.0.2/gcc/java/parse.c Tue Oct 23 10:57:18 2001 *************** *** 1,7 **** ! /* A Bison parser, made from /sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y ! by GNU Bison version 1.27 ! */ #define YYBISON 1 /* Identify Bison output. */ --- 1,6 ---- ! /* A Bison parser, made from /nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y ! by GNU Bison version 1.28 */ #define YYBISON 1 /* Identify Bison output. */ *************** *** 121,127 **** #define BOOL_LIT_TK 363 #define NULL_TK 364 ! #line 48 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" #include "config.h" #include "system.h" --- 120,126 ---- #define BOOL_LIT_TK 363 #define NULL_TK 364 ! #line 48 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" #include "config.h" #include "system.h" *************** static tree src_parse_roots[1] = { NULL_ *** 510,516 **** } while (0) ! #line 437 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" typedef union { tree node; int sub_token; --- 509,515 ---- } while (0) ! #line 437 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" typedef union { tree node; int sub_token; *************** typedef union { *** 520,526 **** } operator; int value; } YYSTYPE; ! #line 447 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" #include "lex.c" #ifndef YYDEBUG --- 519,525 ---- } operator; int value; } YYSTYPE; ! #line 447 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" #include "lex.c" #ifndef YYDEBUG *************** static const short yycheck[] = { 4, *** 2350,2356 **** /* -*-C-*- Note some compilers choke on comments on `#line' lines. */ #line 3 "/usr/lib/bison.simple" ! /* This file comes from bison-1.27. */ /* Skeleton output parser for bison, Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. --- 2349,2355 ---- /* -*-C-*- Note some compilers choke on comments on `#line' lines. */ #line 3 "/usr/lib/bison.simple" ! /* This file comes from bison-1.28. */ /* Skeleton output parser for bison, Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. *************** __yy_memcpy (char *to, char *from, unsig *** 2563,2569 **** #endif #endif ! #line 216 "/usr/lib/bison.simple" /* The user can define YYPARSE_PARAM as the name of an argument to be passed into yyparse. The argument should have type void *. --- 2562,2568 ---- #endif #endif ! #line 217 "/usr/lib/bison.simple" /* The user can define YYPARSE_PARAM as the name of an argument to be passed into yyparse. The argument should have type void *. *************** yyreduce: *** 2892,2898 **** switch (yyn) { case 1: ! #line 598 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { /* Register static variables with the garbage collector. */ --- 2891,2897 ---- switch (yyn) { case 1: ! #line 598 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { /* Register static variables with the garbage collector. */ *************** case 1: *** 2918,2928 **** ; break;} case 2: ! #line 622 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {; break;} case 19: ! #line 666 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { int osb = pop_current_osb (ctxp); tree t = build_java_array_type ((yyvsp[-1].node), -1); --- 2917,2927 ---- ; break;} case 2: ! #line 622 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {; break;} case 19: ! #line 666 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { int osb = pop_current_osb (ctxp); tree t = build_java_array_type ((yyvsp[-1].node), -1); *************** case 19: *** 2932,2938 **** ; break;} case 20: ! #line 674 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { int osb = pop_current_osb (ctxp); tree t = yyvsp[-1].node; --- 2931,2937 ---- ; break;} case 20: ! #line 674 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { int osb = pop_current_osb (ctxp); tree t = yyvsp[-1].node; *************** case 20: *** 2942,2983 **** ; break;} case 24: ! #line 695 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = make_qualified_name (yyvsp[-2].node, yyvsp[0].node, yyvsp[-1].operator.location); ; break;} case 26: ! #line 704 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyval.node = NULL;; break;} case 34: ! #line 716 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = NULL; ; break;} case 35: ! #line 720 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = NULL; ; break;} case 38: ! #line 732 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { ctxp->package = EXPR_WFL_NODE (yyvsp[-1].node); register_package (ctxp->package); ; break;} case 39: ! #line 737 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing name"); RECOVER;; break;} case 40: ! #line 739 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 43: ! #line 749 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree name = EXPR_WFL_NODE (yyvsp[-1].node), last_name; int i = IDENTIFIER_LENGTH (name)-1; --- 2941,2982 ---- ; break;} case 24: ! #line 695 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = make_qualified_name (yyvsp[-2].node, yyvsp[0].node, yyvsp[-1].operator.location); ; break;} case 26: ! #line 704 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyval.node = NULL;; break;} case 34: ! #line 716 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = NULL; ; break;} case 35: ! #line 720 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = NULL; ; break;} case 38: ! #line 732 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { ctxp->package = EXPR_WFL_NODE (yyvsp[-1].node); register_package (ctxp->package); ; break;} case 39: ! #line 737 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing name"); RECOVER;; break;} case 40: ! #line 739 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 43: ! #line 749 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree name = EXPR_WFL_NODE (yyvsp[-1].node), last_name; int i = IDENTIFIER_LENGTH (name)-1; *************** case 43: *** 3005,3019 **** ; break;} case 44: ! #line 775 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing name"); RECOVER;; break;} case 45: ! #line 777 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 46: ! #line 782 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree name = EXPR_WFL_NODE (yyvsp[-3].node); /* Don't import java.lang.* twice. */ --- 3004,3018 ---- ; break;} case 44: ! #line 775 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing name"); RECOVER;; break;} case 45: ! #line 777 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 46: ! #line 782 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree name = EXPR_WFL_NODE (yyvsp[-3].node); /* Don't import java.lang.* twice. */ *************** case 46: *** 3027,3062 **** ; break;} case 47: ! #line 794 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'*' expected"); RECOVER;; break;} case 48: ! #line 796 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 49: ! #line 801 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { end_class_declaration (0); ; break;} case 50: ! #line 803 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { end_class_declaration (0); ; break;} case 52: ! #line 806 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { YYERROR_NOW; yyerror ("Class or interface declaration expected"); ; break;} case 53: ! #line 817 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.value = (1 << yyvsp[0].value); ; break;} case 54: ! #line 821 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { int acc = (1 << yyvsp[0].value); if (yyval.value & acc) --- 3026,3061 ---- ; break;} case 47: ! #line 794 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'*' expected"); RECOVER;; break;} case 48: ! #line 796 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 49: ! #line 801 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { end_class_declaration (0); ; break;} case 50: ! #line 803 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { end_class_declaration (0); ; break;} case 52: ! #line 806 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { YYERROR_NOW; yyerror ("Class or interface declaration expected"); ; break;} case 53: ! #line 817 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.value = (1 << yyvsp[0].value); ; break;} case 54: ! #line 821 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { int acc = (1 << yyvsp[0].value); if (yyval.value & acc) *************** case 54: *** 3070,3152 **** ; break;} case 55: ! #line 837 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { create_class (yyvsp[-4].value, yyvsp[-2].node, yyvsp[-1].node, yyvsp[0].node); ; break;} case 57: ! #line 840 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { create_class (0, yyvsp[-2].node, yyvsp[-1].node, yyvsp[0].node); ; break;} case 59: ! #line 843 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing class name"); RECOVER;; break;} case 60: ! #line 845 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing class name"); RECOVER;; break;} case 61: ! #line 847 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { if (!ctxp->class_err) yyerror ("'{' expected"); DRECOVER(class1); ; break;} case 62: ! #line 852 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {if (!ctxp->class_err) yyerror ("'{' expected"); RECOVER;; break;} case 63: ! #line 856 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = NULL; ; break;} case 64: ! #line 858 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 65: ! #line 860 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'{' expected"); ctxp->class_err=1;; break;} case 66: ! #line 862 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing super class name"); ctxp->class_err=1;; break;} case 67: ! #line 866 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 68: ! #line 868 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 69: ! #line 870 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { ctxp->class_err=1; yyerror ("Missing interface name"); ; break;} case 70: ! #line 878 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { ctxp->interface_number = 1; yyval.node = build_tree_list (yyvsp[0].node, NULL_TREE); ; break;} case 71: ! #line 883 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { ctxp->interface_number++; yyval.node = chainon (yyvsp[-2].node, build_tree_list (yyvsp[0].node, NULL_TREE)); ; break;} case 72: ! #line 888 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing interface name"); RECOVER;; break;} case 73: ! #line 893 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { /* Store the location of the `}' when doing xrefs */ if (flag_emit_xref) --- 3069,3151 ---- ; break;} case 55: ! #line 837 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { create_class (yyvsp[-4].value, yyvsp[-2].node, yyvsp[-1].node, yyvsp[0].node); ; break;} case 57: ! #line 840 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { create_class (0, yyvsp[-2].node, yyvsp[-1].node, yyvsp[0].node); ; break;} case 59: ! #line 843 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing class name"); RECOVER;; break;} case 60: ! #line 845 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing class name"); RECOVER;; break;} case 61: ! #line 847 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { if (!ctxp->class_err) yyerror ("'{' expected"); DRECOVER(class1); ; break;} case 62: ! #line 852 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {if (!ctxp->class_err) yyerror ("'{' expected"); RECOVER;; break;} case 63: ! #line 856 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = NULL; ; break;} case 64: ! #line 858 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 65: ! #line 860 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'{' expected"); ctxp->class_err=1;; break;} case 66: ! #line 862 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing super class name"); ctxp->class_err=1;; break;} case 67: ! #line 866 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 68: ! #line 868 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 69: ! #line 870 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { ctxp->class_err=1; yyerror ("Missing interface name"); ; break;} case 70: ! #line 878 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { ctxp->interface_number = 1; yyval.node = build_tree_list (yyvsp[0].node, NULL_TREE); ; break;} case 71: ! #line 883 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { ctxp->interface_number++; yyval.node = chainon (yyvsp[-2].node, build_tree_list (yyvsp[0].node, NULL_TREE)); ; break;} case 72: ! #line 888 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing interface name"); RECOVER;; break;} case 73: ! #line 893 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { /* Store the location of the `}' when doing xrefs */ if (flag_emit_xref) *************** case 73: *** 3156,3162 **** ; break;} case 74: ! #line 901 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { /* Store the location of the `}' when doing xrefs */ if (flag_emit_xref) --- 3155,3161 ---- ; break;} case 74: ! #line 901 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { /* Store the location of the `}' when doing xrefs */ if (flag_emit_xref) *************** case 74: *** 3166,3191 **** ; break;} case 80: ! #line 920 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { TREE_CHAIN (yyvsp[0].node) = CPC_INSTANCE_INITIALIZER_STMT (ctxp); SET_CPC_INSTANCE_INITIALIZER_STMT (ctxp, yyvsp[0].node); ; break;} case 83: ! #line 930 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { end_class_declaration (1); ; break;} case 84: ! #line 932 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { end_class_declaration (1); ; break;} case 86: ! #line 939 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { register_fields (0, yyvsp[-2].node, yyvsp[-1].node); ; break;} case 87: ! #line 941 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { check_modifiers ("Illegal modifier `%s' for field declaration", --- 3165,3190 ---- ; break;} case 80: ! #line 920 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { TREE_CHAIN (yyvsp[0].node) = CPC_INSTANCE_INITIALIZER_STMT (ctxp); SET_CPC_INSTANCE_INITIALIZER_STMT (ctxp, yyvsp[0].node); ; break;} case 83: ! #line 930 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { end_class_declaration (1); ; break;} case 84: ! #line 932 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { end_class_declaration (1); ; break;} case 86: ! #line 939 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { register_fields (0, yyvsp[-2].node, yyvsp[-1].node); ; break;} case 87: ! #line 941 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { check_modifiers ("Illegal modifier `%s' for field declaration", *************** case 87: *** 3195,3213 **** ; break;} case 89: ! #line 954 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = chainon (yyvsp[-2].node, yyvsp[0].node); ; break;} case 90: ! #line 956 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 91: ! #line 961 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_tree_list (yyvsp[0].node, NULL_TREE); ; break;} case 92: ! #line 963 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { if (java_error_count) yyvsp[0].node = NULL_TREE; --- 3194,3212 ---- ; break;} case 89: ! #line 954 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = chainon (yyvsp[-2].node, yyvsp[0].node); ; break;} case 90: ! #line 956 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 91: ! #line 961 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_tree_list (yyvsp[0].node, NULL_TREE); ; break;} case 92: ! #line 963 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { if (java_error_count) yyvsp[0].node = NULL_TREE; *************** case 92: *** 3216,3222 **** ; break;} case 93: ! #line 970 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("Missing variable initializer"); yyval.node = build_tree_list (yyvsp[-2].node, NULL_TREE); --- 3215,3221 ---- ; break;} case 93: ! #line 970 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("Missing variable initializer"); yyval.node = build_tree_list (yyvsp[-2].node, NULL_TREE); *************** case 93: *** 3224,3230 **** ; break;} case 94: ! #line 976 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("';' expected"); yyval.node = build_tree_list (yyvsp[-3].node, NULL_TREE); --- 3223,3229 ---- ; break;} case 94: ! #line 976 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("';' expected"); yyval.node = build_tree_list (yyvsp[-3].node, NULL_TREE); *************** case 94: *** 3232,3246 **** ; break;} case 96: ! #line 986 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_unresolved_array_type (yyvsp[-2].node); ; break;} case 97: ! #line 988 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Invalid declaration"); DRECOVER(vdi);; break;} case 98: ! #line 990 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree node = java_lval.node; if (node && (TREE_CODE (node) == INTEGER_CST --- 3231,3245 ---- ; break;} case 96: ! #line 986 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_unresolved_array_type (yyvsp[-2].node); ; break;} case 97: ! #line 988 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Invalid declaration"); DRECOVER(vdi);; break;} case 98: ! #line 990 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree node = java_lval.node; if (node && (TREE_CODE (node) == INTEGER_CST *************** case 98: *** 3252,3262 **** ; break;} case 99: ! #line 1000 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Unbalanced ']'"); DRECOVER(vdi);; break;} case 102: ! #line 1011 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { current_function_decl = yyvsp[0].node; if (current_function_decl --- 3251,3261 ---- ; break;} case 99: ! #line 1000 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Unbalanced ']'"); DRECOVER(vdi);; break;} case 102: ! #line 1011 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { current_function_decl = yyvsp[0].node; if (current_function_decl *************** case 102: *** 3267,3334 **** ; break;} case 103: ! #line 1020 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { finish_method_declaration (yyvsp[0].node); ; break;} case 104: ! #line 1022 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {YYNOT_TWICE yyerror ("'{' expected"); RECOVER;; break;} case 105: ! #line 1027 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = method_header (0, yyvsp[-2].node, yyvsp[-1].node, yyvsp[0].node); ; break;} case 106: ! #line 1029 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = method_header (0, void_type_node, yyvsp[-1].node, yyvsp[0].node); ; break;} case 107: ! #line 1031 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = method_header (yyvsp[-3].value, yyvsp[-2].node, yyvsp[-1].node, yyvsp[0].node); ; break;} case 108: ! #line 1033 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = method_header (yyvsp[-3].value, void_type_node, yyvsp[-1].node, yyvsp[0].node); ; break;} case 109: ! #line 1035 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("Invalid method declaration, method name required"); RECOVER; ; break;} case 110: ! #line 1040 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {RECOVER;; break;} case 111: ! #line 1042 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Identifier expected"); RECOVER;; break;} case 112: ! #line 1044 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Identifier expected"); RECOVER;; break;} case 113: ! #line 1046 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("Invalid method declaration, return type required"); RECOVER; ; break;} case 114: ! #line 1054 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { ctxp->formal_parameter_number = 0; yyval.node = method_declarator (yyvsp[-2].node, NULL_TREE); ; break;} case 115: ! #line 1059 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = method_declarator (yyvsp[-3].node, yyvsp[-1].node); ; break;} case 116: ! #line 1061 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { EXPR_WFL_LINECOL (wfl_operator) = yyvsp[-1].operator.location; TREE_PURPOSE (yyvsp[-2].node) = --- 3266,3333 ---- ; break;} case 103: ! #line 1020 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { finish_method_declaration (yyvsp[0].node); ; break;} case 104: ! #line 1022 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {YYNOT_TWICE yyerror ("'{' expected"); RECOVER;; break;} case 105: ! #line 1027 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = method_header (0, yyvsp[-2].node, yyvsp[-1].node, yyvsp[0].node); ; break;} case 106: ! #line 1029 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = method_header (0, void_type_node, yyvsp[-1].node, yyvsp[0].node); ; break;} case 107: ! #line 1031 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = method_header (yyvsp[-3].value, yyvsp[-2].node, yyvsp[-1].node, yyvsp[0].node); ; break;} case 108: ! #line 1033 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = method_header (yyvsp[-3].value, void_type_node, yyvsp[-1].node, yyvsp[0].node); ; break;} case 109: ! #line 1035 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("Invalid method declaration, method name required"); RECOVER; ; break;} case 110: ! #line 1040 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {RECOVER;; break;} case 111: ! #line 1042 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Identifier expected"); RECOVER;; break;} case 112: ! #line 1044 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Identifier expected"); RECOVER;; break;} case 113: ! #line 1046 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("Invalid method declaration, return type required"); RECOVER; ; break;} case 114: ! #line 1054 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { ctxp->formal_parameter_number = 0; yyval.node = method_declarator (yyvsp[-2].node, NULL_TREE); ; break;} case 115: ! #line 1059 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = method_declarator (yyvsp[-3].node, yyvsp[-1].node); ; break;} case 116: ! #line 1061 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { EXPR_WFL_LINECOL (wfl_operator) = yyvsp[-1].operator.location; TREE_PURPOSE (yyvsp[-2].node) = *************** case 116: *** 3339,3397 **** ; break;} case 117: ! #line 1070 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("')' expected"); DRECOVER(method_declarator);; break;} case 118: ! #line 1072 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("']' expected"); RECOVER;; break;} case 119: ! #line 1077 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { ctxp->formal_parameter_number = 1; ; break;} case 120: ! #line 1081 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { ctxp->formal_parameter_number += 1; yyval.node = chainon (yyvsp[-2].node, yyvsp[0].node); ; break;} case 121: ! #line 1086 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("Missing formal parameter term"); RECOVER; ; break;} case 122: ! #line 1091 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_tree_list (yyvsp[0].node, yyvsp[-1].node); ; break;} case 123: ! #line 1095 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_tree_list (yyvsp[0].node, yyvsp[-1].node); ARG_FINAL_P (yyval.node) = 1; ; break;} case 124: ! #line 1100 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("Missing identifier"); RECOVER; yyval.node = NULL_TREE; ; break;} case 125: ! #line 1105 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("Missing identifier"); RECOVER; yyval.node = NULL_TREE; ; break;} case 126: ! #line 1113 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { check_modifiers ("Illegal modifier `%s'. Only `final' was expected here", yyvsp[0].value, ACC_FINAL); --- 3338,3396 ---- ; break;} case 117: ! #line 1070 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("')' expected"); DRECOVER(method_declarator);; break;} case 118: ! #line 1072 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("']' expected"); RECOVER;; break;} case 119: ! #line 1077 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { ctxp->formal_parameter_number = 1; ; break;} case 120: ! #line 1081 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { ctxp->formal_parameter_number += 1; yyval.node = chainon (yyvsp[-2].node, yyvsp[0].node); ; break;} case 121: ! #line 1086 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("Missing formal parameter term"); RECOVER; ; break;} case 122: ! #line 1091 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_tree_list (yyvsp[0].node, yyvsp[-1].node); ; break;} case 123: ! #line 1095 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_tree_list (yyvsp[0].node, yyvsp[-1].node); ARG_FINAL_P (yyval.node) = 1; ; break;} case 124: ! #line 1100 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("Missing identifier"); RECOVER; yyval.node = NULL_TREE; ; break;} case 125: ! #line 1105 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("Missing identifier"); RECOVER; yyval.node = NULL_TREE; ; break;} case 126: ! #line 1113 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { check_modifiers ("Illegal modifier `%s'. Only `final' was expected here", yyvsp[0].value, ACC_FINAL); *************** case 126: *** 3400,3434 **** ; break;} case 127: ! #line 1122 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 128: ! #line 1124 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 129: ! #line 1126 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing class type term"); RECOVER;; break;} case 130: ! #line 1131 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_tree_list (yyvsp[0].node, yyvsp[0].node); ; break;} case 131: ! #line 1133 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = tree_cons (yyvsp[0].node, yyvsp[0].node, yyvsp[-2].node); ; break;} case 132: ! #line 1135 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing class type term"); RECOVER;; break;} case 134: ! #line 1140 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 135: ! #line 1146 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { TREE_CHAIN (yyvsp[0].node) = CPC_STATIC_INITIALIZER_STMT (ctxp); SET_CPC_STATIC_INITIALIZER_STMT (ctxp, yyvsp[0].node); --- 3399,3433 ---- ; break;} case 127: ! #line 1122 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 128: ! #line 1124 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 129: ! #line 1126 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing class type term"); RECOVER;; break;} case 130: ! #line 1131 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_tree_list (yyvsp[0].node, yyvsp[0].node); ; break;} case 131: ! #line 1133 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = tree_cons (yyvsp[0].node, yyvsp[0].node, yyvsp[-2].node); ; break;} case 132: ! #line 1135 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing class type term"); RECOVER;; break;} case 134: ! #line 1140 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 135: ! #line 1146 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { TREE_CHAIN (yyvsp[0].node) = CPC_STATIC_INITIALIZER_STMT (ctxp); SET_CPC_STATIC_INITIALIZER_STMT (ctxp, yyvsp[0].node); *************** case 135: *** 3436,3442 **** ; break;} case 136: ! #line 1155 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { check_modifiers ("Illegal modifier `%s' for static initializer", yyvsp[0].value, ACC_STATIC); /* Can't have a static initializer in an innerclass */ --- 3435,3441 ---- ; break;} case 136: ! #line 1155 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { check_modifiers ("Illegal modifier `%s' for static initializer", yyvsp[0].value, ACC_STATIC); /* Can't have a static initializer in an innerclass */ *************** case 136: *** 3450,3505 **** ; break;} case 137: ! #line 1171 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { current_function_decl = yyvsp[0].node; source_start_java_method (current_function_decl); ; break;} case 138: ! #line 1176 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { finish_method_declaration (yyvsp[0].node); ; break;} case 139: ! #line 1181 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = method_header (0, NULL_TREE, yyvsp[-1].node, yyvsp[0].node); ; break;} case 140: ! #line 1183 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = method_header (yyvsp[-2].value, NULL_TREE, yyvsp[-1].node, yyvsp[0].node); ; break;} case 141: ! #line 1188 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { ctxp->formal_parameter_number = 0; yyval.node = method_declarator (yyvsp[-2].node, NULL_TREE); ; break;} case 142: ! #line 1193 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = method_declarator (yyvsp[-3].node, yyvsp[-1].node); ; break;} case 143: ! #line 1201 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { BLOCK_EXPR_BODY (yyvsp[0].node) = empty_stmt_node; yyval.node = yyvsp[0].node; ; break;} case 144: ! #line 1206 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 145: ! #line 1208 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 146: ! #line 1210 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 148: ! #line 1220 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_method_invocation (yyvsp[-3].node, NULL_TREE); yyval.node = build_debugable_stmt (EXPR_WFL_LINECOL (yyvsp[-3].node), yyval.node); --- 3449,3504 ---- ; break;} case 137: ! #line 1171 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { current_function_decl = yyvsp[0].node; source_start_java_method (current_function_decl); ; break;} case 138: ! #line 1176 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { finish_method_declaration (yyvsp[0].node); ; break;} case 139: ! #line 1181 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = method_header (0, NULL_TREE, yyvsp[-1].node, yyvsp[0].node); ; break;} case 140: ! #line 1183 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = method_header (yyvsp[-2].value, NULL_TREE, yyvsp[-1].node, yyvsp[0].node); ; break;} case 141: ! #line 1188 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { ctxp->formal_parameter_number = 0; yyval.node = method_declarator (yyvsp[-2].node, NULL_TREE); ; break;} case 142: ! #line 1193 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = method_declarator (yyvsp[-3].node, yyvsp[-1].node); ; break;} case 143: ! #line 1201 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { BLOCK_EXPR_BODY (yyvsp[0].node) = empty_stmt_node; yyval.node = yyvsp[0].node; ; break;} case 144: ! #line 1206 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 145: ! #line 1208 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 146: ! #line 1210 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 148: ! #line 1220 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_method_invocation (yyvsp[-3].node, NULL_TREE); yyval.node = build_debugable_stmt (EXPR_WFL_LINECOL (yyvsp[-3].node), yyval.node); *************** case 148: *** 3507,3513 **** ; break;} case 149: ! #line 1226 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_method_invocation (yyvsp[-4].node, yyvsp[-2].node); yyval.node = build_debugable_stmt (EXPR_WFL_LINECOL (yyvsp[-4].node), yyval.node); --- 3506,3512 ---- ; break;} case 149: ! #line 1226 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_method_invocation (yyvsp[-4].node, yyvsp[-2].node); yyval.node = build_debugable_stmt (EXPR_WFL_LINECOL (yyvsp[-4].node), yyval.node); *************** case 149: *** 3515,3529 **** ; break;} case 150: ! #line 1234 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyval.node = parse_jdk1_1_error ("explicit constructor invocation"); ; break;} case 151: ! #line 1236 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyval.node = parse_jdk1_1_error ("explicit constructor invocation"); ; break;} case 152: ! #line 1241 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree wfl = build_wfl_node (this_identifier_node); EXPR_WFL_LINECOL (wfl) = yyvsp[0].operator.location; --- 3514,3528 ---- ; break;} case 150: ! #line 1234 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyval.node = parse_jdk1_1_error ("explicit constructor invocation"); ; break;} case 151: ! #line 1236 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyval.node = parse_jdk1_1_error ("explicit constructor invocation"); ; break;} case 152: ! #line 1241 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree wfl = build_wfl_node (this_identifier_node); EXPR_WFL_LINECOL (wfl) = yyvsp[0].operator.location; *************** case 152: *** 3531,3537 **** ; break;} case 153: ! #line 1247 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree wfl = build_wfl_node (super_identifier_node); EXPR_WFL_LINECOL (wfl) = yyvsp[0].operator.location; --- 3530,3536 ---- ; break;} case 153: ! #line 1247 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree wfl = build_wfl_node (super_identifier_node); EXPR_WFL_LINECOL (wfl) = yyvsp[0].operator.location; *************** case 153: *** 3539,3647 **** ; break;} case 154: ! #line 1258 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { create_interface (0, yyvsp[0].node, NULL_TREE); ; break;} case 156: ! #line 1261 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { create_interface (yyvsp[-2].value, yyvsp[0].node, NULL_TREE); ; break;} case 158: ! #line 1264 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { create_interface (0, yyvsp[-1].node, yyvsp[0].node); ; break;} case 160: ! #line 1267 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { create_interface (yyvsp[-3].value, yyvsp[-1].node, yyvsp[0].node); ; break;} case 162: ! #line 1270 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'{' expected"); RECOVER;; break;} case 163: ! #line 1272 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'{' expected"); RECOVER;; break;} case 164: ! #line 1277 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { ctxp->interface_number = 1; yyval.node = build_tree_list (yyvsp[0].node, NULL_TREE); ; break;} case 165: ! #line 1282 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { ctxp->interface_number++; yyval.node = chainon (yyvsp[-2].node, build_tree_list (yyvsp[0].node, NULL_TREE)); ; break;} case 166: ! #line 1287 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Invalid interface type"); RECOVER;; break;} case 167: ! #line 1289 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 168: ! #line 1294 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 169: ! #line 1296 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 174: ! #line 1308 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { end_class_declaration (1); ; break;} case 175: ! #line 1310 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { end_class_declaration (1); ; break;} case 177: ! #line 1319 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { check_abstract_method_header (yyvsp[-1].node); current_function_decl = NULL_TREE; /* FIXME ? */ ; break;} case 178: ! #line 1324 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 179: ! #line 1330 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_new_array_init (yyvsp[-1].operator.location, NULL_TREE); ; break;} case 180: ! #line 1332 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_new_array_init (yyvsp[-2].operator.location, yyvsp[-1].node); ; break;} case 181: ! #line 1334 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_new_array_init (yyvsp[-3].operator.location, yyvsp[-2].node); ; break;} case 182: ! #line 1339 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = tree_cons (maybe_build_array_element_wfl (yyvsp[0].node), yyvsp[0].node, NULL_TREE); ; break;} case 183: ! #line 1344 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = tree_cons (maybe_build_array_element_wfl (yyvsp[0].node), yyvsp[0].node, yyvsp[-2].node); ; break;} case 184: ! #line 1348 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 185: ! #line 1354 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { /* Store the location of the `}' when doing xrefs */ if (current_function_decl && flag_emit_xref) --- 3538,3646 ---- ; break;} case 154: ! #line 1258 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { create_interface (0, yyvsp[0].node, NULL_TREE); ; break;} case 156: ! #line 1261 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { create_interface (yyvsp[-2].value, yyvsp[0].node, NULL_TREE); ; break;} case 158: ! #line 1264 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { create_interface (0, yyvsp[-1].node, yyvsp[0].node); ; break;} case 160: ! #line 1267 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { create_interface (yyvsp[-3].value, yyvsp[-1].node, yyvsp[0].node); ; break;} case 162: ! #line 1270 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'{' expected"); RECOVER;; break;} case 163: ! #line 1272 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'{' expected"); RECOVER;; break;} case 164: ! #line 1277 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { ctxp->interface_number = 1; yyval.node = build_tree_list (yyvsp[0].node, NULL_TREE); ; break;} case 165: ! #line 1282 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { ctxp->interface_number++; yyval.node = chainon (yyvsp[-2].node, build_tree_list (yyvsp[0].node, NULL_TREE)); ; break;} case 166: ! #line 1287 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Invalid interface type"); RECOVER;; break;} case 167: ! #line 1289 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 168: ! #line 1294 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 169: ! #line 1296 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 174: ! #line 1308 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { end_class_declaration (1); ; break;} case 175: ! #line 1310 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { end_class_declaration (1); ; break;} case 177: ! #line 1319 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { check_abstract_method_header (yyvsp[-1].node); current_function_decl = NULL_TREE; /* FIXME ? */ ; break;} case 178: ! #line 1324 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 179: ! #line 1330 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_new_array_init (yyvsp[-1].operator.location, NULL_TREE); ; break;} case 180: ! #line 1332 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_new_array_init (yyvsp[-2].operator.location, yyvsp[-1].node); ; break;} case 181: ! #line 1334 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_new_array_init (yyvsp[-3].operator.location, yyvsp[-2].node); ; break;} case 182: ! #line 1339 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = tree_cons (maybe_build_array_element_wfl (yyvsp[0].node), yyvsp[0].node, NULL_TREE); ; break;} case 183: ! #line 1344 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = tree_cons (maybe_build_array_element_wfl (yyvsp[0].node), yyvsp[0].node, yyvsp[-2].node); ; break;} case 184: ! #line 1348 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 185: ! #line 1354 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { /* Store the location of the `}' when doing xrefs */ if (current_function_decl && flag_emit_xref) *************** case 185: *** 3651,3665 **** ; break;} case 186: ! #line 1362 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 187: ! #line 1367 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { enter_block (); ; break;} case 188: ! #line 1372 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { maybe_absorb_scoping_blocks (); /* Store the location of the `}' when doing xrefs */ --- 3650,3664 ---- ; break;} case 186: ! #line 1362 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 187: ! #line 1367 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { enter_block (); ; break;} case 188: ! #line 1372 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { maybe_absorb_scoping_blocks (); /* Store the location of the `}' when doing xrefs */ *************** case 188: *** 3672,3705 **** ; break;} case 192: ! #line 1392 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { java_method_add_stmt (current_function_decl, yyvsp[0].node); ; break;} case 193: ! #line 1394 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { LOCAL_CLASS_P (TREE_TYPE (GET_CPC ())) = 1; end_class_declaration (1); ; break;} case 195: ! #line 1406 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { declare_local_variables (0, yyvsp[-1].node, yyvsp[0].node); ; break;} case 196: ! #line 1408 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { declare_local_variables (yyvsp[-2].value, yyvsp[-1].node, yyvsp[0].node); ; break;} case 202: ! #line 1418 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = exit_block (); ; break;} case 207: ! #line 1427 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = exit_block (); ; break;} case 219: ! #line 1446 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { if (flag_extraneous_semicolon) { --- 3671,3704 ---- ; break;} case 192: ! #line 1392 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { java_method_add_stmt (current_function_decl, yyvsp[0].node); ; break;} case 193: ! #line 1394 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { LOCAL_CLASS_P (TREE_TYPE (GET_CPC ())) = 1; end_class_declaration (1); ; break;} case 195: ! #line 1406 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { declare_local_variables (0, yyvsp[-1].node, yyvsp[0].node); ; break;} case 196: ! #line 1408 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { declare_local_variables (yyvsp[-2].value, yyvsp[-1].node, yyvsp[0].node); ; break;} case 202: ! #line 1418 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = exit_block (); ; break;} case 207: ! #line 1427 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = exit_block (); ; break;} case 219: ! #line 1446 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { if (flag_extraneous_semicolon) { *************** case 219: *** 3710,3716 **** ; break;} case 220: ! #line 1458 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_labeled_block (EXPR_WFL_LINECOL (yyvsp[-1].node), EXPR_WFL_NODE (yyvsp[-1].node)); --- 3709,3715 ---- ; break;} case 220: ! #line 1458 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_labeled_block (EXPR_WFL_LINECOL (yyvsp[-1].node), EXPR_WFL_NODE (yyvsp[-1].node)); *************** case 220: *** 3720,3738 **** ; break;} case 221: ! #line 1469 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = finish_labeled_statement (yyvsp[-1].node, yyvsp[0].node); ; break;} case 222: ! #line 1471 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("':' expected"); RECOVER;; break;} case 223: ! #line 1476 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = finish_labeled_statement (yyvsp[-1].node, yyvsp[0].node); ; break;} case 224: ! #line 1483 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { /* We have a statement. Generate a WFL around it so we can debug it */ --- 3719,3737 ---- ; break;} case 221: ! #line 1469 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = finish_labeled_statement (yyvsp[-1].node, yyvsp[0].node); ; break;} case 222: ! #line 1471 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("':' expected"); RECOVER;; break;} case 223: ! #line 1476 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = finish_labeled_statement (yyvsp[-1].node, yyvsp[0].node); ; break;} case 224: ! #line 1483 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { /* We have a statement. Generate a WFL around it so we can debug it */ *************** case 224: *** 3743,3845 **** ; break;} case 225: ! #line 1492 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { YYNOT_TWICE yyerror ("Invalid expression statement"); DRECOVER (expr_stmt); ; break;} case 226: ! #line 1497 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { YYNOT_TWICE yyerror ("Invalid expression statement"); DRECOVER (expr_stmt); ; break;} case 227: ! #line 1502 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { YYNOT_TWICE yyerror ("Invalid expression statement"); DRECOVER (expr_stmt); ; break;} case 228: ! #line 1507 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 229: ! #line 1509 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { parse_ctor_invocation_error (); RECOVER; ; break;} case 230: ! #line 1514 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 231: ! #line 1516 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { parse_ctor_invocation_error (); RECOVER; ; break;} case 232: ! #line 1521 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER;; break;} case 233: ! #line 1523 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 234: ! #line 1525 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 235: ! #line 1527 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 236: ! #line 1529 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 244: ! #line 1544 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_if_else_statement (yyvsp[-3].operator.location, yyvsp[-2].node, yyvsp[0].node, NULL_TREE); ; break;} case 245: ! #line 1549 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER;; break;} case 246: ! #line 1551 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 247: ! #line 1553 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 248: ! #line 1558 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_if_else_statement (yyvsp[-5].operator.location, yyvsp[-4].node, yyvsp[-2].node, yyvsp[0].node); ; break;} case 249: ! #line 1563 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_if_else_statement (yyvsp[-5].operator.location, yyvsp[-4].node, yyvsp[-2].node, yyvsp[0].node); ; break;} case 250: ! #line 1568 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { enter_block (); ; break;} case 251: ! #line 1572 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { /* Make into "proper list" of COMPOUND_EXPRs. I.e. make the last statment also have its own --- 3742,3844 ---- ; break;} case 225: ! #line 1492 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { YYNOT_TWICE yyerror ("Invalid expression statement"); DRECOVER (expr_stmt); ; break;} case 226: ! #line 1497 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { YYNOT_TWICE yyerror ("Invalid expression statement"); DRECOVER (expr_stmt); ; break;} case 227: ! #line 1502 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { YYNOT_TWICE yyerror ("Invalid expression statement"); DRECOVER (expr_stmt); ; break;} case 228: ! #line 1507 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 229: ! #line 1509 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { parse_ctor_invocation_error (); RECOVER; ; break;} case 230: ! #line 1514 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 231: ! #line 1516 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { parse_ctor_invocation_error (); RECOVER; ; break;} case 232: ! #line 1521 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER;; break;} case 233: ! #line 1523 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 234: ! #line 1525 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 235: ! #line 1527 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 236: ! #line 1529 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 244: ! #line 1544 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_if_else_statement (yyvsp[-3].operator.location, yyvsp[-2].node, yyvsp[0].node, NULL_TREE); ; break;} case 245: ! #line 1549 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER;; break;} case 246: ! #line 1551 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 247: ! #line 1553 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 248: ! #line 1558 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_if_else_statement (yyvsp[-5].operator.location, yyvsp[-4].node, yyvsp[-2].node, yyvsp[0].node); ; break;} case 249: ! #line 1563 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_if_else_statement (yyvsp[-5].operator.location, yyvsp[-4].node, yyvsp[-2].node, yyvsp[0].node); ; break;} case 250: ! #line 1568 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { enter_block (); ; break;} case 251: ! #line 1572 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { /* Make into "proper list" of COMPOUND_EXPRs. I.e. make the last statment also have its own *************** case 251: *** 3850,3891 **** ; break;} case 252: ! #line 1584 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build (SWITCH_EXPR, NULL_TREE, yyvsp[-1].node, NULL_TREE); EXPR_WFL_LINECOL (yyval.node) = yyvsp[-2].operator.location; ; break;} case 253: ! #line 1589 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER;; break;} case 254: ! #line 1591 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term or ')'"); DRECOVER(switch_statement);; break;} case 255: ! #line 1593 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'{' expected"); RECOVER;; break;} case 256: ! #line 1601 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 257: ! #line 1603 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 258: ! #line 1605 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 259: ! #line 1607 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 265: ! #line 1626 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree lab = build1 (CASE_EXPR, NULL_TREE, yyvsp[-1].node); EXPR_WFL_LINECOL (lab) = yyvsp[-2].operator.location; --- 3849,3890 ---- ; break;} case 252: ! #line 1584 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build (SWITCH_EXPR, NULL_TREE, yyvsp[-1].node, NULL_TREE); EXPR_WFL_LINECOL (yyval.node) = yyvsp[-2].operator.location; ; break;} case 253: ! #line 1589 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER;; break;} case 254: ! #line 1591 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term or ')'"); DRECOVER(switch_statement);; break;} case 255: ! #line 1593 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'{' expected"); RECOVER;; break;} case 256: ! #line 1601 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 257: ! #line 1603 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 258: ! #line 1605 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 259: ! #line 1607 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = NULL_TREE; ; break;} case 265: ! #line 1626 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree lab = build1 (CASE_EXPR, NULL_TREE, yyvsp[-1].node); EXPR_WFL_LINECOL (lab) = yyvsp[-2].operator.location; *************** case 265: *** 3893,3899 **** ; break;} case 266: ! #line 1632 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree lab = build (DEFAULT_EXPR, NULL_TREE, NULL_TREE); EXPR_WFL_LINECOL (lab) = yyvsp[-1].operator.location; --- 3892,3898 ---- ; break;} case 266: ! #line 1632 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree lab = build (DEFAULT_EXPR, NULL_TREE, NULL_TREE); EXPR_WFL_LINECOL (lab) = yyvsp[-1].operator.location; *************** case 266: *** 3901,3957 **** ; break;} case 267: ! #line 1638 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing or invalid constant expression"); RECOVER;; break;} case 268: ! #line 1640 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("':' expected"); RECOVER;; break;} case 269: ! #line 1642 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("':' expected"); RECOVER;; break;} case 270: ! #line 1647 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree body = build_loop_body (yyvsp[-2].operator.location, yyvsp[-1].node, 0); yyval.node = build_new_loop (body); ; break;} case 271: ! #line 1655 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = finish_loop_body (0, NULL_TREE, yyvsp[0].node, 0); ; break;} case 272: ! #line 1657 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {YYERROR_NOW; yyerror ("'(' expected"); RECOVER;; break;} case 273: ! #line 1659 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term and ')' expected"); RECOVER;; break;} case 274: ! #line 1661 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 275: ! #line 1666 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = finish_loop_body (0, NULL_TREE, yyvsp[0].node, 0); ; break;} case 276: ! #line 1671 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree body = build_loop_body (0, NULL_TREE, 1); yyval.node = build_new_loop (body); ; break;} case 277: ! #line 1680 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = finish_loop_body (yyvsp[-3].operator.location, yyvsp[-2].node, yyvsp[-5].node, 1); ; break;} case 278: ! #line 1685 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { if (TREE_CODE_CLASS (TREE_CODE (yyvsp[-4].node)) == 'c') yyvsp[-4].node = build_wfl_node (yyvsp[-4].node); --- 3900,3956 ---- ; break;} case 267: ! #line 1638 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing or invalid constant expression"); RECOVER;; break;} case 268: ! #line 1640 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("':' expected"); RECOVER;; break;} case 269: ! #line 1642 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("':' expected"); RECOVER;; break;} case 270: ! #line 1647 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree body = build_loop_body (yyvsp[-2].operator.location, yyvsp[-1].node, 0); yyval.node = build_new_loop (body); ; break;} case 271: ! #line 1655 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = finish_loop_body (0, NULL_TREE, yyvsp[0].node, 0); ; break;} case 272: ! #line 1657 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {YYERROR_NOW; yyerror ("'(' expected"); RECOVER;; break;} case 273: ! #line 1659 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term and ')' expected"); RECOVER;; break;} case 274: ! #line 1661 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 275: ! #line 1666 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = finish_loop_body (0, NULL_TREE, yyvsp[0].node, 0); ; break;} case 276: ! #line 1671 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree body = build_loop_body (0, NULL_TREE, 1); yyval.node = build_new_loop (body); ; break;} case 277: ! #line 1680 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = finish_loop_body (yyvsp[-3].operator.location, yyvsp[-2].node, yyvsp[-5].node, 1); ; break;} case 278: ! #line 1685 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { if (TREE_CODE_CLASS (TREE_CODE (yyvsp[-4].node)) == 'c') yyvsp[-4].node = build_wfl_node (yyvsp[-4].node); *************** case 278: *** 3959,3965 **** ; break;} case 279: ! #line 1691 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = finish_for_loop (0, NULL_TREE, yyvsp[-2].node, yyvsp[0].node); /* We have not condition, so we get rid of the EXIT_EXPR */ --- 3958,3964 ---- ; break;} case 279: ! #line 1691 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = finish_for_loop (0, NULL_TREE, yyvsp[-2].node, yyvsp[0].node); /* We have not condition, so we get rid of the EXIT_EXPR */ *************** case 279: *** 3968,3990 **** ; break;} case 280: ! #line 1698 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Invalid control expression"); RECOVER;; break;} case 281: ! #line 1700 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Invalid update expression"); RECOVER;; break;} case 282: ! #line 1702 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Invalid update expression"); RECOVER;; break;} case 283: ! #line 1707 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = finish_for_loop (EXPR_WFL_LINECOL (yyvsp[-4].node), yyvsp[-4].node, yyvsp[-2].node, yyvsp[0].node);; break;} case 284: ! #line 1709 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = finish_for_loop (0, NULL_TREE, yyvsp[-2].node, yyvsp[0].node); /* We have not condition, so we get rid of the EXIT_EXPR */ --- 3967,3989 ---- ; break;} case 280: ! #line 1698 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Invalid control expression"); RECOVER;; break;} case 281: ! #line 1700 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Invalid update expression"); RECOVER;; break;} case 282: ! #line 1702 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Invalid update expression"); RECOVER;; break;} case 283: ! #line 1707 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = finish_for_loop (EXPR_WFL_LINECOL (yyvsp[-4].node), yyvsp[-4].node, yyvsp[-2].node, yyvsp[0].node);; break;} case 284: ! #line 1709 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = finish_for_loop (0, NULL_TREE, yyvsp[-2].node, yyvsp[0].node); /* We have not condition, so we get rid of the EXIT_EXPR */ *************** case 284: *** 3993,3999 **** ; break;} case 285: ! #line 1719 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { /* This scope defined for local variable that may be defined within the scope of the for loop */ --- 3992,3998 ---- ; break;} case 285: ! #line 1719 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { /* This scope defined for local variable that may be defined within the scope of the for loop */ *************** case 285: *** 4001,4015 **** ; break;} case 286: ! #line 1725 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'(' expected"); DRECOVER(for_1);; break;} case 287: ! #line 1727 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Invalid init statement"); RECOVER;; break;} case 288: ! #line 1732 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { /* We now declare the loop body. The loop is declared as a for loop. */ --- 4000,4014 ---- ; break;} case 286: ! #line 1725 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'(' expected"); DRECOVER(for_1);; break;} case 287: ! #line 1727 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Invalid init statement"); RECOVER;; break;} case 288: ! #line 1732 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { /* We now declare the loop body. The loop is declared as a for loop. */ *************** case 288: *** 4022,4032 **** ; break;} case 289: ! #line 1744 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = empty_stmt_node; ; break;} case 290: ! #line 1746 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { /* Init statement recorded within the previously defined block scope */ --- 4021,4031 ---- ; break;} case 289: ! #line 1744 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = empty_stmt_node; ; break;} case 290: ! #line 1746 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { /* Init statement recorded within the previously defined block scope */ *************** case 290: *** 4034,4040 **** ; break;} case 291: ! #line 1752 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { /* Local variable are recorded within the previously defined block scope */ --- 4033,4039 ---- ; break;} case 291: ! #line 1752 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { /* Local variable are recorded within the previously defined block scope */ *************** case 291: *** 4042,4135 **** ; break;} case 292: ! #line 1758 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("';' expected"); DRECOVER(for_init_1);; break;} case 293: ! #line 1762 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyval.node = empty_stmt_node;; break;} case 294: ! #line 1764 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_debugable_stmt (BUILD_LOCATION (), yyvsp[0].node); ; break;} case 295: ! #line 1769 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = add_stmt_to_compound (NULL_TREE, NULL_TREE, yyvsp[0].node); ; break;} case 296: ! #line 1771 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = add_stmt_to_compound (yyvsp[-2].node, NULL_TREE, yyvsp[0].node); ; break;} case 297: ! #line 1773 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 298: ! #line 1778 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_bc_statement (yyvsp[-1].operator.location, 1, NULL_TREE); ; break;} case 299: ! #line 1780 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_bc_statement (yyvsp[-2].operator.location, 1, yyvsp[-1].node); ; break;} case 300: ! #line 1782 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 301: ! #line 1784 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 302: ! #line 1789 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_bc_statement (yyvsp[-1].operator.location, 0, NULL_TREE); ; break;} case 303: ! #line 1791 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_bc_statement (yyvsp[-2].operator.location, 0, yyvsp[-1].node); ; break;} case 304: ! #line 1793 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 305: ! #line 1795 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 306: ! #line 1800 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_return (yyvsp[-1].operator.location, NULL_TREE); ; break;} case 307: ! #line 1802 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_return (yyvsp[-2].operator.location, yyvsp[-1].node); ; break;} case 308: ! #line 1804 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 309: ! #line 1806 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 310: ! #line 1811 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build1 (THROW_EXPR, NULL_TREE, yyvsp[-1].node); EXPR_WFL_LINECOL (yyval.node) = yyvsp[-2].operator.location; ; break;} case 311: ! #line 1816 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 312: ! #line 1818 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 313: ! #line 1823 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build (SYNCHRONIZED_EXPR, NULL_TREE, yyvsp[-2].node, yyvsp[0].node); EXPR_WFL_LINECOL (yyval.node) = --- 4041,4134 ---- ; break;} case 292: ! #line 1758 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("';' expected"); DRECOVER(for_init_1);; break;} case 293: ! #line 1762 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyval.node = empty_stmt_node;; break;} case 294: ! #line 1764 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_debugable_stmt (BUILD_LOCATION (), yyvsp[0].node); ; break;} case 295: ! #line 1769 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = add_stmt_to_compound (NULL_TREE, NULL_TREE, yyvsp[0].node); ; break;} case 296: ! #line 1771 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = add_stmt_to_compound (yyvsp[-2].node, NULL_TREE, yyvsp[0].node); ; break;} case 297: ! #line 1773 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 298: ! #line 1778 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_bc_statement (yyvsp[-1].operator.location, 1, NULL_TREE); ; break;} case 299: ! #line 1780 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_bc_statement (yyvsp[-2].operator.location, 1, yyvsp[-1].node); ; break;} case 300: ! #line 1782 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 301: ! #line 1784 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 302: ! #line 1789 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_bc_statement (yyvsp[-1].operator.location, 0, NULL_TREE); ; break;} case 303: ! #line 1791 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_bc_statement (yyvsp[-2].operator.location, 0, yyvsp[-1].node); ; break;} case 304: ! #line 1793 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 305: ! #line 1795 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 306: ! #line 1800 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_return (yyvsp[-1].operator.location, NULL_TREE); ; break;} case 307: ! #line 1802 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_return (yyvsp[-2].operator.location, yyvsp[-1].node); ; break;} case 308: ! #line 1804 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 309: ! #line 1806 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 310: ! #line 1811 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build1 (THROW_EXPR, NULL_TREE, yyvsp[-1].node); EXPR_WFL_LINECOL (yyval.node) = yyvsp[-2].operator.location; ; break;} case 311: ! #line 1816 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 312: ! #line 1818 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("';' expected"); RECOVER;; break;} case 313: ! #line 1823 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build (SYNCHRONIZED_EXPR, NULL_TREE, yyvsp[-2].node, yyvsp[0].node); EXPR_WFL_LINECOL (yyval.node) = *************** case 313: *** 4137,4159 **** ; break;} case 314: ! #line 1829 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'{' expected"); RECOVER;; break;} case 315: ! #line 1831 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER;; break;} case 316: ! #line 1833 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 317: ! #line 1835 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 318: ! #line 1840 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { check_modifiers ( "Illegal modifier `%s'. Only `synchronized' was expected here", --- 4136,4158 ---- ; break;} case 314: ! #line 1829 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'{' expected"); RECOVER;; break;} case 315: ! #line 1831 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER;; break;} case 316: ! #line 1833 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 317: ! #line 1835 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 318: ! #line 1840 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { check_modifiers ( "Illegal modifier `%s'. Only `synchronized' was expected here", *************** case 318: *** 4164,4196 **** ; break;} case 319: ! #line 1852 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_try_statement (yyvsp[-2].operator.location, yyvsp[-1].node, yyvsp[0].node); ; break;} case 320: ! #line 1854 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_try_finally_statement (yyvsp[-2].operator.location, yyvsp[-1].node, yyvsp[0].node); ; break;} case 321: ! #line 1856 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_try_finally_statement (yyvsp[-3].operator.location, build_try_statement (yyvsp[-3].operator.location, yyvsp[-2].node, yyvsp[-1].node), yyvsp[0].node); ; break;} case 322: ! #line 1861 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'{' expected"); DRECOVER (try_statement);; break;} case 324: ! #line 1867 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { TREE_CHAIN (yyvsp[0].node) = yyvsp[-1].node; yyval.node = yyvsp[0].node; ; break;} case 325: ! #line 1875 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { java_method_add_stmt (current_function_decl, yyvsp[0].node); exit_block (); --- 4163,4195 ---- ; break;} case 319: ! #line 1852 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_try_statement (yyvsp[-2].operator.location, yyvsp[-1].node, yyvsp[0].node); ; break;} case 320: ! #line 1854 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_try_finally_statement (yyvsp[-2].operator.location, yyvsp[-1].node, yyvsp[0].node); ; break;} case 321: ! #line 1856 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_try_finally_statement (yyvsp[-3].operator.location, build_try_statement (yyvsp[-3].operator.location, yyvsp[-2].node, yyvsp[-1].node), yyvsp[0].node); ; break;} case 322: ! #line 1861 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'{' expected"); DRECOVER (try_statement);; break;} case 324: ! #line 1867 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { TREE_CHAIN (yyvsp[0].node) = yyvsp[-1].node; yyval.node = yyvsp[0].node; ; break;} case 325: ! #line 1875 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { java_method_add_stmt (current_function_decl, yyvsp[0].node); exit_block (); *************** case 325: *** 4198,4204 **** ; break;} case 326: ! #line 1883 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { /* We add a block to define a scope for formal_parameter (CCBP). The formal parameter is --- 4197,4203 ---- ; break;} case 326: ! #line 1883 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { /* We add a block to define a scope for formal_parameter (CCBP). The formal parameter is *************** case 326: *** 4216,4303 **** ; break;} case 327: ! #line 1899 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER; yyval.node = NULL_TREE;; break;} case 328: ! #line 1901 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("Missing term or ')' expected"); RECOVER; yyval.node = NULL_TREE; ; break;} case 329: ! #line 1906 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; yyval.node = NULL_TREE;; break;} case 330: ! #line 1911 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 331: ! #line 1913 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'{' expected"); RECOVER; ; break;} case 335: ! #line 1925 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_this (yyvsp[0].operator.location); ; break;} case 336: ! #line 1927 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyval.node = yyvsp[-1].node;; break;} case 342: ! #line 1937 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree wfl = build_wfl_node (this_identifier_node); yyval.node = make_qualified_primary (yyvsp[-2].node, wfl, EXPR_WFL_LINECOL (yyvsp[-2].node)); ; break;} case 343: ! #line 1942 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 344: ! #line 1944 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'class' or 'this' expected" ); RECOVER;; break;} case 345: ! #line 1946 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'class' expected" ); RECOVER;; break;} case 346: ! #line 1948 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'class' expected" ); RECOVER;; break;} case 347: ! #line 1953 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_incomplete_class_ref (yyvsp[-1].operator.location, yyvsp[-2].node); ; break;} case 348: ! #line 1955 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_incomplete_class_ref (yyvsp[-1].operator.location, yyvsp[-2].node); ; break;} case 349: ! #line 1957 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_incomplete_class_ref (yyvsp[-1].operator.location, yyvsp[-2].node); ; break;} case 350: ! #line 1959 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_incomplete_class_ref (yyvsp[-1].operator.location, void_type_node); ; break;} case 351: ! #line 1967 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_new_invocation (yyvsp[-3].node, yyvsp[-1].node); ; break;} case 352: ! #line 1969 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_new_invocation (yyvsp[-2].node, NULL_TREE); ; break;} case 354: ! #line 1975 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree ctor = build_new_invocation (yyvsp[-2].node, NULL_TREE); yyval.node = make_qualified_primary (yyvsp[-3].node, ctor, --- 4215,4302 ---- ; break;} case 327: ! #line 1899 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER; yyval.node = NULL_TREE;; break;} case 328: ! #line 1901 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("Missing term or ')' expected"); RECOVER; yyval.node = NULL_TREE; ; break;} case 329: ! #line 1906 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; yyval.node = NULL_TREE;; break;} case 330: ! #line 1911 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = yyvsp[0].node; ; break;} case 331: ! #line 1913 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'{' expected"); RECOVER; ; break;} case 335: ! #line 1925 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_this (yyvsp[0].operator.location); ; break;} case 336: ! #line 1927 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyval.node = yyvsp[-1].node;; break;} case 342: ! #line 1937 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree wfl = build_wfl_node (this_identifier_node); yyval.node = make_qualified_primary (yyvsp[-2].node, wfl, EXPR_WFL_LINECOL (yyvsp[-2].node)); ; break;} case 343: ! #line 1942 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 344: ! #line 1944 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'class' or 'this' expected" ); RECOVER;; break;} case 345: ! #line 1946 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'class' expected" ); RECOVER;; break;} case 346: ! #line 1948 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'class' expected" ); RECOVER;; break;} case 347: ! #line 1953 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_incomplete_class_ref (yyvsp[-1].operator.location, yyvsp[-2].node); ; break;} case 348: ! #line 1955 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_incomplete_class_ref (yyvsp[-1].operator.location, yyvsp[-2].node); ; break;} case 349: ! #line 1957 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_incomplete_class_ref (yyvsp[-1].operator.location, yyvsp[-2].node); ; break;} case 350: ! #line 1959 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_incomplete_class_ref (yyvsp[-1].operator.location, void_type_node); ; break;} case 351: ! #line 1967 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_new_invocation (yyvsp[-3].node, yyvsp[-1].node); ; break;} case 352: ! #line 1969 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_new_invocation (yyvsp[-2].node, NULL_TREE); ; break;} case 354: ! #line 1975 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree ctor = build_new_invocation (yyvsp[-2].node, NULL_TREE); yyval.node = make_qualified_primary (yyvsp[-3].node, ctor, *************** case 354: *** 4305,4311 **** ; break;} case 356: ! #line 1982 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree ctor = build_new_invocation (yyvsp[-3].node, yyvsp[-1].node); yyval.node = make_qualified_primary (yyvsp[-4].node, ctor, --- 4304,4310 ---- ; break;} case 356: ! #line 1982 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree ctor = build_new_invocation (yyvsp[-3].node, yyvsp[-1].node); yyval.node = make_qualified_primary (yyvsp[-4].node, ctor, *************** case 356: *** 4313,4347 **** ; break;} case 358: ! #line 1989 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'(' expected"); DRECOVER(new_1);; break;} case 359: ! #line 1991 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER;; break;} case 360: ! #line 1993 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("')' or term expected"); RECOVER;; break;} case 361: ! #line 1995 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 362: ! #line 1997 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {YYERROR_NOW; yyerror ("Identifier expected"); RECOVER;; break;} case 363: ! #line 1999 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER;; break;} case 364: ! #line 2009 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { create_anonymous_class (yyvsp[-4].operator.location, yyvsp[-3].node); ; break;} case 365: ! #line 2011 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree id = build_wfl_node (DECL_NAME (GET_CPC ())); EXPR_WFL_LINECOL (id) = EXPR_WFL_LINECOL (yyvsp[-5].node); --- 4312,4346 ---- ; break;} case 358: ! #line 1989 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'(' expected"); DRECOVER(new_1);; break;} case 359: ! #line 1991 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER;; break;} case 360: ! #line 1993 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("')' or term expected"); RECOVER;; break;} case 361: ! #line 1995 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("')' expected"); RECOVER;; break;} case 362: ! #line 1997 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {YYERROR_NOW; yyerror ("Identifier expected"); RECOVER;; break;} case 363: ! #line 1999 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'(' expected"); RECOVER;; break;} case 364: ! #line 2009 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { create_anonymous_class (yyvsp[-4].operator.location, yyvsp[-3].node); ; break;} case 365: ! #line 2011 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree id = build_wfl_node (DECL_NAME (GET_CPC ())); EXPR_WFL_LINECOL (id) = EXPR_WFL_LINECOL (yyvsp[-5].node); *************** case 365: *** 4374,4384 **** ; break;} case 366: ! #line 2042 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { create_anonymous_class (yyvsp[-3].operator.location, yyvsp[-2].node); ; break;} case 367: ! #line 2044 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree id = build_wfl_node (DECL_NAME (GET_CPC ())); EXPR_WFL_LINECOL (id) = EXPR_WFL_LINECOL (yyvsp[-4].node); --- 4373,4383 ---- ; break;} case 366: ! #line 2042 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { create_anonymous_class (yyvsp[-3].operator.location, yyvsp[-2].node); ; break;} case 367: ! #line 2044 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree id = build_wfl_node (DECL_NAME (GET_CPC ())); EXPR_WFL_LINECOL (id) = EXPR_WFL_LINECOL (yyvsp[-4].node); *************** case 367: *** 4393,4441 **** ; break;} case 368: ! #line 2060 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = yyvsp[-2].node; ; break;} case 369: ! #line 2062 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = yyvsp[-2].node; ; break;} case 370: ! #line 2067 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = tree_cons (NULL_TREE, yyvsp[0].node, NULL_TREE); ctxp->formal_parameter_number = 1; ; break;} case 371: ! #line 2072 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { ctxp->formal_parameter_number += 1; yyval.node = tree_cons (NULL_TREE, yyvsp[0].node, yyvsp[-2].node); ; break;} case 372: ! #line 2077 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 373: ! #line 2082 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_newarray_node (yyvsp[-1].node, yyvsp[0].node, 0); ; break;} case 374: ! #line 2084 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_newarray_node (yyvsp[-1].node, yyvsp[0].node, 0); ; break;} case 375: ! #line 2086 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_newarray_node (yyvsp[-2].node, yyvsp[-1].node, pop_current_osb (ctxp));; break;} case 376: ! #line 2088 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_newarray_node (yyvsp[-2].node, yyvsp[-1].node, pop_current_osb (ctxp));; break;} case 377: ! #line 2092 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { char *sig; int osb = pop_current_osb (ctxp); --- 4392,4440 ---- ; break;} case 368: ! #line 2060 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = yyvsp[-2].node; ; break;} case 369: ! #line 2062 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = yyvsp[-2].node; ; break;} case 370: ! #line 2067 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = tree_cons (NULL_TREE, yyvsp[0].node, NULL_TREE); ctxp->formal_parameter_number = 1; ; break;} case 371: ! #line 2072 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { ctxp->formal_parameter_number += 1; yyval.node = tree_cons (NULL_TREE, yyvsp[0].node, yyvsp[-2].node); ; break;} case 372: ! #line 2077 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 373: ! #line 2082 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_newarray_node (yyvsp[-1].node, yyvsp[0].node, 0); ; break;} case 374: ! #line 2084 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_newarray_node (yyvsp[-1].node, yyvsp[0].node, 0); ; break;} case 375: ! #line 2086 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_newarray_node (yyvsp[-2].node, yyvsp[-1].node, pop_current_osb (ctxp));; break;} case 376: ! #line 2088 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_newarray_node (yyvsp[-2].node, yyvsp[-1].node, pop_current_osb (ctxp));; break;} case 377: ! #line 2092 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { char *sig; int osb = pop_current_osb (ctxp); *************** case 377: *** 4447,4453 **** ; break;} case 378: ! #line 2102 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { int osb = pop_current_osb (ctxp); tree type = yyvsp[-2].node; --- 4446,4452 ---- ; break;} case 378: ! #line 2102 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { int osb = pop_current_osb (ctxp); tree type = yyvsp[-2].node; *************** case 378: *** 4458,4480 **** ; break;} case 379: ! #line 2111 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("'[' expected"); DRECOVER ("]");; break;} case 380: ! #line 2113 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("']' expected"); RECOVER;; break;} case 381: ! #line 2118 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_tree_list (NULL_TREE, yyvsp[0].node); ; break;} case 382: ! #line 2120 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = tree_cons (NULL_TREE, yyvsp[0].node, yyval.node); ; break;} case 383: ! #line 2125 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { if (JNUMERIC_TYPE_P (TREE_TYPE (yyvsp[-1].node))) { --- 4457,4479 ---- ; break;} case 379: ! #line 2111 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("'[' expected"); DRECOVER ("]");; break;} case 380: ! #line 2113 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("']' expected"); RECOVER;; break;} case 381: ! #line 2118 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_tree_list (NULL_TREE, yyvsp[0].node); ; break;} case 382: ! #line 2120 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = tree_cons (NULL_TREE, yyvsp[0].node, yyval.node); ; break;} case 383: ! #line 2125 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { if (JNUMERIC_TYPE_P (TREE_TYPE (yyvsp[-1].node))) { *************** case 383: *** 4486,4496 **** ; break;} case 384: ! #line 2135 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("']' expected"); RECOVER;; break;} case 385: ! #line 2137 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("Missing term"); yyerror ("']' expected"); --- 4485,4495 ---- ; break;} case 384: ! #line 2135 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("']' expected"); RECOVER;; break;} case 385: ! #line 2137 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("Missing term"); yyerror ("']' expected"); *************** case 385: *** 4498,4504 **** ; break;} case 386: ! #line 2146 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { int allocate = 0; /* If not initialized, allocate memory for the osb --- 4497,4503 ---- ; break;} case 386: ! #line 2146 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { int allocate = 0; /* If not initialized, allocate memory for the osb *************** case 386: *** 4526,4544 **** ; break;} case 387: ! #line 2172 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { CURRENT_OSB (ctxp)++; ; break;} case 388: ! #line 2174 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("']' expected"); RECOVER;; break;} case 389: ! #line 2179 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = make_qualified_primary (yyvsp[-2].node, yyvsp[0].node, yyvsp[-1].operator.location); ; break;} case 390: ! #line 2183 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree super_wfl = build_wfl_node (super_identifier_node); EXPR_WFL_LINECOL (super_wfl) = yyvsp[-2].operator.location; --- 4525,4543 ---- ; break;} case 387: ! #line 2172 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { CURRENT_OSB (ctxp)++; ; break;} case 388: ! #line 2174 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("']' expected"); RECOVER;; break;} case 389: ! #line 2179 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = make_qualified_primary (yyvsp[-2].node, yyvsp[0].node, yyvsp[-1].operator.location); ; break;} case 390: ! #line 2183 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree super_wfl = build_wfl_node (super_identifier_node); EXPR_WFL_LINECOL (super_wfl) = yyvsp[-2].operator.location; *************** case 390: *** 4546,4564 **** ; break;} case 391: ! #line 2189 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Field expected"); DRECOVER (super_field_acces);; break;} case 392: ! #line 2194 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_method_invocation (yyvsp[-2].node, NULL_TREE); ; break;} case 393: ! #line 2196 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_method_invocation (yyvsp[-3].node, yyvsp[-1].node); ; break;} case 394: ! #line 2198 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { if (TREE_CODE (yyvsp[-4].node) == THIS_EXPR) yyval.node = build_this_super_qualified_invocation --- 4545,4563 ---- ; break;} case 391: ! #line 2189 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Field expected"); DRECOVER (super_field_acces);; break;} case 392: ! #line 2194 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_method_invocation (yyvsp[-2].node, NULL_TREE); ; break;} case 393: ! #line 2196 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_method_invocation (yyvsp[-3].node, yyvsp[-1].node); ; break;} case 394: ! #line 2198 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { if (TREE_CODE (yyvsp[-4].node) == THIS_EXPR) yyval.node = build_this_super_qualified_invocation *************** case 394: *** 4571,4577 **** ; break;} case 395: ! #line 2209 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { if (TREE_CODE (yyvsp[-5].node) == THIS_EXPR) yyval.node = build_this_super_qualified_invocation --- 4570,4576 ---- ; break;} case 395: ! #line 2209 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { if (TREE_CODE (yyvsp[-5].node) == THIS_EXPR) yyval.node = build_this_super_qualified_invocation *************** case 395: *** 4584,4704 **** ; break;} case 396: ! #line 2220 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_this_super_qualified_invocation (0, yyvsp[-2].node, NULL_TREE, yyvsp[-4].operator.location, yyvsp[-3].operator.location); ; break;} case 397: ! #line 2225 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_this_super_qualified_invocation (0, yyvsp[-3].node, yyvsp[-1].node, yyvsp[-5].operator.location, yyvsp[-4].operator.location); ; break;} case 398: ! #line 2234 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("'(' expected"); DRECOVER (method_invocation); ; break;} case 399: ! #line 2236 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("'(' expected"); DRECOVER (method_invocation); ; break;} case 400: ! #line 2241 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_array_ref (yyvsp[-2].operator.location, yyvsp[-3].node, yyvsp[-1].node); ; break;} case 401: ! #line 2243 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_array_ref (yyvsp[-2].operator.location, yyvsp[-3].node, yyvsp[-1].node); ; break;} case 402: ! #line 2245 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("Missing term and ']' expected"); DRECOVER(array_access); ; break;} case 403: ! #line 2250 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("']' expected"); DRECOVER(array_access); ; break;} case 404: ! #line 2255 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("Missing term and ']' expected"); DRECOVER(array_access); ; break;} case 405: ! #line 2260 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyerror ("']' expected"); DRECOVER(array_access); ; break;} case 410: ! #line 2275 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_incdec (yyvsp[0].operator.token, yyvsp[0].operator.location, yyvsp[-1].node, 1); ; break;} case 411: ! #line 2280 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_incdec (yyvsp[0].operator.token, yyvsp[0].operator.location, yyvsp[-1].node, 1); ; break;} case 414: ! #line 2287 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyval.node = build_unaryop (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[0].node); ; break;} case 415: ! #line 2289 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyval.node = build_unaryop (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[0].node); ; break;} case 417: ! #line 2292 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; break;} case 418: ! #line 2294 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; break;} case 419: ! #line 2299 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyval.node = build_incdec (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[0].node, 0); ; break;} case 420: ! #line 2301 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; break;} case 421: ! #line 2306 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyval.node = build_incdec (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[0].node, 0); ; break;} case 422: ! #line 2308 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; break;} case 424: ! #line 2314 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyval.node = build_unaryop (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[0].node); ; break;} case 425: ! #line 2316 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyval.node = build_unaryop (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[0].node); ; break;} case 427: ! #line 2319 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; break;} case 428: ! #line 2321 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; break;} case 429: ! #line 2326 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { tree type = yyvsp[-3].node; int osb = pop_current_osb (ctxp); --- 4583,4703 ---- ; break;} case 396: ! #line 2220 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_this_super_qualified_invocation (0, yyvsp[-2].node, NULL_TREE, yyvsp[-4].operator.location, yyvsp[-3].operator.location); ; break;} case 397: ! #line 2225 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_this_super_qualified_invocation (0, yyvsp[-3].node, yyvsp[-1].node, yyvsp[-5].operator.location, yyvsp[-4].operator.location); ; break;} case 398: ! #line 2234 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("'(' expected"); DRECOVER (method_invocation); ; break;} case 399: ! #line 2236 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("'(' expected"); DRECOVER (method_invocation); ; break;} case 400: ! #line 2241 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_array_ref (yyvsp[-2].operator.location, yyvsp[-3].node, yyvsp[-1].node); ; break;} case 401: ! #line 2243 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_array_ref (yyvsp[-2].operator.location, yyvsp[-3].node, yyvsp[-1].node); ; break;} case 402: ! #line 2245 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("Missing term and ']' expected"); DRECOVER(array_access); ; break;} case 403: ! #line 2250 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("']' expected"); DRECOVER(array_access); ; break;} case 404: ! #line 2255 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("Missing term and ']' expected"); DRECOVER(array_access); ; break;} case 405: ! #line 2260 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyerror ("']' expected"); DRECOVER(array_access); ; break;} case 410: ! #line 2275 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_incdec (yyvsp[0].operator.token, yyvsp[0].operator.location, yyvsp[-1].node, 1); ; break;} case 411: ! #line 2280 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_incdec (yyvsp[0].operator.token, yyvsp[0].operator.location, yyvsp[-1].node, 1); ; break;} case 414: ! #line 2287 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyval.node = build_unaryop (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[0].node); ; break;} case 415: ! #line 2289 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyval.node = build_unaryop (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[0].node); ; break;} case 417: ! #line 2292 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; break;} case 418: ! #line 2294 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; break;} case 419: ! #line 2299 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyval.node = build_incdec (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[0].node, 0); ; break;} case 420: ! #line 2301 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; break;} case 421: ! #line 2306 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyval.node = build_incdec (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[0].node, 0); ; break;} case 422: ! #line 2308 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; break;} case 424: ! #line 2314 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyval.node = build_unaryop (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[0].node); ; break;} case 425: ! #line 2316 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyval.node = build_unaryop (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[0].node); ; break;} case 427: ! #line 2319 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; break;} case 428: ! #line 2321 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER; break;} case 429: ! #line 2326 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { tree type = yyvsp[-3].node; int osb = pop_current_osb (ctxp); *************** case 429: *** 4708,4722 **** ; break;} case 430: ! #line 2334 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_cast (yyvsp[-3].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 431: ! #line 2336 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_cast (yyvsp[-3].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 432: ! #line 2338 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { const char *ptr; int osb = pop_current_osb (ctxp); --- 4707,4721 ---- ; break;} case 430: ! #line 2334 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_cast (yyvsp[-3].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 431: ! #line 2336 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_cast (yyvsp[-3].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 432: ! #line 2338 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { const char *ptr; int osb = pop_current_osb (ctxp); *************** case 432: *** 4731,4984 **** ; break;} case 433: ! #line 2351 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("']' expected, invalid type expression");; break;} case 434: ! #line 2353 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { YYNOT_TWICE yyerror ("Invalid type expression"); RECOVER; RECOVER; ; break;} case 435: ! #line 2358 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 436: ! #line 2360 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 437: ! #line 2362 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 439: ! #line 2368 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 440: ! #line 2373 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 441: ! #line 2378 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 442: ! #line 2383 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 443: ! #line 2385 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 444: ! #line 2387 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 446: ! #line 2393 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 447: ! #line 2398 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 448: ! #line 2403 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 449: ! #line 2405 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 451: ! #line 2411 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 452: ! #line 2416 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 453: ! #line 2421 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 454: ! #line 2426 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 455: ! #line 2428 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 456: ! #line 2430 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 458: ! #line 2436 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 459: ! #line 2441 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 460: ! #line 2446 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 461: ! #line 2451 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 462: ! #line 2456 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (INSTANCEOF_EXPR, yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 463: ! #line 2458 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 464: ! #line 2460 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 465: ! #line 2462 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 466: ! #line 2464 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 467: ! #line 2466 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Invalid reference type"); RECOVER;; break;} case 469: ! #line 2472 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 470: ! #line 2477 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 471: ! #line 2482 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 472: ! #line 2484 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 474: ! #line 2490 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 475: ! #line 2495 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 477: ! #line 2501 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 478: ! #line 2506 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 480: ! #line 2512 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 481: ! #line 2517 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 483: ! #line 2523 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 484: ! #line 2528 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 486: ! #line 2534 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 487: ! #line 2539 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 489: ! #line 2545 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build (CONDITIONAL_EXPR, NULL_TREE, yyvsp[-4].node, yyvsp[-2].node, yyvsp[0].node); EXPR_WFL_LINECOL (yyval.node) = yyvsp[-3].operator.location; ; break;} case 490: ! #line 2550 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { YYERROR_NOW; yyerror ("Missing term"); --- 4730,4983 ---- ; break;} case 433: ! #line 2351 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("']' expected, invalid type expression");; break;} case 434: ! #line 2353 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { YYNOT_TWICE yyerror ("Invalid type expression"); RECOVER; RECOVER; ; break;} case 435: ! #line 2358 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 436: ! #line 2360 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 437: ! #line 2362 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 439: ! #line 2368 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 440: ! #line 2373 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 441: ! #line 2378 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 442: ! #line 2383 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 443: ! #line 2385 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 444: ! #line 2387 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 446: ! #line 2393 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 447: ! #line 2398 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 448: ! #line 2403 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 449: ! #line 2405 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 451: ! #line 2411 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 452: ! #line 2416 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 453: ! #line 2421 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 454: ! #line 2426 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 455: ! #line 2428 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 456: ! #line 2430 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 458: ! #line 2436 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 459: ! #line 2441 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 460: ! #line 2446 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 461: ! #line 2451 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 462: ! #line 2456 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (INSTANCEOF_EXPR, yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 463: ! #line 2458 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 464: ! #line 2460 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 465: ! #line 2462 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 466: ! #line 2464 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 467: ! #line 2466 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Invalid reference type"); RECOVER;; break;} case 469: ! #line 2472 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 470: ! #line 2477 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 471: ! #line 2482 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 472: ! #line 2484 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 474: ! #line 2490 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 475: ! #line 2495 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 477: ! #line 2501 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 478: ! #line 2506 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 480: ! #line 2512 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 481: ! #line 2517 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 483: ! #line 2523 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 484: ! #line 2528 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 486: ! #line 2534 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_binop (BINOP_LOOKUP (yyvsp[-1].operator.token), yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 487: ! #line 2539 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); RECOVER;; break;} case 489: ! #line 2545 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build (CONDITIONAL_EXPR, NULL_TREE, yyvsp[-4].node, yyvsp[-2].node, yyvsp[0].node); EXPR_WFL_LINECOL (yyval.node) = yyvsp[-3].operator.location; ; break;} case 490: ! #line 2550 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { YYERROR_NOW; yyerror ("Missing term"); *************** case 490: *** 4986,5004 **** ; break;} case 491: ! #line 2556 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); DRECOVER (2);; break;} case 492: ! #line 2558 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" {yyerror ("Missing term"); DRECOVER (3);; break;} case 495: ! #line 2568 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { yyval.node = build_assignment (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 496: ! #line 2570 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" { YYNOT_TWICE yyerror ("Missing term"); DRECOVER (assign); --- 4985,5003 ---- ; break;} case 491: ! #line 2556 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); DRECOVER (2);; break;} case 492: ! #line 2558 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" {yyerror ("Missing term"); DRECOVER (3);; break;} case 495: ! #line 2568 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { yyval.node = build_assignment (yyvsp[-1].operator.token, yyvsp[-1].operator.location, yyvsp[-2].node, yyvsp[0].node); ; break;} case 496: ! #line 2570 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" { YYNOT_TWICE yyerror ("Missing term"); DRECOVER (assign); *************** case 496: *** 5006,5012 **** break;} } /* the action file gets copied in in place of this dollarsign */ ! #line 542 "/usr/lib/bison.simple" yyvsp -= yylen; yyssp -= yylen; --- 5005,5011 ---- break;} } /* the action file gets copied in in place of this dollarsign */ ! #line 543 "/usr/lib/bison.simple" yyvsp -= yylen; yyssp -= yylen; *************** yyerrhandle: *** 5226,5232 **** } return 1; } ! #line 2595 "/sourceware/snapshot-tmp/gcc-3.0.1-release/gcc-3.0.1/gcc-3.0.1/gcc/java/parse.y" /* Helper function to retrieve an OSB count. Should be used when the --- 5225,5231 ---- } return 1; } ! #line 2595 "/nfs/gandalf/u2/mitchell/gcc-3.0.2/gcc-3.0.2/gcc/java/parse.y" /* Helper function to retrieve an OSB count. Should be used when the diff -Nrc3pad gcc-3.0.1/gcc/listing gcc-3.0.2/gcc/listing *** gcc-3.0.1/gcc/listing Wed Dec 16 12:57:08 1998 --- gcc-3.0.2/gcc/listing Wed Dec 31 16:00:00 1969 *************** *** 1,227 **** - #!/bin/sh -f - # Generate a source code listing for C or C++ code with assembler code. The - # listing is always written to stdout. - # Author: Igor Metz - - # Revision 1.4 94/08/26 13:58:27 coxs - # lister now guesses how to should be configured. Added elf and coff support. - # - # Revision 1.3 89/12/18 13:58:27 metz - # lister must now be configured before it can be used. This is done in the - # /bin/sh part of the code. - # - # - # Revision 1.2 89/08/16 17:35:02 metz - # Support for SPARC added. - # - # Revision 1.1 89/08/16 16:49:22 metz - # Initial revision - # - - # Requires: gawk (may be it works also with nawk) - - # usage: lister filename [compiler-options] - - # Method: - # compile the source with -g option to assembler code, then merge the - # generated assembler code with the source code. Compiler options - # can be supplied on the command line (for example -O) - - # To install lister, assign one of the supported values to the variable MYSYS: - # mc68020 for Motorola 68020 (Sun-3, ..) - # mc68030 for Motorola 68030 (Sun-3, ..) - # sparc for SPARC (SUN-4, ..) - # i386 for i386 (Sun i386, ...) - # i386-gnu-linux for i386 (GNU/Linux, ...) - - # Guess what kind of objects we are creating and thus what type of assembler - # symbols to look for - - ex /tmp/$$.c </dev/null - a - main (){} - . - w - q - END - WD=`pwd` - cd /tmp - gcc -c $$.c - case "`file $$.o`" in - *ELF*) MYSYS=elf ;; - *COFF*|*BCS*) MYSYS=coff ;; - *mc68k*|*M68000*) MYSYS=mc68030 ;; - *SPARC*) MYSYS=sparc ;; - *386*) MYSYS=i386 ;; - esac - rm $$.c $$.o - cd $WD - - # uncomment the line you need if the above guesses incorrectly: - # MYSYS=mc68020 - # MYSYS=mc68030 - # MYSYS=sparc - # MYSYS=i386 - # MYSYS=i386-gnu-linux - # MYSYS=`mach` # this will work on Suns with SunOS > 4.0.0 - # MYSYS=elf - # MYSYS=coff - - WHOAMI=$0 - if [ $# -gt 0 ] ; then - FILENAME=$1 - shift - fi - - exec gawk -v whoami=$WHOAMI -vsys=$MYSYS -voptions="$*" ' - # commandline arguments: - # ARGV[0] = "gawk" - # ARGV[1] = processid - # ARGV[2] = filename - BEGIN { - if (ARGC != 3) { - usage() - exit 1 - } - - # Declaration of global variables - c_filename = "" - asm_filename = "" - cmdline = "" - asm_code = "" - c_code = "" - c_lineno = 0 - oldlineno = 0 - newlineno = 0 - ignore_stabd = 0 - num_of_fields = 0 - - # check processor architecture and set sourcecode line_hint accordingly - if (sys == "sparc" || sys == "i386") { - line_hint = "^[ \t]*\.stabn.*" - line_field = 3; - line_delimiter = ","; - line_offset = 0; - } - else if (sys == "mc68020" || sys == "mc68030" || sys == "i386-gnu-linux") { - line_hint = "^[ \t]*\.stabd.*" - line_field = 3; - line_delimiter = ","; - line_offset = 0; - } - else if (sys == "elf") { - line_hint = "section.*\.line" - line_field = 3; - line_delimiter = "\t"; - line_offset = 0; - } - else if (sys == "coff") { - line_hint = "^[ \t]*ln" - line_field = 3; - line_delimiter = "\t"; - } - else { - error("Processor type " sys " is not supported yet, sorry") - } - - parse_cmdline() - - printf("compiling %s to asm code\n", c_filename ) > "/dev/stderr" - - if (system(cmdline) != 0 ) { - error("Compilation of " c_filename " failed") - } - - printf("generating listing\n") > "/dev/stderr" - - - while ( getline asm_code < asm_filename > 0 ) { - if ( (ignore_stabd==0) && (asm_code ~ line_hint)) { - while ( sys == "elf" && (asm_code !~ "word" && asm_code !~ "byte") && - getline asm_code < asm_filename > 0); - # source line hint found. Split the line into fields separated by commas. - # num_of_fields is 4 for sparc, 3 for m68k - num_of_fields = split(asm_code, fields, line_delimiter) - newlineno = fields[line_field] + line_offset; - - if (newlineno > oldlineno) { - while ( newlineno > c_lineno && getline c_code < c_filename > 0) { - c_lineno++ - printf("%4d %s\n", c_lineno, c_code) - } - oldlineno = newlineno - } - } - else if ( asm_code ~ ".*Ltext[ \t]*$" ) { - # filename hint found - if ( match(asm_code, c_filename)) { - ignore_stabd = 0 - } - else { - ignore_stabd = 1 - } - } - else if ( sys == "elf" && asm_code ~ "section.*\.debug" ) { - while ( asm_code !~ "^[ \t]*[.]*previous" && - asm_code !~ "\.popsection" && - getline asm_code < asm_filename > 0 ); - if ( ! (getline asm_code < asm_filename > 0)) break; - } - else if ( sys == "coff" && asm_code ~ "^[ \t]*sdef" ) { - if ( asm_code ~ "\.bf" ) { - while ( asm_code !~ "^[ \t]*line" && - getline asm_code < asm_filename > 0 ) { - num_of_fields = split(asm_code, fields, "\t") - line_offset = fields[line_field] - 1; - } - } - while ( asm_code !~ "^[ \t]*endef" && - getline asm_code < asm_filename > 0 ) { - } - if ( ! (getline asm_code < asm_filename > 0)) break; - } - printf("\t\t\t%s\n", asm_code) - } - - # general cleanup - system("/bin/rm " asm_filename) - } - - function usage() { - printf("usage: %s filename compiler-options\n", whoami) > "/dev/stderr" - } - - function error(s) { - printf("error: %s\n", s) > "/dev/stderr" - exit 1 - } - - function parse_cmdline( i) { - # construct filenames to use - asm_filename = "/tmp/lister" ARGV[1] ".s" - ARGV[1] = "" - c_filename = ARGV[2] - ARGV[2] = "" - - # construct commandline to use - if ( match(c_filename, ".C") || match(c_filename, ".cc") ) { - cmdline = "g++" - } - else if (match(c_filename, ".c") || match(c_filename, ".i")) { - cmdline = "gcc" - } - else { - error("unknown extension for file " c_filename) - } - - cmdline = cmdline " -g -S -o " asm_filename - - # now we append the compiler options specified by the user - cmdline = cmdline " " options - - # last but not least: the name of the file to compile - cmdline = cmdline " " c_filename - } - - ' $$ $FILENAME - --- 0 ---- diff -Nrc3pad gcc-3.0.1/gcc/loop.c gcc-3.0.2/gcc/loop.c *** gcc-3.0.1/gcc/loop.c Tue Jun 12 19:46:54 2001 --- gcc-3.0.2/gcc/loop.c Tue Sep 4 22:54:42 2001 *************** express_from_1 (a, b, mult) *** 6336,6342 **** } else if (CONSTANT_P (a)) { ! return simplify_gen_binary (MINUS, GET_MODE (b) != VOIDmode ? GET_MODE (b) : GET_MODE (a), const0_rtx, a); } else if (GET_CODE (b) == PLUS) { --- 6336,6342 ---- } else if (CONSTANT_P (a)) { ! return simplify_gen_binary (MINUS, GET_MODE (b) != VOIDmode ? GET_MODE (b) : GET_MODE (a), b, a); } else if (GET_CODE (b) == PLUS) { diff -Nrc3pad gcc-3.0.1/gcc/objc/objc-parse.c gcc-3.0.2/gcc/objc/objc-parse.c *** gcc-3.0.1/gcc/objc/objc-parse.c Sun Aug 19 17:53:34 2001 --- gcc-3.0.2/gcc/objc/objc-parse.c Tue Oct 23 10:57:19 2001 *************** *** 1,7 **** /* A Bison parser, made from objc-parse.y ! by GNU Bison version 1.27 ! */ #define YYBISON 1 /* Identify Bison output. */ --- 1,6 ---- /* A Bison parser, made from objc-parse.y ! by GNU Bison version 1.28 */ #define YYBISON 1 /* Identify Bison output. */ *************** static const short yycheck[] = { 56, *** 1755,1761 **** }; /* -*-C-*- Note some compilers choke on comments on `#line' lines. */ #line 3 "/usr/lib/bison.simple" ! /* This file comes from bison-1.27. */ /* Skeleton output parser for bison, Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. --- 1754,1760 ---- }; /* -*-C-*- Note some compilers choke on comments on `#line' lines. */ #line 3 "/usr/lib/bison.simple" ! /* This file comes from bison-1.28. */ /* Skeleton output parser for bison, Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. *************** __yy_memcpy (char *to, char *from, unsig *** 1968,1974 **** #endif #endif ! #line 216 "/usr/lib/bison.simple" /* The user can define YYPARSE_PARAM as the name of an argument to be passed into yyparse. The argument should have type void *. --- 1967,1973 ---- #endif #endif ! #line 217 "/usr/lib/bison.simple" /* The user can define YYPARSE_PARAM as the name of an argument to be passed into yyparse. The argument should have type void *. *************** case 588: *** 4799,4805 **** break;} } /* the action file gets copied in in place of this dollarsign */ ! #line 542 "/usr/lib/bison.simple" yyvsp -= yylen; yyssp -= yylen; --- 4798,4804 ---- break;} } /* the action file gets copied in in place of this dollarsign */ ! #line 543 "/usr/lib/bison.simple" yyvsp -= yylen; yyssp -= yylen; diff -Nrc3pad gcc-3.0.1/gcc/po/ChangeLog gcc-3.0.2/gcc/po/ChangeLog *** gcc-3.0.1/gcc/po/ChangeLog Sun Aug 19 14:08:21 2001 --- gcc-3.0.2/gcc/po/ChangeLog Tue Oct 23 10:20:00 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/gcc/regmove.c gcc-3.0.2/gcc/regmove.c *** gcc-3.0.1/gcc/regmove.c Mon Aug 13 00:05:59 2001 --- gcc-3.0.2/gcc/regmove.c Tue Sep 18 11:23:37 2001 *************** optimize_reg_copy_3 (insn, dest, src) *** 702,707 **** --- 702,710 ---- if (! (set = single_set (p)) || GET_CODE (SET_SRC (set)) != MEM + /* If there's a REG_EQUIV note, this must be an insn that loads an + argument. Prefer keeping the note over doing this optimization. */ + || find_reg_note (p, REG_EQUIV, NULL_RTX) || SET_DEST (set) != src_reg) return; *************** optimize_reg_copy_3 (insn, dest, src) *** 745,750 **** --- 748,759 ---- /* One or more changes were no good. Back out everything. */ PUT_MODE (src_reg, old_mode); XEXP (src, 0) = src_reg; + } + else + { + rtx note = find_reg_note (p, REG_EQUAL, NULL_RTX); + if (note) + remove_note (p, note); } } diff -Nrc3pad gcc-3.0.1/gcc/regrename.c gcc-3.0.2/gcc/regrename.c *** gcc-3.0.1/gcc/regrename.c Sun Jul 22 00:09:45 2001 --- gcc-3.0.2/gcc/regrename.c Sat Sep 29 14:51:19 2001 *************** note_sets (x, set, data) *** 112,117 **** --- 112,122 ---- return; regno = REGNO (x); nregs = HARD_REGNO_NREGS (regno, GET_MODE (x)); + + /* There must not be pseudos at this point. */ + if (regno + nregs > FIRST_PSEUDO_REGISTER) + abort (); + while (nregs-- > 0) SET_HARD_REG_BIT (*pset, regno + nregs); } *************** clear_dead_regs (pset, kind, notes) *** 132,137 **** --- 137,147 ---- rtx reg = XEXP (note, 0); unsigned int regno = REGNO (reg); int nregs = HARD_REGNO_NREGS (regno, GET_MODE (reg)); + + /* There must not be pseudos at this point. */ + if (regno + nregs > FIRST_PSEUDO_REGISTER) + abort (); + while (nregs-- > 0) CLEAR_HARD_REG_BIT (*pset, regno + nregs); } diff -Nrc3pad gcc-3.0.1/gcc/reload.c gcc-3.0.2/gcc/reload.c *** gcc-3.0.1/gcc/reload.c Mon Jul 23 15:41:47 2001 --- gcc-3.0.2/gcc/reload.c Sat Sep 29 14:51:19 2001 *************** find_reloads (insn, replace, ind_levels, *** 3770,3776 **** if (GET_CODE (operand) == REG) { if (modified[i] != RELOAD_WRITE) ! emit_insn_before (gen_rtx_USE (VOIDmode, operand), insn); if (modified[i] != RELOAD_READ) emit_insn_after (gen_rtx_CLOBBER (VOIDmode, operand), insn); } --- 3770,3780 ---- if (GET_CODE (operand) == REG) { if (modified[i] != RELOAD_WRITE) ! /* We mark the USE with QImode so that we recognize ! it as one that can be safely deleted at the end ! of reload. */ ! PUT_MODE (emit_insn_before (gen_rtx_USE (VOIDmode, operand), ! insn), QImode); if (modified[i] != RELOAD_READ) emit_insn_after (gen_rtx_CLOBBER (VOIDmode, operand), insn); } *************** find_reloads_toplev (x, opnum, type, ind *** 4256,4262 **** this substitution. We have to emit a USE of the pseudo so that delete_output_reload can see it. */ if (replace_reloads && recog_data.operand[opnum] != x) ! emit_insn_before (gen_rtx_USE (VOIDmode, x), insn); x = mem; i = find_reloads_address (GET_MODE (x), &x, XEXP (x, 0), &XEXP (x, 0), opnum, type, ind_levels, insn); --- 4260,4270 ---- this substitution. We have to emit a USE of the pseudo so that delete_output_reload can see it. */ if (replace_reloads && recog_data.operand[opnum] != x) ! /* We mark the USE with QImode so that we recognize it ! as one that can be safely deleted at the end of ! reload. */ ! PUT_MODE (emit_insn_before (gen_rtx_USE (VOIDmode, x), insn), ! QImode); x = mem; i = find_reloads_address (GET_MODE (x), &x, XEXP (x, 0), &XEXP (x, 0), opnum, type, ind_levels, insn); *************** find_reloads_address (mode, memrefloc, a *** 4529,4535 **** && ! rtx_equal_p (tem, reg_equiv_mem[regno])) { *loc = tem; ! emit_insn_before (gen_rtx_USE (VOIDmode, ad), insn); /* This doesn't really count as replacing the address as a whole, since it is still a memory access. */ } --- 4537,4548 ---- && ! rtx_equal_p (tem, reg_equiv_mem[regno])) { *loc = tem; ! /* We mark the USE with QImode so that we ! recognize it as one that can be safely ! deleted at the end of reload. */ ! PUT_MODE (emit_insn_before (gen_rtx_USE (VOIDmode, ad), ! insn), QImode); ! /* This doesn't really count as replacing the address as a whole, since it is still a memory access. */ } *************** subst_reg_equivs (ad, insn) *** 4860,4866 **** if (! rtx_equal_p (mem, reg_equiv_mem[regno])) { subst_reg_equivs_changed = 1; ! emit_insn_before (gen_rtx_USE (VOIDmode, ad), insn); return mem; } } --- 4873,4883 ---- if (! rtx_equal_p (mem, reg_equiv_mem[regno])) { subst_reg_equivs_changed = 1; ! /* We mark the USE with QImode so that we recognize it ! as one that can be safely deleted at the end of ! reload. */ ! PUT_MODE (emit_insn_before (gen_rtx_USE (VOIDmode, ad), insn), ! QImode); return mem; } } *************** find_reloads_subreg_address (x, force_re *** 5687,5693 **** this substitution. We have to emit a USE of the pseudo so that delete_output_reload can see it. */ if (replace_reloads && recog_data.operand[opnum] != x) ! emit_insn_before (gen_rtx_USE (VOIDmode, SUBREG_REG (x)), insn); x = tem; } } --- 5704,5715 ---- this substitution. We have to emit a USE of the pseudo so that delete_output_reload can see it. */ if (replace_reloads && recog_data.operand[opnum] != x) ! /* We mark the USE with QImode so that we recognize it ! as one that can be safely deleted at the end of ! reload. */ ! PUT_MODE (emit_insn_before (gen_rtx_USE (VOIDmode, ! SUBREG_REG (x)), ! insn), QImode); x = tem; } } diff -Nrc3pad gcc-3.0.1/gcc/reload1.c gcc-3.0.2/gcc/reload1.c *** gcc-3.0.1/gcc/reload1.c Tue Jun 5 20:31:21 2001 --- gcc-3.0.2/gcc/reload1.c Sat Sep 29 14:51:19 2001 *************** reload (first, global) *** 760,765 **** --- 760,772 ---- { rtx set = single_set (insn); + /* We may introduce USEs that we want to remove at the end, so + we'll mark them with QImode. Make sure there are no + previously-marked insns left by say regmove. */ + if (INSN_P (insn) && GET_CODE (PATTERN (insn)) == USE + && GET_MODE (insn) != VOIDmode) + PUT_MODE (insn, VOIDmode); + if (GET_CODE (insn) == NOTE && CONST_CALL_P (insn) && NOTE_LINE_NUMBER (insn) == NOTE_INSN_SETJMP) for (i = 0; i < FIRST_PSEUDO_REGISTER; i++) *************** reload (first, global) *** 1187,1193 **** CALL_INSN_FUNCTION_USAGE (insn)); if ((GET_CODE (PATTERN (insn)) == USE ! && find_reg_note (insn, REG_EQUAL, NULL_RTX)) || (GET_CODE (PATTERN (insn)) == CLOBBER && (GET_CODE (XEXP (PATTERN (insn), 0)) != REG || ! REG_FUNCTION_VALUE_P (XEXP (PATTERN (insn), 0))))) --- 1194,1202 ---- CALL_INSN_FUNCTION_USAGE (insn)); if ((GET_CODE (PATTERN (insn)) == USE ! /* We mark with QImode USEs introduced by reload itself. */ ! && (GET_MODE (insn) == QImode ! || find_reg_note (insn, REG_EQUAL, NULL_RTX))) || (GET_CODE (PATTERN (insn)) == CLOBBER && (GET_CODE (XEXP (PATTERN (insn), 0)) != REG || ! REG_FUNCTION_VALUE_P (XEXP (PATTERN (insn), 0))))) *************** reload_combine_note_use (xp, insn) *** 8968,8974 **** case CLOBBER: if (GET_CODE (SET_DEST (x)) == REG) ! return; break; case PLUS: --- 8977,8988 ---- case CLOBBER: if (GET_CODE (SET_DEST (x)) == REG) ! { ! /* No spurious CLOBBERs of pseudo registers may remain. */ ! if (REGNO (SET_DEST (x)) >= FIRST_PSEUDO_REGISTER) ! abort (); ! return; ! } break; case PLUS: *************** reload_combine_note_use (xp, insn) *** 8985,8994 **** int use_index; int nregs; ! /* Some spurious USEs of pseudo registers might remain. ! Just ignore them. */ if (regno >= FIRST_PSEUDO_REGISTER) ! return; nregs = HARD_REGNO_NREGS (regno, GET_MODE (x)); --- 8999,9007 ---- int use_index; int nregs; ! /* No spurious USEs of pseudo registers may remain. */ if (regno >= FIRST_PSEUDO_REGISTER) ! abort (); nregs = HARD_REGNO_NREGS (regno, GET_MODE (x)); diff -Nrc3pad gcc-3.0.1/gcc/rtl.h gcc-3.0.2/gcc/rtl.h *** gcc-3.0.1/gcc/rtl.h Sun May 13 14:36:15 2001 --- gcc-3.0.2/gcc/rtl.h Fri Sep 7 16:28:52 2001 *************** extern void fancy_abort PARAMS ((const c *** 1996,2001 **** --- 1996,2002 ---- #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__) /* In alias.c */ + extern void clear_reg_alias_info PARAMS ((rtx)); extern rtx canon_rtx PARAMS ((rtx)); extern int true_dependence PARAMS ((rtx, enum machine_mode, rtx, int (*)(rtx, int))); diff -Nrc3pad gcc-3.0.1/gcc/sibcall.c gcc-3.0.2/gcc/sibcall.c *** gcc-3.0.1/gcc/sibcall.c Mon Jun 4 13:25:58 2001 --- gcc-3.0.2/gcc/sibcall.c Mon Oct 8 13:15:51 2001 *************** success: *** 663,674 **** we actually write into. */ for (insn = get_insns (); insn; insn = NEXT_INSN (insn)) { ! if (GET_CODE (insn) == NOTE) ! { ! if (NOTE_LINE_NUMBER (insn) == NOTE_INSN_FUNCTION_BEG) ! break; ! } ! else if (INSN_P (insn)) purge_mem_unchanging_flag (PATTERN (insn)); } } --- 663,669 ---- we actually write into. */ for (insn = get_insns (); insn; insn = NEXT_INSN (insn)) { ! if (INSN_P (insn)) purge_mem_unchanging_flag (PATTERN (insn)); } } diff -Nrc3pad gcc-3.0.1/gcc/stor-layout.c gcc-3.0.2/gcc/stor-layout.c *** gcc-3.0.1/gcc/stor-layout.c Tue Feb 6 05:04:43 2001 --- gcc-3.0.2/gcc/stor-layout.c Tue Sep 4 22:54:42 2001 *************** layout_type (type) *** 1408,1413 **** --- 1408,1414 ---- #else TYPE_ALIGN (type) = MAX (TYPE_ALIGN (element), BITS_PER_UNIT); #endif + TYPE_USER_ALIGN (type) = TYPE_USER_ALIGN (element); #ifdef ROUND_TYPE_SIZE if (TYPE_SIZE (type) != 0) diff -Nrc3pad gcc-3.0.1/gcc/testsuite/ChangeLog gcc-3.0.2/gcc/testsuite/ChangeLog *** gcc-3.0.1/gcc/testsuite/ChangeLog Sun Aug 19 14:08:22 2001 --- gcc-3.0.2/gcc/testsuite/ChangeLog Tue Oct 23 10:20:08 2001 *************** *** 1,3 **** --- 1,50 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + + 2001-10-10 Franz Sirl + + * gcc.c-torture/compile/20011010-1.c: New. + + 2001-10-08 Franz Sirl + + * gcc.c-torture/execute/20011008-3.c: New. + + 2001-09-21 Richard Henderson + + * g++.old-deja/g++.abi/ptrmem.C: Update for ia64 c++ abi. + * g++.old-deja/g++.abi/vtable2.C: Likewise. + + 2001-09-12 Jakub Jelinek + + * gcc.c-torture/execute/20010403-1.c: New test. + * gcc.dg/20010912-1.c: New test. + + 2001-09-06 Nathan Sidwell + + PR c++/3986 + * g++.old-deja/g++.abi/vbase9.C: New test. + + 2001-09-05 Jakub Jelinek + + * gcc.c-torture/compile/20010903-1.c: New test. + * gcc.c-torture/execute/20010904-1.c: New test. + * gcc.c-torture/execute/20010904-2.c: New test. + + 2001-09-04 Nathan Sidwell + + PR c++/4203 + * g++.old-deja/g++.other/empty1.C: XFAIL. See PR c++/4222 + * g++.old-deja/g++.other/empty3.C: New test. + + 2001-08-29 Kazu Hirata + + * gcc.c-torture/compile/981006-1.x: Do not use -fpic on h8300. + + 2001-08-23 Kriang Lerdsuwanakij + + * g++.dg/unify1.C: New test. + 2001-08-19 Release Manager * GCC 3.0.1 Released. *************** Mon Jul 16 12:21:56 2001 Nicola Pero < *** 118,124 **** 2000-09-10 Michael Chamberlain ! * gcc.misc-tests/mg.exp (compiler_output): Support tcl 8.3.1. 2001-06-29 Rainer Orth --- 165,171 ---- 2000-09-10 Michael Chamberlain ! * gcc.misc-tests/mg.exp (compiler_output): Support tcl 8.3.1. 2001-06-29 Rainer Orth *************** Mon Jul 16 12:21:56 2001 Nicola Pero < *** 136,142 **** 20010617 Release Manager ! * GCC 3.0 Released. 2001-06-14 Nathan Sidwell --- 183,189 ---- 20010617 Release Manager ! * GCC 3.0 Released. 2001-06-14 Nathan Sidwell *************** Thu Apr 26 11:13:27 2001 Jeffrey A Law *** 767,775 **** 2001-03-06 Zack Weinberg ! * objc/execute/string1.m, objc/execute/string2.m: Compare the ! result of -cString against what we expect it to be; don't just ! print it out for no one to read. * objc/execute/string3.m, objc/execute/string4.m: New tests. Based on testcases provided by Nicola Pero. --- 814,822 ---- 2001-03-06 Zack Weinberg ! * objc/execute/string1.m, objc/execute/string2.m: Compare the ! result of -cString against what we expect it to be; don't just ! print it out for no one to read. * objc/execute/string3.m, objc/execute/string4.m: New tests. Based on testcases provided by Nicola Pero. *************** Thu Apr 26 11:13:27 2001 Jeffrey A Law *** 816,822 **** 2001-02-28 Geoffrey Keating ! * g++.dg/vtgc1.C: Update for new ABI. 2001-02-27 Nathan Sidwell --- 863,869 ---- 2001-02-28 Geoffrey Keating ! * g++.dg/vtgc1.C: Update for new ABI. 2001-02-27 Nathan Sidwell *************** Wed Feb 7 09:54:47 2001 Ovidiu Predesc *** 933,939 **** 2001-02-06 Neil Booth ! * gcc.dg/cpp/avoidpaste1.c: Update. Tue Feb 5 8:53:33 2001 Ovidiu Predescu --- 980,986 ---- 2001-02-06 Neil Booth ! * gcc.dg/cpp/avoidpaste1.c: Update. Tue Feb 5 8:53:33 2001 Ovidiu Predescu *************** Tue Feb 5 8:53:33 2001 Ovidiu Predescu *** 975,981 **** 2001-02-01 Neil Booth ! * gcc.dg/cpp/avoidpaste2.c: New tests. 2001-01-31 Jakub Jelinek --- 1022,1028 ---- 2001-02-01 Neil Booth ! * gcc.dg/cpp/avoidpaste2.c: New tests. 2001-01-31 Jakub Jelinek *************** Wed Jan 31 12:23:32 2001 J"orn Rennecke *** 996,1007 **** 2001-01-31 Neil Booth ! * gcc.dg/cpp/tr-warn1.c: Add tests. 2001-01-31 Neil Booth ! * gcc.dg/cpp/avoidpaste1.c: Update. ! * gcc.dg/cpp/paste4.c: Update. 2001-01-30 Jeffrey Oldham --- 1043,1054 ---- 2001-01-31 Neil Booth ! * gcc.dg/cpp/tr-warn1.c: Add tests. 2001-01-31 Neil Booth ! * gcc.dg/cpp/avoidpaste1.c: Update. ! * gcc.dg/cpp/paste4.c: Update. 2001-01-30 Jeffrey Oldham *************** Wed Jan 31 12:23:32 2001 J"orn Rennecke *** 1027,1033 **** 2001-01-28 Neil Booth ! * gcc.dg/cpp/avoidpaste1.c: Test case. 2001-01-28 Jakub Jelinek --- 1074,1080 ---- 2001-01-28 Neil Booth ! * gcc.dg/cpp/avoidpaste1.c: Test case. 2001-01-28 Jakub Jelinek *************** Wed Jan 31 12:23:32 2001 J"orn Rennecke *** 1143,1149 **** 2001-01-18 Neil Booth ! * gcc.dg/cpp/assembl2.S: New test case. 2001-01-17 Jeffrey Oldham --- 1190,1196 ---- 2001-01-18 Neil Booth ! * gcc.dg/cpp/assembl2.S: New test case. 2001-01-17 Jeffrey Oldham *************** Wed Jan 31 12:23:32 2001 J"orn Rennecke *** 1183,1190 **** 2001-01-15 Neil Booth ! * gcc.dg/cpp/if-2.c: Comment out occasionally bogus test; we ! have an equivalent working one below it. 2001-01-14 Jeffrey Oldham --- 1230,1237 ---- 2001-01-15 Neil Booth ! * gcc.dg/cpp/if-2.c: Comment out occasionally bogus test; we ! have an equivalent working one below it. 2001-01-14 Jeffrey Oldham *************** Wed Jan 31 12:23:32 2001 J"orn Rennecke *** 1227,1234 **** 2001-01-13 Neil Booth ! * gcc.dg/cpp/widestr1.c: Update. ! * gcc.dg/cpp/prag-imp.c: Remove. 2001-01-12 Jakub Jelinek --- 1274,1281 ---- 2001-01-13 Neil Booth ! * gcc.dg/cpp/widestr1.c: Update. ! * gcc.dg/cpp/prag-imp.c: Remove. 2001-01-12 Jakub Jelinek *************** Wed Jan 31 12:23:32 2001 J"orn Rennecke *** 1291,1299 **** 2001-01-08 Jonathan Larmour * gcc.dg/20000419-2.c: Move to "special" subdirectory. ! * gcc.dg/special/20000419-2.c: New file. Identical to above. ! * gcc.dg/special/special.exp: New test driver which will check ! for alias support for the above test. 2001-01-09 Alan Lehotsky --- 1338,1346 ---- 2001-01-08 Jonathan Larmour * gcc.dg/20000419-2.c: Move to "special" subdirectory. ! * gcc.dg/special/20000419-2.c: New file. Identical to above. ! * gcc.dg/special/special.exp: New test driver which will check ! for alias support for the above test. 2001-01-09 Alan Lehotsky *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 1619,1630 **** 2000-12-17 Neil Booth ! * gcc.dg/cpp/multiline.c: New test. 2000-12-17 Neil Booth ! * g++.old-deja/g++.other/syshdr1.C: Update. ! * gcc.dg/cpp/lineflags.c: Remove temporarily. 2000-12-15 Kriang Lerdsuwanakij --- 1666,1677 ---- 2000-12-17 Neil Booth ! * gcc.dg/cpp/multiline.c: New test. 2000-12-17 Neil Booth ! * g++.old-deja/g++.other/syshdr1.C: Update. ! * gcc.dg/cpp/lineflags.c: Remove temporarily. 2000-12-15 Kriang Lerdsuwanakij *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 1672,1678 **** 2000-12-11 Neil Booth ! * gcc.dg/cpp/if-2.c: Separate tests so that which failed is obvious. 2000-12-09 Joseph S. Myers --- 1719,1725 ---- 2000-12-11 Neil Booth ! * gcc.dg/cpp/if-2.c: Separate tests so that which failed is obvious. 2000-12-09 Joseph S. Myers *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 1680,1689 **** 2000-12-09 Neil Booth ! * gcc.dg/cpp/lineflags.c: New tests. ! * gcc.dg/cpp/poison.c: Update. ! * gcc.dg/cpp/redef2.c: Update. ! * gcc.dg/cpp/skipping.c: New test. 2000-12-07 Geoffrey Keating --- 1727,1736 ---- 2000-12-09 Neil Booth ! * gcc.dg/cpp/lineflags.c: New tests. ! * gcc.dg/cpp/poison.c: Update. ! * gcc.dg/cpp/redef2.c: Update. ! * gcc.dg/cpp/skipping.c: New test. 2000-12-07 Geoffrey Keating *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 1691,1702 **** 2000-12-07 Neil Booth ! * gcc.dg/wtr-aggr-init-1.c, wtr-escape-1.c, wtr-int-type-1.c, ! wtr-label-1.c, wtr-static-1.c, wtr-strcat-1.c, wtr-suffix-1.c, ! wtr-switch-1.c, wtr-unary-plus-1.c, wtr-union-init-1.c ! wtr-union-init-2.c, wtr-union-init-3.c: Update. ! * gcc.dg/cpp/extratokens.c, tr-warn4.c, tr-warn5.c, tr-warn6.c: ! Update. 2000-12-07 Joseph S. Myers --- 1738,1749 ---- 2000-12-07 Neil Booth ! * gcc.dg/wtr-aggr-init-1.c, wtr-escape-1.c, wtr-int-type-1.c, ! wtr-label-1.c, wtr-static-1.c, wtr-strcat-1.c, wtr-suffix-1.c, ! wtr-switch-1.c, wtr-unary-plus-1.c, wtr-union-init-1.c ! wtr-union-init-2.c, wtr-union-init-3.c: Update. ! * gcc.dg/cpp/extratokens.c, tr-warn4.c, tr-warn5.c, tr-warn6.c: ! Update. 2000-12-07 Joseph S. Myers *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 1771,1778 **** 2000-12-04 Neil Booth ! * gcc.dg/cpp/assert_trad1.c, assert_trad2.c, assert_trad3.c: ! New tests. 2000-12-03 Kaveh R. Ghazi --- 1818,1825 ---- 2000-12-04 Neil Booth ! * gcc.dg/cpp/assert_trad1.c, assert_trad2.c, assert_trad3.c: ! New tests. 2000-12-03 Kaveh R. Ghazi *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 1785,1791 **** 2000-12-03 Neil Booth ! * gcc.dg/cpp/macro6.c: New test cases. 2000-12-02 Kaveh R. Ghazi --- 1832,1838 ---- 2000-12-03 Neil Booth ! * gcc.dg/cpp/macro6.c: New test cases. 2000-12-02 Kaveh R. Ghazi *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 1805,1823 **** 2000-12-02 Neil Booth ! * g++.old-deja/g++.other/externC4.C, ! g++.old-deja/g++.other/friend10.C: New tests. 2000-12-02 Neil Booth ! * g++.old-deja/g++.other/instan2.C ! * g++.old-deja/g++.other/instan3.C: New test. 2000-12-02 Neil Booth ! * gcc.dg/cpp/c++98.c,c++98-pedantic.c,c89.c,c89-pedantic.c, ! c94.c,c94-pedantic.c,c99.c,c99-pedantic.c,gnuc89.c,gnuc89-pedantic.c, ! gnuc99.c,gnuc99-pedantic.c: New tests. 2000-12-01 Joseph S. Myers --- 1852,1870 ---- 2000-12-02 Neil Booth ! * g++.old-deja/g++.other/externC4.C, ! g++.old-deja/g++.other/friend10.C: New tests. 2000-12-02 Neil Booth ! * g++.old-deja/g++.other/instan2.C ! * g++.old-deja/g++.other/instan3.C: New test. 2000-12-02 Neil Booth ! * gcc.dg/cpp/c++98.c,c++98-pedantic.c,c89.c,c89-pedantic.c, ! c94.c,c94-pedantic.c,c99.c,c99-pedantic.c,gnuc89.c,gnuc89-pedantic.c, ! gnuc99.c,gnuc99-pedantic.c: New tests. 2000-12-01 Joseph S. Myers *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 1826,1834 **** 2000-12-01 Neil Booth ! * gcc.dg/cpp/20000720-1.S: Remove duplicate testcase. ! * gcc.dg/cpp/poison.c: Update. ! * gcc.dg/cpp/spacing1.c: New testcase for all spacing issues. 2000-12-01 Toon Moene --- 1873,1881 ---- 2000-12-01 Neil Booth ! * gcc.dg/cpp/20000720-1.S: Remove duplicate testcase. ! * gcc.dg/cpp/poison.c: Update. ! * gcc.dg/cpp/spacing1.c: New testcase for all spacing issues. 2000-12-01 Toon Moene *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 1984,1990 **** 2000-11-22 Loren J. Rittle ! * g++.old-deja/g++.robertl/eb39.C: Don't include libio.h. 2000-11-22 Jakub Jelinek --- 2031,2037 ---- 2000-11-22 Loren J. Rittle ! * g++.old-deja/g++.robertl/eb39.C: Don't include libio.h. 2000-11-22 Jakub Jelinek *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 2004,2010 **** 2000-11-21 Neil Booth ! * gcc.dg/cpp/integrated1.c: Remove. 2000-11-21 Jakub Jelinek --- 2051,2057 ---- 2000-11-21 Neil Booth ! * gcc.dg/cpp/integrated1.c: Remove. 2000-11-21 Jakub Jelinek *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 2030,2037 **** 2000-11-20 Neil Booth ! * gcc.dg/cpp/paste2.c: Update test. ! * objc/execute/paste.m: New test. 2000-11-20 Joseph S. Myers --- 2077,2084 ---- 2000-11-20 Neil Booth ! * gcc.dg/cpp/paste2.c: Update test. ! * objc/execute/paste.m: New test. 2000-11-20 Joseph S. Myers *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 2110,2117 **** 2000-11-15 Neil Booth ! gcc.dg/cpp/_Pragma1.c: Update. ! gcc.dg/cpp/_Pragma2.c: New test. 2000-11-15 Nathan Sidwell --- 2157,2164 ---- 2000-11-15 Neil Booth ! gcc.dg/cpp/_Pragma1.c: Update. ! gcc.dg/cpp/_Pragma2.c: New test. 2000-11-15 Nathan Sidwell *************** Thu Dec 21 22:43:03 2000 J"orn Rennecke *** 2295,2301 **** 2000-11-04 Neil Booth ! * gcc.dg/cpp/include2.c: New tests. Fri Nov 3 13:32:14 2000 Mark P Mitchell --- 2342,2348 ---- 2000-11-04 Neil Booth ! * gcc.dg/cpp/include2.c: New tests. Fri Nov 3 13:32:14 2000 Mark P Mitchell *************** Fri Nov 3 13:32:14 2000 Mark P Mitchel *** 2349,2355 **** 2000-10-29 Neil Booth ! * gcc.dg/cpp/macro4.c, macro5.c: New tests. * mi1.c, mi1c.h: Add null directives to multiple-include test. * mi5.c: Test multiple includes work with -C. * trigraphs.c: Test ^= version. --- 2396,2402 ---- 2000-10-29 Neil Booth ! * gcc.dg/cpp/macro4.c, macro5.c: New tests. * mi1.c, mi1c.h: Add null directives to multiple-include test. * mi5.c: Test multiple includes work with -C. * trigraphs.c: Test ^= version. *************** Mon Oct 9 23:32:06 MET DST 2000 Jan Hu *** 2598,2604 **** 2000-09-26 Jakub Jelinek ! * gcc.c-torture/compile/20000923-1.c: New test. 2000-09-25 Theodore Papadopoulo --- 2645,2651 ---- 2000-09-26 Jakub Jelinek ! * gcc.c-torture/compile/20000923-1.c: New test. 2000-09-25 Theodore Papadopoulo *************** Tue Sep 12 18:32:07 2000 J"orn Rennecke *** 2730,2736 **** 2000-09-07 Catherine Moore ! * gcc.c-torture/execute/unroll-1.c: New test. 2000-09-06 Zack Weinberg --- 2777,2783 ---- 2000-09-07 Catherine Moore ! * gcc.c-torture/execute/unroll-1.c: New test. 2000-09-06 Zack Weinberg diff -Nrc3pad gcc-3.0.1/gcc/testsuite/g++.dg/unify1.C gcc-3.0.2/gcc/testsuite/g++.dg/unify1.C *** gcc-3.0.1/gcc/testsuite/g++.dg/unify1.C Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/g++.dg/unify1.C Thu Aug 23 06:50:37 2001 *************** *** 0 **** --- 1,26 ---- + // Test non-type template argument folding. + // Origin: smacdonald@seimac.com + + // { dg-do compile } + + template < int I1, int I2 > + class unit + { + public: + unit() {} + unit( const unit& ) {} + + template< int Q1, int Q2 > + unit< I1 - Q1, I2 - Q2 > operator / ( const unit< Q1, Q2 >& rhs ) const { + return unit< I1 - Q1, I2 - Q2 >(); + } + + }; + + int main() + { + const unit<1,0> u1; + const unit<2,0> u2; + + unit<-1,0> u3( u1 / u2 ); + } diff -Nrc3pad gcc-3.0.1/gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C gcc-3.0.2/gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C *** gcc-3.0.1/gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C Sun Jun 10 14:46:21 2001 --- gcc-3.0.2/gcc/testsuite/g++.old-deja/g++.abi/ptrmem.C Fri Sep 21 18:33:29 2001 *************** *** 14,19 **** --- 14,29 ---- #define ADJUST_DELTA(delta, virt) (delta) #endif + /* IA64 uses function descriptors instead of function pointers in its + vtables, which means that we can't meaningfully compare them directly. */ + #if defined __ia64__ + #define CMP_PTRFN(A, B) (*(void **)(A) == *(void **)(B)) + #define VPTE_SIZE (16) + #else + #define CMP_PTRFN(A, B) ((A) == (B)) + #define VPTE_SIZE sizeof(void *) + #endif + #if defined (__GXX_ABI_VERSION) && __GXX_ABI_VERSION >= 100 // Check that pointers-to-member functions are represented correctly. *************** main () *** 85,96 **** // There should be no adjustment for the `T' version, and an // appropriate adjustment for the `S' version. y = &T::f; ! if (yp->ptr != ADJUST_PTRFN (&_ZN1T1fEv, 0)) return 5; if (yp->adj != ADJUST_DELTA (0, 0)) return 6; x = (sp) y; ! if (xp->ptr != ADJUST_PTRFN (&_ZN1T1fEv, 0)) return 7; if (xp->adj != ADJUST_DELTA (delta, 0)) return 8; --- 95,106 ---- // There should be no adjustment for the `T' version, and an // appropriate adjustment for the `S' version. y = &T::f; ! if (! CMP_PTRFN (yp->ptr, ADJUST_PTRFN (&_ZN1T1fEv, 0))) return 5; if (yp->adj != ADJUST_DELTA (0, 0)) return 6; x = (sp) y; ! if (! CMP_PTRFN (xp->ptr, ADJUST_PTRFN (&_ZN1T1fEv, 0))) return 7; if (xp->adj != ADJUST_DELTA (delta, 0)) return 8; *************** main () *** 99,110 **** // one. `T::h' is in the second slot: the vtable pointer points to // the first virtual function. y = &T::h; ! if (yp->ptr != ADJUST_PTRFN (sizeof (void *), 1)) return 9; if (yp->adj != ADJUST_DELTA (0, 1)) return 10; x = (sp) y; ! if (xp->ptr != ADJUST_PTRFN (sizeof (void *), 1)) return 11; if (xp->adj != ADJUST_DELTA (delta, 1)) return 12; --- 109,120 ---- // one. `T::h' is in the second slot: the vtable pointer points to // the first virtual function. y = &T::h; ! if (yp->ptr != ADJUST_PTRFN (VPTE_SIZE, 1)) return 9; if (yp->adj != ADJUST_DELTA (0, 1)) return 10; x = (sp) y; ! if (xp->ptr != ADJUST_PTRFN (VPTE_SIZE, 1)) return 11; if (xp->adj != ADJUST_DELTA (delta, 1)) return 12; diff -Nrc3pad gcc-3.0.1/gcc/testsuite/g++.old-deja/g++.abi/vbase9.C gcc-3.0.2/gcc/testsuite/g++.old-deja/g++.abi/vbase9.C *** gcc-3.0.1/gcc/testsuite/g++.old-deja/g++.abi/vbase9.C Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/g++.old-deja/g++.abi/vbase9.C Thu Sep 6 03:39:45 2001 *************** *** 0 **** --- 1,60 ---- + // Build don't link: + + // Copyright (C) 2001 Free Software Foundation, Inc. + // Contributed by Nathan Sidwell 5 Sept 2001 + + // Bug 3986. Another indirect primary base problem. + + struct Consts + { + }; + + struct MathLib : + virtual Consts + { + }; + + struct Parallel : + virtual Consts + { + }; + + struct Particles : + virtual MathLib, + virtual Parallel + { + }; + + struct Ring : + virtual Particles + { + }; + + struct Injection : + virtual Particles, + virtual Ring + { + }; + + struct LSpaceCharge : + virtual Ring, + virtual Injection + { + }; + + struct Bump : + virtual Consts + { + }; + + struct Output : + virtual Injection, + virtual Bump + { + }; + + struct Plots : + virtual LSpaceCharge, + virtual Output + { + }; diff -Nrc3pad gcc-3.0.1/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C gcc-3.0.2/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C *** gcc-3.0.1/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C Sun Jun 4 14:12:25 2000 --- gcc-3.0.2/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C Fri Sep 21 18:33:29 2001 *************** *** 1,4 **** --- 1,5 ---- // Origin: Mark Mitchell + // Special g++ Options: -fno-strict-aliasing #if defined (__GXX_ABI_VERSION) && __GXX_ABI_VERSION >= 100 *************** void _ZN2S32s3Ev (); *** 126,131 **** --- 127,141 ---- void _ZN2S42s1Ev (); } + // IA-64 uses function descriptors not function pointers in its vtables. + #if defined __ia64__ + #define CMP_VPTR(A, B) (*(void **)(A) == *(void **)(B)) + #define INC_VPTR(A) ((A) += 2) + #else + #define CMP_VPTR(A, B) (*(A) == (ptrdiff_t)(B)) + #define INC_VPTR(A) ((A) += 1) + #endif + int main () { S4 s4; *************** int main () *** 147,156 **** return 4; // Skip the RTTI entry. vtbl++; ! if (*vtbl++ != (ptrdiff_t) &_ZN2S32s3Ev) return 5; ! if (*vtbl++ != (ptrdiff_t) &_ZN2S42s1Ev) return 6; // The S1 vbase offset. if (*vtbl++ != 0) return 7; --- 157,168 ---- return 4; // Skip the RTTI entry. vtbl++; ! if (! CMP_VPTR (vtbl, &_ZN2S32s3Ev)) return 5; ! INC_VPTR (vtbl); ! if (! CMP_VPTR (vtbl, &_ZN2S42s1Ev)) return 6; + INC_VPTR (vtbl); // The S1 vbase offset. if (*vtbl++ != 0) return 7; *************** int main () *** 168,175 **** // Skip the RTTI entry. vtbl++; // Skip the remaining virtual functions -- they are thunks. ! vtbl++; ! vtbl++; } #else /* !(defined (__GXX_ABI_VERSION) && __GXX_ABI_VERSION >= 100) */ --- 180,187 ---- // Skip the RTTI entry. vtbl++; // Skip the remaining virtual functions -- they are thunks. ! INC_VPTR (vtbl); ! INC_VPTR (vtbl); } #else /* !(defined (__GXX_ABI_VERSION) && __GXX_ABI_VERSION >= 100) */ diff -Nrc3pad gcc-3.0.1/gcc/testsuite/g++.old-deja/g++.oliva/ChangeLog gcc-3.0.2/gcc/testsuite/g++.old-deja/g++.oliva/ChangeLog *** gcc-3.0.1/gcc/testsuite/g++.old-deja/g++.oliva/ChangeLog Sun Aug 19 14:08:24 2001 --- gcc-3.0.2/gcc/testsuite/g++.old-deja/g++.oliva/ChangeLog Tue Oct 23 10:20:13 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/gcc/testsuite/g++.old-deja/g++.other/empty1.C gcc-3.0.2/gcc/testsuite/g++.old-deja/g++.other/empty1.C *** gcc-3.0.1/gcc/testsuite/g++.old-deja/g++.other/empty1.C Tue Jan 4 07:52:23 2000 --- gcc-3.0.2/gcc/testsuite/g++.old-deja/g++.other/empty1.C Tue Sep 4 06:03:04 2001 *************** *** 1,4 **** --- 1,10 ---- // Origin: Mark Mitchell + // This test case checks that the return value optimization works for + // empty classes. + + // xfailed because empty classes clobbering what they overlay as the + // backend treats them as single byte objects. See bug 4222 + // execution test - XFAIL *-*-* extern "C" void abort(); extern "C" int printf (const char *, ...); diff -Nrc3pad gcc-3.0.1/gcc/testsuite/g++.old-deja/g++.other/empty3.C gcc-3.0.2/gcc/testsuite/g++.old-deja/g++.other/empty3.C *** gcc-3.0.1/gcc/testsuite/g++.old-deja/g++.other/empty3.C Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/g++.old-deja/g++.other/empty3.C Tue Sep 4 06:03:04 2001 *************** *** 0 **** --- 1,28 ---- + // Copyright (C) 2001 Free Software Foundation, Inc. + // Contributed by Nathan Sidwell 3 Sept 2001 + + // Bug 4203. We were bit copying empty bases including the + // padding. Which clobbers whatever they overlay. + + class EmptyBase0 {}; + class EmptyBase1 : public EmptyBase0 {}; + class Base1 + { + public: + unsigned int t_; + Base1(unsigned int t) : t_(t) {} + }; + + class PEPE : public Base1, public EmptyBase1 + { + public: + PEPE(unsigned int t) + : Base1(t), EmptyBase1(EmptyBase1()) {} + }; + + int main() + { + PEPE pepe(0xff); + + return pepe.t_ != 255; + } diff -Nrc3pad gcc-3.0.1/gcc/testsuite/gcc.c-torture/compile/20010903-1.c gcc-3.0.2/gcc/testsuite/gcc.c-torture/compile/20010903-1.c *** gcc-3.0.1/gcc/testsuite/gcc.c-torture/compile/20010903-1.c Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/gcc.c-torture/compile/20010903-1.c Tue Sep 4 22:54:44 2001 *************** *** 0 **** --- 1,28 ---- + struct A { + long a; + }; + + static inline void foo(struct A *x) + { + __asm__ __volatile__("" : "+m"(x->a) : "r"(x) : "memory", "cc"); + } + + static inline void bar(struct A *x) + { + foo(x); + } + + struct B { char buf[640]; struct A a; }; + struct B b[32]; + + int baz(void) + { + int i; + struct B *j; + for (i = 1; i < 32; i++) + { + j = &b[i]; + bar(&j->a); + } + return 0; + } diff -Nrc3pad gcc-3.0.1/gcc/testsuite/gcc.c-torture/compile/20011010-1.c gcc-3.0.2/gcc/testsuite/gcc.c-torture/compile/20011010-1.c *** gcc-3.0.1/gcc/testsuite/gcc.c-torture/compile/20011010-1.c Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/gcc.c-torture/compile/20011010-1.c Wed Oct 10 12:24:59 2001 *************** *** 0 **** --- 1,10 ---- + extern int used (void); + + + int foo () + { + int i; + for (; used (); ({while (1) if (used ()) return 0;})) + i++; + return i; + } diff -Nrc3pad gcc-3.0.1/gcc/testsuite/gcc.c-torture/compile/981006-1.x gcc-3.0.2/gcc/testsuite/gcc.c-torture/compile/981006-1.x *** gcc-3.0.1/gcc/testsuite/gcc.c-torture/compile/981006-1.x Tue Sep 12 10:37:24 2000 --- gcc-3.0.2/gcc/testsuite/gcc.c-torture/compile/981006-1.x Wed Aug 29 09:12:20 2001 *************** if { [istarget rs6000-*-aix*] *** 6,11 **** --- 6,12 ---- || [istarget fr30-*-*] || [istarget sh-*-hms] || [istarget sh-*-coff] + || [istarget h8300*-*-*] } { set options "-Wuninitialized -Werror" } else { diff -Nrc3pad gcc-3.0.1/gcc/testsuite/gcc.c-torture/execute/20010403-1.c gcc-3.0.2/gcc/testsuite/gcc.c-torture/execute/20010403-1.c *** gcc-3.0.1/gcc/testsuite/gcc.c-torture/execute/20010403-1.c Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/gcc.c-torture/execute/20010403-1.c Wed Sep 12 13:55:22 2001 *************** *** 0 **** --- 1,36 ---- + void b (int *); + void c (int, int); + void d (int); + + int e; + + void a (int x, int y) + { + int f = x ? e : 0; + int z = y; + + b (&y); + c (z, y); + d (f); + } + + void b (int *y) + { + (*y)++; + } + + void c (int x, int y) + { + if (x == y) + abort (); + } + + void d (int x) + { + } + + int main (void) + { + a (0, 0); + exit (0); + } diff -Nrc3pad gcc-3.0.1/gcc/testsuite/gcc.c-torture/execute/20010904-1.c gcc-3.0.2/gcc/testsuite/gcc.c-torture/execute/20010904-1.c *** gcc-3.0.1/gcc/testsuite/gcc.c-torture/execute/20010904-1.c Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/gcc.c-torture/execute/20010904-1.c Wed Sep 5 01:47:31 2001 *************** *** 0 **** --- 1,11 ---- + typedef struct x { int a; int b; } __attribute__((aligned(32))) X; + typedef struct y { X x[32]; int c; } Y; + + Y y[2]; + + int main(void) + { + if (((char *)&y[1] - (char *)&y[0]) & 31) + abort (); + exit (0); + } diff -Nrc3pad gcc-3.0.1/gcc/testsuite/gcc.c-torture/execute/20010904-2.c gcc-3.0.2/gcc/testsuite/gcc.c-torture/execute/20010904-2.c *** gcc-3.0.1/gcc/testsuite/gcc.c-torture/execute/20010904-2.c Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/gcc.c-torture/execute/20010904-2.c Tue Sep 4 22:54:44 2001 *************** *** 0 **** --- 1,11 ---- + typedef struct x { int a; int b; } __attribute__((aligned(32))) X; + typedef struct y { X x; X y[31]; int c; } Y; + + Y y[2]; + + int main(void) + { + if (((char *)&y[1] - (char *)&y[0]) & 31) + abort (); + exit (0); + } diff -Nrc3pad gcc-3.0.1/gcc/testsuite/gcc.c-torture/execute/20010910-1.c gcc-3.0.2/gcc/testsuite/gcc.c-torture/execute/20010910-1.c *** gcc-3.0.1/gcc/testsuite/gcc.c-torture/execute/20010910-1.c Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/gcc.c-torture/execute/20010910-1.c Mon Sep 10 09:21:53 2001 *************** *** 0 **** --- 1,59 ---- + /* Test case contributed by Ingo Rohloff . + Code distilled from Linux kernel. */ + + /* Compile this program with a gcc-2.95.2 using + "gcc -O2" and run it. The result will be that + rx_ring[1].next == 0 (it should be == 14) + and + ep.skbuff[4] == 5 (it should be 0) + */ + + extern void abort(void); + + struct epic_rx_desc + { + unsigned int next; + }; + + struct epic_private + { + struct epic_rx_desc *rx_ring; + unsigned int rx_skbuff[5]; + }; + + static void epic_init_ring(struct epic_private *ep) + { + int i; + + for (i = 0; i < 5; i++) + { + ep->rx_ring[i].next = 10 + (i+1)*2; + ep->rx_skbuff[i] = 0; + } + ep->rx_ring[i-1].next = 10; + } + + static int check_rx_ring[5] = { 12,14,16,18,10 }; + + int main(void) + { + struct epic_private ep; + struct epic_rx_desc rx_ring[5]; + int i; + + for (i=0;i<5;i++) + { + rx_ring[i].next=0; + ep.rx_skbuff[i]=5; + } + + ep.rx_ring=rx_ring; + epic_init_ring(&ep); + + for (i=0;i<5;i++) + { + if ( rx_ring[i].next != check_rx_ring[i] ) abort(); + if ( ep.rx_skbuff[i] != 0 ) abort(); + } + return 0; + } diff -Nrc3pad gcc-3.0.1/gcc/testsuite/gcc.c-torture/execute/20011008-3.c gcc-3.0.2/gcc/testsuite/gcc.c-torture/execute/20011008-3.c *** gcc-3.0.1/gcc/testsuite/gcc.c-torture/execute/20011008-3.c Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/gcc.c-torture/execute/20011008-3.c Wed Oct 10 09:30:43 2001 *************** *** 0 **** --- 1,99 ---- + extern void exit (int); + extern void abort (void); + + typedef unsigned int u_int32_t; + typedef unsigned char u_int8_t; + typedef int int32_t; + + typedef enum { + TXNLIST_DELETE, + TXNLIST_LSN, + TXNLIST_TXNID, + TXNLIST_PGNO + } db_txnlist_type; + + struct __db_lsn; typedef struct __db_lsn DB_LSN; + struct __db_lsn { + u_int32_t file; + u_int32_t offset; + }; + struct __db_txnlist; typedef struct __db_txnlist DB_TXNLIST; + + struct __db_txnlist { + db_txnlist_type type; + struct { struct __db_txnlist *le_next; struct __db_txnlist **le_prev; } links; + union { + struct { + u_int32_t txnid; + int32_t generation; + int32_t aborted; + } t; + struct { + + + u_int32_t flags; + int32_t fileid; + u_int32_t count; + char *fname; + } d; + struct { + int32_t ntxns; + int32_t maxn; + DB_LSN *lsn_array; + } l; + struct { + int32_t nentries; + int32_t maxentry; + char *fname; + int32_t fileid; + void *pgno_array; + u_int8_t uid[20]; + } p; + } u; + }; + + int log_compare (const DB_LSN *a, const DB_LSN *b) + { + return 1; + } + + + int + __db_txnlist_lsnadd(int val, DB_TXNLIST *elp, DB_LSN *lsnp, u_int32_t flags) + { + int i; + + for (i = 0; i < (!(flags & (0x1)) ? 1 : elp->u.l.ntxns); i++) + { + int __j; + DB_LSN __tmp; + val++; + for (__j = 0; __j < elp->u.l.ntxns - 1; __j++) + if (log_compare(&elp->u.l.lsn_array[__j], &elp->u.l.lsn_array[__j + 1]) < 0) + { + __tmp = elp->u.l.lsn_array[__j]; + elp->u.l.lsn_array[__j] = elp->u.l.lsn_array[__j + 1]; + elp->u.l.lsn_array[__j + 1] = __tmp; + } + } + + *lsnp = elp->u.l.lsn_array[0]; + return val; + } + + int main (void) + { + DB_TXNLIST el; + DB_LSN lsn, lsn_a[1235]; + + el.u.l.ntxns = 1234; + el.u.l.lsn_array = lsn_a; + + if (__db_txnlist_lsnadd (0, &el, &lsn, 0) != 1) + abort (); + + if (__db_txnlist_lsnadd (0, &el, &lsn, 1) != 1234) + abort (); + + exit (0); + } diff -Nrc3pad gcc-3.0.1/gcc/testsuite/gcc.c-torture/execute/990208-1.x gcc-3.0.2/gcc/testsuite/gcc.c-torture/execute/990208-1.x *** gcc-3.0.1/gcc/testsuite/gcc.c-torture/execute/990208-1.x Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/gcc.c-torture/execute/990208-1.x Thu Sep 20 10:54:56 2001 *************** *** 0 **** --- 1,14 ---- + # Doesn't work at -O3 because of ifcvt.c optimizations which + # cause the 2 inlined labels to be at the same location. + + set torture_eval_before_execute { + + set compiler_conditional_xfail_data { + "ifcvt transforms 2 inlined labels to the same address" \ + "ia64-*-*" \ + { "-O3" } \ + { "" } + } + } + + return 0 diff -Nrc3pad gcc-3.0.1/gcc/testsuite/gcc.dg/20010912-1.c gcc-3.0.2/gcc/testsuite/gcc.dg/20010912-1.c *** gcc-3.0.1/gcc/testsuite/gcc.dg/20010912-1.c Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/gcc.dg/20010912-1.c Wed Sep 12 13:55:22 2001 *************** *** 0 **** --- 1,48 ---- + /* { dg-do run } */ + /* { dg-options "-O2 -fpic" } */ + + extern void abort (void); + extern void exit (int); + + int bar (int x, char **y) + { + if (x != 56) + abort (); + if (**y != 'a') + abort (); + *y = "def"; + return 1; + } + + int baz (int x, char **y) + { + if (x != 56) + abort (); + if (**y != 'a') + abort (); + return 26; + } + + int foo (int x, char *y) + { + int a; + char *b = y; + a = bar (x, &y); + if (a) + { + y = b; + a = baz (x, &y); + } + if (a) + return a; + + baz (x, &y); + return 0; + } + + int main () + { + if (foo (56, "abc") != 26) + abort (); + exit (0); + } diff -Nrc3pad gcc-3.0.1/gcc/testsuite/gcc.dg/array-5.c gcc-3.0.2/gcc/testsuite/gcc.dg/array-5.c *** gcc-3.0.1/gcc/testsuite/gcc.dg/array-5.c Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/gcc/testsuite/gcc.dg/array-5.c Mon Sep 17 12:56:41 2001 *************** *** 0 **** --- 1,42 ---- + /* { dg-do compile } */ + /* { dg-options "" } */ + + /* Check compatibility of array declarations. */ + + /* Incomplete decl matches. */ + extern char arr0[]; + char arr0[1]; + + /* Two integral expressions must be the same. Note that 0 is + a gcc extension, but it should work like any other constant. */ + extern char arr1[1]; + char arr1[1]; + extern char arr2[0]; + char arr2[0]; + extern char arr3[0]; /* { dg-error "previous declaration" } */ + char arr3[1]; /* { dg-error "conflicting types" } */ + + /* Variable size matches. */ + void func(int n, int m) + { + /* The next two are from the example in c99 6.7.5.2/9. */ + { + /* Invalid: not compatible because 4 != 6. */ + int a[n][6][m]; + int (*p)[4][n+1]; + p = a; /* { dg-error "incompatible" } */ + } + { + /* Compatible, but defined behavior only if n == 6 and m == n+1. */ + int c[n][n][6][m]; + int (*r)[n][n][n+1]; + r = c; + } + { + /* Compatible, but undefined behavior; (2, 2) is not a constant + expression, and thus A is a VLA. */ + int a[6][(2, 2)]; + int (*p)[3]; + p = a; /* { dg-bogus "incompatible" "bad vla handling" { xfail *-*-* } } */ + } + } diff -Nrc3pad gcc-3.0.1/gcc/tradcif.c gcc-3.0.2/gcc/tradcif.c *** gcc-3.0.1/gcc/tradcif.c Sun Aug 19 18:02:06 2001 --- gcc-3.0.2/gcc/tradcif.c Tue Oct 23 10:59:38 2001 *************** *** 1,7 **** /* A Bison parser, made from tradcif.y ! by GNU Bison version 1.27 ! */ #define YYBISON 1 /* Identify Bison output. */ --- 1,6 ---- /* A Bison parser, made from tradcif.y ! by GNU Bison version 1.28 */ #define YYBISON 1 /* Identify Bison output. */ *************** static const short yycheck[] = { 4, *** 226,232 **** }; /* -*-C-*- Note some compilers choke on comments on `#line' lines. */ #line 3 "/usr/lib/bison.simple" ! /* This file comes from bison-1.27. */ /* Skeleton output parser for bison, Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. --- 225,231 ---- }; /* -*-C-*- Note some compilers choke on comments on `#line' lines. */ #line 3 "/usr/lib/bison.simple" ! /* This file comes from bison-1.28. */ /* Skeleton output parser for bison, Copyright (C) 1984, 1989, 1990 Free Software Foundation, Inc. *************** __yy_memcpy (char *to, char *from, unsig *** 439,445 **** #endif #endif ! #line 216 "/usr/lib/bison.simple" /* The user can define YYPARSE_PARAM as the name of an argument to be passed into yyparse. The argument should have type void *. --- 438,444 ---- #endif #endif ! #line 217 "/usr/lib/bison.simple" /* The user can define YYPARSE_PARAM as the name of an argument to be passed into yyparse. The argument should have type void *. *************** case 31: *** 954,960 **** break;} } /* the action file gets copied in in place of this dollarsign */ ! #line 542 "/usr/lib/bison.simple" yyvsp -= yylen; yyssp -= yylen; --- 953,959 ---- break;} } /* the action file gets copied in in place of this dollarsign */ ! #line 543 "/usr/lib/bison.simple" yyvsp -= yylen; yyssp -= yylen; diff -Nrc3pad gcc-3.0.1/gcc/tree.def gcc-3.0.2/gcc/tree.def *** gcc-3.0.1/gcc/tree.def Sun May 13 00:09:59 2001 --- gcc-3.0.2/gcc/tree.def Fri Sep 21 18:33:20 2001 *************** DEFTREECODE (ADDR_EXPR, "addr_expr", 'e' *** 717,724 **** DEFTREECODE (REFERENCE_EXPR, "reference_expr", 'e', 1) /* Operand is a function constant; result is a function variable value ! of typeEPmode. Used only for languages that need static chains. */ DEFTREECODE (ENTRY_VALUE_EXPR, "entry_value_expr", 'e', 1) /* Given two real or integer operands of the same type, returns a complex value of the corresponding complex type. */ --- 717,728 ---- DEFTREECODE (REFERENCE_EXPR, "reference_expr", 'e', 1) /* Operand is a function constant; result is a function variable value ! of type EPmode. Used only for languages that need static chains. */ DEFTREECODE (ENTRY_VALUE_EXPR, "entry_value_expr", 'e', 1) + + /* Operand0 is a function constant; result is part N of a function + descriptor of type ptr_mode. */ + DEFTREECODE (FDESC_EXPR, "fdesc_expr", 'e', 2) /* Given two real or integer operands of the same type, returns a complex value of the corresponding complex type. */ diff -Nrc3pad gcc-3.0.1/gcc/unroll.c gcc-3.0.2/gcc/unroll.c *** gcc-3.0.1/gcc/unroll.c Sat Apr 21 11:43:40 2001 --- gcc-3.0.2/gcc/unroll.c Thu Oct 11 12:39:52 2001 *************** loop_iterations (loop) *** 3498,3503 **** --- 3498,3528 ---- return 0; } + /* If there are multiple conditionalized loop exit tests, they may jump + back to differing CODE_LABELs. */ + if (loop->top && loop->cont) + { + rtx temp = PREV_INSN (last_loop_insn); + + do + { + if (GET_CODE (temp) == JUMP_INSN + /* Previous unrolling may have generated new insns not covered + by the uid_luid array. */ + && INSN_UID (JUMP_LABEL (temp)) < max_uid_for_loop + /* Check if we jump back into the loop body. */ + && INSN_LUID (JUMP_LABEL (temp)) > INSN_LUID (loop->top) + && INSN_LUID (JUMP_LABEL (temp)) < INSN_LUID (loop->cont)) + { + if (loop_dump_stream) + fprintf (loop_dump_stream, + "Loop iterations: Loop has multiple back edges.\n"); + return 0; + } + } + while ((temp = PREV_INSN (temp)) != loop->cont); + } + /* Find the iteration variable. If the last insn is a conditional branch, and the insn before tests a register value, make that the iteration variable. */ diff -Nrc3pad gcc-3.0.1/gcc/unwind.h gcc-3.0.2/gcc/unwind.h *** gcc-3.0.1/gcc/unwind.h Sun May 13 00:10:02 2001 --- gcc-3.0.2/gcc/unwind.h Tue Sep 4 11:19:41 2001 *************** typedef int _Unwind_Action; *** 87,92 **** --- 87,93 ---- #define _UA_CLEANUP_PHASE 2 #define _UA_HANDLER_FRAME 4 #define _UA_FORCE_UNWIND 8 + #define _UA_END_OF_STACK 16 /* This is an opaque type used to refer to a system-specific data structure used by the system unwinder. This context is created and diff -Nrc3pad gcc-3.0.1/gcc/unwind.inc gcc-3.0.2/gcc/unwind.inc *** gcc-3.0.1/gcc/unwind.inc Sat May 19 17:31:42 2001 --- gcc-3.0.2/gcc/unwind.inc Tue Sep 4 11:19:41 2001 *************** _Unwind_ForcedUnwind_Phase2(struct _Unwi *** 142,155 **** while (1) { _Unwind_FrameState fs; code = uw_frame_state_for (context, &fs); if (code != _URC_NO_REASON && code != _URC_END_OF_STACK) return _URC_FATAL_PHASE2_ERROR; /* Unwind successful. */ ! stop_code = (*stop) (1, _UA_FORCE_UNWIND | _UA_CLEANUP_PHASE, ! exc->exception_class, exc, context, stop_argument); if (stop_code != _URC_NO_REASON) return _URC_FATAL_PHASE2_ERROR; --- 142,159 ---- while (1) { _Unwind_FrameState fs; + int action; code = uw_frame_state_for (context, &fs); if (code != _URC_NO_REASON && code != _URC_END_OF_STACK) return _URC_FATAL_PHASE2_ERROR; /* Unwind successful. */ ! action = _UA_FORCE_UNWIND | _UA_CLEANUP_PHASE; ! if (code == _URC_END_OF_STACK) ! action |= _UA_END_OF_STACK; ! stop_code = (*stop) (1, action, exc->exception_class, exc, ! context, stop_argument); if (stop_code != _URC_NO_REASON) return _URC_FATAL_PHASE2_ERROR; diff -Nrc3pad gcc-3.0.1/gcc/varasm.c gcc-3.0.2/gcc/varasm.c *** gcc-3.0.1/gcc/varasm.c Mon Aug 6 10:24:21 2001 --- gcc-3.0.2/gcc/varasm.c Fri Sep 21 18:33:20 2001 *************** initializer_constant_valid_p (value, end *** 4119,4124 **** --- 4119,4125 ---- return null_pointer_node; case ADDR_EXPR: + case FDESC_EXPR: return staticp (TREE_OPERAND (value, 0)) ? TREE_OPERAND (value, 0) : 0; case NON_LVALUE_EXPR: *************** output_constant (exp, size) *** 4305,4310 **** --- 4306,4323 ---- if (TREE_CODE (exp) == CONSTRUCTOR && CONSTRUCTOR_ELTS (exp) == 0) { assemble_zeros (size); + return; + } + + if (TREE_CODE (exp) == FDESC_EXPR) + { + HOST_WIDE_INT part = tree_low_cst (TREE_OPERAND (exp, 1), 0); + tree decl = TREE_OPERAND (exp, 0); + #ifdef ASM_OUTPUT_FDESC + ASM_OUTPUT_FDESC (asm_out_file, decl, part); + #else + abort (); + #endif return; } diff -Nrc3pad gcc-3.0.1/gcc/version.c gcc-3.0.2/gcc/version.c *** gcc-3.0.1/gcc/version.c Sun Aug 19 14:08:39 2001 --- gcc-3.0.2/gcc/version.c Tue Oct 23 10:21:24 2001 *************** *** 1,4 **** #include "gansidecl.h" #include "version.h" ! const char *const version_string = "3.0.1"; --- 1,4 ---- #include "gansidecl.h" #include "version.h" ! const char *const version_string = "3.0.2"; diff -Nrc3pad gcc-3.0.1/gnats.html gcc-3.0.2/gnats.html *** gcc-3.0.1/gnats.html Sun Aug 19 17:45:07 2001 --- gcc-3.0.2/gnats.html Tue Oct 23 10:56:12 2001 *************** does not foo", "objc crashes when doing *** 74,79 **** --- 74,81 ----
        This indicates the GCC subproject which is affected by the problem. Currently, it can be one of
        +
        ada
        +
        A problem with the Ada compiler, libraries or tools.
        bootstrap
        GCC fails to bootstrap. This should be filed only if a bootstrap failure prevails for an extended period of time (at least diff -Nrc3pad gcc-3.0.1/include/ChangeLog gcc-3.0.2/include/ChangeLog *** gcc-3.0.1/include/ChangeLog Sun Aug 19 14:08:25 2001 --- gcc-3.0.2/include/ChangeLog Tue Oct 23 10:20:18 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/libf2c/ChangeLog gcc-3.0.2/libf2c/ChangeLog *** gcc-3.0.1/libf2c/ChangeLog Sun Aug 19 14:08:26 2001 --- gcc-3.0.2/libf2c/ChangeLog Tue Oct 23 10:20:23 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/libf2c/libF77/Version.c gcc-3.0.2/libf2c/libF77/Version.c *** gcc-3.0.1/libf2c/libF77/Version.c Sun Aug 19 13:27:48 2001 --- gcc-3.0.2/libf2c/libF77/Version.c Tue Oct 23 10:21:33 2001 *************** static char junk[] = "\n@(#)LIBF77 VERSI *** 3,9 **** /* */ ! char __G77_LIBF77_VERSION__[] = "0.5.26 20010819 (release)"; /* 2.00 11 June 1980. File version.c added to library. --- 3,9 ---- /* */ ! char __G77_LIBF77_VERSION__[] = "0.5.26 20011023 (release)"; /* 2.00 11 June 1980. File version.c added to library. diff -Nrc3pad gcc-3.0.1/libf2c/libI77/Version.c gcc-3.0.2/libf2c/libI77/Version.c *** gcc-3.0.1/libf2c/libI77/Version.c Sun Aug 19 13:27:50 2001 --- gcc-3.0.2/libf2c/libI77/Version.c Tue Oct 23 10:21:38 2001 *************** static char junk[] = "\n@(#) LIBI77 VERS *** 3,9 **** /* */ ! char __G77_LIBI77_VERSION__[] = "0.5.26 20010819 (release)"; /* 2.01 $ format added --- 3,9 ---- /* */ ! char __G77_LIBI77_VERSION__[] = "0.5.26 20011023 (release)"; /* 2.01 $ format added diff -Nrc3pad gcc-3.0.1/libf2c/libU77/Version.c gcc-3.0.2/libf2c/libU77/Version.c *** gcc-3.0.1/libf2c/libU77/Version.c Sun Aug 19 13:27:51 2001 --- gcc-3.0.2/libf2c/libU77/Version.c Tue Oct 23 10:21:44 2001 *************** *** 1,6 **** static char junk[] = "\n@(#) LIBU77 VERSION 19980709\n"; ! char __G77_LIBU77_VERSION__[] = "0.5.26 20010819 (release)"; #include --- 1,6 ---- static char junk[] = "\n@(#) LIBU77 VERSION 19980709\n"; ! char __G77_LIBU77_VERSION__[] = "0.5.26 20011023 (release)"; #include diff -Nrc3pad gcc-3.0.1/libffi/ChangeLog gcc-3.0.2/libffi/ChangeLog *** gcc-3.0.1/libffi/ChangeLog Sun Aug 19 14:08:28 2001 --- gcc-3.0.2/libffi/ChangeLog Tue Oct 23 10:20:30 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/libiberty/ChangeLog gcc-3.0.2/libiberty/ChangeLog *** gcc-3.0.1/libiberty/ChangeLog Sun Aug 19 14:08:29 2001 --- gcc-3.0.2/libiberty/ChangeLog Tue Oct 23 10:20:36 2001 *************** *** 1,3 **** --- 1,13 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + + 2001-08-21 Christopher Faylor + + * configure.in: Set HAVE_SYS_ERRLIST and HAVE_SYS_NERR whenever hosting + on cygwin. + * configure: Regenerate. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/libiberty/configure gcc-3.0.2/libiberty/configure *** gcc-3.0.1/libiberty/configure Tue Dec 26 14:16:22 2000 --- gcc-3.0.2/libiberty/configure Tue Oct 9 21:28:03 2001 *************** fi *** 1826,1831 **** --- 1826,1844 ---- + case "${host}" in + *-*-cygwin*) + cat >> confdefs.h <<\EOF + #define HAVE_SYS_ERRLIST 1 + EOF + + cat >> confdefs.h <<\EOF + #define HAVE_SYS_NERR 1 + EOF + + ;; + esac + if test -z "${setobjs}"; then case "${host}" in *************** if test -z "${setobjs}"; then *** 1917,1923 **** # We haven't set the list of objects yet. Use the standard autoconf # tests. This will only work if the compiler works. echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works""... $ac_c" 1>&6 ! echo "configure:1921: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works" >&5 ac_ext=c # CFLAGS is not in ac_cpp because -g, -O, etc. are not valid cpp options. --- 1930,1936 ---- # We haven't set the list of objects yet. Use the standard autoconf # tests. This will only work if the compiler works. echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works""... $ac_c" 1>&6 ! echo "configure:1934: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) works" >&5 ac_ext=c # CFLAGS is not in ac_cpp because -g, -O, etc. are not valid cpp options. *************** cross_compiling=$ac_cv_prog_cc_cross *** 1928,1939 **** cat > conftest.$ac_ext << EOF ! #line 1932 "configure" #include "confdefs.h" main(){return(0);} EOF ! if { (eval echo configure:1937: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then ac_cv_prog_cc_works=yes # If we can't run a trivial program, we are probably using a cross compiler. if (./conftest; exit) 2>/dev/null; then --- 1941,1952 ---- cat > conftest.$ac_ext << EOF ! #line 1945 "configure" #include "confdefs.h" main(){return(0);} EOF ! if { (eval echo configure:1950: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then ac_cv_prog_cc_works=yes # If we can't run a trivial program, we are probably using a cross compiler. if (./conftest; exit) 2>/dev/null; then *************** if test $ac_cv_prog_cc_works = no; then *** 1959,1977 **** { echo "configure: error: installation or configuration problem: C compiler cannot create executables." 1>&2; exit 1; } fi echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler""... $ac_c" 1>&6 ! echo "configure:1963: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler" >&5 echo "$ac_t""$ac_cv_prog_cc_cross" 1>&6 cross_compiling=$ac_cv_prog_cc_cross for ac_func in $funcs do echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 ! echo "configure:1970: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&2; exit 1; } fi echo $ac_n "checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler""... $ac_c" 1>&6 ! echo "configure:1976: checking whether the C compiler ($CC $CFLAGS $LDFLAGS) is a cross-compiler" >&5 echo "$ac_t""$ac_cv_prog_cc_cross" 1>&6 cross_compiling=$ac_cv_prog_cc_cross for ac_func in $funcs do echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 ! echo "configure:1983: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else --- 2007,2013 ---- ; return 0; } EOF ! if { (eval echo configure:2011: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else *************** EOF *** 2041,2059 **** # The Ultrix 4.2 mips builtin alloca declared by alloca.h only works # for constant arguments. Useless! echo $ac_n "checking for working alloca.h""... $ac_c" 1>&6 ! echo "configure:2045: checking for working alloca.h" >&5 if eval "test \"`echo '$''{'ac_cv_header_alloca_h'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < int main() { char *p = alloca(2 * sizeof(int)); ; return 0; } EOF ! if { (eval echo configure:2057: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* ac_cv_header_alloca_h=yes else --- 2054,2072 ---- # The Ultrix 4.2 mips builtin alloca declared by alloca.h only works # for constant arguments. Useless! echo $ac_n "checking for working alloca.h""... $ac_c" 1>&6 ! echo "configure:2058: checking for working alloca.h" >&5 if eval "test \"`echo '$''{'ac_cv_header_alloca_h'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < int main() { char *p = alloca(2 * sizeof(int)); ; return 0; } EOF ! if { (eval echo configure:2070: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* ac_cv_header_alloca_h=yes else *************** EOF *** 2074,2085 **** fi echo $ac_n "checking for alloca""... $ac_c" 1>&6 ! echo "configure:2078: checking for alloca" >&5 if eval "test \"`echo '$''{'ac_cv_func_alloca_works'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&6 ! echo "configure:2091: checking for alloca" >&5 if eval "test \"`echo '$''{'ac_cv_func_alloca_works'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* ac_cv_func_alloca_works=yes else --- 2120,2126 ---- char *p = (char *) alloca(1); ; return 0; } EOF ! if { (eval echo configure:2124: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* ac_cv_func_alloca_works=yes else *************** EOF *** 2139,2150 **** echo $ac_n "checking whether alloca needs Cray hooks""... $ac_c" 1>&6 ! echo "configure:2143: checking whether alloca needs Cray hooks" >&5 if eval "test \"`echo '$''{'ac_cv_os_cray'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&6 ! echo "configure:2156: checking whether alloca needs Cray hooks" >&5 if eval "test \"`echo '$''{'ac_cv_os_cray'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&6 *** 2169,2180 **** if test $ac_cv_os_cray = yes; then for ac_func in _getb67 GETB67 getb67; do echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 ! echo "configure:2173: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&6 ! echo "configure:2186: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else --- 2210,2216 ---- ; return 0; } EOF ! if { (eval echo configure:2214: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else *************** done *** 2224,2230 **** fi echo $ac_n "checking stack direction for C alloca""... $ac_c" 1>&6 ! echo "configure:2228: checking stack direction for C alloca" >&5 if eval "test \"`echo '$''{'ac_cv_c_stack_direction'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 2237,2243 ---- fi echo $ac_n "checking stack direction for C alloca""... $ac_c" 1>&6 ! echo "configure:2241: checking stack direction for C alloca" >&5 if eval "test \"`echo '$''{'ac_cv_c_stack_direction'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** else *** 2232,2238 **** ac_cv_c_stack_direction=0 else cat > conftest.$ac_ext < conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_c_stack_direction=1 else --- 2264,2270 ---- exit (find_stack_direction() < 0); } EOF ! if { (eval echo configure:2268: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_c_stack_direction=1 else *************** fi *** 2276,2287 **** esac echo $ac_n "checking for ANSI C header files""... $ac_c" 1>&6 ! echo "configure:2280: checking for ANSI C header files" >&5 if eval "test \"`echo '$''{'ac_cv_header_stdc'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #include --- 2289,2300 ---- esac echo $ac_n "checking for ANSI C header files""... $ac_c" 1>&6 ! echo "configure:2293: checking for ANSI C header files" >&5 if eval "test \"`echo '$''{'ac_cv_header_stdc'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #include *************** else *** 2289,2295 **** #include EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:2293: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* --- 2302,2308 ---- #include EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:2306: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* *************** rm -f conftest* *** 2306,2312 **** if test $ac_cv_header_stdc = yes; then # SunOS 4.x string.h does not declare mem*, contrary to ANSI. cat > conftest.$ac_ext < EOF --- 2319,2325 ---- if test $ac_cv_header_stdc = yes; then # SunOS 4.x string.h does not declare mem*, contrary to ANSI. cat > conftest.$ac_ext < EOF *************** fi *** 2324,2330 **** if test $ac_cv_header_stdc = yes; then # ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI. cat > conftest.$ac_ext < EOF --- 2337,2343 ---- if test $ac_cv_header_stdc = yes; then # ISC 2.0.2 stdlib.h does not declare free, contrary to ANSI. cat > conftest.$ac_ext < EOF *************** if test "$cross_compiling" = yes; then *** 2345,2351 **** : else cat > conftest.$ac_ext < #define ISLOWER(c) ('a' <= (c) && (c) <= 'z') --- 2358,2364 ---- : else cat > conftest.$ac_ext < #define ISLOWER(c) ('a' <= (c) && (c) <= 'z') *************** if (XOR (islower (i), ISLOWER (i)) || to *** 2356,2362 **** exit (0); } EOF ! if { (eval echo configure:2360: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then : else --- 2369,2375 ---- exit (0); } EOF ! if { (eval echo configure:2373: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then : else *************** EOF *** 2380,2391 **** fi echo $ac_n "checking for pid_t""... $ac_c" 1>&6 ! echo "configure:2384: checking for pid_t" >&5 if eval "test \"`echo '$''{'ac_cv_type_pid_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #if STDC_HEADERS --- 2393,2404 ---- fi echo $ac_n "checking for pid_t""... $ac_c" 1>&6 ! echo "configure:2397: checking for pid_t" >&5 if eval "test \"`echo '$''{'ac_cv_type_pid_t'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < #if STDC_HEADERS *************** fi *** 2414,2430 **** ac_safe=`echo "vfork.h" | sed 'y%./+-%__p_%'` echo $ac_n "checking for vfork.h""... $ac_c" 1>&6 ! echo "configure:2418: checking for vfork.h" >&5 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:2428: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* --- 2427,2443 ---- ac_safe=`echo "vfork.h" | sed 'y%./+-%__p_%'` echo $ac_n "checking for vfork.h""... $ac_c" 1>&6 ! echo "configure:2431: checking for vfork.h" >&5 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:2441: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* *************** else *** 2449,2466 **** fi echo $ac_n "checking for working vfork""... $ac_c" 1>&6 ! echo "configure:2453: checking for working vfork" >&5 if eval "test \"`echo '$''{'ac_cv_func_vfork_works'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else if test "$cross_compiling" = yes; then echo $ac_n "checking for vfork""... $ac_c" 1>&6 ! echo "configure:2459: checking for vfork" >&5 if eval "test \"`echo '$''{'ac_cv_func_vfork'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&6 ! echo "configure:2466: checking for working vfork" >&5 if eval "test \"`echo '$''{'ac_cv_func_vfork_works'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else if test "$cross_compiling" = yes; then echo $ac_n "checking for vfork""... $ac_c" 1>&6 ! echo "configure:2472: checking for vfork" >&5 if eval "test \"`echo '$''{'ac_cv_func_vfork'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_vfork=yes" else --- 2496,2502 ---- ; return 0; } EOF ! if { (eval echo configure:2500: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_vfork=yes" else *************** fi *** 2505,2511 **** ac_cv_func_vfork_works=$ac_cv_func_vfork else cat > conftest.$ac_ext < --- 2518,2524 ---- ac_cv_func_vfork_works=$ac_cv_func_vfork else cat > conftest.$ac_ext < *************** main() { *** 2600,2606 **** } } EOF ! if { (eval echo configure:2604: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_func_vfork_works=yes else --- 2613,2619 ---- } } EOF ! if { (eval echo configure:2617: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_func_vfork_works=yes else *************** fi *** 2627,2645 **** fi for v in $vars; do echo $ac_n "checking for $v""... $ac_c" 1>&6 ! echo "configure:2631: checking for $v" >&5 if eval "test \"`echo '$''{'libiberty_cv_var_$v'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "libiberty_cv_var_$v=yes" else --- 2640,2658 ---- fi for v in $vars; do echo $ac_n "checking for $v""... $ac_c" 1>&6 ! echo "configure:2644: checking for $v" >&5 if eval "test \"`echo '$''{'libiberty_cv_var_$v'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "libiberty_cv_var_$v=yes" else *************** EOF *** 2665,2676 **** for ac_func in $checkfuncs do echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 ! echo "configure:2669: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&6 ! echo "configure:2682: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else --- 2706,2712 ---- ; return 0; } EOF ! if { (eval echo configure:2710: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else *************** for ac_hdr in unistd.h *** 2723,2739 **** do ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'` echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6 ! echo "configure:2727: checking for $ac_hdr" >&5 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:2737: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* --- 2736,2752 ---- do ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'` echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6 ! echo "configure:2740: checking for $ac_hdr" >&5 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:2750: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* *************** done *** 2762,2773 **** for ac_func in getpagesize do echo $ac_n "checking for $ac_func""... $ac_c" 1>&6 ! echo "configure:2766: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&6 ! echo "configure:2779: checking for $ac_func" >&5 if eval "test \"`echo '$''{'ac_cv_func_$ac_func'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else --- 2803,2809 ---- ; return 0; } EOF ! if { (eval echo configure:2807: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* eval "ac_cv_func_$ac_func=yes" else *************** fi *** 2815,2821 **** done echo $ac_n "checking for working mmap""... $ac_c" 1>&6 ! echo "configure:2819: checking for working mmap" >&5 if eval "test \"`echo '$''{'ac_cv_func_mmap_fixed_mapped'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 2828,2834 ---- done echo $ac_n "checking for working mmap""... $ac_c" 1>&6 ! echo "configure:2832: checking for working mmap" >&5 if eval "test \"`echo '$''{'ac_cv_func_mmap_fixed_mapped'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** else *** 2823,2829 **** ac_cv_func_mmap_fixed_mapped=no else cat > conftest.$ac_ext < conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_func_mmap_fixed_mapped=yes else --- 2976,2982 ---- } EOF ! if { (eval echo configure:2980: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_func_mmap_fixed_mapped=yes else *************** fi *** 2987,2993 **** echo $ac_n "checking for working strncmp""... $ac_c" 1>&6 ! echo "configure:2991: checking for working strncmp" >&5 if eval "test \"`echo '$''{'ac_cv_func_strncmp_works'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else --- 3000,3006 ---- echo $ac_n "checking for working strncmp""... $ac_c" 1>&6 ! echo "configure:3004: checking for working strncmp" >&5 if eval "test \"`echo '$''{'ac_cv_func_strncmp_works'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else *************** else *** 2995,3001 **** ac_cv_func_strncmp_works=no else cat > conftest.$ac_ext < conftest.$ac_ext <&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_func_strncmp_works=yes else --- 3069,3075 ---- } EOF ! if { (eval echo configure:3073: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null then ac_cv_func_strncmp_works=yes else diff -Nrc3pad gcc-3.0.1/libiberty/configure.in gcc-3.0.2/libiberty/configure.in *** gcc-3.0.1/libiberty/configure.in Tue Dec 26 14:16:22 2000 --- gcc-3.0.2/libiberty/configure.in Tue Oct 9 21:28:04 2001 *************** fi *** 191,196 **** --- 191,203 ---- AC_SUBST(CHECK) + case "${host}" in + *-*-cygwin*) + AC_DEFINE(HAVE_SYS_ERRLIST) + AC_DEFINE(HAVE_SYS_NERR) + ;; + esac + if test -z "${setobjs}"; then case "${host}" in diff -Nrc3pad gcc-3.0.1/libjava/ChangeLog gcc-3.0.2/libjava/ChangeLog *** gcc-3.0.1/libjava/ChangeLog Sun Aug 19 14:08:30 2001 --- gcc-3.0.2/libjava/ChangeLog Tue Oct 23 10:20:46 2001 *************** *** 1,3 **** --- 1,50 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + + 2001-10-16 Bryce McKinlay + + * name-finder.cc (_Jv_name_finder::lookup): Check for NULL dli_sname + and dli_fname. + + 2001-10-03 Bryce McKinlay + + * resolve.cc (_Jv_PrepareClass): Fix typos in vtable layout. + + 2001-09-30 Bryce McKinlay + + * java/lang/natClass.cc (_Jv_IsAssignableFrom): Handle the case of + an uninitialized target class. Revert patch of 2001-07-18. + + 2001-08-17 Tom Tromey + + * gnu/gcj/convert/IOConverter.java: Add `646' alias. + + 2001-06-15 Tom Tromey + + * jni.cc (_Jv_JNI_NewLocalRef): Search other frames. + + 2001-05-03 Tom Tromey + + * java/lang/natRuntime.cc (init): Call add_library on the program + itself. + (_Jv_FindSymbolInExecutable): Return NULL if no library on the + list has the symbol. + + 2001-09-21 Richard Henderson + + * include/jvm.h (_Jv_VTable): Handle function descriptors for ia64; + add get_method, set_method, vtable_elt_size, new_vtable. + (_Jv_ArrayVTable): Derive from _Jv_VTable. + * resolve.cc (_Jv_PrepareClass): Use new _Jv_VTable methods. + * interpret.cc (_Jv_InterpMethod::continue1): Likewise. + * java/lang/natClassLoader.cc (_Jv_NewArrayClass): Likewise. + + 2001-09-17 Jeff Sturm + + * gnu/gcj/convert/UnicodeToBytes.java (write): Write work buffer + starting from zero offset. + 2001-08-19 Release Manager * GCC 3.0.1 Released. *************** *** 100,106 **** 20010617 Release Manager ! * GCC 3.0 Released. 2001-06-13 Tom Tromey --- 147,153 ---- 20010617 Release Manager ! * GCC 3.0 Released. 2001-06-13 Tom Tromey *************** *** 162,184 **** 2001-05-29 Andrew Haley ! * include/i386-signal.h (MAKE_THROW_FRAME): Don't fix up frame ! pointer: the dwarf unwinder in libgcc will do everything that's ! needed. ! (HANDLE_DIVIDE_OVERFLOW): Tidy. Don't mess with stack frames any ! more than we absolutely need to. ! * configure.host (EXCEPTIONSPEC): Remove libgcj_sjlj on Alpha. ! * configure.in (SIGNAL_HANDLER): Use include/dwarf2-signal.h on ! Alpha. ! (SIGNAL_HANDLER): Test "$enable_sjlj_exceptions", not ! "$libgcj_sjlj". ! * configure: Rebuilt. ! * include/dwarf2-signal.h (MAKE_THROW_FRAME): Adjust PC ! for Alpha. ! (SIGNAL_HANDLER): Use siginfo style handler. ! (INIT_SEGV): Likewise. ! (INIT_FPE): Likewise. ! * include/ppc-signal.h: Delete whole file. 2001-05-23 Jeff Sturm --- 209,231 ---- 2001-05-29 Andrew Haley ! * include/i386-signal.h (MAKE_THROW_FRAME): Don't fix up frame ! pointer: the dwarf unwinder in libgcc will do everything that's ! needed. ! (HANDLE_DIVIDE_OVERFLOW): Tidy. Don't mess with stack frames any ! more than we absolutely need to. ! * configure.host (EXCEPTIONSPEC): Remove libgcj_sjlj on Alpha. ! * configure.in (SIGNAL_HANDLER): Use include/dwarf2-signal.h on ! Alpha. ! (SIGNAL_HANDLER): Test "$enable_sjlj_exceptions", not ! "$libgcj_sjlj". ! * configure: Rebuilt. ! * include/dwarf2-signal.h (MAKE_THROW_FRAME): Adjust PC ! for Alpha. ! (SIGNAL_HANDLER): Use siginfo style handler. ! (INIT_SEGV): Likewise. ! (INIT_FPE): Likewise. ! * include/ppc-signal.h: Delete whole file. 2001-05-23 Jeff Sturm *************** *** 214,220 **** * include/dwarf2-signal.h: New file. * configure.in (SYSDEP_SOURCES): Add dwarf2-signal.h for PPC. * configure.host (EXCEPTIONSPEC): Don't use sjlj on PPC. ! * configure: Rebuilt. 2001-05-19 Bryce McKinlay --- 261,267 ---- * include/dwarf2-signal.h: New file. * configure.in (SYSDEP_SOURCES): Add dwarf2-signal.h for PPC. * configure.host (EXCEPTIONSPEC): Don't use sjlj on PPC. ! * configure: Rebuilt. 2001-05-19 Bryce McKinlay diff -Nrc3pad gcc-3.0.1/libjava/gnu/gcj/convert/IOConverter.java gcc-3.0.2/libjava/gnu/gcj/convert/IOConverter.java *** gcc-3.0.1/libjava/gnu/gcj/convert/IOConverter.java Wed Nov 1 09:00:01 2000 --- gcc-3.0.2/libjava/gnu/gcj/convert/IOConverter.java Fri Sep 28 23:07:30 2001 *************** public abstract class IOConverter *** 27,32 **** --- 27,37 ---- // Manually maintained aliases. Note that the value must be our // canonical name. hash.put ("ISO-Latin-1", "8859_1"); + // On Solaris the default encoding, as returned by nl_langinfo(), + // is `646' (aka ASCII), but the Solaris iconv_open() doesn't + // understand that. We work around the problem by adding an + // explicit alias for Solaris users. + hash.put ("646", "ASCII"); // All aliases after this point are automatically generated by the // `encodings.pl' script. Run it to make any corrections. hash.put ("ANSI_X3.4-1968", "ASCII"); diff -Nrc3pad gcc-3.0.1/libjava/gnu/gcj/convert/UnicodeToBytes.java gcc-3.0.2/libjava/gnu/gcj/convert/UnicodeToBytes.java *** gcc-3.0.1/libjava/gnu/gcj/convert/UnicodeToBytes.java Sun Sep 10 17:35:51 2000 --- gcc-3.0.2/libjava/gnu/gcj/convert/UnicodeToBytes.java Mon Sep 17 21:04:32 2001 *************** public abstract class UnicodeToBytes ext *** 120,125 **** work = new char[inlength]; int srcEnd = inpos + (inlength > work.length ? work.length : inlength); str.getChars(inpos, srcEnd, work, 0); ! return write(work, inpos, inlength); } } --- 120,125 ---- work = new char[inlength]; int srcEnd = inpos + (inlength > work.length ? work.length : inlength); str.getChars(inpos, srcEnd, work, 0); ! return write(work, 0, srcEnd - inpos); } } diff -Nrc3pad gcc-3.0.1/libjava/include/jvm.h gcc-3.0.2/libjava/include/jvm.h *** gcc-3.0.1/libjava/include/jvm.h Fri Mar 23 11:12:19 2001 --- gcc-3.0.2/libjava/include/jvm.h Fri Sep 21 18:34:48 2001 *************** details. */ *** 27,36 **** /* Structure of the virtual table. */ struct _Jv_VTable { jclass clas; void *gc_descr; ! void *method[1]; ! void *get_finalizer() { return method[0]; } }; // Number of virtual methods on object. FIXME: it sucks that we have --- 27,61 ---- /* Structure of the virtual table. */ struct _Jv_VTable { + #ifdef __ia64__ jclass clas; + unsigned long : 64; void *gc_descr; ! unsigned long : 64; ! ! typedef struct { void *pc, *gp; } vtable_elt; ! #else ! jclass clas; ! void *gc_descr; ! ! typedef void *vtable_elt; ! #endif ! ! // This must be last, as derived classes "extend" this by ! // adding new data members. ! vtable_elt method[1]; ! ! #ifdef __ia64__ ! void *get_method(int i) { return &method[i]; } ! void set_method(int i, void *fptr) { method[i] = *(vtable_elt *)fptr; } ! #else ! void *get_method(int i) { return method[i]; } ! void set_method(int i, void *fptr) { method[i] = fptr; } ! #endif ! ! void *get_finalizer() { return get_method(0); } ! static size_t vtable_elt_size() { return sizeof(vtable_elt); } ! static _Jv_VTable *new_vtable (int count); }; // Number of virtual methods on object. FIXME: it sucks that we have *************** struct _Jv_VTable *** 38,49 **** #define NUM_OBJECT_METHODS 5 // This structure is the type of an array's vtable. ! struct _Jv_ArrayVTable { ! jclass clas; ! void *gc_descr; ! void *method[NUM_OBJECT_METHODS]; ! void *get_finalizer() { return method[0]; } }; union _Jv_word --- 63,71 ---- #define NUM_OBJECT_METHODS 5 // This structure is the type of an array's vtable. ! struct _Jv_ArrayVTable : public _Jv_VTable { ! vtable_elt extra_method[NUM_OBJECT_METHODS - 1]; }; union _Jv_word *************** void *_Jv_AllocBytesChecked (jsize size) *** 162,167 **** --- 184,201 ---- extern "C" void JvRunMain (jclass klass, int argc, const char **argv); void _Jv_RunMain (const char* name, int argc, const char **argv, bool is_jar); + + // Delayed until after _Jv_AllocBytes is declared. + // + // Note that we allocate this as unscanned memory -- the vtables + // are handled specially by the GC. + + inline _Jv_VTable * + _Jv_VTable::new_vtable (int count) + { + size_t size = sizeof(_Jv_VTable) + (count - 1) * vtable_elt_size (); + return (_Jv_VTable *) _Jv_AllocBytes (size); + } // This function is used to determine the hash code of an object. inline jint diff -Nrc3pad gcc-3.0.1/libjava/interpret.cc gcc-3.0.2/libjava/interpret.cc *** gcc-3.0.1/libjava/interpret.cc Sun May 13 00:10:25 2001 --- gcc-3.0.2/libjava/interpret.cc Fri Sep 21 18:34:48 2001 *************** void _Jv_InterpMethod::continue1 (_Jv_In *** 691,697 **** { jobject rcv = sp[0].o; _Jv_VTable *table = *(_Jv_VTable**)rcv; ! fun = (void (*)()) table->method[rmeth->vtable_index]; } } goto perform_invoke; --- 691,697 ---- { jobject rcv = sp[0].o; _Jv_VTable *table = *(_Jv_VTable**)rcv; ! fun = (void (*)()) table->get_method(rmeth->vtable_index); } } goto perform_invoke; diff -Nrc3pad gcc-3.0.1/libjava/java/lang/natClass.cc gcc-3.0.2/libjava/java/lang/natClass.cc *** gcc-3.0.1/libjava/java/lang/natClass.cc Wed Jul 18 11:08:57 2001 --- gcc-3.0.2/libjava/java/lang/natClass.cc Sat Sep 29 20:50:39 2001 *************** java::lang::Class::getMethods (void) *** 624,629 **** --- 624,632 ---- jboolean java::lang::Class::isAssignableFrom (jclass klass) { + // Arguments may not have been initialized, given ".class" syntax. + _Jv_InitClass (this); + _Jv_InitClass (klass); return _Jv_IsAssignableFrom (this, klass); } *************** java::lang::Class::isInstance (jobject o *** 632,637 **** --- 635,641 ---- { if (! obj) return false; + _Jv_InitClass (this); return _Jv_IsAssignableFrom (this, JV_CLASS (obj)); } *************** _Jv_LookupInterfaceMethodIdx (jclass kla *** 905,914 **** jboolean _Jv_IsAssignableFrom (jclass target, jclass source) { - // Arguments may not have been initialized, given ".class" syntax. - _Jv_InitClass (target); - _Jv_InitClass (source); - if (source == target) return true; --- 909,914 ---- *************** _Jv_IsAssignableFrom (jclass target, jcl *** 955,962 **** return false; return true; } ! else if (source->ancestors != NULL ! && source->depth >= target->depth && source->ancestors[source->depth - target->depth] == target) return true; --- 955,963 ---- return false; return true; } ! else if (source->ancestors != NULL ! && target->ancestors != NULL ! && source->depth >= target->depth && source->ancestors[source->depth - target->depth] == target) return true; diff -Nrc3pad gcc-3.0.1/libjava/java/lang/natClassLoader.cc gcc-3.0.2/libjava/java/lang/natClassLoader.cc *** gcc-3.0.1/libjava/java/lang/natClassLoader.cc Sun May 20 09:24:41 2001 --- gcc-3.0.2/libjava/java/lang/natClassLoader.cc Fri Sep 21 18:34:48 2001 *************** _Jv_NewArrayClass (jclass element, java: *** 592,611 **** JvAssert (ObjectClass.vtable_method_count == NUM_OBJECT_METHODS); int dm_count = ObjectClass.vtable_method_count; ! // Create a new vtable by copying Object's vtable (except the ! // class pointer, of course). Note that we allocate this as ! // unscanned memory -- the vtables are handled specially by the ! // GC. ! int size = (sizeof (_Jv_VTable) + ((dm_count - 1) * sizeof (void *))); _Jv_VTable *vtable; if (array_vtable) vtable = array_vtable; else ! vtable = (_Jv_VTable *) _Jv_AllocBytes (size); vtable->clas = array_class; - memcpy (vtable->method, ObjectClass.vtable->method, - dm_count * sizeof (void *)); vtable->gc_descr = ObjectClass.vtable->gc_descr; array_class->vtable = vtable; array_class->vtable_method_count = ObjectClass.vtable_method_count; --- 592,608 ---- JvAssert (ObjectClass.vtable_method_count == NUM_OBJECT_METHODS); int dm_count = ObjectClass.vtable_method_count; ! // Create a new vtable by copying Object's vtable. _Jv_VTable *vtable; if (array_vtable) vtable = array_vtable; else ! vtable = _Jv_VTable::new_vtable (dm_count); vtable->clas = array_class; vtable->gc_descr = ObjectClass.vtable->gc_descr; + for (int i = 0; i < dm_count; ++i) + vtable->set_method (i, ObjectClass.vtable->get_method (i)); + array_class->vtable = vtable; array_class->vtable_method_count = ObjectClass.vtable_method_count; diff -Nrc3pad gcc-3.0.1/libjava/java/lang/natRuntime.cc gcc-3.0.2/libjava/java/lang/natRuntime.cc *** gcc-3.0.1/libjava/java/lang/natRuntime.cc Sun Mar 11 23:33:57 2001 --- gcc-3.0.2/libjava/java/lang/natRuntime.cc Fri Sep 28 23:07:30 2001 *************** _Jv_FindSymbolInExecutable (const char * *** 69,75 **** return r; } ! return lt_dlsym (NULL, symname); } #endif /* USE_LTDL */ --- 69,75 ---- return r; } ! return NULL; } #endif /* USE_LTDL */ *************** java::lang::Runtime::init (void) *** 191,196 **** --- 191,199 ---- finalize_on_exit = false; #ifdef USE_LTDL lt_dlinit (); + lt_dlhandle self = lt_dlopen (NULL); + if (self != NULL) + add_library (self); #endif } diff -Nrc3pad gcc-3.0.1/libjava/jni.cc gcc-3.0.2/libjava/jni.cc *** gcc-3.0.1/libjava/jni.cc Thu May 3 09:55:34 2001 --- gcc-3.0.2/libjava/jni.cc Fri Sep 28 23:07:29 2001 *************** _Jv_JNI_NewLocalRef (JNIEnv *env, jobjec *** 281,296 **** // Try to find an open slot somewhere in the topmost frame. _Jv_JNI_LocalFrame *frame = env->locals; bool done = false, set = false; ! while (frame != NULL && ! done) { for (int i = 0; i < frame->size; ++i) ! if (frame->vec[i] == NULL) ! { ! set = true; ! done = true; ! frame->vec[i] = obj; ! break; ! } } if (! set) --- 281,303 ---- // Try to find an open slot somewhere in the topmost frame. _Jv_JNI_LocalFrame *frame = env->locals; bool done = false, set = false; ! for (; frame != NULL && ! done; frame = frame->next) { for (int i = 0; i < frame->size; ++i) ! { ! if (frame->vec[i] == NULL) ! { ! set = true; ! done = true; ! frame->vec[i] = obj; ! break; ! } ! } ! ! // If we found a slot, or if the frame we just searched is the ! // mark frame, then we are done. ! if (done || frame->marker != MARK_NONE) ! break; } if (! set) diff -Nrc3pad gcc-3.0.1/libjava/libltdl/ChangeLog gcc-3.0.2/libjava/libltdl/ChangeLog *** gcc-3.0.1/libjava/libltdl/ChangeLog Sun Aug 19 14:08:32 2001 --- gcc-3.0.2/libjava/libltdl/ChangeLog Tue Oct 23 10:20:53 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/libjava/name-finder.cc gcc-3.0.2/libjava/name-finder.cc *** gcc-3.0.1/libjava/name-finder.cc Wed Nov 22 21:45:47 2000 --- gcc-3.0.2/libjava/name-finder.cc Tue Oct 16 00:45:20 2001 *************** _Jv_name_finder::lookup (void *p) *** 145,155 **** if (dladdr (p, &dl_info)) { ! strncpy (file_name, dl_info.dli_fname, sizeof file_name); ! strncpy (method_name, dl_info.dli_sname, sizeof method_name); /* Don't trust dladdr() if the address is from the main program. */ ! if (_Jv_argv == NULL || strcmp (file_name, _Jv_argv[0]) != 0) return true; } } --- 145,159 ---- if (dladdr (p, &dl_info)) { ! if (dl_info.dli_fname) ! strncpy (file_name, dl_info.dli_fname, sizeof file_name); ! if (dl_info.dli_sname) ! strncpy (method_name, dl_info.dli_sname, sizeof method_name); /* Don't trust dladdr() if the address is from the main program. */ ! if (dl_info.dli_fname != NULL ! && dl_info.dli_sname != NULL ! && (_Jv_argv == NULL || strcmp (file_name, _Jv_argv[0]) != 0)) return true; } } diff -Nrc3pad gcc-3.0.1/libjava/resolve.cc gcc-3.0.2/libjava/resolve.cc *** gcc-3.0.1/libjava/resolve.cc Fri Mar 23 11:12:19 2001 --- gcc-3.0.2/libjava/resolve.cc Wed Oct 3 01:31:50 2001 *************** _Jv_PrepareClass(jclass klass) *** 698,706 **** clz->vtable_method_count = vtable_count; /* allocate vtable structure */ ! _Jv_VTable *vtable = (_Jv_VTable*) ! _Jv_AllocBytesChecked (sizeof (_Jv_VTable) ! + (sizeof (void*) * (vtable_count))); vtable->clas = clz; vtable->gc_descr = _Jv_BuildGCDescr(clz); --- 698,704 ---- clz->vtable_method_count = vtable_count; /* allocate vtable structure */ ! _Jv_VTable *vtable = _Jv_VTable::new_vtable (vtable_count); vtable->clas = clz; vtable->gc_descr = _Jv_BuildGCDescr(clz); *************** _Jv_PrepareClass(jclass klass) *** 714,722 **** /* copy super class' vtable entries. */ if (effective_superclass && effective_superclass->vtable) ! memcpy ((void*)&vtable->method[0], ! (void*)&effective_superclass->vtable->method[0], ! sizeof (void*) * effective_superclass->vtable_method_count); } /* now, install our own vtable entries, reprise... */ --- 712,719 ---- /* copy super class' vtable entries. */ if (effective_superclass && effective_superclass->vtable) ! for (int i = 0; i < effective_superclass->vtable_method_count; ++i) ! vtable->set_method (i, effective_superclass->vtable->get_method (i)); } /* now, install our own vtable entries, reprise... */ *************** _Jv_PrepareClass(jclass klass) *** 737,745 **** throw_internal_error ("vtable problem..."); if (clz->interpreted_methods[i] == 0) ! vtable->method[index] = (void*)&_Jv_abstractMethodError; else ! vtable->method[index] = this_meth->ncode; } } --- 734,742 ---- throw_internal_error ("vtable problem..."); if (clz->interpreted_methods[i] == 0) ! vtable->set_method(index, (void*)&_Jv_abstractMethodError); else ! vtable->set_method(index, this_meth->ncode); } } diff -Nrc3pad gcc-3.0.1/libjava/testsuite/ChangeLog gcc-3.0.2/libjava/testsuite/ChangeLog *** gcc-3.0.1/libjava/testsuite/ChangeLog Sun Aug 19 14:08:33 2001 --- gcc-3.0.2/libjava/testsuite/ChangeLog Tue Oct 23 10:20:57 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/libobjc/ChangeLog gcc-3.0.2/libobjc/ChangeLog *** gcc-3.0.1/libobjc/ChangeLog Sun Aug 19 14:08:34 2001 --- gcc-3.0.2/libobjc/ChangeLog Tue Oct 23 10:21:02 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/libstdc++-v3/ChangeLog gcc-3.0.2/libstdc++-v3/ChangeLog *** gcc-3.0.1/libstdc++-v3/ChangeLog Sun Aug 19 14:08:35 2001 --- gcc-3.0.2/libstdc++-v3/ChangeLog Tue Oct 23 10:21:07 2001 *************** *** 1,6 **** ! 2001-08-19 Release Manager ! * GCC 3.0.1 Released. 2001-08-19 Release Manager --- 1,250 ---- ! 2001-10-23 Release Manager ! * GCC 3.0.2 Released. ! ! 2001-10-19 Phil Edwards ! ! Bulk documentation merge (copy) from trunk. ! * docs/html/17_intro/COPYING.DOC, docs/html/17_intro/license.html, ! docs/html/22_locale/messages.html, docs/html/ext/lwg-active.html, ! docs/html/ext/lwg-defects.html, docs/html/ext/sgiexts.html: New. ! ! * docs/html/configopts.html, docs/html/documentation.html, ! docs/html/explanations.html, docs/html/install.html, ! docs/html/17_intro/howto.html, docs/html/18_support/howto.html, ! docs/html/19_diagnostics/howto.html, docs/html/20_util/howto.html, ! docs/html/21_strings/howto.html, docs/html/22_locale/codecvt.html, ! docs/html/22_locale/ctype.html, docs/html/22_locale/howto.html, ! docs/html/22_locale/locale.html, docs/html/23_containers/howto.html, ! docs/html/24_iterators/howto.html, docs/html/25_algorithms/howto.html, ! docs/html/26_numerics/howto.html, docs/html/27_io/howto.html, ! docs/html/ext/howto.html, docs/html/faq/index.html, ! docs/html/faq/index.txt: Merge from trunk. ! ! 2001-10-07 Joseph S. Myers ! ! * docs/html/22_locale/locale.html: Fix spelling error of ! "separate" as "seperate". ! ! 2001-10-02 Rainer Orth ! ! * testsuite/lib/libstdc++-v3-dg.exp (libstdc++-v3-init): Use ! correct multilib builddir. ! Properly locate libgcc_s. ! ! 2001-09-25 Phil Edwards ! ! * testsuite/21_strings/c_strings.cc (test01, test02): Increase ! `carray' size. ! ! 2001-09-14 Phil Edwards ! ! * docs/html/17_intro/headers_cc.txt: "Sync"/copy real file over. ! * docs/html/17_intro/howto.html: Spacing and HTML markup fixes. ! * docs/html/18_support/howto.html: It won't compile; it's not code. ! * docs/html/19_diagnostics/howto.html: Point diagram seekers to ! doxygen'd pages. ! * docs/html/22_locale/howto.html: Comment for future work. ! * docs/html/23_containers/howto.html: More comments. ! * docs/html/25_algorithms/howto.html: It's a comment, not a ! blunt command to the reader. (English grammar.) ! ! 2001-09-12 Gabriel Dos Reis ! ! * include/bits/std_limits.h (numeric_limits::radix, ! numeric_limits::epsilon: Fix thinko. ! ! 2001-09-10 Benjamin Kosnik ! ! * src/Makefile.am (libstdc___la_LDFLAGS): Increase revision number. ! * src/Makefile.in: Regenerate. ! ! 2001-09-04 Benjamin Kosnik ! ! * include/c_std/bits/std_c*.h: Don't use include_next. ! ! 2001-09-05 Phil Edwards ! ! * Makefile.am: The testsuite directory never needs to be made here. ! * Makefile.in: Regenerate. ! * include/Makefile.in: Regenerate. ! * libio/Makefile.in: Regenerate. ! * libmath/Makefile.in: Regenerate. ! * libsupc++/Makefile.in: Regenerate. ! * po/Makefile.in: Regenerate. ! * src/Makefile.in: Regenerate. ! * testsuite/Makefile.in: Regenerate. ! ! 2001-08-30 Loren J. Rittle ! ! PR libstdc++/4082 ! 2001-08-13 H.J. Lu (hjl@gnu.org) ! ! * testsuite/lib/libstdc++-v3-dg.exp (libstdc++-v3-copy-files): ! New. Copy files. ! (libstdc++-v3-init): Use it. ! ! 2001-08-28 Loren J. Rittle ! ! PR libstdc++/4082 ! * include/Makefile.am: Use toplevel_srcdir to refer to src files ! outside this component. ! * include/Makefile.in: Regenerate. ! ! 2001-08-28 Phil Edwards ! ! Move testsuite_hooks changes onto the branch. This is the 08-06 ! patch (on trunk) from pme, plus the 08-09 change from bkoz and the ! 08-10 fix from ljrittle, accumulated into one. ! * acconfig.h (_GLIBCPP_MEM_LIMITS): Define. ! * acinclude.m4 (GLIBCPP_CONFIGURE_TESTSUITE): New macro, calls... ! (GLIBCPP_CHECK_SETRLIMIT): ...this new macro, which also uses... ! (GLIBCPP_CHECK_SETRLIMIT_ancilliary): ...this new macro. ! * configure.in: Call GLIBCPP_CONFIGURE_TESTSUITE. ! * aclocal.m4: Regenerate. ! * config.h.in: Regenerate. ! * configure: Regenerate. ! * testsuite/lib/libstdc++-v3-dg.exp: Download new header instead ! of old header. ! ! * testsuite/debug_assert.h: Removed; contents merged into... ! * testsuite/testsuite_hooks.h: ...here. New file. ! * testsuite/17_intro/header_ciso646.cc: No longer include ! debug_assert.h, include testsuite_hooks.h instead. ! * testsuite/17_intro/header_fstream.cc: Likewise. ! * testsuite/17_intro/header_iomanip.cc: Likewise. ! * testsuite/17_intro/header_ios.cc: Likewise. ! * testsuite/17_intro/header_iosfwd.cc: Likewise. ! * testsuite/17_intro/header_iostream.cc: Likewise. ! * testsuite/17_intro/header_istream.cc: Likewise. ! * testsuite/17_intro/header_ostream.cc: Likewise. ! * testsuite/17_intro/header_sstream.cc: Likewise. ! * testsuite/17_intro/header_streambuf.cc: Likewise. ! * testsuite/18_support/numeric_limits.cc: Likewise. ! * testsuite/19_diagnostics/stdexceptions.cc: Likewise. ! * testsuite/20_util/auto_ptr.cc: Likewise. ! * testsuite/21_strings/append.cc: Likewise. ! * testsuite/21_strings/capacity.cc: Likewise. ! * testsuite/21_strings/char_traits_requirements.cc: Likewise. ! * testsuite/21_strings/compare.cc: Likewise. ! * testsuite/21_strings/ctor_copy_dtor.cc: Likewise. ! * testsuite/21_strings/element_access.cc: Likewise. ! * testsuite/21_strings/find.cc: Likewise. ! * testsuite/21_strings/insert.cc: Likewise. ! * testsuite/21_strings/inserters_extractors.cc: Likewise. ! * testsuite/21_strings/invariants.cc: Likewise. ! * testsuite/21_strings/nonmember.cc: Likewise. ! * testsuite/21_strings/operations.cc: Likewise. ! * testsuite/21_strings/replace.cc: Likewise. ! * testsuite/21_strings/rfind.cc: Likewise. ! * testsuite/21_strings/substr.cc: Likewise. ! * testsuite/22_locale/codecvt_char_char.cc: Likewise. ! * testsuite/22_locale/codecvt_unicode_char.cc: Likewise. ! * testsuite/22_locale/codecvt_unicode_wchar_t.cc: Likewise. ! * testsuite/22_locale/codecvt_wchar_t_char.cc: Likewise. ! * testsuite/22_locale/ctor_copy_dtor.cc: Likewise. ! * testsuite/22_locale/ctype_char_members.cc: Likewise. ! * testsuite/22_locale/ctype_wchar_t_members.cc: Likewise. ! * testsuite/22_locale/facet.cc: Likewise. ! * testsuite/22_locale/global_templates.cc: Likewise. ! * testsuite/22_locale/members.cc: Likewise. ! * testsuite/22_locale/numpunct_byname.cc: Likewise. ! * testsuite/22_locale/numpunct_char_members.cc: Likewise. ! * testsuite/22_locale/operators.cc: Likewise. ! * testsuite/22_locale/static_members.cc: Likewise. ! * testsuite/23_containers/bitset_ctor.cc: Likewise. ! * testsuite/23_containers/bitset_members.cc: Likewise. ! * testsuite/23_containers/bitset_shift.cc: Likewise. ! * testsuite/23_containers/map_insert.cc: Likewise. ! * testsuite/23_containers/vector_capacity.cc: Likewise. ! * testsuite/23_containers/vector_ctor.cc: Likewise. ! * testsuite/23_containers/vector_element_access.cc: Likewise. ! * testsuite/23_containers/vector_modifiers.cc: Likewise. ! * testsuite/24_iterators/istreambuf_iterator.cc: Likewise. ! * testsuite/24_iterators/iterator.cc: Likewise. ! * testsuite/24_iterators/ostreambuf_iterator.cc: Likewise. ! * testsuite/25_algorithms/lower_bound.cc: Likewise. ! * testsuite/25_algorithms/min_max.cc: Likewise. ! * testsuite/26_numerics/c_math.cc: Likewise. ! * testsuite/26_numerics/complex_inserters_extractors.cc: Likewise. ! * testsuite/26_numerics/complex_value.cc: Likewise. ! * testsuite/27_io/filebuf.cc: Likewise. ! * testsuite/27_io/filebuf_members.cc: Likewise. ! * testsuite/27_io/filebuf_virtuals.cc: Likewise. ! * testsuite/27_io/fpos.cc: Likewise. ! * testsuite/27_io/fstream_members.cc: Likewise. ! * testsuite/27_io/ifstream_members.cc: Likewise. ! * testsuite/27_io/ios_base_callbacks.cc: Likewise. ! * testsuite/27_io/ios_base_members_static.cc: Likewise. ! * testsuite/27_io/ios_base_storage.cc: Likewise. ! * testsuite/27_io/ios_ctor.cc: Likewise. ! * testsuite/27_io/ios_init.cc: Likewise. ! * testsuite/27_io/ios_manip_basefield.cc: Likewise. ! * testsuite/27_io/ios_manip_fmtflags.cc: Likewise. ! * testsuite/27_io/ios_members.cc: Likewise. ! * testsuite/27_io/istream_extractor_arith.cc: Likewise. ! * testsuite/27_io/istream_extractor_char.cc: Likewise. ! * testsuite/27_io/istream_extractor_other.cc: Likewise. ! * testsuite/27_io/istream_manip.cc: Likewise. ! * testsuite/27_io/istream_seeks.cc: Likewise. ! * testsuite/27_io/istream_sentry.cc: Likewise. ! * testsuite/27_io/istream_unformatted.cc: Likewise. ! * testsuite/27_io/istringstream_members.cc: Likewise. ! * testsuite/27_io/narrow_stream_objects.cc: Likewise. ! * testsuite/27_io/ofstream_members.cc: Likewise. ! * testsuite/27_io/ostream_inserter_arith.cc: Likewise. ! * testsuite/27_io/ostream_inserter_char.cc: Likewise. ! * testsuite/27_io/ostream_inserter_other.cc: Likewise. ! * testsuite/27_io/ostream_manip.cc: Likewise. ! * testsuite/27_io/ostream_seeks.cc: Likewise. ! * testsuite/27_io/ostream_unformatted.cc: Likewise. ! * testsuite/27_io/ostringstream_members.cc: Likewise. ! * testsuite/27_io/streambuf.cc: Likewise. ! * testsuite/27_io/stringbuf.cc: Likewise. ! * testsuite/27_io/stringbuf_virtuals.cc: Likewise. ! * testsuite/27_io/stringstream.cc: Likewise. ! * testsuite/27_io/stringstream_members.cc: Likewise. ! * testsuite/27_io/wide_stream_objects.cc: Likewise. ! ! 2001-08-28 Loren J. Rittle ! ! * testsuite/23_containers/map_insert.cc: (For 3.0 branch only:) ! Include debug_assert.h not testsuite_hooks.h. ! ! 2001-08-27 Phil Edwards ! ! PR libstdc++/4143 ! * acinclude.m4 (GLIBCPP_EXPORT_INSTALL_INFO): Handle enable/disable ! correctly for version-specific-runtime-libs. ! * aclocal.m4: Regenerate. ! * configure: Regenerate. ! ! 2001-08-24 Benjamin Kosnik ! ! * include/Makefile.am (install-data-local): Don't install Makefile. ! * include/Makefile.in: Regenerated. ! ! 2001-08-24 Jan van Male ! ! * docs/html/17_intro/C++STYLE: Fix typo. ! ! 2001-08-24 Phil Edwards ! ! * docs/html/23_containers/howto.html: Describe implementation of ! insertion with hints. ! ! 2001-08-24 Sylvain Pion ! Phil Edwards ! ! PR libstdc++/3349 ! * include/bits/stl_tree.h (insert_unique): Revert last change. ! Values inserted at begin() must be less, not greater, than *begin()'s. ! * testsuite/23_containers/map_insert.cc: New file. ! ! 2001-08-23 David Edelsohn ! ! * config/os/gnu-linux/bits/os_defines.h: Correct __s390__ definitions. ! Set __powerpc__ long double definition based on __LONG_DOUBLE_128__. 2001-08-19 Release Manager *************** *** 8,17 **** 2001-08-17 Loren J. Rittle ! bootstrap/3963 ! * include/Makefile.am: Use relative file path in rule to allow ! colon in $(objdir). ! * include/Makefile.in: Rebuilt. 2001-08-16 Franz Sirl --- 252,261 ---- 2001-08-17 Loren J. Rittle ! bootstrap/3963 ! * include/Makefile.am: Use relative file path in rule to allow ! colon in $(objdir). ! * include/Makefile.in: Rebuilt. 2001-08-16 Franz Sirl *************** *** 77,100 **** 2001-08-10 Gabriel Dos Reis Mark Mitchell ! * include/bits/std_limits.h: New file. ! * include/Makefile.am (bits_headers): Add std_limits.h ! (all-local): std_limits.h is no longer built. ! (${target_builddir}/std_limits.h): Remove. ! * include/Makefile.in: Regenerate. ! * src/limits.cc: New file. ! * src/Makefile.am (sources): Add limits.cc in replacement of ! limitsMEMBERS.cc. ! * src/Makefile.in: Regenerate. 2001-08-09 David Edelsohn ! * config/os/aix/bits/os_defines.h: Define std_limits.h macros. ! * config/os/generic/bits/os_defines.h: Likewise. ! * config/os/gnu-linux/bits/os_defines.h: Likewise. ! * config/os/hpux/bits/os_defines.h: Likewise. ! * config/os/irix/irix6.5/bits/os_defines.h: Likewise. ! * config/os/solaris/solaris2.7/bits/os_defines.h: Likewise. 2001-08-10 Gunter Winkler --- 321,344 ---- 2001-08-10 Gabriel Dos Reis Mark Mitchell ! * include/bits/std_limits.h: New file. ! * include/Makefile.am (bits_headers): Add std_limits.h ! (all-local): std_limits.h is no longer built. ! (${target_builddir}/std_limits.h): Remove. ! * include/Makefile.in: Regenerate. ! * src/limits.cc: New file. ! * src/Makefile.am (sources): Add limits.cc in replacement of ! limitsMEMBERS.cc. ! * src/Makefile.in: Regenerate. 2001-08-09 David Edelsohn ! * config/os/aix/bits/os_defines.h: Define std_limits.h macros. ! * config/os/generic/bits/os_defines.h: Likewise. ! * config/os/gnu-linux/bits/os_defines.h: Likewise. ! * config/os/hpux/bits/os_defines.h: Likewise. ! * config/os/irix/irix6.5/bits/os_defines.h: Likewise. ! * config/os/solaris/solaris2.7/bits/os_defines.h: Likewise. 2001-08-10 Gunter Winkler *************** *** 105,110 **** --- 349,360 ---- * src/gen-num-limits.cc: Use __LONG_LONG_MAX__. + 2001-07-30 Benjamin Kosnik + + * configure.target: Remove mips from cpu table. + * config/cpu/mips/bits/atomicity.h: Remove generic + versions. Comment sgidefs include. + 2001-07-26 Gabriel Dos Reis * acinclude.m4: CHECK_MATH_DECL_AND_LINKAGE for hypot, hypotf, *************** *** 241,250 **** 2001-07-10 Gabriel Dos Reis ! * acinclude.m4: Don't AC_REPLACE_MATHFUNCS expf and atan2f. ! * aclocal.m4: Regenerate. ! * configure: Same. ! 2001-07-09 Phil Edwards * docs/html/configopts.html: Fix thinko. --- 491,500 ---- 2001-07-10 Gabriel Dos Reis ! * acinclude.m4: Don't AC_REPLACE_MATHFUNCS expf and atan2f. ! * aclocal.m4: Regenerate. ! * configure: Same. ! 2001-07-09 Phil Edwards * docs/html/configopts.html: Fix thinko. *************** *** 404,412 **** * libmath/Makefile.am (libmath_la_SOURCES): Add stubs.c. * libmath/Makefile.in: Regenerate. ! 20010617 Release Manager ! * GCC 3.0 Released. 2001-06-14 Nathan Sidwell --- 654,670 ---- * libmath/Makefile.am (libmath_la_SOURCES): Add stubs.c. * libmath/Makefile.in: Regenerate. ! 2001-06-19 Benjamin Kosnik ! * include/c_std/bits/std_cwchar.h: Include ctime. ! * testsuite/17_intro/header_cwchar.cc : Check. ! ! * include/c_std/bits/std_cwctype.h: Inject wctype. ! * testsuite/17_intro/header_cwctype.cc: Update. ! ! 2001-06-17 Release Manager ! ! * GCC 3.0 Released. 2001-06-14 Nathan Sidwell *************** *** 675,681 **** * include/bits/c++config: Cleanup threading configuration macros. In particular, define __STL_GTHREADS macro which controls... * include/bits/stl_threads.h: ...a brand new gthr.h-based ! configuration here. * config/c_io_stdio.h: Include staged gthr.h instead of local thread configuration file. Always use __gthread_mutex_t --- 933,939 ---- * include/bits/c++config: Cleanup threading configuration macros. In particular, define __STL_GTHREADS macro which controls... * include/bits/stl_threads.h: ...a brand new gthr.h-based ! configuration here. * config/c_io_stdio.h: Include staged gthr.h instead of local thread configuration file. Always use __gthread_mutex_t *************** *** 837,843 **** 2001-05-30 Rainer Orth ! * testsuite/lib/libstdc++-v3-dg.exp (libstdc++-v3-init): Use get_multilibs to find gcc. 2001-05-30 Phil Edwards --- 1095,1101 ---- 2001-05-30 Rainer Orth ! * testsuite/lib/libstdc++-v3-dg.exp (libstdc++-v3-init): Use get_multilibs to find gcc. 2001-05-30 Phil Edwards *************** *** 890,896 **** Phil Edwards Alexandre Oliva ! * acinclude.m4 (GLIBCPP_EXPORT_INSTALL_INFO): Set glibcpp_srcdir in an amd-safe manner. Revert glibcpp_prefixdir. 2001-05-25 Gabriel Dos Reis --- 1148,1154 ---- Phil Edwards Alexandre Oliva ! * acinclude.m4 (GLIBCPP_EXPORT_INSTALL_INFO): Set glibcpp_srcdir in an amd-safe manner. Revert glibcpp_prefixdir. 2001-05-25 Gabriel Dos Reis *************** *** 1019,1027 **** 2001-05-18 Angela Marie Thomas ! * testsuite/lib/libstdc++-v3-dg.exp (libstdc++-v3-init): Set flags ! appropriately for remote testing and testing installed files without ! a build dir. 2001-05-18 Benjamin Kosnik --- 1277,1285 ---- 2001-05-18 Angela Marie Thomas ! * testsuite/lib/libstdc++-v3-dg.exp (libstdc++-v3-init): Set flags ! appropriately for remote testing and testing installed files without ! a build dir. 2001-05-18 Benjamin Kosnik *************** *** 1044,1056 **** 2001-05-18 Angela Marie Thomas ! * testsuite/lib/libstdc++-v3-dg.exp (libstdc++-v3-dg-test): Set ! output_file based on the name of the testcase. 2001-05-18 Angela Marie Thomas ! * testsuite/lib/libstdc++-v3-dg.exp (libstdc++-v3-init): Build ! gluefile and use it if needs_status_wrapper is set. 2001-05-18 Alexandre Oliva --- 1302,1314 ---- 2001-05-18 Angela Marie Thomas ! * testsuite/lib/libstdc++-v3-dg.exp (libstdc++-v3-dg-test): Set ! output_file based on the name of the testcase. 2001-05-18 Angela Marie Thomas ! * testsuite/lib/libstdc++-v3-dg.exp (libstdc++-v3-init): Build ! gluefile and use it if needs_status_wrapper is set. 2001-05-18 Alexandre Oliva *************** *** 1078,1088 **** 001-05-15 Zack Weinberg ! * testsuite/21_strings/inserters_extractors.cc, ! testsuite/27_io/istream_unformatted.cc, ! testsuite/27_io/stringstream.cc: ! Replace multi-line string constants with C89-style ! concatenated string constants. 2001-05-14 Richard Henderson --- 1336,1346 ---- 001-05-15 Zack Weinberg ! * testsuite/21_strings/inserters_extractors.cc, ! testsuite/27_io/istream_unformatted.cc, ! testsuite/27_io/stringstream.cc: ! Replace multi-line string constants with C89-style ! concatenated string constants. 2001-05-14 Richard Henderson *************** *** 1274,1280 **** 2001-04-24 Peter Schmid ! * include/ext/slist: Include required header files. 2001-04-23 Loren J. Rittle --- 1532,1538 ---- 2001-04-24 Peter Schmid ! * include/ext/slist: Include required header files. 2001-04-23 Loren J. Rittle *************** *** 1444,1451 **** 2001-04-06 Joe Buck ! * stl_algobase.h (std::equal): avoid use of possibly-undefined ! operator != (one line patch). 2001-04-06 Benjamin Kosnik --- 1702,1709 ---- 2001-04-06 Joe Buck ! * stl_algobase.h (std::equal): avoid use of possibly-undefined ! operator != (one line patch). 2001-04-06 Benjamin Kosnik *************** *** 1458,1465 **** 2001-04-06 Gabriel Dos Reis ! * include/c_std/bits/std_cmath.h: Get rid of C99 math macros. ! * testsuite/26_numerics/c99_macros.cc: Add test. 2001-04-06 Phil Edwards --- 1716,1723 ---- 2001-04-06 Gabriel Dos Reis ! * include/c_std/bits/std_cmath.h: Get rid of C99 math macros. ! * testsuite/26_numerics/c99_macros.cc: Add test. 2001-04-06 Phil Edwards *************** *** 1559,1566 **** 2001-04-03 Peter Schmid ! * include/backward/fstream.h: Expose streampos to global ! namespace. 2001-04-03 Peter Schmid --- 1817,1824 ---- 2001-04-03 Peter Schmid ! * include/backward/fstream.h: Expose streampos to global ! namespace. 2001-04-03 Peter Schmid *************** *** 1763,1769 **** 2001-03-26 Peter Schmid * libstdc++-v3/tests_flags.in: Change the order of libstdc++ ! and libc 2001-03-26 Benjamin Kosnik --- 2021,2027 ---- 2001-03-26 Peter Schmid * libstdc++-v3/tests_flags.in: Change the order of libstdc++ ! and libc 2001-03-26 Benjamin Kosnik *************** *** 1833,1839 **** 2001-03-21 Theodore Papadopoulo ! * include/bits/basic_file.h: Fix typos in comments. 2001-03-20 Richard Henderson --- 2091,2097 ---- 2001-03-21 Theodore Papadopoulo ! * include/bits/basic_file.h: Fix typos in comments. 2001-03-20 Richard Henderson diff -Nrc3pad gcc-3.0.1/libstdc++-v3/Makefile.am gcc-3.0.2/libstdc++-v3/Makefile.am *** gcc-3.0.1/libstdc++-v3/Makefile.am Thu Jul 26 00:51:00 2001 --- gcc-3.0.2/libstdc++-v3/Makefile.am Wed Sep 5 15:44:19 2001 *************** mkinstalldirs = $(SHELL) $(toplevel_srcd *** 35,47 **** # compile time, execution time, and binary size. check-script: $(top_builddir)/mkcheck -(chmod + $(top_builddir)/mkcheck; \ - test -d testsuite || (mkdir testsuite; chmod u+w testsuite); \ cd testsuite; \ @glibcpp_builddir@/mkcheck 0) check-script-install: $(top_builddir)/mkcheck -(chmod + $(top_builddir)/mkcheck; \ - test -d testsuite || (mkdir testsuite; chmod u+w testsuite); \ cd testsuite; \ @glibcpp_builddir@/mkcheck 1) --- 35,45 ---- diff -Nrc3pad gcc-3.0.1/libstdc++-v3/Makefile.in gcc-3.0.2/libstdc++-v3/Makefile.in *** gcc-3.0.1/libstdc++-v3/Makefile.in Mon Aug 13 15:21:28 2001 --- gcc-3.0.2/libstdc++-v3/Makefile.in Mon Sep 10 13:10:25 2001 *************** mostlyclean distclean maintainer-clean *** 426,438 **** # compile time, execution time, and binary size. check-script: $(top_builddir)/mkcheck -(chmod + $(top_builddir)/mkcheck; \ - test -d testsuite || (mkdir testsuite; chmod u+w testsuite); \ cd testsuite; \ @glibcpp_builddir@/mkcheck 0) check-script-install: $(top_builddir)/mkcheck -(chmod + $(top_builddir)/mkcheck; \ - test -d testsuite || (mkdir testsuite; chmod u+w testsuite); \ cd testsuite; \ @glibcpp_builddir@/mkcheck 1) --- 426,436 ---- diff -Nrc3pad gcc-3.0.1/libstdc++-v3/acconfig.h gcc-3.0.2/libstdc++-v3/acconfig.h *** gcc-3.0.1/libstdc++-v3/acconfig.h Fri Jun 8 13:08:09 2001 --- gcc-3.0.2/libstdc++-v3/acconfig.h Tue Aug 28 14:18:19 2001 *************** *** 21,26 **** --- 21,29 ---- // Define if code specialized for wchar_t should be used. #undef _GLIBCPP_USE_WCHAR_T + // Define if using setrlimit to limit memory usage during 'make check'. + #undef _GLIBCPP_MEM_LIMITS + // Define if you have the atan2f function. #undef _GLIBCPP_HAVE_ATAN2F diff -Nrc3pad gcc-3.0.1/libstdc++-v3/acinclude.m4 gcc-3.0.2/libstdc++-v3/acinclude.m4 *** gcc-3.0.1/libstdc++-v3/acinclude.m4 Thu Jul 26 11:24:58 2001 --- gcc-3.0.2/libstdc++-v3/acinclude.m4 Tue Aug 28 14:18:19 2001 *************** AC_MSG_RESULT($gxx_include_dir) *** 1584,1607 **** AC_MSG_CHECKING([for --enable-version-specific-runtime-libs]) AC_ARG_ENABLE(version-specific-runtime-libs, [ --enable-version-specific-runtime-libs Specify that runtime libraries should be installed in a compiler-specific directory ], ! [ version_specific_libs=yes ! # Need the gcc compiler version to know where to install libraries ! # and header files if --enable-version-specific-runtime-libs option ! # is selected. ! changequote(,)dnl ! gcc_version_trigger=${srcdir}/../gcc/version.c ! gcc_version_full=`grep version_string ${gcc_version_trigger} | sed -e 's/.*\"\([^\"]*\)\".*/\1/'` ! gcc_version=`echo ${gcc_version_full} | sed -e 's/\([^ ]*\) .*/\1/'` ! gxx_include_dir='$(libdir)/gcc-lib/$(target_alias)/'${gcc_version}/include/g++ ! glibcpp_toolexecdir='$(libdir)/gcc-lib/$(target_alias)' ! glibcpp_toolexeclibdir='$(toolexecdir)/'${gcc_version} ! changequote([,])dnl ! ],version_specific_libs=no) AC_MSG_RESULT($version_specific_libs) # Default case for install directory for include files. ! if test x"$version_specific_libs" = x"no" \ ! && test x"$gxx_include_dir" = x"no"; then gxx_include_dir='$(prefix)'/include/g++-${libstdcxx_interface} fi --- 1584,1615 ---- AC_MSG_CHECKING([for --enable-version-specific-runtime-libs]) AC_ARG_ENABLE(version-specific-runtime-libs, [ --enable-version-specific-runtime-libs Specify that runtime libraries should be installed in a compiler-specific directory ], ! [case "$enableval" in ! yes) version_specific_libs=yes ;; ! no) version_specific_libs=no ;; ! *) AC_MSG_ERROR([Unknown argument to enable/disable version-specific libs]);; ! esac], ! version_specific_libs=no)dnl ! # Option set, now we can test it. AC_MSG_RESULT($version_specific_libs) + if test $version_specific_libs = yes; then + # Need the gcc compiler version to know where to install libraries + # and header files if --enable-version-specific-runtime-libs option + # is selected. + changequote(,)dnl + gcc_version_trigger=${srcdir}/../gcc/version.c + gcc_version_full=`grep version_string ${gcc_version_trigger} | sed -e 's/.*\"\([^\"]*\)\".*/\1/'` + gcc_version=`echo ${gcc_version_full} | sed -e 's/\([^ ]*\) .*/\1/'` + gxx_include_dir='$(libdir)/gcc-lib/$(target_alias)/'${gcc_version}/include/g++ + glibcpp_toolexecdir='$(libdir)/gcc-lib/$(target_alias)' + glibcpp_toolexeclibdir='$(toolexecdir)/'${gcc_version}'$(MULTISUBDIR)' + changequote([,])dnl + fi + # Default case for install directory for include files. ! if test $version_specific_libs = no && ! test $gxx_include_dir = no; then gxx_include_dir='$(prefix)'/include/g++-${libstdcxx_interface} fi *************** dnl string, '#' otherwise *** 1753,1758 **** --- 1761,1822 ---- fi AC_SUBST(ifGNUmake) ]) + + + dnl Check for headers for, and arguments to, the setrlimit() function. + dnl Used only in testsuite_hooks.h. + AC_DEFUN(GLIBCPP_CHECK_SETRLIMIT_ancilliary, [ + AC_TRY_COMPILE([#include + #include + ], [ int f = RLIMIT_$1 ; ], + [glibcpp_mresult=1], [glibcpp_mresult=0]) + AC_DEFINE_UNQUOTED(HAVE_MEMLIMIT_$1, $glibcpp_mresult, + [Only used in build directory testsuite_hooks.h.]) + ]) + AC_DEFUN(GLIBCPP_CHECK_SETRLIMIT, [ + setrlimit_have_headers=yes + AC_CHECK_HEADERS(sys/resource.h unistd.h, + [], + setrlimit_have_headers=no) + # If don't have the headers, then we can't run the tests now, and we + # won't be seeing any of these during testsuite compilation. + if test $setrlimit_have_headers = yes; then + # Can't do these in a loop, else the resulting syntax is wrong. + GLIBCPP_CHECK_SETRLIMIT_ancilliary(DATA) + GLIBCPP_CHECK_SETRLIMIT_ancilliary(RSS) + GLIBCPP_CHECK_SETRLIMIT_ancilliary(VMEM) + GLIBCPP_CHECK_SETRLIMIT_ancilliary(AS) + + # Check for rlimit, setrlimit. + AC_CACHE_VAL(ac_setrlimit, [ + AC_TRY_COMPILE([#include + #include + ], + [ struct rlimit r; setrlimit(0, &r);], + [ac_setrlimit=yes], [ac_setrlimit=no]) + ]) + fi + + AC_MSG_CHECKING([for testsuite memory limit support]) + if test $setrlimit_have_headers = yes && test $ac_setrlimit = yes; then + ac_mem_limits=yes + AC_DEFINE(_GLIBCPP_MEM_LIMITS) + else + ac_mem_limits=no + fi + AC_MSG_RESULT($ac_mem_limits) + ]) + + + dnl + dnl Does any necessary configuration of the testsuite directory. Generates + dnl the testsuite_hooks.h header. + dnl + dnl GLIBCPP_CONFIGURE_TESTSUITE [no args] + AC_DEFUN(GLIBCPP_CONFIGURE_TESTSUITE, [ + GLIBCPP_CHECK_SETRLIMIT + ]) + sinclude(../libtool.m4) dnl The lines below arrange for aclocal not to bring an installed diff -Nrc3pad gcc-3.0.1/libstdc++-v3/aclocal.m4 gcc-3.0.2/libstdc++-v3/aclocal.m4 *** gcc-3.0.1/libstdc++-v3/aclocal.m4 Thu Jul 26 11:24:58 2001 --- gcc-3.0.2/libstdc++-v3/aclocal.m4 Tue Aug 28 14:18:20 2001 *************** AC_MSG_RESULT($gxx_include_dir) *** 1596,1619 **** AC_MSG_CHECKING([for --enable-version-specific-runtime-libs]) AC_ARG_ENABLE(version-specific-runtime-libs, [ --enable-version-specific-runtime-libs Specify that runtime libraries should be installed in a compiler-specific directory ], ! [ version_specific_libs=yes ! # Need the gcc compiler version to know where to install libraries ! # and header files if --enable-version-specific-runtime-libs option ! # is selected. ! changequote(,)dnl ! gcc_version_trigger=${srcdir}/../gcc/version.c ! gcc_version_full=`grep version_string ${gcc_version_trigger} | sed -e 's/.*\"\([^\"]*\)\".*/\1/'` ! gcc_version=`echo ${gcc_version_full} | sed -e 's/\([^ ]*\) .*/\1/'` ! gxx_include_dir='$(libdir)/gcc-lib/$(target_alias)/'${gcc_version}/include/g++ ! glibcpp_toolexecdir='$(libdir)/gcc-lib/$(target_alias)' ! glibcpp_toolexeclibdir='$(toolexecdir)/'${gcc_version} ! changequote([,])dnl ! ],version_specific_libs=no) AC_MSG_RESULT($version_specific_libs) # Default case for install directory for include files. ! if test x"$version_specific_libs" = x"no" \ ! && test x"$gxx_include_dir" = x"no"; then gxx_include_dir='$(prefix)'/include/g++-${libstdcxx_interface} fi --- 1596,1627 ---- AC_MSG_CHECKING([for --enable-version-specific-runtime-libs]) AC_ARG_ENABLE(version-specific-runtime-libs, [ --enable-version-specific-runtime-libs Specify that runtime libraries should be installed in a compiler-specific directory ], ! [case "$enableval" in ! yes) version_specific_libs=yes ;; ! no) version_specific_libs=no ;; ! *) AC_MSG_ERROR([Unknown argument to enable/disable version-specific libs]);; ! esac], ! version_specific_libs=no)dnl ! # Option set, now we can test it. AC_MSG_RESULT($version_specific_libs) + if test $version_specific_libs = yes; then + # Need the gcc compiler version to know where to install libraries + # and header files if --enable-version-specific-runtime-libs option + # is selected. + changequote(,)dnl + gcc_version_trigger=${srcdir}/../gcc/version.c + gcc_version_full=`grep version_string ${gcc_version_trigger} | sed -e 's/.*\"\([^\"]*\)\".*/\1/'` + gcc_version=`echo ${gcc_version_full} | sed -e 's/\([^ ]*\) .*/\1/'` + gxx_include_dir='$(libdir)/gcc-lib/$(target_alias)/'${gcc_version}/include/g++ + glibcpp_toolexecdir='$(libdir)/gcc-lib/$(target_alias)' + glibcpp_toolexeclibdir='$(toolexecdir)/'${gcc_version}'$(MULTISUBDIR)' + changequote([,])dnl + fi + # Default case for install directory for include files. ! if test $version_specific_libs = no && ! test $gxx_include_dir = no; then gxx_include_dir='$(prefix)'/include/g++-${libstdcxx_interface} fi *************** dnl string, '#' otherwise *** 1765,1770 **** --- 1773,1834 ---- fi AC_SUBST(ifGNUmake) ]) + + + dnl Check for headers for, and arguments to, the setrlimit() function. + dnl Used only in testsuite_hooks.h. + AC_DEFUN(GLIBCPP_CHECK_SETRLIMIT_ancilliary, [ + AC_TRY_COMPILE([#include + #include + ], [ int f = RLIMIT_$1 ; ], + [glibcpp_mresult=1], [glibcpp_mresult=0]) + AC_DEFINE_UNQUOTED(HAVE_MEMLIMIT_$1, $glibcpp_mresult, + [Only used in build directory testsuite_hooks.h.]) + ]) + AC_DEFUN(GLIBCPP_CHECK_SETRLIMIT, [ + setrlimit_have_headers=yes + AC_CHECK_HEADERS(sys/resource.h unistd.h, + [], + setrlimit_have_headers=no) + # If don't have the headers, then we can't run the tests now, and we + # won't be seeing any of these during testsuite compilation. + if test $setrlimit_have_headers = yes; then + # Can't do these in a loop, else the resulting syntax is wrong. + GLIBCPP_CHECK_SETRLIMIT_ancilliary(DATA) + GLIBCPP_CHECK_SETRLIMIT_ancilliary(RSS) + GLIBCPP_CHECK_SETRLIMIT_ancilliary(VMEM) + GLIBCPP_CHECK_SETRLIMIT_ancilliary(AS) + + # Check for rlimit, setrlimit. + AC_CACHE_VAL(ac_setrlimit, [ + AC_TRY_COMPILE([#include + #include + ], + [ struct rlimit r; setrlimit(0, &r);], + [ac_setrlimit=yes], [ac_setrlimit=no]) + ]) + fi + + AC_MSG_CHECKING([for testsuite memory limit support]) + if test $setrlimit_have_headers = yes && test $ac_setrlimit = yes; then + ac_mem_limits=yes + AC_DEFINE(_GLIBCPP_MEM_LIMITS) + else + ac_mem_limits=no + fi + AC_MSG_RESULT($ac_mem_limits) + ]) + + + dnl + dnl Does any necessary configuration of the testsuite directory. Generates + dnl the testsuite_hooks.h header. + dnl + dnl GLIBCPP_CONFIGURE_TESTSUITE [no args] + AC_DEFUN(GLIBCPP_CONFIGURE_TESTSUITE, [ + GLIBCPP_CHECK_SETRLIMIT + ]) + sinclude(../libtool.m4) dnl The lines below arrange for aclocal not to bring an installed diff -Nrc3pad gcc-3.0.1/libstdc++-v3/config/cpu/mips/bits/atomicity.h gcc-3.0.2/libstdc++-v3/config/cpu/mips/bits/atomicity.h *** gcc-3.0.1/libstdc++-v3/config/cpu/mips/bits/atomicity.h Wed Jul 25 22:04:48 2001 --- gcc-3.0.2/libstdc++-v3/config/cpu/mips/bits/atomicity.h Mon Sep 10 13:11:05 2001 *************** *** 1,4 **** ! // Low-level functions for atomic operations. Mips version. // Copyright (C) 2001 Free Software Foundation, Inc. // --- 1,4 ---- ! // Low-level functions for atomic operations. MIPS II version. // Copyright (C) 2001 Free Software Foundation, Inc. // *************** *** 30,41 **** #ifndef _BITS_ATOMICITY_H #define _BITS_ATOMICITY_H 1 ! #include typedef int _Atomic_word; - #if (_MIPS_ISA >= _MIPS_ISA_MIPS2) - static inline int __attribute__ ((unused)) __exchange_and_add (volatile _Atomic_word *__mem, int __val) --- 30,40 ---- #ifndef _BITS_ATOMICITY_H #define _BITS_ATOMICITY_H 1 ! // #include ! // #ifdef (_MIPS_ISA_MIPS2) typedef int _Atomic_word; static inline int __attribute__ ((unused)) __exchange_and_add (volatile _Atomic_word *__mem, int __val) *************** __compare_and_swap (volatile long int *_ *** 102,138 **** return __ret; } - - #else /* (_MIPS_ISA >= _MIPS_ISA_MIPS2) */ - - static inline int - __attribute__ ((unused)) - __exchange_and_add (volatile _Atomic_word *__mem, int __val) - { - int __result = *__mem; - *__mem += __val; - return __result; - } - - static inline void - __attribute__ ((unused)) - __atomic_add (volatile _Atomic_word *__mem, int __val) - { - *__mem += __val; - } - - static inline int - __attribute__ ((unused)) - __compare_and_swap (volatile long int *__p, long int __oldval, - long int __newval) - { - if (*__p != __oldval) - return 0; - - *__p = __newval; - return 1; - } - - #endif /* !(_MIPS_ISA >= _MIPS_ISA_MIPS2) */ #endif /* atomicity.h */ --- 101,105 ---- diff -Nrc3pad gcc-3.0.1/libstdc++-v3/config/os/gnu-linux/bits/os_defines.h gcc-3.0.2/libstdc++-v3/config/os/gnu-linux/bits/os_defines.h *** gcc-3.0.1/libstdc++-v3/config/os/gnu-linux/bits/os_defines.h Wed Aug 15 08:48:36 2001 --- gcc-3.0.2/libstdc++-v3/config/os/gnu-linux/bits/os_defines.h Fri Aug 24 10:38:36 2001 *************** typedef __loff_t __off64_t; *** 63,82 **** # define __NO_STRING_INLINES # endif ! #if defined (__powerpc__) || defined (__s390__) || defined (__s390x__) #define __glibcpp_wchar_t_is_signed true #endif ! ! #if defined (__alpha__) || defined (__powerpc64__) || (defined (__sparc__) && defined(__arch64__)) || defined (__s390__) || defined (__s390x__) #define __glibcpp_long_bits 64 #endif ! ! #if defined (__alpha__) || defined (__powerpc64__) #define __glibcpp_long_double_bits 64 #endif ! #if defined (__mc68000__) #define __glibcpp_long_double_bits 96 #endif #endif --- 63,83 ---- # define __NO_STRING_INLINES # endif ! #if defined (__powerpc__) || defined (__s390__) #define __glibcpp_wchar_t_is_signed true #endif ! ! #if defined (__alpha__) || defined (__powerpc64__) || (defined (__sparc__) && defined(__arch64__)) || defined (__s390x__) #define __glibcpp_long_bits 64 #endif ! ! #if defined (__alpha__) || (defined (__powerpc__) && !defined (__LONG_DOUBLE_128__)) || defined (__s390__) #define __glibcpp_long_double_bits 64 #endif ! #if defined (__mc68000__) #define __glibcpp_long_double_bits 96 #endif #endif + diff -Nrc3pad gcc-3.0.1/libstdc++-v3/config.h.in gcc-3.0.2/libstdc++-v3/config.h.in *** gcc-3.0.1/libstdc++-v3/config.h.in Thu Jul 26 11:24:58 2001 --- gcc-3.0.2/libstdc++-v3/config.h.in Tue Aug 28 14:18:20 2001 *************** *** 21,26 **** --- 21,29 ---- // Define if code specialized for wchar_t should be used. #undef _GLIBCPP_USE_WCHAR_T + // Define if using setrlimit to limit memory usage during 'make check'. + #undef _GLIBCPP_MEM_LIMITS + // Define if mbstate_t exists in wchar.h. #undef HAVE_MBSTATE_T *************** *** 681,686 **** --- 684,692 ---- /* Define if you have the header file. */ #undef HAVE_SYS_MACHINE_H + /* Define if you have the header file. */ + #undef HAVE_SYS_RESOURCE_H + /* Define if you have the header file. */ #undef HAVE_UNISTD_H *************** *** 701,706 **** --- 707,724 ---- /* Define if sigsetjmp is available. */ #undef HAVE_SIGSETJMP + + /* Only used in build directory testsuite_hooks.h. */ + #undef HAVE_MEMLIMIT_DATA + + /* Only used in build directory testsuite_hooks.h. */ + #undef HAVE_MEMLIMIT_RSS + + /* Only used in build directory testsuite_hooks.h. */ + #undef HAVE_MEMLIMIT_VMEM + + /* Only used in build directory testsuite_hooks.h. */ + #undef HAVE_MEMLIMIT_AS // // Systems that have certain non-standard functions prefixed with an diff -Nrc3pad gcc-3.0.1/libstdc++-v3/configure gcc-3.0.2/libstdc++-v3/configure *** gcc-3.0.1/libstdc++-v3/configure Mon Aug 13 15:21:28 2001 --- gcc-3.0.2/libstdc++-v3/configure Mon Sep 10 13:10:25 2001 *************** fi *** 16873,16878 **** --- 16873,17078 ---- fi + # Enable/configure some pieces which may require knowledge about the + # compiler situation (native/cross), which we just finished discovering. + + + setrlimit_have_headers=yes + for ac_hdr in sys/resource.h unistd.h + do + ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'` + echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6 + echo "configure:16886: checking for $ac_hdr" >&5 + if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then + echo $ac_n "(cached) $ac_c" 1>&6 + else + cat > conftest.$ac_ext < + EOF + ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" + { (eval echo configure:16896: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } + ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` + if test -z "$ac_err"; then + rm -rf conftest* + eval "ac_cv_header_$ac_safe=yes" + else + echo "$ac_err" >&5 + echo "configure: failed program was:" >&5 + cat conftest.$ac_ext >&5 + rm -rf conftest* + eval "ac_cv_header_$ac_safe=no" + fi + rm -f conftest* + fi + if eval "test \"`echo '$ac_cv_header_'$ac_safe`\" = yes"; then + echo "$ac_t""yes" 1>&6 + ac_tr_hdr=HAVE_`echo $ac_hdr | sed 'y%abcdefghijklmnopqrstuvwxyz./-%ABCDEFGHIJKLMNOPQRSTUVWXYZ___%'` + cat >> confdefs.h <&6 + setrlimit_have_headers=no + fi + done + + # If don't have the headers, then we can't run the tests now, and we + # won't be seeing any of these during testsuite compilation. + if test $setrlimit_have_headers = yes; then + # Can't do these in a loop, else the resulting syntax is wrong. + + cat > conftest.$ac_ext < + #include + + int main() { + int f = RLIMIT_DATA ; + ; return 0; } + EOF + if { (eval echo configure:16938: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then + rm -rf conftest* + glibcpp_mresult=1 + else + echo "configure: failed program was:" >&5 + cat conftest.$ac_ext >&5 + rm -rf conftest* + glibcpp_mresult=0 + fi + rm -f conftest* + cat >> confdefs.h < conftest.$ac_ext < + #include + + int main() { + int f = RLIMIT_RSS ; + ; return 0; } + EOF + if { (eval echo configure:16964: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then + rm -rf conftest* + glibcpp_mresult=1 + else + echo "configure: failed program was:" >&5 + cat conftest.$ac_ext >&5 + rm -rf conftest* + glibcpp_mresult=0 + fi + rm -f conftest* + cat >> confdefs.h < conftest.$ac_ext < + #include + + int main() { + int f = RLIMIT_VMEM ; + ; return 0; } + EOF + if { (eval echo configure:16990: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then + rm -rf conftest* + glibcpp_mresult=1 + else + echo "configure: failed program was:" >&5 + cat conftest.$ac_ext >&5 + rm -rf conftest* + glibcpp_mresult=0 + fi + rm -f conftest* + cat >> confdefs.h < conftest.$ac_ext < + #include + + int main() { + int f = RLIMIT_AS ; + ; return 0; } + EOF + if { (eval echo configure:17016: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then + rm -rf conftest* + glibcpp_mresult=1 + else + echo "configure: failed program was:" >&5 + cat conftest.$ac_ext >&5 + rm -rf conftest* + glibcpp_mresult=0 + fi + rm -f conftest* + cat >> confdefs.h <&6 + else + + cat > conftest.$ac_ext < + #include + + int main() { + struct rlimit r; setrlimit(0, &r); + ; return 0; } + EOF + if { (eval echo configure:17047: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then + rm -rf conftest* + ac_setrlimit=yes + else + echo "configure: failed program was:" >&5 + cat conftest.$ac_ext >&5 + rm -rf conftest* + ac_setrlimit=no + fi + rm -f conftest* + + fi + + fi + + echo $ac_n "checking for testsuite memory limit support""... $ac_c" 1>&6 + echo "configure:17063: checking for testsuite memory limit support" >&5 + if test $setrlimit_have_headers = yes && test $ac_setrlimit = yes; then + ac_mem_limits=yes + cat >> confdefs.h <<\EOF + #define _GLIBCPP_MEM_LIMITS 1 + EOF + + else + ac_mem_limits=no + fi + echo "$ac_t""$ac_mem_limits" 1>&6 + + + # Propagate the target-specific source directories through the build chain. OS_INC_SRCDIR=$os_include_dir/bits ATOMICITY_INC_SRCDIR=$ATOMICITYH/bits *************** rm -f confcache *** 16943,16959 **** ac_safe=`echo "locale.h" | sed 'y%./+-%__p_%'` echo $ac_n "checking for locale.h""... $ac_c" 1>&6 ! echo "configure:16947: checking for locale.h" >&5 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:16957: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* --- 17143,17159 ---- ac_safe=`echo "locale.h" | sed 'y%./+-%__p_%'` echo $ac_n "checking for locale.h""... $ac_c" 1>&6 ! echo "configure:17147: checking for locale.h" >&5 if eval "test \"`echo '$''{'ac_cv_header_$ac_safe'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < EOF ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out" ! { (eval echo configure:17157: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; } ac_err=`grep -v '^ *+' conftest.out | grep -v "^conftest.${ac_ext}\$"` if test -z "$ac_err"; then rm -rf conftest* *************** if eval "test \"`echo '$ac_cv_header_'$a *** 16971,16989 **** echo "$ac_t""yes" 1>&6 echo $ac_n "checking for LC_MESSAGES""... $ac_c" 1>&6 ! echo "configure:16975: checking for LC_MESSAGES" >&5 if eval "test \"`echo '$''{'ac_cv_val_LC_MESSAGES'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < int main() { return LC_MESSAGES ; return 0; } EOF ! if { (eval echo configure:16987: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* ac_cv_val_LC_MESSAGES=yes else --- 17171,17189 ---- echo "$ac_t""yes" 1>&6 echo $ac_n "checking for LC_MESSAGES""... $ac_c" 1>&6 ! echo "configure:17175: checking for LC_MESSAGES" >&5 if eval "test \"`echo '$''{'ac_cv_val_LC_MESSAGES'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else cat > conftest.$ac_ext < int main() { return LC_MESSAGES ; return 0; } EOF ! if { (eval echo configure:17187: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then rm -rf conftest* ac_cv_val_LC_MESSAGES=yes else *************** esac *** 17036,17048 **** glibcpp_prefixdir=${prefix} echo $ac_n "checking for interface version number""... $ac_c" 1>&6 ! echo "configure:17040: checking for interface version number" >&5 libstdcxx_interface=$INTERFACE echo "$ac_t""$libstdcxx_interface" 1>&6 # Process the option --with-gxx-include-dir= echo $ac_n "checking for --with-gxx-include-dir""... $ac_c" 1>&6 ! echo "configure:17046: checking for --with-gxx-include-dir" >&5 # Check whether --with-gxx-include-dir or --without-gxx-include-dir was given. if test "${with_gxx_include_dir+set}" = set; then withval="$with_gxx_include_dir" --- 17236,17248 ---- glibcpp_prefixdir=${prefix} echo $ac_n "checking for interface version number""... $ac_c" 1>&6 ! echo "configure:17240: checking for interface version number" >&5 libstdcxx_interface=$INTERFACE echo "$ac_t""$libstdcxx_interface" 1>&6 # Process the option --with-gxx-include-dir= echo $ac_n "checking for --with-gxx-include-dir""... $ac_c" 1>&6 ! echo "configure:17246: checking for --with-gxx-include-dir" >&5 # Check whether --with-gxx-include-dir or --without-gxx-include-dir was given. if test "${with_gxx_include_dir+set}" = set; then withval="$with_gxx_include_dir" *************** echo "$ac_t""$gxx_include_dir" 1>&6 *** 17066,17095 **** # Process the option "--enable-version-specific-runtime-libs" echo $ac_n "checking for --enable-version-specific-runtime-libs""... $ac_c" 1>&6 ! echo "configure:17070: checking for --enable-version-specific-runtime-libs" >&5 # Check whether --enable-version-specific-runtime-libs or --disable-version-specific-runtime-libs was given. if test "${enable_version_specific_runtime_libs+set}" = set; then enableval="$enable_version_specific_runtime_libs" ! version_specific_libs=yes ! # Need the gcc compiler version to know where to install libraries ! # and header files if --enable-version-specific-runtime-libs option ! # is selected. ! gcc_version_trigger=${srcdir}/../gcc/version.c ! gcc_version_full=`grep version_string ${gcc_version_trigger} | sed -e 's/.*\"\([^\"]*\)\".*/\1/'` ! gcc_version=`echo ${gcc_version_full} | sed -e 's/\([^ ]*\) .*/\1/'` ! gxx_include_dir='$(libdir)/gcc-lib/$(target_alias)/'${gcc_version}/include/g++ ! glibcpp_toolexecdir='$(libdir)/gcc-lib/$(target_alias)' ! glibcpp_toolexeclibdir='$(toolexecdir)/'${gcc_version} ! else version_specific_libs=no fi ! echo "$ac_t""$version_specific_libs" 1>&6 # Default case for install directory for include files. ! if test x"$version_specific_libs" = x"no" \ ! && test x"$gxx_include_dir" = x"no"; then gxx_include_dir='$(prefix)'/include/g++-${libstdcxx_interface} fi --- 17266,17301 ---- # Process the option "--enable-version-specific-runtime-libs" echo $ac_n "checking for --enable-version-specific-runtime-libs""... $ac_c" 1>&6 ! echo "configure:17270: checking for --enable-version-specific-runtime-libs" >&5 # Check whether --enable-version-specific-runtime-libs or --disable-version-specific-runtime-libs was given. if test "${enable_version_specific_runtime_libs+set}" = set; then enableval="$enable_version_specific_runtime_libs" ! case "$enableval" in ! yes) version_specific_libs=yes ;; ! no) version_specific_libs=no ;; ! *) { echo "configure: error: Unknown argument to enable/disable version-specific libs" 1>&2; exit 1; };; ! esac else version_specific_libs=no fi ! # Option set, now we can test it. echo "$ac_t""$version_specific_libs" 1>&6 + if test $version_specific_libs = yes; then + # Need the gcc compiler version to know where to install libraries + # and header files if --enable-version-specific-runtime-libs option + # is selected. + gcc_version_trigger=${srcdir}/../gcc/version.c + gcc_version_full=`grep version_string ${gcc_version_trigger} | sed -e 's/.*\"\([^\"]*\)\".*/\1/'` + gcc_version=`echo ${gcc_version_full} | sed -e 's/\([^ ]*\) .*/\1/'` + gxx_include_dir='$(libdir)/gcc-lib/$(target_alias)/'${gcc_version}/include/g++ + glibcpp_toolexecdir='$(libdir)/gcc-lib/$(target_alias)' + glibcpp_toolexeclibdir='$(toolexecdir)/'${gcc_version}'$(MULTISUBDIR)' + fi + # Default case for install directory for include files. ! if test $version_specific_libs = no && ! test $gxx_include_dir = no; then gxx_include_dir='$(prefix)'/include/g++-${libstdcxx_interface} fi *************** if test x"$glibcpp_toolexecdir" = x"no"; *** 17106,17112 **** fi echo $ac_n "checking for install location""... $ac_c" 1>&6 ! echo "configure:17110: checking for install location" >&5 echo "$ac_t""$gxx_include_dir" 1>&6 --- 17312,17318 ---- fi echo $ac_n "checking for install location""... $ac_c" 1>&6 ! echo "configure:17316: checking for install location" >&5 echo "$ac_t""$gxx_include_dir" 1>&6 diff -Nrc3pad gcc-3.0.1/libstdc++-v3/configure.in gcc-3.0.2/libstdc++-v3/configure.in *** gcc-3.0.1/libstdc++-v3/configure.in Mon Aug 13 15:22:25 2001 --- gcc-3.0.2/libstdc++-v3/configure.in Tue Aug 28 14:19:07 2001 *************** else *** 221,226 **** --- 221,230 ---- AC_FUNC_MMAP fi + # Enable/configure some pieces which may require knowledge about the + # compiler situation (native/cross), which we just finished discovering. + GLIBCPP_CONFIGURE_TESTSUITE + # Propagate the target-specific source directories through the build chain. OS_INC_SRCDIR=$os_include_dir/bits ATOMICITY_INC_SRCDIR=$ATOMICITYH/bits diff -Nrc3pad gcc-3.0.1/libstdc++-v3/configure.target gcc-3.0.2/libstdc++-v3/configure.target *** gcc-3.0.1/libstdc++-v3/configure.target Sat Aug 18 12:23:13 2001 --- gcc-3.0.2/libstdc++-v3/configure.target Mon Sep 10 13:11:05 2001 *************** case "${target_cpu}" in *** 42,50 **** m68k | m680[246]0) cpu_include_dir="config/cpu/m68k" ;; - mips*) - cpu_include_dir="config/cpu/mips" - ;; powerpc | rs6000) cpu_include_dir="config/cpu/powerpc" ;; --- 42,47 ---- diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/17_intro/C++STYLE gcc-3.0.2/libstdc++-v3/docs/html/17_intro/C++STYLE *** gcc-3.0.1/libstdc++-v3/docs/html/17_intro/C++STYLE Tue Feb 6 16:03:20 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/17_intro/C++STYLE Fri Aug 24 13:51:32 2001 *************** Notable areas of divergence from what ma *** 91,97 **** { space = _ISspace, print = _ISprint, ! cntrl = _IScntrl, }; -NOT- enum { space = _ISspace, print = _ISprint, cntrl = _IScntrl }; --- 91,97 ---- { space = _ISspace, print = _ISprint, ! cntrl = _IScntrl }; -NOT- enum { space = _ISspace, print = _ISprint, cntrl = _IScntrl }; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/17_intro/COPYING.DOC gcc-3.0.2/libstdc++-v3/docs/html/17_intro/COPYING.DOC *** gcc-3.0.1/libstdc++-v3/docs/html/17_intro/COPYING.DOC Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/libstdc++-v3/docs/html/17_intro/COPYING.DOC Fri Oct 19 13:07:35 2001 *************** *** 0 **** --- 1,355 ---- + GNU Free Documentation License + Version 1.1, March 2000 + + Copyright (C) 2000 Free Software Foundation, Inc. + 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + + 0. PREAMBLE + + The purpose of this License is to make a manual, textbook, or other + written document "free" in the sense of freedom: to assure everyone + the effective freedom to copy and redistribute it, with or without + modifying it, either commercially or noncommercially. Secondarily, + this License preserves for the author and publisher a way to get + credit for their work, while not being considered responsible for + modifications made by others. + + This License is a kind of "copyleft", which means that derivative + works of the document must themselves be free in the same sense. It + complements the GNU General Public License, which is a copyleft + license designed for free software. + + We have designed this License in order to use it for manuals for free + software, because free software needs free documentation: a free + program should come with manuals providing the same freedoms that the + software does. But this License is not limited to software manuals; + it can be used for any textual work, regardless of subject matter or + whether it is published as a printed book. We recommend this License + principally for works whose purpose is instruction or reference. + + + 1. APPLICABILITY AND DEFINITIONS + + This License applies to any manual or other work that contains a + notice placed by the copyright holder saying it can be distributed + under the terms of this License. The "Document", below, refers to any + such manual or work. Any member of the public is a licensee, and is + addressed as "you". + + A "Modified Version" of the Document means any work containing the + Document or a portion of it, either copied verbatim, or with + modifications and/or translated into another language. + + A "Secondary Section" is a named appendix or a front-matter section of + the Document that deals exclusively with the relationship of the + publishers or authors of the Document to the Document's overall subject + (or to related matters) and contains nothing that could fall directly + within that overall subject. (For example, if the Document is in part a + textbook of mathematics, a Secondary Section may not explain any + mathematics.) The relationship could be a matter of historical + connection with the subject or with related matters, or of legal, + commercial, philosophical, ethical or political position regarding + them. + + The "Invariant Sections" are certain Secondary Sections whose titles + are designated, as being those of Invariant Sections, in the notice + that says that the Document is released under this License. + + The "Cover Texts" are certain short passages of text that are listed, + as Front-Cover Texts or Back-Cover Texts, in the notice that says that + the Document is released under this License. + + A "Transparent" copy of the Document means a machine-readable copy, + represented in a format whose specification is available to the + general public, whose contents can be viewed and edited directly and + straightforwardly with generic text editors or (for images composed of + pixels) generic paint programs or (for drawings) some widely available + drawing editor, and that is suitable for input to text formatters or + for automatic translation to a variety of formats suitable for input + to text formatters. A copy made in an otherwise Transparent file + format whose markup has been designed to thwart or discourage + subsequent modification by readers is not Transparent. A copy that is + not "Transparent" is called "Opaque". + + Examples of suitable formats for Transparent copies include plain + ASCII without markup, Texinfo input format, LaTeX input format, SGML + or XML using a publicly available DTD, and standard-conforming simple + HTML designed for human modification. Opaque formats include + PostScript, PDF, proprietary formats that can be read and edited only + by proprietary word processors, SGML or XML for which the DTD and/or + processing tools are not generally available, and the + machine-generated HTML produced by some word processors for output + purposes only. + + The "Title Page" means, for a printed book, the title page itself, + plus such following pages as are needed to hold, legibly, the material + this License requires to appear in the title page. For works in + formats which do not have any title page as such, "Title Page" means + the text near the most prominent appearance of the work's title, + preceding the beginning of the body of the text. + + + 2. VERBATIM COPYING + + You may copy and distribute the Document in any medium, either + commercially or noncommercially, provided that this License, the + copyright notices, and the license notice saying this License applies + to the Document are reproduced in all copies, and that you add no other + conditions whatsoever to those of this License. You may not use + technical measures to obstruct or control the reading or further + copying of the copies you make or distribute. However, you may accept + compensation in exchange for copies. If you distribute a large enough + number of copies you must also follow the conditions in section 3. + + You may also lend copies, under the same conditions stated above, and + you may publicly display copies. + + + 3. COPYING IN QUANTITY + + If you publish printed copies of the Document numbering more than 100, + and the Document's license notice requires Cover Texts, you must enclose + the copies in covers that carry, clearly and legibly, all these Cover + Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on + the back cover. Both covers must also clearly and legibly identify + you as the publisher of these copies. The front cover must present + the full title with all words of the title equally prominent and + visible. You may add other material on the covers in addition. + Copying with changes limited to the covers, as long as they preserve + the title of the Document and satisfy these conditions, can be treated + as verbatim copying in other respects. + + If the required texts for either cover are too voluminous to fit + legibly, you should put the first ones listed (as many as fit + reasonably) on the actual cover, and continue the rest onto adjacent + pages. + + If you publish or distribute Opaque copies of the Document numbering + more than 100, you must either include a machine-readable Transparent + copy along with each Opaque copy, or state in or with each Opaque copy + a publicly-accessible computer-network location containing a complete + Transparent copy of the Document, free of added material, which the + general network-using public has access to download anonymously at no + charge using public-standard network protocols. If you use the latter + option, you must take reasonably prudent steps, when you begin + distribution of Opaque copies in quantity, to ensure that this + Transparent copy will remain thus accessible at the stated location + until at least one year after the last time you distribute an Opaque + copy (directly or through your agents or retailers) of that edition to + the public. + + It is requested, but not required, that you contact the authors of the + Document well before redistributing any large number of copies, to give + them a chance to provide you with an updated version of the Document. + + + 4. MODIFICATIONS + + You may copy and distribute a Modified Version of the Document under + the conditions of sections 2 and 3 above, provided that you release + the Modified Version under precisely this License, with the Modified + Version filling the role of the Document, thus licensing distribution + and modification of the Modified Version to whoever possesses a copy + of it. In addition, you must do these things in the Modified Version: + + A. Use in the Title Page (and on the covers, if any) a title distinct + from that of the Document, and from those of previous versions + (which should, if there were any, be listed in the History section + of the Document). You may use the same title as a previous version + if the original publisher of that version gives permission. + B. List on the Title Page, as authors, one or more persons or entities + responsible for authorship of the modifications in the Modified + Version, together with at least five of the principal authors of the + Document (all of its principal authors, if it has less than five). + C. State on the Title page the name of the publisher of the + Modified Version, as the publisher. + D. Preserve all the copyright notices of the Document. + E. Add an appropriate copyright notice for your modifications + adjacent to the other copyright notices. + F. Include, immediately after the copyright notices, a license notice + giving the public permission to use the Modified Version under the + terms of this License, in the form shown in the Addendum below. + G. Preserve in that license notice the full lists of Invariant Sections + and required Cover Texts given in the Document's license notice. + H. Include an unaltered copy of this License. + I. Preserve the section entitled "History", and its title, and add to + it an item stating at least the title, year, new authors, and + publisher of the Modified Version as given on the Title Page. If + there is no section entitled "History" in the Document, create one + stating the title, year, authors, and publisher of the Document as + given on its Title Page, then add an item describing the Modified + Version as stated in the previous sentence. + J. Preserve the network location, if any, given in the Document for + public access to a Transparent copy of the Document, and likewise + the network locations given in the Document for previous versions + it was based on. These may be placed in the "History" section. + You may omit a network location for a work that was published at + least four years before the Document itself, or if the original + publisher of the version it refers to gives permission. + K. In any section entitled "Acknowledgements" or "Dedications", + preserve the section's title, and preserve in the section all the + substance and tone of each of the contributor acknowledgements + and/or dedications given therein. + L. Preserve all the Invariant Sections of the Document, + unaltered in their text and in their titles. Section numbers + or the equivalent are not considered part of the section titles. + M. Delete any section entitled "Endorsements". Such a section + may not be included in the Modified Version. + N. Do not retitle any existing section as "Endorsements" + or to conflict in title with any Invariant Section. + + If the Modified Version includes new front-matter sections or + appendices that qualify as Secondary Sections and contain no material + copied from the Document, you may at your option designate some or all + of these sections as invariant. To do this, add their titles to the + list of Invariant Sections in the Modified Version's license notice. + These titles must be distinct from any other section titles. + + You may add a section entitled "Endorsements", provided it contains + nothing but endorsements of your Modified Version by various + parties--for example, statements of peer review or that the text has + been approved by an organization as the authoritative definition of a + standard. + + You may add a passage of up to five words as a Front-Cover Text, and a + passage of up to 25 words as a Back-Cover Text, to the end of the list + of Cover Texts in the Modified Version. Only one passage of + Front-Cover Text and one of Back-Cover Text may be added by (or + through arrangements made by) any one entity. If the Document already + includes a cover text for the same cover, previously added by you or + by arrangement made by the same entity you are acting on behalf of, + you may not add another; but you may replace the old one, on explicit + permission from the previous publisher that added the old one. + + The author(s) and publisher(s) of the Document do not by this License + give permission to use their names for publicity for or to assert or + imply endorsement of any Modified Version. + + + 5. COMBINING DOCUMENTS + + You may combine the Document with other documents released under this + License, under the terms defined in section 4 above for modified + versions, provided that you include in the combination all of the + Invariant Sections of all of the original documents, unmodified, and + list them all as Invariant Sections of your combined work in its + license notice. + + The combined work need only contain one copy of this License, and + multiple identical Invariant Sections may be replaced with a single + copy. If there are multiple Invariant Sections with the same name but + different contents, make the title of each such section unique by + adding at the end of it, in parentheses, the name of the original + author or publisher of that section if known, or else a unique number. + Make the same adjustment to the section titles in the list of + Invariant Sections in the license notice of the combined work. + + In the combination, you must combine any sections entitled "History" + in the various original documents, forming one section entitled + "History"; likewise combine any sections entitled "Acknowledgements", + and any sections entitled "Dedications". You must delete all sections + entitled "Endorsements." + + + 6. COLLECTIONS OF DOCUMENTS + + You may make a collection consisting of the Document and other documents + released under this License, and replace the individual copies of this + License in the various documents with a single copy that is included in + the collection, provided that you follow the rules of this License for + verbatim copying of each of the documents in all other respects. + + You may extract a single document from such a collection, and distribute + it individually under this License, provided you insert a copy of this + License into the extracted document, and follow this License in all + other respects regarding verbatim copying of that document. + + + 7. AGGREGATION WITH INDEPENDENT WORKS + + A compilation of the Document or its derivatives with other separate + and independent documents or works, in or on a volume of a storage or + distribution medium, does not as a whole count as a Modified Version + of the Document, provided no compilation copyright is claimed for the + compilation. Such a compilation is called an "aggregate", and this + License does not apply to the other self-contained works thus compiled + with the Document, on account of their being thus compiled, if they + are not themselves derivative works of the Document. + + If the Cover Text requirement of section 3 is applicable to these + copies of the Document, then if the Document is less than one quarter + of the entire aggregate, the Document's Cover Texts may be placed on + covers that surround only the Document within the aggregate. + Otherwise they must appear on covers around the whole aggregate. + + + 8. TRANSLATION + + Translation is considered a kind of modification, so you may + distribute translations of the Document under the terms of section 4. + Replacing Invariant Sections with translations requires special + permission from their copyright holders, but you may include + translations of some or all Invariant Sections in addition to the + original versions of these Invariant Sections. You may include a + translation of this License provided that you also include the + original English version of this License. In case of a disagreement + between the translation and the original English version of this + License, the original English version will prevail. + + + 9. TERMINATION + + You may not copy, modify, sublicense, or distribute the Document except + as expressly provided for under this License. Any other attempt to + copy, modify, sublicense or distribute the Document is void, and will + automatically terminate your rights under this License. However, + parties who have received copies, or rights, from you under this + License will not have their licenses terminated so long as such + parties remain in full compliance. + + + 10. FUTURE REVISIONS OF THIS LICENSE + + The Free Software Foundation may publish new, revised versions + of the GNU Free Documentation License from time to time. Such new + versions will be similar in spirit to the present version, but may + differ in detail to address new problems or concerns. See + http://www.gnu.org/copyleft/. + + Each version of the License is given a distinguishing version number. + If the Document specifies that a particular numbered version of this + License "or any later version" applies to it, you have the option of + following the terms and conditions either of that specified version or + of any later version that has been published (not as a draft) by the + Free Software Foundation. If the Document does not specify a version + number of this License, you may choose any version ever published (not + as a draft) by the Free Software Foundation. + + + ADDENDUM: How to use this License for your documents + + To use this License in a document you have written, include a copy of + the License in the document and put the following copyright and + license notices just after the title page: + + Copyright (c) YEAR YOUR NAME. + Permission is granted to copy, distribute and/or modify this document + under the terms of the GNU Free Documentation License, Version 1.1 + or any later version published by the Free Software Foundation; + with the Invariant Sections being LIST THEIR TITLES, with the + Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. + A copy of the license is included in the section entitled "GNU + Free Documentation License". + + If you have no Invariant Sections, write "with no Invariant Sections" + instead of saying which ones are invariant. If you have no + Front-Cover Texts, write "no Front-Cover Texts" instead of + "Front-Cover Texts being LIST"; likewise for Back-Cover Texts. + + If your document contains nontrivial examples of program code, we + recommend releasing these examples in parallel under your choice of + free software license, such as the GNU General Public License, + to permit their use in free software. diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/17_intro/headers_cc.txt gcc-3.0.2/libstdc++-v3/docs/html/17_intro/headers_cc.txt *** gcc-3.0.1/libstdc++-v3/docs/html/17_intro/headers_cc.txt Sat Dec 9 20:03:09 2000 --- gcc-3.0.2/libstdc++-v3/docs/html/17_intro/headers_cc.txt Fri Sep 14 17:42:00 2001 *************** *** 80,83 **** #include #endif ! int main() { } --- 80,83 ---- #include #endif ! int main() { return 0; } diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/17_intro/howto.html gcc-3.0.2/libstdc++-v3/docs/html/17_intro/howto.html *** gcc-3.0.1/libstdc++-v3/docs/html/17_intro/howto.html Fri Jun 8 13:09:27 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/17_intro/howto.html Fri Oct 19 13:07:35 2001 *************** *** 1,77 **** ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 17 ! ! ! ! !

        Chapter 17: Library Introduction

        !

        Chapter 17 is actually a list of definitions and descriptions used in the following chapters of the Standard when describing the actual library. Here, we use "Introduction" as an introduction ! to the GNU implementation of the ISO Standard C++ Library. !

        !
        !

        Contents

        ! !
        !

        The Standard C++ header files

        !

        The Standard C++ Library specifies 50 header files that must be available to all hosted implementations. Actually, the word "files" is a misnomer, since the contents of the headers don't necessarily have to be in any kind of external file. The ! only rule is that when you #include a certain header, the contents of that header, as defined by the Standard, become available to you, no matter how. !

        !

        The names of the headers can be easily seen in ! testsuite/17_intro/headers.cc, which is a small testbed we use to make certain that the headers all compile and run. !

        !
        !

        Thread-safety

        !

        This is a thorny issue that gets brought up on the libstdc++-v3 and gcc mailing lists on a regular basis (probably by a cron job). This entry will mention a very little bit about the general MT issues with libstdc++. The latest status and quick notes will be in FAQ 5.6. Some discussion about thread-safe containers will be in section 6.8 (the HOWTOs on containers). This section only applies when gcc and libstdc++-v3 were configured with --enable-threads. !

        !

        The libstdc++ code (all of it, not just the containers) has been designed so that thread-safety will be easily possible. The first ! (!) problem is finding a fast method of implementation portable to all platforms. A minor problem that pops up every so often is different interpretations of what "thread-safe" means for a library (not a general program). We currently use the ! same ! definition that SGI uses for their STL subset. ! Please see the many cautions given in HOWTOs on containers. !

        !

        ! Here is another attempt at explaining the dangers of using the STL with threading support without understanding some important details. The STL implementation is currently configured to use the high-speed caching memory allocator. If you absolutely --- 1,76 ---- ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 17 ! ! ! !

        Chapter 17: Library Introduction

        !

        Chapter 17 is actually a list of definitions and descriptions used in the following chapters of the Standard when describing the actual library. Here, we use "Introduction" as an introduction ! to the GNU implementation of the ISO Standard C++ Library. !

        !
        !

        Contents

        ! !
        !

        The Standard C++ header files

        !

        The Standard C++ Library specifies 50 header files that must be available to all hosted implementations. Actually, the word "files" is a misnomer, since the contents of the headers don't necessarily have to be in any kind of external file. The ! only rule is that when you #include a certain header, the contents of that header, as defined by the Standard, become available to you, no matter how. !

        !

        The names of the headers can be easily seen in ! testsuite/17_intro/headers.cc, which is a small testbed we use to make certain that the headers all compile and run. !

        !
        !

        Thread-safety

        !

        This is a thorny issue that gets brought up on the libstdc++-v3 and gcc mailing lists on a regular basis (probably by a cron job). This entry will mention a very little bit about the general MT issues with libstdc++. The latest status and quick notes will be in FAQ 5.6. Some discussion about thread-safe containers will be in section 6.8 (the HOWTOs on containers). This section only applies when gcc and libstdc++-v3 were configured with --enable-threads. !

        !

        The libstdc++ code (all of it, not just the containers) has been designed so that thread-safety will be easily possible. The first ! (!) problem is finding a fast method of implementation portable to all platforms. A minor problem that pops up every so often is different interpretations of what "thread-safe" means for a library (not a general program). We currently use the ! same ! definition that SGI uses for their STL subset. ! Please see the many cautions given in ! HOWTOs on containers. !

        !

        Here is another attempt at explaining the dangers of using the STL with threading support without understanding some important details. The STL implementation is currently configured to use the high-speed caching memory allocator. If you absolutely *************** *** 81,191 **** fully aware that you may change the external or internal ABI of libstdc++-v3 when you provide -D__USE_MALLOC on the command line or make a change to that configuration file. !

        !

        ! If you don't like caches of objects being retained inside the ! STL, then you might be tempted to define __USE_MALLOC either on ! the command line or by rebuilding c++config.h. Please note, ! once you define __USE_MALLOC, only the malloc allocator is ! visible to application code (i.e. the typically higher-speed ! allocator is not even available in this configuration). There ! is a better way: It is possible to force the malloc-based ! allocator on a per-case-basis for some application code even ! when the above macro symbol is not defined. The author of this ! comment believes that is a better way to tune an application for ! high-speed using this implementation of the STL. Here is one ! possible example displaying the forcing of the malloc-based allocator over the typically higher-speed default allocator: ! ! std::list my_malloc_based_list; !

        !

        A recent journal article has described "atomic integer operations," which would allow us to, well, perform updates on integers atomically, and without requiring an explicit mutex lock. This appears promising, but the major difficulty is that these operations "may not be available on all systems, and if they are, may have different interfaces." [quoting from mailing list messages] !

        !

        Here is a small link farm to threads (no pun) in the mail archives that discuss the threading problem. Each link is to the first relevent message in the thread; from there you can use "Thread Next" to move down the thread. This farm is in latest-to-oldest order. !

        !
        ! Here are discussions that took place before the current snapshot; ! they are still relevant and instructive. !
        !
          !
        • One way of preventing memory leaks by the old default memory ! allocator in multithreaded code is ! discussed here. !
        • This thread ! concerns strings. !
        • So does this ! one. This initial message also refers to another ! thread in the GCC mailing list... !
        • which is here, ! and goes on for some time. Ironically, the initial message ! in this thread also mentions another threading thread... !
        • beginning here, ! and talking about pthreads. (Note that a much more recent ! message from the first thread in this list notes that ! pthreads ! should not be used as a starting point for making ! libstdc++ threadsafe.) !
        • This ! message, ! this one, ! and this one ! are the tops of related threads (all within the same time ! period) discussing threading and the IO library. Much of it ! is dealing with the C library, but C++ is included as well. !
        !

        !

        This section will be updated as new and interesting issues come to light. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        <foo> vs <foo.h>

        !

        The new-style headers are fully supported in libstdc++-v3. The compiler ! itself fully supports namespaces, including std::. !

        !

        For those of you new to ISO C++98, no, that isn't a typo, the headers really have new names. Marshall Cline's C++ FAQ Lite has a good explanation in ! item [25.4]. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: howto.html,v 1.1.4.4 2001/06/08 20:09:27 ljrittle Exp $ !

        ! ! --- 80,165 ---- fully aware that you may change the external or internal ABI of libstdc++-v3 when you provide -D__USE_MALLOC on the command line or make a change to that configuration file. !

        !

        If you don't like caches of objects being retained inside the STL, then ! you might be tempted to define __USE_MALLOC either on the command ! line or by rebuilding c++config.h. Please note, once you define ! __USE_MALLOC, only the malloc allocator is visible to application code ! (i.e. the typically higher-speed allocator is not even available ! in this configuration). There is a better way: It is possible ! to force the malloc-based allocator on a per-case-basis for some ! application code even when the above macro symbol is not defined. ! The library team generally believes that this is a better way to tune ! an application for high-speed using this implementation of the STL. ! Here is one possible example displaying the forcing of the malloc-based allocator over the typically higher-speed default allocator: !

        !       std::list <my_type, std::malloc_alloc>  my_malloc_based_list;
        !

        !

        A recent journal article has described "atomic integer operations," which would allow us to, well, perform updates on integers atomically, and without requiring an explicit mutex lock. This appears promising, but the major difficulty is that these operations "may not be available on all systems, and if they are, may have different interfaces." [quoting from mailing list messages] !

        !

        Here is a small link farm to threads (no pun) in the mail archives that discuss the threading problem. Each link is to the first relevent message in the thread; from there you can use "Thread Next" to move down the thread. This farm is in latest-to-oldest order. !

          !
        • Our threading expert Loren gives a breakdown of ! the ! six situations involving threads for the 3.0 release series. !
        • ! This message inspired a recent updating of issues with threading ! and the SGI STL library. It also contains some example ! POSIX-multithreaded STL code. !
        • ! Here is an early analysis of why __USE_MALLOC should be disabled ! for the 3.0 release of libstdc++. !
        ! (A large selection of links to older messages has been removed; many ! of the messages from 1999 were lost in a disk crash, and the few ! people with access to the backup tapes have been too swamped with work ! to restore them. Many of the points have been superceded anyhow.) !

        !

        This section will be updated as new and interesting issues come to light. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        <foo> vs <foo.h>

        !

        The new-style headers are fully supported in libstdc++-v3. The compiler ! itself fully supports namespaces, including std::. !

        !

        For those of you new to ISO C++98, no, that isn't a typo, the headers really have new names. Marshall Cline's C++ FAQ Lite has a good explanation in ! item [25.4]. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/17_intro/license.html gcc-3.0.2/libstdc++-v3/docs/html/17_intro/license.html *** gcc-3.0.1/libstdc++-v3/docs/html/17_intro/license.html Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/libstdc++-v3/docs/html/17_intro/license.html Fri Oct 19 13:07:35 2001 *************** *** 0 **** --- 1,110 ---- + + + + + + + + + libstdc++-v3 copying + + + + +

        Licenses for the Library

        + +

        As long as this sentence is in place, this page isn't + official. It is still experimental if you are reading this.

        + +

        There are two licenses affecting GNU libstdc++-v3: one for the code, and + one for the documentation. Here we will describe both of them, and try + to answer some of the widespread questions. If you have more questions, + ask the FSF or the + gcc mailing list; the person + writing this page is a programmer, not a lawyer. +

        + +
        + +

        The Code: Runtime GPL

        + +

        The source code of libstdc++-v3 is distributed under version 2 of the + GNU General Public License, with the so-called + "runtime exception," as follows (or see any header or + implementation file): +

        +    As a special exception, you may use this file as part of a free software
        +    library without restriction.  Specifically, if other files instantiate
        +    templates or use macros or inline functions from this file, or you compile
        +    this file and link it with other files to produce an executable, this
        +    file does not by itself cause the resulting executable to be covered by
        +    the GNU General Public License.  This exception does not however
        +    invalidate any other reasons why the executable file might be covered by
        +    the GNU General Public License.
        +    
        +

        + +

        Hopefully that text is self-explanatory. If it isn't, you need to speak + to your lawyer, or the Free Software Foundation. +

        + + +

        Q: So any program which uses libstdc++ falls under the GPL? +
        A: No. The special exception permits use of the + library in proprietary applications. +

        + +

        Q: How is that different from the GNU {Lesser,Library} + GPL? + +
        A: The LGPL requires that users be able to replace the LGPL code with a + modified version; this is trivial if the library in question is a C + shared library. But there's no way to make that work with C++, where + much of the library consists of inline functions and templates, which + are expanded inside the code that uses the library. So to allow people + to replace the library code, someone using the library would have to + distribute their own source, rendering the LGPL equivalent to the GPL. +

        + +

        Q: I see. So, what restrictions are there on + programs that use the library? +
        A: None. We encourage such programs to be released as open source, + but we won't punish you or sue you if you choose otherwise. +

        + +
        + +

        The Docs: FDL

        + +

        The documentation shipped with the library and made available over the + web, including the pages generated from source comments, are copyrighted + by the Free Software Foundation, and placed under + the GNU Free Documentation License version 1.1. + There are no Front-Cover Texts, no Back-Cover Texts, and + + no Invariant Sections. +

        + +

        If you plan on making copies of the documentation, please let us know. + We can probably offer suggestions. +

        + + + + +
        +

        + Comments and suggestions about this page are welcome, and may be sent to + the libstdc++ mailing list. + Comments or questions about the licenses themselves are also welcome, and + should be directed to the GCC list as descibed above. +

        + + + + + + diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/18_support/howto.html gcc-3.0.2/libstdc++-v3/docs/html/18_support/howto.html *** gcc-3.0.1/libstdc++-v3/docs/html/18_support/howto.html Wed May 30 14:59:31 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/18_support/howto.html Fri Oct 19 13:07:36 2001 *************** *** 1,66 **** ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 18 ! ! ! ! !

        Chapter 18: Library Support

        !

        Chapter 18 deals with the functions called and objects created automatically during the course of a program's existence. !

        !

        While we can't reproduce the contents of the Standard here (you need to get your own copy from your nation's member body; see our homepage for help), we can mention a couple of changes in what kind of support a C++ program gets from the Standard Library. !

        !
        !

        Contents

        ! !
        !

        Types

        !

        All the types that you're used to in C are here in one form or another. The only change that might affect people is the type of NULL: while it is required to be a macro, the definition of that ! macro is not allowed to be (void*)0, which is often used in C. !

        !

        In g++, NULL is #define'd to be __null, a magic keyword extension of g++. !

        !

        The biggest problem of #defining NULL to be something like "0L" is that the compiler will view that as a long integer before it views it as a pointer, so overloading won't do what you expect. (This is why g++ has a magic extension, so that NULL is always a pointer.) !

        !

        In his book ! Effective C++, Scott Meyers points out that the best way to solve this problem is to not overload on pointer-vs-integer types to begin with. He also offers a way to make your own magic NULL that will match pointers before it matches integers: !

             const                             // this is a const object...
             class {
             public:
        --- 1,65 ----
          
        ! 
        ! 
        !    
        !    
        !    
        !    
        !    
        !    libstdc++-v3 HOWTO:  Chapter 18
        ! 
        ! 
        ! 
          
        ! 

        Chapter 18: Library Support

        !

        Chapter 18 deals with the functions called and objects created automatically during the course of a program's existence. !

        !

        While we can't reproduce the contents of the Standard here (you need to get your own copy from your nation's member body; see our homepage for help), we can mention a couple of changes in what kind of support a C++ program gets from the Standard Library. !

        !
        !

        Contents

        ! !
        !

        Types

        !

        All the types that you're used to in C are here in one form or another. The only change that might affect people is the type of NULL: while it is required to be a macro, the definition of that ! macro is not allowed to be (void*)0, which is often used in C. !

        !

        In g++, NULL is #define'd to be __null, a magic keyword extension of g++. !

        !

        The biggest problem of #defining NULL to be something like "0L" is that the compiler will view that as a long integer before it views it as a pointer, so overloading won't do what you expect. (This is why g++ has a magic extension, so that NULL is always a pointer.) !

        !

        In his book ! Effective C++, Scott Meyers points out that the best way to solve this problem is to not overload on pointer-vs-integer types to begin with. He also offers a way to make your own magic NULL that will match pointers before it matches integers: !

             const                             // this is a const object...
             class {
             public:
        ***************
        *** 77,118 ****
                                               // taken (see Item 27)...
          
             } NULL;                           // and whose name is NULL
        !       
        (Cribbed from the published version of ! the ! Effective C++ CD, reproduced here with permission.) !

        !

        If you aren't using g++ (why?), but you do have a compiler which supports member function templates, then you can use this definition of NULL (be sure to #undef any existing versions). It only helps if you actually use NULL in function calls, though; if you make a call of ! foo(0); instead of foo(NULL);, then you're back where you started. !

        !

        Added Note: When we contacted Dr. Meyers to ask permission to print this stuff, it prompted him to run this code through current compilers to see what the state of the art is with respect to member template functions. He posted ! an ! article to Usenet after discovering that the code above is not valid! Even though it has no data members, it still needs a user-defined constructor (which means that the class needs a type name after all). The ctor can have an empty body; it just needs to be there. (Stupid requirement? We think so too, and this will probably be changed in the language itself.) !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Implementation properties

        !

        !

        <limits>

        This header mainly defines traits classes to give access to various implementation defined-aspects of the fundamental types. The traits classes -- fourteen in total -- are all specilizations of the ! template class numeric_limits defined as follows: !
             template<typename T> struct class {
                static const bool is_specialized;
                static T max() throw();
        --- 76,118 ----
                                               // taken (see Item 27)...
          
             } NULL;                           // and whose name is NULL
        !       
        (Cribbed from the published version of ! the ! Effective C++ CD, reproduced here with permission.) !

        !

        If you aren't using g++ (why?), but you do have a compiler which supports member function templates, then you can use this definition of NULL (be sure to #undef any existing versions). It only helps if you actually use NULL in function calls, though; if you make a call of ! foo(0); instead of foo(NULL);, then you're back where you started. !

        !

        Added Note: When we contacted Dr. Meyers to ask ! permission to print this stuff, it prompted him to run this code through current compilers to see what the state of the art is with respect to member template functions. He posted ! an ! article to Usenet after discovering that the code above is not valid! Even though it has no data members, it still needs a user-defined constructor (which means that the class needs a type name after all). The ctor can have an empty body; it just needs to be there. (Stupid requirement? We think so too, and this will probably be changed in the language itself.) !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Implementation properties

        !

        !

        <limits>

        This header mainly defines traits classes to give access to various implementation defined-aspects of the fundamental types. The traits classes -- fourteen in total -- are all specilizations of the ! template class numeric_limits defined as follows: !
             template<typename T> struct class {
                static const bool is_specialized;
                static T max() throw();
        ***************
        *** 148,178 ****
                static const bool traps;
                static const bool tinyness_before;
                static const float_round_style round_style;
        !    };
        !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Start and Termination

        !

        Not many changes here to <cstdlib> (the old stdlib.h). ! You should note that the abort() function does not call the destructors of automatic nor static objects, so if you're depending on those to do cleanup, it isn't going to happen. (The functions ! registered with atexit() don't get called either, so you can forget about that possibility, too.) !

        !

        The good old exit() function can be a bit funky, too, until you look closer. Basically, three points to remember are: !

          !
        1. Static objects are destroyed in reverse order of their creation. !
        2. Functions registered with atexit() are called in reverse order of registration, once per registration call. (This isn't actually new.) !
        3. The previous two actions are "interleaved," that is, ! given this code: !
                          extern "C or C++" void  f1 (void);
                          extern "C or C++" void  f2 (void);
            
          --- 148,178 ----
                  static const bool traps;
                  static const bool tinyness_before;
                  static const float_round_style round_style;
          !    };
          !

          !

          Return to top of page or ! to the FAQ. !

          !
          !

          Start and Termination

          !

          Not many changes here to <cstdlib> (the old stdlib.h). ! You should note that the abort() function does not call the destructors of automatic nor static objects, so if you're depending on those to do cleanup, it isn't going to happen. (The functions ! registered with atexit() don't get called either, so you can forget about that possibility, too.) !

          !

          The good old exit() function can be a bit funky, too, until you look closer. Basically, three points to remember are: !

            !
          1. Static objects are destroyed in reverse order of their creation. !
          2. Functions registered with atexit() are called in reverse order of registration, once per registration call. (This isn't actually new.) !
          3. The previous two actions are "interleaved," that is, ! given this pseudocode: !
                            extern "C or C++" void  f1 (void);
                            extern "C or C++" void  f2 (void);
              
            ***************
            *** 180,230 ****
                            atexit(f1);
                            static Thing obj2;
                            atexit(f2);
            !             
            then at a call of exit(), f2 will be called, then obj2 will be destroyed, then f1 will be called, and finally obj1 will be destroyed. If f1 or f2 allow an exception to propogate out of them, Bad Things happen. !
          !

          !

          Note also that atexit() is only required to store 32 functions, and the compiler/library might already be using some of those slots. If you think you may run out, we recommend using the xatexit/xexit combination from libiberty, which has no such limit. !

          !

          Return to top of page or ! to the FAQ. !

          !
          !

          Dynamic memory management

          !

          There are six flavors each of new and delete, so make certain that you're using the right ones! Here are quickie ! descriptions of new: !

            !
          • single object form, throwing a bad_alloc on errors; this is what most people are used to using !
          • single object "nothrow" form, returning NULL on errors !
          • array new, throwing bad_alloc on errors !
          • array nothrow new, returning NULL on errors !
          • placement new, which does nothing (like it's supposed to) !
          • placement array new, which also does nothing !
          They are distinguished by the parameters that you pass to them, like ! any other overloaded function. The six flavors of delete are distinguished the same way, but none of them are allowed to throw an exception under any circumstances anyhow. (They match up for completeness' sake.) !

          !

          Remember that it is perfectly okay to call delete on a NULL pointer! Nothing happens, by definition. That is not the same thing as deleting a pointer twice. !

          !

          By default, if one of the "throwing news" can't allocate the memory requested, it tosses an instance of a ! bad_alloc exception (or, technically, some class derived ! from it). You can change this by writing your own function (called ! a new-handler) and then registering it with set_new_handler(): !

               typedef void (*PFV)(void);
            
               static char*  safety;
          --- 180,230 ----
                          atexit(f1);
                          static Thing obj2;
                          atexit(f2);
          !             
          then at a call of exit(), f2 will be called, then obj2 will be destroyed, then f1 will be called, and finally obj1 will be destroyed. If f1 or f2 allow an exception to propogate out of them, Bad Things happen. !
        !

        !

        Note also that atexit() is only required to store 32 functions, and the compiler/library might already be using some of those slots. If you think you may run out, we recommend using the xatexit/xexit combination from libiberty, which has no such limit. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Dynamic memory management

        !

        There are six flavors each of new and delete, so make certain that you're using the right ones! Here are quickie ! descriptions of new: !

          !
        • single object form, throwing a bad_alloc on errors; this is what most people are used to using !
        • single object "nothrow" form, returning NULL on errors !
        • array new, throwing bad_alloc on errors !
        • array nothrow new, returning NULL on errors !
        • placement new, which does nothing (like it's supposed to) !
        • placement array new, which also does nothing !
        They are distinguished by the parameters that you pass to them, like ! any other overloaded function. The six flavors of delete are distinguished the same way, but none of them are allowed to throw an exception under any circumstances anyhow. (They match up for completeness' sake.) !

        !

        Remember that it is perfectly okay to call delete on a NULL pointer! Nothing happens, by definition. That is not the same thing as deleting a pointer twice. !

        !

        By default, if one of the "throwing news" can't allocate the memory requested, it tosses an instance of a ! bad_alloc exception (or, technically, some class derived ! from it). You can change this by writing your own function (called a ! new-handler) and then registering it with set_new_handler(): !

             typedef void (*PFV)(void);
          
             static char*  safety;
        ***************
        *** 243,273 ****
             int main ()
             {
                 safety = new char[500000];
        !        old_handler = set_new_handler (&my_new_handler);
                 ...
             }
        !       
        !

        !

        bad_alloc is derived from the base exception class defined in Chapter 19. !

        !

        Return to top of page or ! to the FAQ. !

        ! ! !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: howto.html,v 1.1.4.2 2001/05/30 21:59:31 pme Exp $ !

        ! ! --- 243,271 ---- int main () { safety = new char[500000]; ! old_handler = set_new_handler (&my_new_handler); ... } !
        !

        !

        bad_alloc is derived from the base exception class defined in Chapter 19. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/19_diagnostics/howto.html gcc-3.0.2/libstdc++-v3/docs/html/19_diagnostics/howto.html *** gcc-3.0.1/libstdc++-v3/docs/html/19_diagnostics/howto.html Wed May 30 14:59:31 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/19_diagnostics/howto.html Fri Oct 19 13:07:36 2001 *************** *** 1,116 **** ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 19 ! ! ! ! !

        Chapter 19: Diagnostics

        !

        Chapter 19 deals with program diagnostics, such as exceptions and assertions. You know, all the things we wish weren't even necessary at all. !

        !
        !

        Contents

        ! !
        !

        Adding data to exceptions

        !

        The standard exception classes carry with them a single string as data (usually describing what went wrong or where the 'throw' took place). It's good to remember that you can add your own data to these exceptions when extending the heirarchy: !

        !
        !    using std::runtime_error;
        !    struct My_Exception : public runtime_error
             {
               public:
                 My_Exception (const string& whatarg)
        !            : runtime_error(whatarg), e(errno), id(GetDataBaseID()) { }
                 int  errno_at_time_of_throw() const { return e; }
                 DBID id_of_thing_that_threw() const { return id; }
               protected:
                 int    e;
                 DBID   id;     // some user-defined type
             };
        !    
        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Exception class hierarchy diagram

        !

        The diagram is in PDF, or ! at least it will be once it gets finished. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Concept checkers -- new and improved!

        !

        Better taste! Less fat! Literally!

        !

        In 1999, SGI added concept checkers to their implementation of the STL: code which checked the template parameters of instantiated pieces of the STL, in order to insure that the parameters being used met the requirements of the standard. For example, the Standard requires that types passed as template parameters to ! vector be "Assignable" (which means what you think it means). The checking was done during compilation, and none of the code was executed at runtime. !

        !

        Unfortunately, the size of the compiler files grew significantly as a result. The checking code itself was cumbersome. And bugs were found in it on more than one occasion. !

        !

        The primary author of the checking code, Jeremy Siek, had already started work on a replcement implementation. The new code has been formally reviewed and accepted into ! the ! Boost libraries, and we are pleased to incorporate it into the GNU C++ library. !

        !

        The new version imposes a much smaller space overhead on the generated object file. The checks are also cleaner and easier to read and understand. !

        !

        Right now they are off by default. More will be added once GCC 3.0 is released and we have time to revisit this topic. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: howto.html,v 1.1.4.2 2001/05/30 21:59:31 pme Exp $ !

        ! ! --- 1,121 ---- ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 19 ! ! ! !

        Chapter 19: Diagnostics

        !

        Chapter 19 deals with program diagnostics, such as exceptions and assertions. You know, all the things we wish weren't even necessary at all. !

        !
        !

        Contents

        ! !
        !

        Adding data to exceptions

        !

        The standard exception classes carry with them a single string as data (usually describing what went wrong or where the 'throw' took place). It's good to remember that you can add your own data to these exceptions when extending the heirarchy: !

        !
        !    struct My_Exception : public std::runtime_error
             {
               public:
                 My_Exception (const string& whatarg)
        !            : std::runtime_error(whatarg), e(errno), id(GetDataBaseID()) { }
                 int  errno_at_time_of_throw() const { return e; }
                 DBID id_of_thing_that_threw() const { return id; }
               protected:
                 int    e;
                 DBID   id;     // some user-defined type
             };
        !    
        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Exception class hierarchy diagram

        !

        At one point we were going to make up a PDF of the exceptions ! hierarchy, akin to the one done for the I/O class hierarchy. ! Time was our enemy. Since then we've moved to Doxygen, which has ! the useful property of not sucking. Specifically, when the source ! code is changed, the diagrams are automatically brought up to date. ! For the old way, we had to update the diagrams separately. !

        !

        There are several links to the Doxygen-generated pages from ! here. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Concept checkers -- new and improved!

        !

        Better taste! Less fat! Literally!

        !

        In 1999, SGI added concept checkers to their implementation of the STL: code which checked the template parameters of instantiated pieces of the STL, in order to insure that the parameters being used met the requirements of the standard. For example, the Standard requires that types passed as template parameters to ! vector be "Assignable" (which means what you think it means). The checking was done during compilation, and none of the code was executed at runtime. !

        !

        Unfortunately, the size of the compiler files grew significantly as a result. The checking code itself was cumbersome. And bugs were found in it on more than one occasion. !

        !

        The primary author of the checking code, Jeremy Siek, had already started work on a replcement implementation. The new code has been formally reviewed and accepted into ! the ! Boost libraries, and we are pleased to incorporate it into the GNU C++ library. !

        !

        The new version imposes a much smaller space overhead on the generated object file. The checks are also cleaner and easier to read and understand. !

        !

        Right now they are off by default. More will be added once GCC 3.0 is released and we have time to revisit this topic. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/20_util/howto.html gcc-3.0.2/libstdc++-v3/docs/html/20_util/howto.html *** gcc-3.0.1/libstdc++-v3/docs/html/20_util/howto.html Wed May 30 14:59:31 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/20_util/howto.html Fri Oct 19 13:07:36 2001 *************** *** 1,54 **** ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 20 ! ! ! ! !

        Chapter 20: General Utilities

        !

        Chapter 20 deals with utility classes and functions, such as ! the oft-debated auto_ptr<>. !

        !
        !

        Contents

        ! !
        !

        auto_ptr is not omnipotent

        !

        I'm not going to try and explain all of the fun and delicious things that can happen with misuse of the auto_ptr class template (called AP here), nor am I going to try and teach you how to use AP safely in the presence of copying. The AP class is a really nifty idea for a smart pointer, but it is one of the dumbest of all the smart pointers -- and that's fine. !

        !

        AP is not meant to be a supersmart solution to all resource leaks everywhere. Neither is it meant to be an effective form of garbage collection (although it can help, a little bit). ! And it can not be used for arrays! !

        !

        AP is meant to prevent nasty leaks in the presence of ! exceptions. That's all. This code is AP-friendly: !

              // not a recommend naming scheme, but good for web-based FAQs
              typedef std::auto_ptr<MyClass>  APMC;
          
        --- 1,53 ----
          
        ! 
        ! 
        !    
        !    
        !    
        !    
        !    
        !    libstdc++-v3 HOWTO:  Chapter 20
        ! 
        ! 
        ! 
          
        ! 

        Chapter 20: General Utilities

        !

        Chapter 20 deals with utility classes and functions, such as ! the oft-debated auto_ptr<>. !

        !
        !

        Contents

        ! !
        !

        auto_ptr is not omnipotent

        !

        I'm not going to try and explain all of the fun and delicious things that can happen with misuse of the auto_ptr class template (called AP here), nor am I going to try and teach you how to use AP safely in the presence of copying. The AP class is a really nifty idea for a smart pointer, but it is one of the dumbest of all the smart pointers -- and that's fine. !

        !

        AP is not meant to be a supersmart solution to all resource leaks everywhere. Neither is it meant to be an effective form of garbage collection (although it can help, a little bit). ! And it can not be used for arrays! !

        !

        AP is meant to prevent nasty leaks in the presence of ! exceptions. That's all. This code is AP-friendly: !

              // not a recommend naming scheme, but good for web-based FAQs
              typedef std::auto_ptr<MyClass>  APMC;
          
        ***************
        *** 63,120 ****
          
                  function_taking_MyClass_pointer (ap.get());
              }
        !       
        When an exception gets thrown, the instance of MyClass that's ! been created on the heap will be delete'd as the stack is ! unwound past func(). !

        !

        Changing that code as follows is not AP-friendly: !

                  APMC  ap (new MyClass[22]);
        !       
        You will get the same problems as you would without the use of AP: !
                  char*  array = new char[10];       // array new...
                  ...
                  delete array;                      // ...but single-object delete
        !       
        !

        !

        AP cannot tell whether the pointer you've passed at creation points to one or many things. If it points to many things, you are about to die. AP is trivial to write, however, so you could write your ! own auto_array_ptr for that situation (in fact, this has been done many times; check the mailing lists, Usenet, Boost, etc). !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        auto_ptr inside container classes

        !

        All of the containers described in the standard library require their contained types to have, among other things, a copy contructor like this: !

              struct My_Type
              {
                  My_Type (My_Type const&);
              };
        !       
        Note the const keyword; the object being copied shouldn't change. ! The template class auto_ptr (called AP here) does not meet this requirement. Creating a new AP by copying an existing one transfers ownership of the pointed-to object, which means that the AP being copied must change, which in turn means that the copy ctors of AP do not take const objects. !

        !

        The resulting rule is simple: Never ever use a container of ! auto_ptr objects. The standard says that undefined behavior ! is the result, but it is guaranteed to be messy. !

        !

        To prevent you from doing this to yourself, the ! concept checks built in to this implementation will issue an error if you try to compile code like this: !

              #include <vector>
              #include <memory>
              
        --- 62,119 ----
          
                  function_taking_MyClass_pointer (ap.get());
              }
        !       
        When an exception gets thrown, the instance of MyClass that's ! been created on the heap will be delete'd as the stack is ! unwound past func(). !

        !

        Changing that code as follows is not AP-friendly: !

                  APMC  ap (new MyClass[22]);
        !       
        You will get the same problems as you would without the use of AP: !
                  char*  array = new char[10];       // array new...
                  ...
                  delete array;                      // ...but single-object delete
        !       
        !

        !

        AP cannot tell whether the pointer you've passed at creation points to one or many things. If it points to many things, you are about to die. AP is trivial to write, however, so you could write your ! own auto_array_ptr for that situation (in fact, this has been done many times; check the mailing lists, Usenet, Boost, etc). !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        auto_ptr inside container classes

        !

        All of the containers described in the standard library require their contained types to have, among other things, a copy contructor like this: !

              struct My_Type
              {
                  My_Type (My_Type const&);
              };
        !       
        Note the const keyword; the object being copied shouldn't change. ! The template class auto_ptr (called AP here) does not meet this requirement. Creating a new AP by copying an existing one transfers ownership of the pointed-to object, which means that the AP being copied must change, which in turn means that the copy ctors of AP do not take const objects. !

        !

        The resulting rule is simple: Never ever use a container of ! auto_ptr objects. The standard says that "undefined" ! behavior is the result, but it is guaranteed to be messy. !

        !

        To prevent you from doing this to yourself, the ! concept checks built in to this implementation will issue an error if you try to compile code like this: !

              #include <vector>
              #include <memory>
              
        ***************
        *** 122,208 ****
              {
                  std::vector< std::auto_ptr<int> >   vec_ap_int;
              }
        !       
        Should you try this with the checks enabled, you will see an error. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Functors

        !

        If you don't know what functors are, you're not alone. Many people get slightly the wrong idea. In the interest of not reinventing the wheel, we will refer you to the introduction to the functor concept written by SGI as part of their STL, in ! their ! http://www.sgi.com/Technology/STL/functors.html. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Pairs

        !

        The pair<T1,T2> is a simple and handy way to carry around a pair of objects. One is of type T1, and another of type T2; they may be the same type, but you don't get anything extra if they are. The two members can be accessed directly, as ! .first and .second. !

        !

        Construction is simple. The default ctor initializes each member with its respective default ctor. The other simple ctor, !

              pair (const T1& x, const T2& y);
        !       
        does what you think it does, first getting x ! and second getting y. !

        !

        There is a copy constructor, but it requires that your compiler handle member function templates: !

              template <class U, class V> pain (const pair<U,V>& p);
        !       
        The compiler will convert as necessary from U to T1 and from V to T2 in order to perform the respective initializations. !

        !

        The comparison operators are done for you. Equality ! of two pair<T1,T2>s is defined as both first ! members comparing equal and both second members comparing equal; this simply delegates responsibility to the respective ! operator== functions (for types like MyClass) or builtin comparisons (for types like int, char, etc). !

        !

        The less-than operator is a bit odd the first time you see it. It is defined as evaluating to: !

              x.first  <  y.first  ||
                  ( !(y.first  <  x.first)  &&  x.second  <  y.second )
        !       
        ! The other operators are not defined using the rel_ops functions above, but their semantics are the same. !

        !

        Finally, there is a template function called make_pair that takes two references-to-const objects and returns an instance of a pair instantiated on their respective types: !

              pair<int,MyClass> p = make_pair(4,myobject);
        !       
        !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: howto.html,v 1.2.4.2 2001/05/30 21:59:31 pme Exp $ !

        ! ! --- 121,209 ---- { std::vector< std::auto_ptr<int> > vec_ap_int; } !
        Should you try this with the checks enabled, you will see an error. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Functors

        !

        If you don't know what functors are, you're not alone. Many people get slightly the wrong idea. In the interest of not reinventing the wheel, we will refer you to the introduction to the functor concept written by SGI as part of their STL, in ! their ! http://www.sgi.com/Technology/STL/functors.html. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Pairs

        !

        The pair<T1,T2> is a simple and handy way to carry around a pair of objects. One is of type T1, and another of type T2; they may be the same type, but you don't get anything extra if they are. The two members can be accessed directly, as ! .first and .second. !

        !

        Construction is simple. The default ctor initializes each member with its respective default ctor. The other simple ctor, !

              pair (const T1& x, const T2& y);
        !       
        does what you think it does, first getting x ! and second getting y. !

        !

        There is a copy constructor, but it requires that your compiler handle member function templates: !

              template <class U, class V> pain (const pair<U,V>& p);
        !       
        The compiler will convert as necessary from U to T1 and from V to T2 in order to perform the respective initializations. !

        !

        The comparison operators are done for you. Equality ! of two pair<T1,T2>s is defined as both first ! members comparing equal and both second members comparing equal; this simply delegates responsibility to the respective ! operator== functions (for types like MyClass) or builtin comparisons (for types like int, char, etc). !

        ! !

        The less-than operator is a bit odd the first time you see it. It is defined as evaluating to: !

              x.first  <  y.first  ||
                  ( !(y.first  <  x.first)  &&  x.second  <  y.second )
        !       
        ! The other operators are not defined using the rel_ops functions above, but their semantics are the same. !

        !
        !

        Finally, there is a template function called make_pair that takes two references-to-const objects and returns an instance of a pair instantiated on their respective types: !

              pair<int,MyClass> p = make_pair(4,myobject);
        !       
        !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/21_strings/howto.html gcc-3.0.2/libstdc++-v3/docs/html/21_strings/howto.html *** gcc-3.0.1/libstdc++-v3/docs/html/21_strings/howto.html Mon May 14 12:48:56 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/21_strings/howto.html Fri Oct 19 13:07:37 2001 *************** *** 1,66 **** ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 21 ! ! ! ! !

        Chapter 21: Strings

        !

        Chapter 21 deals with the C++ strings library (a welcome relief). !

        !
        !

        Contents

        ! !
        !

        MFC's CString

        !

        A common lament seen in various newsgroups deals with the Standard string class as opposed to the Microsoft Foundation Class called CString. Often programmers realize that a standard portable answer is better than a proprietary nonportable one, but in porting their application from a Win32 platform, they discover that they are relying on special functons offered by the CString class. !

        !

        Things are not as bad as they seem. In ! this ! message, Joe Buck points out a few very important things: !

          !
        • The Standard string supports all the operations that CString does, with three exceptions. !
        • Two of those exceptions (whitespace trimming and case conversion) are trivial to implement. In fact, we do so on this page. !
        • The third is CString::Format, which allows formatting ! in the style of sprintf. This deserves some mention: !
        !

        ! !

        The old libg++ library had a function called form(), which did much the same thing. But for a Standard solution, you should use the stringstream classes. These are the bridge between the iostream hierarchy and the string class, and they operate with regular streams seamlessly because they inherit from the iostream heirarchy. An quick example: !

             #include <iostream>
             #include <string>
             #include <sstream>
        --- 1,65 ----
          
        ! 
        ! 
        !    
        !    
        !    
        !    
        !    
        !    libstdc++-v3 HOWTO:  Chapter 21
        ! 
        ! 
        ! 
          
        ! 

        Chapter 21: Strings

        !

        Chapter 21 deals with the C++ strings library (a welcome relief). !

        !
        !

        Contents

        ! !
        !

        MFC's CString

        !

        A common lament seen in various newsgroups deals with the Standard string class as opposed to the Microsoft Foundation Class called CString. Often programmers realize that a standard portable answer is better than a proprietary nonportable one, but in porting their application from a Win32 platform, they discover that they are relying on special functons offered by the CString class. !

        !

        Things are not as bad as they seem. In ! this ! message, Joe Buck points out a few very important things: !

          !
        • The Standard string supports all the operations that CString does, with three exceptions. !
        • Two of those exceptions (whitespace trimming and case conversion) are trivial to implement. In fact, we do so on this page. !
        • The third is CString::Format, which allows formatting ! in the style of sprintf. This deserves some mention: !
        !

        ! !

        The old libg++ library had a function called form(), which did much the same thing. But for a Standard solution, you should use the stringstream classes. These are the bridge between the iostream hierarchy and the string class, and they operate with regular streams seamlessly because they inherit from the iostream heirarchy. An quick example: !

             #include <iostream>
             #include <string>
             #include <sstream>
        ***************
        *** 79,89 ****
                               << " and 3*N was " << (3*the_number);
          
                 return output_stream.str();
        !    } 
        !

        !

        A serious problem with CString is a design bug in its memory allocation. Specifically, quoting from that same message: !

             CString suffers from a common programming error that results in
             poor performance.  Consider the following code:
             
        --- 78,88 ----
                               << " and 3*N was " << (3*the_number);
          
                 return output_stream.str();
        !    } 
        !

        !

        A serious problem with CString is a design bug in its memory allocation. Specifically, quoting from that same message: !

             CString suffers from a common programming error that results in
             poor performance.  Consider the following code:
             
        ***************
        *** 104,150 ****
             
             If you replace CString with string in the above function, the
             performance is O(n).
        !       
        !

        !

        Joe Buck also pointed out some other things to keep in mind when comparing CString and the Standard string class: !

          !
        • CString permits access to its internal representation; coders ! who exploited that may have problems moving to string. !
        • Microsoft ships the source to CString (in the files MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation bug and rebuild your MFC libraries. ! Note: It looks like the the CString shipped with VC++6.0 has fixed this, although it may in fact have been one ! of the VC++ SPs that did it. !
        • string operations like this have O(n) complexity ! if the implementors do it correctly. The libstdc++ implementors did it correctly. Other vendors might not. !
        • While parts of the SGI STL are used in libstdc++-v3, their ! string class is not. The SGI string is essentially ! vector<char> and does not do any reference counting like libstdc++-v3's does. (It is O(n), though.) So if you're thinking about SGI's string or rope classes, you're now looking at four possibilities: CString, the libstdc++ string, the SGI string, and the SGI rope, and this is all before any allocator or traits customizations! (More choices than you can shake a stick at -- want fries with that?) !
        !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        A case-insensitive string class

        !

        The well-known-and-if-it-isn't-well-known-it-ought-to-be ! Guru of the Week discussions held on Usenet covered this topic in January of 1998. Briefly, the challenge was, "write a 'ci_string' class which is identical to the standard 'string' class, but is case-insensitive in the same way as the (common but nonstandard) C function stricmp():" !

             ci_string s( "AbCdE" );
          
             // case insensitive
        --- 103,149 ----
             
             If you replace CString with string in the above function, the
             performance is O(n).
        !       
        !

        !

        Joe Buck also pointed out some other things to keep in mind when comparing CString and the Standard string class: !

          !
        • CString permits access to its internal representation; coders ! who exploited that may have problems moving to string. !
        • Microsoft ships the source to CString (in the files MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation bug and rebuild your MFC libraries. ! Note: It looks like the the CString shipped with VC++6.0 has fixed this, although it may in fact have been one ! of the VC++ SPs that did it. !
        • string operations like this have O(n) complexity ! if the implementors do it correctly. The libstdc++ implementors did it correctly. Other vendors might not. !
        • While parts of the SGI STL are used in libstdc++-v3, their ! string class is not. The SGI string is essentially ! vector<char> and does not do any reference counting like libstdc++-v3's does. (It is O(n), though.) So if you're thinking about SGI's string or rope classes, you're now looking at four possibilities: CString, the libstdc++ string, the SGI string, and the SGI rope, and this is all before any allocator or traits customizations! (More choices than you can shake a stick at -- want fries with that?) !
        !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        A case-insensitive string class

        !

        The well-known-and-if-it-isn't-well-known-it-ought-to-be ! Guru of the Week discussions held on Usenet covered this topic in January of 1998. Briefly, the challenge was, "write a 'ci_string' class which is identical to the standard 'string' class, but is case-insensitive in the same way as the (common but nonstandard) C function stricmp():" !

             ci_string s( "AbCdE" );
          
             // case insensitive
        ***************
        *** 153,263 ****
          
             // still case-preserving, of course
             assert( strcmp( s.c_str(), "AbCdE" ) == 0 );
        !    assert( strcmp( s.c_str(), "abcde" ) != 0 ); 
        !

        !

        The solution is surprisingly easy. The original answer pages on the GotW website were removed into cold storage, in preparation for ! a ! published book of GotW notes. Before being put on the web, of course, it was posted on Usenet, and that ! posting containing the answer is available ! here. !

        !

        See? Told you it was easy!

        !

        Added June 2000: The May issue of C++ Report contains ! a fascinating article by Matt Austern (yes, the Matt Austern) on why case-insensitive comparisons are not as easy as they seem, ! and why creating a class is the wrong way to go about it in production code. (The GotW answer mentions one of the principle difficulties; his article mentions more.) !

        !

        Basically, this is "easy" only if you ignore some things, things which may be too important to your program to ignore. (I chose to ignore them when originally writing this entry, and am surprised that nobody ever called me on it...) The GotW question and answer remain useful instructional tools, however. !

        !

        Added September 2000: James Kanze provided a link to a ! Unicode ! Technical Report discussing case handling, which provides some very good information. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Breaking a C++ string into tokens

        !

        The Standard C (and C++) function strtok() leaves a lot to be desired in terms of user-friendliness. It's unintuitive, it destroys the character string on which it operates, and it requires you to handle all the memory problems. But it does let the client code decide what to use to break the string into pieces; it allows you to choose the "whitespace," so to speak. !

        !

        A C++ implementation lets us keep the good things and fix those annoyances. The implementation here is more intuitive (you only call it once, not in a loop with varying argument), it does not affect the original string at all, and all the memory allocation is handled for you. !

        !

        It's called stringtok, and it's a template function. It's given ! in this file in a less-portable form than it could be, to keep this example simple (for example, see the comments on what kind of string it will accept). The author uses a more general (but less readable) form of it for parsing command strings and the like. If you compiled and ran this code using it: !

             std::list<string>  ls;
             stringtok (ls, " this  \t is\t\n  a test  ");
             for (std::list<string>const_iterator i = ls.begin();
                  i != ls.end(); ++i)
             {
                 std::cerr << ':' << (*i) << ":\n";
        !    }
        You would see this as output: !
             :this:
             :is:
             :a:
        !    :test:
        ! with all the whitespace removed. The original s is still ! available for use, ls will clean up after itself, and ! ls.size() will return how many tokens there were. !

        !

        As always, there is a price paid here, in that stringtok is not as fast as strtok. The other benefits usually outweight that, however. ! Another version of stringtok is given ! here, suggested by Chris King and tweaked by Petr Prikryl, and this one uses the transformation functions mentioned below. If you are comfortable with reading the new function names, this version is recommended as an example. !

        !

        Added February 2001: Mark Wilden pointed out that the ! standard std::getline() function can be used with standard ! istringstreams to perform tokenizing as well. Build an istringstream from the input text, and then use std::getline with varying delimiters (the three-argument signature) to extract tokens into a string. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Simple transformations

        !

        Here are Standard, simple, and portable ways to perform common ! transformations on a string instance, such as "convert to all upper case." The word transformations is especially apt, because the standard template function ! transform<> is used. !

        !

        This code will go through some iterations (no pun). Here's the simplistic version usually seen on Usenet: !

             #include <string>
             #include <algorithm>
             #include <cctype>      // old <ctype.h>
        --- 152,263 ----
          
             // still case-preserving, of course
             assert( strcmp( s.c_str(), "AbCdE" ) == 0 );
        !    assert( strcmp( s.c_str(), "abcde" ) != 0 ); 
        !

        !

        The solution is surprisingly easy. The original answer pages on the GotW website were removed into cold storage, in preparation for ! a ! published book of GotW notes. Before being put on the web, of course, it was posted on Usenet, and that ! posting containing the answer is available ! here. !

        !

        See? Told you it was easy!

        !

        Added June 2000: The May issue of C++ Report ! contains ! a fascinating article by Matt Austern (yes, the Matt Austern) on why case-insensitive comparisons are not as easy as they seem, ! and why creating a class is the wrong way to go about it in production code. (The GotW answer mentions one of the principle difficulties; his article mentions more.) !

        !

        Basically, this is "easy" only if you ignore some things, things which may be too important to your program to ignore. (I chose to ignore them when originally writing this entry, and am surprised that nobody ever called me on it...) The GotW question and answer remain useful instructional tools, however. !

        !

        Added September 2000: James Kanze provided a link to a ! Unicode ! Technical Report discussing case handling, which provides some very good information. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Breaking a C++ string into tokens

        !

        The Standard C (and C++) function strtok() leaves a lot to be desired in terms of user-friendliness. It's unintuitive, it destroys the character string on which it operates, and it requires you to handle all the memory problems. But it does let the client code decide what to use to break the string into pieces; it allows you to choose the "whitespace," so to speak. !

        !

        A C++ implementation lets us keep the good things and fix those annoyances. The implementation here is more intuitive (you only call it once, not in a loop with varying argument), it does not affect the original string at all, and all the memory allocation is handled for you. !

        !

        It's called stringtok, and it's a template function. It's given ! in this file in a less-portable form than it could be, to keep this example simple (for example, see the comments on what kind of string it will accept). The author uses a more general (but less readable) form of it for parsing command strings and the like. If you compiled and ran this code using it: !

             std::list<string>  ls;
             stringtok (ls, " this  \t is\t\n  a test  ");
             for (std::list<string>const_iterator i = ls.begin();
                  i != ls.end(); ++i)
             {
                 std::cerr << ':' << (*i) << ":\n";
        !    }
        You would see this as output: !
             :this:
             :is:
             :a:
        !    :test:
        ! with all the whitespace removed. The original s is still ! available for use, ls will clean up after itself, and ! ls.size() will return how many tokens there were. !

        !

        As always, there is a price paid here, in that stringtok is not as fast as strtok. The other benefits usually outweight that, however. ! Another version of stringtok is given ! here, suggested by Chris King and tweaked by Petr Prikryl, and this one uses the transformation functions mentioned below. If you are comfortable with reading the new function names, this version is recommended as an example. !

        !

        Added February 2001: Mark Wilden pointed out that the ! standard std::getline() function can be used with standard ! istringstreams to perform tokenizing as well. Build an istringstream from the input text, and then use std::getline with varying delimiters (the three-argument signature) to extract tokens into a string. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Simple transformations

        !

        Here are Standard, simple, and portable ways to perform common ! transformations on a string instance, such as "convert to all upper case." The word transformations is especially apt, because the standard template function ! transform<> is used. !

        !

        This code will go through some iterations (no pun). Here's the simplistic version usually seen on Usenet: !

             #include <string>
             #include <algorithm>
             #include <cctype>      // old <ctype.h>
        ***************
        *** 274,309 ****
             // result in a different string
             std::string  capital_s;
             capital_s.reserve(s.size());
        !    std::transform (s.begin(), s.end(), capital_s.begin(), tolower); 
        ! Note that these calls all involve ! the global C locale through the use of the C functions ! toupper/tolower. This is absolutely guaranteed to work -- ! but only if the string contains only characters ! from the basic source character set, and there are only 96 of those. Which means that not even all English text can be represented (certain British spellings, proper names, and so forth). So, if all your input forevermore consists of only those 96 characters (hahahahahaha), then you're done. !

        !

        At minimum, you can write short wrappers like !

             char toLower (char c)
             {
                return tolower(static_cast<unsigned char>(c));
        !    }
        !

        !

        The correct method is to use a facet for a particular locale and call its conversion functions. These are discussed more in Chapter 22; the specific part is ! here, which shows the final version of this code. (Thanks to James Kanze for assistance and suggestions on all of this.) !

        !

        Another common operation is trimming off excess whitespace. Much like transformations, this task is trivial with the use of string's ! find family. These examples are broken into multiple statements for readability: !

             std::string  str (" \t blah blah blah    \n ");
          
             // trim leading whitespace
        --- 274,309 ----
             // result in a different string
             std::string  capital_s;
             capital_s.reserve(s.size());
        !    std::transform (s.begin(), s.end(), capital_s.begin(), tolower); 
        ! Note that these calls all ! involve the global C locale through the use of the C functions ! toupper/tolower. This is absolutely guaranteed to work -- ! but only if the string contains only characters ! from the basic source character set, and there are only 96 of those. Which means that not even all English text can be represented (certain British spellings, proper names, and so forth). So, if all your input forevermore consists of only those 96 characters (hahahahahaha), then you're done. !

        !

        At minimum, you can write short wrappers like !

             char toLower (char c)
             {
                return tolower(static_cast<unsigned char>(c));
        !    }
        !

        !

        The correct method is to use a facet for a particular locale and call its conversion functions. These are discussed more in Chapter 22; the specific part is ! here, which shows the final version of this code. (Thanks to James Kanze for assistance and suggestions on all of this.) !

        !

        Another common operation is trimming off excess whitespace. Much like transformations, this task is trivial with the use of string's ! find family. These examples are broken into multiple statements for readability: !

             std::string  str (" \t blah blah blah    \n ");
          
             // trim leading whitespace
        ***************
        *** 312,338 ****
          
             // trim trailing whitespace
             notwhite = str.find_last_not_of(" \t\n"); 
        !    str.erase(notwhite+1); 
        ! Obviously, the calls to find could be inserted directly ! into the calls to erase, in case your compiler does not optimize named temporaries out of existance. !

        !

        Return to top of page or ! to the FAQ. !

        ! !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: howto.html,v 1.2.2.1 2001/05/14 19:48:56 bkoz Exp $ !

        ! ! --- 312,337 ---- // trim trailing whitespace notwhite = str.find_last_not_of(" \t\n"); ! str.erase(notwhite+1);
        ! Obviously, the calls to find could be inserted directly ! into the calls to erase, in case your compiler does not optimize named temporaries out of existance. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/22_locale/codecvt.html gcc-3.0.2/libstdc++-v3/docs/html/22_locale/codecvt.html *** gcc-3.0.1/libstdc++-v3/docs/html/22_locale/codecvt.html Sat Dec 9 20:04:55 2000 --- gcc-3.0.2/libstdc++-v3/docs/html/22_locale/codecvt.html Fri Oct 19 13:07:37 2001 *************** *** 1,18 **** ! ! !

        Notes on the codecvt implementation. !

        ! prepared by Benjamin Kosnik (bkoz@redhat.com) on August 28, 2000 !

        !

        1. Abstract !

        !

        The standard class codecvt attempts to address conversions between different character encoding schemes. In particular, the standard attempts to detail conversions between the implementation-defined wide --- 1,18 ---- ! ! !

        Notes on the codecvt implementation. !

        ! prepared by Benjamin Kosnik (bkoz@redhat.com) on August 28, 2000 !

        !

        1. Abstract !

        !

        The standard class codecvt attempts to address conversions between different character encoding schemes. In particular, the standard attempts to detail conversions between the implementation-defined wide *************** Unicode and UTF8. Design issues and requ *** 26,37 **** examples of correct usage for both the required specializations for wide and narrow characters and the implementation-provided extended functionality are given. !

        !

        !

        2. What the standard says !

        Around page 425 of the C++ Standard, this charming heading comes into view:
        --- 26,37 ---- examples of correct usage for both the required specializations for wide and narrow characters and the implementation-provided extended functionality are given. !

        !

        !

        2. What the standard says !

        Around page 425 of the C++ Standard, this charming heading comes into view:
        *************** Unicode and EUC. *** 49,59 ****
        !

        Hmm. So, in some unspecified way, Unicode encodings and translations between other character sets should be handled by this class. !

        --- 49,59 ----
        !

        Hmm. So, in some unspecified way, Unicode encodings and translations between other character sets should be handled by this class. !

        *************** class. *** 61,69 ****
        !

        Ah ha! Another clue... !

        --- 61,69 ----
        !

        Ah ha! Another clue... !

        *************** is useful to communicate to or from the *** 81,104 ****
        !

        At this point, a couple points become clear: !

        One: The standard clearly implies that attempts to add non-required (yet useful and widely used) conversions need to do so through the ! third template parameter, stateT.

        !

        Two: The required conversions, by specifying mbstate_t as the third template parameter, imply an implementation strategy that is mostly (or wholly) based on the underlying C library, and the functions ! mcsrtombs and wcsrtombs in particular.

        !

        !

        3. Some thoughts on what would be useful !

        Probably the most frequently asked question about code conversion is: "So dudes, what's the deal with Unicode strings?" The dude part is optional, but apparently the usefulness of Unicode strings is pretty --- 81,104 ----
        !

        At this point, a couple points become clear: !

        One: The standard clearly implies that attempts to add non-required (yet useful and widely used) conversions need to do so through the ! third template parameter, stateT.

        !

        Two: The required conversions, by specifying mbstate_t as the third template parameter, imply an implementation strategy that is mostly (or wholly) based on the underlying C library, and the functions ! mcsrtombs and wcsrtombs in particular.

        !

        !

        3. Some thoughts on what would be useful !

        Probably the most frequently asked question about code conversion is: "So dudes, what's the deal with Unicode strings?" The dude part is optional, but apparently the usefulness of Unicode strings is pretty *************** widely appreciated. Sadly, this specific *** 106,112 **** encodings like UTF8, UCS4, ISO 8859-10, etc etc etc) are not mentioned in the C++ standard. !

        In particular, the simple implementation detail of wchar_t's size seems to repeatedly confound people. Many systems use a two byte, unsigned integral type to represent wide characters, and use an --- 106,112 ---- encodings like UTF8, UCS4, ISO 8859-10, etc etc etc) are not mentioned in the C++ standard. !

        In particular, the simple implementation detail of wchar_t's size seems to repeatedly confound people. Many systems use a two byte, unsigned integral type to represent wide characters, and use an *************** UCS4. (GNU/Linux systems using glibc, in *** 117,136 **** programming language (and thus C++) does not specify a specific size for the type wchar_t. !

        Thus, portable C++ code cannot assume a byte size (or endianness) either. !

        Getting back to the frequently asked question: What about Unicode strings? !

        What magic spell will do this conversion? !

        A couple of comments: !

        !

        The thought that all one needs to convert between two arbitrary codesets is two types and some kind of state argument is unfortunate. In particular, encodings may be stateless. The naming of --- 117,136 ---- programming language (and thus C++) does not specify a specific size for the type wchar_t. !

        Thus, portable C++ code cannot assume a byte size (or endianness) either. !

        Getting back to the frequently asked question: What about Unicode strings? !

        What magic spell will do this conversion? !

        A couple of comments: !

        !

        The thought that all one needs to convert between two arbitrary codesets is two types and some kind of state argument is unfortunate. In particular, encodings may be stateless. The naming of *************** the third parameter as stateT is unfortu *** 138,238 **** is some kind of generalized type that accounts for the issues that abstract encodings will need. The minimum information that is required includes: !

        !
          !
        • !

          Identifiers for each of the codesets involved in the conversion. For example, using the iconv family of functions from the Single Unix Specification (what used to be called X/Open) hosted on the GNU/Linux operating system allows bi-directional mapping between far more than the following tantalizing possibilities: !

          ! (An edited list taken from `iconv --list` on a Red Hat 6.2/Intel system:
            8859_1, 8859_9, 10646-1:1993, 10646-1:1993/UCS4, ARABIC, ARABIC7,
          ! ASCII, EUC-CN, EUC-JP, EUC-KR, EUC-TW, GREEK-CCITT, GREEK, GREEK7-OLD,
            GREEK7, GREEK8, HEBREW, ISO-8859-1, ISO-8859-2, ISO-8859-3,
            ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8,
            ISO-8859-9, ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14,
            ISO-8859-15, ISO-10646, ISO-10646/UCS2, ISO-10646/UCS4,
            ISO-10646/UTF-8, ISO-10646/UTF8, SHIFT-JIS, SHIFT_JIS, UCS-2, UCS-4,
          ! UCS2, UCS4, UNICODE, UNICODEBIG, UNICODELITTLE, US-ASCII, US, UTF-8,
            UTF-16, UTF8, UTF16).
            
          !

          For iconv-based implementations, string literals for each of the encodings (ie. "UCS-2" and "UTF-8") are necessary, although for other, non-iconv implementations a table of enumerated values or some other mechanism may be required. !

        • Maximum length of the identifying string literal. !
        • Some encodings are require explicit endian-ness. As such, some kind of endian marker or other byte-order marker will be necessary. See "Footnotes for C/C++ developers" in Haible for more information on UCS-2/Unicode endian issues. (Summary: big endian seems most likely, however implementations, most notably Microsoft, vary.) !
        • Types representing the conversion state, for conversions involving the machinery in the "C" library, or the conversion descriptor, for conversions using iconv (such as the type iconv_t.) Note that the conversion descriptor encodes more information than a simple encoding state type. !
        • Conversion descriptors for both directions of encoding. (ie, both UCS-2 to UTF-8 and UTF-8 to UCS-2.) !
        • Something to indicate if the conversion requested if valid. !
        • Something to represent if the conversion descriptors are valid. !
        • Some way to enforce strict type checking on the internal and external types. As part of this, the size of the internal and external types will need to be known. !
        !

        !

        4. Problems with "C" code conversions : thread safety, global locales, termination. !

        In addition, multi-threaded and multi-locale environments also impact the design and requirements for code conversions. In particular, they affect the required specialization codecvt<wchar_t, char, mbstate_t> when implemented using standard "C" functions. !

        Three problems arise, one big, one of medium importance, and one small. !

        First, the small: mcsrtombs and wcsrtombs may not be multithread-safe on all systems required by the GNU tools. For GNU/Linux and glibc, this is not an issue. !

        Of medium concern, in the grand scope of things, is that the functions used to implement this specialization work on null-terminated strings. Buffers, especially file buffers, may not be null-terminated, thus giving conversions that end prematurely or are otherwise incorrect. Yikes! !

        The last, and fundamental problem, is the assumption of a global locale for all the "C" functions referenced above. For something like C++ iostreams (where codecvt is explicitly used) the notion of --- 138,238 ---- is some kind of generalized type that accounts for the issues that abstract encodings will need. The minimum information that is required includes: !

        !
          !
        • !

          Identifiers for each of the codesets involved in the conversion. For example, using the iconv family of functions from the Single Unix Specification (what used to be called X/Open) hosted on the GNU/Linux operating system allows bi-directional mapping between far more than the following tantalizing possibilities: !

          ! (An edited list taken from `iconv --list` on a Red Hat 6.2/Intel system:
            8859_1, 8859_9, 10646-1:1993, 10646-1:1993/UCS4, ARABIC, ARABIC7,
          ! ASCII, EUC-CN, EUC-JP, EUC-KR, EUC-TW, GREEK-CCIcode, GREEK, GREEK7-OLD,
            GREEK7, GREEK8, HEBREW, ISO-8859-1, ISO-8859-2, ISO-8859-3,
            ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8,
            ISO-8859-9, ISO-8859-10, ISO-8859-11, ISO-8859-13, ISO-8859-14,
            ISO-8859-15, ISO-10646, ISO-10646/UCS2, ISO-10646/UCS4,
            ISO-10646/UTF-8, ISO-10646/UTF8, SHIFT-JIS, SHIFT_JIS, UCS-2, UCS-4,
          ! UCS2, UCS4, UNICODE, UNICODEBIG, UNICODELIcodeLE, US-ASCII, US, UTF-8,
            UTF-16, UTF8, UTF16).
            
          !

          For iconv-based implementations, string literals for each of the encodings (ie. "UCS-2" and "UTF-8") are necessary, although for other, non-iconv implementations a table of enumerated values or some other mechanism may be required. !

        • Maximum length of the identifying string literal. !
        • Some encodings are require explicit endian-ness. As such, some kind of endian marker or other byte-order marker will be necessary. See "Footnotes for C/C++ developers" in Haible for more information on UCS-2/Unicode endian issues. (Summary: big endian seems most likely, however implementations, most notably Microsoft, vary.) !
        • Types representing the conversion state, for conversions involving the machinery in the "C" library, or the conversion descriptor, for conversions using iconv (such as the type iconv_t.) Note that the conversion descriptor encodes more information than a simple encoding state type. !
        • Conversion descriptors for both directions of encoding. (ie, both UCS-2 to UTF-8 and UTF-8 to UCS-2.) !
        • Something to indicate if the conversion requested if valid. !
        • Something to represent if the conversion descriptors are valid. !
        • Some way to enforce strict type checking on the internal and external types. As part of this, the size of the internal and external types will need to be known. !
        !

        !

        4. Problems with "C" code conversions : thread safety, global locales, termination. !

        In addition, multi-threaded and multi-locale environments also impact the design and requirements for code conversions. In particular, they affect the required specialization codecvt<wchar_t, char, mbstate_t> when implemented using standard "C" functions. !

        Three problems arise, one big, one of medium importance, and one small. !

        First, the small: mcsrtombs and wcsrtombs may not be multithread-safe on all systems required by the GNU tools. For GNU/Linux and glibc, this is not an issue. !

        Of medium concern, in the grand scope of things, is that the functions used to implement this specialization work on null-terminated strings. Buffers, especially file buffers, may not be null-terminated, thus giving conversions that end prematurely or are otherwise incorrect. Yikes! !

        The last, and fundamental problem, is the assumption of a global locale for all the "C" functions referenced above. For something like C++ iostreams (where codecvt is explicitly used) the notion of *************** multiple locales and or simultaneous usa *** 243,285 **** correct results. In short, libstdc++-v3 is trying to offer, as an option, a high-quality implementation, damn the additional complexity! !

        For the required specialization codecvt<wchar_t, char, mbstate_t> , conversions are made between the internal character set (always UCS4 on GNU/Linux) and whatever the currently selected locale for the LC_CTYPE category implements. !

        !

        5. Design !

        The two required specializations are implemented as follows: !

        ! codecvt<char, char, mbstate_t> ! !

        This is a degenerate (ie, does nothing) specialization. Implementing this was a piece of cake. !

        ! codecvt<char, wchar_t, mbstate_t> ! !

        This specialization, by specifying all the template parameters, pretty much ties the hands of implementors. As such, the implementation is straightforward, involving mcsrtombs for the conversions between char to wchar_t and wcsrtombs for conversions between wchar_t and char. !

        Neither of these two required specializations deals with Unicode characters. As such, libstdc++-v3 implements a partial specialization of the codecvt class with and iconv wrapper class, __enc_traits as the third template parameter. !

        This implementation should be standards conformant. First of all, the standard explicitly points out that instantiations on the third template parameter, stateT, are the proper way to implement --- 243,285 ---- correct results. In short, libstdc++-v3 is trying to offer, as an option, a high-quality implementation, damn the additional complexity! !

        For the required specialization codecvt<wchar_t, char, mbstate_t> , conversions are made between the internal character set (always UCS4 on GNU/Linux) and whatever the currently selected locale for the LC_CTYPE category implements. !

        !

        5. Design !

        The two required specializations are implemented as follows: !

        ! codecvt<char, char, mbstate_t> ! !

        This is a degenerate (ie, does nothing) specialization. Implementing this was a piece of cake. !

        ! codecvt<char, wchar_t, mbstate_t> ! !

        This specialization, by specifying all the template parameters, pretty much ties the hands of implementors. As such, the implementation is straightforward, involving mcsrtombs for the conversions between char to wchar_t and wcsrtombs for conversions between wchar_t and char. !

        Neither of these two required specializations deals with Unicode characters. As such, libstdc++-v3 implements a partial specialization of the codecvt class with and iconv wrapper class, __enc_traits as the third template parameter. !

        This implementation should be standards conformant. First of all, the standard explicitly points out that instantiations on the third template parameter, stateT, are the proper way to implement *************** of all, the requirements for the stateT *** 289,322 **** (see 21.1.2 traits typedefs) only indicate that this type be copy constructible. !

        As such, the type __enc_traits is defined as a non-templatized, POD type to be used as the third type of a codecvt instantiation. This type is just a wrapper class for iconv, and provides an easy interface to iconv functionality. !

        There are two constructors for __enc_traits: !

        ! __enc_traits() : __in_desc(0), __out_desc(0) ! !

        This default constructor sets the internal encoding to some default (currently UCS4) and the external encoding to whatever is returned by nl_langinfo(CODESET). !

        ! __enc_traits(const char* __int, const char* __ext) ! !

        This constructor takes as parameters string literals that indicate the desired internal and external encoding. There are no defaults for either argument. !

        One of the issues with iconv is that the string literals identifying conversions are not standardized. Because of this, the thought of mandating and or enforcing some set of pre-determined valid --- 289,322 ---- (see 21.1.2 traits typedefs) only indicate that this type be copy constructible. !

        As such, the type __enc_traits is defined as a non-templatized, POD type to be used as the third type of a codecvt instantiation. This type is just a wrapper class for iconv, and provides an easy interface to iconv functionality. !

        There are two constructors for __enc_traits: !

        ! __enc_traits() : __in_desc(0), __out_desc(0) ! !

        This default constructor sets the internal encoding to some default (currently UCS4) and the external encoding to whatever is returned by nl_langinfo(CODESET). !

        ! __enc_traits(const char* __int, const char* __ext) ! !

        This constructor takes as parameters string literals that indicate the desired internal and external encoding. There are no defaults for either argument. !

        One of the issues with iconv is that the string literals identifying conversions are not standardized. Because of this, the thought of mandating and or enforcing some set of pre-determined valid *************** inducing) strategy was implemented: end- *** 326,349 **** encodings. It is up to the user to make sure that these strings are valid on the target system. !

        ! void _M_init() ! !

        Strangely enough, this member function attempts to open conversion descriptors for a given __enc_traits object. If the conversion descriptors are not valid, the conversion descriptors returned will not be valid and the resulting calls to the codecvt conversion functions will return error. !

        ! bool _M_good() ! !

        Provides a way to see if the given __enc_traits object has been properly initialized. If the string literals describing the desired internal and external encoding are not valid, initialization will --- 326,349 ---- encodings. It is up to the user to make sure that these strings are valid on the target system. !

        ! void _M_init() ! !

        Strangely enough, this member function attempts to open conversion descriptors for a given __enc_traits object. If the conversion descriptors are not valid, the conversion descriptors returned will not be valid and the resulting calls to the codecvt conversion functions will return error. !

        ! bool _M_good() ! !

        Provides a way to see if the given __enc_traits object has been properly initialized. If the string literals describing the desired internal and external encoding are not valid, initialization will *************** encodings are valid, but iconv_open coul *** 352,380 **** descriptors, this will also return false. Otherwise, the object is ready to convert and will return true. !

        ! __enc_traits(const __enc_traits&) ! !

        As iconv allocates memory and sets up conversion descriptors, the copy constructor can only copy the member data pertaining to the internal and external code conversions, and not the conversion descriptors themselves. !

        Definitions for all the required codecvt member functions are provided for this specialization, and usage of codecvt<internal character type, external character type, __enc_traits> is consistent with other codecvt usage. !

        !

        6. Examples !

        !
          !
        • a. conversions involving string literals
          --- 352,380 ----
            descriptors, this will also return false. Otherwise, the object is
            ready to convert and will return true.
            
          ! 

          ! __enc_traits(const __enc_traits&) ! !

          As iconv allocates memory and sets up conversion descriptors, the copy constructor can only copy the member data pertaining to the internal and external code conversions, and not the conversion descriptors themselves. !

          Definitions for all the required codecvt member functions are provided for this specialization, and usage of codecvt<internal character type, external character type, __enc_traits> is consistent with other codecvt usage. !

          !

          6. Examples !

          !
            !
          • a. conversions involving string literals
            *************** codecvt usage.
            *** 415,520 ****
                VERIFY( efrom_next == e_lit + size );
                VERIFY( ito_next == i_arr + size );
              
            !
          • b. conversions involving std::string !
          • c. conversions involving std::filebuf and std::ostream !
          More information can be found in the following testcases: !
            !
          • testsuite/22_locale/codecvt_char_char.cc !
          • testsuite/22_locale/codecvt_unicode_wchar_t.cc !
          • testsuite/22_locale/codecvt_unicode_char.cc !
          • testsuite/22_locale/codecvt_wchar_t_char.cc !
          !

          !

          7. Unresolved Issues !

          !
            !
          • a. things that are sketchy, or remain unimplemented: do_encoding, max_length and length member functions are only weakly implemented. I have no idea how to do this correctly, and in a generic manner. Nathan? !
          • b. conversions involving std::string !
              !
            • how should operators != and == work for string of different/same encoding? !
            • what is equal? A byte by byte comparison or an encoding then byte comparison? !
            • conversions between narrow, wide, and unicode strings !
            !
          • c. conversions involving std::filebuf and std::ostream !
              !
            • how to initialize the state object in a standards-conformant manner? !
            • how to synchronize the "C" and "C++" conversion information? !
            • wchar_t/char internal buffers and conversions between internal/external buffers? !
            !
          !

          !

          8. Acknowledgments !

          Ulrich Drepper for the iconv suggestions and patient answering of late-night questions, Jason Merrill for the template partial specialization hints, language clarification, and wchar_t fixes. !

          !

          9. Bibliography / Referenced Documents !

          Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters "6. Character Set Handling" and "7 Locales and Internationalization" !

          Drepper, Ulrich, Numerous, late-night email correspondence !

          Feather, Clive, "A brief description of Normative Addendum 1," in particular the parts on Extended Character Sets http://www.lysator.liu.se/c/na1.html !

          Haible, Bruno, "The Unicode HOWTO" v0.18, 4 August 2000 ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html !

          ISO/IEC 14882:1998 Programming languages - C++ !

          ISO/IEC 9899:1999 Programming languages - C !

          Khun, Markus, "UTF-8 and Unicode FAQ for Unix/Linux" http://www.cl.cam.ac.uk/~mgk25/unicode.html !

          Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000 !

          Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 !

          System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) The Open Group/The Institute of Electrical and Electronics Engineers, Inc. http://www.opennc.org/austin/docreg.html --- 415,520 ---- VERIFY( efrom_next == e_lit + size ); VERIFY( ito_next == i_arr + size );

          !
        • b. conversions involving std::string !
        • c. conversions involving std::filebuf and std::ostream !
        More information can be found in the following testcases: !
          !
        • testsuite/22_locale/codecvt_char_char.cc !
        • testsuite/22_locale/codecvt_unicode_wchar_t.cc !
        • testsuite/22_locale/codecvt_unicode_char.cc !
        • testsuite/22_locale/codecvt_wchar_t_char.cc !
        !

        !

        7. Unresolved Issues !

        !
          !
        • a. things that are sketchy, or remain unimplemented: do_encoding, max_length and length member functions are only weakly implemented. I have no idea how to do this correctly, and in a generic manner. Nathan? !
        • b. conversions involving std::string !
            !
          • how should operators != and == work for string of different/same encoding? !
          • what is equal? A byte by byte comparison or an encoding then byte comparison? !
          • conversions between narrow, wide, and unicode strings !
          !
        • c. conversions involving std::filebuf and std::ostream !
            !
          • how to initialize the state object in a standards-conformant manner? !
          • how to synchronize the "C" and "C++" conversion information? !
          • wchar_t/char internal buffers and conversions between internal/external buffers? !
          !
        !

        !

        8. Acknowledgments !

        Ulrich Drepper for the iconv suggestions and patient answering of late-night questions, Jason Merrill for the template partial specialization hints, language clarification, and wchar_t fixes. !

        !

        9. Bibliography / Referenced Documents !

        Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters "6. Character Set Handling" and "7 Locales and Internationalization" !

        Drepper, Ulrich, Numerous, late-night email correspondence !

        Feather, Clive, "A brief description of Normative Addendum 1," in particular the parts on Extended Character Sets http://www.lysator.liu.se/c/na1.html !

        Haible, Bruno, "The Unicode HOWTO" v0.18, 4 August 2000 ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html !

        ISO/IEC 14882:1998 Programming languages - C++ !

        ISO/IEC 9899:1999 Programming languages - C !

        Khun, Markus, "UTF-8 and Unicode FAQ for Unix/Linux" http://www.cl.cam.ac.uk/~mgk25/unicode.html !

        Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000 !

        Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 !

        System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) The Open Group/The Institute of Electrical and Electronics Engineers, Inc. http://www.opennc.org/austin/docreg.html diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/22_locale/ctype.html gcc-3.0.2/libstdc++-v3/docs/html/22_locale/ctype.html *** gcc-3.0.1/libstdc++-v3/docs/html/22_locale/ctype.html Sat Dec 9 20:04:55 2000 --- gcc-3.0.2/libstdc++-v3/docs/html/22_locale/ctype.html Fri Oct 19 13:07:37 2001 *************** *** 1,144 **** ! ! !

        Notes on the ctype implementation. !

        ! prepared by Benjamin Kosnik (bkoz@redhat.com) on August 30, 2000 !

        !

        1. Abstract !

        !

        Woe is me. !

        !

        !

        2. What the standard says !

        !

        !

        3. Problems with "C" ctype : global locales, termination. !

        !

        For the required specialization codecvt<wchar_t, char, mbstate_t> , conversions are made between the internal character set (always UCS4 on GNU/Linux) and whatever the currently selected locale for the LC_CTYPE category implements. !

        !

        4. Design !

        The two required specializations are implemented as follows: !

        ! ctype<char> ! !

        This is simple specialization. Implementing this was a piece of cake. !

        ! ctype<wchar_t> ! !

        This specialization, by specifying all the template parameters, pretty much ties the hands of implementors. As such, the implementation is straightforward, involving mcsrtombs for the conversions between char to wchar_t and wcsrtombs for conversions between wchar_t and char. !

        Neither of these two required specializations deals with Unicode characters. As such, libstdc++-v3 implements !

        !

        5. Examples !

            typedef ctype cctype;
          
        More information can be found in the following testcases: !
          !
        • testsuite/22_locale/ctype_char_members.cc !
        • testsuite/22_locale/ctype_wchar_t_members.cc !
        !

        !

        6. Unresolved Issues !

        !
          !
        • how to deal with the global locale issue? !
        • how to deal with different types than char, wchar_t? !
        • codecvt/ctype overlap: narrow/widen !
        • mask typedef in codecvt_base, argument types in codecvt. what is know about this type? !
        • why mask* argument in codecvt? !
        • can this be made (more) generic? is there a simple way to straighten out the configure-time mess that is a by-product of this class? !
        • get the ctype::mask stuff under control. Need to make some kind of static table, and not do lookup evertime somebody hits the do_is... functions. Too bad we can't just redefine mask for ctype !
        • rename abstract base class. See if just smash-overriding is a better approach. Clarify, add sanity to naming. !
        !

        !

        7. Acknowledgments !

        Ulrich Drepper for patient answering of late-night questions, skeletal examples, and C language expertise. !

        !

        8. Bibliography / Referenced Documents !

        Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters "6. Character Set Handling" and "7 Locales and Internationalization" !

        Drepper, Ulrich, Numerous, late-night email correspondence !

        ISO/IEC 14882:1998 Programming languages - C++ !

        ISO/IEC 9899:1999 Programming languages - C !

        Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000 !

        Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 !

        System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) The Open Group/The Institute of Electrical and Electronics Engineers, Inc. http://www.opennc.org/austin/docreg.html --- 1,144 ---- ! ! !

        Notes on the ctype implementation. !

        ! prepared by Benjamin Kosnik (bkoz@redhat.com) on August 30, 2000 !

        !

        1. Abstract !

        !

        Woe is me. !

        !

        !

        2. What the standard says !

        !

        !

        3. Problems with "C" ctype : global locales, termination. !

        !

        For the required specialization codecvt<wchar_t, char, mbstate_t> , conversions are made between the internal character set (always UCS4 on GNU/Linux) and whatever the currently selected locale for the LC_CTYPE category implements. !

        !

        4. Design !

        The two required specializations are implemented as follows: !

        ! ctype<char> ! !

        This is simple specialization. Implementing this was a piece of cake. !

        ! ctype<wchar_t> ! !

        This specialization, by specifying all the template parameters, pretty much ties the hands of implementors. As such, the implementation is straightforward, involving mcsrtombs for the conversions between char to wchar_t and wcsrtombs for conversions between wchar_t and char. !

        Neither of these two required specializations deals with Unicode characters. As such, libstdc++-v3 implements !

        !

        5. Examples !

            typedef ctype cctype;
          
        More information can be found in the following testcases: !
          !
        • testsuite/22_locale/ctype_char_members.cc !
        • testsuite/22_locale/ctype_wchar_t_members.cc !
        !

        !

        6. Unresolved Issues !

        !
          !
        • how to deal with the global locale issue? !
        • how to deal with different types than char, wchar_t? !
        • codecvt/ctype overlap: narrow/widen !
        • mask typedef in codecvt_base, argument types in codecvt. what is know about this type? !
        • why mask* argument in codecvt? !
        • can this be made (more) generic? is there a simple way to straighten out the configure-time mess that is a by-product of this class? !
        • get the ctype::mask stuff under control. Need to make some kind of static table, and not do lookup evertime somebody hits the do_is... functions. Too bad we can't just redefine mask for ctype !
        • rename abstract base class. See if just smash-overriding is a better approach. Clarify, add sanity to naming. !
        !

        !

        7. Acknowledgments !

        Ulrich Drepper for patient answering of late-night questions, skeletal examples, and C language expertise. !

        !

        8. Bibliography / Referenced Documents !

        Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters "6. Character Set Handling" and "7 Locales and Internationalization" !

        Drepper, Ulrich, Numerous, late-night email correspondence !

        ISO/IEC 14882:1998 Programming languages - C++ !

        ISO/IEC 9899:1999 Programming languages - C !

        Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000 !

        Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 !

        System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) The Open Group/The Institute of Electrical and Electronics Engineers, Inc. http://www.opennc.org/austin/docreg.html diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/22_locale/howto.html gcc-3.0.2/libstdc++-v3/docs/html/22_locale/howto.html *** gcc-3.0.1/libstdc++-v3/docs/html/22_locale/howto.html Mon May 14 12:48:56 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/22_locale/howto.html Fri Oct 19 13:07:37 2001 *************** *** 1,144 **** ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 22 ! ! ! ! !

        Chapter 22: Localization

        !

        Chapter 22 deals with the C++ localization facilities. !

        !
        !

        Contents

        ! ! !
        !

        Stroustrup on Locales

        !

        Dr. Bjarne Stroustrup has released a ! pointer ! to Appendix D of his book, ! The C++ ! Programming Language (3rd Edition). It is a detailed ! description of locales and how to use them. !

        !

        He also writes: !

        ! Please note that I still consider this detailed description of ! locales beyond the needs of most C++ programmers. It is written ! with experienced programmers in mind and novices will do best to ! avoid it. !
        !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Nathan Myers on Locales

        !

        An article entitled "The Standard C++ Locale" was ! published in Dr. Dobb's Journal and can be found ! here. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        class locale

        !

        Notes made during the implementation of locales can be found ! here. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        class codecvt

        !

        Notes made during the implementation of codecvt can be found ! here. !

        !

        The following is the abstract from the implementation notes: !

        ! The standard class codecvt attempts to address conversions ! between different character encoding schemes. In particular, the ! standard attempts to detail conversions between the ! implementation-defined wide characters (hereafter referred to as ! wchar_t) and the standard type char that is so beloved in classic ! "C" (which can now be referred to as narrow characters.) ! This document attempts to describe how the GNU libstdc++-v3 ! implementation deals with the conversion between wide and narrow ! characters, and also presents a framework for dealing with the huge ! number of other encodings that iconv can convert, including Unicode ! and UTF8. Design issues and requirements are addressed, and examples ! of correct usage for both the required specializations for wide and ! narrow characters and the implementation-provided extended ! functionality are given. !
        !

        Return to top of page or ! to the FAQ. !

        !
        !

        class ctype

        !

        Notes made during the implementation of ctype can be found ! here. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Correct Transformations

        ! !

        A very common question on newsgroups and mailing lists is, "How do I do <foo> to a character string?" where <foo> is a task such as changing all the letters to uppercase, to lowercase, testing for digits, etc. A skilled and conscientious programmer will follow the question with another, "And how do I make the code portable?" !

        !

        (Poor innocent programmer, you have no idea the depths of trouble you are getting yourself into. 'Twould be best for your sanity if you dropped the whole idea and took up basket weaving instead. No? Fine, you asked for it...) !

        !

        The task of changing the case of a letter or classifying a character as numeric, graphical, etc, all depends on the cultural context of the program at runtime. So, first you must take the portability question into account. Once you have localized the program to a particular natural language, only then can you perform the specific task. Unfortunately, specializing a function for a human language is not as simple as declaring ! extern "Danish" int tolower (int); . !

        !

        The C++ code to do all this proceeds in the same way. First, a locale is created. Then member functions of that locale are called to perform minor tasks. Continuing the example from Chapter 21, we wish to use the following convenience functions: !

             namespace std {
               template <class charT>
                 charT
        --- 1,137 ----
          
        ! 
        ! 
        !    
        !    
        !    
        !    
        !    
        !    libstdc++-v3 HOWTO:  Chapter 22
        ! 
        ! 
        ! 
          
        ! 

        Chapter 22: Localization

        !

        Chapter 22 deals with the C++ localization facilities. !

        ! !
        !

        Contents

        ! !
        !

        class locale

        !

        Notes made during the implementation of locales can be found ! here. !

        !
        !

        class codecvt

        !

        Notes made during the implementation of codecvt can be found ! here. !

        !

        The following is the abstract from the implementation notes: !

        ! The standard class codecvt attempts to address conversions between ! different character encoding schemes. In particular, the standard ! attempts to detail conversions between the implementation-defined ! wide characters (hereafter referred to as wchar_t) and the standard ! type char that is so beloved in classic "C" (which can ! now be referred to as narrow characters.) This document attempts ! to describe how the GNU libstdc++-v3 implementation deals with the ! conversion between wide and narrow characters, and also presents a ! framework for dealing with the huge number of other encodings that ! iconv can convert, including Unicode and UTF8. Design issues and ! requirements are addressed, and examples of correct usage for both ! the required specializations for wide and narrow characters and the ! implementation-provided extended functionality are given. !
        !

        !
        !

        class ctype

        !

        Notes made during the implementation of ctype can be found ! here. !

        !
        !

        class messages

        !

        Notes made during the implementation of messages can be found ! here. !

        !
        !

        Stroustrup on Locales

        !

        Dr. Bjarne Stroustrup has released a ! pointer ! to Appendix D of his book, ! The C++ ! Programming Language (3rd Edition). It is a detailed ! description of locales and how to use them. !

        !

        He also writes: !

        ! Please note that I still consider this detailed description of ! locales beyond the needs of most C++ programmers. It is written ! with experienced programmers in mind and novices will do best to ! avoid it. !
        !

        !
        !

        Nathan Myers on Locales

        !

        An article entitled "The Standard C++ Locale" was ! published in Dr. Dobb's Journal and can be found ! here. !

        !
        !

        Correct Transformations

        ! !

        A very common question on newsgroups and mailing lists is, "How do I do <foo> to a character string?" where <foo> is a task such as changing all the letters to uppercase, to lowercase, testing for digits, etc. A skilled and conscientious programmer will follow the question with another, "And how do I make the code portable?" !

        !

        (Poor innocent programmer, you have no idea the depths of trouble you are getting yourself into. 'Twould be best for your sanity if you dropped the whole idea and took up basket weaving instead. No? Fine, you asked for it...) !

        !

        The task of changing the case of a letter or classifying a character as numeric, graphical, etc, all depends on the cultural context of the program at runtime. So, first you must take the portability question into account. Once you have localized the program to a particular natural language, only then can you perform the specific task. Unfortunately, specializing a function for a human language is not as simple as declaring ! extern "Danish" int tolower (int); . !

        !

        The C++ code to do all this proceeds in the same way. First, a locale is created. Then member functions of that locale are called to perform minor tasks. Continuing the example from Chapter 21, we wish to use the following convenience functions: !

             namespace std {
               template <class charT>
                 charT
        *************** functionality are given.
        *** 146,167 ****
               template <class charT>
                 charT
                 tolower (charT c, const locale& loc) const;
        !    }
        This function extracts the appropriate "facet" from the ! locale loc and calls the appropriate member function of that ! facet, passing c as its argument. The resulting character is returned. !

        !

        For the C/POSIX locale, the results are the same as calling the ! classic C toupper/tolower function that was used in previous examples. For other locales, the code should Do The Right Thing. !

        !

        Of course, these functions take a second argument, and the transformation algorithm's operator argument can only take a single parameter. So we write simple wrapper structs to handle that. !

        !

        The next-to-final version of the code started in Chapter 21 looks like: !

             #include <iterator>    // for back_inserter
             #include <locale>
             #include <string>
        --- 139,160 ----
               template <class charT>
                 charT
                 tolower (charT c, const locale& loc) const;
        !    }
        This function extracts the appropriate "facet" from the ! locale loc and calls the appropriate member function of that ! facet, passing c as its argument. The resulting character is returned. !

        !

        For the C/POSIX locale, the results are the same as calling the ! classic C toupper/tolower function that was used in previous examples. For other locales, the code should Do The Right Thing. !

        !

        Of course, these functions take a second argument, and the transformation algorithm's operator argument can only take a single parameter. So we write simple wrapper structs to handle that. !

        !

        The next-to-final version of the code started in Chapter 21 looks like: !

             #include <iterator>    // for back_inserter
             #include <locale>
             #include <string>
        *************** functionality are given.
        *** 187,193 ****
             int main ()
             {
                std::string  s ("Some Kind Of Initial Input Goes Here");
        !       Toupper      up ( std::locale("C") );
                Tolower      down ( std::locale("C") );
             
                // Change everything into upper case
        --- 180,186 ----
             int main ()
             {
                std::string  s ("Some Kind Of Initial Input Goes Here");
        !       Toupper      up   ( std::locale("C") );
                Tolower      down ( std::locale("C") );
             
                // Change everything into upper case
        *************** functionality are given.
        *** 206,234 ****
                std::transform (s.begin(), s.end(), std::back_inserter(capital_s),
                                up
                               );
        !    }
        !

        !

        The final version of the code uses bind2nd to eliminate the wrapper structs, but the resulting code is tricky. I have not shown it here because no compilers currently available to me will handle it. !

        !

        Return to top of page or ! to the FAQ. !

        ! ! !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: howto.html,v 1.2.2.1 2001/05/14 19:48:56 bkoz Exp $ !

        ! ! --- 199,222 ---- std::transform (s.begin(), s.end(), std::back_inserter(capital_s), up ); ! }
        !

        !

        The final version of the code uses bind2nd to eliminate the wrapper structs, but the resulting code is tricky. I have not shown it here because no compilers currently available to me will handle it. !

        !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/22_locale/locale.html gcc-3.0.2/libstdc++-v3/docs/html/22_locale/locale.html *** gcc-3.0.1/libstdc++-v3/docs/html/22_locale/locale.html Tue Jan 30 01:18:50 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/22_locale/locale.html Fri Oct 19 13:07:37 2001 *************** *** 1,45 **** ! ! !

        Notes on the locale implementation. !

        ! ! prepared by Benjamin Kosnik (bkoz@redhat.com) on January 24, 2001 !

        !

        1. Abstract Describes the basic locale object, including nested classes id, facet, and the reference-counted implementation object, class _Impl. !

        !

        !

        !

        !

        2. What the standard says See Chapter 22 of the standard. !

        !

        !

        3. Problems with "C" locales : global locales, termination. !

        !

        The major problem is fitting an object-orientated and non-global locale design ontop of POSIX and other relevant stanards, which include the Single Unix (nee X/Open.) Because POSIX falls down so completely, portibility is an issue. !

        !

        4. Design !

        Class locale in non-templatized and has three distinct types nested inside of it: --- 1,45 ---- ! ! !

        Notes on the locale implementation. !

        ! ! prepared by Benjamin Kosnik (bkoz@redhat.com) on August 8, 2001 !

        !

        1. Abstract Describes the basic locale object, including nested classes id, facet, and the reference-counted implementation object, class _Impl. !

        !

        !

        !

        !

        2. What the standard says See Chapter 22 of the standard. !

        !

        !

        3. Problems with "C" locales : global locales, termination. !

        !

        The major problem is fitting an object-orientated and non-global locale design ontop of POSIX and other relevant stanards, which include the Single Unix (nee X/Open.) Because POSIX falls down so completely, portibility is an issue. !

        !

        4. Design !

        Class locale in non-templatized and has three distinct types nested inside of it: *************** class facet *** 48,54 **** Facets actually implement locale functionality. For instance, a facet called numpunct is the data objects that can be used to query for the ! thousands seperator is in the German locale. Literally, a facet is strictly defined: - containing --- 48,54 ---- Facets actually implement locale functionality. For instance, a facet called numpunct is the data objects that can be used to query for the ! thousands separator is in the German locale. Literally, a facet is strictly defined: - containing *************** Provides an index for looking up specifi *** 69,133 **** class _Impl !

        !

        5. Examples !

            typedef __locale_t locale;
          
        More information can be found in the following testcases: !
          !
        • testsuite/22_locale/ctype_char_members.cc !
        • testsuite/22_locale/ctype_wchar_t_members.cc !
        !

        !

        6. Unresolved Issues !

        !
          !
        • locale -a displays available locales on linux !
        • locale initialization: at what point does _S_classic, _S_global get initialized? Can named locales assume this initialization has already taken place? -
        !

        !

        7. Acknowledgments !

        !

        !

        8. Bibliography / Referenced Documents !

        Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters "6. Character Set Handling" and "7 Locales and Internationalization" !

        Drepper, Ulrich, Numerous, late-night email correspondence !

        ISO/IEC 14882:1998 Programming languages - C++ !

        ISO/IEC 9899:1999 Programming languages - C !

        Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000 !

        Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 !

        System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) The Open Group/The Institute of Electrical and Electronics Engineers, Inc. http://www.opennc.org/austin/docreg.html - - --- 69,144 ---- class _Impl !

        !

        5. Examples !

            typedef __locale_t locale;
          
        More information can be found in the following testcases: !
          !
        • testsuite/22_locale/ctype_char_members.cc !
        • testsuite/22_locale/ctype_wchar_t_members.cc !
        !

        !

        6. Unresolved Issues !

        !
          !
        • locale -a displays available locales on linux !
        • locale initialization: at what point does _S_classic, _S_global get initialized? Can named locales assume this initialization has already taken place? +
        • document how named locales error check when filling data + members. Ie, a fr_FR locale that doesn't have + numpunct::truename(): does it use "true"? Or is it a blank + string? What's the convention? !
        • explain how locale aliasing happens. When does "de_DE" ! use "de" information? What is the rule for locales composed of ! just an ISO language code (say, "de") and locales with both an ! ISO language code and ISO country code (say, "de_DE"). ! !
        • what should non-required facet instantiations do? If the ! generic implemenation is provided, then how to end-users ! provide specializations? !
        ! !

        !

        7. Acknowledgments !

        !

        !

        8. Bibliography / Referenced Documents !

        Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters "6. Character Set Handling" and "7 Locales and Internationalization" !

        Drepper, Ulrich, Numerous, late-night email correspondence !

        ISO/IEC 14882:1998 Programming languages - C++ !

        ISO/IEC 9899:1999 Programming languages - C !

        Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000 !

        Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 !

        System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) The Open Group/The Institute of Electrical and Electronics Engineers, Inc. http://www.opennc.org/austin/docreg.html diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/22_locale/messages.html gcc-3.0.2/libstdc++-v3/docs/html/22_locale/messages.html *** gcc-3.0.1/libstdc++-v3/docs/html/22_locale/messages.html Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/libstdc++-v3/docs/html/22_locale/messages.html Fri Oct 19 13:07:37 2001 *************** *** 0 **** --- 1,404 ---- + + +

        + Notes on the messages implementation. +

        + + + prepared by Benjamin Kosnik (bkoz@redhat.com) on August 8, 2001 + + +

        +

        + 1. Abstract +

        +

        + The std::messages facet implements message retrieval functionality + equivalent to Java's java.text.MessageFormat .using either GNU gettext + or IEEE 1003.1-200 functions. +

        + +

        +

        + 2. What the standard says +

        + The std::messages facet is probably the most vaguely defined facet in + the standard library. It's assumed that this facility was built into + the standard library in order to convert string literals from one + locale to the other. For instance, converting the "C" locale's + const char* c = "please" to a German-localized "bitte" + during program execution. + +
        + 22.2.7.1 - Template class messages [lib.locale.messages] +
        + + This class has three public member functions, which directly + correspond to three protected virtual member functions. + + The public member functions are: + +

        + catalog open(const basic_string&, const locale&) const + +

        + string_type get(catalog, int, int, const string_type&) const + +

        + void close(catalog) const + +

        + While the virtual functions are: + +

        + catalog do_open(const basic_string&, const locale&) const +

        + + -1- Returns: A value that may be passed to get() to retrieve a + message, from the message catalog identified by the string name + according to an implementation-defined mapping. The result can be used + until it is passed to close(). Returns a value less than 0 if no such + catalog can be opened. + +
        + +

        + string_type do_get(catalog, int, int, const string_type&) const +

        + + -3- Requires: A catalog cat obtained from open() and not yet closed. + -4- Returns: A message identified by arguments set, msgid, and dfault, + according to an implementation-defined mapping. If no such message can + be found, returns dfault. + +
        + +

        + void do_close(catalog) const +

        + + -5- Requires: A catalog cat obtained from open() and not yet closed. + -6- Effects: Releases unspecified resources associated with cat. + -7- Notes: The limit on such resources, if any, is implementation-defined. + +
        + + +

        +

        + 3. Problems with "C" messages: thread safety, + over-specification, and assumptions. +

        + A couple of notes on the standard. + +

        + First, why is messages_base::catalog specified as a typedef + to int? This makes sense for implementations that use + catopen, but not for others. Fortunately, it's not heavily + used and so only a minor irritant. + +

        + Second, by making the member functions const, it is + impossible to save state in them. Thus, storing away information used + in the 'open' member function for use in 'get' is impossible. This is + unfortunate. + +

        + The 'open' member function in particular seems to be oddly + designed. The signature seems quite peculiar. Why specify a const + string& argument, for instance, instead of just const + char*? Or, why specify a const locale& argument that is + to be used in the 'get' member function? How, exactly, is this locale + argument useful? What was the intent? It might make sense if a locale + argument was associated with a given default message string in the + 'open' member function, for instance. Quite murky and unclear, on + reflection. + +

        + Lastly, it seems odd that messages, which explicitly require code + conversion, don't use the codecvt facet. Because the messages facet + has only one template parameter, it is assumed that ctype, and not + codecvt, is to be used to convert between character sets. + +

        + It is implicitly assumed that the locale for the default message + string in 'get' is in the "C" locale. Thus, all source code is assumed + to be written in English, so translations are always from "en_US" to + other, explicitly named locales. + +

        +

        + 4. Design and Implementation Details +

        + This is a relatively simple class, on the face of it. The standard + specifies very little in concrete terms, so generic implementations + that are conforming yet do very little are the norm. Adding + functionality that would be useful to programmers and comparable to + Java's java.text.MessageFormat takes a bit of work, and is highly + dependent on the capabilities of the underlying operating system. + +

        + Three different mechanisms have been provided, selectable via + configure flags: + +

          +
        • generic +

          + This model does very little, and is what is used by default. +

          + +
        • gnu +

          + The gnu model is complete and fully tested. It's based on the + GNU gettext package, which is part of glibc. It uses the functions + textdomain, bindtextdomain, gettext + to implement full functionality. Creating message + catalogs is a relatively straight-forward process and is + lightly documented below, and fully documented in gettext's + distributed documentation. +

          + +
        • ieee_1003.1-200x +

          + This is a complete, though untested, implementation based on + the IEEE standard. The functions + catopen, catgets, catclose + are used to retrieve locale-specific messages given the + appropriate message catalogs that have been constructed for + their use. Note, the script po2msg.sed that is part + of the gettext distribution can convert gettext catalogs into + catalogs that catopen can use. +

          +
        + +

        + A new, standards-conformant non-virtual member function signature was + added for 'open' so that a directory could be specified with a given + message catalog. This simplifies calling conventions for the gnu + model. + +

        + The rest of this document discusses details of the GNU model. + +

        + The messages facet, because it is retrieving and converting between + characters sets, depends on the ctype and perhaps the codecvt facet in + a given locale. In addition, underlying "C" library locale support is + necessary for more than just the LC_MESSAGES mask: + LC_CTYPE is also necessary. To avoid any unpleasantness, all + bits of the "C" mask (ie LC_ALL) are set before retrieving + messages. + +

        + Making the message catalogs can be initially tricky, but become quite + simple with practice. For complete info, see the gettext + documentation. Here's an idea of what is required: + +

          +
        • Make a source file with the required string literals + that need to be translated. See + intl/string_literals.cc for an example. + +

          +

        • Make initial catalog (see "4 Making the PO Template File" + from the gettext docs). +

          + xgettext --c++ --debug string_literals.cc -o libstdc++.pot + +

          +

        • Make language and country-specific locale catalogs. +

          + cp libstdc++.pot fr_FR.po +

          + cp libstdc++.pot de_DE.po + +

          +

        • Edit localized catalogs in emacs so that strings are + translated. +

          + emacs fr_FR.po + +

          +

        • Make the binary mo files. +

          + msgfmt fr_FR.po -o fr_FR.mo +

          + msgfmt de_DE.po -o de_DE.mo + +

          +

        • Copy the binary files into the correct directory structure. +

          + cp fr_FR.mo (dir)/fr_FR/LC_MESSAGES/libstdc++-v3.mo +

          + cp de_DE.mo (dir)/de_DE/LC_MESSAGES/libstdc++-v3.mo + +

          +

        • Use the new message catalogs. +

          + locale loc_de("de_DE"); +

          + + use_facet >(loc_de).open("libstdc++", locale(), dir); + +

        + +

        +

        + 5. Examples +

        + +
          +
        • message converting, simple example using the GNU model. + +
          + #include 
          + 
          + void test01()
          + {
          +   using namespace std;
          +   typedef std::messages::catalog catalog;
          + 
          +   // Set to the root directory of the libstdc++.mo catalogs.
          +   const char* dir = LOCALEDIR;
          +   locale loc_de("de_DE");
          + 
          +   // Cache the messages facet.
          +   const messages& mssg_de = use_facet >(loc_de); 
          + 
          +   // Check German (de_DE) locale.
          +   catalog cat_de = mssg_de.open("libstdc++", loc_c, dir);
          +   string s01 = mssg_de.get(cat_de, 0, 0, "please");
          +   string s02 = mssg_de.get(cat_de, 0, 0, "thank you");
          +   // s01 == "bitte" 
          +   // s02 == "danke" 
          +   mssg_de.close(cat_de);
          + }
          + 
          +
        + + More information can be found in the following testcases: +
          +
        • testsuite/22_locale/messages.cc +
        • testsuite/22_locale/messages_byname.cc +
        • testsuite/22_locale/messages_char_members.cc +
        + +

        +

        + 6. Unresolved Issues +

        +
          +
        • Things that are sketchy, or remain unimplemented: +
            +
          • _M_convert_from_char, _M_convert_to_char are in + flux, depending on how the library ends up doing + character set conversions. It might not be possible to + do a real character set based conversion, due to the + fact that the template parameter for messages is not + enough to instantiate the codecvt facet (1 supplied, + need at least 2 but would prefer 3). + +
          • There are issues with gettext needing the global + locale set to extract a message. This dependence on + the global locale makes the current "gnu" model non + MT-safe. Future versions of glibc, ie glibc 2.3.x will + fix this, and the C++ library bits are already in + place. +
          + +

          +

        • Development versions of the GNU "C" library, glibc 2.3 will allow + a more efficient, MT implementation of std::messages, and will + allow the removal of the _M_name_messages data member. If this + is done, it will change the library ABI. The C++ parts to + support glibc 2.3 have already been coded, but are not in use: + once this version of the "C" library is released, the marked + parts of the messages implementation can be switched over to + the new "C" library functionality. +

          +

        • At some point in the near future, std::numpunct will probably use + std::messages facilities to implement truename/falename + correctly. This is currently not done, but entries in + libstdc++.pot have already been made for "true" and "false" + string literals, so all that remains is the std::numpunct + coding and the configure/make hassles to make the installed + library search its own catalog. Currently the libstdc++.mo + catalog is only searched for the testsuite cases involving + messages members. + +

          +

        • The following member functions: + +

          + + catalog + open(const basic_string& __s, const locale& __loc) const + + +

          + + catalog + open(const basic_string&, const locale&, const char*) const; + + +

          + Don't actually return a "value less than 0 if no such catalog + can be opened" as required by the standard in the "gnu" + model. As of this writing, it is unknown how to query to see + if a specified message catalog exists using the gettext + package. +

        + +

        +

        + 7. Acknowledgments +

        + Ulrich Drepper for the character set explanations, gettext details, + and patient answering of late-night questions, Tom Tromey for the java details. + + +

        +

        + 8. Bibliography / Referenced Documents +

        + + Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters + "7 Locales and Internationalization" + +

        + Drepper, Ulrich, Thread-Aware Locale Model, A proposal. This is a + draft document describing the design of glibc 2.3 MT locale + functionality. + +

        + Drepper, Ulrich, Numerous, late-night email correspondence + +

        + ISO/IEC 9899:1999 Programming languages - C + +

        + ISO/IEC 14882:1998 Programming languages - C++ + +

        + Java 2 Platform, Standard Edition, v 1.3.1 API Specification. In + particular, java.util.Properties, java.text.MessageFormat, + java.util.Locale, java.util.ResourceBundle. + http://java.sun.com/j2se/1.3/docs/api + +

        + System Interface Definitions, Issue 7 (IEEE Std. 1003.1-200x) + The Open Group/The Institute of Electrical and Electronics Engineers, Inc. + In particular see lines 5268-5427. + http://www.opennc.org/austin/docreg.html + +

        GNU gettext tools, version 0.10.38, Native Language Support + Library and Tools. + http://sources.redhat.com/gettext + +

        + Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, + Advanced Programmer's Guide and Reference, Addison Wesley Longman, + Inc. 2000. See page 725, Internationalized Messages. + +

        + Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000 diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/23_containers/howto.html gcc-3.0.2/libstdc++-v3/docs/html/23_containers/howto.html *** gcc-3.0.1/libstdc++-v3/docs/html/23_containers/howto.html Fri Jun 8 13:09:28 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/23_containers/howto.html Fri Oct 19 13:07:38 2001 *************** *** 1,132 **** ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 23 ! ! ! ! !

        Chapter 23: Containers

        !

        Chapter 23 deals with container classes and what they offer. !

        !
        !

        Contents

        ! !
        !

        Making code unaware of the container/array difference

        !

        You're writing some code and can't decide whether to use builtin arrays or some kind of container. There are compelling reasons to use one of the container classes, but you're afraid that you'll eventually run into difficulties, change everything back to arrays, and then have to change all the code that uses those data types to keep up with the change. !

        !

        If your code makes use of the standard algorithms, this isn't as scary as it sounds. The algorithms don't know, nor care, about the kind of "container" on which they work, since the algorithms are only given endpoints to work with. For the container ! classes, these are iterators (usually begin() and ! end(), but not always). For builtin arrays, these are the address of the first element and the ! past-the-end element. !

        !

        Some very simple wrapper functions can hide all of that from the rest of the code. For example, a pair of functions called ! beginof can be written, one that takes an array, another that takes a vector. The first returns a pointer to the first ! element, and the second returns the vector's begin() iterator. !

        !

        The functions should be made template functions, and should also be declared inline. As pointed out in the comments in the code ! below, this can lead to beginof being optimized out of existence, so you pay absolutely nothing in terms of increased code size or execution time. !

        !

        The result is that if all your algorithm calls look like !

        !    std::transform(beginof(foo), endof(foo), beginof(foo), SomeFunction);
        then the type of foo can change from an array of ints to a vector of ints to a deque of ints and back again, without ever changing any client code. !

        !

        This author has a collection of such functions, called "*of" because they all extend the builtin "sizeof". It started with some Usenet discussions on a transparent way to find the length of an array. A simplified and much-reduced version for easier ! reading is given here. !

        !

        Astute readers will notice two things at once: first, that the ! container class is still a vector<T> instead of a ! more general Container<T>. This would mean that ! three functions for deque would have to be added, another ! three for list, and so on. This is due to problems with getting template resolution correct; I find it easier just to give the extra three lines and avoid confusion. !

        !

        Second, the line !

        !     inline unsigned int lengthof (T (&)[sz]) { return sz; } 
        looks just weird! Hint: unused parameters can be left nameless. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Variable-sized bitmasks

        !

        No, you cannot write code of the form !

                #include <bitset>
          
                void foo (size_t n)
                {
                    std::bitset<n>   bits;
                    ....
        !       } 
        ! because n must be known at compile time. Your compiler is correct; it is not a bug. That's the way templates work. (Yes, it ! is a feature.) !

        !

        There are a couple of ways to handle this kind of thing. Please consider all of them before passing judgement. They include, in no particular order: !

          !
        • A very large N in bitset<N>. !
        • A container<bool>. !
        • Extremely weird solutions. !
        !

        !

        A very large N in bitset<N>.   It has been pointed out a few times in newsgroups that N bits only takes up (N/8) bytes on most systems, and division by a factor of eight is pretty impressive when speaking of memory. Half a megabyte given over to a bitset (recall that there is zero space overhead for housekeeping info; it is known at compile time exactly how large the set is) will hold over four million bits. If you're using those bits as status flags (e.g., ! "changed"/"unchanged" flags), that's a lot of state. !

        !

        You can then keep track of the "maximum bit used" during some testing runs on representative data, make note of how many of those bits really need to be there, and then reduce N to a smaller number. Leave some extra space, of course. (If you plan to write code like the --- 1,134 ---- ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 23 ! ! ! !

        Chapter 23: Containers

        !

        Chapter 23 deals with container classes and what they offer. !

        !
        !

        Contents

        ! !
        !

        Making code unaware of the container/array difference

        !

        You're writing some code and can't decide whether to use builtin arrays or some kind of container. There are compelling reasons to use one of the container classes, but you're afraid that you'll eventually run into difficulties, change everything back to arrays, and then have to change all the code that uses those data types to keep up with the change. !

        !

        If your code makes use of the standard algorithms, this isn't as scary as it sounds. The algorithms don't know, nor care, about the kind of "container" on which they work, since the algorithms are only given endpoints to work with. For the container ! classes, these are iterators (usually begin() and ! end(), but not always). For builtin arrays, these are the address of the first element and the ! past-the-end element. !

        !

        Some very simple wrapper functions can hide all of that from the rest of the code. For example, a pair of functions called ! beginof can be written, one that takes an array, another that takes a vector. The first returns a pointer to the first ! element, and the second returns the vector's begin() iterator. !

        !

        The functions should be made template functions, and should also be declared inline. As pointed out in the comments in the code ! below, this can lead to beginof being optimized out of existence, so you pay absolutely nothing in terms of increased code size or execution time. !

        !

        The result is that if all your algorithm calls look like !

        !    std::transform(beginof(foo), endof(foo), beginof(foo), SomeFunction);
        then the type of foo can change from an array of ints to a vector of ints to a deque of ints and back again, without ever changing any client code. !

        !

        This author has a collection of such functions, called "*of" because they all extend the builtin "sizeof". It started with some Usenet discussions on a transparent way to find the length of an array. A simplified and much-reduced version for easier ! reading is given here. !

        !

        Astute readers will notice two things at once: first, that the ! container class is still a vector<T> instead of a ! more general Container<T>. This would mean that ! three functions for deque would have to be added, another ! three for list, and so on. This is due to problems with getting template resolution correct; I find it easier just to give the extra three lines and avoid confusion. !

        !

        Second, the line !

        !     inline unsigned int lengthof (T (&)[sz]) { return sz; } 
        looks just weird! Hint: unused parameters can be left nameless. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Variable-sized bitmasks

        !

        No, you cannot write code of the form !

                #include <bitset>
          
                void foo (size_t n)
                {
                    std::bitset<n>   bits;
                    ....
        !       } 
        ! because n must be known at compile time. Your compiler is correct; it is not a bug. That's the way templates work. (Yes, it ! is a feature.) !

        !

        There are a couple of ways to handle this kind of thing. Please consider all of them before passing judgement. They include, in no particular order: !

          !
        • A very large N in bitset<N>. !
        • A container<bool>. !
        • Extremely weird solutions. !
        !

        !

        A very large N in ! bitset<N>.   It has been pointed out a few times in newsgroups that N bits only takes up (N/8) bytes on most systems, and division by a factor of eight is pretty impressive when speaking of memory. Half a megabyte given over to a bitset (recall that there is zero space overhead for housekeeping info; it is known at compile time exactly how large the set is) will hold over four million bits. If you're using those bits as status flags (e.g., ! "changed"/"unchanged" flags), that's a lot of state. !

        !

        You can then keep track of the "maximum bit used" during some testing runs on representative data, make note of how many of those bits really need to be there, and then reduce N to a smaller number. Leave some extra space, of course. (If you plan to write code like the *************** *** 134,267 **** may have to talk your compiler into allowing that much stack space; there may be zero space overhead, but it's all allocated inside the object.) !

        !

        A container<bool>.   The Committee made provision for the space savings possible with that (N/8) usage previously mentioned, so that you don't have to do wasteful things like ! Container<char> or Container<short int>. ! Specifically, vector<bool> is required to be specialized for that space savings. !

        !

        The problem is that vector<bool> doesn't behave like a normal vector anymore. There have been recent journal articles which discuss the problems (the ones by Herb Sutter in the May and July/August 1999 issues of ! C++ Report cover it well). Future revisions of the ISO C++ ! Standard will change the requirement for vector<bool> ! specialization. In the meantime, deque<bool> is recommended (although its behavior is sane, you probably will not get the space savings, but the allocation scheme is different than that of vector). !

        !

        Extremely weird solutions.   If you have access to the compiler and linker at runtime, you can do something insane, like figuring out just how many bits you need, then writing a temporary ! source code file. That file contains an instantiation of bitset for the required number of bits, inside some wrapper functions with unchanging signatures. Have your program then call the compiler on that file using Position Independant Code, then open the newly-created object file and load those wrapper functions. You'll have ! an instantiation of bitset<N> for the exact N that you need at the time. Don't forget to delete the temporary files. ! (Yes, this can be, and has been, done.) !

        !

        This would be the approach of either a visionary genius or a raving lunatic, depending on your programming and management style. Probably the latter. !

        !

        Which of the above techniques you use, if any, are up to you and your intended application. Some time/space profiling is indicated if it really matters (don't just guess). And, if you manage to do anything along the lines of the third category, the author would love to hear from you... !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Containers and multithreading

        !

        This section will mention some of the problems in designing MT ! programs that use Standard containers. For information on other ! aspects of multithreading (e.g., the library as a whole), see ! the Received Wisdom on Chapter 17. This section only applies ! when gcc and libstdc++-v3 were configured with --enable-threads. !

        !

        Two excellent pages to read when working with templatized containers ! and threads are ! SGI's ! http://www.sgi.com/tech/stl/thread_safety.html and ! SGI's ! http://www.sgi.com/tech/stl/Allocators.html. The ! libstdc++-v3 uses the same definition of thread safety ! when discussing design. A key point that beginners may miss is the fourth major paragraph of the first page mentioned above ! ("For most clients,"...), pointing ! out that locking must nearly always be done outside the container, ! by client code (that'd be you, not us *grin*). ! However, please take caution when considering the discussion ! about the user-level configuration of the mutex lock ! implementation inside the STL container-memory allocator on that ! page. For the sake of this discussion, libstdc++-v3 configures ! the SGI STL implementation, not you. We attempt to configure ! the mutex lock as is best for your platform. In particular, ! past advice was for people using g++ to explicitly define ! _PTHREADS on the command line to get a thread-safe STL. This ! is no longer required for your port. It may or may not be ! a good idea for your port. Extremely big caution: if you ! compile some of your application code against the STL with one ! set of threading flags and macros and another portion of the ! code with different flags and macros that influence the ! selection of the mutex lock, you may well end up with multiple ! locking mechanisms in use which don't impact each other in the ! manner that they should. Everything might link and all code ! might have been built with a perfectly reasonable thread model ! but you may have two internal ABIs in play within the ! application. This might produce races, memory leaks and fatal ! crashes. In any multithreaded application using STL, this ! is the first thing to study well before blaming the allocator. !

        !

        You didn't read it, did you? *sigh* I'm serious, go read the ! SGI page. It's really good and doesn't take long, and makes most ! of the points that would otherwise have to be made here (and does ! a better job). !

        !

        That's much better. Now, the issue of MT has been brought up on ! the libstdc++-v3 mailing list as well as the main GCC mailing list ! several times. The Chapter 17 HOWTO has some links into the mail ! archives, so you can see what's been thrown around. The usual ! container (or pseudo-container, depending on how you look at it) ! that people have in mind is string, which is one of the ! points where libstdc++ departs from the SGI STL. As of the ! 2.90.8 snapshot, the libstdc++-v3 string class is safe for ! certain kinds of multithreaded access. !

        !

        For implementing a container which does its own locking, it is ! trivial to (as SGI suggests) provide a wrapper class which obtains ! the lock, performs the container operation, then releases the lock. ! This could be templatized to a certain extent, on the ! underlying container and/or a locking mechanism. Trying to provide ! a catch-all general template solution would probably be more trouble ! than it's worth. !

        ! !

        Return to top of page or ! to the FAQ. !

        ! !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: howto.html,v 1.1.4.4 2001/06/08 20:09:28 ljrittle Exp $ !

        ! ! --- 136,366 ---- may have to talk your compiler into allowing that much stack space; there may be zero space overhead, but it's all allocated inside the object.) !

        !

        A container<bool>.   The Committee ! made provision for the space savings possible with that (N/8) usage previously mentioned, so that you don't have to do wasteful things like ! Container<char> or ! Container<short int>. ! Specifically, vector<bool> is required to be specialized for that space savings. !

        !

        The problem is that vector<bool> doesn't behave like a normal vector anymore. There have been recent journal articles which discuss the problems (the ones by Herb Sutter in the May and July/August 1999 issues of ! C++ Report cover it well). Future revisions of the ISO C++ ! Standard will change the requirement for vector<bool> ! specialization. In the meantime, deque<bool> is recommended (although its behavior is sane, you probably will not get the space savings, but the allocation scheme is different than that of vector). !

        !

        Extremely weird solutions.   If you have ! access to the compiler and linker at runtime, you can do something insane, like figuring out just how many bits you need, then writing a temporary ! source code file. That file contains an instantiation of ! bitset for the required number of bits, inside some wrapper functions with unchanging signatures. Have your program then call the compiler on that file using Position Independant Code, then open the newly-created object file and load those wrapper functions. You'll have ! an instantiation of bitset<N> for the exact ! N that you need at the time. Don't forget to delete the temporary files. ! (Yes, this can be, and has been, done.) !

        !

        This would be the approach of either a visionary genius or a raving lunatic, depending on your programming and management style. Probably the latter. !

        !

        Which of the above techniques you use, if any, are up to you and your intended application. Some time/space profiling is indicated if it really matters (don't just guess). And, if you manage to do anything along the lines of the third category, the author would love to hear from you... !

        !

        Also note that the implementation of bitset used in libstdc++-v3 has ! some extensions. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Containers and multithreading

        !

        This section discusses issues surrounding the design of ! multithreaded applications which use Standard C++ containers. ! All information in this section is current as of the gcc 3.0 ! release and all later point releases. Although earlier gcc ! releases had a different approach to threading configuration and ! proper compilation, the basic code design rules presented here ! were similar. For information on all other aspects of ! multithreading as it relates to libstdc++, including details on ! the proper compilation of threaded code (and compatibility between ! threaded and non-threaded code), see Chapter 17. !

        !

        Two excellent pages to read when working with the Standard C++ ! containers and threads are ! SGI's ! http://www.sgi.com/tech/stl/thread_safety.html and ! SGI's ! http://www.sgi.com/tech/stl/Allocators.html. !

        !

        However, please ignore all discussions about the user-level ! configuration of the lock implementation inside the STL ! container-memory allocator on those pages. For the sake of this ! discussion, libstdc++-v3 configures the SGI STL implementation, ! not you. This is quite different from how gcc pre-3.0 worked. ! In particular, past advice was for people using g++ to ! explicitly define _PTHREADS or other macros or port-specific ! compilation options on the command line to get a thread-safe ! STL. This is no longer required for any port and should no ! longer be done unless you really know what you are doing and ! assume all responsibility. !

        !

        Since the container implementation of libstdc++-v3 uses the SGI ! code, we use the same definition of thread safety as SGI when ! discussing design. A key point that beginners may miss is the fourth major paragraph of the first page mentioned above ! ("For most clients,"...), which points out that ! locking must nearly always be done outside the container, by ! client code (that'd be you, not us). There is a notable ! exceptions to this rule. Allocators called while a container or ! element is constructed uses an internal lock obtained and ! released solely within libstdc++-v3 code (in fact, this is the ! reason STL requires any knowledge of the thread configuration). !

        !

        For implementing a container which does its own locking, it is ! trivial to provide a wrapper class which obtains the lock (as ! SGI suggests), performs the container operation, and then ! releases the lock. This could be templatized to a certain ! extent, on the underlying container and/or a locking ! mechanism. Trying to provide a catch-all general template ! solution would probably be more trouble than it's worth. !

        !

        Return to top of page or ! to the FAQ. !

        +
        +

        "Hinting" during insertion

        +

        Section [23.1.2], Table 69, of the C++ standard lists this function + for all of the associative containers (map, set, etc): +

        +       a.insert(p,t);
        + where 'p' is an iterator into the container 'a', and 't' is the item + to insert. The standard says that "iterator p is a hint + pointing to where the insert should start to search," but + specifies nothing more. (LWG Issue #233, currently in review, + addresses this topic, but I will ignore it here because it is not yet + finalized.) +

        +

        Here we'll describe how the hinting works in the libstdc++-v3 + implementation, and what you need to do in order to take advantage of + it. (Insertions can change from logarithmic complexity to amortized + constant time, if the hint is properly used.) Also, since the current + implementation is based on the SGI STL one, these points may hold true + for other library implementations also, since the HP/SGI code is used + in a lot of places. +

        +

        In the following text, the phrases greater than and less + than refer to the results of the strict weak ordering imposed on + the container by its comparison object, which defaults to (basically) + "<". Using those phrases is semantically sloppy, but I + didn't want to get bogged down in syntax. I assume that if you are + intelligent enough to use your own comparison objects, you are also + intelligent enough to assign "greater" and "lesser" + their new meanings in the next paragraph. *grin* +

        +

        If the hint parameter ('p' above) is equivalent to: +

          +
        • begin(), then the item being inserted should have a key + less than all the other keys in the container. The item will + be inserted at the beginning of the container, becoming the new + entry at begin(). +
        • end(), then the item being inserted should have a key + greater than all the other keys in the container. The item will + be inserted at the end of the container, becoming the new entry + at end(). +
        • neither begin() nor end(), then: Let h + be the entry in the container pointed to by hint, that + is, h = *hint. Then the item being inserted should have + a key less than that of h, and greater than that of the + item preceeding h. The new item will be inserted + between h and h's predecessor. +
        +

        +

        For multimap and multiset, the restrictions are + slightly looser: "greater than" should be replaced by + "not less than" and "less than" should be replaced + by "not greater than." (Why not replace greater with + greater-than-or-equal-to? You probably could in your head, but the + mathematicians will tell you that it isn't the same thing.) +

        +

        If the conditions are not met, then the hint is not used, and the + insertion proceeds as if you had called a.insert(t) + instead. (Note that GCC releases prior to 3.0.2 + had a bug in the case with hint == begin() for the + map and set classes. You should not use a hint + argument in those releases.) +

        +

        This behavior goes well with other container's insert() + functions which take an iterator: if used, the new item will be + inserted before the iterator passed as an argument, same as the other + containers. The exception + (in a sense) is with a hint of end(): the new item will + actually be inserted after end(), but it also becomes the + new end(). +

        +

        Note also that the hint in this implementation is a + one-shot. The insertion-with-hint routines check the immediately + surrounding entries to ensure that the new item would in fact belong + there. If the hint does not point to the correct place, then no + further local searching is done; the search begins from scratch in + logarithmic time. (Further local searching would only increase the + time required when the hint is too far off.) +

        +

        Return to top of page or + to the FAQ. +

        +
        +

        Bitmasks and string arguments

        +

        Bitmasks do not take char* nor const char* arguments in their + constructors. This is something of an accident, but you can read + about the problem: follow the library's "Links" from the + homepage, and from the C++ information "defect reflector" + link, select the library issues list. Issue number 116 describes the + problem. +

        +

        For now you can simply make a temporary string object using the + constructor expression: +

        +       std::bitset<5> b ( std::string("10110") );
        +       
        + instead of +
        +       std::bitset<5> b ( "10110" );    // invalid
        +       
        +

        +

        Return to top of page or + to the FAQ. +

        + !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/24_iterators/howto.html gcc-3.0.2/libstdc++-v3/docs/html/24_iterators/howto.html *** gcc-3.0.1/libstdc++-v3/docs/html/24_iterators/howto.html Wed May 30 14:59:32 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/24_iterators/howto.html Fri Oct 19 13:07:38 2001 *************** *** 1,108 **** ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 24 ! ! ! ! !

        Chapter 24: Iterators

        !

        Chapter 24 deals with the FORTRAN subroutines for automatically transforming lemmings into gold. !

        !
        !

        Contents

        ! !
        !

        They ain't pointers!

        !

        FAQ 5.1 points out that iterators are not implemented as pointers. They are a generalization of pointers, but they are implemented in libstdc++-v3 as separate classes. !

        !

        Keeping that simple fact in mind as you design your code will prevent a whole lot of difficult-to-understand bugs. !

        !

        You can think of it the other way 'round, even. Since iterators ! are a generalization, that means that pointers are ! iterators, and that pointers can be used whenever an iterator would be. All those functions in the Algorithms chapter of the Standard will work just as well on plain arrays and their pointers. !

        !

        That doesn't mean that when you pass in a pointer, it gets wrapped into some special delegating iterator-to-pointer class with a layer of overhead. (If you think that's the case anywhere, you don't understand templates to begin with...) Oh, no; if you pass in a pointer, then the compiler will instantiate that template ! using T* as a type and good old high-speed pointer arithmetic as its operations, so the resulting code will be doing exactly the same things as it would be doing if you had hand-coded it yourself (for the 273rd time). !

        !

        How much overhead is there when using an interator class? Very little. Most of the layering classes contain nothing but typedefs, and typedefs are "meta-information" that simply tell the compiler some nicknames; they don't create code. That information gets passed down through inheritance, so while the compiler has to do work looking up all the names, your runtime code does not. (This has been a prime concern from the beginning.) !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        It ends where?

        !

        This starts off sounding complicated, but is actually very easy, especially towards the end. Trust me. !

        !

        Beginners usually have a little trouble understand the whole 'past-the-end' thing, until they remember their early algebra classes ! (see, they told you that stuff would come in handy!) and the concept of half-open ranges. !

        !

        First, some history, and a reminder of some of the funkier rules in C and C++ for builtin arrays. The following rules have always been true for both languages: !

          !
        1. You can point anywhere in the array, or to the first element ! past the end of the array. A pointer that points to one past the end of the array is guaranteed to be as unique as a pointer to somewhere inside the array, so that you can compare such pointers safely. !
        2. You can only dereference a pointer that points into an array. If your array pointer points outside the array -- even to just one past the end -- and you dereference it, Bad Things happen. !
        3. Strictly speaking, simply pointing anywhere else invokes undefined behavior. Most programs won't puke until such a pointer is actually dereferenced, but the standards leave that up to the platform. !
        The reason this past-the-end addressing was allowed is to make it easy to write a loop to go over an entire array, e.g., while (*d++ = *s++);. !

        !

        So, when you think of two pointers delimiting an array, don't think ! of them as indexing 0 through n-1. Think of them as boundary ! markers: !

          
             beginning            end
               |                   |
        --- 1,107 ----
          
        ! 
        ! 
        !    
        !    
        !    
        !    
        !    
        !    libstdc++-v3 HOWTO:  Chapter 24
        ! 
        ! 
        ! 
          
        ! 

        Chapter 24: Iterators

        !

        Chapter 24 deals with the FORTRAN subroutines for automatically transforming lemmings into gold. !

        !
        !

        Contents

        ! !
        !

        They ain't pointers!

        !

        FAQ 5.1 points out that iterators are not implemented as pointers. They are a generalization of pointers, but they are implemented in libstdc++-v3 as separate classes. !

        !

        Keeping that simple fact in mind as you design your code will prevent a whole lot of difficult-to-understand bugs. !

        !

        You can think of it the other way 'round, even. Since iterators ! are a generalization, that means that pointers are ! iterators, and that pointers can be used whenever an iterator would be. All those functions in the Algorithms chapter of the Standard will work just as well on plain arrays and their pointers. !

        !

        That doesn't mean that when you pass in a pointer, it gets wrapped into some special delegating iterator-to-pointer class with a layer of overhead. (If you think that's the case anywhere, you don't understand templates to begin with...) Oh, no; if you pass in a pointer, then the compiler will instantiate that template ! using T* as a type, and good old high-speed pointer arithmetic as its operations, so the resulting code will be doing exactly the same things as it would be doing if you had hand-coded it yourself (for the 273rd time). !

        !

        How much overhead is there when using an interator class? Very little. Most of the layering classes contain nothing but typedefs, and typedefs are "meta-information" that simply tell the compiler some nicknames; they don't create code. That information gets passed down through inheritance, so while the compiler has to do work looking up all the names, your runtime code does not. (This has been a prime concern from the beginning.) !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        It ends where?

        !

        This starts off sounding complicated, but is actually very easy, especially towards the end. Trust me. !

        !

        Beginners usually have a little trouble understand the whole 'past-the-end' thing, until they remember their early algebra classes ! (see, they told you that stuff would come in handy!) and the concept of half-open ranges. !

        !

        First, some history, and a reminder of some of the funkier rules in C and C++ for builtin arrays. The following rules have always been true for both languages: !

          !
        1. You can point anywhere in the array, or to the first element ! past the end of the array. A pointer that points to one past the end of the array is guaranteed to be as unique as a pointer to somewhere inside the array, so that you can compare such pointers safely. !
        2. You can only dereference a pointer that points into an array. If your array pointer points outside the array -- even to just one past the end -- and you dereference it, Bad Things happen. !
        3. Strictly speaking, simply pointing anywhere else invokes undefined behavior. Most programs won't puke until such a pointer is actually dereferenced, but the standards leave that up to the platform. !
        The reason this past-the-end addressing was allowed is to make it easy to write a loop to go over an entire array, e.g., while (*d++ = *s++);. !

        !

        So, when you think of two pointers delimiting an array, don't think ! of them as indexing 0 through n-1. Think of them as boundary ! markers: !

          
             beginning            end
               |                   |
        ***************
        *** 122,184 ****
               |                       |           dereference 'end'.
             beginning                end
          
        !       
        See? Everything between the boundary markers is part of the array. Simple. !

        !

        Now think back to your junior-high school algebra course, when you were learning how to draw graphs. Remember that a graph terminating with a solid dot meant, "Everything up through this point," and a graph terminating with an open dot meant, "Everything up to, but not including, this point," respectively called closed and open ranges? Remember how closed ranges were written with ! brackets, [a,b], and open ranges were written with parentheses, ! (a,b)? !

        !

        The boundary markers for arrays describe a half-open range, starting with (and including) the first element, and ending with (but ! not including) the last element: [beginning,end). See, I told you it would be simple in the end. !

        !

        Iterators, and everything working with iterators, follows this same ! time-honored tradition. A container's begin() method returns ! an iterator referring to the first element, and its end() method returns a past-the-end iterator, which is guaranteed to be unique and comparable against any other iterator pointing into the middle of the container. !

        !

        Container constructors, container methods, and algorithms, all take pairs of iterators describing a range of values on which to operate. All of these ranges are half-open ranges, so you pass the beginning iterator as the starting parameter, and the one-past-the-end iterator as the finishing parameter. !

        !

        This generalizes very well. You can operate on sub-ranges quite ! easily this way; functions accepting a [first,last) range don't know or care whether they are the boundaries of an entire {array, sequence, container, whatever}, or whether they only enclose a few elements from the center. This approach also makes zero-length sequences very simple to recognize: if the two endpoints compare equal, then the {array, sequence, container, whatever} is empty. !

        !

        Just don't dereference end(). !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: howto.html,v 1.1.4.2 2001/05/30 21:59:32 pme Exp $ !

        ! ! --- 121,183 ---- | | dereference 'end'. beginning end !
        See? Everything between the boundary markers is part of the array. Simple. !

        !

        Now think back to your junior-high school algebra course, when you were learning how to draw graphs. Remember that a graph terminating with a solid dot meant, "Everything up through this point," and a graph terminating with an open dot meant, "Everything up to, but not including, this point," respectively called closed and open ranges? Remember how closed ranges were written with ! brackets, [a,b], and open ranges were written with parentheses, ! (a,b)? !

        !

        The boundary markers for arrays describe a half-open range, starting with (and including) the first element, and ending with (but ! not including) the last element: [beginning,end). See, I told you it would be simple in the end. !

        !

        Iterators, and everything working with iterators, follows this same ! time-honored tradition. A container's begin() method returns ! an iterator referring to the first element, and its end() method returns a past-the-end iterator, which is guaranteed to be unique and comparable against any other iterator pointing into the middle of the container. !

        !

        Container constructors, container methods, and algorithms, all take pairs of iterators describing a range of values on which to operate. All of these ranges are half-open ranges, so you pass the beginning iterator as the starting parameter, and the one-past-the-end iterator as the finishing parameter. !

        !

        This generalizes very well. You can operate on sub-ranges quite ! easily this way; functions accepting a [first,last) range don't know or care whether they are the boundaries of an entire {array, sequence, container, whatever}, or whether they only enclose a few elements from the center. This approach also makes zero-length sequences very simple to recognize: if the two endpoints compare equal, then the {array, sequence, container, whatever} is empty. !

        !

        Just don't dereference end(). !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/25_algorithms/howto.html gcc-3.0.2/libstdc++-v3/docs/html/25_algorithms/howto.html *** gcc-3.0.1/libstdc++-v3/docs/html/25_algorithms/howto.html Wed May 30 14:59:32 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/25_algorithms/howto.html Fri Oct 19 13:07:39 2001 *************** *** 1,95 **** ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 25 ! ! ! ! !

        Chapter 25: Algorithms

        !

        Chapter 25 deals with the generalized subroutines for automatically transforming lemmings into gold. !

        !
        !

        Contents

        ! !
        !

        Prerequisites

        !

        The neatest accomplishment of the algorithms chapter is that all the work is done via iterators, not containers directly. This means two important things: !

          !
        1. Anything that behaves like an iterator can be used in one of these algorithms. Raw pointers make great candidates, thus ! built-in arrays are fine containers. So do your own iterators. !
        2. The algorithms do not (and cannot) affect the container as a whole; only the things between the two iterator endpoints. If you pass a range of iterators only enclosing the middle third of a container, then anything outside that range is inviolate. !
        !

        !

        Even strings can be fed through the algorithms here, although the string class has specialized versions of many of these functions (for ! example, string::find()). Most of the examples on this page will use simple arrays of integers as a playground for algorithms, just to keep things simple. ! The use of N as a size in the examples is ! to keep things easy to read but probably won't be legal code. You can ! use wrappers such as those described in the ! containers chapter to keep real code readable. !

        !

        The single thing that trips people up the most is the definition of ! range used with iterators; the famous "past-the-end" rule that everybody loves to hate. The ! iterators chapter of this document has a complete explanation of this simple rule that seems to ! cause so much confusion. Once you get range into your head (it's not that hard, honest!), then the algorithms are a cakewalk. !

        !

        !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Topic

        !

        Blah. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: howto.html,v 1.1.4.2 2001/05/30 21:59:32 pme Exp $ !

        ! ! --- 1,102 ---- ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 25 ! ! ! !

        Chapter 25: Algorithms

        !

        Chapter 25 deals with the generalized subroutines for automatically transforming lemmings into gold. !

        !
        !

        Contents

        ! !
        !

        Prerequisites

        !

        The neatest accomplishment of the algorithms chapter is that all the work is done via iterators, not containers directly. This means two important things: !

          !
        1. Anything that behaves like an iterator can be used in one of these algorithms. Raw pointers make great candidates, thus ! built-in arrays are fine containers, as well as your own iterators. !
        2. The algorithms do not (and cannot) affect the container as a whole; only the things between the two iterator endpoints. If you pass a range of iterators only enclosing the middle third of a container, then anything outside that range is inviolate. !
        !

        !

        Even strings can be fed through the algorithms here, although the string class has specialized versions of many of these functions (for ! example, string::find()). Most of the examples on this page will use simple arrays of integers as a playground for algorithms, just to keep things simple. ! The use of N as a size in the ! examples is to keep things easy to read but probably won't be valid ! code. You can use wrappers such as those described in the ! containers chapter to keep real code readable. !

        !

        The single thing that trips people up the most is the definition of ! range used with iterators; the famous "past-the-end" rule that everybody loves to hate. The ! iterators chapter of this document has a complete explanation of this simple rule that seems to ! cause so much confusion. Once you get range into your head (it's not that hard, honest!), then the algorithms are a cakewalk. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Special swaps

        !

        If you call std::swap(x,y); where x and y are standard ! containers, then the call will automatically be replaced by a call to ! x.swap(y); instead. !

        !

        This allows member functions of each container class to take over, and ! containers' swap functions should have O(1) complexity according to ! the standard. (And while "should" allows implementations to ! behave otherwise and remain compliant, this implementation does in ! fact use constant-time swaps.) This should not be surprising, since ! for two containers of the same type to swap contents, only some ! internal pointers to storage need to be exchanged. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/26_numerics/howto.html gcc-3.0.2/libstdc++-v3/docs/html/26_numerics/howto.html *** gcc-3.0.1/libstdc++-v3/docs/html/26_numerics/howto.html Wed May 30 14:59:32 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/26_numerics/howto.html Fri Oct 19 13:07:39 2001 *************** *** 1,109 **** ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 26 ! ! ! ! !

        Chapter 26: Numerics

        !

        Chapter 26 deals with building block abstractions to aid in numerical computing: !

          !
        • Template data structures such as valarray<> ! and complex<>. !
        • Template numerical functions such as accumulate; ! inner_product; partial_sum and ! adjacent_difference. !
        All of the Standard C math functions are of course included in C++, ! and overloaded versions for long, float, and ! long double have been added for all of them. !

        !
        !

        Contents

        ! !
        !

        Complex Number Processing

        !

        Using complex<> becomes even more comple- er, sorry, ! complicated, with the not-quite-gratuitously-incompatible addition of complex types to the C language. David Tribble has compiled a list of C++98 and C99 conflict points; his description of C's new type versus those of C++ and how to get them playing together nicely is ! here. !

        !

        complex<> is intended to be instantiated with a floating-point type. As long as you meet that and some other basic requirements, then the resulting instantiation has all of the usual ! math operators defined, as well as definitions of op<< ! and op>> that work with iostreams: op<< ! prints (u,v) and op>> can read u, ! (u), and (u,v). !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Array Processing

        !

        One of the major reasons why FORTRAN can chew through numbers so well is that it is defined to be free of pointer aliasing, an assumption ! that C89 is not allowed to make, and neither is C++. C99 adds a new ! keyword, restrict, to apply to individual pointers. The C++ ! solution is contained in the library rather than the language (although many vendors can be expected to add this to their compilers as an extension). !

        !

        That library solution is a set of two classes, five template classes, and "a whole bunch" of functions. The classes are required to be free of pointer aliasing, so compilers can optimize the daylights out of them the same way that they have been for FORTRAN. ! They are collectively called valarray, although strictly speaking this is only one of the five template classes, and they are designed to be familiar to people who have worked with the BLAS libraries before. !

        !

        Some more stuff should go here once somebody has time to write it. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Numerical Functions

        !

        There are four generalized functions in the <numeric> header that follow the same conventions as those in <algorithm>. Each of them is overloaded: one signature for common default operations, and a second for fully general operations. Their names are self-explanatory to anyone who works with numerics on a regular basis: !

          !
        • accumulate !
        • inner_product !
        • partial_sum !
        • adjacent_difference !
        !

        !

        Here is a simple example of the two forms of accumulate. !

             int   ar[50];
             int   someval = somefunction();
          
        --- 1,108 ----
          
        ! 
        ! 
        !    
        !    
        !    
        !    
        !    
        !    libstdc++-v3 HOWTO:  Chapter 26
        ! 
        ! 
        ! 
          
        ! 

        Chapter 26: Numerics

        !

        Chapter 26 deals with building block abstractions to aid in numerical computing: !

          !
        • Template data structures such as valarray<> ! and complex<>. !
        • Template numerical functions such as accumulate, ! inner_product, partial_sum, and ! adjacent_difference. !
        All of the Standard C math functions are of course included in C++, ! and overloaded versions for long, float, and ! long double have been added for all of them. !

        !
        !

        Contents

        ! !
        !

        Complex Number Processing

        !

        Using complex<> becomes even more comple- er, sorry, ! complicated, with the not-quite-gratuitously-incompatible addition of complex types to the C language. David Tribble has compiled a list of C++98 and C99 conflict points; his description of C's new type versus those of C++ and how to get them playing together nicely is ! here. !

        !

        complex<> is intended to be instantiated with a floating-point type. As long as you meet that and some other basic requirements, then the resulting instantiation has all of the usual ! math operators defined, as well as definitions of op<< ! and op>> that work with iostreams: op<< ! prints (u,v) and op>> can read u, ! (u), and (u,v). !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Array Processing

        !

        One of the major reasons why FORTRAN can chew through numbers so well is that it is defined to be free of pointer aliasing, an assumption ! that C89 is not allowed to make, and neither is C++98. C99 adds a new ! keyword, restrict, to apply to individual pointers. The ! C++ solution is contained in the library rather than the language (although many vendors can be expected to add this to their compilers as an extension). !

        !

        That library solution is a set of two classes, five template classes, and "a whole bunch" of functions. The classes are required to be free of pointer aliasing, so compilers can optimize the daylights out of them the same way that they have been for FORTRAN. ! They are collectively called valarray, although strictly speaking this is only one of the five template classes, and they are designed to be familiar to people who have worked with the BLAS libraries before. !

        !

        Some more stuff should go here once somebody has time to write it. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Numerical Functions

        !

        There are four generalized functions in the <numeric> header that follow the same conventions as those in <algorithm>. Each of them is overloaded: one signature for common default operations, and a second for fully general operations. Their names are self-explanatory to anyone who works with numerics on a regular basis: !

          !
        • accumulate !
        • inner_product !
        • partial_sum !
        • adjacent_difference !
        !

        !

        Here is a simple example of the two forms of accumulate. !

             int   ar[50];
             int   someval = somefunction();
          
        ***************
        *** 112,163 ****
             int  sum       = std::accumulate(ar,ar+50,0);
             int  sum_stuff = std::accumulate(ar,ar+50,someval);
             int  product   = std::accumulate(ar,ar+50,1,std::multiplies<int>());
        !       
        The first call adds all the members of the array, using zero as an ! initial value for sum. The second does the same, but uses ! someval as the starting value (thus, sum_stuff == sum + ! someval). The final call uses the second of the two signatures, and multiplies all the members of the array; here we must obviously use 1 as a starting value instead of 0. !

        !

        The other three functions have similar dual-signature forms. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        C99

        !

        In addition to the other topics on this page, we'll note here some of the C99 features that appear in libstdc++-v3. !

        !

        The C99 features depend on the --enable-c99 configure flag. This flag is already on by default, but it can be disabled by the user. Also, the configuration machinery will disable it if the neccessary support for C99 (e.g., header files) cannot be found. !

        !

        As of GCC 3.0, C99 support includes classification functions ! such as isnormal, isgreater, isnan, etc. ! The functions used for 'long long' support such as strtoll ! are supported, as is the lldiv_t typedef. Also supported are the wide character functions using 'long long', like ! wcstoll. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: howto.html,v 1.1.4.2 2001/05/30 21:59:32 pme Exp $ !

        ! ! --- 111,163 ---- int sum = std::accumulate(ar,ar+50,0); int sum_stuff = std::accumulate(ar,ar+50,someval); int product = std::accumulate(ar,ar+50,1,std::multiplies<int>()); !
        The first call adds all the members of the array, using zero as an ! initial value for sum. The second does the same, but uses ! someval as the starting value (thus, sum_stuff == sum + ! someval). The final call uses the second of the two signatures, and multiplies all the members of the array; here we must obviously use 1 as a starting value instead of 0. !

        !

        The other three functions have similar dual-signature forms. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        C99

        !

        In addition to the other topics on this page, we'll note here some of the C99 features that appear in libstdc++-v3. !

        !

        The C99 features depend on the --enable-c99 configure flag. This flag is already on by default, but it can be disabled by the user. Also, the configuration machinery will disable it if the neccessary support for C99 (e.g., header files) cannot be found. !

        !

        As of GCC 3.0, C99 support includes classification functions ! such as isnormal, isgreater, ! isnan, etc. ! The functions used for 'long long' support such as strtoll ! are supported, as is the lldiv_t typedef. Also supported are the wide character functions using 'long long', like ! wcstoll. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/27_io/howto.html gcc-3.0.2/libstdc++-v3/docs/html/27_io/howto.html *** gcc-3.0.1/libstdc++-v3/docs/html/27_io/howto.html Wed Jul 18 14:39:58 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/27_io/howto.html Fri Oct 19 13:07:40 2001 *************** *** 1,85 **** ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 27 ! ! ! ! !

        Chapter 27: Input/Output

        !

        Chapter 27 deals with iostreams and all their subcomponents ! and extensions. All kinds of fun stuff. !

        !
        !

        Contents

        ! !
        !

        Copying a file

        !

        So you want to copy a file quickly and easily, and most important, completely portably. And since this is C++, you have an open ifstream (call it IN) and an open ofstream (call it OUT): !

             #include <fstream>
          
             std::ifstream  IN ("input_file");
        !    std::ofstream  OUT ("output_file"); 
        !

        !

        Here's the easiest way to get it completely wrong: !

        !    OUT << IN;
        For those of you who don't already know why this doesn't work (probably from having done it before), I invite you to quickly create a simple text file called "input_file" containing the sentence !
        !    The quick brown fox jumped over the lazy dog.
        surrounded by blank lines. Code it up and try it. The contents of "output_file" may surprise you. !

        !

        Seriously, go do it. Get surprised, then come back. It's worth it. !

        !
        !

        The thing to remember is that the basic_[io]stream classes handle formatting, nothing else. In particular, they break up on whitespace. The actual reading, writing, and storing of data is ! handled by the basic_streambuf family. Fortunately, the ! operator<< is overloaded to take an ostream and a pointer-to-streambuf, in order to help with just this kind of "dump the data verbatim" situation. !

        !

        Why a pointer to streambuf and not just a streambuf? Well, the [io]streams hold pointers (or references, depending on the implementation) to their buffers, not the actual buffers. This allows polymorphic behavior on the part of the buffers as well as the streams themselves. The pointer is easily retrieved ! using the rdbuf() member function. Therefore, the easiest way to copy the file is: !

        !    OUT << IN.rdbuf();
        !

        !

        So what was happening with OUT<<IN? Undefined behavior, since that particular << isn't defined by the Standard. I have seen instances where it is implemented, but the character extraction process removes all the whitespace, leaving you with no --- 1,85 ---- ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Chapter 27 ! ! ! !

        Chapter 27: Input/Output

        !

        Chapter 27 deals with iostreams and all their subcomponents ! and extensions. All kinds of fun stuff. !

        !
        !

        Contents

        ! !
        !

        Copying a file

        !

        So you want to copy a file quickly and easily, and most important, completely portably. And since this is C++, you have an open ifstream (call it IN) and an open ofstream (call it OUT): !

             #include <fstream>
          
             std::ifstream  IN ("input_file");
        !    std::ofstream  OUT ("output_file"); 
        !

        !

        Here's the easiest way to get it completely wrong: !

        !    OUT << IN;
        For those of you who don't already know why this doesn't work (probably from having done it before), I invite you to quickly create a simple text file called "input_file" containing the sentence !
        !    The quick brown fox jumped over the lazy dog.
        surrounded by blank lines. Code it up and try it. The contents of "output_file" may surprise you. !

        !

        Seriously, go do it. Get surprised, then come back. It's worth it. !

        !
        !

        The thing to remember is that the basic_[io]stream classes handle formatting, nothing else. In particular, they break up on whitespace. The actual reading, writing, and storing of data is ! handled by the basic_streambuf family. Fortunately, the ! operator<< is overloaded to take an ostream and a pointer-to-streambuf, in order to help with just this kind of "dump the data verbatim" situation. !

        !

        Why a pointer to streambuf and not just a streambuf? Well, the [io]streams hold pointers (or references, depending on the implementation) to their buffers, not the actual buffers. This allows polymorphic behavior on the part of the buffers as well as the streams themselves. The pointer is easily retrieved ! using the rdbuf() member function. Therefore, the easiest way to copy the file is: !

        !    OUT << IN.rdbuf();
        !

        !

        So what was happening with OUT<<IN? Undefined behavior, since that particular << isn't defined by the Standard. I have seen instances where it is implemented, but the character extraction process removes all the whitespace, leaving you with no *************** *** 88,156 **** member pointers) sometimes gets converted to a void*, and the output file then contains a perfect text representation of a hexidecimal address (quite a big surprise). Others don't compile at all. !

        !

        Also note that none of this is specific to o*f*streams. The operators shown above are all defined in the parent basic_ostream class and are therefore available with all possible descendents. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        The buffering is screwing up my program!

        !

        First, are you sure that you understand buffering? Particularly the fact that C++ may not, in fact, have anything to do with it? !

        !

        The rules for buffering can be a little odd, but they aren't any different from those of C. (Maybe that's why they can be a bit odd.) Many people think that writing a newline to an output stream automatically flushes the output buffer. This is true only when the output stream is, in fact, a terminal and not a file ! or some other device -- and that may not even be true since C++ says nothing about files nor terminals. All of that is system-dependant. (The "newline-buffer-flushing only occuring on terminals" thing is mostly true on Unix systems, though.) !

        !

        Some people also believe that sending endl down an output stream only writes a newline. This is incorrect; after a newline is written, the buffer is also flushed. Perhaps this is the effect you want when writing to a screen -- get the text out as soon as possible, etc -- but the buffering is largely wasted when doing this to a file: !

             output << "a line of text" << endl;
             output << some_data_variable << endl;
        !    output << "another line of text" << endl; 
        The proper thing to do in this case to just write the data out and let the libraries and the system worry about the buffering. If you need a newline, just write a newline: !
             output << "a line of text\n"
                    << some_data_variable << '\n'
        !           << "another line of text\n"; 
        I have also joined the output statements into a single statement. You could make the code prettier by moving the single newline to the start of the quoted text on the thing line, for example. !

        !

        If you do need to flush the buffer above, you can send an ! endl if you also need a newline, or just flush the buffer yourself: !

             output << ...... << flush;    // can use std::flush manipulator
        !    output.flush();               // or call a member fn 
        !

        !

        On the other hand, there are times when writing to a file should be like writing to standard error; no buffering should be done because the data needs to appear quickly (a prime example is a log file for security-related information). The way to do this is ! just to turn off the buffering before any I/O operations at ! all have been done, i.e., as soon as possible after opening: !

             std::ofstream    os ("/foo/bar/baz");
             std::ifstream    is ("/qux/quux/quuux");
             int   i;
        --- 88,156 ----
                member pointers) sometimes gets converted to a void*, and the output
                file then contains a perfect text representation of a hexidecimal
                address (quite a big surprise).  Others don't compile at all.
        !    

        !

        Also note that none of this is specific to o*f*streams. The operators shown above are all defined in the parent basic_ostream class and are therefore available with all possible descendents. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        The buffering is screwing up my program!

        !

        First, are you sure that you understand buffering? Particularly the fact that C++ may not, in fact, have anything to do with it? !

        !

        The rules for buffering can be a little odd, but they aren't any different from those of C. (Maybe that's why they can be a bit odd.) Many people think that writing a newline to an output stream automatically flushes the output buffer. This is true only when the output stream is, in fact, a terminal and not a file ! or some other device -- and that may not even be true since C++ says nothing about files nor terminals. All of that is system-dependant. (The "newline-buffer-flushing only occuring on terminals" thing is mostly true on Unix systems, though.) !

        !

        Some people also believe that sending endl down an output stream only writes a newline. This is incorrect; after a newline is written, the buffer is also flushed. Perhaps this is the effect you want when writing to a screen -- get the text out as soon as possible, etc -- but the buffering is largely wasted when doing this to a file: !

             output << "a line of text" << endl;
             output << some_data_variable << endl;
        !    output << "another line of text" << endl; 
        The proper thing to do in this case to just write the data out and let the libraries and the system worry about the buffering. If you need a newline, just write a newline: !
             output << "a line of text\n"
                    << some_data_variable << '\n'
        !           << "another line of text\n"; 
        I have also joined the output statements into a single statement. You could make the code prettier by moving the single newline to the start of the quoted text on the thing line, for example. !

        !

        If you do need to flush the buffer above, you can send an ! endl if you also need a newline, or just flush the buffer yourself: !

             output << ...... << flush;    // can use std::flush manipulator
        !    output.flush();               // or call a member fn 
        !

        !

        On the other hand, there are times when writing to a file should be like writing to standard error; no buffering should be done because the data needs to appear quickly (a prime example is a log file for security-related information). The way to do this is ! just to turn off the buffering before any I/O operations at ! all have been done, i.e., as soon as possible after opening: !

             std::ofstream    os ("/foo/bar/baz");
             std::ifstream    is ("/qux/quux/quuux");
             int   i;
        ***************
        *** 159,207 ****
             is.rdbuf()->pubsetbuf(0,0);
             ...
             os << "this data is written immediately\n";
        !    is >> i;   // and this will probably cause a disk read 
        !

        !

        Since all aspects of buffering are handled by a streambuf-derived ! member, it is necessary to get at that member with rdbuf(). ! Then the public version of setbuf can be called. The arguments are the same as those for the Standard C I/O Library function (a buffer area followed by its size). !

        !

        A great deal of this is implementation-dependant. For example, ! streambuf does not specify any actions for its own ! setbuf()-ish functions; the classes derived from ! streambuf each define behavior that "makes ! sense" for that class: an argument of (0,0) turns off ! buffering for filebuf but has undefined behavior for ! its sibling stringbuf, and specifying anything other ! than (0,0) has varying effects. Other user-defined class derived ! from streambuf can do whatever they want. !

        !

        A last reminder: there are usually more buffers involved than just those at the language/library level. Kernel buffers, disk buffers, and the like will also have an effect. Inspecting and changing those are system-dependant. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Binary I/O

        !

        The first and most important thing to remember about binary I/O is ! that opening a file with ios::binary is not, repeat ! not, the only thing you have to do. It is not a silver ! bullet, and will not allow you to use the <</>> operators of the normal fstreams to do binary I/O. !

        !

        Sorry. Them's the breaks. !

        !

        This isn't going to try and be a complete tutorial on reading and writing binary files (because "binary" ! covers a lot of ground), but we will try and clear up a couple of misconceptions and common errors. !

        !

        First, ios::binary has exactly one defined effect, no more and no less. Normal text mode has to be concerned with the newline characters, and the runtime system will translate between (for example) '\n' and the appropriate end-of-line sequence (LF on Unix, --- 159,210 ---- is.rdbuf()->pubsetbuf(0,0); ... os << "this data is written immediately\n"; ! is >> i; // and this will probably cause a disk read

        !

        !

        Since all aspects of buffering are handled by a streambuf-derived ! member, it is necessary to get at that member with rdbuf(). ! Then the public version of setbuf can be called. The arguments are the same as those for the Standard C I/O Library function (a buffer area followed by its size). !

        !

        A great deal of this is implementation-dependant. For example, ! streambuf does not specify any actions for its own ! setbuf()-ish functions; the classes derived from ! streambuf each define behavior that "makes ! sense" for that class: an argument of (0,0) turns off buffering ! for filebuf but has undefined behavior for its sibling ! stringbuf, and specifying anything other than (0,0) has ! varying effects. Other user-defined class derived from streambuf can ! do whatever they want. (For filebuf and arguments for ! (p,s) other than zeros, libstdc++ does what you'd expect: ! the first s bytes of p are used as a buffer, ! which you must allocate and deallocate.) !

        !

        A last reminder: there are usually more buffers involved than just those at the language/library level. Kernel buffers, disk buffers, and the like will also have an effect. Inspecting and changing those are system-dependant. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Binary I/O

        !

        The first and most important thing to remember about binary I/O is ! that opening a file with ios::binary is not, repeat ! not, the only thing you have to do. It is not a silver ! bullet, and will not allow you to use the <</>> operators of the normal fstreams to do binary I/O. !

        !

        Sorry. Them's the breaks. !

        !

        This isn't going to try and be a complete tutorial on reading and writing binary files (because "binary" ! covers a lot of ground), but we will try and clear up a couple of misconceptions and common errors. !

        !

        First, ios::binary has exactly one defined effect, no more and no less. Normal text mode has to be concerned with the newline characters, and the runtime system will translate between (for example) '\n' and the appropriate end-of-line sequence (LF on Unix, *************** *** 213,341 **** if it is doing so in your program then you've discovered a bug in your vendor's compiler (or some other part of the C++ implementation, possibly the runtime system). !

        !

        Second, using << to write and >> to read isn't going to work with the standard file stream classes, even ! if you use skipws during reading. Why not? Because ! ifstream and ofstream exist for the purpose of formatting, not reading and writing. Their job is to interpret the data into text characters, and that's exactly what you don't want to happen during binary I/O. !

        !

        Third, using the get() and put()/write() member functions still aren't guaranteed to help you. These are "unformatted" I/O functions, but still character-based. (This may or may not be what you want, see below.) !

        !

        Notice how all the problems here are due to the inappropriate use ! of formatting functions and classes to perform something ! which requires that formatting not be done? There are a seemingly infinite number of solutions, and a few are listed here: !

          !
        • "Derive your own fstream-type classes and write your own <</>> operators to do binary I/O on whatever data types you're using." This is a Bad Thing, because while the compiler would probably be just fine with it, other humans are going to be confused. The overloaded bitshift operators have a well-defined meaning (formatting), and this breaks it. !
        • "Build the file structure in memory, then mmap() the file and copy the structure." Well, this is easy to make work, and easy to break, and is pretty equivalent to ! using ::read() and ::write() directly, and makes no use of the iostream library at all... !
        • "Use streambufs, that's what they're there for." While not trivial for the beginner, this is the best of all solutions. The streambuf/filebuf layer is the layer that is responsible for actual I/O. If you want to use the C++ library for binary I/O, this is where you start. !
        !

        !

        How to go about using streambufs is a bit beyond the scope of this document (at least for now), but while streambufs go a long way, they still leave a couple of things up to you, the programmer. As an example, byte ordering is completely between you and the operating system, and you have to handle it yourself. !

        !

        Deriving a streambuf or filebuf class from the standard ones, one that is specific to your data types (or an abstraction thereof) is probably a good idea, and lots of examples exist in journals and on Usenet. Using the standard filebufs directly (either by declaring your own or by ! using the pointer returned from an fstream's rdbuf()) is certainly feasible as well. !

        !

        One area that causes problems is trying to do bit-by-bit operations with filebufs. C++ is no different from C in this respect: I/O must be done at the byte level. If you're trying to read or write a few bits at a time, you're going about it the wrong way. You must read/write an integral number of bytes and then process the bytes. (For example, the streambuf functions take and return ! variables of type int_type.) !

        !

        Another area of problems is opening text files in binary mode. Generally, binary mode is intended for binary files, and opening text files in binary mode means that you now have to deal with all of those end-of-line and end-of-file problems that we mentioned before. An instructive thread from comp.lang.c++.moderated delved off into this topic starting more or less at ! this article and continuing to the end of the thread. (You'll have to sort through some flames every couple of paragraphs, but the points made are good ones.) !

        !
        !

        What is this <sstream>/stringstreams thing?

        !

        Stringstreams (defined in the header <sstream>) are in this author's opinion one of the coolest things since sliced time. An example of their use is in the Received Wisdom section for Chapter 21 (Strings), ! describing how to ! format strings. !

        !

        The quick definition is: they are siblings of ifstream and ofstream, ! and they do for std::string what their siblings do for ! files. All that work you put into writing << and ! >> functions for your classes now pays off ! again! Need to format a string before passing the string ! to a function? Send your stuff via << to an ostringstream. You've read a string as input and need to parse it? Initialize an istringstream with that string, and then pull pieces ! out of it with >>. Have a stringstream and need to ! get a copy of the string inside? Just call the str() member function. !

        !

        This only works if you've written your ! <</>> functions correctly, though, and correctly means that they take istreams and ostreams as parameters, not ifstreams and ofstreams. If they take the latter, then your I/O operators will work fine with file streams, but with nothing else -- including stringstreams. !

        !

        If you are a user of the strstream classes, you need to update ! your code. You don't have to explicitly append ends to terminate the C-style character array, you don't have to mess with "freezing" functions, and you don't have to manage the memory yourself. The strstreams have been officially deprecated, which means that 1) future revisions of the C++ Standard won't support them, and 2) if you use them, people will laugh at you. !

        !
        !

        Deriving a stream buffer

        !

        Creating your own stream buffers for I/O can be remarkably easy. If you are interested in doing so, we highly recommend two very ! excellent books: Standard C++ IOStreams and Locales by Langer and Kreft, ISBN 0-201-18395-1, and ! The C++ Standard Library by Nicolai Josuttis, ISBN 0-201-37926-0. Both are published by Addison-Wesley, who isn't paying us a cent for saying that, honest. !

        !

        Here is a simple example, io/outbuf1, from the Josuttis text. It transforms everything sent through it to uppercase. This version assumes many things about the nature of the character type being used (for more information, read the books or the newsgroups): !

              #include <iostream>
              #include <streambuf>
              #include <locale>
        --- 216,344 ----
                if it is doing so in your program then you've discovered a bug in
                your vendor's compiler (or some other part of the C++ implementation,
                possibly the runtime system).
        !    

        !

        Second, using << to write and >> to read isn't going to work with the standard file stream classes, even ! if you use skipws during reading. Why not? Because ! ifstream and ofstream exist for the purpose of formatting, not reading and writing. Their job is to interpret the data into text characters, and that's exactly what you don't want to happen during binary I/O. !

        !

        Third, using the get() and put()/write() member functions still aren't guaranteed to help you. These are "unformatted" I/O functions, but still character-based. (This may or may not be what you want, see below.) !

        !

        Notice how all the problems here are due to the inappropriate use ! of formatting functions and classes to perform something ! which requires that formatting not be done? There are a seemingly infinite number of solutions, and a few are listed here: !

          !
        • "Derive your own fstream-type classes and write your own <</>> operators to do binary I/O on whatever data types you're using." This is a Bad Thing, because while the compiler would probably be just fine with it, other humans are going to be confused. The overloaded bitshift operators have a well-defined meaning (formatting), and this breaks it. !
        • "Build the file structure in memory, then mmap() the file and copy the structure." Well, this is easy to make work, and easy to break, and is pretty equivalent to ! using ::read() and ::write() directly, and makes no use of the iostream library at all... !
        • "Use streambufs, that's what they're there for." While not trivial for the beginner, this is the best of all solutions. The streambuf/filebuf layer is the layer that is responsible for actual I/O. If you want to use the C++ library for binary I/O, this is where you start. !
        !

        !

        How to go about using streambufs is a bit beyond the scope of this document (at least for now), but while streambufs go a long way, they still leave a couple of things up to you, the programmer. As an example, byte ordering is completely between you and the operating system, and you have to handle it yourself. !

        !

        Deriving a streambuf or filebuf class from the standard ones, one that is specific to your data types (or an abstraction thereof) is probably a good idea, and lots of examples exist in journals and on Usenet. Using the standard filebufs directly (either by declaring your own or by ! using the pointer returned from an fstream's rdbuf()) is certainly feasible as well. !

        !

        One area that causes problems is trying to do bit-by-bit operations with filebufs. C++ is no different from C in this respect: I/O must be done at the byte level. If you're trying to read or write a few bits at a time, you're going about it the wrong way. You must read/write an integral number of bytes and then process the bytes. (For example, the streambuf functions take and return ! variables of type int_type.) !

        !

        Another area of problems is opening text files in binary mode. Generally, binary mode is intended for binary files, and opening text files in binary mode means that you now have to deal with all of those end-of-line and end-of-file problems that we mentioned before. An instructive thread from comp.lang.c++.moderated delved off into this topic starting more or less at ! this article and continuing to the end of the thread. (You'll have to sort through some flames every couple of paragraphs, but the points made are good ones.) !

        !
        !

        What is this <sstream>/stringstreams thing?

        !

        Stringstreams (defined in the header <sstream>) are in this author's opinion one of the coolest things since sliced time. An example of their use is in the Received Wisdom section for Chapter 21 (Strings), ! describing how to ! format strings. !

        !

        The quick definition is: they are siblings of ifstream and ofstream, ! and they do for std::string what their siblings do for ! files. All that work you put into writing << and ! >> functions for your classes now pays off ! again! Need to format a string before passing the string ! to a function? Send your stuff via << to an ostringstream. You've read a string as input and need to parse it? Initialize an istringstream with that string, and then pull pieces ! out of it with >>. Have a stringstream and need to ! get a copy of the string inside? Just call the str() member function. !

        !

        This only works if you've written your ! <</>> functions correctly, though, and correctly means that they take istreams and ostreams as parameters, not ifstreams and ofstreams. If they take the latter, then your I/O operators will work fine with file streams, but with nothing else -- including stringstreams. !

        !

        If you are a user of the strstream classes, you need to update ! your code. You don't have to explicitly append ends to terminate the C-style character array, you don't have to mess with "freezing" functions, and you don't have to manage the memory yourself. The strstreams have been officially deprecated, which means that 1) future revisions of the C++ Standard won't support them, and 2) if you use them, people will laugh at you. !

        !
        !

        Deriving a stream buffer

        !

        Creating your own stream buffers for I/O can be remarkably easy. If you are interested in doing so, we highly recommend two very ! excellent books: Standard C++ IOStreams and Locales by Langer and Kreft, ISBN 0-201-18395-1, and ! The C++ Standard Library by Nicolai Josuttis, ISBN 0-201-37926-0. Both are published by Addison-Wesley, who isn't paying us a cent for saying that, honest. !

        !

        Here is a simple example, io/outbuf1, from the Josuttis text. It transforms everything sent through it to uppercase. This version assumes many things about the nature of the character type being used (for more information, read the books or the newsgroups): !

              #include <iostream>
              #include <streambuf>
              #include <locale>
        ***************
        *** 366,470 ****
          	// create special output buffer
          	outbuf ob;
          	// initialize output stream with that output buffer
        ! 	std::ostream out(&ob);
          
          	out << "31 hexadecimal: "
          	    << std::hex << 31 << std::endl;
          	return 0;
              }
        !    
        Try it yourself! !

        !
        !

        More on binary I/O

        !

        Towards the beginning of February 2001, the subject of "binary" I/O was brought up in a couple of places at the same time. One notable place was Usenet, where James Kanze and Dietmar Kühl separately posted articles on why attempting generic binary I/O was not a good idea. (Here are copies of ! Kanze's article and ! Kühl's article.) !

        !

        Briefly, the problems of byte ordering and type sizes mean that ! the unformatted functions like ostream::put() and ! istream::get() cannot safely be used to communicate between arbitrary programs, or across a network, or from one invocation of a program to another invocation of the same program on a different platform, etc. !

        !

        The entire Usenet thread is instructive, and took place under the subject heading "binary iostreams" on both comp.std.c++ and comp.lang.c++.moderated in parallel. Also in that thread, Dietmar Kühl mentioned that he had written a pair of stream classes that would read and write XDR, which is a good step towards a portable binary format. !

        !
        !

        Pathetic performance? Ditch C.

        !

        It sounds like a flame on C, but it isn't. Really. Calm down. I'm just saying it to get your attention. !

        !

        Because the C++ library includes the C library, both C-style and C++-style I/O have to work at the same time. For example: !

               #include <iostream>
               #include <cstdio>
          
               std::cout << "Hel";
               std::printf ("lo, worl");
               std::cout << "d!\n";
        !       
        This must do what you think it does. !

        !

        Alert members of the audience will immediately notice that buffering is going to make a hash of the output unless special steps are taken. !

        !

        The special steps taken by libstdc++, at least for version 3.0, involve doing very little buffering for the standard streams, leaving most of the buffering to the underlying C library. (This kind of ! thing is tricky to get right.) The upside is that correctness is ensured. The downside is that ! writing through cout can quite easily lead to awful performance when the C++ I/O library is layered on top of the C I/O library (as it is for 3.0 by default). Some patches are in the works which should improve the situation for 3.1. !

        !

        However, the C and C++ standard streams only need to be kept in sync when both libraries' facilities are in use. If your program only uses C++ I/O, then there's no need to sync with the C streams. The right thing to do in this case is to call !

        !      #include any of the I/O headers such as ios, iostream, etc
          
               std::ios::sync_with_stdio(false);
        !       
        !

        !

        You must do this before performing any I/O via the C++ stream objects. Once you call this, the C++ streams will operate independantly of the ! (unused) C streams. For GCC 3.0, this means that cout and company will become fully buffered on their own. !

        !

        Note, by the way, that the synchronization requirement only applies to ! the standard streams (cin, cout, cerr, ! clog, and their wide-character counterparts). File stream ! objects that you create yourself have no such requirement and are fully buffered. !

        !








        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: howto.html,v 1.3.2.5 2001/07/18 21:39:58 pme Exp $ !

        ! ! --- 369,560 ---- // create special output buffer outbuf ob; // initialize output stream with that output buffer ! std::ostream out(&ob); out << "31 hexadecimal: " << std::hex << 31 << std::endl; return 0; } !
        Try it yourself! !

        !
        !

        More on binary I/O

        !

        Towards the beginning of February 2001, the subject of "binary" I/O was brought up in a couple of places at the same time. One notable place was Usenet, where James Kanze and Dietmar Kühl separately posted articles on why attempting generic binary I/O was not a good idea. (Here are copies of ! Kanze's article and ! Kühl's article.) !

        !

        Briefly, the problems of byte ordering and type sizes mean that ! the unformatted functions like ostream::put() and ! istream::get() cannot safely be used to communicate between arbitrary programs, or across a network, or from one invocation of a program to another invocation of the same program on a different platform, etc. !

        !

        The entire Usenet thread is instructive, and took place under the subject heading "binary iostreams" on both comp.std.c++ and comp.lang.c++.moderated in parallel. Also in that thread, Dietmar Kühl mentioned that he had written a pair of stream classes that would read and write XDR, which is a good step towards a portable binary format. !

        !
        !

        Pathetic performance? Ditch C.

        !

        It sounds like a flame on C, but it isn't. Really. Calm down. I'm just saying it to get your attention. !

        !

        Because the C++ library includes the C library, both C-style and C++-style I/O have to work at the same time. For example: !

               #include <iostream>
               #include <cstdio>
          
               std::cout << "Hel";
               std::printf ("lo, worl");
               std::cout << "d!\n";
        !       
        This must do what you think it does. !

        !

        Alert members of the audience will immediately notice that buffering is going to make a hash of the output unless special steps are taken. !

        !

        The special steps taken by libstdc++, at least for version 3.0, involve doing very little buffering for the standard streams, leaving most of the buffering to the underlying C library. (This kind of ! thing is tricky to get right.) The upside is that correctness is ensured. The downside is that ! writing through cout can quite easily lead to awful performance when the C++ I/O library is layered on top of the C I/O library (as it is for 3.0 by default). Some patches are in the works which should improve the situation for 3.1. !

        !

        However, the C and C++ standard streams only need to be kept in sync when both libraries' facilities are in use. If your program only uses C++ I/O, then there's no need to sync with the C streams. The right thing to do in this case is to call !

        !      #include any of the I/O headers such as ios, iostream, etc
          
               std::ios::sync_with_stdio(false);
        !       
        !

        !

        You must do this before performing any I/O via the C++ stream objects. Once you call this, the C++ streams will operate independantly of the ! (unused) C streams. For GCC 3.0, this means that cout and company will become fully buffered on their own. !

        !

        Note, by the way, that the synchronization requirement only applies to ! the standard streams (cin, cout, ! cerr, ! clog, and their wide-character counterparts). File stream ! objects that you declare yourself have no such requirement and are fully buffered. !

        ! !
        !

        Threads and I/O

        !

        I'll assume that you have already read the ! general notes on library threads, ! and the ! notes on threaded container ! access (you might not think of an I/O stream as a container, but ! the points made there also hold here). If you have not read them, ! please do so first. !

        !

        This gets a bit tricky. Please read carefully, and bear with me. !

        !

        Structure

        !

        As described here, a wrapper ! type called __basic_file provides our abstraction layer ! for the std::filebuf classes. Nearly all decisions dealing ! with actual input and output must be made in __basic_file. !

        !

        A generic locking mechanism is somewhat in place at the filebuf layer, ! but is not used in the current code. Providing locking at any higher ! level is akin to providing locking within containers, and is not done ! for the same reasons (see the links above). !

        !

        The defaults for 3.0.x

        !

        The __basic_file type is simply a collection of small wrappers around ! the C stdio layer (again, see the link under Structure). We do no ! locking ourselves, but simply pass through to calls to fopen, ! fwrite, and so forth. !

        !

        So, for 3.0, the question of "is multithreading safe for I/O" ! must be answered with, "is your platform's C library threadsafe ! for I/O?" Some are by default, some are not; many offer multiple ! implementations of the C library with varying tradeoffs of threadsafety ! and efficiency. You, the programmer, are always required to take care ! with multiple threads. !

        !

        (As an example, the POSIX standard requires that C stdio FILE* ! operations are atomic. POSIX-conforming C libraries (e.g, on Solaris ! and GNU/Linux) have an internal mutex to serialize operations on ! FILE*s. However, you still need to not do stupid things like calling ! fclose(fs) in one thread followed by an access of ! fs in another.) !

        !

        So, if your platform's C library is threadsafe, then your ! fstream I/O operations will be threadsafe at the lowest ! level. For higher-level operations, such as manipulating the data ! contained in the stream formatting classes (e.g., setting up callbacks ! inside an std::ofstream), you need to guard such accesses ! like any other critical shared resource. !

        !

        The future

        !

        As already mentioned here, a ! second choice is available for I/O implementations: libio. This is ! disabled by default, and in fact will not currently work due to other ! issues. It will be revisited, however. !

        !

        The libio code is a subset of the guts of the GNU libc (glibc) I/O ! implementation. When libio is in use, the __basic_file ! type is basically derived from FILE. (The real situation is more ! complex than that... it's derived from an internal type used to ! implement FILE. See libio/libioP.h to see scary things done with ! vtbls.) The result is that there is no "layer" of C stdio ! to go through; the filebuf makes calls directly into the same ! functions used to implement fread, fwrite, ! and so forth, using internal data structures. (And when I say ! "makes calls directly," I mean the function is literally ! replaced by a jump into an internal function. Fast but frightening. ! *grin*) !

        !

        Also, the libio internal locks are used. This requires pulling in ! large chunks of glibc, such as a pthreads implementation, and is one ! of the issues preventing widespread use of libio as the libstdc++ ! cstdio implementation. !

        !

        But we plan to make this work, at least as an option if not a future ! default. Platforms running a copy of glibc with a recent-enough ! version will see calls from libstdc++ directly into the glibc already ! installed. For other platforms, a copy of the libio subsection will ! be built and included in libstdc++. !

        !

        Alternatives

        !

        Don't forget that other cstdio implemenations are possible. You could ! easily write one to perform your own forms of locking, to solve your ! "interesting" problems. !

        !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/configopts.html gcc-3.0.2/libstdc++-v3/docs/html/configopts.html *** gcc-3.0.1/libstdc++-v3/docs/html/configopts.html Mon Jul 9 14:55:36 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/configopts.html Fri Oct 19 13:07:34 2001 *************** *** 1,111 **** ! ! ! ! ! ! ! libstdc++-v3 configure options ! ! ! ! !

        Interesting configure ! options

        !

        The latest version of this document is always available at ! ! http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html. !

        !

        To the libstdc++-v3 homepage. !


        !

        Here are some of the non-obvious options to libstdc++'s configure. Keep in mind that ! they ! all have opposite forms as well (enable/disable and with/without). The defaults are for current development sources. !

        !

        The canonical way to find out the configure options that are available for a given set of libstdc++ sources is to go to the ! source directory and then type: ./configure --help !

        !
        --enable-multilib [default] !

        This is part of the generic multilib support for building cross compilers. As such, targets like "powerpc-elf" will have libstdc++ built many different ways: "-msoft-float" and not, etc. A different libstdc++ will be built for each of the different multilib versions. This option is on by default. !

        !
        --enable-debug !

        The configure script will automatically detect the highest level ! of optimization that the compiler in use can use (certain ! versions of g++ will ICE if given the -O2 option, but ! this is fixed in later versions of the compiler). This --enable ! flag will disable all optimizations and instruct the compiler to ! emit as much extra debugging information as it can, for use ! inside GDB. !

        !
        --enable-cstdio !

        This is an abbreviated form of '--enable-cstdio=stdio' (described next). !

        !
        --enable-cstdio=LIB !

        Select a target-specific I/O package. As of libstdc++-v3 snapshot 2.91, the choices are 'libio' to specify the GNU I/O package (from ! glibc, the GNU C library), or 'stdio' to use a generic "C" abstraction. The default is 'stdio'. A longer explanation ! is here. !

        !
        --enable-sjlj-exceptions !

        Forces old, set-jump/long-jump exception handling model. If at all possible, the new, frame unwinding exception handling routines should be used instead, as they significantly reduce both runtime memory usage and executable size. !

        !
        --enable-clocale !

        This is an abbreviated form of '--enable-clocale=generic' (described next). !

        !
        --enable-clocale=MODEL !

        Select a target-specific underlying locale package. The choices ! are 'gnu' to specify an X/Open (IEEE Std. 1003.1-200x) model based ! on langinfo/iconv (from ! glibc, the GNU C ! library), or 'generic' to use a generic "C" abstraction ! which consists of "C" locale info. The default is 'generic'. !

        !
        --enable-c99 !

        The "long long" type was introduced in C99, along ! with bunches of other functions for wide characters, and math classification macros, etc. If enabled, all C99 functions not ! specified by the C++ standard will be put into namespace ! c99, and then all names in the c99 namespace will be injected ! into namespace std, so that C99 functions can be used "as ! if" they were in the C++ standard (as they will eventually ! be in some future revision of the standard, without a doubt). ! By default, C99 support is on, assuming the configure probes find ! all the necessary functions and bits necessary. !

        !
        --enable-long-long !

        The "long long" type was introduced in C99. It is provided as a GNU extension to C++98 in g++. This flag builds support for "long long" into the library (specialized templates and the like for iostreams). This option is on by default: --- 1,116 ---- ! ! ! ! ! ! ! libstdc++-v3 configure options ! ! ! !

        Interesting configure ! options

        !

        The latest version of this document is always available at ! ! http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html. !

        !

        To the libstdc++-v3 homepage. !


        !

        Here are some of the non-obvious options to libstdc++'s configure. Keep in mind that ! they ! all have opposite forms as well (enable/disable and with/without). The defaults are for current development sources. !

        !

        The canonical way to find out the configure options that are available for a given set of libstdc++ sources is to go to the ! source directory and then type: ./configure --help !

        !
        --enable-multilib [default] !

        This is part of the generic multilib support for building cross compilers. As such, targets like "powerpc-elf" will have libstdc++ built many different ways: "-msoft-float" and not, etc. A different libstdc++ will be built for each of the different multilib versions. This option is on by default. !

        !
        --enable-debug !

        The configure script will automatically detect the highest ! level of optimization that the compiler in use can use ! (certain versions of g++ will ICE if given the -O2 ! option, but this is fixed in later versions of the compiler). ! This --enable flag will disable all optimizations and instruct ! the compiler to emit as much extra debugging information as it ! can, for use inside GDB. Note this make command, executed in ! the build directory, will do much the same thing, without the ! configuration difference:make CXXFLAGS='-g -O0' all !

        !
        --enable-cstdio !

        This is an abbreviated form of '--enable-cstdio=stdio' (described next). !

        !
        --enable-cstdio=LIB !

        Select a target-specific I/O package. As of libstdc++-v3 snapshot 2.91, the choices are 'libio' to specify the GNU I/O package (from ! glibc, the GNU C library), or 'stdio' to use a generic "C" abstraction. The default is 'stdio'. A longer explanation ! is here. !

        !
        --enable-sjlj-exceptions !

        Forces old, set-jump/long-jump exception handling model. If at all possible, the new, frame unwinding exception handling routines should be used instead, as they significantly reduce both runtime memory usage and executable size. !

        !
        --enable-clocale !

        This is an abbreviated form of '--enable-clocale=generic' (described next). !

        !
        --enable-clocale=MODEL !

        Select a target-specific underlying locale package. The ! choices are 'ieee_1003.1' to specify an X/Open, Standard Unix ! (IEEE Std. 1003.1-200x) model based on langinfo/iconv/catgets, ! 'gnu' to specify a model based on functionality from the GNU C ! library (langinfo/iconv/gettext) (from glibc, the GNU C ! library), or 'generic' to use a generic "C" ! abstraction which consists of "C" locale info. The ! default is 'generic'. !

        !
        --enable-c99 !

        The "long long" type was introduced in C99, along ! with many other functions for wide characters, and math classification macros, etc. If enabled, all C99 functions not ! specified by the C++ standard will be put into namespace ! __gnu_cxx, and then all these names will ! be injected into namespace std, so that C99 functions can be ! used "as if" they were in the C++ standard (as they ! will eventually be in some future revision of the standard, ! without a doubt). By default, C99 support is on, assuming the ! configure probes find all the necessary functions and bits ! necessary. !

        !
        --enable-long-long !

        The "long long" type was introduced in C99. It is provided as a GNU extension to C++98 in g++. This flag builds support for "long long" into the library (specialized templates and the like for iostreams). This option is on by default: *************** options *** 115,136 **** allow "C" visibility of this feature (on GNU/Linux, the flag is -D_ISOC99_SOURCE, which is added automatically via CPLUSPLUS_CPP_SPEC's addition of _GNU_SOURCE). !

        !
        --enable-cheaders=OPTION !

        This allows the user to define what kind of C headers are used. Options are: c, c_std, and c_shadow. These correspond to the source directory's include/c, include/c_std, and include/c_shadow directories. The default is c_std. !

        !
        --enable-threads !

        This is an abbreviated form of '--enable-threads=yes' (described next). !

        !
        --enable-threads=LIB !

        Select a threading library. As of libstdc++-v3 snapshot 2.91, the choices are: 'yes' for some kind of default (hmmmmm); 'decosf1', 'irix', 'mach', 'os2', 'posix'/'pthreads' --- 120,141 ---- allow "C" visibility of this feature (on GNU/Linux, the flag is -D_ISOC99_SOURCE, which is added automatically via CPLUSPLUS_CPP_SPEC's addition of _GNU_SOURCE). !

        !
        --enable-cheaders=OPTION !

        This allows the user to define what kind of C headers are used. Options are: c, c_std, and c_shadow. These correspond to the source directory's include/c, include/c_std, and include/c_shadow directories. The default is c_std. !

        !
        --enable-threads !

        This is an abbreviated form of '--enable-threads=yes' (described next). !

        !
        --enable-threads=LIB !

        Select a threading library. As of libstdc++-v3 snapshot 2.91, the choices are: 'yes' for some kind of default (hmmmmm); 'decosf1', 'irix', 'mach', 'os2', 'posix'/'pthreads' *************** options *** 139,219 **** corresponding interface; and 'single', 'no', or 'none' for the null-case, single-threaded library. !

        !

        All of this is currently undergoing a lot of changes. As of 2.91, 'single' and 'posix' are the only implemented models. Default is single. !

        !
        --enable-version-specific-runtime-libs !

        Specify that run-time libraries should be installed in the compiler-specific subdirectory (i.e., ! ${libdir}/gcc-lib/${target_alias}/${gcc_version}) ! instead of ${libdir}. This option is useful if you intend to use several versions of gcc in parallel. In addition, libstdc++'s include files will be installed in ! ${libdir}/gcc-lib/${target_alias}/${gcc_version}/include/g++, unless you also specify ! --with-gxx-include-dir=dirname during configuration. !

        !
        --with-gxx-include-dir=<include-files dir> !

        Adds support for named libstdc++ include directory. For instance, the following puts all the libstdc++ headers into a directory called "2.97-20001008" instead of the usual "g++-v3". !

        !    --with-gxx-include-dir=/foo/H-x86-gcc-3-c-gxx-inc/include/2.97-20001008
        !

        !
        --enable-cxx-flags=FLAGS !

        With this option, you can pass a string of -f (functionality) flags to the compiler to use when building libstdc++. FLAGS is a quoted string of options, like !

        !   --enable-cxx-flags='-fvtable-gc -fomit-frame-pointer -ansi'
        Note that the flags don't necessarily have to all be -f flags, as shown, but usually those are the ones that will make sense for experimentation and configure-time overriding. !

        !

        The advantage of --enable-cxx-flags over setting CXXFLAGS in the 'make' environment is that, if files are automatically rebuilt, the same flags will be used when compiling those files as well, so that everything matches. !

        !

        Fun flags to try might include combinations of !

            -fstrict-aliasing
            -fno-exceptions
            -ffunction-sections
        !   -fvtable-gc
        ! and opposite forms (-fno-) of the same. Tell us (the mailing ! list) if you discover more! !

        !
        --enable-c-mbchar [default] !

        Certain template specializations are required for wide character conversion support. This is tricky and currently changing rapidly, and can cause problems on new platforms. Disabling wide character specializations is useful for initial porting steps, but builds only a subset of what is required by ! ISO. Default is on, but the --enable-cstdio=stdio ! option currently turns it off. !

        !
        !

        !

        Return to the top of the page or ! to the homepage. !

        !
        !

        ! $Id: configopts.html,v 1.6.2.5 2001/07/09 21:55:36 pme Exp $ !

        ! ! --- 144,225 ---- corresponding interface; and 'single', 'no', or 'none' for the null-case, single-threaded library. !

        !

        All of this is currently undergoing a lot of changes. As of 2.91, 'single' and 'posix' are the only implemented models. Default is single. !

        !
        --enable-version-specific-runtime-libs !

        Specify that run-time libraries should be installed in the compiler-specific subdirectory (i.e., ! ${libdir}/gcc-lib/${target_alias}/${gcc_version}) ! instead of ${libdir}. This option is useful if you intend to use several versions of gcc in parallel. In addition, libstdc++'s include files will be installed in ! ${libdir}/gcc-lib/${target_alias}/${gcc_version}/include/g++, unless you also specify ! --with-gxx-include-dir=dirname during configuration. !

        !
        --with-gxx-include-dir=<include-files dir> !

        Adds support for named libstdc++ include directory. For instance, the following puts all the libstdc++ headers into a directory called "2.97-20001008" instead of the usual "g++-v3". !

        !    --with-gxx-include-dir=/foo/H-x86-gcc-3-c-gxx-inc/include/2.97-20001008
        !

        !
        --enable-cxx-flags=FLAGS !

        With this option, you can pass a string of -f (functionality) flags to the compiler to use when building libstdc++. FLAGS is a quoted string of options, like !

        !   --enable-cxx-flags='-fvtable-gc -fomit-frame-pointer -ansi'
        Note that the flags don't necessarily have to all be -f flags, as shown, but usually those are the ones that will make sense for experimentation and configure-time overriding. !

        !

        The advantage of --enable-cxx-flags over setting CXXFLAGS in the 'make' environment is that, if files are automatically rebuilt, the same flags will be used when compiling those files as well, so that everything matches. !

        !

        Fun flags to try might include combinations of !

            -fstrict-aliasing
            -fno-exceptions
            -ffunction-sections
        !   -fvtable-gc
        ! and opposite forms (-fno-) of the same. Tell us (the libstdc++ ! mailing list) if you discover more! !

        !
        --enable-c-mbchar [default] !

        Certain template specializations are required for wide character conversion support. This is tricky and currently changing rapidly, and can cause problems on new platforms. Disabling wide character specializations is useful for initial porting steps, but builds only a subset of what is required by ! ISO. By default, this option is on. !

        !
        !

        !

        Return to the top of the page or ! to the libstdc++ homepage. !

        !
        !

        ! See license.html for copying conditions. ! Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/documentation.html gcc-3.0.2/libstdc++-v3/docs/html/documentation.html *** gcc-3.0.1/libstdc++-v3/docs/html/documentation.html Wed May 30 14:59:30 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/documentation.html Fri Oct 19 13:07:34 2001 *************** *** 1,96 **** ! ! ! ! Standard C++ Library v3 ! ! ! ! !

        All of these documents (in fact, this entire homepage set) are ! bundled with the library source, under the docs subdirectory, for releases and snapshots. The sole exception is the automatically-generated source documentation, available separately. !

        !
        !

        Source Documentation

        !

        In addition to the distribution documentation (these pages), we also have a set of HTML documents generated from the sources themselves, using the Doxygen tool. These are useful for examining the signatures of public member functions for the library classes, etc. !

        !

        ! The latest collection is libstdc++-doxygen-20010501.tar.gz (3.7MB), ! viewable online. The collection is also available in the libstdc++ snapshots directory at ! <URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/>. You will almost certainly need to use one of the ! mirror sites to download the tarball. After unpacking, simply load ! libstdc++-doxygen-20010501/index.html in a browser. Feedback (and additional documentation!) is welcome. !

        !
        !

        Configuring, Building, Installing

        ! !
        !

        Introductory notes for libstdc++

        !

        This is a short list of text files pertaining to this implementation of ISO 14882. A brief description follows the name of the file. !

        !

        !

        !

        !
        !

        Chapter-Specific Information, Extensions, Notes and Advice

        !
          !
        1. Chapter 17 (Intro) !
        2. Chapter 18 (Library Support) !
        3. Chapter 19 (Diagnostics) !
        4. Chapter 20 (Utilities) !
        5. Chapter 21 (Strings) !
        6. Chapter 22 (Localization) !
        7. Chapter 23 (Containers) !
        8. Chapter 24 (Iterators) !
        9. Chapter 25 (Algorithms) !
        10. Chapter 26 (Numerics) !
        11. Chapter 27 (I/O) !
        12. Extensions to the Standard Library !
        ! ! --- 1,109 ---- ! ! ! ! Standard C++ Library v3 ! ! ! !

        All of these documents (in fact, this entire homepage set) are ! bundled with the library source, under the docs subdirectory, for releases and snapshots. The sole exception is the automatically-generated source documentation, available separately. !

        !
        !

        Source Documentation

        !

        In addition to the distribution documentation (these pages), we also have a set of HTML documents generated from the sources themselves, using the Doxygen tool. These are useful for examining the signatures of public member functions for the library classes, etc. !

        !

        ! The latest collection is for the GCC 3.0 release, ! libstdc++-doxygen-3.0.tar.gz (3.8MB), ! viewable online. The collection is also available in the libstdc++ snapshots directory at ! <URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/>. You will almost certainly need to use one of the ! mirror sites to download the tarball. After unpacking, simply load ! libstdc++-doxygen-3.0/index.html in a browser. Feedback (and additional documentation!) is welcome. !

        ! !
        !

        Configuring, Building, Installing

        ! !
        !

        Introductory notes for libstdc++

        !

        This is a short list of text files pertaining to this implementation of ISO 14882. A brief description follows the name of the file. !

        !

        !

        !

        !
        !

        Chapter-Specific Information, Extensions, Notes and Advice

        !
          !
        1. Chapter 17 (Intro) !
        2. Chapter 18 (Library Support) !
        3. Chapter 19 (Diagnostics) !
        4. Chapter 20 (Utilities) !
        5. Chapter 21 (Strings) !
        6. Chapter 22 (Localization) !
        7. Chapter 23 (Containers) !
        8. Chapter 24 (Iterators) !
        9. Chapter 25 (Algorithms) !
        10. Chapter 26 (Numerics) !
        11. Chapter 27 (I/O) !
        12. Extensions to the Standard Library !
        ! ! ! !

        Return to the libstdc++ homepage.

        ! !
        !

        ! See license.html for copying conditions. ! Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/explanations.html gcc-3.0.2/libstdc++-v3/docs/html/explanations.html *** gcc-3.0.1/libstdc++-v3/docs/html/explanations.html Mon Jul 9 12:38:58 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/explanations.html Fri Oct 19 13:07:34 2001 *************** *** 1,74 **** ! ! ! ! ! ! ! Explanatory notes about libstdc++-v3 design ! ! ! ! !

        Explanatory notes about libstdc++-v3 ! design

        !

        The latest version of this document is always available at ! ! http://gcc.gnu.org/onlinedocs/libstdc++/explanations.html. !

        !

        To the libstdc++-v3 homepage. !


        !

        "I/O packages", --enable-cstdio

        !

        In addition to all the nifty things which C++ can do for I/O, its library also includes all of the I/O capabilites of C. Making them work together can be a challenge, not only ! for the programmer but for the implementors as well. !

        !

        There are two ways to do a C++ library: the cool way, and the easy way. More specifically, the cool-but-easy-to-get-wrong way, and the easy-to-guarantee-correct-behavior way. For 3.0, the easy way is used. !

        !

        Choosing 'stdio' is the easy way. It builds a C++ library which forwards all operations to the C library. Many of the C++ I/O functions are specified in the standard 'as if' they called a certain C function; the easiest way to get it correct is to actually call that function. The disadvantage is that the C++ code will run slower (fortunately, the layer is thin). !

        !

        Choosing 'libio' is the cool way; it allows C++ and C to share some buffers. It's disabled because of tricky synchronization issues. Other cool ways (various methods of sharing resources between C and C++ facilities, instead of layering) are possible. This approach can speed up I/O significantly. !

        !

        Other packages are possible. For a new package, a header must be written to provide types like streamsize (usually just a typedef), as ! well as some internal types like __c_file_type and ! __c_lock (for the stdio case, these are FILE (as in "FILE*") and a simple POSIX mutex, respectively). An ! interface class called __basic_file must also be filled in; as an example, for the stdio case, these member functions are all inline calles to fread, fwrite, etc. !

        !

        Return to the top of the page or ! to the homepage. !

        !
        !

        ! $Id: explanations.html,v 1.1.2.1 2001/07/09 19:38:58 pme Exp $ !

        ! ! --- 1,75 ---- ! ! ! ! ! ! ! Explanatory notes about libstdc++-v3 design ! ! ! !

        Explanatory notes about libstdc++-v3 ! design

        !

        The latest version of this document is always available at ! ! http://gcc.gnu.org/onlinedocs/libstdc++/explanations.html. !

        !

        To the libstdc++-v3 homepage. !


        !

        "I/O packages", --enable-cstdio

        !

        In addition to all the nifty things which C++ can do for I/O, its library also includes all of the I/O capabilites of C. Making them work together can be a challenge, not only ! for the programmer but for the implementors as well. !

        !

        There are two ways to do a C++ library: the cool way, and the easy way. More specifically, the cool-but-easy-to-get-wrong way, and the easy-to-guarantee-correct-behavior way. For 3.0, the easy way is used. !

        !

        Choosing 'stdio' is the easy way. It builds a C++ library which forwards all operations to the C library. Many of the C++ I/O functions are specified in the standard 'as if' they called a certain C function; the easiest way to get it correct is to actually call that function. The disadvantage is that the C++ code will run slower (fortunately, the layer is thin). !

        !

        Choosing 'libio' is the cool way; it allows C++ and C to share some buffers. It's disabled because of tricky synchronization issues. Other cool ways (various methods of sharing resources between C and C++ facilities, instead of layering) are possible. This approach can speed up I/O significantly. !

        !

        Other packages are possible. For a new package, a header must be written to provide types like streamsize (usually just a typedef), as ! well as some internal types like __c_file_type and ! __c_lock (for the stdio case, these are FILE (as in "FILE*") and a simple POSIX mutex, respectively). An ! interface class called __basic_file must also be filled in; as an example, for the stdio case, these member functions are all inline calles to fread, fwrite, etc. !

        !

        Return to the top of the page or ! to the homepage. !

        !
        !

        ! See license.html for copying conditions. ! Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/ext/howto.html gcc-3.0.2/libstdc++-v3/docs/html/ext/howto.html *** gcc-3.0.1/libstdc++-v3/docs/html/ext/howto.html Wed May 30 14:59:33 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/ext/howto.html Fri Oct 19 13:07:40 2001 *************** *** 1,174 **** ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Extensions ! ! ! ! !

        Extensions

        !

        Here we will make an attempt at describing the non-Standard extensions to the library. Some of these are from SGI's STL, some of these are GNU's, and some just seemed to appear on the doorstep. !

        !

        Before you leap in and use these, be aware of two things: !

          !
        1. Non-Standard means exactly that. The behavior, and the very existence, of these extensions may change with little or no warning. (Ideally, the really good ones will appear in the next revision of C++.) Also, other platforms, other compilers, other versions of g++ or libstdc++-v3 may not recognize these names, or treat them differently, or... !
        2. You should know how to access ! these headers properly. !
        !

        !
        !

        Contents

        ! !
        !

        Ropes and trees and hashes, oh my!

        !

        The SGI headers !

               <bvector>
               <hash_map>
               <hash_set>
               <rope>
               <slist>
               <tree>
        !      
        are all here; <bvector> exposes the old bit_vector class that was used before specialization of vector<bool> was available (it's actually a typedef for the specialization now). ! <hash_map> and <hash_set> ! are discussed further below. <rope> is the SGI specialization for large strings ("rope," "large strings," get it? love those SGI folks). ! <slist> is a singly-linked list, for when the ! doubly-linked list<> is too much space overhead, and ! <tree> exposes the red-black tree classes used in the implementation of the standard maps and sets. !

        !

        Okay, about those hashing classes... I'm going to foist most of the work off onto SGI's own site. !

        !

        Each of the associative containers map, multimap, set, and multiset have a counterpart which uses a ! hashing ! function to do the arranging, instead of a strict weak ordering function. The classes take as one of their template parameters a function object that will return the hash value; by default, an instantiation of ! hash. You should specialize this functor for your class, or define your own, before trying to use one of the hashing classes. !

        !

        The hashing classes support all the usual associative container functions, as well as some extra constructors specifying the number of buckets, etc. !

        !

        Why would you want to use a hashing class instead of the "normal" implementations? Matt Austern writes: !

        [W]ith a well chosen hash function, hash tables generally provide much better average-case performance than binary search trees, and much worse worst-case performance. So if your implementation has hash_map, if you don't mind using nonstandard components, and if you aren't scared about the possibility of pathological cases, you'll probably get better performance from ! hash_map.
        !

        !

        (Side note: for those of you wondering, "Why wasn't a hash ! table included in the Standard in the first #!$@ place?" I'll ! give a quick answer: it was proposed, but too late and in too unorganized a fashion. Some sort of hashing will undoubtedly be included in a future Standard. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Added members

        !

        Some of the classes in the Standard Library have additional ! publicly-available members. Of those, some are intended purely for ! the implementors, for example, additional typedefs. Those won't be ! described here (or anywhere else). This list will grow slowly, since ! we expect it to be rare -- most extensions will be self-contained. !

        !

        !

          !
        • filebufs have another ctor with this signature:
          ! basic_filebuf(__c_file_type*, ios_base::openmode, int_type); !
          This comes in very handy in a number of places, such as attaching Unix sockets, pipes, and anything else which uses file descriptors, into the IOStream buffering classes. The three arguments are as follows: !
            !
          • __c_file_type* F // the __c_file_type typedef usually boils down to stdio's FILE !
          • ios_base::openmode M // same as all the other uses of openmode !
          • int_type B // buffer size, defaults to BUFSIZ !
          For those wanting to use file descriptors instead of FILE*'s, I ! invite you to contemplate the mysteries of C's fdopen(). !
        !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Allocators

        !

        This will be blank for a while. It will describe all of the different memory allocators, most inherited from SGI's code. Input is solicited. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Compile-time checks

        !

        Currently libstdc++-v3 uses the concept checkers from the Boost ! library to perform optional ! compile-time checking of template instantiations of the standard containers. They are described in the linked-to page. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: howto.html,v 1.1.4.2 2001/05/30 21:59:33 pme Exp $ !

        ! ! --- 1,320 ---- ! ! ! ! ! ! ! ! libstdc++-v3 HOWTO: Extensions ! ! ! !

        Extensions

        !

        Here we will make an attempt at describing the non-Standard extensions to the library. Some of these are from SGI's STL, some of these are GNU's, and some just seemed to appear on the doorstep. !

        !

        Before you leap in and use these, be aware of two things: !

          !
        1. Non-Standard means exactly that. The behavior, and the very existence, of these extensions may change with little or no warning. (Ideally, the really good ones will appear in the next revision of C++.) Also, other platforms, other compilers, other versions of g++ or libstdc++-v3 may not recognize these names, or treat them differently, or... !
        2. You should know how to access ! these headers properly. !
        !

        !
        !

        Contents

        ! !
        !

        Ropes and trees and hashes, oh my!

        !

        The SGI headers !

               <bvector>
               <hash_map>
               <hash_set>
               <rope>
               <slist>
               <tree>
        !      
        are all here; <bvector> exposes the old bit_vector class that was used before specialization of vector<bool> was available (it's actually a typedef for the specialization now). ! <hash_map> and <hash_set> ! are discussed further below. <rope> is the SGI specialization for large strings ("rope," "large strings," get it? love those SGI folks). ! <slist> is a singly-linked list, for when the ! doubly-linked list<> is too much space overhead, and ! <tree> exposes the red-black tree classes used in the implementation of the standard maps and sets. !

        !

        Okay, about those hashing classes... I'm going to foist most of the work off onto SGI's own site. !

        !

        Each of the associative containers map, multimap, set, and multiset have a counterpart which uses a ! hashing ! function to do the arranging, instead of a strict weak ordering function. The classes take as one of their template parameters a function object that will return the hash value; by default, an instantiation of ! hash. You should specialize this functor for your class, or define your own, before trying to use one of the hashing classes. !

        !

        The hashing classes support all the usual associative container functions, as well as some extra constructors specifying the number of buckets, etc. !

        !

        Why would you want to use a hashing class instead of the "normal" implementations? Matt Austern writes: !

        [W]ith a well chosen hash function, hash tables generally provide much better average-case performance than binary search trees, and much worse worst-case performance. So if your implementation has hash_map, if you don't mind using nonstandard components, and if you aren't scared about the possibility of pathological cases, you'll probably get better performance from ! hash_map.
        !

        !

        (Side note: for those of you wondering, "Why wasn't a hash ! table included in the Standard in the first #!$@ place?" ! I'll give a quick answer: it was proposed, but too late and in too unorganized a fashion. Some sort of hashing will undoubtedly be included in a future Standard. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Added members and types

        !

        Some of the classes in the Standard Library have additional ! publicly-available members, and some classes are themselves not in ! the standard. Of those, some are intended purely for the implementors, ! for example, additional typedefs. Those won't be described here ! (or anywhere else). !

        !

        !

          !
        • The extensions added by SGI are so numerous that they have ! their own page. Since the SGI STL is no ! longer actively maintained, we will try and keep this code working ! ourselves. !
        • filebufs have another ctor with this signature:
          ! basic_filebuf(__c_file_type*, ios_base::openmode, int_type); !
          This comes in very handy in a number of places, such as attaching Unix sockets, pipes, and anything else which uses file descriptors, into the IOStream buffering classes. The three arguments are as follows: !
            !
          • __c_file_type* F // the __c_file_type typedef usually boils down to stdio's FILE !
          • ios_base::openmode M // same as all the other uses of openmode !
          • int_type B // buffer size, defaults to BUFSIZ !
          For those wanting to use file descriptors instead of FILE*'s, I ! invite you to contemplate the mysteries of C's fdopen(). !
        !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Allocators

        !

        This will be blank for a while. It will describe all of the different memory allocators, most inherited from SGI's code. Input is solicited. !

        !

        Return to top of page or ! to the FAQ. !

        !
        !

        Compile-time checks

        !

        Currently libstdc++-v3 uses the concept checkers from the Boost ! library to perform optional ! compile-time checking of template instantiations of the standard containers. They are described in the linked-to page. !

        !

        Return to top of page or ! to the FAQ. !

        +
        +

        LWG Issues

        +

        Everybody's got issues. Even the C++ Standard Library. +

        +

        The Library Working Group, or LWG, is the ISO subcommittee responsible + for making changes to the library. They periodically publish an + Issues List containing problems and possible solutions. As they reach + a consensus on proposed solutions, we often incorporate the solution + into libstdc++-v3. +

        +

        Here are the issues which have resulted in code changes to the library. + The links are to the specific defect reports from a partial + copy of the + Issues List. You can read the full version online at the ISO C++ + Committee homepage, linked to on the GCC "Readings" page. If + you spend a lot of time reading the issues, we recommend downloading + the ZIP file and reading them locally. +

        +

        (NB: partial copy means that not all links within + the lwg-*.html pages will work. + Specifically, links to defect reports that have not been accorded full + DR status will probably break. Rather than trying to mirror the + entire issues list on our overworked web server, we recommend you go + to the LWG homepage instead.) +

        +

        + If a DR is not listed here, we may simply not have gotten to it yet; + feel free to submit a patch. Search the include/bits and src + directories for appearances of _GLIBCPP_RESOLVE_LIB_DEFECTS for + examples of style. Note that we usually do not make changes to the code + until an issue has reached DR status. +

        +

        + +
        5: + string::compare specification questionable +
        This should be two overloaded functions rather than a single function. + +
        17: + Bad bool parsing +
        Apparently extracting Boolean values was messed up... + +
        25: + String operator<< uses width() value wrong +
        Padding issues. + +
        48: + Use of non-existent exception constructor +
        An instance of ios_base::failure is constructed instead. + +
        49: + Underspecification of ios_base::sync_with_stdio +
        The return type is the previous state of synchronization. + +
        50: + Copy constructor and assignment operator of ios_base +
        These members functions are declared private and are + thus inaccessible. Specifying the correct semantics of + "copying stream state" was deemed too complicated. + +
        68: + Extractors for char* should store null at end +
        And they do now. An editing glitch in the last item in the list of + [27.6.1.2.3]/7. + +
        74: + Garbled text for codecvt::do_max_length +
        The text of the standard was gibberish. Typos gone rampant. + +
        83: + string::npos vs. string::max_size() +
        Safety checks on the size of the string should test against + max_size() rather than npos. + +
        109: + Missing binders for non-const sequence elements +
        The binder1st and binder2nd didn't have an + operator() taking a non-const parameter. + +
        110: + istreambuf_iterator::equal not const +
        This was not a const member function. Note that the DR says to + replace the function with a const one; we have instead provided an + overloaded version with identical contents. + +
        129: + Need error indication from seekp() and seekg() +
        These functions set failbit on error now. + +
        136: + seekp, seekg setting wrong streams? +
        seekp should only set the output stream, and + seekg should only set the input stream. + + + +
        167: + Improper use of traits_type::length() +
        op<< with a const char* was + calculating an incorrect number of characters to write. + +
        181: + make_pair() unintended behavior +
        This function used to take its arguments as reference-to-const, now + it copies them (pass by value). + +
        195: + Should basic_istream::sentry's constructor ever set eofbit? +
        Yes, it can, specifically if EOF is reached while skipping whitespace. + +
        211: + operator>>(istream&, string&) doesn't set failbit +
        If nothing is extracted into the string, op>> now + sets failbit (which can cause an exception, etc, etc). + +
        214: + set::find() missing const overload +
        Both set and multiset were missing + overloaded find, lower_bound, upper_bound, and equal_range functions + for const instances. + +
        251: + basic_stringbuf missing allocator_type +
        This nested typdef was originally not specified. + +
        265: + std::pair::pair() effects overly restrictive +
        The default ctor would build its members from copies of temporaries; + now it simply uses their respective default ctors. + + +

        +

        Return to top of page or + to the FAQ. !


        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/ext/lwg-active.html gcc-3.0.2/libstdc++-v3/docs/html/ext/lwg-active.html *** gcc-3.0.1/libstdc++-v3/docs/html/ext/lwg-active.html Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/libstdc++-v3/docs/html/ext/lwg-active.html Fri Oct 19 13:07:41 2001 *************** *** 0 **** --- 1,6442 ---- + + + C++ Standard Library Active Issues List + + + + + + + + + + + + + + + + + + +
        Doc. no.J16/01-0031 = WG21 N1317
        Date:11 Sep 2001
        Project:Programming Language C++
        Reply to:Matt Austern <austern@research.att.com>
        +

        C++ Standard Library Active Issues List (Revision 19)

        +

        Reference ISO/IEC IS 14882:1998(E)

        +

        Also see:

        + +

        The purpose of this document is to record the status of issues + which have come before the Library Working Group (LWG) of the ANSI + (J16) and ISO (WG21) C++ Standards Committee. Issues represent + potential defects in the ISO/IEC IS 14882:1998(E) document. Issues + are not to be used to request new features or other extensions.

        + +

        This document contains only library issues which are actively being + considered by the Library Working Group. That is, issues which have a + status of New, Open, + Ready, and Review. See + Library Defect Reports List for issues considered defects and + Library Closed Issues List for issues considered closed.

        + +

        The issues in these lists are not necessarily formal ISO Defect + Reports (DR's). While some issues will eventually be elevated to + official Defect Report status, other issues will be disposed of in + other ways. See Issue Status.

        + +

        This document is in an experimental format designed for both + viewing via a world-wide web browser and hard-copy printing. It + is available as an HTML file for browsing or PDF file for + printing.

        + +

        Prior to Revision 14, library issues lists existed in two slightly + different versions; a Committee Version and a Public + Version. Beginning with Revision 14 the two versions were combined + into a single version.

        + +

        This document includes [bracketed italicized notes] as a + reminder to the LWG of current progress on issues. Such notes are + strictly unofficial and should be read with caution as they may be + incomplete or incorrect. Be aware that LWG support for a particular + resolution can quickly change if new viewpoints or killer examples are + presented in subsequent discussions.

        + +

        For the most current official version of this document see + http://www.dkuug.dk/jtc1/sc22/wg21. + Requests for further information about this document should include + the document number above, reference ISO/IEC 14882:1998(E), and be + submitted to Information Technology Industry Council (ITI), 1250 Eye + Street NW, Washington, DC 20005.

        + +

        Public information as to how to obtain a copy of the C++ Standard, + join the standards committee, submit an issue, or comment on an issue + can be found in the C++ FAQ at http://www.research.att.com/~austern/csc/faq.html. + Public discussion of C++ Standard related issues occurs on news:comp.std.c++. +

        + +

        For committee members, files available on the committee's private + web site include the HTML version of the Standard itself. HTML + hyperlinks from this issues list to those files will only work for + committee members who have downloaded them into the same disk + directory as the issues list files.

        +

        Revision History

        +
          +
        • R19: + Pre-Redmond mailing. Added new issues + 323-335. +
        • +
        • R18: + Post-Copenhagen mailing; reflects actions taken in Copenhagen. + Added new issues 312-317, and discussed + new issues 271-314. + + Changed status of issues + 103 118 136 153 + 165 171 183 184 + 185 186 214 221 + 234 237 243 248 + 251 252 256 260 + 261 262 263 265 + 268 + to DR. + + Changed status of issues + 49 109 117 182 + 228 230 232 235 + 238 241 242 250 + 259 264 266 267 + 271 272 273 275 + 281 284 285 286 + 288 292 295 297 + 298 301 303 306 + 307 308 312 + to Ready. + + Closed issues + 111 277 279 287 + 289 293 302 313 + 314 + as NAD. + +
        • +
        • R17: + Pre-Copenhagen mailing. Converted issues list to XML. Added proposed + resolutions for issues 49, 76, 91, 235, 250, 267. + Added new issues 278-311. +
        • +
        • R16: + post-Toronto mailing; reflects actions taken in Toronto. Added new + issues 265-277. Changed status of issues + 3, 8, 9, 19, + 26, 31, 61, + 63, 86, 108, + 112, 114, 115, + 122, 127, 129, + 134, 137, 142, + 144, 146, 147, + 159, 164, 170, + 181, 199, 208, + 209, 210, 211, + 212, 217, 220, + 222, 223, 224, + 227 to "DR". Reopened issue 23. Reopened + issue 187. Changed issues 2 and + 4 to NAD. Fixed a typo in issue 17. Fixed + issue 70: signature should be changed both places it + appears. Fixed issue 160: previous version didn't fix + the bug in enough places. +
        • +
        • R15: + pre-Toronto mailing. Added issues + 233-264. Some small HTML formatting + changes so that we pass Weblint tests. +
        • +
        • R14: + post-Tokyo II mailing; reflects committee actions taken in + Tokyo. Added issues 228 to 232. (00-0019R1/N1242) +
        • +
        • R13: + pre-Tokyo II updated: Added issues 212 to 227. +
        • +
        • R12: + pre-Tokyo II mailing: Added issues 199 to + 211. Added "and paragraph 5" to the proposed resolution + of issue 29. Add further rationale to issue + 178. +
        • +
        • R11: + post-Kona mailing: Updated to reflect LWG and full committee actions + in Kona (99-0048/N1224). Note changed resolution of issues + 4 and 38. Added issues 196 + to 198. Closed issues list split into "defects" and + "closed" documents. Changed the proposed resolution of issue + 4 to NAD, and changed the wording of proposed resolution + of issue 38. +
        • +
        • R10: + pre-Kona updated. Added proposed resolutions 83, + 86, 91, 92, + 109. Added issues 190 to + 195. (99-0033/D1209, 14 Oct 99) +
        • +
        • R9: + pre-Kona mailing. Added issues 140 to + 189. Issues list split into separate "active" and + "closed" documents. (99-0030/N1206, 25 Aug 99) +
        • +
        • R8: + post-Dublin mailing. Updated to reflect LWG and full committee actions + in Dublin. (99-0016/N1193, 21 Apr 99) +
        • +
        • R7: + pre-Dublin updated: Added issues 130, 131, + 132, 133, 134, + 135, 136, 137, + 138, 139 (31 Mar 99) +
        • +
        • R6: + pre-Dublin mailing. Added issues 127, 128, + and 129. (99-0007/N1194, 22 Feb 99) +
        • +
        • R5: + update issues 103, 112; added issues + 114 to 126. Format revisions to prepare + for making list public. (30 Dec 98) +
        • +
        • R4: + post-Santa Cruz II updated: Issues 110, + 111, 112, 113 added, several + issues corrected. (22 Oct 98) +
        • +
        • R3: + post-Santa Cruz II: Issues 94 to 109 + added, many issues updated to reflect LWG consensus (12 Oct 98) +
        • +
        • R2: + pre-Santa Cruz II: Issues 73 to 93 added, + issue 17 updated. (29 Sep 98) +
        • +
        • R1: + Correction to issue 55 resolution, 60 code + format, 64 title. (17 Sep 98) +
        • +
        +

        + Issue Status

        +

        + New - The issue has not yet been + reviewed by the LWG. Any Proposed Resolution is purely a + suggestion from the issue submitter, and should not be construed as + the view of LWG.

        + +

        + Open - The LWG has discussed the issue + but is not yet ready to move the issue forward. There are several + possible reasons for open status:

        +
          +
        • Consensus may have not yet have been reached as to how to deal + with the issue.
        • +
        • Informal consensus may have been reached, but the LWG awaits + exact Proposed Resolution wording for review.
        • +
        • The LWG wishes to consult additional technical experts before + proceeding.
        • +
        • The issue may require further study.
        • +
        + +

        A Proposed Resolution for an open issue is still not be + construed as the view of LWG. Comments on the current state of + discussions are often given at the end of open issues in an italic + font. Such comments are for information only and should not be given + undue importance.

        + +

        + Dup - The LWG has reached consensus that + the issue is a duplicate of another issue, and will not be further + dealt with. A Rationale identities the duplicated issue's + issue number.

        + +

        + NAD - The LWG has reached consensus that + the issue is not a defect in the Standard, and the issue is ready to + forward to the full committee as a proposed record of response. A + Rationale discusses the LWG's reasoning.

        + +

        + Review - Exact wording of a + Proposed Resolution is now available for review on an issue + for which the LWG previously reached informal consensus.

        + +

        + Ready - The LWG has reached consensus + that the issue is a defect in the Standard, the Proposed + Resolution is correct, and the issue is ready to forward to the + full committee for further action as a Defect Report (DR).

        + +

        + DR - (Defect Report) - The full J16 + committee has voted to forward the issue to the Project Editor to be + processed as a Potential Defect Report. The Project Editor reviews + the issue, and then forwards it to the WG21 Convenor, who returns it + to the full committee for final disposition. This issues list + accords the status of DR to all these Defect Reports regardless of + where they are in that process.

        + +

        + TC - (Technical Corrigenda) - The full + WG21 committee has voted to accept the Defect Report's Proposed + Resolution as a Technical Corrigenda. Action on this issue is thus + complete and no further action is possible under ISO rules.

        + +

        + RR - (Record of Response) - The full WG21 + committee has determined that this issue is not a defect in the + Standard. Action on this issue is thus complete and no further + action is possible under ISO rules.

        + +

        + Future - In addition to the regular + status, the LWG believes that this issue should be revisited at the + next revision of the standard. It is usually paired with NAD.

        + +

        Issues are always given the status of New when + they first appear on the issues list. They may progress to + Open or Review while the LWG + is actively working on them. When the LWG has reached consensus on + the disposition of an issue, the status will then change to + Dup, NAD, or Ready as appropriate. Once the full J16 committee votes to + forward Ready issues to the Project Editor, they are given the + status of Defect Report ( DR). These in turn may + become the basis for Technical Corrigenda (TC), + or are closed without action other than a Record of Response + (RR ). The intent of this LWG process is that + only issues which are truly defects in the Standard move to the + formal ISO DR status. +

        + +

        Active Issues

        +
        +

        23. Num_get overflow result

        + Section: 22.2.2.1.2 [lib.facet.num.get.virtuals]  Status: Open  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        The current description of numeric input does not account for the possibility of + overflow. This is an implicit result of changing the description to rely on the definition + of scanf() (which fails to report overflow), and conflicts with the documented behavior of + traditional and current implementations.

        + +

        Users expect, when reading a character sequence that results in a value unrepresentable + in the specified type, to have an error reported. The standard as written does not permit + this.

        + +

        Further comments from Dietmar:

        + +

        + I don't feel comfortable with the proposed resolution to issue 23: It + kind of simplifies the issue to much. Here is what is going on: +

        + +

        + Currently, the behavior of numeric overflow is rather counter intuitive + and hard to trace, so I will describe it briefly: +

        + +
          +
        • + According to 22.2.2.1.2 + paragraph 11 failbit is set if scanf() would + return an input error; otherwise a value is converted to the rules + of scanf. +
        • +
        • + scanf() is defined in terms of fscanf(). +
        • +
        • + fscanf() returns an input failure if during conversion no + character matching the conversion specification could be extracted + before reaching EOF. This is the only reason for fscanf() + to fail due to an input error and clearly does not apply to the case + of overflow. +
        • +
        • + Thus, the conversion is performed according to the rules of + fscanf() which basically says that strtod, + strtol(), etc. are to be used for the conversion. +
        • +
        • + The strtod(), strtol(), etc. functions consume as + many matching characters as there are and on overflow continue to + consume matching characters but also return a value identical to + the maximum (or minimum for signed types if there was a leading minus) + value of the corresponding type and set errno to ERANGE. +
        • +
        • + Thus, according to the current wording in the standard, overflows + can be detected! All what is to be done is to check errno + after reading an element and, of course, clearing errno + before trying a conversion. With the current wording, it can be + detected whether the overflow was due to a positive or negative + number for signed types. +
        • +
        + +

        + Now the proposed resolution results in not modifying the value passed + as last argument if an overflow is encountered but failbit + is set. Checking errno for ERANGE still allows for + detection of an overflow but not what the sign was. +

        + +

        + Actually, my problem is not that much with the sign but this is at least + making things worse... My problem is more that it is still necessary + to check errno for the error description. Thus, I propose the + following resolution: +

        + +

        Change paragraph 11 from

        + +
        +

        + -11- Stage 3: + The result of stage 2 processing can be one of

        + +
          +
        • A sequence of chars + has been accumulated in stage 2 that is converted (according to the + rules of scanf) to a value of the type of val. + This value is stored in val and + ios_base::goodbit is stored in err.
        • + +
        • The sequence of chars + accumulated in stage 2 would have caused scanf to report an input failure. + ios_base::failbit is assigned to err.
        • +
        +
        + +

        to become

        + +
        +

        + -11- Stage 3: + The result of stage 2 processing can be one of

        + +
          +
        • A sequence of chars + has been accumulated in stage 2 that is converted (according to the + rules of scanf) to a value of the type of val. + This value is stored in val. If the conversion reported + an overflow error for the type of val (ie. + errno would be set to ERANGE by the used + conversion function) then ios_base::failbit is stored in + err, otherwise ios_base::goodbit is stored in + err.
        • + +
        • The sequence of chars accumulated in stage 2 would have + caused scanf to report an input failure. ios_base::failbit + is assigned to err.
        • +
        +
        + +

        + With this definition, overflow can be detected easily by storing a value + different from the maximum value in val and checking whether + this value was modified in case failbit is set: If it was, there + was an overflow error, otherwise some other input error occurred (under the + conditions for the second bullet val is not changed). +

        +

        Proposed resolution:

        +

        In 22.2.2.1.2 , paragraph 11, second bullet item, + change

        + +
        +

        The sequence of chars accumulated in stage 2 would have caused scanf to report an input + failure.

        +
        + +

        to

        + +
        +

        The sequence of chars accumulated in stage 2 would have caused scanf to report an input + failure, or the value of the sequence cannot be represented in the type of _val_.

        +
        + +

        [post-Toronto: "cannot be represented" is probably wrong: + infinity can be represented on an IEC559 platform, but 0.1 cannot be + represented exactly. However, the alternate proposal may be wrong as + well. It's not clear whether overflow (and underflow?) should always + be treated as errors. This issue requires much more thought]

        + +
        +

        44. Iostreams use operator== on int_type values

        + Section: 27 [lib.input.output]  Status: Open  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        Many of the specifications for iostreams specify that character + values or their int_type equivalents are compared using operators == + or !=, though in other places traits::eq() or traits::eq_int_type is + specified to be used throughout. This is an inconsistency; we should + change uses of == and != to use the traits members instead.

        +

        Proposed resolution:

        + +

        [Kona: Nathan to supply proposed wording]

        + +

        [ + Tokyo: the LWG reaffirmed that this is a defect, and requires careful + review of clause 27 as the changes are context sensitive. + ]

        + +
        +

        49. Underspecification of ios_base::sync_with_stdio

        + Section: 27.4.2.4 [lib.ios.members.static]  Status: Ready  Submitter: Matt Austern  Date: 21 Jun 1998

        +

        Two problems

        + +

        (1) 27.4.2.4 doesn't say what ios_base::sync_with_stdio(f) + returns. Does it return f, or does it return the previous + synchronization state? My guess is the latter, but the standard + doesn't say so.

        + +

        (2) 27.4.2.4 doesn't say what it means for streams to be + synchronized with stdio. Again, of course, I can make some + guesses. (And I'm unhappy about the performance implications of those + guesses, but that's another matter.)

        +

        Proposed resolution:

        +

        Change the following sentence in 27.4.2.4 + returns clause from:

        + +
        +

        + true if the standard iostream objects (27.3) are + synchronized and otherwise returns false.

        +
        + +

        to:

        + +
        +

        + true if the previous state of the standard iostream + objects (27.3) was synchronized and otherwise returns + false.

        +
        + +

        Add the following immediately after 27.4.2.4 , + paragraph 2:

        + +
        +

        When a standard iostream object str is synchronized with a + standard stdio stream f, the effect of inserting a character c by

        +
        +   fputc(f, c);
        + 
        + +

        is the same as the effect of

        +
        +   str.rdbuf()->sputc(c);
        + 
        + +

        for any sequence of characters; the effect of extracting a + character c by

        +
        +   c = fgetc(f);
        + 
        + +

        is the same as the effect of:

        +
        +   c = str.rdbuf()->sbumpc(c);
        + 
        + +

        for any sequences of characters; and the effect of pushing + back a character c by

        +
        +   ungetc(c, f);
        + 
        + +

        is the same as the effect of

        +
        +   str.rdbuf()->sputbackc(c);
        + 
        + +

        for any sequence of characters. [Footnote: This implies + that operations on a standard iostream object can be mixed arbitrarily + with operations on the corresponding stdio stream. In practical + terms, synchronization usually means that a standard iostream object + and a standard stdio object share a buffer. --End Footnote]

        +
        + +

        [pre-Copenhagen: PJP and Matt contributed the definition + of "synchronization"]

        + +

        [post-Copenhagen: proposed resolution was revised slightly: + text was added in the non-normative footnote to say that operations + on the two streams can be mixed arbitrarily.]

        +
        +

        76. Can a codecvt facet always convert one internal character at a time?

        + Section: 22.2.1.5 [lib.locale.codecvt]  Status: Review  Submitter: Matt Austern  Date: 25 Sep 1998

        +

        This issue concerns the requirements on classes derived from + codecvt, including user-defined classes. What are the + restrictions on the conversion from external characters + (e.g. char) to internal characters (e.g. wchar_t)? + Or, alternatively, what assumptions about codecvt facets can + the I/O library make?

        + +

        The question is whether it's possible to convert from internal + characters to external characters one internal character at a time, + and whether, given a valid sequence of external characters, it's + possible to pick off internal characters one at a time. Or, to put it + differently: given a sequence of external characters and the + corresponding sequence of internal characters, does a position in the + internal sequence correspond to some position in the external + sequence?

        + +

        To make this concrete, suppose that [first, last) is a + sequence of M external characters and that [ifirst, + ilast) is the corresponding sequence of N internal + characters, where N > 1. That is, my_encoding.in(), + applied to [first, last), yields [ifirst, + ilast). Now the question: does there necessarily exist a + subsequence of external characters, [first, last_1), such + that the corresponding sequence of internal characters is the single + character *ifirst? +

        + +

        (What a "no" answer would mean is that + my_encoding translates sequences only as blocks. There's a + sequence of M external characters that maps to a sequence of + N internal characters, but that external sequence has no + subsequence that maps to N-1 internal characters.)

        + +

        Some of the wording in the standard, such as the description of + codecvt::do_max_length (22.2.1.5.2 , + paragraph 11) and basic_filebuf::underflow (27.8.1.4 , paragraph 3) suggests that it must always be + possible to pick off internal characters one at a time from a sequence + of external characters. However, this is never explicitly stated one + way or the other.

        + +

        This issue seems (and is) quite technical, but it is important if + we expect users to provide their own encoding facets. This is an area + where the standard library calls user-supplied code, so a well-defined + set of requirements for the user-supplied code is crucial. Users must + be aware of the assumptions that the library makes. This issue affects + positioning operations on basic_filebuf, unbuffered input, + and several of codecvt's member functions.

        +

        Proposed resolution:

        +

        Add the following text as a new paragraph, following 22.2.1.5.2 paragraph 2:

        + +
        +

        A codecvt facet that is used by basic_filebuf + (27.8 ) must have the property that if

        +
        +     do_out(state, from, from_end, from_next, to, to_lim, to_next)
        + 
        + would succeed (return value would be ok), where + from != from_end, then +
        +     do_out(state, from, from + 1, from_next, to, to_end, to_next)
        + 
        + must also succeed, and that if +
        +     do_in(state, from, from_end, from_next, to, to_lim, to_next)
        + 
        + would succeed, where to != to_lim, then +
        +     do_in(state, from, from_end, from_next, to, to + 1, to_next)
        + 
        +

        must also succeed. [Footnote: Informally, this means that + basic_filebuf assumes that the mapping from internal to + external characters is 1 to N: a codecvt that is used by + basic_filebuf must be able to translate characters one + internal character at a time. --End Footnote]

        +
        + +

        Rationale:

        + +

        The proposed resoluion says that conversions can be performed one + internal character at a time. This rules out some encodings that + would otherwise be legal. The alternative answer would mean there + would be some internal positions that do not correspond to any + external file position.

        +

        + An example of an encoding that this rules out is one where the + internT and externT are of the same type, and + where the internal sequence c1 c2 corresponds to the + external sequence c2 c1. +

        +

        It was generally agreed that basic_filebuf relies + on this property: it was designed under the assumption that + the external-to-internal mapping is N-to-1, and it is not clear + that basic_filebuf is implementable without that + restriction. +

        +

        + The proposed resolution is expressed as a restriction on + codecvt when used by basic_filebuf, rather + than a blanket restriction on all codecvt facets, + because basic_filebuf is the only other part of the + library that uses codecvt. If a user wants to define + a codecvt facet that implements a more general N-to-M + mapping, there is no reason to prohibit it, so long as the user + does not expect basic_filebuf to be able to use it. +

        +
        +

        91. Description of operator>> and getline() for string<> might cause endless loop

        + Section: 21.3.7.9 [lib.string.io]  Status: Review  Submitter: Nico Josuttis  Date: 29 Sep 1998

        +

        Operator >> and getline() for strings read until eof() + in the input stream is true. However, this might never happen, if the + stream can't read anymore without reaching EOF. So shouldn't it be + changed into that it reads until !good() ?

        +

        Proposed resolution:

        +

        In 21.3.7.9 , paragraph 1, replace:

        +
        + Effects: Begins by constructing a sentry object k as if k were + constructed by typename basic_istream<charT,traits>::sentry k( is). If + bool( k) is true, it calls str.erase() and then extracts characters + from is and appends them to str as if by calling str.append(1, c). If + is.width() is greater than zero, the maximum number n of characters + appended is is.width(); otherwise n is str.max_size(). Characters are + extracted and appended until any of the following occurs: +
        +

        with:

        +
        + Effects: Behaves as an unformatted input function (27.6.1.2 ). After constructing a sentry object, if the + sentry converts to true, calls str.erase() and then extracts + characters from is and appends them to str as if by calling + str.append(1,c). If is.width() is greater than zero, the maximum + number n of characters appended is is.width(); otherwise n is + str.max_size(). Characters are extracted and appended until any of the + following occurs: +
        + +

        In 21.3.7.9 , paragraph 6, replace

        +
        + Effects: Begins by constructing a sentry object k as if by typename + basic_istream<charT,traits>::sentry k( is, true). If bool( k) is true, + it calls str.erase() and then extracts characters from is and appends + them to str as if by calling str.append(1, c) until any of the + following occurs: +
        +

        with:

        +
        + Effects: Behaves as an unformatted input function (27.6.1.2 ). After constructing a sentry object, if the + sentry converts to true, calls str.erase() and then extracts + characters from is and appends them to str as if by calling + str.append(1,c) until any of the following occurs: +
        + +

        Rationale:

        +

        The real issue here is whether or not these string input functions + perform formatted input. If they do, then they get their characters + from a streambuf, rather than by calling an istream's member functions, + and a streambuf signals failure either by returning eof or by throwing + an exception. The proposed resolution makes it clear that these two + functions do perform formatted input.

        +
        +

        92. Incomplete Algorithm Requirements

        + Section: 25 [lib.algorithms]  Status: Open  Submitter: Nico Josuttis  Date: 29 Sep 1998

        +

        The standard does not state, how often a function object is copied, + called, or the order of calls inside an algorithm. This may lead to + surprising/buggy behavior. Consider the following example:

        + +
        class Nth {    // function object that returns true for the nth element 
        +   private: 
        +     int nth;     // element to return true for 
        +     int count;   // element counter 
        +   public: 
        +     Nth (int n) : nth(n), count(0) { 
        +     } 
        +     bool operator() (int) { 
        +         return ++count == nth; 
        +     } 
        + }; 
        + .... 
        + // remove third element 
        +     list<int>::iterator pos; 
        +     pos = remove_if(coll.begin(),coll.end(),  // range 
        +                     Nth(3)),                  // remove criterion 
        +     coll.erase(pos,coll.end()); 
        + +

        This call, in fact removes the 3rd AND the 6th element. This + happens because the usual implementation of the algorithm copies the + function object internally:

        + +
        template <class ForwIter, class Predicate> 
        + ForwIter std::remove_if(ForwIter beg, ForwIter end, Predicate op) 
        + { 
        +     beg = find_if(beg, end, op); 
        +     if (beg == end) { 
        +         return beg; 
        +     } 
        +     else { 
        +         ForwIter next = beg; 
        +         return remove_copy_if(++next, end, beg, op); 
        +     } 
        + } 
        + +

        The algorithm uses find_if() to find the first element that should + be removed. However, it then uses a copy of the passed function object + to process the resulting elements (if any). Here, Nth is used again + and removes also the sixth element. This behavior compromises the + advantage of function objects being able to have a state. Without any + cost it could be avoided (just implement it directly instead of + calling find_if()).

        +

        Proposed resolution:

        +

        In [lib.function.objects] 20.3 Function objects add as new + paragraph 6 (or insert after paragraph 1):

        + +

        Option 1:

        +
        + Predicates are functions or function objects that fulfill the + following requirements:
          - They return a Boolean value (bool + or a value convertible to bool)
          - It doesn't matter for the + behavior of a predicate how often it is copied or assigned and how + often it is called. +
        + +

        Option 2:

        +
        + - if it's a function:
          - All calls with the same + argument values yield the same result.
        - if it's a function + object:
          - In any sequence of calls to operator () without + calling any non-constant member function, all calls with the same + argument values yield the same result. 
        - After an assignment + or copy both objects return the same result for the same values. +
        + +

        [Santa Cruz: The LWG believes that there may be more to this than + meets the eye. It applies to all function objects, particularly + predicates. Two questions: (1) must a function object be + copyable? (2) how many times is a function object called?  These + are in effect questions about state.  Function objects appear to + require special copy semantics to make state work, and may fail if + calling alters state and calling occurs an unexpected number of + times.]

        + +

        [Dublin: Pete Becker felt that this may not be a defect, + but rather something that programmers need to be educated about. + There was discussion of adding wording to the effect that the number + and order of calls to function objects, including predicates, not + affect the behavior of the function object.]

        + +

        [Pre-Kona: Nico comments: It seems the problem is that we don't + have a clear statement of "predicate" in the + standard. People including me seemed to think "a function + returning a Boolean value and being able to be called by an STL + algorithm or be used as sorting criterion or ... is a + predicate". But a predicate has more requirements: It should + never change its behavior due to a call or being copied. IMHO we have + to state this in the standard. If you like, see section 8.1.4 of my + library book for a detailed discussion.]

        + +

        [Kona: Nico will provide wording to the effect that "unless + otherwise specified, the number of copies of and calls to function + objects by algorithms is unspecified".  Consider placing in + 25 after paragraph 9.]

        + +

        [Pre-Tokyo: Angelika Langer comments: if the resolution is + that algorithms are free to copy and pass around any function objects, + then it is a valid question whether they are also allowed to change + the type information from reference type to value type.]

        + +

        [Tokyo: Nico will discuss this further with Matt as there are + multiple problems beyond the underlying problem of no definition of + "Predicate".]

        + +

        [Post-Tokyo: Nico provided the above proposed + resolutions.]

        + +
        +

        96. Vector<bool> is not a container

        + Section: 23.2.5 [lib.vector.bool]  Status: Open  Submitter: AFNOR  Date: 7 Oct 1998

        +

        + vector<bool> is not a container as its reference and + pointer types are not references and pointers.

        + +

        Also it forces everyone to have a space optimization instead of a + speed one.

        + +

        + See also: 99-0008 == N1185 Vector<bool> is + Nonconforming, Forces Optimization Choice.

        +

        Proposed resolution:

        + +

        [In Santa Cruz the LWG felt that this was Not A Defect.]

        + +

        [In Dublin many present felt that failure to meet Container + requirements was a defect. There was disagreement as to whether + or not the optimization requirements constituted a defect.]

        + +

        [The LWG looked at the following resolutions in some detail: +
        +      * Not A Defect.
        +      * Add a note explaining that vector<bool> does not meet + Container requirements.
        +      * Remove vector<bool>.
        +      * Add a new category of container requirements which + vector<bool> would meet.
        +      * Rename vector<bool>.
        +
        + No alternative had strong, wide-spread, support and every alternative + had at least one "over my dead body" response.
        +
        + There was also mention of a transition scheme something like (1) add + vector_bool and deprecate vector<bool> in the next standard. (2) + Remove vector<bool> in the following standard.]

        + +

        [Modifying container requirements to permit returning proxies + (thus allowing container requirements conforming vector<bool>) + was also discussed.]

        + +

        [It was also noted that there is a partial but ugly workaround in + that vector<bool> may be further specialized with a customer + allocator.]

        + +

        [Kona: Herb Sutter presented his paper J16/99-0035==WG21/N1211, + vector<bool>: More Problems, Better Solutions. Much discussion + of a two step approach: a) deprecate, b) provide replacement under a + new name. LWG straw vote on that: 1-favor, 11-could live with, 2-over + my dead body. This resolution was mentioned in the LWG report to the + full committee, where several additional committee members indicated + over-my-dead-body positions.]

        + +

        [Tokyo: Not discussed by the full LWG; no one claimed new + insights and so time was more productively spent on other issues. In + private discussions it was asserted that requirements for any solution + include 1) Increasing the full committee's understanding of the + problem, and 2) providing compiler vendors, authors, teachers, and of + course users with specific suggestions as to how to apply the eventual + solution.]

        + +
        +

        98. Input iterator requirements are badly written

        + Section: 24.1.1 [lib.input.iterators]  Status: Open  Submitter: AFNOR  Date: 7 Oct 1998

        +

        Table 72 in 24.1.1 specifies semantics for + *r++ of:

        + +

           { T tmp = *r; ++r; return tmp; } +

        + +

        This does not work for pointers and over constrains implementors.

        +

        Proposed resolution:

        +

        Add for *r++: “To call the copy constructor for the type T is + allowed but not required.”

        + +

        [Dublin: Pete Becker will attempt improved wording.]

        + +

        [Tokyo: The essence of the issue seems to have escaped. + Pete will email Valentin to try to recapture it.]

        +
        +

        109. Missing binders for non-const sequence elements

        + Section: 20.3.6 [lib.binders]  Status: Ready  Submitter: Bjarne Stroustrup  Date: 7 Oct 1998

        +

        There are no versions of binders that apply to non-const elements + of a sequence. This makes examples like for_each() using bind2nd() on + page 521 of "The C++ Programming Language (3rd)" + non-conforming. Suitable versions of the binders need to be added.

        + +

        Further discussion from Nico:

        + +

        What is probably meant here is shown in the following example:

        + +
        class Elem { 
        +   public: 
        +     void print (int i) const { } 
        +     void modify (int i) { } 
        + }; 
        +
        int main() 
        + { 
        +     vector<Elem> coll(2); 
        +     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::print),42));    // OK 
        +     for_each (coll.begin(), coll.end(), bind2nd(mem_fun_ref(&Elem::modify),42));   // ERROR 
        + }
        + +

        The error results from the fact that bind2nd() passes its first + argument (the argument of the sequence) as constant reference. See the + following typical implementation:

        + +
        +
        template <class Operation> 
        + class binder2nd 
        +   : public unary_function<typename Operation::first_argument_type, 
        +                           typename Operation::result_type> { 
        + protected: 
        +   Operation op; 
        +   typename Operation::second_argument_type value; 
        + public: 
        +   binder2nd(const Operation& o, 
        +             const typename Operation::second_argument_type& v) 
        +       : op(o), value(v) {} 
        +
         typename Operation::result_type 
        +   operator()(const typename Operation::first_argument_type& x) const { 
        +     return op(x, value); 
        +   } 
        + };
        +
        + +

        The solution is to overload operator () of bind2nd for non-constant arguments:

        + +
        +
        template <class Operation> 
        + class binder2nd 
        +   : public unary_function<typename Operation::first_argument_type, 
        +                           typename Operation::result_type> { 
        + protected: 
        +   Operation op; 
        +   typename Operation::second_argument_type value; 
        + public: 
        +   binder2nd(const Operation& o, 
        +             const typename Operation::second_argument_type& v) 
        +       : op(o), value(v) {} 
        +
         typename Operation::result_type 
        +   operator()(const typename Operation::first_argument_type& x) const { 
        +     return op(x, value); 
        +   } 
        +   typename Operation::result_type 
        +   operator()(typename Operation::first_argument_type& x) const { 
        +     return op(x, value); 
        +   } 
        + };
        +
        +

        Proposed resolution:

        +

        In 20.3.6.1 in the declaration of binder1st after:

        +
        +

        typename Operation::result_type
        +  operator()(const typename Operation::second_argument_type& x) const;

        +
        +

        insert:

        +
        +

        typename Operation::result_type
        +  operator()(typename Operation::second_argument_type& x) const;

        +
        +

        In 20.3.6.3 in the declaration of binder2nd after:

        +
        +

        typename Operation::result_type
        +  operator()(const typename Operation::first_argument_type& x) const;

        +
        +

        insert:

        +
        +

        typename Operation::result_type
        +  operator()(typename Operation::first_argument_type& x) const;

        +
        + +

        [Kona: The LWG discussed this at some length.It was agreed that + this is a mistake in the design, but there was no consensus on whether + it was a defect in the Standard. Straw vote: NAD - 5. Accept + proposed resolution - 3. Leave open - 6.]

        + +

        [Copenhagen: It was generally agreed that this was a defect. + Strap poll: NAD - 0. Accept proposed resolution - 10. + Leave open - 1.]

        + +
        +

        117. basic_ostream uses nonexistent num_put member functions

        + Section: 27.6.2.5.2 [lib.ostream.inserters.arithmetic]  Status: Ready  Submitter: Matt Austern  Date: 20 Nov 1998

        +

        The effects clause for numeric inserters says that + insertion of a value x, whose type is either bool, + short, unsigned short, int, unsigned + int, long, unsigned long, float, + double, long double, or const void*, is + delegated to num_put, and that insertion is performed as if + through the following code fragment:

        + +
        bool failed = use_facet<
        +    num_put<charT,ostreambuf_iterator<charT,traits> > 
        +    >(getloc()).put(*this, *this, fill(), val). failed();
        + +

        This doesn't work, because num_put<>::put is only + overloaded for the types bool, long, unsigned + long, double, long double, and const + void*. That is, the code fragment in the standard is incorrect + (it is diagnosed as ambiguous at compile time) for the types + short, unsigned short, int, unsigned + int, and float.

        + +

        We must either add new member functions to num_put, or + else change the description in ostream so that it only calls + functions that are actually there. I prefer the latter.

        +

        Proposed resolution:

        +

        Replace 27.6.2.5.2, paragraph 1 with the following:

        + +
        +

        + The classes num_get<> and num_put<> handle locale­dependent numeric + formatting and parsing. These inserter functions use the imbued + locale value to perform numeric formatting. When val is of type bool, + long, unsigned long, double, long double, or const void*, the + formatting conversion occurs as if it performed the following code + fragment: +

        + +
        + bool failed = use_facet<
        +    num_put<charT,ostreambuf_iterator<charT,traits> >
        +    >(getloc()).put(*this, *this, fill(), val). failed();
        + 
        + +

        + When val is of type short the formatting conversion occurs as if it + performed the following code fragment: +

        + +
        + ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
        + bool failed = use_facet<
        +    num_put<charT,ostreambuf_iterator<charT,traits> >
        +    >(getloc()).put(*this, *this, fill(),
        +       baseflags == ios_base::oct || baseflags == ios_base::hex
        +          ? static_cast<long>(static_cast<unsigned short>(val))
        +          : static_cast<long>(val)). failed();
        + 
        + +

        + When val is of type int the formatting conversion occurs as if it performed + the following code fragment: +

        + +
        + ios_base::fmtflags baseflags = ios_base::flags() & ios_base::basefield;
        + bool failed = use_facet<
        +    num_put<charT,ostreambuf_iterator<charT,traits> >
        +    >(getloc()).put(*this, *this, fill(),
        +       baseflags == ios_base::oct || baseflags == ios_base::hex
        +          ? static_cast<long>(static_cast<unsigned int>(val))
        +          : static_cast<long>(val)). failed();
        + 
        + +

        + When val is of type unsigned short or unsigned int the formatting conversion + occurs as if it performed the following code fragment: +

        + +
        + bool failed = use_facet<
        +    num_put<charT,ostreambuf_iterator<charT,traits> >
        +    >(getloc()).put(*this, *this, fill(), static_cast<unsigned long>(val)).
        + failed();
        + 
        + +

        + When val is of type float the formatting conversion occurs as if it + performed the following code fragment: +

        + +
        + bool failed = use_facet<
        +    num_put<charT,ostreambuf_iterator<charT,traits> >
        +    >(getloc()).put(*this, *this, fill(), static_cast<double>(val)).
        + failed();
        + 
        + +
        + +

        [post-Toronto: This differs from the previous proposed + resolution; PJP provided the new wording. The differences are in + signed short and int output.]

        +

        Rationale:

        +

        The original proposed resolution was to cast int and short to long, + unsigned int and unsigned short to unsigned long, and float to double, + thus ensuring that we don't try to use nonexistent num_put<> + member functions. The current proposed resolution is more + complicated, but gives more expected results for hex and octal output + of signed short and signed int. (On a system with 16-bit short, for + example, printing short(-1) in hex format should yield 0xffff.)

        +
        +

        120. Can an implementor add specializations?

        + Section: 17.4.3.1 [lib.reserved.names]  Status: Open  Submitter: Judy Ward  Date: 15 Dec 1998

        +

        Section 17.4.3.1 says:

        + +
        +

        It is undefined for a C++ program to add declarations or definitions to namespace std + or namespaces within namespace std unless otherwise specified. A program may add template + specializations for any standard library template to namespace std. Such a specialization + (complete or partial) of a standard library template results in undefined behavior unless + the declaration depends on a user-defined name of external linkage and unless the + specialization meets the standard library requirements for the original template...

        +
        + +

        This implies that it is ok for library users to add specializations, but not + implementors. A user program can actually detect this, for example, the following manual + instantiation will not compile if the implementor has made ctype<wchar_t> a + specialization:

        + +
        + #include <locale>
        + #include <wchar.h>
        + 
        + template class std::ctype<wchar_t>; // can't be specialization
        + 
        + +

        + Lib-7047 Matt Austern comments: +

        +
        +

        The status quo is unclear, and probably contradictory. This issue + applies both to explicit instantiations and to specializations, since + it is not permitted to provide both a specialization and an explicit + instantiation. +

        +

        + The specialization issue is actually more serious than the + instantiation one. +

        +
        + +

        In Copenhagen, core working group decided on a proposed resolution + to core issue 259. Under the proposed resolution, it will be legal + for a translation unit to contain both a specialization and an + explicit instantiation of the same template, provided that the + specialization comes first. In such a case, the explicit + instantiation will be ignored. Further discussion of library issue + 120 assumes that the core 259 resolution will be adopted.

        + +

        Proposed resolution:

        +

        Option 1.

        +
        +

        Append to 17.4.3.1 paragraph 1:

        +
        + A program may explicitly instantiate any templates in the standard + library only if the declaration depends on a user-defined name of + external linkage and the instantiation meets the standard library + requirements for the original template. +
        +
        + +

        Option 2.

        +
        +

        In light of the resolution to core issue 259, no normative changes + in the library clauses are necessary. Add the following non-normative + note to the end of 17.4.3.1 paragraph 1:

        +
        + [Note: A program may explicitly instantiate standard library + templates, even when an explicit instantiation does not depend on + a user-defined name. --end note] +
        +
        + +

        [Copenhagen: LWG discussed three options. (A) Users may not + explicitly instantiate standard library templates, except on + user-defined types. Consequence: library implementors may freely + specialize or instantiate templates. (B) It is implementation defined + whether users may explicitly instantiate standard library templates on + non-user-defined types. Consequence: library implementors may freely + specialize or instantiate templates, but must document the templates + they have explicitly instantiated. (C) Users may explicitly + instantiate any standard library template. Consequence: library + implementors may freely specialize templates, but may not explicitly + instantiate them. This is a serious burden for implementors; one way + they can manage it is by defining the standard template as a wrapper, + and putting all of the real work in an internal helper class/function. + ]

        + +

        [Straw poll (first number is favor, second is strongly oppose): + A - 4, 0; B - 0, 9; C - 9, 1. Proposed resolution 1, above, is + option A. (It is the original proposed resolution.) Proposed + resolution 2, above, is option C. Because there was no support + for option B, no wording is provided.]

        +
        +

        123. Should valarray helper arrays fill functions be const?

        + Section: 26.3.5.4 [lib.slice.arr.fill], 26.3.7.4 [lib.gslice.array.fill], 26.3.8.4 [lib.mask.array.fill], 26.3.9.4 [lib.indirect.array.fill]  Status: Open  Submitter: Judy Ward  Date: 15 Dec 1998

        +

        One of the operator= in the valarray helper arrays is const and one + is not. For example, look at slice_array. This operator= in Section + 26.3.5.2 is const:

        + +

            void operator=(const valarray<T>&) const;

        + +

        but this one in Section 26.3.5.4 is not:

        + +

            void operator=(const T&); +

        + +

        The description of the semantics for these two functions is similar.

        +

        Proposed resolution:

        +

        Make the operator=(const T&) versions of slice_array, gslice_array, + indirect_array, and mask_array const member functions.

        + +

        [Dublin: Pete Becker spoke to Daveed Vandevoorde about this and will work on a + proposed resolution.]

        + +

        [Tokyo: Discussed together with the AFNOR paper + 00-0023/N1246. The current helper slices now violate language rules + due to a core language change (but most compilers don't check, so the + violation has previously gone undetected). Major surgery is being + asked for in this and other valarray proposals (see issue 77Rationale), and a complete design review is needed before + making piecemeal changes. Robert Klarer will work on formulating the + issues.]

        +
        +

        167. Improper use of traits_type::length() +

        + Section: 27.6.2.5.4 [lib.ostream.inserters.character]  Status: Review  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        Paragraph 4 states that the length is determined using + traits::length(s). Unfortunately, this function is not + defined for example if the character type is wchar_t and the + type of s is char const*. Similar problems exist if + the character type is char and the type of s is + either signed char const* or unsigned char + const*.

        +

        Proposed resolution:

        +

        Change 27.6.2.5.4 paragraph 4 from:

        +
        +

        Effects: Behaves like an formatted inserter (as described in + lib.ostream.formatted.reqmts) of out. After a sentry object is + constructed it inserts characters. The number of characters starting + at s to be inserted is traits::length(s). Padding is determined as + described in lib.facet.num.put.virtuals. The traits::length(s) + characters starting at s are widened using out.widen + (lib.basic.ios.members). The widened characters and any required + padding are inserted into out. Calls width(0).

        +
        +

        to:

        +
        +

        Effects: Behaves like an formatted inserter (as described in + lib.ostream.formatted.reqmts) of out. After a sentry object is + constructed it inserts characters. The number len of characters + starting at s to be inserted is

        +

        + - traits::length((const char*)s) if the second argument is of type + const charT*
        + - char_traits<char>::length(s) if the second argument is of + type const char*, const signed char*, or const unsigned char* and + and charT is not char.
        +

        +

        Padding is determined as described in + lib.facet.num.put.virtuals. The len characters starting at s are + widened using out.widen (lib.basic.ios.members). The widened + characters and any required padding are inserted into out. Calls + width(0).

        +
        + +

        [Kona: It is clear to the LWG there is a defect here. + Dietmar will supply specific wording.]

        + +

        [Post-Tokyo: Dietmar supplied the above wording.]

        + +

        [Toronto: The original proposed resolution involved + char_traits<signed char> and char_traits<unsigned char>. + There was strong opposition to requiring that library implementors + provide those specializations of char_traits.]

        + +

        [Copenhagen: This still isn't quite right: proposed resolution + text got garbled when the signed char/unsigned char specializations + were removed. Dietmar will provide revised wording.]

        +
        +

        179. Comparison of const_iterators to iterators doesn't work

        + Section: 23.1 [lib.container.requirements]  Status: Review  Submitter: Judy Ward  Date: 2 Jul 1998

        +

        Currently the following will not compile on two well-known standard + library implementations:

        + +
        +
        #include <set>
        + using namespace std;
        + 
        + void f(const set<int> &s)
        + {
        +   set<int>::iterator i;
        +   if (i==s.end()); // s.end() returns a const_iterator
        + }
        +
        + +

        + The reason this doesn't compile is because operator== was implemented + as a member function of the nested classes set:iterator and + set::const_iterator, and there is no conversion from const_iterator to + iterator. Surprisingly, (s.end() == i) does work, though, because of + the conversion from iterator to const_iterator. +

        + +

        + I don't see a requirement anywhere in the standard that this must + work. Should there be one? If so, I think the requirement would need + to be added to the tables in section 24.1.1. I'm not sure about the + wording. If this requirement existed in the standard, I would think + that implementors would have to make the comparison operators + non-member functions.

        + +

        This issues was also raised on comp.std.c++ by Darin + Adler.  The example given was:

        + +
        +
        bool check_equal(std::deque<int>::iterator i,
        + std::deque<int>::const_iterator ci)
        + {
        + return i == ci;
        + }
        +
        + +

        Comment from John Potter:

        +
        +

        + In case nobody has noticed, accepting it will break reverse_iterator. +

        + +

        + The fix is to make the comparison operators templated on two types. +

        + +
        +     template <class Iterator1, class Iterator2>
        +     bool operator== (reverse_iterator<Iterator1> const& x,
        +                      reverse_iterator<Iterator2> const& y);
        +     
        + +

        + Obviously: return x.base() == y.base(); +

        + +

        + Currently, no reverse_iterator to const_reverse_iterator compares are + valid. +

        + +

        + BTW, I think the issue is in support of bad code. Compares should be + between two iterators of the same type. All std::algorithms require + the begin and end iterators to be of the same type. +

        +
        +

        Proposed resolution:

        +

        In section 23.1 after paragraph 7 add:

        +
        +

        It is possible to mix iterators and + const_iterators in iterator comparison and + iterator difference operations.

        +
        + +

        [Post-Tokyo: Judy supplied the above wording at the request of + the LWG.]

        + +

        [post-Toronto: Judy supplied a new proposed resolution. The old + version did not include the words "and iterator + difference".]

        + +

        [Copenhagen: There was some concern that "it is possible + to mix" might be too informal. Howard and Dave will provide new + wording, which will involve a list of expressions that are + guaranteed to be valid.]

        +

        Rationale:

        +

        + The LWG believes it is clear that the above wording applies only to + the nested types X::iterator and X::const_iterator, + where X is a container. There is no requirement that + X::reverse_iterator and X::const_reverse_iterator + can be mixed. If mixing them is considered important, that's a + separate issue. (Issue 280.) +

        +
        +

        182. Ambiguous references to size_t

        + Section: 17 [lib.library]  Status: Ready  Submitter: Al Stevens  Date: 15 Aug 1999

        +

        Many references to size_t throughout the document + omit the std:: namespace qualification.

        For + example, 17.4.3.4 paragraph 2:

        +
        +
        — operator new(size_t)
        + — operator new(size_t, const std::nothrow_t&)
        + — operator new[](size_t)
        + — operator new[](size_t, const std::nothrow_t&)
        +
        +

        Proposed resolution:

        +

        In 17.4.3.4 paragraph 2: replace:

        +
        +

        - operator new(size_t)
        + - operator new(size_t, const std::nothrow_t&)
        + - operator new[](size_t)
        + - operator new[](size_t, const std::nothrow_t&)

        +
        +

        by:

        +
        +
        - operator new(std::size_t)
        + - operator new(std::size_t, const std::nothrow_t&)
        + - operator new[](std::size_t)
        + - operator new[](std::size_t, const std::nothrow_t&)
        +
        +

        In [lib.allocator.requirements] 20.1.5, paragraph 4: replace:

        +
        +

        The typedef members pointer, const_pointer, size_type, and difference_type + are required to be T*, T const*, size_t, and ptrdiff_t, respectively.

        +
        +

         by:

        +
        +

        The typedef members pointer, const_pointer, size_type, and difference_type + are required to be T*, T const*, std::size_t, and std::ptrdiff_t, + respectively.

        +
        +

        In [lib.allocator.members] 20.4.1.1, paragraphs 3 and 6: replace:

        +
        +

        3 Notes: Uses ::operator new(size_t) (18.4.1).

        +

        6 Note: the storage is obtained by calling ::operator new(size_t), but it + is unspecified when or how often this function is called. The use of hint is + unspecified, but intended as an aid to locality if an implementation so + desires.

        +
        +

        by:

        +
        +

        3 Notes: Uses ::operator new(std::size_t) (18.4.1).

        +

        6 Note: the storage is obtained by calling ::operator new(std::size_t), but + it is unspecified when or how often this function is called. The use of hint + is unspecified, but intended as an aid to locality if an implementation so + desires.

        +
        +

        In [lib.char.traits.require] 21.1.1, paragraph 1: replace:

        +
        +

        In Table 37, X denotes a Traits class defining types and functions for the + character container type CharT; c and d denote values of type CharT; p and q + denote values of type const CharT*; s denotes a value of type CharT*; n, i and + j denote values of type size_t; e and f denote values of type X::int_type; pos + denotes a value of type X::pos_type; and state denotes a value of type X::state_type.

        +
        +

        by:

        +
        +

        In Table 37, X denotes a Traits class defining types and functions for the + character container type CharT; c and d denote values of type CharT; p and q + denote values of type const CharT*; s denotes a value of type CharT*; n, i and + j denote values of type std::size_t; e and f denote values of type X::int_type; + pos denotes a value of type X::pos_type; and state denotes a value of type X::state_type.

        +
        +

        In [lib.char.traits.require] 21.1.1, table 37: replace the return type of + X::length(p): "size_t" by "std::size_t".

        +

        In [lib.std.iterator.tags] 24.3.3, paragraph 2: replace:
        +     typedef ptrdiff_t difference_type;
        + by:
        +     typedef std::ptrdiff_t difference_type;

        +

        In [lib.locale.ctype] 22.2.1.1 put namespace std { ...} around the declaration of template <class charT> class ctype.
        +
        + In [lib.iterator.traits] 24.3.1, paragraph 2 put namespace std { ...} around the declaration of:
        +
        +     template<class Iterator> struct iterator_traits
        +     template<class T> struct iterator_traits<T*>
        +     template<class T> struct iterator_traits<const T*>

        +

        Rationale:

        +

        The LWG believes correcting names like size_t and + ptrdiff_t to std::size_t and std::ptrdiff_t + to be essentially editorial. There there can't be another size_t or + ptrdiff_t meant anyway because, according to 17.4.3.1.4 ,

        + +
        + For each type T from the Standard C library, the types ::T and std::T + are reserved to the implementation and, when defined, ::T shall be + identical to std::T. +
        + +

        The issue is treated as a Defect Report to make explicit the Project + Editor's authority to make this change.

        + +

        [Post-Tokyo: Nico Josuttis provided the above wording at the + request of the LWG.]

        + +

        [Toronto: This is tangentially related to issue 229, but only tangentially: the intent of this issue is to + address use of the name size_t in contexts outside of + namespace std, such as in the description of ::operator new. + The proposed changes should be reviewed to make sure they are + correct.]

        + +

        [pre-Copenhagen: Nico has reviewed the changes and believes + them to be correct.]

        + +
        +

        187. iter_swap underspecified

        + Section: 25.2.2 [lib.alg.swap]  Status: Open  Submitter: Andrew Koenig  Date: 14 Aug 1999

        +

        The description of iter_swap in 25.2.2 paragraph 7,says that it ``exchanges the values'' + of the objects to which two iterators refer.
        +
        + What it doesn't say is whether it does so using swap or using the assignment operator and copy constructor.
        +
        + This question is an important one to answer, because swap is specialized to work efficiently for standard containers.
        + For example:

        +
        +
        vector<int> v1, v2;
        + iter_swap(&v1, &v2);
        +
        +

        Is this call to iter_swap equivalent to calling swap(v1, v2)?  Or is it equivalent to

        +
        +
        {
        + vector<int> temp = v1;
        + v1 = v2;
        + v2 = temp;
        + }
        +
        +

        The first alternative is O(1); the second is O(n).

        +

        A LWG member, Dave Abrahams, comments:

        +
        +

        Not an objection necessarily, but I want to point out the cost of that requirement:

        +
        +

        iter_swap(list<T>::iterator, list<T>::iterator)

        +
        +

        can currently be specialized to be more efficient than iter_swap(T*,T*) for many T (by using splicing). Your proposal would make that optimization + illegal. 

        +
        + +

        [Kona: The LWG notes the original need for iter_swap was proxy iterators + which are no longer permitted.]

        +

        Proposed resolution:

        +

        Change the effect clause of iter_swap in 25.2.2 paragraph 7 from:

        +
        +

        Exchanges the values pointed to by the two iterators a and b.

        +
        +

        to

        +
        +

        + swap(*a, *b).

        +
        + +

        [post-Toronto: The LWG is concerned about possible + overspecification: there may be cases, such as Dave Abrahams's example + above, and such as vector<bool>'s iterators, where it makes more + sense for iter_swap to do something other than swap. If performance + is a concern, it may be better to have explicit complexity + requirements than to say how iter_swap should be implemented.]

        +
        +

        197. max_size() underspecified

        + Section: 20.1.5 [lib.allocator.requirements], 23.1 [lib.container.requirements]  Status: Open  Submitter: Andy Sawyer  Date: 21 Oct 1999

        +

        Must the value returned by max_size() be unchanged from call to call?

        + +

        Must the value returned from max_size() be meaningful?

        + +

        Possible meanings identified in lib-6827:

        + +

        1) The largest container the implementation can support given "best + case" conditions - i.e. assume the run-time platform is "configured to + the max", and no overhead from the program itself. This may possibly + be determined at the point the library is written, but certainly no + later than compile time.
        +
        + 2) The largest container the program could create, given "best case" + conditions - i.e. same platform assumptions as (1), but take into + account any overhead for executing the program itself. (or, roughly + "storage=storage-sizeof(program)"). This does NOT include any resource + allocated by the program. This may (or may not) be determinable at + compile time.
        +
        + 3) The largest container the current execution of the program could + create, given knowledge of the actual run-time platform, but again, + not taking into account any currently allocated resource. This is + probably best determined at program start-up.
        +
        + 4) The largest container the current execution program could create at + the point max_size() is called (or more correctly at the point + max_size() returns :-), given it's current environment (i.e. taking + into account the actual currently available resources). This, + obviously, has to be determined dynamically each time max_size() is + called.

        +

        Proposed resolution:

        +

        Change 20.1.5 table 32 max_size() wording from:
        +
        +       the largest value that can meaningfully be + passed to X::allocate
        + to:
        +       the value of the largest constant expression + (5.19 ) that could ever meaningfully be passed to X::allocate

        + +

        + Change 23.1 table 65 max_size() wording from:
        +
        +       size() of the largest possible container.
        + to:
        +       the value of the largest constant expression + (5.19 ) that could ever meaningfully be returned by X::size(). +

        + +

        [Kona: The LWG informally discussed this and asked Andy Sawyer to submit + an issue.]

        + +

        [Tokyo: The LWG believes (1) above is the intended meaning.]

        + +

        [Post-Tokyo: Beman Dawes supplied the above resolution at the + request of the LWG. 21.3.3 was not changed because it + references max_size() in 23.1. The term "compile-time" was + avoided because it is not defined anywhere in the standard (even + though it is used several places in the library clauses).]

        + +

        [Copenhagen: Exactly what max_size means is still + unclear. It may have a different meaning as a container member + function than as an allocator member function. For the latter, + it is probably best thought of as an architectural limit. + Nathan will provide new wording.]

        +
        +

        198. Validity of pointers and references unspecified after iterator destruction

        + Section: 24.1 [lib.iterator.requirements]  Status: Review  Submitter: Beman Dawes  Date: 3 Nov 1999

        +

        + Is a pointer or reference obtained from an iterator still valid after + destruction of the iterator? +

        +

        + Is a pointer or reference obtained from an iterator still valid after the value + of the iterator changes? +

        +
        +
        + #include <iostream>
        + #include <vector>
        + #include <iterator>
        + 
        + int main()
        + {
        +     typedef std::vector<int> vec_t;
        +     vec_t v;
        +     v.push_back( 1 );
        + 
        +     // Is a pointer or reference obtained from an iterator still
        +     // valid after destruction of the iterator?
        +     int * p = &*v.begin();
        +     std::cout << *p << '\n';  // OK?
        + 
        +     // Is a pointer or reference obtained from an iterator still
        +     // valid after the value of the iterator changes?
        +     vec_t::iterator iter( v.begin() );
        +     p = &*iter++;
        +     std::cout << *p << '\n';  // OK?
        + 
        +     return 0;
        + }
        + 
        +
        + +

        The standard doesn't appear to directly address these + questions. The standard needs to be clarified. At least two real-world + cases have been reported where library implementors wasted + considerable effort because of the lack of clarity in the + standard. The question is important because requiring pointers and + references to remain valid has the effect for practical purposes of + prohibiting iterators from pointing to cached rather than actual + elements of containers.

        + +

        The standard itself assumes that pointers and references obtained + from an iterator are still valid after iterator destruction or + change. The definition of reverse_iterator::operator*(), 24.4.1.3.3 , which returns a reference, defines + effects:

        + +
        +
        Iterator tmp = current;
        + return *--tmp;
        +
        +

        The definition of reverse_iterator::operator->(), 24.4.1.3.4 , which returns a pointer, defines effects:

        +
        +
        return &(operator*());
        +
        + +

        Because the standard itself assumes pointers and references remain + valid after iterator destruction or change, the standard should say so + explicitly. This will also reduce the chance of user code breaking + unexpectedly when porting to a different standard library + implementation.

        +

        Proposed resolution:

        +

        Add a new paragraph to 24.1 :

        +
        + Destruction of an iterator may invalidate pointers and references + previously obtained from that iterator. +
        + +

        Replace paragraph 1 of 24.4.1.3.3 with:

        + +
        +

        Effects:

        +
        +   this->tmp = current;
        +   --this->tmp;
        +   return *this->tmp;
        + 
        + +

        + [Note: This operation must use an auxiliary member variable, + rather than a temporary variable, to avoid returning a reference that + persists beyond the lifetime of its associated iterator. (See + 24.1 .) The name of this member variable is shown for + exposition only. --end note] +

        +
        + +

        [Tokyo: The LWG reformulated the question purely in terms of + iterators. The answer to the question is "no, pointers and references + don't remain valid after iterator destruction." PJP explained that + implementors use considerable care to avoid such ephemeral pointers and + references. Several LWG members said that they thought that the standard + did not actually specify the lifetime of pointers and references obtained from + iterators, except possibly input iterators.]

        + +

        [Post-Tokyo: The issue has been reformulated purely + in terms of iterators.]

        + +

        [Pre-Toronto: Steve Cleary pointed out the no-invalidation + assumption by reverse_iterator. The issue and proposed resolution was + reformulated yet again to reflect this reality.]

        + +

        [Copenhagen: Andy Koenig pointed out that it is possible to + rewrite reverse_iterator so that it no longer makes this assumption. + However, this issue is related to issue 299. If we + decide it is intentional that p[n] may return by value + instead of reference when p is a Random Access Iterator, then + other changes in reverse_iterator will be necessary.]

        +
        +

        200. Forward iterator requirements don't allow constant iterators

        + Section: 24.1.3 [lib.forward.iterators]  Status: Open  Submitter: Matt Austern  Date: 19 Nov 1999

        +

        + In table 74, the return type of the expression *a is given + as T&, where T is the iterator's value type. + For constant iterators, however, this is wrong. ("Value type" + is never defined very precisely, but it is clear that the value type + of, say, std::list<int>::const_iterator is supposed to be + int, not const int.) +

        +

        Proposed resolution:

        +

        + In table 74, change the return type column for *a + from "T&" to "T& if + X is mutable, otherwise const T&". +

        + +

        [Tokyo: The LWG believes this is the tip of a larger iceberg; + there are multiple const problems with the STL portion of the library + and that these should be addressed as a single package.  Note + that issue 180 has already been declared NAD Future for + that very reason.]

        +
        +

        201. Numeric limits terminology wrong

        + Section: 18.2.1 [lib.limits]  Status: Open  Submitter: Stephen Cleary  Date: 21 Dec 1999

        +

        + In some places in this section, the terms "fundamental types" and + "scalar types" are used when the term "arithmetic types" is intended. + The current usage is incorrect because void is a fundamental type and + pointers are scalar types, neither of which should have + specializations of numeric_limits. +

        +

        Proposed resolution:

        +

        Change 18.2 [lib.support.limits] para 1 from:

        +
        + +

        The headers <limits>, <climits>, and <cfloat> supply characteristics of implementation-dependent fundamental types (3.9.1).

        +
        + +

        to:

        +
        + +

        The headers <limits>, <climits>, and <cfloat> supply characteristics of implementation-dependent arithmetic types (3.9.1).

        +
        + +

        Change 18.2.1 [lib.limits] para 1 from:

        +
        + +

        The numeric_limits component provides a C++ program with information about various properties of the implementation's representation of the fundamental + types.

        +
        + +

        to:

        +
        + +

        The numeric_limits component provides a C++ program with information about various properties of the implementation's representation of the arithmetic + types.

        +
        + +

        Change 18.2.1 [lib.limits] para 2 from:

        +
        + +

        Specializations shall be provided for each fundamental type. . .

        +
        + +

        to:

        +
        + +

        Specializations shall be provided for each arithmetic type. . .

        +
        + +

        Change 18.2.1 [lib.limits] para 4 from:

        +
        + +

        Non-fundamental standard types. . .

        +
        + +

        to:

        +
        + +

        Non-arithmetic standard types. . .

        +
        + +

        Change 18.2.1.1 [lib.numeric.limits] para 1 from:

        +
        + +

        The member is_specialized makes it possible to distinguish between fundamental types, which have specializations, and non-scalar types, which + do not.

        +
        + +

        to:

        +
        + +

        The member is_specialized makes it possible to distinguish between arithmetic types, which have specializations, and non-arithmetic types, + which do not.

        +
        + +

        [post-Toronto: The opinion of the LWG is that the wording in the + standard, as well as the wording of the proposed resolution, is + flawed. The term "arithmetic types" is well defined in C + and C++, and it is not clear that the term is being used correctly. + It is also not clear that the term "implementation + dependent" has any useful meaning in this context. The biggest + problem is that numeric_limits seems to be intended both for built-in + types and for user-defined types, and the standard doesn't make it + clear how numeric_limits applies to each of those cases. A wholesale + review of numeric_limits is needed. A paper would be welcome.]

        +
        +

        202. unique() effects unclear when predicate not an equivalence relation

        + Section: 25.2.8 [lib.alg.unique]  Status: Open  Submitter: Andrew Koenig  Date: 13 Jan 2000

        +

        + What should unique() do if you give it a predicate that is not an + equivalence relation? There are at least two plausible answers: +

        + +
        + +

        + 1. You can't, because 25.2.8 says that it it "eliminates all but + the first element from every consecutive group of equal + elements..." and it wouldn't make sense to interpret "equal" as + meaning anything but an equivalence relation. [It also doesn't + make sense to interpret "equal" as meaning ==, because then there + would never be any sense in giving a predicate as an argument at + all.] +

        + +

        + 2. The word "equal" should be interpreted to mean whatever the + predicate says, even if it is not an equivalence relation + (and in particular, even if it is not transitive). +

        + +
        + +

        + The example that raised this question is from Usenet: +

        + +
        + +
        int f[] = { 1, 3, 7, 1, 2 };
        + int* z = unique(f, f+5, greater<int>());
        + +
        + +

        + If one blindly applies the definition using the predicate + greater<int>, and ignore the word "equal", you get: +

        + +
        + +

        + Eliminates all but the first element from every consecutive group + of elements referred to by the iterator i in the range [first, last) + for which *i > *(i - 1). +

        + +
        + +

        + The first surprise is the order of the comparison. If we wanted to + allow for the predicate not being an equivalence relation, then we + should surely compare elements the other way: pred(*(i - 1), *i). If + we do that, then the description would seem to say: "Break the + sequence into subsequences whose elements are in strictly increasing + order, and keep only the first element of each subsequence". So the + result would be 1, 1, 2. If we take the description at its word, it + would seem to call for strictly DEcreasing order, in which case the + result should be 1, 3, 7, 2.
        +
        + In fact, the SGI implementation of unique() does neither: It yields 1, + 3, 7. +

        +

        Proposed resolution:

        +

        Options:

        +
        +

        1. Impose an explicit requirement that the predicate be an + equivalence relation. 

        +

        2. Drop the word "equal" from the description to make it clear that + the intent is to compare pairs of adjacent elements, and + change pred(*i, *(i - 1)) to pred(*(i - 1), i).

        +

        3. Change the effects to:

        +
        + Effects: Eliminates all but the first element e from + every consecutive group of elements referred to by the + iterator i in the range [first, last) for which the + following corresponding conditions hold: e == *i or + pred(e,*i) != false. +
        +
        +

        A LWG member, Nico Josuttis, comments:

        +

        First, I agree that the current wording is simply wrong. However, to follow + all [known] current implementations I propose [option 3 above].

        + +

        [ Tokyo: The issue was discussed at length without reaching + consensus. Straw vote: Option 1 - preferred by 2 people. Option 2 - + preferred by 0 people. Option 3 - preferred by 3 people. Many + abstentions. ]

        + +

        [Copenhagen: There was some support for all options. The option + with the least support was 1 (one person in favor), and the option + with the most support was 2 (seven in favor). One person was strongly + opposed to option 1, and one person was strongly opposed to the + variation on option 2 in which the order of arguments would remain + pred(*i, *(i - 1)).]

        +
        +

        225. std:: algorithms use of other unqualified algorithms

        + Section: 17.4.4.3 [lib.global.functions]  Status: Open  Submitter: Dave Abrahams  Date: 01 Apr 2000

        +

        Are algorithms in std:: allowed to use other algorithms without qualification, so functions in + user namespaces might be found through Koenig lookup?

        +

        For example, a popular standard library implementation includes this + implementation of std::unique:

        +
        +
        namespace std {
        +     template <class _ForwardIter>
        +     _ForwardIter unique(_ForwardIter __first, _ForwardIter __last) {
        +       __first = adjacent_find(__first, __last);
        +       return unique_copy(__first, __last, __first);
        +     }
        +     }
        +
        +

        Imagine two users on opposite sides of town, each using unique on his own + sequences bounded by my_iterators . User1 looks at his standard library + implementation and says, "I know how to implement a more efficient + unique_copy for my_iterators", and writes:

        +
        +
        namespace user1 {
        +     class my_iterator;
        +     // faster version for my_iterator
        +     my_iterator unique_copy(my_iterator, my_iterator, my_iterator);
        +     }
        +
        +

        user1::unique_copy() is selected by Koenig lookup, as he intended.

        +

        User2 has other needs, and writes:

        +
        +
        namespace user2 {
        +     class my_iterator;
        +     // Returns true iff *c is a unique copy of *a and *b.
        +     bool unique_copy(my_iterator a, my_iterator b, my_iterator c);
        +     }
        +
        +

        User2 is shocked to find later that his fully-qualified use of + std::unique(user2::my_iterator, user2::my_iterator, user2::my_iterator) fails to + compile (if he's lucky). Looking in the standard, he sees the following Effects + clause for unique():

        +
        +

        Effects: Eliminates all but the first element from every consecutive group + of equal elements referred to by the iterator i in the range [first, last) for + which the following corresponding conditions hold: *i == *(i - 1) or pred(*i, + *(i - 1)) != false

        +
        +

        The standard gives user2 absolutely no reason to think he can interfere with + std::unique by defining names in namespace user2. His standard library has been + built with the template export feature, so he is unable to inspect the + implementation. User1 eventually compiles his code with another compiler, and + his version of unique_copy silently stops being called. Eventually, he realizes + that he was depending on an implementation detail of his library and had no + right to expect his unique_copy() to be called portably.

        +

        On the face of it, and given above scenario, it may seem obvious that the + implementation of unique() shown is non-conforming because it uses unique_copy() + rather than ::std::unique_copy(). Most standard library implementations, + however, seem to disagree with this notion.

        +

        [Tokyo:  Steve Adamczyk from + the core working group indicates that "std::" is sufficient;  + leading "::" qualification is not required because any namespace + qualification is sufficient to suppress Koenig lookup.] +

        +

        Proposed resolution:

        +

        Add a paragraph and a note at the end of + 17.4.4.3 :

        +
        + +

        Unless otherwise specified, no global or non-member function in the + standard library shall use a function from another namespace which is + found through argument-dependent name lookup (3.4.2 ).

        + +

        [Note: the phrase "unless otherwise specified" is intended to + allow Koenig lookup in cases like that of ostream_iterators:
        + +
        + Effects:

        +
        +

        *out_stream << value;
        + if(delim != 0) *out_stream << delim;
        + return (*this);

        +

        --end note]

        +
        +
        + +

        [Tokyo: The LWG agrees that this is a defect in the standard, but + is as yet unsure if the proposed resolution is the best + solution. Furthermore, the LWG believes that the same problem of + unqualified library names applies to wording in the standard itself, + and has opened issue 229 accordingly. Any resolution of + issue 225 should be coordinated with the resolution of + issue 229.]

        + +

        [Toronto: The LWG is not sure if this is a defect in the + standard. Most LWG members believe that an implementation of + std::unique like the one quoted in this issue is already + illegal, since, under certain circumstances, its semantics are not + those specified in the standard. The standard's description of + unique does not say that overloading adjacent_find + should have any effect.]

        +
        +

        226. User supplied specializations or overloads of namespace std function templates

        + Section: 17.4.3.1 [lib.reserved.names]  Status: Open  Submitter: Dave Abrahams  Date: 01 Apr 2000

        +

        The issues are: 

        +

        1. How can a 3rd party library implementor (lib1) write a version of a standard + algorithm which is specialized to work with his own class template? 

        +

        2. How can another library implementor (lib2) write a generic algorithm which + will take advantage of the specialized algorithm in lib1?

        +

        This appears to be the only viable answer under current language rules:

        +
        +
        namespace lib1
        + {
        +     // arbitrary-precision numbers using T as a basic unit
        +     template <class T>
        +     class big_num { //...
        +     };
        +     
        +
            // defining this in namespace std is illegal (it would be an
        +     // overload), so we hope users will rely on Koenig lookup
        +     template <class T>
        +     void swap(big_int<T>&, big_int<T>&);
        + }
        +
        #include <algorithm>
        + namespace lib2
        + {
        +     template <class T>
        +     void generic_sort(T* start, T* end)
        +     {
        +             ...
        +         // using-declaration required so we can work on built-in types
        +         using std::swap;
        +         // use Koenig lookup to find specialized algorithm if available
        +         swap(*x, *y);
        +     }
        + }
        +
        +

        This answer has some drawbacks. First of all, it makes writing lib2 difficult + and somewhat slippery. The implementor needs to remember to write the + using-declaration, or generic_sort will fail to compile when T is a built-in + type. The second drawback is that the use of this style in lib2 effectively + "reserves" names in any namespace which defines types which may + eventually be used with lib2. This may seem innocuous at first when applied to + names like swap, but consider more ambiguous names like unique_copy() instead. + It is easy to imagine the user wanting to define these names differently in his + own namespace. A definition with semantics incompatible with the standard + library could cause serious problems (see issue 225).

        +

        Why, you may ask, can't we just partially specialize std::swap()? It's + because the language doesn't allow for partial specialization of function + templates. If you write:

        +
        +
        namespace std
        + {
        +     template <class T>
        +     void swap(lib1::big_int<T>&, lib1::big_int<T>&);
        + }
        +
        +

        You have just overloaded std::swap, which is illegal under the current + language rules. On the other hand, the following full specialization is legal:

        +
        +
        namespace std
        + {
        +     template <>
        +     void swap(lib1::other_type&, lib1::other_type&);
        + }
        +
        + +

        This issue reflects concerns raised by the "Namespace issue + with specialized swap" thread on comp.lang.c++.moderated. A + similar set of concerns was earlier raised on the boost.org mailing + list and the ACCU-general mailing list. Also see library reflector + message c++std-lib-7354.

        + +

        Proposed resolution:

        + +

        [Tokyo: Summary, "There is no conforming way to extend + std::swap for user defined templates."  The LWG agrees that + there is a problem.  Would like more information before + proceeding. This may be a core issue. Core issue 229 has been opened + to discuss the core aspects of this problem. It was also noted that + submissions regarding this issue have been received from several + sources, but too late to be integrated into the issues list. + ]

        + +

        [Post-Tokyo: A paper with several proposed resolutions, + J16/00-0029==WG21/N1252, "Shades of namespace std functions + " by Alan Griffiths, is in the Post-Tokyo mailing. It + should be considered a part of this issue.]

        + +

        [Toronto: Dave Abrahams and Peter Dimov have proposed a + resolution that involves core changes: it would add partial + specialization of function template. The Core Working Group is + reluctant to add partial specialization of function templates. It is + viewed as a large change, CWG believes that proposal presented leaves + some syntactic issues unanswered; if the CWG does add partial + specialization of function templates, it wishes to develop its own + proposal. The LWG continues to believe that there is a serious + problem: there is no good way for users to force the library to use + user specializations of generic standard library functions, and in + certain cases (e.g. transcendental functions called by + valarray and complex) this is important. Koenig + lookup isn't adequate, since names within the library must be + qualified with std (see issue 225), specialization doesn't + work (we don't have partial specialization of function templates), and + users aren't permitted to add overloads within namespace std. + ]

        + +

        [Copenhagen: Discussed at length, with no consensus. Relevant + papers in the pre-Copenhagen mailing: N1289, N1295, N1296. Discussion + focused on four options. (1) Relax restrictions on overloads within + namespace std. (2) Mandate that the standard library use unqualified + calls for swap and possibly other functions. (3) Introduce + helper class templates for swap and possibly other functions. + (4) Introduce partial specialization of function templates. Every + option had both support and opposition. Straw poll (first number is + support, second is strongly opposed): (1) 6, 4; (2) 6, 7; (3) 3, 8; + (4) 4, 4.]

        +
        +

        228. Incorrect specification of "..._byname" facets

        + Section: 22.2 [lib.locale.categories]  Status: Ready  Submitter: Dietmar Kühl  Date: 20 Apr 2000

        +

        The sections 22.2.1.2 , 22.2.1.4 , + 22.2.1.6 , 22.2.3.2 , 22.2.4.2 , 22.2.5.4 , 22.2.6.4 , and 22.2.7.2 overspecify the + definitions of the "..._byname" classes by listing a bunch + of virtual functions. At the same time, no semantics of these + functions are defined. Real implementations do not define these + functions because the functional part of the facets is actually + implemented in the corresponding base classes and the constructor of + the "..._byname" version just provides suitable date used by + these implementations. For example, the 'numpunct' methods just return + values from a struct. The base class uses a statically initialized + struct while the derived version reads the contents of this struct + from a table. However, no virtual function is defined in + 'numpunct_byname'.

        + +

        For most classes this does not impose a problem but specifically + for 'ctype' it does: The specialization for 'ctype_byname<char>' + is required because otherwise the semantics would change due to the + virtual functions defined in the general version for 'ctype_byname': + In 'ctype<char>' the method 'do_is()' is not virtual but it is + made virtual in both 'ctype<cT>' and 'ctype_byname<cT>'. + Thus, a class derived from 'ctype_byname<char>' can tell whether + this class is specialized or not under the current specification: + Without the specialization, 'do_is()' is virtual while with + specialization it is not virtual.

        +

        Proposed resolution:

        +

          Change section 22.2.1.2 (lib.locale.ctype.byname) to become:

        +
             namespace std {
        +        template <class charT>
        +        class ctype_byname : public ctype<charT> {
        +        public:
        +          typedef ctype<charT>::mask mask;
        +          explicit ctype_byname(const char*, size_t refs = 0);
        +        protected:
        +         ~ctype_byname();             //  virtual
        +        };
        +      }
        +

          Change section 22.2.1.6 (lib.locale.codecvt.byname) to become:

        +
            namespace std {
        +       template <class internT, class externT, class stateT>
        +       class codecvt_byname : public codecvt<internT, externT, stateT> {
        +       public:
        +        explicit codecvt_byname(const char*, size_t refs = 0);
        +       protected:
        +       ~codecvt_byname();             //  virtual
        +        };
        +      }
        + 
        +

          Change section 22.2.3.2 (lib.locale.numpunct.byname) to become:

        +
             namespace std {
        +        template <class charT>
        +        class numpunct_byname : public numpunct<charT> {
        +      //  this class is specialized for  char  and  wchar_t.
        +        public:
        +          typedef charT                char_type;
        +          typedef basic_string<charT>  string_type;
        +          explicit numpunct_byname(const char*, size_t refs = 0);
        +        protected:
        +         ~numpunct_byname();          //  virtual
        +        };
        +      }
        +

          Change section 22.2.4.2 (lib.locale.collate.byname) to become:

        +
             namespace std {
        +        template <class charT>
        +        class collate_byname : public collate<charT> {
        +        public:
        +          typedef basic_string<charT> string_type;
        +          explicit collate_byname(const char*, size_t refs = 0);
        +        protected:
        +         ~collate_byname();           //  virtual
        +        };
        +      }
        +

          Change section 22.2.5.2 (lib.locale.time.get.byname) to become:

        +
             namespace std {
        +        template <class charT, class InputIterator = istreambuf_iterator<charT> >
        +        class time_get_byname : public time_get<charT, InputIterator> {
        +        public:
        +          typedef time_base::dateorder dateorder;
        +          typedef InputIterator        iter_type
        +
                 explicit time_get_byname(const char*, size_t refs = 0);
        +        protected:
        +         ~time_get_byname();          //  virtual
        +        };
        +      }
        +

          Change section 22.2.5.4 (lib.locale.time.put.byname) to become:

        +
             namespace std {
        +        template <class charT, class OutputIterator = ostreambuf_iterator<charT> >
        +        class time_put_byname : public time_put<charT, OutputIterator>
        +        {
        +        public:
        +          typedef charT          char_type;
        +          typedef OutputIterator iter_type;
        +
                 explicit time_put_byname(const char*, size_t refs = 0);
        +        protected:
        +         ~time_put_byname();          //  virtual
        +        };
        +      }"
        +

          Change section 22.2.6.4 (lib.locale.moneypunct.byname) to become:

        +
             namespace std {
        +        template <class charT, bool Intl = false>
        +        class moneypunct_byname : public moneypunct<charT, Intl> {
        +        public:
        +          typedef money_base::pattern pattern;
        +          typedef basic_string<charT> string_type;
        +
                 explicit moneypunct_byname(const char*, size_t refs = 0);
        +        protected:
        +         ~moneypunct_byname();        //  virtual
        +        };
        +      }
        +

          Change section 22.2.7.2 (lib.locale.messages.byname) to become:

        +
             namespace std {
        +        template <class charT>
        +        class messages_byname : public messages<charT> {
        +        public:
        +          typedef messages_base::catalog catalog;
        +          typedef basic_string<charT>    string_type;
        +
                 explicit messages_byname(const char*, size_t refs = 0);
        +        protected:
        +         ~messages_byname();          //  virtual
        +        };
        +      }
        +

        Remove section 22.2.1.4 completely (because in + this case only those members are defined to be virtual which are + defined to be virtual in 'ctype<cT>'.)

        + +

        [Post-Tokyo: Dietmar Kühl submitted this issue at the request of + the LWG to solve the underlying problems raised by issue 138.]

        + +

        [Copenhagen: proposed resolution was revised slightly, to remove + three last virtual functions from messages_byname.]

        + +
        +

        229. Unqualified references of other library entities

        + Section: 17.4.1.1 [lib.contents]  Status: Open  Submitter: Steve Clamage  Date: 19 Apr 2000

        +

        Throughout the library chapters, the descriptions of library entities refer + to other library entities without necessarily qualifying the names.

        + +

        For example, section 25.2.2 "Swap" describes the effect of + swap_ranges in terms of the unqualified name "swap". This section + could reasonably be interpreted to mean that the library must be implemented so + as to do a lookup of the unqualified name "swap", allowing users to + override any ::std::swap function when Koenig lookup applies.

        + +

        Although it would have been best to use explicit qualification with + "::std::" throughout, too many lines in the standard would have to be + adjusted to make that change in a Technical Corrigendum.

        + +

        Issue 182, which addresses qualification of + size_t, is a special case of this. +

        +

        Proposed resolution:

        +

        To section 17.4.1.1 "Library contents" Add the following paragraph:

        +
        +

        Whenever a name x defined in the standard library is mentioned, the name x + is assumed to be fully qualified as ::std::x, unless explicitly described + otherwise. For example, if the Effects section for library function F is + described as calling library function G, the function ::std::G is meant.

        +
        + +

        [Post-Tokyo: Steve Clamage submitted this issue at the request of + the LWG to solve a problem in the standard itself similar to the + problem within implementations of library identified by issue 225. Any resolution of issue 225 should be + coordinated with the resolution of this issue.]

        + +

        [post-Toronto: Howard is undecided about whether it is + appropriate for all standard library function names referred to in + other standard library functions to be explicitly qualified by + std: it is common advice that users should define global + functions that operate on their class in the same namespace as the + class, and this requires argument-dependent lookup if those functions + are intended to be called by library code. Several LWG members are + concerned that valarray appears to require argument-dependent lookup, + but that the wording may not be clear enough to fall under + "unless explicitly described otherwise".]

        +
        +

        230. Assignable specified without also specifying CopyConstructible

        + Section: 17 [lib.library]  Status: Ready  Submitter: Beman Dawes  Date: 26 Apr 2000

        +

        Issue 227 identified an instance (std::swap) where + Assignable was specified without also specifying + CopyConstructible. The LWG asked that the standard be searched to + determine if the same defect existed elsewhere.

        + +

        There are a number of places (see proposed resolution below) where + Assignable is specified without also specifying + CopyConstructible. There are also several cases where both are + specified. For example, 26.4.1 .

        +

        Proposed resolution:

        +

        In 23.1 table 65 for value_type: + change "T is Assignable" to "T is CopyConstructible and + Assignable" +

        + +

        In 23.1.2 table 69 X::key_type; change + "Key is Assignable" to "Key is + CopyConstructible and Assignable"
        +

        + +

        In 24.1.2 paragraph 1, change: +

        +
        +

        A class or a built-in type X satisfies the requirements of an + output iterator if X is an Assignable type (23.1) and also the + following expressions are valid, as shown in Table 73: +

        +
        +

        to: +

        +
        +

        A class or a built-in type X satisfies the requirements of an + output iterator if X is a CopyConstructible (20.1.3) and Assignable + type (23.1) and also the following expressions are valid, as shown in + Table 73: +

        +
        + +

        [Post-Tokyo: Beman Dawes submitted this issue at the request of + the LWG. He asks that the 25.2.4 and 25.2.5 changes be studied carefully, as it is not clear that + CopyConstructible is really a requirement and may be + overspecification.]

        +

        Rationale:

        +

        The original proposed resolution also included changes to input + iterator, fill, and replace. The LWG believes that those changes are + not necessary. The LWG considered some blanket statement, where an + Assignable type was also required to be Copy Constructible, but + decided against this because fill and replace really don't require the + Copy Constructible property.

        +
        +

        231. Precision in iostream?

        + Section: 22.2.2.2.2 [lib.facet.num.put.virtuals]  Status: Review  Submitter: James Kanze, Stephen Clamage  Date:  25 Apr 2000

        +

        What is the following program supposed to output?

        +
        #include <iostream>
        + 
        +     int
        +     main()
        +     {
        +         std::cout.setf( std::ios::scientific , std::ios::floatfield ) ;
        +         std::cout.precision( 0 ) ;
        +         std::cout << 1.23 << '\n' ;
        +         return 0 ;
        +     }
        +

        From my C experience, I would expect "1e+00"; this is what + printf("%.0e" , 1.23 ); does. G++ outputs + "1.000000e+00".

        + +

        The only indication I can find in the standard is 22.2.2.2.2/11, + where it says "For conversion from a floating-point type, if + (flags & fixed) != 0 or if str.precision() > 0, then + str.precision() is specified in the conversion specification." + This is an obvious error, however, fixed is not a mask for a field, + but a value that a multi-bit field may take -- the results of and'ing + fmtflags with ios::fixed are not defined, at least not if + ios::scientific has been set. G++'s behavior corresponds to what might + happen if you do use (flags & fixed) != 0 with a typical + implementation (floatfield == 3 << something, fixed == 1 + << something, and scientific == 2 << something).

        + +

        Presumably, the intent is either (flags & floatfield) != 0, or + (flags & floatfield) == fixed; the first gives something more or + less like the effect of precision in a printf floating point + conversion. Only more or less, of course. In order to implement printf + formatting correctly, you must know whether the precision was + explicitly set or not. Say by initializing it to -1, instead of 6, and + stating that for floating point conversions, if precision < -1, 6 + will be used, for fixed point, if precision < -1, 1 will be used, + etc. Plus, of course, if precision == 0 and flags & floatfield == + 0, 1 should be = used. But it probably isn't necessary to emulate all + of the anomalies of printf:-).

        +

        Proposed resolution:

        +

        + In 22.2.2.2.2 , paragraph 11, change + "if (flags & fixed) != 0" to + "if (flags & floatfield) == fixed || + (flags & floatfield) == scientific" +

        +

        Rationale:

        +

        The floatfield determines whether numbers are formatted as if + with %f, %e, or %g. If the fixed bit is set, it's %f, + if scientific it's %e, and if both bits are set, or + neither, it's %e.

        +

        Turning to the C standard, a precision of 0 is meaningful + for %f and %e, but not for %g: for %g, precision 0 is taken + to be the same as precision 1.

        +

        The proposed resolution has the effect that the output of + the above program will be "1e+00".

        +
        +

        232. "depends" poorly defined in 17.4.3.1

        + Section: 17.4.3.1 [lib.reserved.names]  Status: Ready  Submitter: Peter Dimov  Date: 18 Apr 2000

        +

        17.4.3.1/1 uses the term "depends" to limit the set of allowed + specializations of standard templates to those that "depend on a + user-defined name of external linkage."

        +

        This term, however, is not adequately defined, making it possible to + construct a specialization that is, I believe, technically legal according to + 17.4.3.1/1, but that specializes a standard template for a built-in type such as + 'int'.

        +

        The following code demonstrates the problem:

        +
        +
        #include <algorithm>
        +
        template<class T> struct X
        + {
        +  typedef T type;
        + };
        +
        namespace std
        + {
        +  template<> void swap(::X<int>::type& i, ::X<int>::type& j);
        + }
        +
        +

        Proposed resolution:

        +

        Change "user-defined name" to "user-defined + type".

        +

        Rationale:

        +

        This terminology is used in section 2.5.2 and 4.1.1 of The C++ + Programming Language. It disallows the example in the issue, + since the underlying type itself is not user-defined. The only + possible problem I can see is for non-type templates, but there's no + possible way for a user to come up with a specialization for bitset, + for example, that might not have already been specialized by the + implementor?

        + +

        [Toronto: this may be related to issue 120.]

        + +

        [post-Toronto: Judy provided the above proposed resolution and + rationale.]

        +
        +

        233. Insertion hints in associative containers

        + Section: 23.1.2 [lib.associative.reqmts]  Status: Review  Submitter: Andrew Koenig  Date: 30 Apr 2000

        +

        + If mm is a multimap and p is an iterator + into the multimap, then mm.insert(p, x) inserts + x into mm with p as a hint as + to where it should go. Table 69 claims that the execution time is + amortized constant if the insert winds up taking place adjacent to + p, but does not say when, if ever, this is guaranteed to + happen. All it says it that p is a hint as to where to + insert. +

        +

        + The question is whether there is any guarantee about the relationship + between p and the insertion point, and, if so, what it + is. +

        +

        + I believe the present state is that there is no guarantee: The user + can supply p, and the implementation is allowed to + disregard it entirely. +

        +

        Proposed resolution:

        + +

        + General Idea (Andrew Koenig): + t is inserted at the point closest to (the point immediately + ahead of) p. That would give the user a way of controlling the order + in which elements appear that have equal keys. Doing so would be + particularly easy in two cases that I suspect are common: +

        +
        +   mm.insert(mm.begin(), t); // inserts as first element of set of equal keys
        +   mm.insert(mm.end(), t);   // inserts as last element of set of equal keys
        + 
        + +

        + These examples would allow t to be inserted at the beginning and end, + respectively, of the set of elements with the same key as t. +

        + +

        + assertion/note/pre/postcondition in table 69
        + Change: +

        +
        + iterator p is a hint pointing to where the insert should start to search. +
        +

        To:

        +
        + if t is inserted, p is used as follows: insert t right before p + if possible; otherwise, if p is equal to a.end(), or if the key value + of t is greater than the key value of *p, t is inserted just before + a.lowerbound(the key value of t); otherwise, t is inserted right + before a.upperbound(the key value of t). +
        +

        complexity:
        + Change:

        +
        right after p
        +

        To:

        +
        right before p
        + +

        + Thus making:
        + assertion/note/pre/postcondition: +

        +
        + inserts t if and only if there is no element with key equivalent to + the key of t in containers with unique keys; always inserts t in + containers with equivalent keys. always returns the iterator pointing + to the element with key equivalent to the key of t. + if t is inserted, p is used as follows: insert t right before p + if possible; otherwise, if p is equal to a.end(), or if the key value + of t is greater than the key value of *p, t is inserted just before + a.lowerbound(the key value of t); otherwise, t is inserted right + before a.upperbound(the key value of t). +
        NON-NORMATIVE FOOTNOTE: + | This gives the user a way of controlling the order + | in which elements appear that have equal keys. Doing this is + | particularly easy in two common cases: +
        + | mm.insert(mm.begin(), t); // inserts as first element of set of equal keys
        + | mm.insert(mm.end(), t);   // inserts as last element of set of equal keys
        + 
        +
        END-FOOTNOTE +
        + +

        complexity:

        +
        + logarithmic in general, but amortized constant if t is inserted right + before p. +
        + +

        [Toronto: there was general agreement that this is a real defect: + when inserting an element x into a multiset that already contains + several copies of x, there is no way to know whether the hint will be + used. There was some support for an alternative resolution: we check + on both sides of the hint (both before and after, in that order). If + either is the correct location, the hint is used; otherwise it is not. + This would be different from the original proposed resolution, because + in the proposed resolution the hint will be used even if it is very + far from the insertion point. JC van Winkel supplied precise wording + for both options.]

        + +

        [Copenhagen: the LWG looked at both options, and preferred the + original. This preference is contingent on seeing a reference + implementation showing that it is possible to implement this + requirement without loss of efficiency.]

        + +
        +

        235. No specification of default ctor for reverse_iterator

        + Section: 24.4.1.1 [lib.reverse.iterator]  Status: Ready  Submitter: Dietmar Kühl  Date: 24 Apr 2000

        +

        The declaration of reverse_iterator lists a default + constructor. However, no specification is given what this constructor + should do.

        +

        Proposed resolution:

        +

        In section 24.4.1.3.1 add the following + paragraph:

        +
        +

        reverse_iterator()

        + +

        Default initializes current. Iterator operations + applied to the resulting iterator have defined behavior if and + only if the corresponding operations are defined on a default + constructed iterator of type Iterator.

        +
        +

        [pre-Copenhagen: Dietmar provide wording for proposed + resolution.]

        +
        +

        238. Contradictory results of stringbuf initialization.

        + Section: 27.7.1.1 [lib.stringbuf.cons]  Status: Ready  Submitter: Dietmar Kühl  Date: 11 May 2000

        +

        In 27.7.1.1 paragraph 4 the results of calling the constructor of + 'basic_stringbuf' are said to be str() == str. This is fine + that far but consider this code:

        + +
        +   std::basic_stringbuf<char> sbuf("hello, world", std::ios_base::openmode(0));
        +   std::cout << "'" << sbuf.str() << "'\n";
        + 
        + +

        Paragraph 3 of 27.7.1.1 basically says that in this case neither + the output sequence nor the input sequence is initialized and + paragraph 2 of 27.7.1.2 basically says that str() either + returns the input or the output sequence. None of them is initialized, + ie. both are empty, in which case the return from str() is + defined to be basic_string<cT>().

        + +

        However, probably only test cases in some testsuites will detect this + "problem"...

        +

        Proposed resolution:

        +

        Remove 27.7.1.1 paragraph 4.

        +

        Rationale:

        +

        We could fix 27.7.1.1 paragraph 4, but there would be no point. If + we fixed it, it would say just the same thing as text that's already + in the standard.

        +
        +

        239. Complexity of unique() and/or unique_copy incorrect

        + Section: 25.2.8 [lib.alg.unique]  Status: Open  Submitter: Angelika Langer  Date: May 15 2000

        +

        The complexity of unique and unique_copy are inconsistent with each + other and inconsistent with the implementations.  The standard + specifies:

        + +

        for unique():

        + +
        -3- Complexity: If the range (last - first) is not empty, exactly + (last - first) - 1 applications of the corresponding predicate, otherwise + no applications of the predicate.
        + +

        for unique_copy():

        + +
        -7- Complexity: Exactly last - first applications of the corresponding + predicate.
        + +

        + The implementations do it the other way round: unique() applies the + predicate last-first times and unique_copy() applies it last-first-1 + times.

        + +

        As both algorithms use the predicate for pair-wise comparison of + sequence elements I don't see a justification for unique_copy() + applying the predicate last-first times, especially since it is not + specified to which pair in the sequence the predicate is applied + twice.

        +

        Proposed resolution:

        +

        Change both complexity sections in 25.2.8 to:

        + +
        Complexity: Exactly last - first - 1 applications of the + corresponding predicate.
        + +

        [Toronto: This is related to issue 202. We can't + specify unique's complexity until we decide what + unique is supposed to do.]

        +
        +

        240. Complexity of adjacent_find() is meaningless

        + Section: 25.1.5 [lib.alg.adjacent.find]  Status: Review  Submitter: Angelika Langer  Date: May 15 2000

        +

        The complexity section of adjacent_find is defective:

        + +
        +
        + template <class ForwardIterator>
        + ForwardIterator adjacent_find(ForwardIterator first, ForwardIterator last
        +                               BinaryPredicate pred);
        + 
        + +

        -1- Returns: The first iterator i such that both i and i + 1 are in + the range [first, last) for which the following corresponding + conditions hold: *i == *(i + 1), pred(*i, *(i + 1)) != false. Returns + last if no such iterator is found.

        + +

        -2- Complexity: Exactly find(first, last, value) - first applications + of the corresponding predicate. +

        +
        + +

        In the Complexity section, it is not defined what "value" + is supposed to mean. My best guess is that "value" means an + object for which one of the conditions pred(*i,value) or + pred(value,*i) is true, where i is the iterator defined in the Returns + section. However, the value type of the input sequence need not be + equality-comparable and for this reason the term find(first, last, + value) - first is meaningless.

        + +

        A term such as find_if(first, last, bind2nd(pred,*i)) - first or + find_if(first, last, bind1st(pred,*i)) - first might come closer to + the intended specification. Binders can only be applied to function + objects that have the function call operator declared const, which is + not required of predicates because they can have non-const data + members. For this reason, a specification using a binder could only be + an "as-if" specification.

        +

        Proposed resolution:

        +

        Change the complexity section in 25.1.5 to:

        +
        + For a nonempty range, exactly min((i - first) + 1, + (last - first) - 1) applications of the + corresponding predicate, where i is adjacent_find's + return value. +
        + +

        [Copenhagen: the original resolution specified an upper + bound. The LWG preferred an exact count.]

        + +
        +

        241. Does unique_copy() require CopyConstructible and Assignable?

        + Section: 25.2.8 [lib.alg.unique]  Status: Ready  Submitter: Angelika Langer  Date: May 15 2000

        + +

        Some popular implementations of unique_copy() create temporary + copies of values in the input sequence, at least if the input iterator + is a pointer. Such an implementation is built on the assumption that + the value type is CopyConstructible and Assignable.

        + +

        It is common practice in the standard that algorithms explicitly + specify any additional requirements that they impose on any of the + types used by the algorithm. An example of an algorithm that creates + temporary copies and correctly specifies the additional requirements + is accumulate(), 26.4.1 .

        + +

        Since the specifications of unique() and unique_copy() do not + require CopyConstructible and Assignable of the InputIterator's value + type the above mentioned implementations are not standard-compliant. I + cannot judge whether this is a defect in the standard or a defect in + the implementations.

        +

        Proposed resolution:

        +

        In 25.2.8 change:

        + +
        + -4- Requires: The ranges [first, last) and [result, result+(last-first)) + shall not overlap. +
        + +

        to:

        + +
        + -4- Requires: The ranges [first, last) and [result, result+(last-first)) + shall not overlap. The expression *result = *first is valid. +
        +

        Rationale:

        +

        + Creating temporary copies is unavoidable, since the arguments may be + input iterators; this implies that the value type must be copy + constructible. However, we don't need to say this explicitly; it's + already implied by table 72 in 24.1.1. We don't precisely want to say + that the input iterator's value type T must be assignable, + because we never quite use that property. We assign through the + output iterator. The output iterator might have a different value + type, or no value type; it might not use T's assignment + operator. If it's an ostream_iterator, for example, then + we'll use T's operator<< but not its assignment + operator. +

        +
        +

        242. Side effects of function objects

        + Section: 25.2.3 [lib.alg.transform], 26.4 [lib.numeric.ops]  Status: Ready  Submitter: Angelika Langer  Date: May 15 2000

        +

        The algorithms transform(), accumulate(), inner_product(), + partial_sum(), and adjacent_difference() require that the function + object supplied to them shall not have any side effects.

        + +

        The standard defines a side effect in 1.9 as:

        +
        -7- Accessing an object designated by a volatile lvalue (basic.lval), + modifying an object, calling a library I/O function, or calling a function + that does any of those operations are all side effects, which are changes + in the state of the execution environment.
        + +

        As a consequence, the function call operator of a function object supplied + to any of the algorithms listed above cannot modify data members, cannot + invoke any function that has a side effect, and cannot even create and + modify temporary objects.  It is difficult to imagine a function object + that is still useful under these severe limitations. For instance, any + non-trivial transformator supplied to transform() might involve creation + and modification of temporaries, which is prohibited according to the current + wording of the standard.

        + +

        On the other hand, popular implementations of these algorithms exhibit + uniform and predictable behavior when invoked with a side-effect-producing + function objects. It looks like the strong requirement is not needed for + efficient implementation of these algorithms.

        + +

        The requirement of  side-effect-free function objects could be + replaced by a more relaxed basic requirement (which would hold for all + function objects supplied to any algorithm in the standard library):

        +
        A function objects supplied to an algorithm shall not invalidate + any iterator or sequence that is used by the algorithm. Invalidation of + the sequence includes destruction of the sorting order if the algorithm + relies on the sorting order (see section 25.3 - Sorting and related operations + [lib.alg.sorting]).
        + +

        I can't judge whether it is intended that the function objects supplied + to transform(), accumulate(), inner_product(), partial_sum(), or adjacent_difference() + shall not modify sequence elements through dereferenced iterators.

        + +

        It is debatable whether this issue is a defect or a change request. + Since the consequences for user-supplied function objects are drastic and + limit the usefulness of the algorithms significantly I would consider it + a defect.

        +

        Proposed resolution:

        + +

        Things to notice about these changes:

        + +
          +
        1. The fully-closed ("[]" as opposed to half-closed "[)" ranges + are intentional. we want to prevent side-effects from + invalidating the end iterators. +
        2. + +
        3. That has the unintentional side-effect of prohibiting + modification of the end element as a side-effect. This could + conceivably be significant in some cases. +
        4. + +
        5. The wording also prevents side-effects from modifying elements + of the output sequence. I can't imagine why anyone would want + to do this, but it is arguably a restriction that implementors + don't need to place on users. +
        6. + +
        7. Lifting the restrictions imposed in #2 and #3 above is possible + and simple, but would require more verbiage. +
        8. +
        + +

        Change 25.2.3/2 from:

        + +
        + -2- Requires: op and binary_op shall not have any side effects. +
        + +

        to:

        + +
        + -2- Requires: in the ranges [first1, last1], [first2, first2 + + (last1 - first1)] and [result, result + (last1- first1)], op and + binary_op shall neither modify elements nor invalidate iterators or + subranges. + [Footnote: The use of fully closed ranges is intentional --end footnote] +
        + + +

        Change 25.2.3/2 from:

        + +
        + -2- Requires: op and binary_op shall not have any side effects. +
        + +

        to:

        + +
        + -2- Requires: op and binary_op shall not invalidate iterators or + subranges, or modify elements in the ranges [first1, last1], + [first2, first2 + (last1 - first1)], and [result, result + (last1 + - first1)]. + [Footnote: The use of fully closed ranges is intentional --end footnote] +
        + + +

        Change 26.4.1/2 from:

        + +
        + -2- Requires: T must meet the requirements of CopyConstructible + (lib.copyconstructible) and Assignable (lib.container.requirements) + types. binary_op shall not cause side effects. +
        + +

        to:

        + +
        + -2- Requires: T must meet the requirements of CopyConstructible + (lib.copyconstructible) and Assignable + (lib.container.requirements) types. In the range [first, last], + binary_op shall neither modify elements nor invalidate iterators + or subranges. + [Footnote: The use of a fully closed range is intentional --end footnote] +
        + +

        Change 26.4.2/2 from:

        + +
        + -2- Requires: T must meet the requirements of CopyConstructible + (lib.copyconstructible) and Assignable (lib.container.requirements) + types. binary_op1 and binary_op2 shall not cause side effects. +
        + +

        to:

        + +
        + -2- Requires: T must meet the requirements of CopyConstructible + (lib.copyconstructible) and Assignable (lib.container.requirements) + types. In the ranges [first, last] and [first2, first2 + (last - + first)], binary_op1 and binary_op2 shall neither modify elements + nor invalidate iterators or subranges. + [Footnote: The use of fully closed ranges is intentional --end footnote] +
        + + +

        Change 26.4.3/4 from:

        + +
        + -4- Requires: binary_op is expected not to have any side effects. +
        + +

        to:

        + +
        + -4- Requires: In the ranges [first, last] and [result, result + + (last - first)], binary_op shall neither modify elements nor + invalidate iterators or subranges. + [Footnote: The use of fully closed ranges is intentional --end footnote] +
        + +

        Change 26.4.4/2 from:

        + +
        + -2- Requires: binary_op shall not have any side effects. +
        + +

        to:

        + +
        + -2- Requires: In the ranges [first, last] and [result, result + + (last - first)], binary_op shall neither modify elements nor + invalidate iterators or subranges. + [Footnote: The use of fully closed ranges is intentional --end footnote] +
        + +

        [Toronto: Dave Abrahams supplied wording.]

        + +

        [Copenhagen: Proposed resolution was modified slightly. Matt + added footnotes pointing out that the use of closed ranges was + intentional.]

        + +
        +

        247. vector, deque::insert complexity

        + Section: 23.2.4.3 [lib.vector.modifiers]  Status: Open  Submitter: Lisa Lippincott  Date: 06 June 2000

        +

        Paragraph 2 of 23.2.4.3 [lib.vector.modifiers] describes the complexity + of vector::insert:

        + +
        + Complexity: If first and last are forward iterators, bidirectional + iterators, or random access iterators, the complexity is linear in + the number of elements in the range [first, last) plus the distance + to the end of the vector. If they are input iterators, the complexity + is proportional to the number of elements in the range [first, last) + times the distance to the end of the vector. +
        + +

        First, this fails to address the non-iterator forms of + insert.

        + +

        Second, the complexity for input iterators misses an edge case -- + it requires that an arbitrary number of elements can be added at + the end of a vector in constant time.

        + +

        At the risk of strengthening the requirement, I suggest simply

        + +
        + Complexity: The complexity is linear in the number of elements + inserted plus the distance to the end of the vector. +
        + +

        For input iterators, one may achieve this complexity by first + inserting at the end of the vector, and then using + rotate.

        + +

        I looked to see if deque had a similar problem, and was + surprised to find that deque places no requirement on the + complexity of inserting multiple elements (23.2.1.3 , + paragraph 3):

        + +
        + Complexity: In the worst case, inserting a single element into a + deque takes time linear in the minimum of the distance from the + insertion point to the beginning of the deque and the distance + from the insertion point to the end of the deque. Inserting a + single element either at the beginning or end of a deque always + takes constant time and causes a single call to the copy constructor + of T. +
        + +

        I suggest:

        + +
        + Complexity: The complexity is linear in the number of elements + inserted plus the shorter of the distances to the beginning and + end of the deque. Inserting a single element at either the + beginning or the end of a deque causes a single call to the copy + constructor of T. +
        +

        Proposed resolution:

        + +

        [Toronto: It's agreed that there is a defect in complexity of + multi-element insert for vector and deque. For vector, the complexity + should probably be something along the lines of c1 * N + + c2 * distance(i, end()). However, there is some + concern about whether it is reasonable to amortize away the copies + that we get from a reallocation whenever we exceed the vector's + capacity. For deque, the situation is somewhat less clear. Deque is + notoriously complicated, and we may not want to impose complexity + requirements that would imply any implementation technique more + complicated than a while loop whose body is a single-element + insert.]

        +
        +

        250. splicing invalidates iterators

        + Section: 23.2.2.4 [lib.list.ops]  Status: Ready  Submitter: Brian Parker   Date: 14 Jul 2000

        +

        + Section 23.2.2.4 [lib.list.ops] states that +

        +
        +   void splice(iterator position, list<T, Allocator>& x);
        + 
        +

        + invalidates all iterators and references to list x. +

        + +

        + This is unnecessary and defeats an important feature of splice. In + fact, the SGI STL guarantees that iterators to x remain valid + after splice. +

        +

        Proposed resolution:

        + +

        Add a footnote to 23.2.2.4 , paragraph 1:

        +
        + [Footnote: As specified in 20.1.5 , paragraphs + 4-5, the semantics described in this clause applies only to the case + where allocators compare equal. --end footnote] +
        + +

        In 23.2.2.4 , replace paragraph 4 with:

        +
        + Effects: Inserts the contents of x before position and x becomes + empty. Pointers and references to the moved elements of x now refer to + those same elements but as members of *this. Iterators referring to the + moved elements will continue to refer to their elements, but they now + behave as iterators into *this, not into x. +
        + +

        In 23.2.2.4 , replace paragraph 7 with:

        +
        + Effects: Inserts an element pointed to by i from list x before + position and removes the element from x. The result is unchanged if + position == i or position == ++i. Pointers and references to *i continue + to refer to this same element but as a member of *this. Iterators to *i + (including i itself) continue to refer to the same element, but now + behave as iterators into *this, not into x. +
        + +

        In 23.2.2.4 , replace paragraph 12 with:

        +
        + Requires: [first, last) is a valid range in x. The result is + undefined if position is an iterator in the range [first, last). + Pointers and references to the moved elements of x now refer to those + same elements but as members of *this. Iterators referring to the moved + elements will continue to refer to their elements, but they now behave as + iterators into *this, not into x. +
        + +

        [pre-Copenhagen: Howard provided wording.]

        +

        Rationale:

        +

        The original proposed resolution said that iterators and references + would remain "valid". The new proposed resolution clarifies what that + means. Note that this only applies to the case of equal allocators. + From 20.1.5 paragraph 4, the behavior of list when + allocators compare nonequal is outside the scope of the standard.

        +
        +

        253. valarray helper functions are almost entirely useless

        + Section: 26.3.2.1 [lib.valarray.cons], 26.3.2.2 [lib.valarray.assign]  Status: Open  Submitter: Robert Klarer  Date: 31 Jul 2000

        +

        This discussion is adapted from message c++std-lib-7056 posted + November 11, 1999. I don't think that anyone can reasonably claim + that the problem described below is NAD.

        + +

        These valarray constructors can never be called:

        + +
        +    template <class T>
        +          valarray<T>::valarray(const slice_array<T> &);
        +    template <class T>
        +          valarray<T>::valarray(const gslice_array<T> &);
        +    template <class T>
        +          valarray<T>::valarray(const mask_array<T> &);
        +    template <class T>
        +          valarray<T>::valarray(const indirect_array<T> &);
        + 
        + +

        Similarly, these valarray assignment operators cannot be + called:

        + +
        +      template <class T>
        +      valarray<T> valarray<T>::operator=(const slice_array<T> &);
        +      template <class T>
        +      valarray<T> valarray<T>::operator=(const gslice_array<T> &);
        +      template <class T>
        +      valarray<T> valarray<T>::operator=(const mask_array<T> &);
        +      template <class T>
        +      valarray<T> valarray<T>::operator=(const indirect_array<T> &);
        + 
        + +

        Please consider the following example:

        + +
        +    #include <valarray>
        +    using namespace std;
        + 
        +    int main()
        +    {
        +        valarray<double> va1(12);
        +        valarray<double> va2(va1[slice(1,4,3)]); // line 1
        +    }
        + 
        + + +

        Since the valarray va1 is non-const, the result of the sub-expression + va1[slice(1,4,3)] at line 1 is an rvalue of type const + std::slice_array<double>. This slice_array rvalue is then used to + construct va2. The constructor that is used to construct va2 is + declared like this:

        + +
        +      template <class T>
        +      valarray<T>::valarray(const slice_array<T> &);
        + 
        + +

        Notice the constructor's const reference parameter. When the + constructor is called, a slice_array must be bound to this reference. + The rules for binding an rvalue to a const reference are in 8.5.3, + paragraph 5 (see also 13.3.3.1.4). Specifically, paragraph 5 + indicates that a second slice_array rvalue is constructed (in this + case copy-constructed) from the first one; it is this second rvalue + that is bound to the reference parameter. Paragraph 5 also requires + that the constructor that is used for this purpose be callable, + regardless of whether the second rvalue is elided. The + copy-constructor in this case is not callable, however, because it is + private. Therefore, the compiler should report an error.

        + +

        Since slice_arrays are always rvalues, the valarray constructor that has a + parameter of type const slice_array<T> & can never be called. The + same reasoning applies to the three other constructors and the four + assignment operators that are listed at the beginning of this post. + Furthermore, since these functions cannot be called, the valarray helper + classes are almost entirely useless.

        +

        Proposed resolution:

        +

        + Adopt section 2 of 00-0023/N1246. Sections 1 and 5 of that paper have + already been classified as "Request for Extension". Sections + 3 and 4 are reasonable generalizations of section 2, but they do not + resolve an obvious inconsistency in the standard. +

        + +

        [Toronto: it is agreed that there is a defect. A full + discussion, and an attempt at fixing the defect, should wait until we + can hear from valarray experts.]

        +
        +

        254. Exception types in clause 19 are constructed from std::string +

        + Section: 19.1 [lib.std.exceptions]  Status: Open  Submitter: Dave Abrahams  Date: 01 Aug 2000

        +

        + Many of the standard exception types which implementations are + required to throw are constructed with a const std::string& + parameter. For example: +

        + +
        +      19.1.5  Class out_of_range                          [lib.out.of.range]
        +      namespace std {
        +        class out_of_range : public logic_error {
        +        public:
        +          explicit out_of_range(const string& what_arg);
        +        };
        +      }
        + 
        +    1 The class out_of_range defines the type of objects  thrown  as  excep-
        +      tions to report an argument value not in its expected range.
        + 
        +      out_of_range(const string& what_arg);
        + 
        +      Effects:
        +        Constructs an object of class out_of_range.
        +      Postcondition:
        +        strcmp(what(), what_arg.c_str()) == 0.
        + 
        + +

        + There are at least two problems with this: +

        +
          +
        1. A program which is low on memory may end up throwing + std::bad_alloc instead of out_of_range because memory runs out while + constructing the exception object.
        2. +
        3. An obvious implementation which stores a std::string data member + may end up invoking terminate() during exception unwinding because the + exception object allocates memory (or rather fails to) as it is being + copied.
        4. +
        + +

        + There may be no cure for (1) other than changing the interface to + out_of_range, though one could reasonably argue that (1) is not a + defect. Personally I don't care that much if out-of-memory is reported + when I only have 20 bytes left, in the case when out_of_range would + have been reported. People who use exception-specifications might care + a lot, though. +

        + +

        + There is a cure for (2), but it isn't completely obvious. I think a + note for implementors should be made in the standard. Avoiding + possible termination in this case shouldn't be left up to chance. The + cure is to use a reference-counted "string" implementation + in the exception object. I am not necessarily referring to a + std::string here; any simple reference-counting scheme for a NTBS + would do. +

        + +

        + Further discussion, in email: +

        + +

        + ...I'm not so concerned about (1). After all, a library implementation + can add const char* constructors as an extension, and users don't + need to avail themselves of the standard exceptions, though this is + a lame position to be forced into. FWIW, std::exception and + std::bad_alloc don't require a temporary basic_string. +

        + +

        + ...I don't think the fixed-size buffer is a solution to the problem, + strictly speaking, because you can't satisfy the postcondition +
        +   strcmp(what(), what_arg.c_str()) == 0 +
        + For all values of what_arg (i.e. very long values). That means that + the only truly conforming solution requires a dynamic allocation. +

        +

        Proposed resolution:

        + +

        [Toronto: some LWG members thought this was merely a QoI issue, + but most believed that it was at least a borderline defect. There was + more support for nonnormative advice to implementors than for a + normative change.]

        +
        +

        258. Missing allocator requirement

        + Section: 20.1.5 [lib.allocator.requirements]  Status: Open  Submitter: Matt Austern  Date: 22 Aug 2000

        +

        + From lib-7752: +

        + +

        + I've been assuming (and probably everyone else has been assuming) that + allocator instances have a particular property, and I don't think that + property can be deduced from anything in Table 32. +

        + +

        + I think we have to assume that allocator type conversion is a + homomorphism. That is, if x1 and x2 are of type X, where + X::value_type is T, and if type Y is X::template + rebind<U>::other, then Y(x1) == Y(x2) if and only if x1 == x2. +

        + +

        + Further discussion: Howard Hinnant writes, in lib-7757: +

        + +

        + I think I can prove that this is not provable by Table 32. And I agree + it needs to be true except for the "and only if". If x1 != x2, I see no + reason why it can't be true that Y(x1) == Y(x2). Admittedly I can't + think of a practical instance where this would happen, or be valuable. + But I also don't see a need to add that extra restriction. I think we + only need: +

        + +
        + if (x1 == x2) then Y(x1) == Y(x2) +
        + +

        + If we decide that == on allocators is transitive, then I think I can + prove the above. But I don't think == is necessarily transitive on + allocators. That is: +

        + +

        + Given x1 == x2 and x2 == x3, this does not mean x1 == x3. +

        + +

        Example:

        + +
        +

        + x1 can deallocate pointers from: x1, x2, x3
        + x2 can deallocate pointers from: x1, x2, x4
        + x3 can deallocate pointers from: x1, x3
        + x4 can deallocate pointers from: x2, x4 +

        + +

        + x1 == x2, and x2 == x4, but x1 != x4 +

        +
        +

        Proposed resolution:

        + +

        [Toronto: LWG members offered multiple opinions. One + opinion is that it should not be required that x1 == x2 + implies Y(x1) == Y(x2), and that it should not even be + required that X(x1) == x1. Another opinion is that + the second line from the bottom in table 32 already implies the + desired property. This issue should be considered in light of + other issues related to allocator instances.]

        +
        +

        259. basic_string::operator[] and const correctness

        + Section: 21.3.4 [lib.string.access]  Status: Ready  Submitter: Chris Newton   Date: 27 Aug 2000

        +

        + Paraphrased from a message that Chris Newton posted to comp.std.c++: +

        + +

        + The standard's description of basic_string<>::operator[] + seems to violate const correctness. +

        + +

        + The standard (21.3.4/1) says that "If pos < size(), + returns data()[pos]." The types don't work. The + return value of data() is const charT*, but + operator[] has a non-const version whose return type is reference. +

        +

        Proposed resolution:

        +

        + In section 21.3.4, paragraph 1, change + "data()[pos]" to "*(begin() + + pos)". +

        +
        +

        264. Associative container insert(i, j) complexity requirements are not feasible.

        + Section: 23.1.2 [lib.associative.reqmts]  Status: Ready  Submitter: John Potter  Date: 07 Sep 2000

        +

        + Table 69 requires linear time if [i, j) is sorted. Sorted is necessary but not sufficient. + Consider inserting a sorted range of even integers into a set<int> containing the odd + integers in the same range. +

        + +

        Related issue: 102

        +

        Proposed resolution:

        +

        + In Table 69, in section 23.1.2, change the complexity clause for + insertion of a range from "N log(size() + N) (N is the distance + from i to j) in general; linear if [i, j) is sorted according to + value_comp()" to "N log(size() + N), where N is the distance + from i to j". +

        + +

        [Copenhagen: Minor fix in proposed resolution: fixed unbalanced + parens in the revised wording.]

        + +

        Rationale:

        +

        + Testing for valid insertions could be less efficient than simply + inserting the elements when the range is not both sorted and between + two adjacent existing elements; this could be a QOI issue. +

        + +

        + The LWG considered two other options: (a) specifying that the + complexity was linear if [i, j) is sorted according to value_comp() + and between two adjacent existing elements; or (b) changing to + Klog(size() + N) + (N - K) (N is the distance from i to j and K is the + number of elements which do not insert immediately after the previous + element from [i, j) including the first). The LWG felt that, since + we can't guarantee linear time complexity whenever the range to be + inserted is sorted, it's more trouble than it's worth to say that it's + linear in some special cases. +

        +
        +

        266. bad_exception::~bad_exception() missing Effects clause

        + Section: 18.6.2.1 [lib.bad.exception]  Status: Ready  Submitter: Martin Sebor  Date: 24 Sep 2000

        +

        + The synopsis for std::bad_exception lists the function ~bad_exception() + but there is no description of what the function does (the Effects + clause is missing). +

        +

        Proposed resolution:

        +

        + Remove the destructor from the class synopses of + bad_alloc (18.4.2.1 ), + bad_cast (18.5.2 ), + bad_typeid (18.5.3 ), + and bad_exception (18.6.2.1 ). +

        +

        Rationale:

        +

        + This is a general problem with the exception classes in clause 18. + The proposed resolution is to remove the destructors from the class + synopses, rather than to document the destructors' behavior, because + removing them is more consistent with how exception classes are + described in clause 19. +

        +
        +

        267. interaction of strstreambuf::overflow() and seekoff()

        + Section: D.7.1.3 [depr.strstreambuf.virtuals]  Status: Ready  Submitter: Martin Sebor  Date: 5 Oct 2000

        +

        + It appears that the interaction of the strstreambuf members overflow() + and seekoff() can lead to undefined behavior in cases where defined + behavior could reasonably be expected. The following program + demonstrates this behavior: +

        + +
        +     #include <strstream>
        + 
        +     int main ()
        +     {
        +          std::strstreambuf sb;
        +          sb.sputc ('c');
        + 
        +          sb.pubseekoff (-1, std::ios::end, std::ios::in);
        +          return !('c' == sb.sgetc ());
        +     }
        + 
        + +

        + D.7.1.1, p1 initializes strstreambuf with a call to basic_streambuf<>(), + which in turn sets all pointers to 0 in 27.5.2.1, p1. +

        + +

        + 27.5.2.2.5, p1 says that basic_streambuf<>::sputc(c) calls + overflow(traits::to_int_type(c)) if a write position isn't available (it + isn't due to the above). +

        + +

        + D.7.1.3, p3 says that strstreambuf::overflow(off, ..., ios::in) makes at + least one write position available (i.e., it allows the function to make + any positive number of write positions available). +

        + +

        + D.7.1.3, p13 computes newoff = seekhigh - eback(). In D.7.1, p4 we see + seekhigh = epptr() ? epptr() : egptr(), or seekhigh = epptr() in this + case. newoff is then epptr() - eback(). +

        + +

        + D.7.1.4, p14 sets gptr() so that gptr() == eback() + newoff + off, or + gptr() == epptr() + off holds. +

        + +

        + If strstreambuf::overflow() made exactly one write position available + then gptr() will be set to just before epptr(), and the program will + return 0. Buf if the function made more than one write position + available, epptr() and gptr() will both point past pptr() and the + behavior of the program is undefined. +

        +

        Proposed resolution:

        + + +

        Change the last sentence of D.7.1 paragraph 4 from

        + +
        + Otherwise, seeklow equals gbeg and seekhigh is either pend, if + pend is not a null pointer, or gend. +
        + +

        to become

        + +
        + Otherwise, seeklow equals gbeg and seekhigh is either gend if + 0 == pptr(), or pbase() + max where max is the maximum value of + pptr() - pbase() ever reached for this stream. +
        + +

        [ + pre-Copenhagen: Dietmar provided wording for proposed resolution. + ]

        + +

        [ + post-Copenhagen: Fixed a typo: proposed resolution said to fix + 4.7.1, not D.7.1. + ]

        + +

        Rationale:

        +

        Note that this proposed resolution does not require an increase in + the layout of strstreambuf to maintain max: If overflow() is + implemented to make exactly one write position available, max == + epptr() - pbase() always holds. However, if overflow() makes more than + one write position available, the number of additional character (or + some equivalent) has to be stored somewhere.

        +
        +

        270. Binary search requirements overly strict

        + Section: 25.3.3 [lib.alg.binary.search]  Status: Review  Submitter: Matt Austern  Date: 18 Oct 2000

        +

        + Each of the four binary search algorithms (lower_bound, upper_bound, + equal_range, binary_search) has a form that allows the user to pass a + comparison function object. According to 25.3, paragraph 2, that + comparison function object has to be a strict weak ordering. +

        + +

        + This requirement is slightly too strict. Suppose we are searching + through a sequence containing objects of type X, where X is some + large record with an integer key. We might reasonably want to look + up a record by key, in which case we would want to write something + like this: +

        +
        +     struct key_comp {
        +       bool operator()(const X& x, int n) const {
        +         return x.key() < n;
        +       }
        +     }
        + 
        +     std::lower_bound(first, last, 47, key_comp());
        + 
        + +

        + key_comp is not a strict weak ordering, but there is no reason to + prohibit its use in lower_bound. +

        + +

        + There's no difficulty in implementing lower_bound so that it allows + the use of something like key_comp. (It will probably work unless an + implementor takes special pains to forbid it.) What's difficult is + formulating language in the standard to specify what kind of + comparison function is acceptable. We need a notion that's slightly + more general than that of a strict weak ordering, one that can encompass + a comparison function that involves different types. Expressing that + notion may be complicated. +

        + +

        Additional questions raised at the Toronto meeting:

        +
          +
        • Do we really want to specify what ordering the implementor must + use when calling the function object? The standard gives + specific expressions when describing these algorithms, but it also + says that other expressions (with different argument order) are + equivalent.
        • +
        • If we are specifying ordering, note that the standard uses both + orderings when describing equal_range.
        • +
        • Are we talking about requiring these algorithms to work properly + when passed a binary function object whose two argument types + are not the same, or are we talking about requirements when + they are passed a binary function object with several overloaded + versions of operator()?
        • +
        • The definition of a strict weak ordering does not appear to give + any guidance on issues of overloading; it only discusses expressions, + and all of the values in these expressions are of the same type. + Some clarification would seem to be in order.
        • +
        + +

        Additional discussion from Copenhagen:

        +
          +
        • It was generally agreed that there is a real defect here: if + the predicate is merely required to be a Strict Weak Ordering, then + it's possible to pass in a function object with an overloaded + operator(), where the version that's actually called does something + completely inappropriate. (Such as returning a random value.)
        • + +
        • An alternative formulation was presented in a paper distributed by + David Abrahams at the meeting, "Binary Search with Heterogeneous + Comparison", J16-01/0027 = WG21 N1313: Instead of viewing the + predicate as a Strict Weak Ordering acting on a sorted sequence, view + the predicate/value pair as something that partitions a sequence. + This is almost equivalent to saying that we should view binary search + as if we are given a unary predicate and a sequence, such that f(*p) + is true for all p below a specific point and false for all p above it. + The proposed resolution is based on that alternative formulation.
        • +
        +

        Proposed resolution:

        + +

        Change 25.3 [lib.alg.sorting] paragraph 3 from:

        + +
        + 3 For all algorithms that take Compare, there is a version that uses + operator< instead. That is, comp(*i, *j) != false defaults to *i < + *j != false. For the algorithms to work correctly, comp has to + induce a strict weak ordering on the values. +
        + +

        to:

        + +
        + 3 For all algorithms that take Compare, there is a version that uses + operator< instead. That is, comp(*i, *j) != false defaults to *i < + *j != false. For algorithms not described in lib.alg.binary.search + (25.3.3) to work correctly, comp has to induce a strict weak + ordering on the values. +
        + +

        Add the following paragraph after 25.3 [lib.alg.sorting] paragraph 5:

        + +
        + -6- A sequence [start, finish) is partitioned with respect to an + expression f(e) if there exists a non-negative integer n such that + for all 0 <= i < distance(start, finish), f(*(begin+i)) is true if + and only if i < n. +
        + +

        Change 25.3.3 [lib.alg.binary.search] paragraph 1 from:

        + +
        + -1- All of the algorithms in this section are versions of binary + search and assume that the sequence being searched is in order + according to the implied or explicit comparison function. They work + on non-random access iterators minimizing the number of + comparisons, which will be logarithmic for all types of + iterators. They are especially appropriate for random access + iterators, because these algorithms do a logarithmic number of + steps through the data structure. For non-random access iterators + they execute a linear number of steps. +
        + +

        to:

        + +
        + -1- All of the algorithms in this section are versions of binary + search and assume that the sequence being searched is partitioned + with respect to an expression formed by binding the search key to + an argument of the implied or explicit comparison function. They + work on non-random access iterators minimizing the number of + comparisons, which will be logarithmic for all types of + iterators. They are especially appropriate for random access + iterators, because these algorithms do a logarithmic number of + steps through the data structure. For non-random access iterators + they execute a linear number of steps. +
        + +

        Change 25.3.3.1 [lib.lower.bound] paragraph 1 from:

        + +
        + -1- Requires: Type T is LessThanComparable + (lib.lessthancomparable). +
        + +

        to:

        + +
        + -1- Requires: The elements e of [first, last) are partitioned with + respect to the expression e < value or comp(e, value) +
        + + +

        Remove 25.3.3.1 [lib.lower.bound] paragraph 2:

        + +
        + -2- Effects: Finds the first position into which value can be + inserted without violating the ordering. +
        + +

        Change 25.3.3.2 [lib.upper.bound] paragraph 1 from:

        + +
        + -1- Requires: Type T is LessThanComparable (lib.lessthancomparable). +
        + +

        to:

        + +
        + -1- Requires: The elements e of [first, last) are partitioned with + respect to the expression !(value < e) or !comp(value, e) +
        + +

        Remove 25.3.3.2 [lib.upper.bound] paragraph 2:

        + +
        + -2- Effects: Finds the furthermost position into which value can be + inserted without violating the ordering. +
        + +

        Change 25.3.3.3 [lib.equal.range] paragraph 1 from:

        + +
        + -1- Requires: Type T is LessThanComparable + (lib.lessthancomparable). +
        + +

        to:

        + +
        + -1- Requires: The elements e of [first, last) are partitioned with + respect to the expressions e < value and !(value < e) or + comp(e, value) and !comp(value, e). +
        + +

        + Optionally add the following to the end of the proposed text above, + which allows library implementors to make a small optimization at the + cost of slightly complexifying the standard text. The idea is that we + want to ensure that the partition point which defines the upper_bound + is no earlier in the sequence than the partion point which defines the + lower_bound, so that the implementor can do one of the searches over a + subrange: +

        + +
        + Also, for all elements e of [first, last), e < value implies + !(value < e) or comp(e, value) implies !comp(value, e) +
        + +

        Note also that if we don't add the above, the result of + equal_range() might be an invalid range.

        + + +

        Change 25.3.3.3 [lib.equal.range] paragraph 2 from:

        + +
        + -2- Effects: Finds the largest subrange [i, j) such that the value + can be inserted at any iterator k in it without violating the + ordering. k satisfies the corresponding conditions: !(*k < value) + && !(value < *k) or comp(*k, value) == false && comp(value, *k) == + false. +
        + +

        to:

        + +
        +    -2- Returns: 
        +          make_pair(lower_bound(first, last, value),
        +                    upper_bound(first, last, value))
        +        or
        +          make_pair(lower_bound(first, last, value, comp),
        +                    upper_bound(first, last, value, comp))
        + 
        + +

        + Note that the original text did not say whether the first element of + the return value was the beginning or end of the range, or something + else altogether. The proposed text is both more precise and general + enough to accomodate heterogeneous comparisons. +

        + +

        Change 25.3.3.3 [lib.binary.search] paragraph 1 from:

        + +
        + -1- Requires: Type T is LessThanComparable + (lib.lessthancomparable). +
        + +

        to:

        + +
        + -1- Requires: The elements e of [first, last) are partitioned with + respect to the expressions e < value and !(value < e) or comp(e, + value) and !comp(value, e). Also, for all elements e of [first, + last), e < value implies !(value < e) or comp(e, value) implies + !comp(value, e) +
        + +

        [Dave Abrahams provided this wording]

        + +
        +

        271. basic_iostream missing typedefs

        + Section: 27.6.1.5 [lib.iostreamclass]  Status: Ready  Submitter: Martin Sebor  Date: 02 Nov 2000

        +

        + Class template basic_iostream has no typedefs. The typedefs it + inherits from its base classes can't be used, since (for example) + basic_iostream<T>::traits_type is ambiguous. +

        +

        Proposed resolution:

        + +

        Add the following to basic_iostream's class synopsis in + 27.6.1.5 , immediately after public:

        + +
        +   // types:
        +   typedef charT                     char_type;
        +   typedef typename traits::int_type int_type;
        +   typedef typename traits::pos_type pos_type;
        +   typedef typename traits::off_type off_type;
        +   typedef traits                    traits_type;
        + 
        +
        +

        272. Missing parentheses around subexpression

        + Section: 27.4.4.3 [lib.iostate.flags]  Status: Ready  Submitter: Martin Sebor  Date: 02 Nov 2000

        +

        + 27.4.4.3, p4 says about the postcondition of the function: If + rdbuf()!=0 then state == rdstate(); otherwise + rdstate()==state|ios_base::badbit. +

        + +

        + The expression on the right-hand-side of the operator==() needs to be + parenthesized in order for the whole expression to ever evaluate to + anything but non-zero. +

        +

        Proposed resolution:

        +

        + Add parentheses like so: rdstate()==(state|ios_base::badbit). +

        +
        +

        273. Missing ios_base qualification on members of a dependent class

        + Section: 27 [lib.input.output]  Status: Ready  Submitter: Martin Sebor  Date: 02 Nov 2000

        +

        27.5.2.4.2, p4, and 27.8.1.6, p2, 27.8.1.7, p3, 27.8.1.9, p2, + 27.8.1.10, p3 refer to in and/or out w/o ios_base:: qualification. + That's incorrect since the names are members of a dependent base + class (14.6.2 [temp.dep]) and thus not visible.

        +

        Proposed resolution:

        +

        Qualify the names with the name of the class of which they are + members, i.e., ios_base.

        +
        +

        274. a missing/impossible allocator requirement

        + Section: 20.1.5 [lib.allocator.requirements]  Status: Review  Submitter: Martin Sebor  Date: 02 Nov 2000

        +

        + I see that table 31 in 20.1.5, p3 allows T in std::allocator<T> to be of + any type. But the synopsis in 20.4.1 calls for allocator<>::address() to + be overloaded on reference and const_reference, which is ill-formed for + all T = const U. In other words, this won't work: +

        + +

        + template class std::allocator<const int>; +

        + +

        + The obvious solution is to disallow specializations of allocators on + const types. However, while containers' elements are required to be + assignable (which rules out specializations on const T's), I think that + allocators might perhaps be potentially useful for const values in other + contexts. So if allocators are to allow const types a partial + specialization of std::allocator<const T> would probably have to be + provided. +

        +

        Proposed resolution:

        +

        Change the text in row 1, column 2 of table 32 in 20.1.5, p3 from

        + +
        + any type +
        + +

        to

        +
        + any non-const, non-volatile, non-reference type +
        +

        Rationale:

        +

        + Two resolutions were originally proposed: one that partially + specialized std::allocator for const types, and one that said an + allocator's value type may not be const. The LWG chose the second. + The first wouldn't be appropriate, because allocators are intended for + use by containers, and const value types don't work in containers. + Encouraging the use of allocators with const value types would only + lead to unsafe code. +

        +

        + The original text for proposed resolution 2 was modified so that it + also forbids volatile types and reference types. +

        +
        +

        275. Wrong type in num_get::get() overloads

        + Section: 22.2.2.1.1 [lib.facet.num.get.members]  Status: Ready  Submitter: Matt Austern  Date: 02 Nov 2000

        +

        + In 22.2.2.1.1, we have a list of overloads for num_get<>::get(). + There are eight overloads, all of which are identical except for the + last parameter. The overloads are: +

        +
          +
        • long&
        • +
        • unsigned short&
        • +
        • unsigned int&
        • +
        • unsigned long&
        • +
        • short&
        • +
        • double&
        • +
        • long double&
        • +
        • void*&
        • +
        + +

        + There is a similar list, in 22.2.2.1.2, of overloads for + num_get<>::do_get(). In this list, the last parameter has + the types: +

        +
          +
        • long&
        • +
        • unsigned short&
        • +
        • unsigned int&
        • +
        • unsigned long&
        • +
        • float&
        • +
        • double&
        • +
        • long double&
        • +
        • void*&
        • +
        + +

        + These two lists are not identical. They should be, since + get is supposed to call do_get with exactly + the arguments it was given. +

        +

        Proposed resolution:

        +

        In 22.2.2.1.1 , change

        +
        +   iter_type get(iter_type in, iter_type end, ios_base& str,
        +                 ios_base::iostate& err, short& val) const;
        + 
        +

        to

        +
        +   iter_type get(iter_type in, iter_type end, ios_base& str,
        +                 ios_base::iostate& err, float& val) const;
        + 
        +
        +

        276. Assignable requirement for container value type overly strict

        + Section: 23.1 [lib.container.requirements]  Status: Review  Submitter: Peter Dimov  Date: 07 Nov 2000

        +

        + 23.1/3 states that the objects stored in a container must be + Assignable. 23.3.1 , paragraph 2, + states that map satisfies all requirements for a container, while in + the same time defining value_type as pair<const Key, T> - a type + that is not Assignable. +

        + +

        + It should be noted that there exists a valid and non-contradictory + interpretation of the current text. The wording in 23.1/3 avoids + mentioning value_type, referring instead to "objects stored in a + container." One might argue that map does not store objects of + type map::value_type, but of map::mapped_type instead, and that the + Assignable requirement applies to map::mapped_type, not + map::value_type. +

        + +

        + However, this makes map a special case (other containers store objects of + type value_type) and the Assignable requirement is needlessly restrictive in + general. +

        + +

        + For example, the proposed resolution of active library issue + 103 is to make set::iterator a constant iterator; this + means that no set operations can exploit the fact that the stored + objects are Assignable. +

        + +

        + This is related to, but slightly broader than, closed issue + 140. +

        +

        Proposed resolution:

        +

        23.1/3: Strike the trailing part of the sentence:

        +
        + , and the additional requirements of Assignable types from 23.1/3 +
        +

        so that it reads:

        +
        + -3- The type of objects stored in these components must meet the + requirements of CopyConstructible types (lib.copyconstructible). +
        + +

        23.1/4: Modify to make clear that this requirement is not for all + containers. Change to:

        + +
        + -4- Table 64 defines the Assignable requirement. Some containers + require this property of the types to be stored in the container. T is + the type used to instantiate the container. t is a value of T, and u is + a value of (possibly const) T. +
        + +

        23.1, Table 65: in the first row, change "T is Assignable" to "T is + CopyConstructible".

        + +

        23.2.1/2: Add sentence for Assignable requirement. Change to:

        + +
        + -2- A deque satisfies all of the requirements of a container and of a + reversible container (given in tables in lib.container.requirements) and + of a sequence, including the optional sequence requirements + (lib.sequence.reqmts). In addition to the requirements on the stored + object described in 23.1[lib.container.requirements], the stored object + must also meet the requirements of Assignable. Descriptions are + provided here only for operations on deque that are not described in one + of these tables or for operations where there is additional semantic + information. +
        + +

        23.2.2/2: Add Assignable requirement to specific methods of list. + Change to:

        + +
        +

        -2- A list satisfies all of the requirements of a container and of a + reversible container (given in two tables in lib.container.requirements) + and of a sequence, including most of the the optional sequence + requirements (lib.sequence.reqmts). The exceptions are the operator[] + and at member functions, which are not provided. + + [Footnote: These member functions are only provided by containers whose + iterators are random access iterators. --- end foonote] +

        + +

        list does not require the stored type T to be Assignable unless the + following methods are instantiated: + + [Footnote: Implementors are permitted but not required to take advantage + of T's Assignable properties for these methods. -- end foonote] +

        +
        +      list<T,Allocator>& operator=(const list<T,Allocator>&  x );
        +      template <class InputIterator>
        +        void assign(InputIterator first, InputIterator last);
        +      void assign(size_type n, const T& t);
        + 
        + + +

        Descriptions are provided here only for operations on list that are not + described in one of these tables or for operations where there is + additional semantic information.

        +
        + +

        23.2.4/2: Add sentence for Assignable requirement. Change to:

        + +
        + -2- A vector satisfies all of the requirements of a container and of a + reversible container (given in two tables in lib.container.requirements) + and of a sequence, including most of the optional sequence requirements + (lib.sequence.reqmts). The exceptions are the push_front and pop_front + member functions, which are not provided. In addition to the + requirements on the stored object described in + 23.1[lib.container.requirements], the stored object must also meet the + requirements of Assignable. Descriptions are provided here only for + operations on vector that are not described in one of these tables or + for operations where there is additional semantic information. +
        +

        Rationale:

        +

        list, set, multiset, map, multimap are able to store non-Assignables. + However, there is some concern about list<T>: + although in general there's no reason for T to be Assignable, some + implementations of the member functions operator= and + assign do rely on that requirement. The LWG does not want + to forbid such implementations.

        + +

        Note that the type stored in a standard container must still satisfy + the requirements of the container's allocator; this rules out, for + example, such types as "const int". See issue 274 + for more details. +

        + +
        +

        278. What does iterator validity mean?

        + Section: 23.2.2.4 [lib.list.ops]  Status: Review  Submitter: P.J. Plauger  Date: 27 Nov 2000

        +

        + Section 23.2.2.4 [lib.list.ops] states that +

        +
        +   void splice(iterator position, list<T, Allocator>& x);
        + 
        +

        + invalidates all iterators and references to list x. +

        + +

        + But what does the C++ Standard mean by "invalidate"? You + can still dereference the iterator to a spliced list element, but + you'd better not use it to delimit a range within the original + list. For the latter operation, it has definitely lost some of its + validity. +

        + +

        + If we accept the proposed resolution to issue 250, + then we'd better clarify that a "valid" iterator need no + longer designate an element within the same container as it once did. + We then have to clarify what we mean by invalidating a past-the-end + iterator, as when a vector or string grows by reallocation. Clearly, + such an iterator has a different kind of validity. Perhaps we should + introduce separate terms for the two kinds of "validity." +

        +

        Proposed resolution:

        +

        Add the following text to the end of section 24.1 , + after paragraph 5:

        +
        + Invalidating an iterator means modifying it such that + it may have a singular value. [Footnote: This definition applies to + pointers, since pointers are iterators. The effect of dereferencing + an iterator that has been invalidated is undefined.] +
        + +

        [post-Copenhagen: Matt provided wording.]

        + +
        +

        280. Comparison of reverse_iterator to const reverse_iterator

        + Section: 24.4.1 [lib.reverse.iterators]  Status: Open  Submitter: Steve Cleary  Date: 27 Nov 2000

        +

        + This came from an email from Steve Cleary to Fergus in reference to + issue 179. The library working group briefly discussed + this in Toronto and believed it should be a separate issue. There was + also some reservations about whether this was a worthwhile problem to + fix. +

        + +

        + Steve said: "Fixing reverse_iterator. std::reverse_iterator can + (and should) be changed to preserve these additional + requirements." He also said in email that it can be done without + breaking user's code: "If you take a look at my suggested + solution, reverse_iterator doesn't have to take two parameters; there + is no danger of breaking existing code, except someone taking the + address of one of the reverse_iterator global operator functions, and + I have to doubt if anyone has ever done that. . . But, just in + case they have, you can leave the old global functions in as well -- + they won't interfere with the two-template-argument functions. With + that, I don't see how any user code could break." +

        +

        Proposed resolution:

        +

        + Section: 24.4.1.1 + add/change the following declarations:

        +
        +   A) Add a templated assignment operator, after the same manner
        +         as the templated copy constructor, i.e.:
        + 
        +   template < class U >
        +   reverse_iterator < Iterator >& operator=(const reverse_iterator< U >& u);
        + 
        +   B) Make all global functions (except the operator+) have
        +   two template parameters instead of one, that is, for
        +   operator ==, !=, <, >, <=, >=, - replace:
        + 
        +        template < class Iterator >
        +        typename reverse_iterator< Iterator >::difference_type operator-(
        +                  const reverse_iterator< Iterator >& x,
        +                  const reverse_iterator< Iterator >& y);
        + 
        +   with:
        + 
        +       template < class Iterator1, class Iterator2 >
        +       typename reverse_iterator < Iterator1 >::difference_type operator-(
        +                  const reverse_iterator < Iterator1 > & x,
        +                  const reverse_iterator < Iterator2 > & y);
        + 
        +

        + Also make the addition/changes for these signatures in + 24.4.1.3 . +

        + +

        [ + Copenhagen: The LWG is concerned that the proposed resolution + introduces new overloads. Experience shows that introducing + overloads is always risky, and that it would be inappropriate to + make this change without implementation experience. It may be + desirable to provide this feature in a different way. + ]

        + +
        +

        281. std::min() and max() requirements overly restrictive

        + Section: 25.3.7 [lib.alg.min.max]  Status: Ready  Submitter: Martin Sebor  Date: 02 Dec 2000

        +

        The requirements in 25.3.7, p1 and 4 call for T to satisfy the + requirements of LessThanComparable (20.1.2 ) + and CopyConstructible (20.1.3 ). + Since the functions take and return their arguments and result by + const reference, I believe the CopyConstructible requirement + is unnecessary. +

        +

        Proposed resolution:

        +

        Remove the CopyConstructible requirement. Specifically, replace + 25.3.7, p1 with

        +

        + -1- Requires: Type T is LessThanComparable + (20.1.2 ). +

        +

        and replace 25.3.7, p4 with

        +

        + -4- Requires: Type T is LessThanComparable + (20.1.2 ). +

        +
        +

        282. What types does numpunct grouping refer to?

        + Section: 22.2.2.2.2 [lib.facet.num.put.virtuals]  Status: Open  Submitter: Howard Hinnant  Date: 5 Dec 2000

        +

        + Paragraph 16 mistakenly singles out integral types for inserting + thousands_sep() characters. This conflicts with the syntax for floating + point numbers described under 22.2.3.1/2. +

        +

        Proposed resolution:

        +

        Change paragraph 16 from:

        + +
        + For integral types, punct.thousands_sep() characters are inserted into + the sequence as determined by the value returned by punct.do_grouping() + using the method described in 22.2.3.1.2 . +
        + +

        To:

        + +
        + For arithmetic types, punct.thousands_sep() characters are inserted into + the sequence as determined by the value returned by punct.do_grouping() + using the method described in 22.2.3.1.2 . +
        + +

        [ + Copenhagen: Opinions were divided about whether this is actually an + inconsistency, but at best it seems to have been unintentional. This + is only an issue for floating-point output: The standard is + unambiguous that implementations must parse thousands_sep characters + when performing floating-point. The standard is also unambiguous that + this requirement does not apply to the "C" locale. + ]

        + +

        [ + A survey of existing practice is needed; it is believed that some + implementations do insert thousands_sep characters for floating-point + output and others doing. + ]

        + +
        +

        283. std::replace() requirement incorrect/insufficient

        + Section: 25.2.4 [lib.alg.replace]  Status: Open  Submitter: Martin Sebor  Date: 15 Dec 2000

        +

        + The requirements in 25.2.4 , p1 that T to be + Assignable (23.1 ) is not necessary or + sufficient for either of the algorithms. The algorithms require that + std::iterator_traits<ForwardIterator>::value_type be + Assignable and that both + std::iterator_traits<ForwardIterator>::value_type and be + EqualityComparable (20.1.1 ) with respect to + one another. +

        + +

        + Note that a similar problem occurs in several other places in section + 25 as well (e.g., 25.1.6 , or 25.2.5 ) so + what really needs to happen is for all those places to be identified + and corrected. The proposed resolution below addresses only 25.2.4. +

        +

        Proposed resolution:

        +

        Change 25.2.4, p1 from

        + +
        + -1- Requires:Type T is Assignable + (23.1 ) (and, for replace(), + EqualityComparable (20.1.1 )). +
        + +

        to

        + +
        + -1- Requires:Type + std::iterator_traits<ForwardIterator>::value_type + is Assignable (23.1 ), the type T is + convertible tostd::iterator_traits<ForwardIterator>::value_type, + (and, for replace(), types + std::iterator_traits<ForwardIterator>::value_type and + T are EqualityComparable (20.1.1 ) + with respect to one another). +
        + +

        [ + The LWG agrees with the general idea of the proposed resolution, but + not with the specific wording. (There is no definition in the + standard of what it means for one type to be EqualityComparable to + another.) Jeremy will provide new wording, and will review clause 25 + for similar issues. + ]

        + +
        +

        284. unportable example in 20.3.7, p6

        + Section: 20.3.7 [lib.function.pointer.adaptors]  Status: Ready  Submitter: Martin Sebor  Date: 26 Dec 2000

        +

        The example in 20.3.7 , p6 shows how to use the C + library function strcmp() with the function pointer adapter + ptr_fun(). But since it's unspecified whether the C library + functions have extern "C" or extern + "C++" linkage [17.4.2.2 ], and since + function pointers with different the language linkage specifications + (7.5 ) are incompatible, whether this example is + well-formed is unspecified. +

        +

        Proposed resolution:

        +

        Replace the code snippet in the following text

        +
        +

        + -6- [Example: +

        +
        +     replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(strcmp), "C")), "C++");
        +   
        +
        + + +

        with

        +
        +

        + -6- [Example: +

        +
        +     int compare(const char*, const char*);
        +     replace_if(v.begin(), v.end(), not1(bind2nd(ptr_fun(compare), "abc")), "def");
        +   
        +
        + +

        [Copenhagen: Minor change in the proposed resolution. Since this + issue deals in part with C and C++ linkage, it was believed to be too + confusing for the strings in the example to be "C" and "C++". + ]

        +
        +

        285. minor editorial errors in fstream ctors

        + Section: 27.8.1.6 [lib.ifstream.cons]  Status: Ready  Submitter: Martin Sebor  Date: 31 Dec 2000

        +

        27.8.1.6 , p2, 27.8.1.9 , p2, and + 27.8.1.12 , p2 say about the effects of each constructor: + [lib.ifstream.cons] +

        + +

        ... If that function returns a null pointer, calls + setstate(failbit) (which may throw ios_base::failure). +

        + +

        The parenthetical note doesn't apply since the ctors cannot throw an + exception due to the requirement in 27.4.4.1 , p3 + that exceptions() be initialized to ios_base::goodbit. +

        +

        Proposed resolution:

        +

        + Strike the parenthetical note from the Effects clause in each of the + paragraphs mentioned above. +

        +
        +

        286. <cstdlib> requirements missing size_t typedef

        + Section: 25.4 [lib.alg.c.library]  Status: Ready  Submitter: Judy Ward  Date: 30 Dec 2000

        +

        + The <cstdlib> header file contains prototypes for bsearch and + qsort (C++ Standard section 25.4 paragraphs 3 and 4) and other + prototypes (C++ Standard section 21.4 paragraph 1 table 49) that + require the typedef size_t. Yet size_t is not listed in the + <cstdlib> synopsis table 78 in section 25.4. +

        +

        Proposed resolution:

        +

        + Add the type size_t to Table 78 (section 25.4) and add + the type size_t <cstdlib> to Table 97 (section C.2). +

        +

        Rationale:

        +

        Since size_t is in <stdlib.h>, it must also be in <cstdlib>.

        +
        +

        288. <cerrno> requirements missing macro EILSEQ

        + Section: 19.3 [lib.errno]  Status: Ready  Submitter: Judy Ward  Date: 30 Dec 2000

        +

        + ISO/IEC 9899:1990/Amendment1:1994 Section 4.3 States: "The list + of macros defined in <errno.h> is adjusted to include a new + macro, EILSEQ" +

        + +

        + ISO/IEC 14882:1998(E) section 19.3 does not refer + to the above amendment. +

        + +

        Proposed resolution:

        +

        + Update Table 26 (section 19.3) "Header <cerrno> synopsis" + and Table 95 (section C.2) "Standard Macros" to include EILSEQ. +

        +
        +

        290. Requirements to for_each and its function object

        + Section: 25.1.1 [lib.alg.foreach]  Status: Open  Submitter: Angelika Langer  Date: 03 Jan 2001

        +

        The specification of the for_each algorithm does not have a + "Requires" section, which means that there are no + restrictions imposed on the function object whatsoever. In essence it + means that I can provide any function object with arbitrary side + effects and I can still expect a predictable result. In particular I + can expect that the function object is applied exactly last - first + times, which is promised in the "Complexity" section. +

        + +

        I don't see how any implementation can give such a guarantee + without imposing requirements on the function object. +

        + +

        Just as an example: consider a function object that removes + elements from the input sequence. In that case, what does the + complexity guarantee (applies f exactly last - first times) mean? +

        + +

        One can argue that this is obviously a nonsensical application and + a theoretical case, which unfortunately it isn't. I have seen + programmers shooting themselves in the foot this way, and they did not + understand that there are restrictions even if the description of the + algorithm does not say so. +

        +

        Proposed resolution:

        +

        Add a "Requires" section to section 25.1.1 similar to those + proposed for transform and the numeric algorithms (see issue + 242): +

        + +
        + -2- Requires: In the range [first, last], f shall not invalidate + iterators or subranges. +
        + +

        [Copenhagen: The LWG agrees that a function object passed to an + algorithm should not invalidate iterators in the range that the + algorithm is operating on. The LWG believes that this should be a + blanket statement in Clause 25, not just a special requirement for + for_each. + ]

        + +
        +

        291. Underspecification of set algorithms

        + Section: 25.3.5 [lib.alg.set.operations]  Status: Open  Submitter: Matt Austern  Date: 03 Jan 2001

        +

        + The standard library contains four algorithms that compute set + operations on sorted ranges: set_union, set_intersection, + set_difference, and set_symmetric_difference. Each + of these algorithms takes two sorted ranges as inputs, and writes the + output of the appropriate set operation to an output range. The elements + in the output range are sorted. +

        + +

        + The ordinary mathematical definitions are generalized so that they + apply to ranges containing multiple copies of a given element. Two + elements are considered to be "the same" if, according to an + ordering relation provided by the user, neither one is less than the + other. So, for example, if one input range contains five copies of an + element and another contains three, the output range of set_union + will contain five copies, the output range of + set_intersection will contain three, the output range of + set_difference will contain two, and the output range of + set_symmetric_difference will contain two. +

        + +

        + Because two elements can be "the same" for the purposes + of these set algorithms, without being identical in other respects + (consider, for example, strings under case-insensitive comparison), + this raises a number of unanswered questions: +

        + +
          +
        • If we're copying an element that's present in both of the + input ranges, which one do we copy it from?
        • +
        • If there are n copies of an element in the relevant + input range, and the output range will contain fewer copies (say + m) which ones do we choose? The first m, or the last + m, or something else?
        • +
        • Are these operations stable? That is, does a run of equivalent + elements appear in the output range in the same order as as it + appeared in the input range(s)?
        • +
        + +

        + The standard should either answer these questions, or explicitly + say that the answers are unspecified. I prefer the former option, + since, as far as I know, all existing implementations behave the + same way. +

        + +

        Proposed resolution:

        +

        [The LWG agrees that the standard should answer these questions. + Matt will provide wording.]

        +
        +

        292. effects of a.copyfmt (a)

        + Section: 27.4.4.2 [lib.basic.ios.members]  Status: Ready  Submitter: Martin Sebor  Date: 05 Jan 2001

        +

        The Effects clause of the member function copyfmt() in + 27.4.4.2, p15 doesn't consider the case where the left-hand side + argument is identical to the argument on the right-hand side, that is + (this == &rhs). If the two arguments are identical there + is no need to copy any of the data members or call any callbacks + registered with register_callback(). Also, as Howard Hinnant + points out in message c++std-lib-8149 it appears to be incorrect to + allow the object to fire erase_event followed by + copyfmt_event since the callback handling the latter event + may inadvertently attempt to access memory freed by the former. +

        +

        Proposed resolution:

        +

        Change the Effects clause in 27.4.4.2, p15 from

        + +
        + -15- Effects:Assigns to the member objects of *this + the corresponding member objects of rhs, except that... +
        + +

        to

        + +
        + -15- Effects:If (this == &rhs) does nothing. Otherwise + assigns to the member objects of *this the corresponding member + objects of rhs, except that... +
        +
        +

        294. User defined macros and standard headers

        + Section: 17.4.3.1.1 [lib.macro.names]  Status: Open  Submitter: James Kanze  Date: 11 Jan 2001

        +

        Paragraph 2 of 17.4.3.1.1 reads: "A + translation unit that includes a header shall not contain any macros + that define names declared in that header." As I read this, it + would mean that the following program is legal:

        + +
        +   #define npos 3.14
        +   #include <sstream>
        + 
        + +

        since npos is not defined in <sstream>. It is, however, defined + in <string>, and it is hard to imagine an implementation in + which <sstream> didn't include <string>.

        + +

        I think that this phrase was probably formulated before it was + decided that a standard header may freely include other standard + headers. The phrase would be perfectly appropriate for C, for + example. In light of 17.4.4.1 paragraph 1, however, + it isn't stringent enough.

        +

        Proposed resolution:

        +

        In paragraph 2 of 17.4.3.1.1 , change "A + translation unit that includes a header shall not contain any macros + that define names declared in that header." to "A + translation unit that includes a header shall not contain any macros + that define names declared in any standard header."

        + +

        [Copenhagen: the general idea is clearly correct, but there is + concern about making sure that the two paragraphs in 17.4.3.1.1 remain consistent. Nathan will provide new + wording.]

        + +
        +

        295. Is abs defined in <cmath>?

        + Section: 26.5 [lib.c.math]  Status: Ready  Submitter: Jens Maurer  Date: 12 Jan 2001

        +

        + Table 80 lists the contents of the <cmath> header. It does not + list abs(). However, 26.5, paragraph 6, which lists added + signatures present in <cmath>, does say that several overloads + of abs() should be defined in <cmath>. +

        +

        Proposed resolution:

        +

        + Add abs to Table 80. Also, remove the parenthetical list + of functions "(abs(), div(), rand(), srand())" from 26.5 , + paragraph 1. +

        + +

        [Copenhagen: Modified proposed resolution so that it also gets + rid of that vestigial list of functions in paragraph 1.]

        + +
        +

        296. Missing descriptions and requirements of pair operators

        + Section: 20.2.2 [lib.pairs]  Status: Review  Submitter: Martin Sebor  Date: 14 Jan 2001

        +

        The synopsis of the header <utility> in 20.2 + lists the complete set of equality and relational operators for pair + but the section describing the template and the operators only describes + operator==() and operator<(), and it fails to mention + any requirements on the template arguments. The remaining operators are + not mentioned at all. +

        +

        Proposed resolution:

        + +

        Add the following after 20.2.2 , paragraph 5:

        + +
        +
        + template <class T1, class T2> +
        bool operator!=(const pair<T1, T2>& x, const pair<T1, + T2>& y); +
        + +

        + Requires: Types T1 and T2 are + EqualityComparable (20.1.1 ).

        + +

        + Returns: !(x == y).

        +
        + +

        Add the following after 20.2.2 , paragraph 6:

        + +
        +
        + template <class T1, class T2> +
        bool operator>(const pair<T1, T2>& x, const pair<T1, T2>& y); +
        + +

        + Requires: Types T1 and T2 are + LessThanComparable (20.1.2 ).

        + +

        + Returns: y < x.

        + +
        + template <class T1, class T2> +
        bool operator<=(const pair<T1, T2>& x, const pair<T1, T2>& y); +
        + +

        + Requires: Types T1 and T2 are + LessThanComparable (20.1.2 ).

        + +

        + Returns: !(y < x).

        + +
        + template <class T1, class T2> +
        bool operator>=(const pair<T1, T2>& x, const pair<T1, T2>& y); +
        + +

        + Requires: Types T1 and T2 are + LessThanComparable (20.1.2 ).

        + +

        + Returns: !(x < y).

        +
        + +

        [post-Copenhagen: modified proposed resolution so that it does + not create a new section 20.2.2.1. That would violate ISO rules: we + cannot have 20.2.2.1 unless we also have 20.2.2.2.]

        + +
        +

        297. const_mem_fun_t<>::argument_type should be const T*

        + Section: 20.3.8 [lib.member.pointer.adaptors]  Status: Ready  Submitter: Martin Sebor  Date: 6 Jan 2001

        +

        The class templates const_mem_fun_t in 20.3.8, p8 and + const_mem_fun1_t + in 20.3.8, p9 derive from unary_function<T*, S>, and + binary_function<T*, + A, S>, respectively. Consequently, their argument_type, and + first_argument_type + members, respectively, are both defined to be T* (non-const). + However, their function call member operator takes a const T* + argument. It is my opinion that argument_type should be const + T* instead, so that one can easily refer to it in generic code. The + example below derived from existing code fails to compile due to the + discrepancy: +

        + +

        + template <class T> +
        void foo (typename T::argument_type arg)   // #1 +
        { +
            typename T::result_type (T::*pf) (typename + T::argument_type) + const =   // #2 +
                &T::operator(); +
        } +

        + +

        struct X { /* ... */ };

        + +

        + int main () +
        { +
            const X x; +
            foo<std::const_mem_fun_t<void, X> + >(&x);   + // #3 +
        } +

        + +

        #1 foo() takes a plain unqualified X* as an argument +
        #2 the type of the pointer is incompatible with the type of the member + function +
        #3 the address of a constant being passed to a function taking a non-const + X* +

        +

        Proposed resolution:

        +

        Replace the top portion of the definition of the class template + const_mem_fun_t in 20.3.8, p8 +

        +

        + template <class S, class T> class const_mem_fun_t +
                  : public + unary_function<T*, S> { +

        +

        with

        +

        + template <class S, class T> class const_mem_fun_t +
                  : public + unary_function<const T*, S> { +

        +

        Also replace the top portion of the definition of the class template + const_mem_fun1_t in 20.3.8, p9

        +

        + template <class S, class T, class A> class const_mem_fun1_t +
                  : public + binary_function<T*, A, S> { +

        +

        with

        +

        + template <class S, class T, class A> class const_mem_fun1_t +
                  : public + binary_function<const T*, A, S> { +

        +

        Rationale:

        +

        This is simply a contradiction: the argument_type typedef, + and the argument type itself, are not the same.

        +
        +

        298. ::operator delete[] requirement incorrect/insufficient

        + Section: 18.4.1.2 [lib.new.delete.array]  Status: Ready  Submitter: John A. Pedretti  Date: 10 Jan 2001

        +

        + The default behavior of operator delete[] described in 18.4.1.2, p12 - + namely that for non-null value of ptr, the operator reclaims storage + allocated by the earlier call to the default operator new[] - is not + correct in all cases. Since the specified operator new[] default + behavior is to call operator new (18.4.1.2, p4, p8), which can be + replaced, along with operator delete, by the user, to implement their + own memory management, the specified default behavior of operator + delete[] must be to call operator delete. +

        +

        Proposed resolution:

        +

        Change 18.4.1.2, p12 from

        +
        + -12- Default behavior: +
          +
        • + For a null value of ptr , does nothing. +
        • +
        • + Any other value of ptr shall be a value returned + earlier by a call to the default operator new[](std::size_t). + [Footnote: The value must not have been invalidated by an intervening + call to operator delete[](void*) (17.4.3.7 ). + --- end footnote] + For such a non-null value of ptr , reclaims storage + allocated by the earlier call to the default operator new[]. +
        • +
        +
        + +

        to

        + +
        + -12- Default behavior: Calls operator + delete(ptr) + or operator delete(ptr, std::nothrow) respectively. +
        +

        and expunge paragraph 13.

        +
        +

        299. Incorrect return types for iterator dereference

        + Section: 24.1.4 [lib.bidirectional.iterators], 24.1.5 [lib.random.access.iterators]  Status: Open  Submitter: John Potter  Date: 22 Jan 2001

        +

        + In section 24.1.4 , + Table 75 gives the return type of *r-- as convertible to T. This is + not consistent with Table 74 which gives the return type of *r++ as + T&. *r++ = t is valid while *r-- = t is invalid. +

        + +

        + In section 24.1.5 , + Table 76 gives the return type of a[n] as convertible to T. This is + not consistent with the semantics of *(a + n) which returns T& by + Table 74. *(a + n) = t is valid while a[n] = t is invalid. +

        + +

        + Discussion from the Copenhagen meeting: the first part is + uncontroversial. The second part, operator[] for Random Access + Iterators, requires more thought. There are reasonable arguments on + both sides. Return by value from operator[] enables some potentially + useful iterators, e.g. a random access "iota iterator" (a.k.a + "counting iterator" or "int iterator"). There isn't any obvious way + to do this with return-by-reference, since the reference would be to a + temporary. On the other hand, reverse_iterator takes an + arbitrary Random Access Iterator as template argument, and its + operator[] returns by reference. If we decided that the return type + in Table 76 was correct, we would have to change + reverse_iterator. This change would probably affect user + code. +

        + +

        + History: the contradiction between reverse_iterator and the + Random Access Iterator requirements has been present from an early + stage. In both the STL proposal adopted by the committee + (N0527==94-0140) and the STL technical report (HPL-95-11 (R.1), by + Stepanov and Lee), the Random Access Iterator requirements say that + operator[]'s return value is "convertible to T". In N0527 + reverse_iterator's operator[] returns by value, but in HPL-95-11 + (R.1), and in the STL implementation that HP released to the public, + reverse_iterator's operator[] returns by reference. In 1995, the + standard was amended to reflect the contents of HPL-95-11 (R.1). The + original intent for operator[] is unclear. +

        + +

        + In the long term it may be desirable to add more fine-grained + iterator requirements, so that access method and traversal strategy + can be decoupled. (See "Improved Iterator Categories and + Requirements", N1297 = 01-0011, by Jeremy Siek.) Any decisions + about issue 299 should keep this possibility in mind. +

        + +

        Proposed resolution:

        +

        In section 24.1.4 , change the return type in table + 75 from "convertible to T" to T&.

        + +

        In section 24.1.5 , change the return type in table + 76 from "convertible to T" to T&.

        + +
        +

        300. list::merge() specification incomplete

        + Section: 23.2.2.4 [lib.list.ops]  Status: Open  Submitter: John Pedretti  Date: 23 Jan 2001

        +

        + The "Effects" clause for list::merge() (23.2.2.4, p23) + appears to be incomplete: it doesn't cover the case where the argument + list is identical to *this (i.e., this == &x). The requirement in the + note in p24 (below) is that x be empty after the merge which is surely + unintended in this case. +

        +

        Proposed resolution:

        +

        + Change 23.2.2.4, p23 to: +

        +
        + Effects: If &x == this, does nothing; otherwise, merges the + argument list into the list. +
        + +

        [Copenhagen: The proposed resolution does not fix all of the + problems in 23.2.2.4 , p22-25. Three different + paragraphs (23, 24, 25) describe the effects of merge. + Changing p23, without changing the other two, appears to introduce + contradictions. Additionally, "merges the argument list into the + list" is excessively vague.]

        + +
        +

        301. basic_string template ctor effects clause omits allocator argument

        + Section: 21.3.1 [lib.string.cons]  Status: Ready  Submitter: Martin Sebor  Date: 27 Jan 2001

        +

        + The effects clause for the basic_string template ctor in 21.3.1, p15 + leaves out the third argument of type Allocator. I believe this to be + a mistake. +

        +

        Proposed resolution:

        +

        Replace

        + +
        +

        + -15- Effects: If InputIterator is an integral + type, equivalent to

        + +
        basic_string(static_cast<size_type>(begin), + static_cast<value_type>(end))
        +
        + +

        with

        + +
        +

        + -15- Effects: If InputIterator is an integral + type, equivalent to

        + +
        basic_string(static_cast<size_type>(begin), + static_cast<value_type>(end), a)
        +
        +
        +

        303. Bitset input operator underspecified

        + Section: 23.3.5.3 [lib.bitset.operators]  Status: Ready  Submitter: Matt Austern  Date: 5 Feb 2001

        +

        + In 23.3.5.3, we are told that bitset's input operator + "Extracts up to N (single-byte) characters from + is.", where is is a stream of type + basic_istream<charT, traits>. +

        + +

        + The standard does not say what it means to extract single byte + characters from a stream whose character type, charT, is in + general not a single-byte character type. Existing implementations + differ. +

        + +

        + A reasonable solution will probably involve widen() and/or + narrow(), since they are the supplied mechanism for a single + character between char and arbitrary charT. +

        + +

        Narrowing the input characters is not the same as widening the + literals '0' and '1', because there may be some + locales in which more than one wide character maps to the narrow + character '0'. Narrowing means that alternate + representations may be used for bitset input, widening means that + they may not be.

        + +

        Note that for numeric input, num_get<> + (22.2.2.1.2/8) compares input characters to widened version of narrow + character literals.

        + +

        From Pete Becker, in c++std-lib-8224:

        +
        +

        + Different writing systems can have different representations for the + digits that represent 0 and 1. For example, in the Unicode representation + of the Devanagari script (used in many of the Indic languages) the digit 0 + is 0x0966, and the digit 1 is 0x0967. Calling narrow would translate those + into '0' and '1'. But Unicode also provides the ASCII values 0x0030 and + 0x0031 for for the Latin representations of '0' and '1', as well as code + points for the same numeric values in several other scripts (Tamil has no + character for 0, but does have the digits 1-9), and any of these values + would also be narrowed to '0' and '1'. +

        + +

        ...

        + +

        + It's fairly common to intermix both native and Latin + representations of numbers in a document. So I think the rule has to be + that if a wide character represents a digit whose value is 0 then the bit + should be cleared; if it represents a digit whose value is 1 then the bit + should be set; otherwise throw an exception. So in a Devanagari locale, + both 0x0966 and 0x0030 would clear the bit, and both 0x0967 and 0x0031 + would set it. Widen can't do that. It would pick one of those two values, + and exclude the other one. +

        + +
        + +

        From Jens Maurer, in c++std-lib-8233:

        + +
        +

        + Whatever we decide, I would find it most surprising if + bitset conversion worked differently from int conversion + with regard to alternate local representations of + numbers. +

        + +

        Thus, I think the options are:

        +
          +
        • Have a new defect issue for 22.2.2.1.2/8 so that it will + require the use of narrow().
        • + +
        • Have a defect issue for bitset() which describes clearly + that widen() is to be used.
        • +
        +
        +

        Proposed resolution:

        + +

        Replace the first two sentences of paragraph 5 with:

        + +
        + Extracts up to N characters from is. Stores these + characters in a temporary object str of type + basic_string<charT, traits>, then evaluates the + expression x = bitset<N>(str). +
        + +

        Replace the third bullet item in paragraph 5 with:

        +
        • + the next input character is neither is.widen(0) + nor is.widen(1) (in which case the input character + is not extracted). +
        + +

        Rationale:

        +

        Input for bitset should work the same way as numeric + input. Using widen does mean that alternative digit + representations will not be recognized, but this was a known + consequence of the design choice.

        +
        +

        304. Must *a return an lvalue when a is an input iterator?

        + Section: 24.1 [lib.iterator.requirements]  Status: Open  Submitter: Dave Abrahams  Date: 5 Feb 2001

        +

        + We all "know" that input iterators are allowed to produce + values when dereferenced of which there is no other in-memory copy. +

        + +

        + But: Table 72, with a careful reading, seems to imply that this can only be + the case if the value_type has no members (e.g. is a built-in type). +

        + +

        The problem occurs in the following entry:

        + +
        +   a->m     pre: (*a).m is well-defined
        +            Equivalent to (*a).m
        + 
        + +

        + *a.m can be well-defined if *a is not a reference + type, but since operator->() must return a pointer for + a->m to be well-formed, it needs something to return a + pointer to. This seems to indicate that *a must be + buffered somewhere to make a legal input iterator. +

        + +

        I don't think this was intentional.

        +

        Proposed resolution:

        +

        [Copenhagen: the two obvious possibilities are to keep the + operator-> requirement for Input Iterators, and put + in a non-normative note describing how it can be implemented with + proxies, or else moving the operator-> requirement + from Input Iterator to Forward Iterator. If we do the former + we'll also have to change istreambuf_iterator, because + it has no operator->. A straw poll showed roughly equal + support for the two options.]

        +
        +

        305. Default behavior of codecvt<wchar_t, char, mbstate_t>::length()

        + Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: Review  Submitter: Howard Hinnant  Date: 24 Jan 2001

        +

        22.2.1.5/3 introduces codecvt in part with:

        + +
        + codecvt<wchar_t,char,mbstate_t> converts between the native + character sets for tiny and wide characters. Instantiations on + mbstate_t perform conversion between encodings known to the library + implementor. +
        + +

        But 22.2.1.5.2/10 describes do_length in part with:

        + +
        + ... codecvt<wchar_t, char, mbstate_t> ... return(s) the lesser of max and + (from_end-from). +
        + +

        + The semantics of do_in and do_length are linked. What one does must + be consistent with what the other does. 22.2.1.5/3 leads me to + believe that the vendor is allowed to choose the algorithm that + codecvt<wchar_t,char,mbstate_t>::do_in performs so that it makes + his customers happy on a given platform. But 22.2.1.5.2/10 explicitly + says what codecvt<wchar_t,char,mbstate_t>::do_length must + return. And thus indirectly specifies the algorithm that + codecvt<wchar_t,char,mbstate_t>::do_in must perform. I believe + that this is not what was intended and is a defect. +

        + +

        Discussion from the -lib reflector: + +
        This proposal would have the effect of making the semantics of + all of the virtual functions in codecvt<wchar_t, char, + mbstate_t> implementation specified. Is that what we want, or + do we want to mandate specific behavior for the base class virtuals + and leave the implementation specified behavior for the codecvt_byname + derived class? The tradeoff is that former allows implementors to + write a base class that actually does something useful, while the + latter gives users a way to get known and specified---albeit + useless---behavior, and is consistent with the way the standard + handles other facets. It is not clear what the original intention + was.

        + +

        + Nathan has suggest a compromise: a character that is a widened version + of the characters in the basic execution character set must be + converted to a one-byte sequence, but there is no such requirement + for characters that are not part of the basic execution character set. +

        +

        Proposed resolution:

        +

        Change 22.2.1.5.2/10 from:

        + +
        + -10- Returns: (from_next-from) where from_next is the largest value in + the range [from,from_end] such that the sequence of values in the + range [from,from_next) represents max or fewer valid complete + characters of type internT. The instantiations required in Table 51 + (21.1.1.1.1), namely codecvt<wchar_t, char, mbstate_t> and + codecvt<char, char, mbstate_t>, return the lesser of max and + (from_end-from). +
        + +

        to:

        + +
        + -10- Returns: (from_next-from) where from_next is the largest value in + the range [from,from_end] such that the sequence of values in the range + [from,from_next) represents max or fewer valid complete characters of + type internT. The instantiation codecvt<char, char, mbstate_t> returns + the lesser of max and (from_end-from). +
        + +

        [Copenhagen: straw poll was 3-1 in favor, with many abstentions. + Nathan would like to see more guarantees than are in the proposed + resolution. He will discuss this issue with the other people who + care about it.]

        + +
        +

        306. offsetof macro and non-POD types

        + Section: 18.1 [lib.support.types]  Status: Ready  Submitter: Steve Clamage  Date: 21 Feb 2001

        +

        Spliced together from reflector messages c++std-lib-8294 and -8295:

        + +

        18.1, paragraph 5, reads: "The macro offsetof + accepts a restricted set of type arguments in this + International Standard. type shall be a POD structure or a POD + union (clause 9). The result of applying the offsetof macro to a field + that is a static data member or a function member is + undefined."

        + +

        For the POD requirement, it doesn't say "no diagnostic + required" or "undefined behavior". I read 1.4 , paragraph 1, to mean that a diagnostic is required. + It's not clear whether this requirement was intended. While it's + possible to provide such a diagnostic, the extra complication doesn't + seem to add any value. +

        +

        Proposed resolution:

        +

        Change 18.1, paragraph 5, to "If type is not a POD + structure or a POD union the results are undefined."

        + +

        [Copenhagen: straw poll was 7-4 in favor. It was generally + agreed that requiring a diagnostic was inadvertent, but some LWG + members thought that diagnostics should be required whenever + possible.]

        + +
        +

        307. Lack of reference typedefs in container adaptors

        + Section: 23.2.3 [lib.container.adaptors]  Status: Ready  Submitter: Howard Hinnant  Date: 13 Mar 2001

        + +

        From reflector message c++std-lib-8330. See also lib-8317.

        + +

        + The standard is currently inconsistent in 23.2.3.2 + paragraph 1 and 23.2.3.3 paragraph 1. + 23.2.3.3/1, for example, says: +

        + +
        + -1- Any sequence supporting operations back(), push_back() and pop_back() + can be used to instantiate stack. In particular, vector (lib.vector), list + (lib.list) and deque (lib.deque) can be used. +
        + +

        But this is false: vector<bool> can not be used, because the + container adaptors return a T& rather than using the underlying + container's reference type.

        + +

        This is a contradiction that can be fixed by:

        + +
          +
        1. Modifying these paragraphs to say that vector<bool> + is an exception.
        2. +
        3. Removing the vector<bool> specialization.
        4. +
        5. Changing the return types of stack and priority_queue to use + reference typedef's.
        6. +
        + +

        + I propose 3. This does not preclude option 2 if we choose to do it + later (see issue 96); the issues are independent. Option + 3 offers a small step towards support for proxied containers. This + small step fixes a current contradiction, is easy for vendors to + implement, is already implemented in at least one popular lib, and + does not break any code. +

        + +

        Proposed resolution:

        +

        Summary: Add reference and const_reference typedefs to queue, + priority_queue and stack. Change return types of "value_type&" to + "reference". Change return types of "const value_type&" to + "const_reference". Details:

        + +

        Change 23.2.3.1/1 from:

        + +
        +   namespace std {
        +     template <class T, class Container = deque<T> >
        +     class queue {
        +     public:
        +       typedef typename Container::value_type            value_type;
        +       typedef typename Container::size_type             size_type;
        +       typedef          Container                        container_type;
        +     protected:
        +       Container c;
        + 
        +     public:
        +       explicit queue(const Container& = Container());
        + 
        +       bool      empty() const             { return c.empty(); }
        +       size_type size()  const             { return c.size(); }
        +       value_type&       front()           { return c.front(); }
        +       const value_type& front() const     { return c.front(); }
        +       value_type&       back()            { return c.back(); }
        +       const value_type& back() const      { return c.back(); }
        +       void push(const value_type& x)      { c.push_back(x); }
        +       void pop()                          { c.pop_front(); }
        +     };
        + 
        + +

        to:

        + +
        +   namespace std {
        +     template <class T, class Container = deque<T> >
        +     class queue {
        +     public:
        +       typedef typename Container::value_type            value_type;
        +       typedef typename Container::reference             reference;
        +       typedef typename Container::const_reference       const_reference;
        +       typedef typename Container::value_type            value_type;
        +       typedef typename Container::size_type             size_type;
        +       typedef          Container                        container_type;
        +     protected:
        +       Container c;
        + 
        +     public:
        +       explicit queue(const Container& = Container());
        + 
        +       bool      empty() const             { return c.empty(); }
        +       size_type size()  const             { return c.size(); }
        +       reference         front()           { return c.front(); }
        +       const_reference   front() const     { return c.front(); }
        +       reference         back()            { return c.back(); }
        +       const_reference   back() const      { return c.back(); }
        +       void push(const value_type& x)      { c.push_back(x); }
        +       void pop()                          { c.pop_front(); }
        +     };
        + 
        + +

        Change 23.2.3.2/1 from:

        + +
        +   namespace std {
        +     template <class T, class Container = vector<T>,
        +               class Compare = less<typename Container::value_type> >
        +     class priority_queue {
        +     public:
        +       typedef typename Container::value_type            value_type;
        +       typedef typename Container::size_type             size_type;
        +       typedef          Container                        container_type;
        +     protected:
        +       Container c;
        +       Compare comp;
        + 
        +     public:
        +       explicit priority_queue(const Compare& x = Compare(),
        +                               const Container& = Container());
        +       template <class InputIterator>
        +         priority_queue(InputIterator first, InputIterator last,
        +                        const Compare& x = Compare(),
        +                        const Container& = Container());
        + 
        +       bool      empty() const       { return c.empty(); }
        +       size_type size()  const       { return c.size(); }
        +       const value_type& top() const { return c.front(); }
        +       void push(const value_type& x);
        +       void pop();
        +     };
        +                                   //  no equality is provided
        +   }
        + 
        + +

        to:

        + +
        +   namespace std {
        +     template <class T, class Container = vector<T>,
        +               class Compare = less<typename Container::value_type> >
        +     class priority_queue {
        +     public:
        +       typedef typename Container::value_type            value_type;
        +       typedef typename Container::reference             reference;
        +       typedef typename Container::const_reference       const_reference;
        +       typedef typename Container::size_type             size_type;
        +       typedef          Container                        container_type;
        +     protected:
        +       Container c;
        +       Compare comp;
        + 
        +     public:
        +       explicit priority_queue(const Compare& x = Compare(),
        +                               const Container& = Container());
        +       template <class InputIterator>
        +         priority_queue(InputIterator first, InputIterator last,
        +                        const Compare& x = Compare(),
        +                        const Container& = Container());
        + 
        +       bool      empty() const       { return c.empty(); }
        +       size_type size()  const       { return c.size(); }
        +       const_reference   top() const { return c.front(); }
        +       void push(const value_type& x);
        +       void pop();
        +     };
        +                                   //  no equality is provided
        +   }
        + 
        + +

        And change 23.2.3.3/1 from:

        + +
        +   namespace std {
        +     template <class T, class Container = deque<T> >
        +     class stack {
        +     public:
        +       typedef typename Container::value_type            value_type;
        +       typedef typename Container::size_type             size_type;
        +       typedef          Container                        container_type;
        +     protected:
        +       Container c;
        + 
        +     public:
        +       explicit stack(const Container& = Container());
        + 
        +       bool      empty() const             { return c.empty(); }
        +       size_type size()  const             { return c.size(); }
        +       value_type&       top()             { return c.back(); }
        +       const value_type& top() const       { return c.back(); }
        +       void push(const value_type& x)      { c.push_back(x); }
        +       void pop()                          { c.pop_back(); }
        +     };
        + 
        +     template <class T, class Container>
        +       bool operator==(const stack<T, Container>& x,
        +                       const stack<T, Container>& y);
        +     template <class T, class Container>
        +       bool operator< (const stack<T, Container>& x,
        +                       const stack<T, Container>& y);
        +     template <class T, class Container>
        +       bool operator!=(const stack<T, Container>& x,
        +                       const stack<T, Container>& y);
        +     template <class T, class Container>
        +       bool operator> (const stack<T, Container>& x,
        +                       const stack<T, Container>& y);
        +     template <class T, class Container>
        +       bool operator>=(const stack<T, Container>& x,
        +                       const stack<T, Container>& y);
        +     template <class T, class Container>
        +       bool operator<=(const stack<T, Container>& x,
        +                       const stack<T, Container>& y);
        +   }
        + 
        + +

        to:

        + +
        +   namespace std {
        +     template <class T, class Container = deque<T> >
        +     class stack {
        +     public:
        +       typedef typename Container::value_type            value_type;
        +       typedef typename Container::reference             reference;
        +       typedef typename Container::const_reference       const_reference;
        +       typedef typename Container::size_type             size_type;
        +       typedef          Container                        container_type;
        +     protected:
        +       Container c;
        + 
        +     public:
        +       explicit stack(const Container& = Container());
        + 
        +       bool      empty() const             { return c.empty(); }
        +       size_type size()  const             { return c.size(); }
        +       reference         top()             { return c.back(); }
        +       const_reference   top() const       { return c.back(); }
        +       void push(const value_type& x)      { c.push_back(x); }
        +       void pop()                          { c.pop_back(); }
        +     };
        + 
        +     template <class T, class Container>
        +       bool operator==(const stack<T, Container>& x,
        +                       const stack<T, Container>& y);
        +     template <class T, class Container>
        +       bool operator< (const stack<T, Container>& x,
        +                       const stack<T, Container>& y);
        +     template <class T, class Container>
        +       bool operator!=(const stack<T, Container>& x,
        +                       const stack<T, Container>& y);
        +     template <class T, class Container>
        +       bool operator> (const stack<T, Container>& x,
        +                       const stack<T, Container>& y);
        +     template <class T, class Container>
        +       bool operator>=(const stack<T, Container>& x,
        +                       const stack<T, Container>& y);
        +     template <class T, class Container>
        +       bool operator<=(const stack<T, Container>& x,
        +                       const stack<T, Container>& y);
        +   }
        + 
        + +

        [Copenhagen: This change was discussed before the IS was released + and it was deliberately not adopted. Nevertheless, the LWG believes + (straw poll: 10-2) that it is a genuine defect.]

        + +
        +

        308. Table 82 mentions unrelated headers

        + Section: 27 [lib.input.output]  Status: Ready  Submitter: Martin Sebor  Date: 15 Mar 2001

        +

        + Table 82 in section 27 mentions the header <cstdlib> for String + streams (27.7 ) and the headers <cstdio> and + <cwchar> for File streams (27.8 ). It's not clear + why these headers are mentioned in this context since they do not + define any of the library entities described by the + subclauses. According to 17.4.1.1 , only such headers + are to be listed in the summary. +

        +

        Proposed resolution:

        +

        Remove <cstdlib> and <cwchar> from + Table 82.

        + +

        [Copenhagen: changed the proposed resolution slightly. The + original proposed resolution also said to remove <cstdio> from + Table 82. However, <cstdio> is mentioned several times within + section 27.8 , including 27.8.2 .]

        + +
        +

        309. Does sentry catch exceptions?

        + Section: 27.6 [lib.iostream.format]  Status: Open  Submitter: Martin Sebor  Date: 19 Mar 2001

        +

        + The descriptions of the constructors of basic_istream<>::sentry + (27.6.1.1.2 ) and basic_ostream<>::sentry + (27.6.2.3 ) do not explain what the functions do in + case an exception is thrown while they execute. Some current + implementations allow all exceptions to propagate, others catch them + and set ios_base::badbit instead, still others catch some but let + others propagate. +

        + +

        + The text also mentions that the functions may call setstate(failbit) + (without actually saying on what object, but presumably the stream + argument is meant). That may have been fine for + basic_istream<>::sentry prior to issue 195, since + the function performs an input operation which may fail. However, + issue 195 amends 27.6.1.1.2 , p2 to + clarify that the function should actually call setstate(failbit | + eofbit), so the sentence in p3 is redundant or even somewhat + contradictory. +

        + +

        + The same sentence that appears in 27.6.2.3 , p3 + doesn't seem to be very meaningful for basic_istream<>::sentry + which performs no input. It is actually rather misleading since it + would appear to guide library implementers to calling + setstate(failbit) when os.tie()->flush(), the only called function, + throws an exception (typically, it's badbit that's set in response to + such an event). +

        +

        Proposed resolution:

        +

        Add the following paragraph immediately after + 27.6.1.1.2 , p5

        + +
        +

        + If an exception is thrown during the preparation then ios::badbit + is turned on* in is's error state. +

        + +

        + [Footnote: This is done without causing an ios::failure to be thrown. + --- end footnote] +

        + +

        + If (is.exceptions() & ios_base::badbit)!= 0 then the exception is + rethrown. +

        +
        + +

        And strike the following sentence from 27.6.1.1.2 , p5

        + +
        + During preparation, the constructor may call setstate(failbit) + (which may throw ios_base::failure (lib.iostate.flags)) +
        + +

        Add the following paragraph immediately after + 27.6.2.3 , p3

        + +
        +

        + If an exception is thrown during the preparation then ios::badbit + is turned on* in os's error state. +

        + +

        + [Footnote: This is done without causing an ios::failure to be + thrown. --- end footnote] +

        + +

        + If (os.exceptions() & ios_base::badbit)!= 0 then the exception + is rethrown. +

        +
        + +

        And strike the following sentence from 27.6.2.3 , p3

        + +
        + During preparation, the constructor may call setstate(failbit) + (which may throw ios_base::failure (lib.iostate.flags)) +
        + +

        (Note that the removal of the two sentences means that the ctors + will not be able to report the failure of any implementation-dependent + operations referred to in footnotes 280 and 293, unless such + operations throw an exception.)

        + +

        [ + Copenhagen: It was agreed that there was an issue here, but there was + disagreement about the resolution. Some LWG members argued that a + sentry's constructor should not catch exceptions, because sentries + should only be used within (un)formatted input functions and that + exception handling is the responsibility of those functions, not of + the sentries. + ]

        + +
        +

        310. Is errno a macro?

        + Section: 17.4.1.2 [lib.headers], 19.3 [lib.errno]  Status: Review  Submitter: Steve Clamage  Date: 21 Mar 2001

        +

        + Exactly how should errno be declared in a conforming C++ header? +

        + +

        + The C standard says in 7.1.4 that it is unspecified whether errno is a + macro or an identifier with external linkage. In some implementations + it can be either, depending on compile-time options. (E.g., on + Solaris in multi-threading mode, errno is a macro that expands to a + function call, but is an extern int otherwise. "Unspecified" allows + such variability.) +

        + +

        The C++ standard:

        +
          +
        • 17.4.1.2 says in a note that errno must be macro in C. (false)
        • +
        • 17.4.3.1.3 footnote 166 says errno is reserved as an external + name (true), and implies that it is an identifier.
        • +
        • 19.3 simply lists errno as a macro (by what reasoning?) and goes + on to say that the contents of of C++ <errno.h> are the + same as in C, begging the question.
        • +
        • C.2, table 95 lists errno as a macro, without comment.
        • +
        + +

        I find no other references to errno.

        + +

        We should either explicitly say that errno must be a macro, even + though it need not be a macro in C, or else explicitly leave it + unspecified. We also need to say something about namespace std. + A user who includes <cerrno> needs to know whether to write + errno, or ::errno, or std::errno, or + else <cerrno> is useless.

        + +

        Two acceptable fixes:

        +
          +
        • errno must be a macro. This is trivially satisfied by adding
          +   #define errno (::std::errno)
          + to the headers if errno is not already a macro. You then always + write errno without any scope qualification, and it always expands + to a correct reference. Since it is always a macro, you know to + avoid using errno as a local identifer.

        • +
        • errno is in the global namespace. This fix is inferior, because + ::errno is not guaranteed to be well-formed.

        • +
        + +

        [ + This issue was first raised in 1999, but it slipped through + the cracks. + ]

        +

        Proposed resolution:

        +

        Change the Note in section 17.4.1.2p5 from

        + +
        + Note: the names defined as macros in C include the following: + assert, errno, offsetof, setjmp, va_arg, va_end, and va_start. +
        + +

        to

        + +
        + Note: the names defined as macros in C include the following: + assert, offsetof, setjmp, va_arg, va_end, and va_start. +
        + +

        In section 19.3, change paragraph 2 from

        + +
        + The contents are the same as the Standard C library header + <errno.h>. +
        + +

        to

        + +
        + The contents are the same as the Standard C library header + <errno.h>, except that errno shall be defined as a macro. +
        +
        +

        311. Incorrect wording in basic_ostream class synopsis

        + Section: 27.6.2.1 [lib.ostream]  Status: Review  Submitter: Andy Sawyer  Date: 21 Mar 2001

        + +

        In 27.6.2.1 , the synopsis of class basic_ostream says:

        + +
        +   // partial specializationss
        +   template<class traits>
        +     basic_ostream<char,traits>& operator<<( basic_ostream<char,traits>&,
        +                                             const char * );
        + 
        + +

        Problems:

        +
          +
        • Too many 's's at the end of "specializationss"
        • +
        • This is an overload, not a partial specialization
        • +
        + +

        Proposed resolution:

        +

        In the synopsis in 27.6.2.1 , remove the + // partial specializationss comment.

        +
        +

        312. Table 27 is missing headers

        + Section: 20 [lib.utilities]  Status: Ready  Submitter: Martin Sebor  Date: 29 Mar 2001

        +

        Table 27 in section 20 lists the header <memory> (only) for + Memory (lib.memory) but neglects to mention the headers + <cstdlib> and <cstring> that are discussed in 20.4.6 .

        +

        Proposed resolution:

        +

        Add <cstdlib> and <cstring> to Table 27, in the same row + as <memory>.

        +
        +

        315. Bad "range" in list::unique complexity

        + Section: 23.2.2.4 [lib.list.ops]  Status: New  Submitter: Andy Sawyer  Date: 1 May 2001

        +

        + 23.2.2.4 , Para 21 describes the complexity of + list::unique as: "If the range (last - first) is not empty, exactly + (last - first) -1 applications of the corresponding predicate, + otherwise no applications of the predicate)". +

        + +

        + "(last - first)" is not a range. +

        +

        Proposed resolution:

        +

        + Change the "range" from (last - first) to [first, last). Change the + complexity from "(last - first) -1 applications of the corresponding + predicate" to "distance(first,last)-1 applications of the corresponding + predicate. +

        +
        +

        316. Vague text in Table 69

        + Section: 23.1.2 [lib.associative.reqmts]  Status: New  Submitter: Martin Sebor  Date: 4 May 2001

        +

        Table 69 says this about a_uniq.insert(t):

        + +
        + inserts t if and only if there is no element in the container with key + equivalent to the key of t. The bool component of the returned pair + indicates whether the insertion takes place and the iterator component of the + pair points to the element with key equivalent to the key of t. +
        + +

        The description should be more specific about exactly how the bool component + indicates whether the insertion takes place.

        +

        Proposed resolution:

        +

        Change the text in question to

        + +
        + ...The bool component of the returned pair is true if and only if the insertion + takes place... +
        +
        +

        317. Instantiation vs. specialization of facets

        + Section: 22 [lib.localization]  Status: New  Submitter: Martin Sebor  Date: 4 May 2001

        +

        + The localization section of the standard refers to specializations of + the facet templates as instantiations even though the required facets + are typically specialized rather than explicitly (or implicitly) + instantiated. In the case of ctype<char> and + ctype_byname<char> (and the wchar_t versions), these facets are + actually required to be specialized. The terminology should be + corrected to make it clear that the standard doesn't mandate explicit + instantiation (the term specialization encompasses both explicit + instantiations and specializations). +

        +

        Proposed resolution:

        +

        + In the following paragraphs, replace all occurrences of the word + instantiation or instantiations with specialization or specializations, + respectively: +

        + +
        + 22.1.1.1.1, p4, Table 52, 22.2.1.1, p2, 22.2.1.5, p3, 22.2.1.5.1, p5, + 22.2.1.5.2, p10, 22.2.2, p2, 22.2.3.1, p1, 22.2.3.1.2, p1, p2 and p3, + 22.2.4.1, p1, 22.2.4.1.2, p1, 22,2,5, p1, 22,2,6, p2, 22.2.6.3.2, p7, and + Footnote 242. +
        + +

        And change the text in 22.1.1.1.1, p4 from

        + +
        + An implementation is required to provide those instantiations + for facet templates identified as members of a category, and + for those shown in Table 52: +
        + +

        to

        + +
        + An implementation is required to support those specializations... +
        +
        +

        318. Misleading comment in definition of numpunct_byname

        + Section: 22.2.3.2 [lib.locale.numpunct.byname]  Status: New  Submitter: Martin Sebor  Date: 12 May 2001

        +

        The definition of the numpunct_byname template contains the following + comment:

        + +
        +     namespace std {
        +         template <class charT>
        +         class numpunct_byname : public numpunct<charT> {
        +     // this class is specialized for char and wchar_t.
        +         ...
        + 
        + +

        There is no documentation of the specializations and it seems + conceivable that an implementation will not explicitly specialize the + template at all, but simply provide the primary template.

        +

        Proposed resolution:

        +

        Remove the comment from the text in 22.2.3.2 and from the proposed + resolution of library issue 228.

        +
        +

        319. Storage allocation wording confuses "Required behavior", "Requires"

        + Section: 18.4.1.1 [lib.new.delete.single], 18.4.1.2 [lib.new.delete.array]  Status: New  Submitter: Beman Dawes  Date: 15 May 2001

        +

        The standard specifies 17.3.1.3 that "Required + behavior" elements describe "the semantics of a function definition + provided by either the implementation or a C++ program."

        + +

        The standard specifies 17.3.1.3 that "Requires" + elements describe "the preconditions for calling the function."

        + +

        In the sections noted below, the current wording specifies + "Required Behavior" for what are actually preconditions, and thus + should be specified as "Requires".

        + +

        Proposed resolution:

        + +

        In 18.4.1.1 Para 12 Change:

        +
        +

        Required behavior: accept a value of ptr that is null or that was + returned by an earlier call ...

        +
        +

        to:

        +
        +

        Requires: the value of ptr be null or the value returned by an + earlier call ...

        +
        + +

        In 18.4.1.2 Para 11 Change:

        +
        +

        Required behavior: accept a value of ptr that is null or that was + returned by an earlier call ...

        +
        +

        to:

        +
        +

        Requires: the value of ptr be null or the value returned by an + earlier call ...

        +
        + +
        +

        320. list::assign overspecified

        + Section: 23.2.2.1 [lib.list.cons]  Status: New  Submitter: Howard Hinnant  Date: 17 May 2001

        +

        + Section 23.2.2.1, paragraphs 6-8 specify that list assign (both forms) have + the "effects" of a call to erase followed by a call to insert. +

        + +

        + I would like to document that implementers have the freedom to implement + assign by other methods, as long as the end result is the same and the + exception guarantee is as good or better than the basic guarantee. +

        + +

        + The motivation for this is to use T's assignment operator to recycle + existing nodes in the list instead of erasing them and reallocating + them with new values. It is also worth noting that, with careful + coding, most common cases of assign (everything but assignment with + true input iterators) can elevate the exception safety to strong if + T's assignment has a nothrow guarantee (with no extra memory cost). + Metrowerks does this. However I do not propose that this subtlety be + standardized. It is a QoI issue.

        + +

        Existing practise: + Metrowerks and SGI recycle nodes, Dinkumware and Rogue Wave don't. +

        +

        Proposed resolution:

        +

        Change 23.2.2.1/7 from:

        + +
        +

        Effects:

        + +
        +    erase(begin(), end());
        +    insert(begin(), first, last);
        + 
        +
        + +

        to:

        + +
        +

        Effects: Replaces the contents of the list with the range [first, last).

        +

        PostCondition: *this == list<T, Allocator>(first, last)

        +

        Notes: If an exception is thrown, the contents of the list are + indeterminate.

        +
        + +

        Change 23.2.2.1/8 from:

        + +
        +

        Effects:

        +
        +    erase(begin(), end());
        +    insert(begin(), n, t);
        + 
        +
        +

        to:

        + +
        +

        Effects: Replaces the contents of the list with n copies of t.

        +

        PostCondition: *this == list<T, Allocator>(n, t)

        +

        Notes: If an exception is thrown, the contents of the list are self + consistent but indeterminate.

        +
        +
        +

        321. Typo in num_get

        + Section: 22.2.2.1.2 [lib.facet.num.get.virtuals]  Status: New  Submitter: Kevin Djang  Date: 17 May 2001

        +

        + Section 22.2.2.1.2 at p7 states that "A length specifier is added to + the conversion function, if needed, as indicated in Table 56." + However, Table 56 uses the term "length modifier", not "length + specifier". +

        +

        Proposed resolution:

        +

        + In 22.2.2.1.2 at p7, change the text "A length specifier is added ..." + to be "A length modifier is added ..." +

        +
        +

        322. iterator and const_iterator should have the same value type

        + Section: 23.1 [lib.container.requirements]  Status: New  Submitter: Matt Austern  Date: 17 May 2001

        +

        + It's widely assumed that, if X is a container, + iterator_traits<X::iterator>::value_type and + iterator_traits<X::const_iterator>::value_type should both be + X::value_type. However, this is nowhere stated. The language in + Table 65 is not precise about the iterators' value types (it predates + iterator_traits), and could even be interpreted as saying that + iterator_traits<X::const_iterator>::value_type should be "const + X::value_type". +

        + +

        Related issue: 279.

        +

        Proposed resolution:

        +

        In Table 65 ("Container Requirements"), change the return type for + X::iterator to "iterator type whose value type is T". Change the + return type for X::const_iterator to "constant iterator type whose + value type is T".

        +

        Rationale:

        +

        + This belongs as a container requirement, rather than an iterator + requirement, because the whole notion of iterator/const_iterator + pairs is specific to containers' iterator. +

        +

        + It is existing practice that (for example) + iterator_traits<list<int>::const_iterator>::value_type + is "int", rather than "const int". This is consistent with + the way that const pointers are handled: the standard already + requires that iterator_traits<const int*>::value_type is int. +

        +
        +

        323. abs() overloads in different headers

        + Section: 26.5 [lib.c.math]  Status: New  Submitter: Dave Abrahams  Date: 4 June 2001

        +

        Currently the standard mandates the following overloads of + abs():

        + +
        +     abs(long), abs(int) in <cstdlib>
        + 
        +     abs(float), abs(double), abs(long double) in <cmath>
        + 
        +     template<class T> T abs(const complex<T>&) in <complex>
        + 
        +     template<class T> valarray<T> abs(const valarray<T>&); in <valarray>
        + 
        + +

        + The problem is that having only some overloads visible of a function + that works on "implicitly inter-convertible" types is dangerous in + practice. The headers that get included at any point in a translation + unit can change unpredictably during program + development/maintenance. The wrong overload might be unintentionally + selected. +

        + +

        + Currently, there is nothing that mandates the simultaneous visibility + of these overloads. Indeed, some vendors have begun fastidiously + reducing dependencies among their (public) headers as a QOI issue: it + helps people to write portable code by refusing to compile unless all + the correct headers are #included. +

        + +

        The same issue may exist for other functions in the library.

        +

        Proposed resolution:

        +
        +

        324. Do output iterators have value types?

        + Section: 24.1.2 [lib.output.iterators]  Status: New  Submitter: Dave Abrahams  Date: 7 June 2001

        + +

        Table 73 suggests that output iterators have value types. It says + defines the expression "*a = t". Additionally, although Table 73 + never lists "a = t" or "X(a) = t" in the "expressions" column, it + contains a note saying that "a = t" and "X(a) = t" have equivalent + (but nowhere specified!) semantics.

        + +

        According to 24.1/9, t is supposed to be "a value of value type + T":

        + +
        + In the following sections, a and b denote values of X, n denotes a + value of the difference type Distance, u, tmp, and m denote + identifiers, r denotes a value of X&, t denotes a value of + value type T. +
        + +

        Two other parts of the standard that are relevant to whether + output iterators have value types:

        + +
          +
        • 24.1/1 says "All iterators i support the expression *i, + resulting in a value of some class, enumeration, or built-in type + T, called the value type of the iterator".
        • + +
        • + 24.3.1/1, which says "In the case of an output iterator, the types + iterator_traits<Iterator>::difference_type + iterator_traits<Iterator>::value_type are both defined as void." +
        • +
        + +

        The first of these passages suggests that "*i" is supposed to + return a useful value, which contradicts the note in 24.1.2/2 saying + that the only valid use of "*i" for output iterators is in an + expression of the form "*i = t". The second of these passages appears + to contradict Table 73, because it suggests that "*i"'s return value + should be void. The second passage is also broken in the case of a an + iterator type, like non-const pointers, that satisfies both the output + iterator requirements and the forward iterator requirements.

        + +

        What should the standard say about "*i's" return value when i is an + output iterator, and what should it say about that t is in the + expression "*i = t"? Finally, should the standard say anything about + output iterators' pointer and reference types?

        + +

        Proposed resolution:

        + +

        A sketch of one proposed resolution, without language: Make it + clear that the notion of "value type" does not apply to output + iterators.

        + +
        + Put an "except for output iterators" qualification in 24.1/1; remove + the note in table 73 about "a = t" and "X(a) = t"; put language in + 24.1.2 paragraph 1 saying that "t" is a value of whatever type or + types for which "*i = t" is defined and that an output iterator need + not have a unique value type; change 24.3.1/1 to say that an output + iterator may, but need not, define + iterator_traits<Iterator>::difference_type + iterator_traits<Iterator>::value_type as void. +
        + +

        A sketch of an alternate proposed resolution, also without + language: Require every output iterator to have a value type, just + like other kinds of iterators.

        + +
        + Put an "except for output iterators" qualification in 24.1/1; remove + the note in table 73 about "a = t" and "X(a) = t"; put language in + 24.1.2 paragraph 1 saying that an output iterator's value type is the + type for which "*i = t" is defined; remove the note in 24.3.1/1 saying + that iterator_traits<>::value_type is void for an output + iterator; change all of the predefined output iterators + (ostream_iterator, ostreambuf_iterator, back_insert_iterator, + front_insert_iterator, insert_iterator) so that they have non-void + value types. +
        + +
        +

        325. Misleading text in moneypunct<>::do_grouping

        + Section: 22.2.6.3.2 [lib.locale.moneypunct.virtuals]  Status: New  Submitter: Martin Sebor  Date: 02 Jul 2001

        +

        The Returns clause in 22.2.6.3.2, p3 says about + moneypunct<charT>::do_grouping() +

        + +
        + Returns: A pattern defined identically as the result of + numpunct<charT>::do_grouping().241) +
        + +

        Footnote 241 then reads

        + +
        + This is most commonly the value "\003" (not "3"). +
        + +

        + The returns clause seems to imply that the two member functions must + return an identical value which in reality may or may not be true, + since the facets are usually implemented in terms of struct std::lconv + and return the value of the grouping and mon_grouping, respectively. + The footnote also implies that the member function of the moneypunct + facet (rather than the overridden virtual functions in moneypunct_byname) + most commonly return "\003", which contradicts the C standard which + specifies the value of "" for the (most common) C locale. +

        + +

        Proposed resolution:

        +

        Replace the text in Returns clause in 22.2.6.3.2, p3 with the following:

        + +
        + Returns: A pattern defined identically as, but not necessarily + equal to, the result of numpunct<charT>::do_grouping().241) +
        + +

        and replace the text in Footnote 241 with the following:

        + +
        + The moneypunct facet (or its derivative) installed in named locales + other than "C" will most commonly return the value "\003" (not "3"). +
        +

        Rationale:

        +

        + Note that the proposed resolution is sufficiently vague to allow + implementations to implement the behavior of both moneypunct and + moneypunct_byname to be implemented by the base. This may or may + not be desirable depending on whether we want the base behavior + to strictly reflect the "C" locale (only) and the derived behavior + to implement the behavior specific to the named locales. This + distinction would be detectable by obtaining a reference to + moneypunct_byname, say mp, and calling mp.do_grouping() or + mp.moneypunct<charT>::do_grouping() to get one or the other. +

        +
        +

        326. Missing typedef in moneypunct_byname

        + Section: 22.2.6.4 [lib.locale.moneypunct.byname]  Status: New  Submitter: Martin Sebor  Date: 05 Jul 2001

        +

        The definition of the moneypunct facet contains the typedefs char_type + and string_type. Only one of these names, string_type, is defined in + the derived facet, moneypunct_byname.

        +

        Proposed resolution:

        +

        For consistency with the numpunct facet, add a typedef for + char_type to the definition of the moneypunct_byname facet in + 22.2.6.4 .

        +
        +

        327. Typo in time_get facet in table 52

        + Section: 22.1.1.1.1 [lib.locale.category]  Status: New  Submitter: Tiki Wan  Date: 06 Jul 2001

        +

        The wchar_t versions of time_get and + time_get_byname are listed incorrectly in table 52, + required instantiations. In both cases the second template + parameter is given as OutputIterator. It should instead be + InputIterator, since these are input facets.

        +

        Proposed resolution:

        +

        + In table 52, required instantiations, in + 22.1.1.1.1 , change

        +
        +     time_get<wchar_t, OutputIterator>
        +     time_get_byname<wchart, OutputIterator>
        + 
        +

        to

        +
        +     time_get<wchar_t, InputIterator>
        +     time_get_byname<wchart, InputIterator>
        + 
        +
        +

        328. Bad sprintf format modifier in money_put<>::do_put()

        + Section: 22.2.6.2.2 [lib.locale.money.put.virtuals]  Status: New  Submitter: Martin Sebor  Date: 07 Jul 2001

        +

        The sprintf format string , "%.01f" (that's the digit one), in the + description of the do_put() member functions of the money_put facet in + 22.2.6.2.2, p1 is incorrect. First, the f format specifier is wrong + for values of type long double, and second, the precision of 01 + doesn't seem to make sense. What was most likely intended was + "%.0Lf"., that is a precision of zero followed by the L length + modifier.

        +

        Proposed resolution:

        +

        Change the format string to "%.0Lf".

        +
        +

        329. vector capacity, reserve and reallocation

        + Section: 23.2.4.2 [lib.vector.capacity], 23.2.4.3 [lib.vector.modifiers]  Status: New  Submitter: Anthony Williams  Date: 13 Jul 2001

        +

        + There is an apparent contradiction about which circumstances can cause + a reallocation of a vector in Section 23.2.4.2 and + section 23.2.4.3 . +

        + +

        23.2.4.2p5 says:

        +
        + Notes: Reallocation invalidates all the references, pointers, and iterators + referring to the elements in the sequence. It is guaranteed that no + reallocation takes place during insertions that happen after a call to + reserve() until the time when an insertion would make the size of the vector + greater than the size specified in the most recent call to reserve(). +
        + +

        Which implies if I do

        + +
        +   std::vector<int> vec;
        +   vec.reserve(23);
        +   vec.reserve(0);
        +   vec.insert(vec.end(),1);
        + 
        + +

        then the implementation may reallocate the vector for the insert, + as the size specified in the previous call to reserve was zero.

        + +

        However, the previous paragraphs (23.2.4.2, p1-2) state:

        +
        +

        + (capacity) Returns: The total number of elements the vector + can hold without requiring reallocation +

        +

        + ...After reserve(), capacity() is greater or equal to the + argument of reserve if reallocation happens; and equal to the previous value + of capacity() otherwise... +

        +
        + +

        + This implies that vec.capacity() is still 23, and so the insert() + should not require a reallocation, as vec.size() is 0. This is backed + up by 23.2.4.3p1: +

        +
        + (insert) Notes: Causes reallocation if the new size is greater than the old + capacity. +
        + +

        + Though this doesn't rule out reallocation if the new size is less + than the old capacity, I think the intent is clear. +

        + +

        Proposed resolution:

        +

        Change the wording of 23.2.4.5p5 to:

        + +
        + Notes: Reallocation invalidates all the references, pointers, and + iterators referring to the elements in the sequence. It is guaranteed + that no reallocation takes place during insertions that happen after a + call to reserve() until the time when an insertion would make the size + of the vector greater than the value of capacity() after the most + recent call to reserve(). +
        + +
        +

        330. Misleading "exposition only" value in class locale definition

        + Section: 22.1.1 [lib.locale]  Status: New  Submitter: Martin Sebor  Date: 15 Jul 2001

        +

        + The "exposition only" value of the std::locale::none constant shown in + the definition of class locale is misleading in that it on many + systems conflicts with the value assigned to one if the LC_XXX + constants (specifically, LC_COLLATE on AIX, LC_ALL on HP-UX, LC_CTYPE + on Linux and SunOS). This causes incorrect behavior when such a + constant is passed to one of the locale member functions that accept a + locale::category argument and interpret it as either the C LC_XXX + constant or a bitmap of locale::category values. At least three major + implementations adopt the suggested value without a change and + consequently suffer from this problem. +

        + +

        + For instance, the following code will (presumably) incorrectly copy facets + belonging to the collate category from the German locale on AIX: +

        + +
        +   std::locale l (std::locale ("C"), "de_DE", std::locale::none);
        + 
        +

        Proposed resolution:

        +

        + Change the value from 0 to some other bit value, say 0x400, distinct + from any of the other values shown. +

        +
        +

        331. bad declaration of destructor for ios_base::failure

        + Section: 27.4.2.1.1 [lib.ios::failure]  Status: New  Submitter: PremAnand M. Rao  Date: 23 Aug 2001

        +

        + With the change in 17.4.4.8 to state + "An implementation may strengthen the exception-specification for a + non-virtual function by removing listed exceptions." + (issue 119) + and the following declaration of ~failure() in ios_base::failure +

        +
        +     namespace std {
        +        class ios_base::failure : public exception {
        +        public:
        +            ...
        +            virtual ~failure();
        +            ...
        +        };
        +      }
        + 
        +

        the class failure cannot be implemented since in 18.6.1 the destructor of class exception has an empty + exception specification:

        +
        +     namespace std {
        +        class exception {
        +        public:
        +          ...
        +          virtual ~exception() throw();
        +          ...
        +        };
        +      }
        + 
        +

        Proposed resolution:

        +

        Two alternatives:

        +
          +
        1. Change the declaration of ~failure() to virtual ~failure() throw();
        2. +
        3. Remove the declaration of ~failure().
        4. +
        +
        +

        332. Consider adding increment and decrement operators to std::fpos< T >

        + Section: 27.4.3 [lib.fpos]  Status: New  Submitter: PremAnand M. Rao  Date: 27 Aug 2001

        +

        + Increment and decrement operators are missing from + Table 88 -- Position type requirements in 27.4.3 . +

        +

        Proposed resolution:

        +

        + Table 88 (section 27.4.3) -- Position type requirements + be updated to include increment and decrement operators. +

        + +
        + expression        return type     operational    note
        + 
        + ++p               fpos&           p += O(1)
        + p++               fpos            { P tmp = p;
        +                                     ++p;
        +                                     return tmp; }
        + --p               fpos&           p -= O(1)
        + p--               fpos            { P tmp = p;
        +                                     --p;
        +                                     return tmp; }
        + 
        + +
        +

        333. does endl imply synchronization with the device?

        + Section: 27.6.2.7 [lib.ostream.manip]  Status: New  Submitter: PremAnand M. Rao  Date: 27 Aug 2001

        +

        A footnote in 27.6.2.7 states:

        +
        + [Footnote: The effect of executing cout << endl is to insert a + newline character in the output sequence controlled by cout, then + synchronize it with any external file with which it might be + associated. --- end foonote] +
        + +

        + Does the term "file" here refer to the external device? + This leads to some implementation ambiguity on systems with fully + buffered files where a newline does not cause a flush to the device. +

        + +

        + Choosing to sync with the device leads to significant performance + penalties for each call to endl, while not sync-ing leads to + errors under special circumstances. +

        + +

        + I could not find any other statement that explicitly defined + the behavior one way or the other. +

        +

        Proposed resolution:

        +
        +

        334. map::operator[] specification forces inefficient implementation

        + Section: 23.3.1.2 [lib.map.access]  Status: New  Submitter: Andrea Griffini  Date: 02 Sep 2001

        +

        + The current standard describes map::operator[] using a + code example. That code example is however quite + inefficient because it requires several useless copies + of both the passed key_type value and of default + constructed mapped_type instances. + My opinion is that was not meant by the comitee to + require all those temporary copies. +

        + +

        Currently map::operator[] behaviour is specified as:

        +
        +   Returns:
        +     (*((insert(make_pair(x, T()))).first)).second.
        + 
        + +

        + This specification however uses make_pair that is a + template function of which parameters in this case + will be deduced being of type const key_type& and + const T&. This will create a pair<key_type,T> that + isn't the correct type expected by map::insert so + another copy will be required using the template + conversion constructor available in pair to build + the required pair<const key_type,T> instance. +

        + +

        If we consider calling of key_type copy constructor + and mapped_type default constructor and copy + constructor as observable behaviour (as I think we + should) then the standard is in this place requiring + two copies of a key_type element plus a default + construction and two copy construction of a mapped_type + (supposing the addressed element is already present + in the map; otherwise at least another copy + construction for each type). +

        +

        Proposed resolution:

        +

        A simple (half) solution would be replacing the description with:

        +
        +   Returns:
        +     (*((insert(value_type(x, T()))).first)).second.
        + 
        + +

        This will remove the wrong typed pair construction that + requires one extra copy of both key and value.

        + +

        However still the using of map::insert requires temporary + objects while the operation, from a logical point of view, + doesn't require any.

        + +

        I think that a better solution would be leaving free an + implementer to use a different approach than map::insert + that, because of its interface, forces default constructed + temporaries and copies in this case. + The best solution in my opinion would be just requiring + map::operator[] to return a reference to the mapped_type + part of the contained element creating a default element + with the specified key if no such an element is already + present in the container. Also a logarithmic complexity + requirement should be specified for the operation. +

        + +

        + This would allow library implementers to write alternative + implementations not using map::insert and reaching optimal + performance in both cases of the addressed element being + present or absent from the map (no temporaries at all and + just the creation of a new pair inside the container if + the element isn't present). + Some implementer has already taken this option but I think + that the current wording of the standard rules that as + non-conforming. +

        + +

        + Note that this is a "relaxing" of requirment and won't + make any currently conforming implementation on this + point to become non-conforming because of the change. +

        + +

        + There is a small risk that current code may be depending + on the number of temporaries created by map::operator[]; + but I think that such dependencies would be present only + in code that is most probably already non portable as + the number of copies of parameters isn't guaranteed by + the standard (in the current wording there's just an + implicit *minimum* number of required copies). +

        + +
        +

        335. minor issue with char_traits, table 37

        + Section: 21.1.1 [lib.char.traits.require]  Status: New  Submitter: Andy Sawyer  Date: 06 Sep 2001

        +

        + Table 37, in 21.1.1 , descibes char_traits::assign + as: +

        +
        +   X::assign(c,d)   assigns c = d.
        + 
        + +

        And para 1 says:

        + +
        + [...] c and d denote values of type CharT [...] +
        + +

        + Naturally, if c and d are values, then the assignment is + (effectively) meaningless. It's clearly intended that (in the case of + assign, at least), 'c' is intended to be a reference type. +

        + +

        I did a quick survey of the four implementations I happened to have + lying around, and sure enough they all have signatures:

        +
        +     assign( charT&, const charT& );
        + 
        + +

        (or the equivalent). It's also described this way in Nico's book. + (Not to mention the synopses of char_traits<char> in 21.1.3.1 + and char_traits<wchar_t> in 21.1.3.2...) +

        +

        Proposed resolution:

        +

        Add the following to 21.1.1 para 1:

        +
        + r denotes a reference to CharT +
        + +

        and change the description of assign in the table to:

        +
        +   X::assign(r,d)   assigns r = d
        + 
        +

        ----- End of document -----

        + + diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/ext/lwg-defects.html gcc-3.0.2/libstdc++-v3/docs/html/ext/lwg-defects.html *** gcc-3.0.1/libstdc++-v3/docs/html/ext/lwg-defects.html Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/libstdc++-v3/docs/html/ext/lwg-defects.html Fri Oct 19 13:07:41 2001 *************** *** 0 **** --- 1,4866 ---- + + + C++ Standard Library Defect Report List + + + + + + + + + + + + + + + + + + +
        Doc. no.J16/01-0032 = WG21 N1318
        Date:11 Sep 2001
        Project:Programming Language C++
        Reply to:Matt Austern <austern@research.att.com>
        +

        C++ Standard Library Defect Report List (Revision 19)

        +

        Reference ISO/IEC IS 14882:1998(E)

        +

        Also see:

        + +

        This document contains only library issues which have been closed + by the Library Working Group (LWG) after being found to be defects + in the standard. That is, issues which have a status of DR, TC, or RR. See the + Library Closed Issues List for issues closed as non-defects. See the + Library Active Issues List for active issues and more information. The + introductory material in that document also applies to this + document.

        +

        Revision History

        +
          +
        • R19: + Pre-Redmond mailing. Added new issues + 323-335. +
        • +
        • R18: + Post-Copenhagen mailing; reflects actions taken in Copenhagen. + Added new issues 312-317, and discussed + new issues 271-314. + + Changed status of issues + 103 118 136 153 + 165 171 183 184 + 185 186 214 221 + 234 237 243 248 + 251 252 256 260 + 261 262 263 265 + 268 + to DR. + + Changed status of issues + 49 109 117 182 + 228 230 232 235 + 238 241 242 250 + 259 264 266 267 + 271 272 273 275 + 281 284 285 286 + 288 292 295 297 + 298 301 303 306 + 307 308 312 + to Ready. + + Closed issues + 111 277 279 287 + 289 293 302 313 + 314 + as NAD. + +
        • +
        • R17: + Pre-Copenhagen mailing. Converted issues list to XML. Added proposed + resolutions for issues 49, 76, 91, 235, 250, 267. + Added new issues 278-311. +
        • +
        • R16: + post-Toronto mailing; reflects actions taken in Toronto. Added new + issues 265-277. Changed status of issues + 3, 8, 9, 19, + 26, 31, 61, + 63, 86, 108, + 112, 114, 115, + 122, 127, 129, + 134, 137, 142, + 144, 146, 147, + 159, 164, 170, + 181, 199, 208, + 209, 210, 211, + 212, 217, 220, + 222, 223, 224, + 227 to "DR". Reopened issue 23. Reopened + issue 187. Changed issues 2 and + 4 to NAD. Fixed a typo in issue 17. Fixed + issue 70: signature should be changed both places it + appears. Fixed issue 160: previous version didn't fix + the bug in enough places. +
        • +
        • R15: + pre-Toronto mailing. Added issues + 233-264. Some small HTML formatting + changes so that we pass Weblint tests. +
        • +
        • R14: + post-Tokyo II mailing; reflects committee actions taken in + Tokyo. Added issues 228 to 232. (00-0019R1/N1242) +
        • +
        • R13: + pre-Tokyo II updated: Added issues 212 to 227. +
        • +
        • R12: + pre-Tokyo II mailing: Added issues 199 to + 211. Added "and paragraph 5" to the proposed resolution + of issue 29. Add further rationale to issue + 178. +
        • +
        • R11: + post-Kona mailing: Updated to reflect LWG and full committee actions + in Kona (99-0048/N1224). Note changed resolution of issues + 4 and 38. Added issues 196 + to 198. Closed issues list split into "defects" and + "closed" documents. Changed the proposed resolution of issue + 4 to NAD, and changed the wording of proposed resolution + of issue 38. +
        • +
        • R10: + pre-Kona updated. Added proposed resolutions 83, + 86, 91, 92, + 109. Added issues 190 to + 195. (99-0033/D1209, 14 Oct 99) +
        • +
        • R9: + pre-Kona mailing. Added issues 140 to + 189. Issues list split into separate "active" and + "closed" documents. (99-0030/N1206, 25 Aug 99) +
        • +
        • R8: + post-Dublin mailing. Updated to reflect LWG and full committee actions + in Dublin. (99-0016/N1193, 21 Apr 99) +
        • +
        • R7: + pre-Dublin updated: Added issues 130, 131, + 132, 133, 134, + 135, 136, 137, + 138, 139 (31 Mar 99) +
        • +
        • R6: + pre-Dublin mailing. Added issues 127, 128, + and 129. (99-0007/N1194, 22 Feb 99) +
        • +
        • R5: + update issues 103, 112; added issues + 114 to 126. Format revisions to prepare + for making list public. (30 Dec 98) +
        • +
        • R4: + post-Santa Cruz II updated: Issues 110, + 111, 112, 113 added, several + issues corrected. (22 Oct 98) +
        • +
        • R3: + post-Santa Cruz II: Issues 94 to 109 + added, many issues updated to reflect LWG consensus (12 Oct 98) +
        • +
        • R2: + pre-Santa Cruz II: Issues 73 to 93 added, + issue 17 updated. (29 Sep 98) +
        • +
        • R1: + Correction to issue 55 resolution, 60 code + format, 64 title. (17 Sep 98) +
        • +
        +

        Defect Reports

        +
        +

        1. C library linkage editing oversight

        + Section: 17.4.2.2 [lib.using.linkage]  Status: DR  Submitter: Beman Dawes  Date: 16 Nov 1997

        +

        The change specified in the proposed resolution below did not make + it into the Standard. This change was accepted in principle at the + London meeting, and the exact wording below was accepted at the + Morristown meeting.

        +

        Proposed resolution:

        +

        Change 17.4.2.2 paragraph 2 + from:

        + +
        +

        It is unspecified whether a name from the Standard C library + declared with external linkage has either extern "C" or + extern "C++" linkage.

        +
        + +

        to:

        + +
        +

        Whether a name from the Standard C library declared with external + linkage has extern "C" or extern "C++" linkage + is implementation defined. It is recommended that an implementation + use extern "C++" linkage for this purpose.

        +
        +
        +

        3. Atexit registration during atexit() call is not described

        + Section: 18.3 [lib.support.start.term]  Status: DR  Submitter: Steve Clamage  Date: 12 Dec 1997

        +

        We appear not to have covered all the possibilities of + exit processing with respect to + atexit registration.
        +
        + Example 1: (C and C++)

        + +
            #include <stdlib.h>
        +     void f1() { }
        +     void f2() { atexit(f1); }
        +     
        +     int main()
        +     {
        +         atexit(f2); // the only use of f2
        +         return 0; // for C compatibility
        +     }
        + +

        At program exit, f2 gets called due to its registration in + main. Running f2 causes f1 to be newly registered during the exit + processing. Is this a valid program? If so, what are its + semantics?

        + +

        + Interestingly, neither the C standard, nor the C++ draft standard nor + the forthcoming C9X Committee Draft says directly whether you can + register a function with atexit during exit processing.

        + +

        + All 3 standards say that functions are run in reverse order of their + registration. Since f1 is registered last, it ought to be run first, + but by the time it is registered, it is too late to be first.

        + +

        If the program is valid, the standards are self-contradictory about + its semantics.

        + +

        Example 2: (C++ only)

        + +
            
        +     void F() { static T t; } // type T has a destructor
        + 
        +     int main()
        +     {
        +         atexit(F); // the only use of F
        +     }
        + 
        + +

        Function F registered with atexit has a local static variable t, + and F is called for the first time during exit processing. A local + static object is initialized the first time control flow passes + through its definition, and all static objects are destroyed during + exit processing. Is the code valid? If so, what are its semantics?

        + +

        + Section 18.3 "Start and termination" says that if a function + F is registered with atexit before a static object t is initialized, F + will not be called until after t's destructor completes.

        + +

        + In example 2, function F is registered with atexit before its local + static object O could possibly be initialized. On that basis, it must + not be called by exit processing until after O's destructor + completes. But the destructor cannot be run until after F is called, + since otherwise the object could not be constructed in the first + place.

        + +

        If the program is valid, the standard is self-contradictory about + its semantics.

        + +

        I plan to submit Example 1 as a public comment on the C9X CD, with + a recommendation that the results be undefined. (Alternative: make it + unspecified. I don't think it is worthwhile to specify the case where + f1 itself registers additional functions, each of which registers + still more functions.)

        + +

        I think we should resolve the situation in the whatever way the C + committee decides.

        + +

        For Example 2, I recommend we declare the results undefined.

        + +

        [See reflector message lib-6500 for further discussion.]

        + +

        Proposed resolution:

        +

        Change section 18.3/8 from:

        +
        + First, objects with static storage duration are destroyed and + functions registered by calling atexit are called. Objects with + static storage duration are destroyed in the reverse order of the + completion of their constructor. (Automatic objects are not + destroyed as a result of calling exit().) Functions registered with + atexit are called in the reverse order of their registration. A + function registered with atexit before an object obj1 of static + storage duration is initialized will not be called until obj1's + destruction has completed. A function registered with atexit after + an object obj2 of static storage duration is initialized will be + called before obj2's destruction starts. +
        +

        to:

        +
        + First, objects with static storage duration are destroyed and + functions registered by calling atexit are called. Non-local objects + with static storage duration are destroyed in the reverse order of + the completion of their constructor. (Automatic objects are not + destroyed as a result of calling exit().) Functions registered with + atexit are called in the reverse order of their registration, except + that a function is called after any previously registered functions + that had already been called at the time it was registered. A + function registered with atexit before a non-local object obj1 of + static storage duration is initialized will not be called until + obj1's destruction has completed. A function registered with atexit + after a non-local object obj2 of static storage duration is + initialized will be called before obj2's destruction starts. A local + static object obj3 is destroyed at the same time it would be if a + function calling the obj3 destructor were registered with atexit at + the completion of the obj3 constructor. +
        +

        Rationale:

        +

        See 99-0039/N1215, October 22, 1999, by Stephen D. Clamage for the analysis + supporting to the proposed resolution.

        +
        +

        5. String::compare specification questionable

        + Section: 21.3.6.8 [lib.string::compare]  Status: DR  Submitter: Jack Reeves  Date: 11 Dec 1997

        +

        At the very end of the basic_string class definition is the signature: int + compare(size_type pos1, size_type n1, const charT* s, size_type n2 = npos) const; In the + following text this is defined as: returns + basic_string<charT,traits,Allocator>(*this,pos1,n1).compare( + basic_string<charT,traits,Allocator>(s,n2);

        + +

        Since the constructor basic_string(const charT* s, size_type n, const Allocator& a + = Allocator()) clearly requires that s != NULL and n < npos and further states that it + throws length_error if n == npos, it appears the compare() signature above should always + throw length error if invoked like so: str.compare(1, str.size()-1, s); where 's' is some + null terminated character array.

        + +

        This appears to be a typo since the obvious intent is to allow either the call above or + something like: str.compare(1, str.size()-1, s, strlen(s)-1);

        + +

        This would imply that what was really intended was two signatures int compare(size_type + pos1, size_type n1, const charT* s) const int compare(size_type pos1, size_type n1, const + charT* s, size_type n2) const; each defined in terms of the corresponding constructor.

        +

        Proposed resolution:

        +

        Replace the compare signature in 21.3 + (at the very end of the basic_string synopsis) which reads:

        + +
        +

        int compare(size_type pos1, size_type n1,
        +             const charT* s, + size_type n2 = npos) const;

        +
        + +

        with:

        + +
        +

        int compare(size_type pos1, size_type n1,
        +             const charT* s) const;
        + int compare(size_type pos1, size_type n1,
        +             const charT* s, + size_type n2) const;

        +
        + +

        Replace the portion of 21.3.6.8 + paragraphs 5 and 6 which read:

        + +
        +

        + int compare(size_type pos, size_type n1,
        +             charT * s, size_type n2 + = npos) const;
        +
        Returns:
        + basic_string<charT,traits,Allocator>(*this, pos, n1).compare(
        +              + basic_string<charT,traits,Allocator>( s, n2))
        +

        +
        + +

        with:

        + +
        +

        + int compare(size_type pos, size_type n1,
        +             const charT * s) const;
        +
        Returns:
        + basic_string<charT,traits,Allocator>(*this, pos, n1).compare(
        +              + basic_string<charT,traits,Allocator>( s ))
        +
        + int compare(size_type pos, size_type n1,
        +             const charT * s, + size_type n2) const;
        +
        Returns:
        + basic_string<charT,traits,Allocator>(*this, pos, n1).compare(
        +              + basic_string<charT,traits,Allocator>( s, n2))
        +

        +
        + +

        Editors please note that in addition to splitting the signature, the third argument + becomes const, matching the existing synopsis.

        +

        Rationale:

        +

        While the LWG dislikes adding signatures, this is a clear defect in + the Standard which must be fixed.  The same problem was also + identified in issues 7 (item 5) and 87.

        +
        +

        7. String clause minor problems

        + Section: 21 [lib.strings]  Status: DR  Submitter: Matt Austern  Date: 15 Dec 1997

        +

        (1) In 21.3.5.4 , the description of template + <class InputIterator> insert(iterator, InputIterator, + InputIterator) makes no sense. It refers to a member function that + doesn't exist. It also talks about the return value of a void + function.

        + +

        (2) Several versions of basic_string::replace don't appear in the + class synopsis.

        + +

        (3) basic_string::push_back appears in the synopsis, but is never + described elsewhere. In the synopsis its argument is const charT, + which doesn't makes much sense; it should probably be charT, or + possible const charT&.

        + +

        (4) basic_string::pop_back is missing.

        + +

        (5) int compare(size_type pos, size_type n1, charT* s, size_type n2 + = npos) make no sense. First, it's const charT* in the synopsis and + charT* in the description. Second, given what it says in RETURNS, + leaving out the final argument will always result in an exception + getting thrown. This is paragraphs 5 and 6 of + 21.3.6.8

        + +

        (6) In table 37, in section 21.1.1 , + there's a note for X::move(s, p, n). It says "Copies correctly + even where p is in [s, s+n)". This is correct as far as it goes, + but it doesn't go far enough; it should also guarantee that the copy + is correct even where s in in [p, p+n). These are two orthogonal + guarantees, and neither one follows from the other. Both guarantees + are necessary if X::move is supposed to have the same sort of + semantics as memmove (which was clearly the intent), and both + guarantees are necessary if X::move is actually supposed to be + useful.

        +

        Proposed resolution:

        +

        ITEM 1: In 21.3.5.4 [lib.string::insert], change paragraph 16 to
        +
        +     EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).
        +
        + ITEM 2:  Not a defect; the Standard is clear.. There are ten versions of replace() in + the synopsis, and ten versions in 21.3.5.6 [lib.string::replace].
        +
        + ITEM 3: Change the declaration of push_back in the string synopsis (21.3, + [lib.basic.string]) from:

        + +

             void push_back(const charT)
        +
        + to
        +
        +      void push_back(charT)
        +
        + Add the following text immediately after 21.3.5.2 [lib.string::append], paragraph 10.
        +
        +     void basic_string::push_back(charT c);
        +     EFFECTS: Equivalent to append(static_cast<size_type>(1), c);
        +
        + ITEM 4: Not a defect. The omission appears to have been deliberate.
        +
        + ITEM 5: Duplicate; see issue 5 (and 87).
        +
        + ITEM 6: In table 37, Replace:
        +
        +     "Copies correctly even where p is in [s, s+n)."
        +
        + with:
        +
        +      "Copies correctly even where the ranges [p, p+n) and [s, + s+n) overlap."

        +
        +

        8. Locale::global lacks guarantee

        + Section: 22.1.1.5 [lib.locale.statics]  Status: DR  Submitter: Matt Austern  Date: 24 Dec 1997

        +

        It appears there's an important guarantee missing from clause + 22. We're told that invoking locale::global(L) sets the C locale if L + has a name. However, we're not told whether or not invoking + setlocale(s) sets the global C++ locale.

        + +

        The intent, I think, is that it should not, but I can't find any + such words anywhere.

        +

        Proposed resolution:

        +

        Add a sentence at the end of 22.1.1.5 , + paragraph 2: 

        + +
        +

        No library function other than locale::global() shall affect + the value returned by locale().

        + +
        +
        +

        9. Operator new(0) calls should not yield the same pointer

        + Section: 18.4.1 [lib.new.delete]  Status: DR  Submitter: Steve Clamage  Date: 4 Jan 1998

        +

        Scott Meyers, in a comp.std.c++ posting: I just noticed that + section 3.7.3.1 of CD2 seems to allow for the possibility that all + calls to operator new(0) yield the same pointer, an implementation + technique specifically prohibited by ARM 5.3.3.Was this prohibition + really lifted? Does the FDIS agree with CD2 in the regard? [Issues + list maintainer's note: the IS is the same.]

        +

        Proposed resolution:

        +

        Change the last paragraph of 3.7.3 from:

        +
        +

        Any allocation and/or deallocation functions defined in a C++ program shall + conform to the semantics specified in 3.7.3.1 and 3.7.3.2.

        +
        +

        to:

        +
        +

        Any allocation and/or deallocation functions defined in a C++ program, + including the default versions in the library, shall conform to the semantics + specified in 3.7.3.1 and 3.7.3.2.

        +
        +

        Change 3.7.3.1/2, next-to-last sentence, from :

        +
        +

        If the size of the space requested is zero, the value returned shall not be + a null pointer value (4.10).

        +
        +

        to:

        +
        +

        Even if the size of the space requested is zero, the request can fail. If + the request succeeds, the value returned shall be a non-null pointer value + (4.10) p0 different from any previously returned value p1, unless that value + p1 was since passed to an operator delete.

        +
        +

        5.3.4/7 currently reads:

        +
        +

        When the value of the expression in a direct-new-declarator is zero, the + allocation function is called to allocate an array with no elements. The + pointer returned by the new-expression is non-null. [Note: If the library + allocation function is called, the pointer returned is distinct from the + pointer to any other object.]

        +
        +

        Retain the first sentence, and delete the remainder.

        +

        18.4.1 currently has no text. Add the following:

        +
        +

        Except where otherwise specified, the provisions of 3.7.3 apply to the + library versions of operator new and operator delete.

        +
        +

        To 18.4.1.3, add the following text:

        +
        +

        The provisions of 3.7.3 do not apply to these reserved placement forms of + operator new and operator delete.

        +
        +

        Rationale:

        +

        See 99-0040/N1216, October 22, 1999, by Stephen D. Clamage for the analysis + supporting to the proposed resolution.

        +
        +

        11. Bitset minor problems

        + Section: 23.3.5 [lib.template.bitset]  Status: DR  Submitter: Matt Austern  Date: 22 Jan 1998

        +

        (1) bitset<>::operator[] is mentioned in the class synopsis (23.3.5), but it is + not documented in 23.3.5.2.

        + +

        (2) The class synopsis only gives a single signature for bitset<>::operator[], + reference operator[](size_t pos). This doesn't make much sense. It ought to be overloaded + on const. reference operator[](size_t pos); bool operator[](size_t pos) const.

        + +

        (3) Bitset's stream input function (23.3.5.3) ought to skip all whitespace before + trying to extract 0s and 1s. The standard doesn't explicitly say that, though. This should + go in the Effects clause.

        +

        Proposed resolution:

        +

        ITEMS 1 AND 2:
        +
        + In the bitset synopsis (23.3.5 ), + replace the member function
        +
        +     reference operator[](size_t pos);
        +

        + with the two member functions
        +
        +     bool operator[](size_t pos) const;
        +     reference operator[](size_t pos);
        +

        + Add the following text at the end of 23.3.5.2 , + immediately after paragraph 45:

        + +
        +

        + bool operator[](size_t pos) const;
        + Requires: pos is valid
        + Throws: nothing
        + Returns: test(pos)
        +
        + bitset<N>::reference operator[](size_t pos);
        + Requires: pos is valid
        + Throws: nothing
        + Returns: An object of type bitset<N>::reference such that (*this)[pos] + == this->test(pos), and such that (*this)[pos] = val is equivalent to this->set(pos, + val); +

        +
        +

        Rationale:

        +

        The LWG believes Item 3 is not a defect. "Formatted + input" implies the desired semantics. See 27.6.1.2 . +

        +
        +

        13. Eos refuses to die

        + Section: 27.6.1.2.3 [lib.istream::extractors]  Status: DR  Submitter: William M. Miller  Date: 3 Mar 1998

        +

        In 27.6.1.2.3, there is a reference to "eos", which is + the only one in the whole draft (at least using Acrobat search), so + it's undefined.

        +

        Proposed resolution:

        +

        In 27.6.1.2.3 , replace "eos" with + "charT()"

        +
        +

        14. Locale::combine should be const

        + Section: 22.1.1.3 [lib.locale.members]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        locale::combine is the only member function of locale (other than constructors and + destructor) that is not const. There is no reason for it not to be const, and good reasons + why it should have been const. Furthermore, leaving it non-const conflicts with 22.1.1 + paragraph 6: "An instance of a locale is immutable."

        + +

        History: this member function originally was a constructor. it happened that the + interface it specified had no corresponding language syntax, so it was changed to a member + function. As constructors are never const, there was no "const" in the interface + which was transformed into member "combine". It should have been added at that + time, but the omission was not noticed.

        +

        Proposed resolution:

        +

        In 22.1.1 and also in 22.1.1.3 , add + "const" to the declaration of member combine:

        +
        +
        template <class Facet> locale combine(const locale& other) const; 
        +
        +
        +

        15. Locale::name requirement inconsistent

        + Section: 22.1.1.3 [lib.locale.members]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        locale::name() is described as returning a string that can be passed to a locale + constructor, but there is no matching constructor.

        +

        Proposed resolution:

        +

        In 22.1.1.3 , paragraph 5, replace + "locale(name())" with + "locale(name().c_str())". +

        +
        +

        16. Bad ctype_byname<char> decl

        + Section: 22.2.1.4 [lib.locale.ctype.byname.special]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        The new virtual members ctype_byname<char>::do_widen and do_narrow did not get + edited in properly. Instead, the member do_widen appears four times, with wrong argument + lists.

        +

        Proposed resolution:

        +

        The correct declarations for the overloaded members + do_narrow and do_widen should be copied + from 22.2.1.3 .

        +
        +

        17. Bad bool parsing

        + Section: 22.2.2.1.2 [lib.facet.num.get.virtuals]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        This section describes the process of parsing a text boolean value from the input + stream. It does not say it recognizes either of the sequences "true" or + "false" and returns the corresponding bool value; instead, it says it recognizes + only one of those sequences, and chooses which according to the received value of a + reference argument intended for returning the result, and reports an error if the other + sequence is found. (!) Furthermore, it claims to get the names from the ctype<> + facet rather than the numpunct<> facet, and it examines the "boolalpha" + flag wrongly; it doesn't define the value "loc"; and finally, it computes + wrongly whether to use numeric or "alpha" parsing.
        +
        + I believe the correct algorithm is "as if":

        + +
          // in, err, val, and str are arguments.
        +   err = 0;
        +   const numpunct<charT>& np = use_facet<numpunct<charT> >(str.getloc());
        +   const string_type t = np.truename(), f = np.falsename();
        +   bool tm = true, fm = true;
        +   size_t pos = 0;
        +   while (tm && pos < t.size() || fm && pos < f.size()) {
        +     if (in == end) { err = str.eofbit; }
        +     bool matched = false;
        +     if (tm && pos < t.size()) {
        +       if (!err && t[pos] == *in) matched = true;
        +       else tm = false;
        +     }
        +     if (fm && pos < f.size()) {
        +       if (!err && f[pos] == *in) matched = true;
        +       else fm = false;
        +     }
        +     if (matched) { ++in; ++pos; }
        +     if (pos > t.size()) tm = false;
        +     if (pos > f.size()) fm = false;
        +   }
        +   if (tm == fm || pos == 0) { err |= str.failbit; }
        +   else                      { val = tm; }
        +   return in;
        + +

        Notice this works reasonably when the candidate strings are both empty, or equal, or + when one is a substring of the other. The proposed text below captures the logic of the + code above.

        +

        Proposed resolution:

        +

        In 22.2.2.1.2 , in the first line of paragraph 14, + change "&&" to "&".

        + +

        Then, replace paragraphs 15 and 16 as follows:

        + +
        + +

        Otherwise target sequences are determined "as if" by + calling the members falsename() and + truename() of the facet obtained by + use_facet<numpunct<charT> >(str.getloc()). + Successive characters in the range [in,end) (see + [lib.sequence.reqmts]) are obtained and matched against + corresponding positions in the target sequences only as necessary to + identify a unique match. The input iterator in is + compared to end only when necessary to obtain a + character. If and only if a target sequence is uniquely matched, + val is set to the corresponding value.

        + +
        + +
        +

        The in iterator is always left pointing one position beyond the last character + successfully matched. If val is set, then err is set to str.goodbit; or to + str.eofbit if, when seeking another character to match, it is found that + (in==end). If val is not set, then err is set to str.failbit; or to + (str.failbit|str.eofbit)if + the reason for the failure was that (in==end). [Example: for targets + true:"a" and false:"abb", the input sequence "a" yields + val==true and err==str.eofbit; the input sequence "abc" yields + err=str.failbit, with in ending at the 'c' element. For targets + true:"1" + and false:"0", the input sequence "1" yields val==true + and err=str.goodbit. For empty targets (""), any input sequence yields + err==str.failbit. --end example]

        +
        +
        +

        18. Get(...bool&) omitted

        + Section: 22.2.2.1.1 [lib.facet.num.get.members]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        In the list of num_get<> non-virtual members on page 22-23, the member + that parses bool values was omitted from the list of definitions of non-virtual + members, though it is listed in the class definition and the corresponding + virtual is listed everywhere appropriate.

        +

        Proposed resolution:

        +

        Add at the beginning of 22.2.2.1.1 + another get member for bool&, copied from the entry in + 22.2.2.1 .

        +
        +

        19. "Noconv" definition too vague

        + Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        + In the definitions of codecvt<>::do_out and do_in, they are + specified to return noconv if "no conversion is + needed". This definition is too vague, and does not say + normatively what is done with the buffers. +

        +

        Proposed resolution:

        +

        + Change the entry for noconv in the table under paragraph 4 in section + 22.2.1.5.2 to read: +

        +
        +

        + noconv: internT and externT are the same type, + and input sequence is identical to converted sequence.

        +
        +

        Change the Note in paragraph 2 to normative text as follows:

        +
        +

        If returns noconv, internT and externT are the + same type and the converted sequence is identical to the input sequence [from,from_next). + to_next is set equal to to, the value of state is + unchanged, and there are no changes to the values in [to, to_limit).

        +
        +
        +

        20. Thousands_sep returns wrong type

        + Section: 22.2.3.1.2 [lib.facet.numpunct.virtuals]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        The synopsis for numpunct<>::do_thousands_sep, and the + definition of numpunct<>::thousands_sep which calls it, specify + that it returns a value of type char_type. Here it is erroneously + described as returning a "string_type".

        +

        Proposed resolution:

        +

        In 22.2.3.1.2 , above paragraph 2, change + "string_type" to "char_type".

        +
        +

        21. Codecvt_byname<> instantiations

        + Section: 22.1.1.1.1 [lib.locale.category]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        In the second table in the section, captioned "Required + instantiations", the instantiations for codecvt_byname<> + have been omitted. These are necessary to allow users to construct a + locale by name from facets.

        +

        Proposed resolution:

        +

        Add in 22.1.1.1.1 to the table captioned + "Required instantiations", in the category "ctype" + the lines

        + +
        +
        codecvt_byname<char,char,mbstate_t>,
        + codecvt_byname<wchar_t,char,mbstate_t> 
        +
        +
        +

        22. Member open vs. flags

        + Section: 27.8.1.7 [lib.ifstream.members]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        The description of basic_istream<>::open leaves unanswered questions about how it + responds to or changes flags in the error status for the stream. A strict reading + indicates that it ignores the bits and does not change them, which confuses users who do + not expect eofbit and failbit to remain set after a successful open. There are three + reasonable resolutions: 1) status quo 2) fail if fail(), ignore eofbit 3) clear failbit + and eofbit on call to open().

        +

        Proposed resolution:

        +

        In 27.8.1.7 paragraph 3, and in 27.8.1.10 paragraph 3, under open() effects, add a footnote: +

        + +
        +

        A successful open does not change the error state.

        +
        +
        +

        24. "do_convert" doesn't exist

        + Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        The description of codecvt<>::do_out and do_in mentions a + symbol "do_convert" which is not defined in the + standard. This is a leftover from an edit, and should be "do_in + and do_out".

        +

        Proposed resolution:

        +

        In 22.2.1.5 , paragraph 3, change + "do_convert" to "do_in or do_out". Also, in 22.2.1.5.2 , change "do_convert()" to "do_in + or do_out".

        +
        +

        25. String operator<< uses width() value wrong

        + Section: 21.3.7.9 [lib.string.io]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        In the description of operator<< applied to strings, the standard says that uses + the smaller of os.width() and str.size(), to pad "as described in stage 3" + elsewhere; but this is inconsistent, as this allows no possibility of space for padding.

        +

        Proposed resolution:

        +

        Change 21.3.7.9 paragraph 4 from:
        +
        +     "... where n is the smaller of os.width() and str.size(); + ..."
        +
        + to:
        +
        +     "... where n is the larger of os.width() and str.size(); + ..."

        +
        +

        26. Bad sentry example

        + Section: 27.6.1.1.2 [lib.istream::sentry]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        In paragraph 6, the code in the example:

        + +
          template <class charT, class traits = char_traits<charT> >
        +   basic_istream<charT,traits>::sentry(
        +            basic_istream<charT,traits>& is, bool noskipws = false) {
        +       ...
        +       int_type c;
        +       typedef ctype<charT> ctype_type;
        +       const ctype_type& ctype = use_facet<ctype_type>(is.getloc());
        +       while ((c = is.rdbuf()->snextc()) != traits::eof()) {
        +         if (ctype.is(ctype.space,c)==0) {
        +           is.rdbuf()->sputbackc (c);
        +           break;
        +         }
        +       }
        +       ...
        +    }
        + +

        fails to demonstrate correct use of the facilities described. In + particular, it fails to use traits operators, and specifies incorrect + semantics. (E.g. it specifies skipping over the first character in the + sequence without examining it.)

        +

        Proposed resolution:

        +

        Remove the example above from 27.6.1.1.2 + paragraph 6.

        +

        Rationale:

        +

        The originally proposed replacement code for the example was not + correct. The LWG tried in Kona and again in Tokyo to correct it + without success. In Tokyo, an implementor reported that actual working + code ran over one page in length and was quite complicated. The LWG + decided that it would be counter-productive to include such a lengthy + example, which might well still contain errors.

        +
        +

        27. String::erase(range) yields wrong iterator

        + Section: 21.3.5.5 [lib.string::erase]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        The string::erase(iterator first, iterator last) is specified to return an element one + place beyond the next element after the last one erased. E.g. for the string + "abcde", erasing the range ['b'..'d') would yield an iterator for element 'e', + while 'd' has not been erased.

        +

        Proposed resolution:

        +

        In 21.3.5.5 , paragraph 10, change:

        + +
        +

        Returns: an iterator which points to the element immediately following _last_ prior to + the element being erased.

        +
        + +

        to read

        + +
        +

        Returns: an iterator which points to the element pointed to by _last_ prior to the + other elements being erased.

        +
        +
        +

        28. Ctype<char>is ambiguous

        + Section: 22.2.1.3.2 [lib.facet.ctype.char.members]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        The description of the vector form of ctype<char>::is can be interpreted to mean + something very different from what was intended. Paragraph 4 says

        + +
        +

        Effects: The second form, for all *p in the range [low, high), assigns vec[p-low] to + table()[(unsigned char)*p].

        +
        + +

        This is intended to copy the value indexed from table()[] into the place identified in + vec[].

        +

        Proposed resolution:

        +

        Change 22.2.1.3.2 , paragraph 4, to read

        + +
        +

        Effects: The second form, for all *p in the range [low, high), assigns into vec[p-low] + the value table()[(unsigned char)*p].

        +
        +
        +

        29. Ios_base::init doesn't exist

        + Section: 27.3.1 [lib.narrow.stream.objects]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        Sections 27.3.1 and 27.3.2 mention + a function ios_base::init, which is not defined. Probably they mean + basic_ios<>::init, defined in 27.4.4.1 , + paragraph 3.

        +

        Proposed resolution:

        +

        [R12: modified to include paragraph 5.]

        + +

        In 27.3.1 paragraph 2 and 5, change

        + +
        +

        ios_base::init

        +
        + +

        to

        + +
        +

        basic_ios<char>::init

        +
        + +

        Also, make a similar change in 27.3.2 except it + should read

        + +
        +

        basic_ios<wchar_t>::init

        +
        +
        +

        30. Wrong header for LC_*

        + Section: 22.1.1.1.1 [lib.locale.category]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        Paragraph 2 implies that the C macros LC_CTYPE etc. are defined in <cctype>, + where they are in fact defined elsewhere to appear in <clocale>.

        +

        Proposed resolution:

        +

        In 22.1.1.1.1 , paragraph 2, change + "<cctype>" to read "<clocale>".

        +
        +

        31. Immutable locale values

        + Section: 22.1.1 [lib.locale]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        Paragraph 6, says "An instance of locale is + immutable; once a facet reference is obtained from it, + ...". This has caused some confusion, because locale variables + are manifestly assignable.

        +

        Proposed resolution:

        +

        In 22.1.1 replace paragraph 6

        + +
        +

        An instance of locale is immutable; once a facet + reference is obtained from it, that reference remains usable as long + as the locale value itself exists.

        +
        + +

        with

        + +
        +

        Once a facet reference is obtained from a locale object by + calling use_facet<>, that reference remains usable, and the + results from member functions of it may be cached and re-used, as + long as some locale object refers to that facet.

        +
        +
        +

        32. Pbackfail description inconsistent

        + Section: 27.5.2.4.4 [lib.streambuf.virt.pback]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        The description of the required state before calling virtual member + basic_streambuf<>::pbackfail requirements is inconsistent with the conditions + described in 27.5.2.2.4 [lib.streambuf.pub.pback] where member sputbackc calls it. + Specifically, the latter says it calls pbackfail if:

        + +

            traits::eq(c,gptr()[-1]) is false

        + +

        where pbackfail claims to require:

        + +

            traits::eq(*gptr(),traits::to_char_type(c)) returns false

        + +

        It appears that the pbackfail description is wrong.

        +

        Proposed resolution:

        +

        In 27.5.2.4.4 , paragraph 1, change:

        + +
        +

        "traits::eq(*gptr(),traits::to_char_type( c))"

        +
        + +

        to

        + +
        +

        "traits::eq(traits::to_char_type(c),gptr()[-1])" +

        +
        +

        Rationale:

        +

        Note deliberate reordering of arguments for clarity in addition to the correction of + the argument value.

        +
        +

        33. Codecvt<> mentions from_type

        + Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        In the table defining the results from do_out and do_in, the specification for the + result error says

        + +
        +

        encountered a from_type character it could not convert

        +
        + +

        but from_type is not defined. This clearly is intended to be an externT for do_in, or + an internT for do_out.

        +

        Proposed resolution:

        +

        In 22.2.1.5.2 paragraph 4, replace the definition + in the table for the case of _error_ with

        + +
        +

        encountered a character in [from,from_end) that it could not convert.

        +
        +
        +

        34. True/falsename() not in ctype<>

        + Section: 22.2.2.2.2 [lib.facet.num.put.virtuals]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        In paragraph 19, Effects:, members truename() and falsename are used from facet + ctype<charT>, but it has no such members. Note that this is also a problem in + 22.2.2.1.2, addressed in (4).

        +

        Proposed resolution:

        +

        In 22.2.2.2.2 , paragraph 19, in the Effects: + clause for member put(...., bool), replace the initialization of the + string_type value s as follows:

        + +
        +
        const numpunct& np = use_facet<numpunct<charT> >(loc);
        + string_type s = val ? np.truename() : np.falsename(); 
        +
        +
        +

        35. No manipulator unitbuf in synopsis

        + Section: 27.4 [lib.iostreams.base]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        In 27.4.5.1 , we have a definition for a manipulator + named "unitbuf". Unlike other manipulators, it's not listed + in synopsis. Similarly for "nounitbuf".

        +

        Proposed resolution:

        +

        Add to the synopsis for <ios> in 27.4 , after + the entry for "nouppercase", the prototypes:

        + +
        +
        ios_base& unitbuf(ios_base& str);
        + ios_base& nounitbuf(ios_base& str); 
        +
        +
        +

        36. Iword & pword storage lifetime omitted

        + Section: 27.4.2.5 [lib.ios.base.storage]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        In the definitions for ios_base::iword and pword, the lifetime of the storage is + specified badly, so that an implementation which only keeps the last value stored appears + to conform. In particular, it says:

        + +

        The reference returned may become invalid after another call to the object's iword + member with a different index ...

        + +

        This is not idle speculation; at least one implementation was done this way.

        +

        Proposed resolution:

        +

        Add in 27.4.2.5 , in both paragraph 2 and also in + paragraph 4, replace the sentence:

        + +
        +

        The reference returned may become invalid after another call to the object's iword + [pword] member with a different index, after a call to its copyfmt member, or when the + object is destroyed.

        +
        + +

        with:

        + +
        +

        The reference returned is invalid after any other operations on the object. However, + the value of the storage referred to is retained, so that until the next call to copyfmt, + calling iword [pword] with the same index yields another reference to the same value.

        +
        + +

        substituting "iword" or "pword" as appropriate.

        +
        +

        37. Leftover "global" reference

        + Section: 22.1.1 [lib.locale]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        In the overview of locale semantics, paragraph 4, is the sentence

        + +
        +

        If Facet is not present in a locale (or, failing that, in the global locale), it throws + the standard exception bad_cast.

        +
        + +

        This is not supported by the definition of use_facet<>, and represents semantics + from an old draft.

        +

        Proposed resolution:

        +

        In 22.1.1 , paragraph 4, delete the parenthesized + expression

        + +
        +

        (or, failing that, in the global locale)

        +
        +
        +

        38. Facet definition incomplete

        + Section: 22.1.2 [lib.locale.global.templates]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        It has been noticed by Esa Pulkkinen that the definition of + "facet" is incomplete. In particular, a class derived from + another facet, but which does not define a member id, cannot + safely serve as the argument F to use_facet<F>(loc), + because there is no guarantee that a reference to the facet instance + stored in loc is safely convertible to F.

        +

        Proposed resolution:

        +

        In the definition of std::use_facet<>(), replace the text in paragraph 1 which + reads:

        + +
        +

        Get a reference to a facet of a locale.

        +
        + +

        with:

        + +
        +

        Requires: Facet is a facet class whose definition + contains the public static member id as defined in 22.1.1.1.2 .

        +
        + +

        [ + Kona: strike as overspecification the text "(not inherits)" + from the original resolution, which read "... whose definition + contains (not inherits) the public static member + id..." + ]

        + +
        +

        39. istreambuf_iterator<>::operator++(int) definition garbled

        + Section: 24.5.3.4 [lib.istreambuf.iterator::op++]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        Following the definition of istreambuf_iterator<>::operator++(int) in paragraph + 3, the standard contains three lines of garbage text left over from a previous edit.

        + +
        +
        istreambuf_iterator<charT,traits> tmp = *this;
        + sbuf_->sbumpc();
        + return(tmp); 
        +
        +

        Proposed resolution:

        +

        In 24.5.3.4 , delete the three lines of code at the + end of paragraph 3.

        +
        +

        40. Meaningless normative paragraph in examples

        + Section: 22.2.8 [lib.facets.examples]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        Paragraph 3 of the locale examples is a description of part of an + implementation technique that has lost its referent, and doesn't mean + anything.

        +

        Proposed resolution:

        +

        Delete 22.2.8 paragraph 3 which begins "This + initialization/identification system depends...", or (at the + editor's option) replace it with a place-holder to keep the paragraph + numbering the same.

        +
        +

        41. Ios_base needs clear(), exceptions()

        + Section: 27.4.2 [lib.ios.base]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        The description of ios_base::iword() and pword() in 27.4.2.4 , say that if they fail, they "set badbit, + which may throw an exception". However, ios_base offers no + interface to set or to test badbit; those interfaces are defined in + basic_ios<>.

        +

        Proposed resolution:

        +

        Change the description in 27.4.2.5 in + paragraph 2, and also in paragraph 4, as follows. Replace

        + +
        +

        If the function fails it sets badbit, which may throw an exception.

        +
        + +

        with

        + +
        +

        If the function fails, and *this is a base sub-object of + a basic_ios<> object or sub-object, the effect is + equivalent to calling basic_ios<>::setstate(badbit) + on the derived object (which may throw failure).

        +
        + +

        [Kona: LWG reviewed wording; setstate(failbit) changed to + setstate(badbit).]

        + +
        +

        42. String ctors specify wrong default allocator

        + Section: 21.3 [lib.basic.string]  Status: DR  Submitter: Nathan Myers  Date: 6 Aug 1998

        +

        The basic_string<> copy constructor:

        + +
        basic_string(const basic_string& str, size_type pos = 0,
        +              size_type n = npos, const Allocator& a = Allocator()); 
        + +

        specifies an Allocator argument default value that is + counter-intuitive. The natural choice for a the allocator to copy from + is str.get_allocator(). Though this cannot be expressed in + default-argument notation, overloading suffices.

        + +

        Alternatively, the other containers in Clause 23 (deque, list, + vector) do not have this form of constructor, so it is inconsistent, + and an evident source of confusion, for basic_string<> to have + it, so it might better be removed.

        +

        Proposed resolution:

        +

        In 21.3 , replace the declaration of the copy + constructor as follows:

        + +
        +
        basic_string(const basic_string& str);
        + basic_string(const basic_string& str, size_type pos, size_type n = npos,
        +              const Allocator& a = Allocator());
        +
        + +

        In 21.3.1 , replace the copy constructor declaration + as above. Add to paragraph 5, Effects:

        + +
        +

        In the first form, the Allocator value used is copied from + str.get_allocator().

        +
        +

        Rationale:

        +

        The LWG believes the constructor is actually broken, rather than + just an unfortunate design choice.

        + +

        The LWG considered two other possible resolutions:

        + +

        A. In 21.3 , replace the declaration of the copy + constructor as follows:

        + +
        +
        basic_string(const basic_string& str, size_type pos = 0,
        +              size_type n = npos);
        + basic_string(const basic_string& str, size_type pos,
        +              size_type n, const Allocator& a); 
        +
        + +

        In 21.3.1 , replace the copy constructor declaration + as above. Add to paragraph 5, Effects:

        + +
        +

        When no Allocator argument is provided, the string is constructed using the + value str.get_allocator().

        +
        + +

        B. In 21.3 , and also in 21.3.1 , replace + the declaration of the copy constructor as follows:

        + +
        +
        basic_string(const basic_string& str, size_type pos = 0,
        +              size_type n = npos); 
        +
        + +

        The proposed resolution reflects the original intent of the LWG. It + was also noted by Pete Becker that this fix "will cause + a small amount of existing code to now work correctly."

        + +

        [ + Kona: issue editing snafu fixed - the proposed resolution now correctly + reflects the LWG consensus. + ]

        +
        +

        46. Minor Annex D errors

        + Section: D.7 [depr.str.strstreams]  Status: DR  Submitter: Brendan Kehoe  Date:  1 Jun 1998

        +

        See lib-6522 and edit-814.

        +

        Proposed resolution:

        +

        Change D.7.1 (since streambuf is a typedef of + basic_streambuf<char>) from:

        + +
                 virtual streambuf<char>* setbuf(char* s, streamsize n);
        + +

        to:

        + +
                 virtual streambuf* setbuf(char* s, streamsize n);
        + +

        In D.7.4 insert the semicolon now missing after + int_type:

        + +
             namespace std {
        +        class strstream
        +          : public basic_iostream<char> {
        +        public:
        +          // Types
        +          typedef char                                char_type;
        +          typedef typename char_traits<char>::int_type int_type
        +          typedef typename char_traits<char>::pos_type pos_type;
        +
        +

        47. Imbue() and getloc() Returns clauses swapped

        + Section: 27.4.2.3 [lib.ios.base.locales]  Status: DR  Submitter: Matt Austern  Date: 21 Jun 1998

        +

        Section 27.4.2.3 specifies how imbue() and getloc() work. That + section has two RETURNS clauses, and they make no sense as + stated. They make perfect sense, though, if you swap them. Am I + correct in thinking that paragraphs 2 and 4 just got mixed up by + accident?

        +

        Proposed resolution:

        +

        In 27.4.2.3 swap paragraphs 2 and 4.

        +
        +

        48. Use of non-existent exception constructor

        + Section: 27.4.2.1.1 [lib.ios::failure]  Status: DR  Submitter: Matt Austern  Date: 21 Jun 1998

        +

        27.4.2.1.1, paragraph 2, says that class failure initializes the + base class, exception, with exception(msg). Class exception (see + 18.6.1) has no such constructor.

        +

        Proposed resolution:

        +

        Replace 27.4.2.1.1 , paragraph 2, with

        + +
        +

        EFFECTS: Constructs an object of class failure.

        +
        +
        +

        50. Copy constructor and assignment operator of ios_base

        + Section: 27.4.2 [lib.ios.base]  Status: DR  Submitter: Matt Austern  Date: 21 Jun 1998

        +

        As written, ios_base has a copy constructor and an assignment + operator. (Nothing in the standard says it doesn't have one, and all + classes have copy constructors and assignment operators unless you + take specific steps to avoid them.) However, nothing in 27.4.2 says + what the copy constructor and assignment operator do.

        + +

        My guess is that this was an oversight, that ios_base is, like + basic_ios, not supposed to have a copy constructor or an assignment + operator.

        + +

        + Jerry Schwarz comments: Yes, its an oversight, but in the opposite + sense to what you're suggesting. At one point there was a definite + intention that you could copy ios_base. It's an easy way to save the + entire state of a stream for future use. As you note, to carry out + that intention would have required a explicit description of the + semantics (e.g. what happens to the iarray and parray stuff). +

        +

        Proposed resolution:

        +

        In 27.4.2 , class ios_base, specify the copy + constructor and operator= members as being private.

        +

        Rationale:

        +

        The LWG believes the difficulty of specifying correct semantics + outweighs any benefit of allowing ios_base objects to be copyable.

        +
        +

        51. Requirement to not invalidate iterators missing

        + Section: 23.1 [lib.container.requirements]  Status: DR  Submitter: David Vandevoorde  Date: 23 Jun 1998

        +

        The std::sort algorithm can in general only sort a given sequence + by moving around values. The list<>::sort() member on the other + hand could move around values or just update internal pointers. Either + method can leave iterators into the list<> dereferencable, but + they would point to different things.

        + +

        Does the FDIS mandate anywhere which method should be used for + list<>::sort()?

        + +

        Matt Austern comments:

        + +

        I think you've found an omission in the standard.

        + +

        The library working group discussed this point, and there was + supposed to be a general requirement saying that list, set, map, + multiset, and multimap may not invalidate iterators, or change the + values that iterators point to, except when an operation does it + explicitly. So, for example, insert() doesn't invalidate any iterators + and erase() and remove() only invalidate iterators pointing to the + elements that are being erased.

        + +

        I looked for that general requirement in the FDIS, and, while I + found a limited form of it for the sorted associative containers, I + didn't find it for list. It looks like it just got omitted.

        + +

        The intention, though, is that list<>::sort does not + invalidate any iterators and does not change the values that any + iterator points to. There would be no reason to have the member + function otherwise.

        +

        Proposed resolution:

        +

        Add a new paragraph at the end of 23.1:

        + +
        +

        Unless otherwise specified (either explicitly or by defining a function in terms of + other functions), invoking a container member function or passing a container as an + argument to a library function shall not invalidate iterators to, or change the values of, + objects within that container.

        +
        +

        Rationale:

        +

        This was US issue CD2-23-011; it was accepted in London but the + change was not made due to an editing oversight. The wording in the + proposed resolution below is somewhat updated from CD2-23-011, + particularly the addition of the phrase "or change the values + of"

        +
        +

        52. Small I/O problems

        + Section: 27.4.3.2 [lib.fpos.operations]  Status: DR  Submitter: Matt Austern  Date: 23 Jun 1998

        +

        First, 27.4.4.1 , table 89. This is pretty obvious: + it should be titled "basic_ios<>() effects", not + "ios_base() effects".

        + +

        [The second item is a duplicate; see issue 6 for + resolution.]

        + +

        Second, 27.4.3.2 table 88 . There are a couple + different things wrong with it, some of which I've already discussed + with Jerry, but the most obvious mechanical sort of error is that it + uses expressions like P(i) and p(i), without ever defining what sort + of thing "i" is. +

        + +

        (The other problem is that it requires support for streampos + arithmetic. This is impossible on some systems, i.e. ones where file + position is a complicated structure rather than just a number. Jerry + tells me that the intention was to require syntactic support for + streampos arithmetic, but that it wasn't actually supposed to do + anything meaningful except on platforms, like Unix, where genuine + arithmetic is possible.)

        +

        Proposed resolution:

        +

        Change 27.4.4.1 table 89 title from + "ios_base() effects" to "basic_ios<>() + effects".

        +
        +

        53. Basic_ios destructor unspecified

        + Section: 27.4.4.1 [lib.basic.ios.cons]  Status: DR  Submitter: Matt Austern  Date: 23 Jun 1998

        +

        There's nothing in 27.4.4 saying what basic_ios's destructor does. + The important question is whether basic_ios::~basic_ios() destroys + rdbuf().

        +

        Proposed resolution:

        +

        Add after 27.4.4.1 paragraph 2:

        + +
        +

        virtual ~basic_ios();

        +

        + Notes: The destructor does not destroy rdbuf().

        +
        +

        Rationale:

        +

        The LWG reviewed the additional question of whether or not + rdbuf(0) may set badbit. The answer is + clearly yes; it may be set via clear(). See 27.4.4.2 , paragraph 6. This issue was reviewed at length + by the LWG, which removed from the original proposed resolution a + footnote which incorrectly said "rdbuf(0) does not set + badbit".

        +
        +

        54. Basic_streambuf's destructor

        + Section: 27.5.2.1 [lib.streambuf.cons]  Status: DR  Submitter: Matt Austern  Date: 25 Jun 1998

        +

        The class synopsis for basic_streambuf shows a (virtual) + destructor, but the standard doesn't say what that destructor does. My + assumption is that it does nothing, but the standard should say so + explicitly.

        +

        Proposed resolution:

        +

        Add after 27.5.2.1 paragraph 2:

        + +
        +

        virtual  ~basic_streambuf();

        +

        + Effects: None.

        +
        +
        +

        55. Invalid stream position is undefined

        + Section: 27 [lib.input.output]  Status: DR  Submitter: Matt Austern  Date: 26 Jun 1998

        +

        Several member functions in clause 27 are defined in certain + circumstances to return an "invalid stream position", a term + that is defined nowhere in the standard. Two places (27.5.2.4.2, + paragraph 4, and 27.8.1.4, paragraph 15) contain a cross-reference to + a definition in _lib.iostreams.definitions_, a nonexistent + section.

        + +

        I suspect that the invalid stream position is just supposed to be + pos_type(-1). Probably best to say explicitly in (for example) + 27.5.2.4.2 that the return value is pos_type(-1), rather than to use + the term "invalid stream position", define that term + somewhere, and then put in a cross-reference.

        + +

        The phrase "invalid stream position" appears ten times in + the C++ Standard. In seven places it refers to a return value, and it + should be changed. In three places it refers to an argument, and it + should not be changed. Here are the three places where "invalid + stream position" should not be changed:

        + +
        +

        27.7.1.3 , paragraph 14
        + 27.8.1.4 , paragraph 14
        + D.7.1.3 , paragraph 17 + [lib.stringbuf.virtuals] +

        +
        +

        Proposed resolution:

        +

        In 27.5.2.4.2 , paragraph 4, change "Returns an + object of class pos_type that stores an invalid stream position + (_lib.iostreams.definitions_)" to "Returns + pos_type(off_type(-1))". +

        + +

        In 27.5.2.4.2 , paragraph 6, change "Returns + an object of class pos_type that stores an invalid stream + position" to "Returns pos_type(off_type(-1))".

        + +

        In 27.7.1.3 , paragraph 13, change "the object + stores an invalid stream position" to "the return value is + pos_type(off_type(-1))".

        + +

        In 27.8.1.4 , paragraph 13, change "returns an + invalid stream position (27.4.3)" to "returns + pos_type(off_type(-1))"

        + +

        In 27.8.1.4 , paragraph 15, change "Otherwise + returns an invalid stream position (_lib.iostreams.definitions_)" + to "Otherwise returns pos_type(off_type(-1))" +

        + +

        In D.7.1.3 , paragraph 15, change "the object + stores an invalid stream position" to "the return value is + pos_type(off_type(-1))"

        + +

        In D.7.1.3 , paragraph 18, change "the object + stores an invalid stream position" to "the return value is + pos_type(off_type(-1))"

        +
        +

        56. Showmanyc's return type

        + Section: 27.5.2 [lib.streambuf]  Status: DR  Submitter: Matt Austern  Date: 29 Jun 1998

        +

        The class summary for basic_streambuf<>, in 27.5.2, says that + showmanyc has return type int. However, 27.5.2.4.3 says that its + return type is streamsize.

        +

        Proposed resolution:

        +

        Change showmanyc's return type in the + 27.5.2 class summary to streamsize.

        +
        +

        57. Mistake in char_traits

        + Section: 21.1.3.2 [lib.char.traits.specializations.wchar.t]  Status: DR  Submitter: Matt Austern  Date: 1 Jul 1998

        +

        21.1.3.2, paragraph 3, says "The types streampos and + wstreampos may be different if the implementation supports no shift + encoding in narrow-oriented iostreams but supports one or more shift + encodings in wide-oriented streams".

        + +

        That's wrong: the two are the same type. The <iosfwd> summary + in 27.2 says that streampos and wstreampos are, respectively, synonyms + for fpos<char_traits<char>::state_type> and + fpos<char_traits<wchar_t>::state_type>, and, flipping back + to clause 21, we see in 21.1.3.1 and 21.1.3.2 that + char_traits<char>::state_type and + char_traits<wchar_t>::state_type must both be mbstate_t.

        +

        Proposed resolution:

        +

        Remove the sentence in 21.1.3.2 paragraph 3 which + begins "The types streampos and wstreampos may be + different..." .

        +
        +

        59. Ambiguity in specification of gbump

        + Section: 27.5.2.3.1 [lib.streambuf.get.area]  Status: DR  Submitter: Matt Austern  Date: 28 Jul 1998

        +

        27.5.2.3.1 says that basic_streambuf::gbump() "Advances the + next pointer for the input sequence by n."

        + +

        The straightforward interpretation is that it is just gptr() += + n. An alternative interpretation, though, is that it behaves as if it + calls sbumpc n times. (The issue, of course, is whether it might ever + call underflow.) There is a similar ambiguity in the case of + pbump.

        + +

        (The "classic" AT&T implementation used the + former interpretation.)

        +

        Proposed resolution:

        +

        Change 27.5.2.3.1 paragraph 4 gbump effects from:

        + +
        +

        Effects: Advances the next pointer for the input sequence by n.

        +
        + +

        to:

        + +
        +

        Effects: Adds n to the next pointer for the input sequence.

        +
        + +

        Make the same change to 27.5.2.3.2 paragraph 4 pbump + effects.

        +
        +

        60. What is a formatted input function?

        + Section: 27.6.1.2.1 [lib.istream.formatted.reqmts]  Status: DR  Submitter: Matt Austern  Date: 3 Aug 1998

        +

        Paragraph 1 of 27.6.1.2.1 contains general requirements for all + formatted input functions. Some of the functions defined in section + 27.6.1.2 explicitly say that those requirements apply ("Behaves + like a formatted input member (as described in 27.6.1.2.1)"), but + others don't. The question: is 27.6.1.2.1 supposed to apply to + everything in 27.6.1.2, or only to those member functions that + explicitly say "behaves like a formatted input member"? Or + to put it differently: are we to assume that everything that appears + in a section called "Formatted input functions" really is a + formatted input function? I assume that 27.6.1.2.1 is intended to + apply to the arithmetic extractors (27.6.1.2.2), but I assume that it + is not intended to apply to extractors like

        + +
            basic_istream& operator>>(basic_istream& (*pf)(basic_istream&));
        + +

        and

        + +
            basic_istream& operator>>(basic_streammbuf*);
        + +

        There is a similar ambiguity for unformatted input, formatted output, and unformatted + output.

        + +

        Comments from Judy Ward: It seems like the problem is that the + basic_istream and basic_ostream operator <<()'s that are used + for the manipulators and streambuf* are in the wrong section and + should have their own separate section or be modified to make it clear + that the "Common requirements" listed in section 27.6.1.2.1 + (for basic_istream) and section 27.6.2.5.1 (for basic_ostream) do not + apply to them.

        + +

        Additional comments from Dietmar Kühl: It appears to be somewhat + nonsensical to consider the functions defined in 27.6.1.2.3 paragraphs 1 to 5 to be "Formatted input + function" but since these functions are defined in a section + labeled "Formatted input functions" it is unclear to me + whether these operators are considered formatted input functions which + have to conform to the "common requirements" from 27.6.1.2.1 : If this is the case, all manipulators, not + just ws, would skip whitespace unless noskipws is + set (... but setting noskipws using the manipulator syntax + would also skip whitespace :-)

        It is not clear which functions + are to be considered unformatted input functions. As written, it seems + that all functions in 27.6.1.3 are unformatted input + functions. However, it does not really make much sense to construct a + sentry object for gcount(), sync(), ... Also it is + unclear what happens to the gcount() if + eg. gcount(), putback(), unget(), or + sync() is called: These functions don't extract characters, + some of them even "unextract" a character. Should this still + be reflected in gcount()? Of course, it could be read as if + after a call to gcount() gcount() return 0 + (the last unformatted input function, gcount(), didn't + extract any character) and after a call to putback() + gcount() returns -1 (the last unformatted input + function putback() did "extract" back into the + stream). Correspondingly for unget(). Is this what is + intended? If so, this should be clarified. Otherwise, a corresponding + clarification should be used.

        +

        Proposed resolution:

        +

        + In 27.6.1.2.2 [lib.istream.formatted.arithmetic], paragraph 1. + Change the beginning of the second sentence from "The conversion + occurs" to "These extractors behave as formatted input functions (as + described in 27.6.1.2.1). After a sentry object is constructed, + the conversion occurs" +

        + +

        + In 27.6.1.2.3, [lib.istream::extractors], before paragraph 1. + Add an effects clause. "Effects: None. This extractor does + not behave as a formatted input function (as described in + 27.6.1.2.1). +

        + +

        + In 27.6.1.2.3, [lib.istream::extractors], paragraph 2. Change the + effects clause to "Effects: Calls pf(*this). This extractor does not + behave as a formatted input function (as described in 27.6.1.2.1). +

        + +

        + In 27.6.1.2.3, [lib.istream::extractors], paragraph 4. Change the + effects clause to "Effects: Calls pf(*this). This extractor does not + behave as a formatted input function (as described in 27.6.1.2.1). +

        + +

        + In 27.6.1.2.3, [lib.istream::extractors], paragraph 12. Change the + first two sentences from "If sb is null, calls setstate(failbit), + which may throw ios_base::failure (27.4.4.3). Extracts characters + from *this..." to "Behaves as a formatted input function (as described + in 27.6.1.2.1). If sb is null, calls setstate(failbit), which may + throw ios_base::failure (27.4.4.3). After a sentry object is + constructed, extracts characters from *this...". +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], before paragraph 2. Add an + effects clause. "Effects: none. This member function does not behave + as an unformatted input function (as described in 27.6.1.3, paragraph 1)." +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 3. Change the + beginning of the first sentence of the effects clause from "Extracts a + character" to "Behaves as an unformatted input function (as described + in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a + character" +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the + beginning of the first sentence of the effects clause from "Extracts a + character" to "Behaves as an unformatted input function (as described + in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts a + character" +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 5. Change the + beginning of the first sentence of the effects clause from "Extracts + characters" to "Behaves as an unformatted input function (as described + in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts + characters" +

        + +

        + [No change needed in paragraph 10, because it refers to paragraph 7.] +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 12. Change the + beginning of the first sentence of the effects clause from "Extracts + characters" to "Behaves as an unformatted input function (as described + in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts + characters" +

        + +

        + [No change needed in paragraph 15.] +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 17. Change the + beginning of the first sentence of the effects clause from "Extracts + characters" to "Behaves as an unformatted input function (as described + in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts + characters" +

        + +

        + [No change needed in paragraph 23.] +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 24. Change the + beginning of the first sentence of the effects clause from "Extracts + characters" to "Behaves as an unformatted input function (as described + in 27.6.1.3, paragraph 1). After constructing a sentry object, extracts + characters" +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], before paragraph 27. Add an + Effects clause: "Effects: Behaves as an unformatted input function (as + described in 27.6.1.3, paragraph 1). After constructing a sentry + object, reads but does not extract the current input character." +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 28. Change the + first sentence of the Effects clause from "If !good() calls" to + Behaves as an unformatted input function (as described in 27.6.1.3, + paragraph 1). After constructing a sentry object, if !good() calls" +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 30. Change the + first sentence of the Effects clause from "If !good() calls" to + "Behaves as an unformatted input function (as described in 27.6.1.3, + paragraph 1). After constructing a sentry object, if !good() calls" +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 32. Change the + first sentence of the Effects clause from "If !good() calls..." to + "Behaves as an unformatted input function (as described in 27.6.1.3, + paragraph 1). After constructing a sentry object, if !good() + calls..." Add a new sentence to the end of the Effects clause: + "[Note: this function extracts no characters, so the value returned + by the next call to gcount() is 0.]" +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 34. Change the + first sentence of the Effects clause from "If !good() calls" to + "Behaves as an unformatted input function (as described in 27.6.1.3, + paragraph 1). After constructing a sentry object, if !good() calls". + Add a new sentence to the end of the Effects clause: "[Note: this + function extracts no characters, so the value returned by the next + call to gcount() is 0.]" +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 36. Change the + first sentence of the Effects clause from "If !rdbuf() is" to "Behaves + as an unformatted input function (as described in 27.6.1.3, paragraph + 1), except that it does not count the number of characters extracted + and does not affect the value returned by subsequent calls to + gcount(). After constructing a sentry object, if rdbuf() is" +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], before paragraph 37. Add an + Effects clause: "Effects: Behaves as an unformatted input function (as + described in 27.6.1.3, paragraph 1), except that it does not count the + number of characters extracted and does not affect the value returned + by subsequent calls to gcount()." Change the first sentence of + paragraph 37 from "if fail()" to "after constructing a sentry object, + if fail()". +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 38. Change the + first sentence of the Effects clause from "If fail()" to "Behaves + as an unformatted input function (as described in 27.6.1.3, paragraph + 1), except that it does not count the number of characters extracted + and does not affect the value returned by subsequent calls to + gcount(). After constructing a sentry object, if fail() +

        + +

        + In 27.6.1.3, [lib.istream.unformatted], paragraph 40. Change the + first sentence of the Effects clause from "If fail()" to "Behaves + as an unformatted input function (as described in 27.6.1.3, paragraph + 1), except that it does not count the number of characters extracted + and does not affect the value returned by subsequent calls to + gcount(). After constructing a sentry object, if fail() +

        + +

        + In 27.6.2.5.2 [lib.ostream.inserters.arithmetic], paragraph 1. Change + the beginning of the third sentence from "The formatting conversion" + to "These extractors behave as formatted output functions (as + described in 27.6.2.5.1). After the sentry object is constructed, the + conversion occurs". +

        + +

        + In 27.6.2.5.3 [lib.ostream.inserters], before paragraph 1. Add an + effects clause: "Effects: None. Does not behave as a formatted output + function (as described in 27.6.2.5.1).". +

        + +

        + In 27.6.2.5.3 [lib.ostream.inserters], paragraph 2. Change the + effects clause to "Effects: calls pf(*this). This extractor does not + behave as a formatted output function (as described in 27.6.2.5.1).". +

        + +

        + In 27.6.2.5.3 [lib.ostream.inserters], paragraph 4. Change the + effects clause to "Effects: calls pf(*this). This extractor does not + behave as a formatted output function (as described in 27.6.2.5.1).". +

        + +

        + In 27.6.2.5.3 [lib.ostream.inserters], paragraph 6. Change the first + sentence from "If sb" to "Behaves as a formatted output function (as + described in 27.6.2.5.1). After the sentry object is constructed, if + sb". +

        + +

        + In 27.6.2.6 [lib.ostream.unformatted], paragraph 2. Change the first + sentence from "Inserts the character" to "Behaves as an unformatted + output function (as described in 27.6.2.6, paragraph 1). After + constructing a sentry object, inserts the character". +

        + +

        + In 27.6.2.6 [lib.ostream.unformatted], paragraph 5. Change the first + sentence from "Obtains characters" to "Behaves as an unformatted + output function (as described in 27.6.2.6, paragraph 1). After + constructing a sentry object, obtains characters". +

        + +

        + In 27.6.2.6 [lib.ostream.unformatted], paragraph 7. Add a new + sentence at the end of the paragraph: "Does not behave as an + unformatted output function (as described in 27.6.2.6, paragraph 1)." +

        +

        Rationale:

        +

        See J16/99-0043==WG21/N1219, Proposed Resolution to Library Issue 60, + by Judy Ward and Matt Austern. This proposed resolution is section + VI of that paper.

        +
        +

        61. Ambiguity in iostreams exception policy

        + Section: 27.6.1.3 [lib.istream.unformatted]  Status: DR  Submitter: Matt Austern  Date: 6 Aug 1998

        +

        The introduction to the section on unformatted input (27.6.1.3) + says that every unformatted input function catches all exceptions that + were thrown during input, sets badbit, and then conditionally rethrows + the exception. That seems clear enough. Several of the specific + functions, however, such as get() and read(), are documented in some + circumstances as setting eofbit and/or failbit. (The standard notes, + correctly, that setting eofbit or failbit can sometimes result in an + exception being thrown.) The question: if one of these functions + throws an exception triggered by setting failbit, is this an exception + "thrown during input" and hence covered by 27.6.1.3, or does + 27.6.1.3 only refer to a limited class of exceptions? Just to make + this concrete, suppose you have the following snippet.

        + +
          
        +   char buffer[N];
        +   istream is;
        +   ...
        +   is.exceptions(istream::failbit); // Throw on failbit but not on badbit.
        +   is.read(buffer, N);
        + +

        Now suppose we reach EOF before we've read N characters. What + iostate bits can we expect to be set, and what exception (if any) will + be thrown?

        +

        Proposed resolution:

        +

        + In 27.6.1.3, paragraph 1, after the sentence that begins + "If an exception is thrown...", add the following + parenthetical comment: "(Exceptions thrown from + basic_ios<>::clear() are not caught or rethrown.)" +

        +

        Rationale:

        +

        The LWG looked to two alternative wordings, and choose the proposed + resolution as better standardese.

        +
        +

        62. Sync's return value

        + Section: 27.6.1.3 [lib.istream.unformatted]  Status: DR  Submitter: Matt Austern  Date: 6 Aug 1998

        +

        The Effects clause for sync() (27.6.1.3, paragraph 36) says that it + "calls rdbuf()->pubsync() and, if that function returns -1 + ... returns traits::eof()."

        + +

        That looks suspicious, because traits::eof() is of type + traits::int_type while the return type of sync() is int.

        +

        Proposed resolution:

        +

        In 27.6.1.3 , paragraph 36, change "returns + traits::eof()" to "returns -1". +

        +
        +

        63. Exception-handling policy for unformatted output

        + Section: 27.6.2.6 [lib.ostream.unformatted]  Status: DR  Submitter: Matt Austern  Date: 11 Aug 1998

        +

        Clause 27 details an exception-handling policy for formatted input, + unformatted input, and formatted output. It says nothing for + unformatted output (27.6.2.6). 27.6.2.6 should either include the same + kind of exception-handling policy as in the other three places, or + else it should have a footnote saying that the omission is + deliberate.

        +

        Proposed resolution:

        +

        + In 27.6.2.6, paragraph 1, replace the last sentence ("In any + case, the unformatted output function ends by destroying the sentry + object, then returning the value specified for the formatted output + function.") with the following text: +

        +
        + If an exception is thrown during output, then ios::badbit is + turned on [Footnote: without causing an ios::failure to be + thrown.] in *this's error state. If (exceptions() & + badbit) != 0 then the exception is rethrown. In any case, the + unformatted output function ends by destroying the sentry object, + then, if no exception was thrown, returning the value specified for + the formatted output function. +
        +

        Rationale:

        +

        + This exception-handling policy is consistent with that of formatted + input, unformatted input, and formatted output. +

        +
        +

        64. Exception handling in basic_istream::operator>>(basic_streambuf*) +

        + Section: 27.6.1.2.3 [lib.istream::extractors]  Status: DR  Submitter: Matt Austern  Date: 11 Aug 1998

        +

        27.6.1.2.3, paragraph 13, is ambiguous. It can be interpreted two + different ways, depending on whether the second sentence is read as an + elaboration of the first.

        +

        Proposed resolution:

        +

        Replace 27.6.1.2.3 , paragraph 13, which begins + "If the function inserts no characters ..." with:

        + +
        +

        If the function inserts no characters, it calls + setstate(failbit), which may throw + ios_base::failure (27.4.4.3). If it inserted no characters + because it caught an exception thrown while extracting characters + from sb and failbit is on in exceptions() + (27.4.4.3), then the caught exception is rethrown.

        +
        +
        +

        66. Strstreambuf::setbuf

        + Section: D.7.1.3 [depr.strstreambuf.virtuals]  Status: DR  Submitter: Matt Austern  Date: 18 Aug 1998

        +

        D.7.1.3, paragraph 19, says that strstreambuf::setbuf + "Performs an operation that is defined separately for each class + derived from strstreambuf". This is obviously an incorrect + cut-and-paste from basic_streambuf. There are no classes derived from + strstreambuf.

        +

        Proposed resolution:

        +

        D.7.1.3 , paragraph 19, replace the setbuf effects + clause which currently says "Performs an operation that is + defined separately for each class derived from strstreambuf" + with: [depr.strstreambuf.virtuals] +

        + +
        +

        + Effects: implementation defined, except that + setbuf(0,0) has no effect.

        +
        +
        +

        68. Extractors for char* should store null at end

        + Section: 27.6.1.2.3 [lib.istream::extractors]  Status: DR  Submitter: Angelika Langer  Date: 14 Jul 1998

        +

        Extractors for char* (27.6.1.2.3) do not store a null character + after the extracted character sequence whereas the unformatted + functions like get() do. Why is this?

        + +

        Comment from Jerry Schwarz: There is apparently an editing + glitch. You'll notice that the last item of the list of what stops + extraction doesn't make any sense. It was supposed to be the line that + said a null is stored.

        +

        Proposed resolution:

        +

        27.6.1.2.3 , paragraph 7, change the last list + item from: [lib.istream::extractors] +

        + +
        + A null byte (charT()) in the next position, which may be + the first position if no characters were extracted. +
        + +

        to become a new paragraph which reads:

        + +
        + Operator>> then stores a null byte (charT()) in the + next position, which may be the first position if no characters were + extracted. +
        +
        +

        69. Must elements of a vector be contiguous?

        + Section: 23.2.4 [lib.vector]  Status: DR  Submitter: Andrew Koenig  Date: 29 Jul 1998

        +

        The issue is this: Must the elements of a vector be in contiguous memory?

        + +

        (Please note that this is entirely separate from the question of + whether a vector iterator is required to be a pointer; the answer to + that question is clearly "no," as it would rule out + debugging implementations)

        +

        Proposed resolution:

        +

        Add the following text to the end of 23.2.4 , + paragraph 1.

        + +
        +

        The elements of a vector are stored contiguously, meaning that if + v is a vector<T, Allocator> where T is some type + other than bool, then it obeys the identity &v[n] + == &v[0] + n for all 0 <= n < v.size().

        +
        +

        Rationale:

        +

        The LWG feels that as a practical matter the answer is clearly + "yes". There was considerable discussion as to the best way + to express the concept of "contiguous", which is not + directly defined in the standard. Discussion included:

        + +
          +
        • An operational definition similar to the above proposed resolution is + already used for valarray (26.3.2.3 ).
        • +
        • There is no need to explicitly consider a user-defined operator& + because elements must be copyconstructible (23.1 para 3) + and copyconstructible (20.1.3 ) specifies + requirements for operator&.
        • +
        • There is no issue of one-past-the-end because of language rules.
        • +
        +
        +

        70. Uncaught_exception() missing throw() specification

        + Section: 18.6 [lib.support.exception], 18.6.4 [lib.uncaught]  Status: DR  Submitter: Steve Clamage  Date: Unknown

        +

        In article 3E04@pratique.fr, Valentin Bonnard writes:

        + +

        uncaught_exception() doesn't have a throw specification.

        + +

        It is intentional ? Does it means that one should be prepared to + handle exceptions thrown from uncaught_exception() ?

        + +

        uncaught_exception() is called in exception handling contexts where + exception safety is very important.

        +

        Proposed resolution:

        +

        In 15.5.3 , paragraph 1, 18.6 , and 18.6.4 , add "throw()" to uncaught_exception().

        +
        +

        71. Do_get_monthname synopsis missing argument

        + Section: 22.2.5.1 [lib.locale.time.get]  Status: DR  Submitter: Nathan Myers  Date: 13 Aug 1998

        +

        The locale facet member time_get<>::do_get_monthname + is described in 22.2.5.1.2 with five arguments, + consistent with do_get_weekday and with its specified use by member + get_monthname. However, in the synopsis, it is specified instead with + four arguments. The missing argument is the "end" iterator + value.

        +

        Proposed resolution:

        +

        In 22.2.5.1 , add an "end" argument to + the declaration of member do_monthname as follows:

        + +
          virtual iter_type do_get_monthname(iter_type s, iter_type end, ios_base&,
        +                                      ios_base::iostate& err, tm* t) const;
        +
        +

        74. Garbled text for codecvt::do_max_length +

        + Section: 22.2.1.5.2 [lib.locale.codecvt.virtuals]  Status: DR  Submitter: Matt Austern  Date: 8 Sep 1998

        +

        The text of codecvt::do_max_length's "Returns" + clause (22.2.1.5.2, paragraph 11) is garbled. It has unbalanced + parentheses and a spurious n.

        +

        Proposed resolution:

        +

        Replace 22.2.1.5.2 paragraph 11 with the + following:

        + +
        + Returns: The maximum value that + do_length(state, from, from_end, 1) can return for any + valid range [from, from_end) and stateT value + state. The specialization codecvt<char, char, + mbstate_t>::do_max_length() returns 1. +
        +
        +

        75. Contradiction in codecvt::length's argument types

        + Section: 22.2.1.5 [lib.locale.codecvt]  Status: DR  Submitter:  Matt + Austern  Date:  18 Sep 1998

        +

        The class synopses for classes codecvt<> (22.2.1.5) + and codecvt_byname<> (22.2.1.6) say that the first + parameter of the member functions length and + do_length is of type const stateT&. The member + function descriptions, however (22.2.1.5.1, paragraph 6; 22.2.1.5.2, + paragraph 9) say that the type is stateT&. Either the + synopsis or the summary must be changed.

        + +

        If (as I believe) the member function descriptions are correct, + then we must also add text saying how do_length changes its + stateT argument.

        +

        Proposed resolution:

        +

        In 22.2.1.5 , and also in 22.2.1.6 , + change the stateT argument type on both member + length() and member do_length() from

        + +
        +

        const stateT&

        +
        + +

        to

        + +
        +

        stateT&

        +
        + +

        In 22.2.1.5.2 , add to the definition for member + do_length a paragraph:

        + +
        +

        Effects: The effect on the state argument is ``as if'' + it called do_in(state, from, from_end, from, to, to+max, + to) for to pointing to a buffer of at least + max elements.

        +
        +
        +

        78. Typo: event_call_back

        + Section: 27.4.2 [lib.ios.base]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998

        +

        typo: event_call_back should be event_callback  

        +

        Proposed resolution:

        +

        In the 27.4.2 synopsis change + "event_call_back" to "event_callback".

        +
        +

        79. Inconsistent declaration of polar()

        + Section: 26.2.1 [lib.complex.synopsis], 26.2.7 [lib.complex.value.ops]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998

        +

        In 26.2.1 polar is declared as follows:

        +
           template<class T> complex<T> polar(const T&, const T&); 
        + +

        In 26.2.7 it is declared as follows:

        +
           template<class T> complex<T> polar(const T& rho, const T& theta = 0); 
        + +

        Thus whether the second parameter is optional is not clear.

        +

        Proposed resolution:

        +

        In 26.2.1 change:

        +
           template<class T> complex<T> polar(const T&, const T&);
        + +

        to:

        +
           template<class T> complex<T> polar(const T& rho, const T& theta = 0); 
        +
        +

        80. Global Operators of complex declared twice

        + Section: 26.2.1 [lib.complex.synopsis], 26.2.2 [lib.complex]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998

        +

        Both 26.2.1 and 26.2.2 contain declarations of global operators for + class complex. This redundancy should be removed.

        +

        Proposed resolution:

        +

        Reduce redundancy according to the general style of the standard.

        +
        +

        83. String::npos vs. string::max_size()

        + Section: 21.3 [lib.basic.string]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998

        +

        Many string member functions throw if size is getting or exceeding + npos. However, I wonder why they don't throw if size is getting or + exceeding max_size() instead of npos. May be npos is known at compile + time, while max_size() is known at runtime. However, what happens if + size exceeds max_size() but not npos, then? It seems the standard + lacks some clarifications here.

        +

        Proposed resolution:

        +

        After 21.3 paragraph 4 ("The functions + described in this clause...") add a new paragraph:

        + +
        +

        For any string operation, if as a result of the operation, size() would exceed + max_size() then + the operation throws length_error.

        +
        +

        Rationale:

        +

        The LWG believes length_error is the correct exception to throw.

        +
        +

        86. String constructors don't describe exceptions

        + Section: 21.3.1 [lib.string.cons]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998

        +

        The constructor from a range:

        + +
        template<class InputIterator> 
        +          basic_string(InputIterator begin, InputIterator end, 
        +                       const Allocator& a = Allocator());
        + +

        lacks a throws clause. However, I would expect that it throws + according to the other constructors if the numbers of characters in + the range equals npos (or exceeds max_size(), see above).

        +

        Proposed resolution:

        +

        In 21.3.1 , Strike throws paragraphs for + constructors which say "Throws: length_error if n == + npos."

        +

        Rationale:

        +

        Throws clauses for length_error if n == npos are no longer needed + because they are subsumed by the general wording added by the + resolution for issue 83.

        +
        +

        90. Incorrect description of operator >> for strings

        + Section: 21.3.7.9 [lib.string.io]  Status: DR  Submitter: Nico Josuttis  Date: 29 Sep 1998

        +

        The effect of operator >> for strings contain the following item:

        + +

            isspace(c,getloc()) is true for the next available input + character c.

        + +

        Here getloc() has to be replaced by is.getloc().

        +

        Proposed resolution:

        +

        In 21.3.7.9 paragraph 1 Effects clause replace:

        + +
        +

        + isspace(c,getloc()) is true for the next available input character c.

        +
        + +

        with:

        + +
        +

        + isspace(c,is.getloc()) is true for the next available input character c.

        +
        +
        +

        103. set::iterator is required to be modifiable, but this allows modification of keys

        + Section: 23.1.2 [lib.associative.reqmts]  Status: DR  Submitter: AFNOR  Date: 7 Oct 1998

        +

        Set::iterator is described as implementation-defined with a + reference to the container requirement; the container requirement says + that const_iterator is an iterator pointing to const T and iterator an + iterator pointing to T.

        + +

        23.1.2 paragraph 2 implies that the keys should not be modified to + break the ordering of elements. But that is not clearly + specified. Especially considering that the current standard requires + that iterator for associative containers be different from + const_iterator. Set, for example, has the following:

        + +

        typedef implementation defined iterator;
        +        // See _lib.container.requirements_

        + +

        23.1 actually requires that iterator type pointing + to T (table 65). Disallowing user modification of keys by changing the + standard to require an iterator for associative container to be the + same as const_iterator would be overkill since that will unnecessarily + significantly restrict the usage of associative container. A class to + be used as elements of set, for example, can no longer be modified + easily without either redesigning the class (using mutable on fields + that have nothing to do with ordering), or using const_cast, which + defeats requiring iterator to be const_iterator. The proposed solution + goes in line with trusting user knows what he is doing. [lib.container.requirements] +

        + +

        + Other Options Evaluated:

        + +

        Option A.   In 23.1.2 , paragraph 2, after + first sentence, and before "In addition,...", add one line: +

        + +
        +

        Modification of keys shall not change their strict weak ordering.

        +
        + +

        Option B. Add three new sentences to 23.1.2 :

        + +
        +

        At the end of paragraph 5: "Keys in an associative container + are immutable." At the end of paragraph 6: "For + associative containers where the value type is the same as the key + type, both iterator and const_iterator are + constant iterators. It is unspecified whether or not + iterator and const_iterator are the same + type."

        +
        + +

        Option C. To 23.1.2 , paragraph 3, which + currently reads:

        + +
        +

        The phrase ``equivalence of keys'' means the equivalence relation imposed by the + comparison and not the operator== on keys. That is, two keys k1 and k2 in the same + container are considered to be equivalent if for the comparison object comp, comp(k1, k2) + == false && comp(k2, k1) == false.

        +
        + +

          add the following:

        + +
        +

        For any two keys k1 and k2 in the same container, comp(k1, k2) shall return the same + value whenever it is evaluated. [Note: If k2 is removed from the container and later + reinserted, comp(k1, k2) must still return a consistent value but this value may be + different than it was the first time k1 and k2 were in the same container. This is + intended to allow usage like a string key that contains a filename, where comp compares + file contents; if k2 is removed, the file is changed, and the same k2 (filename) is + reinserted, comp(k1, k2) must again return a consistent value but this value may be + different than it was the previous time k2 was in the container.]

        +
        +

        Proposed resolution:

        +

        Add the following to 23.1.2 at + the indicated location:

        + +
        +

        At the end of paragraph 3: "For any two keys k1 and k2 in the same container, + calling comp(k1, k2) shall always return the same + value."

        +

        At the end of paragraph 5: "Keys in an associative container are immutable."

        +

        At the end of paragraph 6: "For associative containers where the value type is the + same as the key type, both iterator and const_iterator are constant + iterators. It is unspecified whether or not iterator and const_iterator + are the same type."

        +
        +

        Rationale:

        +

        Several arguments were advanced for and against allowing set elements to be + mutable as long as the ordering was not effected. The argument which swayed the + LWG was one of safety; if elements were mutable, there would be no compile-time + way to detect of a simple user oversight which caused ordering to be + modified. There was a report that this had actually happened in practice, + and had been painful to diagnose. If users need to modify elements, + it is possible to use mutable members or const_cast.

        + +

        Simply requiring that keys be immutable is not sufficient, because the comparison + object may indirectly (via pointers) operate on values outside of the keys.

        + +

        + The types iterator and const_iterator are permitted + to be different types to allow for potential future work in which some + member functions might be overloaded between the two types. No such + member functions exist now, and the LWG believes that user functionality + will not be impaired by permitting the two types to be the same. A + function that operates on both iterator types can be defined for + const_iterator alone, and can rely on the automatic + conversion from iterator to const_iterator. +

        + +

        [Tokyo: The LWG crafted the proposed resolution and rationale.]

        +
        +

        106. Numeric library private members are implementation defined

        + Section: 26.3.5 [lib.template.slice.array]  Status: DR  Submitter: AFNOR  Date: 7 Oct 1998

        +

        This is the only place in the whole standard where the implementation has to document + something private.

        +

        Proposed resolution:

        +

        + Remove the comment which says "// remainder implementation defined" from: +

        + + +
        +

        108. Lifetime of exception::what() return unspecified

        + Section: 18.6.1 [lib.exception]  Status: DR  Submitter: AFNOR  Date: 7 Oct 1998

        +

        In 18.6.1, paragraphs 8-9, the lifetime of the return value of + exception::what() is left unspecified. This issue has implications + with exception safety of exception handling: some exceptions should + not throw bad_alloc.

        +

        Proposed resolution:

        +

        Add to 18.6.1 paragraph 9 (exception::what notes + clause) the sentence:

        + +
        +

        The return value remains valid until the exception object from which it is obtained is + destroyed or a non-const member function of the exception object is called.

        +
        +

        Rationale:

        +

        If an exception object has non-const members, they may be used + to set internal state that should affect the contents of the string + returned by what(). +

        +
        +

        110. istreambuf_iterator::equal not const

        + Section: 24.5.3 [lib.istreambuf.iterator], 24.5.3.5 [lib.istreambuf.iterator::equal]  Status: DR  Submitter: Nathan Myers  Date: 15 Oct 1998

        +

        Member istreambuf_iterator<>::equal is not declared + "const", yet 24.5.3.6 says that operator==, + which is const, calls it. This is contradictory.

        +

        Proposed resolution:

        +

        In 24.5.3 and also in 24.5.3.5 , + replace:

        + +
        +
        bool equal(istreambuf_iterator& b);
        +
        + +

        with:

        + +
        +
        bool equal(const istreambuf_iterator& b) const;
        +
        +
        +

        112. Minor typo in ostreambuf_iterator constructor

        + Section: 24.5.4.1 [lib.ostreambuf.iter.cons]  Status: DR  Submitter: Matt Austern  Date: 20 Oct 1998

        +

        The requires clause for ostreambuf_iterator's + constructor from an ostream_type (24.5.4.1, paragraph 1) + reads "s is not null". However, s is a + reference, and references can't be null.

        +

        Proposed resolution:

        +

        In 24.5.4.1 :

        + +

        Move the current paragraph 1, which reads "Requires: s is not + null.", from the first constructor to the second constructor.

        + +

        Insert a new paragraph 1 Requires clause for the first constructor + reading:

        + +
        +

        + Requires: s.rdbuf() is not null.

        +
        +
        +

        114. Placement forms example in error twice

        + Section: 18.4.1.3 [lib.new.delete.placement]  Status: DR  Submitter: Steve Clamage  Date: 28 Oct 1998

        +

        Section 18.4.1.3 contains the following example:

        + +
        [Example: This can be useful for constructing an object at a known address:
        +         char place[sizeof(Something)];
        +         Something* p = new (place) Something();
        +  -end example]
        + +

        First code line: "place" need not have any special alignment, and the + following constructor could fail due to misaligned data.

        + +

        Second code line: Aren't the parens on Something() incorrect?  [Dublin: the LWG + believes the () are correct.]

        + +

        Examples are not normative, but nevertheless should not show code that is invalid or + likely to fail.

        +

        Proposed resolution:

        +

        Replace the first line of code in the example in + 18.4.1.3 with: +

        + +
        +
        void* place = operator new(sizeof(Something));
        +
        +
        +

        115. Typo in strstream constructors

        + Section: D.7.4.1 [depr.strstream.cons]  Status: DR  Submitter: Steve Clamage  Date: 2 Nov 1998

        +

        D.7.4.1 strstream constructors paragraph 2 says:

        + +
        +

        Effects: Constructs an object of class strstream, initializing the base class with + iostream(& sb) and initializing sb with one of the two constructors:

        +

        - If mode&app==0, then s shall designate the first element of an array of n + elements. The constructor is strstreambuf(s, n, s).

        +

        - If mode&app==0, then s shall designate the first element of an array of n + elements that contains an NTBS whose first element is designated by s. The constructor is + strstreambuf(s, n, s+std::strlen(s)).

        +
        + +

        Notice the second condition is the same as the first. I think the second condition + should be "If mode&app==app", or "mode&app!=0", meaning that + the append bit is set.

        +

        Proposed resolution:

        +

        In D.7.3.1 paragraph 2 and D.7.4.1 + paragraph 2, change the first condition to (mode&app)==0 + and the second condition to (mode&app)!=0.

        +
        +

        118. basic_istream uses nonexistent num_get member functions

        + Section: 27.6.1.2.2 [lib.istream.formatted.arithmetic]  Status: DR  Submitter: Matt Austern  Date: 20 Nov 1998

        +

        Formatted input is defined for the types short, unsigned short, int, + unsigned int, long, unsigned long, float, double, + long double, bool, and void*. According to section 27.6.1.2.2, + formatted input of a value x is done as if by the following code fragment:

        + +
        typedef num_get< charT,istreambuf_iterator<charT,traits> > numget; 
        + iostate err = 0; 
        + use_facet< numget >(loc).get(*this, 0, *this, err, val); 
        + setstate(err);
        + +

        According to section 22.2.2.1.1 , however, + num_get<>::get() is only overloaded for the types + bool, long, unsigned short, unsigned + int, unsigned long, unsigned long, + float, double, long double, and + void*. Comparing the lists from the two sections, we find + that 27.6.1.2.2 is using a nonexistent function for types + short and int.

        +

        Proposed resolution:

        +

        In 27.6.1.2.2 Arithmetic Extractors, remove the + two lines (1st and 3rd) which read:

        +
        +
        operator>>(short& val);
        + ...
        + operator>>(int& val);
        +
        + +

        And add the following at the end of that section (27.6.1.2.2) :

        + +
        +
        operator>>(short& val);
        +

        The conversion occurs as if performed by the following code fragment (using + the same notation as for the preceding code fragment):

        +
          typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
        +   iostate err = 0;
        +   long lval;
        +   use_facet< numget >(loc).get(*this, 0, *this, err, lval);
        +         if (err == 0
        +                 && (lval < numeric_limits<short>::min() || numeric_limits<short>::max() < lval))
        +                 err = ios_base::failbit;
        +   setstate(err);
        +
        operator>>(int& val);
        +

        The conversion occurs as if performed by the following code fragment (using + the same notation as for the preceding code fragment):

        +
          typedef num_get< charT,istreambuf_iterator<charT,traits> > numget;
        +   iostate err = 0;
        +   long lval;
        +   use_facet< numget >(loc).get(*this, 0, *this, err, lval);
        +         if (err == 0
        +                 && (lval < numeric_limits<int>::min() || numeric_limits<int>::max() < lval))
        +                 err = ios_base::failbit;
        +   setstate(err);
        +
        + +

        [Post-Tokyo: PJP provided the above wording.]

        +
        +

        119. Should virtual functions be allowed to strengthen the exception specification?

        + Section: 17.4.4.8 [lib.res.on.exception.handling]  Status: DR  Submitter: Judy Ward  Date: 15 Dec 1998

        +

        Section 17.4.4.8 states:

        + +

        "An implementation may strengthen the exception-specification + for a function by removing listed exceptions."

        + +

        The problem is that if an implementation is allowed to do this for + virtual functions, then a library user cannot write a class that + portably derives from that class.

        + +

        For example, this would not compile if ios_base::failure::~failure + had an empty exception specification:

        + +
        #include <ios>
        + #include <string>
        + 
        + class D : public std::ios_base::failure {
        + public:
        +         D(const std::string&);
        +         ~D(); // error - exception specification must be compatible with 
        +               // overridden virtual function ios_base::failure::~failure()
        + };
        +

        Proposed resolution:

        +

        Change Section 17.4.4.8 from:

        + +

             "may strengthen the + exception-specification for a function"

        + +

        to:

        + +

             "may strengthen the + exception-specification for a non-virtual function".

        +
        +

        122. streambuf/wstreambuf description should not say they are specializations

        + Section: 27.5.2 [lib.streambuf]  Status: DR  Submitter: Judy Ward  Date: 15 Dec 1998

        +

        Section 27.5.2 describes the streambuf classes this way:

        + +
        + +

        The class streambuf is a specialization of the template class basic_streambuf + specialized for the type char.

        + +

        The class wstreambuf is a specialization of the template class basic_streambuf + specialized for the type wchar_t.

        + +
        + +

        This implies that these classes must be template specializations, not typedefs.

        + +

        It doesn't seem this was intended, since Section 27.5 has them declared as typedefs.

        +

        Proposed resolution:

        +

        Remove 27.5.2 paragraphs 2 and 3 (the above two + sentences).

        +

        Rationale:

        +

        The streambuf synopsis already has a declaration for the + typedefs and that is sufficient.

        +
        +

        124. ctype_byname<charT>::do_scan_is & do_scan_not return type should be const charT*

        + Section: 22.2.1.2 [lib.locale.ctype.byname]  Status: DR  Submitter: Judy Ward  Date: 15 Dec 1998

        +

        In Section 22.2.1.2 + ctype_byname<charT>::do_scan_is() and do_scan_not() are declared + to return a const char* not a const charT*.

        +

        Proposed resolution:

        +

        Change Section 22.2.1.2 do_scan_is() and + do_scan_not() to return a const + charT*.

        +
        +

        125. valarray<T>::operator!() return type is inconsistent

        + Section: 26.3.2 [lib.template.valarray]  Status: DR  Submitter: Judy Ward  Date: 15 Dec 1998

        +

        In Section 26.3.2 valarray<T>::operator!() is + declared to return a valarray<T>, but in Section 26.3.2.5 it is declared to return a valarray<bool>. The + latter appears to be correct.

        +

        Proposed resolution:

        +

        Change in Section 26.3.2 the declaration of + operator!() so that the return type is + valarray<bool>.

        +
        +

        126. typos in Effects clause of ctype::do_narrow()

        + Section: 22.2.1.1.2 [lib.locale.ctype.virtuals]  Status: DR  Submitter: Judy Ward  Date: 15 Dec 1998

        +

        Typos in 22.2.1.1.2 need to be fixed.

        +

        Proposed resolution:

        +

        In Section 22.2.1.1.2 change:

        + +
           do_widen(do_narrow(c),0) == c
        + +

        to:

        + +
           do_widen(do_narrow(c,0)) == c
        + +

        and change:

        + +
           (is(M,c) || !ctc.is(M, do_narrow(c),dfault) )
        + +

        to:

        + +
           (is(M,c) || !ctc.is(M, do_narrow(c,dfault)) )
        +
        +

        127. auto_ptr<> conversion issues

        + Section: 20.4.5 [lib.auto.ptr]  Status: DR  Submitter: Greg Colvin  Date: 17 Feb 1999

        +

        There are two problems with the current auto_ptr wording + in the standard:

        + +

        First, the auto_ptr_ref definition cannot be nested + because auto_ptr<Derived>::auto_ptr_ref is unrelated to + auto_ptr<Base>::auto_ptr_ref. Also submitted by + Nathan Myers, with the same proposed resolution. +

        + +

        Second, there is no auto_ptr assignment operator taking an + auto_ptr_ref argument.

        + +

        I have discussed these problems with my proposal coauthor, Bill + Gibbons, and with some compiler and library implementors, and we + believe that these problems are not desired or desirable implications + of the standard.

        + +

        25 Aug 1999: The proposed resolution now reflects changes suggested + by Dave Abrahams, with Greg Colvin's concurrence; 1) changed + "assignment operator" to "public assignment + operator", 2) changed effects to specify use of release(), 3) + made the conversion to auto_ptr_ref const.

        + +

        2 Feb 2000: Lisa Lippincott comments: [The resolution of] this issue + states that the conversion from auto_ptr to auto_ptr_ref should + be const. This is not acceptable, because it would allow + initialization and assignment from _any_ const auto_ptr! It also + introduces an implementation difficulty in writing this conversion + function -- namely, somewhere along the line, a const_cast will be + necessary to remove that const so that release() may be called. This + may result in undefined behavior [7.1.5.1/4]. The conversion + operator does not have to be const, because a non-const implicit + object parameter may be bound to an rvalue [13.3.3.1.4/3] + [13.3.1/5].

        + +

        Tokyo: The LWG removed the following from the proposed resolution:

        + +

        In 20.4.5 , paragraph 2, and 20.4.5.3 , + paragraph 2, make the conversion to auto_ptr_ref const:

        +
        +
        template<class Y> operator auto_ptr_ref<Y>() const throw();
        +
        +

        Proposed resolution:

        +

        In 20.4.5 , paragraph 2, move + the auto_ptr_ref definition to namespace scope.

        + +

        In 20.4.5 , paragraph 2, add + a public assignment operator to the auto_ptr definition:

        + +
        +
        auto_ptr& operator=(auto_ptr_ref<X> r) throw();
        +
        + +

        Also add the assignment operator to 20.4.5.3 :

        + +
        +
        auto_ptr& operator=(auto_ptr_ref<X> r) throw()
        + + Effects: Calls reset(p.release()) for the auto_ptr + p that r holds a reference to.
        + Returns: *this. + +
        +
        +

        129. Need error indication from seekp() and seekg()

        + Section: 27.6.1.3 [lib.istream.unformatted], 27.6.2.4 [lib.ostream.seeks]  Status: DR  Submitter: Angelika Langer  Date: 22 Feb 1999

        +

        Currently, the standard does not specify how seekg() and seekp() + indicate failure. They are not required to set failbit, and they can't + return an error indication because they must return *this, i.e. the + stream. Hence, it is undefined what happens if they fail. And they + can fail, for instance, when a file stream is disconnected from the + underlying file (is_open()==false) or when a wide character file + stream must perform a state-dependent code conversion, etc.

        + +

        The stream functions seekg() and seekp() should set failbit in the + stream state in case of failure.

        +

        Proposed resolution:

        +

        Add to the Effects: clause of  seekg() in + 27.6.1.3 and to the Effects: clause of seekp() in + 27.6.2.4 :

        + +
        +

        In case of failure, the function calls setstate(failbit) (which may throw ios_base::failure). +

        +
        +

        Rationale:

        +

        Setting failbit is the usual error reporting mechanism for streams

        +
        +

        132. list::resize description uses random access iterators

        + Section: 23.2.2.2 [lib.list.capacity]  Status: DR  Submitter: Howard Hinnant  Date: 6 Mar 1999

        +

        The description reads:

        + +

        -1- Effects:

        + +
                 if (sz > size())
        +            insert(end(), sz-size(), c);
        +          else if (sz < size())
        +            erase(begin()+sz, end());
        +          else
        +            ;                           //  do nothing
        + +

        Obviously list::resize should not be specified in terms of random access iterators.

        +

        Proposed resolution:

        +

        Change 23.2.2.2 paragraph 1 to:

        + +

        Effects:

        + +
                 if (sz > size())
        +            insert(end(), sz-size(), c);
        +          else if (sz < size())
        +          {
        +            iterator i = begin();
        +            advance(i, sz);
        +            erase(i, end());
        +          }
        + +

        [Dublin: The LWG asked Howard to discuss exception safety offline + with David Abrahams. They had a discussion and believe there is + no issue of exception safety with the proposed resolution.]

        +
        +

        133. map missing get_allocator()

        + Section: 23.3.1 [lib.map]  Status: DR  Submitter: Howard Hinnant  Date: 6 Mar 1999

        +

        The title says it all.

        +

        Proposed resolution:

        +

        Insert in 23.3.1 , paragraph 2, + after operator= in the map declaration:

        + +
            allocator_type get_allocator() const;
        +
        +

        134. vector constructors over specified

        + Section: 23.2.4.1 [lib.vector.cons]  Status: DR  Submitter: Howard Hinnant  Date: 6 Mar 1999

        +

        The complexity description says: "It does at most 2N calls to the copy constructor + of T and logN reallocations if they are just input iterators ...".

        + +

        This appears to be overly restrictive, dictating the precise memory/performance + tradeoff for the implementor.

        +

        Proposed resolution:

        +

        Change 23.2.4.1 , paragraph 1 to:

        + +

        -1- Complexity: The constructor template <class + InputIterator> vector(InputIterator first, InputIterator last) + makes only N calls to the copy constructor of T (where N is the + distance between first and last) and no reallocations if iterators + first and last are of forward, bidirectional, or random access + categories. It makes order N calls to the copy constructor of T and + order logN reallocations if they are just input iterators. +

        +

        Rationale:

        +

        "at most 2N calls" is correct only if the growth factor + is greater than or equal to 2. +

        +
        +

        136. seekp, seekg setting wrong streams?

        + Section: 27.6.1.3 [lib.istream.unformatted]  Status: DR  Submitter: Howard Hinnant  Date: 6 Mar 1999

        +

        I may be misunderstanding the intent, but should not seekg set only + the input stream and seekp set only the output stream? The description + seems to say that each should set both input and output streams. If + that's really the intent, I withdraw this proposal.

        +

        Proposed resolution:

        +

        In section 27.6.1.3 change:

        + +
        basic_istream<charT,traits>& seekg(pos_type pos);
        + Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). 
        + +

        To:

        + +
        basic_istream<charT,traits>& seekg(pos_type pos);
        + Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::in). 
        + +

        In section 27.6.1.3 change:

        + +
        basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
        + Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). 
        + +

        To:

        + +
        basic_istream<charT,traits>& seekg(off_type& off, ios_base::seekdir dir);
        + Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::in). 
        + +

        In section 27.6.2.4, paragraph 2 change:

        + +
        -2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos). 
        + +

        To:

        + +
        -2- Effects: If fail() != true, executes rdbuf()->pubseekpos(pos, ios_base::out). 
        + +

        In section 27.6.2.4, paragraph 4 change:

        + +
        -4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir). 
        + +

        To:

        + +
        -4- Effects: If fail() != true, executes rdbuf()->pubseekoff(off, dir, ios_base::out). 
        + +

        [Dublin: Dietmar Kühl thinks this is probably correct, but would + like the opinion of more iostream experts before taking action.]

        + +

        [Tokyo: Reviewed by the LWG. PJP noted that although his docs are + incorrect, his implementation already implements the Proposed + Resolution.]

        + +

        [Post-Tokyo: Matt Austern comments:
        + Is it a problem with basic_istream and basic_ostream, or is it a problem + with basic_stringbuf? + We could resolve the issue either by changing basic_istream and + basic_ostream, or by changing basic_stringbuf. I prefer the latter + change (or maybe both changes): I don't see any reason for the standard to + require that std::stringbuf s(std::string("foo"), std::ios_base::in); + s.pubseekoff(0, std::ios_base::beg); must fail.
        + This requirement is a bit weird. There's no similar requirement + for basic_streambuf<>::seekpos, or for basic_filebuf<>::seekoff or + basic_filebuf<>::seekpos.]

        +
        +

        137. Do use_facet and has_facet look in the global locale?

        + Section: 22.1.1 [lib.locale]  Status: DR  Submitter: Angelika Langer  Date: 17 Mar 1999

        +

        Section 22.1.1 says:

        + +

        -4- In the call to use_facet<Facet>(loc), the type argument + chooses a facet, making available all members of the named type. If + Facet is not present in a locale (or, failing that, in the global + locale), it throws the standard exception bad_cast. A C++ program can + check if a locale implements a particular facet with the template + function has_facet<Facet>().

        + +

        This contradicts the specification given in section + 22.1.2 : +

        + template <class  Facet> const  Facet& use_facet(const + locale&  loc);
        +
        + -1- Get a reference to a facet of a locale.
        + -2- Returns: a reference to the corresponding facet of loc, if present.
        + -3- Throws: bad_cast if has_facet<Facet>(loc) is false.
        + -4- Notes: The reference returned remains valid at least as long as any copy of loc exists +

        +

        Proposed resolution:

        +

        Remove the phrase "(or, failing that, in the global locale)" + from section 22.1.1.

        +

        Rationale:

        +

        Needed for consistency with the way locales are handled elsewhere + in the standard.

        +
        +

        139. Optional sequence operation table description unclear

        + Section: 23.1.1 [lib.sequence.reqmts]  Status: DR  Submitter: Andrew Koenig  Date: 30 Mar 1999

        +

        The sentence introducing the Optional sequence operation table + (23.1.1 paragraph 12) has two problems:

        + +

        A. It says ``The operations in table 68 are provided only for the containers for which + they take constant time.''
        +
        + That could be interpreted in two ways, one of them being ``Even though table 68 shows + particular operations as being provided, implementations are free to omit them if they + cannot implement them in constant time.''
        +
        + B. That paragraph says nothing about amortized constant time, and it should. 

        +

        Proposed resolution:

        +

        Replace the wording in 23.1.1 paragraph 12  which begins ``The operations in table 68 are provided only..." + with:

        + +
        +

        Table 68 lists sequence operations that are provided for some types of sequential + containers but not others. An implementation shall provide these operations for all + container types shown in the ``container'' column, and shall implement them so as to take + amortized constant time.

        +
        +
        +

        141. basic_string::find_last_of, find_last_not_of say pos instead of xpos

        + Section: 21.3.6.4 [lib.string::find.last.of], 21.3.6.6 [lib.string::find.last.not.of]  Status: DR  Submitter: Arch Robison  Date: 28 Apr 1999

        +

        Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1 surely have misprints where they + say:
        +
        + — xpos <= pos and pos < size(); +

        + +

        Surely the document meant to say ``xpos < size()'' in both places.

        + +

        [Judy Ward also sent in this issue for 21.3.6.4 with the same + proposed resolution.]

        +

        Proposed resolution:

        +

        Change Sections 21.3.6.4 paragraph 1 and 21.3.6.6 paragraph 1, the line which says:
        +
        + — xpos <= pos and pos < size();
        +
        +
        to:
        +
        +
        xpos <= pos and xpos < size(); +

        +
        +

        142. lexicographical_compare complexity wrong

        + Section: 25.3.8 [lib.alg.lex.comparison]  Status: DR  Submitter: Howard Hinnant  Date: 20 Jun 1999

        +

        The lexicographical_compare complexity is specified as:
        +
        +      "At most min((last1 - first1), (last2 - first2)) + applications of the corresponding comparison."
        +
        + The best I can do is twice that expensive.

        + +

        Nicolai Josuttis comments in lib-6862: You mean, to check for + equality you have to check both < and >? Yes, IMO you are + right! (and Matt states this complexity in his book)

        + +

        Proposed resolution:

        +

        Change 25.3.8 complexity to:

        +
        + At most 2*min((last1 - first1), (last2 - first2)) + applications of the corresponding comparison. +
        + +

        Change the example at the end of paragraph 3 to read:

        +
        + [Example:
        +
        +     for ( ; first1 != last1 && first2 != last2 ; + ++first1, ++first2) {
        +       if (*first1 < *first2) return true;
        +       if (*first2 < *first1) return false;
        +     }
        +     return first1 == last1 && first2 != last2;
        +    
        + --end example] +
        +
        +

        144. Deque constructor complexity wrong

        + Section: 23.2.1.1 [lib.deque.cons]  Status: DR  Submitter: Herb Sutter  Date: 9 May 1999

        +

        In 23.2.1.1 paragraph 6, the deque ctor that takes an iterator range appears + to have complexity requirements which are incorrect, and which contradict the + complexity requirements for insert(). I suspect that the text in question, + below, was taken from vector:

        +
        +

        Complexity: If the iterators first and last are forward iterators, + bidirectional iterators, or random access iterators the constructor makes only + N calls to the copy constructor, and performs no reallocations, where N is + last - first.

        +
        +

        The word "reallocations" does not really apply to deque. Further, + all of the following appears to be spurious:

        +
        +

        It makes at most 2N calls to the copy constructor of T and log N + reallocations if they are input iterators.1)

        +

        1) The complexity is greater in the case of input iterators because each + element must be added individually: it is impossible to determine the distance + between first abd last before doing the copying.

        +
        +

        This makes perfect sense for vector, but not for deque. Why should deque gain + an efficiency advantage from knowing in advance the number of elements to + insert?

        +

        Proposed resolution:

        +

        In 23.2.1.1 paragraph 6, replace the Complexity description, including the + footnote, with the following text (which also corrects the "abd" + typo):

        +
        +

        Complexity: Makes last - first calls to the copy constructor of T.

        +
        +
        +

        146. complex<T> Inserter and Extractor need sentries

        + Section: 26.2.6 [lib.complex.ops]  Status: DR  Submitter: Angelika Langer  Date: 12 May 1999

        +

        The extractor for complex numbers is specified as: 

        + +
        + +

        template<class T, class charT, class traits> 
        + basic_istream<charT, traits>& 
        + operator>>(basic_istream<charT, traits>& is, complex<T>& x);
        +  
        + Effects: Extracts a complex number x of the form: u, (u), or (u,v), + where u is the real part and v is the imaginary part + (lib.istream.formatted). 
        + Requires: The input values be convertible to T. If bad input is + encountered, calls is.setstate(ios::failbit) (which may throw + ios::failure (lib.iostate.flags). 
        + Returns: is .

        + +
        +

        Is it intended that the extractor for complex numbers does not skip + whitespace, unlike all other extractors in the standard library do? + Shouldn't a sentry be used? 
        +
        + The inserter for complex numbers is specified as:

        + +
        + +

        template<class T, class charT, class traits> 
        + basic_ostream<charT, traits>& 
        + operator<<(basic_ostream<charT, traits>& o, const complex<T>& x);
        +
        + Effects: inserts the complex number x onto the stream o as if it were implemented as follows:
        +
        + template<class T, class charT, class traits> 
        + basic_ostream<charT, traits>& 
        + operator<<(basic_ostream<charT, traits>& o, const complex<T>& x) 
        + { 
        + basic_ostringstream<charT, traits> s; 
        + s.flags(o.flags()); 
        + s.imbue(o.getloc()); 
        + s.precision(o.precision()); 
        + s << '(' << x.real() << "," << x.imag() << ')'; 
        + return o << s.str(); 
        + }

        + +
        + +

        Is it intended that the inserter for complex numbers ignores the + field width and does not do any padding? If, with the suggested + implementation above, the field width were set in the stream then the + opening parentheses would be adjusted, but the rest not, because the + field width is reset to zero after each insertion.

        + +

        I think that both operations should use sentries, for sake of + consistency with the other inserters and extractors in the + library. Regarding the issue of padding in the inserter, I don't know + what the intent was. 

        +

        Proposed resolution:

        +

        After 26.2.6 paragraph 14 (operator>>), add a + Notes clause:

        + +
        + +

        Notes: This extraction is performed as a series of simpler + extractions. Therefore, the skipping of whitespace is specified to be the + same for each of the simpler extractions.

        + +
        +

        Rationale:

        +

        For extractors, the note is added to make it clear that skipping whitespace + follows an "all-or-none" rule.

        + +

        For inserters, the LWG believes there is no defect; the standard is correct + as written.

        +
        +

        147. Library Intro refers to global functions that aren't global

        + Section: 17.4.4.3 [lib.global.functions]  Status: DR  Submitter: Lois Goldthwaite  Date: 4 Jun 1999

        +

        The library had many global functions until 17.4.1.1 [lib.contents] + paragraph 2 was added:

        + +
        + +

        All library entities except macros, operator new and operator + delete are defined within the namespace std or namespaces nested + within namespace std.

        + +
        + +

        It appears "global function" was never updated in the following:

        + +
        + +

        17.4.4.3 - Global functions [lib.global.functions]
        +
        + -1- It is unspecified whether any global functions in the C++ Standard + Library are defined as inline (dcl.fct.spec).
        +
        + -2- A call to a global function signature described in Clauses + lib.language.support through lib.input.output behaves the same as if + the implementation declares no additional global function + signatures.*
        +
        + [Footnote: A valid C++ program always calls the expected library + global function. An implementation may also define additional + global functions that would otherwise not be called by a valid C++ + program. --- end footnote]
        +
        + -3- A global function cannot be declared by the implementation as + taking additional default arguments. 
        +
        + 17.4.4.4 - Member functions [lib.member.functions]
        +
        + -2- An implementation can declare additional non-virtual member + function signatures within a class:

        + +
        + +

        -- by adding arguments with default values to a member function + signature; The same latitude does not extend to the implementation of + virtual or global functions, however.

        + +
        +
        +

        Proposed resolution:

        +

        Change "global" to "global or non-member" in:

        +
        +

        17.4.4.3 [lib.global.functions] section title,
        + 17.4.4.3 [lib.global.functions] para 1,
        + 17.4.4.3 [lib.global.functions] para 2 in 2 places plus 2 + places in the footnote,
        + 17.4.4.3 [lib.global.functions] para 3,
        + 17.4.4.4 [lib.member.functions] para 2

        +
        +

        Rationale:

        +

        + Because operator new and delete are global, the proposed resolution + was changed from "non-member" to "global or non-member. +

        +
        +

        148. Functions in the example facet BoolNames should be const

        + Section: 22.2.8 [lib.facets.examples]  Status: DR  Submitter: Jeremy Siek  Date: 3 Jun 1999

        +

        In 22.2.8 paragraph 13, the do_truename() and + do_falsename() functions in the example facet BoolNames should be + const. The functions they are overriding in + numpunct_byname<char> are const.

        +

        Proposed resolution:

        +

        In 22.2.8 paragraph 13, insert "const" in + two places:

        +
        +

        string do_truename() const { return "Oui Oui!"; }
        + string do_falsename() const { return "Mais Non!"; }

        +
        +
        +

        150. Find_first_of says integer instead of iterator

        + Section: 25.1.4 [lib.alg.find.first.of]  Status: DR  Submitter: Matt McClure  Date: 30 Jun 1999

        +

        Proposed resolution:

        +

        Change 25.1.4 paragraph 2 from:

        + +
        +

        Returns: The first iterator i in the range [first1, last1) such + that for some integer j in the range [first2, last2) ...

        +
        + +

        to:

        + +
        +

        Returns: The first iterator i in the range [first1, last1) such + that for some iterator j in the range [first2, last2) ...

        +
        +
        +

        151. Can't currently clear() empty container

        + Section: 23.1.1 [lib.sequence.reqmts]  Status: DR  Submitter: Ed Brey  Date: 21 Jun 1999

        +

        For both sequences and associative containers, a.clear() has the + semantics of erase(a.begin(),a.end()), which is undefined for an empty + container since erase(q1,q2) requires that q1 be dereferenceable + (23.1.1,3 and 23.1.2,7). When the container is empty, a.begin() is + not dereferenceable.
        +
        + The requirement that q1 be unconditionally dereferenceable causes many + operations to be intuitively undefined, of which clearing an empty + container is probably the most dire.
        +
        + Since q1 and q2 are only referenced in the range [q1, q2), and [q1, + q2) is required to be a valid range, stating that q1 and q2 must be + iterators or certain kinds of iterators is unnecessary. +

        +

        Proposed resolution:

        +

        In 23.1.1, paragraph 3, change:

        +
        +

        p and q2 denote valid iterators to a, q and q1 denote valid dereferenceable iterators to a, [q1, q2) denotes a valid range

        +
        +

        to:

        +
        +

        p denotes a valid iterator to a, q denotes a valid dereferenceable iterator to a, [q1, q2) denotes a valid range + in a +

        +
        +

        In 23.1.2, paragraph 7, change:

        +
        +

        p and q2 are valid iterators to a, q and q1 are valid dereferenceable + iterators to a, [q1, q2) is a valid range

        +
        +

        to

        +
        +

        p is a valid iterator to a, q is a valid dereferenceable iterator to a, [q1, q2) is a valid range + into a +

        +
        +
        +

        152. Typo in scan_is() semantics

        + Section: 22.2.1.1.2 [lib.locale.ctype.virtuals]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        The semantics of scan_is() (paragraphs 4 and 6) is not exactly described + because there is no function is() which only takes a character as + argument. Also, in the effects clause (paragraph 3), the semantic is also kept + vague.

        +

        Proposed resolution:

        +

        In 22.2.1.1.2 paragraphs 4 and 6, change the returns + clause from:

        +
        +

        "... such that is(*p) + would..."

        +
        +

        to:  "... such that is(m, *p) + would...."

        +
        +

        153. Typo in narrow() semantics

        + Section: 22.2.1.3.2 [lib.facet.ctype.char.members]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        The description of the array version of narrow() (in + paragraph 11) is flawed: There is no member do_narrow() which + takes only three arguments because in addition to the range a default + character is needed.

        + +

        Additionally, for both widen and narrow we have + two signatures followed by a Returns clause that only addresses + one of them.

        + +

        Proposed resolution:

        +

        Change the returns clause in 22.2.1.3.2 + paragraph 10 from:

        +

            Returns: do_widen(low, high, to).

        + +

        to:

        +

            Returns: do_widen(c) or do_widen(low, high, to), + respectively.

        + +

        Change 22.2.1.3.2 paragraph 10 and 11 from:

        +
                char        narrow(char c, char /*dfault*/) const;
        +         const char* narrow(const char* low, const char* high,
        +                            char /*dfault*/, char* to) const;
        +
                Returns: do_narrow(low, high, to).
        +

        to:

        +
                char        narrow(char c, char dfault) const;
        +         const char* narrow(const char* low, const char* high,
        +                            char dfault, char* to) const;
        +
                Returns: do_narrow(c, dfault) or
        +                  do_narrow(low, high, dfault, to), respectively.
        + +

        [Kona: 1) the problem occurs in additional places, 2) a user + defined version could be different.]

        + +

        [Post-Tokyo: Dietmar provided the above wording at the request of + the LWG. He could find no other places the problem occurred. He + asks for clarification of the Kona "a user defined + version..." comment above. Perhaps it was a circuitous way of + saying "dfault" needed to be uncommented?]

        + +

        [Post-Toronto: the issues list maintainer has merged in the + proposed resolution from issue 207, which addresses the + same paragraphs.]

        +
        +

        154. Missing double specifier for do_get() +

        + Section: 22.2.2.1.2 [lib.facet.num.get.virtuals]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        The table in paragraph 7 for the length modifier does not list the length + modifier l to be applied if the type is double. Thus, the + standard asks the implementation to do undefined things when using scanf() + (the missing length modifier for scanf() when scanning doubles + is actually a problem I found quite often in production code, too).

        +

        Proposed resolution:

        +

        In 22.2.2.1.2 , paragraph 7, add a row in the Length + Modifier table to say that for double a length modifier + l is to be used.

        +

        Rationale:

        +

        The standard makes an embarrassing beginner's mistake.

        +
        +

        155. Typo in naming the class defining the class Init +

        + Section: 27.3 [lib.iostream.objects]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        There are conflicting statements about where the class + Init is defined. According to 27.3 paragraph 2 + it is defined as basic_ios::Init, according to 27.4.2 it is defined as ios_base::Init.

        +

        Proposed resolution:

        +

        Change 27.3 paragraph 2 from + "basic_ios::Init" to + "ios_base::Init".

        +

        Rationale:

        +

        Although not strictly wrong, the standard was misleading enough to warrant + the change.

        +
        +

        156. Typo in imbue() description

        + Section: 27.4.2.3 [lib.ios.base.locales]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        There is a small discrepancy between the declarations of + imbue(): in 27.4.2 the argument is passed as + locale const& (correct), in 27.4.2.3 it + is passed as locale const (wrong).

        +

        Proposed resolution:

        +

        In 27.4.2.3 change the imbue argument + from "locale const" to "locale + const&". +

        +
        +

        158. Underspecified semantics for setbuf() +

        + Section: 27.5.2.4.2 [lib.streambuf.virt.buffer]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        The default behavior of setbuf() is described only for the + situation that gptr() != 0 && gptr() != egptr(): + namely to do nothing. What has to be done in other situations  + is not described although there is actually only one reasonable + approach, namely to do nothing, too.

        + +

        Since changing the buffer would almost certainly mess up most + buffer management of derived classes unless these classes do it + themselves, the default behavior of setbuf() should always be + to do nothing.

        +

        Proposed resolution:

        +

        Change 27.5.2.4.2 , paragraph 3, Default behavior, + to: "Default behavior: Does nothing. Returns this."

        +
        +

        159. Strange use of underflow() +

        + Section: 27.5.2.4.3 [lib.streambuf.virt.get]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        The description of the meaning of the result of + showmanyc() seems to be rather strange: It uses calls to + underflow(). Using underflow() is strange because + this function only reads the current character but does not extract + it, uflow() would extract the current character. This should + be fixed to use sbumpc() instead.

        +

        Proposed resolution:

        +

        Change 27.5.2.4.3 paragraph 1, + showmanyc()returns clause, by replacing the word + "supplied" with the words "extracted from the + stream".

        +
        +

        160. Typo: Use of non-existing function exception() +

        + Section: 27.6.1.1 [lib.istream]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        The paragraph 4 refers to the function exception() which + is not defined. Probably, the referred function is + basic_ios<>::exceptions().

        +

        Proposed resolution:

        +

        In 27.6.1.1 , 27.6.1.3 , paragraph 1, + 27.6.2.1 , paragraph 3, and 27.6.2.5.1 , + paragraph 1, change "exception()" to + "exceptions()".

        + +

        [Note to Editor: "exceptions" with an "s" + is the correct spelling.]

        +
        +

        161. Typo: istream_iterator vs. istreambuf_iterator +

        + Section: 27.6.1.2.2 [lib.istream.formatted.arithmetic]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        The note in the second paragraph pretends that the first argument + is an object of type istream_iterator. This is wrong: It is + an object of type istreambuf_iterator.

        +

        Proposed resolution:

        +

        Change 27.6.1.2.2 from:

        +
        +

        The first argument provides an object of the istream_iterator class...

        +
        +

        to

        +
        +

        The first argument provides an object of the istreambuf_iterator class...

        +
        +
        +

        164. do_put() has apparently unused fill argument

        + Section: 22.2.5.3.2 [lib.locale.time.put.virtuals]  Status: DR  Submitter: Angelika Langer  Date: 23 Jul 1999

        +

        In 22.2.5.3.2 the do_put() function is specified + as taking a fill character as an argument, but the description of the + function does not say whether the character is used at all and, if so, + in which way. The same holds for any format control parameters that + are accessible through the ios_base& argument, such as the + adjustment or the field width. Is strftime() supposed to use the fill + character in any way? In any case, the specification of + time_put.do_put() looks inconsistent to me.

        Is the + signature of do_put() wrong, or is the effects clause incomplete?

        +

        Proposed resolution:

        +

        Add the following note after 22.2.5.3.2 + paragraph 2:

        +
        +

        [Note: the fill argument may be used in the implementation-defined formats, or by derivations. A space character is a reasonable default + for this argument. --end Note]

        +
        +

        Rationale:

        +

        The LWG felt that while the normative text was correct, + users need some guidance on what to pass for the fill + argument since the standard doesn't say how it's used.

        +
        +

        165. xsputn(), pubsync() never called by basic_ostream members?

        + Section: 27.6.2.1 [lib.ostream]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        Paragraph 2 explicitly states that none of the basic_ostream + functions falling into one of the groups "formatted output functions" + and "unformatted output functions" calls any stream buffer function + which might call a virtual function other than overflow(). Basically + this is fine but this implies that sputn() (this function would call + the virtual function xsputn()) is never called by any of the standard + output functions. Is this really intended? At minimum it would be convenient to + call xsputn() for strings... Also, the statement that overflow() + is the only virtual member of basic_streambuf called is in conflict + with the definition of flush() which calls rdbuf()->pubsync() + and thereby the virtual function sync() (flush() is listed + under "unformatted output functions").

        +

        In addition, I guess that the sentence starting with "They may use other + public members of basic_ostream ..." probably was intended to + start with "They may use other public members of basic_streamuf..." + although the problem with the virtual members exists in both cases.

        +

        I see two obvious resolutions:

        +
          +
        1. state in a footnote that this means that xsputn() will never be + called by any ostream member and that this is intended.
        2. +
        3. relax the restriction and allow calling overflow() and xsputn(). + Of course, the problem with flush() has to be resolved in some way.
        4. +
        +

        Proposed resolution:

        +

        Change the last sentence of 27.6.2.1 (lib.ostream) paragraph 2 from:

        +
        +

        They may use other public members of basic_ostream except that they do not + invoke any virtual members of rdbuf() except overflow().

        +
        +

        to:

        +
        +

        They may use other public members of basic_ostream except that they shall + not invoke any virtual members of rdbuf() except overflow(), xsputn(), and + sync().

        +
        + +

        [Kona: the LWG believes this is a problem. Wish to ask Jerry or + PJP why the standard is written this way.]

        + +

        [Post-Tokyo: Dietmar supplied wording at the request of the + LWG. He comments: The rules can be made a little bit more specific if + necessary be explicitly spelling out what virtuals are allowed to be + called from what functions and eg to state specifically that flush() + is allowed to call sync() while other functions are not.]

        +
        +

        168. Typo: formatted vs. unformatted

        + Section: 27.6.2.6 [lib.ostream.unformatted]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        The first paragraph begins with a descriptions what has to be done + in formatted output functions. Probably this is a typo and the + paragraph really want to describe unformatted output functions...

        +

        Proposed resolution:

        +

        In 27.6.2.6 paragraph 1, the first and last + sentences, change the word "formatted" to + "unformatted":

        +
        +

        "Each unformatted output function begins ..."
        + "... value specified for the unformatted output + function."

        +
        +
        +

        169. Bad efficiency of overflow() mandated

        + Section: 27.7.1.3 [lib.stringbuf.virtuals]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        Paragraph 8, Notes, of this section seems to mandate an extremely + inefficient way of buffer handling for basic_stringbuf, + especially in view of the restriction that basic_ostream + member functions are not allowed to use xsputn() (see 27.6.2.1 ): For each character to be inserted, a new buffer + is to be created.

        +

        Of course, the resolution below requires some handling of + simultaneous input and output since it is no longer possible to update + egptr() whenever epptr() is changed. A possible + solution is to handle this in underflow().

        +

        Proposed resolution:

        +

        In 27.7.1.3 paragraph 8, Notes, insert the words + "at least" as in the following:

        +
        +

        To make a write position available, the function reallocates (or initially + allocates) an array object with a sufficient number of elements to hold the + current array object (if any), plus at least one additional write + position.

        +
        +
        +

        170. Inconsistent definition of traits_type +

        + Section: 27.7.4 [lib.stringstream]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        The classes basic_stringstream (27.7.4 ), + basic_istringstream (27.7.2 ), and + basic_ostringstream (27.7.3 ) are inconsistent + in their definition of the type traits_type: For + istringstream, this type is defined, for the other two it is + not. This should be consistent.

        +

        Proposed resolution:

        +

        Proposed resolution:

        To the declarations of + basic_ostringstream (27.7.3 ) and + basic_stringstream (27.7.4 ) add:

        +
        +
        typedef traits traits_type;
        +
        +
        +

        171. Strange seekpos() semantics due to joint position

        + Section: 27.8.1.4 [lib.filebuf.virtuals]  Status: DR  Submitter: Dietmar Kühl  Date: 20 Jul 1999

        +

        Overridden virtual functions, seekpos()

        In 27.8.1.1 paragraph 3, it is stated that a joint input and + output position is maintained by basic_filebuf. Still, the + description of seekpos() seems to talk about different file + positions. In particular, it is unclear (at least to me) what is + supposed to happen to the output buffer (if there is one) if only the + input position is changed. The standard seems to mandate that the + output buffer is kept and processed as if there was no positioning of + the output position (by changing the input position). Of course, this + can be exactly what you want if the flag ios_base::ate is + set. However, I think, the standard should say something like + this:

        +
          +
        • If (which & mode) == 0 neither read nor write position is + changed and the call fails. Otherwise, the joint read and write position is + altered to correspond to sp.
        • +
        • If there is an output buffer, the output sequences is updated and any + unshift sequence is written before the position is altered.
        • +
        • If there is an input buffer, the input sequence is updated after the + position is altered.
        • +
        +

        Plus the appropriate error handling, that is...

        +

        Proposed resolution:

        +

        Change the unnumbered paragraph in 27.8.1.4 (lib.filebuf.virtuals) before + paragraph 14 from:

        +
        +

        pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in | + ios_base::out);

        +

        Alters the file position, if possible, to correspond to the position stored + in sp (as described below).

        +

        - if (which&ios_base::in)!=0, set the file position to sp, then update + the input sequence

        +

        - if (which&ios_base::out)!=0, then update the output sequence, write + any unshift sequence, and set the file position to sp.

        +
        +

        to:

        +
        +

        pos_type seekpos(pos_type sp, ios_base::openmode = ios_base::in | + ios_base::out);

        +

        Alters the file position, if possible, to correspond to the position stored + in sp (as described below). Altering the file position performs as follows:

        +

        1. if (om & ios_base::out)!=0, then update the output sequence and + write any unshift sequence;

        +

        2. set the file position to sp;

        +

        3. if (om & ios_base::in)!=0, then update the input sequence;

        +

        where om is the open mode passed to the last call to open(). The operation + fails if is_open() returns false.

        +
        + +

        [Kona: Dietmar is working on a proposed resolution.]

        +

        [Post-Tokyo: Dietmar supplied the above wording.]

        +
        +

        172. Inconsistent types for basic_istream::ignore() +

        + Section: 27.6.1.3 [lib.istream.unformatted]  Status: DR  Submitter: Greg Comeau, Dietmar Kühl  Date: 23 Jul 1999

        +

        In 27.6.1.1 the function + ignore() gets an object of type streamsize as first + argument. However, in 27.6.1.3 + paragraph 23 the first argument is of type int. +

        + +

        As far as I can see this is not really a contradiction because + everything is consistent if streamsize is typedef to be + int. However, this is almost certainly not what was + intended. The same thing happened to basic_filebuf::setbuf(), + as described in issue 173.

        + +

        Darin Adler also + submitted this issue, commenting: Either 27.6.1.1 should be modified + to show a first parameter of type int, or 27.6.1.3 should be modified + to show a first parameter of type streamsize and use + numeric_limits<streamsize>::max.

        +

        Proposed resolution:

        +

        In 27.6.1.3 paragraph 23 and 24, change both uses + of int in the description of ignore() to + streamsize.

        +
        +

        173. Inconsistent types for basic_filebuf::setbuf() +

        + Section: 27.8.1.4 [lib.filebuf.virtuals]  Status: DR  Submitter: Greg Comeau, Dietmar Kühl  Date: 23 Jul 1999

        + +

        + In 27.8.1.1 the function setbuf() gets an + object of type streamsize as second argument. However, in + 27.8.1.4 paragraph 9 the second argument is of type + int. +

        + +

        + As far as I can see this is not really a contradiction because + everything is consistent if streamsize is typedef to be + int. However, this is almost certainly not what was + intended. The same thing happened to basic_istream::ignore(), + as described in issue 172. +

        + +

        Proposed resolution:

        +

        In 27.8.1.4 paragraph 9, change all uses of + int in the description of setbuf() to + streamsize.

        +
        +

        174. Typo: OFF_T vs. POS_T +

        + Section: D.6 [depr.ios.members]  Status: DR  Submitter: Dietmar Kühl  Date: 23 Jul 1999

        +

        According to paragraph 1 of this section, streampos is the + type OFF_T, the same type as streamoff. However, in + paragraph 6 the streampos gets the type POS_T +

        +

        Proposed resolution:

        +

        Change D.6 paragraph 1 from "typedef + OFF_T streampos;" to "typedef POS_T + streampos;"

        +
        +

        175. Ambiguity for basic_streambuf::pubseekpos() and a few other functions.

        + Section: D.6 [depr.ios.members]  Status: DR  Submitter: Dietmar Kühl  Date: 23 Jul 1999

        +

        According to paragraph 8 of this section, the methods + basic_streambuf::pubseekpos(), + basic_ifstream::open(), and basic_ofstream::open + "may" be overloaded by a version of this function taking the + type ios_base::open_mode as last argument argument instead of + ios_base::openmode (ios_base::open_mode is defined + in this section to be an alias for one of the integral types). The + clause specifies, that the last argument has a default argument in + three cases. However, this generates an ambiguity with the overloaded + version because now the arguments are absolutely identical if the last + argument is not specified.

        +

        Proposed resolution:

        +

        In D.6 paragraph 8, remove the default arguments for + basic_streambuf::pubseekpos(), + basic_ifstream::open(), and + basic_ofstream::open(). +

        +
        +

        176. exceptions() in ios_base...?

        + Section: D.6 [depr.ios.members]  Status: DR  Submitter: Dietmar Kühl  Date: 23 Jul 1999

        +

        The "overload" for the function exceptions() in + paragraph 8 gives the impression that there is another function of + this function defined in class ios_base. However, this is not + the case. Thus, it is hard to tell how the semantics (paragraph 9) can + be implemented: "Call the corresponding member function specified + in clause 27 ."

        +

        Proposed resolution:

        +

        In D.6 paragraph 8, move the declaration of the + function exceptions()into class basic_ios.

        +
        +

        181. make_pair() unintended behavior

        + Section: 20.2.2 [lib.pairs]  Status: DR  Submitter: Andrew Koenig  Date: 3 Aug 1999

        +

        The claim has surfaced in Usenet that expressions such as
        +
        +        make_pair("abc", 3)
        +
        + are illegal, notwithstanding their use in examples, because template instantiation tries to bind the first template + parameter to const char (&)[4], which type is uncopyable.
        +
        + I doubt anyone intended that behavior... +

        +

        Proposed resolution:

        +

        In 20.2 , paragraph 1 change the following + declaration of make_pair():

        +
        +
        template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);
        +
        +

        to:

        +
        +
        template <class T1, class T2> pair<T1,T2> make_pair(T1, T2);
        +
        +

        In 20.2.2 paragraph 7 and the line before, change:

        +
        +
        template <class T1, class T2>
        + pair<T1, T2> make_pair(const T1& x, const T2& y);
        +
        +

        to:

        +
        +
        template <class T1, class T2>
        + pair<T1, T2> make_pair(T1 x, T2 y);
        +
        +

        and add the following footnote to the effects clause:

        +
        +

        According to 12.8 [class.copy], an implementation is permitted + to not perform a copy of an argument, thus avoiding unnecessary + copies.

        +
        +

        Rationale:

        +

        Two potential fixes were suggested by Matt Austern and Dietmar + Kühl, respectively, 1) overloading with array arguments, and 2) use of + a reference_traits class with a specialization for arrays. Andy + Koenig suggested changing to pass by value. In discussion, it appeared + that this was a much smaller change to the standard that the other two + suggestions, and any efficiency concerns were more than offset by the + advantages of the solution. Two implementors reported that the + proposed resolution passed their test suites.

        +
        +

        183. I/O stream manipulators don't work for wide character streams

        + Section: 27.6.3 [lib.std.manip]  Status: DR  Submitter: Andy Sawyer  Date: 7 Jul 1999

        +

        27.6.3 paragraph 3 says (clause numbering added for + exposition): [lib.std.manip] +

        +
        +

        Returns: An object s of unspecified type such that if [1] out is an (instance + of) basic_ostream then the expression out<<s behaves as if f(s) were + called, and if [2] in is an (instance of) basic_istream then the expression + in>>s behaves as if f(s) were called. Where f can be defined as: ios_base& + f(ios_base& str, ios_base::fmtflags mask) { // reset specified flags + str.setf(ios_base::fmtflags(0), mask); return str; } [3] The expression + out<<s has type ostream& and value out. [4] The expression in>>s + has type istream& and value in.

        +
        +

        Given the definitions [1] and [2] for out and in, surely [3] should read: + "The expression out << s has type basic_ostream& ..." and + [4] should read: "The expression in >> s has type basic_istream& + ..."

        +

        If the wording in the standard is correct, I can see no way of implementing + any of the manipulators so that they will work with wide character streams.

        +

        e.g. wcout << setbase( 16 );

        +

        Must have value 'wcout' (which makes sense) and type 'ostream&' (which + doesn't).

        +

        The same "cut'n'paste" type also seems to occur in Paras 4,5,7 and + 8. In addition, Para 6 [setfill] has a similar error, but relates only to + ostreams.

        +

        I'd be happier if there was a better way of saying this, to make it clear + that the value of the expression is "the same specialization of + basic_ostream as out"&

        +

        Proposed resolution:

        +

        Replace section 27.6.3 except paragraph 1 with the + following:

        +
        +

        2- The type designated smanip in each of the following function descriptions is implementation-specified and may be different for each + function.
        +
        + smanip resetiosflags(ios_base::fmtflags mask);
        +
        + -3- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves + as if f(s, mask) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if + f(s, mask) were called. The function f can be defined as:*
        +
        + [Footnote: The expression cin >> resetiosflags(ios_base::skipws) clears ios_base::skipws in the format flags stored in the + basic_istream<charT,traits> object cin (the same as cin >> noskipws), and the expression cout << resetiosflags(ios_base::showbase) clears + ios_base::showbase in the format flags stored in the basic_ostream<charT,traits> object cout (the same as cout << + noshowbase). --- end footnote]
        +
        +      ios_base& f(ios_base& str, ios_base::fmtflags mask)
        +    {
        +    // reset specified flags
        +    str.setf(ios_base::fmtflags(0), mask);
        +    return str;
        +    }
        +

        + The expression out<<s has type basic_ostream<charT,traits>& and value out. + The expression in>>s has type basic_istream<charT,traits>& and value in.
        +
        +  smanip setiosflags(ios_base::fmtflags mask);
        +
        + -4- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves + as if f(s, mask) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, + mask) were called. The function f can be defined as:
        +
        +      ios_base& f(ios_base& str, ios_base::fmtflags mask)
        +    {
        +    // set specified flags
        +    str.setf(mask);
        +    return str;
        +    }
        +

        + The expression out<<s has type basic_ostream<charT,traits>& and value out. + The expression in>>s has type basic_istream<charT,traits>& and value in.
        +
        + smanip setbase(int base);
        +
        + -5- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves + as if f(s, base) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, + base) were called. The function f can be defined as:
        +
        +      ios_base& f(ios_base& str, int base)
        +    {
        +    // set basefield
        +    str.setf(base == 8 ? ios_base::oct :
        +    base == 10 ? ios_base::dec :
        +    base == 16 ? ios_base::hex :
        +    ios_base::fmtflags(0), ios_base::basefield);
        +    return str;
        +    }
        +

        + The expression out<<s has type basic_ostream<charT,traits>& and value out. + The expression in>>s has type basic_istream<charT,traits>& and value in.
        +
        + smanip setfill(char_type c);
        +

        + -6- Returns: An object s of unspecified type such that if out is (or is derived from) basic_ostream<charT,traits> and c has type charT then the + expression out<<s behaves as if f(s, c) were called. The function f can be + defined as:
        +
        +       template<class charT, class traits>
        +    basic_ios<charT,traits>& f(basic_ios<charT,traits>& str, charT c)
        +    {
        +    // set fill character
        +    str.fill(c);
        +    return str;
        +    }
        +

        + The expression out<<s has type basic_ostream<charT,traits>& and value out.
        +
        + smanip setprecision(int n);
        +
        + -7- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves + as if f(s, n) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, n) + were called. The function f can be defined as:
        +
        +       ios_base& f(ios_base& str, int n)
        +    {
        +    // set precision
        +    str.precision(n);
        +    return str;
        +    }
        +

        + The expression out<<s has type basic_ostream<charT,traits>& and value out. + The expression in>>s has type basic_istream<charT,traits>& and value in
        + .
        + smanip setw(int n);
        +

        + -8- Returns: An object s of unspecified type such that if out is an instance of basic_ostream<charT,traits> then the expression out<<s behaves + as if f(s, n) were called, or if in is an instance of basic_istream<charT,traits> then the expression in>>s behaves as if f(s, n) + were called. The function f can be defined as:
        +
        +       ios_base& f(ios_base& str, int n)
        +    {
        +    // set width
        +    str.width(n);
        +    return str;
        +    }
        +

        + The expression out<<s has type + basic_ostream<charT,traits>& and value out. The expression + in>>s has type basic_istream<charT,traits>& and value + in. +

        +
        + +

        [Kona: Andy Sawyer and Beman Dawes will work to improve the wording of + the proposed resolution.]

        + +

        [Tokyo - The LWG noted that issue 216 involves + the same paragraphs.]

        + +

        [Post-Tokyo: The issues list maintainer combined the proposed + resolution of this issue with the proposed resolution for issue 216 as they both involved the same paragraphs, and were so + intertwined that dealing with them separately appear fraught with + error. The full text was supplied by Bill Plauger; it was cross + checked against changes supplied by Andy Sawyer. It should be further + checked by the LWG.]

        +
        +

        184. numeric_limits<bool> wording problems

        + Section: 18.2.1.5 [lib.numeric.special]  Status: DR  Submitter: Gabriel Dos Reis  Date: 21 Jul 1999

        +

        bools are defined by the standard to be of integer types, as per + 3.9.1 paragraph 7. However "integer types" + seems to have a special meaning for the author of 18.2. The net effect + is an unclear and confusing specification for + numeric_limits<bool> as evidenced below.

        + +

        18.2.1.2/7 says numeric_limits<>::digits is, for built-in integer + types, the number of non-sign bits in the representation.

        + +

        4.5/4 states that a bool promotes to int ; whereas 4.12/1 says any non zero + arithmetical value converts to true.

        + +

        I don't think it makes sense at all to require + numeric_limits<bool>::digits and numeric_limits<bool>::digits10 to + be meaningful.

        + +

        The standard defines what constitutes a signed (resp. unsigned) integer + types. It doesn't categorize bool as being signed or unsigned. And the set of + values of bool type has only two elements.

        + +

        I don't think it makes sense to require numeric_limits<bool>::is_signed + to be meaningful.

        + +

        18.2.1.2/18 for numeric_limits<integer_type>::radix  says:

        +
        +

        For integer types, specifies the base of the representation.186)

        +
        + +

        This disposition is at best misleading and confusing for the standard + requires a "pure binary numeration system" for integer types as per + 3.9.1/7

        + +

        The footnote 186) says: "Distinguishes types with base other than 2 (e.g + BCD)."  This also erroneous as the standard never defines any integer + types with base representation other than 2.

        + +

        Furthermore, numeric_limits<bool>::is_modulo and + numeric_limits<bool>::is_signed have similar problems.

        +

        Proposed resolution:

        +

        Append to the end of 18.2.1.5 :

        +
        +

        The specialization for bool shall be provided as follows:

        +
            namespace std {
        +        template<> class numeric_limits<bool> {
        +        public:
        +          static const bool is_specialized = true;
        +          static bool min() throw() { return false; }
        +          static bool max() throw() { return true; }
        + 
        +          static const int  digits = 1;
        +          static const int  digits10 = 0;
        +          static const bool is_signed = false;
        +          static const bool is_integer = true;
        +          static const bool is_exact = true;
        +          static const int  radix = 2;
        +          static bool epsilon() throw() { return 0; }
        +          static bool round_error() throw() { return 0; }
        + 
        +          static const int  min_exponent = 0;
        +          static const int  min_exponent10 = 0;
        +          static const int  max_exponent = 0;
        +          static const int  max_exponent10 = 0;
        + 
        +          static const bool has_infinity = false;
        +          static const bool has_quiet_NaN = false;
        +          static const bool has_signaling_NaN = false;
        +          static const float_denorm_style has_denorm = denorm_absent;
        +          static const bool has_denorm_loss = false;
        +          static bool infinity() throw() { return 0; }
        +          static bool quiet_NaN() throw() { return 0; }
        +          static bool signaling_NaN() throw() { return 0; }
        +          static bool denorm_min() throw() { return 0; }
        + 
        +          static const bool is_iec559 = false;
        +          static const bool is_bounded = true;
        +          static const bool is_modulo = false;
        + 
        +          static const bool traps = false;
        +          static const bool tinyness_before = false;
        +          static const float_round_style round_style = round_toward_zero;
        +        };
        +      }
        +
        + +

        [Tokyo:  The LWG desires wording that specifies exact values + rather than more general wording in the original proposed + resolution.]

        + +

        [Post-Tokyo:  At the request of the LWG in Tokyo, Nico + Josuttis provided the above wording.]

        +
        +

        185. Questionable use of term "inline"

        + Section: 20.3 [lib.function.objects]  Status: DR  Submitter: UK Panel  Date: 26 Jul 1999

        +

        Paragraph 4 of 20.3 says:

        +
        +

         [Example: To negate every element of a: transform(a.begin(), a.end(), + a.begin(), negate<double>()); The corresponding functions will inline + the addition and the negation. end example]

        +
        +

        (Note: The "addition" referred to in the above is in para 3) we can + find no other wording, except this (non-normative) example which suggests that + any "inlining" will take place in this case.

        +

        Indeed both:

        +
        +

        17.4.4.3 Global Functions [lib.global.functions] 1 It is + unspecified whether any global functions in the C++ Standard Library + are defined as inline (7.1.2).

        +
        +

        and

        +
        +

        17.4.4.4 Member Functions [lib.member.functions] 1 It is + unspecified whether any member functions in the C++ Standard Library + are defined as inline (7.1.2).

        +
        +

        take care to state that this may indeed NOT be the case.

        +

        Thus the example "mandates" behavior that is explicitly + not required elsewhere.

        +

        Proposed resolution:

        +

        In 20.3 paragraph 1, remove the sentence:

        +
        +

        They are important for the effective use of the library.

        +
        +

        Remove 20.3 paragraph 2, which reads:

        +
        +

        Using function objects together with function templates + increases the expressive power of the library as well as making the + resulting code much more efficient.

        +
        +

        In 20.3 paragraph 4, remove the sentence:

        +
        +

        The corresponding functions will inline the addition and the + negation.

        +
        + +

        [Kona: The LWG agreed there was a defect.]

        +

        [Tokyo: The LWG crafted the proposed resolution.]

        +
        +

        186. bitset::set() second parameter should be bool

        + Section: 23.3.5.2 [lib.bitset.members]  Status: DR  Submitter: Darin Adler  Date: 13 Aug 1999

        +

        In section 23.3.5.2 , paragraph 13 defines the + bitset::set operation to take a second parameter of type int. The + function tests whether this value is non-zero to determine whether to + set the bit to true or false. The type of this second parameter should + be bool. For one thing, the intent is to specify a Boolean value. For + another, the result type from test() is bool. In addition, it's + possible to slice an integer that's larger than an int. This can't + happen with bool, since conversion to bool has the semantic of + translating 0 to false and any non-zero value to true.

        +

        Proposed resolution:

        +

        In 23.3.5 Para 1 Replace:

        +
        +
        bitset<N>& set(size_t pos, int val = true ); 
        +
        +

        With:

        +
        +
        bitset<N>& set(size_t pos, bool val = true );
        +
        +

        In 23.3.5.2 Para 12(.5) Replace:

        +
        +
        bitset<N>& set(size_t pos, int val = 1 );
        +
        +

        With:

        +
        +
        bitset<N>& set(size_t pos, bool val = true );
        +
        + +

        [Kona: The LWG agrees with the description.  Andy Sawyer will work + on better P/R wording.]

        +

        [Post-Tokyo: Andy provided the above wording.]

        +

        Rationale:

        +

        + bool is a better choice. It is believed that binary + compatibility is not an issue, because this member function is + usually implemented as inline, and because it is already + the case that users cannot rely on the type of a pointer to a + nonvirtual member of a standard library class.

        +
        +

        189. setprecision() not specified correctly

        + Section: 27.4.2.2 [lib.fmtflags.state]  Status: DR  Submitter: Andrew Koenig  Date: 25 Aug 1999

        +

        27.4.2.2 paragraph 9 claims that setprecision() sets the precision, + and includes a parenthetical note saying that it is the number of + digits after the decimal point.
        +
        + This claim is not strictly correct. For example, in the default + floating-point output format, setprecision sets the number of + significant digits printed, not the number of digits after the decimal + point.
        +
        + I would like the committee to look at the definition carefully and + correct the statement in 27.4.2.2

        +

        Proposed resolution:

        +

        Remove from 27.4.2.2 , paragraph 9, the text + "(number of digits after the decimal point)".

        +
        +

        193. Heap operations description incorrect

        + Section: 25.3.6 [lib.alg.heap.operations]  Status: DR  Submitter: Markus Mauhart  Date: 24 Sep 1999

        +

        25.3.6 [lib.alg.heap.operations] states two key properties of a heap [a,b), the first of them + is
        +
        +     `"(1) *a is the largest element"
        +
        + I think this is incorrect and should be changed to the wording in the proposed + resolution.

        +

        Actually there are two independent changes:

        +
        +

        A-"part of largest equivalence class" instead of "largest", cause 25.3 + [lib.alg.sorting] asserts "strict weak ordering" for all its sub clauses.

        +

        B-Take 'an oldest' from that equivalence class, otherwise the heap functions could not be used for a + priority queue as explained in 23.2.3.2.2 [lib.priqueue.members] (where I assume that a "priority queue" respects priority AND time).

        +
        +

        Proposed resolution:

        +

        Change 25.3.6 property (1) from:

        +
        +

        (1) *a is the largest element

        +
        +

        to:

        +
        +

        (1) There is no element greater than *a +

        +
        +
        +

        195. Should basic_istream::sentry's constructor ever set eofbit?

        + Section: 27.6.1.1.2 [lib.istream::sentry]  Status: DR  Submitter: Matt Austern  Date: 13 Oct 1999

        +

        Suppose that is.flags() & ios_base::skipws is nonzero. + What should basic_istream<>::sentry's constructor do if it + reaches eof while skipping whitespace? 27.6.1.1.2/5 suggests it + should set failbit. Should it set eofbit as well? The standard + doesn't seem to answer that question.

        + +

        On the one hand, nothing in 27.6.1.1.2 says that + basic_istream<>::sentry should ever set eofbit. On the + other hand, 27.6.1.1 paragraph 4 says that if + extraction from a streambuf "returns + traits::eof(), then the input function, except as explicitly + noted otherwise, completes its actions and does + setstate(eofbit)". So the question comes down to + whether basic_istream<>::sentry's constructor is an + input function.

        + +

        Comments from Jerry Schwarz:

        +
        +

        It was always my intention that eofbit should be set any time that a + virtual returned something to indicate eof, no matter what reason + iostream code had for calling the virtual.

        +

        + The motivation for this is that I did not want to require streambufs + to behave consistently if their virtuals are called after they have + signaled eof.

        +

        + The classic case is a streambuf reading from a UNIX file. EOF isn't + really a state for UNIX file descriptors. The convention is that a + read on UNIX returns 0 bytes to indicate "EOF", but the file + descriptor isn't shut down in any way and future reads do not + necessarily also return 0 bytes. In particular, you can read from + tty's on UNIX even after they have signaled "EOF". (It + isn't always understood that a ^D on UNIX is not an EOF indicator, but + an EOL indicator. By typing a "line" consisting solely of + ^D you cause a read to return 0 bytes, and by convention this is + interpreted as end of file.)

        +
        +

        Proposed resolution:

        +

        Add a sentence to the end of 27.6.1.1.2 paragraph 2:

        +
        +

        If is.rdbuf()->sbumpc() or is.rdbuf()->sgetc() + returns traits::eof(), the function calls + setstate(failbit | eofbit) (which may throw + ios_base::failure). +

        +
        +
        +

        199. What does allocate(0) return?

        + Section: 20.1.5 [lib.allocator.requirements]  Status: DR  Submitter: Matt Austern  Date: 19 Nov 1999

        +

        + Suppose that A is a class that conforms to the + Allocator requirements of Table 32, and a is an + object of class A What should be the return + value of a.allocate(0)? Three reasonable + possibilities: forbid the argument 0, return + a null pointer, or require that the return value be a + unique non-null pointer. +

        +

        Proposed resolution:

        +

        + Add a note to the allocate row of Table 32: + "[Note: If n == 0, the return value is unspecified. --end note]"

        +

        Rationale:

        +

        A key to understanding this issue is that the ultimate use of + allocate() is to construct an iterator, and that iterator for zero + length sequences must be the container's past-the-end + representation. Since this already implies special case code, it + would be over-specification to mandate the return value. +

        +
        +

        208. Unnecessary restriction on past-the-end iterators

        + Section: 24.1 [lib.iterator.requirements]  Status: DR  Submitter: Stephen Cleary  Date: 02 Feb 2000

        +

        In 24.1 paragraph 5, it is stated ". . . Dereferenceable and + past-the-end values are always non-singular."

        +

        This places an unnecessary restriction on past-the-end iterators for + containers with forward iterators (for example, a singly-linked list). If the + past-the-end value on such a container was a well-known singular value, it would + still satisfy all forward iterator requirements.

        +

        Removing this restriction would allow, for example, a singly-linked list + without a "footer" node.

        +

        This would have an impact on existing code that expects past-the-end + iterators obtained from different (generic) containers being not equal.

        +

        Proposed resolution:

        +

        Change 24.1 paragraph 5, the last sentence, from:

        +
        +

        Dereferenceable and past-the-end values are always non-singular.

        +
        +

        to:

        +
        +

        Dereferenceable values are always non-singular. 

        +
        +

        Rationale:

        +

        For some kinds of containers, including singly linked lists and + zero-length vectors, null pointers are perfectly reasonable past-the-end + iterators. Null pointers are singular. +

        +
        +

        209. basic_string declarations inconsistent

        + Section: 21.3 [lib.basic.string]  Status: DR  Submitter: Igor Stauder  Date: 11 Feb 2000

        +

        In Section 21.3 the basic_string member function + declarations use a consistent style except for the following functions:

        +
        +
        void push_back(const charT);
        + basic_string& assign(const basic_string&);
        + void swap(basic_string<charT,traits,Allocator>&);
        +
        +

        - push_back, assign, swap: missing argument name 
        + - push_back: use of const with charT (i.e. POD type passed by value + not by reference - should be charT or const charT& )
        + - swap: redundant use of template parameters in argument + basic_string<charT,traits,Allocator>&

        +

        Proposed resolution:

        +

        In Section 21.3 change the basic_string member + function declarations push_back, assign, and swap to:

        +
        +
        void push_back(charT c); 
        + 
        + basic_string& assign(const basic_string& str);
        + void swap(basic_string& str);
        +
        +

        Rationale:

        +

        Although the standard is in general not consistent in declaration + style, the basic_string declarations are consistent other than the + above. The LWG felt that this was sufficient reason to merit the + change. +

        +
        +

        210. distance first and last confused

        + Section: 25 [lib.algorithms]  Status: DR  Submitter: Lisa Lippincott  Date: 15 Feb 2000

        +

        In paragraph 9 of section 25 , it is written:

        +
        +

        In the description of the algorithms operators + and - are used + for some of the iterator categories for which they do not have to + be defined. In these cases the semantics of [...] a-b is the same + as of
        +
        +      return distance(a, b); +

        +
        +

        Proposed resolution:

        +

        On the last line of paragraph 9 of section 25 change + "a-b" to "b-a". +

        +

        Rationale:

        +

        There are two ways to fix the defect; change the description to b-a + or change the return to distance(b,a). The LWG preferred the + former for consistency.

        +
        +

        211. operator>>(istream&, string&) doesn't set failbit

        + Section: 21.3.7.9 [lib.string.io]  Status: DR  Submitter: Scott Snyder  Date: 4 Feb 2000

        +

        The description of the stream extraction operator for std::string (section + 21.3.7.9 [lib.string.io]) does not contain a requirement that failbit be set in + the case that the operator fails to extract any characters from the input + stream.

        +

        This implies that the typical construction

        +
        +
        std::istream is;
        + std::string str;
        + ...
        + while (is >> str) ... ;
        +
        +

        (which tests failbit) is not required to terminate at EOF.

        +

        Furthermore, this is inconsistent with other extraction operators, + which do include this requirement. (See sections 27.6.1.2 and 27.6.1.3 ), where this + requirement is present, either explicitly or implicitly, for the + extraction operators. It is also present explicitly in the description + of getline (istream&, string&, charT) in section 21.3.7.9 paragraph 8.)

        +

        Proposed resolution:

        +

        Insert new paragraph after paragraph 2 in section 21.3.7.9 :

        +
        + +

        If the function extracts no characters, it calls + is.setstate(ios::failbit) which may throw ios_base::failure + (27.4.4.3).

        +
        +
        +

        212. Empty range behavior unclear for several algorithms

        + Section: 25.3.7 [lib.alg.min.max]  Status: DR  Submitter: Nico Josuttis  Date: 26 Feb 2000

        +

        The standard doesn't specify what min_element() and max_element() shall + return if the range is empty (first equals last). The usual implementations + return last. This problem seems also apply to partition(), stable_partition(), + next_permutation(), and prev_permutation().

        +

        Proposed resolution:

        +

        In 25.3.7 - Minimum and maximum, paragraphs 7 and + 9, append: Returns last if first==last.

        +

        Rationale:

        +

        The LWG looked in some detail at all of the above mentioned + algorithms, but believes that except for min_element() and + max_element() it is already clear that last is returned if first == + last.

        +
        +

        214. set::find() missing const overload

        + Section: 23.3.3 [lib.set], 23.3.4 [lib.multiset]  Status: DR  Submitter: Judy Ward  Date: 28 Feb 2000

        +

        The specification for the associative container requirements in + Table 69 state that the find member function should "return + iterator; const_iterator for constant a". The map and multimap + container descriptions have two overloaded versions of find, but set + and multiset do not, all they have is:

        +
        +
        iterator find(const key_type & x) const;
        +
        +

        Proposed resolution:

        +

        Change the prototypes for find(), lower_bound(), upper_bound(), and + equal_range() in section 23.3.3 and section 23.3.4 to each have two overloads:

        +
        +
        iterator find(const key_type & x);
        + const_iterator find(const key_type & x) const;
        +
        iterator lower_bound(const key_type & x);
        + const_iterator lower_bound(const key_type & x) const;
        +
        iterator upper_bound(const key_type & x);
        + const_iterator upper_bound(const key_type & x) const;
        +
        pair<iterator, iterator> equal_range(const key_type & x);
        + pair<const_iterator, const_iterator> equal_range(const key_type & x) const;
        +
        + +

        [Tokyo: At the request of the LWG, Judy Ward provided wording + extending the proposed resolution to lower_bound, upper_bound, and + equal_range.]

        +
        +

        217. Facets example (Classifying Japanese characters) contains errors

        + Section: 22.2.8 [lib.facets.examples]  Status: DR  Submitter: Martin Sebor  Date: 29 Feb 2000

        +

        The example in 22.2.8, paragraph 11 contains the following errors:

        +

        1) The member function `My::JCtype::is_kanji()' is non-const; the function + must be const in order for it to be callable on a const object (a reference to + which which is what std::use_facet<>() returns).

        +

        2) In file filt.C, the definition of `JCtype::id' must be qualified with the + name of the namespace `My'.

        +

        3) In the definition of `loc' and subsequently in the call to use_facet<>() + in main(), the name of the facet is misspelled: it should read `My::JCtype' + rather than `My::JCType'.

        +

        Proposed resolution:

        +

        Replace the "Classifying Japanese characters" example in 22.2.8, + paragraph 11 with the following:

        +
        #include <locale>
        +
        namespace My {
        +     using namespace std;
        +     class JCtype : public locale::facet {
        +     public:
        +         static locale::id id;     //  required for use as a new locale facet
        +         bool is_kanji (wchar_t c) const;
        +         JCtype() {}
        +     protected:
        +         ~JCtype() {}
        +     };
        + }
        +
        //  file:  filt.C
        + #include <iostream>
        + #include <locale>
        + #include "jctype"                 //  above
        + std::locale::id My::JCtype::id;   //  the static  JCtype  member
        + declared above.
        +
        int main()
        + {
        +     using namespace std;
        +     typedef ctype<wchar_t> wctype;
        +     locale loc(locale(""),              //  the user's preferred locale...
        +                new My::JCtype);         //  and a new feature ...
        +     wchar_t c = use_facet<wctype>(loc).widen('!');
        +     if (!use_facet<My::JCtype>(loc).is_kanji(c))
        +         cout << "no it isn't!" << endl;
        +     return 0;
        + }
        +
        +

        220. ~ios_base() usage valid?

        + Section: 27.4.2.7 [lib.ios.base.cons]  Status: DR  Submitter: Jonathan Schilling, Howard Hinnant  Date: 13 Mar 2000

        +

        The pre-conditions for the ios_base destructor are described in 27.4.2.7 + paragraph 2:

        +
        +

        Effects: Destroys an object of class ios_base. Calls each registered + callback pair (fn,index) (27.4.2.6) as (*fn)(erase_event,*this,index) at such + time that any ios_base member function called from within fn has well defined + results.

        +
        +

        But what is not clear is: If no callback functions were ever registered, does + it matter whether the ios_base members were ever initialized?

        +

        For instance, does this program have defined behavior:

        +
        +
        #include <ios>
        +
        class D : public std::ios_base { };
        +
        int main() { D d; }
        +
        +

        It seems that registration of a callback function would surely affect the + state of an ios_base. That is, when you register a callback function with an + ios_base, the ios_base must record that fact somehow.

        +

        But if after construction the ios_base is in an indeterminate state, and that + state is not made determinate before the destructor is called, then how would + the destructor know if any callbacks had indeed been registered? And if the + number of callbacks that had been registered is indeterminate, then is not the + behavior of the destructor undefined?

        +

        By comparison, the basic_ios class description in 27.4.4.1 paragraph 2 makes + it explicit that destruction before initialization results in undefined + behavior.

        +

        Proposed resolution:

        +

        Modify 27.4.2.7 paragraph 1 from

        +
        +

        Effects: Each ios_base member has an indeterminate value after + construction.

        +
        +

        to

        +
        +

        Effects: Each ios_base member has an indeterminate value after + construction. These members must be initialized by calling basic_ios::init. If an ios_base object is destroyed before these initializations + have taken place, the behavior is undefined.

        +
        +
        +

        221. num_get<>::do_get stage 2 processing broken

        + Section: 22.2.2.1.2 [lib.facet.num.get.virtuals]  Status: DR  Submitter: Matt Austern  Date: 14 Mar 2000

        +

        Stage 2 processing of numeric conversion is broken.

        + +

        Table 55 in 22.2.2.1.2 says that when basefield is 0 the integral + conversion specifier is %i. A %i specifier determines a number's base + by its prefix (0 for octal, 0x for hex), so the intention is clearly + that a 0x prefix is allowed. Paragraph 8 in the same section, + however, describes very precisely how characters are processed. (It + must be done "as if" by a specified code fragment.) That + description does not allow a 0x prefix to be recognized.

        + +

        Very roughly, stage 2 processing reads a char_type ct. It converts + ct to a char, not by using narrow but by looking it up in a + translation table that was created by widening the string literal + "0123456789abcdefABCDEF+-". The character "x" is + not found in that table, so it can't be recognized by stage 2 + processing.

        +

        Proposed resolution:

        +

        In 22.2.2.1.2 paragraph 8, replace the line:

        +
        +
        static const char src[] = "0123456789abcdefABCDEF+-";
        +
        +

        with the line:

        +
        +
        static const char src[] = "0123456789abcdefxABCDEFX+-";
        +
        +

        Rationale:

        +

        If we're using the technique of widening a string literal, the + string literal must contain every character we wish to recognize. + This technique has the consequence that alternate representations + of digits will not be recognized. This design decision was made + deliberately, with full knowledge of that limitation.

        +
        +

        222. Are throw clauses necessary if a throw is already implied by the effects clause?

        + Section: 17.3.1.3 [lib.structure.specifications]  Status: DR  Submitter: Judy Ward  Date: 17 Mar 2000

        +

        Section 21.3.6.8 describes the basic_string::compare function this way:

        +
        +
        21.3.6.8 - basic_string::compare [lib.string::compare]
        + 
        + int compare(size_type pos1, size_type n1,
        +                 const basic_string<charT,traits,Allocator>&  str ,
        +                 size_type  pos2 , size_type  n2 ) const;
        + 
        + -4- Returns: 
        + 
        +     basic_string<charT,traits,Allocator>(*this,pos1,n1).compare(
        +                  basic_string<charT,traits,Allocator>(str,pos2,n2)) .
        +
        +

        and the constructor that's implicitly called by the above is + defined to throw an out-of-range exception if pos > str.size(). See + section 21.3.1 paragraph 4.

        + +

        On the other hand, the compare function descriptions themselves don't have + "Throws: " clauses and according to 17.3.1.3, paragraph 3, elements + that do not apply to a function are omitted.

        +

        So it seems there is an inconsistency in the standard -- are the + "Effects" clauses correct, or are the "Throws" clauses + missing?

        +

        Proposed resolution:

        +

        In 17.3.1.3 paragraph 3, the footnote 148 attached to + the sentence "Descriptions of function semantics contain the + following elements (as appropriate):", insert the word + "further" so that the foot note reads:

        +
        +

        To save space, items that do not apply to a function are + omitted. For example, if a function does not specify any further + preconditions, there will be no "Requires" paragraph.

        +
        +

        Rationale:

        +

        The standard is somewhat inconsistent, but a failure to note a + throw condition in a throws clause does not grant permission not to + throw. The inconsistent wording is in a footnote, and thus + non-normative. The proposed resolution from the LWG clarifies the + footnote.

        +
        +

        223. reverse algorithm should use iter_swap rather than swap

        + Section: 25.2.9 [lib.alg.reverse]  Status: DR  Submitter: Dave Abrahams  Date: 21 Mar 2000

        +

        Shouldn't the effects say "applies iter_swap to all pairs..."?

        +

        Proposed resolution:

        +

        In 25.2.9 , replace:

        +
        + Effects: For each non-negative integer i <= (last - first)/2, + applies swap to all pairs of iterators first + i, (last - i) - 1. +
        +

        with:

        +
        + Effects: For each non-negative integer i <= (last - first)/2, + applies iter_swap to all pairs of iterators first + i, (last - i) - 1. +
        +
        +

        224. clear() complexity for associative containers refers to undefined N

        + Section: 23.1.2 [lib.associative.reqmts]  Status: DR  Submitter: Ed Brey  Date: 23 Mar 2000

        +

        In the associative container requirements table in 23.1.2 paragraph 7, + a.clear() has complexity "log(size()) + N". However, the meaning of N + is not defined.

        +

        Proposed resolution:

        +

        In the associative container requirements table in 23.1.2 paragraph + 7, the complexity of a.clear(), change "log(size()) + N" to + "linear in size()".

        +

        Rationale:

        +

        It's the "log(size())", not the "N", that is in + error: there's no difference between O(N) and O(N + + log(N)). The text in the standard is probably an incorrect + cut-and-paste from the range version of erase.

        +
        +

        227. std::swap() should require CopyConstructible or DefaultConstructible arguments

        + Section: 25.2.2 [lib.alg.swap]  Status: DR  Submitter: Dave Abrahams  Date: 09 Apr 2000

        +

        25.2.2 reads:

        +
        +

        + template<class T> void swap(T& a, T& b);
        +
        + Requires: Type T is Assignable (_lib.container.requirements_).
        + Effects: Exchanges values stored in two locations.

        +
        +

        The only reasonable** generic implementation of swap requires construction of a + new temporary copy of one of its arguments:

        +
        +
        template<class T> void swap(T& a, T& b);
        +   {
        +       T tmp(a);
        +       a = b;
        +       b = tmp;
        +   }
        +
        +

        But a type which is only Assignable cannot be swapped by this implementation.

        +

        **Yes, there's also an unreasonable implementation which would require T to be + DefaultConstructible instead of CopyConstructible. I don't think this is worthy + of consideration:

        +
        +
        template<class T> void swap(T& a, T& b);
        + {
        +     T tmp;
        +     tmp = a;
        +     a = b;
        +     b = tmp;
        + }
        +
        +

        Proposed resolution:

        +

        Change 25.2.2 paragraph 1 from:

        +
        +

        Requires: Type T is Assignable (23.1).

        +
        +

        to:

        +
        +

        Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1)

        +
        +
        +

        234. Typos in allocator definition

        + Section: 20.4.1.1 [lib.allocator.members]  Status: DR  Submitter: Dietmar Kühl  Date: 24 Apr 2000

        +

        In paragraphs 12 and 13 the effects of construct() and + destruct() are described as returns but the functions actually + return void.

        +

        Proposed resolution:

        +

        Substitute "Returns" by "Effect".

        +
        +

        237. Undefined expression in complexity specification

        + Section: 23.2.2.1 [lib.list.cons]  Status: DR  Submitter: Dietmar Kühl  Date: 24 Apr 2000

        +

        The complexity specification in paragraph 6 says that the complexity + is linear in first - last. Even if operator-() is + defined on iterators this term is in general undefined because it + would have to be last - first.

        +

        Proposed resolution:

        +

        Change paragraph 6 from

        +
        Linear in first - last.
        +

        to become

        +
        Linear in distance(first, last).
        +
        +

        243. get and getline when sentry reports failure

        + Section: 27.6.1.3 [lib.istream.unformatted]  Status: DR  Submitter: Martin Sebor  Date: May 15 2000

        +

        basic_istream<>::get(), and basic_istream<>::getline(), + are unclear with respect to the behavior and side-effects of the named + functions in case of an error.

        + +

        27.6.1.3, p1 states that "... If the sentry object returns + true, when converted to a value of type bool, the function endeavors + to obtain the requested input..." It is not clear from this (or + the rest of the paragraph) what precisely the behavior should be when + the sentry ctor exits by throwing an exception or when the sentry + object returns false. In particular, what is the number of characters + extracted that gcount() returns supposed to be?

        + +

        27.6.1.3 p8 and p19 say about the effects of get() and getline(): + "... In any case, it then stores a null character (using + charT()) into the next successive location of the array." Is not + clear whether this sentence applies if either of the conditions above + holds (i.e., when sentry fails).

        +

        Proposed resolution:

        +

        Add to 27.6.1.3, p1 after the sentence

        + +
        + "... If the sentry object returns true, when converted to a value of + type bool, the function endeavors to obtain the requested input." +
        + +

        the following

        + + +
        + "Otherwise, if the sentry constructor exits by throwing an exception or + if the sentry object returns false, when converted to a value of type + bool, the function returns without attempting to obtain any input. In + either case the number of extracted characters is set to 0; unformatted + input functions taking a character array of non-zero size as an argument + shall also store a null character (using charT()) in the first location + of the array." +
        +

        Rationale:

        +

        Although the general philosophy of the input functions is that the + argument should not be modified upon failure, getline + historically added a terminating null unconditionally. Most + implementations still do that. Earlier versions of the draft standard + had language that made this an unambiguous requirement; those words + were moved to a place where their context made them less clear. See + Jerry Schwarz's message c++std-lib-7618.

        +
        +

        248. time_get fails to set eofbit

        + Section: 22.2.5 [lib.category.time]  Status: DR  Submitter: Martin Sebor  Date: 22 June 2000

        +

        There is no requirement that any of time_get member functions set + ios::eofbit when they reach the end iterator while parsing their input. + Since members of both the num_get and money_get facets are required to + do so (22.2.2.1.2, and 22.2.6.1.2, respectively), time_get members + should follow the same requirement for consistency.

        +

        Proposed resolution:

        +

        Add paragraph 2 to section 22.2.5.1 with the following text:

        + +
        + If the end iterator is reached during parsing by any of the get() + member functions, the member sets ios_base::eofbit in err. +
        +

        Rationale:

        +

        Two alternative resolutions were proposed. The LWG chose this one + because it was more consistent with the way eof is described for other + input facets.

        +
        +

        251. basic_stringbuf missing allocator_type

        + Section: 27.7.1 [lib.stringbuf]  Status: DR  Submitter: Martin Sebor  Date: 28 Jul 2000

        +

        The synopsis for the template class basic_stringbuf + doesn't list a typedef for the template parameter + Allocator. This makes it impossible to determine the type of + the allocator at compile time. It's also inconsistent with all other + template classes in the library that do provide a typedef for the + Allocator parameter.

        +

        Proposed resolution:

        +

        Add to the synopses of the class templates basic_stringbuf (27.7.1), + basic_istringstream (27.7.2), basic_ostringstream (27.7.3), and + basic_stringstream (27.7.4) the typedef:

        +
        +   typedef Allocator allocator_type;
        + 
        +
        +

        252. missing casts/C-style casts used in iostreams

        + Section: 27.7 [lib.string.streams]  Status: DR  Submitter: Martin Sebor  Date: 28 Jul 2000

        +

        27.7.2.2, p1 uses a C-style cast rather than the more appropriate + const_cast<> in the Returns clause for basic_istringstream<>::rdbuf(). + The same C-style cast is being used in 27.7.3.2, p1, D.7.2.2, p1, and + D.7.3.2, p1, and perhaps elsewhere. 27.7.6, p1 and D.7.2.2, p1 are missing + the cast altogether.

        + +

        C-style casts have not been deprecated, so the first part of this + issue is stylistic rather than a matter of correctness.

        +

        Proposed resolution:

        +

        In 27.7.2.2, p1 replace

        +
          -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.
        + +

        with

        +
          -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).
        + + +

        In 27.7.3.2, p1 replace

        +
          -1- Returns: (basic_stringbuf<charT,traits,Allocator>*)&sb.
        + +

        with

        +
          -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).
        + +

        In 27.7.6, p1, replace

        +
          -1- Returns: &sb
        + +

        with

        +
          -1- Returns: const_cast<basic_stringbuf<charT,traits,Allocator>*>(&sb).
        + +

        In D.7.2.2, p1 replace

        +
          -2- Returns: &sb. 
        + +

        with

        +
          -2- Returns: const_cast<strstreambuf*>(&sb).
        +
        +

        256. typo in 27.4.4.2, p17: copy_event does not exist

        + Section: 27.4.4.2 [lib.basic.ios.members]  Status: DR  Submitter: Martin Sebor  Date: 21 Aug 2000

        +

        + 27.4.4.2, p17 says +

        + +
        + -17- Before copying any parts of rhs, calls each registered callback + pair (fn,index) as (*fn)(erase_event,*this,index). After all parts but + exceptions() have been replaced, calls each callback pair that was + copied from rhs as (*fn)(copy_event,*this,index). +
        + +

        + The name copy_event isn't defined anywhere. The intended name was + copyfmt_event. +

        +

        Proposed resolution:

        +

        Replace copy_event with copyfmt_event in the named paragraph.

        +
        +

        260. Inconsistent return type of istream_iterator::operator++(int) +

        + Section: 24.5.1.2 [lib.istream.iterator.ops]  Status: DR  Submitter: Martin Sebor  Date: 27 Aug 2000

        +

        The synopsis of istream_iterator::operator++(int) in 24.5.1 shows + it as returning the iterator by value. 24.5.1.2, p5 shows the same + operator as returning the iterator by reference. That's incorrect + given the Effects clause below (since a temporary is returned). The + `&' is probably just a typo.

        +

        Proposed resolution:

        +

        Change the declaration in 24.5.1.2, p5 from

        +
        +  istream_iterator<T,charT,traits,Distance>& operator++(int);
        +  
        +

        to

        +
        +  istream_iterator<T,charT,traits,Distance> operator++(int);
        +  
        +

        (that is, remove the `&').

        +
        +

        261. Missing description of istream_iterator::operator!= +

        + Section: 24.5.1.2 [lib.istream.iterator.ops]  Status: DR  Submitter: Martin Sebor  Date: 27 Aug 2000

        +

        + 24.5.1, p3 lists the synopsis for +

        + +
        +    template <class T, class charT, class traits, class Distance>
        +         bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
        +                         const istream_iterator<T,charT,traits,Distance>& y);
        + 
        + +

        + but there is no description of what the operator does (i.e., no Effects + or Returns clause) in 24.5.1.2. +

        +

        Proposed resolution:

        +

        + Add paragraph 7 to the end of section 24.5.1.2 with the following text: +

        + +
        +    template <class T, class charT, class traits, class Distance>
        +         bool operator!=(const istream_iterator<T,charT,traits,Distance>& x,
        +                         const istream_iterator<T,charT,traits,Distance>& y);
        + 
        + +

        -7- Returns: !(x == y).

        +
        +

        262. Bitmask operator ~ specified incorrectly

        + Section: 17.3.2.1.2 [lib.bitmask.types]  Status: DR  Submitter: Beman Dawes  Date: 03 Sep 2000

        +

        + The ~ operation should be applied after the cast to int_type. +

        +

        Proposed resolution:

        +

        + Change 17.3.2.1.2 [lib.bitmask.types] operator~ from: +

        + +
        +    bitmask operator~ ( bitmask X )
        +      { return static_cast< bitmask>(static_cast<int_type>(~ X)); }
        + 
        + +

        + to: +

        + +
        +    bitmask operator~ ( bitmask X )
        +      { return static_cast< bitmask>(~static_cast<int_type>(X)); }
        + 
        +
        +

        263. Severe restriction on basic_string reference counting

        + Section: 21.3 [lib.basic.string]  Status: DR  Submitter: Kevlin Henney  Date: 04 Sep 2000

        +

        + The note in paragraph 6 suggests that the invalidation rules for + references, pointers, and iterators in paragraph 5 permit a reference- + counted implementation (actually, according to paragraph 6, they permit + a "reference counted implementation", but this is a minor editorial fix). +

        + +

        + However, the last sub-bullet is so worded as to make a reference-counted + implementation unviable. In the following example none of the + conditions for iterator invalidation are satisfied: +

        + +
        +     // first example: "*******************" should be printed twice
        +     string original = "some arbitrary text", copy = original;
        +     const string & alias = original;
        + 
        +     string::const_iterator i = alias.begin(), e = alias.end();
        +     for(string::iterator j = original.begin(); j != original.end(); ++j)
        +         *j = '*';
        +     while(i != e)
        +         cout << *i++;
        +     cout << endl;
        +     cout << original << endl;
        + 
        + +

        + Similarly, in the following example: +

        + +
        +     // second example: "some arbitrary text" should be printed out
        +     string original = "some arbitrary text", copy = original;
        +     const string & alias = original;
        + 
        +     string::const_iterator i = alias.begin();
        +     original.begin();
        +     while(i != alias.end())
        +         cout << *i++;
        + 
        + +

        + I have tested this on three string implementations, two of which were + reference counted. The reference-counted implementations gave + "surprising behavior" because they invalidated iterators on + the first call to non-const begin since construction. The current + wording does not permit such invalidation because it does not take + into account the first call since construction, only the first call + since various member and non-member function calls. +

        +

        Proposed resolution:

        +

        + Change the following sentence in 21.3 paragraph 5 from +

        + +
        + Subsequent to any of the above uses except the forms of insert() and + erase() which return iterators, the first call to non-const member + functions operator[](), at(), begin(), rbegin(), end(), or rend(). +
        + +

        to

        + +
        + Following construction or any of the above uses, except the forms of + insert() and erase() that return iterators, the first call to non- + const member functions operator[](), at(), begin(), rbegin(), end(), + or rend(). +
        +
        +

        265. std::pair::pair() effects overly restrictive

        + Section: 20.2.2 [lib.pairs]  Status: DR  Submitter: Martin Sebor  Date: 11 Sep 2000

        +

        + I don't see any requirements on the types of the elements of the + std::pair container in 20.2.2. From the descriptions of the member + functions it appears that they must at least satisfy the requirements of + 20.1.3 [lib.copyconstructible] and 20.1.4 [lib.default.con.req], and in + the case of the [in]equality operators also the requirements of 20.1.1 + [lib.equalitycomparable] and 20.1.2 [lib.lessthancomparable]. +

        + +

        + I believe that the the CopyConstructible requirement is unnecessary in + the case of 20.2.2, p2. +

        +

        Proposed resolution:

        +

        Change the Effects clause in 20.2.2, p2 from

        + +
        + -2- Effects: Initializes its members as if implemented: pair() : + first(T1()), second(T2()) {} +
        + +

        to

        + +
        + -2- Effects: Initializes its members as if implemented: pair() : + first(), second() {} +
        +

        Rationale:

        +

        The existing specification of pair's constructor appears to be a + historical artifact: there was concern that pair's members be properly + zero-initialized when they are built-in types. At one time there was + uncertainty about whether they would be zero-initialized if the + default constructor was written the obvious way. This has been + clarified by core issue 178, and there is no longer any doubt that + the straightforward implementation is correct.

        +
        +

        268. Typo in locale synopsis

        + Section: 22.1.1 [lib.locale]  Status: DR  Submitter: Martin Sebor  Date: 5 Oct 2000

        +

        The synopsis of the class std::locale in 22.1.1 contains two typos: + the semicolons after the declarations of the default ctor + locale::locale() and the copy ctor locale::locale(const locale&) + are missing.

        +

        Proposed resolution:

        +

        Add the missing semicolons, i.e., change

        + +
        +     //  construct/copy/destroy:
        +         locale() throw()
        +         locale(const locale& other) throw()
        + 
        + +

        in the synopsis in 22.1.1 to

        + +
        +     //  construct/copy/destroy:
        +         locale() throw();
        +         locale(const locale& other) throw();
        + 
        +

        ----- End of document -----

        + + diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/ext/sgiexts.html gcc-3.0.2/libstdc++-v3/docs/html/ext/sgiexts.html *** gcc-3.0.1/libstdc++-v3/docs/html/ext/sgiexts.html Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/libstdc++-v3/docs/html/ext/sgiexts.html Fri Oct 19 13:07:41 2001 *************** *** 0 **** --- 1,234 ---- + + + + + + + + SGI extensions to the library in libstdc++-v3 + + + + +

        SGI extensions to the library in + libstdc++-v3

        + +

        This page describes the extensions that SGI made to their version of the + STL subset of the Standard C++ Library. For a time we + tracked and imported changes and updates + from most of the SGI STL, up through their (apparently) final release. + Their extensions were mostly preserved. +

        + +

        They are listed according to the chapters of the library that they + extend (see the chapter-specific notes + for a description). Not every chapter may have extensions, and the + extensions may come and go. Also, this page is incomplete because the + author is pressed for time. Check back often; the latest change was on + $Date: 2001/10/19 20:07:41 $ (UTC). +

        + +

        Descriptions range from the scanty to the verbose. You should also check + the generated documentation for notes + and comments, especially for entries marked with '*'. For more complete + doumentation, see the SGI website. For really complete + documentation, buy a copy of Matt Austern's book. *grin* +

        + +

        Back to the libstdc++-v3 extensions. + + + +


        +

        Chapter 20

        +

        The <functional> header contains many additional functors and + helper functions, extending section 20.3. They are implemented in the + file stl_function.h: +

          +
        • identity_element for addition and multiplication. * +
        • The functor identity, whose op() returns the argument + unchanged. * +
        • Composition functors unary_function and + binary_function, and their helpers compose1 + and compose2. * +
        • select1st and select2nd, to strip pairs. * +
        • project1st and project2nd. * +
        • A set of functors/functions which always return the same result. They + are constant_void_fun, constant_binary_fun, constant_unary_fun, + constant0, constant1, and constant2. * +
        • The class subtractive_rng. * +
        • mem_fun adaptor helpers mem_fun1 and mem_fun1_ref are provided for + backwards compatibility. +

        +

        20.4.3 is extended with a special version of + get_temporary_buffer taking a second argument. The argument + is a pointer, which is ignored, but can be used to specify the template + type (instead of using explicit function template arguments like the + standard version does). That is, in addition to +

        +    get_temporary_buffer<int>(5);
        + you can also use +
        +    get_temporary_buffer(5, (int*)0);
        +

        +

        A class temporary_buffer is given in stl_tempbuf.h. * +

        +

        The specialized algorithms of section 20.4.4 are extended with + uninitialized_copy_n. * +

        +

        Return to the main extensions page or + to the homepage. +

        + + +
        +

        Chapter 23

        +

        A few extensions and nods to backwards-compatability have been made with + containers. Those dealing with older SGI-style allocators are dealt with + elsewhere. The remaining ones all deal with bits: +

        +

        The old pre-standard bit_vector class is present for + backwards compatibility. It is simply a typedef for the + vector<bool> specialization. +

        +

        The bitset class has a number of extensions, described in the + rest of this item. First, we'll mention that this implementation of + bitset<N> is specialized for cases where N number of + bits will fit into a single word of storage. If your choice of N is + within that range (<=32 on i686-pc-linux-gnu, for example), then all + of the operations will be faster. +

        +

        There are + versions of single-bit test, set, reset, and flip member functions which + do no range-checking. If we call them member functions of an instantiation + of "bitset<N>," then their names and signatures are: +

        +    bitset<N>&   _Unchecked_set   (size_t pos);
        +    bitset<N>&   _Unchecked_set   (size_t pos, int val);
        +    bitset<N>&   _Unchecked_reset (size_t pos);
        +    bitset<N>&   _Unchecked_flip  (size_t pos);
        +    bool         _Unchecked_test  (size_t pos);
        + Note that these may in fact be removed in the future, although we have + no present plans to do so (and there doesn't seem to be any immediate + reason to). +

        +

        + The semantics of member function operator[] are not specified + in the C++ standard. A long-standing defect report calls for sensible + obvious semantics, which are already implemented here: op[] + on a const bitset returns a bool, and for a non-const bitset returns a + reference (a nested type). However, this implementation does + no range-checking on the index argument, which is in keeping with other + containers' op[] requirements. The defect report's proposed + resolution calls for range-checking to be done. We'll just wait and see... +

        +

        Finally, two additional searching functions have been added. They return + the index of the first "on" bit, and the index of the first + "on" bit that is after prev, respectively: +

        +    size_t _Find_first() const;
        +    size_t _Find_next (size_t prev) const;
        + The same caveat given for the _Unchecked_* functions applies here also. +

        +

        Return to the main extensions page or + to the homepage. +

        + + +
        +

        Chapter 24

        +

        24.3.2 describes struct iterator, which didn't exist in the + original HP STL implementation (the language wasn't rich enough at the + time). For backwards compatibility, base classes are provided which + declare the same nested typedefs: +

          +
        • input_iterator +
        • output_iterator +
        • forward_iterator +
        • bidirectional_iterator +
        • random_access_iterator +
        +

        +

        24.3.4 describes iterator operation distance, which takes + two iterators and returns a result. It is extended by another signature + which takes two iterators and a reference to a result. The result is + modified, and the function returns nothing. +

        +

        Return to the main extensions page or + to the homepage. +

        + + +
        +

        Chapter 25

        +

        25.1.6 (count, count_if) is extended with two more versions of count + and count_if. The standard versions return their results. The + additional signatures return void, but take a final parameter by + reference to which they assign their results, e.g., +

        +    void count (first, last, value, n);
        +

        +

        25.2 (mutating algorithms) is extended with two families of signatures, + random_sample and random_sample_n. +

        +

        25.2.1 (copy) is extended with +

        +    copy_n (_InputIter first, _Size count, _OutputIter result);
        + which copies the first 'count' elements at 'first' into 'result'. +

        +

        25.3 (sorting 'n' heaps 'n' stuff) is extended with some helper + predicates. Look in the doxygen-generated pages for notes on these. +

          +
        • is_heap tests whether or not a range is a heap. +
        • is_sorted tests whether or not a range is sorted in + nondescending order. +
        +

        +

        25.3.8 (lexigraphical_compare) is extended with +

        +    lexicographical_compare_3way(_InputIter1 first1, _InputIter1 last1,
        +                                  _InputIter2 first2, _InputIter2 last2)
        + which does... what? +

        +

        Return to the main extensions page or + to the homepage. +

        + + +
        +

        Chapter 26

        +

        26.4, the generalized numeric operations such as accumulate, are extended + with the following functions: +

        +    power (x, n);
        +    power (x, n, moniod_operation);
        + Returns, in FORTRAN syntax, "x ** n" where n>=0. In the + case of n == 0, returns the identity element for the + monoid operation. The two-argument signature uses multiplication (for + a true "power" implementation), but addition is supported as well. + The operation functor must be associative. +

        +

        The iota function wins the award for Extension With the + Coolest Name. It "assigns sequentially increasing values to a range. + That is, it assigns value to *first, value + 1 to *(first + 1) and so + on." Quoted from SGI documentation. +

        +    void iota(_ForwardIter first, _ForwardIter last, _Tp value);
        +

        +

        Return to the main extensions page or + to the homepage. +

        + + + + +
        +

        + See license.html for copying conditions. + Comments and suggestions are welcome, and may be sent to + the libstdc++ mailing list. +

        + + + + diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/faq/index.html gcc-3.0.2/libstdc++-v3/docs/html/faq/index.html *** gcc-3.0.1/libstdc++-v3/docs/html/faq/index.html Wed Jul 18 14:39:58 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/faq/index.html Fri Oct 19 13:07:42 2001 *************** *** 1,215 **** ! ! ! ! ! ! libstdc++-v3 FAQ ! ! ! ! !

        libstdc++ Frequently Asked Questions

        !

        The latest version of this document is always available at ! ! http://gcc.gnu.org/onlinedocs/libstdc++/faq/.

        !

        To the libstdc++-v3 homepage. !


        !

        Questions

        !
          !
        1. General Information !
            !
          1. What is libstdc++-v3? !
          2. Why should I use libstdc++? !
          3. Who's in charge of it? !
          4. How do I get libstdc++? !
          5. When is libstdc++ going to be finished? !
          6. How do I contribute to the effort? !
          7. What happened to libg++? I need that! !
          8. What if I have more questions? !
          !
        2. Installation !
            !
          1. How do I install libstdc++-v3? !
          2. [removed] !
          3. What is this CVS thing that you keep ! mentioning? !
          4. How do I know if it works? !
          !
        3. Platform-Specific Issues !
            !
          1. Can libstdc++-v3 be used with <my ! favorite compiler>? !
          2. [removed] !
          3. Building under DEC OSF kills the assembler !
          !
        4. Known Bugs and Non-Bugs !
            !
          1. What works already? !
          2. Bugs in gcc/g++ (not libstdc++-v3) !
          3. Bugs in the C++ language/lib specification !
          4. Things in libstdc++ that look like bugs ! !
          5. Aw, that's easy to fix! !
          !
        5. Miscellaneous !
            !
          1. string::iterator is not char*; ! vector<T>::iterator is not T* !
          2. What's next after libstdc++-v3? !
          3. What about the STL from SGI? !
          4. Extensions and Backward Compatibility !
          5. [removed] !
          6. Is libstdc++-v3 thread-safe? !
          7. How do I get a copy of the ISO C++ Standard? !
          !
        !
        !

        1.0 General Information

        !

        1.1 What is libstdc++-v3?

        !

        The GNU Standard C++ Library v3, or libstdc++-2.9x, is an ongoing project to implement the ISO 14882 Standard C++ library as described in chapters 17 through 27 and annex D. As the library reaches stable plateaus, it is captured in a snapshot ! and released. The current release is the ! eleventh snapshot. For those who want to see exactly how far the project has come, or just want the latest bleeding-edge code, the up-to-date source is available over anonymous CVS, and can even be browsed over the Web (see below). !

        !

        A more formal description of the V3 goals can be found in the ! official design document. !

        !
        !

        1.2 Why should I use libstdc++?

        !

        The completion of the ISO C++ standardization gave the C++ community a powerful set of reuseable tools in the form of the C++ Standard Library. However, all existing C++ implementations are (as the Draft Standard used to say) "incomplet and incorrekt," and many suffer from limitations of the compilers that use them. !

        !

        The GNU C/C++/FORTRAN/<pick-a-language> compiler ! (gcc, g++, etc) is widely considered to be one of the leading compilers in the world. Its development has recently been taken over by the ! GCC team. All of the rapid development and near-legendary ! portability that are the hallmarks of an open-source project are being applied to libstdc++. !

        !

        That means that all of the Standard classes and functions ! (such as string, vector<>, iostreams, and algorithms) will be freely available and fully compliant. Programmers will no longer need to "roll their own" nor be worried about platform-specific incompatabilities. !

        !
        !

        1.3 Who's in charge of it?

        !

        The libstdc++ project is contributed to by several developers all over the world, in the same way as GCC or Linux. Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, and Ulrich Drepper are the lead maintainers of the CVS archive. !

        !

        Development and discussion is held on the libstdc++ mailing list. Subscribing to the list, or searching the list archives, is open to everyone. You can read instructions for ! doing so on the homepage. If you have questions, ideas, code, or are just curious, sign up! !

        !
        !

        1.4 How do I get libstdc++?

        !

        The eleventh (and latest) snapshot of libstdc++-v3 is ! available via ftp. !

        !

        The homepage has instructions for retrieving the latest CVS sources, and for browsing the CVS sources over the web. !

        !

        The subset commonly known as the Standard Template Library ! (chapters 23 through 25, mostly) is adapted from the SGI STL, ! which is also an ongoing work. !

        !
        !

        1.5 When is libstdc++ going to be finished?

        ! !

        Nathan Myers gave the best of all possible answers, responding to a ! Usenet article asking this question: Sooner, if you help. !

        ! !
        !

        1.6 How do I contribute to the effort?

        !

        Here is a ! page devoted to this topic. Subscribing to the mailing list (see above, or the homepage) is a very good idea if you have something to contribute, or if you have spare time and want to help. Contributions don't have to be in the form of source code; anybody who is willing to help write documentation, for example, or has found a bug in code that we all thought was working, is more than welcome! !

        !
        !

        1.7 What happened to libg++? I need that!

        !

        The most recent libg++ README states that libg++ is no longer being actively maintained. It should not be used for new projects, and is only being kicked along to support older code. !

        !

        The libg++ was designed and created when there was no Standard to provide guidance. Classes like linked lists are now provided ! for by list<T> and do not need to be created by ! genclass. (For that matter, templates exist now and are well-supported, whereas genclass (mostly) predates them.) !

        !

        There are other classes in libg++ that are not specified in the ISO Standard (e.g., statistical analysis). While there are a lot of really useful things that are used by a lot of people (e.g., statistics :-), the Standards Committee couldn't include everything, and so a lot of those "obvious" classes didn't get included. !

        !

        Since libstdc++ is an implementation of the Standard Library, we have no plans at this time to include non-Standard utilities in the implementation, however handy they are. (The extensions provided in the SGI STL aren't maintained by us and don't get --- 1,213 ---- ! ! ! ! ! ! libstdc++-v3 FAQ ! ! ! !

        libstdc++ Frequently Asked Questions

        !

        The latest version of this document is always available at ! ! http://gcc.gnu.org/onlinedocs/libstdc++/faq/.

        !

        To the libstdc++-v3 homepage. !


        !

        Questions

        !
          !
        1. General Information !
            !
          1. What is libstdc++-v3? !
          2. Why should I use libstdc++? !
          3. Who's in charge of it? !
          4. How do I get libstdc++? !
          5. When is libstdc++ going to be finished? !
          6. How do I contribute to the effort? !
          7. What happened to libg++? I need that! !
          8. What if I have more questions? !
          9. What are the license terms for libstdc++-v3? !
          !
        2. Installation !
            !
          1. How do I install libstdc++-v3? !
          2. [removed] !
          3. What is this CVS thing that you keep ! mentioning? !
          4. How do I know if it works? !
          !
        3. Platform-Specific Issues !
            !
          1. Can libstdc++-v3 be used with <my ! favorite compiler>? !
          2. [removed] !
          3. Building under DEC OSF kills the assembler !
          !
        4. Known Bugs and Non-Bugs !
            !
          1. What works already? !
          2. Bugs in gcc/g++ (not libstdc++-v3) !
          3. Bugs in the C++ language/lib specification !
          4. Things in libstdc++ that look like bugs ! !
          5. Aw, that's easy to fix! !
          !
        5. Miscellaneous !
            !
          1. string::iterator is not char*; ! vector<T>::iterator is not T* !
          2. What's next after libstdc++-v3? !
          3. What about the STL from SGI? !
          4. Extensions and Backward Compatibility !
          5. [removed] !
          6. Is libstdc++-v3 thread-safe? !
          7. How do I get a copy of the ISO C++ Standard? !
          !
        !
        !

        1.0 General Information

        !

        1.1 What is libstdc++-v3?

        !

        The GNU Standard C++ Library v3, or libstdc++-2.9x, is an ongoing project to implement the ISO 14882 Standard C++ library as described in chapters 17 through 27 and annex D. As the library reaches stable plateaus, it is captured in a snapshot ! and released. The current release is ! the ! eleventh snapshot. For those who want to see exactly how far the project has come, or just want the latest bleeding-edge code, the up-to-date source is available over anonymous CVS, and can even be browsed over the Web (see below). !

        !

        A more formal description of the V3 goals can be found in the ! official design document. !

        !
        !

        1.2 Why should I use libstdc++?

        !

        The completion of the ISO C++ standardization gave the C++ community a powerful set of reuseable tools in the form of the C++ Standard Library. However, all existing C++ implementations are (as the Draft Standard used to say) "incomplet and incorrekt," and many suffer from limitations of the compilers that use them. !

        !

        The GNU C/C++/FORTRAN/<pick-a-language> compiler ! (gcc, g++, etc) is widely considered to be one of the leading compilers in the world. Its development has recently been taken over by the ! GCC team. All of the rapid development and near-legendary ! portability that are the hallmarks of an open-source project are being applied to libstdc++. !

        !

        That means that all of the Standard classes and functions ! (such as string, vector<>, iostreams, and algorithms) will be freely available and fully compliant. Programmers will no longer need to "roll their own" nor be worried about platform-specific incompatabilities. !

        !
        !

        1.3 Who's in charge of it?

        !

        The libstdc++ project is contributed to by several developers all over the world, in the same way as GCC or Linux. Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, and Ulrich Drepper are the lead maintainers of the CVS archive. !

        !

        Development and discussion is held on the libstdc++ mailing list. Subscribing to the list, or searching the list archives, is open to everyone. You can read instructions for ! doing so on the homepage. If you have questions, ideas, code, or are just curious, sign up! !

        !
        !

        1.4 How do I get libstdc++?

        !

        The eleventh (and latest) snapshot of libstdc++-v3 is ! available via ! ftp. The filename is libstdc++-2.92.tar.gz. !

        !

        The homepage has instructions for retrieving the latest CVS sources, and for browsing the CVS sources over the web. !

        !

        The subset commonly known as the Standard Template Library ! (chapters 23 through 25, mostly) is adapted from the final release ! of the SGI STL. !

        !
        !

        1.5 When is libstdc++ going to be finished?

        ! !

        Nathan Myers gave the best of all possible answers, responding to a ! Usenet article asking this question: Sooner, if you help. !

        !
        !

        1.6 How do I contribute to the effort?

        !

        Here is a ! page devoted to this topic. Subscribing to the mailing list (see above, or the homepage) is a very good idea if you have something to contribute, or if you have spare time and want to help. Contributions don't have to be in the form of source code; anybody who is willing to help write documentation, for example, or has found a bug in code that we all thought was working, is more than welcome! !

        !
        !

        1.7 What happened to libg++? I need that!

        !

        The most recent libg++ README states that libg++ is no longer being actively maintained. It should not be used for new projects, and is only being kicked along to support older code. !

        !

        The libg++ was designed and created when there was no Standard to provide guidance. Classes like linked lists are now provided ! for by list<T> and do not need to be created by ! genclass. (For that matter, templates exist now and are well-supported, whereas genclass (mostly) predates them.) !

        !

        There are other classes in libg++ that are not specified in the ISO Standard (e.g., statistical analysis). While there are a lot of really useful things that are used by a lot of people (e.g., statistics :-), the Standards Committee couldn't include everything, and so a lot of those "obvious" classes didn't get included. !

        !

        Since libstdc++ is an implementation of the Standard Library, we have no plans at this time to include non-Standard utilities in the implementation, however handy they are. (The extensions provided in the SGI STL aren't maintained by us and don't get *************** which is no longer available, thanks dej *** 217,377 **** time.) It is entirely plausable that the "useful stuff" from libg++ might be extracted into an updated utilities library, but nobody has stated such a project yet. !

        !

        (The Boost site houses free C++ libraries that do varying things, and happened to be started by members of the Standards Committee. Certain "useful stuff" classes will probably migrate there.) !

        !

        For the bold and/or desperate, the ! GCC FAQ describes where to find the last libg++ source. !

        !
        !

        1.8 What if I have more questions?

        !

        If you have read the README and RELEASE-NOTES files, and your question remains unanswered, then just ask the mailing list. At present, you do not need to be subscribed to the list to send a message to it. More information is available on the homepage (including how to browse the list archives); to send ! to the list, use ! libstdc++@gcc.gnu.org. !

        !

        If you have a question that you think should be included here, ! or if you have a question about a question/answer here, ! contact Phil Edwards ! or Gabriel Dos Reis. !

        !
        !

        2.0 Installation

        !

        2.1 How do I install libstdc++-v3?

        !

        Complete instructions are not given here (this is a FAQ, not an installation document), but the tools required are few: !

        !
          !
        • A 3.x release of GCC. Note that building GCC is much easier and more automated than building the GCC 2.[78] series was. If you are using GCC 2.95, you can still build earlier snapshots of libstdc++. !
        • GNU Make is recommended, but should not be required. !
        • The GNU Autotools are needed if you are messing with the configury or makefiles. !
        !

        The file documentation.html provides a good overview of the steps necessary to build, install, and use the library. Instructions for configuring the library with new flags such as --enable-threads are there also, as well as patches and instructions for working with GCC 2.95. !

        !

        The top-level install.html and ! RELEASE-NOTES files contain the exact build and installation instructions. You may wish to browse those files over CVSweb ahead of time to get a feel for what's required. RELEASE-NOTES is located in the ".../docs/17_intro/" directory of the distribution. !

        !
        !

        2.2 [removed]

        !

        This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). !

        !
        !

        2.3 What is this CVS thing that you ! keep mentioning?

        !

        The Concurrent Versions System is one of several revision control packages. It was selected for GNU projects because it's free (speech), free (beer), and very high quality. The CVS entry in ! the GNU software catalogue has a better description as well as a ! link to the makers of CVS. !

        !

        The "anonymous client checkout" feature of CVS is similar to anonymous FTP in that it allows anyone to retrieve the latest libstdc++ sources. !

        !

        After the first of April, American users will have a "/pharmacy" command-line option... !

        !
        !

        2.4 How do I know if it works?

        !

        libstdc++-v3 comes with its own testsuite. You do not need ! to actually install the library ("make ! install") to run the testsuite. !

        !

        To run the testsuite on the library after building it, use "make check" while in your build directory. To run the testsuite on the library after building and installing it, use "make check-install" instead. !

        !

        If you find bugs in the testsuite programs themselves, or if ! you think of a new test program that should be added to the ! suite, please write up your idea and send it to the list! !

        !
        !

        3.0 Platform-Specific Issues

        !

        3.1 Can libstdc++-v3 be used with <my ! favorite compiler>?

        !

        Probably not. Yet.

        !

        Because GCC advances so rapidly, development and testing of libstdc++ is being done almost entirely under that compiler. If you are curious about whether other, lesser compilers (*grin*) support libstdc++, you are more than welcome to try. Configuring and building the library (see above) will still require certain tools, however. Also keep in mind that ! building libstdc++ does not imply that your compiler ! will be able to use all of the features found in the C++ Standard Library. !

        !

        Since the goal of ISO Standardization is for all C++ implementations to be able to share code, the final libstdc++ should, in theory, be useable under any ISO-compliant compiler. It will still be targeted and optimized for GCC/g++, however. !

        !
        !

        3.2 [removed]

        !

        This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). !

        !
        !

        3.3 Building DEC OSF kills the assembler

        !

        The atomicity.h header for the Alpha processor currently uses pseudo-operators which the DEC assembler doesn't understand (in particular, .subsection and .previous). ! The simple solution is to install GNU as and arrange for the GCC build to use it (or merge the sources and build it during the bootstrap). !

        !

        Anyone who ! knows ! the DEC assembler well enough to provide the equivalent of these two pseudos would win praise and accolades from many. !

        ! !
        !

        4.0 Known Bugs and Non-Bugs

        ! Note that this section can get rapdily outdated -- such is the nature of an open-source project. For the latest information, join the mailing list or look through recent archives. The RELEASE- ! NOTES and BUGS files are generally kept up-to-date. !

        4.1 What works already?

        !

        This is a verbatim clip from the "Status" section of the RELEASE-NOTES for the latest snapshot. !

        --- 215,398 ---- time.) It is entirely plausable that the "useful stuff" from libg++ might be extracted into an updated utilities library, but nobody has stated such a project yet. !

        !

        (The Boost site houses free C++ libraries that do varying things, and happened to be started by members of the Standards Committee. Certain "useful stuff" classes will probably migrate there.) !

        !

        For the bold and/or desperate, the ! GCC FAQ describes where to find the last libg++ source. !

        !
        !

        1.8 What if I have more questions?

        !

        If you have read the README and RELEASE-NOTES files, and your question remains unanswered, then just ask the mailing list. At present, you do not need to be subscribed to the list to send a message to it. More information is available on the homepage (including how to browse the list archives); to send ! to the list, use ! libstdc++@gcc.gnu.org. !

        !

        If you have a question that you think should be included here, ! or if you have a question about a question/answer here, ! contact Phil Edwards ! or Gabriel Dos Reis. !

        !
        !

        1.9 What are the license terms for libstdc++-v3?

        !

        See our license description ! for these and related questions. !

        !
        !

        2.0 Installation

        !

        2.1 How do I install libstdc++-v3?

        !

        Complete instructions are not given here (this is a FAQ, not an installation document), but the tools required are few: !

        !
          !
        • A 3.x release of GCC. Note that building GCC is much easier and more automated than building the GCC 2.[78] series was. If you are using GCC 2.95, you can still build earlier snapshots of libstdc++. !
        • GNU Make is recommended, but should not be required. !
        • The GNU Autotools are needed if you are messing with the configury or makefiles. !
        !

        The file documentation.html provides a good overview of the steps necessary to build, install, and use the library. Instructions for configuring the library with new flags such as --enable-threads are there also, as well as patches and instructions for working with GCC 2.95. !

        !

        The top-level install.html and ! RELEASE-NOTES files contain the exact build and installation instructions. You may wish to browse those files over CVSweb ahead of time to get a feel for what's required. RELEASE-NOTES is located in the ".../docs/17_intro/" directory of the distribution. !

        !
        !

        2.2 [removed]

        !

        This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). !

        !
        !

        2.3 What is this CVS thing that you ! keep mentioning?

        !

        The Concurrent Versions System is one of several revision control packages. It was selected for GNU projects because it's free (speech), free (beer), and very high quality. The CVS entry in ! the GNU software catalogue has a better description as well as a ! link to the makers of CVS. !

        !

        The "anonymous client checkout" feature of CVS is similar to anonymous FTP in that it allows anyone to retrieve the latest libstdc++ sources. !

        !

        After the first of April, American users will have a "/pharmacy" command-line option... !

        !
        !

        2.4 How do I know if it works?

        !

        libstdc++-v3 comes with its own testsuite. You do not need ! to actually install the library ("make ! install") to run the testsuite. !

        !

        To run the testsuite on the library after building it, use "make check" while in your build directory. To run the testsuite on the library after building and installing it, use "make check-install" instead. !

        !

        If you find bugs in the testsuite programs themselves, or if you ! think of a new test program that should be added to the suite, ! please write up your idea and send it to the list! !

        !
        !

        3.0 Platform-Specific Issues

        !

        3.1 Can libstdc++-v3 be used with <my ! favorite compiler>?

        !

        Probably not. Yet.

        !

        Because GCC advances so rapidly, development and testing of libstdc++ is being done almost entirely under that compiler. If you are curious about whether other, lesser compilers (*grin*) support libstdc++, you are more than welcome to try. Configuring and building the library (see above) will still require certain tools, however. Also keep in mind that ! building libstdc++ does not imply that your compiler ! will be able to use all of the features found in the C++ Standard Library. !

        !

        Since the goal of ISO Standardization is for all C++ implementations to be able to share code, the final libstdc++ should, in theory, be useable under any ISO-compliant compiler. It will still be targeted and optimized for GCC/g++, however. !

        !
        !

        3.2 [removed]

        !

        This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). !

        !
        !

        3.3 Building DEC OSF kills the assembler

        !

        The atomicity.h header for the Alpha processor currently uses pseudo-operators which the DEC assembler doesn't understand (in particular, .subsection and .previous). ! The simple solution is to install GNU as and arrange for the GCC build to use it (or merge the sources and build it during the bootstrap). !

        !

        Anyone who ! knows ! the DEC assembler well enough to provide the equivalent of these two pseudos would win praise and accolades from many. !

        !
        !

        4.0 Known Bugs and Non-Bugs

        ! Note that this section can get rapdily outdated -- such is the nature of an open-source project. For the latest information, join the mailing list or look through recent archives. The RELEASE- ! NOTES and BUGS files are generally kept up-to-date. !

        For 3.0.1, the most common "bug" is an apparently missing ! "../" in include/Makefile, resulting in files ! like gthr.h and gthr-single.h not being found. !

        !

        Please read ! the configuration ! instructions for GCC, ! specifically the part about configuring in a separate build directory, ! and how strongly recommended it is. Building in the source directory ! is fragile, is rarely tested, and tends to break, as in this case. ! Work has already gone into the source tree to make this less painful ! for the next release. !

        !

        Please do not report this as a bug. We know about it. ! Reporting this -- or any other problem that's already been fixed -- ! hinders the development of GCC, because we have to take time to ! respond to your report. Thank you. !

        ! !

        4.1 What works already?

        !

        This is a verbatim clip from the "Status" section of the RELEASE-NOTES for the latest snapshot. !

        *************** New: *** 402,687 **** !
        !

        4.2 Bugs in gcc/g++ (not libstdc++-v3)

        !

        This is by no means meant to be complete nor exhaustive, but mentions some problems that users may encounter when building or using libstdc++. If you are experiencing one of these problems, you can find more information on the libstdc++ and the GCC mailing lists. !

        !
          !
        • As of 2.91, these bugs have all been fixed. We look forward to new ones, well, not exactly... !
        !
        !

        4.3 Bugs in the C++ language/lib specification

        !

        Yes, unfortunately, there are some. In a message ! to the list, Nathan Myers announced that he has started a list of problems in the ISO C++ Standard itself, especially with regard to the chapters that concern the library. The list ! itself is posted on his ! website. Developers who are having problems interpreting the Standard may wish to consult his notes. !

        !

        For those people who are not part of the ISO Library Group (i.e., nearly all of us needing to read this page in the first place :-), a public list of the library defects is occasionally ! published here. !

        !
        !

        4.4 Things in libstdc++ that look like bugs

        !

        There are things which are not bugs in the compiler (4.2) nor the language specification (4.3), but aren't really bugs in libstdc++, either. Really! Please do not report these as bugs. !

        ! !

        -Weffc++ The biggest of these is the quadzillions of warnings about the ! library headers emitted when -Weffc++ is used. Making libstdc++ "-Weffc++-clean" is not a goal of the project, for a few reasons. Mainly, that option tries to enforce object-oriented programming, while the Standard Library isn't necessarily trying to be OO. There are multiple solutions under discussion. !

        !
        ! !

        rel_ops ! Another is the rel_ops namespace and the template comparison operator functions contained therein. If they become visible in the same namespace as other comparison functions ! (e.g., 'using' them and the <iterator> header), then you will suddenly be faced with huge numbers of ambiguity errors. This was discussed on the -v3 list; Nathan Myers ! sums ! things up here. !

        ! !

        The g++-3 headers are ! not ours

        !

        If you have found an extremely broken header file which is causing problems for you, look carefully before submitting a "high" priority bug report (which you probably shouldn't do anyhow; see the last paragraph of the page describing ! the GCC bug database). !

        !

        If the headers are in ${prefix}/include/g++-3, then you are using the old libstdc++-v2 library, which is nonstandard and unmaintained. Do not report problems with -v2 to the -v3 mailing list. !

        !

        Currently our header files are installed in ! ${prefix}/include/g++-v3 (see the 'v'?). This may change with the next release of GCC, as it may be too confusing, ! but the ! question has not yet been decided. !

        ! ! !

        glibc If you're on a GNU/Linux system and have just upgraded to glibc 2.2, but are still using gcc 2.95.2, then you should have read the glibc FAQ, specifically 2.34: !

          2.34.   When compiling C++ programs, I get a compilation error in streambuf.h.
          
          {BH} You are using g++ 2.95.2? After upgrading to glibc 2.2, you need to
          apply a patch to the include files in /usr/include/g++, because the fpos_t
          type has changed in glibc 2.2.  The patch is at
          http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
        !    
        Note that 2.95.x shipped with the !
        old v2 library which is no longer maintained. Also note that gcc 2.95.3 fixes this problem, but requires a separate patch for libstdc++-v3. !

        ! ! !

        concept checks If you see compilation errors containing messages about ! fooConcept and a constraints member function, then most likely you have violated one of the requirements for types used during instantiation of template containers and functions. For example, EqualityComparableConcept appears if your types must be comparable with == and you have not provided this capability (a typo, or wrong visibility, or you just plain forgot, etc). !

        !

        More information, including how to optionally enable/disable the checks, is available ! here. !

        ! !
        !

        4.5 Aw, that's easy to fix!

        !

        If you have found a bug in the library and you think you have a working fix, then send it in! The main GCC site has a page ! on submitting ! patches that covers the procedure, but for libstdc++ you should also send the patch to our mailing list in addition to the GCC patches mailing list. The libstdc++ ! contributors' page also talks about how to submit patches. !

        !

        In addition to the description, the patch, and the ChangeLog entry, it is a Good Thing if you can additionally create a small test program to test for the presence of the bug that your patch fixes. Bugs have a way of being reintroduced; if an old bug creeps back in, it will be caught immediately by the ! testsuite -- but only if such a test exists. !

        !
        !

        5.0 Miscellaneous

        !

        5.1 string::iterator is not char*; ! vector<T>::iterator is not T*

        !

        If you have code that depends on container<T> iterators being implemented as pointer-to-T, your code is broken. !

        !

        While there are arguments for iterators to be implemented in that manner, A) they aren't very good ones in the long term, and B) they were never guaranteed by the Standard anyway. The type-safety achieved by making iterators a real class rather ! than a typedef for T* outweighs nearly all opposing arguments. !

        !

        Code which does assume that a vector iterator i is a pointer can often be fixed by changing i in certain expressions to &*i . Future revisions of the Standard are expected to bless this usage for vector<> (but not for basic_string<>). !

        !
        !

        5.2 What's next after libstdc++-v3?

        !

        Hopefully, not much. The goal of libstdc++-v3 is to produce a fully-compliant, fully-portable Standard Library. After that, ! we're mostly done: there won't be any more compliance work to do. However: !

        !
          !
        1. The ISO Committee will meet periodically to review Defect Reports in the C++ Standard. Undoubtedly some of these will result in changes to the Standard, which will be reflected in patches to libstdc++. Some of that is already happening, see 4.2. Some of those changes are being predicted by the library maintainers, and we add code to the library based on what the current proposed ! resolution specifies. !

          !
        2. Performance tuning. Lots of performance tuning. This too is already underway for post-3.0 releases, starting with memory expansion in container classes and buffer usage in synchronized stream objects. !

          !
        3. An ABI for libstdc++ will eventually be developed, so that multiple binary-incompatible copies of the library can be replaced with a single backwards-compatible library, like libgcc_s.so is. !

          !
        4. The current libstdc++ contains extensions to the Library which must be explicitly requested by client code (for example, the hash tables from SGI). Other extensions may be added to libstdc++-v3 if they seem to be "standard" enough. (For example, the "long long" type from C99.) Bugfixes and rewrites (to improve or fix thread safety, for instance) will of course be a continuing task. !

          !
        !

        This ! question about the next libstdc++ prompted some brief but ! interesting speculation. !

        !
        !

        5.3 What about the STL from SGI?

        !

        The STL from SGI, version 3.3, was the most recent merge of the STL codebase. The code in libstdc++ contains many fixes and changes, and it is very likely that the SGI code is no longer under active development. We expect that no future merges will take place. !

        !

        In particular, string is not from SGI and makes no use of their "rope" class (which is included as an ! optional extension), nor is valarray and some others. ! Classes like vector<> are, however. !

        !

        The FAQ for SGI's STL (one jump off of their main page) is recommended reading. !

        !
        !

        5.4 Extensions and Backward Compatibility

        !

        Although you can specify -I options to make the preprocessor search the g++-v3/ext and /backward directories, it is better to refer to files there by their path, as in: !

        !
                 #include <ext/hash_map>
        !          
        !

        Extensions to the library have ! their own page. !

        !
        !

        5.5 [removed]

        !

        This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). !

        !
        !

        5.6 Is libstdc++-v3 thread-safe?

        !

        Quick answer: no, as of 2.92 (eleventh snapshot), the ! library is not appropriate for multithreaded access. The ! string class is MT-safe. !

        !

        This is assuming that your idea of "multithreaded" ! is the same as ours... The general question of multithreading ! and libstdc++-v3 is addressed in the chapter-specific advice for ! Library ! Introduction. Threadsafe containers are covered in ! more detail in ! the ! Received Wisdom section on containers. ! !

        !
        !

        5.7 How do I get a copy of the ISO C++ Standard?

        !

        Copies of the full ISO 14882 standard are available on line via the ISO mirror site for committee members. Non-members, or those who have not paid for the privilege of sitting on the committee and sustained their two-meeting commitment for voting rights, may get a copy of the standard from their respective national standards organization. In the USA, this national standards organization is ! ANSI and their website is right here. (And if you've already registered with them, clicking this link will take you to directly to the place where you can ! buy ! the standard on-line. !

        !

        Who is your country's member body? Visit the ! ISO homepage and find out! !

        !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: index.html,v 1.2.4.5 2001/07/18 21:39:58 pme Exp $ !

        ! ! --- 423,762 ---- !
        !

        4.2 Bugs in gcc/g++ (not libstdc++-v3)

        !

        This is by no means meant to be complete nor exhaustive, but mentions some problems that users may encounter when building or using libstdc++. If you are experiencing one of these problems, you can find more information on the libstdc++ and the GCC mailing lists. !

        !
          !
        • As of 2.91, these bugs have all been fixed. We look forward to new ones, well, not exactly... !
        !
        !

        4.3 Bugs in the C++ language/lib specification

        !

        Yes, unfortunately, there are some. In a ! message ! to the list, Nathan Myers announced that he has started a list of problems in the ISO C++ Standard itself, especially with regard to the chapters that concern the library. The list ! itself is ! posted on his ! website. Developers who are having problems interpreting the Standard may wish to consult his notes. !

        !

        For those people who are not part of the ISO Library Group (i.e., nearly all of us needing to read this page in the first place :-), a public list of the library defects is occasionally ! published here. ! Some of these have resulted in code changes. !

        !
        !

        4.4 Things in libstdc++ that look like bugs

        !

        There are things which are not bugs in the compiler (4.2) nor the language specification (4.3), but aren't really bugs in libstdc++, either. Really! Please do not report these as bugs. !

        ! !

        -Weffc++ The biggest of these is the quadzillions of warnings about the ! library headers emitted when -Weffc++ is used. Making libstdc++ "-Weffc++-clean" is not a goal of the project, for a few reasons. Mainly, that option tries to enforce object-oriented programming, while the Standard Library isn't necessarily trying to be OO. There are multiple solutions under discussion. !

        !
        ! !

        reopening a stream fails ! Did I just say that -Weffc++ was our biggest false-bug report? I ! lied. (It used to be.) Today it seems to be reports that after ! executing a sequence like !

        !     #include <fstream>
        !     ...
        !     std::fstream  fs("a_file");
        !     // .
        !     // . do things with fs...
        !     // .
        !     fs.close();
        !     fs.open("a_new_file");
        ! all operations on the re-opened fs will fail, or at ! least act very strangely. Yes, they often will, especially if ! fs reached the EOF state on the previous file. The ! reason is that the state flags are not cleared ! on a successful call to open(). The standard unfortunately did ! not specify behavior in this case, and to everybody's great sorrow, ! the
        proposed LWG resolution (see ! DR #22) is to leave the flags unchanged. You must insert a call ! to fs.clear() between the calls to close() and open(), ! and then everything will work like we all expect it to work. !

        ! ! !

        rel_ops ! Another is the rel_ops namespace and the template comparison operator functions contained therein. If they become visible in the same namespace as other comparison functions ! (e.g., 'using' them and the <iterator> header), then you will suddenly be faced with huge numbers of ambiguity errors. This was discussed on the -v3 list; Nathan Myers ! sums ! things up here. !

        ! !

        The g++-3 headers are ! not ours

        !

        If you have found an extremely broken header file which is causing problems for you, look carefully before submitting a "high" priority bug report (which you probably shouldn't do anyhow; see the last paragraph of the page describing ! the GCC bug database). !

        !

        If the headers are in ${prefix}/include/g++-3, then you are using the old libstdc++-v2 library, which is nonstandard and unmaintained. Do not report problems with -v2 to the -v3 mailing list. !

        !

        Currently our header files are installed in ! ${prefix}/include/g++-v3 (see the 'v'?). This may change with the next release of GCC, as it may be too confusing, ! but the ! question has not yet been decided. !

        ! ! !

        glibc If you're on a GNU/Linux system and have just upgraded to glibc 2.2, but are still using gcc 2.95.2, then you should have read the glibc FAQ, specifically 2.34: !

          2.34.   When compiling C++ programs, I get a compilation error in streambuf.h.
          
          {BH} You are using g++ 2.95.2? After upgrading to glibc 2.2, you need to
          apply a patch to the include files in /usr/include/g++, because the fpos_t
          type has changed in glibc 2.2.  The patch is at
          http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
        !    
        Note that 2.95.x shipped with the !
        old v2 library which is no longer maintained. Also note that gcc 2.95.3 fixes this problem, but requires a separate patch for libstdc++-v3. !

        ! ! !

        concept checks If you see compilation errors containing messages about ! fooConcept and a constraints member function, then most likely you have violated one of the requirements for types used during instantiation of template containers and functions. For example, EqualityComparableConcept appears if your types must be comparable with == and you have not provided this capability (a typo, or wrong visibility, or you just plain forgot, etc). !

        !

        More information, including how to optionally enable/disable the checks, is available ! here. !

        ! !
        !

        4.5 Aw, that's easy to fix!

        !

        If you have found a bug in the library and you think you have a working fix, then send it in! The main GCC site has a page ! on submitting ! patches that covers the procedure, but for libstdc++ you should also send the patch to our mailing list in addition to the GCC patches mailing list. The libstdc++ ! contributors' page also talks about how to submit patches. !

        !

        In addition to the description, the patch, and the ChangeLog entry, it is a Good Thing if you can additionally create a small test program to test for the presence of the bug that your patch fixes. Bugs have a way of being reintroduced; if an old bug creeps back in, it will be caught immediately by the ! testsuite -- but only if such a test exists. !

        !
        !

        5.0 Miscellaneous

        !

        5.1 string::iterator is not char*; ! vector<T>::iterator is not T*

        !

        If you have code that depends on container<T> iterators being implemented as pointer-to-T, your code is broken. !

        !

        While there are arguments for iterators to be implemented in that manner, A) they aren't very good ones in the long term, and B) they were never guaranteed by the Standard anyway. The type-safety achieved by making iterators a real class rather ! than a typedef for T* outweighs nearly all opposing arguments. !

        !

        Code which does assume that a vector iterator i is a pointer can often be fixed by changing i in certain expressions to &*i . Future revisions of the Standard are expected to bless this usage for vector<> (but not for basic_string<>). !

        !
        !

        5.2 What's next after libstdc++-v3?

        !

        Hopefully, not much. The goal of libstdc++-v3 is to produce a fully-compliant, fully-portable Standard Library. After that, ! we're mostly done: there won't be any more compliance work to do. However: !

        !
          !
        1. The ISO Committee will meet periodically to review Defect Reports in the C++ Standard. Undoubtedly some of these will result in changes to the Standard, which will be reflected in patches to libstdc++. Some of that is already happening, see 4.2. Some of those changes are being predicted by the library maintainers, and we add code to the library based on what the current proposed ! resolution specifies. Those additions are listed in ! the extensions page. !

          !
        2. Performance tuning. Lots of performance tuning. This too is already underway for post-3.0 releases, starting with memory expansion in container classes and buffer usage in synchronized stream objects. !

          !
        3. An ABI for libstdc++ will eventually be developed, so that multiple binary-incompatible copies of the library can be replaced with a single backwards-compatible library, like libgcc_s.so is. !

          !
        4. The current libstdc++ contains extensions to the Library which must be explicitly requested by client code (for example, the hash tables from SGI). Other extensions may be added to libstdc++-v3 if they seem to be "standard" enough. (For example, the "long long" type from C99.) Bugfixes and rewrites (to improve or fix thread safety, for instance) will of course be a continuing task. !

          !
        !

        This ! question about the next libstdc++ prompted some brief but ! interesting ! speculation. !

        !
        !

        5.3 What about the STL from SGI?

        !

        The STL from SGI, version 3.3, was the most recent merge of the STL codebase. The code in libstdc++ contains many fixes and changes, and it is very likely that the SGI code is no longer under active development. We expect that no future merges will take place. !

        !

        In particular, string is not from SGI and makes no use of their "rope" class (which is included as an ! optional extension), nor is valarray and some others. ! Classes like vector<> are, however. !

        !

        The FAQ for SGI's STL (one jump off of their main page) is recommended reading. !

        !
        !

        5.4 Extensions and Backward Compatibility

        !

        Although you can specify -I options to make the preprocessor search the g++-v3/ext and /backward directories, it is better to refer to files there by their path, as in: !

        !
                 #include <ext/hash_map>
        !          
        !

        Extensions to the library have ! their own page. !

        !
        !

        5.5 [removed]

        !

        This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). !

        !
        !

        5.6 Is libstdc++-v3 thread-safe?

        !

        When the system's libc is itself thread-safe, a non-generic ! implementation of atomicity.h exists for the architecture, and gcc ! itself reports a thread model other than single; libstdc++-v3 ! strives to be thread-safe. The user-code must guard against ! concurrent method calls which may access any particular library ! object's state. Typically, the application programmer may infer ! what object locks must be held based on the objects referenced in ! a method call. Without getting into great detail, here is an ! example which requires user-level locks: !

        !      library_class_a shared_object_a;
          
        !      thread_main () {
        !        library_class_b *object_b = new library_class_b;
        !        shared_object_a.add_b (object_b);   // must hold lock for shared_object_a
        !        shared_object_a.mutate ();          // must hold lock for shared_object_a
        !      }
        ! 
        !      // Multiple copies of thread_main() are started in independent threads.
        !

        !

        Under the assumption that object_a and object_b are never exposed to ! another thread, here is an example that should not require any ! user-level locks: !

        !      thread_main () {
        !        library_class_a object_a;
        !        library_class_b *object_b = new library_class_b;
        !        object_a.add_b (object_b);
        !        object_a.mutate ();
        !      } 
        !

        !

        All library objects are safe to use in a multithreaded program as ! long as each thread carefully locks out access by any other thread ! while it uses any object visible to another thread. This requirement ! includes both read and write access to objects; do not assume that ! two threads may read a shared standard container at the same time. !

        !

        See chapters 17 (library ! introduction), 23 ! (containers), and 27 (I/O) for ! more information. !

        ! !
        !

        5.7 How do I get a copy of the ISO C++ Standard?

        !

        Copies of the full ISO 14882 standard are available on line via the ISO mirror site for committee members. Non-members, or those who have not paid for the privilege of sitting on the committee and sustained their two-meeting commitment for voting rights, may get a copy of the standard from their respective national standards organization. In the USA, this national standards organization is ! ANSI and their website is right here. (And if you've already registered with them, clicking this link will take you to directly to the place where you can ! buy ! the standard on-line. !

        !

        Who is your country's member body? Visit the ! ISO homepage and find out! !

        !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/faq/index.txt gcc-3.0.2/libstdc++-v3/docs/html/faq/index.txt *** gcc-3.0.1/libstdc++-v3/docs/html/faq/index.txt Wed Jul 18 14:39:58 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/faq/index.txt Fri Oct 19 13:07:42 2001 *************** *** 1,7 **** libstdc++ Frequently Asked Questions ! The latest version of this document is always available at [1]http://gcc.gnu.org/onlinedocs/libstdc++/faq/. To the [2]libstdc++-v3 homepage. --- 1,7 ---- libstdc++ Frequently Asked Questions ! The latest version of this document is always available at [1]http://gcc.gnu.org/onlinedocs/libstdc++/faq/. To the [2]libstdc++-v3 homepage. *************** *** 18,166 **** 6. [9]How do I contribute to the effort? 7. [10]What happened to libg++? I need that! 8. [11]What if I have more questions? ! 2. [12]Installation ! 1. [13]How do I install libstdc++-v3? ! 2. [14][removed] ! 3. [15]What is this CVS thing that you keep mentioning? ! 4. [16]How do I know if it works? ! 3. [17]Platform-Specific Issues ! 1. [18]Can libstdc++-v3 be used with ? ! 2. [19][removed] ! 3. [20]Building under DEC OSF kills the assembler ! 4. [21]Known Bugs and Non-Bugs ! 1. [22]What works already? ! 2. [23]Bugs in gcc/g++ (not libstdc++-v3) ! 3. [24]Bugs in the C++ language/lib specification ! 4. [25]Things in libstdc++ that look like bugs ! o [26]-Weffc++ complains too much ! o [27]"ambiguous overloads" after including an old-style header ! o [28]The g++-3 headers are not ours ! o [29]compilation errors from streambuf.h ! o [30]errors about *Cconcept and constraints in the STL... ! 5. [31]Aw, that's easy to fix! ! 5. [32]Miscellaneous ! 1. [33]string::iterator is not char*; vector::iterator is not T* ! 2. [34]What's next after libstdc++-v3? ! 3. [35]What about the STL from SGI? ! 4. [36]Extensions and Backward Compatibility ! 5. [37][removed] ! 6. [38]Is libstdc++-v3 thread-safe? ! 7. [39]How do I get a copy of the ISO C++ Standard? _________________________________________________________________ 1.0 General Information 1.1 What is libstdc++-v3? ! The GNU Standard C++ Library v3, or libstdc++-2.9x, is an ongoing ! project to implement the ISO 14882 Standard C++ library as described ! in chapters 17 through 27 and annex D. As the library reaches stable ! plateaus, it is captured in a snapshot and released. The current ! release is [40]the eleventh snapshot. For those who want to see ! exactly how far the project has come, or just want the latest ! bleeding-edge code, the up-to-date source is available over anonymous CVS, and can even be browsed over the Web (see below). A more formal description of the V3 goals can be found in the official ! [41]design document. _________________________________________________________________ 1.2 Why should I use libstdc++? The completion of the ISO C++ standardization gave the C++ community a ! powerful set of reuseable tools in the form of the C++ Standard ! Library. However, all existing C++ implementations are (as the Draft ! Standard used to say) "incomplet and incorrekt," and many suffer from limitations of the compilers that use them. ! The GNU C/C++/FORTRAN/ compiler (gcc, g++, etc) is widely considered to be one of the leading compilers in the world. Its ! development has recently been taken over by the [42]GCC team. All of ! the rapid development and near-legendary [43]portability that are the hallmarks of an open-source project are being applied to libstdc++. ! That means that all of the Standard classes and functions (such as ! string, vector<>, iostreams, and algorithms) will be freely available ! and fully compliant. Programmers will no longer need to "roll their own" nor be worried about platform-specific incompatabilities. _________________________________________________________________ 1.3 Who's in charge of it? The libstdc++ project is contributed to by several developers all over ! the world, in the same way as GCC or Linux. Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, and Ulrich Drepper are the lead maintainers of the CVS archive. ! Development and discussion is held on the libstdc++ mailing list. ! Subscribing to the list, or searching the list archives, is open to ! everyone. You can read instructions for doing so on the [44]homepage. If you have questions, ideas, code, or are just curious, sign up! _________________________________________________________________ 1.4 How do I get libstdc++? ! The eleventh (and latest) snapshot of libstdc++-v3 is [45]available ! via ftp. ! The [46]homepage has instructions for retrieving the latest CVS sources, and for browsing the CVS sources over the web. ! The subset commonly known as the Standard Template Library (chapters ! 23 through 25, mostly) is adapted from the SGI STL, which is also an ! ongoing work. _________________________________________________________________ 1.5 When is libstdc++ going to be finished? ! Nathan Myers gave the best of all possible answers, responding to a Usenet article asking this question: Sooner, if you help. _________________________________________________________________ 1.6 How do I contribute to the effort? ! Here is [47]a page devoted to this topic. Subscribing to the mailing ! list (see above, or the homepage) is a very good idea if you have ! something to contribute, or if you have spare time and want to help. Contributions don't have to be in the form of source code; anybody who ! is willing to help write documentation, for example, or has found a bug in code that we all thought was working, is more than welcome! _________________________________________________________________ 1.7 What happened to libg++? I need that! ! The most recent libg++ README states that libg++ is no longer being ! actively maintained. It should not be used for new projects, and is only being kicked along to support older code. ! The libg++ was designed and created when there was no Standard to ! provide guidance. Classes like linked lists are now provided for by ! list and do not need to be created by genclass. (For that matter, ! templates exist now and are well-supported, whereas genclass (mostly) predates them.) ! There are other classes in libg++ that are not specified in the ISO Standard (e.g., statistical analysis). While there are a lot of really ! useful things that are used by a lot of people (e.g., statistics :-), ! the Standards Committee couldn't include everything, and so a lot of those "obvious" classes didn't get included. ! Since libstdc++ is an implementation of the Standard Library, we have ! no plans at this time to include non-Standard utilities in the ! implementation, however handy they are. (The extensions provided in ! the SGI STL aren't maintained by us and don't get a lot of our ! attention, because they don't require a lot of our time.) It is ! entirely plausable that the "useful stuff" from libg++ might be ! extracted into an updated utilities library, but nobody has stated such a project yet. ! (The [48]Boost site houses free C++ libraries that do varying things, ! and happened to be started by members of the Standards Committee. Certain "useful stuff" classes will probably migrate there.) ! For the bold and/or desperate, the [49]GCC FAQ describes where to find the last libg++ source. _________________________________________________________________ --- 18,168 ---- 6. [9]How do I contribute to the effort? 7. [10]What happened to libg++? I need that! 8. [11]What if I have more questions? ! 9. [12]What are the license terms for libstdc++-v3? ! 2. [13]Installation ! 1. [14]How do I install libstdc++-v3? ! 2. [15][removed] ! 3. [16]What is this CVS thing that you keep mentioning? ! 4. [17]How do I know if it works? ! 3. [18]Platform-Specific Issues ! 1. [19]Can libstdc++-v3 be used with ? ! 2. [20][removed] ! 3. [21]Building under DEC OSF kills the assembler ! 4. [22]Known Bugs and Non-Bugs ! 1. [23]What works already? ! 2. [24]Bugs in gcc/g++ (not libstdc++-v3) ! 3. [25]Bugs in the C++ language/lib specification ! 4. [26]Things in libstdc++ that look like bugs ! o [27]reopening a stream fails ! o [28]-Weffc++ complains too much ! o [29]"ambiguous overloads" after including an old-style header ! o [30]The g++-3 headers are not ours ! o [31]compilation errors from streambuf.h ! o [32]errors about *Cconcept and constraints in the STL... ! 5. [33]Aw, that's easy to fix! ! 5. [34]Miscellaneous ! 1. [35]string::iterator is not char*; vector::iterator is not T* ! 2. [36]What's next after libstdc++-v3? ! 3. [37]What about the STL from SGI? ! 4. [38]Extensions and Backward Compatibility ! 5. [39][removed] ! 6. [40]Is libstdc++-v3 thread-safe? ! 7. [41]How do I get a copy of the ISO C++ Standard? _________________________________________________________________ 1.0 General Information 1.1 What is libstdc++-v3? ! The GNU Standard C++ Library v3, or libstdc++-2.9x, is an ongoing ! project to implement the ISO 14882 Standard C++ library as described ! in chapters 17 through 27 and annex D. As the library reaches stable ! plateaus, it is captured in a snapshot and released. The current ! release is [42]the eleventh snapshot. For those who want to see ! exactly how far the project has come, or just want the latest ! bleeding-edge code, the up-to-date source is available over anonymous CVS, and can even be browsed over the Web (see below). A more formal description of the V3 goals can be found in the official ! [43]design document. _________________________________________________________________ 1.2 Why should I use libstdc++? The completion of the ISO C++ standardization gave the C++ community a ! powerful set of reuseable tools in the form of the C++ Standard ! Library. However, all existing C++ implementations are (as the Draft ! Standard used to say) "incomplet and incorrekt," and many suffer from limitations of the compilers that use them. ! The GNU C/C++/FORTRAN/ compiler (gcc, g++, etc) is widely considered to be one of the leading compilers in the world. Its ! development has recently been taken over by the [44]GCC team. All of ! the rapid development and near-legendary [45]portability that are the hallmarks of an open-source project are being applied to libstdc++. ! That means that all of the Standard classes and functions (such as ! string, vector<>, iostreams, and algorithms) will be freely available ! and fully compliant. Programmers will no longer need to "roll their own" nor be worried about platform-specific incompatabilities. _________________________________________________________________ 1.3 Who's in charge of it? The libstdc++ project is contributed to by several developers all over ! the world, in the same way as GCC or Linux. Benjamin Kosnik, Gabriel Dos Reis, Phil Edwards, and Ulrich Drepper are the lead maintainers of the CVS archive. ! Development and discussion is held on the libstdc++ mailing list. ! Subscribing to the list, or searching the list archives, is open to ! everyone. You can read instructions for doing so on the [46]homepage. If you have questions, ideas, code, or are just curious, sign up! _________________________________________________________________ 1.4 How do I get libstdc++? ! The eleventh (and latest) snapshot of libstdc++-v3 is [47]available ! via ftp. The filename is libstdc++-2.92.tar.gz. ! The [48]homepage has instructions for retrieving the latest CVS sources, and for browsing the CVS sources over the web. ! The subset commonly known as the Standard Template Library (chapters ! 23 through 25, mostly) is adapted from the final release of the SGI ! STL. _________________________________________________________________ 1.5 When is libstdc++ going to be finished? ! Nathan Myers gave the best of all possible answers, responding to a Usenet article asking this question: Sooner, if you help. _________________________________________________________________ 1.6 How do I contribute to the effort? ! Here is [49]a page devoted to this topic. Subscribing to the mailing ! list (see above, or the homepage) is a very good idea if you have ! something to contribute, or if you have spare time and want to help. Contributions don't have to be in the form of source code; anybody who ! is willing to help write documentation, for example, or has found a bug in code that we all thought was working, is more than welcome! _________________________________________________________________ 1.7 What happened to libg++? I need that! ! The most recent libg++ README states that libg++ is no longer being ! actively maintained. It should not be used for new projects, and is only being kicked along to support older code. ! The libg++ was designed and created when there was no Standard to ! provide guidance. Classes like linked lists are now provided for by ! list and do not need to be created by genclass. (For that matter, ! templates exist now and are well-supported, whereas genclass (mostly) predates them.) ! There are other classes in libg++ that are not specified in the ISO Standard (e.g., statistical analysis). While there are a lot of really ! useful things that are used by a lot of people (e.g., statistics :-), ! the Standards Committee couldn't include everything, and so a lot of those "obvious" classes didn't get included. ! Since libstdc++ is an implementation of the Standard Library, we have ! no plans at this time to include non-Standard utilities in the ! implementation, however handy they are. (The extensions provided in ! the SGI STL aren't maintained by us and don't get a lot of our ! attention, because they don't require a lot of our time.) It is ! entirely plausable that the "useful stuff" from libg++ might be ! extracted into an updated utilities library, but nobody has stated such a project yet. ! (The [50]Boost site houses free C++ libraries that do varying things, ! and happened to be started by members of the Standards Committee. Certain "useful stuff" classes will probably migrate there.) ! For the bold and/or desperate, the [51]GCC FAQ describes where to find the last libg++ source. _________________________________________________________________ *************** *** 168,227 **** If you have read the README and RELEASE-NOTES files, and your question remains unanswered, then just ask the mailing list. At present, you do ! not need to be subscribed to the list to send a message to it. More ! information is available on the homepage (including how to browse the ! list archives); to send to the list, use [50]libstdc++@gcc.gnu.org. ! If you have a question that you think should be included here, or if ! you have a question about a question/answer here, contact [51]Phil ! Edwards or [52]Gabriel Dos Reis. _________________________________________________________________ 2.0 Installation 2.1 How do I install libstdc++-v3? ! Complete instructions are not given here (this is a FAQ, not an installation document), but the tools required are few: ! * A 3.x release of GCC. Note that building GCC is much easier and more automated than building the GCC 2.[78] series was. If you are ! using GCC 2.95, you can still build earlier snapshots of libstdc++. * GNU Make is recommended, but should not be required. * The GNU Autotools are needed if you are messing with the configury or makefiles. ! The file [53]documentation.html provides a good overview of the steps ! necessary to build, install, and use the library. Instructions for ! configuring the library with new flags such as --enable-threads are ! there also, as well as patches and instructions for working with GCC 2.95. ! The top-level install.html and [54]RELEASE-NOTES files contain the ! exact build and installation instructions. You may wish to browse ! those files over CVSweb ahead of time to get a feel for what's ! required. RELEASE-NOTES is located in the ".../docs/17_intro/" directory of the distribution. _________________________________________________________________ 2.2 [removed] ! This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). _________________________________________________________________ 2.3 What is this CVS thing that you keep mentioning? ! The Concurrent Versions System is one of several revision control packages. It was selected for GNU projects because it's free (speech), ! free (beer), and very high quality. The [55]CVS entry in the GNU ! software catalogue has a better description as well as a [56]link to the makers of CVS. The "anonymous client checkout" feature of CVS is similar to anonymous FTP in that it allows anyone to retrieve the latest libstdc++ sources. ! After the first of April, American users will have a "/pharmacy" command-line option... _________________________________________________________________ --- 170,234 ---- If you have read the README and RELEASE-NOTES files, and your question remains unanswered, then just ask the mailing list. At present, you do ! not need to be subscribed to the list to send a message to it. More ! information is available on the homepage (including how to browse the ! list archives); to send to the list, use [52]libstdc++@gcc.gnu.org. ! If you have a question that you think should be included here, or if ! you have a question about a question/answer here, contact [53]Phil ! Edwards or [54]Gabriel Dos Reis. ! _________________________________________________________________ ! ! 1.9 What are the license terms for libstdc++-v3? ! ! See [55]our license description for these and related questions. _________________________________________________________________ 2.0 Installation 2.1 How do I install libstdc++-v3? ! Complete instructions are not given here (this is a FAQ, not an installation document), but the tools required are few: ! * A 3.x release of GCC. Note that building GCC is much easier and more automated than building the GCC 2.[78] series was. If you are ! using GCC 2.95, you can still build earlier snapshots of libstdc++. * GNU Make is recommended, but should not be required. * The GNU Autotools are needed if you are messing with the configury or makefiles. ! The file [56]documentation.html provides a good overview of the steps ! necessary to build, install, and use the library. Instructions for ! configuring the library with new flags such as --enable-threads are ! there also, as well as patches and instructions for working with GCC 2.95. ! The top-level install.html and [57]RELEASE-NOTES files contain the ! exact build and installation instructions. You may wish to browse ! those files over CVSweb ahead of time to get a feel for what's ! required. RELEASE-NOTES is located in the ".../docs/17_intro/" directory of the distribution. _________________________________________________________________ 2.2 [removed] ! This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). _________________________________________________________________ 2.3 What is this CVS thing that you keep mentioning? ! The Concurrent Versions System is one of several revision control packages. It was selected for GNU projects because it's free (speech), ! free (beer), and very high quality. The [58]CVS entry in the GNU ! software catalogue has a better description as well as a [59]link to the makers of CVS. The "anonymous client checkout" feature of CVS is similar to anonymous FTP in that it allows anyone to retrieve the latest libstdc++ sources. ! After the first of April, American users will have a "/pharmacy" command-line option... _________________________________________________________________ *************** *** 230,242 **** libstdc++-v3 comes with its own testsuite. You do not need to actually install the library ("make install") to run the testsuite. ! To run the testsuite on the library after building it, use "make ! check" while in your build directory. To run the testsuite on the ! library after building and installing it, use "make check-install" instead. If you find bugs in the testsuite programs themselves, or if you think ! of a new test program that should be added to the suite, please write up your idea and send it to the list! _________________________________________________________________ --- 237,249 ---- libstdc++-v3 comes with its own testsuite. You do not need to actually install the library ("make install") to run the testsuite. ! To run the testsuite on the library after building it, use "make ! check" while in your build directory. To run the testsuite on the ! library after building and installing it, use "make check-install" instead. If you find bugs in the testsuite programs themselves, or if you think ! of a new test program that should be added to the suite, please write up your idea and send it to the list! _________________________________________________________________ *************** *** 246,291 **** Probably not. Yet. ! Because GCC advances so rapidly, development and testing of libstdc++ ! is being done almost entirely under that compiler. If you are curious ! about whether other, lesser compilers (*grin*) support libstdc++, you ! are more than welcome to try. Configuring and building the library ! (see above) will still require certain tools, however. Also keep in mind that building libstdc++ does not imply that your compiler will be able to use all of the features found in the C++ Standard Library. ! Since the goal of ISO Standardization is for all C++ implementations ! to be able to share code, the final libstdc++ should, in theory, be ! useable under any ISO-compliant compiler. It will still be targeted and optimized for GCC/g++, however. _________________________________________________________________ 3.2 [removed] ! This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). _________________________________________________________________ 3.3 Building DEC OSF kills the assembler ! The atomicity.h header for the Alpha processor currently uses ! pseudo-operators which the DEC assembler doesn't understand (in ! particular, .subsection and .previous). The simple solution is to ! install GNU as and arrange for the GCC build to use it (or merge the sources and build it during the bootstrap). ! Anyone who [57]knows the DEC assembler well enough to provide the ! equivalent of these two pseudos would win praise and accolades from many. _________________________________________________________________ 4.0 Known Bugs and Non-Bugs ! Note that this section can get rapdily outdated -- such is the nature ! of an open-source project. For the latest information, join the ! mailing list or look through recent archives. The RELEASE- NOTES and BUGS files are generally kept up-to-date. 4.1 What works already? This is a verbatim clip from the "Status" section of the RELEASE-NOTES --- 253,314 ---- Probably not. Yet. ! Because GCC advances so rapidly, development and testing of libstdc++ ! is being done almost entirely under that compiler. If you are curious ! about whether other, lesser compilers (*grin*) support libstdc++, you ! are more than welcome to try. Configuring and building the library ! (see above) will still require certain tools, however. Also keep in mind that building libstdc++ does not imply that your compiler will be able to use all of the features found in the C++ Standard Library. ! Since the goal of ISO Standardization is for all C++ implementations ! to be able to share code, the final libstdc++ should, in theory, be ! useable under any ISO-compliant compiler. It will still be targeted and optimized for GCC/g++, however. _________________________________________________________________ 3.2 [removed] ! This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). _________________________________________________________________ 3.3 Building DEC OSF kills the assembler ! The atomicity.h header for the Alpha processor currently uses ! pseudo-operators which the DEC assembler doesn't understand (in ! particular, .subsection and .previous). The simple solution is to ! install GNU as and arrange for the GCC build to use it (or merge the sources and build it during the bootstrap). ! Anyone who [60]knows the DEC assembler well enough to provide the ! equivalent of these two pseudos would win praise and accolades from many. _________________________________________________________________ 4.0 Known Bugs and Non-Bugs ! Note that this section can get rapdily outdated -- such is the nature ! of an open-source project. For the latest information, join the ! mailing list or look through recent archives. The RELEASE- NOTES and BUGS files are generally kept up-to-date. + For 3.0.1, the most common "bug" is an apparently missing "../" in + include/Makefile, resulting in files like gthr.h and gthr-single.h not + being found. + + Please read [61]the configuration instructions for GCC, specifically + the part about configuring in a separate build directory, and how + strongly recommended it is. Building in the source directory is + fragile, is rarely tested, and tends to break, as in this case. Work + has already gone into the source tree to make this less painful for + the next release. + + Please do not report this as a bug. We know about it. Reporting this + -- or any other problem that's already been fixed -- hinders the + development of GCC, because we have to take time to respond to your + report. Thank you. + 4.1 What works already? This is a verbatim clip from the "Status" section of the RELEASE-NOTES *************** New: *** 317,324 **** 4.2 Bugs in gcc/g++ (not libstdc++-v3) ! This is by no means meant to be complete nor exhaustive, but mentions ! some problems that users may encounter when building or using libstdc++. If you are experiencing one of these problems, you can find more information on the libstdc++ and the GCC mailing lists. * As of 2.91, these bugs have all been fixed. We look forward to new --- 340,347 ---- 4.2 Bugs in gcc/g++ (not libstdc++-v3) ! This is by no means meant to be complete nor exhaustive, but mentions ! some problems that users may encounter when building or using libstdc++. If you are experiencing one of these problems, you can find more information on the libstdc++ and the GCC mailing lists. * As of 2.91, these bugs have all been fixed. We look forward to new *************** New: *** 327,381 **** 4.3 Bugs in the C++ language/lib specification ! Yes, unfortunately, there are some. In a [58]message to the list, ! Nathan Myers announced that he has started a list of problems in the ! ISO C++ Standard itself, especially with regard to the chapters that ! concern the library. The list itself is [59]posted on his website. ! Developers who are having problems interpreting the Standard may wish to consult his notes. ! For those people who are not part of the ISO Library Group (i.e., ! nearly all of us needing to read this page in the first place :-), a ! public list of the library defects is occasionally published [60]here. _________________________________________________________________ 4.4 Things in libstdc++ that look like bugs ! There are things which are not bugs in the compiler (4.2) nor the ! language specification (4.3), but aren't really bugs in libstdc++, either. Really! Please do not report these as bugs. ! -Weffc++ The biggest of these is the quadzillions of warnings about ! the library headers emitted when -Weffc++ is used. Making libstdc++ ! "-Weffc++-clean" is not a goal of the project, for a few reasons. ! Mainly, that option tries to enforce object-oriented programming, ! while the Standard Library isn't necessarily trying to be OO. There are multiple solutions under discussion. ! rel_ops Another is the rel_ops namespace and the template comparison ! operator functions contained therein. If they become visible in the ! same namespace as other comparison functions (e.g., 'using' them and ! the header), then you will suddenly be faced with huge ! numbers of ambiguity errors. This was discussed on the -v3 list; ! Nathan Myers [61]sums things up here. The g++-3 headers are not ours ! If you have found an extremely broken header file which is causing ! problems for you, look carefully before submitting a "high" priority ! bug report (which you probably shouldn't do anyhow; see the last ! paragraph of the page describing [62]the GCC bug database). ! If the headers are in ${prefix}/include/g++-3, then you are using the ! old libstdc++-v2 library, which is nonstandard and unmaintained. Do not report problems with -v2 to the -v3 mailing list. ! Currently our header files are installed in ${prefix}/include/g++-v3 ! (see the 'v'?). This may change with the next release of GCC, as it ! may be too confusing, but [63]the question has not yet been decided. ! glibc If you're on a GNU/Linux system and have just upgraded to glibc ! 2.2, but are still using gcc 2.95.2, then you should have read the glibc FAQ, specifically 2.34: 2.34. When compiling C++ programs, I get a compilation error in streambuf.h. --- 350,427 ---- 4.3 Bugs in the C++ language/lib specification ! Yes, unfortunately, there are some. In a [62]message to the list, ! Nathan Myers announced that he has started a list of problems in the ! ISO C++ Standard itself, especially with regard to the chapters that ! concern the library. The list itself is [63]posted on his website. ! Developers who are having problems interpreting the Standard may wish to consult his notes. ! For those people who are not part of the ISO Library Group (i.e., ! nearly all of us needing to read this page in the first place :-), a ! public list of the library defects is occasionally published [64]here. ! Some of these have resulted in [65]code changes. _________________________________________________________________ 4.4 Things in libstdc++ that look like bugs ! There are things which are not bugs in the compiler (4.2) nor the ! language specification (4.3), but aren't really bugs in libstdc++, either. Really! Please do not report these as bugs. ! -Weffc++ The biggest of these is the quadzillions of warnings about ! the library headers emitted when -Weffc++ is used. Making libstdc++ ! "-Weffc++-clean" is not a goal of the project, for a few reasons. ! Mainly, that option tries to enforce object-oriented programming, ! while the Standard Library isn't necessarily trying to be OO. There are multiple solutions under discussion. ! reopening a stream fails Did I just say that -Weffc++ was our biggest ! false-bug report? I lied. (It used to be.) Today it seems to be ! reports that after executing a sequence like ! #include ! ... ! std::fstream fs("a_file"); ! // . ! // . do things with fs... ! // . ! fs.close(); ! fs.open("a_new_file"); ! ! all operations on the re-opened fs will fail, or at least act very ! strangely. Yes, they often will, especially if fs reached the EOF ! state on the previous file. The reason is that the state flags are not ! cleared on a successful call to open(). The standard unfortunately did ! not specify behavior in this case, and to everybody's great sorrow, ! the [66]proposed LWG resolution (see DR #22) is to leave the flags ! unchanged. You must insert a call to fs.clear() between the calls to ! close() and open(), and then everything will work like we all expect ! it to work. ! ! rel_ops Another is the rel_ops namespace and the template comparison ! operator functions contained therein. If they become visible in the ! same namespace as other comparison functions (e.g., 'using' them and ! the header), then you will suddenly be faced with huge ! numbers of ambiguity errors. This was discussed on the -v3 list; ! Nathan Myers [67]sums things up here. The g++-3 headers are not ours ! If you have found an extremely broken header file which is causing ! problems for you, look carefully before submitting a "high" priority ! bug report (which you probably shouldn't do anyhow; see the last ! paragraph of the page describing [68]the GCC bug database). ! If the headers are in ${prefix}/include/g++-3, then you are using the ! old libstdc++-v2 library, which is nonstandard and unmaintained. Do not report problems with -v2 to the -v3 mailing list. ! Currently our header files are installed in ${prefix}/include/g++-v3 ! (see the 'v'?). This may change with the next release of GCC, as it ! may be too confusing, but [69]the question has not yet been decided. ! glibc If you're on a GNU/Linux system and have just upgraded to glibc ! 2.2, but are still using gcc 2.95.2, then you should have read the glibc FAQ, specifically 2.34: 2.34. When compiling C++ programs, I get a compilation error in streambuf.h. *************** type has changed in glibc 2.2. The patc *** 385,420 **** http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff ! Note that 2.95.x shipped with the [64]old v2 library which is no ! longer maintained. Also note that gcc 2.95.3 fixes this problem, but requires a separate patch for libstdc++-v3. concept checks If you see compilation errors containing messages about ! fooConcept and a constraints member function, then most likely you ! have violated one of the requirements for types used during ! instantiation of template containers and functions. For example, ! EqualityComparableConcept appears if your types must be comparable ! with == and you have not provided this capability (a typo, or wrong visibility, or you just plain forgot, etc). ! More information, including how to optionally enable/disable the ! checks, is available [65]here. _________________________________________________________________ 4.5 Aw, that's easy to fix! ! If you have found a bug in the library and you think you have a ! working fix, then send it in! The main GCC site has a page on ! [66]submitting patches that covers the procedure, but for libstdc++ ! you should also send the patch to our mailing list in addition to the ! GCC patches mailing list. The libstdc++ [67]contributors' page also talks about how to submit patches. In addition to the description, the patch, and the ChangeLog entry, it is a Good Thing if you can additionally create a small test program to ! test for the presence of the bug that your patch fixes. Bugs have a ! way of being reintroduced; if an old bug creeps back in, it will be ! caught immediately by the [68]testsuite -- but only if such a test exists. _________________________________________________________________ --- 431,466 ---- http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff ! Note that 2.95.x shipped with the [70]old v2 library which is no ! longer maintained. Also note that gcc 2.95.3 fixes this problem, but requires a separate patch for libstdc++-v3. concept checks If you see compilation errors containing messages about ! fooConcept and a constraints member function, then most likely you ! have violated one of the requirements for types used during ! instantiation of template containers and functions. For example, ! EqualityComparableConcept appears if your types must be comparable ! with == and you have not provided this capability (a typo, or wrong visibility, or you just plain forgot, etc). ! More information, including how to optionally enable/disable the ! checks, is available [71]here. _________________________________________________________________ 4.5 Aw, that's easy to fix! ! If you have found a bug in the library and you think you have a ! working fix, then send it in! The main GCC site has a page on ! [72]submitting patches that covers the procedure, but for libstdc++ ! you should also send the patch to our mailing list in addition to the ! GCC patches mailing list. The libstdc++ [73]contributors' page also talks about how to submit patches. In addition to the description, the patch, and the ChangeLog entry, it is a Good Thing if you can additionally create a small test program to ! test for the presence of the bug that your patch fixes. Bugs have a ! way of being reintroduced; if an old bug creeps back in, it will be ! caught immediately by the [74]testsuite -- but only if such a test exists. _________________________________________________________________ *************** http://clisp.cons.org/~haible/gccinclude *** 422,481 **** 5.1 string::iterator is not char*; vector::iterator is not T* ! If you have code that depends on container iterators being implemented as pointer-to-T, your code is broken. ! While there are arguments for iterators to be implemented in that ! manner, A) they aren't very good ones in the long term, and B) they were never guaranteed by the Standard anyway. The type-safety achieved ! by making iterators a real class rather than a typedef for T* outweighs nearly all opposing arguments. Code which does assume that a vector iterator i is a pointer can often ! be fixed by changing i in certain expressions to &*i . Future ! revisions of the Standard are expected to bless this usage for vector<> (but not for basic_string<>). _________________________________________________________________ 5.2 What's next after libstdc++-v3? ! Hopefully, not much. The goal of libstdc++-v3 is to produce a ! fully-compliant, fully-portable Standard Library. After that, we're mostly done: there won't be any more compliance work to do. However: ! 1. The ISO Committee will meet periodically to review Defect Reports ! in the C++ Standard. Undoubtedly some of these will result in ! changes to the Standard, which will be reflected in patches to ! libstdc++. Some of that is already happening, see 4.2. Some of ! those changes are being predicted by the library maintainers, and ! we add code to the library based on what the current proposed ! resolution specifies. ! 2. Performance tuning. Lots of performance tuning. This too is ! already underway for post-3.0 releases, starting with memory ! expansion in container classes and buffer usage in synchronized stream objects. ! 3. An ABI for libstdc++ will eventually be developed, so that multiple binary-incompatible copies of the library can be replaced with a single backwards-compatible library, like libgcc_s.so is. ! 4. The current libstdc++ contains extensions to the Library which must be explicitly requested by client code (for example, the hash tables from SGI). Other extensions may be added to libstdc++-v3 if ! they seem to be "standard" enough. (For example, the "long long" ! type from C99.) Bugfixes and rewrites (to improve or fix thread safety, for instance) will of course be a continuing task. ! [69]This question about the next libstdc++ prompted some brief but ! interesting [70]speculation. _________________________________________________________________ 5.3 What about the STL from SGI? ! The [71]STL from SGI, version 3.3, was the most recent merge of the ! STL codebase. The code in libstdc++ contains many fixes and changes, ! and it is very likely that the SGI code is no longer under active development. We expect that no future merges will take place. In particular, string is not from SGI and makes no use of their "rope" ! class (which is included as an optional extension), nor is valarray and some others. Classes like vector<> are, however. The FAQ for SGI's STL (one jump off of their main page) is recommended --- 468,528 ---- 5.1 string::iterator is not char*; vector::iterator is not T* ! If you have code that depends on container iterators being implemented as pointer-to-T, your code is broken. ! While there are arguments for iterators to be implemented in that ! manner, A) they aren't very good ones in the long term, and B) they were never guaranteed by the Standard anyway. The type-safety achieved ! by making iterators a real class rather than a typedef for T* outweighs nearly all opposing arguments. Code which does assume that a vector iterator i is a pointer can often ! be fixed by changing i in certain expressions to &*i . Future ! revisions of the Standard are expected to bless this usage for vector<> (but not for basic_string<>). _________________________________________________________________ 5.2 What's next after libstdc++-v3? ! Hopefully, not much. The goal of libstdc++-v3 is to produce a ! fully-compliant, fully-portable Standard Library. After that, we're mostly done: there won't be any more compliance work to do. However: ! 1. The ISO Committee will meet periodically to review Defect Reports ! in the C++ Standard. Undoubtedly some of these will result in ! changes to the Standard, which will be reflected in patches to ! libstdc++. Some of that is already happening, see 4.2. Some of ! those changes are being predicted by the library maintainers, and ! we add code to the library based on what the current proposed ! resolution specifies. Those additions are listed in [75]the ! extensions page. ! 2. Performance tuning. Lots of performance tuning. This too is ! already underway for post-3.0 releases, starting with memory ! expansion in container classes and buffer usage in synchronized stream objects. ! 3. An ABI for libstdc++ will eventually be developed, so that multiple binary-incompatible copies of the library can be replaced with a single backwards-compatible library, like libgcc_s.so is. ! 4. The current libstdc++ contains extensions to the Library which must be explicitly requested by client code (for example, the hash tables from SGI). Other extensions may be added to libstdc++-v3 if ! they seem to be "standard" enough. (For example, the "long long" ! type from C99.) Bugfixes and rewrites (to improve or fix thread safety, for instance) will of course be a continuing task. ! [76]This question about the next libstdc++ prompted some brief but ! interesting [77]speculation. _________________________________________________________________ 5.3 What about the STL from SGI? ! The [78]STL from SGI, version 3.3, was the most recent merge of the ! STL codebase. The code in libstdc++ contains many fixes and changes, ! and it is very likely that the SGI code is no longer under active development. We expect that no future merges will take place. In particular, string is not from SGI and makes no use of their "rope" ! class (which is included as an optional extension), nor is valarray and some others. Classes like vector<> are, however. The FAQ for SGI's STL (one jump off of their main page) is recommended *************** http://clisp.cons.org/~haible/gccinclude *** 484,535 **** 5.4 Extensions and Backward Compatibility ! Although you can specify -I options to make the preprocessor search ! the g++-v3/ext and /backward directories, it is better to refer to files there by their path, as in: #include ! Extensions to the library have [72]their own page. _________________________________________________________________ 5.5 [removed] ! This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). _________________________________________________________________ 5.6 Is libstdc++-v3 thread-safe? ! Quick answer: no, as of 2.92 (eleventh snapshot), the library is not ! appropriate for multithreaded access. The string class is MT-safe. ! This is assuming that your idea of "multithreaded" is the same as ! ours... The general question of multithreading and libstdc++-v3 is ! addressed in the chapter-specific advice for [73]Library Introduction. ! Threadsafe containers are covered in more detail in [74]the Received ! Wisdom section on containers. _________________________________________________________________ 5.7 How do I get a copy of the ISO C++ Standard? ! Copies of the full ISO 14882 standard are available on line via the ! ISO mirror site for committee members. Non-members, or those who have ! not paid for the privilege of sitting on the committee and sustained ! their two-meeting commitment for voting rights, may get a copy of the standard from their respective national standards organization. In the USA, this national standards organization is ANSI and their website is ! right [75]here. (And if you've already registered with them, clicking ! this link will take you to directly to the place where you can [76]buy the standard on-line. ! Who is your country's member body? Visit the [77]ISO homepage and find out! _________________________________________________________________ ! Comments and suggestions are welcome, and may be sent to [78]the ! mailing list. ! $Id: index.txt,v 1.2.4.5 2001/07/18 21:39:58 pme Exp $ References --- 531,612 ---- 5.4 Extensions and Backward Compatibility ! Although you can specify -I options to make the preprocessor search ! the g++-v3/ext and /backward directories, it is better to refer to files there by their path, as in: #include ! Extensions to the library have [79]their own page. _________________________________________________________________ 5.5 [removed] ! This question has become moot and has been removed. The stub is here to preserve numbering (and hence links/bookmarks). _________________________________________________________________ 5.6 Is libstdc++-v3 thread-safe? ! When the system's libc is itself thread-safe, a non-generic ! implementation of atomicity.h exists for the architecture, and gcc ! itself reports a thread model other than single; libstdc++-v3 strives ! to be thread-safe. The user-code must guard against concurrent method ! calls which may access any particular library object's state. ! Typically, the application programmer may infer what object locks must ! be held based on the objects referenced in a method call. Without ! getting into great detail, here is an example which requires ! user-level locks: ! library_class_a shared_object_a; ! thread_main () { ! library_class_b *object_b = new library_class_b; ! shared_object_a.add_b (object_b); // must hold lock for shared_object_ ! a ! shared_object_a.mutate (); // must hold lock for shared_object_ ! a ! } ! ! // Multiple copies of thread_main() are started in independent threads. ! ! Under the assumption that object_a and object_b are never exposed to ! another thread, here is an example that should not require any ! user-level locks: ! thread_main () { ! library_class_a object_a; ! library_class_b *object_b = new library_class_b; ! object_a.add_b (object_b); ! object_a.mutate (); ! } ! ! All library objects are safe to use in a multithreaded program as long ! as each thread carefully locks out access by any other thread while it ! uses any object visible to another thread. This requirement includes ! both read and write access to objects; do not assume that two threads ! may read a shared standard container at the same time. ! ! See chapters [80]17 (library introduction), [81]23 (containers), and ! [82]27 (I/O) for more information. _________________________________________________________________ 5.7 How do I get a copy of the ISO C++ Standard? ! Copies of the full ISO 14882 standard are available on line via the ! ISO mirror site for committee members. Non-members, or those who have ! not paid for the privilege of sitting on the committee and sustained ! their two-meeting commitment for voting rights, may get a copy of the standard from their respective national standards organization. In the USA, this national standards organization is ANSI and their website is ! right [83]here. (And if you've already registered with them, clicking ! this link will take you to directly to the place where you can [84]buy the standard on-line. ! Who is your country's member body? Visit the [85]ISO homepage and find out! _________________________________________________________________ ! See [86]license.html for copying conditions. Comments and suggestions ! are welcome, and may be sent to [87]the libstdc++ mailing list. References *************** References *** 544,613 **** 9. ../faq/index.html#1_6 10. ../faq/index.html#1_7 11. ../faq/index.html#1_8 ! 12. ../faq/index.html#2_0 ! 13. ../faq/index.html#2_1 ! 14. ../faq/index.html#2_2 ! 15. ../faq/index.html#2_3 ! 16. ../faq/index.html#2_4 ! 17. ../faq/index.html#3_0 ! 18. ../faq/index.html#3_1 ! 19. ../faq/index.html#3_2 ! 20. ../faq/index.html#3_3 ! 21. ../faq/index.html#4_0 ! 22. ../faq/index.html#4_1 ! 23. ../faq/index.html#4_2 ! 24. ../faq/index.html#4_3 ! 25. ../faq/index.html#4_4 ! 26. ../faq/index.html#4_4_Weff ! 27. ../faq/index.html#4_4_rel_ops ! 28. ../faq/index.html#4_4_interface ! 29. ../faq/index.html#4_4_glibc ! 30. ../faq/index.html#4_4_checks ! 31. ../faq/index.html#4_5 ! 32. ../faq/index.html#5_0 ! 33. ../faq/index.html#5_1 ! 34. ../faq/index.html#5_2 ! 35. ../faq/index.html#5_3 ! 36. ../faq/index.html#5_4 ! 37. ../faq/index.html#5_5 ! 38. ../faq/index.html#5_6 ! 39. ../faq/index.html#5_7 ! 40. ftp://gcc.gnu.org/pub/libstdc++/libstdc++-2.92.tar.gz ! 41. ../17_intro/DESIGN ! 42. http://gcc.gnu.org/ ! 43. http://gcc.gnu.org/gcc-2.95/buildstat.html ! 44. http://gcc.gnu.org/libstdc++/ ! 45. ftp://gcc.gnu.org/pub/libstdc++/libstdc++-2.92.tar.gz 46. http://gcc.gnu.org/libstdc++/ ! 47. ../17_intro/contribute.html ! 48. http://www.boost.org/ ! 49. http://gcc.gnu.org/fom_serv/cache/33.html ! 50. mailto:libstdc++@gcc.gnu.org ! 51. mailto:pme@gcc.gnu.org ! 52. mailto:gdr@gcc.gnu.org ! 53. ../documentation.html ! 54. ../17_intro/RELEASE-NOTES ! 55. http://www.gnu.org/software/cvs/cvs.html ! 56. http://www.cvshome.org/ ! 57. http://gcc.gnu.org/ml/libstdc++/2000-12/msg00279.html ! 58. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html ! 59. http://www.cantrip.org/draft-bugs.txt ! 60. http://anubis.dkuug.dk/jtc1/sc22/wg21/ ! 61. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html ! 62. http://gcc.gnu.org/gnatswrite.html ! 63. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html ! 64. ../faq/index.html#4_4_interface ! 65. ../19_diagnostics/howto.html#3 ! 66. http://gcc.gnu.org/contribute.html ! 67. ../17_intro/contribute.html ! 68. ../faq/index.html#2_4 ! 69. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html ! 70. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html ! 71. http://www.sgi.com/Technology/STL/ ! 72. ../ext/howto.html ! 73. http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/howto.html#3 ! 74. http://gcc.gnu.org/onlinedocs/libstdc++/23_containers/howto.html ! 75. http://www.ansi.org/ ! 76. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998 ! 77. http://www.iso.ch/ ! 78. mailto:libstdc++@gcc.gnu.org --- 621,699 ---- 9. ../faq/index.html#1_6 10. ../faq/index.html#1_7 11. ../faq/index.html#1_8 ! 12. ../faq/index.html#1_9 ! 13. ../faq/index.html#2_0 ! 14. ../faq/index.html#2_1 ! 15. ../faq/index.html#2_2 ! 16. ../faq/index.html#2_3 ! 17. ../faq/index.html#2_4 ! 18. ../faq/index.html#3_0 ! 19. ../faq/index.html#3_1 ! 20. ../faq/index.html#3_2 ! 21. ../faq/index.html#3_3 ! 22. ../faq/index.html#4_0 ! 23. ../faq/index.html#4_1 ! 24. ../faq/index.html#4_2 ! 25. ../faq/index.html#4_3 ! 26. ../faq/index.html#4_4 ! 27. ../faq/index.html#4_4_iostreamclear ! 28. ../faq/index.html#4_4_Weff ! 29. ../faq/index.html#4_4_rel_ops ! 30. ../faq/index.html#4_4_interface ! 31. ../faq/index.html#4_4_glibc ! 32. ../faq/index.html#4_4_checks ! 33. ../faq/index.html#4_5 ! 34. ../faq/index.html#5_0 ! 35. ../faq/index.html#5_1 ! 36. ../faq/index.html#5_2 ! 37. ../faq/index.html#5_3 ! 38. ../faq/index.html#5_4 ! 39. ../faq/index.html#5_5 ! 40. ../faq/index.html#5_6 ! 41. ../faq/index.html#5_7 ! 42. http://gcc.gnu.org/libstdc++/download.html ! 43. ../17_intro/DESIGN ! 44. http://gcc.gnu.org/ ! 45. http://gcc.gnu.org/gcc-2.95/buildstat.html 46. http://gcc.gnu.org/libstdc++/ ! 47. http://gcc.gnu.org/libstdc++/download.html ! 48. http://gcc.gnu.org/libstdc++/ ! 49. ../17_intro/contribute.html ! 50. http://www.boost.org/ ! 51. http://gcc.gnu.org/fom_serv/cache/33.html ! 52. mailto:libstdc++@gcc.gnu.org ! 53. mailto:pme@gcc.gnu.org ! 54. mailto:gdr@gcc.gnu.org ! 55. ../17_intro/license.html ! 56. ../documentation.html ! 57. ../17_intro/RELEASE-NOTES ! 58. http://www.gnu.org/software/cvs/cvs.html ! 59. http://www.cvshome.org/ ! 60. http://gcc.gnu.org/ml/libstdc++/2000-12/msg00279.html ! 61. http://gcc.gnu.org/install/configure.html ! 62. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html ! 63. http://www.cantrip.org/draft-bugs.txt ! 64. http://anubis.dkuug.dk/jtc1/sc22/wg21/ ! 65. ../faq/index.html#5_2 ! 66. ../ext/howto.html#5 ! 67. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html ! 68. http://gcc.gnu.org/gnatswrite.html ! 69. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html ! 70. ../faq/index.html#4_4_interface ! 71. ../19_diagnostics/howto.html#3 ! 72. http://gcc.gnu.org/contribute.html ! 73. ../17_intro/contribute.html ! 74. ../faq/index.html#2_4 ! 75. ../ext/howto.html#5 ! 76. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html ! 77. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html ! 78. http://www.sgi.com/Technology/STL/ ! 79. ../ext/howto.html ! 80. ../17_intro/howto.html#3 ! 81. ../23_containers/howto.html#3 ! 82. ../27_io/howto.html#9 ! 83. http://www.ansi.org/ ! 84. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998 ! 85. http://www.iso.ch/ ! 86. ../17_intro/license.html ! 87. mailto:libstdc++@gcc.gnu.org diff -Nrc3pad gcc-3.0.1/libstdc++-v3/docs/html/install.html gcc-3.0.2/libstdc++-v3/docs/html/install.html *** gcc-3.0.1/libstdc++-v3/docs/html/install.html Wed May 30 14:59:30 2001 --- gcc-3.0.2/libstdc++-v3/docs/html/install.html Fri Oct 19 13:07:34 2001 *************** *** 1,53 **** ! ! ! ! ! ! ! libstdc++-v3 Installation Instructions ! ! ! ! !

        libstdc++-v3 INSTALL

        !

        The latest version of this document is always available at ! ! http://gcc.gnu.org/onlinedocs/libstdc++/install.html. !

        !

        To the libstdc++-v3 homepage. !


        !

        Contents

        ! !
        !

        Tools you will need beforehand

        !

        You will need a recent version of g++ to compile the snapshot of libstdc++, such as one of the GCC 3.x snapshots (insert standard caveat about using snapshots rather than formal releases). You will need the full source distribution to whatever compiler release you are using. The GCC snapshots can be had from one of the sites on their ! mirror list. !

        !

        In addition, if you plan to modify the makefiles or regenerate the configure scripts you'll need recent versions of the GNU Autotools: autoconf (version 2.50 or later), automake (version 1.4 or later), --- 1,52 ---- ! ! ! ! ! ! ! libstdc++-v3 Installation Instructions ! ! ! !

        libstdc++-v3 INSTALL

        !

        The latest version of this document is always available at ! ! http://gcc.gnu.org/onlinedocs/libstdc++/install.html. !

        !

        To the libstdc++-v3 homepage. !


        !

        Contents

        ! !
        !

        Tools you will need beforehand

        !

        You will need a recent version of g++ to compile the snapshot of libstdc++, such as one of the GCC 3.x snapshots (insert standard caveat about using snapshots rather than formal releases). You will need the full source distribution to whatever compiler release you are using. The GCC snapshots can be had from one of the sites on their ! mirror list. !

        !

        In addition, if you plan to modify the makefiles or regenerate the configure scripts you'll need recent versions of the GNU Autotools: autoconf (version 2.50 or later), automake (version 1.4 or later), *************** *** 56,293 **** These tools are all required to be installed in the same location (most linux distributions install these tools by default, so no worries as long as the versions are correct). !

        !

        GNU Make is the only 'make' that will parse the makefiles correctly. !

        !

        To test your build, you will need either DejaGNU 1.4 (to run ! 'make check' like ! the rest of GCC), ! or Bash 2.x (to run 'make check-script'). !

        !

        As of June 19, 2000, libstdc++ attempts to use tricky and space-saving features of the GNU toolchain, enabled with ! -ffunction-sections -fdata-sections -Wl,--gc-sections. To obtain maximum benefit from this, binutils after this date should also be used (bugs were fixed with C++ exception handling related to this change in libstdc++-v3). The version of these ! tools should be 2.10.90, and you can get snapshots (as well as releases) of binutils ! here. !

        !
        !

        Setting up the source directories

        !

        The following definitions will be used throughout the rest of this document: !

          !
        • gccsrcdir: The directory holding the source of the compiler. It should have several subdirectories like ! gccsrcdir/libio and gccsrcdir/gcc. !
        • libsrcdir: The directory holding the source of the C++ library. !
        • gccbuilddir: The build directory for the compiler ! in gccsrcdir. GCC requires that it be built in a different directory than its sources. !
        • libbuilddir: The build directory for libstdc++. !
        • destdir: The eventual installation directory for the compiler/libraries, set with the --prefix option to the configure script. !
        Note: !
          !
        1. The 3.0 version and following are intended to replace the ! library that comes with the compiler, so libsrcdir ! and libbuilddir must be contained under ! gccsrcdir and gccbuilddir, respectively. !
        2. The source, build, and installation directories should not be parents of one another; i.e., these should all be separate directories. Please don't build out of the source directory. !
        !

        !

        Check out or download the gcc sources: the resulting source directory ! (gcc or gcc-3.0, for example) is gccsrcdir. ! Once in gccsrcdir, you'll need to rename or delete the libstdc++-v3 directory which comes with that snapshot: !

        !    mv libstdc++-v3 libstdc++-v3-previous  [OR]
        !    rm -r libstdc++-v3
        !

        !

        Next, unpack the libstdc++-v3 library tarball into this ! gccsrcdir directory; it will create a ! libsrcdir called libstdc++-version: !

        !    gzip -dc libstdc++-version.tar.gz | tar xf -
        !

        !

        Finally, rename libsrcdir to libstdc++-v3 so that gcc's configure flags will be able to deal with the new library. !

        !    mv libsrcdir libstdc++-v3
        !

        !
        !

        Configuring

        !

        If you have never done this before, you should read the basic ! GCC Installation ! Instructions first. !

        !

        When building libstdc++-v3 you'll have to configure ! the entire gccsrcdir directory. The full list of libstdc++-v3 specific configuration options, not dependent on the specific compiler ! release being used, can be found here. !

        !

        Consider possibly using --enable-languages=c++ to save time by only building the C++ language parts. !

        !

        !    cd gccbuilddir
        !    gccsrcdir/configure --prefix=destdir --other-opts...
        !

        !
        !

        Building and installing the library

        !

        Now you have a few options:

        !

        [re]building everything

        !

        If you're building GCC from scratch, you can do the usual ! 'make bootstrap' here, and libstdc++-v3 will be built as its default C++ library. The generated g++ will magically use the correct headers, link against the correct library binary, and in general using libstdc++-v3 will be a piece of ! cake. You're done; run 'make install' (see the GCC installation instructions) to put the new compiler and libraries into place. !

        !

        [re]building only libstdc++

        !

        To rebuild just libstdc++, use: !

        !    make all-target-libstdc++-v3
        This will configure and build the C++ library in the ! gccbuilddir/cpu-vendor-os/libstdc++ directory. !

        !

        If you are rebuilding from a previous build [attempt], some information is kept in a cache file. This is stored in ! gccbuilddir/cpu-vendor-os/ if you are building with multilibs (the default), or in ! gccbuilddir/cpu-vendor-os/libstdc++-v3 if you have multilibs disabled. The filename is config.cache; if previous information is causing problems, you can delete it entirely, or simply edit it and remove lines. !

        !

        You're done. Now install the rebuilt pieces with !

        !    make install
        or !
             make install-gcc
        !    make install-target-libstdc++-v3
        !

        !
        !

        Post-installation

        !

        Installation will create the destdir directory and populate it with subdirectories: !

             lib/
             include/g++-v3/
                backward/
                bits/
        !       cpu-vendor-os/bits/
        !       ext/
        !

        !

        You can check the status of the build without installing it using !

        !    make check
        or you can check the status of the installed library using !
        !    make check-install
        ! in the libbuilddir directory. These commands will create a 'testsuite' directory underneath ! libbuilddir containing the results of the tests. We are interested in any strange failures of the testsuite; please see ! FAQ 2.4 for which files to examine. !

        !
        !

        Using the library

        !
      • Find the new library at runtime (shared linking only) !

        If you only built a static library (libstdc++.a), or if you specified static linking, you don't have to worry about this. But if you built a shared library (libstdc++.so) and linked against it, then you will need to find that library when you run the executable. !

        !

        Methods vary for different platforms and different styles, but the usual ones are printed to the screen during installation. They include: !

          !
        • At runtime set LD_LIBRARY_PATH in your environment correctly, so that the shared library for libstdc++ can be found and loaded. Be certain that you understand all of the other implications and behavior of LD_LIBRARY_PATH first (few people do, and they get into trouble). !
        • Compile the path to find the library at runtime into the program. This can be done by passing certain options to g++, which will in turn pass them on to the linker. The exact format of the options is dependent on which linker you use: !
            !
          • GNU ld (default on Linux): -Wl,--rpath,destdir/lib !
          • IRIX ld: -Wl,-rpath,destdir/lib !
          • Solaris ld: -Wl,-Rdestdir/lib !
          • More...? !
          !
        !

        !

        Use the ldd(1) utility to show which library the system thinks it will get at runtime. !

        !

        A libstdc++.la file is also installed, for use with Libtool. If you use Libtool to create your executables, these details are taken care of for you. !

        ! !

        !
        !

        Comments and suggestions are welcome, and may be sent to ! the mailing list. !
        $Id: install.html,v 1.4.2.2 2001/05/30 21:59:30 pme Exp $ !

        ! ! --- 55,292 ---- These tools are all required to be installed in the same location (most linux distributions install these tools by default, so no worries as long as the versions are correct). !

        !

        GNU Make is the only 'make' that will parse the makefiles correctly. !

        !

        To test your build, you will need either DejaGNU 1.4 (to run ! 'make check' like ! the rest of GCC), ! or Bash 2.x (to run 'make check-script'). !

        !

        As of June 19, 2000, libstdc++ attempts to use tricky and space-saving features of the GNU toolchain, enabled with ! -ffunction-sections -fdata-sections -Wl,--gc-sections. To obtain maximum benefit from this, binutils after this date should also be used (bugs were fixed with C++ exception handling related to this change in libstdc++-v3). The version of these ! tools should be 2.10.90, and you can get snapshots (as well as releases) of binutils ! here. !

        !
        !

        Setting up the source directories

        !

        The following definitions will be used throughout the rest of this document: !

          !
        • gccsrcdir: The directory holding the source of the compiler. It should have several subdirectories like ! gccsrcdir/libio and gccsrcdir/gcc. !
        • libsrcdir: The directory holding the source of the C++ library. !
        • gccbuilddir: The build directory for the compiler ! in gccsrcdir. GCC requires that it be built in a different directory than its sources. !
        • libbuilddir: The build directory for libstdc++. !
        • destdir: The eventual installation directory for the compiler/libraries, set with the --prefix option to the configure script. !
        Note: !
          !
        1. The 3.0 version and following are intended to replace the ! library that comes with the compiler, so libsrcdir ! and libbuilddir must be contained under ! gccsrcdir and gccbuilddir, respectively. !
        2. The source, build, and installation directories should not be parents of one another; i.e., these should all be separate directories. Please don't build out of the source directory. !
        !

        !

        Check out or download the gcc sources: the resulting source directory ! (gcc or gcc-3.0, for example) is gccsrcdir. ! Once in gccsrcdir, you'll need to rename or delete the libstdc++-v3 directory which comes with that snapshot: !

        !    mv libstdc++-v3 libstdc++-v3-previous  [OR]
        !    rm -r libstdc++-v3
        !

        !

        Next, unpack the libstdc++-v3 library tarball into this ! gccsrcdir directory; it will create a ! libsrcdir called libstdc++-version: !

        !    gzip -dc libstdc++-version.tar.gz | tar xf -
        !

        !

        Finally, rename libsrcdir to libstdc++-v3 so that gcc's configure flags will be able to deal with the new library. !

        !    mv libsrcdir libstdc++-v3
        !

        !
        !

        Configuring

        !

        If you have never done this before, you should read the basic ! GCC Installation ! Instructions first. !

        !

        When building libstdc++-v3 you'll have to configure ! the entire gccsrcdir directory. The full list of libstdc++-v3 specific configuration options, not dependent on the specific compiler ! release being used, can be found here. !

        !

        Consider possibly using --enable-languages=c++ to save time by only building the C++ language parts. !

        !

        !    cd gccbuilddir
        !    gccsrcdir/configure --prefix=destdir --other-opts...
        !

        !
        !

        Building and installing the library

        !

        Now you have a few options:

        !

        [re]building everything

        !

        If you're building GCC from scratch, you can do the usual ! 'make bootstrap' here, and libstdc++-v3 will be built as its default C++ library. The generated g++ will magically use the correct headers, link against the correct library binary, and in general using libstdc++-v3 will be a piece of ! cake. You're done; run 'make install' (see the GCC installation instructions) to put the new compiler and libraries into place. !

        !

        [re]building only libstdc++

        !

        To rebuild just libstdc++, use: !

        !    make all-target-libstdc++-v3
        This will configure and build the C++ library in the ! gccbuilddir/cpu-vendor-os/libstdc++ directory. !

        !

        If you are rebuilding from a previous build [attempt], some information is kept in a cache file. This is stored in ! gccbuilddir/cpu-vendor-os/ if you are building with multilibs (the default), or in ! gccbuilddir/cpu-vendor-os/libstdc++-v3 if you have multilibs disabled. The filename is config.cache; if previous information is causing problems, you can delete it entirely, or simply edit it and remove lines. !

        !

        You're done. Now install the rebuilt pieces with !

        !    make install
        or !
             make install-gcc
        !    make install-target-libstdc++-v3
        !

        !
        !

        Post-installation

        !

        Installation will create the destdir directory and populate it with subdirectories: !

             lib/
             include/g++-v3/
                backward/
                bits/
        !       cpu-vendor-os/bits/
        !       ext/
        !

        !

        You can check the status of the build without installing it using !

        !    make check
        or you can check the status of the installed library using !
        !    make check-install
        ! in the libbuilddir directory. These commands will create a 'testsuite' directory underneath ! libbuilddir containing the results of the tests. We are interested in any strange failures of the testsuite; please see ! FAQ 2.4 for which files to examine. !

        !
        !

        Using the library

        !
      • Find the new library at runtime (shared linking only) !

        If you only built a static library (libstdc++.a), or if you specified static linking, you don't have to worry about this. But if you built a shared library (libstdc++.so) and linked against it, then you will need to find that library when you run the executable. !

        !

        Methods vary for different platforms and different styles, but the usual ones are printed to the screen during installation. They include: !

          !
        • At runtime set LD_LIBRARY_PATH in your environment correctly, so that the shared library for libstdc++ can be found and loaded. Be certain that you understand all of the other implications and behavior of LD_LIBRARY_PATH first (few people do, and they get into trouble). !
        • Compile the path to find the library at runtime into the program. This can be done by passing certain options to g++, which will in turn pass them on to the linker. The exact format of the options is dependent on which linker you use: !
            !
          • GNU ld (default on Linux): -Wl,--rpath,destdir/lib !
          • IRIX ld: -Wl,-rpath,destdir/lib !
          • Solaris ld: -Wl,-Rdestdir/lib !
          • More...? !
          !
        !

        !

        Use the ldd(1) utility to show which library the system thinks it will get at runtime. !

        !

        A libstdc++.la file is also installed, for use with Libtool. If you use Libtool to create your executables, these details are taken care of for you. !

        ! !

        !
        !

        ! See license.html for copying conditions. Comments and suggestions are welcome, and may be sent to ! the libstdc++ mailing list. !

        ! ! diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/Makefile.am gcc-3.0.2/libstdc++-v3/include/Makefile.am *** gcc-3.0.1/libstdc++-v3/include/Makefile.am Fri Aug 17 22:03:40 2001 --- gcc-3.0.2/libstdc++-v3/include/Makefile.am Tue Aug 28 17:41:56 2001 *************** *** 21,27 **** ## Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, ## USA. ! ## $Id: Makefile.am,v 1.1.6.4 2001/08/18 05:03:40 ljrittle Exp $ AUTOMAKE_OPTIONS = 1.3 gnits MAINT_CHARSET = latin1 --- 21,27 ---- ## Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, ## USA. ! ## $Id: Makefile.am,v 1.1.6.6 2001/08/29 00:41:56 ljrittle Exp $ AUTOMAKE_OPTIONS = 1.3 gnits MAINT_CHARSET = latin1 *************** uppercase = [ABCDEFGHIJKLMNOPQRSTUVWXYZ_ *** 399,423 **** ${thread_builddir}/gthr.h: sed -e '/^#/s/\(${uppercase}${uppercase}*\)/_GLIBCPP_\1/g' \ -e 's,^#include "\(.*\)",#include ,g' \ ! < ${glibcpp_srcdir}/../gcc/gthr.h > $@ ${thread_builddir}/gthr-single.h: sed -e 's/\(UNUSED\)/_GLIBCPP_\1/g' \ -e 's/\(GCC${uppercase}*_H\)/_GLIBCPP_\1/g' \ ! < ${glibcpp_srcdir}/../gcc/gthr-single.h > $@ ${thread_builddir}/gthr-default.h: sed -e 's/\(UNUSED\)/_GLIBCPP_\1/g' \ -e 's/\(GCC${uppercase}*_H\)/_GLIBCPP_\1/g' \ -e 's/\(${uppercase}*WEAK\)/_GLIBCPP_\1/g' \ ! < ${glibcpp_srcdir}/../gcc/${glibcpp_thread_h} > $@ # One big happy istallation: just copy everything from the build to the # install tree (except for the build stamps). gxx_include_dir = @gxx_include_dir@ install-data-local: ! for file in `find . ! -name stamp-\* -print`; do \ installFile=${gxx_include_dir}/$${file} ;\ if [ -d $${file} ]; then \ $(INSTALL) -d $${installFile} ;\ --- 399,423 ---- ${thread_builddir}/gthr.h: sed -e '/^#/s/\(${uppercase}${uppercase}*\)/_GLIBCPP_\1/g' \ -e 's,^#include "\(.*\)",#include ,g' \ ! < ${toplevel_srcdir}/gcc/gthr.h > $@ ${thread_builddir}/gthr-single.h: sed -e 's/\(UNUSED\)/_GLIBCPP_\1/g' \ -e 's/\(GCC${uppercase}*_H\)/_GLIBCPP_\1/g' \ ! < ${toplevel_srcdir}/gcc/gthr-single.h > $@ ${thread_builddir}/gthr-default.h: sed -e 's/\(UNUSED\)/_GLIBCPP_\1/g' \ -e 's/\(GCC${uppercase}*_H\)/_GLIBCPP_\1/g' \ -e 's/\(${uppercase}*WEAK\)/_GLIBCPP_\1/g' \ ! < ${toplevel_srcdir}/gcc/${glibcpp_thread_h} > $@ # One big happy istallation: just copy everything from the build to the # install tree (except for the build stamps). gxx_include_dir = @gxx_include_dir@ install-data-local: ! for file in `find . ! -name stamp-\* ! -name Makefile -print`; do \ installFile=${gxx_include_dir}/$${file} ;\ if [ -d $${file} ]; then \ $(INSTALL) -d $${installFile} ;\ diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/Makefile.in gcc-3.0.2/libstdc++-v3/include/Makefile.in *** gcc-3.0.1/libstdc++-v3/include/Makefile.in Fri Aug 17 22:02:27 2001 --- gcc-3.0.2/libstdc++-v3/include/Makefile.in Mon Sep 10 13:11:05 2001 *************** ${target_builddir}/c++config.h: ../confi *** 377,397 **** ${thread_builddir}/gthr.h: sed -e '/^#/s/\(${uppercase}${uppercase}*\)/_GLIBCPP_\1/g' \ -e 's,^#include "\(.*\)",#include ,g' \ ! < ${glibcpp_srcdir}/../gcc/gthr.h > $@ ${thread_builddir}/gthr-single.h: sed -e 's/\(UNUSED\)/_GLIBCPP_\1/g' \ -e 's/\(GCC${uppercase}*_H\)/_GLIBCPP_\1/g' \ ! < ${glibcpp_srcdir}/../gcc/gthr-single.h > $@ ${thread_builddir}/gthr-default.h: sed -e 's/\(UNUSED\)/_GLIBCPP_\1/g' \ -e 's/\(GCC${uppercase}*_H\)/_GLIBCPP_\1/g' \ -e 's/\(${uppercase}*WEAK\)/_GLIBCPP_\1/g' \ ! < ${glibcpp_srcdir}/../gcc/${glibcpp_thread_h} > $@ install-data-local: ! for file in `find . ! -name stamp-\* -print`; do \ installFile=${gxx_include_dir}/$${file} ;\ if [ -d $${file} ]; then \ $(INSTALL) -d $${installFile} ;\ --- 377,397 ---- ${thread_builddir}/gthr.h: sed -e '/^#/s/\(${uppercase}${uppercase}*\)/_GLIBCPP_\1/g' \ -e 's,^#include "\(.*\)",#include ,g' \ ! < ${toplevel_srcdir}/gcc/gthr.h > $@ ${thread_builddir}/gthr-single.h: sed -e 's/\(UNUSED\)/_GLIBCPP_\1/g' \ -e 's/\(GCC${uppercase}*_H\)/_GLIBCPP_\1/g' \ ! < ${toplevel_srcdir}/gcc/gthr-single.h > $@ ${thread_builddir}/gthr-default.h: sed -e 's/\(UNUSED\)/_GLIBCPP_\1/g' \ -e 's/\(GCC${uppercase}*_H\)/_GLIBCPP_\1/g' \ -e 's/\(${uppercase}*WEAK\)/_GLIBCPP_\1/g' \ ! < ${toplevel_srcdir}/gcc/${glibcpp_thread_h} > $@ install-data-local: ! for file in `find . ! -name stamp-\* ! -name Makefile -print`; do \ installFile=${gxx_include_dir}/$${file} ;\ if [ -d $${file} ]; then \ $(INSTALL) -d $${installFile} ;\ diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/bits/c++config gcc-3.0.2/libstdc++-v3/include/bits/c++config *** gcc-3.0.1/libstdc++-v3/include/bits/c++config Sun Aug 19 00:52:57 2001 --- gcc-3.0.2/libstdc++-v3/include/bits/c++config Tue Oct 23 00:17:00 2001 *************** *** 36,42 **** #include // The current version of the C++ library in compressed ISO date format. ! #define __GLIBCPP__ 20010819 // This is necessary until GCC supports separate template // compilation. --- 36,42 ---- #include // The current version of the C++ library in compressed ISO date format. ! #define __GLIBCPP__ 20011023 // This is necessary until GCC supports separate template // compilation. diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/bits/std_limits.h gcc-3.0.2/libstdc++-v3/include/bits/std_limits.h *** gcc-3.0.1/libstdc++-v3/include/bits/std_limits.h Wed Aug 15 08:48:36 2001 --- gcc-3.0.2/libstdc++-v3/include/bits/std_limits.h Wed Sep 12 00:48:02 2001 *************** namespace std *** 1770,1778 **** static const bool is_signed = true; static const bool is_integer = false; static const bool is_exact = false; ! static const int radix = 2; static float epsilon() throw() ! { return __glibcpp_float_radix; } static float round_error() throw() { return __glibcpp_float_round_error; } --- 1770,1778 ---- static const bool is_signed = true; static const bool is_integer = false; static const bool is_exact = false; ! static const int radix = __glibcpp_float_radix; static float epsilon() throw() ! { return __glibcpp_float_epsilon; } static float round_error() throw() { return __glibcpp_float_round_error; } diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/bits/stl_tree.h gcc-3.0.2/libstdc++-v3/include/bits/stl_tree.h *** gcc-3.0.1/libstdc++-v3/include/bits/stl_tree.h Wed Jun 27 10:12:28 2001 --- gcc-3.0.2/libstdc++-v3/include/bits/stl_tree.h Fri Aug 24 10:45:48 2001 *************** _Rb_tree<_Key, _Val, _KeyOfValue, _Compa *** 920,926 **** { if (__position._M_node == _M_header->_M_left) { // begin() if (size() > 0 && ! _M_key_compare(_S_key(__position._M_node), _KeyOfValue()(__v))) return _M_insert(__position._M_node, __position._M_node, __v); // first argument just needs to be non-null else --- 920,926 ---- { if (__position._M_node == _M_header->_M_left) { // begin() if (size() > 0 && ! _M_key_compare(_KeyOfValue()(__v), _S_key(__position._M_node))) return _M_insert(__position._M_node, __position._M_node, __v); // first argument just needs to be non-null else diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cassert.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cassert.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cassert.h Fri Jun 8 16:33:14 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cassert.h Mon Sep 10 13:11:05 2001 *************** *** 34,40 **** // No include guards on this header... #pragma GCC system_header ! #include_next --- 34,40 ---- // No include guards on this header... #pragma GCC system_header ! #include diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cctype.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cctype.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cctype.h Sat Jun 9 11:53:56 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cctype.h Mon Sep 10 13:11:05 2001 *************** *** 35,41 **** #define _CPP_CCTYPE 1 #pragma GCC system_header ! #include_next // Get rid of those macros defined in in lieu of real functions. #undef isalnum --- 35,41 ---- #define _CPP_CCTYPE 1 #pragma GCC system_header ! #include // Get rid of those macros defined in in lieu of real functions. #undef isalnum diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cerrno.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cerrno.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cerrno.h Fri Jun 8 16:33:14 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cerrno.h Mon Sep 10 13:11:05 2001 *************** *** 35,41 **** #define _CPP_CERRNO 1 #pragma GCC system_header ! #include_next // Adhere to section 17.4.1.2 clause 5 of ISO 14882:1998 #ifndef errno --- 35,41 ---- #define _CPP_CERRNO 1 #pragma GCC system_header ! #include // Adhere to section 17.4.1.2 clause 5 of ISO 14882:1998 #ifndef errno diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cfloat.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cfloat.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cfloat.h Fri Jun 8 16:33:14 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cfloat.h Mon Sep 10 13:11:05 2001 *************** *** 35,40 **** #define _CPP_CFLOAT 1 #pragma GCC system_header ! #include_next #endif --- 35,40 ---- #define _CPP_CFLOAT 1 #pragma GCC system_header ! #include #endif diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_climits.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_climits.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_climits.h Fri Jun 8 16:33:14 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_climits.h Mon Sep 10 13:11:05 2001 *************** *** 35,40 **** #define _CPP_CLIMITS 1 #pragma GCC system_header ! #include_next #endif --- 35,40 ---- #define _CPP_CLIMITS 1 #pragma GCC system_header ! #include #endif diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_clocale.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_clocale.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_clocale.h Fri Jun 8 23:57:15 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_clocale.h Mon Sep 10 13:11:05 2001 *************** *** 35,41 **** #define _CPP_CLOCALE 1 #pragma GCC system_header ! #include_next // Get rid of those macros defined in in lieu of real functions. #undef setlocale --- 35,41 ---- #define _CPP_CLOCALE 1 #pragma GCC system_header ! #include // Get rid of those macros defined in in lieu of real functions. #undef setlocale diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cmath.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cmath.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cmath.h Sun Jun 10 16:41:55 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cmath.h Mon Sep 10 13:11:06 2001 *************** *** 37,43 **** #include #pragma GCC system_header ! #include_next // Get rid of those macros defined in in lieu of real functions. #undef abs --- 37,43 ---- #include #pragma GCC system_header ! #include // Get rid of those macros defined in in lieu of real functions. #undef abs diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_csetjmp.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_csetjmp.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_csetjmp.h Fri Jun 8 16:33:14 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_csetjmp.h Mon Sep 10 13:11:06 2001 *************** *** 35,41 **** #define _CPP_CSETJMP 1 #pragma GCC system_header ! #include_next // Get rid of those macros defined in in lieu of real functions. #undef longjmp --- 35,41 ---- #define _CPP_CSETJMP 1 #pragma GCC system_header ! #include // Get rid of those macros defined in in lieu of real functions. #undef longjmp diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_csignal.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_csignal.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_csignal.h Fri Jun 8 16:33:14 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_csignal.h Mon Sep 10 13:11:06 2001 *************** *** 35,41 **** #define _CPP_CSIGNAL 1 #pragma GCC system_header ! #include_next // Get rid of those macros defined in in lieu of real functions. #undef raise --- 35,41 ---- #define _CPP_CSIGNAL 1 #pragma GCC system_header ! #include // Get rid of those macros defined in in lieu of real functions. #undef raise diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cstdarg.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cstdarg.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cstdarg.h Fri Jun 8 16:33:14 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cstdarg.h Mon Sep 10 13:11:06 2001 *************** *** 35,41 **** #define _CPP_CSTDARG 1 #pragma GCC system_header ! #include_next // Adhere to section 17.4.1.2 clause 5 of ISO 14882:1998 #ifndef va_end --- 35,41 ---- #define _CPP_CSTDARG 1 #pragma GCC system_header ! #include // Adhere to section 17.4.1.2 clause 5 of ISO 14882:1998 #ifndef va_end diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cstddef.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cstddef.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cstddef.h Fri Jun 8 16:33:14 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cstddef.h Mon Sep 10 13:11:06 2001 *************** *** 35,41 **** #define _CPP_CSTDDEF 1 #pragma GCC system_header ! #include_next namespace std { --- 35,41 ---- #define _CPP_CSTDDEF 1 #pragma GCC system_header ! #include namespace std { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cstdio.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cstdio.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cstdio.h Sun Jun 10 16:41:55 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cstdio.h Mon Sep 10 13:11:06 2001 *************** *** 38,44 **** #include #pragma GCC system_header ! #include_next // Get rid of those macros defined in in lieu of real functions. #undef clearerr --- 38,44 ---- #include #pragma GCC system_header ! #include // Get rid of those macros defined in in lieu of real functions. #undef clearerr diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cstdlib.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cstdlib.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cstdlib.h Sun Jun 10 16:41:55 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cstdlib.h Mon Sep 10 13:11:06 2001 *************** *** 38,44 **** #include #pragma GCC system_header ! #include_next // Get rid of those macros defined in in lieu of real functions. #undef abort --- 38,44 ---- #include #pragma GCC system_header ! #include // Get rid of those macros defined in in lieu of real functions. #undef abort diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cstring.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cstring.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cstring.h Sat Jun 9 11:53:56 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cstring.h Mon Sep 10 13:11:06 2001 *************** *** 37,43 **** #include #pragma GCC system_header ! #include_next // Get rid of those macros defined in in lieu of real functions. #undef memcpy --- 37,43 ---- #include #pragma GCC system_header ! #include // Get rid of those macros defined in in lieu of real functions. #undef memcpy diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_ctime.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_ctime.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_ctime.h Sat Jun 9 11:53:56 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_ctime.h Mon Sep 10 13:11:06 2001 *************** *** 37,43 **** #include #pragma GCC system_header ! #include_next // Get rid of those macros defined in in lieu of real functions. #undef clock --- 37,43 ---- #include #pragma GCC system_header ! #include // Get rid of those macros defined in in lieu of real functions. #undef clock diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cwchar.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cwchar.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cwchar.h Sun Jun 10 22:06:54 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cwchar.h Mon Sep 10 13:11:06 2001 *************** *** 28,34 **** // the GNU General Public License. // ! // ISO C++ 14882: ??? // #ifndef _CPP_CWCHAR --- 28,34 ---- // the GNU General Public License. // ! // ISO C++ 14882: 21.4 // #ifndef _CPP_CWCHAR *************** *** 36,45 **** #include #include #if _GLIBCPP_HAVE_WCHAR_H #pragma GCC system_header ! #include_next #endif // Need to do a bit of trickery here with mbstate_t as char_traits --- 36,46 ---- #include #include + #include #if _GLIBCPP_HAVE_WCHAR_H #pragma GCC system_header ! #include #endif // Need to do a bit of trickery here with mbstate_t as char_traits diff -Nrc3pad gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cwctype.h gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cwctype.h *** gcc-3.0.1/libstdc++-v3/include/c_std/bits/std_cwctype.h Fri Jun 8 16:33:14 2001 --- gcc-3.0.2/libstdc++-v3/include/c_std/bits/std_cwctype.h Mon Sep 10 13:11:06 2001 *************** *** 35,41 **** #define _CPP_CWCTYPE 1 #pragma GCC system_header ! #include_next // Get rid of those macros defined in in lieu of real functions. #undef iswalnum --- 35,41 ---- #define _CPP_CWCTYPE 1 #pragma GCC system_header ! #include // Get rid of those macros defined in in lieu of real functions. #undef iswalnum *************** *** 56,61 **** --- 56,62 ---- #undef towupper #undef towctrans #undef wctrans + #undef wctype namespace std { *************** namespace std *** 82,87 **** --- 83,89 ---- using ::towupper; using ::towctrans; using ::wctrans; + using ::wctype; } #endif diff -Nrc3pad gcc-3.0.1/libstdc++-v3/libio/ChangeLog gcc-3.0.2/libstdc++-v3/libio/ChangeLog *** gcc-3.0.1/libstdc++-v3/libio/ChangeLog Sun Aug 19 14:08:37 2001 --- gcc-3.0.2/libstdc++-v3/libio/ChangeLog Tue Oct 23 10:21:13 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. diff -Nrc3pad gcc-3.0.1/libstdc++-v3/src/Makefile.am gcc-3.0.2/libstdc++-v3/src/Makefile.am *** gcc-3.0.1/libstdc++-v3/src/Makefile.am Tue Aug 14 14:10:06 2001 --- gcc-3.0.2/libstdc++-v3/src/Makefile.am Mon Sep 10 13:11:06 2001 *************** *** 21,27 **** ## Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, ## USA. ! ## $Id: Makefile.am,v 1.71.2.12 2001/08/14 21:10:06 bkoz Exp $ AUTOMAKE_OPTIONS = 1.3 gnits MAINT_CHARSET = latin1 --- 21,27 ---- ## Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, ## USA. ! ## $Id: Makefile.am,v 1.71.2.13 2001/09/10 20:11:06 bkoz Exp $ AUTOMAKE_OPTIONS = 1.3 gnits MAINT_CHARSET = latin1 *************** libstdc___la_LIBADD = \ *** 77,83 **** ../libmath/libmath.la @libio_la@ \ ../libsupc++/libsupc++convenience.la ! libstdc___la_LDFLAGS = -version-info 3:1:0 -lm libstdc___la_DEPENDENCIES = $(libstdc___la_LIBADD) --- 77,83 ---- ../libmath/libmath.la @libio_la@ \ ../libsupc++/libsupc++convenience.la ! libstdc___la_LDFLAGS = -version-info 3:2:0 -lm libstdc___la_DEPENDENCIES = $(libstdc___la_LIBADD) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/src/Makefile.in gcc-3.0.2/libstdc++-v3/src/Makefile.in *** gcc-3.0.1/libstdc++-v3/src/Makefile.in Tue Aug 14 14:10:07 2001 --- gcc-3.0.2/libstdc++-v3/src/Makefile.in Mon Sep 10 13:11:06 2001 *************** libstdc___la_SOURCES = $(sources) *** 164,170 **** libstdc___la_LIBADD = ../libmath/libmath.la @libio_la@ ../libsupc++/libsupc++convenience.la ! libstdc___la_LDFLAGS = -version-info 3:1:0 -lm libstdc___la_DEPENDENCIES = $(libstdc___la_LIBADD) --- 164,170 ---- libstdc___la_LIBADD = ../libmath/libmath.la @libio_la@ ../libsupc++/libsupc++convenience.la ! libstdc___la_LDFLAGS = -version-info 3:2:0 -lm libstdc___la_DEPENDENCIES = $(libstdc___la_LIBADD) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_ciso646.cc gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_ciso646.cc *** gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_ciso646.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_ciso646.cc Tue Aug 28 14:19:07 2001 *************** *** 23,29 **** // { dg-do link } #include ! #include // 2.11 Keywords --- 23,29 ---- // { dg-do link } #include ! #include // 2.11 Keywords diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_cwchar.cc gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_cwchar.cc *** gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_cwchar.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_cwchar.cc Mon Sep 10 13:11:07 2001 *************** int main(void) *** 27,31 **** --- 27,34 ---- { // Make sure size_t is in namespace std std::size_t i = 5; + + std::tm mytime; + return 0; } diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_cwctype.cc gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_cwctype.cc *** gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_cwctype.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_cwctype.cc Mon Sep 10 13:11:07 2001 *************** *** 22,32 **** #if _GLIBCPP_USE_WCHAR_T #include ! // Make sure wint_t is in namespace std ! std::wint_t i = 5; #endif int main(void) { return 0; } --- 22,54 ---- #if _GLIBCPP_USE_WCHAR_T #include ! // Make sure wint_t is in namespace std ! std::wint_t i = 5; ! ! // Make sure table 46 is in namespace std. ! using std::wctype_t; ! using std::wctrans_t; ! using std::iswalpha; ! using std::iswupper; ! using std::iswlower; ! using std::iswdigit; ! using std::iswxdigit; ! using std::iswalnum; ! using std::iswspace; ! using std::iswpunct; ! using std::iswprint; ! using std::iswgraph; ! using std::iswcntrl; ! using std::iswctype; ! using std::towctrans; ! using std::towlower; ! using std::towupper; ! using std::wctrans; ! using std::wctype; #endif int main(void) { return 0; } + diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_fstream.cc gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_fstream.cc *** gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_fstream.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_fstream.cc Tue Aug 28 14:19:07 2001 *************** *** 21,27 **** // 17.4.1.2 Headers, fstream #include ! #include int main(void) --- 21,27 ---- // 17.4.1.2 Headers, fstream #include ! #include int main(void) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_iomanip.cc gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_iomanip.cc *** gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_iomanip.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_iomanip.cc Tue Aug 28 14:19:07 2001 *************** *** 21,27 **** // 17.4.1.2 Headers, iomanip #include ! #include int main(void) --- 21,27 ---- // 17.4.1.2 Headers, iomanip #include ! #include int main(void) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_ios.cc gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_ios.cc *** gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_ios.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_ios.cc Tue Aug 28 14:19:07 2001 *************** *** 21,27 **** // 17.4.1.2 Headers, ios #include ! #include int main(void) --- 21,27 ---- // 17.4.1.2 Headers, ios #include ! #include int main(void) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_iosfwd.cc gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_iosfwd.cc *** gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_iosfwd.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_iosfwd.cc Tue Aug 28 14:19:07 2001 *************** *** 21,27 **** // 17.4.1.2 Headers, iosfwd #include ! #include int main(void) --- 21,27 ---- // 17.4.1.2 Headers, iosfwd #include ! #include int main(void) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_iostream.cc gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_iostream.cc *** gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_iostream.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_iostream.cc Tue Aug 28 14:19:07 2001 *************** *** 21,27 **** // 17.4.1.2 Headers, iostream #include ! #include int main(void) --- 21,27 ---- // 17.4.1.2 Headers, iostream #include ! #include int main(void) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_istream.cc gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_istream.cc *** gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_istream.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_istream.cc Tue Aug 28 14:19:07 2001 *************** *** 21,27 **** // 17.4.1.2 Headers, istream #include ! #include int main(void) --- 21,27 ---- // 17.4.1.2 Headers, istream #include ! #include int main(void) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_ostream.cc gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_ostream.cc *** gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_ostream.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_ostream.cc Tue Aug 28 14:19:07 2001 *************** *** 21,27 **** // 17.4.1.2 Headers, ostream #include ! #include int main(void) --- 21,27 ---- // 17.4.1.2 Headers, ostream #include ! #include int main(void) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_sstream.cc gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_sstream.cc *** gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_sstream.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_sstream.cc Tue Aug 28 14:19:07 2001 *************** *** 21,27 **** // 17.4.1.2 Headers, sstream #include ! #include int main(void) --- 21,27 ---- // 17.4.1.2 Headers, sstream #include ! #include int main(void) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_streambuf.cc gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_streambuf.cc *** gcc-3.0.1/libstdc++-v3/testsuite/17_intro/header_streambuf.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/17_intro/header_streambuf.cc Tue Aug 28 14:19:07 2001 *************** *** 21,27 **** // 17.4.1.2 Headers, streambuf #include ! #include int main(void) --- 21,27 ---- // 17.4.1.2 Headers, streambuf #include ! #include int main(void) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/18_support/numeric_limits.cc gcc-3.0.2/libstdc++-v3/testsuite/18_support/numeric_limits.cc *** gcc-3.0.1/libstdc++-v3/testsuite/18_support/numeric_limits.cc Mon May 14 12:49:16 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/18_support/numeric_limits.cc Tue Aug 28 14:19:08 2001 *************** *** 21,27 **** // 18.2.1.1 template class numeric_limits #include ! #include template --- 21,27 ---- // 18.2.1.1 template class numeric_limits #include ! #include template diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/19_diagnostics/stdexceptions.cc gcc-3.0.2/libstdc++-v3/testsuite/19_diagnostics/stdexceptions.cc *** gcc-3.0.1/libstdc++-v3/testsuite/19_diagnostics/stdexceptions.cc Thu May 24 18:14:56 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/19_diagnostics/stdexceptions.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include #include ! #include // libstdc++/1972 void test01() --- 22,28 ---- #include #include ! #include // libstdc++/1972 void test01() diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/20_util/auto_ptr.cc gcc-3.0.2/libstdc++-v3/testsuite/20_util/auto_ptr.cc *** gcc-3.0.1/libstdc++-v3/testsuite/20_util/auto_ptr.cc Sun Dec 10 03:23:50 2000 --- gcc-3.0.2/libstdc++-v3/testsuite/20_util/auto_ptr.cc Tue Aug 28 14:19:08 2001 *************** *** 19,25 **** // 20.4.5 Template class auto_ptr [lib.auto.ptr] #include ! #include struct A { --- 19,25 ---- // 20.4.5 Template class auto_ptr [lib.auto.ptr] #include ! #include struct A { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/append.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/append.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/append.cc Mon May 14 12:49:17 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/append.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include #include ! #include bool test01(void) { --- 22,28 ---- #include #include ! #include bool test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/c_strings.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/c_strings.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/c_strings.cc Thu May 24 18:14:56 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/c_strings.cc Tue Sep 25 18:46:18 2001 *************** void test01() *** 33,39 **** const char* cc1 = &cc; const char* ccarray1 = "san francisco roof garden inspectors"; const char* ccarray2 = "san francisco sunny-day park inspectors"; ! char carray[30]; std::strcpy(carray, ccarray1); void* v = carray; const void* cv = ccarray1; --- 33,39 ---- const char* cc1 = &cc; const char* ccarray1 = "san francisco roof garden inspectors"; const char* ccarray2 = "san francisco sunny-day park inspectors"; ! char carray[50]; std::strcpy(carray, ccarray1); void* v = carray; const void* cv = ccarray1; *************** void test02() *** 70,76 **** const char* ccarray1 = "san francisco roof garden inspectors"; const char* ccarray2 = "san francisco sunny-day park inspectors"; ! char carray[30]; strcpy(carray, ccarray1); void* v = carray; const void* cv = ccarray1; --- 70,76 ---- const char* ccarray1 = "san francisco roof garden inspectors"; const char* ccarray2 = "san francisco sunny-day park inspectors"; ! char carray[50]; strcpy(carray, ccarray1); void* v = carray; const void* cv = ccarray1; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/capacity.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/capacity.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/capacity.cc Mon May 14 12:49:17 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/capacity.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include #include ! #include template struct A { }; --- 22,28 ---- #include #include ! #include template struct A { }; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/char_traits_requirements.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/char_traits_requirements.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/char_traits_requirements.cc Mon May 14 12:49:17 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/char_traits_requirements.cc Tue Aug 28 14:19:08 2001 *************** *** 21,27 **** // 21.1.1 Characher traits requirements #include ! #include int test01(void) { --- 21,27 ---- // 21.1.1 Characher traits requirements #include ! #include int test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/compare.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/compare.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/compare.cc Mon May 14 12:49:18 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/compare.cc Tue Aug 28 14:19:08 2001 *************** *** 31,37 **** // things would be sorted in a dictionary. #include ! #include enum want_value {lt=0, z=1, gt=2}; --- 31,37 ---- // things would be sorted in a dictionary. #include ! #include enum want_value {lt=0, z=1, gt=2}; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/ctor_copy_dtor.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/ctor_copy_dtor.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/ctor_copy_dtor.cc Fri Jul 13 13:55:54 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/ctor_copy_dtor.cc Tue Aug 28 14:19:08 2001 *************** *** 23,29 **** #include #include #include ! #include int test01(void) { --- 23,29 ---- #include #include #include ! #include int test01(void) { *************** void test03() *** 196,201 **** --- 196,202 ---- int main() { + __set_testsuite_memlimit(); test01(); test02(); test03(); diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/element_access.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/element_access.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/element_access.cc Mon May 14 12:49:18 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/element_access.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include #include ! #include bool test01(void) { --- 22,28 ---- #include #include ! #include bool test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/find.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/find.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/find.cc Mon May 14 12:49:18 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/find.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include #include ! #include bool test01(void) { --- 22,28 ---- #include #include ! #include bool test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/insert.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/insert.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/insert.cc Mon May 14 12:49:18 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/insert.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include #include ! #include int test01(void) { --- 22,28 ---- #include #include ! #include int test01(void) { *************** int test01(void) *** 189,194 **** --- 189,195 ---- int main() { + __set_testsuite_memlimit(); test01(); return 0; } diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/inserters_extractors.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/inserters_extractors.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/inserters_extractors.cc Thu May 24 21:36:36 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/inserters_extractors.cc Tue Aug 28 14:19:08 2001 *************** *** 30,36 **** #include #include #include ! #include bool test01(void) { --- 30,36 ---- #include #include #include ! #include bool test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/invariants.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/invariants.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/invariants.cc Mon May 14 12:49:18 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/invariants.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include #include ! #include // Do a quick sanity check on known problems with element access and // ref-counted strings. These should all pass, regardless of the --- 22,28 ---- #include #include ! #include // Do a quick sanity check on known problems with element access and // ref-counted strings. These should all pass, regardless of the diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/nonmember.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/nonmember.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/nonmember.cc Mon May 14 12:49:18 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/nonmember.cc Tue Aug 28 14:19:08 2001 *************** template ! #include int test01(void) { --- 111,117 ---- */ #include ! #include int test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/operations.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/operations.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/operations.cc Mon May 14 12:49:19 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/operations.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include #include ! #include int test01(void) { --- 22,28 ---- #include #include ! #include int test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/replace.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/replace.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/replace.cc Mon May 14 12:49:19 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/replace.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include #include ! #include bool test01(void) { --- 22,28 ---- #include #include ! #include bool test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/rfind.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/rfind.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/rfind.cc Mon May 14 12:49:19 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/rfind.cc Tue Aug 28 14:19:08 2001 *************** *** 20,26 **** #include #include ! #include // 21.3.6.2 basic_string rfind bool test01(void) --- 20,26 ---- #include #include ! #include // 21.3.6.2 basic_string rfind bool test01(void) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/21_strings/substr.cc gcc-3.0.2/libstdc++-v3/testsuite/21_strings/substr.cc *** gcc-3.0.1/libstdc++-v3/testsuite/21_strings/substr.cc Mon May 14 12:49:19 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/21_strings/substr.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include #include ! #include bool test01(void) { --- 22,28 ---- #include #include ! #include bool test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/codecvt_char_char.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/codecvt_char_char.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/codecvt_char_char.cc Mon May 14 12:49:19 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/codecvt_char_char.cc Tue Aug 28 14:19:08 2001 *************** *** 21,27 **** // 22.2.1.5 - Template class codecvt [lib.locale.codecvt] #include ! #include // Required instantiation, degenerate conversion. // codecvt --- 21,27 ---- // 22.2.1.5 - Template class codecvt [lib.locale.codecvt] #include ! #include // Required instantiation, degenerate conversion. // codecvt diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/codecvt_unicode_char.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/codecvt_unicode_char.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/codecvt_unicode_char.cc Mon May 14 12:49:19 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/codecvt_unicode_char.cc Tue Aug 28 14:19:08 2001 *************** *** 21,27 **** // 22.2.1.5 - Template class codecvt [lib.locale.codecvt] #include ! #include using namespace std; --- 21,27 ---- // 22.2.1.5 - Template class codecvt [lib.locale.codecvt] #include ! #include using namespace std; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/codecvt_unicode_wchar_t.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/codecvt_unicode_wchar_t.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/codecvt_unicode_wchar_t.cc Mon May 14 12:49:19 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/codecvt_unicode_wchar_t.cc Tue Aug 28 14:19:08 2001 *************** *** 21,27 **** // 22.2.1.5 - Template class codecvt [lib.locale.codecvt] #include ! #include using namespace std; --- 21,27 ---- // 22.2.1.5 - Template class codecvt [lib.locale.codecvt] #include ! #include using namespace std; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/codecvt_wchar_t_char.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/codecvt_wchar_t_char.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/codecvt_wchar_t_char.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/codecvt_wchar_t_char.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include // for mbstate_t #include ! #include // Need to explicitly set the state(mbstate_t) to zero. --- 22,28 ---- #include // for mbstate_t #include ! #include // Need to explicitly set the state(mbstate_t) to zero. diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/ctor_copy_dtor.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/ctor_copy_dtor.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/ctor_copy_dtor.cc Tue Jan 30 01:18:51 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/ctor_copy_dtor.cc Tue Aug 28 14:19:08 2001 *************** *** 23,29 **** #include // for mbstate_t #include #include ! #include #if _GLIBCPP_USE_WCHAR_T typedef std::codecvt c_codecvt; --- 23,29 ---- #include // for mbstate_t #include #include ! #include #if _GLIBCPP_USE_WCHAR_T typedef std::codecvt c_codecvt; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/ctype_char_members.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/ctype_char_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/ctype_char_members.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/ctype_char_members.cc Tue Aug 28 14:19:08 2001 *************** *** 31,37 **** #include // NB: Don't include any other headers in this file. ! #include class gnu_ctype: public std::ctype { }; --- 31,37 ---- #include // NB: Don't include any other headers in this file. ! #include class gnu_ctype: public std::ctype { }; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/ctype_wchar_t_members.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/ctype_wchar_t_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/ctype_wchar_t_members.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/ctype_wchar_t_members.cc Tue Aug 28 14:19:08 2001 *************** *** 31,37 **** #include // NB: Don't include any other headers in this file. ! #include #if _GLIBCPP_USE_WCHAR_T class gnu_ctype: public std::ctype {}; --- 31,37 ---- #include // NB: Don't include any other headers in this file. ! #include #if _GLIBCPP_USE_WCHAR_T class gnu_ctype: public std::ctype {}; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/facet.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/facet.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/facet.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/facet.cc Tue Aug 28 14:19:08 2001 *************** *** 25,31 **** #include #include #include ! #include // 1 a class if a facet if it is publicly derived from another facet typedef std::istreambuf_iterator input_iterator; --- 25,31 ---- #include #include #include ! #include // 1 a class if a facet if it is publicly derived from another facet typedef std::istreambuf_iterator input_iterator; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/global_templates.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/global_templates.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/global_templates.cc Mon Oct 30 17:26:06 2000 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/global_templates.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include // for mbstate_t #include ! #include typedef std::codecvt ccodecvt; --- 22,28 ---- #include // for mbstate_t #include ! #include typedef std::codecvt ccodecvt; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/members.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/members.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/members.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include #include ! #include // creating unnamed locales 1 using new + combine void --- 22,28 ---- #include #include ! #include // creating unnamed locales 1 using new + combine void diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/numpunct_byname.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/numpunct_byname.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/numpunct_byname.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/numpunct_byname.cc Tue Aug 28 14:19:08 2001 *************** *** 21,27 **** // 22.2.3.2 Template class numpunct_byname #include ! #include void test01() { --- 21,27 ---- // 22.2.3.2 Template class numpunct_byname #include ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/numpunct_char_members.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/numpunct_char_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/numpunct_char_members.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/numpunct_char_members.cc Tue Aug 28 14:19:08 2001 *************** *** 21,27 **** // 22.2.3.1.1 nunpunct members #include ! #include void test01() { --- 21,27 ---- // 22.2.3.1.1 nunpunct members #include ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/operators.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/operators.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/operators.cc Mon Oct 30 17:26:06 2000 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/operators.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include // for mbstate_t #include ! #include typedef std::codecvt ccodecvt; class gnu_codecvt: public ccodecvt { }; --- 22,28 ---- #include // for mbstate_t #include ! #include typedef std::codecvt ccodecvt; class gnu_codecvt: public ccodecvt { }; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/22_locale/static_members.cc gcc-3.0.2/libstdc++-v3/testsuite/22_locale/static_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/22_locale/static_members.cc Mon Oct 30 17:26:06 2000 --- gcc-3.0.2/libstdc++-v3/testsuite/22_locale/static_members.cc Tue Aug 28 14:19:08 2001 *************** *** 22,28 **** #include // for mbstate_t #include ! #include typedef std::codecvt ccodecvt; class gnu_codecvt: public ccodecvt { }; --- 22,28 ---- #include // for mbstate_t #include ! #include typedef std::codecvt ccodecvt; class gnu_codecvt: public ccodecvt { }; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/23_containers/bitset_ctor.cc gcc-3.0.2/libstdc++-v3/testsuite/23_containers/bitset_ctor.cc *** gcc-3.0.1/libstdc++-v3/testsuite/23_containers/bitset_ctor.cc Mon Aug 14 12:59:25 2000 --- gcc-3.0.2/libstdc++-v3/testsuite/23_containers/bitset_ctor.cc Tue Aug 28 14:19:09 2001 *************** *** 22,28 **** #include #include ! #include bool test01(void) { --- 22,28 ---- #include #include ! #include bool test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/23_containers/bitset_members.cc gcc-3.0.2/libstdc++-v3/testsuite/23_containers/bitset_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/23_containers/bitset_members.cc Mon Jun 4 10:44:33 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/23_containers/bitset_members.cc Tue Aug 28 14:19:09 2001 *************** *** 21,27 **** // 23.3.5.2 bitset members #include ! #include bool test01(void) { --- 21,27 ---- // 23.3.5.2 bitset members #include ! #include bool test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/23_containers/bitset_shift.cc gcc-3.0.2/libstdc++-v3/testsuite/23_containers/bitset_shift.cc *** gcc-3.0.1/libstdc++-v3/testsuite/23_containers/bitset_shift.cc Mon Aug 14 12:59:25 2000 --- gcc-3.0.2/libstdc++-v3/testsuite/23_containers/bitset_shift.cc Tue Aug 28 14:19:09 2001 *************** *** 22,28 **** #include #include ! #include static char original_bits[1024]; static char left_shifted[1024]; --- 22,28 ---- #include #include ! #include static char original_bits[1024]; static char left_shifted[1024]; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/23_containers/map_insert.cc gcc-3.0.2/libstdc++-v3/testsuite/23_containers/map_insert.cc *** gcc-3.0.1/libstdc++-v3/testsuite/23_containers/map_insert.cc Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/libstdc++-v3/testsuite/23_containers/map_insert.cc Tue Aug 28 14:19:09 2001 *************** *** 0 **** --- 1,69 ---- + // 2001-08-23 pme & Sylvain.Pion@sophia.inria.fr + + // Copyright (C) 2001 Free Software Foundation, Inc. + // + // This file is part of the GNU ISO C++ Library. This library is free + // software; you can redistribute it and/or modify it under the + // terms of the GNU General Public License as published by the + // Free Software Foundation; either version 2, or (at your option) + // any later version. + + // This library is distributed in the hope that it will be useful, + // but WITHOUT ANY WARRANTY; without even the implied warranty of + // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + // GNU General Public License for more details. + + // You should have received a copy of the GNU General Public License along + // with this library; see the file COPYING. If not, write to the Free + // Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, + // USA. + + // 23.3.1.2, table 69 -- map::insert(p,t) + + #include + #include + + // { dg-do run } + + // libstdc++/3349 and + // http://gcc.gnu.org/ml/gcc-patches/2001-08/msg01375.html + void test01() + { + typedef std::map Map; + Map M; + Map::iterator hint; + + hint = M.insert(Map::value_type(7, 0)).first; + + M.insert(hint, Map::value_type(8, 1)); + M.insert(M.begin(), Map::value_type(9, 2)); + + #if 0 + // The tree's __rb_verify() member must be exposed in map<> before this + // will even compile. It's good test to see that "missing" entries are + // in fact present in the {map,tree}, but in the wrong place. + if (0) + { + Map::iterator i = M.begin(); + while (i != M.end()) { + std::cerr << '(' << i->first << ',' << i->second << ")\n"; + ++i; + } + std::cerr << "tree internal verify: " + << std::boolalpha << M.__rb_verify() << "\n"; + } + #endif + + VERIFY ( M.find(7) != M.end() ); + VERIFY ( M.find(8) != M.end() ); + VERIFY ( M.find(9) != M.end() ); + } + + + int main() + { + test01(); + + return 0; + } + diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/23_containers/vector_capacity.cc gcc-3.0.2/libstdc++-v3/testsuite/23_containers/vector_capacity.cc *** gcc-3.0.1/libstdc++-v3/testsuite/23_containers/vector_capacity.cc Mon Aug 14 12:59:25 2000 --- gcc-3.0.2/libstdc++-v3/testsuite/23_containers/vector_capacity.cc Tue Aug 28 14:19:09 2001 *************** *** 22,28 **** // 23.2.4.2 vector capacity #include ! #include template struct A { }; --- 22,28 ---- // 23.2.4.2 vector capacity #include ! #include template struct A { }; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/23_containers/vector_ctor.cc gcc-3.0.2/libstdc++-v3/testsuite/23_containers/vector_ctor.cc *** gcc-3.0.1/libstdc++-v3/testsuite/23_containers/vector_ctor.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/23_containers/vector_ctor.cc Tue Aug 28 14:19:09 2001 *************** *** 22,28 **** // 23.2.4.1 vector constructors, copy, and assignment #include ! #include template struct A { }; --- 22,28 ---- // 23.2.4.1 vector constructors, copy, and assignment #include ! #include template struct A { }; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/23_containers/vector_element_access.cc gcc-3.0.2/libstdc++-v3/testsuite/23_containers/vector_element_access.cc *** gcc-3.0.1/libstdc++-v3/testsuite/23_containers/vector_element_access.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/23_containers/vector_element_access.cc Tue Aug 28 14:19:09 2001 *************** *** 23,29 **** #include #include ! #include template struct A { }; --- 23,29 ---- #include #include ! #include template struct A { }; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/23_containers/vector_modifiers.cc gcc-3.0.2/libstdc++-v3/testsuite/23_containers/vector_modifiers.cc *** gcc-3.0.1/libstdc++-v3/testsuite/23_containers/vector_modifiers.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/23_containers/vector_modifiers.cc Tue Aug 28 14:19:09 2001 *************** *** 21,27 **** // 23.2.4.3 vector modifiers #include ! #include template struct A { }; --- 21,27 ---- // 23.2.4.3 vector modifiers #include ! #include template struct A { }; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/24_iterators/istreambuf_iterator.cc gcc-3.0.2/libstdc++-v3/testsuite/24_iterators/istreambuf_iterator.cc *** gcc-3.0.1/libstdc++-v3/testsuite/24_iterators/istreambuf_iterator.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/24_iterators/istreambuf_iterator.cc Tue Aug 28 14:19:09 2001 *************** *** 22,28 **** #include #include ! #include bool test01(void) { --- 22,28 ---- #include #include ! #include bool test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/24_iterators/iterator.cc gcc-3.0.2/libstdc++-v3/testsuite/24_iterators/iterator.cc *** gcc-3.0.1/libstdc++-v3/testsuite/24_iterators/iterator.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/24_iterators/iterator.cc Tue Aug 28 14:19:09 2001 *************** *** 21,27 **** #include #include ! #include int string_stuff() --- 21,27 ---- #include #include ! #include int string_stuff() diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/24_iterators/ostreambuf_iterator.cc gcc-3.0.2/libstdc++-v3/testsuite/24_iterators/ostreambuf_iterator.cc *** gcc-3.0.1/libstdc++-v3/testsuite/24_iterators/ostreambuf_iterator.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/24_iterators/ostreambuf_iterator.cc Tue Aug 28 14:19:09 2001 *************** *** 22,28 **** #include #include ! #include bool test01(void) { --- 22,28 ---- #include #include ! #include bool test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/25_algorithms/lower_bound.cc gcc-3.0.2/libstdc++-v3/testsuite/25_algorithms/lower_bound.cc *** gcc-3.0.1/libstdc++-v3/testsuite/25_algorithms/lower_bound.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/25_algorithms/lower_bound.cc Tue Aug 28 14:19:09 2001 *************** *** 17,23 **** // USA. #include ! #include // http://gcc.gnu.org/ml/libstdc++/2000-06/msg00316.html struct foo { }; --- 17,23 ---- // USA. #include ! #include // http://gcc.gnu.org/ml/libstdc++/2000-06/msg00316.html struct foo { }; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/25_algorithms/min_max.cc gcc-3.0.2/libstdc++-v3/testsuite/25_algorithms/min_max.cc *** gcc-3.0.1/libstdc++-v3/testsuite/25_algorithms/min_max.cc Mon May 14 12:49:20 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/25_algorithms/min_max.cc Tue Aug 28 14:19:09 2001 *************** *** 19,25 **** // USA. #include ! #include void test01() { --- 19,25 ---- // USA. #include ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/26_numerics/c_math.cc gcc-3.0.2/libstdc++-v3/testsuite/26_numerics/c_math.cc *** gcc-3.0.1/libstdc++-v3/testsuite/26_numerics/c_math.cc Mon May 14 12:49:21 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/26_numerics/c_math.cc Tue Aug 28 14:19:09 2001 *************** *** 20,26 **** // USA. #include ! #include // test compilation. int --- 20,26 ---- // USA. #include ! #include // test compilation. int diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/26_numerics/complex_inserters_extractors.cc gcc-3.0.2/libstdc++-v3/testsuite/26_numerics/complex_inserters_extractors.cc *** gcc-3.0.1/libstdc++-v3/testsuite/26_numerics/complex_inserters_extractors.cc Thu May 31 05:41:48 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/26_numerics/complex_inserters_extractors.cc Tue Aug 28 14:19:09 2001 *************** *** 24,30 **** #include #include #include ! #include #include template --- 24,30 ---- #include #include #include ! #include #include template diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/26_numerics/complex_value.cc gcc-3.0.2/libstdc++-v3/testsuite/26_numerics/complex_value.cc *** gcc-3.0.1/libstdc++-v3/testsuite/26_numerics/complex_value.cc Mon Nov 20 13:13:45 2000 --- gcc-3.0.2/libstdc++-v3/testsuite/26_numerics/complex_value.cc Tue Aug 28 14:19:09 2001 *************** *** 20,26 **** // USA. #include ! #include void test01() { --- 20,26 ---- // USA. #include ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/filebuf.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/filebuf.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/filebuf.cc Mon May 14 12:49:21 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/filebuf.cc Tue Aug 28 14:19:09 2001 *************** *** 26,32 **** // @diff@ %-*.tst %*.txt #include ! #include const char carray_01[] = "santa cruz or sandiego?"; const char carray_02[] = "memphis, new orleans, and savanah"; --- 26,32 ---- // @diff@ %-*.tst %*.txt #include ! #include const char carray_01[] = "santa cruz or sandiego?"; const char carray_02[] = "memphis, new orleans, and savanah"; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/filebuf_members.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/filebuf_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/filebuf_members.cc Mon May 14 12:49:21 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/filebuf_members.cc Tue Aug 28 14:19:09 2001 *************** *** 27,33 **** #include #include #include ! #include // verify that std::filebuf doesn't close files that it didn't open // when using the following std::filebuf ctor: --- 27,33 ---- #include #include #include ! #include // verify that std::filebuf doesn't close files that it didn't open // when using the following std::filebuf ctor: diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/filebuf_virtuals.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/filebuf_virtuals.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/filebuf_virtuals.cc Tue May 22 11:56:12 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/filebuf_virtuals.cc Tue Aug 28 14:19:09 2001 *************** *** 21,27 **** // 27.8.1.4 Overridden virtual functions #include ! #include void test01() { --- 21,27 ---- // 27.8.1.4 Overridden virtual functions #include ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/fpos.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/fpos.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/fpos.cc Tue Jun 12 18:50:28 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/fpos.cc Tue Aug 28 14:19:09 2001 *************** *** 31,37 **** #include // for mbstate_t #include ! #include void test01() { --- 31,37 ---- #include // for mbstate_t #include ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/fstream_members.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/fstream_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/fstream_members.cc Thu May 24 16:20:33 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/fstream_members.cc Tue Aug 28 14:19:09 2001 *************** *** 21,27 **** // 27.8.1.13 member functions (fstream_members) #include ! #include void redirect_buffer(std::ios& stream, std::streambuf* new_buf) --- 21,27 ---- // 27.8.1.13 member functions (fstream_members) #include ! #include void redirect_buffer(std::ios& stream, std::streambuf* new_buf) diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ifstream_members.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ifstream_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ifstream_members.cc Thu May 24 16:20:33 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ifstream_members.cc Tue Aug 28 14:19:09 2001 *************** *** 22,28 **** #include #include ! #include const char name_01[] = "ifstream_members-1.tst"; const char name_02[] = "ifstream_members-1.txt"; --- 22,28 ---- #include #include ! #include const char name_01[] = "ifstream_members-1.tst"; const char name_02[] = "ifstream_members-1.txt"; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_base_callbacks.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_base_callbacks.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_base_callbacks.cc Mon May 14 12:49:22 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_base_callbacks.cc Tue Aug 28 14:19:09 2001 *************** *** 22,28 **** #include #include ! #include const std::string str01("the nubians of plutonia"); std::string str02; --- 22,28 ---- #include #include ! #include const std::string str01("the nubians of plutonia"); std::string str02; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_base_members_static.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_base_members_static.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_base_members_static.cc Mon May 14 12:49:22 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_base_members_static.cc Tue Aug 28 14:19:09 2001 *************** *** 28,34 **** #include #include ! #include // N.B. Once we have called sync_with_stdio(false), we can never go back. --- 28,34 ---- #include #include ! #include // N.B. Once we have called sync_with_stdio(false), we can never go back. diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_base_storage.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_base_storage.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_base_storage.cc Mon May 14 12:49:22 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_base_storage.cc Tue Aug 28 14:19:09 2001 *************** *** 23,29 **** #include #include ! #include // http://gcc.gnu.org/ml/gcc-bugs/2000-12/msg00413.html void test01() --- 23,29 ---- #include #include ! #include // http://gcc.gnu.org/ml/gcc-bugs/2000-12/msg00413.html void test01() diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_ctor.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_ctor.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_ctor.cc Mon May 14 12:49:22 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_ctor.cc Tue Aug 28 14:19:09 2001 *************** *** 31,37 **** #include #include ! #include void test01() { --- 31,37 ---- #include #include ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_init.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_init.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_init.cc Tue Jun 5 18:39:01 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_init.cc Tue Aug 28 14:19:09 2001 *************** *** 31,37 **** #include #include ! #include class gnu_filebuf: public std::filebuf { --- 31,37 ---- #include #include ! #include class gnu_filebuf: public std::filebuf { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_manip_basefield.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_manip_basefield.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_manip_basefield.cc Mon Aug 14 12:59:25 2000 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_manip_basefield.cc Tue Aug 28 14:19:09 2001 *************** *** 31,37 **** #include #include #include ! #include struct MyNP : std::numpunct { --- 31,37 ---- #include #include #include ! #include struct MyNP : std::numpunct { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_manip_fmtflags.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_manip_fmtflags.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_manip_fmtflags.cc Mon Aug 14 12:59:25 2000 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_manip_fmtflags.cc Tue Aug 28 14:19:09 2001 *************** *** 31,37 **** #include #include #include ! #include struct MyNP : std::numpunct { --- 31,37 ---- #include #include #include ! #include struct MyNP : std::numpunct { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_members.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ios_members.cc Mon May 14 12:49:22 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ios_members.cc Tue Aug 28 14:19:09 2001 *************** *** 31,37 **** #include // NB: Don't include any other headers in this file. ! #include void test01() { --- 31,37 ---- #include // NB: Don't include any other headers in this file. ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_extractor_arith.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_extractor_arith.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_extractor_arith.cc Mon May 14 12:49:23 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_extractor_arith.cc Tue Aug 28 14:19:09 2001 *************** *** 25,31 **** #include #include #include ! #include std::string str_01; std::string str_02("true false 0 1 110001"); --- 25,31 ---- #include #include #include ! #include std::string str_01; std::string str_02("true false 0 1 110001"); diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_extractor_char.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_extractor_char.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_extractor_char.cc Mon May 14 12:49:23 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_extractor_char.cc Tue Aug 28 14:19:09 2001 *************** *** 22,28 **** #include #include ! #include bool test01() { --- 22,28 ---- #include #include ! #include bool test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_extractor_other.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_extractor_other.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_extractor_other.cc Mon May 14 12:49:23 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_extractor_other.cc Tue Aug 28 14:19:09 2001 *************** *** 25,31 **** #include #include #include ! #include // stringbufs. --- 25,31 ---- #include #include #include ! #include // stringbufs. diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_manip.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_manip.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_manip.cc Mon May 14 12:49:23 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_manip.cc Tue Aug 28 14:19:09 2001 *************** *** 23,29 **** #include #include #include ! #include bool test01(void) { --- 23,29 ---- #include #include #include ! #include bool test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_seeks.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_seeks.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_seeks.cc Mon Jun 11 19:30:06 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_seeks.cc Tue Aug 28 14:19:09 2001 *************** *** 26,32 **** #include #include #include ! #include bool test01() { --- 26,32 ---- #include #include #include ! #include bool test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_sentry.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_sentry.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_sentry.cc Mon May 14 12:49:24 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_sentry.cc Tue Aug 28 14:19:09 2001 *************** *** 31,37 **** #include #include ! #include void test01() { --- 31,37 ---- #include #include ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_unformatted.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_unformatted.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/istream_unformatted.cc Tue May 15 13:51:30 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/istream_unformatted.cc Tue Aug 28 14:19:09 2001 *************** *** 26,32 **** #include #include #include ! #include int test01() --- 26,32 ---- #include #include #include ! #include int test01() diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/istringstream_members.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/istringstream_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/istringstream_members.cc Thu May 24 16:20:33 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/istringstream_members.cc Tue Aug 28 14:19:09 2001 *************** *** 21,27 **** // 27.7.2.2 member functions (istringstream_members) #include ! #include void test01() { --- 21,27 ---- // 27.7.2.2 member functions (istringstream_members) #include ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/narrow_stream_objects.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/narrow_stream_objects.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/narrow_stream_objects.cc Mon May 14 12:49:25 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/narrow_stream_objects.cc Tue Aug 28 14:19:09 2001 *************** *** 66,72 **** #include #include #include ! #include // Include iostream last, just to make is as difficult as possible to // properly initialize the standard iostream objects. --- 66,72 ---- #include #include #include ! #include // Include iostream last, just to make is as difficult as possible to // properly initialize the standard iostream objects. diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ofstream_members.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ofstream_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ofstream_members.cc Thu May 24 16:20:33 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ofstream_members.cc Tue Aug 28 14:19:09 2001 *************** *** 22,28 **** #include #include ! #include const char name_01[] = "ofstream_members-1.tst"; const char name_02[] = "ofstream_members-1.txt"; --- 22,28 ---- #include #include ! #include const char name_01[] = "ofstream_members-1.tst"; const char name_02[] = "ofstream_members-1.txt"; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostream_inserter_arith.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostream_inserter_arith.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostream_inserter_arith.cc Mon May 14 12:49:25 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostream_inserter_arith.cc Tue Aug 28 14:19:09 2001 *************** *** 25,31 **** #include #include #include ! #include using namespace std; --- 25,31 ---- #include #include #include ! #include using namespace std; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostream_inserter_char.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostream_inserter_char.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostream_inserter_char.cc Mon May 14 12:49:25 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostream_inserter_char.cc Tue Aug 28 14:19:09 2001 *************** *** 24,30 **** #include #include #include ! #include // ofstream bool test01() --- 24,30 ---- #include #include #include ! #include // ofstream bool test01() diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostream_inserter_other.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostream_inserter_other.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostream_inserter_other.cc Mon May 14 12:49:25 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostream_inserter_other.cc Tue Aug 28 14:19:09 2001 *************** *** 26,32 **** #include #include #include ! #include const int size = 1000; const char name_01[] = "ostream_inserter_other-1.tst"; --- 26,32 ---- #include #include #include ! #include const int size = 1000; const char name_01[] = "ostream_inserter_other-1.tst"; diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostream_manip.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostream_manip.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostream_manip.cc Mon May 14 12:49:25 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostream_manip.cc Tue Aug 28 14:19:09 2001 *************** *** 23,29 **** #include #include #include ! #include bool test01(void) { --- 23,29 ---- #include #include #include ! #include bool test01(void) { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostream_seeks.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostream_seeks.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostream_seeks.cc Mon May 14 12:49:26 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostream_seeks.cc Tue Aug 28 14:19:09 2001 *************** *** 23,29 **** #include #include #include ! #include bool test01() --- 23,29 ---- #include #include #include ! #include bool test01() diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostream_unformatted.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostream_unformatted.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostream_unformatted.cc Mon May 14 12:49:26 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostream_unformatted.cc Tue Aug 28 14:19:09 2001 *************** *** 20,26 **** #include #include ! #include void test01() --- 20,26 ---- #include #include ! #include void test01() diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostringstream_members.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostringstream_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/ostringstream_members.cc Thu May 24 16:20:33 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/ostringstream_members.cc Tue Aug 28 14:19:09 2001 *************** *** 21,27 **** // 27.7.3.2 member functions (ostringstream_members) #include ! #include void test01() { --- 21,27 ---- // 27.7.3.2 member functions (ostringstream_members) #include ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/streambuf.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/streambuf.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/streambuf.cc Mon May 14 12:49:26 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/streambuf.cc Tue Aug 28 14:19:09 2001 *************** *** 33,39 **** #include #include #include ! #include class testbuf : public std::streambuf { --- 33,39 ---- #include #include #include ! #include class testbuf : public std::streambuf { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/stringbuf.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/stringbuf.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/stringbuf.cc Fri Jul 13 13:55:54 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/stringbuf.cc Tue Aug 28 14:19:09 2001 *************** *** 19,25 **** // USA. #include ! #include std::string str_01("mykonos. . . or what?"); std::string str_02("paris, or sainte-maxime?"); --- 19,25 ---- // USA. #include ! #include std::string str_01("mykonos. . . or what?"); std::string str_02("paris, or sainte-maxime?"); diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/stringbuf_virtuals.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/stringbuf_virtuals.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/stringbuf_virtuals.cc Tue May 22 11:56:12 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/stringbuf_virtuals.cc Tue Aug 28 14:19:09 2001 *************** *** 21,27 **** // 27.7.1.3 Overridden virtual functions #include ! #include void test01() { --- 21,27 ---- // 27.7.1.3 Overridden virtual functions #include ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/stringstream.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/stringstream.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/stringstream.cc Tue May 15 13:51:30 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/stringstream.cc Tue Aug 28 14:19:09 2001 *************** *** 31,37 **** #include #include #include ! #include // 01: sanity checks for strings, stringbufs std::string --- 31,37 ---- #include #include #include ! #include // 01: sanity checks for strings, stringbufs std::string diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/stringstream_members.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/stringstream_members.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/stringstream_members.cc Thu May 24 16:20:33 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/stringstream_members.cc Tue Aug 28 14:19:09 2001 *************** *** 21,27 **** // 27.7.6 member functions (stringstream_members) #include ! #include void test01() { --- 21,27 ---- // 27.7.6 member functions (stringstream_members) #include ! #include void test01() { diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/27_io/wide_stream_objects.cc gcc-3.0.2/libstdc++-v3/testsuite/27_io/wide_stream_objects.cc *** gcc-3.0.1/libstdc++-v3/testsuite/27_io/wide_stream_objects.cc Mon Aug 14 12:59:26 2000 --- gcc-3.0.2/libstdc++-v3/testsuite/27_io/wide_stream_objects.cc Tue Aug 28 14:19:09 2001 *************** *** 71,77 **** #include #include #endif ! #include // Include iostream last, just to make is as difficult as possible to // properly initialize the standard iostream objects. --- 71,77 ---- #include #include #endif ! #include // Include iostream last, just to make is as difficult as possible to // properly initialize the standard iostream objects. diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/debug_assert.h gcc-3.0.2/libstdc++-v3/testsuite/debug_assert.h *** gcc-3.0.1/libstdc++-v3/testsuite/debug_assert.h Mon Aug 14 13:56:06 2000 --- gcc-3.0.2/libstdc++-v3/testsuite/debug_assert.h Wed Dec 31 16:00:00 1969 *************** *** 1,51 **** - // 20000810 Brent Verner - // - // Copyright (C) 2000 Free Software Foundation, Inc. - // - // This file is part of the GNU ISO C++ Library. This library is free - // software; you can redistribute it and/or modify it under the - // terms of the GNU General Public License as published by the - // Free Software Foundation; either version 2, or (at your option) - // any later version. - // - // This library is distributed in the hope that it will be useful, - // but WITHOUT ANY WARRANTY; without even the implied warranty of - // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - // GNU General Public License for more details. - // - // You should have received a copy of the GNU General Public License along - // with this library; see the file COPYING. If not, write to the Free - // Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, - // USA. - // - // - // Purpose: - // This file is included in the various testsuite programs to provide - // #define(able) assert() behavior for debugging/testing. It may be - // a suitable location for other furry woodland creatures as well. - // - // Notes: - // If you find yourself compiling small test progs as much as I - // do, you can move this file to a location your compiler(s) - // will find, and possibly add more cheap debugging stuff... - // - - #ifndef _CPP_DEBUG_ASSERT_H - #define _CPP_DEBUG_ASSERT_H - - #ifdef DEBUG_ASSERT - # include - # define VERIFY(fn) assert(fn) - - #else - # define VERIFY(fn) test &= (fn) - // should we define this here to make sure no 'unexpected' failures - // happen, or do we require that it be defined in any scope where - // the VERIFY macro is used??? - // - // static bool test = true; - #endif - - - #endif // _CPP_DEBUG_ASSERT_H - --- 0 ---- diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/lib/libstdc++-v3-dg.exp gcc-3.0.2/libstdc++-v3/testsuite/lib/libstdc++-v3-dg.exp *** gcc-3.0.1/libstdc++-v3/testsuite/lib/libstdc++-v3-dg.exp Wed May 30 13:29:34 2001 --- gcc-3.0.2/libstdc++-v3/testsuite/lib/libstdc++-v3-dg.exp Tue Oct 2 11:01:04 2001 *************** *** 19,24 **** --- 19,39 ---- load_lib dg.exp load_lib libgloss.exp + proc libstdc++-v3-copy-files {srcfiles dstdir} { + foreach f $srcfiles { + if { [catch { set symlink [file readlink $f] } x] } then { + file copy -force $f $dstdir + } else { + if { [regexp "^/" "$symlink"] } then { + file copy -force $symlink $dstdir + } else { + set dirname [file dirname $f] + file copy -force $dirname/$symlink $dstdir + } + } + } + } + proc libstdc++-v3-init { args } { global srcdir global outdir *************** proc libstdc++-v3-init { args } { *** 29,61 **** global objdir global gluefile wrap_flags global ld_library_path ! set blddir [lookfor_file $outdir libstdc++-v3] ! # By default, we assume we want to run program images. global dg-do-what-default set dg-do-what-default run # Copy any required data files. ! foreach tst [glob -nocomplain "$srcdir/*/*.tst"] { ! file copy -force $tst $outdir ! } ! foreach txt [glob -nocomplain "$srcdir/*/*.txt"] { ! file copy -force $txt $outdir ! } # set LD_LIBRARY_PATH so that libgcc_s, libstdc++ binaries can be found. ! set gccpath [get_multilibs] set ld_library_path "." ! append ld_library_path ":${gccpath}../gcc" append ld_library_path ":${blddir}/src/.libs" # Do a bunch of handstands and backflips for cross compiling and # finding simulators... if [is_remote host] { ! set header [remote_download host ${srcdir}/debug_assert.h] if { $header == "" } { ! verbose -log "Unable to download ${srcdir}/debug_assert.h to host." return "untested" } set cxx [transform "g++"] --- 44,79 ---- global objdir global gluefile wrap_flags global ld_library_path + global tool_root_dir ! set blddir [lookfor_file [get_multilibs] libstdc++-v3] ! # By default, we assume we want to run program images. global dg-do-what-default set dg-do-what-default run # Copy any required data files. ! libstdc++-v3-copy-files [glob -nocomplain "$srcdir/*/*.tst"] $outdir ! libstdc++-v3-copy-files [glob -nocomplain "$srcdir/*/*.txt"] $outdir # set LD_LIBRARY_PATH so that libgcc_s, libstdc++ binaries can be found. ! # locate libgcc.a so we don't need to account for different values of ! # SHLIB_EXT on different platforms ! set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a] ! if {$gccdir != ""} { ! set gccdir [file dirname $gccdir] ! } ! set ld_library_path "." ! append ld_library_path ":${gccdir}" append ld_library_path ":${blddir}/src/.libs" # Do a bunch of handstands and backflips for cross compiling and # finding simulators... if [is_remote host] { ! set header [remote_download host ${blddir}/testsuite/testsuite_hooks.h] if { $header == "" } { ! verbose -log "Unable to download ${blddir}/testsuite/testsuite_hooks.h to host." return "untested" } set cxx [transform "g++"] diff -Nrc3pad gcc-3.0.1/libstdc++-v3/testsuite/testsuite_hooks.h gcc-3.0.2/libstdc++-v3/testsuite/testsuite_hooks.h *** gcc-3.0.1/libstdc++-v3/testsuite/testsuite_hooks.h Wed Dec 31 16:00:00 1969 --- gcc-3.0.2/libstdc++-v3/testsuite/testsuite_hooks.h Tue Aug 28 14:19:07 2001 *************** *** 0 **** --- 1,104 ---- + // Utility subroutines for the C++ library testsuite. + // + // Copyright (C) 2000, 2001 Free Software Foundation, Inc. + // + // This file is part of the GNU ISO C++ Library. This library is free + // software; you can redistribute it and/or modify it under the + // terms of the GNU General Public License as published by the + // Free Software Foundation; either version 2, or (at your option) + // any later version. + // + // This library is distributed in the hope that it will be useful, + // but WITHOUT ANY WARRANTY; without even the implied warranty of + // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + // GNU General Public License for more details. + // + // You should have received a copy of the GNU General Public License along + // with this library; see the file COPYING. If not, write to the Free + // Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, + // USA. + // + // As a special exception, you may use this file as part of a free software + // library without restriction. Specifically, if other files instantiate + // templates or use macros or inline functions from this file, or you compile + // this file and link it with other files to produce an executable, this + // file does not by itself cause the resulting executable to be covered by + // the GNU General Public License. This exception does not however + // invalidate any other reasons why the executable file might be covered by + // the GNU General Public License. + + // This file provides the following: + // + // 1) VERIFY(), via DEBUG_ASSERT, from Brent Verner . + // This file is included in the various testsuite programs to provide + // #define(able) assert() behavior for debugging/testing. It may be + // a suitable location for other furry woodland creatures as well. + // + // 2) __set_testsuite_memlimit() + // __set_testsuite_memlimit() uses setrlimit() to restrict dynamic memory + // allocation. We provide a default memory limit if none is passed by the + // calling application. The argument to __set_testsuite_memlimit() is the + // limit in megabytes (a floating-point number). If _GLIBCPP_MEM_LIMITS is + // #defined before including this header, then no limiting is attempted. + + #ifndef _GLIBCPP_TESTSUITE_HOOKS_H + #define _GLIBCPP_TESTSUITE_HOOKS_H + + #ifdef DEBUG_ASSERT + # include + # define VERIFY(fn) assert(fn) + #else + # define VERIFY(fn) test &= (fn) + # define VERIFY(fn) fn + #endif + + #include + + // Defined in GLIBCPP_CONFIGURE_TESTSUITE. + #ifndef _GLIBCPP_MEM_LIMITS + + // Don't do memory limits. + void + __set_testsuite_memlimit(float x = 0) + { } + + #else + + // Do memory limits. + #include + #include + + #ifndef MEMLIMIT_MB + #define MEMLIMIT_MB 16.0 + #endif + + void + __set_testsuite_memlimit(float __size = MEMLIMIT_MB) + { + struct rlimit r; + r.rlim_cur = (rlim_t)(__size * 1048576); + + // Heap size, seems to be common. + #if _GLIBCPP_HAVE_MEMLIMIT_DATA + setrlimit(RLIMIT_DATA, &r); + #endif + + // Resident set size. + #if _GLIBCPP_HAVE_MEMLIMIT_RSS + setrlimit(RLIMIT_RSS, &r); + #endif + + // Mapped memory (brk + mmap). + #if _GLIBCPP_HAVE_MEMLIMIT_VMEM + setrlimit(RLIMIT_VMEM, &r); + #endif + + // Virtual memory. + #if _GLIBCPP_HAVE_MEMLIMIT_AS + setrlimit(RLIMIT_AS, &r); + #endif + } + #endif + + #endif // _GLIBCPP_TESTSUITE_HOOKS_H + diff -Nrc3pad gcc-3.0.1/zlib/ChangeLog gcc-3.0.2/zlib/ChangeLog *** gcc-3.0.1/zlib/ChangeLog Sun Aug 19 14:08:38 2001 --- gcc-3.0.2/zlib/ChangeLog Tue Oct 23 10:21:18 2001 *************** *** 1,3 **** --- 1,7 ---- + 2001-10-23 Release Manager + + * GCC 3.0.2 Released. + 2001-08-19 Release Manager * GCC 3.0.1 Released. *************** Changes in 1.0.6 (19 Jan 1998) *** 227,233 **** - use _fdopen instead of fdopen for MSC >= 6.0 (Thomas Fanslau) - added makelcc.bat for lcc-win32 (Tom St Denis) - in Makefile.dj2, use copy and del instead of install and rm (Frank Donahoe) ! - Avoid expanded $Id: ChangeLog,v 1.1.8.3 2001/08/19 21:08:38 gccadmin Exp $. Use "rcs -kb" or "cvs admin -kb" to avoid Id expansion. - check for unistd.h in configure (for off_t) - remove useless check parameter in inflate_blocks_free - avoid useless assignment of s->check to itself in inflate_blocks_new --- 231,237 ---- - use _fdopen instead of fdopen for MSC >= 6.0 (Thomas Fanslau) - added makelcc.bat for lcc-win32 (Tom St Denis) - in Makefile.dj2, use copy and del instead of install and rm (Frank Donahoe) ! - Avoid expanded $Id: ChangeLog,v 1.1.8.4 2001/10/23 17:21:18 mmitchel Exp $. Use "rcs -kb" or "cvs admin -kb" to avoid Id expansion. - check for unistd.h in configure (for off_t) - remove useless check parameter in inflate_blocks_free - avoid useless assignment of s->check to itself in inflate_blocks_new