[Bug fortran/113793] New: malloc abort on character allocate with source argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113793 Bug ID: 113793 Summary: malloc abort on character allocate with source argument Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: manfred99 at gmx dot ch Target Milestone: --- Allocating an allocatable character array, I get a malloc error when the source argument is not properly padded: CHARACTER*30,allocatable :: a(:),b(:) ALLOCATE(a(100),source=" ") ALLOCATE(b(100),source=" ") END yields: malloc(): corrupted top size When doing a lame indirection: CHARACTER*30,allocatable :: a(:),b(:) CHARACTER*30 :: c=" " ALLOCATE(a(100),source=c) ALLOCATE(b(100),source=c) END everything is fine. I don't know whether this is mandated by the standard, but the error message is not very user friendly and hard to grasp. I would have expected that the source argument is automatically padded as with variable assignments and function call arguments.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #25 from Manfred Schwarb --- Same issue for MAX1 and MIN1: 88 | ff=MAX1(a, a) | 1 Warning: Change of value in conversion from 'REAL(4)' to 'INTEGER(4)' at (1) [-Wconversion] Surprisingly, I could not provoke a warning for AMAX0 and AMIN0. I will prepare a patch.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #24 from Manfred Schwarb --- Sandra, I will look into this. Probably streamlining the patch to only use *4 and *8 is appropriate.
[Bug bootstrap/100654] trunk bootstrap errors with -O0 and -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100654 --- Comment #2 from Manfred Schwarb --- OK, then I will not report such issues in the future and use --disable-werror per default when using non-standard flags. Thanks.
[Bug bootstrap/100654] New: trunk bootstrap errors with -O0 and -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100654 Bug ID: 100654 Summary: trunk bootstrap errors with -O0 and -O1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: manfred99 at gmx dot ch Target Milestone: --- linux x86_64 and i686 (GCC 7.5 as bootstrap compiler), with BOOT_CFLAGS="-O0 -g": ../../gcc-trunk-source/gcc/gcc/opts.c: In function 'void print_filtered_help(unsigned int, unsigned int, unsigned int, unsigned int, gcc_options*, unsigned int)': ../../gcc-trunk-source/gcc/gcc/opts.c:1406:26: error: ' ' directive output may be truncated writing 2 bytes into a region of size between 1 and 256 [-Werror=format-truncation=] 1406 | "%s %s", help, _(use_diagnosed_msg)); | ^~ ../../gcc-trunk-source/gcc/gcc/opts.c:1405:22: note: 'snprintf' output 3 or more bytes (assuming 258) into a destination of size 256 1405 | snprintf (new_help, sizeof new_help, | ~^~~ 1406 | "%s %s", help, _(use_diagnosed_msg)); | ~ last successful bootstrap for my daily builds with "-O0" was 99e8df7a4cc0bb1bfa49e69ccb0f7e02c9755e3c (2021-05-05). with BOOT_CFLAGS="-O1 -g": ../../gcc-trunk-source/gcc/gcc/gimplify.c: In function 'gimplify_status gimplify_omp_loop(tree_node**, gimple**)': ../../gcc-trunk-source/gcc/gcc/gimplify.c:12967:17: error: 'last' may be used uninitialized in this function [-Werror=maybe-uninitialized] 12967 | if (pass != last) | ^~ trunk builds fine with "-O2" however.
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 --- Comment #5 from Manfred Schwarb --- This might have been solved by https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=ac932bfcd21e9523fa2b880ae8138aef79da7f54 , at least I don't see it anymore in today's build. As the crash of class_61.f90 is a bit difficult to reproduce, additional confirmation might be needed.
[Bug fortran/95687] ICE in get_unique_hashed_string, at fortran/class.c:508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95687 Manfred Schwarb changed: What|Removed |Added CC||manfred99 at gmx dot ch --- Comment #6 from Manfred Schwarb --- This might have solved PR89661, at least I don't see it anymore in today's build. As the crash of class_61.f90 is a bit difficult to reproduce, additional confirmation might be needed.
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment #4 from Manfred Schwarb ---
I see it too on i686 for current trunk: Instrumenting the testsuite checks with
/usr/bin/env LIBC_FATAL_STDERR_=1 MALLOC_PERTURB_=B MALLOC_CHECK_=3 make check
9 | class(t2), pointer :: q(2) ! { dg-error "must have a deferred
shape" }
| 1
Error: Pointer array component of structure at (1) must have a deferred shape
f951: internal compiler error: Segmentation fault
0x8e61e8d crash_signal
../../gcc-trunk-source/gcc/gcc/toplev.c:328
0x860f511 resolve_component
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:14318
0x86107fb resolve_fl_derived0
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:14753
0x8610d29 resolve_fl_derived
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:14882
0x8611ad0 resolve_symbol
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:15251
0x8636a81 do_traverse_symtree
../../gcc-trunk-source/gcc/gcc/fortran/symbol.c:4150
0x8636b18 gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
../../gcc-trunk-source/gcc/gcc/fortran/symbol.c:4175
0x8615988 resolve_types
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:17175
0x8615dd8 gfc_resolve(gfc_namespace*)
../../gcc-trunk-source/gcc/gcc/fortran/resolve.c:17290
0x85eb469 resolve_all_program_units
../../gcc-trunk-source/gcc/gcc/fortran/parse.c:6245
0x85ebb66 gfc_parse_file()
../../gcc-trunk-source/gcc/gcc/fortran/parse.c:6492
0x864043d gfc_be_parse_file
../../gcc-trunk-source/gcc/gcc/fortran/f95-lang.c:210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
With valgrind, the following analysis is shown:
==72395== Invalid read of size 4
==72395==at 0x860F4C3: resolve_component(gfc_component*, gfc_symbol*)
(resolve.c:14304)
==72395==by 0x86107FB: resolve_fl_derived0(gfc_symbol*) (resolve.c:14753)
==72395==by 0x8610D29: resolve_fl_derived(gfc_symbol*) (resolve.c:14882)
==72395==by 0x8611AD0: resolve_symbol(gfc_symbol*) (resolve.c:15251)
==72395==by 0x8636A81: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) (symbol.c:4150)
==72395==by 0x8636B18: gfc_traverse_ns(gfc_namespace*, void
(*)(gfc_symbol*)) (symbol.c:4175)
==72395==by 0x8615988: resolve_types(gfc_namespace*) (resolve.c:17175)
==72395==by 0x8615DD8: gfc_resolve(gfc_namespace*) (resolve.c:17290)
==72395==by 0x85EB469: resolve_all_program_units(gfc_namespace*)
(parse.c:6245)
==72395==by 0x85EBB66: gfc_parse_file() (parse.c:6492)
==72395==by 0x864043D: gfc_be_parse_file() (f95-lang.c:210)
==72395==by 0x8E62281: compile_file() (toplev.c:458)
==72395== Address 0x46e99e4 is 116 bytes inside a block of size 204 free'd
==72395==at 0x4031B37: free (in
/usr/lib64/valgrind/vgpreload_memcheck-x86-linux.so)
==72395==by 0x8635090: gfc_free_symbol(gfc_symbol*) (symbol.c:3096)
==72395==by 0x863515D: gfc_release_symbol(gfc_symbol*) (symbol.c:3123)
==72395==by 0x8635FCA: gfc_restore_last_undo_checkpoint() (symbol.c:3700)
==72395==by 0x863606B: gfc_undo_symbols() (symbol.c:3731)
==72395==by 0x85E60B0: reject_statement() (parse.c:2633)
==72395==by 0x85DE291: match_word(char const*, match (*)(), locus*)
(parse.c:70)
==72395==by 0x85DEE43: decode_statement() (parse.c:376)
==72395==by 0x85E4A6F: next_free() (parse.c:1279)
==72395==by 0x85E500C: next_statement() (parse.c:1511)
==72395==by 0x85E7256: parse_derived() (parse.c:3342)
==72395==by 0x85E7F06: parse_spec(gfc_statement) (parse.c:3883)
==72395== Block was alloc'd at
==72395==at 0x4032CC6: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-x86-linux.so)
==72395==by 0x9F4F125: xcalloc (xmalloc.c:162)
==72395==by 0x863517D: gfc_new_symbol(char const*, gfc_namespace*)
(symbol.c:3134)
==72395==by 0x86356A0: gfc_get_sym_tree(char const*, gfc_namespace*,
gfc_symtree**, bool) (symbol.c:3368)
==72395==by 0x863584F: gfc_get_symbol(char const*, gfc_namespace*,
gfc_symbol**) (symbol.c:3421)
==72395==by 0x855E4D3: gfc_match_decl_type_spec(gfc_typespec*, int)
(decl.c:4494)
==72395==by 0x8560A37: gfc_match_data_decl() (decl.c:6119)
==72395==by 0x85DE270: match_word(char const*, match (*)(), locus*)
(parse.c:65)
==72395==by 0x85DEE43: decode_statement() (parse.c:376)
==72395==by 0x85E4A6F: next_free() (parse.c:1279)
==72395==by 0x85E500C: next_statement() (parse.c:1511)
==72395==by 0x85E7256: parse_derived() (parse.c:3342)
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 --- Comment #10 from Manfred Schwarb --- I just tried to build a compiler with "-fno-omit-frame-pointer" to get potentially better backtraces, but then the ICE vanishes ... Is there a way to get useful backtraces? "--enable-checking=yes,extra" seems not to be enough...
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090
--- Comment #9 from Manfred Schwarb ---
I sprinkled some printf's into get_unique_type_string():
XXderived->name: strlen=63;
t2345678901234567890123456789012345678901234567890123456789_123
XXdt_name: strlen=63;
T2345678901234567890123456789012345678901234567890123456789_123
XXderived->ns->proc_name->name: strlen=63;
m2345678901234567890123456789012345678901234567890123456789_123
XXstring: strlen=127;
m2345678901234567890123456789012345678901234567890123456789_123_T2345678901234567890123456789012345678901234567890123456789_123
XXderived->name: strlen=66;
Pdtt2345678901234567890123456789012345678901234567890123456789_123
XXdt_name: strlen=66;
Pdtt2345678901234567890123456789012345678901234567890123456789_123
XXderived->ns->proc_name->name: strlen=63;
m2345678901234567890123456789012345678901234567890123456789_123
XXstring: strlen=130;
m2345678901234567890123456789012345678901234567890123456789_123_Pdtt2345678901234567890123456789012345678901234567890123456789_123
XXderived->name: strlen=66;
Pdtt2345678901234567890123456789012345678901234567890123456789_123
XXdt_name: strlen=66;
Pdtt2345678901234567890123456789012345678901234567890123456789_123
XXderived->ns->proc_name->name: strlen=63;
m2345678901234567890123456789012345678901234567890123456789_123
XXstring: strlen=130;
m2345678901234567890123456789012345678901234567890123456789_123_Pdtt2345678901234567890123456789012345678901234567890123456789_123
If both string lengths get upped by 3, things get working:
get_unique_type_string (char *string, gfc_symbol *derived)
{
- char dt_name[GFC_MAX_SYMBOL_LEN+1];
+ char dt_name[GFC_MAX_SYMBOL_LEN+4];
get_unique_hashed_string (char *string, gfc_symbol *derived)
{
- char tmp[2*GFC_MAX_SYMBOL_LEN+2];
+ char tmp[2*GFC_MAX_SYMBOL_LEN+5];
So with these changes, I get no ICE anymore.
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 --- Comment #8 from Manfred Schwarb --- I even tried "char tmp[2*GFC_MAX_SYMBOL_LEN+800];" but it still fails.
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 --- Comment #5 from Manfred Schwarb --- gdb shows: Program received signal SIGSEGV, Segmentation fault. 0xf7aa5162 in __strlen_sse2_bsf () from /lib/libc.so.6 #0 0xf7aa5162 in __strlen_sse2_bsf () from /lib/libc.so.6 #1 0x083e6def in get_unique_hashed_string(char*, gfc_symbol*) () #2 0x083e7754 in gfc_find_derived_vtab(gfc_symbol*) () #3 0x0847ef21 in resolve_fl_derived(gfc_symbol*) () #4 0x0847b857 in resolve_symbol(gfc_symbol*) () #5 0x084a6a10 in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*), void (*)(gfc_symbol*)) () #6 0x084870b7 in resolve_types(gfc_namespace*) () #7 0x0847a825 in gfc_resolve(gfc_namespace*) () #8 0x0846db96 in gfc_parse_file() () #9 0x084bdd27 in gfc_be_parse_file() () #10 0x08a3a6de in compile_file() () #11 0x083c8b15 in toplev::main(int, char**) () #12 0x083ccc21 in main ()
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 Manfred Schwarb changed: What|Removed |Added CC||manfred99 at gmx dot ch --- Comment #4 from Manfred Schwarb --- This breaks for me in i686, see http://gfortran.meteodat.ch/download/i686/nightlies/gcc-trunk-20200528-gfe7ebef7fe4f9acb79658ed9db0749b07efc3105-README.txt See also HJ's test in https://gcc.gnu.org/pipermail/gcc-testresults/2020-May/562121.html x86_64 seems is OK. Error message is not really revealing: Executing on host: /tmp/gcc-trunk-32bit-build/gcc/testsuite/gfortran2/../../gfortran -B/tmp/gcc-trunk-32bit-build/gcc/testsuite/gfortran2/../../ -B/tmp/gcc-trunk-32bit-build/i686-linux/./libgfortran/ /tmp/gcc-trunk-source/gcc/gcc/testsuite/gfortran.dg/pr95090.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never-O -fcoarray=lib -fsecond-underscore -S -o pr95090.s(timeout = 300) spawn -ignore SIGHUP /tmp/gcc-trunk-32bit-build/gcc/testsuite/gfortran2/../../gfortran -B/tmp/gcc-trunk-32bit-build/gcc/testsuite/gfortran2/../../ -B/tmp/gcc-trunk-32bit-build/i686-linux/./libgfortran/ /tmp/gcc-trunk-source/gcc/gcc/testsuite/gfortran.dg/pr95090.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O -fcoarray=lib -fsecond-underscore -S -o pr95090.s f951: internal compiler error: Segmentation fault 0x83cf0ac ??? ../sysdeps/i386/start.S:117 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. compiler exited with status 1 FAIL: gfortran.dg/pr95090.f90 -O (internal compiler error)
[Bug testsuite/95008] [11 regression] excess errors in gcc.dg/analyzer/pr93382.c and gcc.dg/two-types-6.c after r11-169
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95008
--- Comment #2 from Manfred Schwarb ---
gcc.dg/analyzer/pr93382.c: Sorry, I can't reproduce, this test passes for me.
gcc.dg/two-types-6.c: My bad, I forgot to mention this failure, as this
test did not make sense to me. I could not determine what the actual
intention of the test is. And the test nameing does not help either.
And finally it fell through the cracks, bah...
There should be a warning for the "struct f" line, no?
At the moment there is no warning, and so my correction triggered the
error.
If one adds a semicolon, there is the expected "does not declare anything",
but then there is no second error any more, so it fails, too.
To silence it, one could simply do
--- a/gcc/testsuite/gcc.dg/two-types-6.c
+++ b/gcc/testsuite/gcc.dg/two-types-6.c
@@ -2,6 +2,6 @@
/* { dg-options "-std=gnu89" } // suppress default -pedantic-errors */
struct s {
- struct f {} /* { dg-warning "does not declare anything" } */
+ struct f {}
struct g {} x; /* { dg-error "expected ';', identifier or " } */
};
Or, to get both, one could do
--- a/gcc/testsuite/gcc.dg/two-types-6.c
+++ b/gcc/testsuite/gcc.dg/two-types-6.c
@@ -2,6 +2,7 @@
/* { dg-options "-std=gnu89" } // suppress default -pedantic-errors */
struct s {
- struct f {} /* { dg-warning "does not declare anything" } */
+ struct e {}; /* { dg-warning "does not declare anything" } */
+ struct f {}
struct g {} x; /* { dg-error "expected ';', identifier or " } */
};
[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739 --- Comment #9 from Manfred Schwarb --- Patch seems to work so far. Do you need any logfiles?
[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739 --- Comment #8 from Manfred Schwarb --- Created attachment 48384 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48384&action=edit libiberty/config.log The full logfile of libiberty. I will apply the patch now and will report back.
[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment #4 from Manfred Schwarb ---
This broke my i686 build (only, x86_64 build with same settings is OK), I get
configure: error: Intel CET must be enabled on Intel CET enabled host
make[2]: *** [configure-stage2-lto-plugin] Error 1
make[2]: *** Waiting for unfinished jobs
configure: error: Intel CET must be enabled on Intel CET enabled host
make[2]: *** [configure-stage2-libiberty] Error 1
both in prev-libiberty/config.log and prev-lto-plugin/config.log there is
configure:5283: checking for CET support
configure:5312: gcc -march=i686 -m32 -Wa,--32 -c -g -fcf-protection conftest.c
>&5
gcc: error: unrecognized command line option '-fcf-protection'
configure:5312: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define _TANDEM_SOURCE 1
| #define _FILE_OFFSET_BITS 64
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| #if !defined(__SSE2__)
| #error target does not support multi-byte NOPs
| #else
| asm ("setssbsy");
| #endif
|
| ;
| return 0;
| }
My configure command is
#> ../gcc-trunk-source/gcc/configure --enable-languages=c,c++,fortran
--enable-checking=yes,extra --disable-libstdcxx-pch --enable-libgomp
--enable-lto --enable-gold --with-plugin-ld=gold
--prefix=/usr/local/gcc-trunk-32bit i686-linux
and then I issue the make command with
#> make -j4 BOOT_CFLAGS="-g -O2" bootstrap2-lean
As mentioned above, the very same commands (without the "i686-linux" configure
argument) work fine to build x86_64 binaries.
[Bug analyzer/93276] New: Build error of current trunk indicating "#pragma GCC diagnostic not allowed inside functions"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93276 Bug ID: 93276 Summary: Build error of current trunk indicating "#pragma GCC diagnostic not allowed inside functions" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: manfred99 at gmx dot ch Target Milestone: --- Current trunk (as of today 2020-01-15) does not bootstrap for me on x86_64, with errors in stage 1, in the analyzer directory: ../../gcc-trunk-source/gcc/gcc/analyzer/constraint-manager.cc:121:1: error: #pragma GCC diagnostic not allowed inside functions ... ../../gcc-trunk-source/gcc/gcc/analyzer/region-model.cc:89:1: error: #pragma GCC diagnostic not allowed inside functions ... This is with # gcc --version gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585] Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Is there a new minimum version of GCC for bootstapping or do I miss something else? My build environment worked fine for several years now, on a daily base, and stopped working with the checkin of the analyzer branch.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #19 from Manfred Schwarb --- Created attachment 46963 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46963&action=edit extended patch from comment #4 to also cover gfc_simplify_dble and gfc_simplify_sngl Note, I do not have neither commit rights nor assigment. Supresses all warnings of the test in comment #9 and regtests cleanly.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #17 from Manfred Schwarb --- Here is the documentation fallout I mentioned, previous attachment. And probably a lot of @multitable @columnfractions .20 .20 .20 .25 entries should be widened for the last column, as "Fortran 77 and later" and alike does not fit in a normal 80char Terminal, otherwise.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #16 from Manfred Schwarb --- Created attachment 46873 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46873&action=edit documentation changes for conversion intrinsics
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #14 from Manfred Schwarb --- >FWIW, I briefly looked at conversions of complex variables >and did not find any similar -Wconversion warnings for a patched compiler. Well, I only looked at REAL,REALPART,AIMAG,IMAG,IMAGPART,DIMAG. For CMPLX, there is some warning: complex(4) ww complex(8) xx ww=CMPLX(1.0_8, 1.0_8) ww=CMPLX(1.0_8, 1.0_8, kind=4) ww=COMPLEX(1.0_8, 1.0_8) xx=CMPLX(1.0_10, 1.0_10) xx=CMPLX(1.0_10, 1.0_10, kind=8) xx=COMPLEX(1.0_10, 1.0_10) end c.f:4:15: 4 | ww=CMPLX(1.0_8, 1.0_8) | 1 Warning: Conversion from REAL(8) to default-kind COMPLEX(4) at (1) might lose precision, consider using the KIND argument [-Wconversion] c.f:7:15: 7 | xx=CMPLX(1.0_10, 1.0_10) | 1 Warning: Conversion from REAL(10) to default-kind COMPLEX(4) at (1) might lose precision, consider using the KIND argument [-Wconversion] This seems very reasonable though, no warnings when using an explicit kind statement. So no action needed here, from my point of view.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #13 from Manfred Schwarb --- FWIW, I briefly looked at conversions of complex variables and did not find any similar -Wconversion warnings for a patched compiler.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #11 from Manfred Schwarb --- >> !---LONG not allowed anymore in gfortran 10 (?): >> !!ff=LONG(a) >> !!ff=LONG(b) >> !!ff=LONG(c) >> !!ff=LONG(d) >> !!ff=LONG(g) > >LONG was removed by by BOZ patch. It was documented >to convert its argument to C's 32-bit long type. Not >a good thing as long can be 64-bit. Note, SHORT was >also removed. Fortunately, LONG and SHORT were in-line >conversion, so no change to libgfortran was needed. Well, the error message is 92 | ff=LONG(a) | 1 Error: 'long' intrinsic subprogram at (1) has been deprecated. Use INT intrinsic subprogram. The message talks about "deprecated", so I assumed I could eliminate this error with "-std=legacy" or something similar. But in fact you have deleted this feature. This is very OK for me, but I find the message a bit confusing.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #9 from Manfred Schwarb --- Hi Steve, I tried your patch in comment 4, it is a good starting point. However, SNGL and DBLE still throw warnings: real*4 a,aa real*8 b,bb real*10 c,cc real*16 d integer*2 e,ee integer*4 f,ff integer*8 g,gg PARAMETER(a=3.1415927_4) PARAMETER(b=3.1415927_8) PARAMETER(c=3.1415927_10) PARAMETER(d=3.1415927_16) PARAMETER(e=123_2) PARAMETER(f=123_4) PARAMETER(g=123_8) aa=REAL(b) aa=REAL(c) aa=REAL(d) aa=REAL(e) aa=REAL(f) aa=REAL(g) aa=FLOAT(f) aa=FLOOR(b) aa=FLOOR(c) aa=FLOOR(d) aa=CEILING(b) aa=CEILING(c) aa=CEILING(d) !---unknown but documented type conversions: !!aa=FLOATI(e) !!aa=FLOATJ(f) !!aa=FLOATK(g) !---documentation is wrong for sngl: aa=SNGL(c) aa=SNGL(d) bb=REAL(c, kind=8) bb=REAL(d, kind=8) bb=DBLE(c) bb=DBLE(d) bb=DFLOAT(g) bb=FLOOR(c) bb=FLOOR(d) bb=CEILING(c) bb=CEILING(d) cc=REAL(d, kind=10) cc=FLOOR(d) cc=CEILING(d) aa=AINT(b) aa=ANINT(b) aa=AINT(c) aa=ANINT(c) aa=AINT(d) aa=ANINT(d) bb=DINT(b) bb=DNINT(b) ee=INT(a, kind=2) ee=NINT(a, kind=2) ee=INT(b, kind=2) ee=NINT(b, kind=2) ee=INT(c, kind=2) ee=NINT(c, kind=2) ee=INT(d, kind=2) ee=NINT(d, kind=2) ee=INT(f, kind=2) ee=INT(g, kind=2) ee=IFIX(a) ee=IDINT(b) ee=IDNINT(b) ee=INT2(a) ee=INT2(b) ee=INT2(c) ee=INT2(d) ee=INT2(f) ee=INT2(g) ff=INT(a, kind=4) ff=NINT(a, kind=4) ff=INT(b, kind=4) ff=NINT(b, kind=4) ff=INT(c, kind=4) ff=NINT(c, kind=4) ff=INT(d, kind=4) ff=NINT(d, kind=4) ff=INT(f, kind=4) ff=INT(g, kind=4) ff=IFIX(a) ff=IDINT(b) ff=IDNINT(b) !---LONG not allowed anymore in gfortran 10 (?): !!ff=LONG(a) !!ff=LONG(b) !!ff=LONG(c) !!ff=LONG(d) !!ff=LONG(g) gg=INT(a, kind=8) gg=NINT(a, kind=8) gg=INT(b, kind=8) gg=NINT(b, kind=8) gg=INT(c, kind=8) gg=NINT(c, kind=8) gg=INT(d, kind=8) gg=NINT(d, kind=8) gg=INT(f, kind=8) gg=INT(g, kind=8) gg=IFIX(a) gg=IDINT(b) gg=IDNINT(b) gg=INT8(a) gg=INT8(b) gg=INT8(c) gg=INT8(d) gg=INT8(g) end a.f:34:14: 34 | aa=SNGL(c) | 1 Warning: Change of value in conversion from 'REAL(10)' to 'REAL(4)' at (1) [-Wconversion] a.f:35:14: 35 | aa=SNGL(d) | 1 Warning: Change of value in conversion from 'REAL(16)' to 'REAL(4)' at (1) [-Wconversion] a.f:38:14: 38 | bb=DBLE(c) | 1 Warning: Change of value in conversion from 'REAL(10)' to 'REAL(8)' at (1) [-Wconversion] a.f:39:14: 39 | bb=DBLE(d) | 1 Warning: Change of value in conversion from 'REAL(16)' to 'REAL(8)' at (1) [-Wconversion]
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #7 from Manfred Schwarb --- Hopefully this rings some bells: The warnings happen only for parameters: real b double precision a,c,d PARAMETER(a=3.1415927d0) DATA c /3.1415927d0/ d=3.1415927d0 b=REAL(a) b=REAL(a, kind=4) b=REAL(c) b=REAL(d) end a.f:8:13: 8 | b=REAL(a) | 1 Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1) [-Wconversion] a.f:9:13: 9 | b=REAL(a, kind=4) | 1 Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1) [-Wconversion] Thanks for your efforts!
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 Manfred Schwarb changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Manfred Schwarb --- Of course. But not being able to silence such warnings renders this option rather useless, IMO. I would have expected that explicit castings would have been special-cased in some way... And the manual talks explicitely about implicit conversion: -Wconversion Warn about implicit conversions ...
[Bug fortran/91497] New: -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 Bug ID: 91497 Summary: -Wconversion warns when doing explicit type conversion Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: manfred99 at gmx dot ch Target Milestone: --- real b double precision a PARAMETER(a=3.1415927d0) b=REAL(a) b=REAL(a, kind=4) end gives a.f:5:13: 5 | b=REAL(a) | 1 Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1) [-Wconversion] a.f:6:13: 6 | b=REAL(a, kind=4) | 1 Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1) [-Wconversion] for current trunk (no new regression though). gfortran should not warn about explicit type conversions with REAL(), INT() etc. Otherwise there is no possibility to silence this warning.
[Bug fortran/88536] [9 Regression] i686 testsuite errors for %re, %im, %len and %kind features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536
--- Comment #7 from Manfred Schwarb ---
Thanks Jakub for the debug hint, and thanks Dominique for finding the
duplicate.
Indeed, my backtrace also points to simplify_ref_chain:
# gdb --quiet `/usr/local/gcc-trunk-32bit/bin/gcc -print-prog-name=f951`
Reading symbols from
/usr/local/gcc-trunk-32bit/libexec/gcc/i686-linux/9.0.0/f951...done.
(gdb) run /tmp/gcc-trunk-source/gcc/gcc/testsuite/gfortran.dg/pr87945_1.f90
Starting program: /usr/local/gcc-trunk-32bit/libexec/gcc/i686-linux/9.0.0/f951
/tmp/gcc-trunk-source/gcc/gcc/testsuite/gfortran.dg/pr87945_1.f90
/tmp/gcc-trunk-source/gcc/gcc/testsuite/gfortran.dg/pr87945_1.f90:5:13:
5 |data a%len /1/ ! { dg-error "parameter cannot appear in" }
| 1
Error: Inquiry parameter cannot appear in a data-stmt-object-list at (1)
Program received signal SIGSEGV, Segmentation fault.
0x083debd5 in simplify_ref_chain(gfc_ref*, int, gfc_expr**) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
414 gcc_assert (lo < hi);
(gdb) bt
#0 0x083debd5 in simplify_ref_chain(gfc_ref*, int, gfc_expr**) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#1 0x083de5bc in gfc_simplify_expr(gfc_expr*, int) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#2 0x08435f2b in gfc_match_varspec(gfc_expr*, int, bool, bool) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#3 0x08436719 in match_variable(gfc_expr**, int, int) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#4 0x083c1fa7 in var_element(gfc_data_variable*) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#5 0x083c3e98 in gfc_match_data() () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#6 0x08428b4a in match_word () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#7 0x0842a5ea in decode_statement() () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#8 0x0842d0a5 in next_statement() () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#9 0x0842e9ff in parse_spec(gfc_statement) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#10 0x08430eaa in parse_progunit(gfc_statement) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#11 0x08432153 in gfc_parse_file() () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#12 0x08479649 in gfc_be_parse_file() () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#13 0x0897ce7d in compile_file() () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#14 0x083a01cf in toplev::main(int, char**) () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
#15 0x083a3c31 in main () at
../../../gcc-trunk-source/gcc/libgcc/unwind-dw2-fde-dip.c:414
[Bug fortran/88536] [9 Regression] i686 testsuite errors for %re, %im, %len and %kind features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536 --- Comment #3 from Manfred Schwarb --- BTW, the build logs (*README.txt) are here: http://gfortran.meteodat.ch/download/i686/nightlies/
[Bug fortran/88536] [9 Regression] i686 testsuite errors for %re, %im, %len and %kind features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536 --- Comment #2 from Manfred Schwarb --- ./gfortran -v output: Using built-in specs. COLLECT_GCC=/usr/local/gcc-trunk-32bit/bin/gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk-32bit/bin/../libexec/gcc/i686-linux/9.0.0/lto-wrapper Target: i686-linux Configured with: ../gcc-trunk-source/gcc/configure --enable-languages=c,c++,fortran --enable-checking=yes,extra --disable-libstdcxx-pch --enable-libgomp --enable-lto --enable-gold --with-plugin-ld=gold --prefix=/usr/local/gcc-trunk-32bit i686-linux Thread model: posix gcc version 9.0.0 20181218 (experimental) [trunk revision 267225] (GCC) This build of the 32bit compiler is made in an OpenSuse 11.4 x86_64 environment using glibc 2.11.3
[Bug fortran/88536] New: i686 testsuite errors for %re, %im, %len and %kind features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88536 Bug ID: 88536 Summary: i686 testsuite errors for %re, %im, %len and %kind features Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: manfred99 at gmx dot ch Target Milestone: --- Since several weeks I get testsuite errors for the i686 target (x86_64 is OK) which relate to the %re, %im, %len and %kind features: gfortran.dg/inquiry_type_ref_1.f08 gfortran.dg/inquiry_type_ref_3.f90 gfortran.dg/pr87945_1.f90 gfortran.dg/pr87945_2.f90 gfortran.dg/pr87994_1.f90 gfortran.dg/pr87994_2.f90 gfortran.dg/pr87994_3.f90 Unfortunately, the error messages are not really helpful: f951: internal compiler error: Segmentation fault 0x838c18c ??? ../sysdeps/i386/elf/start.S:119 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. I was not able to further track down these errors. Related bug reports are PR40196, PR87945 and PR87994.
[Bug fortran/40196] [F03] [F08] Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40196
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment #15 from Manfred Schwarb ---
Paul, these three tests fail for me on x86 (32bit) since you
introduced them (x86_64 is OK). Unfortunately, the error message is not
really helpful:
f951: internal compiler error: Segmentation fault
0x838c18c ???
../sysdeps/i386/elf/start.S:119
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
The compiler barfs at all of the following lines, in the very same way:
inquiry_type_ref_1.f08:
REAL, parameter :: rc = zc%re
REAL, parameter :: ic = zc%im
if (str%kind .ne. kind (str)) stop 6
inquiry_type_ref_2.f90:
a%len = 2 ! { dg-error "Fortran 2003: LEN part_ref" }
i = a%kind ! { dg-error "Fortran 2003: KIND part_ref" }
inquiry_type_ref_3.f90:
a%kind = 2! { dg-error "Assignment to a constant expression" }
As already told, x86_64 is OK. No idea if this is specific to my compile
setting. The rest of the test-suite passes more or less OK for me, so ...
[Bug libfortran/78549] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 --- Comment #29 from Manfred Schwarb --- Here are the results from my test case from PR82938 (without the "print*,f" statement, which consumes ~1s): 1.1s for GNU Fortran (GCC) 8.0.0 20170828 (experimental) [trunk revision 251373] 3.3s for GNU Fortran (GCC) 8.0.0 20170829 (experimental) [trunk revision 251395] 1.3s for GNU Fortran (GCC) 8.0.0 20171123 (experimental) [trunk revision 255090] 0.4s for version with Fortran wrapper of C function strtof() So, with Jerry's patch gfortran is now only a little slower than before the DTIO patches, so still some minor regression for internal read. But there is still some large gap compared to the C routine version...
[Bug fortran/82938] New: Speed regression in internal read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82938 Bug ID: 82938 Summary: Speed regression in internal read Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: manfred99 at gmx dot ch Target Milestone: --- #!/bin/sh seq --format="%.1f" 1 100 > read.txt cat > read.f </dev/null On my box, this short program takes 2.4s for GNU Fortran (GCC) 8.0.0 20170828 (experimental) [trunk revision 251373] 4.4s for GNU Fortran (GCC) 8.0.0 20170829 (experimental) [trunk revision 251395] This is most likely due to http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=251374 Of these 4.4s, about 4s are solely taken by the line "read(buffer,'(f12.0)') f". It is really "amazing" how slow internal read is, compare e.g. with a C program ... This issue clearly shows as a regression in a operational program of mine, so no artificial, constructed issue.
[Bug fortran/53029] missed optimization in internal read (without implied-do-loop)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53029 --- Comment #6 from Manfred Schwarb --- Will do tomorrow. Thanks for your patch, I hadn't seen your comments here when I wrote my comment to bug 35339 ... We had seemingly the same association when reading nicolas' patch.
[Bug fortran/35339] Improve translation of implied do loop in transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35339 Manfred Schwarb changed: What|Removed |Added CC||manfred99 at gmx dot ch --- Comment #10 from Manfred Schwarb --- As I understand this patch applies to read and write. How does this optimization behave regarding my pet issue (short array reads)? I.e. program internalread integer m parameter(m=1000) character value*10 integer i,j,intvalues(m) DO j=1,100 write(value,'(i3,a5)') j," 5 69" CCread(value,*,end=20) (intvalues(i),i=1,m) read(value,*,end=20) intvalues 20 print*,"20" write(*,*) j,i ENDDO end program internalread On my box this is 2.8s vs. 31s, i.e. the array version is more than 10 times slower than the implied do loop.
[Bug fortran/77707] New: [4.5-7.0 Regression] formatted direct access: nextrec off by one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77707 Bug ID: 77707 Summary: [4.5-7.0 Regression] formatted direct access: nextrec off by one Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: manfred99 at gmx dot ch Target Milestone: --- program directaccess_formatted integer nextrec open(10, file='directaccess_formatted.dat', form='formatted', access='direct', recl=10*4) write(10,'(10i4)',rec=9) 1,2,3,4,5,6,7,8,9,10 inquire(unit=10,nextrec=nextrec) print*,"Next rec: ",nextrec close(10) end prints the following: 4.3: Next rec: 10 4.5-7.0: Next rec:9 As I have no working gfortran 4.4 any more, I can't tell whether 4.4 is OK or not. nextrec is "last record read or written, plus one". In contrast, unformatted direct access is OK and prints "10". Possibly related bugs: Bug 14836, Bug 14904
[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741 Manfred Schwarb changed: What|Removed |Added CC||manfred99 at gmx dot ch --- Comment #33 from Manfred Schwarb --- There is some slight improvement since 2015-09-08: before: #> a 17.848000310.2399871 #> grep "number of SCoPs" a.f90.124t.graphite number of SCoPs: 0 number of SCoPs: 2 after: #> a 15.84710.2399871 #> grep "number of SCoPs" a.f90.121t.graphite number of SCoPs: 0 number of SCoPs: 1 which also gives a testsuite warning on my box: XPASS: gfortran.dg/graphite/pr14741.f90 -O scan-tree-dump-times graphite "number of SCoPs: 1" 1
[Bug c++/66255] [6 Regression] ice in retrieve_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66255 Manfred Schwarb changed: What|Removed |Added CC||manfred99 at gmx dot ch --- Comment #6 from Manfred Schwarb --- I just got ../../gcc-trunk-source/gcc/gcc/cp/pt.c:1026:29: error: unused parameter 'args' [-Werror=unused-parameter] check_unstripped_args (tree args) ^ cc1plus: all warnings being treated as errors make[3]: *** [cp/pt.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [bootstrap2-lean] Error 2 the whole code is encapsulated with #ifdef ENABLE_CHECKING ...
[Bug bootstrap/65971] bootstrap fails with "multiple definition of '__cpu_indicator_init'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65971 --- Comment #2 from Manfred Schwarb --- Hmm, that's a pretty new binutils version. So it is not possible any more to build GCC on somewhat older installations? This seems not to be documented at https://gcc.gnu.org/install/specific.html, at least.
[Bug bootstrap/65971] New: bootstrap fails with "multiple definition of '__cpu_indicator_init'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65971 Bug ID: 65971 Summary: bootstrap fails with "multiple definition of '__cpu_indicator_init'" Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: manfred99 at gmx dot ch Target Milestone: --- Since 2015-04-17 (probably since https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=222178), my bootstrap of trunk fails with gold: error: cpuinfo_s.o: multiple definition of '__cpu_indicator_init' gold: cpuinfo_s.o: previous definition here gold: error: cpuinfo_s.o: multiple definition of '__cpu_model' gold: cpuinfo_s.o: previous definition here collect2: error: ld returned 1 exit status make[3]: *** [libgcc_s.so] Error 1 make[3]: *** Waiting for unfinished jobs gold: error: cpuinfo_s.o: multiple definition of '__cpu_indicator_init' gold: cpuinfo_s.o: previous definition here gold: error: cpuinfo_s.o: multiple definition of '__cpu_model' gold: cpuinfo_s.o: previous definition here collect2: error: ld returned 1 exit status make[5]: *** [libgcc_s.so] Error 1 make[4]: *** [multi-do] Error 1 make[3]: *** [all-multi] Error 2 make[2]: *** [all-stage1-target-libgcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [bootstrap2-lean] Error 2 before this date everything was fine. Are there any new prerequisites on the build environment? I build with ../build/configure \ --enable-languages=c,c++,fortran \ --enable-checking=release \ --disable-libstdcxx-pch --enable-libgomp \ --enable-lto --enable-gold --with-plugin-ld=gold make BOOT_CFLAGS="-g -O2" bootstrap2-lean with gcc 4.5.1, glibc 2.11.3 and binutils 2.21
[Bug other/62168] error in configure: line 21572: test: =: unary operator expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168
--- Comment #8 from Manfred Schwarb ---
Works for me, the error message is gone.
I inserted a pair of set -x/set +x around the gold configure block,
and the following is the output, everything looks OK:
original:
+ test set = set
+ :
+ enableval=yes
+ case "${enableval}" in
+ test x '!=' x
+ gcc_cv_gld_major_version=
+ gcc_cv_gld_minor_version=
++ echo ../../gfortran-source/gcc-5-20140817/gcc
++ sed -e 's,/gcc$,,'
+ gcc_cv_ld_gld_srcdir=../../gfortran-source/gcc-5-20140817/ld
++ echo ../../gfortran-source/gcc-5-20140817/gcc
++ sed -e 's,/gcc$,,'
+ gcc_cv_ld_gold_srcdir=../../gfortran-source/gcc-5-20140817/gold
++ echo ../../gfortran-source/gcc-5-20140817/gcc
++ sed -e 's,/gcc$,,'
+ gcc_cv_ld_bfd_srcdir=../../gfortran-source/gcc-5-20140817/bfd
+ test '' = set
+ test -x ''
+ test = yes
/scratch/gfortran-source/gcc-5-20140817/gcc/configure: line 21572: test: =:
unary operator expected
+ test -f ../../gfortran-source/gcc-5-20140817/ld/configure.in
+ test -x collect-ld
+ set dummy
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld
+ test -x
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld
+
gcc_cv_ld=/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld
+ set +x
with your new patch:
+ install_gold_as_default=no
+ test set = set
+ :
+ enableval=yes
+ case "${enableval}" in
+ test x '!=' x
+ gcc_cv_gld_major_version=
+ gcc_cv_gld_minor_version=
++ echo ../../gfortran-source/gcc-5-20140817/gcc
++ sed -e 's,/gcc$,,'
+ gcc_cv_ld_gld_srcdir=../../gfortran-source/gcc-5-20140817/ld
++ echo ../../gfortran-source/gcc-5-20140817/gcc
++ sed -e 's,/gcc$,,'
+ gcc_cv_ld_gold_srcdir=../../gfortran-source/gcc-5-20140817/gold
++ echo ../../gfortran-source/gcc-5-20140817/gcc
++ sed -e 's,/gcc$,,'
+ gcc_cv_ld_bfd_srcdir=../../gfortran-source/gcc-5-20140817/bfd
+ test '' = set
+ test -x ''
+ test no = yes
+ test -f ../../gfortran-source/gcc-5-20140817/ld/configure.in
+ test -x collect-ld
+ set dummy
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld
+ test -x
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld
+
gcc_cv_ld=/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld
+ set +x
[Bug other/62168] error in configure: line 21572: test: =: unary operator expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168 --- Comment #6 from Manfred Schwarb --- I did the following (error present also with your recent patch): # ../gfortran-source/gcc-5-20140817/configure --enable-languages=c,c++,fortran --disable-nls --enable-checking=release --disable-libmudflap --disable-libstdcxx-pch --enable-libgomp --enable-lto --enable-gold --with-plugin-ld=gold --disable-isl-version-check --prefix=/usr/local/gfortran-test # make -j16 bootstrap2-lean 1>/dev/null
[Bug other/62168] error in configure: line 21572: test: =: unary operator expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168
--- Comment #4 from Manfred Schwarb ---
This does not catch all cases. There is also
yes)
if test x${default_ld} != x; then
install_gold_as_default=yes
fi
;;
which needs an "else" case, as far as I can see.
"default_ld" is empty for the normal cases, unless you set --enable-ld=no.
Or you fix the if statement some few lines below:
--- configure.ac.orig 2014-07-31 02:30:13.804162521 +0200
+++ configure.ac2014-08-18 21:47:10.722061603 +0200
@@ -2117,7 +2117,7 @@
AS_VAR_SET_IF(gcc_cv_ld,, [
if test -x "$DEFAULT_LINKER"; then
gcc_cv_ld="$DEFAULT_LINKER"
-elif test $install_gold_as_default = yes \
+elif test x$install_gold_as_default = xyes \
&& test -f $gcc_cv_ld_gold_srcdir/configure.ac \
&& test -f ../gold/Makefile \
&& test x$build = x$host; then
[Bug other/62168] error in configure: line 21572: test: =: unary operator expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168 --- Comment #1 from Manfred Schwarb --- The script in question is gcc/configure, not toplevel configure. The script error location corrsponds to line 2120 in gcc/configure.ac. The code in question was introduced in revision 205392 by hjl.
[Bug other/62168] New: error in configure: line 21572: test: =: unary operator expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62168 Bug ID: 62168 Summary: error in configure: line 21572: test: =: unary operator expected Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: manfred99 at gmx dot ch configure: line 21572: test: =: unary operator expected This is: if test -x "$DEFAULT_LINKER"; then gcc_cv_ld="$DEFAULT_LINKER" ==> elif test $install_gold_as_default = yes \ && test -f $gcc_cv_ld_gold_srcdir/configure.ac \ && test -f ../gold/Makefile \ either install_gold_as_default should be set in all cases a few lines above, or the variable should be surrounded by quotes: ==> elif test "$install_gold_as_default" = yes \
[Bug libfortran/59513] [4.8/4.9/4.10 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513 --- Comment #26 from Manfred Schwarb --- I just tested g77. As suspected, g77 is in line with gfortran 4.5. It happily accepts the following and does not throw an error in the END clause case: READ(lun,END=100) buffer 100 WRITE(lun,*) "whatever"
[Bug libfortran/59513] [4.8/4.9/4.10 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513
--- Comment #25 from Manfred Schwarb ---
OK, thanks Jerry and Dominique for the explanations.
It seems the correct syntax then is:
READ(lun,END=100) buffer
GOTO 101
100 BACKSPACE(lun)
101 WRITE(lun,*) "whatever"
Not that the above code would make sense to me as a mere user,
but it works both with gfortran 4.5 and 4.6 upwards.
I just wrote a small test program, the output is identical for
gfortran 4.5 and 4.6+:
CHARACTER*20 buffer,buffer2
INTEGER i
buffer=""
buffer2=""
OPEN(10,FILE="test.txt")
WRITE(10,'(a)') "0123456789"
CLOSE(10)
OPEN(10,FILE="test.txt",POSITION="APPEND")
CALL ftell(10,i)
print*,"file position in append mode:",i
CLOSE(10)
OPEN(10,FILE="test.txt")
READ(10,'(a20)') buffer
print*,"X",buffer,"X"
CALL ftell(10,i)
print*,"file position after reading buffer:",i
CC BACKSPACE(10) ! then below write will overwrite first line
WRITE(10,'(a)') "ABC"
CLOSE(10)
CALL system("cat test.txt")
OPEN(10,FILE="test.txt")
WRITE(10,'(a)') "0123456789"
CLOSE(10)
OPEN(10,FILE="test.txt")
READ(10,'(a20)',END=100) buffer,buffer2
GOTO 101
100 CALL ftell(10,i)
print*,"END clause encountered: file position:",i
BACKSPACE(10)
101 CALL ftell(10,i)
print*,"file position:",i
print*,"X",buffer,"X",buffer2,"X"
WRITE(10,'(a)') "ABC"
CLOSE(10)
CALL system("cat test.txt")
END
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 --- Comment #10 from Manfred Schwarb --- Dominique, you are right. The issue is not with isl-0.12 and isl-0.13. It is isl-0.11 that is missing these include files. So with the above mentioned check-in, building GCC using isl-0.11 does no longer work. I just could build trunk successfully now, using isl-0.12.2. One should rip isl-0.11 support out of configure etc. therefore. OK, I see what could have happened to Thomas: GMP support in isl is optional. If you build isl without gmp headers being present, then probably you wont get the needed headers to compile GCC. So it seems isl-0.12.2 with GMP support is needed to build graphite.
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792
--- Comment #8 from Manfred Schwarb ---
The graphite-isl-ast-to-gimple.c code reads
#ifdef HAVE_cloog
#include
#include
#include
#include
#if defined(__cplusplus)
extern "C" {
#endif
#include
#if defined(__cplusplus)
}
#endif
#endif
and val_gmp.h only exists in isl-0.13.
So maybe things work when disabling/not using cloog?
Will have to check tomorrow.
[Bug libfortran/59513] [4.8/4.9/4.10 Regression] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513 Manfred Schwarb changed: What|Removed |Added CC||manfred99 at gmx dot ch --- Comment #22 from Manfred Schwarb --- I just encountered the same issue, with some convoluted legacy code. The scheme seems to be the same: READ(lun,END=100) buffer 100 WRITE(lun,*) "whatever" As the used code definitely was used in practice, mainly before the year 2000, I guess that older compiler supported this. And yes, the BACKSPACE() trick works. However, common sense suggest that with END= we are at the end of the file. This sounds a bit like the old joke, where you have a room with 5 people, you are taking 6 out, so someone has to go in for the room to be empty. Beyond EOF simply does not exist. Jerry, concerning your cited standard: "If the file contains an endfile record" suggests that there is some special marker in the file to be read/written. In this example, we are doing some formatted IO to a plain text file, there are no special markers. Do I miss something? What does/should ftell() report in such a case? That we are one character beyond EOF?
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 --- Comment #6 from Manfred Schwarb --- There is ./configure --disable-isl-version-check, but I doubt that it will help. The thing is, isl-0.13 needs cloog-0.18.2 (or rather, cloog-0.18.1 needs isl-0.12.2 and does not build with isl-0.13), which is not yet released. Now I heard that the goal is to do without cloog, but I guess the configure machinery (and probably, the rest of the graphite code) is not yet up to it. There really needs an immediate solution to this issue, I think ATM there is no way to build graphite without resorting to non-released libraries. I suggest to revert all these isl-0.13 dependencies until cloog-0.18.2 is released, or there is shown some way to build graphite without cloog. Roman, how is one supposed to build GCC with graphite support?
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #29 from Manfred Schwarb --- The regression flag was re-added by Tobias in comment 23 due to a regression in the testcase of comment 21: !234567 character buffer*10 integer i,j DO j=1, write(buffer,'(i4)') j write(*,*) buffer(1:4) read(buffer,'(i10)') i write(*,*) i ENDDO end Here are the profiles of gfortran 4.6: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls Ts/call Ts/call name 97.45 3.06 3.06 _gfortrani_read_decimal 1.59 3.11 0.05 memset 0.64 3.13 0.02 __write_nocancel 0.32 3.14 0.01 format_lex 0.00 3.14 0.001 0.00 0.00 main and gfortran trunk: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls Ts/call Ts/call name 59.96 2.71 2.71 read_utf8 38.72 4.46 1.75 _gfortrani_read_decimal 0.66 4.49 0.03 memset 0.22 4.50 0.01 fflush 0.22 4.51 0.01 formatted_transfer 0.22 4.52 0.01 malloc_consolidate 0.00 4.52 0.001 0.00 0.00 main so the difference is obvious, the utf8 treatment makes the difference. Is there a possibility to speed up reading the trivial cases? 99.99% of fortran input will be ASCII, I guess... And again, the magical approach is to add LEN_TRIM to avoid reading 10 space characters and interpreting them as utf8. So if something like Thomas' patch could be applied also for formatted reads, this would speed up things dramatically as well.
[Bug libfortran/38199] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #22 from Manfred Schwarb 2013-02-15 10:20:46 UTC --- Last month I had a private communication with Jerry, whether this bug can be closed. I decided to add a summary to the bugzilla page: The fix of Thomas is restricted to scalars and list-io. One could simply replace buffer by buffer(1) in my test case 2 in comment #1 (using list-io): !234567 character buffer(1)*10 integer i,j DO j=1, write(buffer(1),'(i4)') j write(*,*) buffer(1)(1:4) read(buffer,*) i write(*,*) i ENDDO end And we are again dog slow. For formatted IO (comment #21), this patch does not help either. Timings of the above test case: gfortran4.3: 10.3s gfortran4.7: 13.5s gfortran4.8: 15.8s as comparison, test case 2 of comment #1: gfortran4.8: 0.26s Timings for testcase in comment #21: gfortran4.3:2.7s gfortran4.6:2.7s gfortran4.7:4.7s <--- gfortran4.8:4.0s
[Bug fortran/53029] missed optimization in internal read (without implied-do-loop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53029 Manfred Schwarb changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | --- Comment #2 from Manfred Schwarb 2012-05-11 21:25:14 UTC --- Is not. Please see the opening date of this bug compared to BUG 50673. It _is_ actually a reaction on seeing that BUG 50673 has not fixed this particular issue ... I just verified it again with #> gfc-test -v Using built-in specs. COLLECT_GCC=/usr/local/gfortran-test/bin/gfortran COLLECT_LTO_WRAPPER=/usr/local/gfortran-test/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gfortran-source/gcc-4.8-20120506/configure --enable-languages=c,c++,fortran --disable-libmudflap --enable-libgomp --disable-nls --enable-checking=release --disable-bootstrap --prefix=/usr/local/gfortran-test --enable-lto --enable-gold --with-plugin-ld=/usr/bin/gold Thread model: posix gcc version 4.8.0 20120506 (experimental) (GCC)
[Bug fortran/53029] New: missed optimization in internal read (without implied-do-loop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53029 Bug #: 53029 Summary: missed optimization in internal read (without implied-do-loop) Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: manfre...@gmx.ch Followup to Bug 32382. !234567C234567 program internalread implicit none integer m parameter(m=100) character value*10 integer i,j,intvalues(m) DO j=1,100 write(value,'(i3,a5)') j," 5 69" write(*,*) value !!read(value,*,end=20) (intvalues(i),i=1,m) ! this is BUG 32382 read(value,*,end=20) intvalues 20 write(*,*) j,(intvalues(i),i=1,4) ENDDO end program internalread This version needs 2.7s on my box, the commented version needs 0.27s (BUG 32382). The array version is about 10x slower than the implied do loop variant.
[Bug libfortran/38199] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #21 from Manfred Schwarb 2012-04-18 09:01:46 UTC --- This new version does fix it, timings are around 0.2s for the above test-case (exactly as fast as the user-optimized len_trim variant). Thanks a lot! However, I don't see why this fix is restricted to list-directed reads. I.e. consider a slight variation: !234567 character buffer*10 integer i,j DO j=1, write(buffer,'(i4)') j write(*,*) buffer(1:4) !!read(buffer(1:len_trim(buffer)),'(i10)') i read(buffer,'(i10)') i write(*,*) i ENDDO end Here, I get 4.5s for the above variant and 0.2s for the len_trim variant. But perhaps this is a different issue (separate bug report needed)?
[Bug libfortran/38199] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #16 from Manfred Schwarb 2012-03-19 09:42:29 UTC --- Thanks, Janne, for your patch. It does not help very much, though. [ As expected, as the reading part is the bottleneck ] My current timings of the second test case: g77: 12.41s 4.3: 14.60s 4.5: 18.55s 4.7: 17.21s 4.8: 16.80s (inkl. Janne's patch) len_trim variant, 4.3: 0.92s len_trim variant, 4.8: 0.24s That's still a factor 70 (sic!) away from the optimized variant. And we are still slower than GCC 4.3 and g77. The len_trim variant improved a lot, probably due to Janne's patch. Now, the interesting thing is: I tried to figure out at which point the len_trim variant is slower due to the len_trim overhead. On my box, this point does not exist, i.e. the len_trim variant is always faster! I.e. even for character buffer*10 the len_trim variant is faster! Which suggests that a brute-force approach to unconditionally issue a "len_trim" in the relevant gfortran reading routine would always be a win!
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #17 from manfred99 at gmx dot ch 2010-04-01 20:35 ---
I will test this new patch, thanks.
Meanwhile, I found that the following works, too:
size_t
PREFIX(ftell) (int * unit)
{
gfc_unit * u = find_unit (*unit);
gfc_offset ret;
if (u == NULL)
return ((size_t) -1);
ret = stell (u->s) - (u->fbuf->act - u->fbuf->pos);
unlock_unit (u);
return ret;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug fortran/43605] [4.4/4.5 Regression] wrong results with ftell
--- Comment #7 from manfred99 at gmx dot ch 2010-04-01 07:42 --- Thanks for the quick fix! I can confirm that the patch works for both the "(a)" and the "*" case. In the code, there is still some size_t reference, should probably be gfc_offset as well: if (u == NULL) return ((size_t) -1); Not that it would matter, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug fortran/43605] New: Regression: wrong results with ftell
cat telltest.txt
123456
789
CC
DD
cat telltest.f
C234567
integer i
character*99 buffer
open(10,FILE="telltest.txt")
read(10,'(a)') buffer
!!read(10,*) buffer
call ftell(10,i)
print*,i
close(10)
end
With gfortran-4.3, this prints "7".
With gfortran-4.5, I get "99" for the "(a)" variant,
and "80" for the "*" variant.
"7" is definitely the right answer, IMO.
--
Summary: Regression: wrong results with ftell
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43605
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #13 from manfred99 at gmx dot ch 2010-01-16 23:48 --- I now built gfortran 4.5.0 (20100107) + Jerry's patch. Patch works for me, no SIGSEGV any more. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug fortran/42772] New: ICE at fold-const.c:10033
With the test case 2 of bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
I get with
# gfortran -frecursive -fcheck=all -o writebug2 writebug2.f
writebug2.f: In function 'MAIN__':
writebug2.f:33:0: internal compiler error: in fold_binary_loc, at
fold-const.c:10033
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
This is with gfortran 4.5.0 (20100107)
A reduced test case is the most trivial fortran program:
Just the line "END"
The ICE depends on the options "-frecursive -fcheck=all"
--
Summary: ICE at fold-const.c:10033
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42772
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #12 from manfred99 at gmx dot ch 2010-01-16 21:43 --- To clarify, this was still with the unpatched gfortran 4.5.0, snapshot of 20100107. BTW, the silly, stray line "anzarg2=j" in writebug2.f does not alter the result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #11 from manfred99 at gmx dot ch 2010-01-16 18:35 --- With test case 2, I get > ./writebug2 > writebug2.txt Interation1 : 25 Interation2 : 32 Interation3 : 39 Interation4 : 46 Interation5 : 53 Interation6 : 60 Interation7 : 67 Interation8 : 74 Interation9 : 81 Interation 10 : 88 Interation 11 : 95 Interation 12 : 102 Interation 13 : 109 Interation 14 : 116 Interation 15 : 123 Interation 16 : 130 Interation 17 : 137 Interation 18 : 144 Interation 19 : 151 Interation 20 : 158 Interation 21 : 165 Interation 22 : 172 Interation 23 : 179 Interation 24 : 186 Interation 25 : 193 Interation 26 : 200 Interation 27 : 207 Interation 28 : 214 Interation 29 : 221 Interation 30 : 228 Segmentation fault It stops at length 228 after the 5th iteration of the inner loop. I tried 32bit and 64bit, no difference. Also, varying values of "ulimit -s" and "-fmax-stack-var-size" made no difference. Maybe your FORMAT_CACHE_STRING_LIMIT is not the same thing as the user space format length, so I can not judge your patch. It seems however, that the bug is not stack size dependent. And my box has more than enough memory. So I'm not completely convinced that the issue is a stack or heap size limitation. I further noticed, that the reached last iteration of the inner loop depends on the loop stop value. If I do "DO i=1,100", then the inner loop stops after iteration 85 (but for the same j=30). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #10 from manfred99 at gmx dot ch 2010-01-16 18:13 --- Created an attachment (id=19625) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19625&action=view) test case 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #6 from manfred99 at gmx dot ch 2010-01-14 13:44 --- fmtstr is put together at runtime, each column may (and actually does sometimes) have different width (minimal width to save space), so - no, your work around does not work for me - no, this example is not contrived - in some invocations of my program I do have ~1000 columns (instead of 74 as in this example), so fmtstr may get huge. Well, this sounds a bit silly, I know. But it worked so far and is well in line with the GNU "no limits" credo ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #3 from manfred99 at gmx dot ch 2010-01-14 13:01 --- See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42744 for comments and test case. Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug libfortran/42744] SIGSEGV at libgfortran/io/format.c:111
--- Comment #3 from manfred99 at gmx dot ch 2010-01-14 12:59 --- Sorry, I made a mess. *** This bug has been marked as a duplicate of 42742 *** -- manfred99 at gmx dot ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42744
[Bug libfortran/42742] [4.5 Regression] SIGSEGV at libgfortran/io/format.c:111
--- Comment #2 from manfred99 at gmx dot ch 2010-01-14 12:59 --- *** Bug 42744 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug libfortran/42744] SIGSEGV at libgfortran/io/format.c:111
--- Comment #2 from manfred99 at gmx dot ch 2010-01-14 12:43 --- This write statement is called in a loop, and it crashes at the second iteration. I did first a test case with only this write statement, and it works OK. Then, I put a loop around it, and I catched it! So the attached test case crashes for me with # ./writebug 2009-10-31 03:00 2.8 7.8 7.3 7.6 7.1 -0.2 2.6 7.3 7.6 7.9 8.2 2.5 7.0 8.0 7.5 6.6 7.8 5.7 9.4 7.3 -0.6 5.2 7.7 8.5 8.8 4.7 7.7 7.7 7.4 7.4 1.2 5.9 2.6 2.5 8.0 7.1 7.2 8.8 3.9? 3.0 2.2 7.3 3.1 1.7 -6.3 5.4 6.3 6.2 -4.5 0.2 4.5 0.3 6.0 9.8 2.9 12.0 11.0 12.7 11.1 0.0 3.7 3.0 -0.9 2.2 -0.4 0.0 -4.6 -6.7 1.8 -0.8?? 4.3 Program received signal 11 (SIGSEGV): Segmentation fault. Backtrace for this error: + /lib64/libc.so.6 [0x7f0d7ee7b560] + in the main program from file writebug.f + /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f0d7ee67a7d] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42744
[Bug libfortran/42744] SIGSEGV at libgfortran/io/format.c:111
--- Comment #1 from manfred99 at gmx dot ch 2010-01-14 12:42 --- Created an attachment (id=19596) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19596&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42744
[Bug libfortran/42744] New: SIGSEGV at libgfortran/io/format.c:111
In a larger program of mine, I got a SIGSEGV when printing
WRITE(*,fmtstr)
& dat(1),"-",dat(2),"-",dat(3),
& datedelim,dat(4),":",dat(5),
& (delim,bufarr(pindx),pindx=1,anzarg2)
with gfortran 4.5 (latest snapshot). Using gfortran 4.3.5 the code runs fine.
Unfortunately, I can not reproduce the crash in a standalone program.
In the above print statement, fmtstr is rather large (~550chars).
Here is the gdb output:
Program received signal SIGSEGV, Segmentation fault.
reset_node (fn=0xc) at
../../../gfortran-source/gcc-4.5-20100107/libgfortran/io/format.c:111
111 if (fn->format != FMT_LPAREN)
(gdb) where
#0 reset_node (fn=0xc) at
../../../gfortran-source/gcc-4.5-20100107/libgfortran/io/format.c:111
#1 0x00423b30 in reset_fnode_counters ()
at ../../../gfortran-source/gcc-4.5-20100107/libgfortran/io/format.c:134
#2 parse_format () at
../../../gfortran-source/gcc-4.5-20100107/libgfortran/io/format.c:1233
#3 0x00418208 in data_transfer_init (dtp=0x7ffead80, read_flag=0)
at ../../../gfortran-source/gcc-4.5-20100107/libgfortran/io/transfer.c:2182
#4 0x0040ba86 in writevals (startjul=,
endjul=,
reqts=, basets=,
use_monthtu=,
station=, param=,
aggrtypes=,
parfmt2=, valarr2=,
datefmt=,
delim=, missing=, anzarg2=,
anzval=, toffset=, qualarr=,
wantqf=, _station=, _param=,
_aggrtypes=, _parfmt2=,
_delim=, _missing=) at
extractdata.f:1464
#5 0x00407818 in extractdata () at extractdata.f:58
#6 0x00407906 in main (argc=, argv=)
at extractdata.f:1179
#7 0x0042b406 in __libc_start_main (main=,
argc=, ubp_av=, init=0x42b8b0
<__libc_csu_init>,
fini=0x42b870 <__libc_csu_fini>, rtld_fini=0, stack_end=0x7fffdf98) at
libc-start.c:220
#8 0x00400209 in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb) list
106 fnode *f;
107
108 fn->count = 0;
109 fn->current = NULL;
110
111 if (fn->format != FMT_LPAREN)
112 return;
113
114 for (f = fn->u.child; f; f = f->next)
115 {
Hopefully this gives already some clues. Otherwise please tell me
how to debug further.
--
Summary: SIGSEGV at libgfortran/io/format.c:111
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42744
[Bug libfortran/42742] New: SIGSEGV at libgfortran/io/format.c:111
In a larger program of mine, I got a SIGSEGV when printing
WRITE(*,fmtstr)
& dat(1),"-",dat(2),"-",dat(3),
& datedelim,dat(4),":",dat(5),
& (delim,bufarr(pindx),pindx=1,anzarg2)
with gfortran 4.5 (latest snapshot). Using gfortran 4.3.5 the code runs fine.
Unfortunately, I can not reproduce the crash in a standalone program.
In the above print statement, fmtstr is rather large (~550chars).
Here is the gdb output:
Program received signal SIGSEGV, Segmentation fault.
reset_node (fn=0xc) at
../../../gfortran-source/gcc-4.5-20100107/libgfortran/io/format.c:111
111 if (fn->format != FMT_LPAREN)
(gdb) where
#0 reset_node (fn=0xc) at
../../../gfortran-source/gcc-4.5-20100107/libgfortran/io/format.c:111
#1 0x00423b30 in reset_fnode_counters ()
at ../../../gfortran-source/gcc-4.5-20100107/libgfortran/io/format.c:134
#2 parse_format () at
../../../gfortran-source/gcc-4.5-20100107/libgfortran/io/format.c:1233
#3 0x00418208 in data_transfer_init (dtp=0x7ffead80, read_flag=0)
at ../../../gfortran-source/gcc-4.5-20100107/libgfortran/io/transfer.c:2182
#4 0x0040ba86 in writevals (startjul=,
endjul=,
reqts=, basets=,
use_monthtu=,
station=, param=,
aggrtypes=,
parfmt2=, valarr2=,
datefmt=,
delim=, missing=, anzarg2=,
anzval=, toffset=, qualarr=,
wantqf=, _station=, _param=,
_aggrtypes=, _parfmt2=,
_delim=, _missing=) at
extractdata.f:1464
#5 0x00407818 in extractdata () at extractdata.f:58
#6 0x00407906 in main (argc=, argv=)
at extractdata.f:1179
#7 0x0042b406 in __libc_start_main (main=,
argc=, ubp_av=, init=0x42b8b0
<__libc_csu_init>,
fini=0x42b870 <__libc_csu_fini>, rtld_fini=0, stack_end=0x7fffdf98) at
libc-start.c:220
#8 0x00400209 in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb) list
106 fnode *f;
107
108 fn->count = 0;
109 fn->current = NULL;
110
111 if (fn->format != FMT_LPAREN)
112 return;
113
114 for (f = fn->u.child; f; f = f->next)
115 {
Hopefully this gives already some clues. Otherwise please tell me
how to debug further.
--
Summary: SIGSEGV at libgfortran/io/format.c:111
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug fortran/38199] [4.4 regression] I/O performance
--- Comment #4 from manfred99 at gmx dot ch 2008-11-20 16:09 --- Consider !234567 program internalread3 implicit none character value*10 integer i,j DO j=1, write(value,'(i4)') j write(*,*) value(1:4) read(value(1:LEN_TRIM(value)),*) i write(*,*) i ENDDO end program internalread3 gfortran4.4 (20081120, 64bit): 1.079s i.e. speedup by factor 23 ... but there are cases where the user can't solve the issue like this. And such basic optimizations are more efficiently done by the compiler. Besides this: This is an internal read, so the compiler has full control over the contents of this string variable. It can e.g. null terminate the string or similar, or it can carry on an index of the last character in string (set on assignment), or ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
[Bug fortran/38199] missed optimization, regression: I/O performance
--- Comment #2 from manfred99 at gmx dot ch 2008-11-20 14:59 --- The profiling of the second testcase gives % cumulative self self total time seconds secondscalls Ts/call Ts/call name 44.20 8.34 8.34 next_char 24.85 13.03 4.69 mem_read 17.04 16.25 3.22 memcpy 4.98 17.19 0.94 eat_spaces 4.03 17.95 0.76 _gfortrani_empty_internal_buffer 2.44 18.41 0.46 nml_query 2.09 18.80 0.40 strncasecmp_l 0.21 18.84 0.04 memset 0.05 18.85 0.01 __divti3 0.05 18.86 0.01 _gfortrani_write_block 0.05 18.87 0.01 next_char 0.00 18.87 0.001 0.00 0.00 MAIN__ It seems gfortran reads character by character and does not take any opportunities to shortcut the read process. For this case, one could imagine that the read routine would scan for the last non-blank character and would stop reading at this position. Perhaps ifort is doing exactly this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
[Bug fortran/38199] New: missed optimization, regression: I/O performance
With
!234567
character buffer*1000
integer i,j
DO j=1,20
write(buffer,'(i2)') j
write(*,*) buffer(1:2)
read(buffer,*) i
write(*,*) i
ENDDO
end
I get the following timings:
ifort11 (64bit): 0.306s
ifort9 (32bit):0.562s
g77 (32bit): 2.786s
gfortran4.3 (64bit): 3.906s
gfortran4.4 (20081120, 64bit): 4.832s
Even worse:
!234567
character buffer*10
integer i,j
DO j=1,
write(buffer,'(i4)') j
write(*,*) buffer(1:4)
read(buffer,*) i
write(*,*) i
ENDDO
end
ifort11 (64bit):0.458s
g77 (32bit): 13.283s
gfortran4.3 (64bit): 19.362s
gfortran4.4 (20081120, 64bit): 23.917s
This is a very realistic real-world scenario when reading
in a flat-file of unknown width (<10 assumed), and
then processing the received string buffer, i.e. doing
100 read(10,'(a)',END=999) buffer
--->
read(buffer,*,END=101,ERR=101) array
101 do something when unexpected content
GOTO 100
999 end
--
Summary: missed optimization, regression: I/O performance
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199
[Bug fortran/34899] Continuation lines with not recognized
--- Comment #8 from manfred99 at gmx dot ch 2008-01-22 09:23 --- Gaa, my example is BS, of course. The really interesting thing is however, that g77 compiles it just fine and happily treats "1" as continuation line. What a can of worms!! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899
[Bug fortran/34899] Continuation lines with not recognized
--- Comment #7 from manfred99 at gmx dot ch 2008-01-22 08:41 ---
Hmm,
I like the idea of being able to compile also legacy code with gfortran.
However, I really see the point Steve is making. With this patch things
get confusing.
If you consider a modified version of Steve's example:
c23456789012345678901234567890123456789012345678901234567890123456789012
program a
integer , b, , dd, , f
1
f1 = 1
print *, f1
end program a
If you write this with tabs, then the program becomes invalid.
So the mere user looking at the code can't see whether this is valid code
or not, you have to investigate the individual lines with an editor.
So I really would suggest to do something like
+ if (found_tab)
{
+ found_tab = false;
+ if (c >= '1' && c <= '9')
+ {
+ *(buffer-1) = c;
+ gfc_warning_now ("Continuation line with tab ... etc.");
+ continue;
+ }
+ }
Secondly: Tradition in gfortran was to bury such things behind -std=legacy.
There are other things which are supported by other compilers and g77 and
which are only supported with -std=legacy in gfortran (e.g. FORMAT("f8")).
I don't care whether it's declared as legacy or not, but there should
perhaps be some overall strategy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899
[Bug fortran/34838] Internal Error: Can't convert LOGICAL(1) to LOGICAL(1)
--- Comment #6 from manfred99 at gmx dot ch 2008-01-18 13:26 --- Yes, PR 34817 pass (both) for me too, with your binaries as well as with the binaries of FX. I just checked my testcase (this PR) with the binaries of FX, it breaks after 2008-01-15, same as with your binaries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34838
[Bug fortran/34838] Internal Error: Can't convert LOGICAL(1) to LOGICAL(1)
--- Comment #4 from manfred99 at gmx dot ch 2008-01-18 08:59 --- I bisected it using the binaries of Tobias: gcc-trunk-x86_64-2008-01-15-r131542.tar.gz works gcc-trunk-x86_64-2008-01-16-r131566.tar.gz is broken inbetween there exist mainly only 2 relevant commits: - r131553 Th. Koenig, fiddling with _gfortran_any_l1 and *logical.m4 - r131566 T. Burnus I doubt somehow that the patch for PR 34817 will help. I will not have time to check it myself in the next days, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34838
[Bug fortran/34838] Internal Error: Can't convert LOGICAL(1) to LOGICAL(1)
--- Comment #1 from manfred99 at gmx dot ch 2008-01-17 22:45 --- shorter version: Logical*1 :: bmp(1),bmpv(1) bmp(1)=.false. bmpv(1)=.true. if ( ANY(bmp(1:1) .NEQV. bmpv(1:1)) ) then print*,"hello" endif end "Logical", "Logical*2" and "Logical*4" in variable definition work. "Logical*1" breaks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34838
[Bug fortran/34838] New: Internal Error: Can't convert LOGICAL(1) to LOGICAL(1)
integer MAXPTS PARAMETER (MAXPTS=1000) Logical*1,allocatable,dimension(:) :: bmp,bmpv integer :: igds(5)=(/0,0,0,0,0/) allocate(bmp(maxpts)) allocate(bmpv(maxpts)) bmp(1)=.false. bmpv(1)=.true. igds(2)=1 if ( ANY(bmp(1:igds(2)) .NEQV. bmpv(1:igds(2))) ) then print*,"hello" endif end gives: demo.f:17.72: end 1 Internal Error at (1): demo.f:14.36: if ( ANY(bmp(1:igds(2)) .NEQV. bmpv(1:igds(2))) ) then 1 Can't convert LOGICAL(1) to LOGICAL(1) at (1) this is with Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /projects/tob/gcc/configure --enable-languages=c,fortran --prefix=/projects/tob/gcc-trunk Thread model: posix gcc version 4.3.0 20080117 (experimental) [trunk revision 131592] (GCC) -- Summary: Internal Error: Can't convert LOGICAL(1) to LOGICAL(1) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manfred99 at gmx dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34838
[Bug rtl-optimization/33638] [4.3 regression] wrong code with -O2 -fforce-addr
--- Comment #27 from manfred99 at gmx dot ch 2007-10-12 15:28 --- With gcc of today (patched tree-ssa-forwprop.c to make it bootstrap): # gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gfortran-source/gcc/configure --enable-languages=fortran --disable-nls --disable-multilib --enable-checking=release --prefix=/usr/local/gfortran-test Thread model: posix gcc version 4.3.0 20071012 (experimental) [trunk revision 129260] (GCC) The original program works fine now, the bugzilla testcase too, both with and without "-fforce-addr". I'm not able to trigger this wrong-code issue with this new version now. Note: the testcase gives different output, as meanwhile in gfortran the default precision for outputs has been increased. The actual values are the same though. Thanks a lot! -- manfred99 at gmx dot ch changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
[Bug middle-end/33638] optimization bug: wrong code with -fforce-addr
--- Comment #7 from manfred99 at gmx dot ch 2007-10-05 09:36 --- Ok, I managed to produce a testcase: a wrapper around the miscompiled function and all the missing routines. Input data is read from a binary file, so the program has to be run on a x86 machine (littleendian). I attach a tar file with all these things, including program output of a good and a bad run. good.out is an output of # gcc -O2 -march=pentium4 -c mova2i.c # gfortran -O2 -march=pentium4 -o main main.f \ comunpack.f rdieee.f gbytesc.f mova2i.o # ./main > good.out bad.out likewise, but with "-O2 -march=pentium4 -fforce-addr" (the additional flag only matters to comunpack.f, the other routines seem not to be affected and can be compiled arbitrarily). Hope this helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
[Bug middle-end/33638] optimization bug: wrong code with -fforce-addr
--- Comment #8 from manfred99 at gmx dot ch 2007-10-05 09:39 --- Created an attachment (id=14300) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14300&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
[Bug fortran/32382] missed optimization in internal read
--- Comment #6 from manfred99 at gmx dot ch 2007-10-05 09:38 --- (From update of attachment 14299) sorry, for wrong bug -- manfred99 at gmx dot ch changed: What|Removed |Added Attachment #14299|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
[Bug fortran/32382] missed optimization in internal read
--- Comment #5 from manfred99 at gmx dot ch 2007-10-05 09:37 --- Created an attachment (id=14299) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14299&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
[Bug middle-end/33638] optimization bug: wrong code with -fforce-addr
--- Comment #5 from manfred99 at gmx dot ch 2007-10-03 20:10 --- Subject: Re: optimization bug: wrong code with -fforce-addr > --- Comment #4 from ubizjak at gmail dot com 2007-10-03 15:43 --- > Please provide enough sources to create an _executable_ that shows the > failure. > We are dealing with runtime failure here. > If I could come up with a short testcase just like that, I would have done so already. > A _short_ testcase (<30 lines) is nice to have, so all non-related parts > should > be removed. Wandering through a maze of jumps certainly doesn't help to > find > the problem. > > An abort() should be called for wrong result, but at least wrong result > and > expected result should be described to help trace the issue down. > I will see what I can do, but do not expect any miracles. This is from a large software package with ~10^2 functions and at the end there is a binary output file of several MB which is either as it should or not :-( And as I told in the bug report, inserting or deleting code suddenly let the issue vanish. I already tried to reduce this code with the result that removing dead code fixed the miscompilation. > BTW: Assembler dumps are not _that_ informative, especially without > -fverbose-asm ;) > As it was not clear to me what information to provide, I asked first on the gcc mailing list, to no avail, so I provided just some random information. BTW 1: # gfortran -v Using built-in specs. Target: i386-pc-linux-gnu Configured with: /home/fx/gfortran_nightbuild/trunk/configure --prefix=/home/fx/gfortran_nightbuild/irun-20071001 --enable-languages=c,fortran --build=i386-pc-linux-gnu --enable-checking=release --with-gmp=/home/fx/gfortran_nightbuild/software Thread model: posix gcc version 4.3.0 20071001 (experimental) [trunk revision 128899] (GCC) BTW 2: Code was checked with valgrind and efence, seems to be ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
[Bug middle-end/33638] optimization bug: wrong code with -fforce-addr
--- Comment #3 from manfred99 at gmx dot ch 2007-10-03 12:49 --- Created an attachment (id=14290) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14290&action=view) Assembler code when commenting line 315, works -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
[Bug middle-end/33638] optimization bug: wrong code with -fforce-addr
--- Comment #2 from manfred99 at gmx dot ch 2007-10-03 12:47 --- Created an attachment (id=14289) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14289&action=view) Assembler code of original code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
[Bug middle-end/33638] optimization bug: wrong code with -fforce-addr
--- Comment #1 from manfred99 at gmx dot ch 2007-10-03 12:46 --- Created an attachment (id=14288) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14288&action=view) Source code of affected function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
[Bug middle-end/33638] New: optimization bug: wrong code with -fforce-addr
I have a rather nasty optimization issue with gfortran (as of yesterday).
As I think it could be an optimization issue and not an gfortran frontend
issue, so I assigned it to the middle-end.
I narrowed my problem to one single fortran function. If I compile this
function with
"gfortran -O2 -march=pentium4" the output is OK, using
"gfortran -O2 -march=pentium4 -fforce-addr" produces wrong output.
When reducing optimization level to "-O1", the issue vanishes for all tried
flag combinations.
If I comment out a particular non-functional line in this code, the issue goes
away:
if (always_true) then
else
this_line_commented_out_makes_it_working_again
endif
I will add assembler output of original, non-working code as well as
of working code when commenting the non-functional line, both compiled with
"gfortran -O2 -march=pentium4 -fforce-addr -S comunpack.f"
Function code is added as well.
Further data points:
- output of -fdump-tree-optimized is the same for both the working and the
broken case (of the original function, not the line commenting test).
- there are differences in assembler output though.
- the code calls C functions.
- I could reproduce this issue on an different, non-pentium4 machine
using the same flags.
- the flag -march=pentium4 is necessary to trigger the issue.
--
Summary: optimization bug: wrong code with -fforce-addr
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638
[Bug fortran/32382] missed optimization in internal read
--- Comment #3 from manfred99 at gmx dot ch 2007-09-02 11:53 --- Jerry, any news on this? I have seen this pattern many times in legacy fortran77 code, and the code authors seem to assume that ridiculously large loop stop values do not compromize performance. After all, in fortran77 you have to do something like this if you don't know the dimension to the data to read. Interestingly, ifort seems to have changed their mind, as ifort 8.1 seems to loop till the end (see comp.lang.fortran link in BUG 32257), whereas ifort 9.0 stops at value 4, like g77. And, as mentioned in BUG 32257, the compiler is free to choose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
[Bug fortran/32382] New: missed optimization in internal read
This is a followup to BUG 32257. Above Bug has been resolved as invalid, but how comes that the loop variable i has the value 101 at the end of the read? consider C234567 program internalread implicit none integer m CC parameter(m=100) parameter(m=100) character value*10 integer i,j,intvalues(m) DO j=1,100 write(value,'(i3,a5)') j," 5 69" write(*,*) value read(value,*,end=20,err=20) (intvalues(i),i=1,m) 20 write(*,*) j ENDDO end program internalread (There is no access to i after the loop, so this program should be valid) m=100: gfortran needs 0.003s g77 needs 0.002s m=100: gfortran needs 0.8s g77 needs 0.002s So gfortran loops to its bitter end, although it could shortcut the loop. g77 seems to exit the loop at i=3, as BUG 32257 shows as well. -- Summary: missed optimization in internal read Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manfred99 at gmx dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32382
[Bug fortran/31162] New: missing warning for real do-loops with implicit typed variables
real r do r=1.0,2.0 print*,r enddo end gives legacy.f:2.10: do r=1.0,2.0 1 Warning: Obsolete: REAL DO loop iterator at (1) which is ok, however do r=1.0,2.0 print*,r enddo end compiles without warning! the same for implicit real(a-z) do r=1.0,2.0 print*,r enddo end Additionally: It seems this warning is tied to -std=legacy, perhaps it would make more sense to tie it to -Wsurprising as it was the case for g77. -- Summary: missing warning for real do-loops with implicit typed variables Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manfred99 at gmx dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31162
[Bug fortran/27634] New: formatted reading/writing: real format without dot
real val
character str*6
open(1,FILE="tmp.dat")
read(1,'(a6,f4)') str,val
print*,str,val
end
gfortran tells me as follows:
read(1,'(a6,f4)') str,val
1
Warning: Period required in format string at (1)
# ./a.out
At line 4 of file read_gfc_test.f
Fortran runtime error: Period required in format
(a6,f4)
^
At compile time, gfortran issues only a warning, although it aborts
unconditionally at runtime, which comes as a bad surprise.
Either gfortran should abort at compile time, or it should support
this syntax ("f4" as an equivalent of "f4.0").
Same issue also for writing.
Support would be probably easy (not regtested, but works for me):
At Line 726 of libgfortran/io/format.c:
if (t != FMT_PERIOD)
{
/* We treat missing decimal descriptor as 0 !! */
fmt->saved_token = t;
tail->u.real.d = 0;
break;
}
This is a regression vs. g77.
--
Summary: formatted reading/writing: real format without dot
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manfred99 at gmx dot ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27634
[Bug fortran/18271] ICE with computed array declaration
--- Comment #5 from manfred99 at gmx dot ch 2005-11-04 15:32 --- 1) There is an easy way to circumvent the ICE: if you add an explicit type conversion for IMAX, such as in REAL:: AUX1(25000+INT(0.82*float(IMAX))) the ICE goes away and gfortran compiles it successfully and without warnings, even with "-std=f95". 2) WRT invalid code: I checked the code with the Lahey Source Check, ifort, SUN f95 and g95: --> Lahey/Fujitsu Fortran 95 (lf95): no errors, no warnings --> Lahey Fortran 90 (lf90): error at INT expression Line 5, file SOURCE.F90 REAL:: AUX1(25000+INT(0.82*IMAX)) | FATAL -- Specification expression required. --> Intel ifort 8.1: no errors, no warnings with "-warn all -stand f90" --> SUN Workshop f95 6.2: no errors, no warnings with "-w4" --> g95: no errors, no warnings with "-std=f95" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18271
[Bug fortran/19589] New: Regression: Error on Data assignment with LOGICAL*1
PROGRAM logical_data LOGICAL*1 GRD DATA GRD /.TRUE./ END gives: > gfc -v logical_data.f Driving: /usr/local/gfortran/irun/bin/gfortran -static -v logical_data.f -lgfortranbegin -lgfortran -lm Using built-in specs. Configured with: ../gcc/configure --enable-languages=c,f95 --prefix=/usr/work/2005023/irun Thread model: posix gcc version 4.0.0 20050123 (experimental) /usr/local/gfortran/irun/bin/../libexec/gcc/i686-pc-linux-gnu/4.0.0/f951 logical_data.f -ffixed-form -quiet -dumpbase logical_data.f -mtune=pentiumpro -auxbase logical_data -version -o /tmp/cc2uDAa6.s GNU F95 version 4.0.0 20050123 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.0.0 20050117 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 In file logical_data.f:3 DATA GRD /.TRUE./ 1 Error: Incompatible types in assignment at (1), LOGICAL(4) to LOGICAL(1) which is a clear regression, g77 supports this. Of course this error happens also with LOGICAL*2, LOGICAL*8, ... -- Summary: Regression: Error on Data assignment with LOGICAL*1 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manfred99 at gmx dot ch CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19589
