[Bug analyzer/115203] [15 Regression] Build fail with non LANG=C in analyzer self test: ICE in fail_formatted at selftest.cc:63 / tree-diagnostic-path.cc:2158: test_control_flow_5: FAIL: ASSERT_STREQ

2024-05-23 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115203 --- Comment #2 from Tobias Burnus --- Indeed, the suggestion was not to disable the translations in general. A similar issue shows up when running the testsuite. There is it solved by "setenv LANG C" and "setenv LANG C.ASCII" – while various

[Bug analyzer/115203] New: [15 Regression] Build fail with non LANG=C in analyzer self test: ICE in fail_formatted at selftest.cc:63 / tree-diagnostic-path.cc:2158: test_control_flow_5: FAIL: ASSERT_S

2024-05-23 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115203 Bug ID: 115203 Summary: [15 Regression] Build fail with non LANG=C in analyzer self test: ICE in fail_formatted at selftest.cc:63 / tree-diagnostic-path.cc:2158: test_control_flow_5:

[Bug fortran/115151] New: procedure(acos) [,pointer] :: p - is wrongly rejected

2024-05-18 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115151 Bug ID: 115151 Summary: procedure(acos) [,pointer] :: p - is wrongly rejected Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal

[Bug fortran/115150] [12/13/14/15 Regression] SHAPE of zero-sized array yields a negative value

2024-05-18 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115150 Tobias Burnus changed: What|Removed |Added Target Milestone|--- |12.5 CC|

[Bug fortran/115150] New: [12/13/14/15 Regression] SHAPE of zero-sized array yields a negative value

2024-05-18 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115150 Bug ID: 115150 Summary: [12/13/14/15 Regression] SHAPE of zero-sized array yields a negative value Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords:

[Bug fortran/44744] Missing -fcheck=bounds diagnostic for function assignment with tmp array

2024-05-18 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44744 --- Comment #5 from Tobias Burnus --- (In reply to Tobias Burnus from comment #4) > Another variant from lsdalton – or rather the BTW: I have not verified that the cause is the same (temporary variable), but it seems to be likely. When

[Bug fortran/44744] Missing -fcheck=bounds diagnostic for function assignment with tmp array

2024-05-18 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44744 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment

[Bug c/113905] [OpenMP] Declare variant rejects variant-function re-usage

2024-05-17 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905 --- Comment #1 from Tobias Burnus --- Ups, testcase was lost. Re-written from scratch: --- int var1() { return 1; } int var2() { return 2; } #pragma omp declare variant (var1) match(construct={target}) #pragma omp declare

[Bug fortran/104621] [OpenMP] Issues with 'declare variant'

2024-05-17 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104621 --- Comment #1 from Tobias Burnus --- This got fixed for OpenMP 6 via OpenMP spec pull request #3383, adding: * A declarative directive must be specified in the specification part after all 'USE', 'IMPORT' and 'IMPLICIT' statements. * If a

[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190

2024-04-23 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 --- Comment #2 from Tobias Burnus --- The difference between the failing program and a working program (pointer-assignment in 'sub' comment out) is: failing: 'type' in gfc_omp_clause_default_ctor is '

[Bug middle-end/114754] New: [OpenMP] Missing 'uses_allocators' diagnostic

2024-04-17 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114754 Bug ID: 114754 Summary: [OpenMP] Missing 'uses_allocators' diagnostic Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic, openmp

[Bug fortran/103496] [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity'

2024-04-12 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496 --- Comment #4 from Tobias Burnus --- (In reply to anlauf from comment #3) > The code in comment#0 compiles at r14-9893-gded646c91d2c0f > and gives the indicated results. which is the commit: Fortran: fix argument checking of intrinsics

[Bug middle-end/113006] OpenMP 5 - lvalue parsing support for map/to/from clause

2024-04-08 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113006 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

2024-04-08 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #30 from Tobias Burnus --- (In reply to rguent...@suse.de from comment #29) > Might be for \r\n line endings? New lines are handled slightly differently – and \f and \v don't seem to be handled at all. Comparing the result with

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

2024-04-08 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #28 from Tobias Burnus --- Created attachment 57896 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57896=edit Testcase It seems as if 'tabs' cause problems, e.g. for: profile_single_file= .true. where there are

[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors

2024-04-05 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596 --- Comment #6 from Tobias Burnus --- (In reply to sandra from comment #5) > Tobias, it looks to me like you missed the connection ... No, I didn't - I did link it (cf. top of comment 3) — but I just cannot read :-/ Hence, for (1) *teams*

[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors

2024-04-05 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596 --- Comment #4 from Tobias Burnus --- > For selector construct = {teams, parallel, for} > score1 = 29 score2 = 29 > --- > > The constructs[i]'s score look fine. > > But I wonder why score == 29 and not 28. Answer:

[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors

2024-04-05 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596 --- Comment #3 from Tobias Burnus --- The scoring is according to TR12: > Each trait selector for which the corresponding trait appears > in the construct trait set in the OpenMP context is given the > value 2^(p−1) where p is the position of

[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors

2024-04-05 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114596 --- Comment #2 from Tobias Burnus --- Crossref to the OpenMP spec discussions [not publicly available] related to the scoring: * Jakub asked about this testcase in an omp-lang in the email 2019/016447.html (w/o getting a reply. * He then

[Bug other/111966] GCN '--with-arch=[...]' not considered for 'mkoffload' default 'elf_arch'

2024-04-03 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111966 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug libgomp/114445] New: [OpenMP] indirect - potential race when creating reverse-offload hash

2024-03-23 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114445 Bug ID: 114445 Summary: [OpenMP] indirect - potential race when creating reverse-offload hash Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: openmp,

[Bug target/114419] [GCC < 14] amdgcn offload compiler fails to build with amdgcn tools based on LLVM 18

2024-03-22 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114419 Tobias Burnus changed: What|Removed |Added CC||ams at gcc dot gnu.org,

[Bug libgomp/114335] OpenACC: use of accelerator constant/read-only memory for "readonly" modifier mappings

2024-03-14 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114335 Tobias Burnus changed: What|Removed |Added Keywords||missed-optimization,

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

2024-03-14 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #19 from Tobias Burnus --- Regarding the LAPACK issue: Actually, I am inclined to * regard it as LAPACK bug * that was also fixed upstream, see comment 6, to make g95 happy. as ';' is not a value separator - while ' ;' is fine,

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

2024-03-14 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 Tobias Burnus changed: What|Removed |Added Attachment #57693|0 |1 is obsolete|

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

2024-03-14 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #34 from Tobias Burnus --- Created attachment 57693 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57693=edit Extended testcase; comment shows results for gfortran(trunk),ifort,ifx,flang See PR114304 for some related issue

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

2024-03-12 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #14 from Tobias Burnus --- Created attachment 57680 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57680=edit Testcase with decimal=COMMA, passes with ifort/ifx/flang - fails with gfortran > commit

[Bug libfortran/114304] [14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

2024-03-11 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #6 from Tobias Burnus --- [For completeness: The LAPACK testsuite change Richard mentioned in comment 2 is https://github.com/Reference-LAPACK/lapack/commit/64e8a7500d817869e5fcde35afd39af8bc7a8086 - That's for g95 and was applied

[Bug libfortran/114304] [14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

2024-03-11 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 Tobias Burnus changed: What|Removed |Added Keywords||wrong-code Summary|[14

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

2024-03-11 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment

[Bug libfortran/114304] [14 Regression] Rejects lapack test

2024-03-11 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #4 from Tobias Burnus --- Created attachment 57668 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57668=edit Testcase Testresults of the attached testcase: See also https://godbolt.org/z/q4rG61EvW The attached testcase

[Bug libfortran/114304] [14 Regression] Rejects lapack test

2024-03-11 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 Tobias Burnus changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug fortran/114283] New: [OpenMP] Dummy procedures/proc pointers and 'defaultmap', 'default', 'firstprivate' etc.

2024-03-08 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114283 Bug ID: 114283 Summary: [OpenMP] Dummy procedures/proc pointers and 'defaultmap', 'default', 'firstprivate' etc. Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug middle-end/114282] New: [OpenMP] Implicit mapping of function/procedure pointers should use 'firstprivate'

2024-03-08 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114282 Bug ID: 114282 Summary: [OpenMP] Implicit mapping of function/procedure pointers should use 'firstprivate' Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c++/110347] [OpenMP] private/firstprivate of a C++ member variable mishandled

2024-03-01 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110347 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug middle-end/113436] [OpenMP] 'allocate' clause has no effect for (first)private on 'target' directives

2024-03-01 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113436 --- Comment #2 from Tobias Burnus --- As mentioned in comment 0, PR110347's testcase (r14-9257-g4f82d5a95a244d) contains '#if 0' code which has to be enabled once this bug is fixed. Please remember to take care of: *

[Bug libgomp/113867] [14 Regression][OpenMP] Wrong code with mapping pointers in structs

2024-02-21 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867 --- Comment #5 from Tobias Burnus --- For: int *q; #pragma omp target device(y5) map(q, q[:5]) GCC currently generates: map(tofrom:q [len: 8]) map(tofrom:*q.4_1 [len: 20]) map(attach:q [bias: 0]) Expected: 'alloc:' instead of

[Bug fortran/114002] New: [OpenACC][OpenACC 3.3] Add 'acc_attach'/'acc_detach' routine

2024-02-19 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114002 Bug ID: 114002 Summary: [OpenACC][OpenACC 3.3] Add 'acc_attach'/'acc_detach' routine Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: openacc

[Bug fortran/113997] Bogus 'Warning: Interface mismatch in global procedure' with C binding

2024-02-19 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997 --- Comment #3 from Tobias Burnus --- > Anyway, renaming the binding label, like >subroutine acc_attach_c(x) bind(C, name="acc_attach_renamed") > makes the code compile. Well, the code *does* compile as it is only a warning. * * * I

[Bug fortran/113997] New: Bogus 'Warning: Interface mismatch in global procedure' with C binding

2024-02-19 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997 Bug ID: 113997 Summary: Bogus 'Warning: Interface mismatch in global procedure' with C binding Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords:

[Bug target/113331] AMDGCN: Compilation failure due to duplicate .LEHB/.LEHE symbols

2024-02-16 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113331 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment

[Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled

2024-02-13 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904 --- Comment #3 from Tobias Burnus --- See comment 1 for remaining to-do items. I also note that the Fortran resolution comes too early - during parsing - as the following shows: module m implicit none contains subroutine test !$omp declare

[Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled

2024-02-13 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904 --- Comment #1 from Tobias Burnus --- Patch for rejecting non-const arguments in Fortran (wrong-code bit) to bring it in line with C/C++: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645488.html * * * TODO as follow up: * Permit

[Bug middle-end/113906] New: [OpenMP][5.2] 'construct' context selectors lack many constructs

2024-02-13 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113906 Bug ID: 113906 Summary: [OpenMP][5.2] 'construct' context selectors lack many constructs Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: openmp,

[Bug c/113905] New: [OpenMP] Declare variant rejects variant-function re-usage

2024-02-13 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113905 Bug ID: 113905 Summary: [OpenMP] Declare variant rejects variant-function re-usage Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: openmp,

[Bug middle-end/113904] New: [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled

2024-02-13 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904 Bug ID: 113904 Summary: [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug libgomp/113867] [14 Regression][OpenMP] Wrong code with mapping pointers in structs

2024-02-13 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867 --- Comment #4 from Tobias Burnus --- Also not handled: struct s { int *p; } s1; ... #pragma omp target map(s1.p[:N]) p[0] = p[N-1] = 99; Here, the pointer attachment is missing. See also PR113724 's attachment 57407 for a testcase

[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1

2024-02-13 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 --- Comment #6 from Tobias Burnus --- Created attachment 57407 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57407=edit C testcase – passes with patch (except for '#if 0'ed PR113867 issues) DejaGNU-ified testcase for this PR and ('#if

[Bug libgomp/113867] [14 Regression][OpenMP] Wrong code with mapping pointers in structs

2024-02-12 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867 --- Comment #3 from Tobias Burnus --- Created attachment 57398 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57398=edit Patch - handling the libgomp issue Possible patch - lightly tested. This fixes the issue in libgomp. While always

[Bug libgomp/113867] [14 Regression][OpenMP] Wrong code with mapping pointers in structs

2024-02-12 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867 Tobias Burnus changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org

[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1

2024-02-10 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 --- Comment #5 from Tobias Burnus --- The runtime issue is now PR113867.

[Bug middle-end/113867] [14 Regression][OpenMP] Wrong code with mapping pointers in structs

2024-02-10 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867 --- Comment #1 from Tobias Burnus --- Created attachment 57382 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57382=edit Fortran testcase, kind of, as pointer + pointee mapping cannot be split (working) For completeness, a Fortran

[Bug middle-end/113867] New: [14 Regression][OpenMP] Wrong code with mapping pointers in structs

2024-02-10 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867 Bug ID: 113867 Summary: [14 Regression][OpenMP] Wrong code with mapping pointers in structs Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: openmp,

[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1

2024-02-10 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 --- Comment #4 from Tobias Burnus --- Created attachment 57377 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57377=edit Fixes the ICE – might paper over a real issue; doesn't fix the run-time issue → TODO + 'data'-issue in PR comment 4

[Bug fortran/113840] New: [OpenACC] !$acc loop seq – bogus rejection of Fortran's EXIT/CYCLE + C/C++ break/continue

2024-02-08 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113840 Bug ID: 113840 Summary: [OpenACC] !$acc loop seq – bogus rejection of Fortran's EXIT/CYCLE + C/C++ break/continue Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1

2024-02-07 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 --- Comment #3 from Tobias Burnus --- Inside omp_build_struct_sibling_lists, the following assignment: 11654 grp->grp_start = new_next; has on the LHS the [3] array with value: (gdb) p *grp $147 = {grp_start = 0x771f9688,

[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1

2024-02-07 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 --- Comment #2 from Tobias Burnus --- Inside: omp_build_struct_sibling_lists new_next = omp_accumulate_sibling_list (region_type, code, struct_map_to_clause, *grpmap,

[Bug tree-optimization/113731] [14 regression] ICE when building libbsd since r14-8768-g85094e2aa6dba7

2024-02-07 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113731 --- Comment #10 from Tobias Burnus --- (In reply to Tamar Christina from comment #9) > (In reply to Matthias Klose from comment #8) > > the proposed patch doesn't fix the amdgcn-amdhsa bootstrap. > > So what is the error with the patch? The

[Bug middle-end/113724] [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1

2024-02-06 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 --- Comment #1 from Tobias Burnus --- Debugging shows: In gimplify_adjust_omp_clauses (line numbers are off by 1 as I have a #pragma GCC optimize("O0") on top of the file): 13717 groups = omp_gather_mapping_groups (list_p); ... 13720

[Bug middle-end/113771] New: [14 Regression][GCN] ICE during GIMPLE pass: vect in vect_transform_loop tree-vect-loop.cc:11969

2024-02-05 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113771 Bug ID: 113771 Summary: [14 Regression][GCN] ICE during GIMPLE pass: vect in vect_transform_loop tree-vect-loop.cc:11969 Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug target/113721] [14 Regression][OpenMP][nvptx] cuCtxSynchronize fail when calling 'free' in the target regsion

2024-02-02 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113721 Tobias Burnus changed: What|Removed |Added Resolution|--- |WORKSFORME

[Bug middle-end/113724] New: [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1

2024-02-02 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724 Bug ID: 113724 Summary: [14 Regression][OpenMP] ICE (segfault) when mapping a struct in omp_gather_mapping_groups_1 Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug target/113721] New: [14 Regression][OpenMP][nvptx] cuCtxSynchronize fail when calling 'free' in the target regsion

2024-02-02 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113721 Bug ID: 113721 Summary: [14 Regression][OpenMP][nvptx] cuCtxSynchronize fail when calling 'free' in the target regsion Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug target/113615] internal compiler error: in extract_insn, at recog.cc:2812

2024-01-29 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113615 --- Comment #4 from Tobias Burnus --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644181.html It fixes this issue but two other kind of issues I still see for gfx1100.

[Bug libgomp/110813] [OpenMP] omp_target_memcpy_rect (+ strided 'target update'): Improve GCN performance and contiguous subranges

2024-01-28 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110813 --- Comment #4 from Tobias Burnus --- The GCN specific part has been applied to GCC 14 mainline in commit: https://gcc.gnu.org/g:a17299c17afeb92a56ef716d2d6380c8538493c4 Unhandled: * Strided and optimized strided copy (incl. generic part of

[Bug target/113615] internal compiler error: in extract_insn, at recog.cc:2812

2024-01-28 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113615 Tobias Burnus changed: What|Removed |Added CC||ams at gcc dot gnu.org --- Comment #2

[Bug target/113645] New: [amdgcn][gfx1030][gfx1100] ICE in RTL pass: vregs with -O3: unrecognizable insn (vector reductions)

2024-01-28 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113645 Bug ID: 113645 Summary: [amdgcn][gfx1030][gfx1100] ICE in RTL pass: vregs with -O3: unrecognizable insn (vector reductions) Product: gcc Version: 14.0 Status:

[Bug libgomp/113513] [OpenMP] libgomp: cuCtxGetDevice error with OMP_DISPLAY_ENV=true OMP_TARGET_OFFLOAD="mandatory" for libgomp.c/target-52.c

2024-01-22 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113513 --- Comment #2 from Tobias Burnus --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643648.html

[Bug other/111966] GCN '--with-arch=[...]' not considered for 'mkoffload' default 'elf_arch'

2024-01-22 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111966 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org

[Bug libgomp/113513] [OpenMP] libgomp: cuCtxGetDevice error with OMP_DISPLAY_ENV=true OMP_TARGET_OFFLOAD="mandatory" for libgomp.c/target-52.c

2024-01-20 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113513 --- Comment #1 from Tobias Burnus --- Looking at the called GOMP_OFFLOAD_* function, in the failing case, there is: ... DEBUG GOMP_OFFLOAD_run DEBUG GOMP_OFFLOAD_dev2host DEBUG GOMP_OFFLOAD_free DEBUG: nvptx_attach_host_thread_to_device - 0

[Bug libgomp/113513] New: [OpenMP] libgomp: cuCtxGetDevice error with OMP_DISPLAY_ENV=true OMP_TARGET_OFFLOAD="mandatory" for libgomp.c/target-52.c

2024-01-19 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113513 Bug ID: 113513 Summary: [OpenMP] libgomp: cuCtxGetDevice error with OMP_DISPLAY_ENV=true OMP_TARGET_OFFLOAD="mandatory" for libgomp.c/target-52.c Product: gcc

[Bug middle-end/113439] New: [OpenMP] Add more collapse testcases mixing precisions, in particular (unsigned) int vs. _BigInt

2024-01-17 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113439 Bug ID: 113439 Summary: [OpenMP] Add more collapse testcases mixing precisions, in particular (unsigned) int vs. _BigInt Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug middle-end/113436] [OpenMP] 'allocate' clause has no effect for (first)private on 'target' directives

2024-01-17 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113436 --- Comment #1 from Tobias Burnus --- BTW: The attach testcase misses 'firstprivate', which obviously needs to be handled as well.

[Bug middle-end/113436] New: [OpenMP] 'allocate' clause has no effect for (first)private on 'target' directives

2024-01-17 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113436 Bug ID: 113436 Summary: [OpenMP] 'allocate' clause has no effect for (first)private on 'target' directives Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug fortran/108382] [12/13/14 Regression] Incorrect parsing when acc and omp coexist and -fopenmp -fopenacc is used.

2024-01-12 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108382 --- Comment #2 from Tobias Burnus --- Fixed-form Fortran likewise fails for: !$acc enter !$acc& data !$omp flush !$omp& RELEASE end ! fails in this line: "Bad continuation line"

[Bug target/113288] [i386] Missing #define for -mavx10.1-256 and -mavx10.1-512

2024-01-09 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288 --- Comment #4 from Tobias Burnus --- The(In reply to Haochen Jiang from comment #3) > Adding them are quite straightforward. I guess so. Note: this PR is about the #define in gcc/config/i386, only. > But I am not quite sure how the whole >

[Bug target/113288] New: [i386] Missing #define for -mavx10.1-256 and -mavx10.1-512

2024-01-08 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113288 Bug ID: 113288 Summary: [i386] Missing #define for -mavx10.1-256 and -mavx10.1-512 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug libgomp/113216] New: [OpenMP] Improve omp_target_is_accessible

2024-01-03 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113216 Bug ID: 113216 Summary: [OpenMP] Improve omp_target_is_accessible Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority:

[Bug libgomp/113213] New: [OpenMP] Update omp_target_is_present / omp_target_is_accessible handling for NULL

2024-01-03 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113213 Bug ID: 113213 Summary: [OpenMP] Update omp_target_is_present / omp_target_is_accessible handling for NULL Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug middle-end/113199] New: [14 Regression][GCN] ICE (segfault) when compiling Newlib

2024-01-02 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113199 Bug ID: 113199 Summary: [14 Regression][GCN] ICE (segfault) when compiling Newlib Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code

[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420

2023-12-28 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163 --- Comment #6 from Tobias Burnus --- and for that condition, we have: 3375 if (!integer_onep (*step_vector)) (gdb) p debug_tree(*step_vector) constant 8>

[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420

2023-12-28 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163 --- Comment #5 from Tobias Burnus --- While higher at the call stack: #3 0x0148714f in vect_transform_loop (loop_vinfo=loop_vinfo@entry=0x350f2a0, loop_vectorized_call=loop_vectorized_call@entry=0x0) at

[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420

2023-12-28 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163 --- Comment #2 from Tobias Burnus --- Created attachment 56958 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56958=edit Reduced testcase ( $ amdgcn-amdhsa-gcc -g -O2 inp5.i -march=gfx900 during GIMPLE pass: vect inp5.i: In function

[Bug middle-end/113163] New: [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420

2023-12-28 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163 Bug ID: 113163 Summary: [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420 Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug middle-end/113067] [OpenMP][5.1] Context selector - handle 'implementation={requires(...)}'

2023-12-18 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113067 --- Comment #1 from Tobias Burnus --- Created attachment 56901 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56901=edit Simple testcase (C and Fortran) - as same-directory .diff

[Bug middle-end/113067] New: [OpenMP][5.1] Context selector - handle 'implementation={requires(...)}'

2023-12-18 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113067 Bug ID: 113067 Summary: [OpenMP][5.1] Context selector - handle 'implementation={requires(...)}' Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords:

[Bug middle-end/110639] [OpenMP][5.1] Predefined firstprivate for pointers - attachment missing

2023-12-11 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110639 --- Comment #5 from Tobias Burnus --- Posted a patch for (A) https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639947.html but it seems as if I might have misunderstood some parts of the example at OpenMP spec issue #1796 (TRAC864) /

[Bug middle-end/110639] [OpenMP][5.1] Predefined firstprivate for pointers - attachment missing

2023-12-06 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110639 --- Comment #4 from Tobias Burnus --- There are *two* independent issues: (A) Predefined firstprivate does not find mappings done in the same directive, e.g. int a[100]; int *p = [0]; #pragma omp target teams distribute map(a)

[Bug middle-end/110639] [OpenMP][5.1] Predefined firstprivate for pointers - attachment missing

2023-12-05 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110639 --- Comment #3 from Tobias Burnus --- Created attachment 56804 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56804=edit gimplify.cc patch to ensure that GOVD_MAP_0LEN_ARRAY comes last (does not fix the issue) I tried the attached patch

[Bug middle-end/112779] New: [OpenMP] Support omp Metadirectives

2023-11-30 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112779 Bug ID: 112779 Summary: [OpenMP] Support omp Metadirectives Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end

[Bug middle-end/112763] New: [OpenMP] ICE in gimplify_adjust_omp_clauses, at gimplify.cc:13238 – with defaultmap(firstprivate) for C++ member variables

2023-11-29 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112763 Bug ID: 112763 Summary: [OpenMP] ICE in gimplify_adjust_omp_clauses, at gimplify.cc:13238 – with defaultmap(firstprivate) for C++ member variables Product: gcc

[Bug middle-end/112667] New: [OpenMP] C++: Handle static local variable in target regions

2023-11-22 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112667 Bug ID: 112667 Summary: [OpenMP] C++: Handle static local variable in target regions Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: openmp,

[Bug middle-end/110639] [OpenMP][5.1] Predefined firstprivate for pointers - attachment missing

2023-11-21 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110639 --- Comment #2 from Tobias Burnus --- > If 'a' is already present on the device (e.g. 'omp target enter data > map(a)'), it works. This applies to both the comment 0 example where only a section of 'a' is mapped start > 0 and for the comment

[Bug middle-end/110639] [OpenMP][5.1] Predefined firstprivate for pointers - attachment missing

2023-11-21 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110639 --- Comment #1 from Tobias Burnus --- Testing shows that the offsets are correctly handled but that there is an ordering problem. Example: int main () { int a[100] = {}; int *p = [0]; uintptr_t iptr; #pragma omp target map(a, iptr)

[Bug c++/110347] [OpenMP] private/firstprivate of a C++ member variable mishandled

2023-11-21 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110347 --- Comment #2 from Tobias Burnus --- An explicit 'firstprivate(x)' will be turned in the compiler from a FIELD_DECL to: int D.2935 [value-expr: ((struct t *) this)->x]; #pragma omp target firstprivate(D.2934) firstprivate(D.2935) {

[Bug middle-end/112634] [14 Regression][OpenMP][-fprofile-generate] ICE in verify_gimple for gcc.dg/gomp/pr27573.c:

2023-11-21 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112634 --- Comment #5 from Tobias Burnus --- @Kostadin: Sebastian posted a patch at https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637451.html that should be fine as workaround, even if it is not completely correct, cf.

[Bug fortran/110415] (Re)allocation on assignment to allocatable polymorphic variable from allocatable polymorphic function result

2023-11-20 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110415 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment

[Bug middle-end/112634] [14 Regression][OpenMP][-fprofile-generate] ICE in verify_gimple for gcc.dg/gomp/pr27573.c:

2023-11-20 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112634 --- Comment #3 from Tobias Burnus --- Breakpoint 6, gen_assign_counter_update (gsi=0x7fffcab0, call=0x77230b48, func=0x7736cb00, result=0x77200b98, name=0x258f5f2 "PROF_time_profile") at

[Bug middle-end/112634] [14 Regression][OpenMP][-fprofile-generate] ICE in verify_gimple for gcc.dg/gomp/pr27573.c:

2023-11-20 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112634 --- Comment #2 from Tobias Burnus --- That's r14-5578-ga350a74d6113e3

[Bug middle-end/112634] [14 Regression][OpenMP][-fprofile-generate] ICE in verify_gimple for gcc.dg/gomp/pr27573.c:

2023-11-20 Thread burnus at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112634 Tobias Burnus changed: What|Removed |Added CC||sebastian.huber@embedded-br

  1   2   3   4   5   6   7   8   9   10   >