https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630
Bug 32630 depends on bug 38220, which changed state.
Bug 38220 Summary: C_LOC intrinsic non-pure and without explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38220
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 38220, which changed state.
Bug 38220 Summary: C_LOC intrinsic non-pure and without explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38220
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Richard Biener from comment #1)
Are you sure you are not using uninitialized memory? try using the various
-fsanitize flags (not sure if uninit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Dominique d'Humieres from comment #3)
Is this PR INVALID?
seems more like an enhancement request to free allocatables at the end of main.
I guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52075
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|WAITING
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
This is a bit an odd bug report, as it so far is just a somewhat worrying
observation:
If I run our simulation package, the output appears to change if we pipe (|) an
output to file via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64230
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56203
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61604
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59345
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2013-12-22 00:00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2013-11-17 00:00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64207
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59345
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
I'm pasting here another testcase, since I think it is related.
This works as it should (i.e. no pack/unpack), an allocatable as function
result:
cat tt.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64207
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Mike Page from comment #3)
BTW, I was using
https://gcc.gnu.org/projects/tree-ssa/vectorization.html#using
for my info on optimization options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26731
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #17 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Harald Anlauf from comment #16)
(In reply to Joost VandeVondele from comment #15)
While if we use -fsanitize=address (at greatly increased cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2013-12-29 00:00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64118
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Assignee|unassigned at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64065
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64065
--- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Richard Biener from comment #4)
Created attachment 34111 [details]
patch
Can you try this?
Cool, fixed!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64065
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to rguent...@suse.de from comment #6)
Does the restrict stuff make any performance difference?
Not noticeable for the particular benchmark I'm running
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Richard Biener from comment #7)
Confirmed that it is ifcombine. Not sure if I'd call it wrong-code though.
Note that there are no default-defs
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Current trunk miscompiles cp2k at ' -flto=jobserver -fuse-linker-plugin
-fno-prefetch-loop-arrays -O3 -march=native -funroll-loops -ffast-math'
The last known good revision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63926
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Depends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63938
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63967
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
current trunk, ICEs for
cat bug.f90
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
current
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Created attachment 34042
-- https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63980
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63983
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to David Binderman from comment #2)
Test case available on request.
since non of the PRs have a testcase yet, would be good, if only to be added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63926
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
I see the following ICE with recent trunk (appeared in the last week or so):
gfortran -c -fprofile-use -O3 -march=native -funroll-loops -ffast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
in the day between r217531 and r217599 the following (reduced) testcase started
failing on trunk:
cat bug.f90
SUBROUTINE influence_factor ( gftype, error )
INTEGER, PARAMETER :: dp=8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63821
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
Created attachment 33852
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33852action=edit
C testcase
warning with : gcc -O1 -std=c11 -g PR63311.c -lm valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63700
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63514
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Richard Biener from comment #2)
The fortran frontend must do sth wrong here - it seems to mark the function
pure itself and either fold or the FE
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
The following testcase is miscompiled at -O1:
cat test.f90
MODULE M1
CONTAINS
INTEGER FUNCTION F1()
INTEGER, VOLATILE :: i
F1=i
END FUNCTION
INTEGER FUNCTION F2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63514
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63316
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
In the one day between r215702 and 215747 trunk started failing to compile CP2K
with '-c -flto=jobserver -fprofile-use '. Several lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Teresa Johnson from comment #2)
Yes, this function is new in r215739. I will see if I can trigger it
tomorrow. If you have a smaller test case
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Example code showing somewhat confusing lines and caret info
cat test.f90
SUBROUTINE S1(d)
INTEGER :: i,d(*)
!$OMP PARALLEL DO
!$OMP DEFAULT(NONE) SHARED(d) PRIVATE(i
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
In the one day between r215373 and r215412 asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63316
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
The following testcase yields a valgrind error when compiled with -O1 but not
at -O0. 4.8 is fine 4.9/trunk is not.
gfortran -O1 -g bug.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54452
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
I've noticed that for this code:
SUBROUTINE S1()
INTEGER, POINTER, DIMENSION(:) :: v
INTERFACE
SUBROUTINE foo(v)
INTEGER, POINTER, DIMENSION(:) :: v
END
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
scalar pointers are not nullified with -finit-local-zero . After the fix for
PR63152, also arrays with the pointer attribute might need this.
cat bug.f90
SUBROUTINE S1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
A recent trunk regression between good: r214776 and bad r214808, suspect
r214795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
The following testcase generates an ICE, it has been reduced from PR62242,
which seems to trigger a bug in the middle end, maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242
--- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
Further reduced:
cat bug.f90.orig
module gfbug
contains
pure function UpperCase(string) result(upper)
character(*), intent(IN) :: string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Julian Taylor from comment #2)
mips is the only architecture with this behavior, all others behave as
documented.
Shouldn't that be reason enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Julian Taylor from comment #7)
But the docs indicate that there is no undefined behavior.
As I interpret them the result of int() is always well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Julian Taylor from comment #9)
thanks, please also clarify/remove the sentence about the sign as the result
sign is not the sign of the input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61234
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
A recent regression introduced in the day between r212967 and r213034
cat bug.f90
MODULE min_heap
TYPE heap_t
END TYPE heap_t
CONTAINS
ELEMENTAL FUNCTION get_left_child(n) RESULT
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
It would be nice if the the following code
cat test.f90
LOGICAL :: file_exists
INQUIRE(UNIT=-1,EXIST=file_exists)
WRITE(6,*) file_exists
END
would error out at runtime, since
F2008:
If le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #52 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Jakub Jelinek from comment #51)
Your assumption is wrong, reductions are not handled in libgomp, but in the
code emitted by the compiler.
does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61644
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
A recent regression introduced in the one day between good: r212096 bad:
r212117 causes an ICE on trunk.
cat bug.f90
MODULE hfx_contract_block
INTEGER, PARAMETER :: dp=8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61604
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #17 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Marc Glisse from comment #16)
Done. Joost, feel free to add your testcase from comment #3 if you want to
(I can't write a hello world in fortran so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|RESOLVED
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Current trunk started failing in the day between
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61234
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Created attachment 32868
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32868action=edit
reduced testcase
The attached testcase is miscompiled with current trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61335
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
For the below testcase, would be nice to have a warning -Wunused-type for the
unused type (T), just like we have for unused functions (but I guess the FE
needs to get active for this one).
cat test.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52370
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Recent regression in the one day between good: r210596 bad: r210629
Unfortunately, only happens with -fprofile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61234
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61234
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Harald Anlauf from comment #3)
Obviously, this only works as long as the code is still compilable by g95 ...
which in our project started to require
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61243
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|WAITING
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
It would be nice to have a warning (-Wuse-only) for a use-stmt without explicit
only-list. It would allow for enforcing this good style with -Werror.
Extra useful would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53940
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
known good: r210485 known bad: r210542 possibly r210491
cat bug.f90
MODULE array_types
INTERFACE array_data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61028
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
201 - 300 of 713 matches
Mail list logo
