[Bug c++/80967] ICE in tsubst_decomp_names, at cp/pt.c:15660

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Markus Trippelsdorf  ---
Please don't report bugs for ancient pre-release versions of gcc-7.

[Bug target/80968] New: [SPARC] Stack frame reference allowed in delay slot of return instruction.

[davem at gcc dot gnu.org]

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

Bug ID: 80968
   Summary: [SPARC] Stack frame reference allowed in delay slot of
return instruction.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: davem at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41467=edit
Distilled test case exhibiting return delay slot bug.

When alloca() is used, gcc can allow a reference to that memory
in the delay slot of a return instruction which deallocates that
stack frame.

This was seen in lib/libcrc32c.c:crc32c() in the Linux kernel.
If an interrupt arrives exactly at that delay slot load instruction
the value can be corrupted.

A distilled version of that code is attached.  When compiled
with "-m64 -O2" you will see something like:


sub %sp, %g1, %sp
add %sp, 2230, %i5
and %i5, -8, %i5
 ...
return  %i7+8
 lduw   [%o5+16], %o0

Seems like we need something like stack tie pattern like other
backends use to block code movement like this, and emit it right
before the epilogue sequence.

[Bug go/80964] cross-gotools are not executable on host system

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor  ---
Those programs are not supposed to be installed in bindir when not doing a
native build.  I'm not sure why that has gone wrong for you.  In your build
directory, in gotools/config.status, what are the values of NATIVE_FALSE and
NATIVE_TRUE?

In the current GCC configure and build system there is no reliable way to build
them for the host system.  They are Go programs, so they would require a
build-x-host Go compiler.

[Bug c++/80967] New: ICE in tsubst_decomp_names, at cp/pt.c:15660

[ryan.burn at gmail dot com]

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

Bug ID: 80967
   Summary: ICE in tsubst_decomp_names, at cp/pt.c:15660
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

Created attachment 41466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41466=edit
preprocessed code

Running with trunk:
g++ (GCC) 7.0.1 20170408 (experimental)
to reproduce run attached file with
g++ -std=c++1z -fconcepts bug.cpp

This is the full output:

/Users/rnickb/proj/satyr/linear_algebra/test/test_blas_lapack.cpp:17:24:  
required from ‘void test_product(const A&, const X&) [with A =
satyr::n_array; X =
satyr::n_array]’
/Users/rnickb/proj/satyr/linear_algebra/test/test_blas_lapack.cpp:56:20:  
required from here
/Users/rnickb/proj/satyr/linear_algebra/include/satyr/linear_algebra/matrix_accessor.h:19:10:
internal compiler error: in tsubst_decomp_names, at cp/pt.c:15660
 auto [s, t] = std::minmax(i, j);
  ^~

/Users/rnickb/proj/satyr/linear_algebra/include/satyr/linear_algebra/matrix_accessor.h:19:10:
internal compiler error: Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
MacBook-Pro-3:structbind rnickb$ ls
bug.cpp.bz2 main.cpp

[Bug bootstrap/80887] gnat bootstrap fails at s-regpat.o: raised STORAGE_ERROR : stack overflow or erroneous memory access

[glisse at gcc dot gnu.org]

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

--- Comment #10 from Marc Glisse  ---
Before FRE, we have the following. I marked with comments the SSA_NAMEs that
are value numbered as something other than themselves.

f ()
{
  unsigned int t2;
  unsigned int t1;
  int a;
  unsigned int u;
  int pos.0_1;
  int _2;
  int pos.1_3;
  unsigned int pos.2_4;
  int _5;
  unsigned int a.3_6;

   [0.00%]:
  pos.0_1 = pos;
  _2 = pos.0_1 + 1;
  pos = _2;
  pos.1_3 = pos; // _2
  pos.2_4 = (unsigned int) pos.1_3;
  u_9 = pos.2_4 + 4294967295;
  a_10 = pos; // _2
  _5 = a_10 + -1; // pos.0_1
  t1_11 = (unsigned int) _5; // u_9
  a.3_6 = (unsigned int) a_10; // pos.2_4
  t2_12 = a.3_6 + 4294967294; // ...
  return;
}

Trying to simplify the last statement:
a.3_6 is valueized to pos.2_4
simplifying pos.2_4 + 4294967294
sees (unsigned)(pos.0_1 + 1) + 4294967294
first produces tmp1 = (unsigned)pos.0_1
mprts_hook - vn_lookup_simplify_result --> replaced by u_9
computes constant 4294967295
trying to simplify u_9+4294967295
aka (pos.2_4 + 4294967295)+4294967295
computes constant 4294967294
simplifying pos.2_4 + 4294967294, but that's already what we are trying to
do a few steps up in the call stack.

I don't know where is the best place to break the recursion.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---
   Severity|blocker |major

--- Comment #33 from Eric Botcazou  ---
> I have wasted enough of my time with Ada. If its maintainers are unable to
> clean the mess caused by revision r247391, I could I?

Well, I only suggested to try the workaround, nothing more.

[Bug fortran/80965] [7/8 Regression] ICE with class argument and -O2 optimization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
The change occurred between revisions r241395 (2016-10-21, compiles) and
r241433 (2016-10-21, ICE), likely r241403 (pr69566).

[Bug fortran/80965] [7/8 Regression] ICE with class argument and -O2 optimization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||5.4.0, 6.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-06-03
 Ever confirmed|0   |1
Summary|ICE with class argument and |[7/8 Regression] ICE with
   |-O2 optimization|class argument and -O2
   ||optimization
   Target Milestone|--- |7.2
  Known to fail||7.1.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed for gcc-7 and trunk (8.0).

If the compiler is configured with --enable-checking=yes, I get

pr80965.f90:3:0:

 subroutine xyz(loc)

Error: mismatching comparison operand types
void (*) ()
integer(kind=4)
if (loc.2_2 == 177599) goto ; else goto ;
pr80965.f90:3:0: Error: mismatching comparison operand types
void (*) ()
integer(kind=4)
if (loc.3_3 == 64409183) goto ; else goto ;
pr80965.f90:3:0: internal compiler error: verify_gimple failed

pr80965.f90:3:0: internal compiler error: Abort trap: 6

without/with optimization.

[Bug target/80966] ICE with -fstack-limit-register and large frames

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-06-03
 CC||ebotcazou at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/80966] New: ICE with -fstack-limit-register and large frames

[segher at gcc dot gnu.org]

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

Bug ID: 80966
   Summary: ICE with -fstack-limit-register and large frames
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41465=edit
testcase (-O0 -fstack-limit-register=r14)

Eric Botcazou reports a bug with -fstack-limit-register with large frames.
Testcase attached (needs -O0 -fstack-limit-register=r14).

[Bug sanitizer/80963] UBSAN false positive with visibility=hidden

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> To fix this you need to have the visibility default attribute on the class
> Archive .

And not just on factory.

[Bug sanitizer/80963] UBSAN false positive with visibility=hidden

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think the error message is correct as the class has a linkage of hidden in
the shared library.

That is Archive in the shared library and in the main executable are considered
two different classes.

To fix this you need to have the visibility default attribute on the class
Archive .

[Bug fortran/80965] New: ICE with class argument and -O2 optimization

[david.sagan at gmail dot com]

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

Bug ID: 80965
   Summary: ICE with class argument and -O2 optimization
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.sagan at gmail dot com
  Target Milestone: ---

Consider the code:

module mode3_mod
contains
subroutine xyz(loc)
implicit none
class(*) :: loc
real X(6)
integer ix_use
select type (loc)
type is (integer)
  x = 0
type is (real)
  ix_use = 0
end select
end subroutine xyz
end module mode3_mod


Compiling with -O2 optimization gives an error:

Davids-Mac-mini:~/Bmad/test> gfortran -c -O2 mode3_mod.f90
mode3_mod.f90:24:0:
 end subroutine xyz
internal compiler error: in compare_values_warnv, at tree-vrp.c:1223
mode3_mod.f90:24:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)


I am running on a Mac (10.12.5) with gcc version:
  gcc (MacPorts gcc7 7-20170420_0) 7.0.1 20170420 (prerelease)

[Bug c++/80956] [7/8 Regression] ICE with abstract class vector

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-03
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|ICE with abstract class |[7/8 Regression] ICE with
   |vector  |abstract class vector
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r240889.

[Bug tree-optimization/79483] [7/8 Regression] [graphite] ICE: verify_ssa failed (error: definition in block 31 does not dominate use in block 28)

[dcb314 at hotmail dot com]

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

--- Comment #8 from David Binderman  ---
Reduced code:

a;
b() {
  int c, d;
  if (a)
d = b();
  return 1 + c + d;
}

Flag -O2 required.

[Bug tree-optimization/79483] [7/8 Regression] [graphite] ICE: verify_ssa failed (error: definition in block 31 does not dominate use in block 28)

[dcb314 at hotmail dot com]

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

--- Comment #7 from David Binderman  ---
Problem seems to be between gcc revision 248553 and 248835.
I'll have a go at reducing the demonstrator code.

[Bug tree-optimization/79483] [7/8 Regression] [graphite] ICE: verify_ssa failed (error: definition in block 31 does not dominate use in block 28)

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #6 from David Binderman  ---
I see this ice now, but in code that isn't anything to do with isl.

Be nice to be able to put this one to bed, because nothing has
happened on it for three months.

[Bug go/80964] New: cross-gotools are not executable on host system

[bernd.edlinger at hotmail dot de]

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

Bug ID: 80964
   Summary: cross-gotools are not executable on host system
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: bernd.edlinger at hotmail dot de
CC: cmang at google dot com
  Target Milestone: ---

I don't know if that is a bug or a feature,
but I use a build spec like this one:

../gcc-trunk/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64
--target=arm-linux-gnueabihf --enable-languages=all --with-arch=armv7-a
--with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard

Note: Recently "all" was changed to include go as well.

Everything builds cleanly, except that the executables
bin/arm-linux-gnueabihf-go and bin/arm-linux-gnueabihf-gofmt
are built for the target system and not for the host, as every other
program in the bin folder:

bin/arm-linux-gnueabihf-readelf -h bin/arm-linux-gnueabihf-go   
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class: ELF32
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  EXEC (Executable file)
  Machine:   ARM
  Version:   0x1
  Entry point address:   0x1a731
  Start of program headers:  52 (bytes into file)
  Start of section headers:  1534068 (bytes into file)
  Flags: 0x5000400, Version5 EABI, hard-float ABI
  Size of this header:   52 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 9
  Size of section headers:   40 (bytes)
  Number of section headers: 39
  Section header string table index: 38

bin/arm-linux-gnueabihf-readelf -h bin/arm-linux-gnueabihf-gofmt
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class: ELF32
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  EXEC (Executable file)
  Machine:   ARM
  Version:   0x1
  Entry point address:   0x147f1
  Start of program headers:  52 (bytes into file)
  Start of section headers:  185156 (bytes into file)
  Flags: 0x5000400, Version5 EABI, hard-float ABI
  Size of this header:   52 (bytes)
  Size of program headers:   32 (bytes)
  Number of program headers: 9
  Size of section headers:   40 (bytes)
  Number of section headers: 39
  Section header string table index: 38

bin/arm-linux-gnueabihf-readelf -h bin/arm-linux-gnueabihf-gccgo
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class: ELF64
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  EXEC (Executable file)
  Machine:   Advanced Micro Devices X86-64
  Version:   0x1
  Entry point address:   0x403e05
  Start of program headers:  64 (bytes into file)
  Start of section headers:  5842128 (bytes into file)
  Flags: 0x0
  Size of this header:   64 (bytes)
  Size of program headers:   56 (bytes)
  Number of program headers: 10
  Size of section headers:   64 (bytes)
  Number of section headers: 39
  Section header string table index: 38

[Bug sanitizer/80963] New: UBSAN false positive with visibility=hidden

[jengelh at inai dot de]

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

Bug ID: 80963
   Summary: UBSAN false positive with visibility=hidden
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jengelh at inai dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

$ cat lib.h
struct Archive {
virtual void foo() = 0;
};
__attribute__((visibility("default"))) Archive *factory();

$ cat libimpl.cpp
#include "lib.h"
struct ArchiveImpl : Archive { void foo(); };
void ArchiveImpl::foo() {}
Archive *factory() { return new ArchiveImpl; }

$ cat main.cpp 
#include "lib.h"
int main(void) {
factory()->foo();
}

$ make
g++ -fPIC -o libimpl.so -shared libimpl.cpp -fvisibility=hidden -Wall
-fsanitize=undefined -lubsan
g++ -o main main.cpp ./libimpl.so -fvisibility=hidden -Wall
-fsanitize=undefined -lubsan

$ ./main
main.cpp:3:16: runtime error: member call on address 0x00dcfc20 which does
not point to an object of type 'Archive'
0x00dcfc20: note: object is of type 'ArchiveImpl'
 00 00 00 00  88 ed 59 dc 84 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00
00 00 00  21 00 00 00
  ^~~
  vptr for 'ArchiveImpl'

The symbol table of main or libimpl.so do not appear to change when
removing/adding -fvisiblity=hidden (no added/removed symbols, just address
changes), so I wonder what exactly it is that UBSAN is trying to look up and
not finding.

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-7 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux
Thread model: posix
gcc version 7.1.1 20170530 [gcc-7-branch revision 248621] (SUSE Linux)

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Oh, I forgot: does anyone have an explanation why
i386-apple-darwin16.7.0 and i386-apple-darwin11.4.2 bootstraps *with*
Ada still work fine while their x86_64 counterparts fail?

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #29 from Dominique d'Humieres  ---
>> Did you try what I suggested in comment #16 as a stopgap measure? 
>> No GNAT developer builds the mainline compiler on Darwin regularly
>> so this may take a while to sort out otherwise.
>
> I have wasted enough of my time with Ada. If its maintainers are unable to
> clean the mess caused by revision r247391, I could I?
>
> Closing as WONTFIX. Please do not reopen this PS and don't CC me for any
> further change in Ada.

Then please keep the PR open, but set the `Ignore Bug Mail' flag so you
won't see any further mails.  The fact that you're no longer interested
doesn't make the bug go away.

When I tried the workaround, I got

/var/gcc/regression/trunk/10.7-gcc/build/./gcc/xgcc
-B/var/gcc/regression/trunk/10.7-gcc/build/./gcc/
-B/vol/gcc/x86_64-apple-darwin11.4.2/bin/
-B/vol/gcc/x86_64-apple-darwin11.4.2/lib/ -isystem
/vol/gcc/x86_64-apple-darwin11.4.2/include -isystem
/vol/gcc/x86_64-apple-darwin11.4.2/sys-include -c -g -O2 -fno-common -W -Wall
-gnatpg -nostdinc g-exptty.adb -o g-exptty.o
dyld: Symbol not found: __ZdaPvm
  Referenced from: /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1
  Expected in: /usr/lib/libstdc++.6.dylib
 in /var/gcc/regression/trunk/10.7-gcc/build/./gcc/gnat1
xgcc: internal compiler error: Trace/BPT trap: 5 (program gnat1)

Rainer

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

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

--- Comment #30 from Dominique d'Humieres  ---
s/I could I/how could I/

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #29 from Dominique d'Humieres  ---
> Did you try what I suggested in comment #16 as a stopgap measure? 
> No GNAT developer builds the mainline compiler on Darwin regularly
> so this may take a while to sort out otherwise.

I have wasted enough of my time with Ada. If its maintainers are unable to
clean the mess caused by revision r247391, I could I?

Closing as WONTFIX. Please do not reopen this PS and don't CC me for any
further change in Ada.

[Bug fortran/80945] Invalid code with allocatable character array in READ/WRITE statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
 Depends on||68241

--- Comment #5 from Dominique d'Humieres  ---
The code is correctly compiled if I replace

character(len=:), dimension(:),allocatable:: ca

with

character(len=N), dimension(:),allocatable:: ca

or

read (buffer, '(3A5)') ca(1:3)

with

read (buffer, '(3A5)') ca

It could be related to pr68241.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] [F03] Deferred-length character

[Bug middle-end/80960] [5/6/7/8 Regression] Huge memory use when compiling a very large test case

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
The second change in memory size occurred between revisions r201916 (1996MB)
and r202560 (6196Mb).

[Bug fortran/65542] [5 Regression] SPREAD intrinsic incorrectly accepted in initialization expressions with -std=f95

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #8 from Thomas Koenig  ---
The fix is not applicable for gcc 5.

Closing.

[Bug fortran/65542] [5/6 Regression] SPREAD intrinsic incorrectly accepted in initialization expressions with -std=f95

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Jun  3 11:26:38 2017
New Revision: 248855

URL: https://gcc.gnu.org/viewcvs?rev=248855=gcc=rev
Log:
2017-05-03  Thomas Koenig  

PR fortran/65542
Backport from trunk
* intrinsic.c (gfc_intrinsic_func_interface):  Return an error
for -std=f95 for disallowed transformational functions in
initialization expressions.

2017-05-03  Thomas Koenig  

PR fortran/65542
Backport from trunk
* gfortran.dg/spread_init_expr_2.f90:  New test case.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/spread_init_expr_2.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/intrinsic.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/80510] Optimize Power7/power8 Altivec load/stores

[sch...@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab  ---
FAIL: gcc.target/powerpc/pr80510-1.c (test for excess errors)
Excess errors:
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:132:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:133:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:134:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:135:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:136:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:137:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:138:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:139:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:141:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:142:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:143:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:144:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:145:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:146:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:147:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:148:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:149:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-1.c:150:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
FAIL: gcc.target/powerpc/pr80510-1.c scan-assembler \\mstxsdx\\M

FAIL: gcc.target/powerpc/pr80510-2.c (test for excess errors)
Excess errors:
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:132:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:133:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:134:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:135:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:136:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:137:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:138:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:139:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:141:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:142:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:143:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:144:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:145:29:
warning: left shift count >= width of type [-Wshift-count-overflow]
/daten/gcc/gcc-20170602/gcc/testsuite/gcc.target/powerpc/pr80510-2.c:146:29:
warning: left shift count >= width of type [-Wshift-count-overflow]

[Bug middle-end/80960] [5/6/7/8 Regression] Huge memory use when compiling a very large test case

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
Timings and memory use for various releases. They show a timing regression for
gcc-7 and trunk compared to gcc-6.

% time gfortran-4.8.5 pr80960_db.f90 -fdefault-integer-8 -O2 -ftime-report
...
 phase opt and generate  : 349.98 (100%) usr   5.90 (99%) sys 356.90 (100%)
wall 1986145 kB (100%) ggc
...
 combiner: 194.33 (55%) usr   3.10 (52%) sys 197.71 (55%) wall
1754287 kB (88%) ggc
...
 TOTAL : 350.37 5.93   357.33   
1995723 kB
% time gfortran-4.9.3 pr80960_db.f90 -fdefault-integer-8 -O2 -ftime-report
...
 phase opt and generate  : 264.34 (100%) usr   6.55 (99%) sys 272.05 (100%)
wall 6179333 kB (100%) ggc
...
 combiner: 204.75 (77%) usr   3.75 (57%) sys 209.44 (77%) wall
5948591 kB (96%) ggc
...
 TOTAL : 264.72 6.59   272.52   
6189174 kB
% time gfortran-5.4 pr80960_db.f90 -fdefault-integer-8 -O2 -ftime-report
...
 phase opt and generate  : 235.60 (100%) usr   3.54 (93%) sys 239.57 (100%)
wall 4455669 kB (100%) ggc
...
 combiner: 160.31 (68%) usr   1.40 (37%) sys 161.98 (67%) wall
1624073 kB (36%) ggc
...
 TOTAL : 236.00 3.79   240.26   
4465708 kB
% time gfortran-6.3 pr80960_db.f90 -fdefault-integer-8 -O2 -ftime-report
...
 phase opt and generate  : 138.71 (100%) usr   2.42 (92%) sys 141.23 (99%) wall
4493675 kB (100%) ggc
...
 combiner:  74.35 (53%) usr   1.11 (42%) sys  75.45 (53%) wall
2700700 kB (60%) ggc
...
 TOTAL : 139.16 2.64   141.97   
4503966 kB
% time gfortran-7.1 pr80960_db.f90 -fdefault-integer-8 -O2 -ftime-report
...
 phase opt and generate  : 233.01 (100%) usr   3.72 (90%) sys 237.31 (99%) wall
4498167 kB (100%) ggc
...
 combiner: 158.53 (68%) usr   1.97 (48%) sys 160.90 (67%) wall
2700700 kB (60%) ggc
...
 TOTAL : 233.47 4.13   238.51   
4508597 kB
% time gfortran-8.0 pr80960_db.f90 -fdefault-integer-8 -O2 -ftime-report
...
 phase opt and generate  : 235.01 (100%) usr   3.44 (93%) sys 238.88 (100%)
wall 4498191 kB (100%) ggc
...
 combiner: 159.18 (68%) usr   1.79 (48%) sys 161.19 (67%) wall
2700700 kB (60%) ggc
...
 TOTAL : 235.47 3.70   239.66   
4508355 kB

[Bug c++/68754] Explicitly defaulted constexpr assignment operator fails to compile

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|--- |5.4