[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94030 Thomas Koenig changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |8.5 Summary|ICE equivalence of an |[8/9/10 Regression] ICE |integer and an element of |equivalence of an integer |an array of size n |and an element of an array ||of size n --- Comment #2 from Thomas Koenig --- This should be rejected.
[Bug fortran/92976] [8 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976 Thomas Koenig changed: What|Removed |Added Target Milestone|10.0|8.5 Summary|[8/9/10 Regression][OOP]|[8 Regression][OOP] ICE in |ICE in trans_associate_var, |trans_associate_var, at |at |fortran/trans-stmt.c:1963 |fortran/trans-stmt.c:1963 |
[Bug fortran/92976] [8 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976 --- Comment #4 from Thomas Koenig --- Fix on trunk was https://gcc.gnu.org/g:957a1b14e99596610abb0777ca86a1c80dde24e0 .
[Bug fortran/94386] [10 Regression] FAIL: gfortran.dg/pr93365.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94386 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-03-29 --- Comment #1 from Thomas Koenig --- The error is here: Program received signal SIGSEGV, Segmentation fault. match_data_constant (result=0x7fffd628) at ../../gcc/gcc/fortran/decl.c:426 426 if ((*result)->symtree->n.sym->attr.save (gdb) l 421 attribute. ... If data-stmt-constant is initial-data-target 422 the corresponding data statement object shall be 423 data-pointer-initialization compatible (7.5.4.6) with the initial 424 data target; the data statement object is initially associated 425 with the target. */ 426 if ((*result)->symtree->n.sym->attr.save 427 && (*result)->symtree->n.sym->attr.target) 428 return m; 429 gfc_free_expr (*result); 430 } (gdb) p (*result)->symtree $1 = (gfc_symtree *) 0x0 (gdb) call debug(*result) (/ /) (INTEGER 4)
[Bug fortran/93579] [9/10 Regression] ICE in gfc_conv_substring_expr, at fortran/trans-expr.c:8587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93579 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED CC||tkoenig at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #4 from Thomas Koenig --- Fixed, then.
[Bug target/94551] New: [10 Regression] Bootstrap failure on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94551 Bug ID: 94551 Summary: [10 Regression] Bootstrap failure on powerpc64le-unknown-linux-gnu Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- This is with commit e26bd694c790b7c8f68c6736b2683c60a8fcbcfe, as of just now.l The machine is gcc135.fsffrance.org, in case anybody wants to reproduce. /home/tkoenig/trunk-bin/./prev-gcc/xg++ -B/home/tkoenig/trunk-bin/./prev-gcc/ -B/home/tkoenig/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++ -B/home/tkoenig/trunk-bin/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/tkoenig/trunk-bin/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/tkoenig/trunk-bin/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/tkoenig/trunk-bin/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/tkoenig/trunk/libstdc++-v3/libsupc++ -L/home/tkoenig/trunk-bin/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/tkoenig/trunk-bin/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fchecking=1 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/dpd -I../libdecnumber -I../../trunk/gcc/../libbacktrace -o tree-streamer.o -MT tree-streamer.o -MMD -MP -MF ./.deps/tree-streamer.TPo ../../trunk/gcc/tree-streamer.c during RTL pass: vartrack ../../trunk/gcc/tree-streamer.c: In function 'void streamer_check_handled_ts_structures()': ../../trunk/gcc/tree-streamer.c:99:1: internal compiler error: in vt_expand_var_loc_chain, at var-tracking.c:8355 99 | } | ^
[Bug fortran/93762] Truncation of deferred-length string when passing as optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93762 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-10 CC||tkoenig at gcc dot gnu.org --- Comment #1 from Thomas Koenig --- Unfortunately, the test case fails with different ways on current trunk: $ gfortran -g a.f90 $ ./a.out at bot of deepest_call, str is "12345" Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f0a66c3059f in ??? at /usr/src/debug/glibc-2.26-lp151.19.11.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 #1 0x400c65 in __interface_call_m_MOD_interface_call at /tmp/a.f90:20 #2 0x400d99 in MAIN__ at /tmp/a.f90:32 #3 0x400f0b in main at /tmp/a.f90:25 Speicherzugriffsfehler (Speicherabzug geschrieben) (gdb) r a.f90 Starting program: /tmp/a.out a.f90 at bot of deepest_call, str is "12345" Program received signal SIGSEGV, Segmentation fault. _gfortran_string_len_trim (s=0x6068d0 "12345", len=) at ../../../gcc/libgfortran/intrinsics/string_intrinsics_inc.c:231 231 if (*((unsigned long*) (s + i + 1)) != blank_longword) (gdb) p s $1 = 0x6068d0 "12345" (gdb) p i $2 = 564082115390472183 Seems like uninitialzed memory for i. Valgrind confirms this: $ valgrind ./a.out ==5621== Memcheck, a memory error detector ==5621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==5621== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==5621== Command: ./a.out ==5621== at bot of deepest_call, str is "12345" ==5621== Conditional jump or move depends on uninitialised value(s) ==5621==at 0x50A29A5: _gfortran_string_len_trim (string_intrinsics_inc.c:188) ==5621==by 0x50A2A87: _gfortran_string_trim (string_intrinsics_inc.c:168) ==5621==by 0x400C65: __interface_call_m_MOD_interface_call (a.f90:20) ==5621==by 0x400D99: MAIN__ (a.f90:32) ==5621==by 0x400F0B: main (a.f90:25) Not sure if this ever worked in a released version.
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Last reconfirmed||2020-04-11 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Thomas Koenig --- Is there a test case?
[Bug fortran/94104] Request for diagnostic improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-04-11 Status|UNCONFIRMED |NEW CC||tkoenig at gcc dot gnu.org Severity|normal |enhancement --- Comment #1 from Thomas Koenig --- Would be useful, yes.
[Bug fortran/94091] Erroneous __builtin_memcpy warning for character assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94091 Thomas Koenig changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Last reconfirmed||2020-04-11 Ever confirmed|0 |1 CC||tkoenig at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Thomas Koenig --- This seems to be fixed on current trunk. Once I have wrestled git into a state that I can work with, I will commit a test case and then close as FIXED.
[Bug fortran/94091] Erroneous __builtin_memcpy warning for character assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94091 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Koenig --- So, fixed, and if it recurs, we'll see it. Thanks a lot for reporting the issue!
[Bug fortran/94090] ICE on mismatched interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94090 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Last reconfirmed||2020-04-12 Ever confirmed|0 |1 Keywords||error-recovery, ||ice-on-invalid-code Status|UNCONFIRMED |NEW --- Comment #1 from Thomas Koenig --- Confirmed at least down to gfortran 7. It does indeed issue a warning: /usr/bin/gfortran interface_46.f90 interface_46.f90:17:4: function cntf(a) result(s) 1 Warning: Interface mismatch in global procedure ‘cntf’ at (1): Rank mismatch in function result (0/1) [-Wargument-mismatch] interface_46.f90:30:0: s = cntf(arr) internal compiler error: in fold_convert_loc, at fold-const.c:2275 It might make more sense to issue an error in case of a function result.
[Bug fortran/94090] ICE on mismatched interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94090 Thomas Koenig changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Thomas Koenig --- Easy enough to fix.
[Bug fortran/94192] ICE on wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94192 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED CC||tkoenig at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #4 from Thomas Koenig --- Fixed on trunk, closing. Thanks for the bug report!
[Bug fortran/94110] Erroneous code compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING CC||tkoenig at gcc dot gnu.org Last reconfirmed||2020-04-13 --- Comment #1 from Thomas Koenig --- (In reply to José Rui Faustino de Sousa from comment #0) > Created attachment 48000 [details] > Code demonstrating problems. > > Hi all! > > I am pretty sure this code is erroneous both because you can not pass an > assumed-size to an assumed-shape This is entirely possible and normal practice, and is often done by normal code. (I am, however, willing to be corrected). > and because of pointer association rules. Which rules? Can you specify what the standard says about this case? (If it is a numbered constraint, then a compiler is required to diagnose it. If it is something like "shall" or "shall not", then it is up to the programmer to get this right; a good implementation might catch the error, but it is not required to do so).
[Bug fortran/94270] Bogus unused dummy argument warning/error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 CC||tkoenig at gcc dot gnu.org Last reconfirmed||2020-04-13 Status|UNCONFIRMED |NEW --- Comment #1 from Thomas Koenig --- Confirmed.
[Bug fortran/94270] [8/9/10 Regression] Bogus unused dummy argument warning/error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |8.5 Summary|Bogus unused dummy argument |[8/9/10 Regression] Bogus |warning/error |unused dummy argument ||warning/error Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- This should be a one-line fix.
[Bug fortran/94270] [8/9/10 Regression] Bogus unused dummy argument warning/error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270
--- Comment #3 from Thomas Koenig ---
Not quite a one-liner, but looks good:
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 75a50c999b7..8f041f0a0a8 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -5317,7 +5317,6 @@ gfc_get_formal_from_actual_arglist (gfc_symbol *sym,
s->ts.is_iso_c = 0;
s->ts.is_c_interop = 0;
s->attr.flavor = FL_VARIABLE;
- s->attr.artificial = 1;
if (a->expr->rank > 0)
{
s->attr.dimension = 1;
@@ -5332,6 +5331,7 @@ gfc_get_formal_from_actual_arglist (gfc_symbol *sym,
s->maybe_array = maybe_dummy_array_arg (a->expr);
}
s->attr.dummy = 1;
+ s->attr.artificial = 1;
s->declared_at = a->expr->where;
s->attr.intent = INTENT_UNKNOWN;
(*f)->sym = s;
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index e91a2795762..487e776f5dd 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -6072,7 +6072,7 @@ generate_local_decl (gfc_symbol * sym)
/* Unused procedure passed as dummy argument. */
if (sym->attr.flavor == FL_PROCEDURE)
{
- if (!sym->attr.referenced)
+ if (!sym->attr.referenced && !sym->attr.artificial)
{
if (warn_unused_dummy_argument)
gfc_warning (OPT_Wunused_dummy_argument,
[Bug fortran/94270] [8/9 Regression] Bogus unused dummy argument warning/error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270 --- Comment #7 from Thomas Koenig --- (In reply to Ignacio Fernández Galván from comment #6) > Will the fix be backported to gcc7? I noticed this when Ubuntu updated the > gcc7 version, so I would like to have the chance of seeing it fixed > eventually too. I'm afraid not, gcc 7 is no longer maintained. I will backport to gcc 8, so when the final release of gcc 8 occurs (in about a year), it will be included. Alternatively, Ubuntu might decide to package gcc 9 earlier than that.
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||pault at gcc dot gnu.org Last reconfirmed||2020-04-14 --- Comment #3 from Thomas Koenig --- The span field is either not set correctly, or it is ignored during the RESHAPE. I'll look a little further...
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578 --- Comment #4 from Thomas Koenig --- Looks like span is not handled in reshape (at all). It will be interesting to see how other intrinsics such as maxloc and just about everything else handles this.
[Bug fortran/94270] [8/9 Regression] Bogus unused dummy argument warning/error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94270 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Thomas Koenig --- Well, should be fixed now. Onto new shores...
[Bug fortran/94110] Passing an assumed-size to an assumed-shape argument should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94110 Thomas Koenig changed: What|Removed |Added Severity|normal |enhancement Summary|Erroneous code compiling|Passing an assumed-size to ||an assumed-shape argument ||should be rejected Keywords|accepts-invalid |diagnostic Status|WAITING |NEW --- Comment #3 from Thomas Koenig --- So, as far as I can see, not something that the compiler is required to diagnose. Confirming as an enhancement.
[Bug fortran/94022] Array slices of assumed-size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022 Thomas Koenig changed: What|Removed |Added Last reconfirmed||2020-04-14 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Thomas Koenig --- Can you simplify this somewhat, and not use assumed shape in your test case? This adds a complication that could well be the real bug, or hide a bug.
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 CC||pault at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Last reconfirmed||2020-04-14 Status|UNCONFIRMED |NEW --- Comment #2 from Thomas Koenig --- (In reply to martin from comment #0) > The following code (compiled without any options) prints "15000, 1" for > the second call to foo, instead of the expected "2, 1". The first > call to foo gives the expected result. This is also reproducible with > gfortran-10 branch. > > This code is a variation of the one reported in bug 93918 to further > understand temporary array creation. > > program array_temps > implicit none > > type :: tt >integer :: u = 1 >integer :: v = 2 > end type tt > > type(tt), dimension(:), pointer :: r > integer :: n > integer, dimension(:), pointer :: p > > allocate(r(1:n)) This test case does not define n. Assuming you want to write n=1 in there, I concur that the output should be as you describe. I assume that the span is not used correctly in the function. The test case works if you do p => r(:)%v instead of the call to get().
[Bug fortran/93948] Surprising option processing of -fdec and -fdec-math in combination with -std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93948 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- Hm, maybe a better thing to do would be just to issue a hard error when combining any of the -dec options with any -std= option.
[Bug fortran/93500] ICE in gfc_numeric_ts, at fortran/expr.c:891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93500 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Thomas Koenig --- Steve, I'll give your patch a spin and commit as obvious if it survives regression-testing.
[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94030 Thomas Koenig changed: What|Removed |Added CC||jiri.pitt...@jh-inst.cas.cz --- Comment #9 from Thomas Koenig --- *** Bug 88452 has been marked as a duplicate of this bug. ***
[Bug fortran/88452] gfortran (Gentoo 8.2.0-r5 p1.6) 8.2.0 reports internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88452 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Thomas Koenig --- This is now rejected with a.f90:6:18: 6 | equivalence(tt1(1,1), ctt1(1,1)) | 1 Error: Array 'tt1' at (1) with non-constant bounds cannot be an EQUIVALENCE object a.f90:6:27: 6 | equivalence(tt1(1,1), ctt1(1,1)) | 1 Error: Array 'ctt1' at (1) with non-constant bounds cannot be an EQUIVALENCE object as per PR 94030 (which is the correct error message, see C8109 in F2018). So, resolving as duplicate. *** This bug has been marked as a duplicate of bug 94030 ***
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578 --- Comment #5 from Thomas Koenig --- Somewhat smaller test case: program main implicit none type foo integer :: x, y end type foo integer :: i integer, dimension (2,2) :: array2d integer, dimension(:), pointer :: array1d type(foo), dimension(2*2), target :: solution data array2d /1,2,3,4/ array1d => solution%x print *,array2d array1d = reshape (source=array2d, shape=shape(array1d)) print *,array1d end program main
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578 --- Comment #6 from Thomas Koenig --- Also wrong: program main implicit none type foo integer :: x, y end type foo integer :: i integer, dimension (2,2) :: array2d integer, dimension(:), pointer :: array1d type(foo), dimension(2*2), target :: solution data array2d /1,3,2,4/ array1d => solution%x array1d = reshape (source=array2d, shape=shape(array1d)) print *,maxval(array2d) print *,maxval(array1d) end program main prints 4 2
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578 --- Comment #8 from Thomas Koenig --- The bug appears to affect intrinsics only, for example this program main implicit none type foo integer :: x, y end type foo integer, dimension(:), pointer :: bp type (foo), dimension(4), target :: b data b%x /1,2,3,4/ data b%y /-1,-2,-3,-4/ bp => b%x bp = x() print *,bp contains function x() integer, dimension(4) :: x x = [11,12,13,14] end function x end program main works as expected (and creates an array temporary). Let's see what we can do here, if this should be solved on the library side or if we should just insert a temporary array here...
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578
--- Comment #9 from Thomas Koenig ---
Here's what a solution could look like. I am not really sure that this
is the way to go, there may be some corner cases (pointer to an
argument which was passed as a transposed argument?) which this
might get wrong.
diff --git a/libgfortran/generated/maxval_i4.c
b/libgfortran/generated/maxval_i4.c
index abad45b50ae..3a9ed436956 100644
--- a/libgfortran/generated/maxval_i4.c
+++ b/libgfortran/generated/maxval_i4.c
@@ -50,6 +50,7 @@ maxval_i4 (gfc_array_i4 * const restrict retarray,
index_type delta;
index_type dim;
int continue_loop;
+ int ret_factor;
/* Make dim zero based to avoid confusion. */
rank = GFC_DESCRIPTOR_RANK (array) - 1;
@@ -112,6 +113,7 @@ maxval_i4 (gfc_array_i4 * const restrict retarray,
return;
}
+ ret_factor = 1;
}
else
{
@@ -124,12 +126,16 @@ maxval_i4 (gfc_array_i4 * const restrict retarray,
if (unlikely (compile_options.bounds_check))
bounds_ifunction_return ((array_t *) retarray, extent,
"return value", "MAXVAL");
+ if (retarray->span != 0)
+ ret_factor = retarray->span / sizeof(GFC_INTEGER_4);
+ else
+ ret_factor = 1;
}
for (n = 0; n < rank; n++)
{
count[n] = 0;
- dstride[n] = GFC_DESCRIPTOR_STRIDE(retarray,n);
+ dstride[n] = GFC_DESCRIPTOR_STRIDE(retarray,n) * ret_factor;
if (extent[n] <= 0)
return;
}
[Bug fortran/94090] ICE on mismatched interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94090 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Thomas Koenig --- Not a regression, and ICE on invalid (after a warning) is not important enough to backport. Hence, closing. Thanks a lot for the bug report!
[Bug libfortran/94143] [9/10 Regression] Asynchronous execute_command_line() breaks following synchronous calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94143 Thomas Koenig changed: What|Removed |Added Last reconfirmed||2020-04-18 Keywords||wrong-code Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Thomas Koenig --- Confirmed. It would be nice to get this fixed before releasing 10.0.
[Bug fortran/93500] ICE in gfc_numeric_ts, at fortran/expr.c:891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93500 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Thomas Koenig --- Fixed on trunk, closing.
[Bug fortran/94347] Assignment pointer at declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94347 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-04-19 CC||tkoenig at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #2 from Thomas Koenig --- Works with current trunk and gcc 9.
[Bug fortran/94347] Assignment pointer at declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94347 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Thomas Koenig --- Fixed, closing. Thanks for the bug report!
[Bug fortran/93338] [8/9/10 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93338 --- Comment #5 from Thomas Koenig --- Works now, probably fixed by Paul's work on associate.
[Bug fortran/93338] [8/9/10 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93338 --- Comment #6 from Thomas Koenig --- Correction: Fails with -O, does not fail without optimization.
[Bug fortran/93338] [8/9/10 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93338
--- Comment #7 from Thomas Koenig ---
(In reply to Richard Biener from comment #2)
> Likely another missing DECL_EXPR for variable-size stuff. TYPE_SIZE has
>
> (bitsizetype) (sizetype) _29 * 8
>
> and _29 is released.
This is confusing.
Grepping through the gimple dump for the length .y , I see
sizetype .y.16;
integer(kind=8) .y;
.y = _24;
.y.15_29 = .y;
.y.16 = (sizetype) .y.15_29;
y.dtype.elem_len = .y.16;
character(kind=1)[0:][1:.y] * D.3961;
.y.19_40 = .y;
_41 = _39 * .y.19_40;
.y.20_44 = .y;
_45 = _gfortran_compare_string (.y.20_44, _43, 3, &"abc"[1]{lb:
1 sz: 1});
.y = {CLOBBER};
so cheking the indentation, .y is correctly declared.
_29 seems to be a variable that is introduced by gimple, possibly
incorrectly. I am not sure how to debug this, or if this is even
a front-end error, or just exposes something in the middle end.
[Bug fortran/91800] ICE in gfc_code2string(): Bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91800 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Thomas Koenig --- Patch committed. Thanks for the bug report and for the patch!
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956
--- Comment #4 from Thomas Koenig ---
Taking the slightly modified test case
program array_temps
implicit none
type :: tt
integer :: u = 1
integer :: v = 2
end type tt
type(tt), dimension(:), pointer :: r
integer :: n
integer, dimension(:), pointer :: p
n = 10
allocate(r(1:n))
p => get(r)
call foo(p, n)
print *,sum(p)
deallocate(r)
contains
subroutine foo(a, n)
integer, dimension(:), intent(in) :: a
integer, intent(in) :: n
print *, sum(a(1:n)), n
end subroutine foo
function get(x) result(q)
type(tt), dimension(:), target, intent(in) :: x
integer, dimension(:), pointer :: q
q => x(:)%v
end function get
end program array_temps
and looking at -fdump-tree-original shows something strange.
get looks good:
{
integer(kind=8) D.3946;
integer(kind=8) D.3947;
D.3946 = ubound.0;
__result->span = 8;
__result->dtype = {.elem_len=4, .rank=1, .type=1};
D.3947 = stride.1;
__result->dim[0].lbound = 1;
__result->dim[0].ubound = D.3946;
__result->dim[0].stride = NON_LVALUE_EXPR ;
__result->data = (void *) &(*x.0)[0].v;
__result->offset = -NON_LVALUE_EXPR ;
}
so the result for span is set.
The call to get and foo does not look to bad, either:
{
struct array01_integer(kind=4) ptrtemp.15;
struct array01_tt * D.4002;
struct tt[0:] * ifm.16;
integer(kind=8) D.4004;
integer(kind=8) D.4005;
ptrtemp.15.span = 4;
D.4002 = &r;
ifm.16 = (struct tt[0:] *) D.4002->data;
D.4004 = (D.4002->dim[0].ubound - D.4002->dim[0].lbound) + 1;
D.4005 = -NON_LVALUE_EXPR dim[0].stride>;
get (&ptrtemp.15, D.4002);
p = ptrtemp.15;
}
foo (&p, &n);
But it seems that foo does not use the span at all.
OK, so what about the test case
program array_temps
implicit none
type :: tt
integer :: u = 1
integer :: v = 2
end type tt
type(tt), dimension(:), pointer :: r
integer :: n
integer, dimension(:), pointer :: p
n = 10
allocate(r(1:n))
p => r%v
call foo(p, n)
print *,sum(p)
deallocate(r)
contains
subroutine foo(a, n)
integer, dimension(:), intent(in) :: a
integer, intent(in) :: n
print *, sum(a(1:n)), n
end subroutine foo
end program array_temps
?
There, we actually convert the argument on call to foo:
p = r;
p.data = (void *) &(*(struct tt[0:] *) r.data)[0].v;
p.span = r.span;
p.dim[0].ubound = p.dim[0].ubound + (1 - p.dim[0].lbound);
p.offset = p.offset - (1 - p.dim[0].lbound) * p.dim[0].stride;
p.dim[0].lbound = 1;
{
integer(kind=4)[0:] * D.3975;
integer(kind=8) D.3976;
integer(kind=8) D.3977;
integer(kind=8) D.3978;
integer(kind=8) D.3979;
struct array01_integer(kind=4) atmp.11;
logical(kind=4) D.3987;
integer(kind=8) D.3988;
void * restrict D.3989;
void * restrict D.3990;
integer(kind=8) D.3991;
integer(kind=4)[0:] * D.3995;
integer(kind=8) D.3996;
integer(kind=8) D.3997;
integer(kind=8) D.3998;
integer(kind=8) D.3999;
D.3975 = (integer(kind=4)[0:] *) p.data;
D.3976 = p.offset;
D.3977 = p.dim[0].lbound;
D.3978 = p.dim[0].ubound;
D.3979 = D.3978 - D.3977;
typedef integer(kind=4) [0:];
atmp.11.dtype = {.elem_len=4, .rank=1, .type=1};
atmp.11.dim[0].stride = 1;
atmp.11.dim[0].lbound = 0;
atmp.11.dim[0].ubound = D.3979;
D.3987 = D.3979 < 0;
D.3988 = D.3979 + 1;
atmp.11.span = 4;
D.3989 = (void * restrict) __builtin_malloc (D.3987 ? 1 : MAX_EXPR
<(unsigned long) (D.3988 * 4), 1>);
D.3990 = D.3989;
atmp.11.data = D.3990;
atmp.11.offset = 0;
D.3991 = NON_LVALUE_EXPR ;
{
integer(kind=8) S.12;
integer(kind=8) D.3993;
D.3993 = p.dim[0].stride;
S.12 = 0;
while (1)
{
if (S.12 > D.3979) goto L.3;
(*(integer(kind=4)[0:] * restrict) atmp.11.data)[S.12] =
*((integer(kind=4) *) D.3975 + (sizetype) (((S.12 + D.3991) * D.3993 + D.3976)
* p.span));
S.12 = S.12 + 1;
}
L.3:;
}
foo (&atmp.11, &n);
__builtin_free ((void *) atmp.11.data);
This is not ideal from a performance perspective, but at least
it generated correct code.
So, it appears that somewhere, that conversion goes missing
(and it would also be enough just to convert the descriptor,
no real need to copy the data).
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 --- Comment #5 from Thomas Koenig --- So, the problem seems to be that sym->attr.subref_array_pointer is not set on the original test case. It should be set by p => get(r(:)) (or by an equivalent call get2(r)) because we don't know what the particular subroutine may be doing.
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #6 from Thomas Koenig --- Let's see if I can get this fixed.
[Bug fortran/92993] [8/9 Regression] ICE in maybe_canonicalize_comparison_1, at fold-const.c:8845
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92993 Thomas Koenig changed: What|Removed |Added Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in |maybe_canonicalize_comparis |maybe_canonicalize_comparis |on_1, at fold-const.c:8845 |on_1, at fold-const.c:8845 --- Comment #6 from Thomas Koenig --- (In reply to anlauf from comment #4) > The testcase in comment#0 compiles for me with today's master. > Has this been fixed accidentally? Maybe someone can bisect > so that one can identify the commit that might be backported > to fix the regression. This probably was https://gcc.gnu.org/g:2298af0800b292f028298c1eaec42fd3033c4b9b the fix for PR94090. I think this is something that could be backported.
[Bug middle-end/91512] [10 Regression] Fortran compile time regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91512 --- Comment #26 from Thomas Koenig --- (In reply to Bill Seurer from comment #25) > This is affecting us on powerpc64 as well. It takes twice as long to build > the spec2017 test cases with most of the difference in a few of the fortran > compilations which take 30 times or more longer. I tried the new option but > it seems to have no effect. > > Some quick comparison timings: > > compiling module_first_rk_step_part1.fppized.f90 (part of 521.wrf_r) > > r10-484: 0m17, 0m14 > r10-485: 9m19, 9m17 > r10-7837 (current-ish trunk): 9m57, 10m3 > r10-7837 with -finline-arg-packing: 9m58, 9m59 > > Compiling all of spec2017 > > r10-484: 34m8 > r10-485: 65m1 > r10-7837: 63m47 > r10-7837 w. option: 65m36 Does the option actually work, i.e. does it have the desired effect of not expanding the packing inline? Maybe you could do a quick check of the tree dumps generated.
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 --- Comment #7 from Thomas Koenig --- Created attachment 48328 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48328&action=edit Patch which sould create the right temporaries Well, this should to the trick - at least fixes the test case.
[Bug fortran/90350] ubound ICE on assumed size array even though explicit bound is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90350 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Thomas Koenig --- Fixen on trunk, closing. Thanks for the bug report!
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 --- Comment #11 from Thomas Koenig --- Fixed on all open branches. Thanks a lot for the bug report! Regards
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Thomas Koenig --- Fixed.
[Bug fortran/93924] ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-25 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- Confirmed.
[Bug fortran/93563] Wrong code makes the compiler hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93563 Thomas Koenig changed: What|Removed |Added Last reconfirmed||2020-04-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||tkoenig at gcc dot gnu.org Keywords||ice-on-invalid-code, ||memory-hog --- Comment #1 from Thomas Koenig --- Confirmed.
[Bug fortran/94737] [8/9/10 Regression] BIND(C) names are not always treated as case sensitive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 Thomas Koenig changed: What|Removed |Added Summary|BIND(C) names are not |[8/9/10 Regression] BIND(C) |always treated as case |names are not always |sensitive. Versions < 8|treated as case sensitive. |are ok. | Keywords||rejects-valid CC| |tkoenig at gcc dot gnu.org Target Milestone|--- |8.5
[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Summary|[8/9/10 Regression] BIND(C) |BIND(C) names are not |names are not always|always treated as case |treated as case sensitive. |sensitive. Resolution|--- |INVALID --- Comment #2 from Thomas Koenig --- Correction, this is not a regression. F2018 has, in 19.2, paragraph 2 # The global identifier of an entity shall not be the same as the global # identifier of any other entity. Furthermore, a binding label shall not # be the same as the global identifier of any other global entity, # ignoring differences in case. So, the error message is correct, and you need to change your program accordingly.
[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 --- Comment #6 from Thomas Koenig --- (In reply to Lee Busby from comment #4) > (In reply to kargl from comment #3) > > (In reply to Thomas Koenig from comment #2) > > > Correction, this is not a regression. > > > > > > F2018 has, in 19.2, paragraph 2 > > > > > > # The global identifier of an entity shall not be the same as the global > > > # identifier of any other entity. Furthermore, a binding label shall not > > > # be the same as the global identifier of any other global entity, > > > # ignoring differences in case. > > > > > > So, the error message is correct, and you need to change your > > > program accordingly. > > > > Good catch, Thomas! > > > > In hindsight, the restriction makes prefect sense given > > Fortran is a case insensitive language. > > I don't have any particular problem using 19.2 to make this a feature, not a > bug. Clarity is always better. I wonder how does 19.2 square with 8.5.5, > lines 13-14: > > # If the value of the [NAME=scalar-character-constant] is [...] nonzero, > # it shall be valid as an identifier on the companion processor. > > If you ignore the case of an identifier in the C language (the "companion > processor"?), I suppose it is still "valid". That's not what is happening. According to the Fortran standard, we ignore the case when determining if there is a duplicate global symbol, which we then reject. You can use a C symbol with whatever case mix you want. Take, for example module foo interface function func1(ii) result (k) bind(c, name="C_fUnC") integer :: ii integer :: k end function func1 end interface contains function func2(ii) result (k) integer :: ii integer :: k k = func1(ii) end function func2 end module foo $ gfortran -c a.f90 $ nm a.o U C_fUnC T __foo_MOD_func2 where you see an identifier "C_fUnC" (your external C function) as an undefined symbol, so you can link it against an object file containing that function, and all will be fine. Regarding extensions: We have quite a few (maybe too many...) for old features, for code that was written before modern Fortran arrived. People need them, so we usually accept patches for this kind of thing. If there is a prohibition against the user doing something in the standard, like in this case (marked by "shall" or "shall not"), we usually try to identify the error to help the user correct his code. Hmm... I just checked, and found that, while we get this right, there is no test case to make sure we don't regress. I will add that shortly.
[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737 --- Comment #8 from Thomas Koenig --- So, test case committed. Thanks for the bug report! Even though it turned out to be invalid, it still ended up making the compiler better.
[Bug fortran/93114] Use span passing components of derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93114 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-04-27 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #1 from Thomas Koenig --- Assigning to myself so I do not forget this.
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578 Thomas Koenig changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93114 --- Comment #12 from Thomas Koenig --- (In reply to Jan-Willem Blokland from comment #11) > If you make use of an temporary variable, it sounds like you will do an > additional memory copy. Therefore, I am wondering what the performance > impact will be. Naively, I would think the span solution would be faster. You are quite correct, but an optimized fix will take far more time than is available until a release candidate for gcc 10 comes out and all development is frozen. I'd rather have correct code on gcc 10. I will revisit this later as part of PR 93114.
[Bug fortran/94769] Possible use of uninitialized variable num
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #5 from Thomas Koenig ---
Steve,
is this sort of what you had in mind?
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -3840,7 +3840,7 @@ if (condition) \
if (dt->asynchronous)
{
- int num;
+ int num = 42; /* Fix stupid gcc warning. */
static const char * asynchronous[] = { "YES", "NO", NULL };
/* Note: gfc_reduce_init_expr reports an error if not init-expr. */
@@ -3853,6 +3853,7 @@ if (condition) \
io_kind_name (k), warn, &dt->asynchronous->where, &num))
return false;
+ gcc_assert (num != 42);
/* For "YES", mark related symbols as asynchronous. */
if (num == 0)
{
[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #8 from Thomas Koenig --- I'd like to understand what went wrong here... I suspect that the fix exposed another bug somewhere :-( Is it possible to isolate a test case like that? If that is the offending patch, I think it is probably about a pointer to a variable of a derived type, either via a function or as an argument (look at the test case to see what the patch fixes).
[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #10 from Thomas Koenig --- (In reply to Richard Biener from comment #3) > Can you maybe bisect this to a specific (fortran) commit in GCC? Richard, when is the last time (presumably) that either a fix can go in or the patch can be reverted?
[Bug fortran/94788] [10 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-27 Ever confirmed|0 |1 --- Comment #17 from Thomas Koenig --- Thanks for the reproducer, this is definitely fishy. valgrind shows: ==21250== Invalid free() / delete / delete[] / realloc() ==21250==at 0x4C2F3B9: free (vg_replace_malloc.c:540) ==21250==by 0x804071: __simulations_uti_MOD_simulations_10 (simulations_uti.f90:42) ==21250==by 0x40A504: __unit_tests_MOD_test (unit_tests.f90:175) ==21250==by 0x804EC5: __simulations_ut_MOD_simulations_test (simulations_ut.f90:45) ==21250==by 0x806AC5: whizard_check.0 (in /home/ig25/Downloads/Whiz/whizard_test) ==21250==by 0x80771A: MAIN__ (in /home/ig25/Downloads/Whiz/whizard_test) ==21250==by 0x808733: main (in /home/ig25/Downloads/Whiz/whizard_test) ==21250== Address 0x959ae00 is 0 bytes inside a block of size 20 free'd ==21250==at 0x4C2F3B9: free (vg_replace_malloc.c:540) ==21250==by 0x8009FE: __simulations_uti_MOD_simulations_10 (simulations_uti.f90:124) ==21250==by 0x40A504: __unit_tests_MOD_test (unit_tests.f90:175) ==21250==by 0x804EC5: __simulations_ut_MOD_simulations_test (simulations_ut.f90:45) ==21250==by 0x806AC5: whizard_check.0 (in /home/ig25/Downloads/Whiz/whizard_test) ==21250==by 0x80771A: MAIN__ (in /home/ig25/Downloads/Whiz/whizard_test) ==21250==by 0x808733: main (in /home/ig25/Downloads/Whiz/whizard_test) ==21250== Block was alloc'd at ==21250==at 0x4C2E221: malloc (vg_replace_malloc.c:309) ==21250==by 0x73EDEA: __rt_data_MOD_rt_data_activate (rt_data.f90:509) ==21250==by 0x7FFEF2: __simulations_uti_MOD_simulations_10 (simulations_uti.f90:104) ==21250==by 0x40A504: __unit_tests_MOD_test (unit_tests.f90:175) ==21250==by 0x804EC5: __simulations_ut_MOD_simulations_test (simulations_ut.f90:45) ==21250==by 0x806AC5: whizard_check.0 (in /home/ig25/Downloads/Whiz/whizard_test) ==21250==by 0x80771A: MAIN__ (in /home/ig25/Downloads/Whiz/whizard_test) ==21250==by 0x808733: main (in /home/ig25/Downloads/Whiz/whizard_test) ==21250== and lots more.
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 Thomas Koenig changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94788 --- Comment #15 from Thomas Koenig --- Reverted on trunk to fix PR 94788. I will revert the commit to the branches shortly.
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 Thomas Koenig changed: What|Removed |Added Version|10.0|9.3.1 Summary|[10 Regression] Severe |[8/9 Regression] Severe |regression leading to |regression leading to |double free in tcache |double free in tcache Target Milestone|10.0|9.4 --- Comment #19 from Thomas Koenig --- Fixed for the upcoming release, will revert on the branches shortly. Thanks for the bug report!
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING Blocks||93956 --- Comment #23 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #20) > Thanks a lot for reverting, Thomas, shall I further reduce the reproducer, > or can you work with it now? I could use it to confirm that there is a bug, but the test case is far too complex for analysis, and it is also not possible to put it in the testsuite. So, at the moment, work on PR 93956 (a F95 wrong-code bug, hence a high priority) is effectively blocked. So yes, I would appreciate a shorter reproducer, especially since I plan to revisit the whole span and pointer area once gcc 10 is out of the door. So, I'll mark this bug as WAITING for now. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 [Bug 93956] Wrong array creation with p => array_dt(1:n)%component
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #27 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #25) > Ok, Simon and I try our best, working independently, me reducing the > existing case further, and he tries to write a small reproducer from scratch. Thanks a lot! That is really appreciated.
[Bug fortran/94841] [10 Regression]527.cam4_r 7.68% regression on Intel Cascadelaker with -O2, 9.57% regression with -Ofast -march=native -funroll-loops -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94841 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94788, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93956, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93114 Status|WAITING |RESOLVED --- Comment #2 from Thomas Koenig --- (In reply to Richard Biener from comment #1) > Probably the mentioned inefficiency but the fix was a correctness one. I had to revert the patch because fixing one correctness issue introduced another one (PR 94788). > Needs a testcase, fortran folks do not have access to SPEC and the question > is whether the inefficiency can be fixed for the problematical case(s). In this particular case, the cause of the inefficiency is clear - creating a temporary because it is not kown if a pointer returned from a procedure has a span or not. And if we don't know, we need to do something about that, such as creating a temporary. We need to revisit this whole thing for gcc 11, also for PR 93114. I have some ideas already. Marking this as fixed in the meantime.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 94841, which changed state. Bug 94841 Summary: [10 Regression]527.cam4_r 7.68% regression on Intel Cascadelaker with -O2, 9.57% regression with -Ofast -march=native -funroll-loops -flto https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94841 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW --- Comment #33 from Thomas Koenig --- So, the first error in your reduced test case is ==8972== Invalid free() / delete / delete[] / realloc() ==8972==at 0x4C2F3B9: free (vg_replace_malloc.c:540) ==8972==by 0x5B2D05: __simulations_uti_MOD_simulations_10 (main_ut.f90:26224) ==8972==by 0x5B494E: MAIN__ (main_ut.f90:26298) ==8972==by 0x5B49BC: main (main_ut.f90:26288) ==8972== Address 0x7ed0510 is 0 bytes inside a block of size 8 free'd ==8972==at 0x4C2F3B9: free (vg_replace_malloc.c:540) ==8972==by 0x5B06F9: __simulations_uti_MOD_simulations_10 (main_ut.f90:26263) ==8972==by 0x5B494E: MAIN__ (main_ut.f90:26298) ==8972==by 0x5B49BC: main (main_ut.f90:26288) ==8972== Block was alloc'd at ==8972==at 0x4C2E221: malloc (vg_replace_malloc.c:309) ==8972==by 0x57D64E: __rt_data_MOD_rt_data_activate (main_ut.f90:24161) ==8972==by 0x5AFED1: __simulations_uti_MOD_simulations_10 (main_ut.f90:26250) ==8972==by 0x5B494E: MAIN__ (main_ut.f90:26298) ==8972==by 0x5B49BC: main (main_ut.f90:26288) where the invalid free is given in the line type(rt_data_t), dimension(1), target :: alt_env and the first one in call simulation%init ([procname1], .true., .true., global, alt_env=alt_env) type(rt_data_t) has a finalizer, rt_global_data_final. Hm, not tonight, but this is something to go on (I think).
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #35 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #34) > Created attachment 48411 [details] > Final reproducer, less than 300 lines ;) > > This one should be sufficient. No further files or input is necessary, it > seems that the problem lies in the combination of inheriting derived types, > allocatables and pointers. All the fun. You do like to stress the language and compilers, do you? :-) However, this last reproducer appears to have something different - it segfaults with released gfortran 8 and with or without the patch we are looking at. Also, the compiler warns pointer_assign_16.f90:195:0: 195 | if (associated (global)) then | Warnung: »global._data« wird in dieser Funktion uninitialisiert verwendet [-Wuninitialized] pointer_assign_16.f90:195:8: 195 | if (associated (global)) then |^ Warnung: »global._data« wird in dieser Funktion uninitialisiert verwendet [-Wuninitialized] I'll look at this tomorrow, when I don't have to do may day job.
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #37 from Thomas Koenig --- (In reply to Jürgen Reuter from comment #36) > Hm, I hope I didn't change the flavor of the bug, but you can cross-check > with the very first reproducer which contains our code more or less > unchanged (except for the build setup with autotools etc.). Since your latest reproducer fails with any version I tried, I suspect you may have deleted the one line too many. Hmm, checking... yes, this is the case. subroutine rt_data_activate (local) class(rt_data_t), intent(inout), target :: local class(rt_data_t), pointer :: global if (associated (global)) then local%logfile = global%logfile local%pn = global%pn end if end subroutine rt_data_activate A previous version has global => local%context as the first executable statement but that is rejected now; and if I comment out the whole body of the subroutine, there is no error.
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #40 from Thomas Koenig --- Yes, that test case works. Thanks a lot for putting in all the effort! Because we need -fsanitize=address to reliably detect this bug, I have proposed https://gcc.gnu.org/pipermail/gcc-patches/2020-May/544975.html which introduces such a gfortran.dg/asan directory where this can be tested.
[Bug fortran/93114] Use span passing components of derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93114 --- Comment #2 from Thomas Koenig --- Created attachment 48430 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48430&action=edit Preliminary partial patch Here is a very preliminary implementation, which only looks at the return values of maxloc et al. If we look at the arguments too, this will be much larger...
[Bug target/95018] New: Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
Bug ID: 95018
Summary: Excessive unrolling for Fortran library array handling
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 48488
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48488&action=edit
Generated assembly
The code generated for in_pack_i4.c from libgfortran on POWER9 is huge
and, presumably, slow; I assume that other code in the library is
similarly affected.
The problem manifests itself in the unrolling of the loops which
do all the work:
while (src)
{
/* Copy the data. */
*(dest++) = *src;
/* Advance to the next element. */
src += stride0;
count[0]++;
/* Advance to the next source element. */
index_type n = 0;
while (count[n] == extent[n])
{
/* When we get to the end of a dimension, reset it and increment
the next dimension. */
count[n] = 0;
/* We could precalculate these products, but this is a less
frequently used path so probably not worth it. */
src -= stride[n] * extent[n];
n++;
if (n == dim)
{
src = NULL;
break;
}
else
{
count[n]++;
src += stride[n];
}
}
}
return destptr;
}
One problem here is the while (count[n] == extent[n]) loop.
This is an odometer algorithm to look for the next element to
go to. Most of the times, the while is false, so it is definitely
not good.
x86_64 does not appear to be affected.
[Bug target/95018] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018 --- Comment #1 from Thomas Koenig --- Created attachment 48489 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48489&action=edit Preprocessed source
[Bug target/95018] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018 --- Comment #2 from Thomas Koenig --- Created attachment 48490 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48490&action=edit -fdump-tree-optimized dumpj Finally, the -fdump-tree-optimized dump. Unrolling already appears to happen in the middle end, all the way up to 15 (which is not good). The PHI nodes are also something to behold: [local count: 96219245]: # src_79 = PHI # count_I_lsm.31_531 = PHI # count_I_lsm.33_537 = PHI <0(36), 0(34), 0(38), _98(14), 0(16), 0(18), 0(20), 0(22), 0(24), 0(26), 0(28), 0(30), 0(32), 0(40)> # count_I_lsm.35_543 = PHI <0(36), 0(34), 0(38), count_I_lsm.35_542(14), _104(16), 0(18), 0(20), 0(22), 0(24), 0(26), 0(28), 0(30), 0(32), 0(40)> # count_I_lsm.37_549 = PHI <0(36), 0(34), 0(38), count_I_lsm.37_548(14), count_I_lsm.37_548(16), _109(18), 0(20), 0(22), 0(24), 0(26), 0(28), 0(30), 0(32), 0(40)> # count_I_lsm.39_555 = PHI <0(36), 0(34), 0(38), count_I_lsm.39_554(14), count_I_lsm.39_554(16), count_I_lsm.39_554(18), _126(20), 0(22), 0(24), 0(26), 0(28), 0(30), 0(32), 0(40)> # count_I_lsm.41_561 = PHI <0(36), 0(34), 0(38), count_I_lsm.41_560(14), count_I_lsm.41_560(16), count_I_lsm.41_560(18), count_I_lsm.41_560(20), _143(22), 0(24), 0(26), 0(28), 0(30), 0(32), 0(40)> # count_I_lsm.43_567 = PHI <0(36), 0(34), 0(38), count_I_lsm.43_566(14), count_I_lsm.43_566(16), count_I_lsm.43_566(18), count_I_lsm.43_566(20), count_I_lsm.43_566(22), _160(24), 0(26), 0(28), 0(30), 0(32), 0(40)> # count_I_lsm.45_573 = PHI <0(36), 0(34), 0(38), count_I_lsm.45_572(14), count_I_lsm.45_572(16), count_I_lsm.45_572(18), count_I_lsm.45_572(20), count_I_lsm.45_572(22), count_I_lsm.45_572(24), _177(26), 0(28), 0(30), 0(32), 0(40)> # count_I_lsm.47_579 = PHI <0(36), 0(34), 0(38), count_I_lsm.47_578(14), count_I_lsm.47_578(16), count_I_lsm.47_578(18), count_I_lsm.47_578(20), count_I_lsm.47_578(22), count_I_lsm.47_578(24), count_I_lsm.47_578(26), _194(28), 0(30), 0(32), 0(40)> # count_I_lsm.49_585 = PHI <0(36), 0(34), 0(38), count_I_lsm.49_584(14), count_I_lsm.49_584(16), count_I_lsm.49_584(18), count_I_lsm.49_584(20), count_I_lsm.49_584(22), count_I_lsm.49_584(24), count_I_lsm.49_584(26), count_I_lsm.49_584(28), _211(30), 0(32), 0(40)> # count_I_lsm.51_591 = PHI <0(36), 0(34), 0(38), count_I_lsm.51_590(14), count_I_lsm.51_590(16), count_I_lsm.51_590(18), count_I_lsm.51_590(20), count_I_lsm.51_590(22), count_I_lsm.51_590(24), count_I_lsm.51_590(26), count_I_lsm.51_590(28), count_I_lsm.51_590(30), _228(32), 0(40)> # count_I_lsm.53_597 = PHI <0(36), _245(34), 0(38), count_I_lsm.53_596(14), count_I_lsm.53_596(16), count_I_lsm.53_596(18), count_I_lsm.53_596(20), count_I_lsm.53_596(22), count_I_lsm.53_596(24), count_I_lsm.53_596(26), count_I_lsm.53_596(28), count_I_lsm.53_596(30), count_I_lsm.53_596(32), 0(40)> # count_I_lsm.55_603 = PHI <_262(36), count_I_lsm.55_602(34), 0(38), count_I_lsm.55_602(14), count_I_lsm.55_602(16), count_I_lsm.55_602(18), count_I_lsm.55_602(20), count_I_lsm.55_602(22), count_I_lsm.55_602(24), count_I_lsm.55_602(26), count_I_lsm.55_602(28), count_I_lsm.55_602(30), count_I_lsm.55_602(32), 0(40)> # count_I_lsm.57_609 = PHI [local count: 102536739]: # src_33 = PHI # count_I_lsm.8_29 = PHI <0(41), _15(12)> # count_I_lsm.31_532 = PHI # count_I_lsm.33_538 = PHI # count_I_lsm.35_544 = PHI # count_I_lsm.37_550 = PHI # count_I_lsm.39_556 = PHI # count_I_lsm.41_562 = PHI # count_I_lsm.43_568 = PHI # count_I_lsm.45_574 = PHI # count_I_lsm.47_580 = PHI # count_I_lsm.49_586 = PHI # count_I_lsm.51_592 = PHI # count_I_lsm.53_598 = PHI # count_I_lsm.55_604 = PHI # count_I_lsm.57_610 = PHI goto ; [100.00%] [local count: 29043813]: # _35 = PHI <_63(3), destptr_52(39), destptr_52(10), destptr_52(13), destptr_52(37), destptr_52(15), destptr_52(17), destptr_52(19), destptr_52(21), destptr_52(23), destptr_52(25), destptr_52(27), destptr_52(29), destptr_52(31), destptr_52(33), destptr_52(35), destptr_52(40)>
[Bug target/95018] [11 Regression] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |11.0 Summary|Excessive unrolling for |[11 Regression] Excessive |Fortran library array |unrolling for Fortran |handling|library array handling --- Comment #3 from Thomas Koenig --- Does not occur on 7.5.0, so it's an 11 regression at least. Further testing underway.
[Bug target/95018] [11 Regression] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018 --- Comment #4 from Thomas Koenig --- 9.3.0 is also not affected.
[Bug target/95018] [11 Regression] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018 --- Comment #5 from Thomas Koenig --- For 9.3.0, I get $ objdump --disassemble in_pack_i4.o | wc -l 123
[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018 Thomas Koenig changed: What|Removed |Added Summary|[11 Regression] Excessive |[10/11 Regression] |unrolling for Fortran |Excessive unrolling for |library array handling |Fortran library array ||handling CC||koenigni at gcc dot gnu.org, ||segher at gcc dot gnu.org Target||powerpc64le-unknown-linux-g ||nu Target Milestone|11.0|10.2 Version|11.0|10.0 --- Comment #6 from Thomas Koenig --- And gcc 10 is also affected: $ objdump --disassemble in_pack_i4.o | wc -l 451 So, marking this a 10/11 Regression.
[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018 --- Comment #7 from Thomas Koenig --- Just checked aarch64, and that also isn't affected: tkoenig@gcc116:~/gcc-bin/aarch64-unknown-linux-gnu/libgfortran$ objdump --disassemble in_pack_i4.o | wc -l 95
[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-05-11 Status|UNCONFIRMED |NEW --- Comment #8 from Thomas Koenig --- The patch which caused the problem was commit 6d099a76a0f6a040a3e678f2bce7fc69cc3257d8 Author: Jiufu Guo Date: Mon Oct 28 05:23:24 2019 + rs6000: Enable limited unrolling at -O2 In PR88760, there are a few disscussion about improve or tune unroller for targets. And we would agree to enable unroller for small loops at O2 first. And we could see performance improvement(~10%) for below code: ``` subroutine foo (i, i1, block) integer :: i, i1 integer :: block(9, 9, 9) block(i:9,1,i1) = block(i:9,1,i1) - 10 end subroutine foo ``` This kind of code occurs a few times in exchange2 benchmark. Similar C code: ``` for (i = 0; i < n; i++) arr[i] = arr[i] - 10; ``` On powerpcle, for O2 , enable -funroll-loops and limit PARAM_MAX_UNROLL_TIMES=2 and PARAM_MAX_UNROLLED_INSNS=20, we can see >2% overall improvement for SPEC2017. This patch is only for rs6000 in which we see visible performance improvement. gcc/ 2019-10-25 Jiufu Guo PR tree-optimization/88760 * config/rs6000/rs6000-common.c (rs6000_option_optimization_table): Enable -funroll-loops for -O2 and above. * config/rs6000/rs6000.c (rs6000_option_override_internal): Set PARAM_MAX_UNROLL_TIMES to 2 and PARAM_MAX_UNROLLED_INSNS to 20, and do not turn on web and rngreg implicitly, if the unroller is not explicitly enabled. gcc.testsuite/ 2019-10-25 Jiufu Guo PR tree-optimization/88760 * gcc.target/powerpc/small-loop-unroll.c: New test. * c-c++-common/tsan/thread_leak2.c: Update test. * gcc.dg/pr59643.c: Update test. * gcc.target/powerpc/loop_align.c: Update test. * gcc.target/powerpc/ppc-fma-1.c: Update test. * gcc.target/powerpc/ppc-fma-2.c: Update test. * gcc.target/powerpc/ppc-fma-3.c: Update test. * gcc.target/powerpc/ppc-fma-4.c: Update test. * gcc.target/powerpc/pr78604.c: Update test. From-SVN: r277501 So, this patch seems to have exposed a problem with the unrolling in general, or with the parameters for POWER.
[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018 --- Comment #9 from Thomas Koenig --- Created attachment 48502 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48502&action=edit Assembly file on x86 with -O2 -funroll-loops So, it seems the decisions made for unrolling are bad for this case independent of architecture - the cold loop is also unrolled 15 times on x86_64 with -funroll-loops. The change to POWER just happened to expose it. The code on x86_64 looks like # ../../../trunk/libgfortran/generated/in_pack_i4.c:76: destptr = xmallocarray (ssize, sizeof (GFC_INTEGER_4)); movq%rax, 152(%rsp) # tmp309, %sfp # ../../../trunk/libgfortran/generated/in_pack_i4.c:78: src = source->base_addr; movq0(%rbp), %rax # source_42(D)->base_addr, src # ../../../trunk/libgfortran/generated/in_pack_i4.c:82: while (src) testq %rax, %rax # src je .L1 #, # ../../../trunk/libgfortran/generated/in_pack_i4.c:91: while (count[n] == extent[n]) movq416(%rsp), %r15 # extent, _68 # ../../../trunk/libgfortran/generated/in_pack_i4.c:108: src += stride[n]; movq552(%rsp), %rdi # stride, _92 # ../../../trunk/libgfortran/generated/in_pack_i4.c:87: src += stride0; leaq0(,%rsi,4), %r12#, _13 # ../../../trunk/libgfortran/generated/in_pack_i4.c:108: src += stride[n]; movq560(%rsp), %r14 # stride, _24 movq568(%rsp), %r13 # stride, _112 # ../../../trunk/libgfortran/generated/in_pack_i4.c:98: src -= stride[n] * extent[n]; imulq %r15, %rsi # _68, tmp225 # ../../../trunk/libgfortran/generated/in_pack_i4.c:91: while (count[n] == extent[n]) movq%r15, 16(%rsp) # _68, %sfp movq424(%rsp), %r15 # extent, _73 movq%rdi, %r10 # _92, tmp226 movq%r14, %r9 # _24, tmp228 movq288(%rsp), %rdx # count, count_I_lsm.8 movq296(%rsp), %rcx # count, count_I_lsm.29 # ../../../trunk/libgfortran/generated/in_pack_i4.c:98: src -= stride[n] * extent[n]; imulq %r15, %rdi # _73, tmp227 # ../../../trunk/libgfortran/generated/in_pack_i4.c:91: while (count[n] == extent[n]) movq%r15, 32(%rsp) # _73, %sfp movq432(%rsp), %r15 # extent, _14 subq%rsi, %r10 # tmp225, tmp226 movq320(%rsp), %r8 # count, count_I_lsm.35 movq304(%rsp), %rsi # count, count_I_lsm.31 # ../../../trunk/libgfortran/generated/in_pack_i4.c:98: src -= stride[n] * extent[n]; imulq %r15, %r14 # _14, tmp229 leaq0(,%r10,4), %r11#, _78 movq%r13, %r10 # _112, tmp230 # ../../../trunk/libgfortran/generated/in_pack_i4.c:91: while (count[n] == extent[n]) ... and so on.
[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018 --- Comment #14 from Thomas Koenig --- Most Fortran arrays are one- or two-dimensional. Assuming a 10*10 two-dimensional array that is being packed, the condition will be tested 121 times and the loop body will be entered 12 times. Only once will it run two times. So, unrolling is definitely not good here.
[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #16 from Thomas Koenig ---
Hi,
I was unable to find a performance problem, so I take back my
presumption of the original problem. I have checked two versions
of the preprocessed source, with
+#pragma GCC unroll 1
while (count[n] == extent[n])
{
as the difference.
What I found was that with the pragma and -O2
- stack size decreased from 752 bytes to 432 bytes, from the stdu 1,-752(1)
instruction
- object code size decreased from 7042 to 1936 bytes, determined by looking
at the addresses of objdump --disassemble
(I also found that #pragma GCC unroll 2 was ignored, but that's for another
PR).
Considering we have this idiom around 400 times in libgfortran, I would
estimate an increase of the size of libgfortan of around two Megabytes.
So, what to do? I don't know if the gcc optimization routines can even
consider this particular loop to be one that is not often used,
although it is an inner loop.
As far as libgfortran is concerned, we could simply use the
pragma on our sources, but maybe other people have the same issue.
[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #21 from Thomas Koenig ---
(In reply to Richard Biener from comment #19)
> Is libgfortran built with -O2 -funroll-loops or with -O3 (IIRC -O3?).
Just plain -O2 (for size reasons), with matmul as an exception
where we add -funroll-loops and other optoins.
> so what's the speciality on POWER? Code growth should trigger with -O3 only.
> Given we have only a guessed profile (and that does not detect the inner
> loop as completely cold) we're allowing growth then. GCC has no idea the
> outer loop iterates more than the inner.
As a test, I changed the condition of the loop in question to
@@ -88,7 +88,7 @@ internal_pack_r4 (gfc_array_r4 * source)
count[0]++;
/* Advance to the next source element. */
index_type n = 0;
- while (count[n] == extent[n])
+ while (unlikely (count[n] == extent[n]))
{
/* When we get to the end of a dimension, reset it and increment
the next dimension. */
which then results in
while (__builtin_expect(!!(count[n] == extent[n]), 0))
and the loop is still completely peeled on POWER at -O2, which
I do not understand.
> Thomas - where did you measure the slowness? For which dimensionality?
Actually, I didn't, I just made an assumption that it would be
bad for speed as well. The tests that I ran then didn't show any
such slowdown, so I guess the POWER9 branch predictor is doing
a good job here.
However, this kind of loop is the standard way of accessing multi-
dimensional arrays of unknown dimension in libgfortran. It occurs
in around 400 files there, sometimes more than once, so the size issue
is significant. I haven't checked if there is an actual degradation
for other use cases.
> I'm quite sure the loop structure will be sub-optimal for certain
> input shapes... (stride0 == 1 could even use memcpy for the inner dimension).
Yes. I plan to revisit this when looking at PR 93114, where I have
to touch that part of the code anyway.
[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018 --- Comment #22 from Thomas Koenig --- Here are the details of how I tested this. I generated the in_pack_r4.i and in_unpack_r4.i by adding -save-temps to the Makefile options in ~/trunk-bin/powerpc64le-unknown-linux-gnu/libgfortran , then removing in_pack_r4.* and in_unpack_r4.* there and running make. In the benchmark directory, I then used bench.f90: program main real, dimension(:,:), allocatable :: a allocate (a(5,4)) call random_number (a) do i=1,500 call foo(a(i::2,:)) call foo(a) end do end program main foo.f90: subroutine foo(a) real, dimension(*) :: a end subroutine foo (constants can be adjusted). The first call to foo needs a repacking, the second one is just to confuse the optimizer not to exit the loop. With the command line gfortran -g -fno-inline-arg-packing -O2 bench.f90 foo.f90 in_pack_r4.i in_unpack_r4.i -static-libgfortran && time ./a.out a test can be run. -fno-inline-arg-repacking is important because otherwise the internal packing routines will not be called, and putting in in_pack_r4.i and in_unpack_r4.i will use those instead of the ones from the (static) library. in_pack_r4.i and in_unpack_r4.i can then be adjusted, for exmaple by adding a #pragma GCC unroll 1.
[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 Thomas Koenig changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #16 from Thomas Koenig --- We really need a test case. SPEC is no different to any other closed-source commercial software in that respect.
[Bug target/95018] [10/11 Regression] Excessive unrolling for Fortran library array handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018
--- Comment #29 from Thomas Koenig ---
It is also interesting that this variant
--- a/libgfortran/generated/in_pack_i4.c
+++ b/libgfortran/generated/in_pack_i4.c
@@ -88,7 +88,7 @@ internal_pack_4 (gfc_array_i4 * source)
count[0]++;
/* Advance to the next source element. */
index_type n = 0;
- while (count[n] == extent[n])
+ while (n < dim && count[n] == extent[n])
{
/* When we get to the end of a dimension, reset it and increment
the next dimension. */
@@ -100,7 +100,6 @@ internal_pack_4 (gfc_array_i4 * source)
if (n == dim)
{
src = NULL;
- break;
}
else
{
does not get peeled.
[Bug libfortran/95101] New: Optimize libgfortran library handling of arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95101 Bug ID: 95101 Summary: Optimize libgfortran library handling of arrays Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Here are some ideas: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95018#c30
[Bug libfortran/95101] Optimize libgfortran library handling of arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95101 Thomas Koenig changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93114 --- Comment #1 from Thomas Koenig --- Also make sure that span is handled directly by the library.
[Bug libfortran/95101] Optimize libgfortran library handling of arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95101 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Severity|normal |enhancement Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-05-13
[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-05-14 CC||tkoenig at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #2 from Thomas Koenig --- Confirmed with current trunk.
[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119 Thomas Koenig changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- I had a hope that https://gcc.gnu.org/pipermail/fortran/2020-January/053926.html would already have fixed it, but that doesn't appear to be the case.
[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119 --- Comment #4 from Thomas Koenig --- So, in order for this to hang, two close statements on the same unit are needed, the first one with an error message. Seems like the unit is not unlocked on the error return.
[Bug fortran/95119] CLOSE hangs when -fopenmp is specified in compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Thomas Koenig ---
This looks simple enough. Regression-testing as I write this.
@@ -31,7 +31,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#endif
typedef enum
-{ CLOSE_DELETE, CLOSE_KEEP, CLOSE_UNSPECIFIED }
+{ CLOSE_INVALID = - 1, CLOSE_DELETE, CLOSE_KEEP, CLOSE_UNSPECIFIED }
close_status;
static const st_option status_opt[] = {
@@ -61,6 +61,12 @@ st_close (st_parameter_close *clp)
find_option (&clp->common, clp->status, clp->status_len,
status_opt, "Bad STATUS parameter in CLOSE statement");
+ if (status == CLOSE_INVALID)
+{
+ library_end ();
+ return;
+}
+
u = find_unit (clp->common.unit);
if (ASYNC_IO && u && u->au)
[Bug fortran/95119] [9/10 Regression] CLOSE hangs when -fopenmp is specified in compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |9.4 Summary|CLOSE hangs when -fopenmp |[9/10 Regression] CLOSE |is specified in compilation |hangs when -fopenmp is ||specified in compilation --- Comment #7 from Thomas Koenig --- Still two revisions to fix.
[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 --- Comment #26 from Thomas Koenig --- (In reply to wschmidt from comment #24) > I'm afraid I disagree. A divide-by-zero that cannot ever be executed is > not an error. Well, there is PR90302. We could insert some piece of code into the IL. A warning or an error could then be issued if the piece of code is still present after the final optimization. It would make a nice project, and remove a few more false positives as well.
[Bug fortran/94925] Undesired runtime warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94925 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Status|UNCONFIRMED |WAITING Last reconfirmed||2020-05-18 Ever confirmed|0 |1 --- Comment #3 from Thomas Koenig --- Please provide a self-contained example and the complete command line that you use.
