https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753
Tobias Burnus changed:
What|Removed |Added
Summary|assumed-rank dummies: |assumed-rank dummies:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
--- Comment #6 from Tobias Burnus ---
Some bound issues were fixed with PR99043 – but my bet is that the BIND(C)
issues still exist. (→ testcase (C + Fortran) attached to this PR).
* * *
Additionally: PR 94020 (duplicate of this PR) with attac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97694
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99308
Tobias Burnus changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99329
Bug ID: 99329
Summary: [OpenMP] device_type(nohost) & host code diagnostic
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid, openmp
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99326
--- Comment #2 from Tobias Burnus ---
This looks very much like an error I looked at before.
I think that was for 'select rank (y => x)', which
has the same issue as 'select type (y => x)' or
as this PR shows 'associate (y=>x)'.
Additionally, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99359
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355
Tobias Burnus changed:
What|Removed |Added
CC||dominiq at lps dot ens.fr
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355
--- Comment #11 from Tobias Burnus ---
(In reply to Dominique d'Humieres from comment #8)
> r11-7501 changed the output of the test in comment O, is this expected?
(In reply to Dominique d'Humieres from comment #10)
> % gfc pr57871.f90
I am sli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355
--- Comment #12 from Tobias Burnus ---
Additional patch – my need some cleanup & check whether the
other flags agree with the description. However, it should
match the implementation:
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355
--- Comment #14 from Tobias Burnus ---
(In reply to Dominique d'Humieres from comment #13)
> I have changed the test in pr57871 comment 0 to [...]
> It is not the result I expect.
Does the patch of comment 11 produce the expected result?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355
--- Comment #16 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566301.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99400
Bug ID: 99400
Summary: OpenMP: ICE in install_var_field, at omp-low.c:789
with "map(alloc: A) map(to: A)"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99355
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97927
--- Comment #12 from Tobias Burnus ---
(In reply to Matthias Klose from comment #10)
> seen again with 20210227
I tried it with the attached file and the build.sh but calling gfortran
directly w/o mpif90 wrapper.
That's with --enable-checking=y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97927
--- Comment #13 from Tobias Burnus ---
Created attachment 50313
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50313&action=edit
Reduced testcase - run with 'gfortran file.f90' (seems to require
--enable-checking=yes)
The generated code ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97927
Tobias Burnus changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #14 from Tobias Burnus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97927
--- Comment #15 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566366.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99137
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88438
Tobias Burnus changed:
What|Removed |Added
Summary|[F08] A pointer function|[F2008][F08] A pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99509
Bug ID: 99509
Summary: [OpenMP] 'omp declare target' for global variable →
"hasn't been marked to be included in the offloaded
code"
Product: gcc
Version: 11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99509
--- Comment #1 from Tobias Burnus ---
Variant which also is valid C:
#pragma omp declare target
int data[]={5};
#pragma omp end declare target
inline int foo(int idx) { return data[idx]; }
int main()
{
int i;
#pragma omp target map(to:i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99514
--- Comment #1 from Tobias Burnus ---
(In reply to markus.weil...@ipp.mpg.de from comment #0)
> I believe the ifort behavior is correct here, because the initialization of
> NTest via DATA causes an implicit save, which seems not to be identified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99514
--- Comment #3 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566548.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99509
--- Comment #3 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566547.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99519
Bug ID: 99519
Summary: [OpenMP] PRIVATE/FIRSTPRIVATE with CLASS / polymorphic
list items
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
Bug ID: 99529
Summary: libgfortran I/O: Data races related to new unit / new
unit calls for I/O to strings
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
--- Comment #1 from Tobias Burnus ---
Regarding calling newunit_alloc, that's due to libgfortran/io/unit.c's:
get_unit (st_parameter_dt *dtp, int do_create)
{
gfc_unit *unit;
if ((dtp->common.flags & IOPARM_DT_HAS_INTERNAL_UNIT) != 0)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
--- Comment #5 from Tobias Burnus ---
(In reply to martin from comment #4)
> Ok, here is another suspicious data race in unit.c (backtrace from helgrind):
It looks as if - for the libgfortran internal use - it first gets the unit
based on that n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
--- Comment #6 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566596.html
@Martin: Besides helgrind, you could also try building your program with
-fsanitize=thread - this might also help finding some issues (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93660
Tobias Burnus changed:
What|Removed |Added
Keywords||wrong-code
Summary|ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98858
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88899
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99509
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98858
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99529
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99514
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93660
--- Comment #3 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-March/055816.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92782
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97927
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57141
--- Comment #6 from Tobias Burnus ---
(In reply to Antonio from comment #5)
> I am experiencing this problem in gfortran from gcc version 10.2.0 and the
> same workaround also works. It seems to be a regression.
Hi Antonio.
Do you use exactly t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99609
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491
Tobias Burnus changed:
What|Removed |Added
CC||Boyce at engineer dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99651
Tobias Burnus changed:
What|Removed |Added
Keywords||rejects-valid
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99651
Tobias Burnus changed:
What|Removed |Added
Last reconfirmed||2021-03-18
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99651
--- Comment #3 from Tobias Burnus ---
The obvious idea to do:
if (sym->attr.flavor == FL_UNKNOWN || sym->attr.flavor == FL_PROCEDURE)
in gfc_intrinsic_func_interface works, but has the side effect that for
print *, allocated(f)
('f' is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99651
--- Comment #4 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566956.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99666
Bug ID: 99666
Summary: [OpenMP][5.0] Support 'affinity' clause in 'omp task'
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99688
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99688
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 99688, which changed state.
Bug 99688 Summary: AddressSanitizer: stack-buffer-overflow on address at
gfc_match_name(char*) gcc/fortran/match.c:685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99688
What|Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99369
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99765
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95622
--- Comment #8 from Tobias Burnus ---
I am not sure whether this is a sensible solution, but it fixes
the issue for c-c++-common/goacc/kernels-alias-ipa-pta-2.c ...
diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index 529e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99765
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93660
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93660
--- Comment #8 from Tobias Burnus ---
(In reply to Christophe Lyon from comment #7)
> Excess errors:
> /gcc/testsuite/gfortran.dg/gomp/declare-simd-coarray-lib.f90:8:18: Warning:
> GCC does not currently support mixed size types for 'simd' functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928
Bug ID: 99928
Summary: [OpenMP] reduction variable in combined target
construct wrongly mapped as firstprivate
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94446
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928
--- Comment #2 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567838.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99817
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100059
Bug ID: 100059
Summary: [OpenMP] wrong code with 'declare target link' and a
scalar variable
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: openmp, w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100059
Tobias Burnus changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100059
--- Comment #2 from Tobias Burnus ---
Probably a read herring as I still get for a.xnvptx-none.c:
static const char *const var_mappings[] = {
"b$linkptr",
"i$linkptr",
"c$linkptr",
"a$linkptr"
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100059
--- Comment #3 from Tobias Burnus ---
With GCN it does work:
i=5: A=5, B=6, C=7
i=5: A=6, B=8, C=10
i=5: A=7, B=10, C=13
And the follow testcase prints:
* with nvptx:
42, 5, 0, 0
* with amdgcn:
5, 42, 43, 44
This something must be rever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100059
Tobias Burnus changed:
What|Removed |Added
Last reconfirmed||2021-04-13
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100144
Bug ID: 100144
Summary: [OpenMP] Data race with "omp parallel master taskloop
... shared(scalar)"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97880
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100144
--- Comment #2 from Tobias Burnus ---
Sollve_vv's testcase has been fixed:
Issue: https://github.com/SOLLVE/sollve_vv/issues/324
Patch test_parallel_master_taskloop.c:
https://github.com/SOLLVE/sollve_vv/pull/325
Patch test_parallel_master_task
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100181
--- Comment #7 from Tobias Burnus ---
I can reproduce this one with LLVM trunk when compiled with '-save-temps -O2'
and then
llvm-mc --triple=amdgcn--amdhsa -mcpu=fiji -filetype=obj
--amdhsa-code-object-version=3 a.xamdgcn-amdhsa.mkoffload.1.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100181
--- Comment #9 from Tobias Burnus ---
(In reply to Thomas Schwinge from comment #8)
> (In reply to Tobias Burnus from comment #7)
> > (I could not reproduce the LLVM 9 issue in PR94278 back then.)
>
> Hmm, but didn't you say in the LLVM issue
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100232
Bug ID: 100232
Summary: [OpenMP][nvptx] Reduction fails with optimization and
'loop'/'for simd' but not with 'for'
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100232
--- Comment #2 from Tobias Burnus ---
(In reply to Tom de Vries from comment #1)
> Can you try the patch for PR81778 ?
> It's possible you're looking at a duplicate.
Unfortunately, it does not seem to make a difference - it still fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97385
Tobias Burnus changed:
What|Removed |Added
Keywords||documentation
--- Comment #1 from Tobias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97390
Tobias Burnus changed:
What|Removed |Added
Summary|Error compiling acc data|[OpenAError compiling acc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97408
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97649
Bug ID: 97649
Summary: OpenMP: 'target teams' with host-fallback: race
condition according to TSAN
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: open
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97649
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97655
--- Comment #3 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #2)
> Guess the second condition should be !c->capture.
I concur.
> Now, something I have clearly missed in the review, why is capture not part
> of atomic_op? capt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97672
Bug ID: 97672
Summary: [11 Regression] gfortran.dg/pdt_14.f03 – runtime:
timeout with -O2 (and higher)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97655
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97699
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95847
--- Comment #7 from Tobias Burnus ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558214.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96835
--- Comment #5 from Tobias Burnus ---
(In reply to Tobias Weinzierl from comment #4)
> Created attachment 49339 [details]
> Reproducer
Compiles here with mainline (11.0.0 20201104) and nvptx offloading (-O0).
I wonder whether that was fixed by:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90111
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97776
Bug ID: 97776
Summary: [C/C++][OpenMP] 'error: array section is not
contiguous in ‘map’ clause' for: map(alloc: p[i][0:C])
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97782
--- Comment #1 from Tobias Burnus ---
Created attachment 49540
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49540&action=edit
Draft patch
There are probably more – like 'omp sections', 'omp parallel', if I glanced at
it correctly. (Searc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97782
--- Comment #2 from Tobias Burnus ---
Technically, the issue is (was): The input_location is used which is obtained
when finishing the the block (= '!$acc end kernels') - or rather whatever comes
before and bumps the line location.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97810
Bug ID: 97810
Summary: [OpenACC] [C/C++] Decide about 'acc atomic update
capture' – remove support or keep it
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95847
--- Comment #9 from Tobias Burnus ---
(In reply to johannes.ziegenbalg from comment #2)
> I get the same bug with GCC 10.2.0 in one of my c++ test-cases.
Johannes: Can you fill a bugreport for the C++ test case? This PR is only about
Fortran – a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95847
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97782
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 1099 matches
Mail list logo
