gfortran
fff.f90: In function 'foo_child':
fff.f90:26:0: internal compiler error: in gfc_conv_structure, at
fortran/trans-expr.c:4390
NAG:
Error: fff.f90, line 29: THIS is neither a POINTER nor a TARGET
detected at PARENT@end-of-statement
IBM:
Final_test.F90, line 27.20: 1514-648 (S) A
--- Comment #10 from laurent at guerby dot net 2010-02-28 09:05 ---
Fixed on arm-linux
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02695.html
powerpc-linux:
http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg02720.html
Thanks!
--
--- Comment #11 from rwild at gcc dot gnu dot org 2010-02-28 09:57 ---
Patches posted at http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01236.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980
--- Comment #12 from aph at gcc dot gnu dot org 2010-02-28 10:07 ---
I can't duplicate this problem with gcc trunk and binutils 2.20-0ubuntu2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-28 10:18 ---
Possibly related:
implicit none
type, abstract :: parent
integer :: i
end type
type, extends(parent) :: child
end type
type(child) :: c1, c1a
class(child), allocatable :: c2
print *, c1%parent%i
--- Comment #5 from pluto at agmk dot net 2010-02-28 10:41 ---
*** This bug has been marked as a duplicate of 42980 ***
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #12 from pluto at agmk dot net 2010-02-28 10:41 ---
*** Bug 38388 has been marked as a duplicate of this bug. ***
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2010-02-28 10:59 ---
Although this pr report a problem for parallel make without install it may be a
duplicate of pr38388.
See also http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01236.html .
--
dominiq at lps dot ens dot fr changed:
--- Comment #6 from rwild at gcc dot gnu dot org 2010-02-28 11:08 ---
Actually, except for the libiberty failure, these failures are different, and
not fixed by the patches for PR 42980. De-duplicating and reopening.
Can you still reproduce the Ada-related failures? It looks like
--- Comment #5 from rwild at gcc dot gnu dot org 2010-02-28 11:15 ---
(In reply to comment #4)
Although this pr report a problem for parallel make without install it may be
a
duplicate of pr38388.
That seems unlikely to me. The cited PR does not change nor concern 'make all'
--- Comment #9 from baldrick at gcc dot gnu dot org 2010-02-28 11:18
---
Yes, that did the trick. Thanks for fixing this!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
--- Comment #13 from dominiq at lps dot ens dot fr 2010-02-28 11:20 ---
Thanks for testing! In trans-array.c's gfc_trans_deferred_array, my current
version has
- if (sym-value)
+ if (sym-value == NULL || !has_default_initializer (sym-ts.u.derived))
--- Comment #1 from dominiq at lps dot ens dot fr 2010-02-28 11:20 ---
Confirmed as a regression (see pr43178 comment #13 for the modified test case):
trunk revision 156618
[macbook] f90/bug% time gfc_c -fno-automatic -finit-integer=-100 pr43205_db.f90
4.575u 0.463s 0:06.59 76.3%
--- Comment #6 from dominiq at lps dot ens dot fr 2010-02-28 11:29 ---
It would however be interesting to know whether this PR is
reproducible with parallel make only.
Indeed, but so far it is not (see comment #3). Do you have any idea of what I
could do to make it reproducible?
--
In function 'g':
lto1: error: invalid conversion in return statement
struct list_node *
struct list_node *
return D.2037_1;
lto1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-02-28
11:40 ---
Created an attachment (id=19985)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19985action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43208
--- Comment #7 from rwild at gcc dot gnu dot org 2010-02-28 11:42 ---
(In reply to comment #6)
It would however be interesting to know whether this PR is
reproducible with parallel make only.
Indeed, but so far it is not (see comment #3).
What does your reply mean? Does it mean
--- Comment #9 from mikpe at it dot uu dot se 2010-02-28 11:53 ---
(In reply to comment #8)
Subject: Bug 42585
Author: hjl
Date: Sun Feb 7 04:41:22 2010
New Revision: 156562
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156562
Log:
Backport testcases from mainline to
--- Comment #8 from dominiq at lps dot ens dot fr 2010-02-28 11:59 ---
(In reply to comment #7)
Please do not answer with yes or no, make it easy for readers to follow you by
formulating a full sentence statement as to what you mean. Thank you.
On a Core2 Duo
--- Comment #9 from rwild at gcc dot gnu dot org 2010-02-28 12:22 ---
(In reply to comment #8)
On a Core2 Duo (x86_64-apple-darwin10), I see the libgomp comparison fails in
a
no reproducible way with both -j2 and -j3 (probability since the first
occurrence at r 156585: 4 times for
--- Comment #10 from dominiq at lps dot ens dot fr 2010-02-28 12:32 ---
(In reply to comment #8)
Thank you, very well. Can you (or somebody else who sees the failure with
-jN,
N1) try a bootstrap on x86_64-apple-darwin10 with non-parallel make from a
clean directory?
I don't
Command line:
gcc -O1 testcase.c
(fails at all -O[123] levels)
Tested revisions:
r156999 - crash
r156745 - crash
r156293 - OK
4.4 r156256 - OK (with checking)
Output (with checking):
$ mnt/svn/gcc-trunk/binary-156999-lto/bin/gcc -O1 testcase.c
testcase.c: In function 'foo':
testcase.c:1:6:
--- Comment #1 from zsojka at seznam dot cz 2010-02-28 13:42 ---
Created an attachment (id=19986)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19986action=view)
reduced testcase
Command line:
gcc -O1 pr43209.c
(or -O2, -O3)
--
--- Comment #10 from pault at gcc dot gnu dot org 2010-02-28 13:46 ---
(In reply to comment #9)
Reduced test case below. The problem is the call. On the trunk the call looks
as follows:
set_set_v (ru, D.1578);
which is complete nonesense. It should be:
ru.data[0].c.use
or
--- Comment #2 from zsojka at seznam dot cz 2010-02-28 13:49 ---
4.4 r157120 works fine too
testcase doesn't fail at -O2, -O3 (in trunk)
--
zsojka at seznam dot cz changed:
What|Removed |Added
Follow up to PR 43205
subroutine test()
integer, SAVE :: hugeArray(1000,1000) = 42
generates a huge initializer of the type:
static integer(kind=4) hugeArray = {42, 42, 42, , 42};
It would be possible to reduce the compile time and object size by initializing
it a run time:
static
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-28 14:05 ---
CONFIRMED. For zero initialization, the created dump should look like:
static integer(kind=4) variable(10) = {};
rather than
static integer(kind=4) variable(10) = {0,0,0,0,0,0,,0,0};
I think as
Command line:
gcc testcase.c
Tested revisions:
r156999 - crash
r155363 - crash
r153685 - crash
4.4 r157120 - OK (with checking)
4.3.4 - OK (without checking)
Output (with checking):
$ /mnt/svn/gcc-trunk/binary-156999-lto/bin/gcc testcase.c
testcase.c:7:19: error: parameter 1 ('t') has incomplete
--- Comment #1 from zsojka at seznam dot cz 2010-02-28 14:15 ---
Created an attachment (id=19987)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19987action=view)
reduced testcase
Command line:
gcc pr43211.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43211
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-28 15:02 ---
A bonus: There should be only a single logical initialized variable for all
initializers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210
--- Comment #2 from domob at gcc dot gnu dot org 2010-02-28 15:07 ---
*** This bug has been marked as a duplicate of 43169 ***
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from domob at gcc dot gnu dot org 2010-02-28 15:07 ---
*** Bug 42912 has been marked as a duplicate of this bug. ***
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
1.c
extern void baz(void);
void foo(void)
{
baz();
}
2.c
extern __attribute__((__noreturn__)) void baz(void);
void bar(void)
{
baz();
}
=
$
--- Comment #11 from dominiq at lps dot ens dot fr 2010-02-28 15:39 ---
I just completed successfully a clean non-parallel bootstrap at revision 157122
with
../p_work/configure --prefix=/opt/gcc/gcc4.5p
--mandir=/opt/gcc/gcc4.5p/share/man --infodir=/opt/gcc/gcc4.5p/share/info
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-28 16:16 ---
Subject: Bug 43205
Author: burnus
Date: Sun Feb 28 16:16:22 2010
New Revision: 157123
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157123
Log:
2010-02-28 Tobias Burnus bur...@net-b.de
PR
--- Comment #3 from hjl dot tools at gmail dot com 2010-02-28 17:02 ---
It is caused by revision 156701:
http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00283.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #22 from mmitchel at gcc dot gnu dot org 2010-02-28 17:08
---
Subject: Bug 42748
Author: mmitchel
Date: Sun Feb 28 17:07:54 2010
New Revision: 157124
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157124
Log:
2010-02-27 Mark Mitchell m...@codesourcery.com
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-28 17:16 ---
FIXED on the trunk (for zero initialization). Thanks for the report! Here, the
example of comment 0 now compiles in 0.037s.
Regarding non-zero initialization (cf. comment 1), see follow-up PR 43210.
--
burnus at
--- Comment #14 from burnus at gcc dot gnu dot org 2010-02-28 17:30 ---
Created an attachment (id=19988)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19988action=view)
Another update - handle -fno-automatic fixes ICE in comment #11
Fixes ICE in comment #11, handles STATIC
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-28 17:42 ---
Patch for using _POSIX - untested.
Index: libgfortran/io/io.h
===
--- libgfortran/io/io.h (Revision 157097)
+++ libgfortran/io/io.h (Arbeitskopie)
@@
--- Comment #12 from rwild at gcc dot gnu dot org 2010-02-28 18:14 ---
Thanks. You are right that the chance for a non-parallelism-related failure
was low, but comparison failures can be due to the phase of the moon literally.
Anyway, here's how I usually debug parallel build
--- Comment #15 from burnus at gcc dot gnu dot org 2010-02-28 19:48 ---
Created an attachment (id=19989)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19989action=view)
Really fix -fno-automatic -- attached the wrong patch which missed a == 0 in
trans-decl.
As pointed out by
--
Summary: [4.5 Regression] Worse code generated with -O2
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-02-28
19:57 ---
Created an attachment (id=19990)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19990action=view)
Poor code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43213
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-02-28
19:58 ---
Created an attachment (id=19991)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19991action=view)
C source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43213
--- Comment #2 from manu at gcc dot gnu dot org 2010-02-28 20:12 ---
Approved patch http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01246.html
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
I think there was not yet a PR about this. The following program compiles with
NAG f95 but fails in gfortran with:
call x(:)%foo
1
Error: Non-scalar base object at (1) currently not implemented
module m
type t
contains
procedure, pass :: foo = foo
end type t
contains
elemental
--- Comment #4 from amonakov at gcc dot gnu dot org 2010-02-28 22:01
---
Confirmed.
The first invocation of get_computation_aff fails with ustep == (long) j, cstep
== (unsigned long) j: constant_multiple_of (ustep, cstep, rat) returns false
(j is int, STRIP_NOPS ({u,c}step) preserves
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-28 22:29 ---
(In reply to comment #1)
It boils down to understand what makes data-ref polymorphic
Answer: A polymorphic entity is a data entity that is able to be of differing
types during program execution. (F2003, 5.1.1.2
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43209
--- Comment #13 from mikestump at comcast dot net 2010-03-01 00:23 ---
This is a dup of c++/42748, which has now been fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40459
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-03-01
01:11 ---
This also happens for i686-apple-darwin10
make[2]: Nothing to be done for `check'.
gcc -DHAVE_CONFIG_H -g -O2 -I..
-I../../../gcc-4.5-20100228/libiberty/testsuite/../../include -o test-demangle
#include stdint.h
uint64_t extract_double (double x)
{
union {
double dbl;
uint64_t u;
} t;
t.dbl = x;
return t.u;
}
Compile this function with x86_64-pc-linux-gnu-gcc -O2 -march=core2 -S a.c,
and we get the following assembly codes:
extract_double:
.LFB0:
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-03-01
04:49 ---
Created an attachment (id=19992)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19992action=view)
Makefile from darwin_objdir/libiberty with commented line that eliminates the
bug
--
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-03-01
04:52 ---
I find that for i686-apple-darwin10, if I comment the line...
# Flags to pass to a recursive make.
FLAGS_TO_PASS = \
AR=$(AR) \
AR_FLAGS=$(AR_FLAGS) \
# CC=$(CC) \
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-03-01 06:30
---
Created an attachment (id=19993)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19993action=view)
A suggested patch
This patch does the trick. I think it is sensible to not warn on leading
spaces, a
--- Comment #4 from ghazi at gcc dot gnu dot org 2010-03-01 07:15 ---
Is this a dup of 29404 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42308
--- Comment #6 from burnus at gcc dot gnu dot org 2010-03-01 07:31 ---
(In reply to comment #5)
Created an attachment (id=19993)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19993action=view) [edit]
A suggested patch
This patch does the trick. I think it is sensible to not
--- Comment #1 from domob at gcc dot gnu dot org 2010-03-01 07:48 ---
This is mentioned as still missing in PR 41177 which I kept open for that, but
it's probably really a good idea to have a new PR. I'll close 41177 instead,
referring here. Note that there might be some infos and
--- Comment #8 from domob at gcc dot gnu dot org 2010-03-01 07:49 ---
Closing, the missing part has its own PR 43214 now (which I think is a good
idea).
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
60 matches
Mail list logo
