I have started implementing this
--
Summary: F2008: Add NEWUNIT= for OPEN statement
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: jvdelisle at gcc dot
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-05-02 23:29
---
Unassigning, time constraints
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #30 from rguenth at gcc dot gnu dot org 2009-05-02 20:51
---
The specific code path doesn't exist in 4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--- Comment #29 from bonzini at gnu dot org 2009-05-02 20:35 ---
what about 4.4?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--- Comment #28 from bonzini at gnu dot org 2009-05-02 20:34 ---
Yes, fixed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|RESOLVED
ecking=release
Thread model: posix
gcc version 4.5.0 20090502 (experimental) (GCC)
If the base class is not a template there is no error, if the y
specialisation is not defined there is no error. As I'm not using the y
specialisation, its contents should make no difference to the instantiation o
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29648
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-02 17:55 ---
Hm, it's rather that the fix for &a vs. &a[0] doesn't apply to constructor
elements. *sigh*
Re-visiting the "real" fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39983
--- Comment #27 from rguenth at gcc dot gnu dot org 2009-05-02 17:51
---
Supposedly fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-02 17:50 ---
Supposedly fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #26 from rguenth at gcc dot gnu dot org 2009-05-02 17:50
---
Subject: Bug 39940
Author: rguenth
Date: Sat May 2 17:50:21 2009
New Revision: 147065
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147065
Log:
2009-05-02 Richard Guenther
PR tree-optimizatio
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-02 17:49 ---
Subject: Bug 40001
Author: rguenth
Date: Sat May 2 17:49:32 2009
New Revision: 147064
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147064
Log:
2009-05-02 Richard Guenther
PR middle-end/40001
--- Comment #1 from hp at gcc dot gnu dot org 2009-05-02 17:03 ---
This bug has been there for a long time, maybe too old to call it a regression
(I believe older than the currently open branches).
Look for changes in handling of GCC_EXEC_PREFIX internally (not just the
test-suite) and f
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2009-05-02 16:42
---
The cause of that is that module procedure are never entered into the global
symbol list (gfc_gsym_root). I think they should be there, under their mangled
name.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2009-05-02 16:26
---
Now, inlining of non-CONTAINED procedures works when -fwhole-file is used (it
will be the default when the remaining bugs are fixed).
However, functions from used modules are still not inlined; a reduced testcase
--- Comment #8 from kargl at gcc dot gnu dot org 2009-05-02 15:37 ---
For the code in Comment #1, I get
REMOVE:kargl[208] gfc4x -c -O -fwhole-file sa.f90
sa.f90:7.10:
call S1(z)
1
Warning: Type mismatch in argument 'z' at (1); passed COMPLEX(4) to REAL(4)
sa.f90:17.11:
--- Comment #25 from rguenth at gcc dot gnu dot org 2009-05-02 15:35
---
Ha, that helped. From looking at the dumps, can you check
Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c (revision 147054)
+++ gcc/tree-ssa-p
--- Comment #7 from dominiq at lps dot ens dot fr 2009-05-02 14:38 ---
> the problem is not bounds, but this:
Yes, I was just pointing out that ifort accept such cheating in another
context.
The problem reported by Richard Guenther for the SPEC 2006 benchmark is
different as related to
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2009-05-02 14:31
---
It's now working with -fwhole-file.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jv244 at cam dot ac dot uk 2009-05-02 14:26 ---
(In reply to comment #5)
> If I have read correctly the ifort man, ifort does not bounds check this kind
> of constructs (A(*) or A(1) in procs).
the problem is not bounds, but this:
Error: Element of assumed-shaped arr
--- Comment #24 from bonzini at gnu dot org 2009-05-02 14:20 ---
Created an attachment (id=17792)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17792&action=view)
debug output with -fdump-tree-all-details-blocks-vops
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--- Comment #23 from bonzini at gnu dot org 2009-05-02 14:16 ---
Now this is funny. I get the same error even with a cross from i686-darwin to
i686-pc-linux-gnu!
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from dominiq at lps dot ens dot fr 2009-05-02 14:16 ---
If I have read correctly the ifort man, ifort does not bounds check this kind
of constructs (A(*) or A(1) in procs).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40006
--- Comment #22 from dominiq at lps dot ens dot fr 2009-05-02 14:12 ---
> But jc1 builds if you just "make jc1", and it exhibits the same bug.
The difference between ppc and intel, is that for the former it does not break
bootstrap. Any idea why?
--
http://gcc.gnu.org/bugzilla/show
--- Comment #4 from jv244 at cam dot ac dot uk 2009-05-02 13:56 ---
a further case to hide behind an eventual switch
SUBROUTINE S3(a)
REAL :: a(*)
END SUBROUTINE
SUBROUTINE T3(a)
REAL, DIMENSION(:) :: a
CALL S3(a(1))
END SUBROUTINE T3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #21 from bonzini at gnu dot org 2009-05-02 13:53 ---
> Java has always been broken at -m64 on ppc-darwin since no one has ever ported
> ffi to work on ppc64 for darwin.
But jc1 builds if you just "make jc1", and it exhibits the same bug.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #20 from bonzini at gnu dot org 2009-05-02 13:51 ---
Also reproducible with compiler to powerpc-apple-darwin, same error message.
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2009-05-02 13:46
---
Patch submitted for review for the ERFC_SCALED compile-time version here:
http://gcc.gnu.org/ml/fortran/2009-05/msg00012.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from jv244 at cam dot ac dot uk 2009-05-02 13:44 ---
with gfortran -c -O0 --param ggc-min-heapsize=320 CP2K_2009-05-01.f90
things compile file (and need some 6Gb of memory).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #3 from jv244 at cam dot ac dot uk 2009-05-02 13:16 ---
(In reply to comment #2)
> Note that also one of the SPEC 2006 benchmark fail with -fwhole-file because
> of
> type cheating.
I would say that I know virtually no large F77 based project that would compile
as a single
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-02 13:04 ---
Note that also one of the SPEC 2006 benchmark fail with -fwhole-file because of
type cheating.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40006
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-02 13:03 ---
The C family of frontends distinguish between different strictness in standard
conformance testing (-pedantic, -pedantic-errors, -fpermissive).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40006
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40006
this is an enhancement for the -fwhole-file option. Like many other compilers
it would be good if gfortran would have a way (either default on not) to turn
the errors produced by -fwhole-file into just a warning. In particular, to
allow quasi-standard (type-cheating) abuse of procedures that are ca
--- Comment #2 from jv244 at cam dot ac dot uk 2009-05-02 12:43 ---
also 4.3.3. fails
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known to fail|4.4.0
--- Comment #1 from jv244 at cam dot ac dot uk 2009-05-02 12:22 ---
not specific to 4.5, also fails with
gcc version 4.4.0 20090414 (prerelease) [gcc-4_4-branch revision 146034] (GCC)
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
-
GNU Fortran (GCC) version 4.5.0 20090422 (experimental) [trunk revision 146549]
at -O0 segfaults on a recent CP2K:
http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2009-05-01.f90.gz
with the following bt from within gdb:
gdb
/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-02 10:45 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-02 10:19 ---
Confirmed. I hit
#ifdef ENABLE_CHECKING
/* Theoretically possible, but *highly* unlikely. */
gcc_assert (num_iterations < 500);
#endif
on trunk.
We seem to oscillate
ANTIC_IN[12] := { A1_1 (000
--- Comment #2 from joseph at codesourcery dot com 2009-05-02 09:34 ---
Subject: Re: New: gcc does not install appropriate plugin
headers
On Sat, 2 May 2009, bradh at frogmouth dot net wrote:
> Writing a plugin requires use of a range of headers (such as gcc-plugin.h)
> which are no
--- Comment #1 from bradh at frogmouth dot net 2009-05-02 07:23 ---
Created an attachment (id=17791)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17791&action=view)
.i of trivial example
Source was only one line:
#include "gcc-plugin.h"
--
http://gcc.gnu.org/bugzilla/show_bu
/devel/gcc-svn/configure --prefix=/opt/gccsvn
--enable-plugins
Thread model: posix
gcc version 4.5.0 20090502 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Dmy_gcc_plugin_EXPORTS' '-fPIC' '-o'
'dumb_plugin-orig.c.o' '-c&#x
42 matches
Mail list logo
