/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' '-mtune=generic'
/opt/gccsvn/libexec/gcc/x86_64-unknown-linux-gnu
--- 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=17791action=view)
.i of trivial example
Source was only one line:
#include gcc-plugin.h
--
--- 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 not
--- 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
--- 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
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
--- 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
--- 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
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
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Severity|normal |enhancement
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
--- 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 #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 #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 #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 #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 #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.
--
--- 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
--
--- 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?
--
--- 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 #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 #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=17792action=view)
debug output with -fdump-tree-all-details-blocks-vops
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--- 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
--- 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 #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 #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)
+++
--- 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 #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
--- 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.
--
--- 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
--- 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=gccview=revrev=147064
Log:
2009-05-02 Richard Guenther rguent...@suse.de
PR
--- 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=gccview=revrev=147065
Log:
2009-05-02 Richard Guenther rguent...@suse.de
PR
--- 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
--- 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
--- 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
--
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
--disable-bootstrap --enable-checking=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 yvoid
specialisation is not defined there is no error. As I'm not using the yvoid
specialisation, its contents should make
--- 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
--- 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 #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 #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
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
42 matches
Mail list logo
