--- Comment #1 from bje at gcc dot gnu dot org 2009-08-19 06:14 ---
Confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from bje at gcc dot gnu dot org 2009-08-19 06:14 ---
Confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from bje at gcc dot gnu dot org 2009-08-19 06:15 ---
Confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from bje at gcc dot gnu dot org 2009-08-19 06:30 ---
Confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from jv244 at cam dot ac dot uk 2009-08-19 06:38 ---
I believe this is has an origin that could be related to PR41113
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36933
--- Comment #8 from burnus at gcc dot gnu dot org 2009-08-19 06:38 ---
Subject: Bug 41102
Author: burnus
Date: Wed Aug 19 06:38:29 2009
New Revision: 150931
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150931
Log:
2009-08-19 Tobias Burnus bur...@net-b.de
PR
--- Comment #9 from burnus at gcc dot gnu dot org 2009-08-19 07:01 ---
Subject: Bug 41102
Author: burnus
Date: Wed Aug 19 07:01:03 2009
New Revision: 150932
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150932
Log:
2009-08-19 Tobias Burnus bur...@net-b.de
PR
--- Comment #10 from burnus at gcc dot gnu dot org 2009-08-19 07:12 ---
Subject: Bug 41102
Author: burnus
Date: Wed Aug 19 07:11:43 2009
New Revision: 150933
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150933
Log:
2009-08-19 Tobias Burnus bur...@net-b.de
PR
--- Comment #11 from burnus at gcc dot gnu dot org 2009-08-19 07:14 ---
The lib_omp.h problem is FIXED on the trunk (4.5) and in the 4.3 and 4.4
branches.
I changed the title to the remaining issue: Having (similarity to C/C++) a
less strict checking for files coming from the system
This is on an AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ (using openSUSE
Factory in x86-64 mode).
When compiling the Polyhedron induct.f90 test case with and without
vectorization, the run time with vectorization is 30% longer. I think the
vectorization cost model needs to be tuned for this
--- Comment #4 from jakub at gcc dot gnu dot org 2009-08-19 08:29 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenther at suse dot de 2009-08-19 08:30 ---
Subject: Re: [4.5 Regression] FAIL:
gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64
On Tue, 18 Aug 2009, dominiq at lps dot ens dot fr wrote:
--- Comment #2 from dominiq at lps dot ens
--- Comment #1 from jv244 at cam dot ac dot uk 2009-08-19 08:58 ---
an ugly workaround is to write instead of
CALL S1(d%data)
the following
CALL S1(d%data(1))
which works in simple cases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41113
--- Comment #2 from ramana at gcc dot gnu dot org 2009-08-19 08:59 ---
(In reply to comment #1)
This fails for me with r149508 with a reload failure.
I don't seem to have a reload failure for this with 150624.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39716
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
Another case of a spurious pack (which really affects performance
unfortunately).
cat test.f90
MODULE M1
CONTAINS
SUBROUTINE S1(data)
REAL, DIMENSION(*) :: data
END SUBROUTINE S1
END MODULE
SUBROUTINE S2
REAL :: data(10,10)
DO i=1,10
CALL S1(data(:,i))
ENDDO
DO i=1,10
CALL
--- Comment #4 from jv244 at cam dot ac dot uk 2009-08-19 10:14 ---
more useless temps...the last two added eat quite a few percent of performance
in CP2K.
This really is an issue where frontend people need to step in to improve the
performance of gfortran.
--
jv244 at cam dot ac
--- Comment #12 from mikpe at it dot uu dot se 2009-08-19 10:38 ---
ICE confirmed with a gcc-4.4.1 cross to m68k-linux. Applying the PR37053 and
PR41064 fixes eliminated the ICE.
The mpegvideo.i test case does not compile as-is for me, as the compiler
complains about a syntax error:
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-19 10:38 ---
The testcase was reduced to an invalid one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-19 11:15 ---
I'm reducing again, from a single-file testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from abnikant dot singh at atmel dot com 2009-08-19 11:57
---
If HARD_REGNO_MODE_OK (r, mode1) and HARD_REGNO_MODE_OK (r, mode2) are always
the same for any r, then MODES_TIEABLE_P (mode1, mode2) should be nonzero. If
they differ for any r, you should define this macro
Consider this example:
cat pr41118.c EOF
void foo(int n, int *a, int *b)
{
int i;
for (i = 0; i n; i++)
a[i] = b[i];
}
EOF
gcc -S -O2 pr41118.c -floop-parallelize-all -ftree-parallelize-loops=2
grep GOMP 41118.s
GCC considers the loop parallel, even though arrays pointed to by
--- Comment #18 from jv244 at cam dot ac dot uk 2009-08-19 13:03 ---
pointing Toon to some lto timing/memory usage data for 'large' Fortran
programs..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41069#c12
--
jv244 at cam dot ac dot uk changed:
What|Removed
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-19 13:30 ---
Created an attachment (id=18401)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18401action=view)
Draft patch - first steps but incomplete will not work
The problem is:
CALL S1(d%data)
We have the variable
--- Comment #1 from burnus at gcc dot gnu dot org 2009-08-19 13:36 ---
See also PR 41113
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41117
Revision 150805:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00485.html
caused:
g++ -c -o mg_dof_tools.o -DSPEC_CPU -DNDEBUG -Iinclude -DBOOST_DISABLE_THREADS
-Ddeal_II_dimension=3 -O2 -ffast-math -DSPEC_CPU_LP64 mg_dof_tools.cc
g++ -c -o mg_smoother.o -DSPEC_CPU -DNDEBUG -Iinclude
--- Comment #1 from hjl dot tools at gmail dot com 2009-08-19 14:12 ---
It doesn't fail with preprocessed code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41119
--- Comment #2 from hjl dot tools at gmail dot com 2009-08-19 14:18 ---
Valgrind reports:
==22210== Invalid read of size 2
==22210==at 0x51521D: is_empty_class (class.c:6524)
==22210==by 0x482E70: build_call_a (call.c:356)
==22210==by 0x483FF2: build_cxx_call (call.c:5782)
-languages=c,c++
--no-create --no-recursion
Thread model: posix
gcc version 4.5.0 20090819 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps
--- Comment #1 from rubidium at openttd dot org 2009-08-19 14:30 ---
Created an attachment (id=18402)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18402action=view)
save-temps data
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41120
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-19 14:31 ---
See PR41120 for a testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Component|middle-end
--- Comment #1 from ubizjak at gmail dot com 2009-08-19 14:51 ---
Fixed in r150929.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2009-08-19 15:02 ---
It is caused by revision 150805:
http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00485.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41120
--- Comment #4 from hjl dot tools at gmail dot com 2009-08-19 15:06 ---
(gdb) bt
#0 0x005cec03 in is_empty_class (type=0xa5a5a5a5a5a5a5a5)
at ../../src/gcc/cp/class.c:6524
#1 0x0048 in build_call_a (function=0x70593e40, n=1,
argarray=0x7fffc750) at
With version r150889, compiling several BLAS and LAPACK source files produce
errors with the '-fimplicit-none' flag. For instance, when building
http://www.netlib.org/blas/dgbmv.f I get the following error message:
gfortran -c -fimplicit-none dgbmv.f
dgbmv.f:297.72:
END
--- Comment #29 from mahatma at eu dot by 2009-08-19 19:08 ---
(In reply to comment #28)
...
This is not mine and isn't needed.
OK. New patch working. While only so (tested in seamonkey with all included
libs).
Are realigning needed for both states of TREE_STATIC (decl)? Now in
--- Comment #2 from oliver dot kellogg at eads dot com 2009-08-19 18:54
---
Ada is not a default language currently and has not been since 4.0.0.
I find that counter-intuitive - how come all other languages are built,
just Ada is not?
--
introduced in the last few days:
gfortran -c small.f90
small.f90: In function write_cputime:
small.f90:1:0: internal compiler error: in gfc_conv_string_tmp, at
fortran/trans-expr.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html
--- Comment #1 from jv244 at cam dot ac dot uk 2009-08-19 19:21 ---
guessing:
2009-08-17 Janus Weil ja...@gcc.gnu.org
PR fortran/40877
* array.c (gfc_resolve_character_array_constructor): Add NULL argument
to gfc_new_charlen.
* decl.c
--- Comment #2 from dominiq at lps dot ens dot fr 2009-08-19 19:26 ---
Confirmed with trunk revision 150825, the code compiles for 4.2.4, 4.3.4,
4.4.1, and 4.5.0 revision 147438.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41126
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-19 19:40 ---
I think we finally should enable ada and obj-c++ by default if all requirements
are met.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-19 19:40 ---
Subject: Bug 41071
Author: rguenth
Date: Wed Aug 19 19:40:28 2009
New Revision: 150943
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150943
Log:
2009-08-19 Richard Guenther rguent...@suse.de
*
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-19 19:43 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from oliver dot kellogg at eads dot com 2009-08-19 20:42
---
I think we finally should enable ada and obj-c++ by default if all
requirements
are met.
Could you point me to the relevant discussion about these requirements?
Thanks.
--
The following code:
#define CHAR_BIT 8
enum EE {ee};
typedef unsigned int T;
struct D {
T : sizeof(unsigned int) * CHAR_BIT; // OK
EE : sizeof(EE) * CHAR_BIT; // OK
enum EE : sizeof(EE) * CHAR_BIT; // not OK
enum EE : sizeof(EE) * CHAR_BIT; // OK
T
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-19 21:02 ---
Requirements as in configure detects a host ada compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41124
--- Comment #7 from robert dot mance at intel dot com 2009-08-19 21:28
---
I've managed to download and install 4.4.5 of gfortran and can verify that what
you're doing here is just about identical to what ifort is doing.
I have a request to emit a DW_TAG_common_inclusion record in
--- Comment #4 from carrot at google dot com 2009-08-19 21:55 ---
(In reply to comment #2)
Why does the basic block reordering pass also not handle this?
Basic block reordering is disabled with options -Os.
The basic block reordering algorithm is for performance only, it usually
--- Comment #2 from jakub at gcc dot gnu dot org 2009-08-19 22:51 ---
Subject: Bug 41123
Author: jakub
Date: Wed Aug 19 22:51:20 2009
New Revision: 150946
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150946
Log:
PR middle-end/41123
* expr.c (expand_expr_real_1)
--- Comment #3 from jakub at gcc dot gnu dot org 2009-08-19 22:52 ---
Subject: Bug 41123
Author: jakub
Date: Wed Aug 19 22:52:11 2009
New Revision: 150947
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150947
Log:
PR middle-end/41123
* expr.c (expand_expr_real_1)
--- Comment #4 from jakub at gcc dot gnu dot org 2009-08-19 22:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from kargl at gcc dot gnu dot org 2009-08-19 23:00 ---
Here's the backtrace
#0 gfc_conv_string_tmp (se=0x7fffdd70, type=0x201afec00, len=0x201af8d20)
at ../../gcc4x/gcc/fortran/trans-expr.c:1107
#1 0x0050c0be in gfc_conv_intrinsic_adjust (se=0x7fffdd70,
--- Comment #5 from rth at gcc dot gnu dot org 2009-08-19 23:06 ---
Basic block reordering *should* be altered to work with -Os.
It's definitely required to clean up silly jump sequences that
exception handling creates.
There's no reason, in principal, that the ordering algorithm
can't
6 honappal ezelott egy nagyszabasu hadmuveletbe fogtak a magyar jatekosok a
neten.
eMagyarorszag roman megszallas ala kerult,es vissza akartunk vagni.
4 honapig tatott a csata. 16 ezer magyar jatekos gyurte a a 18 ezres roman
sereget.
Es nyertunk.Visszafoglaltuk eMagyarorszagot, es
--- Comment #7 from joseph at codesourcery dot com 2009-08-19 23:58 ---
Subject: Re: 'configure' checks for Ada compiler but
does not build one
On Wed, 19 Aug 2009, jakub at gcc dot gnu dot org wrote:
obj-c++ isn't built by default either. And in both cases it is intentional.
It
The command line input
$ gcc max_memory.c -o max_memory.exe
currently gives
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot
find -luser32
collect2: ld returned 1 exit status
The command worked fine initially. Any suggestion as to correcting error would
be greatly
checking for wchar.h... (cached) yes
checking for wctype.h... (cached) yes
checking for ld version... 21901
checking for ld that supports -Wl,--gc-sections... configure: error:
Link tests are not allowed after GCC_NO_EXECUTABLES.
make[2]: *** [configure-target-libstdc++-v3] Error 1
The following code segment
program scr
type S1
real, dimension(:), pointer :: P ! NLEV
real, dimension(:), pointer :: t ! NLEV
end type S1
type S0
real, dimension(:), pointer :: P ! NLEV
end type S0
type (S0) :: x0
type (S1) :: x1
write
--- Comment #1 from evan dot fishbein at jpl dot nasa dot gov 2009-08-20
04:11 ---
(In reply to comment #0)
The following code segment
program scr
type S1
real, dimension(:), pointer :: P ! NLEV
real, dimension(:), pointer :: t ! NLEV
end type
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-08-20 04:42 ---
This is a bug in your installation of GCC and cygwin.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2009-08-20 05:59 ---
gfortran 4.5.0 gives
REMOVE:kargl[5] ./z
x0%P T
x0%P T
x1%P F
x1%P T
Given that you are using a f95 compiler, I believe that you are
invoking processor-dependent behavior. F95 states
2.4.6Pointer
A
62 matches
Mail list logo
