--- Comment #2 from burnus at gcc dot gnu dot org 2006-12-15 17:54 ---
http://gcc.gnu.org/ml/fortran/2006-12/msg00112.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30227
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-15 22:05 ---
Test case (save as *.f file and use gfortran -O2 -c)
SUBROUTINE SGET33( KNT )
INTEGERKNT, IM4, J1
REAL RES, Q( 2, 2 )
DO 80 IM4 = 1, 3
DO 10 J1 = 1, 2
gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30228
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30238
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-17 20:15 ---
This is because in symbol.c's gfc_add_type there is
const char *msg = Symbol '%s' at %L already has basic type of %s;
if (!(sym-ts.type == ts-typesym-ts.type == ts-type
(sym-attr.flavor
--- Comment #2 from burnus at gcc dot gnu dot org 2006-12-17 21:20 ---
As long as the callee doesn't change the value it's probably valid, so this
would need some kind of interprocedural analysis to give a correct error.
I think it is formally seen invalid as you have INTENT([IN]OUT
--- Comment #17 from burnus at gcc dot gnu dot org 2006-12-17 23:19 ---
Using the patch of PR 30223 (add cbrt, cexpi and sincos to Fortran), I don't
get any speed up (21.95s for fatigue).
Using additionally http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00958.html
(folding of cexp ()) I
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-18 07:49 ---
This was a fix for a PR about a year ago - the std=gnu is meant, obviously, to
enforce all versions of the standard on this. However, a number of other
compilers did/do permit this wrinkle on the standard
--- Comment #5 from burnus at gcc dot gnu dot org 2006-12-18 10:04 ---
This feature is now part of the fortran-experiments branch, available at:
svn://gcc.gnu.org/svn/gcc/branches/fortran-experiments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25709
--- Comment #7 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 30022
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
svn+ssh
--- Comment #37 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 29568
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
svn+ssh
--- Comment #8 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 30040
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
svn+ssh
--- Comment #9 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 30033
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
svn+ssh
--- Comment #4 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 27953
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
svn+ssh
--- Comment #4 from burnus at gcc dot gnu dot org 2006-12-19 17:15 ---
Subject: Bug 30021
Author: burnus
Date: Tue Dec 19 17:14:22 2006
New Revision: 120053
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120053
Log:
Merged revisions 119412-119459 via svnmerge from
svn+ssh
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
--- Comment #2 from burnus at gcc dot gnu dot org 2006-12-21 15:17 ---
http://gcc.gnu.org/ml/gcc-cvs/2006-12/msg00691.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from burnus at gcc dot gnu dot org 2006-12-21 15:20 ---
Will this be be fixed for 4.1 too? Or can this PR be closed?
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #42 from burnus at gcc dot gnu dot org 2006-12-21 16:09 ---
I'm in faviour of closing this bug.
The patch associated to this PR is checked in into 4.3 and 4.2
And all the dependend bugs are either fixed or at least check into 4.3.
--
http://gcc.gnu.org/bugzilla
--- Comment #6 from burnus at gcc dot gnu dot org 2006-12-21 16:18 ---
Note the patch was submitted 19/12 but the tracking system seems to have lost
it.
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01326.html
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-22 12:56 ---
Confirmed. I think the following patch should work. I'll take the bug next year
(if I don't forget). Otherwise, if someone wants to take it, feel free to do
so.
The problem is that only
for include_path
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-25 17:55 ---
I think the proper fix is to add . to the search list of directories where
include files may live.
I don't see how this will help; adding . for
'/home/allan/slot2usl/physcons.inc', searches at
./home/allan
--- Comment #3 from burnus at gcc dot gnu dot org 2007-01-02 12:48 ---
Subject: Bug 30238
Author: burnus
Date: Tue Jan 2 12:48:14 2007
New Revision: 120338
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120338
Log:
fortran/
2007-01-02 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-02 12:48 ---
Now also fixed in 4.2.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
--- Comment #11 from burnus at gcc dot gnu dot org 2007-01-02 15:10 ---
(Just to make sure it is not forgotten:)
A draft patch was posted (quite a while ago) by FX:
http://gcc.gnu.org/ml/fortran/2006-11/msg00634.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649
--- Comment #6 from burnus at gcc dot gnu dot org 2007-01-02 15:54 ---
Subject: Bug 30276
Author: burnus
Date: Tue Jan 2 15:54:20 2007
New Revision: 120344
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120344
Log:
2007-01-02 Tobias Burnus [EMAIL PROTECTED]
PR fortran
--- Comment #7 from burnus at gcc dot gnu dot org 2007-01-02 15:55 ---
Fixed in 4.3; I will commit the patch for 4.2 in about a week; I will not fix
4.1.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from burnus at gcc dot gnu dot org 2007-01-04 08:57 ---
Subject: Bug 30276
Author: burnus
Date: Thu Jan 4 08:57:36 2007
New Revision: 120431
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120431
Log:
2007-01-02 Tobias Burnus [EMAIL PROTECTED]
Jakub
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30373
optimization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-05 09:08 ---
Subject: Bug 29624
Author: burnus
Date: Fri Jan 5 09:08:37 2007
New Revision: 120472
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120472
Log:
fortran/
2007-01-05 Tobias Burnus [EMAIL PROTECTED
--- Comment #5 from burnus at gcc dot gnu dot org 2007-01-05 09:20 ---
Fixed in 4.3.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #46 from burnus at gcc dot gnu dot org 2007-01-06 09:22 ---
(In reply to comment #44)
Current gcc ICEs again on CP2K
I tried to reproduce this with gfortran (trunk) of yesterday with CP2k of today
- and I failed to get an ICE. I tried then to directly use gfortran-4.2
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-08 13:23 ---
A look into resolve.c's resolve_where, shows that only EXEC_ASSIGN and not
EXEC_ASSIGN_CALL exists in switch (cnext-op).
Expected: As elemental procedures are also allowed, a case EXEC_ASSIGN_CALL:
has to be added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-08 13:26 ---
0x0044fe6e in resolve_code (code=0xe2f690, ns=0xe2eb60) at
fortran/resolve.c:5097
5097 if (sym-ts.cl-length-expr_type == EXPR_CONSTANT)
(gdb) bt
#1 0x0045042d in resolve_codes (ns
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-08 13:33 ---
Which version of gfortran did you use and which options?
I cannot reproduce it with 4.3.0 20070108 on x86_64-unknown-linux-gnu.
(Thus it is either platform specific or a newer or older bug than my version
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-08 22:25 ---
It appears that the fix to PR 29624 also fixed this one properly.
So far I had only managed to cause collateral damage not collateral fixes :-)
--
burnus at gcc dot gnu dot org changed:
What
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30476
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30481
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-16 21:30 ---
Confirmed with gfortran 4.3.0 20070116.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-16 21:50 ---
Fortran 95:
Constraint:
A namelist-group-object shall not be an array dummy argument with a nonconstant
bound, a variable with nonconstant character length, an automatic object, a
pointer, a variable of a type
traceback (backtrace) on errors
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot
--- Comment #14 from burnus at gcc dot gnu dot org 2007-01-18 12:54 ---
Subject: Bug 29649
Author: burnus
Date: Thu Jan 18 12:54:11 2007
New Revision: 120897
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120897
Log:
2007-01-18 Francois-Xavier Coudert [EMAIL PROTECTED
--- Comment #15 from burnus at gcc dot gnu dot org 2007-01-18 12:56 ---
Fixed in the trunk.
Creating a backtrace is now PR 30498.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-20 09:37 ---
Vaguely related is:
trans-intrinsic.c's gfc_conv_intrinsic_minmaxval, which contains currently:
/* Most negative(-HUGE) for maxval, most positive (-HUGE) for minval. */
if (op == GT_EXPR)
tmp = fold_build1
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-20 12:46 ---
Non-library part of this fix.
This fixes the reported bug, but libgfortran/m4/* should be fixed as well.
m4/iparm.m4 contains:
define(atype_max, atype_name`_HUGE')dnl
define(atype_min, `-'atype_max)dnl
One would
-invalid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30520
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
ReportedBy: burnus at gcc dot gnu dot org
BugsThisDependsOn: 30520
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30522
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-21 16:16 ---
Subject: Bug 30015
Author: burnus
Date: Sun Jan 21 16:16:10 2007
New Revision: 121033
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121033
Log:
2006-12-09 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-22 08:47 ---
For what it's worth, the Intel and Sun compilers have the behaviour you
expect, but the Portland compiler and g95 both have the same behaviour as
gfortran.
NAG f95 and pathscale 2.4 have: -128.
If I understand
OpenMP settings
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30549
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-22 22:17 ---
This fixes the PR but I have not yet determined if it is standard conforming
behaviour
See 5.1.2.5.1 Explicit-shape array:
If the upper bound is less than the lower bound, the range is empty, the
extent
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-22 22:25 ---
No, that means it is used possiable as null.
You need to check inside pure_function to see if there is a way that the
second argument does not get initialized.
There is:
if (e-symtree != NULL
e
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-23 10:34 ---
Based on the bugreport by Ignacio Fernández Galván
http://gcc.gnu.org/ml/fortran/2007-01/msg00531.html
The test case has been extracted from the Dynamo package,
http://www.pdynamo.org/Installation.html
--
http
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-23 20:56 ---
Some more debug information:
The error occurs when the symbol hessian is written.
The error is gone if one removes the : only ENERGY_CONSTRAINT or the use
atoms from the POTENTIAL_ENERGY module (if you have {atom
--- Comment #2 from burnus at gcc dot gnu dot org 2007-01-26 11:06 ---
And OMP_NUM_THREADS's default setting is completely undefined; does it
use by default one or the maximal number of available processors?
Section 3.3 states:
If undefined one thread per CPU online is used
--- Comment #8 from burnus at gcc dot gnu dot org 2007-01-29 08:40 ---
Should we commit the combined fix? I do think this
is a bug.
So do I, but we also need a test case, I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
--- Comment #5 from burnus at gcc dot gnu dot org 2007-01-30 17:53 ---
Subject: Bug 30015
Author: burnus
Date: Tue Jan 30 17:52:46 2007
New Revision: 121348
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121348
Log:
2007-01-30 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2007-01-30 17:56 ---
Fixed in 4.3 and 4.2. I don't plan to fix it in 4.1.
= FIXED.
Thanks again for reporting this bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from burnus at gcc dot gnu dot org 2007-01-30 17:58 ---
Let's then fix this bug.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from burnus at gcc dot gnu dot org 2007-01-30 18:13 ---
Subject: Bug 30276
Author: burnus
Date: Tue Jan 30 18:13:14 2007
New Revision: 121350
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121350
Log:
2007-01-30 Tobias Burnus [EMAIL PROTECTED]
Jakub
--- Comment #11 from burnus at gcc dot gnu dot org 2007-01-30 18:14 ---
Paul Thomas wrote on 2007-01-14:
Fixed in 4.3; I will commit the patch for 4.2 in about a week; I will not
fix
4.1.
Are you in a position to do that now? The week is up and all is well:)
Finally fixed
--- Comment #3 from burnus at gcc dot gnu dot org 2007-01-31 09:18 ---
Subject: Bug 30520
Author: burnus
Date: Wed Jan 31 09:18:33 2007
New Revision: 121379
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121379
Log:
fortran/
2007-01-31 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2007-01-31 09:20 ---
FIXED in gcc 4.3 (note: VOLATILE is not in 4.2).
See PR 30522 for the missing parts.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from burnus at gcc dot gnu dot org 2007-01-31 09:55 ---
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00145.html
Do we have consensus yet on this?
The standard is not exactly straight forward interpret.
I'm not 100% sure. The standard is indeed not very clear about
--- Comment #11 from burnus at gcc dot gnu dot org 2007-01-31 10:24 ---
Subject: Bug 27588
Author: burnus
Date: Wed Jan 31 10:23:53 2007
New Revision: 121401
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121401
Log:
(This part was missing in the r118852 / Wed Nov 15 10:13:16
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
for
files containing only procedures
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu
--- Comment #1 from burnus at gcc dot gnu dot org 2007-01-31 19:54 ---
For completeness, it came up here:
http://gcc.gnu.org/ml/fortran/2006-09/msg00381.html
It came up again
http://gcc.gnu.org/ml/fortran/2007-01/msg00716.html
The c.l.fortran thread mentioned there is
http
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30664
--- Comment #16 from burnus at gcc dot gnu dot org 2007-02-01 09:27 ---
Is this bug fixed or not? I see a 4.3 and a 4.2 check in.
Or is something missing, if yes, what?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30667
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-02 07:50 ---
This actually planed to do, cf.
http://gcc.gnu.org/wiki/GFortran43
Projects for inclusion into gfortran-4.3
Formal/actual argument checking for same file procedures
There are a large number of PRs associated
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-02 10:03 ---
The patch seems to fix the problem with the test file. Unfortunately, the
original problem with the Dynamo package remains:
Modified test case - added:
PRIVATE
PUBLIC :: ENergY_CONTRAINT
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30682
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-03 16:40 ---
We should really be initializing our starting values to +/-Inf, both
in the library and the front end.
In principle yes, but we need still return +HUGE or -HUGE (respectively
-HUGE-1) for arrays with zero elements
--- Comment #4 from burnus at gcc dot gnu dot org 2007-02-04 00:19 ---
Thomas asked at c.l.f:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e3745c39a11522c5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-05 14:45 ---
Thanks, aermod now works. :-)
channel, gas_dyn, induct, nf, protein, rnflow still fail respectively fail now.
$ gfortran -fprofile-generate -march=opteron -ffast-math -funroll-loops
-ftree-vectorize -O3 -o channel
--- Comment #5 from burnus at gcc dot gnu dot org 2007-02-05 19:40 ---
As Dick Hendrickson points out in c.l.fortran:
13.7 (the function descriptions) says
A program is prohibited from invoking an intrinsic procedure under
circumstances where a value to be returned in a subroutine
--- Comment #7 from burnus at gcc dot gnu dot org 2007-02-06 12:30 ---
I don't know what the status is of the other patch for MAXVAL/MINVAL, but we
should probably combine them into a single patch (in particular to ease the
backporting).
The status of the other patch is: Waiting
--- Comment #4 from burnus at gcc dot gnu dot org 2007-02-06 16:34 ---
Not that it much helps, but with today's gcc under x86_64-unknown-linux-gnu it
does not crash.
Maybe someone with Intel Mac can reproduce it.
Oherwise:
Compile with the -v option, e.g. gfortran -v -O3 env_grid.f
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-06 16:52 ---
Confirmed. It crashes with -O but not without optimization.
Reduced test case:
Subroutine xcc_V_CONVERT(iepoch)
implicit none
logical :: IEPOCH
real:: XVECTOR(1:3)
real:: YVECTOR(1:3
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-06 17:45 ---
Reduced test case:
The line xvector = 0.0 can also be removed. The dump-tree-original looks then
as follows:
xcc_v_convert (iepoch)
{
real4 xvector[3];
real4 yvector[3];
if (*iepoch)
{
(void
--- Comment #1 from burnus at gcc dot gnu dot org 2007-02-07 07:56 ---
Patch: http://gcc.gnu.org/ml/gcc/2007-02/msg00094.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-02-07 09:47 ---
Patch implementing the -fbacktrace option
I think one should add also some userhandler
signal(SIGSEGV, my_segv_handler);
which calls show_backtrace and exits/coredumps then.
That way we calso get a backtrace
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-08 07:32 ---
Seemingly fixed
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
BugsThisDependsOn: 30522
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30733
--- Comment #8 from burnus at gcc dot gnu dot org 2007-02-09 09:55 ---
Hi,
I cannot judge how much work this would be, but would it be possible to extend
this patch a little further so that these backtraces can be requested by the
user?
Well, this is possible if one combines
--- Comment #11 from burnus at gcc dot gnu dot org 2007-02-09 21:56 ---
Subject: Bug 30512
Author: burnus
Date: Fri Feb 9 21:56:06 2007
New Revision: 121777
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121777
Log:
fortran/
2007-02-09 Tobias Burnus [EMAIL PROTECTED
: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30783
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-13 18:19 ---
From the Fortran 2003 standard:
--
C528 (R501) If the VALUE attribute is specified, the length type parameter
values shall be omitted or specified by initialization expressions.
--
Which
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
201 - 300 of 4244 matches
Mail list logo
