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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99765
--- Comment #2 from Nick ---
Thanks for finding that in the standard!
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!
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()
pr
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355
--- Comment #5 from Nick ---
Thanks for the swift action! And lots of tests ;)
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
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
: 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=edit
Same as code snippet
I came about this in LAPACK which allows compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48655
Nick changed:
What|Removed |Added
CC||nickpapior at gmail dot com
--- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91496
--- Comment #4 from Nick ---
Great! This is much appreciated!
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
: 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:
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
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
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087
Nick changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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=edit
make check output
I recompiled gcc on the Opteron6136 machine.
I ran the test-suite:
make -k check > test.out
Doing:
grep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087
--- Comment #10 from Nick ---
I am currently testing both cases...
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.
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
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
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)
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69232
Nick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69741
Nick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
: 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=edit
Source code trigging bug
- Compiling amos/zunhj.f in scipy package crashes with:
zunhj.f:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69741
Nick changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69741
Nick changed:
What|Removed |Added
Severity|minor |critical
--- Comment #2 from Nick ---
Note that
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
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=edit
Source code to recreate er
34 matches
Mail list logo
