[Bug libgomp/103976] New: Very large overhead for if(false) openmp pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103976
Bug ID: 103976
Summary: Very large overhead for if(false) openmp pragmas
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: nickpapior at gmail dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
In OpenMP it may be beneficial to not use OpenMP in a region given that the
calculated workload is very small.
Something like this:
test.c:
#include
int main(int narg, char args[]) {
float sum = 0.;
int i, j;
for ( i = 1 ; i<=1 ; i++) {
#ifdef _OPENMP
#pragma omp parallel for private(j) reduction(+:sum) if(0)
#else
// Just to have something that resembles the omp-if
if ( sum >= -1. ) {
#endif
for (j = 1 ; j<= 10 ; j++)
sum += 1./j;
#ifndef _OPENMP
}
#endif
}
printf("%15.7e\n", sum);
}
Never mind the faulty results, the idea is the culprit here.
I get the following timings:
gcc -O3 -o a.out test.c && time ./a.out
./a.out 1.60s user 0.00s system 99% cpu 1.604 total
gcc -O3 -o a.out test.c -fopenmp && time ./a.out
./a.out 9.13s user 4.62s system 99% cpu 13.743 total
Fortran has the same behaviour.
test.F90:
program main
real :: sum
integer :: i, j
sum = 0.
do i = 1, 1
#ifdef _OPENMP
!$OMP parallel do private(j) reduction(+:sum) if(.false.)
#else
! Just to have something that resembles the omp-if
if ( sum >= -1. ) then
#endif
do j = 1, 10
sum = sum + 1./j
end do
#ifdef _OPENMP
!$OMP end parallel do
#else
end if
#endif
end do
print *, sum
end program main
The complexity of adding the explicit if's was to emulate an if statement as
inserted in the openmp code. I know that openmp has lots more boiler plate
code, but this still seems awfully slow for me.
This came up in a sparse matrix solution library (MUMPS) which uses the #pragma
omp ... if(workload_huge) to decide on paths.
Let me know if anything else is necessary.
[Bug fortran/99765] Explicit dimension size declaration of pointer array allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99765 --- Comment #4 from Nick --- I see. I can't seem to find the mentioned line in f2003. I don't know if anything needs to be done. If the programmer expected something different than the last dimension specifier, they would very quickly figure out that it doesn't work as intended. In any case, I would be fine if this is marked as invalid and you left it as it is since f2008 denotes this as valid code. By the way real, dimension(10), allocatable :: a(10) is currently still recognized as an error (as I also mentioned). So basically everything is fine. Sorry for the blurp.
[Bug fortran/99765] Explicit dimension size declaration of pointer array allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99765 --- Comment #2 from Nick --- Thanks for finding that in the standard!
[Bug fortran/99761] Warn flag for non-kind specified mixing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99761 --- Comment #2 from Nick --- Amazing, years of using gfortran and you still find useful flags! Thanks!
[Bug fortran/99765] New: Explicit dimension size declaration of pointer array allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99765 Bug ID: 99765 Summary: Explicit dimension size declaration of pointer array allowed Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nickpapior at gmail dot com Target Milestone: --- A mishandling of variable declarations Consider this program: program test real, dimension(10), pointer :: a(:) => null() print *, associated(a) allocate(a(2)) print *, size(a) !print *, size(a(1)) ! obviously fails as a(1) is a scalar end program test It is ambiguous to determine the size of a. The programmer may think that after allocation one has 2x10 elements a(1:2)(1:10) however what is happening is that the dimension(10) attribute is completely ignored. I can't find anywhere in the standard mentioning that this way of definition is wrong, but I think it clearly shouldn't be allowed. I.e. it is unclear whether the user wants a(1:2)(1:10) or a(1:10)(1:2), in any case neither of the results are achieved. I found this bug in 4.8.4 and also in 9.3.0, so I assume it exists in all in between. A few more cases that resemble this: real, dimension(10), allocatable :: a(:) behaves exactly like with pointers. It is not well-defined and gets to the a(1:2) case. real, dimension(10), allocatable :: a(10) rightfully errors out on compilation with a somewhat unclear error message 3 | real, dimension(10) :: a(10) | 1 Error: Symbol ‘a’ at (1) already has basic type of REAL
[Bug fortran/99761] New: Warn flag for non-kind specified mixing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99761 Bug ID: 99761 Summary: Warn flag for non-kind specified mixing Product: gcc Version: fortran-dev Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nickpapior at gmail dot com Target Milestone: --- Some context here: https://github.com/j3-fortran/fortran_proposals/issues/201 The basic message is that users may forget to add kind specifications for constants which are assigned to higher precision values which then loses the extra bits. Simplest example: real(8), parameter :: pi = 3.14159265358979323846 which actually only stores the floating point value and store that in a double precision variable, thereby loosing precision. My proposal would be to add a flag which warns about misused kinds: program test real(8), parameter :: const = 1.4435435345345 real(8), parameter :: const2 = 1./3. real(8), parameter :: const3 = 1._4/4._4 print *, 1./3. * const end program test it would be nice if the above could be compiled with gfortran -Wpedantic-kind and something like this would be issued: 2 |real(8), parameter :: const = 1.4435435345345 1 Warning: Constant expression at (1) is in lower precision than variable. 3 |real(8), parameter :: const2 = 1./3. 1 Warning: Constant expression at (1) is in lower precision than variable. 3 |real(8), parameter :: const2 = 1./3. 1 Warning: Constant expression at (1) is in lower precision than variable. 5 |print *, 1./3. * const 1 2 Warning: Constant at (1) has lower precision than variable at (2) Line 4 is silently ignored due to explicit kind specification. I think such an enhancement would be extremely useful to hunt down mis-typed kind specifiers.
[Bug fortran/99355] -freal-X-real-Y -freal-Z-real-X promotes Z to Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355 --- Comment #5 from Nick --- Thanks for the swift action! And lots of tests ;)
[Bug fortran/99355] -freal-X-real-Y -freal-Z-real-X promotes Z to Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355 --- Comment #3 from Nick --- Yes, real*4 -> real*16. I agree that the option semantics are not clear. However, the documentation says: Promote all REAL(KIND=M) entities to REAL(KIND=N) entities. If REAL(KIND=N) is unavailable, then an error will be issued. All other real kind types are unaffected by this option. These options should be used with care and may not be suitable for your codes. Areas of possible concern include calls to external procedures, alignment in EQUIVALENCE and/or COMMON, generic interfaces, BOZ literal constant conversion, and I/O. Inspection of the intermediate representation of the translated Fortran code, produced by -fdump-tree-original, is suggested. >From this I read that no *double* promotions are done. However, the text isn't clear either. I would just not assume that *everything* gets promoted, especially since there is a -freal-4-real-16 option, so users can already be explicit. I guess this also applies to the -finteger-4-integer-8 and friends (untested)
[Bug fortran/99355] -freal-X-real-Y -freal-Z-real-X promotes Z to Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355 --- Comment #1 from Nick --- Oh, sorry about gcc-version. I checked this for all these gcc, same for all: 4.8.5 4.9.4 5.4.0 6.5.0 7.5.0 8.4.0 9.2.0
[Bug fortran/99355] New: -freal-X-real-Y -freal-Z-real-X promotes Z to Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355 Bug ID: 99355 Summary: -freal-X-real-Y -freal-Z-real-X promotes Z to Y Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nickpapior at gmail dot com Target Milestone: --- Created attachment 50291 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50291&action=edit Same as code snippet I came about this in LAPACK which allows compiling in quad precision. However, mixed precision algorithms will no longer be mixed precision since *everything* gets promoted. See this code snippet (and attached as well): program test real :: r1 real*4:: r2 real(4) :: r3 real(selected_real_kind(p=6)) :: r4 double precision :: d1 real*8 :: d2 real(8) :: d3 real(kind(1.d0)) :: d4 real(selected_real_kind(p=15)) :: d5 print '(tr3,a10,10(tr1,i2))', 'single', kind(r1), kind(r2), kind(r3), kind(r4) print '(tr3,a10,10(tr1,i2))', 'double', kind(d1), kind(d2), kind(d3), kind(d4), kind(d5) end program test Here listed with 4 different flag combinations: #FLAGS = single 4 4 4 4 double 8 8 8 8 8 #FLAGS = -freal-4-real-8 single 8 8 8 8 double 8 8 8 8 8 #FLAGS = -freal-8-real-16 single 4 4 4 4 double 16 16 16 16 16 #FLAGS = -freal-8-real-16 -freal-4-real-8 (order doesn't matter) single 8 16 16 16 double 16 16 16 16 16 The first 3 flag combinations works as intended. The last one behaves bad. I would have expected 8->16 and 4->8 (without double promotion).
[Bug fortran/48655] "False positive" with -Warray-temporaries or missing warning with -fcheck=array-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48655 Nick changed: What|Removed |Added CC||nickpapior at gmail dot com --- Comment #9 from Nick --- I really think this needs fixing. A user (me) is unaware of the implications and differences between -Warray-temporaries and -fcheck=array-temps. E.g. from this discussion it seems that -Warray-temporaries only pin-points where there _could_ be problems of creating temporaries. -fcheck=array-temps will reveal true temporary copies created. However, I have found that our code (+100.000 LOC) can greatly benefit closing -Warray-temporaries even if -fcheck=array-temps did not show any temporaries created. Why is this? So some follow up questions to clarify the flags: 1) Is there any compiled code difference in places where -Warray-temporaries show up, e.g. can we assume that IFF -Warray-temporaries gives a warning it is equivalent to the compiler inserting something like: if (is_contiguous(A) ) then call with no temp else temp = A(...) call with_temp deallocate(temp) end if ? And if not, then there is nothing to worry about? 2) Can we be sure that -fcheck=array-temps actually shows all true positives related to temporary array creation? What I would really like is the following changes to the documentation: -Warray-temporaries: Warn about possible array temporaries generated by the compiler. The information generated by this warning is sometimes useful in optimization, in order to avoid such temporaries. If this warning is issued it is equivalent to extra code checking for contiguous arrays before determining whether a temporary is created. To assert a temporary array was created, use -fcheck=array-temps. If extra code is not generated when a warning is issued then the 2nd last line should be omitted. Additionally the Warning message should be clarified, currently it looks like: Warning: Creating array temporary at (1) [-Warray-temporaries] However, I think it should look like this: Warning: Creating array temporary at (1) if non-contiguous [-Warray-temporaries] Thanks!
[Bug fortran/91496] !GCC$ directives error if mistyped or unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91496 --- Comment #4 from Nick --- Great! This is much appreciated!
[Bug fortran/91496] !GCC$ directives error if mistyped or unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91496 Nick changed: What|Removed |Added Version|4.7.2 |7.4.0 --- Comment #1 from Nick --- I have bumped version from 4 to 7, to make it *newer*.
[Bug fortran/91496] New: !GCC$ directives error if mistyped or unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91496 Bug ID: 91496 Summary: !GCC$ directives error if mistyped or unknown Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nickpapior at gmail dot com Target Milestone: --- In fortran codes I would like to use directives such as: !GCC$ unroll <> When trying to compile a fortran source code with the above directive it fails with: Error: Unclassifiable GCC directive at (1) A small test code: program test integer :: i real :: a(3) !GCC$ unroll 3 do i = 1, 3 a(i) = 2. end do print *, sum(a) end program Tested versions: Failed: 4.7.2 Failed: 4.8.3 Failed: 4.8.4 Failed: 4.8.5 Failed: 4.9.1 Failed: 4.9.2 Failed: 5.1.0 Failed: 5.2.0 Failed: 5.3.0 Failed: 5.4.0 Failed: 6.1.0 Failed: 6.2.0 Failed: 6.3.0 Failed: 6.4.0 Failed: 6.5.0 Failed: 7.1.0 Failed: 7.2.0 Failed: 7.3.0 Failed: 7.4.0 Success: 8.1.0 Success: 8.2.0 Success: 8.3.0 I would recommend that using non-existing or mis-typed directives should *never* issues errors, but rather warnings. The reasoning is that if new directives are added the source would need pre-processor statements to determine the used gfortran version in order to decide on the acceptance of each directive. This becomes cumbersome and unnecessary.
[Bug tree-optimization/82133] [7/8 Regression] unroll-loops too aggressive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82133 --- Comment #4 from Nick --- It seems that this is simply a bug in the assembly code in OpenBLAS. I have attached the recent post that suggests this inconsistency: https://github.com/xianyi/OpenBLAS/issues/1292#issuecomment-354366612 I have not marked it as resolved because, I guess you would like to decide what you want to do. I.e. 6.3 still works, but 7. does not, so should it be back-ported or not. Thanks! And sorry for the blurp.
[Bug tree-optimization/82133] [7/8 Regression] unroll-loops too aggressive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82133 --- Comment #3 from Nick --- According to https://github.com/xianyi/OpenBLAS/issues/1292#issuecomment-327788223, it is in the kernel/x86_64/dgemv_n_microk_haswell-4.c source where the loop-unrolling has caused the parent function call which is kernel/x86_64/dgemv_n_4.c. I.e. the unrolling is too aggressive in dgemv_n_4.c. However, I am no expert in the OpenBLAS source code to be able to extract the relevant sources and make a functioning C-program to try and reproduce it. All I can see is that the use of the loop counter in dgemv_n_4.c is a relatively complex method. And yes, OpenBLAS works fine without any of the mentioned flags (it also works for much more aggressive optimizations, but just not with the -funroll-loops -fipa-ra flags.
[Bug c/82133] unroll-loops too aggressive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82133 Nick changed: What|Removed |Added Known to work||6.3.0 --- Comment #1 from Nick --- I completely forgot to say that there were no problems using GCC-6.3.0 compiler on the Debian stretch box.
[Bug c/82133] New: unroll-loops too aggressive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82133
Bug ID: 82133
Summary: unroll-loops too aggressive
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nickpapior at gmail dot com
Target Milestone: ---
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/generic/gcc/7.2.0/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix /opt/generic/gcc/7.2.0
--with-gmp=/opt/generic/gcc/7.2.0 --with-mpfr=/opt/generic/gcc/7.2.0
--with-mpc=/opt/generic/gcc/7.2.0 --with-isl=/opt/generic/gcc/7.2.0
--enable-lto --enable-threads --with-quad --with-multilib-list=m64
--enable-languages=c,c++,fortran,objc,obj-c++,go
Thread model: posix
gcc version 7.2.0 (GCC)
The following bug has been confirmed by other parts and runned using these
variants:
- SuSE tumbleweed with system GCC 7.1.1, Atom core
- Debian stretch with custom 7.1.0 and 7.2.0 builds (according to flags
above), Haswell core
- Another distribution (see martin-frbg user in below link).
As several 7.X versions are found; assigned 7.0.
When using unroll-loops to compile OpenBLAS (0.2.20 and developer) it produces
seg-faults when running the tests.
It happens at these minimum compilation options:
-O1 -funroll-loops -fipa-ra
As long as -funroll-loops isn't in the compilation flags everything works as
expected (even for much higher optimization levels: -O3
-fexpensive-optimizations -ftree-vectorize -fprefetch-loop-arrays
-march=native)
It only happens with compilation with optimization, so a backtrace is unusable
(I am not experienced enough to run gdb efficiently).
An invalid memory reference is triggered:
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
I have filed a bug-report with OpenBLAS too and they indicate that it is
because GCC unrolls a loop one to many times.
For the discussion see here: https://github.com/xianyi/OpenBLAS/issues/1292
The bug can be reproduced by using this small script (in the OpenBLAS
directory):
###
#!/bin/bash
function run_all {
echo "CFLAGS = $CFLAGS"
echo "FCFLAGS = $FCFLAGS"
make clean > /dev/null
make COMMON_OPT="$CFLAGS" FCOMMON_OPT="$FCFLAGS" BINARY=64 SANITY_CHECK=1
MAX_STACK_ALLOC=2048 NUM_THREADS=48 USE_THREAD=0 libs netlib shared 2>
${1}_compilation.out > ${1}_compilation.out
make COMMON_OPT="$CFLAGS" FCOMMON_OPT="$FCFLAGS" BINARY=64 SANITY_CHECK=1
MAX_STACK_ALLOC=2048 NUM_THREADS=48 USE_THREAD=0 tests 2> $1.out > $1.out
}
which gcc
sleep 1
unset FCFLAGS
unset CFLAGS
export CFLAGS="-O1 -funroll-loops -fipa-ra"
export FCFLAGS="$CFLAGS"
run_all minimum
###
[Bug fortran/71087] scipy amos crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087 Nick changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #12 from Nick --- Sorry, never mind. The previous check was made against the wrong compiler installation. It now works. :( I had always used the same installation procedure, but I guess never gcc versions allow more advanced optimizations per-default. Sorry for the blurp. :(
[Bug fortran/71087] scipy amos crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087 --- Comment #11 from Nick --- Created attachment 38492 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38492&action=edit make check output I recompiled gcc on the Opteron6136 machine. I ran the test-suite: make -k check > test.out Doing: grep -e FAIL -e ERROR test.out only returns two lines. Those lines only appear due to "WERROR=" lines. I also tried: gcc -O2 -march=opteron -c zunhj.f to no avail. All-in-all, the bug persists. :( I have attached the gz of the make check.
[Bug fortran/71087] scipy amos crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087 --- Comment #10 from Nick --- I am currently testing both cases...
[Bug fortran/71087] scipy amos crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087 --- Comment #7 from Nick --- And the exact same installation on XeonE5-266[5|0v3] works seamlessly. So I wouldn't expect the tar, nor installation options to be the fault.
[Bug fortran/71087] scipy amos crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087 --- Comment #6 from Nick --- http://ftp.download-by.net/gnu/gnu/gcc/gcc-6.1.0/gcc-6.1.0.tar.bz2 md5sum is good: 8fb6cb98b8459f5863328380fbf06bd1 http://www.linuxfromscratch.org/blfs/view/svn/general/gcc.html 2016-05-14 14:02 GMT+02:00 dominiq at lps dot ens.fr < gcc-bugzi...@gcc.gnu.org>: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087 > > --- Comment #4 from Dominique d'Humieres --- > > Same error with this compilation: > > Where did you get your gfortran 6.1? > > -- > You are receiving this mail because: > You reported the bug. >
[Bug fortran/71087] scipy amos crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087 --- Comment #5 from Nick --- http://ftp.download-by.net/gnu/gnu/gcc/gcc-6.1.0/gcc-6.1.0.tar.bz2 md5sum is good: 8fb6cb98b8459f5863328380fbf06bd1 http://www.linuxfromscratch.org/blfs/view/svn/general/gcc.html
[Bug fortran/71087] scipy amos crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087 --- Comment #3 from Nick --- Same error with this compilation: gfortran -O2 -march=corei7 -mtune=corei7 -c zunhj.f (still only on Opteron)
[Bug fortran/71087] scipy amos crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087 --- Comment #1 from Nick --- I have debugged this further. This bug only happens on Opteron with : - 2354 - 2382 - 6136 Only those architectures I have available.
[Bug tree-optimization/69232] floop-unroll-and-jam, at graphite_transform_loops with isl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69232 Nick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick --- Fixed (works in 6.1.0)
[Bug fortran/69741] Bad error in formal with array scalar loop counters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69741 Nick changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Nick --- The error message has been updated and the bug is not part of the fortran specification.
[Bug fortran/71087] New: scipy amos crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087 Bug ID: 71087 Summary: scipy amos crash Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nickpapior at gmail dot com Target Milestone: --- Created attachment 38475 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38475&action=edit Source code trigging bug - Compiling amos/zunhj.f in scipy package crashes with: zunhj.f:1:0: SUBROUTINE ZUNHJ(ZR, ZI, FNU, IPMTR, TOL, PHIR, PHII, ARGR, ARGI, internal compiler error: Illegal instruction 0xa64def crash_signal ../../gcc/toplev.c:333 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. - This bug happens whenever -OX, for X>=1 is in effect. - This returns no errors: gfortran -fsanitize=undefined -c zunhj.f - Here is the output of the detailed excerpt: Using built-in specs. COLLECT_GCC=gfortran Target: x86_64-pc-linux-gnu Configured with: ../configure --prefix <>/gcc/6.1.0 --with-gmp=<>/gmp/6.1.0 --with-mpfr=<>/mpfr/3.1.4 --with-mpc=<>/mpc/1.0.3 --with-isl=<>/isl/0.16.1 --enable-lto --enable-threads --enable-stage1-languages=c,c++,fortran,go,objc,obj-c++ --with-multilib-list=m64 Thread model: posix gcc version 6.1.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-c' '-mtune=generic' '-march=x86-64' <>/gcc/6.1.0/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/f951 zunhj.f -ffixed-form -quiet -dumpbase zunhj.f -mtune=generic -march=x86-64 -auxbase zunhj -O1 -version -fintrinsic-modules-path <>/gcc/6.1.0/lib/gcc/x86_64-pc-linux-gnu/6.1.0/finclude -o zunhj.s GNU Fortran (GCC) version 6.1.0 (x86_64-pc-linux-gnu) compiled by GNU C version 6.1.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 6.1.0 (x86_64-pc-linux-gnu) compiled by GNU C version 6.1.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 zunhj.f:1:0: SUBROUTINE ZUNHJ(ZR, ZI, FNU, IPMTR, TOL, PHIR, PHII, ARGR, ARGI, internal compiler error: Illegal instruction 0xa64def crash_signal ../../gcc/toplev.c:333 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. - uname -a returns Linux <> 2.6.32-573.22.1.el6.x86_64 #1 SMP Tue Mar 22 17:15:28 CDT 2016 x86_64 x86_64 x86_64 GNU/Linux - As a bonus information. This source code has been in scipy since Aug. 2007 with no change since. It successfully compiles using 5.[1-3].0 and 4.8.3 and 4.9.[1-3] (tested in my build).
[Bug fortran/69741] Bad error in formal with array scalar loop counters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69741 --- Comment #8 from Nick --- That is much more informative. However, how are gcc policies on progressive errors? I mean the later errors are due to this non-scalar counter. Should they be silenced in that case? In any case I think this is much clearer and a better error message. Thanks.
[Bug fortran/69741] forall array scalar loop counters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69741 Nick changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #5 from Nick --- Yeah but that kind of defeats the purpose of having it as an array? :) I have re-opened due to the error message. I think it should be clearer from the error message of _what is wrong_? I will not push further if you again decide not to change the error-message.
[Bug fortran/69741] forall array scalar loop counters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69741 Nick changed: What|Removed |Added Severity|minor |critical --- Comment #2 from Nick --- Note that in regular do loops array elements are also not allowed: ``` do ii(2) = 1 , 2 do ii(1) = 1 , 3 a(ii(1),ii(2)) = ii(1) * ii(2) end do end do ``` is also illegal. I think they are related, but if you want me to create a new bug, please let me know. :)
[Bug fortran/69741] New: forall array scalar loop counters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69741 Bug ID: 69741 Summary: forall array scalar loop counters Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nickpapior at gmail dot com Target Milestone: --- In forall statements it may be easier in some cases to use array elements as loop counters. I can only find in the specification that an integer scalar is required as a loop counter and hence I thought that i(1) may be a valid loop counter. 1. If this is allowed then there is a bug. 2. If this is not allowed then the error message is vague and unclear. Compiling the following program results in an error: ``` subroutine check integer :: ii(2) real :: a(3,2) forall (ii(1)=1:3 , ii(2)=1:2) a(ii(1),ii(2)) = ii(1) * ii(2) end forall end subroutine check ``` With the error being: ``` test.f90:5:21: forall (ii(1)=1:3 , ii(2)=1:2) 1 Error: An outer FORALL construct already has an index with this name (1) test.f90:6:5: a(ii(1),ii(2)) = ii(1) * ii(2) 1 Warning: The FORALL with index ‘ii’ is not used on the left side of the assignment at (1) and so might cause multiple assignment to this object test.f90:6:5: Warning: The FORALL with index ‘ii’ is not used on the left side of the assignment at (1) and so might cause multiple assignment to this object ``` This error message does not reflect the actual error if array elements are not allowed as loop counters. PS: Compiler info: gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/generic/gcc/5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix /opt/generic/gcc/5.2.0 --with-gmp=/opt/generic/gmp/6.0.0a --with-mpfr=/opt/generic/mpfr/3.1.3 --with-mpc=/opt/generic/mpc/1.0.3 --with-isl=/opt/generic/isl/0.15 --enable-lto --enable-threads --enable-stage1-languages=c,c++,fortran,go,objc,obj-c++ --with-multilib-list=m64 Thread model: posix gcc version 5.2.0 (GCC)
[Bug tree-optimization/69232] New: floop-unroll-and-jam, at graphite_transform_loops with isl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69232 Bug ID: 69232 Summary: floop-unroll-and-jam, at graphite_transform_loops with isl Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: nickpapior at gmail dot com Target Milestone: --- Created attachment 37308 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37308&action=edit Source code to recreate error Compiling the attached code will produce an internal compiler error. The error message is: ../isl_ctx.c:245: isl_ctx freed, but some objects still reference it bessph.f:7:0: FUNCTION BESSPH (L,X) ^ internal compiler error: Aborted 0xa87146 crash_signal ../../gcc/toplev.c:383 0xfad1e9 graphite_transform_loops() ../../gcc/graphite.c:319 0xfad650 graphite_transforms ../../gcc/graphite.c:339 0xfad650 execute ../../gcc/graphite.c:420 Error arises after compiling the attached file with: gfortran -c -O2 -floop-interchange -floop-unroll-and-jam bessph.f no error at -O1. Tested on two systems. System 1 (5.2.0): # GCC version and configure options Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/generic/gcc/5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix /opt/generic/gcc/5.2.0 --with-gmp=/opt/generic/gmp/6.0.0a --with-mpfr=/opt/generic/mpfr/3.1.3 --with-mpc=/opt/generic/mpc/1.0.3 --with-isl=/opt/generic/isl/0.15 --enable-lto --enable-threads --enable-stage1-languages=c,c++,fortran,go,objc,obj-c++ --with-multilib-list=m64 Thread model: posix gcc version 5.2.0 (GCC) System Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u1 (2015-12-14) x86_64 unknown System 2 (5.3.0) # GCC version and configure options Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/2016-jan/generic/gcc/5.3.0/libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix /opt/2016-jan/generic/gcc/5.3.0 --with-gmp=/opt/2016-jan/generic/gmp/6.1.0 --with-mpfr=/opt/2016-jan/generic/mpfr/3.1.3 --with-mpc=/opt/2016-jan/generic/mpc/1.0.3 --with-isl=/opt/2016-jan/generic/isl/0.15 --enable-lto --enable-threads --enable-stage1-languages=c,c++,fortran,go,objc,obj-c++ --with-multilib-list=m64 Thread model: posix gcc version 5.3.0 (GCC) # System Linux 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov 6 23:43:09 UTC 2012 x86_64 x86_64
