[Bug libstdc++/95983] `std::counted_iterator>>` fails to satisfy `std::input_or_output_iterator`

2020-07-26 Thread ensadc at mailnesia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95983

--- Comment #2 from ensadc at mailnesia dot com ---
See also LWG 3408 (https://wg21.link/lwg3408), which also suggests that the
`iterator_traits>` specialization is problematic.

I think the standard could remove this specialization (and define
`iterator_concept` in `counted_iterator`), since this specialization seems to
have only negative effect.

[Bug c++/96328] New: Singe keyword "friend" makes GCC ICE in cp_lexer_previous_token, at cp/parser.c:769

2020-07-26 Thread haoxintu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96328

Bug ID: 96328
   Summary: Singe keyword "friend" makes GCC ICE in
cp_lexer_previous_token, at cp/parser.c:769
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, all.

Weirdly, a single "friend" makes GCC crashed in the current trunk.

Input: 
//small.cc
friend

Command:
g++ small.cc

Output:
small.cc:1:1: error: ‘friend’ used outside of class
1 | friend
  | ^~
  | --
small.cc:2: internal compiler error: in cp_lexer_previous_token, at
cp/parser.c:769
0x66759d cp_lexer_previous_token
../../gcc/cp/parser.c:769
0x667c28 cp_lexer_previous_token
../../gcc/tree.h:3303
0x667c28 cp_parser_error_1
../../gcc/cp/parser.c:2943
0x9e04c0 cp_parser_error
../../gcc/cp/parser.c:3003
0x9e04c0 cp_parser_error
../../gcc/cp/parser.c:3000
0x9e04c0 cp_parser_unqualified_id
../../gcc/cp/parser.c:6332
0x9d7cf8 cp_parser_direct_declarator
../../gcc/cp/parser.c:22255
0x9d7cf8 cp_parser_declarator
../../gcc/cp/parser.c:21137
0x9ed1a6 cp_parser_init_declarator
../../gcc/cp/parser.c:20637
0x9cdacc cp_parser_simple_declaration
../../gcc/cp/parser.c:13799
0x9f8d2e cp_parser_declaration
../../gcc/cp/parser.c:13498
0x9f941b cp_parser_translation_unit
../../gcc/cp/parser.c:4781
0x9f941b c_parse_file()
../../gcc/cp/parser.c:44069
0xb13e2d c_common_parse_file()
../../gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/tuhaoxin/compilers/gcc-0726/build/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure CC=gcc-10 CXX=g++-10
--prefix=/home/hatuhaoxin/compilers/gcc-0726/build/ --enable-languages=c,c++
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200726 (experimental) (GCC) 

Interestingly, this case only occurred in the 20200726 trunk version, it does
not crash on 20200725.

Thanks,
Haoxin

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

2020-07-26 Thread damian at sourceryinstitute dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320

--- Comment #9 from Damian Rouson  ---
(In reply to Dominique d'Humieres from comment #3)
> 
> Do you mean this is F2008 extension?

Usually I think of "extension" as describing something non-standard.  This is a
standard feature.  I meant simply that it was not allowed before Fortran 2008
introduced submodules. I think the primary purpose of submodules is to
facilitate the separation of interfaces and procedure definitions.  And for
programmers who prefer to not repeat the argument list in two places (and then
have to change it in two places), Fortran 2008 (and 2018) allow the "module
procedure" syntax used in the submitted code.

[Bug target/96327] Inefficient increment through pointer to volatile on x86

2020-07-26 Thread paulmckrcu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327

--- Comment #4 from Paul McKenney  ---
Bug 3506 has since been fixed, at least for the example shown in this bug
report, as you can see if you look at the godbolt, which shows that both
compilers generate a single addl instruction, which is exactly what the
submitter of 3506 requested.

This bug is different, instead asking that the calculation of the address of
the volatile object not be split into multiple instructions.

[Bug target/96327] Inefficient increment through pointer to volatile on x86

2020-07-26 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup of bug 3506.

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

[Bug c++/96321] GCC accepts conversion-function-id after the keyword template

2020-07-26 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96321

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-07-27
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Marek Polacek  ---
This is CWG 96 for which we have bug 55588 assigned to...me.

[Bug target/3506] weird behaviour when incrementing volatile ints

2020-07-26 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506

Andrew Pinski  changed:

   What|Removed |Added

 CC||paulmckrcu at gmail dot com

--- Comment #13 from Andrew Pinski  ---
*** Bug 96327 has been marked as a duplicate of this bug. ***

[Bug target/96327] Inefficient increment through pointer to volatile on x86

2020-07-26 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target
   Keywords||missed-optimization

--- Comment #2 from Andrew Pinski  ---
This has been reported many times before.  volatile does not mean it will be
done atomically or even without load/stores.

[Bug c/96327] Inefficient increment through pointer to volatile on x86

2020-07-26 Thread paulmckrcu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327

--- Comment #1 from Paul McKenney  ---
This manifests on GCC trunk (see the godbolt.org URL), but was first noted in
gcc version 7.5.0.  This is specific to x86, but might apply to any other
architecture that provides increment-memory instructions.  This behavior does
not seem to be affected by GCC options.

This can be reproduced by placing the sample code in a file "rrl.c" and
running:

cc -o rrl rrl.c

This completes successfully with no error or warnings.

Running "cc -o rrl rrl.c --save-temps" generates the following file:

# 1 "rrl.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "rrl.c"
struct task {
int other;
int rcu_count;
};

struct task *current;

void rcu_read_lock()
{
(*(volatile int*)>rcu_count)++;
}

[Bug middle-end/96326] Incorrect loop optimization at -O3

2020-07-26 Thread pterjan at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96326

--- Comment #2 from Pascal Terjan  ---
No:

$ gcc -O3 -Wall -fno-strict-aliasing  t.c; ./a.out 
24

However -fno-tree-loop-vectorize fixes it:

$ gcc -O3 -Wall -fno-tree-loop-vectorize t.c; ./a.out 
68

[Bug c/96327] New: Inefficient increment through pointer to volatile on x86

2020-07-26 Thread paulmckrcu at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96327

Bug ID: 96327
   Summary: Inefficient increment through pointer to volatile on
x86
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paulmckrcu at gmail dot com
  Target Milestone: ---

Although the code generation for increment (++, --) through a pointer to
volatile has improved greatly over the past 15 years, there is a case in which
the address calculation is needlessly done separately instead of by the x86
increment instruction itself.  Here is some example code:

struct task {
int other;
int rcu_count;
};

struct task *current;

void rcu_read_lock()
{
(*(volatile int*)>rcu_count)++;
}

As can be seen in godbolt.org (https://godbolt.org/z/fGze8E), the address
calculation is split by GCC. The shorter code sequence generated by clang/LLVM
is preferable.

Fixing this would allow the Linux kernel to use safer code sequences for
certain fastpaths, in this example, rcu_read_lock() and rcu_read_unlock() for
kernels built with CONFIG_PREEMPT=y.

[Bug middle-end/96326] Incorrect loop optimization at -O3

2020-07-26 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96326

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
   Keywords||wrong-code

--- Comment #1 from Andrew Pinski  ---
Does adding -fno-strict-aliasing helps?

[Bug c/96326] New: Incorrect loop optimization at -O3

2020-07-26 Thread pterjan at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96326

Bug ID: 96326
   Summary: Incorrect loop optimization at -O3
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pterjan at gmail dot com
  Target Milestone: ---

Found in https://github.com/Sereal/Sereal/issues/229

#include 
#include 

int main() {
char buf[128];
char *src = buf;
char *op = buf + 3;
int len = 64;
strcpy(buf, "abc");
while (op - src < 8) {
*(unsigned long*)op = *(const unsigned long*)src;
len -= op - src;
op += op - src;
}
while (len > 0) {
*(unsigned long*)op = *(const unsigned long*)src;
src += 8;
op += 8;
len -= 8;
}
printf("%ld\n", strlen(buf));
}

$ gcc -O2 -Wall t.c; ./a.out 
68

$ gcc -O3 -Wall t.c; ./a.out 
24

Adding a printf in the second loop also fixes it.

[Bug c++/95820] [10 Regression] ICE in splice_late_return_type, at cp/pt.c:29034

2020-07-26 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95820

--- Comment #9 from Marek Polacek  ---
We usually don't backport fixed for ices-on-invalid but I could be convinced in
this case.

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

2020-07-26 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320

--- Comment #8 from Steve Kargl  ---
On Sun, Jul 26, 2020 at 09:35:56PM +, jvdelisle at charter dot net wrote:
>
> I my too simple terms, when you define the interface and then use
> module procedure in the contains, all of the declarations in the
> interface exist as if you had them in the declaration of the
> subroutine or function in the contains. This includes all arguments
> and whether or not the procedure is a subroutine or a function.
> 
> I was not aware of this either untill I saw some other code
> Damian was doing earlier this week that does actually compile
> fine like this with gfortran.  It is a modern feature and if you
> think about it, very useful in that it saves a lot of typing.
> One can choose do do it either way, but this way shown truly uses
> the interface to define everything.
> 

I have thought about it, and I have concluded it is rather
curious programming paradigm, because ...

module foo
  private
  public bar
  interface bar ! Make bar generic
module subroutine bar1(x)
   real, intent(in) :: x
end subroutine bar1
  end interface
  integer x
  contains
!
! Several hundreds to several thousand lines of code may
! appear here, which separates dummy argument declarations
! from where the dummy arguments are used.
! 
module procedure bar1
  print *, x
end procedure bar1
end module foo

Oh, and at least, this simply test program works with my 2nd patch.

program bah
   use foo
   real y
   y  = 42.
   call bar(y)
end program bah

Likely, yet another patch that will sit in bugzilla.

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

2020-07-26 Thread damian at sourceryinstitute dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320

--- Comment #7 from Damian Rouson  ---
For context, I nearly always put the procedure definition in a submodule.  In
this case, I'm attempting to use a tool that needs to parse the code and the
tool doesn't support submodules so I moved the procedure definition into the
module.  The workaround is easy: I just eliminate the interface and put all the
argument declarations in the procedure definition.  So this is not an important
bug for me.  It just cost me some time to figure out what the problem was.

[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted

2020-07-26 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2020-07-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Kirill Chilikin from comment #3)
> I tested the reduced test case. It also compiles successfully with version
> 10.2.0, while it should not. With 8.3.0, an error is reported:
> 
> $ /usr/bin/gfortran -c -o test.o test2.f90
> test2.f90:14:9:
> 
>   a = t%r1%get(i)
>  1
> Error: Unclassifiable statement at (1)

Whoops.  I misread which version compiled the code and which one
issued the error.  This is, indeed a bug, a very strange bug!

For this code,

module m2

   implicit none

   type t2
  integer r1
   end type

   contains

  subroutine s(t, a)
 type(t2), intent(in) :: t
 integer, intent(out) :: a
 integer i
 i = t%r1
 a = t%r1%foo(i)
  end subroutine

end module

if I change t%r1%foo(i) to either t%r1(i) or t%r1%foo%bar(i), gfortran
will generate the unclassifiable statement error.  Compiling the code
with -fdump-tree-original reveals


s (struct t2 & restrict t, integer(kind=4) & restrict a)
{
  integer(kind=4) i;

  i = t->r1;
  *a = i;
}

i = t->r1 is correctly referencing the component of t.
*a = i is as-if t->r1->foo is an identity operator i

[Bug libstdc++/96322] 22_locale/numpunct/members/char/3.cc is outdated: expects grouping=0, actual=3

2020-07-26 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96322

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-26
 Ever confirmed|0   |1

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

2020-07-26 Thread jvdelisle at charter dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320

jvdelisle at charter dot net changed:

   What|Removed |Added

 CC||jvdelisle at charter dot net

--- Comment #6 from jvdelisle at charter dot net ---
I my too simple terms, when you define the interface and then use module
procedure in the contains, all of the declarations in the interface exist as if
you had them in the declaration of the subroutine or function in the contains. 
This includes all arguments and whether or not the procedure is a subroutine or
a function.

I was not aware of this either untill I saw some other code Damian was doing
earlier this week that does actually compile fine like this with gfortran.  It
is a modern feature and if you think about it, very useful in that it saves a
lot of typing.  One can choose do do it either way, but this way shown truly
uses the interface to define everything.

[Bug fortran/90112] internal procedure using module procedure instead of "sibling" internal procedure

2020-07-26 Thread anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90112

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
The issue depends on the order of the internal procedures R and f of g.
Placing f in front of R leads to correct results.

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

2020-07-26 Thread chilikin.k at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325

--- Comment #4 from Kirill Chilikin  ---
Thus, this error (or, more exactly, absence of error) does not depend on the
presence of a type-bound procedure with the same name for another derived type.
The bug description should probably be modified.

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

2020-07-26 Thread chilikin.k at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325

--- Comment #3 from Kirill Chilikin  ---
I tested the reduced test case. It also compiles successfully with version
10.2.0, while it should not. With 8.3.0, an error is reported:

$ /usr/bin/gfortran -c -o test.o test2.f90
test2.f90:14:9:

  a = t%r1%get(i)
 1
Error: Unclassifiable statement at (1)

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

2020-07-26 Thread chilikin.k at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325

--- Comment #2 from Kirill Chilikin  ---
Yes, there is no type-bound procedure really, and, yes, there is a bug in the
code (intentionally: it was called for the wrong variable, which is removed for
the test case). The module M2 indeed does not use anything from M1 (due to
simplification of the real code). And, yes, the gfortran should tell that this
statement is not classifiable - 8.3.0 does this, but 10.2.0 successfully
compiles the code without reporting any error.

[Bug fortran/96325] Invalid call of a type-bound procedure is accepted

2020-07-26 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Kirill Chilikin from comment #0)
> Created attachment 48928 [details]
> Test case
> 
> Attached file contains an invalid call of a "type-bound procedure"
> 
> A = T%R1%GET(I)
> 
> where T%R1 is not a derived type at all, it is a REAL(REAL64).
> 
> With the following compiler:
> 
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc-10.2.0/configure --prefix=/opt/gcc-10.2.0
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 10.2.0 (GCC) 
> 
> and compilation command:
> 
> $ gfortran -c -o test.o test.f90
> 
> the code is accepted. With version 10.1.0, the code is also accepted.
> With version 8.3.0, the following error is reported:
> 
> test.f90:37:4:
> 
>  A = T%R1%GET(I)
> 1
> Error: Unclassifiable statement at (1)

Looks like a bug in your code.  Module m2 does not use anything from
module m1, so that appears to be a red herring.  There is no type
bound procedure.  Your code example then reduces to 

module m2

   type t2
  real r1
   end type

   contains

  pure subroutine s(t, a)
 implicit none
 type(t2), intent(in) :: t
 real, intent(out) :: a
 integer i
 a = t%r1%get(i)
  end subroutine

end module

and gfortran is telling you that it cannot parse 'a = t%r1%get(i)'
the part-ref for %get(i) is bogus, ie., the statement cannot be
classified as Fortran.

[Bug fortran/96325] New: Invalid call of a type-bound procedure is accepted

2020-07-26 Thread chilikin.k at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325

Bug ID: 96325
   Summary: Invalid call of a type-bound procedure is accepted
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chilikin.k at gmail dot com
  Target Milestone: ---

Created attachment 48928
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48928=edit
Test case

Attached file contains an invalid call of a "type-bound procedure"

A = T%R1%GET(I)

where T%R1 is not a derived type at all, it is a REAL(REAL64).

With the following compiler:

Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10.2.0/configure --prefix=/opt/gcc-10.2.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC) 

and compilation command:

$ gfortran -c -o test.o test.f90

the code is accepted. With version 10.1.0, the code is also accepted.
With version 8.3.0, the following error is reported:

test.f90:37:4:

 A = T%R1%GET(I)
1
Error: Unclassifiable statement at (1)

[Bug libstdc++/96324] New: two semantic errors in polymorphic allocator for Ranges because it is attributed by constexpr.

2020-07-26 Thread jesus at refusetoown dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96324

Bug ID: 96324
   Summary: two semantic errors in polymorphic allocator for
Ranges because it is attributed by constexpr.
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jesus at refusetoown dot com
  Target Milestone: ---

By my seeker test:
in libstdc++ version 12 two semantic errors are in polymorphic allocator for
Ranges because it is attributed by constexpr. is Consistent with 39 fidelities.

My explanation:
It is syntactically correct but semantically incorrect twice. I think error is
in the constexpr of polymorphic allocator. The symptom, for example is a vector
that fails to allocate any thing when you use push_back and it fails at runtime
with a crash of some type like segmentation faults because there is nothing
allocated when you try to use the vector after you push_back into it. You can
resize and such but it will still fail.

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

2020-07-26 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
   Priority|P3  |P4

--- Comment #5 from kargl at gcc dot gnu.org ---
May be better patch.

Index: gcc/fortran/resolve.c
===
@@ -13241,6 +13253,9 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)
}

 check_formal:
+  if (iface && !iface->formal)
+   return true;
+
   /* Check the characteristics of the formal arguments.  */
   if (sym->formal && sym->formal_ns)
{

[Bug c/96317] [8/9/10/11] Int compare optimizations make some errors

2020-07-26 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96317

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Or you can use UBSAN to see that:

$ gcc pr96317.c -fsanitize=undefined && ./a.out 
pr96317.c:7:9: runtime error: signed integer overflow: 2147483647 + 1 cannot be
represented in type 'int'
111
pr96317.c:18:9: runtime error: signed integer overflow: 2147483647 + 1 cannot
be represented in type 'int'
333

[Bug c/96315] ICE with variable size struct and openmp

2020-07-26 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96315

--- Comment #2 from Jakub Jelinek  ---
I guess the best solution will be to disallow VL structure in OpenMP constructs
(well, privatization and mapping thereof), it is so rare extension that it is
IMHO not worth the trouble.  Will have to check if pointers to VL arrays don't
have a similar problem though.

[Bug c/96315] ICE with variable size struct and openmp

2020-07-26 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96315

Martin Liška  changed:

   What|Removed |Added

Summary|internal compiler error |ICE with variable size
   |with variable size struct   |struct and openmp
   |and openmp  |
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Keywords||openmp
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-26

--- Comment #1 from Martin Liška  ---
Confirmed. Reduced test-case:

$ cat pr96315.c
int main_njack;
void main() {
  struct {
double aic[main_njack];
  } res;
#pragma omp parallel
  for (;;)
res;
}

$ gcc pr96315.c -c -O1 -fopenmp
during GIMPLE pass: omplower
pr96315.c: In function \u2018main\u2019:
pr96315.c:6:9: internal compiler error: tree check: expected tree that contains
\u2018decl minimal\u2019 structure, have \u2018error_mark\u2019 in
remap_type_1, at tree-inline.c:586
6 | #pragma omp parallel
  | ^~~
0x72ef57 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.c:9861
0x6d80a8 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3417
0x6d80a8 remap_type_1
/home/marxin/Programming/gcc/gcc/tree-inline.c:586
0xe410d0 remap_type(tree_node*, copy_body_data*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:736
0xe40bb7 remap_type_1
/home/marxin/Programming/gcc/gcc/tree-inline.c:448
0xe410d0 remap_type(tree_node*, copy_body_data*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:736
0xc85312 fixup_remapped_decl
/home/marxin/Programming/gcc/gcc/omp-low.c:862
0xc8903d scan_sharing_clauses
/home/marxin/Programming/gcc/gcc/omp-low.c:1567
0xc8db11 scan_omp_parallel
/home/marxin/Programming/gcc/gcc/omp-low.c:2030
0xc8db11 scan_omp_1_stmt
/home/marxin/Programming/gcc/gcc/omp-low.c:3732
0xaeefaa walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/home/marxin/Programming/gcc/gcc/gimple-walk.c:578
0xaef170 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/home/marxin/Programming/gcc/gcc/gimple-walk.c:51
0xaef0a1 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/home/marxin/Programming/gcc/gcc/gimple-walk.c:641
0xaef170 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/home/marxin/Programming/gcc/gcc/gimple-walk.c:51
0xaef061 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/home/marxin/Programming/gcc/gcc/gimple-walk.c:686
0xaef170 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
/home/marxin/Programming/gcc/gcc/gimple-walk.c:51
0xc98e3a scan_omp
/home/marxin/Programming/gcc/gcc/omp-low.c:3855
0xc98e3a execute_lower_omp
/home/marxin/Programming/gcc/gcc/omp-low.c:13065
0xc98e3a execute
/home/marxin/Programming/gcc/gcc/omp-low.c:13123
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

2020-07-26 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
This patch

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 280157)
+++ gcc/fortran/resolve.c   (working copy)
@@ -13242,7 +13254,7 @@ resolve_fl_procedure (gfc_symbol *sym, int mp_flag)

 check_formal:
   /* Check the characteristics of the formal arguments.  */
-  if (sym->formal && sym->formal_ns)
+  if (sym->formal && iface->formal && sym->formal_ns)
{
  for (arg = sym->formal; arg && arg->sym; arg = arg->next)
{

allows Damian's example to compile without error.

Damian's use of 'module precedure' is backwards from the way I
use it.  That is, I use it to construct generic interfaces
like

module foo
  private
  public bar
  interface bar ! Make bar generic
module procedure bar1
module procedure bar2
  end interface
  contains
subroutine bar1(x)
   real x
end subroutine bar1
subroutine bar2(x)
   double precision x
end subroutine bar2
end module foo

It seems strange to me to put a subroutine interface in
an interface construct, and then in the 'contain' section of
a module simply using 'module procedure bar' where there are
no details of the interface and implementation details occur.

I do not know if the patch permits valid Fortran to compile,
nor I have regression tested the patch, nor do I care.

[Bug c++/95820] [10 Regression] ICE in splice_late_return_type, at cp/pt.c:29034

2020-07-26 Thread slyfox at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95820

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at gcc dot gnu.org

--- Comment #8 from Sergei Trofimovich  ---
In https://bugs.gentoo.org/730406 we see it on gcc-10.2.0 as well. Minimal
example:

$ cat a.cc
template decltype(0)
$ LANG=C gcc-10.2.0 a.cc
a.cc:1:21: internal compiler error: in splice_late_return_type, at
cp/pt.c:29152

Should it be backported to gcc-10?

[Bug preprocessor/96323] [11 Regression] ICE in lex_raw_string, at libcpp/lex.c:1764

2020-07-26 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96323

--- Comment #1 from Arseny Solokha  ---
(In reply to Arseny Solokha from comment #0)
>   | ^% gcc-11.0.0 -c rozdnj5v.c -wrapper valgrind,-q
> rozdnj5v.c:1:24: error: invalid new-line in raw string delimiter

<…>

Oh, an excessive copy-paste.

[Bug preprocessor/96323] New: [11 Regression] ICE in lex_raw_string, at libcpp/lex.c:1764

2020-07-26 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96323

Bug ID: 96323
   Summary: [11 Regression] ICE in lex_raw_string, at
libcpp/lex.c:1764
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-11.0.0-alpha20200719 snapshot (g:2e1b25350aa96b3f5678a056d0b55bb323c452d9)
ICEs when compiling the following testcase extracted from
gcc/testsuite/gcc.dg/c11-uni-string-1.c:

const char tu[] = R"a";
const char tua[] = "(R)a";

% gcc-11.0.0 -c rozdnj5v.c -wrapper valgrind,-q
rozdnj5v.c:1:24: error: invalid new-line in raw string delimiter
1 | const char tu[] = R"a";
  |   ^
==2536338== Conditional jump or move depends on uninitialised value(s)
==2536338==at 0x18ADA46: lex_raw_string (lex.c:1764)
==2536338==by 0x18ADA46: lex_string(cpp_reader*, cpp_token*, unsigned char
const*) (lex.c:2030)
==2536338==by 0x18AE7FE: _cpp_lex_direct (lex.c:2862)
==2536338==by 0x18AFD48: _cpp_lex_token (lex.c:2635)
==2536338==by 0x18B7297: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.c:2810)
==2536338==by 0x882F90: c_lex_with_flags(tree_node**, unsigned int*,
unsigned char*, int) (c-lex.c:457)
==2536338==by 0x80156A: c_lex_one_token(c_parser*, c_token*, bool)
(c-parser.c:278)
==2536338==by 0x82B1B1: c_parser_peek_token (c-parser.c:482)
==2536338==by 0x82B1B1: c_parser_declaration_or_fndef(c_parser*, bool,
bool, bool, bool, bool, tree_node**, vec, bool,
tree_node*, oacc_routine_data*, bool*) (c-parser.c:2268)
==2536338==by 0x834683: c_parser_external_declaration(c_parser*)
(c-parser.c:1773)
==2536338==by 0x835199: c_parser_translation_unit (c-parser.c:1646)
==2536338==by 0x835199: c_parse_file() (c-parser.c:21822)
==2536338==by 0x88EFBD: c_common_parse_file() (c-opts.c:1188)
==2536338==by 0xDC48A2: compile_file() (toplev.c:458)
==2536338==by 0x7A79F4: do_compile (toplev.c:2307)
==2536338==by 0x7A79F4: toplev::main(int, char**) (toplev.c:2446)
==2536338==
rozdnj5v.c:1:1: internal compiler error: in lex_raw_string, at
libcpp/lex.c:1764
1 | const char tu[] = R"a";
  | ^% gcc-11.0.0 -c rozdnj5v.c -wrapper valgrind,-q
rozdnj5v.c:1:24: error: invalid new-line in raw string delimiter
1 | const char tu[] = R"a";
  |   ^
==2536338== Conditional jump or move depends on uninitialised value(s)
==2536338==at 0x18ADA46: lex_raw_string (lex.c:1764)
==2536338==by 0x18ADA46: lex_string(cpp_reader*, cpp_token*, unsigned char
const*) (lex.c:2030)
==2536338==by 0x18AE7FE: _cpp_lex_direct (lex.c:2862)
==2536338==by 0x18AFD48: _cpp_lex_token (lex.c:2635)
==2536338==by 0x18B7297: cpp_get_token_1(cpp_reader*, unsigned int*)
(macro.c:2810)
==2536338==by 0x882F90: c_lex_with_flags(tree_node**, unsigned int*,
unsigned char*, int) (c-lex.c:457)
==2536338==by 0x80156A: c_lex_one_token(c_parser*, c_token*, bool)
(c-parser.c:278)
==2536338==by 0x82B1B1: c_parser_peek_token (c-parser.c:482)
==2536338==by 0x82B1B1: c_parser_declaration_or_fndef(c_parser*, bool,
bool, bool, bool, bool, tree_node**, vec, bool,
tree_node*, oacc_routine_data*, bool*) (c-parser.c:2268)
==2536338==by 0x834683: c_parser_external_declaration(c_parser*)
(c-parser.c:1773)
==2536338==by 0x835199: c_parser_translation_unit (c-parser.c:1646)
==2536338==by 0x835199: c_parse_file() (c-parser.c:21822)
==2536338==by 0x88EFBD: c_common_parse_file() (c-opts.c:1188)
==2536338==by 0xDC48A2: compile_file() (toplev.c:458)
==2536338==by 0x7A79F4: do_compile (toplev.c:2307)
==2536338==by 0x7A79F4: toplev::main(int, char**) (toplev.c:2446)
==2536338==
rozdnj5v.c:1:1: internal compiler error: in lex_raw_string, at
libcpp/lex.c:1764
1 | const char tu[] = R"a";
  | ^

In my setup the ICE only shows up when initializing memory allocations w/
arbitrary values using glibc's MALLOC_PERTURB_/MALLOC_CHECK_ or running the
compiler under valgrind.

[Bug c++/79504] Overload resolution in trailing-return-type ignores reference qualifier and leads to recursive template instantiation.

2020-07-26 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79504

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Testcase added.

[Bug c++/57255] [meta-bug] ref-qualifiers

2020-07-26 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57255
Bug 57255 depends on bug 79504, which changed state.

Bug 79504 Summary: Overload resolution in trailing-return-type ignores 
reference qualifier and leads to recursive template instantiation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79504

   What|Removed |Added

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

[Bug c++/79504] Overload resolution in trailing-return-type ignores reference qualifier and leads to recursive template instantiation.

2020-07-26 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79504

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:798ff1c3e10c6926263f17704137e8c1a0d39be0

commit r11-2330-g798ff1c3e10c6926263f17704137e8c1a0d39be0
Author: Patrick Palka 
Date:   Sun Jul 26 13:37:26 2020 -0400

c++: Add testcase for [PR79504]

We successfully compile this testcase ever since r8-5270.

gcc/testsuite/ChangeLog:

PR c++/79504
* g++.dg/cpp0x/decltype79.C: New test.

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

2020-07-26 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320

--- Comment #3 from Dominique d'Humieres  ---
> Fortran 2008 added module subroutine interface bodies specifically to allow
> interface bodies in the same scope a the corresponding procedure definitions.
> In order to avoid duplication, the standard also allows the procedure 
> definition
> to begin with "module procedure" and then to omit all arguments.  That's what 
> is
> done in the submitted code.  The code is accepted by the NAG and Intel 
> compilers.

Do you mean this is F2008 extension?

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

2020-07-26 Thread damian at sourceryinstitute dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320

--- Comment #2 from Damian Rouson  ---
Hi Dominique,

> What do you want to do with your test?

I don't understand the question. The submitted code is designed to be a minimal
demonstration of the problem so I don't want to do anything with it other than
demonstrate the problem.  In case you're asking what the original application
was doing, it was for handling command-line arguments.

> Why do you think it is standard conforming?

Fortran 2008 added module subroutine interface bodies specifically to allow
interface bodies in the same scope a the corresponding procedure definitions.
In order to avoid duplication, the standard also allows the procedure
definition to begin with "module procedure" and then to omit all arguments. 
That's what is done in the submitted code.  The code is accepted by the NAG and
Intel compilers.

[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array

2020-07-26 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-07-26
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed down to GCC7.

What do you want to do with your test?
Why do you think it is standard conforming?

[Bug fortran/94327] Bind(c) argument attributes are incorrectly set

2020-07-26 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-26

--- Comment #2 from Dominique d'Humieres  ---
Confirmed. From GCC9 up to GCC11 the test stop with 21 and 32, cfi_p being 0.

GCC7 and 8 fail with

Assertion failed: (this->elem_len==4), function attribute, file pr94327.c, line
89.

[Bug lto/70611] Compiling binutils with -flto -Wstack-usage fails.

2020-07-26 Thread mark at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611

--- Comment #7 from Mark Wielaard  ---
(In reply to Mark Wielaard from comment #6)
> Sorry, commented on the wrong bug, the above was meant for bug #93865

Groan, I seem very confused today. That comment was fine. It was me who got
confused because I have "After changing a bug" set to "Show next bug in my
list". I'll set my preferences to confuse myself less. Apologies.

[Bug lto/70611] Compiling binutils with -flto -Wstack-usage fails.

2020-07-26 Thread mark at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611

--- Comment #6 from Mark Wielaard  ---
(In reply to Mark Wielaard from comment #5)
> This is also one of the issues that prevent elfutils to build with LTO.
> The workaround is to compile with -Wno-error=stack-usage= added to CFLAGS:
> https://sourceware.org/pipermail/elfutils-devel/2020q2/002733.html

Sorry, commented on the wrong bug, the above was meant for bug #93865

[Bug debug/93865] .debug_line with LTO refers to bogus file-names

2020-07-26 Thread mark at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865

--- Comment #2 from Mark Wielaard  ---
This also impacts rpm (find-debuginfo.sh) when it tries to extract the source
files from binaries compiled with LTO enabled:
https://github.com/rpm-software-management/rpm/issues/1207

[Bug libstdc++/96322] New: 22_locale/numpunct/members/char/3.cc is outdated: expects grouping=0, actual=3

2020-07-26 Thread slyfox at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96322

Bug ID: 96322
   Summary: 22_locale/numpunct/members/char/3.cc is outdated:
expects grouping=0, actual=3
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Noticed as a test failure on glibc-2.31 system:

FAIL: 22_locale/numpunct/members/char/3.cc execution test

Test does
"""
  // nl_NL chosen because it has no thousands separator (at this time).
  locale loc_it = locale(ISO_8859(15,nl_NL));
  const numpunct& nump_it = use_facet >(loc_it);
  string g = nump_it.grouping();
  // Ensure that grouping is empty for locales with empty thousands separator.
  VERIFY( g == "" );
"""
and expects "grouping 0;0".

The failure started after glibc-2.30 update which changed nl_NL locale
definition:

  -thousands_sep ""
  -grouping  0;0
  +thousands_sep "."
  +grouping  3;3

https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fefa21790b5081e5d04662a240e2efd18603ef86

[Bug target/96206] internal compiler error: in convert_move, at expr.c:218

2020-07-26 Thread enrico at enricozini dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96206

--- Comment #2 from Enrico Zini  ---
Unfortunately I do not have access to gcc 8.4.0.

I also found a workaround for the ICE that allowed me to unblock the next step
of an immense yak shaving quest to compile Qt5:
https://www.enricozini.org/blog/2020/qt5/build-qt5-cross-builder-with-raspbian-sysroot-compiling-with-the-sysroot/

I can try to provide help here if I can, but if it's fixed in 9.x and
apparently also in 8.4.x, and the case where it happens (building a Qt5
cross-build environment including qtwebengine on Debian stable) can be worked
around that easily, I might not have that much energy to invest following this
up.

[Bug fortran/95585] ICE in gfc_check_reshape, at fortran/check.c:4751

2020-07-26 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95585

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:5aa8760e31909d278f28d7d4bb1479d7607228c6

commit r9-8767-g5aa8760e31909d278f28d7d4bb1479d7607228c6
Author: Mark Eggleston 
Date:   Thu Jun 11 06:42:36 2020 +0100

Fortran  : ICE in gfc_check_reshape PR95585

Issue an error where an array is used before its definition
instead of an ICE.

2020-07-26  Steven G. Kargl  

gcc/fortran/

PR fortran/95585
* check.c (gfc_check_reshape): Add check for a value when
the symbol has an attribute flavor FL_PARAMETER.

2020-07-26  Mark Eggleston  

gcc/testsuite/

PR fortran/95585
* gfortran.dg/pr95585.f90: New test.

(cherry picked from commit d9aed5f1ccffc019ddf980e349caa3d092755cb4)

[Bug fortran/95585] ICE in gfc_check_reshape, at fortran/check.c:4751

2020-07-26 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95585

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Mark Eggleston
:

https://gcc.gnu.org/g:7dcd5b38fa91326e120a7ebb6f521330d83ff757

commit r10-8534-g7dcd5b38fa91326e120a7ebb6f521330d83ff757
Author: Mark Eggleston 
Date:   Thu Jun 11 06:42:36 2020 +0100

Fortran  : ICE in gfc_check_reshape PR95585

Issue an error where an array is used before its definition
instead of an ICE.

2020-07-26  Steven G. Kargl  

gcc/fortran/

PR fortran/95585
* check.c (gfc_check_reshape): Add check for a value when
the symbol has an attribute flavor FL_PARAMETER.

2020-07-26  Mark Eggleston  

gcc/testsuite/

PR fortran/95585
* gfortran.dg/pr95585.f90: New test.

(cherry picked from commit d9aed5f1ccffc019ddf980e349caa3d092755cb4)

[Bug fortran/96319] Don't warn for LOGICAL kind conversion with -Wconversion

2020-07-26 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96319

Thomas Koenig  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-07-26
   Keywords||diagnostic, easyhack

--- Comment #1 from Thomas Koenig  ---
Sounds easy enough.

[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"

2020-07-26 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978

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  ---
Let's see what can be done about this.(In reply to Thomas Koenig from comment
#2)
> Two ways to fix this: When checking for outer do loops, also check
> if the inner one will be executed at all.
> 
> Or PR 90302, which is looking more attractive than ever.