[Bug c/67919] GCC Compiler failed with "gcc-5.2.0/gcc/expr.c:6529:1: internal compiler error: output_operand: invalid shift operand"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67919 Xinus changed: What|Removed |Added Severity|normal |blocker
[Bug fortran/50069] FORALL fails on a character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069 zmi changed: What|Removed |Added CC||zmi007 at gmail dot com --- Comment #6 from zmi --- A am not sure if its the same bug, but I get ICE for the function !--- !Function !--- function reverse(string) ! bind(c, name='reverse') implicit none character(len=*), intent(in) :: string character(len=:),allocatable :: reverse reverse = string forall (i=1:len(reverse)) reverse(i:i) = reverse(len(reverse)-i+1:len(reverse)-i+1) end function reverse forall (i=1:len(reverse)) reverse(i:i) = reverse(len(reverse)-i+1:len(reverse)-i+1) 1 internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:2368 gfortran --version GNU Fortran (SUSE Linux) 5.2.1 20150721 [gcc-5-branch revision 226027]
[Bug c++/67888] Compiling clang 3.7.0 results in is used but never defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67888 Dimitry Andric changed: What|Removed |Added CC||dimitry at andric dot com, ||paolo.carlini at oracle dot com --- Comment #6 from Dimitry Andric --- This appears to have been fixed with https://gcc.gnu.org/viewcvs?rev=224492&root=gcc&view=rev by Paolo Carlini, see also bug 51048. It seems to look easy enough to backport to earlier branchs. Paolo, can you please confirm?
[Bug c++/67927] New: array new expression with excessive number of elements not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67927
Bug ID: 67927
Summary: array new expression with excessive number of elements
not diagnosed
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This is similar to bug 67913.
A new expression is considered erroneous if the value of the expression in its
noptr-new-declarator is such that the size of the allocated object would exceed
the implementation-defined limit (it's safe to assume that the limit doesn't
exceed the size of the address space). If the expression is a constant
expression, the program is ill-formed. The following program is not diagnosed
by GCC even though it contains two such ill-formed expressions.
void* operator new[] (unsigned long, void *p) { return p; }
void foo (void)
{
char c [1];
new int [__SIZE_MAX__];
new (c) int [__SHRT_MAX__][__SHRT_MAX__];
}
(Clang diagnoses the first but not the second, even though both expressions are
invalid; the second one for other reasons besides exceeding the
implementation-defined size limit.)
[Bug c++/33483] New warning suggestion (for -Wall): sizeof() with non-lvalue has side effects that will not execute at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33483
--- Comment #4 from Martin Sebor ---
It might makes sense to provide the functionality under the
-Wunevaluated-expression option for compatibility with clang:
$ cat u.c && clang -Wall -c u.c
int foo (int i)
{
int a [i];
return sizeof (a [i++]);
}
u.c:4:19: warning: expression with side effects has no effect in an unevaluated
context [-Wunevaluated-expression]
return sizeof (a [i++]);
^
1 warning generated.
[Bug c++/67926] New: Using folding expressions in a constexpr context ice's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67926 Bug ID: 67926 Summary: Using folding expressions in a constexpr context ice's Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc at magfr dot user.lysator.liu.se Target Milestone: --- Trying to compile the following results in an ICE. $ cat z1.ii template concept bool C = (T && ...); $ /usr/local/gcc-head/bin/g++ --version g++ (GCC) 6.0.0 20151010 (experimental) $ /usr/local/gcc-head/bin/g++ -std=c++1z -x c++ z1.ii z1.ii:1:49: sorry, unimplemented: unexpected AST of kind unary_right_fold_expr template concept bool C = (T && ...); ^ z1.ii:1:49: internal compiler error: in potential_constant_expression_1, at cp/constexpr.c:4629
[Bug target/67896] Inconsistent behaviour between C and C++ for types poly8x8_t and poly16x8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67896
--- Comment #1 from Roger Ferrer Ibanez ---
Hi,
after some debugging I think I understand what happens but I'm not sure I can
provide an acceptable fix for that.
When comparing __Poly8x8_t and __Poly16x8_t types (these are the builtin types
for poly8x8_t and poly16x8_t respectively) in the C++ FE, the sequence involves
"comptypes" and then "structural_comptypes".
Since both types are vectors, the number of elements is the same (i.e.
TYPE_VECTOR_SUBPARTS is 8 for the two vector types), so it only remains to
check the element type (i.e. the TREE_TYPE) of the vector (these are __Poly8_t
and __Poly16_t). At this point "structural_comptypes" sees that both types are
INTEGER_TYPE and then proceeds to compare them using TYPE_CANONICAL but at this
point for both types the canonical type is NULL, so the structural comparison
trivially succeeds.
Types __Poly8x8_t and __Poly16x8_t are initialized in
"aarch64_init_simd_builtin_types" in "gcc/config/aarch64/aarch64-builtins.c".
There is an array of structs, called aarch64_simd_types, with two fields, among
others, eltype (element type) and itype (internal type).
At some point the code initializes the several __PolyS_t (where S = {8, 16, 64,
128}) with a distinct type of integer type {QI, HI, DI, TI} (note that itype is
also initialized)
aarch64_simd_types[Poly8_t].eltype = aarch64_simd_types[Poly8_t].itype =
build_distinct_type_copy (unsigned_intQI_type_node);
aarch64_simd_types[Poly16_t].eltype = aarch64_simd_types[Poly16_t].itype =
build_distinct_type_copy (unsigned_intHI_type_node);
...
and a bit later it makes sure __PolySxN_t have their element type to their
respective __PolyS_t.
aarch64_simd_types[Poly8x8_t].eltype = aarch64_simd_types[Poly8_t].itype;
...
aarch64_simd_types[Poly16x8_t].eltype = aarch64_simd_types[Poly16_t].itype;
And it finally proceeds to build the vector types except if the itype is not
null. Only the nonvector __PolyS_t types have a non-null itype (it was assigned
above) so they are not set a vector type.
for (i = 0; i < nelts; i++)
{
tree eltype = aarch64_simd_types[i].eltype;
enum machine_mode mode = aarch64_simd_types[i].mode;
if (aarch64_simd_types[i].itype == NULL)
aarch64_simd_types[i].itype =
build_distinct_type_copy
(build_vector_type (eltype, GET_MODE_NUNITS (mode)));
tdecl = add_builtin_type (aarch64_simd_types[i].name,
aarch64_simd_types[i].itype);
TYPE_NAME (aarch64_simd_types[i].itype) = tdecl;
SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);
}
The last statement in the loop ensures that the type is compared using
structural equality. This effectively sets the canonical type to zero,
according to the macro in tree.h
#define SET_TYPE_STRUCTURAL_EQUALITY(NODE) (TYPE_CANONICAL (NODE) = NULL_TREE)
My knowledge of the internals of GCC is too limited at this point to state
whether setting structural equality for all these types is OK. I think, though,
that setting structural equality for the non-vector types (thus nullifying
their canonical type) may be wrong: it makes two __PolyS_N_t types (where N is
the same) identical at the eyes of the C++ FE.
The following crude patch seems to let the C++ FE distinguish the two types.
--- /home/roger/soft/gcc/src/gcc-5.2.0/gcc/config/aarch64/aarch64-builtins.c
2015-04-01 13:18:03.0 +0200
+++ config/aarch64/aarch64-builtins.c 2015-10-11 23:51:05.315828614 +0200
@@ -628,15 +628,20 @@
tree eltype = aarch64_simd_types[i].eltype;
enum machine_mode mode = aarch64_simd_types[i].mode;
+ bool is_vector = false;
if (aarch64_simd_types[i].itype == NULL)
- aarch64_simd_types[i].itype =
- build_distinct_type_copy
+ {
+ aarch64_simd_types[i].itype =
+ build_distinct_type_copy
(build_vector_type (eltype, GET_MODE_NUNITS (mode)));
+ is_vector = true;
+ }
tdecl = add_builtin_type (aarch64_simd_types[i].name,
aarch64_simd_types[i].itype);
TYPE_NAME (aarch64_simd_types[i].itype) = tdecl;
- SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);
+ if (is_vector)
+ SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);
}
#define AARCH64_BUILD_SIGNED_TYPE(mode) \
With this change, g++ is able to tell the two types apart.
$ cat test.cc
typedef __Poly8x8_t A;
typedef __Poly16x8_t A;
$ aarch64-linux-gnu-g++ -fsyntax-only test.cc -Wall
test.cc:2:22: error: conflicting declaration ‘typedef __vector(8) __Poly16_t A’
typedef __Poly16x8_t A;
^
test.cc:1:21: note: previous declaration as ‘typedef __vector(8) __Poly8_t A’
typedef __Poly8x8_t A;
Caveat: I debugged this problem in a cross-compiler without real hardware so I
do not know if this is OK or not.
Hope this helps.
Kind regards,
[Bug c++/67834] [5 Regression] Local references inside comdat groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67834 John David Anglin changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from John David Anglin --- The ELF specification says "To facilitate removing a group without leaving dangling references and with only minimal processing of the symbol table, the following rules are followed. References to the sections comprising a group from sections outside of the group must be made through symbol table entries with STB_GLOBAL or STB_WEAK binding and section index SHN_UNDEF." The label _ZN3uhd9transport3sphL19handle_overflow_nopEv is not globalized. Probably, TREE_PUBLIC is not being set or there needs to be an addition check added to assemble_start_function to globalize COMDAT functions. Jason, could you take a look?
[Bug middle-end/67912] [6 regression] ICE in gen_lowpart_common, at emit-rtl.c:1399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67912 Matthias Klose changed: What|Removed |Added Keywords||ice-on-valid-code Target|i386-pc-solaris2.* |i386-pc-solaris2.*, ||x86_64-linux-gnu, ||powerpc64le-linux-gnu CC||doko at gcc dot gnu.org Known to work||5.2.1 Known to fail||6.0 --- Comment #3 from Matthias Klose --- seen as well on x86_64-linux-gnu, powerpc64le-linux-gnu.
[Bug c/67925] docs lie about being unable to inline function call before definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67925 Mikhail Maltsev changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2015-10-11 CC||miyuki at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Mikhail Maltsev --- OMG. IIUC, this limitation was fixed in GCC 3.x (early 2000s): http://hubicka.blogspot.ru/2014/04/linktime-optimization-in-gcc-1-brief.html
[Bug c/67925] docs lie about being unable to inline function call before definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67925 --- Comment #1 from Arkadiusz Drabczyk --- BTW, the same incorrect wording is repeated in doc/extend.texi in GCC source tarball.
[Bug c/67925] New: docs lie about being unable to inline function call before definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67925
Bug ID: 67925
Summary: docs lie about being unable to inline function call
before definition
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: arkadiusz at drabczyk dot org
Target Milestone: ---
Here https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/Inline.html it says:
"Some calls cannot be integrated for various reasons (in particular, calls that
precede the function's definition cannot be integrated (...)).". However, since
several releases of GCC this in no longer true as shown in the example:
$ ./gcc --version
gcc (GCC) 6.0.0 20151004 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat bug.c
#include
#include
inline static void def(void);
int main(void)
{
def();
exit(0);
}
static void def(void)
{
puts("blah blah");
}
$ ./gcc bug.c -O2 -S
$ cat bug.s
.file "bug.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "blah blah"
.section.text.startup,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB21:
.cfi_startproc
movl$.LC0, %edi
subq$8, %rsp
.cfi_def_cfa_offset 16
callputs
xorl%edi, %edi
callexit
.cfi_endproc
.LFE21:
.size main, .-main
.ident "GCC: (GNU) 6.0.0 20151004 (experimental)"
.section.note.GNU-stack,"",@progbits
The same happens with -O1 and on older versions of GCC such as 4.9.2. I think
that this outdated piece of documentation should be removed.
[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 --- Comment #11 from Jack Howarth --- Changing... --- gcc-5.2.0.orig/boehm-gc/include/private/gcconfig.h 2013-12-21 15:42:39.0 -0500 +++ gcc-5.2.0/boehm-gc/include/private/gcconfig.h 2015-10-11 15:41:26.0 -0400 @@ -1041,10 +1041,10 @@ # define MACH_TYPE "I386" # if defined(__LP64__) || defined(_WIN64) # define CPP_WORDSZ 64 -# define ALIGNMENT 8 +# define ALIGNMENT 2 # else # define CPP_WORDSZ 32 -# define ALIGNMENT 4 +# define ALIGNMENT 2 /* Appears to hold for all "32 bit" compilers */ /* except Borland. The -a4 option fixes*/ /* Borland. */ @@ -2005,10 +2005,10 @@ # ifdef X86_64 # define MACH_TYPE "X86_64" # ifdef __ILP32__ -# define ALIGNMENT 4 +# define ALIGNMENT 2 # define CPP_WORDSZ 32 # else -# define ALIGNMENT 8 +# define ALIGNMENT 2 # define CPP_WORDSZ 64 # endif # ifndef HBLKSIZE suppress the failures in the boehm-gc test suite on darwin15's unwinder (as well as using ALIGNMENT 1). Note that ALIGNMENT 4 on 64-bit doesn't suppress the boehm-gc test suite failures.
[Bug c++/61362] g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 does not compile lambda with template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61362 --- Comment #5 from Ville Voutilainen --- Oh, some crash with -std=c++1z but not with the current default of -std=c++14.
[Bug c++/61362] g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 does not compile lambda with template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61362 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #4 from Ville Voutilainen --- None of the examples ICE on the current trunk I have on Linux-X64. Can anyone else verify whether the ICEs can still be triggered?
[Bug c++/58566] [c++11] ICE with invalid expression in lambda body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566 --- Comment #5 from Ville Voutilainen --- Ahem, make that https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01076.html
[Bug c++/58566] [c++11] ICE with invalid expression in lambda body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566 --- Comment #4 from Ville Voutilainen --- Patch available: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01075.html
[Bug tree-optimization/67921] "internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147" when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67921
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-10-11
CC||mpolacek at gcc dot gnu.org,
||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
typedef struct {
int fullband_channels;
int masking_curve_cb[][6];
} DCAEncContext;
void fn1(DCAEncContext *p1) {
int a;
for (; a < 2; a++)
for (; p1->fullband_channels;) {
int *b = p1->masking_curve_cb[a];
int c[66];
int j = 0;
for (; j < 56; j++)
fn2(b[j] - c[j]);
}
}
[Bug c++/58566] [c++11] ICE with invalid expression in lambda body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566 Ville Voutilainen changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-10-11 CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com Ever confirmed|0 |1 --- Comment #3 from Ville Voutilainen --- Looks like this should be fixed by changing from void_type_node to error_mark_node in lambda_return_type() when it diagnoses an incomplete type. I'll see whether that causes any regressions.
[Bug rtl-optimization/67814] cmp instruction register allocation error (x86)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67814 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-10-11 Ever confirmed|0 |1 --- Comment #3 from Uroš Bizjak --- I can't confirm this PR with current gcc-5 and gcc-6 development tree. Can you please try with latest gcc-5 release (gcc-5.2) ?
[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 --- Comment #10 from Jack Howarth --- FYI, the earliest upstream boehm-gc which builds and passes make check on 10.11 under the Apple clang 7.0 compiled system unwinder is gc-7.2alpha6.
[Bug gcov-profile/67924] New: Gcov statistics branches error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67924 Bug ID: 67924 Summary: Gcov statistics branches error Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: langjitianya886 at 126 dot com Target Milestone: --- Created attachment 36479 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36479&action=edit gcov statistics error When I use the gcc version is 5.2.0,the gcov statistics branches error. When I use the gcc version is 4.1.1,the gcov statistics functions error. Specific content please see attachment
[Bug middle-end/67912] [6 regression] ICE in gen_lowpart_common, at emit-rtl.c:1399
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67912 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Dominique d'Humieres --- > I think this bug affects all platforms, see the thread > https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01013.html. Right, I've since seen it on x86_64-darwin and sparc-solaris. Didn't expect something of this impact not being in bugzilla, though. Thanks. Rainer
[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 & v7 cpus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67366 Fredrik Hederstierna changed: What|Removed |Added CC||fredrik.hederstierna@securi ||tas-direct.com --- Comment #16 from Fredrik Hederstierna --- Could this fix also possibly improve: Bug 67507 - "Code size increase with -Os from GCC 4.8.x to GCC 4.9.x for ARM thumb1", which also seems related to alignment on ARM targets? Thanks, Fredrik
[Bug fortran/67779] Strange ordering with strings in extended object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67779 --- Comment #6 from Dominique d'Humieres --- The problem is not limited to strings. If I add the following lines array(1)%value = 2 array(9)%value = 10 write( string_array(1)%value, '(a,i0)' ) "String = ", 2 write( string_array(9)%value, '(a,i0)' ) "String = ", 10 the initial values are 2 'String = 2 ' 9 'String = 9 ' 8 'String = 8 ' 7 'String = 7 ' 6 'String = 6 ' 5 'String = 5 ' 4 'String = 4 ' 3 'String = 3 ' 10 'String = 10 ' 1 'String = 1 ' and the "sorted" ones are 2 1 3 4 5 6 7 8 10 9 String = 2 String = 1 String = 10 String = 3 String = 4 String = 5 String = 6 String = 7 String = 8 String = 9
[Bug rtl-optimization/67864] [6 Regression] CSiBE size regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67864 --- Comment #1 from Segher Boessenkool --- Author: segher Date: Sun Oct 11 09:03:09 2015 New Revision: 228692 URL: https://gcc.gnu.org/viewcvs?rev=228692&root=gcc&view=rev Log: bb-reorder: Improve the simple algorithm for -Os (PR67864) As the PR points out, the "simple" reorder algorithm makes bigger code than the STC algorithm did, for -Os, for x86. I now tested it for many different targets and it turns out to be worse everywhere. This simple patch tunes "simple" a bit; this makes it better than STC almost everywhere. The only exceptions (for the targets where I have results) are x86 and mn10300. For those targets it may be best to switch the default algorithm for -Os to STC. 2015-10-11 Segher Boessenkool PR rtl-optimization/67864 * gcc/bb-reorder (reorder_basic_blocks_simple): Prefer existing fallthrough edges for conditional jumps. Don't sort candidate edges if not optimizing for speed. Modified: trunk/gcc/ChangeLog trunk/gcc/bb-reorder.c
[Bug lto/67923] New: [6 Regression] ICEs in the gfortran test suite with -flto after r228680
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67923 Bug ID: 67923 Summary: [6 Regression] ICEs in the gfortran test suite with -flto after r228680 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: hubicka at gcc dot gnu.org, pault at gcc dot gnu.org, rguenth at gcc dot gnu.org Target Milestone: --- Compiling the following tests with -flto on top of the other options gives ICEs FAIL: gfortran.dg/allocatable_function_1.f90 -g -flto (internal compiler error) FAIL: gfortran.dg/forall_10.f90 -g -flto (internal compiler error) FAIL: gfortran.dg/pr56015.f90 -g -flto (internal compiler error) FAIL: gfortran.dg/transfer_simplify_2.f90 -g -flto (internal compiler error) FAIL: gfortran.dg/trim_optimize_3.f90 -g -flto (internal compiler error) FAIL: gfortran.dg/trim_optimize_7.f90 -g -flto (internal compiler error) for both -m32 and -m64. The test FAIL: gfortran.dg/pr46804.f90 -g -flto (internal compiler error) fails only with -m32. The ICEs are of the kind [Book15] f90/bug% gfc /opt/gcc/_clean/gcc/testsuite/gfortran.dg/pr56015.f90 -flto -Ofast -fno-inline /opt/gcc/_clean/gcc/testsuite/gfortran.dg/pr56015.f90: In function 'foo': /opt/gcc/_clean/gcc/testsuite/gfortran.dg/pr56015.f90:12:0: error: type mismatch in pointer plus expression subroutine foo (p) ^ complex double[10] * complex double[10] * restrict long int _85 = p_5(D) + 32; /opt/gcc/_clean/gcc/testsuite/gfortran.dg/pr56015.f90:12:0: internal compiler error: verify_gimple failed /opt/gcc/_clean/gcc/testsuite/gfortran.dg/pr56015.f90:12:0: internal compiler error: Abort trap: 6 gfc: internal compiler error: Abort trap: 6 (program lto1)
