Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: ams at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
For some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95320
Tobias Burnus changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95320
--- Comment #2 from Tobias Burnus ---
Possible patch:
diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index 288e3c0f4c6..6441ab30c8b 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -591,7 +591,7 @@ local_tree_p (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95320
--- Comment #3 from Tobias Burnus ---
Patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546535.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95320
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
||burnus at gcc dot gnu.org
--- Comment #4 from Tobias Burnus ---
Slightly stupid example which currently fails with:
sorry, unimplemented: target cannot support alloca.
x86_64-none-linux-gnu-accel-nvptx-none-gcc returned 1 exit status
call foo(10)
contains
subroutine foo(nn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95146
--- Comment #6 from Tobias Burnus ---
(In reply to Thomas Koenig from comment #5)
> Moving to the non-traditional C preprocessor will cause havoc with
> the // operator in Fortran.
> c = 'a' // 'b' would then be turned into c = 'a', probably not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94874
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Created attachment 48668
--> https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95499
--- Comment #1 from Tobias Burnus ---
Test case need the change (in line 40) to compile - sorry.
@@ -40 +40 @@
-if (any (array /= [(-2*i, i = 1, nn)])) error stop 2
+if (any (array /= [(-2*i, i = 1, 10)])) error stop 2
Shorter test case
Keywords: openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Found when playing around with PR95499
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95499
Tobias Burnus changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The following program gives an ICE with -fopenacc:
12 | !$acc loop private(A)
|
internal compiler error: in
: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: openacc, openmp, wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Mile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551
Tobias Burnus changed:
What|Removed |Added
Depends on||94848
--- Comment #1 from Tobias Burnus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551
--- Comment #2 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #0)
> if (any (array /= [(-2*i, i = 1, 10)])) error stop 2
The A.10.2 is the array {-2,-4,...,-20} in static memory, which has been
removed with -O3 but there is s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551
--- Comment #4 from Tobias Burnus ---
See RFC patch at
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547500.html
→ Don't add read-only artificial variables to the offload table (no need to)
And see experimental (but not working) patch rega
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Depends on: 95551
Target
Status: UNCONFIRMED
Keywords: missed-optimization, openacc, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
--- Comment #4 from Tobias Burnus ---
(In reply to Martin Liška from comment #3)
> Any update on the failing target1.f90 test-case?
Not yet. What needs to be done is to mark loop variables as "private" – and
attach this to the proper OpenMP dire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95622
--- Comment #3 from Tobias Burnus ---
I think there are three related issues here:
(a) force_output = 1 prevents at least one optimization
(b) If not using force_output = 1, we need to find another way to
tell the compiler that the variable is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #2 from Tobias Burnus ---
(In reply to Thomas Schwinge from comment #1)
> Have you verified that it's the same underlying issue
It's not but would otherwise be a duplicate.
> or do you just want to wait for PR95109 being resolved bef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95583
Bug 95583 depends on bug 95551, which changed state.
Bug 95551 Summary: [OpenMP, OpenACC] -fopenmp/-fopenacc also with
-foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to
`A.10.2'
https://gcc.gnu.org/bugzilla/show_bug.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551
Bug 95551 depends on bug 94848, which changed state.
Bug 94848 Summary: [Offloading][LTO] error due to only partially eliminated var
/ -ftree-pre causes link errors |
libgomp.fortran/use_device_ptr-optional-3.f90 failures
https://gcc.gnu.org/bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92029
Tobias Burnus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Compare:
---
type t
character(len=:, kind=4), pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95837
Tobias Burnus changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|
-code, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The following program fails with an ICE or a segfault.
Issues I observed:
* For the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67311
--- Comment #7 from Tobias Burnus ---
Patch – without one recursively checks the same type.
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -330,6 +330,11 @@ gfc_has_alloc_comps (tree type, tree decl)
return false;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95837
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67311
--- Comment #8 from Tobias Burnus ---
Submitted patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548920.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67311
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92311
--- Comment #9 from Tobias Burnus ---
(In reply to Nichols A. Romero from comment #0)
> The error for the OpenMP is shown below:
>29 |!$omp target data use_device_ptr(this_bin)
> | 1
> Err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95622
--- Comment #7 from Tobias Burnus ---
(In reply to Richard Biener from comment #6)
> not sure if fixed?
Not fixed – only XFAILed.
The issue is that optimizations are not done with "node->force_output". As in
the example in comment 0:
"a = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95868
--- Comment #2 from Tobias Burnus ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed. Quite complex test case!
Came up when trying to write a patch for OpenMP structure/derived-type element
mapping (r11-2079). Hence:
Additional t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96212
--- Comment #2 from Tobias Burnus ---
(In reply to Bill Seurer from comment #1)
> After running on a few more machines this appears to be a BE only issue.
alloc-1.F90 uses a proper interface (Fortran module). alloc-3.F uses a header
file with th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93553
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93553
--- Comment #7 from Tobias Burnus ---
The variable ("D.3940") is produced via the following route.
Contrary to variables processed in gimplify.c, which use
/* When within an OMP context, notice uses of variables. */
if (gimplify_omp_ctxp &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93553
--- Comment #8 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550317.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96306
--- Comment #2 from Tobias Burnus ---
Just as background: While OpenMP uses for C/C++ a typedef for 'omp_depend_t',
which maps to a struct with "char[2*sizeof(*void)]", for Fortran an integer
kind is required by the OpenMP spec.
At least with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96306
--- Comment #7 from Tobias Burnus ---
At least as in-between solution, one could change libgfortran to disable
HAVE_GFC_INTEGER_16 for gcn. — libgfortran exercises a lot of the integer
arithmetics, which we do not need here.
One just needs to ens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92876
--- Comment #2 from Tobias Burnus ---
I believe this code is invalid as "s" is a device routine but it call outside
of 'acc kernels'/'acc parallel' construct. – If one adds either around "call
s()" it no longer ICEs.
Still, even invalid code sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92876
--- Comment #3 from Tobias Burnus ---
And: The ICE occurs for
.data_dep.1_7 = .UNIQUE (OACC_HEAD_MARK, 0, 1, 132);
And then one runs inside expand_UNIQUE into:
switch (kind)
{
default:
gcc_unreachable ();
This one is generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96306
--- Comment #9 from Tobias Burnus ---
Initial TI support for AMDGCN has been committed, see:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550663.html
https://gcc.gnu.org/g:8d0b2b33748014ee57973c1d7bc9fd7706bb3da9
commit 8d0b2b33748014ee57
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
sollve_vv's tests/4.5/application_ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96390
--- Comment #1 from Tobias Burnus ---
Created attachment 48961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48961&action=edit
Test case from https://bugs.llvm.org/show_bug.cgi?id=43771 (basis for sollve_vv
test case, by Jonas Hahnfeld)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96390
--- Comment #2 from Tobias Burnus ---
omp-offload.c's omp_discover_declare_target_tgt_fn_r sees the
::S()"
It does not call
((vec *) data)->safe_push (*tp);
to add it to the work list. (→ follow up issue for "V"?)
However, it sets the attribu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96390
--- Comment #3 from Tobias Burnus ---
The following helps with the "S<0>::S()" problem – but then one runs into the
"V<1>::V" problem.
--- a/gcc/omp-offload.c
+++ b/gcc/omp-offload.c
@@ -207,6 +207,12 @@ omp_discover_declare_target_tgt_fn_r (tre
-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: vries at gcc dot gnu.org
Target Milestone: ---
Target: nvptx
Created attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96428
--- Comment #3 from Tobias Burnus ---
Created attachment 48988
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48988&action=edit
Test case (as diff – two files)
I tried the testcase with and without you patch – and with it runs fine :-)
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88463
Tobias Burnus changed:
What|Removed |Added
CC||daanvanvugt at gmail dot com
--- Comment
||burnus at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #4 from Tobias Burnus ---
Works for me with 9.3.1 20200406 (and GCC 10 and GCC 11/mainline).
I can reproduce the error with GCC 7.
My guess is that is has been fixed with PR fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93826
--- Comment #5 from Tobias Burnus ---
Missed to list the PR in the commit :-(
* OpenMP 4.5 patch which rejects this is the following:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551338.html
and https://gcc.gnu.org/g:57dd9f3bfca8bb752c6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95499
--- Comment #3 from Tobias Burnus ---
For 'character(len=:),allocatable :: str' there is '_str' with the string
length.
One can map it explicitly when mapping 'from(str)' by also mapping
'firstprivate(_str)' but the compiler will later remove i
Version: 10.0
Status: UNCONFIRMED
Keywords: build, patch
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Patch: https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96612
Tobias Burnus changed:
What|Removed |Added
Version|10.0|11.0
Target Milestone|---
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The following fails with:
Duplicate OPTIONAL attribute specified
subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96661
--- Comment #1 from Tobias Burnus ---
(In reply to John David Anglin from comment #0)
> Guess this is because target doesn't support int128.
For "omp depend", the OpenMP spec requires that an integer type is used – and
the libgomp implementation
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
The exact behaviour is not well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668
Tobias Burnus changed:
What|Removed |Added
CC||cltang at gcc dot gnu.org
--- Comment #1
Status: UNCONFIRMED
Keywords: openmp, rejects-valid
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
The
: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96680
--- Comment #1 from Tobias Burnus ---
In the debugger, the first call to lto_fixup_prevailing_decls is for
main._omp_fn.0 and the second - and failing - one is for
(gdb) p debug_tree(t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96680
--- Comment #2 from Tobias Burnus ---
Created attachment 49075
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49075&action=edit
C testcase - de-macro-fied version sollve_vv's
5.0/declare_variant/test_declare_variant.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668
--- Comment #4 from Tobias Burnus ---
(In reply to kargl from comment #3)
> > integer, pointer :: p1 => null()
> > integer, pointer :: p1 => null()
> Module m looks wrong. Should the 2nd p1 be p2?
It should be "p2(:)"
(Thanks. I wrote it i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96680
--- Comment #3 from Tobias Burnus ---
Some regression hunting:
* Fails with r11-652-g79ea774f9a9d36d986152d93f9eae4a9ba36b37b
* Works on OG10 = devel/omp/gcc-10 and presumably GCC 10.
My bet is that the following commit causes the issue, but tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96612
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96678
--- Comment #1 from Tobias Burnus ---
At least for C, there is:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96678
--- Comment #2 from Tobias Burnus ---
Side remark: This pops up for SPEC ACCEL 504.polbm; however, it is permitted to
require explicit sizes by defining SPEC_NEED_EXPLICIT_SIZE.
(The default of the testcase is to expect that it works without tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96678
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Fabio Azevedo has some observations at
https://gcc.gnu.org/pipermail/fortran/2020-August/054931.html
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96797
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96811
--- Comment #3 from Tobias Burnus ---
(In reply to kargl from comment #2)
> For real x, gfortran does not generate a call to libgfortran function.
It does – as mentioned in my email reply but not only for 'int' integers:
integer(16) :: n
real :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672
--- Comment #15 from Tobias Burnus ---
(In reply to Tomáš Trnka from comment #12)
> The fix for this broke assumed length optional character arguments. I have
> noticed this on 10.2.1 20200723, which is currently used by Fedora 32.
Thanks for th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31892
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44612
--- Comment #8 from Tobias Burnus ---
For what it is worth, still occurs with on mainline (GCC 11).
(In reply to Richard Biener from comment #6)
> Confirmed.
>
> DSE doesn't remove memset or memcpy calls.
>
> We also do not have a flag to mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96886
--- Comment #3 from Tobias Burnus ---
(In reply to Andy May from comment #0)
> Looks like a regression between 10.1.0 and 10.2.0. test.f90:
I think that's the same issue as reported in PR 94672 comment 12 last week –
which has been fixed very re
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
The following program fails with:
Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96896
--- Comment #1 from Tobias Burnus ---
The error occurs for the LHS of:
myshape(b) = 0.0
reshape_test:_F.DA0 => myshape[[((reshape_test:b(FULL)))]]
(gfc_debug_expr output)
(gdb) p lvalue->rank
$9 = 0
(gdb) p rvalue->rank
$10 = 2
Maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96896
--- Comment #2 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553154.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96896
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
Bug 95654 depends on bug 95109, which changed state.
Bug 95109 Summary: [11 regression] ICE in gfortran.dg/gomp/target1.f90 after
r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94690
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
CC||burnus at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #4 from Tobias Burnus ---
Bisecting points to r11-3009-gfab77644842869adc8871e133e4c3f4c35b2b245
PR tree-optimization/96931 - clear
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
The following program stops with "STOP 7" – as n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97021
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96668
--- Comment #6 from Tobias Burnus ---
Fixed for pointer/allocatable arrays.
Still to be done: scalar pointers/allocatable; here, one needs to be careful as
pointer/always pointer is already used for, e.g., struct mapping – and always
pointer cur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #3 from Tobias Burnus ---
Created attachment 49222
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49222&action=edit
Slightly reduced example, compile with gfortran -fopenmp -O1 -ftracer
Some testing; with gfortran -fopenmp -O1
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
Found when looking at PR95654 - reduced + modified version of
libgomp.fortran/pr66199-5.f90.
The following ICEs with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97061
--- Comment #2 from Tobias Burnus ---
I think I also got this ICE with an additional 'collapse(2)', which might
indicate that a(nother) check is missing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #4 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #3)
> Created attachment 49222 [details]
> Slightly reduced example, compile with gfortran -fopenmp -O1 -ftracer
On the host side, a single BB gets inserted – but more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97061
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
--- Comment #10 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #9)
> See also thread at:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-September/thread.html#554054
Regarding the patch there, the proper way is to adapt can_du
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891
Bug 89891 depends on bug 96041, which changed state.
Bug 96041 Summary: [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96041
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
101 - 200 of 5819 matches
Mail list logo
