http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40282
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41737
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2008-01-23 11:27:01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41737
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46532
--- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-06-29 18:46:13 UTC ---
*** Bug 41737 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51179
--- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-06-30 11:26:59 UTC ---
It looks like this problem is solved in the current 4.7 and 4.8 branches. At
least on an avx machine, the best performance found by the code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47657
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47341
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2011-01-18 11:21:06
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53835
Bug #: 53835
Summary: in tree isl / cloog build fails
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852
Bug #: 53852
Summary: -ftree-loop-linear: large compile time / memory usage
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-07-04 12:17:47 UTC ---
To fill in the X, 130 Gb is not sufficient for this testcase.
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
The following is a code snippet with an implicit save for the variable I.
SUBROUTINE T()
INTEGER :: I=1
WRITE(6,*) I
I=I+1
END SUBROUTINE T
CALL T()
CALL T()
END
Expecting
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Between rev 199047 and 199075 the attached testcase started using an excessive
amount of time (up from about 4s with 4.7.2). The important option seems to be
-ffast-math (16s without
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
I actually suspect the compilation is in an infinite loop. Still running after
15min.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
I killed the compilation after 15h...
: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Created attachment 30179
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30179action=edit
testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Summary|[4.9 Regression] compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57337
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Depends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
still fails with r199397
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
Bug 57393 depends on bug 57337, which changed state.
Bug 57337 Summary: [4.9 Regression] 416.gamess ICE on x86 after r199048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57337
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57337
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57442
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
Simplified testcase that fails with 'gfortran -c -g -O2 -ffast-math bug.f90'
cat bug.f90
SUBROUTINE xb88_lr_adiabatic_lda_calc(npoints,e,g,sx)
IMPLICIT REAL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
Reduced testcase, which appears 'minimal' to trigger a hanging compilation at
gfortran -c -O2 -ffast-math bug.f90
cat bug.f90
SUBROUTINE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
Since the bug is still 'unconfirmed', I'm wondering if this can not be
reproduced, or if I can provide some more information (more than the small
testcase in comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
--- Comment #14 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Janne Blomqvist from comment #13)
I believe a lot of progress has been made indeed.
However, the fundamental(?) issue of module sizes growing
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
The following testcase:
cat test.f90
TYPE data
INTEGER :: x(10)
END TYPE
TYPE data_areas
TYPE(data) :: y(10)
END TYPE
TYPE(data_areas) :: z(10)
integer, volatile :: i,j,k
i=1 ; j=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2007-02-16 16:08:18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Tobias Burnus from comment #6)
(Finally) FIXED on the GCC 4.9 trunk.
Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57400
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57784
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57978
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
Reduced testcase:
subroutine Change_calendar (ts_arr, target_calendar)
integer, dimension(1) :: NO_DAY = (/ 0 /), ONE_DAY = (/ 180 /)
integer, allocatable
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Following invalid testcase yields and ICE with current trunk.
cat small.f90
type sysmtx_t
type(ext_complex_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58024
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Marek Polacek from comment #12)
Started with r199048.
yes, as was pointed out in PR57370
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370#c2
which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #23 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Easwaran Raman from comment #21)
Created attachment 30690 [details]
Proposed patch
I tested this patch on top of the one posted to the mailing list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #24 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
Also the other 'dup' PRs still fail (gcc -O3) . Collecting testcases here:
cat PR58018.c
int a, b, c, d, e;
void bar (int p)
{
int f = b;
e = p = (f ^= 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #25 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
*** Bug 58248 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #28 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Easwaran Raman from comment #27)
These two test cases pass for me (compiles with -O3) with the attached patch
(http://gcc.gnu.org/bugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #29 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Joost VandeVondele from comment #28)
OK, with only the patch mentioned above applied all testcases now pass. I
think this patch should be posted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2012-03-24 00:00:00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #31 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Easwaran Raman from comment #30)
Created attachment 30727 [details]
New patch
fixes all previously observed issues and further light testing.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Trunk yields:
bug.f90: In function ‘dbcsr_buffers_flush’:
bug.f90:28:0: error: virtual definition of statement not up-to-date
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58291
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58292
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58292
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
--- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
This bug is a bit of showstopper for doing automatic leak testing with
gperftools (essentially all our regtests have a non-zero error code with this
leak being
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57461
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57461
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58024
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Most likely caused by the fix for PR fortran/58579
http://gcc.gnu.org/viewcvs?rev=203088root=gccview=rev
cat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58593
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Known to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58593
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Tobias Burnus from comment #1)
Confirmed. - Sorry for the breakage and thanks for the report!
Not sure how the saying goes exactly, but 'those that do
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=61933
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
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=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
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
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
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
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
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
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
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
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
: 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=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
301 - 400 of 713 matches
Mail list logo
