Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: guez at lmd dot ens.fr
Target Milestone: ---
gcc version 12.0.1 20220319 (experimental) [master r12-7719-g8ca61ad148f]
(Ubuntu 12-20220319-1ubuntu1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98433
--- Comment #7 from Lionel GUEZ ---
(In reply to kargl from comment #6)
> Point being that quoting some third-party
> interpretation of what one version of the Fortran standard
> says is of limited value.
OK. I am learning here. I thought thos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98433
--- Comment #4 from Lionel GUEZ ---
Well, you will find that assignment of an expression of derived type to a
variable of the same type was already available in Fortran 95 (for example
Metcalf, 1999, Fortran 90/95 explained, section 3.9). But all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98433
--- Comment #2 from Lionel GUEZ ---
Sure, the issue goes away if you specify the components.
When you say "the likely correct line", do you imply that the line without the
components is incorrect? I would insist that the line without the compone
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: guez at lmd dot ens.fr
Target Milestone: ---
This is the output of `gcc -v` on my machine:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: guez at lmd dot ens.fr
Target Milestone: ---
Here is my system information:
$ gcc-10 -v
Using built-in specs.
COLLECT_GCC=gcc-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118
--- Comment #10 from Lionel GUEZ ---
(In reply to kargl from comment #9)
> Fortran 2018 has declared FORALL to be an obsolescent feature.
> I doubt that anyone will ever try to improve the performance
> of FORALL, because the next standard is lik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
--- Comment #11 from Lionel GUEZ ---
And what about my suggestion that ieee_support_nan(0.) should return false for
the time being?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
--- Comment #8 from Lionel GUEZ ---
It does not seem completely true that gfortran makes no distinction between
qNaN and sNaN. There is the option -finit-real of gfortran with the different
possible values nan and snan. Also, there is the option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207
Lionel GUEZ changed:
What|Removed |Added
CC||guez at lmd dot ens.fr
--- Comment #6
Assignee: unassigned at gcc dot gnu.org
Reporter: guez at lmd dot ens.fr
Target Milestone: ---
$ uname -a
Linux curie91 2.6.32-642.15.1.el6.Bull.110.x86_64 #1 SMP Wed Mar 1 14:13:44 CET
2017 x86_64 x86_64 x86_64 GNU/Linux
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
11 matches
Mail list logo