[Bug c++/67991] Pointer to function with internal linkage not being allowed, when it should be

[nacitar at ubercpp dot com]

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

Jacob McIntosh  changed:

   What|Removed |Added

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

--- Comment #10 from Jacob McIntosh  ---
Fixed in 8.1+

[Bug c++/67991] Pointer to function with internal linkage not being allowed, when it should be

[nacitar at ubercpp dot com]

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

--- Comment #9 from Jacob McIntosh  ---
This is fixed in gcc 8.1.0+

[Bug lto/89084] New: [9 Regression] ICE in get_partitioning_class, at symtab.c:1892

[asolokha at gmx dot com]

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

Bug ID: 89084
   Summary: [9 Regression] ICE in get_partitioning_class, at
symtab.c:1892
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code, lto
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

gfortran-9.0.0-alpha20190127 snapshot (r268327) ICEs when compiling the
following testcase extracted from gcc/testsuite/gfortran.dg/block_16.f08 w/
-flto:

MODULE sparse_matrix_csx_benchmark_utils
  IMPLICIT NONE
CONTAINS  
  SUBROUTINE sparse_matrix_csr_benchmark ( )
WRITE(*,*) 'At*x: t'
block
  integer, dimension(1), parameter :: idxs=[1]
  integer :: i, idx
  do i = 1, size(idxs)
 idx = idxs(i)
  enddo
end block
  END SUBROUTINE sparse_matrix_csr_benchmark
END MODULE sparse_matrix_csx_benchmark_utils

% powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190127 -flto -c cgze3e1i.f08
during IPA pass: fnsummary
cgze3e1i.f08:13: internal compiler error: in get_partitioning_class, at
symtab.c:1892
   13 |   END SUBROUTINE sparse_matrix_csr_benchmark
  | 
0x5a6e79 symtab_node::get_partitioning_class()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/symtab.c:1892
0xc3c5b5 lto_output_varpool_node
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/lto-cgraph.c:618
0xc3c5b5 output_symtab()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/lto-cgraph.c:981
0xc4e0d4 lto_output()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/lto-streamer-out.c:2476
0xcc26fe write_lto
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/passes.c:2593
0xcc6090 ipa_write_summaries_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/passes.c:2657
0xcc6090 ipa_write_summaries()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/passes.c:2720
0x98211c ipa_passes
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cgraphunit.c:2529
0x98211c symbol_table::compile()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cgraphunit.c:2617
0x984ad8 symbol_table::finalize_compilation_unit()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cgraphunit.c:2862

(While my target here is powerpc, the ICE is not target-specific.)

[Bug c++/67991] Pointer to function with internal linkage not being allowed, when it should be

[nacitar at ubercpp dot com]

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

Jacob McIntosh  changed:

   What|Removed |Added

Version|5.2.0   |7.3.0

--- Comment #8 from Jacob McIntosh  ---
This problem still persists in 7.3.0-r3.

It builds with clang with -std=c++17, though... but not in gcc.

[Bug c++/89083] New: [9 Regression] ICE in reshape_init_r, at cp/decl.c:6172

[asolokha at gmx dot com]

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

Bug ID: 89083
   Summary: [9 Regression] ICE in reshape_init_r, at
cp/decl.c:6172
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-9.0.0-alpha20190127 snapshot (r268327) ICEs when compiling the following
testcase extracted from test/CodeGenCXX/mangle-exprs.cpp from the clang 7.0.1.
testsuite:

struct A { int x[3]; };
template decltype(A{1,2},T()) fA1(T t) { return t; }
void f() { fA1(1); }

% g++-9.0.0-alpha20190127 -c surhyc2s.cpp
surhyc2s.cpp: In substitution of 'template decltype ((A{int [3]{1,
2}}, T())) fA1(T) [with T = int]':
surhyc2s.cpp:3:17:   required from here
surhyc2s.cpp:2:28: internal compiler error: in reshape_init_r, at
cp/decl.c:6172
2 | template decltype(A{1,2},T()) fA1(T t) { return t; }
  |^~
0x5e629c reshape_init_r
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/decl.c:6172
0x8fb77b reshape_init_class
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/decl.c:5950
0x8fb77b reshape_init_r
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/decl.c:6185
0x8fb0f6 reshape_init(tree_node*, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/decl.c:6245
0xa299ae finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/semantics.c:2827
0x9e849d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:19230
0x9e7c6e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:19355
0x9e8311 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:18569
0x9f651c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:14991
0x9f651c tsubst(tree_node*, tree_node*, int, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:14991
0x9fbe94 tsubst_function_type
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:14045
0x9f6822 tsubst(tree_node*, tree_node*, int, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:14815
0x9ebab5 tsubst_function_decl
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:12948
0x9ecee7 tsubst_decl
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:13358
0x9f6fdf tsubst(tree_node*, tree_node*, int, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:14258
0x9f5911 instantiate_template_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:19637
0x9f5911 instantiate_template(tree_node*, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:19693
0xa0d76f fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/pt.c:20127
0x89dbef add_template_candidate_real
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/call.c:3247
0x89e5f6 add_template_candidate
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/cp/call.c:3332

I believe it is not a duplicate of PR80864.

[Bug c/59616] OpenMP standard conflict in parallel default clause

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #4)
> This has been changed unintentionally in the OpenMP standard, I was hoping
> and trying to resolve the incompatibility and that is why GCC kept using the
> 3.1 rule here.  In the end after discussing it in the language committee
> recently we've decided that it is too late to resolve it and it will stay
> the way it is currently worded, gomp-5_0-branch already implements this
> behavior and GCC 9 will too.

Ah right, I think I saw you submitting a change to the "Porting to GCC 9"
document mentioning this...

[Bug fortran/85836] [meta-bug] Fortran 2018 support

[damian at sourceryinstitute dot org]

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

Bug 84894 Summary: [F2018] provide ISO_Fortran_binding.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84894

   What|Removed |Added

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

[Bug fortran/84894] [F2018] provide ISO_Fortran_binding.h

[damian at sourceryinstitute dot org]

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

Damian Rouson  changed:

   What|Removed |Added

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

--- Comment #8 from Damian Rouson  ---
I believe commit r267946 fixes this.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[damian at sourceryinstitute dot org]

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

--- Comment #6 from Damian Rouson  ---
Correction to the end of the first sentence of the final paragraph in Comment
5: "... not join them _until_ the end."

[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test

[dave.anglin at bell dot net]

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

--- Comment #25 from dave.anglin at bell dot net ---
On 2018-09-05 8:07 a.m., redi at gcc dot gnu.org wrote:
> Another option is to simply define _GLIBCXX_BROKEN_VSNPRINTF in
> config/os/hpux/os_defines.h and then force the use of vsprintf, which is 
> always
> called with a large enough buffer:
>
> diff --git a/libstdc++-v3/config/locale/generic/c_locale.h
> b/libstdc++-v3/config/locale/generic/c_locale.h
> index 0d208166063..3045931c840 100644
> --- a/libstdc++-v3/config/locale/generic/c_locale.h
> +++ b/libstdc++-v3/config/locale/generic/c_locale.h
> @@ -70,7 +70,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  __builtin_va_list __args;
>  __builtin_va_start(__args, __fmt);
>
> -#if _GLIBCXX_USE_C99_STDIO
> +#if _GLIBCXX_USE_C99_STDIO && !_GLIBCXX_HAVE_BROKEN_VSNPRINTF
>  const int __ret = __builtin_vsnprintf(__out, __size, __fmt, __args);
>  #else
>  const int __ret = __builtin_vsprintf(__out, __fmt, __args);
> diff --git a/libstdc++-v3/config/os/hpux/os_defines.h
> b/libstdc++-v3/config/os/hpux/os_defines.h
> index 1003477fe35..5a9c4faf75d 100644
> --- a/libstdc++-v3/config/os/hpux/os_defines.h
> +++ b/libstdc++-v3/config/os/hpux/os_defines.h
> @@ -109,4 +109,9 @@ typedef long int __padding_type;
>  #if defined (__hppa__)
>  #define _GLIBCXX_HAVE_BROKEN_STRTOLD 1
>  #endif
> +
> +// The vnsprintf function returns -1 when the buffer is too small.
> +// See PR libstdc++/68737.
> +#define _GLIBCXX_HAVE_BROKEN_VSNPRINTF 1
> +
>  #endif
> diff --git a/libstdc++-v3/include/bits/locale_facets.tcc
> b/libstdc++-v3/include/bits/locale_facets.tcc
> index 39da5766075..d5fa91e97d6 100644
> --- a/libstdc++-v3/include/bits/locale_facets.tcc
> +++ b/libstdc++-v3/include/bits/locale_facets.tcc
> @@ -992,7 +992,7 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL
> char __fbuf[16];
> __num_base::_S_format_float(__io, __fbuf, __mod);
>
> -#if _GLIBCXX_USE_C99_STDIO
> +#if _GLIBCXX_USE_C99_STDIO && !_GLIBCXX_HAVE_BROKEN_VSNPRINTF
> // Precision is always used except for hexfloat format.
> const bool __use_prec =
>   (__io.flags() & ios_base::floatfield) != ios_base::floatfield;
The above fix is okay for now.

Dave

[Bug libfortran/79540] [7/8/9 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #15 from John David Anglin  ---
print '(f2.1)',100.00
end

causes a stack overflow in memcpy:

(gdb) bt
Python Exception  Failed to load
/home/gnu/lib/python2.7/lib-dynload/itertools.sl:
#0  0xc01cf85c in memcpy () from /usr/lib/libc.2
#1  0xc1c0545c in ?? () from /home/gnu/gcc/gcc-7/lib/libgfortran.sl.4
#2  0x in ?? () from /usr/lib/libc.2

We seem to have a huge size argument (0xfffd).

Breakpoint 2, 0x7afce720 in memcpy () from /usr/lib/libc.2
(gdb) p/x $r26
$4 = 0x7eff0cfd
(gdb) p/x $r25
$5 = 0x7eff0e7a
(gdb) p/x $r24
$6 = 0xfffd
(gdb) bt
Python Exception  Failed to load
/home/gnu/lib/python2.7/lib-dynload/itertools.sl:
#0  0x7afce720 in memcpy () from /usr/lib/libc.2
#1  0x7ade245c in ?? () from /home/gnu/gcc/gcc-7/lib/libgfortran.sl.4
#2  0x7ade2f14 in ?? () from /home/gnu/gcc/gcc-7/lib/libgfortran.sl.4
#3  0x7ade42c4 in ?? () from /home/gnu/gcc/gcc-7/lib/libgfortran.sl.4
#4  0x7add8444 in ?? () from /home/gnu/gcc/gcc-7/lib/libgfortran.sl.4
#5  0x7add8af4 in ?? () from /home/gnu/gcc/gcc-7/lib/libgfortran.sl.4
#6  0x7add4adc in ?? () from /home/gnu/gcc/gcc-7/lib/libgfortran.sl.4
#7  0x7add4b38 in ?? () from /home/gnu/gcc/gcc-7/lib/libgfortran.sl.4

[Bug fortran/78557] [7/8/9 Regression] [OOP] ICE in trans-expr.c with -fcheck=mem

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jvdelisle at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #7 from Jerry DeLisle  ---
As far as I can tell, this no longer has a problem on 7, 8, and 9. So it got
fixed somewhere along the way. Closing

[Bug fortran/88076] Shared Memory implementation for Coarrays

[damian at sourceryinstitute dot org]

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

--- Comment #5 from Damian Rouson  ---
This is an exciting idea.  When I gave some thought to writing a shared-memory
alternative coarray ABI, it seemed to me that pthreads would be a better choice
than OpenMP.  Part of the problem is that I was considering writing the
implementation in Fortran, and OpenMP lacked support several modern Fortran
features, including several object-oriented programming features.  That of
course won't be an issue for you, however, assuming you're going to write the
implementation in C.  I was going to leverage "forthreads," an open-source
Fortran 20003 interface to pthreads.  One thing that I think would be a major
benefit of having a Fortran implementation of the library is that it greatly
expand the potential community of contributors to include more of the users of
the compiler.

Another important consideration is whether to use the current gfortran
descriptors as arguments in the library functions (as is currently used) or
instead to use the Fortran 2018 CFI descriptors for which Paul recently
committed support.  If you go with the current gfortran descriptors, then there
could be a lot of code to rewrite if gfortran later adopts the standard
descriptors internally.  Paul's recent commit adds functions that can translate
between the gfortran and standard descriptors. I have a volunteer who I'm
hoping will use the translation functions to develop a new, alternative coarray
ABI that accepts the standard descriptors.

On another note mentioned earlier in this PR, I believe it will be necessary to
fork all threads at the beginning of execution and not join them at the end. 
Section 5.3.5 of the Fortran 2018 standard states, "Following the creation of a
fixed number of images, execution begins on each image."  Assuming there is a
one-to-one correspondence between images and threads, I read that as implying
that a fixed number of threads have to be set up before any one thread can
execute.  (Possibly there could also be additional non-image threads that get
forked later also though.)  I recall seeing several interesting papers from
10-15 years ago on SPMD-style programming using threads (OpenMP) so a
literature search on this topic be useful to read.

[Bug libfortran/79540] [7/8/9 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #14 from dave.anglin at bell dot net ---
On 2019-01-26 7:25 a.m., dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540
>
> --- Comment #13 from Dominique d'Humieres  ---
>> print '(f1.0)',100.00  ! => len=1 *: no digits
>> print '(f2.0)',100.00  ! => len=0 : no digits
>> print '(f3.0)',100.00  ! => len=0 : no digits
>> print '(f1.1)',100.00  ! => len=1 *: no digits
>> print '(f3.1)',100.00  ! => len=0 : no digits
> On darwin I get
>
>  print '(f1.0)',100.00  ! => len=1 *: no digits
>  print '(f2.0)',100.00  ! => len=2 **: no digits
>  print '(f3.0)',100.00  ! => len=3 ***: no digits
>  print '(f1.1)',100.00  ! => len=1 *: no digits
>  print '(f2.1)',100.00  ! => len=2 **: no digits
>  print '(f3.1)',100.00  ! => len=3 ***: no digits
>
> What is the output of
>
> print '(f3.1)',100.00
> end
>
> ? If it not '***', it looks like a bug in your libraries?
>
It's '***'.

[Bug fortran/78518] [7/8/9 Regression] Warning format regression

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jvdelisle at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #6 from Jerry DeLisle  ---
I recommend this be closed as won't fix. You can even take it as invalid. The
marker is at te end of the argument list and the message specifies which
argument is the issue in that list. Not a significant regression.

[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753

[eager at eagercon dot com]

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

Michael Eager  changed:

   What|Removed |Added

 CC||eager at eagercon dot com

--- Comment #3 from Michael Eager  ---
MicroBlaze does not do speculative execution.  No action needed.

[Bug fortran/89079] "Invalid compiler error: Segmentation fault" in module with "equivalence" statement

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> The line it's stuck on seems to be:
> #0  0x0001004fcf20 in build_common_decl (is_init=false, 
> union_type=, com=0x60013e1f0) at 
> /usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-common.c:463
> 463   attributes = gfc_add_attributes_to_decl (com->head->attr, 
> NULL_TREE);

I don't see such a line in my gcc sources.

[Bug fortran/89079] "Invalid compiler error: Segmentation fault" in module with "equivalence" statement

[airplanemath at aol dot com]

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

--- Comment #4 from airplanemath  ---
The line that the cygwin-native compiler crashes on:
attributes = gfc_add_attributes_to_decl (com->head->attr, NULL_TREE);
is not present in the Mingw-w64 cross compiler.  
Side-by-side debugging sessions reveal control flow 
through the two versions of build_common_decl are almost 
identical up to that point, except the cygwin-native 
compiler executes a line like
TREE_PUBLIC (decl) = 1;
which is not present in the Mingw-w64 execution.  
I asked for clarification on why the attributes line was 
there on the cygwin list.

[Bug c/89082] New: Feature request: provide annotation for code that's unlikely to be executed

[Hi-Angel at yandex dot ru]

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

Bug ID: 89082
   Summary: Feature request: provide annotation for code that's
unlikely to be executed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Hi-Angel at yandex dot ru
  Target Milestone: ---

In most projects a definite pattern that's unlikely to be executed is a
PRINT_ERR macro which is basically a wrapper around fprintf() call. E.g.

if (some_error) {
PRINT_ERR("ERR");
// do cleanup
return;
}

It would be great if GCC provided an attribute or something to make a hint,
that whenever PRINT_ERR appears, whatever branch was prior to that is unlikely
to be taken.

--

This follows the original question here
https://gcc.gnu.org/ml/gcc-help/2019-01/msg00016.html TL;DR of the discussion
is that currently GCC provides α) __builtin_expect(), but it requires to be
inserted inside an if-condition; and β) `__attribute__((cold))` which requires
macro to be converted to a function, and even then it does something completely
different from being just a "branch hint" — instead it produces a very slow
code.

[Bug fortran/71066] [7/8/9 Regression] ICE in set_loop_bounds, at fortran/trans-array.c:4680

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #7)
> F2018:
> 
> C876
>  (R839) A variable whose designator appears as a data-stmt-object or a
> data-i-do-object shall not be a
> dummy argument, accessed by use or host association, in a named common block
> unless the DATA statement is
> in a block data program unit, in blank common, a function name, a function
> result name, an automatic data
> object, or an allocatable variable.
> 
> So, the first example violates a constraint, which should be diagnosed.
> 
> The second one appears to be OK.

The second one is invalid.

f2008:C565
A data-stmt-object or data-i-do-object shall not be a coindexed variable.

f2018:C873
A data-stmt-object or data-i-do-object shall not be a coindexed variable.

[Bug fortran/89079] "Invalid compiler error: Segmentation fault" in module with "equivalence" statement

[airplanemath at aol dot com]

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

airplanemath  changed:

   What|Removed |Added

  Known to work||7.3.0

--- Comment #3 from airplanemath  ---
The line it's stuck on seems to be:
#0  0x0001004fcf20 in build_common_decl (is_init=false,
union_type=, com=0x60013e1f0) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-common.c:463
463   attributes = gfc_add_attributes_to_decl (com->head->attr,
NULL_TREE);

Printing the value of "com->head" gives 0x0, which would cause the segfault.

Two frames up seems to be the last time com->head gets touched, in
"gfc_get_common_head", which is a macro expanding to "XCNEW (gfc_common_head)",
which is a macro expanding to "((gfc_common_head *) xcalloc (1, sizeof
(gfc_common_head)))".  xcalloc just allocates and zeros memory, so that's not
it.

The Mingw-w64 compiler does not hit this problem because it returns on line
423. There's enough optimization to make it tricky to narrow down farther.

Going back to the Cygwin compiler, I hit the error and check the conditions for
the exit used by the Mingw-w64 compiler:
---
(gdb) print is_init
$2 = false
(gdb) print decl
$3 = (tree) 0x6f00ab0
---
Since the condition is ((decl != NULL_TREE) && (!is_init || ...)), I think the
exit should have been taken here as well.

This suggests that the issue is not with the equivalence-in-module code.  I
downloaded the old 7.3.0 binaries and checked again, to find the problem does
not occur in that version.  I then installed the 7.4.0 binaries and found the
error still in place.  I will check for more help on the cygwin list.

[Bug fortran/57048] [7/8/9 Regression] Handling of C_PTR and C_FUNPTR leads to reject valid

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #11 from Thomas Koenig  ---
... and even passes regression-testing.

Well, let's see.

[Bug target/84923] [8 regression] gcc.dg/attr-weakref-1.c failed on aarch64

[vladimir.mezentsev at oracle dot com]

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

Vladimir Mezentsev  changed:

   What|Removed |Added

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

--- Comment #11 from Vladimir Mezentsev  
---
 The bug is fixed but the status was not updated.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

--- Comment #4 from Nicolas Koenig  ---
Created attachment 45536
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45536=edit
library

Here is the library. At the moment, it has an interprocess allocator and
handles the creation and reaping of images. It also has a very simple
synchroniziation function.

The library part still has to integrated with libgfortrans build system. I
would suggest to handle it the same way libcaf_single is handled at the moment
which is linked against if -fcoarray=native is specified. 

To compile the library at the moment, the Makefile has to edited to allow it to
find libgfortran.h and libgfortran's config.h. After that 'make' will build it.

[Bug target/89021] Implement mmintrin.h in SSE

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
Most of MMX instructions can be implemented with SSE/SSE2.  Thee are
couple tricky cases:

1. MMX maskmovq vs SSE2 maskmovdqu.  They aren't equivalent.  I have

(define_insn_and_split "sse2_maskmovq_"
  [(set (mem:V8QI (match_operand:P 0 "register_operand" "D"))
(unspec:V8QI [(match_operand:V8QI 1 "register_operand" "Yy")
  (match_operand:V8QI 2 "register_operand" "Yy")
  (mem:V8QI (match_dup 0))] 
 UNSPEC_MASKMOV))
   (set (match_operand:V2DI 3 "register_operand" "=Yy")
(unspec:V2DI [(match_operand:V2DI 4 "register_operand" "3")]
 UNSPEC_MASKMOV))]
  "TARGET_MMX_WITH_SSE"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  /* Copy the lower 64 bits of operand 2 to operand 3.  NB: Invalid
 memory access may happen when bits 64:127 at memory location are
 unmapped.  */
  rtx op3 = operands[3];
  rtx op2 = gen_rtx_REG (V2DImode, REGNO (operands[2]));
  rtx insn = gen_sse2_movq128 (op3, op2);
  emit_insn (insn);

  /* Generate SSE2 maskmovdqu with operand 3.  */
  rtx op1 = gen_rtx_REG (V16QImode, REGNO (operands[1]));
  op3 = gen_rtx_REG (V16QImode, REGNO (operands[3]));
  if (Pmode == SImode)
insn = gen_sse2_maskmovdqu_si (operands[0], op1, op3);
  else 
insn = gen_sse2_maskmovdqu_di (operands[0], op1, op3);
  emit_insn (insn);
  DONE;
}
  [(set_attr "type" "ssemov")
   (set_attr "znver1_decode" "vector")
   (set_attr "mode" "TI")])

2. MMX movntq vs SSE2 movntidi, which is only for 64-bit mode.  I have

(define_expand "sse_movntq"
  [(set (match_operand:DI 0 "memory_operand")
(unspec:DI [(match_operand:DI 1 "register_operand")]
   UNSPEC_MOVNTQ))]
  "TARGET_SSE || TARGET_3DNOW_A"
{
  if (TARGET_MMX_WITH_SSE)
{
  rtx insn = gen_sse2_movntidi (operands[0], operands[1]);
  emit_insn (insn);
  DONE;
}
})

3. MMX pshufb vs SSE pshufb.  I have

(define_expand "ssse3_pshufbv8qi3"
  [(set (match_operand:V8QI 0 "register_operand")
(unspec:V8QI [(match_operand:V8QI 1 "register_operand")
  (match_operand:V8QI 2 "nonimmediate_operand")]
 UNSPEC_PSHUFB))]
  "TARGET_SSSE3"
{
  if (TARGET_MMX_WITH_SSE)
{ 
  /* Emulate MMX version of pshufb with SSE version by masking
 out the bit 3 of the shuffle control byte.  */
  rtvec par = gen_rtvec (4, GEN_INT (0xf7f7f7f7),
 GEN_INT (0xf7f7f7f7),
 GEN_INT (0xf7f7f7f7),
 GEN_INT (0xf7f7f7f7));
  rtx vec_const = gen_rtx_CONST_VECTOR (V4SImode, par);
  vec_const = force_const_mem (V4SImode, vec_const);
  rtx op3 = gen_reg_rtx (V4SImode);
  rtx op4 = gen_reg_rtx (V4SImode);
  rtx insn = gen_rtx_SET (op4, vec_const);
  emit_insn (insn);
  rtx op2 = force_reg (V8QImode, operands[2]);
  insn = gen_ssse3_pshufbv8qi3_sse (operands[0], operands[1],
op2, op3, op4);
  emit_insn (insn);
  DONE;
}
})

and

(define_insn_and_split "ssse3_pshufbv8qi3_sse"
  [(set (match_operand:V8QI 0 "register_operand" "=Yx,Yy")
(unspec:V8QI [(match_operand:V8QI 1 "register_operand" "0,Yy")
  (match_operand:V8QI 2 "register_operand" "Yx,Yy")]
 UNSPEC_PSHUFB))
   (set (match_operand:V4SI 3 "register_operand" "=Yx,Yy")
(unspec:V4SI [(match_operand:V4SI 4 "register_operand" "3,3")]
 UNSPEC_PSHUFB))]
  "TARGET_SSSE3 && TARGET_MMX_WITH_SSE"
  "#"
  "&& reload_completed"
  [(const_int 0)]
{
  /* Mask out the bit 3 of the shuffle control byte.  */
  rtx op2 = gen_rtx_REG (V4SImode, REGNO (operands[2]));
  rtx op3 = operands[3];
  rtx insn = gen_andv4si3 (op3, op3, op2);
  emit_insn (insn);
  /* Generate SSE version of pshufb.  */
  rtx op0 = gen_rtx_REG (V16QImode, REGNO (operands[0]));
  rtx op1 = gen_rtx_REG (V16QImode, REGNO (operands[1]));
  op3 = gen_rtx_REG (V16QImode, REGNO (op3));
  insn = gen_ssse3_pshufbv16qi3 (op0, op1, op3);
  emit_insn (insn);
  DONE;
}
  [(set_attr "isa" "noavx,avx")
   (set_attr "type" "sselog1")
   (set_attr "mode" "TI,TI")])

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

--- Comment #3 from Nicolas Koenig  ---
Created attachment 45535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45535=edit
Proof-of-concept

As a little update, here is a proof-of-concept patch. It adds a new coarray
option -fcoarray=native and allows (together with the library I will attach in
the next post) the compilation and execution of the following very simple
coarray program:

$ cat test.f90
program main
  implicit none
  integer:: a[*]
  a[next_image()] = this_image()
  sync all
  print *, 'Hi from', a[this_image()], 'to', this_image()
contains
  function next_image()
integer:: next_image
next_image = mod(this_image() + 1, num_images())
  end function
end program
$ gfortran -fcoarray=native -Lpath/to/native/coarray/library test.f90
-lcoarraynative -lrt
$ GFORTRAN_NUM_IMAGES=4 ./a.out
 Hi from   2 to   3
 Hi from   4 to   1
 Hi from   1 to   2
 Hi from   0 to   4

P.S.: I got a bit sidetracked the last few months, so this all took a bit
longer than expected :D

[Bug fortran/70696] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #21 from Uroš Bizjak  ---
Test case fixed.

[Bug fortran/68887] [6 regression] gfortran.dg/coarray/event_[12].f90 -fcoarray=lib -O2 -lcaf_single -latomic fails

[ubizjak at gmail dot com]

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

Bug 70696 Summary: [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE 
coarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70696

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/70696] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray

[uros at gcc dot gnu.org]

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

--- Comment #20 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jan 27 20:53:30 2019
New Revision: 268327

URL: https://gcc.gnu.org/viewcvs?rev=268327=gcc=rev
Log:
PR fortran/70696
* gfortran.dg/coarray/event_3.f0: Add save attribue to x.


Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray/event_3.f08

[Bug fortran/70696] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray

[uros at gcc dot gnu.org]

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

--- Comment #19 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jan 27 20:48:51 2019
New Revision: 268326

URL: https://gcc.gnu.org/viewcvs?rev=268326=gcc=rev
Log:
PR fortran/70696
* gfortran.dg/coarray/event_3.f0: Add save attribue to x.


Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/coarray/event_3.f08

[Bug fortran/57048] [7/8/9 Regression] Handling of C_PTR and C_FUNPTR leads to reject valid

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
Here's something that appears to work.

Looks like a hack, swims like a hack, and quacks like a hack...

Index: interface.c
===
--- interface.c (Revision 268104)
+++ interface.c (Arbeitskopie)
@@ -692,6 +692,15 @@
   if (ts1->type == BT_VOID || ts2->type == BT_VOID)
 return true;

+  /* Special case for our C interop types.  There should be a better
+ way of doing this...  */
+
+  if (((ts1->type == BT_INTEGER && ts2->type == BT_DERIVED)
+   || (ts1->type == BT_DERIVED && ts2->type == BT_INTEGER))
+  && ts1->u.derived && ts2->u.derived
+  && ts1->u.derived == ts2->u.derived)
+return true;
+
   /* The _data component is not always present, therefore check for its
  presence before assuming, that its derived->attr is available.
  When the _data component is not present, then nevertheless the

[Bug fortran/70696] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray

[uros at gcc dot gnu.org]

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

--- Comment #18 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jan 27 20:44:36 2019
New Revision: 268325

URL: https://gcc.gnu.org/viewcvs?rev=268325=gcc=rev
Log:
PR fortran/70696
* gfortran.dg/coarray/event_3.f0: Add save attribue to x.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray/event_3.f08

[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
What still remains to be fixed is:

// PR c++/78244
// { dg-do compile { target c++11 } }

struct S { S(int); int d; };

template 
auto f1() -> decltype(S{2.0}, void()) { } // { dg-error "narrowing conversion"
}

template 
auto f2() -> decltype(S{2.0}, 1) { return 1; } // { dg-error "narrowing
conversion" }

template 
auto f3() -> decltype(void(), S{2.0}, 1) { return 1; } // { dg-error "narrowing
conversion" }

template 
auto f4() -> decltype((S{2.0}, 1)) { return 1; } // { dg-error "narrowing
conversion" }

[Bug c++/80916] [7/8/9 Regression] Spurious "declared 'static' but never defined" warning

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #10 from Jason Merrill  ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01512.html

[Bug c++/87075] [7/8 Regression] ICE when compiling the test suite of GLM 0.9.9.0

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #11 from Jason Merrill  ---
Fixed on 7/8 branches as well.

[Bug c++/86740] [8 Regression] ICE with hana and nested lambdas (likely a regression, tsubst_copy, at cp/pt.c:15325)

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Sun Jan 27 20:31:37 2019
New Revision: 268324

URL: https://gcc.gnu.org/viewcvs?rev=268324=gcc=rev
Log:
PR c++/86740, ICE with constexpr if and nested generic lambdas.

When we partially instantiate the constexpr if, we walk through its body to
see what it uses from the enclosing local_specializations.  That walk was
overlooking the use of 'count' in the captures of the innermost lambda,
because we weren't walking into the capture list.

* tree.c (cp_walk_subtrees): Handle LAMBDA_EXPR.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/constexpr-if25.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/tree.c

[Bug c++/87075] [7/8 Regression] ICE when compiling the test suite of GLM 0.9.9.0

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  ---
Author: jason
Date: Sun Jan 27 20:31:32 2019
New Revision: 268323

URL: https://gcc.gnu.org/viewcvs?rev=268323=gcc=rev
Log:
PR c++/87075 - ICE with constexpr array initialization.

My patch of 2016-08-26 to avoid calling a trivial default constructor
introduced TARGET_EXPRs initialized with void_node to express trivial
initialization.  But when this shows up in a VEC_INIT_EXPR, we weren't
prepared to handle it.  Fixed by handling it explicitly in
cxx_eval_vec_init_1.

* constexpr.c (cxx_eval_vec_init_1): Handle trivial initialization.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-array6.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/constexpr.c

[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #12 from Marek Polacek  ---
Should be fixed.

[Bug c++/78244] Narrowing conversion is accepted in a function template, but it should be rejected

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
Author: mpolacek
Date: Sun Jan 27 20:19:41 2019
New Revision: 268321

URL: https://gcc.gnu.org/viewcvs?rev=268321=gcc=rev
Log:
PR c++/88815 - narrowing conversion lost in decltype.
PR c++/78244 - narrowing conversion in template not detected.
* cp-tree.h (CONSTRUCTOR_IS_DEPENDENT): New.
* pt.c (instantiation_dependent_r): Consider a CONSTRUCTOR with
CONSTRUCTOR_IS_DEPENDENT instantiation-dependent.
* semantics.c (finish_compound_literal): When the compound literal
isn't instantiation-dependent and the type isn't type-dependent,
fall back to the normal processing.  Set CONSTRUCTOR_IS_DEPENDENT.

* g++.dg/cpp0x/Wnarrowing15.C: New test.
* g++.dg/cpp0x/Wnarrowing16.C: New test.
* g++.dg/cpp0x/constexpr-decltype3.C: New test.
* g++.dg/cpp1y/Wnarrowing1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing15.C
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing16.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-decltype3.C
trunk/gcc/testsuite/g++.dg/cpp1y/Wnarrowing1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Sun Jan 27 20:19:41 2019
New Revision: 268321

URL: https://gcc.gnu.org/viewcvs?rev=268321=gcc=rev
Log:
PR c++/88815 - narrowing conversion lost in decltype.
PR c++/78244 - narrowing conversion in template not detected.
* cp-tree.h (CONSTRUCTOR_IS_DEPENDENT): New.
* pt.c (instantiation_dependent_r): Consider a CONSTRUCTOR with
CONSTRUCTOR_IS_DEPENDENT instantiation-dependent.
* semantics.c (finish_compound_literal): When the compound literal
isn't instantiation-dependent and the type isn't type-dependent,
fall back to the normal processing.  Set CONSTRUCTOR_IS_DEPENDENT.

* g++.dg/cpp0x/Wnarrowing15.C: New test.
* g++.dg/cpp0x/Wnarrowing16.C: New test.
* g++.dg/cpp0x/constexpr-decltype3.C: New test.
* g++.dg/cpp1y/Wnarrowing1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing15.C
trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing16.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-decltype3.C
trunk/gcc/testsuite/g++.dg/cpp1y/Wnarrowing1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/80260] [7/8 Regression] ICE with polymorphic array section actual argument

[damian at sourceryinstitute dot org]

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

--- Comment #13 from Damian Rouson  ---
Thanks for the fix!

[Bug c++/89024] [7/8 Regression] ICE testing convertibility of incomplete enumeration types

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE  |[7/8 Regression] ICE
   |testing convertibility of   |testing convertibility of
   |incomplete enumeration  |incomplete enumeration
   |types   |types

--- Comment #8 from Marek Polacek  ---
Fixed on trunk so far.

[Bug fortran/71066] [7/8/9 Regression] ICE in set_loop_bounds, at fortran/trans-array.c:4680

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #7 from Thomas Koenig  ---
F2018:

C876
 (R839) A variable whose designator appears as a data-stmt-object or a
data-i-do-object shall not be a
dummy argument, accessed by use or host association, in a named common block
unless the DATA statement is
in a block data program unit, in blank common, a function name, a function
result name, an automatic data
object, or an allocatable variable.

So, the first example violates a constraint, which should be diagnosed.

The second one appears to be OK.

[Bug c++/89024] [7/8/9 Regression] ICE testing convertibility of incomplete enumeration types

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Author: mpolacek
Date: Sun Jan 27 19:54:29 2019
New Revision: 268320

URL: https://gcc.gnu.org/viewcvs?rev=268320=gcc=rev
Log:
PR c++/89024 - ICE with incomplete enum type.
* call.c (standard_conversion): When converting an
ARITHMETIC_TYPE_P to an incomplete type, return NULL.

* g++.dg/cpp0x/enum37.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/enum37.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/89020] close(status='DELETE') does not remove file

[jvdelisle at gcc dot gnu.org]

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

--- Comment #16 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Jan 27 19:42:34 2019
New Revision: 268319

URL: https://gcc.gnu.org/viewcvs?rev=268319=gcc=rev
Log:
2019-01-27  Jerry DeLisle  

PR libfortran/89020
* io/close.c (st_close): Simplify text of error message to not
presume a specific cause of failure to remove file.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/close.c

[Bug fortran/82077] [7/8/9 Regression] ICE on associating polymorphic array dummy with a type-guarded array section

[damian at sourceryinstitute dot org]

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

--- Comment #11 from Damian Rouson  ---
Thanks, Paul!

[Bug fortran/66089] [7/8/9 Regression] elemental dependency mishandling when derived types are involved

[tkoenig at gcc dot gnu.org]

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

--- Comment #25 from Thomas Koenig  ---
I've come to a bit of a different conclusion.

For

module x
implicit none
contains
  elemental subroutine foo(a,b)
  real, intent(inout) :: a  
  real, intent(in), optional :: b   
  if (present(b)) a = a + b 
  end subroutine foo
end module x

program main
  use x 
  real :: a(10) 
  a = 1.
  call foo(a)   
  print *,a 
end program main

we (I think correctly) generate

{
  if (b != 0B)
{
  *a = *a + *b;
}
  L.1:;
}

[Bug fortran/82077] [7/8/9 Regression] ICE on associating polymorphic array dummy with a type-guarded array section

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #10 from Paul Thomas  ---
Fixed on 7- thru' 9-branches.

Thanks for the report

Paul

[Bug fortran/80260] [7/8 Regression] ICE with polymorphic array section actual argument

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #12 from Paul Thomas  ---
Fixed on 7- thru' 9-branches.

Thanks for the report

Paul

[Bug fortran/56386] [F03] ICE with ASSOCIATE construct and an derived type array component

[pault at gcc dot gnu.org]

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

--- Comment #15 from Paul Thomas  ---
Author: pault
Date: Sun Jan 27 18:53:47 2019
New Revision: 268317

URL: https://gcc.gnu.org/viewcvs?rev=268317=gcc=rev
Log:
2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.
* trans-expr.c (gfc_find_and_cut_at_last_class_ref): base_expr
should be a copy of e and not the initialization expr.

2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_44.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/select_type_45.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/fortran/trans-expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/82077] [7/8/9 Regression] ICE on associating polymorphic array dummy with a type-guarded array section

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Sun Jan 27 18:53:47 2019
New Revision: 268317

URL: https://gcc.gnu.org/viewcvs?rev=268317=gcc=rev
Log:
2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.
* trans-expr.c (gfc_find_and_cut_at_last_class_ref): base_expr
should be a copy of e and not the initialization expr.

2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_44.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/select_type_45.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/fortran/trans-expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/77385] "Unclassifiable statement" from gfortran

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Sun Jan 27 18:53:47 2019
New Revision: 268317

URL: https://gcc.gnu.org/viewcvs?rev=268317=gcc=rev
Log:
2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.
* trans-expr.c (gfc_find_and_cut_at_last_class_ref): base_expr
should be a copy of e and not the initialization expr.

2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_44.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/select_type_45.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/fortran/trans-expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/58906] [OOP] SELECT TYPE with CLASS IS generates ICE

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Sun Jan 27 18:53:47 2019
New Revision: 268317

URL: https://gcc.gnu.org/viewcvs?rev=268317=gcc=rev
Log:
2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.
* trans-expr.c (gfc_find_and_cut_at_last_class_ref): base_expr
should be a copy of e and not the initialization expr.

2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_44.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/select_type_45.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/fortran/trans-expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/80260] [7/8 Regression] ICE with polymorphic array section actual argument

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas  ---
Author: pault
Date: Sun Jan 27 18:53:47 2019
New Revision: 268317

URL: https://gcc.gnu.org/viewcvs?rev=268317=gcc=rev
Log:
2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.
* trans-expr.c (gfc_find_and_cut_at_last_class_ref): base_expr
should be a copy of e and not the initialization expr.

2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/associate_44.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/select_type_45.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/resolve.c
branches/gcc-7-branch/gcc/fortran/trans-expr.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/89079] "Invalid compiler error: Segmentation fault" in module with "equivalence" statement

[airplanemath at aol dot com]

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

--- Comment #2 from airplanemath  ---
Running gfortran with "-wrapper gdb,--args" notes the segfault with:
---
Thread 1 "f951" received signal SIGSEGV, Segmentation fault.
0x0001004fcf20 in build_common_decl (is_init=false, union_type=, com=0x60013e1f0) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-common.c:463
463   attributes = gfc_add_attributes_to_decl (com->head->attr,
NULL_TREE);
---
Running "bt full" produces
---
#0  0x0001004fcf20 in build_common_decl (is_init=false,
union_type=, com=0x60013e1f0) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-common.c:463
attributes = 
decl = 0x6f00ab0
identifier = 0x6bd4a60
decl = 
identifier = 
size = 
attributes = 
field = 
#1  create_common (com=com@entry=0x60013e1f0, head=,
saw_equiv=saw_equiv@entry=true) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-common.c:672
s = 
next_s = 
union_type = 
field_link = 
field = 
field_init = 
rli = 
decl = 
is_init = 
is_saved = 
__FUNCTION__ = "create_common"
#2  0x0001004fd800 in finish_equivalences (ns=0x600128a00) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-common.c:1270
y = 
sym = 
c = 0x60013e1f0
align = 4
z = 0x60013d510
offset = 
dummy = true
z = 
y = 
sym = 
c = 
offset = 
align = 
dummy = 
#3  gfc_trans_common (ns=ns@entry=0x600128a00) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-common.c:1307
c = 
#4  0x00010050c3a0 in gfc_generate_module_vars (ns=ns@entry=0x600128a00) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans-decl.c:5287
__FUNCTION__ = "gfc_generate_module_vars"
#5  0x0001004e6adf in gfc_generate_module_code (ns=0x600128a00) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/trans.c:2176
n = 
entry = 0x6f49780
__FUNCTION__ = "gfc_generate_module_code"
#6  0x0001004982c2 in translate_all_program_units
(gfc_global_ns_list=) at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/parse.c:6062
errors = 0
errors = 
ns = 
#7  gfc_parse_file () at /usr/src/debug/gcc-7.4.0-1/gcc/fortran/parse.c:6275
seen_program = 
errors_before = 0
errors = 0
top = {state = COMP_NONE, sym = 0x0, do_variable = 0x0, construct =
0x0, head = 0x0, tail = 0x0, previous = 0x0, ext = {end_do_label = 0xcb94,
oacc_declare_clauses = 0xcb94}}
s = {state = COMP_MODULE, sym = 0x6001293b0, do_variable = 0x0,
construct = 0x0, head = 0x0, tail = 0x0, previous = 0xc7b0, ext =
{end_do_label = 0x0, oacc_declare_clauses = 0x0}}
st = 
prog_locus = {nextc = 0xca46, lb = 0xcb94}
next = 
#8  0x0001004df32b in gfc_be_parse_file () at
/usr/src/debug/gcc-7.4.0-1/gcc/fortran/f95-lang.c:204
No locals.
#9  0x0001008fd8ac in compile_file () at
/usr/src/debug/gcc-7.4.0-1/gcc/toplev.c:467
No locals.
#10 0x0001010e7b8d in do_compile () at
/usr/src/debug/gcc-7.4.0-1/gcc/toplev.c:2003
i = 1
#11 toplev::main (this=this@entry=0xca46, argc=,
argc@entry=17, argv=, argv@entry=0xcac0) at
/usr/src/debug/gcc-7.4.0-1/gcc/toplev.c:2138
__FUNCTION__ = "main"
#12 0x000101107545 in main (argc=17, argv=0xcac0) at
/usr/src/debug/gcc-7.4.0-1/gcc/main.c:39
toplev = {m_use_TV_TOTAL = true, m_init_signals = true}
---
I also ran "info locals", which printed:
toplev = {m_use_TV_TOTAL = true, m_init_signals = true}

What other information would help narrow this down? I've exhausted my current
knowledge of gcc and gdb.

[Bug target/89081] [x86] suboptimal code generated for condition expression returning negation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ra

--- Comment #1 from Andrew Pinski  ---
This seems like a register allocation issue.

[Bug fortran/88685] [8/9 regression] pointer class array argument indexing

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
It's mine - ***sigh***

Paul

[Bug fortran/88980] [9 regression] segfault on allocatable string member assignment

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #2 from Paul Thomas  ---
It seems to have been my fault and so I will take it. I am just dealing with
two other regressions and then I will turn to this one.

Thanks

Paul

[Bug fortran/80260] [7/8 Regression] ICE with polymorphic array section actual argument

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #8)
> > Can the bug be marked as resolved?
> 
> I still get an ICE with gcc 7 and 8. Any plan to do the back port (I can do
> it if it helps)?

Hi Dominique and Martin,

I am just in the process of doing the backports. I was distracted by the
ISO_Fortran_binding patch and have only just returned to my PRs. In fact, the
patch to trunk did not fix the select type problems on these branches. The
tweak in trans-expr.c did the job.

Cheers

Paul

[Bug fortran/82077] [7/8/9 Regression] ICE on associating polymorphic array dummy with a type-guarded array section

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
(In reply to Martin Liška from comment #6)
> Paul: Can you please update a Title and Known to work?

Hi Martin,

I had been anticipating backporting to 7- and 8-branches but got stuck in
another job.

Thanks for the reminder.

Paul

[Bug fortran/80260] [7/8 Regression] ICE with polymorphic array section actual argument

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Sun Jan 27 18:02:17 2019
New Revision: 268313

URL: https://gcc.gnu.org/viewcvs?rev=268313=gcc=rev
Log:
2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.
* trans-expr.c (gfc_find_and_cut_at_last_class_ref): base_expr
should be a copy of e and not the initialization expr.

2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/associate_44.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_45.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/fortran/trans-expr.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/56386] [F03] ICE with ASSOCIATE construct and an derived type array component

[pault at gcc dot gnu.org]

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

--- Comment #14 from Paul Thomas  ---
Author: pault
Date: Sun Jan 27 18:02:17 2019
New Revision: 268313

URL: https://gcc.gnu.org/viewcvs?rev=268313=gcc=rev
Log:
2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.
* trans-expr.c (gfc_find_and_cut_at_last_class_ref): base_expr
should be a copy of e and not the initialization expr.

2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/associate_44.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_45.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/fortran/trans-expr.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/58906] [OOP] SELECT TYPE with CLASS IS generates ICE

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Sun Jan 27 18:02:17 2019
New Revision: 268313

URL: https://gcc.gnu.org/viewcvs?rev=268313=gcc=rev
Log:
2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.
* trans-expr.c (gfc_find_and_cut_at_last_class_ref): base_expr
should be a copy of e and not the initialization expr.

2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/associate_44.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_45.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/fortran/trans-expr.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/82077] [7/8/9 Regression] ICE on associating polymorphic array dummy with a type-guarded array section

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Sun Jan 27 18:02:17 2019
New Revision: 268313

URL: https://gcc.gnu.org/viewcvs?rev=268313=gcc=rev
Log:
2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.
* trans-expr.c (gfc_find_and_cut_at_last_class_ref): base_expr
should be a copy of e and not the initialization expr.

2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/associate_44.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_45.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/fortran/trans-expr.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/77385] "Unclassifiable statement" from gfortran

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Sun Jan 27 18:02:17 2019
New Revision: 268313

URL: https://gcc.gnu.org/viewcvs?rev=268313=gcc=rev
Log:
2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
PR fortran/80260
PR fortran/82077
* resolve.c (resolve_variable): Fix up expressions with array
associate names, where the parser did not detect that this is
array and there was no array part_ref in the expression.
* trans-expr.c (gfc_find_and_cut_at_last_class_ref): base_expr
should be a copy of e and not the initialization expr.

2019-01-27  Paul Thomas  

Backport from trunk
PR fortran/56386
PR fortran/58906
PR fortran/77385
* gfortran.dg/associate_44.f90 : New test.

PR fortran/80260
* gfortran.dg/select_type_45.f90 : New test.

PR fortran/82077
* gfortran.dg/select_type_46.f90 : New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/associate_44.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_45.f90
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/select_type_46.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/resolve.c
branches/gcc-8-branch/gcc/fortran/trans-expr.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/88948] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r264148

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|9.0 |7.5

--- Comment #7 from Uroš Bizjak  ---
Fixed everywhere.

[Bug rtl-optimization/88948] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r264148

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jan 27 17:42:58 2019
New Revision: 268312

URL: https://gcc.gnu.org/viewcvs?rev=268312=gcc=rev
Log:
PR target/88948
* rtl.h (prepare_copy_insn): New prototype.
* gcse.c (prepare_copy_insn): New function, split out from
process_insert_insn.
(process_insert_insn): Use prepare_copy_insn.
* store-motion.c (replace_store_insn): Use prepare_copy_insn
instead of gen_move_insn.

testsuite/ChangeLog:

PR target/88948
* gcc.target/i386/pr88948.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr88948.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gcse.c
branches/gcc-7-branch/gcc/rtl.h
branches/gcc-7-branch/gcc/store-motion.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/88948] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r264148

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jan 27 17:36:30 2019
New Revision: 268311

URL: https://gcc.gnu.org/viewcvs?rev=268311=gcc=rev
Log:
PR target/88948
* rtl.h (prepare_copy_insn): New prototype.
* gcse.c (prepare_copy_insn): New function, split out from
process_insert_insn.
(process_insert_insn): Use prepare_copy_insn.
* store-motion.c (replace_store_insn): Use prepare_copy_insn
instead of gen_move_insn.

testsuite/ChangeLog:

PR target/88948
* gcc.target/i386/pr88948.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr88948.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/gcse.c
branches/gcc-8-branch/gcc/rtl.h
branches/gcc-8-branch/gcc/store-motion.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/89081] New: [x86] suboptimal code generated for condition expression returning negation

[wojciech_mula at poczta dot onet.pl]

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

Bug ID: 89081
   Summary: [x86] suboptimal code generated for condition
expression returning negation
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wojciech_mula at poczta dot onet.pl
  Target Milestone: ---

Let's consider this trivial function:

---clamp.c---
#include 

uint64_t clamp1(int64_t x) {
return (x < 0) ? -x : 0;
}
---eof---

$ gcc --version
gcc (GCC) 9.0.0 20190117 (experimental)

$ gcc -O3 -march=skylake clamp.c -c -S && cat clamp.s
clamp1:
movq%rdi, %rax
negq%rax
movl$0, %edx
testq   %rdi, %rdi
cmovns  %rdx, %rax
ret

This procedure can be way shorter, like this

clamp1:
xorq   %rax, %rax # res = 0
negq   %rdi   # -x, sets SF
cmovns %rdi, %rax
ret

One thing I observed recently when looking at assembly is that GCC
never modifies input registers %rdi or %rsi, always makes their
copies -- -thus the proposed shorter version is not possible.
However, clang modifies these registers, so seems the ABI allows this.

[Bug c++/89080] New: ICE with immediately invoked constexpr lambda

[chss95cs at gmail dot com]

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

Bug ID: 89080
   Summary: ICE with immediately invoked constexpr lambda
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chss95cs at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/1IOgpU

Flags were -fconcepts -std=gnu++2a

[Bug fortran/58906] [OOP] SELECT TYPE with CLASS IS generates ICE

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Fixed on trunk.

Thanks for the report.

Paul

[Bug middle-end/60832] add pretty-printer code for double-int/wide-int

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #3)
> (I wish someone would fix https://gcc.gnu.org/PR47781 so we can use a simpler
> syntax to define our custom specifiers; in addition to the positive synergies
> it will bring with other GNU projects that use custom specifiers and wish to
> use -Wformat).

Yeah me too...

[Bug other/82383] Some new toplevel directories are not documented

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> Confirmed, they should be listed here:
> https://gcc.gnu.org/onlinedocs/gccint/Top-Level.html#Top-Level
> but they're not.

That page is generated from sourcebuild.texi, for reference.

[Bug fortran/52884] double precision constants promoted to 16 byte by -fdefault-real-8

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Patch submitted at https://gcc.gnu.org/ml/fortran/2019-01/msg00251.html.

[Bug c/89045] [9 Regression] ICE in get_parm_info, at c/c-decl.c:7518

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

[Bug fortran/89079] "Invalid compiler error: Segmentation fault" in module with "equivalence" statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-01-27
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
WORKSFORME on darwin.

Can you debug the ICE?

[Bug c++/56665] -O2 with -fno-strict-aliasing makes boost::spirit::classic::assign_a not working

[nok.raven at gmail dot com]

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

Nikita Kniazev  changed:

   What|Removed |Added

 CC||nok.raven at gmail dot com

--- Comment #6 from Nikita Kniazev  ---
This is not a GCC bug. The examples above have use after scope bug.
Look at `assign_a` documentation
https://www.boost.org/doc/libs/1_69_0/libs/spirit/classic/doc/predefined_actors.html
it takes a value by reference (by const reference actually).

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[jakub at gcc dot gnu.org]

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

Bug 87214 Summary: [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 
2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87214

   What|Removed |Added

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

[Bug target/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #25 from Jakub Jelinek  ---
Fixed.  Will backport to release branches eventually though, as it is latent
there.

[Bug target/87214] [9 Regression] r263772 miscompiled 520.omnetpp_r in SPEC CPU 2017

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek  ---
Author: jakub
Date: Sun Jan 27 11:56:44 2019
New Revision: 268310

URL: https://gcc.gnu.org/viewcvs?rev=268310=gcc=rev
Log:
PR target/87214
* config/i386/sse.md
(avx512dq_shuf_64x2_1,
avx512f_shuf_64x2_1): Ensure the
first constants in pairs are multiples of 2.  Formatting fixes.
(avx512vl_shuf_32x4_1,
avx512vl_shuf_32x4_1): Ensure the
first constants in each quadruple are multiples of 4.  Formatting
fixes.

* gcc.target/i386/avx512vl-pr87214-1.c: New test.
* gcc.target/i386/avx512vl-pr87214-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr87214-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr87214-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/89079] New: "Invalid compiler error: Segmentation fault" in module with "equivalence" statement

[airplanemath at aol dot com]

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

Bug ID: 89079
   Summary: "Invalid compiler error: Segmentation fault" in module
with "equivalence" statement
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: airplanemath at aol dot com
  Target Milestone: ---

Created attachment 45534
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45534=edit
Fortran 90 file that produces an internal compiler error on cygwin

Compilation of the attached file on 64-bit cygwin (on 64-bit Windows 
10) produces only the .mod and .s files together with the first output 
below.  Compilation of the same file using the Mingw-w64 cross-compiler 
produces the .o file in addition to the .s and .mod files, together 
with the second output below.  How would I go about debugging this?
---
$ x86_64-pc-cygwin-gfortran -v -c test_compile.f90 -save-temps -fverbose-asm
-Wall -Wextra
Using built-in specs.
COLLECT_GCC=x86_64-pc-cygwin-gfortran
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-7.4.0-1.x86_64/src/gcc-7.4.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-7.4.0-1.x86_64/src/gcc-7.4.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp
--enable-libitm --enable-libquadmath --enable-libquadmath-support
--disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts
Thread model: posix
gcc version 7.4.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-save-temps' '-fverbose-asm' '-Wall' '-Wextra'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/f951.exe test_compile.f90 -quiet -dumpbase
test_compile.f90 -mtune=generic -march=x86-64 -auxbase test_compile -Wall
-Wextra -version -fverbose-asm -fintrinsic-modules-path
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/finclude -o test_compile.s
GNU Fortran (GCC) version 7.4.0 (x86_64-pc-cygwin)
compiled by GNU C version 7.4.0, GMP version 6.1.2, MPFR version
4.0.1-p11, MPC version 1.1.0, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 7.4.0 (x86_64-pc-cygwin)
compiled by GNU C version 7.4.0, GMP version 6.1.2, MPFR version
4.0.1-p11, MPC version 1.1.0, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
---
The output from the cross-compiler, which does run to completion, is 
included below:
---
$ x86_64-w64-mingw32-gfortran -v -c test_compile.f90 -save-temps -fverbose-asm
-Wall -Wextra
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gfortran
Target: x86_64-w64-mingw32
Configured with:
/cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/mingw64-x86_64-gcc-7.4.0-1.x86_64/src/gcc-7.4.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/mingw64-x86_64-gcc-7.4.0-1.x86_64/src/gcc-7.4.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/mingw64-x86_64-gcc
--htmldir=/usr/share/doc/mingw64-x86_64-gcc/html -C --build=x86_64-pc-cygwin
--host=x86_64-pc-cygwin --target=x86_64-w64-mingw32 --without-libiconv-prefix
--without-libintl-prefix --with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--with-build-sysroot=/usr/x86_64-w64-mingw32/sys-root --disable-multilib
--disable-win32-registry --enable-languages=c,c++,fortran,lto,objc,obj-c++
--enable-fully-dynamic-string --enable-graphite --enable-libgomp
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-version-specific-runtime-libs --enable-libgomp --enable-libada
--with-dwarf2 --with-gnu-ld --with-gnu-as --with-tune=generic
--with-cloog-include=/usr/include/cloog-isl --with-system-zlib
--enable-threads=posix --libexecdir=/usr/lib
Thread model: posix
gcc version 7.4.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-save-temps' '-fverbose-asm' '-Wall' '-Wextra'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-w64-mingw32/7.4.0/f951.exe test_compile.f90 

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-27
 Ever confirmed|0   |1

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

[dominiq at lps dot ens.fr]

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

Bug ID: 89078
   Summary: [meta-bug] Improve the gfortran manual
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

Motivated by my RFA posted at
https://gcc.gnu.org/ml/fortran/2019-01/msg00142.html.

[Bug fortran/89077] ICE using * as len specifier for character parameter

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-27
 Blocks||31237
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (9.0).

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x10)
frame #0: 0x00010001eb42
f951`::add_init_expr_to_sym(name=, initp=0x7ffeefbfeb60,
var_locus=) at decl.c:1924
   1921 }
   1922   else if (init->ts.u.cl && init->ts.u.cl->length)
   1923 sym->ts.u.cl->length =
-> 1924 gfc_copy_expr
(sym->value->ts.u.cl->length);
   1925 }
   1926 }
   1927   /* Update initializer character length according symbol.  */
(lldb) p sym->value
(gfc_expr *) $1 = 0x
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x10)
  * frame #0: 0x00010001eb42
f951`::add_init_expr_to_sym(name=, initp=0x7ffeefbfeb60,
var_locus=) at decl.c:1924
frame #1: 0x0001000280e6 f951`gfc_match_data_decl() at decl.c:2869
frame #2: 0x000100089096 f951`::decode_statement() at parse.c:65
frame #3: 0x000100089091 f951`::decode_statement()
frame #4: 0x00010008cfa0 f951`::next_statement() at parse.c:1241
frame #5: 0x00010008fa36 f951`::parse_spec(st=ST_DATA_DECL) at
parse.c:3865
frame #6: 0x000100092c10 f951`::parse_progunit(st=ST_NONE) at
parse.c:5680
frame #7: 0x00010009457d f951`gfc_parse_file() at parse.c:6220
frame #8: 0x0001000dd3ec f951`::gfc_be_parse_file() at f95-lang.c:204
frame #9: 0x000100cb0bda f951`::compile_file() at toplev.c:456
frame #10: 0x000101387064 f951`toplev::main(int, char**) at
toplev.c:2176
frame #11: 0x000101386f30 f951`toplev::main(this=0x7ffeefbff10e,
argc=, argv=)
frame #12: 0x0001013898d1 f951`main(argc=2, argv=0x7ffeefbff148) at
main.c:39


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31237
[Bug 31237] [meta-bug] TRANSFER intrinsic

[Bug fortran/89077] ICE using * as len specifier for character parameter

[rrodrigues at poli dot ufrj.br]

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

--- Comment #1 from Rodrigo Rodrigues  ---
Moreover, removing the parameter specifier also produces an ICE:

  character(len(str)) :: str2 = transfer([(str(i:i), i=1,len(str))], str)

> internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:148
> libbacktrace could not find executable to open

[Bug fortran/89077] New: ICE using * as len specifier for character parameter

[rrodrigues at poli dot ufrj.br]

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

Bug ID: 89077
   Summary: ICE using * as len specifier for character parameter
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rrodrigues at poli dot ufrj.br
  Target Milestone: ---

I am getting an Internal Compiler Error when I use assumed character length (*)
in a parameter declaration, when using character substring (apparently,
compiler fails to determine the character length and crashes).



program test
  implicit none
  integer :: i

  ! assumed character length works normally here
  character(*), parameter :: str = 'abcdef'

  ! also works, with intrinsic char inside transfer
  character(*), parameter :: str1 = transfer([(char(64+i), i=1,len(str))], str)

  ! crashes with ICE here, with character substring inside transfer
  character(*), parameter :: str2 = transfer([(str(i:i), i=1,len(str))], str)

  ! it works when the type is specified in array constructor
  character(*), parameter :: str3 = transfer([character :: (str(i:i),
i=1,len(str))], str)

  ! also works, without assumed character length
  character(len(str)), parameter :: str4 = transfer([(str(i:i), i=1,len(str))],
str)

  print *, str, len(str)   ! 'abcdef', 6
  print *, str1, len(str1) ! 'ABCDEF', 6
  ! print *, str2, len(str2)   ! should output 'abcdef', 6, but crashes
  print *, str3, len(str3) ! 'abcdef', 6
  print *, str4, len(str4) ! 'abcdef', 6
end