[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 Paul Thomas changed: What|Removed |Added Assignee|pault at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #14 from Paul Thomas --- I am afraid that this is beyond my pay grade. Unassigning myself. Paul
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #13 from rsandifo at gcc dot gnu.org --- I think this is almost certainly a back-end bug, and the same one that caused PR83851
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at redhat dot com
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 --- Comment #12 from Christophe Lyon --- There are several differences, but I'm not fluent in fortran. In case of doubt, note that 'armeb' means arm target in big-endian mode.
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 --- Comment #11 from Christophe Lyon --- Created attachment 42330 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42330&action=edit tree dump for armeb This is the tree-dump-original for the testcase of comment #8. My compiler is configured with: --target=armeb-none-linux-gnueabihf --with-float=hard --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon-fp16
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 --- Comment #10 from Paul Thomas --- Created attachment 42254 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42254&action=edit tree dump for testcase of comment # 9 The output in comment #9 has left me totally perplexed. I cannot for the life of me understand why the lbounds that should be positive are wrong while everything else is OK. I have attached the tree dump (-fdump-tree-original). Could you compare it on your system, please? If they are the same, I would guess that we have uncovered some weird backend bug. If they are different, we have something to work on. Note that the computation of the lower and upper bounds is pretty similar in respect of what is extracted from the descriptor. Also, there is no sign of the new field 'span' being addressed at all in this testcase. Cordialement Paul
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 --- Comment #9 from Christophe Lyon --- I get: 1 2 1 0 -2 -3 -4 3 4 5 0 7 8 9
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 --- Comment #8 from Thomas Koenig --- Could you try the following program: program try_lf0030 call LF0030(10) end SUBROUTINE LF0030(nf10) INTEGER ILA1(7) INTEGER ILA2(7) LOGICAL LLA(:,:,:,:,:,:,:) INTEGER ICA(7) ALLOCATABLE LLA ALLOCATE (LLA(2:3, 4, 0:5, $ NF10:1, -2:7, -3:8, $ -4:9)) ILA1 = LBOUND(LLA) ILA2 = UBOUND(LLA) print *,ila1 print *,ila2 END SUBROUTINE and report its output? On the machines I have access to, the output is 2 1 0 1 -2 -3 -4 3 4 5 0 7 8 9
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 --- Comment #7 from Christophe Lyon --- Created attachment 4 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=4&action=edit execution traces
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 --- Comment #6 from Christophe Lyon --- Created attachment 42221 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42221&action=edit executable
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 --- Comment #5 from Christophe Lyon --- Created attachment 42220 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42220&action=edit object file
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 --- Comment #4 from Christophe Lyon --- Created attachment 42219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42219&action=edit assembly file Compiled with -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 --- Comment #3 from Christophe Lyon --- The logs are not very helpful here is what I can see in gfortran.log: Execution timeout is: 300 spawn [open ...]^M Program aborted. Backtrace: qemu: uncaught target signal 6 (Aborted) - core dumped I am attaching the executable file I have produced, as well as the execution traces generated by qemu-armeb -d in_asm.
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- I had better take it since I am the guilty party but I must echo Thomas's request for more information. Cheers Paul
[Bug fortran/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-09-21 CC||pault at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- Can you supply any more details, such as any error messages? It's hard to debug otherwise if the developers do not have access to the hardware.
