request of copyright assignment form
HI all. Could someone please send me the "copyright assignment form"? Thanks. Daniel
build error: gcc/gcc/gimplify.c:424: internal compiler error: Segmentation fault
SVN revision: 118109 Configured as: --prefix=$(installdir) --enable-bootstrap --enable-threads=posix --enable-shared --with-system-zlib --disable-nls --program-suffix=-svn --enable-languages=c,fortran Command: make bootstrap-lean Host triplet: i686-pc-linux-gnu Latest messages: /home/daniel/src/gcc-devel/gcc-build/./prev-gcc/xgcc -B/home/daniel/src/gcc-devel/gcc-build/./prev-gcc/ -B/home/daniel/src/gcc-devel/gcc-install/i686-pc-linux-gnu/bin/ -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gencodes \ build/gencodes.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o .././libiberty/libiberty.a build/gencodes ../../gcc/gcc/config/i386/i386.md \ insn-conditions.md > tmp-codes.h /bin/sh ../../gcc/gcc/../move-if-change tmp-codes.h insn-codes.h echo timestamp > s-codes /home/daniel/src/gcc-devel/gcc-build/./prev-gcc/xgcc -B/home/daniel/src/gcc-devel/gcc-build/./prev-gcc/ -B/home/daniel/src/gcc-devel/gcc-install/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber../../gcc/gcc/gimplify.c -o gimplify.o ../../gcc/gcc/gimplify.c: In function 'create_tmp_var_name': ../../gcc/gcc/gimplify.c:424: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate.
bootstrapping r118945 failed
SVN revision: 118945 Host: i686-pc-linux-gnu /home/daniel/svn-build/gcc-head/./gcc/xgcc -B/home/daniel/svn-build/gcc-head/./g cc/ -B/home/daniel/i686-pc-linux-gnu/gcc-svn//i686-pc-linux-gnu/bin/ -B/home/dan iel/i686-pc-linux-gnu/gcc-svn//i686-pc-linux-gnu/lib/ -isystem /home/daniel/i686 -pc-linux-gnu/gcc-svn//i686-pc-linux-gnu/include -isystem /home/daniel/i686-pc-l inux-gnu/gcc-svn//i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/home/dani el/svn/gcc/libgfortran -I. -iquote/home/daniel/svn/gcc/libgfortran/io -I/home/da niel/svn/gcc/libgfortran/../gcc -I/home/daniel/svn/gcc/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prot otypes -Wold-style-definition -Wextra -Wwrite-strings -ftree-vectorize -funroll- loops -O2 -g -O2 -c /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c -fPI C -DPIC -o .libs/matmul_i4.o /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c: In function 'matmul_i4': /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c:337: error: verify_flow_i nfo: Block 136 has loop_father, but there are no loops /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c:337: error: verify_flow_info: Block 135 has loop_father, but there are no loops [snipped 133 identical messages] /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c:337: error: verify_flow_info: Block 2 has loop_father, but there are no loops /home/daniel/svn/gcc/libgfortran/generated/matmul_i4.c:337: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [matmul_i4.lo] Error 1 make[3]: Leaving directory `/home/daniel/svn-build/gcc-head/i686-pc-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/daniel/svn-build/gcc-head/i686-pc-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/daniel/svn-build/gcc-head'
[gomp, documentation] libgomp/NOTES
In the wake of PR28209 ([G]OMP environment variables undocumented), I came across libgomp/NOTES: "Notes on the external ABI presented by libgomp. This ought to get transformed into proper documentation at some point." Would a 1:1 transcription to texinfo suffice for the moment being? E.g. something similar to: -- libgomp.texi -- @chapter The libgomp ABI @menu * Implementing MASTER construct ... * Implementing SINGLE construct @end menu @node Implementing MASTER construct @section Implementing MASTER construct [copy-paste-and-texify-NOTES] @node ... -- libgomp.texi -- Regards Daniel P.S. I can neither confirm nor (re-)assign PR28209 to myself ...?!
[gomp] distributing libgomp/libgomp.info ?
To the gcc packagers: Shall libgomp/libgomp.info ever be distributed, i.e. is there any reason to add the --enable-generated-files-in-srcdir flag from gcc/configure.ac to libgomp/configure.ac as well? The tarball of 4.1.1 includes fastjar/fastjar.info, but not libiberty/libiberty.info. The config file fastjar/configure.ac has the enable-...-srcdir flag, libiberty/configure.ac does not. Thanks Daniel
Re: [gomp] distributing libgomp/libgomp.info ?
On Thursday 23 November 2006 05:11, you wrote: > On Wed, 2006-11-22 at 22:52 +0100, Daniel Franke wrote: > > The tarball of 4.1.1 includes fastjar/fastjar.info, but not > > libiberty/libiberty.info. The config file fastjar/configure.ac has the > > enable-...-srcdir flag, libiberty/configure.ac does not. > > This is because libiberty's API is all internal really and is always > changing and never stable. It is not really a well defined library > unlike say libgomp. Andrew, I added --enable-generated-files-in-srcdir to libgomp/configure.ac. Please find the full patch at: http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01650.html Regards Daniel
[fixincludes] PR29867 - building libgfortran fails
Hi all, I spent the last couple of hours tracking down PR29867 through fixincludes. Now, as the actual problem is identified, I lack the knowledge to fix it appropriately. Could someone more involved with fixincludes comment on this? Thanks. The problem: fixes "glibc_c99_inline_1" and "glibc_c99_inline_2" are looking for "features.h" and "sys/stat.h" respectively. In some x86_64 distros, these files are placed "/usr/include/x86_64-linux", with compat(?) versions of both files in "/usr/include". Adding some debug output to fixincl.c(fix_applies), line 1120, one finds: bailing in glibc_c99_inline_1, looking for file x86_64-linux/features.h in |features.h| bailing in glibc_c99_inline_2, looking for file x86_64-linux/sys/stat.h in |sys/stat.h| [format string: fprintf (myfile, "bailing in %s, looking for file %s in %s\n", p_fixd->fix_name, pz_fname, p_fixd->file_list);] OTOH, some files in /usr/include/x86_64 are fixed (neither fix specifies a file name): Applying ctrl_quotes_def to x86_64-linux/readline/chardefs.h Applying io_quotes_use to x86_64-linux/sys/mount.h Applying io_quotes_use to x86_64-linux/sys/raw.h Some pointers/help how to address this issue would be appreciated. Regards Daniel
x86_64, r120172: bootstrap error (In function `null_or_integer_zerop': undefined reference to `integer_zerop')
host: x86_64-pc-linux-gnu revision: r120172 configured as: ../../svn/gcc-head/configure --prefix=$(localpath) --with-gmp=$(localpath)/gmp-4.2.1 --with-mpfr=$(localpath)/mpfr-2.2.1 --enable-bootstrap --enable-threads=posix --enable-shared --with-system-zlib --program-suffix=-svn --disable-nls --disable-multilib --enable-maintainer-mode --enable-languages=c,fortran gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../../svn/gcc-head/gcc -I../../../svn/gcc-head/gcc/build -I../../../svn/gcc-head/gcc/../include -I../../../svn/gcc-head/gcc/../libcpp/include -I/data/home/daniel/x86_64-unknown-linux-gnu/gmp-4.2.1/include -I/data/home/daniel/x86_64-unknown-linux-gnu/mpfr-2.2.1/include -I../../../svn/gcc-head/gcc/../libdecnumber -I../libdecnumber-o build/vec.o ../../../svn/gcc-head/gcc/vec.c build/genmodes -m > tmp-min-modes.c /bin/sh ../../../svn/gcc-head/gcc/../move-if-change tmp-min-modes.c min-insn-modes.c echo timestamp > s-modes-m gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../../svn/gcc-head/gcc -I../../../svn/gcc-head/gcc/build -I../../../svn/gcc-head/gcc/../include -I../../../svn/gcc-head/gcc/../libcpp/include -I/data/home/daniel/x86_64-unknown-linux-gnu/gmp-4.2.1/include -I/data/home/daniel/x86_64-unknown-linux-gnu/mpfr-2.2.1/include -I../../../svn/gcc-head/gcc/../libdecnumber -I../libdecnumber-o build/min-insn-modes.o min-insn-modes.c gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../../svn/gcc-head/gcc -I../../../svn/gcc-head/gcc/build -I../../../svn/gcc-head/gcc/../include -I../../../svn/gcc-head/gcc/../libcpp/include -I/data/home/daniel/x86_64-unknown-linux-gnu/gmp-4.2.1/include -I/data/home/daniel/x86_64-unknown-linux-gnu/mpfr-2.2.1/include -I../../../svn/gcc-head/gcc/../libdecnumber -I../libdecnumber-o build/gensupport.o ../../../svn/gcc-head/gcc/gensupport.c gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../../svn/gcc-head/gcc -I../../../svn/gcc-head/gcc/build -I../../../svn/gcc-head/gcc/../include -I../../../svn/gcc-head/gcc/../libcpp/include -I/data/home/daniel/x86_64-unknown-linux-gnu/gmp-4.2.1/include -I/data/home/daniel/x86_64-unknown-linux-gnu/mpfr-2.2.1/include -I../../../svn/gcc-head/gcc/../libdecnumber -I../libdecnumber-o build/print-rtl.o ../../../svn/gcc-head/gcc/print-rtl.c gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genconstants \ build/genconstants.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a build/vec.o: In function `null_or_integer_zerop':../../../svn/gcc-head/gcc/tree.h:4083: undefined reference to `integer_zerop' build/vec.o: In function `nonnull_and_integer_nonzerop':../../../svn/gcc-head/gcc/tree.h:4091: undefined reference to `integer_nonzerop' collect2: ld returned 1 exit status make[3]: *** [build/genconstants] Error 1
Re: x86_64, r120172: bootstrap error (In function `null_or_integer_zerop': undefined reference to `integer_zerop')
On Saturday 23 December 2006 23:35, Andrew Pinski wrote: > On Sat, 2006-12-23 at 18:32 +0100, Daniel Franke wrote: > > host: x86_64-pc-linux-gnu > > revision: r120172 > > Even though I could not reproduce this failure. The problem is simple > and obvious. vec.c includes tree.h for some reason, it has always be > included. > > Committed this patch as obvious after a bootstrap/test on i686-linux-gnu > (with C only). Bootstrapping now. Thanks! Daniel
gfortran+libcpp: linking objects from c-compiler
Hi all. To integrate libcpp into gfortran, I copy/adapt quite some code from the c frontend. For include-path handling, I found that I can nicely re-use the functions defined in c-incpath.c and exported by c-incpath.h. Now, linking gfortran, the linker of course complains about undefined references, namely app_path() and register_include_chains(). Is it acceptable to simply link in the C-frontend object to gfortran (as C is a required language and the .o file will be available)? Do I need to do something else in addition or instead, like renaming or moving functions, pushing them to a library or anything else? Comments are highly welcome! Regards Daniel
in asm: where does ".zero 2102063220" come from?
Hi all. I'm in the process of revamping the fortran-frontend to use trees instead of linked lists in its array-constructor representation (initial patch at [1]). By now, I'm hunting down the last regressions. For one regression, I have no idea how to deal with it. The problem: for some reason the .o file for a small fortran program may be blown up to multiple GB. The diff below shows the differences in assembler of the testcase gfortran.dg/actual_array_substr_2.f90, once compiled with current trunk, once with my local tree. The only difference is the ".zero $bignumber" - it's not overly far fetched to link $bignumber with the object file size. It is to assume that I either dropped a required initialization or introduced one that should not be there. Simply reading the diff doesn't help me much as (a) it's rather big by now and (b) whenever I identified a candidate and put a breakpoint there, execution never actually stopped there ^^ Hints where these .zero lines are generated and why, where to put a breakpoint and what to look for -- or anything else that puts me on the right track -- would be appreciated. Thanks Daniel --- actual_array_substr_2.s.orig2009-12-27 04:50:39.0 +0100 +++ actual_array_substr_2.s 2009-12-27 04:48:36.0 +0100 @@ -871,7 +871,9 @@ .type teststring.1574, @object .size teststring.1574, 24 teststring.1574: + .zero 12 .ascii "abc def ghij" + .zero 2102025972 .ascii "klm nop qrst" .align 4 .type m.1571, @object @@ -903,7 +905,9 @@ .type foostring.1518, @object .size foostring.1518, 24 foostring.1518: + .zero 12 .ascii "0123456789#$" + .zero 2102063220 .ascii "$#9876543210" - .ident "GCC: (GNU) 4.5.0 20091226 (experimental)" + .ident "GCC: (GNU) 4.5.0 20091217 (experimental)" .section.note.GNU-stack,"",@progbits [1] http://gcc.gnu.org/ml/fortran/2009-12/msg00170.html
Re: in asm: where does ".zero 2102063220" come from?
On Sunday 27 December 2009 07:09:08 Jerry DeLisle wrote: > Daniel Franke wrote: > > The problem: for some reason the .o file for a small fortran program may > > be blown up to multiple GB. The diff below shows the differences in > > assembler of the testcase gfortran.dg/actual_array_substr_2.f90, once > > compiled with current trunk, once with my local tree. The only difference > > is the ".zero $bignumber" - it's not overly far fetched to link > > $bignumber with the object file size. > > Try to get a look at the -fdump-tree-original output. This should happen > long before any asm is generated. Post it here if you are still stuck. I compiled the testcase in two directories and compared all dumps and the assembler output. None of the dumps differs, but the assembler does?! $ ls local/ trunk/ local/: actual_array_substr_2.f90.003t.original actual_array_substr_2.f90.012t.cfg actual_array_substr_2.f90.041t.release_ssa actual_array_substr_2.f90.004t.gimple actual_array_substr_2.f90.013t.cplxlower0 actual_array_substr_2.f90.042t.inline_param3 actual_array_substr_2.f90.005t.nested actual_array_substr_2.f90.014t.veclower actual_array_substr_2.f90.139t.optimized actual_array_substr_2.f90.006t.vcg actual_array_substr_2.f90.015t.inline_param1 actual_array_substr_2.f90.218t.statistics actual_array_substr_2.f90.008t.omplower actual_array_substr_2.f90.022t.cleanup_cfgactual_array_substr_2.s actual_array_substr_2.f90.009t.lower actual_array_substr_2.f90.024t.ssa actual_array_substr_2.f90.011t.eh actual_array_substr_2.f90.025t.einline2 trunk/: actual_array_substr_2.f90.003t.original actual_array_substr_2.f90.012t.cfg actual_array_substr_2.f90.041t.release_ssa actual_array_substr_2.f90.004t.gimple actual_array_substr_2.f90.013t.cplxlower0 actual_array_substr_2.f90.042t.inline_param3 actual_array_substr_2.f90.005t.nested actual_array_substr_2.f90.014t.veclower actual_array_substr_2.f90.139t.optimized actual_array_substr_2.f90.006t.vcg actual_array_substr_2.f90.015t.inline_param1 actual_array_substr_2.f90.218t.statistics actual_array_substr_2.f90.008t.omplower actual_array_substr_2.f90.022t.cleanup_cfgactual_array_substr_2.s actual_array_substr_2.f90.009t.lower actual_array_substr_2.f90.024t.ssa actual_array_substr_2.f90.011t.eh actual_array_substr_2.f90.025t.einline2 $> diff -ur trunk/ local/ diff -ur trunk/actual_array_substr_2.s local/actual_array_substr_2.s --- trunk/actual_array_substr_2.s 2009-12-27 16:30:24.0 +0100 +++ local/actual_array_substr_2.s 2009-12-27 16:29:27.0 +0100 @@ -871,7 +871,9 @@ .type teststring.1574, @object .size teststring.1574, 24 teststring.1574: + .zero 12 .ascii "abc def ghij" + .zero 1908465300 .ascii "klm nop qrst" .align 4 .type m.1571, @object @@ -903,7 +905,9 @@ .type foostring.1518, @object .size foostring.1518, 24 foostring.1518: + .zero 12 .ascii "0123456789#$" + .zero 1908502548 .ascii "$#9876543210" - .ident "GCC: (GNU) 4.5.0 20091226 (experimental)" + .ident "GCC: (GNU) 4.5.0 20091217 (experimental)"
Re: Regression in gfortran.fortran-torture/execute/st_function.f90
On Saturday 05 May 2007 17:57:30 Paul Richard Thomas wrote: > This has appeared in recent days, with any level of optimization other > than none at all. > > [EMAIL PROTECTED] prs]# /svn-4.3/bin/gfortran -static -O1 > $test/../gfortran.fortran-torture/execute/st_function.f90 > /svn/trunk/gcc/testsuite/gfortran.dg/../gfortran.fortran-torture/execute/st >_function.f90: In function 'MAIN__': > /svn/trunk/gcc/testsuite/gfortran.dg/../gfortran.fortran-torture/execute/st >_function.f90:63: internal compiler error: in expand_expr_real_1, at > expr.c:8833 See PR31095.
FYI: gcc/print-rtl.c (print_rtx) does not build with -Werror
SVN update to revision 124718, configured as: ../../svn/gcc/configure --prefix=/home/daniel/nfs/packages/i686-pc-linux-gnu/gcc --with-gmp=/home/daniel/nfs/packages/i686-pc-linux-gnu/gmp-4.2.1/ --with-mpfr=/home/daniel/nfs/packages/i686-pc-linux-gnu/mpfr-2.2.1 --disable-nls --enable-threads=posix --enable-shared --enable-bootstrap --enable-version-specific-runtime-libs --with-system-zlib --program-suffix=-svn --enable-languages=c,fortran results in: [...] /home/daniel/svn-build/gcc/./prev-gcc/xgcc -B/home/daniel/svn-build/gcc/./prev-gcc/ -B/home/daniel/nfs/packages/i686-pc-linux-gnu/gcc/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../../svn/gcc/gcc -I../../../svn/gcc/gcc/build -I../../../svn/gcc/gcc/../include -I../../../svn/gcc/gcc/../libcpp/include -I/home/daniel/nfs/packages/i686-pc-linux-gnu/gmp-4.2.1//include -I/home/daniel/nfs/packages/i686-pc-linux-gnu/mpfr-2.2.1/include -I../../../svn/gcc/gcc/../libdecnumber -I../../../svn/gcc/gcc/../libdecnumber/bid -I../libdecnumber-o build/print-rtl.o ../../../svn/gcc/gcc/print-rtl.c cc1: warnings being treated as errors ../../../svn/gcc/gcc/print-rtl.c: In function 'print_rtx': ../../../svn/gcc/gcc/print-rtl.c:397: error: format '%lx' expects type 'long unsigned int', but argument 3 has type 'long int' make[3]: *** [build/print-rtl.o] Error 1 Regards Daniel
gcc-4.2 manuals: GNU OpenMP Manual?
Should section "GCC 4.2.0 manuals" of http://gcc.gnu.org/onlinedocs/ not also list the "GNU OpenMP Manual" that is available for 4.2? Thanks Daniel
question on optimizing calls to library functions
Hi all. While looking at PR fortran/22572, I wondered where the difference between the following two programs might be: $> cat matmul.f90 REAL, DIMENSION(1,1), PARAMETER :: a = 1.0, b = 2.0 REAL, DIMENSION(1,1) :: c c = MATMUL(a, b) c = MATMUL(a, b) end $> cat sin.f90 REAL, DIMENSION(1, 1), PARAMETER :: a = 1.0 REAL, DIMENSION(1, 1) :: b, c b = SIN(a) c = SIN(a) end Compiling both with "-Wall -O3 -S -fdump-tree-original -fdump-tree-optimized", one finds that the calls to SIN in sin.f90 have been optimized into nothingness, while MATMUL in matmul.f90 is spelled out twice in the optimized tree dump. The main difference that springs to mind: SIN is built-in, MATMUL is a library function. In gcc/builtin.defs, one finds DEF_LIB_BUILTIN (BUILT_IN_SIN, "sin", BT_FN_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING) with #define ATTR_MATHFN_FPROUNDING (flag_rounding_math ? \ ATTR_PURE_NOTHROW_NOVOPS_LIST : ATTR_CONST_NOTHROW_LIST) Grep'ing the fortran sources, hardly any ATTR_* are used. Would the application of ATTR_MATHFN_FPROUNDING or any other ATTR_* (e.g. ATTR_PURE?) make any difference for the optimizer? If yes, where and how should these attributes be applied to the function symbol? Are these the right questions to ask or am I barking up the wrong tree? Thanks Daniel
Re: Steve Kargle and Daniel Franke - reviewers.
On Saturday 10 January 2009 19:06:48 Toon Moene wrote: > Now, however, I want to congratulate Daniel Franke and Steve Kargle (who > has been a GNU Fortran maintainer before) with their new status of > "reviewer". > > Thanks Daniel and Steve, for (re-)joining the club ! Thanks Toon :) Attached update has been committed as r143269. Regards Daniel Index: ChangeLog === --- ChangeLog (revision 143266) +++ ChangeLog (working copy) @@ -1,3 +1,7 @@ +2009-01-11 Daniel Franke + + * MAINTAINERS: Moved myself to reviewers (Fortran). + 2009-01-06 Thomas Schwinge * MAINTAINERS (OS Port Maintainers): Add myself for GNU/Hurd. Index: MAINTAINERS === --- MAINTAINERS (revision 143266) +++ MAINTAINERS (working copy) @@ -247,6 +247,7 @@ Fortran Janne Blomqvist j...@gcc.gnu.or Fortran Tobias Burnus bur...@net-b.de Fortran Jerry DeLisle jvdeli...@gcc.gnu.org Fortran Erik Edelmann erik.edelm...@iki.fi +Fortran Daniel Franke franke.dan...@gmail.com Fortran Thomas König tkoe...@gcc.gnu.org Fortran Daniel Kraft d...@domob.eu Fortran Toon Moene t...@moene.org @@ -318,7 +319,6 @@ Doug Evans d...@google.com Chris Fairles cfair...@gcc.gnu.org Thomas Fitzsimmonsfitz...@redhat.com Brian Ford f...@vss.fsi.com -Daniel Franke franke.dan...@gmail.com Nathan Froyd froy...@codesourcery.com Chao-ying Fu f...@mips.com Kaveh Ghazi gh...@caip.rutgers.edu
[fortran] spurious initialized warning with select-case?
Hi all. Here's another spurious(?) uninitialized warning. As the full range is implied, the question is, if this a fortran or a middle-end problem: $> cat range.f90 FUNCTION f(n) INTEGER, INTENT(in) :: n REAL:: f SELECT CASE (n) CASE ( :-1); f = -1.0 CASE (0);f = 0.0 CASE (1: ); f = 1.0 END SELECT END FUNCTION $> gfortran-svn -c -O -Wall -fdump-tree-... range.f90 range.f90: In function 'f': range.f90:1: warning: '__result_f' may be used uninitialized in this function After optimization, the dump shows: : switch (*n;) , case -2147483648 ... -1: , case 0: L.3, case 1 ... 2147483647: L.4> Is there any way that 'default' may be reached? Any pointers how to silence this? Thanks Daniel
Re: [fortran] spurious initialized warning with select-case?
On Sunday 05 April 2009 18:56:20 Eric Botcazou wrote:
> > I'm not sure if it would work and I have idea where in trans*.c
> > you need to do this, but if you mark the tree as used with
> > something like
> >
> > TREE_USED (__result_f) = 1
> >
> > the middle-end may be silenced.
>
> I think that TREE_NO_WARNING would be more appropriate for this purpose.
I found that the warning doesn't show up if the testcase is changed:
FUNCTION f(n)
INTEGER, INTENT(in) :: n
REAL:: f
SELECT CASE (n)
CASE ( :-1); f = 0.0 ! was -1.0
CASE (0); f = 0.0
CASE (1: );f = 0.0 ! was 1.0
END SELECT
END FUNCTION
Here, the optimizer removes the select-case completely, so it "knows" that the
full range is covered:
f (integer(kind=4) & n)
{
:
return 0.0;
}
Conclusion: the "default" clause in the generic case is wrong?
Daniel
-f[no-]finite-math-only
Dear all,
some Fortran77 code I inherited gives wrong results if compiled
with '-ffast-math', especially with '-ffinite-math-only' enabled
('-ffast-math -fno-finite-math-only' seems to work).
As '-ffinite-math-only' does "Allow optimizations for floating-point
arithmetic that assume that arguments and results are not NaNs or +-Infs", it
is to assume that the code uses either or both. If so, it's very likely that
this was not intended by the original author.
Any pointers on how to track down these issues in ~25kloc of Fortran77 to
double check what's going on?
Thanks
Daniel
P.S. Not using '-ffast-math' would of course be an option, but knowing that
there might be something fishy going on with NaN/Inf does not improve the
confidence in the application's results ...
