https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348
--- Comment #8 from Bud Davis ---
subroutine s
contains
SUBROUTINE s
END SUBROUTINE
end subroutine
q? Is this valid ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494
--- Comment #4 from Bud Davis ---
my comment sounded snarky; not intended. I did not know that you were also
reducing this test case !!!
This page was 'stale' in my browser when i added the comment.
--bud
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60774
--- Comment #5 from Bud Davis ---
Index: gcc/gcc/fortran/parse.c
===
--- gcc/gcc/fortran/parse.c(revision 214408)
+++ gcc/gcc/fortran/parse.c(working copy)
@@ -868,8 +868,6 @
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60774
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59746
--- Comment #4 from Bud Davis ---
http://gcc.gnu.org/ml/fortran/2014-03/msg00066.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59746
--- Comment #3 from Bud Davis ---
Not so fast...
Made a test for it:
!pr59746
CALL RCCFL(NVE,IR,NU3,VE(1,1,1,I))
COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL
COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59746
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52075
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34928
--- Comment #9 from Bud Davis ---
I completely support closing this PR with a note in the documentation.
On shared memory mini computers of a bygone era, it was common to map the
common blocks to a specific memory address, and then more than one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58226
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57373
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34928
--- Comment #5 from Bud Davis ---
As the reporter of this enhancement request, I think it is something that
should be left open.
Low priority, but this was a 'feature' of some f77 compilers in the past.
Even if no-one ever adds this functional
||bdavis at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #17 from Bud Davis ---
Closing due to no clear problem defined. If more info is available, please
re-open.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56806
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328
--- Comment #8 from Bud Davis ---
The compiler generates code for min and max that checks if an argument is NaN.
(floating point numbers only, of course).
This is different than the example you posted, as it would not give the correct
answer whe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46703
--- Comment #6 from Bud Davis ---
It is a problem with Valgrind.
One that is even mentioned in the (valgrind) manual.
https://bugs.kde.org/show_bug.cgi?id=197915
It has been open for about 4 years, not fixed yet.
Short summary. Don't use valgr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46703
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50405
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51591
--- Comment #4 from Bud Davis ---
Upon closer reflection, the underlying problems is the OpenMP threads doing I/O
while the units are being closed.
So, stop shows in the output, followed by output from threads whose units have
been destroyed, but
||bdavis at gcc dot gnu.org
Resolution||FIXED
--- Comment #4 from Bud Davis 2012-07-06 18:16:49
UTC ---
>From reading the summary, the bug is fixed in recent versions, and no further
action is to be taken. Thus "RESOLVED / FIXED".
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49011
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51591
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50619
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51338
--- Comment #6 from Bud Davis 2011-11-28 23:20:27
UTC ---
The above patch has no new testsuite regressions.
If someone wants to check and make sure the optimisation(s) that could or were
being done is still correct, and check this in, feel free t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51338
--- Comment #5 from Bud Davis 2011-11-28 22:49:33
UTC ---
Index: gcc/gcc/fortran/dependency.c
===
--- gcc/gcc/fortran/dependency.c(revision 181789)
+++ gcc/gcc/fortran/dependency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51338
--- Comment #3 from Bud Davis 2011-11-28 21:59:02
UTC ---
Reduced:
SUBROUTINE PAXCUT(CHIN,CHOUT)
CHARACTER*(*) CHIN,CHOUT
IF(INDEX(CHOUT(K:),'.OR.').EQ.INDEX(CHOUT(K:),'.AND.')) THEN
ENDIF
END
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51338
Bud Davis changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #2
32 matches
Mail list logo
