--- Comment #7 from dominiq at lps dot ens dot fr 2009-05-03 10:24 ---
The test gcc.c-torture/compile/pr39943.c fails on powerpc-apple-darwin9.6, see
http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg00169.html:
FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (internal
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-03 11:06 ---
Looking at rs6000.c likely many more builtins are affected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-03 11:12 ---
Huh. It uses build_opaque_vector_type, but
/* Nonzero in an IDENTIFIER_NODE if the name is a local alias, whose
uses are to be substituted for uses of the TREE_CHAINed identifier. */
#define
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 11:16 ---
IMHO the frontend should, for TYPE_VECTOR_OPAQUE conversions emit
VIEW_CONVERT_EXPRs to honour GIMPLE/GENERIC type system requirements.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
It should have an unsigned vector result
def_builtin (MASK_ALTIVEC, __builtin_vec_ctu, opaque_ftype_opaque_int,
ALTIVEC_BUILTIN_VEC_CTU);
this casues
FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (internal
compiler error)
FAIL: gcc.c-torture/compile/pr39943.c -O3
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-03 11:06 ---
Please do not clutter existing (closed) bugreports like this. - PR40009.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39943
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-03 11:18 ---
For the case in question, vctuxs doesn't look like an instruction that
has an opaque return type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #5 from bonzini at gnu dot org 2009-05-03 12:11 ---
In many cases, opaque types are used in the prototypes just to avoid warnings.
You're right that the front-end should insert VIEW_CONVERT_EXPRs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40009
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-05-03 12:37
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00076.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2009-05-03 12:40
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00077.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-05-03 12:52
---
Doc patch here: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00078.html
I am against allowing $ as first letter in identifiers, as there now are much
better ways to do that (and it's not such a common practice
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-03 13:29 ---
Ok, so the builtins should have a proper, but opaque vector type (like for
VEC_CTU it should be an unsigned vector type, not a signed one).
Thus, the TYPE_VECTOR_OPAQUE description should read like
/* Nonzero in a
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2009-05-03 13:32
---
(In reply to comment #11)
The original testcase in #0 appears to be fixed if compiled with -fwhole-file.
Andrew's comment #4 appears to be still an issue?!
Here's a full testcase showing the remaining issue:
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-03 13:53
---
I guess -fwhole-file should catch this one, but it does not. The testcase I
used is:
integer function two()
two = 2
end function two
program xx
! real, external :: two
print *, two(), kind(two())
end
--- Comment #7 from bonzini at gnu dot org 2009-05-03 14:00 ---
Ok, so the builtins should have a proper, but opaque vector type (like for
VEC_CTU it should be an unsigned vector type, not a signed one).
No, there's no reason to have 1 opaque vector type for a single mode (or even
--- Comment #8 from bonzini at gnu dot org 2009-05-03 14:25 ---
What's remaining was already in the database.
*** This bug has been marked as a duplicate of 30210 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #9 from bonzini at gnu dot org 2009-05-03 14:25 ---
*** Bug 40009 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #10 from bonzini at gnu dot org 2009-05-03 14:26 ---
The wrong types in __builtin_altivec_ctu cause this:
FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (internal
compiler error)
FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (test for
--- Comment #9 from bonzini at gnu dot org 2009-05-03 14:34 ---
To be more specific, the builtin call is created by the vectorizer, and the
vectorizer is quite careless in matching types. The front-end *does* insert
VIEW_CONVERT_EXPRs and so does rs6000-c.c.
--
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-05-03 15:54
---
And as there is _builtin_altivec_cts in addition to _builtin_altivec_ctu these
builtins should better have correct types from the start. In fact they
look more constrained than opaque anyway - so why are they
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-05-03 15:56 ---
*** This bug has been marked as a duplicate of 30210 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-05-03 15:56
---
*** Bug 22372 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-05-03 15:57
---
And now causing regressions with type checking enabled.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 15:59 ---
Seems to be fixed at least in 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-03 16:01 ---
Seems to work with 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 16:04 ---
With --combine? It indeed doesn't complain. But I also don't see type
mismatches with type checking.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-03 16:05 ---
Fixed at least with 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 16:06 ---
It is supposedly fixed as we can bootstrap libjava with type checking enabled.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-03 16:07 ---
Works for me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-03 16:07 ---
Works for me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-03 16:08 ---
Works for me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-03 16:13 ---
Mine. I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2009-05-03 16:28
---
Many new warnings:
../../../trunk/libgfortran/runtime/string.c: In function compare0:
../../../trunk/libgfortran/runtime/string.c:39: warning: comparison between
signed and unsigned integer expressions
Fixed
--- Comment #1 from mikpe at it dot uu dot se 2009-05-03 19:39 ---
(In reply to comment #0)
Create a default configuration that honours big endian ARM by default. PR31938
refers to this.
Looks like a dupe of PR16350. And most of the de-facto standard patch people
have been applying
--- Comment #15 from uros at gcc dot gnu dot org 2009-05-03 19:40 ---
Subject: Bug 39914
Author: uros
Date: Sun May 3 19:40:35 2009
New Revision: 147081
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147081
Log:
Backport from mainline:
2009-04-28 Uros Bizjak
--- Comment #16 from ubizjak at gmail dot com 2009-05-03 19:41 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
Summary of the problems with -fwhole-file I have found so far.
From http://gcc.gnu.org/ml/fortran/2009-03/msg00310.html:
(1) From a first look the several Segmentation fault are coming from
recursive functions,
--- Comment #7 from mikpe at it dot uu dot se 2009-05-03 19:53 ---
(In reply to comment #6)
Created an attachment (id=17475)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17475action=view) [edit]
Proposed fix -- will commit after trunk reopens
Ping, trunk is open now, no? I've
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-03 19:57 ---
Subject: Bug 39983
Author: rguenth
Date: Sun May 3 19:57:32 2009
New Revision: 147083
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147083
Log:
2009-05-03 Richard Guenther rguent...@suse.de
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-03 19:57 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-03 19:58 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from mikpe at it dot uu dot se 2009-05-03 20:05 ---
(In reply to comment #3)
Comment #2 indicates that there isn't a problem with a 4.x series compiler .
I'd like some feedback if this problem exists today with a more recent version
of the compiler.
I can't reproduce
that I am using revision 147075.
$ gcc --version --verbose
Using built-in specs.
gcc (GCC) 4.5.0 20090503 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se
2009-05-03 22:05 ---
Created an attachment (id=17794)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17794action=view)
Test case demonstrating the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
I get an ICE when compiling this code using GCC 4.4 from svn:
template class I class TestClass {
public:
struct Subclass { struct { int c() {return 0;} } b; };
void test();
};
template class I void TestClassI::test() {
Subclass a;
int d[a.b.c()];
}
int main() {
Hi
I tried to build GCC 4.4.0 on my Solaris 8 system.
Output from uname -a:
SunOS catnip.eecg 5.8 Generic_117350-61 sun4u sparc SUNW,Sun-Blade-1500
I used GCC 3.4.6 for the build.
The build compiled fine for about 4 hours then I received the following
error:
configure: error: GNU Fortran
--- Comment #6 from carrot at google dot com 2009-05-04 02:21 ---
We can compute the maximum possible function length first. If the length is not
large enough far jump is not necessary, and we can do this optimization safely.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-04 03:30 ---
It is reproducible with test data, -i test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
Revision 147083:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00057.html
triggered:
FAIL: gfortran.dg/array_memcpy_4.f90 -O scan-tree-dump-times original d =
1
--
Summary: [4.5.0 Regression] Revision 147083 failed
gfortran.dg/array_memcpy_4.f90
--- Comment #9 from jv244 at cam dot ac dot uk 2009-05-04 04:39 ---
(In reply to comment #8)
Thus, the question is what are we recursing on here? type.next_variant
if my sources are matching yours (look at gt-fortran-f95-lang.h:337).
gt_ggc_m_9tree_node
--- Comment #1 from hp at gcc dot gnu dot org 2009-05-04 05:54 ---
Seen for cris-elf too...
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
CC|
52 matches
Mail list logo
