[Bug target/121247] New: -fopenmp and -fopenacc can not be used together on nvptx and g++. Nvidia's nvc++ can use both

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121247 Bug ID: 121247 Summary: -fopenmp and -fopenacc can not be used together on nvptx and g++. Nvidia's nvc++ can use both Product: gcc Version: 15.1.0 Status: UNCONFIRMED

[Bug libgomp/121178] gcc openacc: libgomp: struct not mapped for detach operation if the borders are given on delete, nvc++ compiles correctly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121178 --- Comment #2 from Benjamin Schulz --- oh well sorry, in the last snipped that line #pragma omp target enter data map(to:t.data[0:20]) should not be there... it should be like: mytensor t; int strides[2]={1,2}; int extents[2]

[Bug libgomp/121178] gcc openacc: libgomp: struct not mapped for detach operation if the borders are given on delete, nvc++ compiles correctly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121178 --- Comment #1 from Benjamin Schulz --- and something else: Assume I want to create a struct with a temporary matrix only on gpu, with known extents, known strides, and just allocated data, that is not on the host. The mapping macros require t

[Bug libgomp/121178] New: gcc openacc: libgomp: struct not mapped for detach operation if the borders are given on delete, nvc++ compiles correctly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121178 Bug ID: 121178 Summary: gcc openacc: libgomp: struct not mapped for detach operation if the borders are given on delete, nvc++ compiles correctly Product: gcc Ve

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 --- Comment #17 from Benjamin Schulz --- Ah i forgot that mapping macro... So that is the correct code mytensor t; t.data=(double*)omp_target_alloc(sizeof(double)*20,omp_get_default_device()); t.strides=(int*)omp_target_alloc(sizeof(

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 --- Comment #16 from Benjamin Schulz --- Hm, I want to thank Andrew Pinski for pointing me to a post of mat colgrove from nvidia, https://forums.developer.nvidia.com/t/using-deviceptr-with-structs/136334 And to Tobias Burnus for his comment on

[Bug c++/121169] OpenACC allows members of strucs in OpenACC constructs. Nvidias nvc++ compiles them, gcc 15.1 rejects valid.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121169 --- Comment #5 from Benjamin Schulz --- and yes, this program runs, without causing an error...

[Bug c++/121169] OpenACC allows members of strucs in OpenACC constructs. Nvidias nvc++ compiles them, gcc 15.1 rejects valid.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121169 --- Comment #4 from Benjamin Schulz --- Yes, I would need to copyin t. But anways, nvc++ compiles, without any problem this here: #include struct mytensor { int *strides; int *extents; double *data; }; int main() { mytensor t; t.data=(d

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 Benjamin Schulz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/121170] New: gcc refuses to compile if a struct member variable appears in an OpenAcc construct, which nvc++ accepts

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121170 Bug ID: 121170 Summary: gcc refuses to compile if a struct member variable appears in an OpenAcc construct, which nvc++ accepts Product: gcc Version: 15.1.0 Status: UNCO

[Bug c++/121169] New: OpenACC allows members of strucs in OpenACC constructs. Nvidias nvc++ compiles them, gcc 15.1 rejects valid.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121169 Bug ID: 121169 Summary: OpenACC allows members of strucs in OpenACC constructs. Nvidias nvc++ compiles them, gcc 15.1 rejects valid. Product: gcc Version: 15.1.0

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 --- Comment #14 from Benjamin Schulz --- It turns out that there are indications in the OpenMP standard for C++ which show that the prevention of struct members was indeed deliberate. https://www.openmp.org/spec-html/5.2/openmpsu19.html "Unles

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 --- Comment #13 from Benjamin Schulz --- I suspect that the statement, which Tobias cites, does not forbid member variables of structs. I think that thid is an incorrect interpretation of the standard. What they probably wanted to forbid was t

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 --- Comment #12 from Benjamin Schulz --- a workaround that compiles is this: #include struct mytensor { int *strides; int *extents; double *data; }; int main() { mytensor t; t.data=(double*)omp_target_alloc(sizeof(double)*20,omp_get_default_

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 --- Comment #11 from Benjamin Schulz --- But it is interesting... indeed the problem also seems to cover other areas. For example, this here would compile: int main() { double data[20]; #pragma omp parallel for shared(data) for(int i=1;i<2

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 --- Comment #10 from Benjamin Schulz --- So no, if you read the standard correctly, then the mapping macros also require map([ [map-type-modifier[,] [map-type-modifier[,] ...] map-type : ] locator-list) So in openmp terminology, map also wan

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 --- Comment #9 from Benjamin Schulz --- Ok, now i see that the mapping macros have extended wording to allow members of structs, which is_device_ptr does not have: https://www.openmp.org/spec-html/5.0/openmpsu109.html https://www.openmp.org/sp

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 Benjamin Schulz changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 Benjamin Schulz changed: What|Removed |Added Attachment #61753|0 |1 is obsolete|

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 --- Comment #4 from Benjamin Schulz --- Comment on attachment 61753 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61753 mdspan_omp.h #include struct mytensor { int *strides; int *extents; double *data; }; int main() { mytensor t; t.dat

[Bug middle-end/120865] ICE in gimple-expr.cc:484

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865 Benjamin Schulz changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFI

[Bug middle-end/120865] ICE in gimple-expr.cc:484

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865 --- Comment #7 from Benjamin Schulz --- the correct output is now this one without -O The internal compiler error is at all o levels, -O1, O2, O3.. Interestingly -ffast-math works and leads to a considerable speed-up. Just using -fno-math-err

[Bug middle-end/120865] ICE in gimple-expr.cc:484

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865 Benjamin Schulz changed: What|Removed |Added Attachment #61751|mein_omp.cpp|main_omp.cpp description|

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 --- Comment #3 from Benjamin Schulz --- oh that last comment should have been made in another bug about an internal compiler error. Sorry.

[Bug libgomp/120865] ICE in gimple-expr.cc:484

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865 Benjamin Schulz changed: What|Removed |Added Attachment #61750|0 |1 is obsolete|

[Bug c/120753] is_device_ptr does not compile if given a pointer which is a member of a struct, i.e. is_device_ptr(u.ptr), where mystruct u; and struct mystruct{double *ptr;int something;}; will fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 --- Comment #2 from Benjamin Schulz --- Created attachment 61753 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61753&action=edit mdspan_omp.h mdspan_omp.h with the change in the #pragma omp target teams loop to the #pragma omp target tea

[Bug libgomp/120865] ICE in gimple-expr.cc:484

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865 --- Comment #4 from Benjamin Schulz --- Note that also the values in the last computation are wrong. I can, however, make them correct by writing #pragma omp target parallel for device(devicenum) or #pragma omp target teams distribute para

[Bug libgomp/120865] gimple-expr.cc:484

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865 --- Comment #3 from Benjamin Schulz --- Options were: -O1 -fopenmp -foffload=nvptx-none -fno-stack-protector -Wall Note that without -O i get the following: (i.e. without optimization, the program terminates ordinarily...) Ordinary matri

[Bug libgomp/120865] gimple-expr.cc:484

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865 --- Comment #2 from Benjamin Schulz --- Created attachment 61752 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61752&action=edit cmakelists.txt

[Bug libgomp/120865] gimple-expr.cc:484

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865 --- Comment #1 from Benjamin Schulz --- Created attachment 61751 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61751&action=edit mein_omp.cpp

[Bug libgomp/120865] New: gimple-expr.cc:484

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865 Bug ID: 120865 Summary: gimple-expr.cc:484 Product: gcc Version: 15.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee:

[Bug target/120835] on nvptx target with openmp, gcc 15.1 computes different results with differing -O levels.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120835 Benjamin Schulz changed: What|Removed |Added Attachment #61721|0 |1 is obsolete|

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #17 from Benjamin Schulz --- My code in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120835 apparently provokes gcc to yield different results for the same computation with differing -O optimization levels... I do not use any k

[Bug target/120835] on nvptx target with openmp, gcc 15.1 computes different results with differing -O levels.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120835 --- Comment #9 from Benjamin Schulz --- compile with -g -fopenmp -foffload=nvptx-none -fno-stack-protector lrt lm lc lstdc++ lmpi and various -O levels, of course

[Bug target/120835] on nvptx target with openmp, gcc 15.1 computes different results with differing -O levels.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120835 --- Comment #8 from Benjamin Schulz --- and please forgive me for the large test case. It is probably difficult to shrink this to a small example... I do not know why gcc behaves this way.

[Bug target/120835] on nvptx target with openmp, gcc 15.1 computes different results with differing -O levels.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120835 --- Comment #7 from Benjamin Schulz --- note that the matrix multiplication becomes only crazy with increasing -O when called within another function that does computations. correct are these: A Cholesky decomposition with the multiplicat

[Bug target/120835] on nvptx target with openmp, gcc 15.1 computes different results with differing -O levels.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120835 --- Comment #6 from Benjamin Schulz --- Created attachment 61727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61727&action=edit with O3

[Bug target/120835] on nvptx target with openmp, gcc 15.1 computes different results with differing -O levels.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120835 --- Comment #5 from Benjamin Schulz --- Created attachment 61726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61726&action=edit with-O2 results also wrong

[Bug target/120835] on nvptx target with openmp, gcc 15.1 computes different results with differing -O levels.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120835 --- Comment #4 from Benjamin Schulz --- Created attachment 61725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61725&action=edit results with O1, now the matrix multiplication becomes crazy

[Bug target/120835] on nvptx target with openmp, gcc 15.1 computes different results with differing -O levels.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120835 --- Comment #3 from Benjamin Schulz --- Created attachment 61724 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61724&action=edit correct results

[Bug target/120835] on nvptx target with openmp, gcc 15.1 computes different results with differing -O levels.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120835 --- Comment #2 from Benjamin Schulz --- Created attachment 61723 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61723&action=edit cmake lists.txt for easy switch of the compilers

[Bug target/120835] on nvptx target with openmp, gcc 15.1 computes different results with differing -O levels.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120835 --- Comment #1 from Benjamin Schulz --- Created attachment 61722 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61722&action=edit main which calls the library

[Bug target/120835] New: on nvptx target with openmp, gcc 15.1 computes different results with differing -O levels.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120835 Bug ID: 120835 Summary: on nvptx target with openmp, gcc 15.1 computes different results with differing -O levels. Product: gcc Version: 15.1.1 Status: UNCONFIRMED

[Bug target/120814] gcc does not compute on nvptx device when the loop is given over a variable whose pointer was offloaded in another function....

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814 Benjamin Schulz changed: What|Removed |Added Attachment #61703|0 |1 is obsolete|

[Bug target/120814] gcc does not compute on nvptx device when the loop is given over a variable whose pointer was offloaded in another function....

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814 Benjamin Schulz changed: What|Removed |Added Attachment #61704|0 |1 is obsolete|

[Bug target/120814] gcc does not compute on nvptx device when the loop is given over a variable whose pointer was offloaded in another function....

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814 --- Comment #4 from Benjamin Schulz --- what is also interesting: template bool matrix_multiply_dot( mdspan& A, mdspan& B, mdspan& C, bool on_gpu=false,bool default_device=true,int devicenum=0) you can use the upload member functions of md

[Bug target/120216] openmp unified shared memory currently requires pageableMemoryAccess perhaps Heterogeneous Memory Management (HMM) or even just managedMemory would suffice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120216 --- Comment #4 from Benjamin Schulz --- I did a benchmark here with my new card : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120679 In many nvidia graphics cards on a pci bus, unified shared memory, in form of hmm is currently not very suit

[Bug target/120814] gcc does not compute on nvptx device when the loop is given over a variable whose pointer was offloaded in another function....

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814 --- Comment #3 from Benjamin Schulz --- I want to note that if one comments out //A.device_upload(true); //B.device_upload(true); //C.device_alloc(true); and // C.host_update(true); in bool matrix_multiply_dot( mdspan& A, mdspan& B,

[Bug target/120814] New: gcc does not compute on nvptx device when the loop is given over a variable whose pointer was offloaded in another function....

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814 Bug ID: 120814 Summary: gcc does not compute on nvptx device when the loop is given over a variable whose pointer was offloaded in another function Product: gcc

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #16 from Benjamin Schulz --- Hi @all I just wanted to give you an update how my library progresses and what additional bugs I've found in GCC so far. Since some of you are familiar with my code, perhaps you can help to fix them, as

[Bug target/120814] gcc does not compute on nvptx device when the loop is given over a variable whose pointer was offloaded in another function....

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814 --- Comment #1 from Benjamin Schulz --- Created attachment 61704 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61704&action=edit mainn_omp.cpp contains the main program

[Bug target/120814] gcc does not compute on nvptx device when the loop is given over a variable whose pointer was offloaded in another function....

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120814 --- Comment #2 from Benjamin Schulz --- Created attachment 61705 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61705&action=edit cmakelists.txt cmakelists.txt to switch and see the different results between gcc-15.1 and clang-20.1

[Bug target/120753] is_device_ptr does not compile with pointers in struct elements..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 --- Comment #1 from Benjamin Schulz --- the context of this is of course that this causes problems if one wants to create an object or a struct entirely on gpu, say for temporary computations... A replacement that works is: #include struct a

[Bug target/120753] New: is_device_ptr does not compile with pointers in struct elements..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753 Bug ID: 120753 Summary: is_device_ptr does not compile with pointers in struct elements.. Product: gcc Version: 15.1.1 Status: UNCONFIRMED Severity: normal

[Bug target/120737] #pragma omp atomic fails on nvptx

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120737 Benjamin Schulz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/120737] #pragma omp atomic fails on nvptx

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120737 Benjamin Schulz changed: What|Removed |Added Attachment #61673|0 |1 is obsolete|

[Bug target/120737] New: #pragma omp atomic fails on nvptx

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120737 Bug ID: 120737 Summary: #pragma omp atomic fails on nvptx Product: gcc Version: 15.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug libgomp/120682] declare mapper does not work with templates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120682 --- Comment #9 from Benjamin Schulz --- Hi@all, thank you for your interesting replies. I guess the problem for the mapper and templates is that there are no pragma templates in C++. So this would probably indeed mean that one would have to ch

[Bug libgomp/120682] declare mapper does not work with templates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120682 --- Comment #6 from Benjamin Schulz --- Jakub Jelinek wrote: > The reason why it is invalid is that T lookup fails in the declare mapper > > definition. Yes, And that exactly is the problem. > #pragma omp declare mapper(myvec v) map(v, v.data

[Bug libgomp/120682] declare mapper does not work with templates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120682 --- Comment #4 from Benjamin Schulz --- Also the Openmp specification for mapper says: https://www.openmp.org/spec-html/5.2/openmpsu61.html A structure type T has a predefined default mapper that is defined as if by a declare mapper The quest

[Bug libgomp/120682] declare mapper does not work with templates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120682 --- Comment #3 from Benjamin Schulz --- oh of course withotu std, so typedef myvec doublevec; If one has to specify the datatype explicitly before one can use the openmp mapper, then the mapper pragma of openmp makes not much sense with templ

[Bug libgomp/120682] declare mapper does not work with templates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120682 --- Comment #2 from Benjamin Schulz --- Hi there, if that testcase is "invalid", then that means that the mapper statement does not work with template classes at all It would mean that for a struct with a template datatype template struct my

[Bug libgomp/120682] New: declare mapper does not work with templates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120682 Bug ID: 120682 Summary: declare mapper does not work with templates Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: li

[Bug target/120679] New: nvptx stl support for automatic mapping is slow and not asynchronous despite cuda supporting that. also #pragma omp requires unified_shared_memory is extremely slow compared t

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120679 Bug ID: 120679 Summary: nvptx stl support for automatic mapping is slow and not asynchronous despite cuda supporting that. also #pragma omp requires unified_shared_memory is

[Bug target/120216] openmp unified shared memory currently requires pageableMemoryAccess perhaps Heterogeneous Memory Management (HMM) or even just managedMemory would suffice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120216 --- Comment #3 from Benjamin Schulz --- I now noticed that nvidia's hmm is denoted as #pragma omp requires unified_address I do not know what unified_shared memory then is. Perhaps thats really reserved for onboard gpu's then. The followin

[Bug target/120216] openmp unified shared memory currently requires pageableMemoryAccess perhaps Heterogeneous Memory Management (HMM) or even just managedMemory would suffice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120216 --- Comment #2 from Benjamin Schulz --- Hi, the reason why I am mentioning this is the following: With an nvidia card that supports HMM, like mine, the nvidia nvcc compiler can, if one starts it with the managed parameter, be set such that it c

[Bug target/120216] openmp unified shared memory currently requires pageableMemoryAccess perhaps managedMemory would suffice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120216 --- Comment #1 from Benjamin Schulz --- Hi there, I now bought an RTX 5060 TI from Nvidia. Nvaccelinfo yields: Unified Addressing:Yes Managed Memory:Yes Concurrent Managed Memory: Yes Preemption Supported:

[Bug c++/118590] [14 regression] ICE with acc enter data copyin and dependent types since r14-7033-g1413af02d62182

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118590 --- Comment #13 from Benjamin Schulz --- Thanks. Works with 15.1

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #15 from Benjamin Schulz --- Hi there, my recent openmp version of the code seems to compile now (after a small change) executes without error on gcc 15.1 on gpu. So I now think about whether I have to re-convert some of it back

[Bug target/120216] New: openmp unified shared memory currently requires pageableMemoryAccess perhaps managedMemory would suffice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120216 Bug ID: 120216 Summary: openmp unified shared memory currently requires pageableMemoryAccess perhaps managedMemory would suffice Product: gcc Version: 15.1.0

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #14 from Benjamin Schulz --- By the way, the numbers are for simple tests and are correct, as for that segfault in the last test, this may have been an error owned by me. But I don't know yet, I guess I must look at my old code agai

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #13 from Benjamin Schulz --- Hi many thanks for the effort. Sorry for the late reply. In desperation, by now I have tried to switch my code to openmp entirely and compile it with clang... But openacc has more parallelization levels (

[Bug target/118794] The attached c++ openmp offload code fails, because the c sqrt function makes nonlocal gotos..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118794 --- Comment #8 from Benjamin Schulz --- with this here it is satisfied: // Normalize v T norm=0; // T norm=fabs(gpu_dot_product_w(v,v)); T normc= sqrt(norm); // const T normc=norm; #pragma omp parallel

[Bug target/118794] The attached c++ openmp offload code fails, because the c sqrt function makes nonlocal gotos..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118794 --- Comment #7 from Benjamin Schulz --- with this here it is satisfied: // Normalize v T norm=0; // T norm=fabs(gpu_dot_product_w(v,v)); T normc= sqrt(norm); // const T normc=norm; #pragma omp parallel

[Bug target/118794] The attached c++ openmp offload code fails, because the c sqrt function makes nonlocal gotos..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118794 --- Comment #6 from Benjamin Schulz --- Hi thanks for the fast reply. Unfortunately none of these works... (yes, putting in the -fno-math-errno option also raises this error, even if i put it into -offload... even if i try -foffload= -fno-math

[Bug target/118794] The attached c++ openmp offload code fails, because the c sqrt function makes nonlocal gotos..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118794 --- Comment #3 from Benjamin Schulz --- gcc --version gcc (Gentoo 14.2.1_p20241221 p7) 14.2.1 20241221

[Bug target/118794] The attached c++ openmp offload code fails, because the c sqrt function makes nonlocal gotos..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118794 --- Comment #2 from Benjamin Schulz --- Created attachment 60424 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60424&action=edit cmakelists.txt

[Bug target/118794] The attached c++ openmp offload code fails, because the c sqrt function makes nonlocal gotos..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118794 --- Comment #1 from Benjamin Schulz --- Created attachment 60423 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60423&action=edit main.cpp

[Bug target/118794] New: The attached c++ openmp offload code fails, because the c sqrt function makes nonlocal gotos..

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118794 Bug ID: 118794 Summary: The attached c++ openmp offload code fails, because the c sqrt function makes nonlocal gotos.. Product: gcc Version: 14.2.1 Status: UNCONFIRMED

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #11 from Benjamin Schulz --- if i write something like this: SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fopenacc -foffload=nvptx-none -foffload=-malias -fcf-protection=none -fno-stack-protector -U_FORTIFY_SOURCE -std=c++23 -no-pie")

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #10 from Benjamin Schulz --- the newly attached files work with nvc++ from nvidia. but nvidia has difficulties compiling the openmp part. so it would be good if i could compile this with gcc. What must I do to enable aliasing when bu

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #9 from Benjamin Schulz --- Created attachment 60373 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60373&action=edit cmakelists.txt

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #8 from Benjamin Schulz --- Created attachment 60372 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60372&action=edit main.cpp

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 Benjamin Schulz changed: What|Removed |Added Attachment #60176|0 |1 is obsolete|

[Bug target/118738] the following code compiles with nvc++ and even clang and raises an internal Compiler-error: in expand_UNIQUE, bei internal-fn.cc:3302

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118738 --- Comment #2 from Benjamin Schulz --- Created attachment 60370 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60370&action=edit cmakelists.txt

[Bug target/118738] the following code compiles with nvc++ and even clang and raises an internal Compiler-error: in expand_UNIQUE, bei internal-fn.cc:3302

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118738 --- Comment #1 from Benjamin Schulz --- Created attachment 60369 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60369&action=edit main.cpp

[Bug target/118738] New: the following code compiles with nvc++ and even clang and raises an internal Compiler-error: in expand_UNIQUE, bei internal-fn.cc:3302

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118738 Bug ID: 118738 Summary: the following code compiles with nvc++ and even clang and raises an internal Compiler-error: in expand_UNIQUE, bei internal-fn.cc:3302 Product: gcc

[Bug target/118590] internal compiler error: in build_omp_array_section, bei cp/typeck.cc:4823

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118590 --- Comment #3 from Benjamin Schulz --- gcc --version gcc (Gentoo 14.2.1_p20241221 p7) 14.2.1 20241221

[Bug target/118590] internal compiler error: in build_omp_array_section, bei cp/typeck.cc:4823

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118590 --- Comment #2 from Benjamin Schulz --- Created attachment 60226 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60226&action=edit cmakelists.txt

[Bug target/118590] internal compiler error: in build_omp_array_section, bei cp/typeck.cc:4823

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118590 --- Comment #1 from Benjamin Schulz --- Created attachment 60225 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60225&action=edit main_acc

[Bug target/118590] New: internal compiler error: in build_omp_array_section, bei cp/typeck.cc:4823

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118590 Bug ID: 118590 Summary: internal compiler error: in build_omp_array_section, bei cp/typeck.cc:4823 Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: n

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #6 from Benjamin Schulz --- how do I do that? -malias this is not a compiler option that is listed. What is strange: When i make a simple test program in c, i.e. without classes, then I can define functions in a #pragma omp target

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101544 --- Comment #18 from Benjamin Schulz --- Interesting. Similarly as in clang, after the printf issue was resolved, a simple test script shows: Number of available devices 1 but also, firsttest runs on target Well, I have a gpu, and a cpu. th

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101544 --- Comment #17 from Benjamin Schulz --- -U_FORTIFY_SOURCE worked. Thanks Sam.

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101544 --- Comment #16 from Benjamin Schulz --- "BTW, if you're calling "new" in the offload kernel then you're probably "doing it wrong"," I do not think so. For more complex mathematical algorithms, there are many situations, where we need temporary

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101544 --- Comment #12 from Benjamin Schulz --- In my view, not only the new command is important, but also things like printf, which also does not exist on the target, apparently. The problem is that with openmp, you can only check whether you are re

[Bug target/118520] New: compiles with clang on openmp target, but gcc fails to compile with unresolved symbol __cxa_throw_bad_array_new_length

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118520 Bug ID: 118520 Summary: compiles with clang on openmp target, but gcc fails to compile with unresolved symbol __cxa_throw_bad_array_new_length Product: gcc Versi

[Bug c++/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 Benjamin Schulz changed: What|Removed |Added Target|nvptx | Component|target

[Bug c++/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 Benjamin Schulz changed: What|Removed |Added Target|nvptx | Component|target

[Bug c++/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #1 from Benjamin Schulz --- Created attachment 60177 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60177&action=edit main.cpp

  1   2   >