y: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ajmay81 at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40142
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ajmay81 at googlemail dot com
Target Milestone: ---
Looks like a regression between 10.1.0 and 10.2.0. test.f90:
module test_module
implicit none
contains
subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54678
Bug #: 54678
Summary: second call to get_environment_variable gives valgrind
warning with 8-byte integers
Classification: Unclassified
Product: gcc
Version: 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53685
--- Comment #6 from Andy May 2012-09-24
13:57:37 UTC ---
Thanks for fixing this, the GCC 4.7.1 shipping with openSUSE 12.2 does not show
this problem, and a build of GCC 4.7.2 from source doesn't either. Providing
this has also been pushed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53685
Bug #: 53685
Summary: surprising warns about transfer with explicit
character range
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53714
Bug #: 53714
Summary: false positive for -Wuninitialized
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ajmay81 at googlemail dot com
Target Milestone: ---
When writing and then reading back values from a file on Windows (program built
with gfortran via mxe cross compiler) the wrong values are read. Here is a
trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684
--- Comment #4 from Andy May ---
Yes, I agree that demonstrates the bug - and I see it gives the desired output
with 4.8.3 but not with 5.3.0.
However, I would actually not mind if that modified testcase continued not to
'work' on Linux since th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684
--- Comment #12 from Andy May ---
I don't know that it's necessary or desired to support both '\n' and '\r' as
eol, but instead the native eol just needs to be used consistently everywhere,
for example something like the following pseudo code:
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684
--- Comment #14 from Andy May ---
(In reply to Jerry DeLisle from comment #13)
> (In reply to Andy May from comment #12)
> > I don't know that it's necessary or desired to support both '\n' and '\r' as
> > eol, but instead the native eol just nee
10 matches
Mail list logo
