--- 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
c
--- 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 TYPE_VECTOR_OPAQUE(
--- 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 -fomit-f
--- 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 an
--- 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 progr
--- 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
exc
--- 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.
--
http://gcc.gnu.org/b
--- 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 us
--- 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
Status|UN
--- 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
Status|UN
--- 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
Status|UN
--- 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
Assi
--- 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 #4 from pinskia at gcc dot gnu dot org 2009-05-03 16:38 ---
Even if you don't see the ICE, the code is still invalid as mentioned.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pault at gcc dot gnu dot org 2009-05-03 17:14 ---
(In reply to comment #3)
> with gfortran -c -O0 --param ggc-min-heapsize=320 CP2K_2009-05-01.f90
> things compile file (and need some 6Gb of memory).
>
Joost,
Do you have any idea of what change to g2k might hav
The gcc manpage is not always created due to a dependency missing for gcc.pod
in gcc/Makefile.in. invoke.texi depends upon gcc-vers.texi being generated,
but no such dependency is listed. This was found by
6vvetjsrt26xsrzlh1z0zn4d2gr...@gmail.com in
https://bugs.gentoo.org/show_bug.cgi?id=256608
--- Comment #1 from halcy0n at gentoo dot org 2009-05-03 17:43 ---
Created an attachment (id=17793)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17793&action=view)
gcc-pod-missing-dependency
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40010
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-03 17:52 ---
Does it work if you increase the default stack limit? ulimit -s unlimited
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
--- Comment #6 from jv244 at cam dot ac dot uk 2009-05-03 18:59 ---
(In reply to comment #4)
> Do you have any idea of what change to g2k might have caused this? Even with
> no optimization, it brings my Core 2 Quad to a complete halt. The fact that it
> is garbage handling is worrying
--- Comment #7 from jv244 at cam dot ac dot uk 2009-05-03 19:14 ---
(In reply to comment #5)
> Does it work if you increase the default stack limit? ulimit -s unlimited
trunk does indeed pass with ulimit -s and 4.4.0 as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=400
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2009-05-03 19:29
---
There is a warning in list_read.c left over from the big IO patch that was
merged in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22423
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-03 19:37 ---
This is not a new problem - our recursive GC manages to do this in some cases.
What helps sometimes is to adjust the way structures are linked to avoid too
deep recursion. Maybe the GFortran FE trees are not optimi
--- 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=gcc&view=rev&rev=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=17475&action=view) [edit]
> Proposed fix -- will commit after trunk reopens
Ping, trunk is open now, no? I'v
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-03 19:56 ---
Subject: Bug 23329
Author: rguenth
Date: Sun May 3 19:55:55 2009
New Revision: 147082
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147082
Log:
2009-05-03 Richard Guenther
PR middle-end/23329
--- 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=gcc&view=rev&rev=147083
Log:
2009-05-03 Richard Guenther
PR c/39983
*
--- 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 reproduc
on reports 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 F
--- 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=17794&action=view)
Test case demonstrating the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4001
I get an ICE when compiling this code using GCC 4.4 from svn:
template class TestClass {
public:
struct Subclass { struct { int c() {return 0;} } b; };
void test();
};
template void TestClass::test() {
Subclass a;
int d[a.b.c()];
}
int main() {
TestClass t
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 Fortra
--- 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
Prod
--- 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 ((*x).generic.type.next_vari
--- 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|
--- Comment #13 from julian1844 at yahoo dot com 2009-05-04 06:23 ---
(In reply to comment #12)
Should I conclude that the MinGW site is now www.equation.com?
> (In reply to comment #11)
> > (In reply to comment #9, comment #10)
> > I did not build MinGW 4.3.0. I got it from the officia
--- Comment #2 from dominiq at lps dot ens dot fr 2009-05-04 06:30 ---
Confirmed on i686-apple-darwin9, array_memcpy_4.f90.003t.original is
MAIN__ ()
{
struct t d[5];
struct t s[5];
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
_gfortran_set_options (8, (vo
--- Comment #3 from dominiq at lps dot ens dot fr 2009-05-04 06:32 ---
At revision 147065 I get:
MAIN__ ()
{
struct t d[5];
struct t s[5];
static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};
_gfortran_set_options (8, (void *) &options.0);
d = VIEW_CONVERT_EXPR(
--- Comment #20 from kreckel at ginac dot de 2009-05-04 06:47 ---
So, Joseph explained that the code should execute as expected, at least with
-frounding-math as a workaround. However, with GCC 4.4 it is still not possible
to write code that takes advantage of those advanced features of
66 matches
Mail list logo
