https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70350
Lorenz Hüdepohl changed:
What|Removed |Added
CC||bugs at stellardeath dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66640
--- Comment #2 from Lorenz Hüdepohl ---
(In reply to Dominique d'Humieres from comment #1)
> I cannot reproduce this PR on darwin (no addr2line).
>
> Could you check that this has not been fixed on a recent version of trunk
> (6.0): post
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at stellardeath dot org
Target Milestone: ---
Symbolic backtraces seem to be implemented by a fork()/execve() to addr2line.
when this is done from within
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at stellardeath dot org
cpp is often (mis)used for non-C files, many Fortran projects for example
prefer to run a separate preprocessor step by invoking cpp by hand instead of
relying on the built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57284
--- Comment #3 from Lorenz Hüdepohl bugs at stellardeath dot org ---
Any progress on this one? 4.9.2 still produces the error:
~/sys/stow/gcc-4.9.2/bin/gfortran --version
GNU Fortran (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64947
--- Comment #1 from Lorenz Hüdepohl bugs at stellardeath dot org ---
Also present in 4.8.3:
# gfortran --version
GNU Fortran (SUSE Linux) 4.8.3 20141208 [gcc-4_8-branch revision 218481]
Copyright (C) 2013 Free Software Foundation, Inc.
GNU
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at stellardeath dot org
Created attachment 34676
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34676action=edit
Fairly minimal testcase to trigger the bug.
The following (IMO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854
--- Comment #7 from Lorenz Hüdepohl bugs at stellardeath dot org ---
Use valgrind or -fsanitize=address to detect this kind of
memory problems.
I can live with that, thanks for your comments!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854
--- Comment #2 from Lorenz Hüdepohl bugs at stellardeath dot org ---
(Please remove the line use m1 from my example, its a leftover from a
previous
version)
I'm not denying that there is a mistake in the example program. I just hoped
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at stellardeath dot org
I assumed that the following would be catched by -fcheck=bounds,
array a is passed as an explicit-shape array to subroutine
testsub with the invalid bounds n1, n2:
program test
use m1
implicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64854
--- Comment #4 from Lorenz Hüdepohl bugs at stellardeath dot org ---
The right way to fix the problem is to fix the program
by using an appropriate programming style. Writing
real:: a(n1:) ! not: real :: a(n1:n2)
one gets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59488
Lorenz Hüdepohl bugs at stellardeath dot org changed:
What|Removed |Added
CC||bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59537
--- Comment #6 from Lorenz Hüdepohl bugs at stellardeath dot org ---
Nonetheless, code that compiles without -finit-real should also compile
with -finit-real, right?
I disagree: C506 states that automatic object cannot be initialized. What
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at stellardeath dot org
gfortran produces an internal compiler error when one mistakenly specifies a
file instead
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59537
--- Comment #4 from Lorenz Hüdepohl bugs at stellardeath dot org ---
From the above gfortran is right to reject the code with initialization.
Without the SAVE statement it compiles fine.
From the above (C513) this is a bug, the code should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59537
--- Comment #1 from Lorenz Hüdepohl bugs at stellardeath dot org ---
Maybe related to the already fixed #51800?
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at stellardeath dot org
Created attachment 31461
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31461action=edit
Minimal example code
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at stellardeath dot org
Created attachment 30220
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at stellardeath dot org
Created attachment 30205
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30205action=edit
Minimal test case
When trying to reduce a test-case with delta, I stumbled upon this
(unrelated) invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57435
--- Comment #1 from Lorenz Hüdepohl bugs at stellardeath dot org ---
Seems the output of cat got dropped, for those who do not want to look at the
attached file:
cat gfortran_check_for_ambiguous.f90
module precision
end module precision
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at stellardeath dot org
Created attachment 30182
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30182action=edit
Small test case
The following example program produces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57396
--- Comment #1 from Lorenz Hüdepohl bugs at stellardeath dot org ---
As the loop is quite confusing, i wrote a small python program to reproduce the
correct result:
cat test.py
def foo(n):
r = {}
a = {}
# initialize with some dummy
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at stellardeath dot org
Created attachment 30165
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30165action=edit
Minimal test case
The following invalid code (with a number instead of an identifier
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at stellardeath dot org
Created attachment 30119
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30119action=edit
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bugs at stellardeath dot org
The following invalid code produces an internal error. It is invalid as it uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57285
--- Comment #1 from Lorenz Hüdepohl bugs at stellardeath dot org ---
Created attachment 30120
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30120action=edit
Minimal test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57284
--- Comment #1 from Lorenz Hüdepohl bugs at stellardeath dot org ---
Might be related to Bug #57285
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56852
Bug #: 56852
Summary: ICE on invalid: Bad array reference for an
undeclared loop variable
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55827
Bug #: 55827
Summary: ICE with multiple fortran modules and character lenght
determined by an interfaced pure function
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55827
--- Comment #1 from Lorenz Hüdepohl bugs at stellardeath dot org 2012-12-28
21:12:28 UTC ---
Forgot the actual compiler output, this is of a self-compiled gcc (checked out
2012/12/22), see below for an 4.7.1:
# gfortran -v -fimplicit-none -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51713
Bug #: 51713
Summary: Type mismatch for polymorphic dummy arguments
depending on use path
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status:
31 matches
Mail list logo
