https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64230
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640
--- Comment #4 from Joost VandeVondele
---
(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 this is not mandated by the standard, bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52075
Joost VandeVondele changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
-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=64247
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #3 from Joost VandeVondele
---
(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 memory use is in =address or
> =undefine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
Joost VandeVondele changed:
What|Removed |Added
Summary|program result depends on |malloc alignment and -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #5 from Joost VandeVondele
---
The following is a test program that illustrates the issue:
> cat test.f90
SUBROUTINE gemm(C,A,B,N)
REAL*8 :: A(N,N), B(N,N),C(N,N)
C=0
DO i=1,N
DO j=1,N
DO k=1,N
C(i,j)=C(i,j)+A(k,i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #6 from Joost VandeVondele
---
some similarity with the problem discussed PR55916, except that this case
doesn't require __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #8 from Joost VandeVondele
---
(In reply to Ondrej Bilka from comment #7)
> That looks like invalid bug. Fortran allows reassociate a+(b+c) into (a+b)+c
> which give different result. You will get same instability if you compile
> pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #9 from Joost VandeVondele
---
A variation on the testcase, to indicate how this behavior leads to conflicts
with the Fortran language standard. A routine declared 'PURE' and called with
all intent(in) arguments having the same value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38220
Joost VandeVondele changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
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
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
somewhere between r218726 and r218773 (1day) code compiled & linked with
FCFLAGS = -flto=jobserver -ffree-form -cpp
LDFLAGS = $(FCFLAGS) -O3 -funroll-loops -ffast-math -march=native
-fuse-li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343
Joost VandeVondele changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160
Joost VandeVondele changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591
--- Comment #7 from Joost VandeVondele
---
(In reply to Dominique d'Humieres from comment #6)
> > what about applying this to stage 1 4.9 ?
>
> Too late for 5.0? Note that the patch in comment 3 may have to be updated to
> take into account the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530
Joost VandeVondele changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 :: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61644
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #52 from Joost VandeVondele
---
(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 this imply that the combination of -fsa
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) RES
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61234
Joost VandeVondele changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
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 it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242
--- Comment #2 from Joost VandeVondele
---
Further reduced:
> cat bug.f90.orig
module gfbug
contains
pure function UpperCase(string) result(upper)
character(*), intent(IN) :: string
character(LEN(string)) :: upper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #3 from Joost VandeVondele
---
(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 to change mips?
> if not please docum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #8 from Joost VandeVondele
---
(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 defined.
> If the documentation would no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62245
--- Comment #10 from Joost VandeVondele
---
(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 as indicated by the docs.
it will now inc
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152
Joost VandeVondele changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54452
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152
Joost VandeVondele changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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.
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 changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
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) PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63316
Joost VandeVondele changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
: 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 '. S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422
--- Comment #3 from Joost VandeVondele
---
(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 that would be great. Or even
> if you can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
overnight regression with current trunk:
> cat bug.f90
MODULE qs_efield_berry
TYPE cp_error_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68379
--- Comment #2 from Joost VandeVondele
---
(In reply to Markus Trippelsdorf from comment #1)
> *** Bug 68575 has been marked as a duplicate of this bug. ***
The testcase in PR68575 doesn't require avx, so might be useful for the
testsuite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68379
Joost VandeVondele changed:
What|Removed |Added
Target|aarch64 |aarch64,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68540
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
trunk regression:
> cat bug.f90
SUBROUTINE makeCoulE0(natorb,Coul)
INTEGER, PARAMETER :: dp=8
REAL(KIND=dp), PARAMETER :: fourpi=432
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312
Joost VandeVondele changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
This is an enhancement request. Using -O1 and higher, undefined variables are
considered equal to 0 in optimization. This leads to code compiling at -O1
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
Today's trunk produces a lot of warnings / notes all referring to functions
from libgfortran, when compiling CP2K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
Joost VandeVondele changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
--- Comment #3 from Joost VandeVondele
---
Grepping the list of 'note:' in our build process, it triggers for at least
these functions:
_gfortran_matmul_r8
_gfortran_reshape_4
_gfortran_reshape_c4
_gfortran_reshape_c8
_gfortran_reshape_r4
_gfor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
Joost VandeVondele changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641
--- Comment #10 from Joost VandeVondele
---
(In reply to rguent...@suse.de from comment #9)
> Though with the testcase you gave we warn at both -O0 and -O1:
yes, but unfortunately, -Wuninitialized, also warns for 'may be used
uninitialized' whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68641
--- Comment #12 from Joost VandeVondele
---
(In reply to Marc Glisse from comment #11)
> That sounds like a bug. It works for me on a simple C testcase.
sorry, fat fingers on my side. So, yes, this works
gfortran -c -Werror=uninitialized -Wno-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68550
--- Comment #2 from Joost VandeVondele
---
The following simpler looking testcase fails at -O1:
> cat bug.f90
SUBROUTINE PD2VAL(RES,NDERIV,TG1,TG2,C0)
INTEGER, PARAMETER :: dp=8
REAL(KIND=dp), INTENT(OUT) :: res(*)
REAL(KIND=dp),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68550
--- Comment #7 from Joost VandeVondele
---
(In reply to Sebastian Pop from comment #5)
> fixed
BTW, with this fixed, I can compile our CP2K code with -floop-nest-optimize at
various -Ox and all seems correct. Thanks!
I'll try to integrate '-fl
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
> cat bug.f90
MODULE spme
INTEGER, PARAMETER :: dp=8
PRIVATE
PUBLIC :: get_patch
CONTAINS
SUBROUTINE get_patch ( part, box, green, npts, p, rhos, is_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68692
Joost VandeVondele changed:
What|Removed |Added
Last reconfirmed||2015-12-4
CC|
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
> cat bug.f90
MODULE dbcsr_index_operations
INTERFACE dbcsr_build_row_index
END INTERF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68693
Joost VandeVondele changed:
What|Removed |Added
Last reconfirmed||2015-12-4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68715
Joost VandeVondele changed:
What|Removed |Added
Last reconfirmed||2015-12-5
CC|
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
not a dup of PR68693:
> cat bug.f90
SUBROUTINE se_core_core_interaction(calculate_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39772
Joost VandeVondele changed:
What|Removed |Added
Status|WAITING |NEW
Summary|add a correc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68002
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
Currently, switching from -O3 to -Ofast might result in segfaulting Fortran
programs:
> cat test.f90
MODULE foo
CONTAINS
SUBROUTINE mysu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
--- Comment #11 from Joost VandeVondele
---
(In reply to Jerry DeLisle from comment #10)
> This PR is tagged as a regression. Has anyone determined when it last
> worked or is it longstanding bug uncovered by recent non-fortran fe changes?
For
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
I'm not 100% sure what the right answer is, i.e. if MERGE is defined by the
standard to do something special with respect to evaluating its arguments. The
origin is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68993
Joost VandeVondele changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68993
--- Comment #5 from Joost VandeVondele
---
(In reply to Steve Kargl from comment #4)
>
> I would urge anyone trying to be clever to use clear syntax:
>
https://github.com/hfp/libxsmm/commit/cc308fc5debe6151157a4fa9efacc7aa03351283
is what we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69154
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68829
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68976
--- Comment #5 from Joost VandeVondele
---
I'm somewhat surprised graphite regressions get a P4.
Discussions on the list suggested that graphite would be enabled by default in
the near future. Lowering graphite regression priority to 'not seri
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
After building libgfortran with -fsanitize=thread (see below) any Fortran
program that opens a file fails with:
> cat test.f90
OPEN(10,FILE="
: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: jakub at gcc dot gnu.org
Target Milestone: ---
After compiling libgomp with -fsanitize=thread, the following testcase triggers
a warning, which might indicate a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
The following testcase leads to an incorrect conversion warning (and a failed
CP2K build) with gcc 6.0, while 5.1 compiles fine
> cat bug.f90
MODULE ki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #26 from Joost VandeVondele
---
One more datapoint on the .smod / .mod issue.
I ran into the first package that fails to build with 6.0 because of this.
libxc (version 2.2.2, Tobias Burnus actually being one of the authors), relies
: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: jakub at gcc dot gnu.org
Target Milestone: ---
After compiling libgomp with -fsanitize=thread, the following testcase triggers
a warning, which might indicate a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67303
Joost VandeVondele changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66761
Joost VandeVondele changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66761
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
601 - 700 of 713 matches
Mail list logo
