[Bug middle-end/60102] powerpc fp-bit ices at dwf_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 Cesar Philippidis changed: What|Removed |Added CC||cesar at codesourcery dot com --- Comment #6 from Cesar Philippidis --- I've found a similar problem with dwf_regno() when I tried to bootstrap a ppc-eabispe compiler. The problem there is the register aliasing of r0 between 32 and 64-bit modes. The rs6000 backend uses pseudo registers to disambiguate those two usages. I've posted a patch here <http://gcc.gnu.org/ml/gcc-patches/2014-04/msg02064.html>, but it hasn't been reviewed yet.
[Bug fortran/63857] New: fixed form OpenACC directive ICE with -fopenacc -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63857 Bug ID: 63857 Summary: fixed form OpenACC directive ICE with -fopenacc -fopenmp Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cesar at codesourcery dot com Created attachment 33964 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33964&action=edit test case The attached test case causes gfortran to ICE when -fopenmp is used with -fopenacc. It looks like there is a problem with the way that continuations are handled in openmp/openacc directives.
[Bug fortran/63858] New: fixed form OpenACC directive ICE with -fopenacc -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63858 Bug ID: 63858 Summary: fixed form OpenACC directive ICE with -fopenacc -fopenmp Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cesar at codesourcery dot com The attached test case causes gfortran to ICE when -fopenmp is used with -fopenacc. It looks like there is a problem with the way that continuations are handled in openmp/openacc directives.
[Bug fortran/63859] New: OpenACC DEVICE_RESIDENT clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63859 Bug ID: 63859 Summary: OpenACC DEVICE_RESIDENT clause Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cesar at codesourcery dot com The OpenACC DEVICE_RESIDENT clause isn't fully supported in gfortran.
[Bug fortran/63861] New: OpenACC coarray ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63861 Bug ID: 63861 Summary: OpenACC coarray ICE Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cesar at codesourcery dot com Coarrays in OpenACC accelerated regions causes an ICE in gfortran. The test case gcc/testsuite/gfortran.dg/goacc/coarray.f95 reproduces this failure. It's unclear whether OpenACC 2.0a even supports coarrays. Regardless, this test case shouldn't cause an ICE.
[Bug fortran/63858] fixed form OpenACC directive ICE with -fopenacc -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63858 --- Comment #2 from Cesar Philippidis --- Created attachment 33967 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33967&action=edit fixed-form ICE
[Bug fortran/63858] fixed form OpenACC directive ICE with -fopenacc -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63858 --- Comment #4 from Cesar Philippidis --- *** Bug 63857 has been marked as a duplicate of this bug. ***
[Bug fortran/63857] fixed form OpenACC directive ICE with -fopenacc -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63857 Cesar Philippidis changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Cesar Philippidis --- Yeah. For some reason, I thought I had two specific bugs with -fopenacc -fopenmp. I'll close this one as a duplicate. *** This bug has been marked as a duplicate of bug 63858 ***
[Bug fortran/63247] New: fortran array alignment in omp target map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63247 Bug ID: 63247 Summary: fortran array alignment in omp target map Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: cesar at codesourcery dot com I've noticed that lower_omp_target is not passing the proper pointer alignment to libgomp for fortran array maps. While this isn't a problem for trunk, it does affect our nvptx target. Here is a test case: program test implicit none integer a(5) a = 10; write (*, '(a,Z16)') 'address of a = ', loc(a) !$omp target map(a(1:5)) a(1) = 5 a(2) = 5 a(3) = 5 a(4) = 5 a(5) = 5 !$omp end target end program test Here's my gdb session: Breakpoint 5, lower_omp_target (gsi_p=, ctx=) at ../../../gcc/gcc/omp-low.c:10191 10191CONSTRUCTOR_APPEND_ELT (vkind, purpose, (gdb) p talign $10 = 2 (gdb) p ovar $11 = (tree) (gdb) pt warning: Expression is not an assignment (and might have no effect) unit size align 32 symtab 0 alias set -1 canonical type 0x76303690 precision 32 min max pointer_to_this > type_2 BLK size unit size align 32 symtab 0 alias set -1 canonical type 0x7643e3f0 domain DI size unit size align 64 symtab 0 alias set -1 canonical type 0x7643e738 precision 64 min max > pointer_to_this > addressable used decl_0 BLK file /home/cphilipp/tools/nvidia/demos/fortran-tests/pointer-align-2.f90 line 4 col 0 size unit size align 32 context > (gdb) p talign $12 = 2 How should this issue be resolved? I think the fortran FE behavior is correct. Should lower_omp_target have something like this if (tkind == OMP_CLAUSE_MAP_POINTER) talign = POINTER_SIZE / BITS_PER_UNIT; or should libgomp correct the alignment for OMP_CLAUSE_MAP_POINTER? It should be noted the C FE doesn't have this problem with arrays. Thanks, Cesar
