[Bug fortran/38220] C_LOC intrinsic non-pure and without explicit interface

[jeff.science at gmail dot com via Gcc-bugs]

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

Jeff Hammond  changed:

   What|Removed |Added

 CC||jeff.science at gmail dot com

--- Comment #8 from Jeff Hammond  ---
For what it's worth, ISO/IEC DIS 1539-1:2022 (E) now contains the following:

All standard procedures in the intrinsic module ISO_C_BINDING, other than
C_F_POINTER and C_F_PROCPOINTER, are now pure.

[Bug fortran/107375] New: CFI_cdesc_t incorrectly reports non-interoperable C structure as such

[jeff.science at gmail dot com via Gcc-bugs]

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

Bug ID: 107375
   Summary: CFI_cdesc_t incorrectly reports non-interoperable C
structure as such
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

Interoperable C structs are not permitted to contain allocatable members, among
other things.

The compiler should report that types containing allocatable members are
CFI_type_other, not CFI_type_struct.

I was not sure if the Fortran code was illegal or if the CFI_cdesc_t was
populated incorrectly, but another member of WG5 said it was the latter.


% gcc-12 -g -std=c11 -c foo.c -o foo.o
% gfortran-12 -g -std=f2018 class.F90 foo.o -o class.x
% ./class.x
CFI_cdesc_t.type  = interoperable C structure


==> foo.c <==
#include 
#include 
#include "ISO_Fortran_binding.h"

char * get_type(CFI_type_t t)
{
switch(t) {
case CFI_type_cptr   : return "void *";break;
case CFI_type_struct : return "interoperable C structure"; break;
case CFI_type_other  : return "Not otherwise specified";   break;
default  : abort();
}
}

void foo(CFI_cdesc_t * d)
{
printf("CFI_cdesc_t.type  = %s\n",  get_type(d->type));
}

==> class.F90 <==
module m

type :: t
integer :: i
double precision :: d
integer :: j(10)
real :: r(100)
real, allocatable :: z(:)
end type t

interface
subroutine foo(t) bind(C)
implicit none
type(*), dimension(..) :: t
end subroutine foo
end interface

end module m

program main
use m
implicit none
type(t) :: x
call foo(x)
end program main


% gfortran-12 -v
Using built-in specs.
COLLECT_GCC=gfortran-12
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/12.2.0/bin/../libexec/gcc/aarch64-apple-darwin21/12/lto-wrapper
Target: aarch64-apple-darwin21
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc
--libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls
--enable-checking=release --with-gcc-major-version-only
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-12
--with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr
--with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl
--with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 12.2.0'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--with-system-zlib --build=aarch64-apple-darwin21
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Homebrew GCC 12.2.0)

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

[jeff.science at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Jeff Hammond  ---
> program foo
>use f
>integer i
>call test(i)
> end program
> 
> which specific subroutine is called based on TKR?

I understand there is an ambiguity here, but what if I never make this call? 
Is the module code incorrect?

Anyways, there was a lot of discussion of this on a few channels and it seems
to not be required to work, although it's ambiguous whether compilers need to
catch it, and it seems that at least some compilers defer detection of the
issue until the ambiguous overload is actually used.

[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array

[jeff.science at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Jeff Hammond  ---
Is this ever going to be fixed?  I observe that a similar MCVE (below) is
compiled without complaint by Intel, Cray and NAG Fortran, so it's almost
certainly a lack of support for the standard in GCC.

As best I can, it is impossible to overload an interface when one of the
specific interfaces involves type(*), dimension(..), which makes it impossible
for me to implement MPI-3 F08 support.

My MCVE:

module f
implicit none

interface test
module procedure test_f08
module procedure test_f08ts
end interface test

contains

subroutine test_f08(buf)
integer :: buf
end subroutine test_f08

subroutine test_f08ts(buffer)
type(*), dimension(..), intent(inout) :: buffer
end subroutine test_f08ts

end module f

[Bug fortran/101602] New: local and local_init are not supported in DO CONCURRENT

[jeff.science at gmail dot com via Gcc-bugs]

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

Bug ID: 101602
   Summary: local and local_init are not supported in DO
CONCURRENT
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

Fortran 2018 (https://j3-fortran.org/doc/year/18/18-007r1.pdf) has three
locality specifiers: shared, local and local_init.

GCC Fortran does not support any of these.  This breaks user experience for
Fortran programmers using DO CONCURRENT code that works with other compilers.

OpenMP supports equivalent locality specifiers already so the internal
capability for this surely exists in GCC.

  program bug
implicit none
integer :: i, j, k
integer, dimension(100) :: x
j = 20
k = 30
x = 7
do concurrent (i=1:10) shared(x)
   k = k + x(i)
   j = k 
end do
do concurrent (i=1:10) local(j)
   k = k + x(i)
   j = k 
end do
do concurrent (i=1:10) local_init(k)
   k = k + x(i)
   j = k 
end do
print*,k
  end program bug


% gfortran-11 bug.F
bug.F:8:31:

8 | do concurrent (i=1:10) shared(x)
  |   1
Error: Syntax error in DO statement at (1)
bug.F:11:11:

   11 | end do
  |   1
Error: Expecting END PROGRAM statement at (1)
bug.F:12:31:

   12 | do concurrent (i=1:10) local(j)
  |   1
Error: Syntax error in DO statement at (1)
bug.F:15:11:

   15 | end do
  |   1
Error: Expecting END PROGRAM statement at (1)
bug.F:16:31:

   16 | do concurrent (i=1:10) local_init(k)
  |   1
Error: Syntax error in DO statement at (1)
bug.F:19:11:

   19 | end do
  |   1
Error: Expecting END PROGRAM statement at (1)

% gfortran-11 --version
GNU Fortran (Homebrew GCC 11.1.0_1) 11.1.0
Copyright (C) 2021 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.

[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails

[jeff.science at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Jeff Hammond  ---
@Martin

% gfortran -O3 -fprefetch-loop-arrays --verbose -c ctrsm.f && echo OKAY

Using built-in specs.
COLLECT_GCC=gfortran
Target: aarch64-apple-darwin20
Configured with: ../configure --build=aarch64-apple-darwin20
--prefix=/opt/homebrew/Cellar/gcc/10.2.0_3
--libdir=/opt/homebrew/Cellar/gcc/10.2.0_3/lib/gcc/10 --disable-nls
--enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran
--program-suffix=-10 --with-gmp=/opt/homebrew/opt/gmp
--with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc
--with-isl=/opt/homebrew/opt/isl --with-system-zlib --with-pkgversion='Homebrew
GCC 10.2.0_3' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-multilib --with-native-system-header-dir=/usr/include
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
SED=/usr/bin/sed
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20201220 (Homebrew GCC 10.2.0_3) 
COLLECT_GCC_OPTIONS='-O3' '-fprefetch-loop-arrays' '-v' '-c'
'-mmacosx-version-min=11.2.0' '-asm_macosx_version_min=11.2' '-mlittle-endian'
'-mabi=lp64'

/opt/homebrew/Cellar/gcc/10.2.0_3/libexec/gcc/aarch64-apple-darwin20/10.2.1/f951
ctrsm.f -ffixed-form -fPIC -quiet -dumpbase ctrsm.f -mmacosx-version-min=11.2.0
-mlittle-endian -mabi=lp64 -auxbase ctrsm -O3 -version -fprefetch-loop-arrays
-fintrinsic-modules-path
/opt/homebrew/Cellar/gcc/10.2.0_3/lib/gcc/10/gcc/aarch64-apple-darwin20/10.2.1/finclude
-o /var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccR79V1w.s
GNU Fortran (Homebrew GCC 10.2.0_3) version 10.2.1 20201220
(aarch64-apple-darwin20)
compiled by GNU C version 10.2.1 20201220, GMP version 6.2.1, MPFR
version 4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (Homebrew GCC 10.2.0_3) version 10.2.1 20201220
(aarch64-apple-darwin20)
compiled by GNU C version 10.2.1 20201220, GMP version 6.2.1, MPFR
version 4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-O3' '-fprefetch-loop-arrays' '-v' '-c'
'-mmacosx-version-min=11.2.0'  '-mlittle-endian' '-mabi=lp64'
 as -arch arm64 -v -mmacosx-version-min=11.2 -o ctrsm.o
/var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccR79V1w.s
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: aarch64-apple-darwin20.3.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
-cc1as -triple arm64-apple-macosx11.2.0 -filetype obj -main-file-name
ccR79V1w.s -target-cpu vortex -target-feature +v8.3a -target-feature +fp-armv8
-target-feature +neon -target-feature +crc -target-feature +crypto
-target-feature +fullfp16 -target-feature +ras -target-feature +lse
-target-feature +rdm -target-feature +rcpc -target-feature +zcm -target-feature
+zcz -target-feature +sha2 -target-feature +aes -fdebug-compilation-dir /tmp
-dwarf-debug-producer "Apple clang version 12.0.0 (clang-1200.0.32.29)"
-dwarf-version=4 -mrelocation-model pic -o ctrsm.o
/var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccR79V1w.s
/var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccR79V1w.s:362:23: error:
index must be a multiple of 8 in range [0, 32760].
prfmPLDL1KEEP, [x0, -8]
^

[Bug fortran/99092] New: Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails

[jeff.science at gmail dot com via Gcc-bugs]

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

Bug ID: 99092
   Summary: Using -O3 and -fprefetch-loop-arrays to compile BLAS
on Apple M1 fails
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

Created attachment 50179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50179=edit
source code that triggers bug

I am using GCC 10.2.1 installed via Homebrew on an Apple M1 system.

I attempted to compile one of the functions from the BLAS and it fails as
follows.  The failure is triggered by the combined use of -O3 and
-fprefetch-loop-arrays.  Reducing to -O2 or removing the latter eliminates the
issue, so there is a simple workaround.  Nonetheless, I encountered it the
first time I tried to build NWChem on this platform, so it will be seen by
others until I can fix the NWChem build system to avoid it.

I do not see this issue on x86, although I am not sure if I have tested GCC
10.2.1 specifically.

% wget https://netlib.sandia.gov/blas/ctrsm.f # also attached

% gfortran -O3 -fprefetch-loop-arrays -c ctrsm.f && echo OKAY

/var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccj3jW77.s:362:23: error:
index must be a multiple of 8 in range [0, 32760].
prfmPLDL1KEEP, [x0, -8]
^
% gfortran -O2 -fprefetch-loop-arrays -c ctrsm.f && echo OKAY

OKAY

% gfortran -O3 -c ctrsm.f && echo OKAY

OKAY

% gfortran --version
GNU Fortran (Homebrew GCC 10.2.0_3) 10.2.1 20201220
Copyright (C) 2020 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.

[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)

[jeff.science at gmail dot com]

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

--- Comment #12 from Jeff Hammond  ---
I apologize for stupidly misinterpreting the automated message as something
else. My email client did not show the true sender address.

[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)

[jeff.science at gmail dot com]

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

--- Comment #11 from Jeff Hammond  ---
Thanks for sharing. I’ve seen that bug or closely related ones before. This
is definitely one of the motivating examples for this feature set.

The only question is how many years before it gets adopted (which requires
everybody to use the latest OpenMP implementations, of course)...

Jeff

On Wed, Dec 12, 2018 at 7:21 PM jakub at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035
>
> --- Comment #10 from Jakub Jelinek  ---
> GCC 9 has omp_pause_resource and omp_pause_resource_all APIs as required by
> OpenMP 5.0 for this.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug libstdc++/85998] feature request: support C++17 parallel STL

[jeff.science at gmail dot com]

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

--- Comment #5 from Jeff Hammond  ---
> Finishing C++17 support in libstdc++ is already one of our top priorities for
> GCC 9. There's no need to ask for it, and doing so won't affect priorities.
> The missing pieces are documented:
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017

That page says nothing about priority of parallel STL or the GCC 9 roadmap. 
For "The Parallelism TS Should be Standardized" it says Status=No.

Given the lack of support for C11 threads in glibc
(https://sourceware.org/bugzilla/show_bug.cgi?id=14092), I do not think it is
unreasonable to be pessimistic about support for parallel features in the GNU
toolchain.

> However different developers want to. People work on what they (or their
> employers or sponsors) want to work on.  Personally I don't see any point in
> having open bugs to track that features are missing when they're already
> documented as missing. We know they're missing.

*You* know they are missing.  Do you expect every GCC user to subscribe to
every GCC mailing list to track development?  Have you ever thought about what
it is like to be a user of GCC, as opposed to a developer?

> If it makes you feel better this can be reopened, and then ignored until the
> missing features are done, then closed as FIXED. I don't see any advantage to
> that though.

Please do this.  That way, GCC users who assume the bug tracker is used to
track development can find it.

> On the libstdc++ mailing list, and (especially during the initial stages of
> the integration) in the PSTL upstream.

I'm sure I'm wasting my time in suggesting that email is not a good project
management system.

> So then you might have seen the pull requests being created to prepare it for
> inclusion in libstdc++ and libc++.

I assume you mean https://github.com/intel/parallelstl/pull/9.  I wasn't
watching the GitHub project but am now.

I would have expected to see a pull request against GCC rather than PSTL, but
clearly, GCC has a unique approach to project management.

[Bug libstdc++/85998] feature request: support C++17 parallel STL

[jeff.science at gmail dot com]

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

--- Comment #3 from Jeff Hammond  ---
Other projects use the existence of feature requests in their bug tracker for
prioritization of development.  How does GCC manage this information?  How do
you track GCC roadmap development if not through this system?  Where can I
follow progress towards C++17 parallel STL?

I am well aware of the Intel PSTL work.

[Bug c++/85998] New: feature request: support C++17 parallel STL

[jeff.science at gmail dot com]

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

Bug ID: 85998
   Summary: feature request: support C++17 parallel STL
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

I'd like to see GCC evolve
https://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html into a
proper implementation of the C++17 parallel STL
(http://en.cppreference.com/w/cpp/algorithm).

Because there is already an OpenMP parallel back-end, I assume this is mostly a
matter of creating the boilerplate to map __gnu_parallel::foo(args) to
std::foo(std::execution::par,args).

[Bug c/84274] New: [feature request] mbind attribute

[jeff.science at gmail dot com]

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

Bug ID: 84274
   Summary: [feature request] mbind attribute
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

https://sourceware.org/ml/binutils/2017-03/msg00261.html describes
as-of-yet-unimplemented attributes to control the placement of data into new
variants of bss, data, etc.

> The goal is to place data in special memory sections via 
> attribute. To place an uninitialized variable, foo, in a
> mbind bss section with memory type 1:
> 
> int foo __attribute__ ((mbind(0x1)));
> 
> To place a variable, foo, in a mbind data section with 
> memory type 2:
> 
> int foo __attribute__ ((mbind(0x2))) = 1;
> 
> To place a read-only variable, foo, in a mbind rodata 
> section with memory type 3:
> 
> const int foo __attribute__ ((mbind(0x3))) = 1;

This is a feature request to support these in GCC, since the underlying
functionality is supported
(https://fossies.org/diffs/binutils/2.28_vs_2.29/include/ChangeLog-diff.html).

# Additional references

https://sourceware.org/ml/gnu-gabi/2017-q1/msg0.html

[Bug driver/81358] libatomic not automatically linked with C11 code

[jeff.science at gmail dot com]

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

--- Comment #5 from Jeff Hammond  ---
Indeed, _Atomic is a language keyword and doesn't require any headers (the
inclusion of stdatomic.h in this code is superfluous), so the "header->explicit
library" argument doesn't apply.

In any case, I do not see why language intrinsics that require headers should
require libraries.  Why is sqrt() from math.h different from fprintf() from
stdio.h?  Maybe POSIX requires that, but ISO C11 doesn't, and I'm using
-std=c11 not -std=posix.

--as-needed would greatly enhance user experience for both this and libm.

[Bug fortran/81350] gfortran OpenMP taskloop segfaults or incorrect

[jeff.science at gmail dot com]

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

Jeff Hammond  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug fortran/81350] gfortran OpenMP taskloop segfaults or incorrect

[jeff.science at gmail dot com]

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

Jeff Hammond  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jeff Hammond  ---
You are right.  This is a bogus bug report.  I am still figuring out how to use
TASKLOOP correctly.  Sorry for the trouble.

[Bug fortran/81350] New: gfortran OpenMP taskloop segfaults or incorrect

[jeff.science at gmail dot com]

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

Bug ID: 81350
   Summary: gfortran OpenMP taskloop segfaults or incorrect
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

Created attachment 41697
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41697=edit
source code associated with bug

Code is correct with Intel 18 but generates erroneous results or segfaults with
GCC 7.1.

jrhammon-mac01:FORTRAN jrhammon$ ifort -std08 -fpp -g -O3 -xHOST -DRADIUS=2
-DSTAR -qopenmp stencil-taskloop-openmp.f90 -o stencil-taskloop-openmp-ifort

jrhammon-mac01:FORTRAN jrhammon$ gfortran-7 -std=f2008 -cpp -g -O3
-mtune=native -DRADIUS=2 -DSTAR -fopenmp stencil-taskloop-openmp.f90 -o
stencil-taskloop-openmp-gfortran

jrhammon-mac01:FORTRAN jrhammon$ ./stencil-taskloop-openmp-ifort 10 1000
Parallel Research Kernels
Fortran OpenMP TASKLOOP Stencil execution on 2D grid
Number of threads=4
Grid size= 1000
Radius of stencil=2
Type of stencil  = star
Data type= double precision
Compact representation of stencil loop body
Untiled
Number of iterations =   10
Solution validates
Rate (MFlops/s):   7787.263159 Avg time (s):  0.002420

jrhammon-mac01:FORTRAN jrhammon$ ./stencil-taskloop-openmp-gfortran 10 1000
Parallel Research Kernels
Fortran OpenMP TASKLOOP Stencil execution on 2D grid
Number of threads=4
Grid size= 1000
Radius of stencil=2
Type of stencil  = star
Data type= double precision
Compact representation of stencil loop body
Untiled
Number of iterations =   10
Segmentation fault: 11

jrhammon-mac01:FORTRAN jrhammon$ ./stencil-taskloop-openmp-ifort 10 100
Parallel Research Kernels
Fortran OpenMP TASKLOOP Stencil execution on 2D grid
Number of threads=4
Grid size=  100
Radius of stencil=2
Type of stencil  = star
Data type= double precision
Compact representation of stencil loop body
Untiled
Number of iterations =   10
Solution validates
Rate (MFlops/s):411.036158 Avg time (s):  0.000426

jrhammon-mac01:FORTRAN jrhammon$ ./stencil-taskloop-openmp-gfortran 10 100
Parallel Research Kernels
Fortran OpenMP TASKLOOP Stencil execution on 2D grid
Number of threads=4
Grid size=  100
Radius of stencil=2
Type of stencil  = star
Data type= double precision
Compact representation of stencil loop body
Untiled
Number of iterations =   10
ERROR: L1 norm =  0.00 Reference L1 norm = 22.00
Rate (MFlops/s):814.866756 Avg time (s):  0.000215

$ gfortran-7 -v
Using built-in specs.
COLLECT_GCC=gfortran-7
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/7.1.0/libexec/gcc/x86_64-apple-darwin16.6.0/7.1.0/lto-wrapper
Target: x86_64-apple-darwin16.6.0
Configured with: ../configure --build=x86_64-apple-darwin16.6.0
--prefix=/usr/local/Cellar/gcc/7.1.0
--libdir=/usr/local/Cellar/gcc/7.1.0/lib/gcc/7
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-7
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC
7.1.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-nls --with-native-system-header-dir=/usr/include
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
Thread model: posix
gcc version 7.1.0 (Homebrew GCC 7.1.0)

[Bug c++/81314] New: In function `star1(int, std::vector<double, std::allocator >&) [clone ._omp_cpyfn.1]': $(PWD)/stencil-vector-taskloop-gccbug2.cc:4: undefined reference to `std::vector

[jeff.science at gmail dot com]

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

Bug ID: 81314
   Summary: In function `star1(int, std::vector&) [clone ._omp_cpyfn.1]':
$(PWD)/stencil-vector-taskloop-gccbug2.cc:4: undefined
reference to `std::vector::vector(std::vector&) [clone ._omp_cpyfn.1]':
$(PWD)/stencil-vector-taskloop-gccbug2.cc:4: undefined reference to
`std::vector::vector(std::vector const&)'
collect2: error: ld returned 1 exit status
FAIL

$ g++-7 -std=c++11 -g -O2 -fopenmp stencil-vector-taskloop-gccbug2.cc -o
stencil-vector-taskloop-gccbug2 && echo SUCCESS || echo FAIL
/tmp/ccuIhlTa.o: In function `star1(int, std::vector&) [clone ._omp_cpyfn.1]':
$(PWD)/stencil-vector-taskloop-gccbug2.cc:4: undefined reference to
`std::vector::vector(std::vector const&)'
collect2: error: ld returned 1 exit status
FAIL

## compile-only

$ g++-8 -std=c++11 -g -O2 -fopenmp -c stencil-vector-taskloop-gccbug2.cc -o
stencil-vector-taskloop-gccbug2.o && echo SUCCESS || echo FAIL
SUCCESS

## without OpenMP

$ g++-8 -std=c++11 -g -O2 stencil-vector-taskloop-gccbug2.cc -o
stencil-vector-taskloop-gccbug2 && echo SUCCESS || echo FAIL
SUCCESS

## other compilers

$ /opt/llvm/4.0.0/bin/clang++ -std=c++11 -g -O2 -fopenmp -Wunused
stencil-vector-taskloop-gccbug2.cc -o stencil-vector-taskloop-gccbug2
/opt/llvm/4.0.0/lib/libomp.so && echo SUCCESS || echo FAIL
SUCCESS

$ icpc -std=c++11 -g -O2 -fopenmp stencil-vector-taskloop-gccbug2.cc -o
stencil-vector-taskloop-gccbug2 && echo SUCCESS || echo FAIL
SUCCESS

# SOURCE

$ cat stencil-vector-taskloop-gccbug2.cc
#include 

void star1(const int n, std::vector & out) {
  _Pragma("omp taskloop")
  for (auto i=0; i<(n*n); ++i) out[i] = 1.0;
}

int main()
{
  const int n = 1000;
  std::vector out;
  out.resize(n*n,0.0);
  _Pragma("omp parallel")
  _Pragma("omp master")
  {
star1(n, out);
_Pragma("omp taskwait")
  }
  return 0;
}

# GCC VERSION

$ g++-8 -v
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/opt/gcc/HEAD/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /opt/gcc//git/configure --program-suffix=-8 --disable-multilib
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --enable-languages=c,c++,fortran --with-tune=native
--enable-bootstrap --enable-lto --enable-gold=yes --enable-ld=yes
--prefix=/opt/gcc//HEAD : (reconfigured) /opt/gcc//git/configure
--program-suffix=-8 --disable-multilib --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--enable-languages=c,c++,fortran --with-tune=native --enable-bootstrap
--enable-lto --enable-gold=yes --enable-ld=yes --prefix=/opt/gcc//HEAD
Thread model: posix
gcc version 8.0.0 20170627 (experimental) (GCC)

$ g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/opt/gcc/7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/opt/gcc/7.1.0 --program-suffix=-7
--enable-shared --enable-static --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--enable-languages=c,c++,fortran --with-tune=native --enable-bootstrap
--enable-lto --enable-gold=yes --enable-ld=yes --disable-multilib
Thread model: posix
gcc version 7.1.0 (GCC)

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

[jeff.science at gmail dot com]

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

--- Comment #10 from Jeff Hammond  ---
Thanks for the feedback.  I agree that it is a huge amount of work to optimize
this.

For what it's worth, GCC and Clang perform about the same.  Unfortunately, I do
not have the means to evaluate IBM XLF, which may have an optimized
implementation of this
(https://rd.springer.com/chapter/10.1007%2F978-3-642-32820-6_23), so I do not
have a good sense of what is achievable here, other than what I hand-optimize.

I have no objection if you want to close this as invalid.

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

[jeff.science at gmail dot com]

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

--- Comment #8 from Jeff Hammond  ---
I tried with schedule(dynamic) and schedule(static,n) for n=1,8,100.  None of
this made a positive difference.  Is that expected?  I'm happy to make any code
changes that don't break correctness and are still readable.

I don't fully understand the semantics of ordered, but is it illegal for the
compiler to generate blocked code that still orders the iteration space, which
I achieve by explicitly implementing that with tasks.  The following code
performs very well, at least with appropriate tiling (mc,nc).

  _Pragma("omp master")
  {
for (auto i=1; i=1; j--) {
_Pragma("omp for")
for (auto i=1; i<=j; i++) {
  auto x = n+i-j-1;
  auto y = n-i;
  grid[x*n+y] = grid[(x-1)*n+y] + grid[x*n+(y-1)] -
grid[(x-1)*n+(y-1)];
}
  }
  _Pragma("omp master")
  grid[0*n+0] = -grid[(n-1)*n+(n-1)];

[Bug libstdc++/81221] [7/8 Regression] stl_algo.h: error: ‘__sample’ is not a member of ‘std’

[jeff.science at gmail dot com]

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

--- Comment #2 from Jeff Hammond  ---
Thank you!  Indeed, that fixes it, both when applied directly to the installed
header and when integrated into a build of the latest version.

$ g++-8 -std=gnu++17 -g -O3 -mtune=native -D_GLIBCXX_PARALLEL -fopenmp
test.cc&& echo "SUCCESS" || echo "FAIL"
SUCCESS

$ g++-8 -v
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/opt/gcc/HEAD/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /opt/gcc//git/configure --program-suffix=-8 --disable-multilib
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --enable-languages=c,c++,fortran --with-tune=native
--enable-bootstrap --enable-lto --enable-gold=yes --enable-ld=yes
--prefix=/opt/gcc//HEAD : (reconfigured) /opt/gcc//git/configure
--program-suffix=-8 --disable-multilib --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--enable-languages=c,c++,fortran --with-tune=native --enable-bootstrap
--enable-lto --enable-gold=yes --enable-ld=yes --prefix=/opt/gcc//HEAD
Thread model: posix
gcc version 8.0.0 20170627 (experimental) (GCC)

[Bug libstdc++/81221] New: stl_algo.h: error: ‘__sample’ is not a member of ‘std’

[jeff.science at gmail dot com]

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

Bug ID: 81221
   Summary: stl_algo.h: error: ‘__sample’ is not a member of ‘std’
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

The trivial parallel STL example from the documentation
(https://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode_using.html) does
not compile with GCC 7.1.0 or 8.0.0 (compiled on June 4, 2017).

$ cat test.cc 
#include 
#include 

int main()
{
std::vector v(100);
__gnu_parallel::sort(v.begin(), v.end());
return 0;
}


$ g++-8 -v
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/opt/gcc/HEAD/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /opt/gcc//git/configure --program-suffix=-8 --disable-multilib
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --enable-languages=c,c++,fortran --with-tune=native
--enable-bootstrap --enable-lto --enable-gold=yes --enable-ld=yes
--prefix=/opt/gcc//HEAD
Thread model: posix
gcc version 8.0.0 20170604 (experimental) (GCC) 

$ g++-8 -std=gnu++17 -g -O3 -mtune=native -D_GLIBCXX_PARALLEL -fopenmp test.cc 
In file included from /opt/gcc/HEAD/include/c++/8.0.0/algorithm:62:0,
 from /opt/gcc/HEAD/include/c++/8.0.0/parallel/algorithm:34,
 from test.cc:2:
/opt/gcc/HEAD/include/c++/8.0.0/bits/stl_algo.h: In function ‘_SampleIterator
std::__cxx1998::sample(_PopulationIterator, _PopulationIterator,
_SampleIterator, _Distance, _UniformRandomBitGenerator&&)’:
/opt/gcc/HEAD/include/c++/8.0.0/bits/stl_algo.h:5834:19: error: ‘__sample’ is
not a member of ‘std’
   return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
   ^~~~
/opt/gcc/HEAD/include/c++/8.0.0/bits/stl_algo.h:5834:19: note: suggested
alternative: ‘is_same’
   return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
   ^~~~
   is_same

$ g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/opt/gcc/7.1.0/libexec/gcc/x86_64-pc-linux-gnu/7.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/opt/gcc/7.1.0 --program-suffix=-7
--enable-shared --enable-static --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--enable-languages=c,c++,fortran --with-tune=native --enable-bootstrap
--enable-lto --enable-gold=yes --enable-ld=yes --disable-multilib
Thread model: posix
gcc version 7.1.0 (GCC) 

$ g++-7 -std=gnu++17 -g -O3 -mtune=native -D_GLIBCXX_PARALLEL -fopenmp test.cc 
In file included from /opt/gcc/7.1.0/include/c++/7.1.0/algorithm:62:0,
 from /opt/gcc/7.1.0/include/c++/7.1.0/parallel/algorithm:34,
 from test.cc:2:
/opt/gcc/7.1.0/include/c++/7.1.0/bits/stl_algo.h: In function ‘_SampleIterator
std::__cxx1998::sample(_PopulationIterator, _PopulationIterator,
_SampleIterator, _Distance, _UniformRandomBitGenerator&&)’:
/opt/gcc/7.1.0/include/c++/7.1.0/bits/stl_algo.h:5812:19: error: ‘__sample’ is
not a member of ‘std’
   return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
   ^~~~
/opt/gcc/7.1.0/include/c++/7.1.0/bits/stl_algo.h:5812:19: note: suggested
alternative: ‘is_same’
   return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
   ^~~~
   is_same

It does not build with the standard namespace either...

$ cat test.cc c
#include 
#include 

int main()
{
std::vector v(100);
std::sort(v.begin(), v.end());
return 0;
}

$ g++-7 -std=gnu++17 -g -O3 -mtune=native -D_GLIBCXX_PARALLEL -fopenmp test.cc 
In file included from /opt/gcc/7.1.0/include/c++/7.1.0/algorithm:62:0,
 from /opt/gcc/7.1.0/include/c++/7.1.0/parallel/algorithm:34,
 from test.cc:2:
/opt/gcc/7.1.0/include/c++/7.1.0/bits/stl_algo.h: In function ‘_SampleIterator
std::__cxx1998::sample(_PopulationIterator, _PopulationIterator,
_SampleIterator, _Distance, _UniformRandomBitGenerator&&)’:
/opt/gcc/7.1.0/include/c++/7.1.0/bits/stl_algo.h:5812:19: error: ‘__sample’ is
not a member of ‘std’
   return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
   ^~~~
/opt/gcc/7.1.0/include/c++/7.1.0/bits/stl_algo.h:5812:19: note: suggested
alternative: ‘is_same’
   return std::__sample(__first, __last, __pop_cat{}, __out, __samp_cat{},
   ^~~~
   is_same

$ g++-8 -std=gnu++17 -g -O3 -mtune=native -D_GLIBCXX_PARALLEL -fopenmp test.cc 
In file included from /opt/gcc/HEAD/include/c++/8.0.0/algorithm:62:0,
 from /opt/gcc/HEAD/include/c++/8.0

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

[jeff.science at gmail dot com]

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

--- Comment #6 from Jeff Hammond  ---
Created attachment 41566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41566=edit
tasks C++

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

[jeff.science at gmail dot com]

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

--- Comment #5 from Jeff Hammond  ---
Created attachment 41565
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41565=edit
header for C++ codes

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

[jeff.science at gmail dot com]

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

--- Comment #4 from Jeff Hammond  ---
Created attachment 41564
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41564=edit
doacross C++

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

[jeff.science at gmail dot com]

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

--- Comment #3 from Jeff Hammond  ---
Created attachment 41563
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41563=edit
sequential C++

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

[jeff.science at gmail dot com]

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

--- Comment #2 from Jeff Hammond  ---
Created attachment 41562
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41562=edit
tasks Fortran

This code runs faster than serial (assuming blocking is used), showing that
this pattern can be parallelized.

[Bug libgomp/81108] OpenMP doacross (omp do/for ordered) performance

[jeff.science at gmail dot com]

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

--- Comment #1 from Jeff Hammond  ---
Created attachment 41561
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41561=edit
doacross Fortran

[Bug libgomp/81108] New: OpenMP doacross (omp do/for ordered) performance

[jeff.science at gmail dot com]

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

Bug ID: 81108
   Summary: OpenMP doacross (omp do/for ordered) performance
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

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

When I use "doacross" OpenMP parallelism as described in
https://developers.redhat.com/blog/2016/03/22/what-is-new-in-openmp-4-5-3/, the
performance is ~30x worse than sequential execution.

This code can be effectively parallelized by blocking the wavefront, which I
have implemented as well.  I see the same behavior in Fortran and C++, so I
believe it is relatively agnostic to the front-end.  Clang has the same issue,
which we determined is because the dependency analysis is applied to the
collapsed loop, inhibiting all parallelism, although I don't understand why
this is so much worse than a serial implementation.

If it helps, the project is https://github.com/ParRes/Kernels, although I will
attach all of the code here.

# Sequential

  do j=2,n
do i=2,m
  grid(i,j) = grid(i-1,j) + grid(i,j-1) - grid(i-1,j-1)
enddo
  enddo

$ ./p2p 40 1000 1000
   Parallel Research Kernels
Fortran Serial pipeline execution on 2D 
Number of iterations =   40
Grid sizes   = 10001000
> traverse in the m dimension
Solution validates
Rate (MFlop/s):866.508739 Avg time (s):   0.002303

# OpenMP "doacross"

!$omp do ordered(2) collapse(2)
do j=2,n
  do i=2,m
!$omp ordered depend(sink:j,i-1) depend(sink:j-1,i)
depend(sink:j-1,i-1)
grid(i,j) = grid(i-1,j) + grid(i,j-1) - grid(i-1,j-1)
!$omp ordered depend(source)
  enddo
enddo
!$omp end do

$ ./p2p-openmp-doacross 40 1000 1000

   Parallel Research Kernels
Fortran OpenMP pipeline execution on 2D 
Number of threads=4
Number of iterations =   40
Grid sizes   = 10001000
Solution validates
Rate (MFlop/s): 17.855468 Avg time (s):   0.111787

[Bug middle-end/80161] const argument hidden from AVX intrinsics due to OpenMP outlining

[jeff.science at gmail dot com]

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

--- Comment #5 from Jeff Hammond  ---
Thanks for the comments.  Indeed, I made all the changes to the containing
project to compile in C++ and the problem went away.  I will likely just switch
to the preprocessor solution for now.

For posterity, I found that Clang has the same issue, whereas ICC (Intel) does
not.

Feel free to close this as WONTFIX/INVALID unless you think it should remain
open to motivate the OpenMP IPA changes in GCC 8+.

[Bug target/80161] const argument hidden from AVX intrinsics due to OpenMP outlining

[jeff.science at gmail dot com]

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

--- Comment #2 from Jeff Hammond  ---
Fair point, but the error is "error: the last argument must be scale 1, 2, 4,
8" and "const int scale = 1" sure seems like it should be interpreted by the
compiler as "1", given "scale" has local scope (the error persists even after I
move it inside the parallel region).

And if the compiler is enforcing the lack of const variables in C, should it
not do so consistently, and not just when OpenMP is used?  Why does OpenMP
prevent the compiler from seeing that scale=1, even if const is not there?

[Bug c/80161] New: const argument hidden from AVX intrinsics due to OpenMP outlining

[jeff.science at gmail dot com]

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

Bug ID: 80161
   Summary: const argument hidden from AVX intrinsics due to
OpenMP outlining
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

I get "error: the last argument must be scale 1, 2, 4, 8" when the argument is
"const int scale = 1", only when OpenMP is active.

Having seen similar issues in other compilers, I suspect that the OpenMP
outlining creates an indirection in which the constant properties of "scale"
are lost and thus not visible to the pass that parses intrinsics.

I know that manually inlining and the preprocessor provide a way to solve this,
but neither of those meets other requirements.

# Source Code

$ cat gccbug.c
#include "emmintrin.h"
#include "immintrin.h"

void copy_vgatherdpd128(size_t n, const double * restrict a, double * restrict
b)
{
__m128i vindex = _mm_set_epi32(-1,-1,8,0);
const int scale = 1;
#ifdef _OPENMP
#pragma omp parallel for
#endif
for (size_t i=0; i<n; i+=2) {
__m128d t = _mm_i32gather_pd( &(a[i]), vindex, scale );
_mm_storel_pd( &(b[i  ]), t);
_mm_storeh_pd( &(b[i+1]), t);
}
}

# Build without OpenMP

[jrhammon@esgmonster simd-memtest]$ gcc-7 -O3 -march=core-avx2 -std=gnu11 -g3
-Wall -c gccbug.c -o gccbug.o

# Build with OpenMP

[jrhammon@esgmonster simd-memtest]$ gcc-7 -O3 -march=core-avx2 -std=gnu11 -g3
-Wall -fopenmp -c gccbug.c -o gccbug.o
In file included from
/opt/gcc/HEAD/lib/gcc/x86_64-pc-linux-gnu/7.0.1/include/immintrin.h:43:0,
 from gccbug.c:2:
/opt/gcc/HEAD/lib/gcc/x86_64-pc-linux-gnu/7.0.1/include/avx2intrin.h: In
function ‘copy_vgatherdpd128._omp_fn.0’:
/opt/gcc/HEAD/lib/gcc/x86_64-pc-linux-gnu/7.0.1/include/avx2intrin.h:1254:10:
error: the last argument must be scale 1, 2, 4, 8
   return (__m128d) __builtin_ia32_gathersiv2df (_mm_undefined_pd (),
  ^~~
   __base,
   ~~~
   (__v4si)__index,
   
   __mask,
   ~~~
   __scale);
   

# GCC details

I compiled GCC from Git HEAD today.

$ gcc-7 -v
Using built-in specs.
COLLECT_GCC=gcc-7
COLLECT_LTO_WRAPPER=/opt/gcc/HEAD/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /opt/gcc//git/configure --program-suffix=-7 --disable-multilib
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --enable-languages=c,c++,fortran --with-tune=native
--enable-bootstrap --enable-lto --enable-gold=yes --enable-ld=yes
--prefix=/opt/gcc//HEAD
Thread model: posix
gcc version 7.0.1 20170323 (experimental) (GCC) 

$ gcc-7 --version
gcc-7 (GCC) 7.0.1 20170323 (experimental)
Copyright (C) 2017 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.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jeff.science at gmail dot com]

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

--- Comment #21 from Jeff Hammond  ---
Thanks.  This is great.  I built GCC master last night and can now compile both
the trivial test program and a more interesting one that encapsulates what I
actually need to work to make progress on OpenMP 5 and other activities.

/* trivial */

#include 

int main(void)
{
return 0;
}

/* nontrivial */

#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 201112L) &&
!defined(__STDC_NO_ATOMICS__)

#include 
#include 
#include 

#include 

#ifdef _OPENMP
# include 
#else
# error No OpenMP support!
#endif

#ifdef SEQUENTIAL_CONSISTENCY
int load_model  = memory_order_seq_cst;
int store_model = memory_order_seq_cst;
#else
int load_model  = memory_order_acquire;
int store_model = memory_order_release;
#endif

int main(int argc, char * argv[])
{
int nt = omp_get_max_threads();
#if 1
if (nt != 2) omp_set_num_threads(2);
#else
if (nt < 2)  omp_set_num_threads(2);
if (nt % 2 != 0) omp_set_num_threads(nt-1);
#endif

int iterations = (argc>1) ? atoi(argv[1]) : 100;

printf("thread ping-pong benchmark\n");
printf("num threads  = %d\n", omp_get_max_threads());
printf("iterations   = %d\n", iterations);
#ifdef SEQUENTIAL_CONSISTENCY
printf("memory model = %s\n", "seq_cst");
#else
printf("memory model = %s\n", "acq-rel");
#endif
fflush(stdout);

_Atomic int left_ready  = -1;
_Atomic int right_ready = -1;

int left_payload  = 0;
int right_payload = 0;

#pragma omp parallel
{
int me  = omp_get_thread_num();
/// 0=left 1=right
bool parity = (me % 2 == 0);

int junk = 0;

/// START TIME
#pragma omp barrier
double t0 = omp_get_wtime();

for (int i=0; i

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jeff.science at gmail dot com]

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

--- Comment #10 from Jeff Hammond  ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Jeff Hammond from comment #8)
> > So GCC refuses to compile any code that potentially includes undefined
> > behavior?
> 
> Semantics not being defined is different than undefined behavior.

GCC happily compiles a C++11 OpenMP program that is equivalent to the C11
OpenMP program that it will not compile.

GCC happily compiles the following Fortran 2008 OpenMP program that actually
does something that could be considered undefined.

$ gfortran-6 -fopenmp -std=f2008 -fcoarray=single caf-openmp.f 
$ cat caf-openmp.f 
  program atomic
  use iso_fortran_env
  use omp_lib
  implicit none
  integer :: i
  integer(atomic_int_kind) :: atom[*]
  call atomic_define (atom[1], this_image())
  !$OMP ATOMIC
  atom[1] = -this_image()
  end program atomic

If you want to break user experience for OpenMP programmers, please do it
systematically.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jeff.science at gmail dot com]

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

--- Comment #8 from Jeff Hammond  ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Jeff Hammond from comment #3)
> > Do you seriously pick this one time to prevent the user from even trying to
> > write incorrect code, while allowing an uncountable number of others?
> 
> This is different because the semantics are not defined at all.

So GCC refuses to compile any code that potentially includes undefined
behavior?

Please tell me about the undefined behavior in the following program, when
compiled with -fopenmp:

#include 

int main(void)
{
return 0;
}

> > One of the motivations for writing code that mixes C11 and OpenMP is because
> > I am a member of the OpenMP working group devoted to supporting C11 and
> > C++14 in the OpenMP standard.  By refusing to allow me to experiment with
> > OpenMP+C11, you actively harm progress in the OpenMP standard that would
> > allow you to resolve the semantic ambiguity that motivated disabling
> > C11+OpenMP in the first place.
> 
> If you are part of the working group then you should be able to help define
> the semantics instead of complaining we disable things :).

As I said already, I am trying to define them, but that has nothing to do with
the fact that GCC unnecessary broke an infinite number of valid programs.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jeff.science at gmail dot com]

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

--- Comment #7 from Jeff Hammond  ---
The fact that the parser doesn't handle a particle case where something might
go wrong is no reason to have the compiler refuse to compile code that includes
stdatomic.h with -fopenmp.  Look at my example and tell me what possible thing
can go wrong in it that justifies aborting the compilation.

This sort of attack on user experience is unprecedented in my career of
programming.  Do you break every other mixture of programming standard
semantics that is currently undefined?  I can think of others that GCC allows,
but will not list them, out of fear that someone will decide to break those as
well.

At most, this should have been a warning to indicate to the user that OpenMP
constructs do not correctly interact with _Atomic and the user should take care
to rely on only what is supported by ISO C11 and OpenMP 4.5.

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jeff.science at gmail dot com]

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

--- Comment #4 from Jeff Hammond  ---
Apparently, the GCC team wants to make it impossible for anyone to build
software where independent components that share CFLAGS in the build system
cannot use both the C11 atomics header and the OpenMP flag.  It doesn't matter
if you use either feature, literally including stdatomic.h and compiling with
-fopenmp is impossible.

So projects that use autotools and support CFLAGS=-fopenmp now need to
segregate the build system to compile any source files that include stdatomic.h
using a different set of options from the default?

It is really hard to imagine how someone came to the conclusion this was a
reasonable thing to do.

Anyways, here is the trivial test program that is broken by CFLAGS=-fopenmp.

#include 

int main(void)
{
return 0;
}

[Bug c/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP

[jeff.science at gmail dot com]

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

--- Comment #3 from Jeff Hammond  ---
This is awful.  How do I disable this horrible thing?

I am using OpenMP to create a thread pool, because C11 threads are still not
implemented in glibc, and all of my access to C11 _Atomic variables use C11
atomic operations, so my code is correct.  Do you seriously pick this one time
to prevent the user from even trying to write incorrect code, while allowing an
uncountable number of others?

One of the motivations for writing code that mixes C11 and OpenMP is because I
am a member of the OpenMP working group devoted to supporting C11 and C++14 in
the OpenMP standard.  By refusing to allow me to experiment with OpenMP+C11,
you actively harm progress in the OpenMP standard that would allow you to
resolve the semantic ambiguity that motivated disabling C11+OpenMP in the first
place.

[Bug c/69680] New: stdlib.h does not declare aligned_alloc

[jeff.science at gmail dot com]

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

Bug ID: 69680
   Summary: stdlib.h does not declare aligned_alloc
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

When I use aligned_alloc, I am told to include stdlib.h to provide a
declaration, but I have already done so.

VERSION

$ gcc-5 -v
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/5.3.0/libexec/gcc/x86_64-apple-darwin14.5.0/5.3.0/lto-wrapper
Target: x86_64-apple-darwin14.5.0
Configured with: ../configure --build=x86_64-apple-darwin14.5.0
--prefix=/usr/local/Cellar/gcc/5.3.0
--libdir=/usr/local/Cellar/gcc/5.3.0/lib/gcc/5
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug
--disable-werror --with-pkgversion='Homebrew gcc 5.3.0 --without-multilib'
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin
--disable-nls --disable-multilib
Thread model: posix
gcc version 5.3.0 (Homebrew gcc 5.3.0 --without-multilib) 

COMPILATION

$ gcc-5 -c aligned_alloc.c 
aligned_alloc.c: In function 'my_malloc':
aligned_alloc.c:5:12: warning: implicit declaration of function 'aligned_alloc'
[-Wimplicit-function-declaration]
 return aligned_alloc(64,bytes);
^
aligned_alloc.c:5:12: warning: incompatible implicit declaration of built-in
function 'aligned_alloc'
aligned_alloc.c:5:12: note: include '' or provide a declaration of
'aligned_alloc'

CODE

$ cat aligned_alloc.c 
#include 
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 201112L)
void* my_malloc(size_t bytes)
{
return aligned_alloc(64,bytes);
}
#else
#error Pointless
#endif

EXTRA

It seems that none of the GCC 5.3.0 headers declare this function...

$ find /usr/local/Cellar/gcc/5.3.0/ -name "*.h" -exec grep -H aligned_alloc {}
";"

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[jeff.science at gmail dot com]

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

--- Comment #9 from Jeff Hammond jeff.science at gmail dot com ---
First, you will not accept the fusion of cpp+gfortran behavior as a feature
request?  Is there a reason other than you do not want to do it because you are
already busy?

Second, true, but that doesn't stop gcc from supporting inline assembly outside
of ISO C11, or stop gfortran from being compatible with vendor implementations
of https://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html, or of supporting
any number of other non-standard features.

In short, it's not in the standard, therefore it's fine to break user
experience seems pretty weak here.  It's fine if you tell me that you do not
care about my needs and will not implement it, but please don't use ISO as the
excuse.

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[jeff.science at gmail dot com]

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

--- Comment #13 from Jeff Hammond jeff.science at gmail dot com ---
This is all fair.  I try very hard to fix my own bugs and submit patches, but
in this case I am wholly unqualified.  I don't know the first thing about
implementing a production compiler, or any compiler for that matter.

I believe that some of my Intel colleagues contribute to GCC already.  If I can
figure out who they are, perhaps I can convince them to help here, since
replicating the behavior of the Intel Fortran compiler has value for us.

And yes, I did read a fraction of the gfortran manual (which google decided was
relevant to my issue) in hopes of trying to solve this on my own.  I confess to
not having read the entire gfortran manual.

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[jeff.science at gmail dot com]

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

Jeff Hammond jeff.science at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #6 from Jeff Hammond jeff.science at gmail dot com ---
I want gfortran to behave like cpp, not the other way around.  I filed this bug
report against gfortran, not cpp, and I noted my desire to have gfortran behave
like cpp in both the title and original comments.

Please do not close the bug until you have addressed the bug report, and not a
closely related but ultimately opposite issue.

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[jeff.science at gmail dot com]

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

--- Comment #7 from Jeff Hammond jeff.science at gmail dot com ---
And your obvious workaround is in fact not one because it changes the
behavior of gfortran for Fortran source code and breaks the build in another
way.  And even if it did solve the problem, why not make it automatic with a
flag to gfortran?  

The Intel Fortran compiler behaves as desired by default.

[Bug fortran/67250] New: gfortran does not faithfully preprocess the way cpp does

[jeff.science at gmail dot com]

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

Bug ID: 67250
   Summary: gfortran does not faithfully preprocess the way cpp
does
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

Created attachment 36195
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36195action=edit
source file

I do not understand why gfortran -I. -E source.F does not give the same
result as cpp-5 -I. -E source.F.  It appears that gfortran does not properly
preprocessor #, ## and \.

This breaks NWChem and there is no obvious workaround.

 cat header.fh 
! comment
  integer foo
  external foo
#define DECL(a) \
  integer err_##a; \
  integer l_##a,k_##a;
#define ALLO(a,s) \
  err_##a=foo(s,#a,l_##a,k_##a); \
  if (.not.err_##a) call bar(PUSH#a,#s);

 cat source.F 
C
C OLD SCHOOL COMMENTS
C
  subroutine xyz(stuff)
  implicit none
#include header.fh
  integer stuff
  DECL(handle)
  ALLO(handle,100)
  print*,stuff
  return
  end


 gfortran -I. -E source.F 
# 1 source.F
# 1 built-in
# 1 command-line
# 1 source.F
C
C OLD SCHOOL COMMENTS
C
  subroutine xyz(stuff)
  implicit none

# 1 header.fh 1
! comment
  integer foo
  external foo
# 7 source.F 2
  integer stuff
  integer err_##handle;   integer l_##handle,k_##handle;
  err_##handle=foo(100,#handle,l_##handle,k_##handle);   if
(.not.err_##handle) call bar(PUSH#handle,#100);
  print*,stuff
  return
  end

 cpp-5 -I. -E source.F 
# 1 source.F
# 1 built-in
# 1 command-line
# 1 source.F
C
C OLD SCHOOL COMMENTS
C
  subroutine xyz(stuff)
  implicit none
# 1 header.fh 1
! comment
  integer foo
  external foo
# 7 source.F 2
  integer stuff
  integer err_handle; integer l_handle,k_handle;
  err_handle=foo(100,handle,l_handle,k_handle); if (.not.err_handle) call
bar(PUSHhandle,100);
  print*,stuff
  return
  end

 gfortran-5 -v
Using built-in specs.
COLLECT_GCC=gfortran-5
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/5.2.0/libexec/gcc/x86_64-apple-darwin14.4.0/5.2.0/lto-wrapper
Target: x86_64-apple-darwin14.4.0
Configured with: ../configure --build=x86_64-apple-darwin14.4.0
--prefix=/usr/local/Cellar/gcc/5.2.0
--libdir=/usr/local/Cellar/gcc/5.2.0/lib/gcc/5
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug
--disable-werror --with-pkgversion='Homebrew gcc 5.2.0 --without-multilib'
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin
--disable-nls --disable-multilib
Thread model: posix
gcc version 5.2.0 (Homebrew gcc 5.2.0 --without-multilib)

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[jeff.science at gmail dot com]

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

--- Comment #3 from Jeff Hammond jeff.science at gmail dot com ---
Unfortunately, this does not change anything.

 gfortran-5 -traditional-cpp -I. -E source.F 
# 1 source.F
# 1 built-in
# 1 command-line
# 1 source.F
C
C OLD SCHOOL COMMENTS
C
  subroutine xyz(stuff)
  implicit none

# 1 header.fh 1
! comment
  integer foo
  external foo
# 7 source.F 2
  integer stuff
  integer err_##handle;   integer l_##handle,k_##handle;
  err_##handle=foo(100,#handle,l_##handle,k_##handle);   if
(.not.err_##handle) call bar(PUSH#handle,#100);
  print*,stuff
  return
  end

[Bug fortran/67251] New: gfortran does not faithfully preprocess the way cpp does

[jeff.science at gmail dot com]

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

Bug ID: 67251
   Summary: gfortran does not faithfully preprocess the way cpp
does
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com
  Target Milestone: ---

I do not understand why gfortran -I. -E source.F does not give the same
result as cpp-5 -I. -E source.F.  It appears that gfortran does not properly
preprocessor #, ## and \.

This breaks NWChem and there is no obvious workaround.

 cat header.fh 
! comment
  integer foo
  external foo
#define DECL(a) \
  integer err_##a; \
  integer l_##a,k_##a;
#define ALLO(a,s) \
  err_##a=foo(s,#a,l_##a,k_##a); \
  if (.not.err_##a) call bar(PUSH#a,#s);

 cat source.F 
C
C OLD SCHOOL COMMENTS
C
  subroutine xyz(stuff)
  implicit none
#include header.fh
  integer stuff
  DECL(handle)
  ALLO(handle,100)
  print*,stuff
  return
  end


 gfortran -I. -E source.F 
# 1 source.F
# 1 built-in
# 1 command-line
# 1 source.F
C
C OLD SCHOOL COMMENTS
C
  subroutine xyz(stuff)
  implicit none

# 1 header.fh 1
! comment
  integer foo
  external foo
# 7 source.F 2
  integer stuff
  integer err_##handle;   integer l_##handle,k_##handle;
  err_##handle=foo(100,#handle,l_##handle,k_##handle);   if
(.not.err_##handle) call bar(PUSH#handle,#100);
  print*,stuff
  return
  end

 cpp-5 -I. -E source.F 
# 1 source.F
# 1 built-in
# 1 command-line
# 1 source.F
C
C OLD SCHOOL COMMENTS
C
  subroutine xyz(stuff)
  implicit none
# 1 header.fh 1
! comment
  integer foo
  external foo
# 7 source.F 2
  integer stuff
  integer err_handle; integer l_handle,k_handle;
  err_handle=foo(100,handle,l_handle,k_handle); if (.not.err_handle) call
bar(PUSHhandle,100);
  print*,stuff
  return
  end

 gfortran-5 -v
Using built-in specs.
COLLECT_GCC=gfortran-5
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/5.2.0/libexec/gcc/x86_64-apple-darwin14.4.0/5.2.0/lto-wrapper
Target: x86_64-apple-darwin14.4.0
Configured with: ../configure --build=x86_64-apple-darwin14.4.0
--prefix=/usr/local/Cellar/gcc/5.2.0
--libdir=/usr/local/Cellar/gcc/5.2.0/lib/gcc/5
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug
--disable-werror --with-pkgversion='Homebrew gcc 5.2.0 --without-multilib'
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin
--disable-nls --disable-multilib
Thread model: posix
gcc version 5.2.0 (Homebrew gcc 5.2.0 --without-multilib)

[Bug c/58016] stdatomic.h missing in 4.8.1

[jeff.science at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016

--- Comment #5 from Jeff Hammond jeff.science at gmail dot com ---
Can someone tell me where the appropriate place to define __STDC_NO_ATOMICS__
and __STDC_NO_THREADS__ in GCC so I can submit a patch?  I'd rather solve the
problem and take 1-2 steps forward towards C11 compliance rather than debate
the philosophical aspects of the problem.

[Bug c/58016] stdatomic.h missing in 4.8.1

[jeff.science at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016

Jeff Hammond jeff.science at gmail dot com changed:

   What|Removed |Added

 CC||jeff.science at gmail dot com

--- Comment #6 from Jeff Hammond jeff.science at gmail dot com ---
Created attachment 30568
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30568action=edit
patch to define macros indicating missing C11 support

If GCC defines __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__, it is no longer
non-compliant w.r.t. C11 to not provide stdatomic.h and threads.h.  This would
resolve bugs 53769 and 58016, albeit in a trivial way.

I will not be surprised at all if this patch is rejected, if for no other
reason than my institution has not signed a contributor agreement with FSF
(they almost certainly will if I ask).  My goal is to inspire someone else to
do it properly since it seems trivial and arguably necessary.

[Bug c/58016] stdatomic.h missing in 4.8.1

[jeff.science at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016

Jeff Hammond jeff.science at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Jeff Hammond jeff.science at gmail dot com ---
My patch was w.r.t. the trunk as of earlier today, not 4.8 but that's fine.  I
just subscribed to various GCC lists to track these developments.

I'll apply my patch locally so that I can use 4.8.1 and get the desired
behavior.

[Bug c/58016] New: stdatomic.h missing in 4.8.1

[jeff.science at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016

Bug ID: 58016
   Summary: stdatomic.h missing in 4.8.1
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeff.science at gmail dot com

GCC 4.8.1 provides a -std=c11 option that defines __STDC_VERSION__ = 201112L
and does not define __STDC_NO_ATOMICS__, hence is required to provide
stdatomic.h.  This requirement is not met.

This ticket is closely related to 53769 but I am not reporting the fact that
the macros aren't defined, but rather the missing header.

 cat test-c11-atomics.c 
#if __STDC_VERSION__ = 201112L
# ifdef __STDC_NO_ATOMICS__
#  error Your C11 compiler is not required to provide stdatomic.h
# else
#  include stdatomic.h
# endif
#else
# error Your C compiler isn't providing C11.
#endif

int main(int argc, char * argv[])
{
return 0;
}

 gcc-mp-4.8 -g -Wall -std=c11 test-c11-atomics.c 
test-c11-atomics.c:4:23: fatal error: stdatomic.h: No such file or directory
 #include stdatomic.h
   ^
compilation terminated.

 gcc-mp-4.8 -v
Using built-in specs.
COLLECT_GCC=gcc-mp-4.8
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.8.1/lto-wrapper
Target: x86_64-apple-darwin11
Configured with: ../gcc-4.8.1/configure --prefix=/opt/local
--build=x86_64-apple-darwin11
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.8
--with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local
--with-cloog=/opt/local --enable-cloog-backend=isl
--disable-cloog-version-check --enable-stage1-checking --disable-multilib
--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts
gcc48 4.8.1_0'
Thread model: posix
gcc version 4.8.1 (MacPorts gcc48 4.8.1_0) 

 uname -a
Darwin Jeffs-MacBook-Pro.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23
16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64

[Bug c/58016] stdatomic.h missing in 4.8.1

[jeff.science at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58016

--- Comment #2 from Jeff Hammond jeff.science at gmail dot com ---
If GCC doesn't support C11, it should not claim to support C11 via
__STDC_VERSION__.  The C11 standard definition isn't a recommendation from
which implementers can pick and choose based upon their priorities. 
Documentation an implementations failure to comply with a standard does not
absolve an implementation from lying about its features with ISO standard
macros.  The macro is part of the standard; the documentation is not.

In any case, there is an absolutely trivial way for GCC to satisfy the C11
standard with respect to stdatomic.h, and it involves __STDC_NO_ATOMICS__.  The
failure to define this macro or to provide stdatomic.h make GCC non-compliant
with C11, in which case __STDC_VERSION__ is defined improperly.

[Bug fortran/46340] internal compiler error: Segmentation fault building LAPACK 3.1.1

[jeff.science at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46340

Jeff jeff.science at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME

--- Comment #2 from Jeff jeff.science at gmail dot com 2010-11-07 15:00:53 
UTC ---
Yep, the latest version is fine.

Thanks.

[Bug fortran/46340] New: internal compiler error: Segmentation fault building LAPACK 3.1.1

[jeff.science at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46340

   Summary: internal compiler error: Segmentation fault building
LAPACK 3.1.1
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jeff.scie...@gmail.com


Created attachment 22305
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22305
the source file which induces the error

GotoBLAS2-1.13/lapack-3.1.1/SRC gfortran-4.6 -v -save-temps -O2
-m128bit-long-double -Wall  -m64 -fdefault-integer-8 -fPIC  -c sgesvd.f -o
sgesvd.o
Using built-in specs.
COLLECT_GCC=gfortran-4.6
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.6/lto-wrapper
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++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.6
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.6
--enable-linux-futex --without-system-libunwind --enable-gold
--with-plugin-ld=/usr/bin/gold --with-arch-32=i586 --with-tune=generic
--build=x86_64-suse-linux
Thread model: posix
gcc version 4.6.0 20100831 [trunk revision 163668] (SUSE Linux)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-m128bit-long-double' '-Wall'
'-m64' '-fdefault-integer-8' '-fPIC' '-c' '-o' 'sgesvd.o' '-mtune=generic'
'-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/4.6/f951 sgesvd.f -ffixed-form -quiet
-dumpbase sgesvd.f -m128bit-long-double -m64 -mtune=generic -march=x86-64
-auxbase-strip sgesvd.o -O2 -Wall -version -fdefault-integer-8 -fPIC
-fintrinsic-modules-path /usr/lib64/gcc/x86_64-suse-linux/4.6/finclude -o
sgesvd.s
GNU Fortran (SUSE Linux) version 4.6.0 20100831 [trunk revision 163668]
(x86_64-suse-linux)
compiled by GNU C version 4.6.0 20100831 [trunk revision 163668], GMP
version 4.2.3, MPFR version 2.3.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (SUSE Linux) version 4.6.0 20100831 [trunk revision 163668]
(x86_64-suse-linux)
compiled by GNU C version 4.6.0 20100831 [trunk revision 163668], GMP
version 4.2.3, MPFR version 2.3.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
sgesvd.f:542.21:

 WORK( 1 ) = MAXWRK
 1
Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at
(1)
sgesvd.f:3396.18:

  WORK( 1 ) = MAXWRK
  1
Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at
(1)
sgesvd.f: In function ‘sgesvd’:
sgesvd.f:145:0: warning: ‘wrkbl’ may be used uninitialized in this function
[-Wuninitialized]
sgesvd.f:586:0: warning: ‘mnthr’ may be used uninitialized in this function
[-Wuninitialized]
sgesvd.f:142:0: warning: ‘bdspac’ may be used uninitialized in this function
[-Wuninitialized]
sgesvd.f:1:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.opensuse.org/ for instructions.