[Bug target/97683] [11 Regression] nios2 assembler branch offset errors building glibc

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97683

--- Comment #2 from sandra at gcc dot gnu.org ---
I'm pretty sure this is a gas bug.  I used git bisect to track it down to
binutils commit ae9d2233e61a98ff8dba56be10219aa5306ffc9a which caused gcc to
start passing --gdwarf-5 on the gas command line.  The DWARF-5 support was
present in gas before that and I think it's likely that's disagreeing with
something nios2-specific, perhaps mistakenly adding the size of the dwarf
directive data to the code length or something like that.  The differences in
the .s file generated by GCC for the test case between that binutils revision
with --gdwarf-5 and the one before it without that option don't seem to be
significant.

While working on this, I ran into another issue that is independently
preventing glibc from building:

In function '__rawmemchr',
inlined from '__rawmemchr' at rawmemchr.c:27:1:
rawmemchr.c:40:12: error: 'memchr' specified bound 4294967295 exceeds maximum
object size 2147483647 [-Werror=stringop-overread]
   40 | return memchr (s, c, (size_t)-1);
  |^
cc1: all warnings being treated as errors

I apologize that this is all in such bad shape -- the last time I tried doing
any testing on this target I ran into the glibc breakage Joseph mentioned, and
since then I've been assigned to a different project where my focus has been on
the gfortran front end instead.  :-S  I'll see if I can get some traction on
the gas bug, though.

[Bug fortran/99250] New: [F2018] coshape intrinsic is missing

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99250

Bug ID: 99250
   Summary: [F2018] coshape intrinsic is missing
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

While working on something else, I observed that gfortran doesn't implement the
coshape intrinsic -- it's treated like a regular call to an undeclared
function, and a quick grep of the sources turned up nothing.

[Bug fortran/94331] Bind(C) corrupts array descriptors

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
I think this is probably a duplicate of PR93308, but there are so many things
going on in the test case I can't be sure there aren't other problems lurking
as well.

[Bug fortran/93308] bind(c) subroutine changes lower bound of array argument in caller

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
This bug also affects pointer arrays passed as an argument corresponding to a
non-pointer assumed-shape dummy.  It's also independent of whether the called
bind(c) function is implemented in Fortran or C.

PR94331 is at least a partial duplicate of this bug.

[Bug fortran/94331] Bind(C) corrupts array descriptors

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331

--- Comment #4 from sandra at gcc dot gnu.org ---
OK, there are two flavors of failures being diagnosed by the test case.

The first flavor involves the lower bounds of an array passed into a bind(c)
procedure being set to zero in the callee when the test case thinks they should
be inherited from the array in the caller.  I'm still trying to grok what the
standard actually says about these cases.

The second flavor looks like the same bug as PR93308, involving the lower
bounds of an array passed to a bind(c) procedure appearing to be correct in the
callee, but set to zero in the caller after return.

[Bug fortran/93963] Select rank mishandling allocatable and pointer arguments with bind(c)

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93963

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
Fiddling with the test case a bit, I observe that the RANK() intrinsic returns
the correct result even in the functions where SELECT RANK fails.  Seems odd
that SELECT RANK uses different logic.

[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #4 from sandra at gcc dot gnu.org ---
I'm still seeing failures on mainline head, specifically these 3 groups:

 Testing pointer array
 Using assumed-rank array: 
lbound: expected: [  1  1  1] got: [  3  5  9] FAIL!
ubound: expected: [  2 46  3] got: [  4 50 11] FAIL!

 Testing allocatable array
 Using assumed-rank array: 
lbound: expected: [  1  1  1] got: [  3  5  9] FAIL!
ubound: expected: [  2 46  3] got: [  4 50 11] FAIL!

 Testing explicit array
 Using assumed-rank array: 
lbound: expected: [  1  1  1] got: [  3  5  9] FAIL!
ubound: expected: [  2 46  3] got: [  4 50 11] FAIL!

I'm also confused about the validity of the expectations.  :-S

[Bug fortran/93524] [ISO C Binding][F2018] CFI_allocate – elem_size mishandled + sm wrongly set?

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93524

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
I've checked in a patch that fixes the problem in the description, and I think
that none of the other bugs reported in other comments are still present.

I think this patch ought to be backported to GCC 11 and possibly other branches
as well, since it's a pretty small bug fix.  What branches have similar fixes
for C interoperability features been going on?

[Bug fortran/93524] [ISO C Binding][F2018] CFI_allocate – elem_size mishandled + sm wrongly set?

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93524

--- Comment #7 from sandra at gcc dot gnu.org ---
Now applied to GCC 11 too.  The other two patches referenced in this issue were
put on mainline before GCC 11 branched and not on GCC 10 or any older branch,
so I think I'm done here and the issue can be closed.

[Bug fortran/100917] Bind(c): errors handling long double real

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #4 from sandra at gcc dot gnu.org ---
I've observed this bug in my own testing as well, and traced it to the same
cause:  the GFC descriptor structure doesn't encode the kind, only the
elem_len, so the runtime can't convert it to a valid C descriptor.

IIUC the GFC descriptor needs to encode the kind to support assumed-type
arguments in functions that are not declared bind(c) (for example, a subroutine
with Fortran binding that acts as a wrapper around a C function).  I imagine
any proper fix for this would involve an ABI change affecting programs that
don't even use bind(c).

[Bug fortran/100917] Bind(c): errors handling long double real

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917

--- Comment #5 from sandra at gcc dot gnu.org ---
Here's a related problem:  the GFC descriptor representation can't distinguish
between 

CHARACTER(kind=ucs4, len=1)

and

CHARACTER(kind=c_char, len=4)

because all it has is elem_len == 4.

[Bug c++/108399] New: wrong locations generated for OMP_FOR

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108399

Bug ID: 108399
   Summary: wrong locations generated for OMP_FOR
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54268
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54268&action=edit
WIP patch

While working on some other changes to the "omp for" directive, I noticed that
the locations for errors generated by the C++ front end are inconsistent with
those from the C front end, and not uniform internally within the C++ front end
either.  Specifically, the C front end tags the OMP_FOR with the location of
the directive while the C++ front end tags it with the location of its
outermost nested "for" loop...  but in some cases errors end up being diagnosed
on the line of the directive anyway (see f5 in g++.dg/gomp/loop-8.C, for
instance).

I came up with the attached patch to address this, and fix an obvious think-o
in pt.cc too.  This caused a bunch of regressions in existing test cases:

c-c++-common/gomp/loop-10.c
c-c++-common/gomp/loop-6.c
c-c++-common/gomp/order-4.c
g++.dg/gomp/for-11.C
g++.dg/gomp/for-16.C
g++.dg/gomp/for-1.C
g++.dg/gomp/linear-2.C
g++.dg/gomp/loop-1.C
g++.dg/gomp/loop-2.C
g++.dg/gomp/loop-3.C
g++.dg/gomp/loop-4.C
g++.dg/gomp/loop-5.C
g++.dg/gomp/loop-6.C
g++.dg/gomp/loop-8.C
g++.dg/gomp/pr25996.C
g++.dg/gomp/pr27415.C
g++.dg/gomp/pr35078.C
g++.dg/gomp/pr37533.C
g++.dg/gomp/pr39495-2.C
g++.dg/gomp/pr58567.C
g++.dg/gomp/pr67511.C
g++.dg/gomp/pr67523.C
g++.dg/gomp/pr84448.C
g++.dg/gomp/simd-2.C

The first 3 just need to have the C/C++ conditionalization removed, but in
looking at g++.dg/gomp/for-11.C I realized there is a further bug with invalid
subexpressions of the nested loops not being tagged with correct location
information either by the C++ front end.  It looks like the C parser seems to
be taking more care about this:

default:
  /* Can't be cond = error_mark_node, because we want to preserve   
 the location until c_finish_omp_for.  */
  cond = build1 (NOP_EXPR, boolean_type_node, error_mark_node);

while the C++ front end is just returning bare error_mark_node.

I think it is a reasonable expectation that the C and C++ front ends behave
identically in diagnosing errors for things that have the same semantics in
both languages.  Aside from fixing the bugs, probably most of the C error tests
for "omp for" should be moved to c-c++-common so that we can enforce this.

Anyway, this is looking like a can of worms and lower priority than the thing I
was working on when I ran into this, so I'm dumping state in this issue for
now.  If anybody else wants to pick it up meanwhile, feel free.

[Bug tree-optimization/94920] Failure to optimize abs pattern from arithmetic with selected operands based on comparisons with 0

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94920

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #10 from sandra at gcc dot gnu.org ---
The ABS_EXPR test is also failing on nios2.

[Bug middle-end/106449] New: ICE in #pragma omp parallel for simd

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449

Bug ID: 106449
   Summary: ICE in #pragma omp parallel for simd
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

Test case is derived from c-c++-common/gomp/loop-8.c, with "simd" added:

void
foo (void)
{
  int a[1024];
  int *p, *q;
  #pragma omp parallel for simd collapse(2)
  for (p = &a[0]; p < &a[512]; p++)
for (q = p + 64; q < p + 128; q++)
  ;
}

$ x86_64-none-linux-gnu-gcc -fopenmp loop-8.c
during GIMPLE pass: ompexp
loop-8.c: In function 'foo':
loop-8.c:6:11: internal compiler error: in build2, at tree.cc:5023
6 |   #pragma omp parallel for simd collapse(2)
  |   ^~~
0x19e4116 build2(tree_code, tree_node*, tree_node*, tree_node*)
/path/to/gcc/tree.cc:5022
0xf81b3f build2_loc
/path/to/gcc/tree.h:4577
0xfc0d03 fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/path/to/gcc/fold-const.cc:13860
0xfb26f3 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/path/to/gcc/fold-const.cc:10894
0xfc0cdc fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/path/to/gcc/fold-const.cc:13858
0x380f1ca expand_omp_simd
/path/to/gcc/omp-expand.cc:6882
0x3815c41 expand_omp_for
/path/to/gcc/omp-expand.cc:8090
0x381e79d expand_omp
/path/to/gcc/omp-expand.cc:10357
0x381e717 expand_omp
/path/to/gcc/omp-expand.cc:10343
0x381e717 expand_omp
/path/to/gcc/omp-expand.cc:10343
0x381edbb execute_expand_omp
/path/to/gcc/omp-expand.cc:10592
0x381ee95 execute
/path/to/gcc/omp-expand.cc:10639

[Bug middle-end/106492] New: ICE in #pragma omp for simd

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106492

Bug ID: 106492
   Summary: ICE in #pragma omp for simd
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

This is similar to PR106449; adding the simd keyword to an existing omp for
test case causes an ICE related to incompatible types.

Test case is derived from g++.dg/gomp/pr95063.C:

// PR c++/95063

template 
struct S {
  T a : 12;
  S () : a(0)
  {
#pragma omp for simd linear(a)
for (int k = 0; k < 64; ++k)
  a++;
  }
};
struct U {
  int a : 12;
  U () : a(0)
  {
#pragma omp for simd linear(a)
for (int k = 0; k < 64; ++k)
  a++;
  }
};

S s;
U u;

$ x86_64-none-linux-gnu-g++ -fopenmp pr95063.C -S
pr95063.C: In constructor 'U::U()':
pr95063.C:19:8: error: type mismatch in binary expression
   19 |   a++;
  |   ~^~




int

a = a + D.2648;
during GIMPLE pass: omplower
pr95063.C:19:8: internal compiler error: 'verify_gimple' failed
0x1295c9d verify_gimple_in_seq(gimple*)
/path/to/gcc/tree-cfg.cc:5220
0x1167b60 execute_function_todo
/path/to/gcc/passes.cc:2093
0x1167fdb execute_todo
/path/to/gcc/passes.cc:2145
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/106548] New: ICE in #pragma openmp parallel for simd linear with long long variables

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106548

Bug ID: 106548
   Summary: ICE in #pragma openmp parallel for simd linear with
long long variables
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

Test case is reduced from libgomp.c/linear-1.c, with "simd" added to the loop:

int a[256];

__attribute__((noinline, noclone)) long long int
f3 (long long int i, long long int k)
{
  #pragma omp parallel for simd linear (i: k)
  for (short j = 16; j < 64; j++)
{
  a[i] = j;
  i += 4;
}
  return i;
}

$ x86_64-linux-gnu-gcc -S -fopenmp linear-1.c
during RTL pass: expand
linear-1.c: In function 'f3._omp_fn.0':
linear-1.c:6:11: internal compiler error: in expand_expr_real_1, at
expr.cc:10721
6 |   #pragma omp parallel for simd linear (i: k)
  |   ^~~
0x748517 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/path/to/gcc/expr.cc:10721
0xba694c expand_expr
/path/to/gcc/expr.h:310
0xba694c expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**,
rtx_def**, expand_modifier)
/path/to/gcc/expr.cc:8403
0xb9eedb expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/path/to/gcc/expr.cc:9631
0xa7a3c8 expand_gimple_stmt_1
/path/to/gcc/cfgexpand.cc:3983
0xa7a3c8 expand_gimple_stmt
/path/to/gcc/cfgexpand.cc:4044
0xa8013e expand_gimple_basic_block
/path/to/gcc/cfgexpand.cc:6096
0xa81c66 execute
/path/to/cfgexpand.cc:6822
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Declaring either i or k as plain "int" instead of "long long int" makes the
crash go away.

[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390

--- Comment #4 from sandra at gcc dot gnu.org ---
I thought I had a fix for this that involved making gfc_is_simply_contiguous
smarter about intrinsics and other function calls, but after writing more test
cases I found that this one still ICEs.

program p
   integer, pointer :: z(:)
   integer :: a(3) = [1, 2, 3];
   integer :: b(3) = [4, 5, 6];
   call s(a + b);
contains
   subroutine s(x) bind(c)
  integer, contiguous :: x(:)
   end
end

Tobias's other suggestion to me was gating the copy-out code with
gfc_expr_is_variable() so I'll try that next.

[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390

--- Comment #5 from sandra at gcc dot gnu.org ---
Created attachment 52107
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52107&action=edit
-fdump-tree-original output from second test case

Well, this is nuts.  Unmodified code is generating 3 copies of the loop to
compute "a + b" in the previous example, as well as the invalid copy-out code.

I've got a patch to fix this now, just doing a few more experiments with it.

[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390

--- Comment #6 from sandra at gcc dot gnu.org ---
Patch posted:

https://gcc.gnu.org/pipermail/fortran/2022-January/057249.html

[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390

--- Comment #9 from sandra at gcc dot gnu.org ---
Without a test case, I can't tell if the error in comment 7 was due to this bug
or a different one.  It doesn't really look the same as the other failures I
looked at in this issue, as the source code it's pointing at does not involve a
call to a BIND(C) procedure.  I've pushed the patch now; Antony, can you retry
your build, and work up a test case for a new issue if it still fails in the
same way?

[Bug fortran/103898] [12 Regression] ICE: gimplification failed

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898

--- Comment #4 from sandra at gcc dot gnu.org ---
This is probably related to my rewrite of the size/shape/ubound/lbound
intrinsics back in mid-November.  I can add this one to my queue, but I've
already got 3 or 4 other issues already waiting for me to do something, so if
anybody else wants to take this one meanwhile go ahead.

[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258

--- Comment #5 from sandra at gcc dot gnu.org ---
The previous hacky patch had some testsuite regressions.  I've posted a less
hacky one that doesn't trigger new failures here:

https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587632.html

[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #11 from sandra at gcc dot gnu.org ---
Marking this as fixed since we have a new issue for the other bug.

[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from sandra at gcc dot gnu.org ---
Should be fixed now.

[Bug fortran/95879] [10/11/12 Regression] ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:313

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95879

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
The ICE from the z1.90 example is gone on mainline now.  I don't know if the
error on y1.f90 is correct or not without further research.

[Bug fortran/103366] [9/10/11/12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:5647

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103366

--- Comment #7 from sandra at gcc dot gnu.org ---
The proposed patch looks reasonable to me.

[Bug fortran/102708] Improve ''array temporary was created for argument" diagnostic

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102708

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
I fixed a lot of bugs with creating excessive temporaries for calls to bind(c)
functions in my fix for PR 103390 (commit
6447f6f983ffeaecb8753ef685d702bf2594968b).  I'm not sure if there is more to do
there or not, but it seems unrelated to the original problem.  If there's a
bug, it ought to be in its own issue.

IIUC what needs to be done for the original problem is fixing (all?) the calls
to gfc_conv_subref_array_arg to pass the fsym and proc_name arguments.

[Bug fortran/103898] [12 Regression] ICE: gimplification failed

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898

sandra at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |sandra at gcc dot 
gnu.org

--- Comment #7 from sandra at gcc dot gnu.org ---
Yeah, the implementation of the SIZE intrinsic is pretty borked.  I'm working
on it.

[Bug fortran/103898] [12 Regression] ICE: gimplification failed

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898

--- Comment #8 from sandra at gcc dot gnu.org ---
Patch posted:

https://gcc.gnu.org/pipermail/fortran/2022-January/057293.html

[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from sandra at gcc dot gnu.org ---
Should be fixed now.

[Bug fortran/103898] [12 Regression] ICE: gimplification failed

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from sandra at gcc dot gnu.org ---
Fixed.

[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
I'm not at all familiar with any of this code (yet), but...

Note that it is complaining about variable i declared in the outer procedure p,
not about something in the nested function s that contains the OMP directives.

Looking at the .original dump, I see that the declaration for the iterator
variable j is appearing in the outer procedure p, not the inner function s
where it is used in the OMP task directive.  The .gimple dump shows both i
*and* j declared in both procedures, and the .nested dump shows that a bunch of
static chain stuff has been added for j.  So my guess is that these variables
being inserted into wrong scopes is confusing the ssa passes.

[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695

--- Comment #3 from sandra at gcc dot gnu.org ---
It appears that the wrong-scope problem is introduced in gfc_finish_var_decl,
in this block of code:

  /* Chain this decl to the pending declarations.  Don't do pushdecl()
 because this would add them to the current scope rather than the
 function scope.  */
  if (current_function_decl != NULL_TREE)
{
  if (sym->ns->proc_name
  && (sym->ns->proc_name->backend_decl == current_function_decl
  || sym->result == sym))
gfc_add_decl_to_function (decl);
  else if (sym->ns->proc_name
   && sym->ns->proc_name->attr.flavor == FL_LABEL)
/* This is a BLOCK construct.  */
add_decl_as_local (decl);
  else
gfc_add_decl_to_parent_function (decl);
}

ns->proc_name contains something completely unexpected here so it's falling
through to gfc_add_decl_to_parent_function.  I think it's an accident that it
works at all when it's not inside a nested function.  Do we really want these
iterator variables to have local scope instead?

gfortran.h documents the proc_name field as

  /* If this is a namespace of a procedure, this points to the procedure.  */
  struct gfc_symbol *proc_name;

but the ASSOCIATED clause seems to be using it for an entirely different
purpose, to chain the list of iterator variables (see handle_iterator in
trans-openmp.c).  I think that's the real bug, rather than the code snippet
quoted above.  It ought to be adding a new field to struct gfc_namespace if
there isn't a better place to store this information, instead of overloading
one that means something else.

I'm still trying to find my way around the code that manipulates these
namespaces and iterator variables.  There's an annoying lack of comments here
to explain the data structures it is using or what parts are handled during
gimplification.  :-(

[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695

--- Comment #4 from sandra at gcc dot gnu.org ---
Ooops, I meant AFFINITY clause in the message above, not ASSOCIATED.

[Bug middle-end/103163] [12 Regression] stack_limit_rtx is created too early causing nregs field on REG to be zero (gcc.target/nios2/nios2-stack-check-1.c and gcc.target/powerpc/stack-limit.c)

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103163

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from sandra at gcc dot gnu.org ---
Should be fixed now.

[Bug fortran/104100] Passing an allocated array to a C bind function alters the bounds

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104100

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
Most of the patches are on the devel/omp/gcc-11 development branch that also
includes a bunch of other experimental features and preliminary patches that
haven't made it to mainline yet, but I don't think either Tobias or I have a
todo item to backport the bind(c) patches to the stable gcc 11 branch.  There
were a lot of patches and some of them were quite extensive rewrites, so my
sense is that it's probably not appropriate for a stable branch.

[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695

sandra at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |sandra at gcc dot 
gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
Patch posted here:
https://gcc.gnu.org/pipermail/fortran/2022-January/057425.html

[Bug fortran/102621] ICE in convert_nonlocal_reference_op, at tree-nested.c:1166 since r12-1108-g9a5de4d5af1c10a8

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102621

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED
 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
This is the same problem as PR103695, or at least it's fixed by the same patch.

*** This bug has been marked as a duplicate of bug 103695 ***

[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695

--- Comment #6 from sandra at gcc dot gnu.org ---
*** Bug 102621 has been marked as a duplicate of this bug. ***

[Bug fortran/103695] [12 Regression][OpenMP] affinity clause - ICE: verify_ssa failed since r12-1108-g9a5de4d5af1c10a8

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103695

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from sandra at gcc dot gnu.org ---
Should be fixed now.

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from sandra at gcc dot gnu.org ---
Marking this as fixed.

[Bug fortran/35276] Doc should described how to compile mixed-language programs

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276

sandra at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |sandra at gcc dot 
gnu.org

--- Comment #9 from sandra at gcc dot gnu.org ---
Well, it looks to me like we currently do not document exactly how to link
mixed-language programs, although chapter 7 does cover related concepts like
what you have to do to initialize libgfortran if you are linking e.g. a fortran
library with a main in some other language.  I think this topic does belong in
chapter 7 and not any other part of the manual, and that we should not close
it.  I'll add it to my queue.

[Bug fortran/101337] gfortran doesn't diagnose all operands with constraint violations

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337

sandra at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |sandra at gcc dot 
gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
Patch posted:

https://gcc.gnu.org/pipermail/fortran/2021-November/056906.html

[Bug fortran/35276] Doc should described how to compile mixed-language programs

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from sandra at gcc dot gnu.org ---
Should be fixed now.  I added paragraphs about both C++ compatibility and how
to link.

[Bug fortran/89078] [meta-bug] Improve the gfortran manual

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078
Bug 89078 depends on bug 35276, which changed state.

Bug 35276 Summary: Doc should described how to compile mixed-language programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/35930] -pedantic: Check for -std=f95/f2003/f2008

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35930

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
The manual now documents -pedantic without tying it to Fortran 95, and it
includes a disclaimer 

  Some users try to use @option{-pedantic} to check programs for conformance.
  They soon find that it does not do quite what they want---it finds some
  nonstandard practices, but not all.
  However, improvements to GNU Fortran in this area are welcome.

I think the docs are OK, but is there more to do for this issue in terms of
fixing what -pedantic does?

[Bug fortran/89078] [meta-bug] Improve the gfortran manual

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078

--- Comment #2 from sandra at gcc dot gnu.org ---
I did look over the entire list of still-open issues and did not see any
further low-hanging fruit.  It also seemed to me that some of the issues on the
list are cases where it appears the implementation is broken or not useful, not
just the documentation.

[Bug fortran/101337] gfortran doesn't diagnose all operands with constraint violations

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from sandra at gcc dot gnu.org ---
Fixed, at least the cases I wrote testcases for relating to TS29113 constraint
violations.

[Bug other/103163] New: stack_limit_rtx is created too early

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103163

Bug ID: 103163
   Summary: stack_limit_rtx is created too early
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

stack_limit_rtx is initialized in init_emit_once() before
init_reg_modes_target() is called to fill in the table for hard_regno_nregs. 
For -fstack-limit-register, this means the REG is created with a zero nregs
field, and this ends up tripping over the assertion in df_ref_record while
processing prologue instructions using stack_limit_rtx.

I observed this in a nios2-elf build, where the testcase 
gcc.target/nios2/nios2-stack-check-1.c is ICE'ing:

$ nios2-elf-gcc
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.target/nios2/nios2-stack-check-1.c
-fdiagnostics-plain-output -fstack-limit-register=et -ffat-lto-objects
-fno-ident -S -o nios2-stack-check-1.s
during RTL pass: pro_and_epilogue
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.target/nios2/nios2-stack-check-1.c:
In function 'test':
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.target/nios2/nios2-stack-check-1.c:10:1:
internal compiler error: in df_ref_record, at df-scan.c:2610
0xecb4e2 df_ref_record
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:2610
0xecbd10 df_uses_record
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:2869
0xecc1af df_uses_record
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:3045
0xecca08 df_insn_refs_collect
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:3224
0xec774a df_insn_rescan(rtx_insn*)
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:1087
0xf69280 emit_insn_after_1
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/emit-rtl.c:4598
0xf69439 emit_pattern_after_noloc
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/emit-rtl.c:4646
0xf694a0 emit_insn_after_noloc(rtx_def*, rtx_insn*, basic_block_def*)
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/emit-rtl.c:4670
0xe59262 commit_one_edge_insertion(edge_def*)
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/cfgrtl.c:2051
0xe593ea commit_edge_insertions()
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/cfgrtl.c:2103
0x105b646 thread_prologue_and_epilogue_insns()
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/function.c:6160
0x105c1cc rest_of_handle_thread_prologue_and_epilogue
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/function.c:6534
0x105c3ac execute
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/function.c:6610
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I think I could hack around this by having the nios2 backend create a fresh REG
instead of using stack_limit_rtx directly in the prologue, but that does seem
like a hack instead of a proper fix  Also, it looks like the bfin, m68k,
and rs6000 backends use stack_pointer_rtx too and probably have similar issues.

Looks like the assert was introduced in commit
7232f7c4c2d727431096a7ecfcf4ad4db71dcf2a but the underlying problem probably
long predates that (it's just that nothing was tripping over it in such an
obvious way).

[Bug middle-end/101674] gcc.dg/uninit-pred-9_b.c fails after jump threading rewrite

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #6 from sandra at gcc dot gnu.org ---
Also fails for nios2 (line 20, same as powerpc64).  Are we really just xfailing
this everywhere instead of fixing the bug and/or testcase?  That kind of seems
like sweeping the whole mess under the rug, to me.  :-S

[Bug tree-optimization/92879] [10/11 Regression] incorrect warning of __builtin_memset offset is out of the bounds on zero-size allocation and initialization

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #11 from sandra at gcc dot gnu.org ---
The new testcase is failing on nios2-elf.

$ nios2-elf-g++  src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C
-O2 -fdump-tree-optimized -S -Wall
In constructor 'S::S(int)',
inlined from 'void __static_initialization_and_destruction_0(int, int)' at
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:26:7,
inlined from '(static initializers for
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C)' at
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:26:8:
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:22:7: warning:
array subscript [0, 536870911] is outside array bounds of 'void [0]'
[-Warray-bounds]
   22 |   new (p + i) int ();
  |   ^~
src/gcc-mainline/gcc/testsuite/g++.dg/warn/Warray-bounds-16.C:19:51: note:
object of size 0 allocated by 'operator new []'
   19 | p = (int*) new unsigned char [sizeof (int) * m];
  |   ^


This is what I see in the .optimized dump file:

;; Function _GLOBAL__sub_I_a (_GLOBAL__sub_I_a, funcdef_no=5, decl_uid=1975,
cgraph_uid=6, symbol_order=6) (executed once)

Removing basic block 5
void _GLOBAL__sub_I_a ()
{
  int _2;
  void * _5;
  sizetype _12;
  sizetype _20;

   [local count: 1073741824]:
  a ={v} {CLOBBER};
  a.m = 0;
  _5 = operator new [] (0);
  a.p = _5;
  _2 = a.m;
  if (_2 > 0)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 955630224]:
  _20 = (sizetype) _2;
  _12 = _20 * 4;
  __builtin_memset (_5, 0, _12); [tail call]

   [local count: 1073741825]:
  return;

}

[Bug libstdc++/103166] [12 regression] wrong dependency on getentropy on newlib-based targets

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
I'm seeing these failures in my nios2-elf test results today too.  :-(

[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
I'll take a look when I have time, but I'm deep in another bug right now so it
may be a few days.  Anybody else feel free to grab it meanwhile...

[Bug lto/91288] [9/10/11/12 Regression] ICE in add_symbol_to_partition_1, at lto/lto-partition.c:153 since r249224

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91288

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #7 from sandra at gcc dot gnu.org ---
This ICE doesn't reproduce on mainline (GCC 12) x86_64-linux-gnu for me.

[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258

--- Comment #3 from sandra at gcc dot gnu.org ---
This looks like an existing bug in error checking that was exposed by my patch
to do...  more error checking.  :-S

The problem is that gfc_set_default_type in symbol.c is setting
sym->attr.untyped even when errors are suppressed or buffered and discarded
during parsing.  Since it's marked as having already been diagnosed, we aren't
giving an error in subsequent calls where errors are *not* being suppressed or
discarded, and thus compilation continues as if nothing were wrong, until it
falls over.

Previously we were resolving only the second operand "m" in the "(n+m)"
expression in a situation where errors are buffered in the parsing stage,
leaving "n" without the attr.untyped flag set so that it was being diagnosed
later during the actual resolve phase of processing.  Now it is setting that
flag on both "n" and "m" so neither ever gives a real error.

I've got a hacky patch to avoid setting sym->attr.untyped when a real error
might not be given, but I'm not sure if it's the right solution.  Maybe a
better solution would be to emit the diagnostic somewhere other than
gfc_set_default_type, at a known point in the processing where it'll only
happen once?

[Bug fortran/103258] [12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114 since r12-4979-gee11be7f2d788e60

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258

--- Comment #4 from sandra at gcc dot gnu.org ---
Created attachment 51980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51980&action=edit
hacky patch

Attached patch has not been regression tested, but it does seem to fix the
original testcase, which now produces:

$ gfortran -c pr103258.f90
pr103258.f90:3:13:

3 | character(n+m) :: c
  | 1
Error: Symbol 'm' at (1) has no IMPLICIT type
pr103258.f90:1:14:

1 | subroutine s(n)
  |  1
Error: Symbol 'n' at (1) has no IMPLICIT type

[Bug fortran/103287] [12 Regression] ICE in argument_rank_mismatch, at fortran/interface.c:2240

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103287

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #4 from sandra at gcc dot gnu.org ---
The proposed fix in comment 2 looks OK to me, although I'd like to see a
comment here like

"This case corresponds to an assumed-rank actual passed to a function without
an explicit interface, which is diagnosed in gfc_procedure_use."

to explain what is going on.

[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org,
   ||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
It looks to me like this is due to a collision between my patch to re-do the
SHAPE intrinsic (commit 1af78e731feb9327a17c99ebaa19a4cca1125caf) and Tobias's
big patch to completely reimplement CFI descriptor conversion (commit
64f9623765da3306b0ab6a47997dc5d62c2ea261) and the copy-in/copy-out for array
parameters with the CONTIGUOUS attribute.  

I think the thing the gimplifier is crashing on is this assignment that appears
in the copy-out loop after the call to s:

  (integer(kind=4)) (((unsigned int) z.dim[S.3].ubound - (unsigned
int) z.dim[S.3].lbound) + 1) = (*(integer(kind=4)[1] * restrict)
atmp.0.data)[S.3 + D.4263];

The left-hand side of the assignment is not an lvalue because of the nop_expr.

Besides fixing the bug, it would be good if we could make it smart enough not
to generate the copy-in/copy-out loops at all because it knows perfectly well
that the temporary holding the result of the SHAPE intrinsic is already
contiguous!

[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390

--- Comment #3 from sandra at gcc dot gnu.org ---
Created attachment 51994
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51994&action=edit
-fdump-tree-original output from test case

Here's the full output from -fdump-tree-original for the test case.

[Bug fortran/100914] Bind(c): errors handling complex

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100914

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #8 from sandra at gcc dot gnu.org ---
I think this bug has been fixed by commit 

93b6b2f614eb692d1d8126ec6cb946984a9d01d7

but as Tobias is presently rewriting the front-end code to build CFI
descriptors directly instead of calling a library function, we should be
careful that this bug doesn't creep back in.

[Bug fortran/100917] Bind(c): errors handling long double real

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917

--- Comment #8 from sandra at gcc dot gnu.org ---
There is a workaround for this included in commit

93b6b2f614eb692d1d8126ec6cb946984a9d01d7

that doesn't fully solve the problem:  when "long double" and "float128" are
different types with the same storage size (as on x86_64), it assumes that size
maps onto the standard type "long double" instead of the GNU extension type.

Tobias is presently rewriting the front-end code to build CFI descriptors
directly instead of calling a library function, so as part of that change it
should be possible to properly capture the kind of the type as well as its
size.

[Bug testsuite/102282] New test cases in r12-3320 fail

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102282

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
The UNRESOLVEDs are showing up because these execution tests are currently
throwing out bogus compile-time errors (which are properly xfailed with
reference to PR92482).  Tobias has a patch that has not yet been reviewed or
committed that I think addresses the underlying bug.

The other FAILs you report should have been fixed by commit 
93b6b2f614eb692d1d8126ec6cb946984a9d01d7.  That's PR100917.

[Bug target/102353] New: powerpc64le-linux-gnu build failure when build != host

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353

Bug ID: 102353
   Summary: powerpc64le-linux-gnu build failure when build != host
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
CC: wschmidt at linux dot ibm.com
  Target Milestone: ---
  Host: powerpc64le-linux-gnu
Target: powerpc64le-linux-gnu
 Build: x86_64-linux-gnu

I'm trying to build gcc for powerpc64le-linux-gnu host and target from
x86_64-linux-gnu host using scripts that have been known to work within the
last month or so.  I'm seeing multiple linker errors like 

ld: rs6000-gen-builtins.o: Relocations in generic ELF (EM: 21)

followed by

ld: rs6000-gen-builtins.o: error adding symbols: file in wrong format

And indeed, looking at config/rs6000/t-rs6000, this seems to be broken:

rs6000-gen-builtins.o: $(srcdir)/config/rs6000/rs6000-gen-builtins.c
$(COMPILE) $<
$(POSTCOMPILE)

rbtree.o: $(srcdir)/config/rs6000/rbtree.c
$(COMPILE) $<
$(POSTCOMPILE)

rs6000-gen-builtins: rs6000-gen-builtins.o rbtree.o
$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) -o $@ \
$(filter-out $(BUILD_LIBDEPS), $^) $(BUILD_LIBS)

The two .o files are being built with the *host* compiler, and we're trying to
link them with the *build* linker.  ???

[Bug target/102353] powerpc64le-linux-gnu build failure when build != host

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353

--- Comment #1 from sandra at gcc dot gnu.org ---
Ooops, I meant x86_64-linux-gnu build, not host.  :-(

[Bug target/102353] powerpc64le-linux-gnu build failure when build != host

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353

--- Comment #4 from sandra at gcc dot gnu.org ---
I think rs6000-gen-builtins is supposed to be a build binary, not a host
binary?  I'm seeing this at the end of my build log with that patch.

./rs6000-gen-builtins /path/to/gcc/config/rs6000/rs6000-builtin-new.def \
/path/to/gcc/config/rs6000/rs6000-overload.def rs6000-builtins.h \
rs6000-builtins.c rs6000-vecdefines.h
/path/to/bin/bash: ./rs6000-gen-builtins: cannot execute binary file: Exec
format error
/path/to/gcc/config/rs6000/t-rs6000:67: recipe for target 'rs6000-builtins.c'
failed

[Bug fortran/77652] Invalid rank error in ASSOCIATED when rank is remapped

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77652

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
Still present on trunk.

[Bug fortran/102641] New: Bogus error for intent(out) dummy that is a polymorphic assumed-rank array

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102641

Bug ID: 102641
   Summary: Bogus error for intent(out) dummy that is a
polymorphic assumed-rank array
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

A trivial subroutine with a intent(out) dummy that is a polymorphic
assumed-rank array...

module m

contains
subroutine s1 (x, y)
  class(*) :: x(..)
  class(*), intent (out) :: y(..)
end subroutine

end module

...incorrectly produces a compilation error:

unlimited1.f90:4:23:

4 | subroutine s1 (x, y)
  |   1
Error: Assumed-rank variable y at (1) may only be used as actual argument

This error is arising from references to the intent(out) argument in the
automatically-generated deallocation and initialization code.  Probably some
flag needs to be added to the references in that code to suppress the warning,
which is coming from resolve_variable in resolve.c.

Of course runtime testing is needed as well to ensure that the generated
initialization code DTRT with assumed-rank arrays -- it's obviously never been
tested.  In fact, I wonder if the initialization code generator is even
equipped to handle arrays whose rank is unknown at compile time.  (I'm not
familiar with the code to implement it, but I see a loop nest coming out of the
front end for fixed-rank arrays.)

I ran into this error while working on PR 54753 (diagnostic for C839 involving
assumed-size actual arguments passed to assumed-rank dummies), but it's a
different issue unrelated to invalid calls, so I'm giving it its own issue. 
The patch Tobias already committed that was tagged PR 54753 only fixed
interface declarations by suppressing the unused initialization code entirely,
as a workaround to unblock testing of the actual fix for PR 54753.

[Bug fortran/54753] assumed-rank dummies: Reject assumed-size actuals in in some cases (C535c; in F2018: C839)

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753

--- Comment #5 from sandra at gcc dot gnu.org ---
Patch to add the diagnostic posted here:

https://gcc.gnu.org/pipermail/fortran/2021-October/056656.html

There's still a problem with the bogus diagnostic arising from
deallocation/initialization when you have just a subroutine definition instead
of an interface.  That has nothing to do with this diagnostic or other
caller/callee argument mismatch so I opened a new issue (PR102641) for that.

[Bug fortran/102641] Bogus error for intent(out) dummy that is a polymorphic assumed-rank array

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102641

--- Comment #2 from sandra at gcc dot gnu.org ---
I was thinking that for assumed-rank the front end should probably just emit a
call to a library support function in the callee, instead of whatever it is
doing now to try to deallocate/initialize the array.  That would also fix the
bogus warning, since passing an assumed-rank argument to another function that
expects one is permitted.

[Bug fortran/94070] Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070

--- Comment #11 from sandra at gcc dot gnu.org ---
There are still some bugs present with class arrays.  E.g., this test case
ICEs:

module m
  type :: t
integer :: id
real :: xyz(3)
  end type

contains

  subroutine testit2p(a)
class(t), pointer :: a(..)
print *, shape(a)
  end subroutine 

end module

SHAPE is implemented as a library call and it's trying to copy the pointer
array to a temporary instead of just dereferencing it.  I'm looking at
replacing that logic to handle it inline same as LBOUND/UBOUND.

[Bug fortran/94070] Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from sandra at gcc dot gnu.org ---
I believe this issue is fixed now.  The original test case at the top of the
issue has been committed (now named assumed_rank_22), and my last commit added
a set of tests for the thing that was still triggering the ICE plus some more
for bind(c).

[Bug fortran/94022] Array slices of assumed-size arrays

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022
Bug 94022 depends on bug 94070, which changed state.

Bug 94070 Summary: Assumed-rank arrays – bounds mishandled, 
SIZE/SHAPE/UBOUND/LBOUND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621

--- Comment #21 from sandra at gcc dot gnu.org ---
Tobias, did your big patch fully fix this issue so that we can close it?

[Bug fortran/101304] Bind(C): CONTIGUOUS attribute not handled correctly in Fortran routines called from C with discontiguous argument

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101304

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from sandra at gcc dot gnu.org ---
Although it wasn't explicitly tagged with this issue, Tobias's recent big patch
to re-implement CFI <-> C descriptor conversions (commit
64f9623765da3306b0ab6a47997dc5d62c2ea261) fixed the testcases mentioned here
and removed the XFAILs on them, so I am marking this fixed.

[Bug fortran/101319] Missing diagnostic for argument with type parameters for assumed-type dummy

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101319

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from sandra at gcc dot gnu.org ---
This has been fixed.

[Bug fortran/101320] Bind(C): Missing diagnostic for constraint C1557 on allocatable/pointer arguments

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101320

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from sandra at gcc dot gnu.org ---
This has been fixed.

[Bug fortran/101333] gfortran fails to enforce C711 on assumed-type actual arguments

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101333

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from sandra at gcc dot gnu.org ---
This has been fixed.

[Bug fortran/54753] assumed-rank dummies: Reject assumed-size actuals in in some cases (C535c; in F2018: C839)

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from sandra at gcc dot gnu.org ---
This has been fixed except for the problem with deallocation/initialization of
assumed-rank arrays now being tracked separately in PR102641.

[Bug fortran/101334] gfortran fails to enforce C838 on disallowed uses of assumed-rank variable names + bogus errors

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101334

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from sandra at gcc dot gnu.org ---
This has been fixed.

[Bug fortran/101337] gfortran doesn't diagnose all operands with constraint violations

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337

--- Comment #1 from sandra at gcc dot gnu.org ---
This is likely a "won't fix" bug, but I'll leave it open for now.  The test
cases (now committed) are still XFAILed.

[Bug fortran/100907] Bind(c): failure handling wide character

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #9 from sandra at gcc dot gnu.org ---
Jose's test case for this issue is still failing.

[Bug fortran/100916] Bind(c): CFI_type_other unimplemented.

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100916

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
Jose's test case for this issue is still failing.

[Bug fortran/100914] Bind(c): errors handling complex

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100914

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #9 from sandra at gcc dot gnu.org ---
I think it's safe to close this issue now.  The testcase is in and still passes
after Tobias's changes.

[Bug fortran/100911] Bind(c): failure handling C_PTR

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100911

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
 CC||sandra at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
Fixed now, closing.

[Bug fortran/100915] Bind(c): failure handling C_FUNPTR

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100915

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
 CC||sandra at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
Marking this as fixed now.

[Bug fortran/100910] Bind(c): errors handling long double complex

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100910

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from sandra at gcc dot gnu.org ---
This is fixed now.  There is adequate test coverage in the c-interop testsuite;
typecodes-array-longdouble.f90 and typecodes-scalar-longdouble.f90.

[Bug fortran/100906] Bind(c): failure handling character with len/=1

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100906

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||sandra at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from sandra at gcc dot gnu.org ---
This was fixed as part of Tobias's big GFC <-> CFI descriptor re-work, and I've
separately committed the testcase for this issue.  I think we can close this
issue now.

[Bug fortran/100917] Bind(c): errors handling long double real

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #9 from sandra at gcc dot gnu.org ---
This is fully fixed now.  I think the testcases in the c-interop testsuite are
adequate, so nothing more to do here.

[Bug fortran/94289] Assumed-rank array bounds resuscitate on the second call

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #6 from sandra at gcc dot gnu.org ---
This is working now.  I've committed a slightly cleaned-up version of the
testcase (basically just exchanging the print "FAIL!"s with STOPs).  I also
convinced myself that the testcase is correct.  ;-)

[Bug fortran/99922] Bind(C) with assumed length character should work

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99922

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from sandra at gcc dot gnu.org ---
This is a duplicate of now-fixed PR 92482.

*** This bug has been marked as a duplicate of bug 92482 ***

[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||everythingfunctional@proton
   ||mail.com

--- Comment #11 from sandra at gcc dot gnu.org ---
*** Bug 99922 has been marked as a duplicate of this bug. ***

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #6 from sandra at gcc dot gnu.org ---
Has this bug been fully fixed now, so that we can close it?

[Bug fortran/95196] Assumed-rank incorrect array bounds inside select rank

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95196

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED
 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
I confirmed that the testcase now works, and added it to the testsuite. 
Closing this issue now.

[Bug fortran/84007] [OOP] ICE with SAME_TYPE_AS and CLASS(*) entity

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84007

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #6 from sandra at gcc dot gnu.org ---
I think this issue is fixed now?

[Bug fortran/71703] [9/10/11/12 Regression] [OOP] ICE in wide_int_to_tree, at tree.c:1488

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71703

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #17 from sandra at gcc dot gnu.org ---
I think this issue is fixed now?

[Bug fortran/65819] overzealous checking in gfc_check_dependency for identical=true

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||sandra at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #8 from sandra at gcc dot gnu.org ---
This issue seems to have been fixed by the above patch.

[Bug fortran/36854] [meta-bug] fortran front-end optimization

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
Bug 36854 depends on bug 65819, which changed state.

Bug 65819 Summary: overzealous checking in gfc_check_dependency for 
identical=true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/37131] inline matmul for small matrix sizes

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
Bug 37131 depends on bug 65819, which changed state.

Bug 65819 Summary: overzealous checking in gfc_check_dependency for 
identical=true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65819

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/102729] Assumed rank: ICE when passing noncontiguous to CONTIGUOUS assume rank (assumed-rank loop handling)

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102729

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from sandra at gcc dot gnu.org ---
This is the same ICE previously reported as PR100194.

*** This bug has been marked as a duplicate of bug 100194 ***

[Bug fortran/100194] [9/10/11/12 Regression] ICE in gfc_trans_create_temp_array, at fortran/trans-array.c:1351

[sandra at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100194

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #5 from sandra at gcc dot gnu.org ---
*** Bug 102729 has been marked as a duplicate of this bug. ***