GCC 4.4.1 (prerelease) 20090425
The output can be seen here:
http://www.spinics.net/lists/fedora-testing/msg78463.html
--
Summary: Failed to compile mplayer
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority
--- Comment #1 from yast4ik at yahoo dot com 2009-05-01 08:05 ---
Created an attachment (id=17788)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17788&action=view)
mangle.h config.h imdct.i imdct.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39990
--- Comment #2 from yast4ik at yahoo dot com 2009-05-01 08:07 ---
Command line is:
gcc -v -save-temps -Wundef -Wdisabled-optimization -Wno-pointer-sign
-Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith
-Wredundant-decls -O4 -march=core2 -msse4.1 -pipe -ffast-mat
--- Comment #5 from ramana at gcc dot gnu dot org 2009-05-01 08:39 ---
*** Bug 39989 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-01 08:39 ---
Marking as duplicate of PR38570
*** This bug has been marked as a duplicate of 38570 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from steven at gcc dot gnu dot org 2009-05-01 08:44 ---
I still see no answer to my question from comment #1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34849
--- Comment #10 from gbarnt at student dot dtu dot dk 2009-05-01 09:01
---
In reply to #9:
I have tried to build gcc with and without my own patch on our solaris
machines. While both of them fails they fail at the same place (namely
configuration of [arch]/libgcc trying to figure out t
$> cat locus.f90
MODULE m
PUBLIC :: s
CONTAINS
SUBROUTINE s()
END SUBROUTINE
SUBROUTINE s()
END SUBROUTINE
END MODULE
$> gfortran-svn locus.f90
locus.f90:6.14:
SUBROUTINE s()
1
locus.f90:2.13:
PUBLIC :: s
2
Error: Procedure 's' at (1) is already defined a
--- Comment #13 from dominiq at lps dot ens dot fr 2009-05-01 09:39 ---
On i686-apple-darwin9:
[ibook-dhum] bug/java_test% /opt/gcc/gcc4.5w/bin/gcj -v
Using built-in specs.
Reading specs from
/Volumes/MacBook/opt/gcc/gcc4.5w/bin/../lib/gcc/i686-apple-darwin9/4.5.0/../../../libgcj.spec
r
--- Comment #11 from schwab at linux-m68k dot org 2009-05-01 09:51 ---
GNU make is required for building gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
--- Comment #14 from dominiq at lps dot ens dot fr 2009-05-01 11:13 ---
Note 1: java is broken on ppc-darwin with -m64.
Note 2: the error does not appear at -O1 and -m32 (default).
Note 3: removing the -quiet and some other options, I get:
[karma] bug/java_test%
/opt/gcc/gcc4.5w/libex
--- Comment #6 from MR dot Swami dot Reddy at nsc dot com 2009-05-01 11:42
---
This problem is reproduced with latest gcc-4.4.0 release tools (ie crx-elf-gcc
version 4.4.0).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39685
--- Comment #17 from pinskia at gcc dot gnu dot org 2009-05-01 13:15
---
*** Bug 39990 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-01 13:15 ---
*** This bug has been marked as a duplicate of 39543 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
a nested copy constructor with unclosed parentheses, if
nested sufficiently deeply, exhausts memory and kills the
compiler after several minutes of churning.
class C;
C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(C(
// (40 nested unclosed constructor parentheses)
i
Hi,
The following program compiles fine with all compilers I know of
(a.o., Apple's gcc4.0 and gcc4.2, GNU gcc4.3 ...), and fails with gcc4.4
(it comes from a saclib routine, after having used --save-temps
and some grepping to remove all macros and typedefs) :
_
#inc
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2009-05-01
14:06 ---
Java has always been broken at -m64 on ppc-darwin since no one has ever ported
ffi to work on ppc64 for darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
--- Comment #1 from cbm at whatexit dot org 2009-05-01 14:08 ---
... rather,
> int f(int);
> int
> x=f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(f(0
fails immediately.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39992
--- Comment #5 from kargl at gcc dot gnu dot org 2009-05-01 14:08 ---
(In reply to comment #4)
> (In reply to comment #3)
>
> I couldn't find any other gmp or mpfr in the system.
> Also tried using the system's ld and as (both version 2.11.2) but the same
> error pops up (see below).
>
--- Comment #16 from dominiq at lps dot ens dot fr 2009-05-01 14:08 ---
> Java has always been broken at -m64 on ppc-darwin since no one has ever ported
> ffi to work on ppc64 for darwin.
This is precisely why I have tried the test without -m64.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #11 from manu at gcc dot gnu dot org 2009-05-01 14:37 ---
FIXED by Janis.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITI
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-01 14:49 ---
I don't see this with a bootstrap that I was doing with r147003.
/home/ramana/build-combined-arm-gcc-20090430/./gcc/xgcc -v
Using built-in specs.
Target: armv5tel-unknown-linux-gnueabi
Configured with: ../trunk/co
--- Comment #17 from dominiq at lps dot ens dot fr 2009-05-01 14:50 ---
At revision 147032 on i686-apple-darwin9 the bootstrap still fails. Using the
built jc1 I get:
[ibook-dhum] bug/java_test% /opt/gcc/i686-darwin/gcc/jc1
/opt/gcc/_gcc_clean/libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\
--- Comment #5 from sje at cup dot hp dot com 2009-05-01 14:52 ---
XFAILed on IA64 and SPARC because they do not support the required vector
instructions used by these tests.
--
sje at cup dot hp dot com changed:
What|Removed |Added
---
--- Comment #6 from gustcr at yahoo dot com dot ar 2009-05-01 14:57 ---
(In reply to comment #5)
Well... I already read the installation instructions and know them almost by
hard... and a bit more. At the web page it says:
"First, we highly recommend that GCC be built into a separate d
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2009-05-01 15:04
---
What's the content of your generated file kinds.h? (It's in the target
libgfortran directory)? I suspect that the generation of kinds.h fails but the
Makefile continues, and the content of kinds.h makes it error o
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2009-05-01 15:10
---
Daniel, shouldn't this PR be closed?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from dfranke at gcc dot gnu dot org 2009-05-01 15:21
---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from gustcr at yahoo dot com dot ar 2009-05-01 15:25 ---
I think that it fails in building libgfortran.h
This is the last part of the output:
.
make[4]: Leaving directory
`/home2/gdb/local/gcc-4.4.0-obj/i686-pc-linux-gnu/libssp'
make[3]: Leaving directory
`/home2/gdb/
--- Comment #3 from rearnsha at gcc dot gnu dot org 2009-05-01 15:30
---
This smells like a memory corruption problem in the compiler...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2009-05-01 15:44
---
(In reply to comment #8)
> I think that it fails in building libgfortran.h
libgfortran.h is not "built", it's a source file.
There was one question only in my comment: What's the content of your generated
file k
--- Comment #3 from sje at cup dot hp dot com 2009-05-01 15:54 ---
Looking at exp when we enter expand_expr_addr_expr_1 I see:
unit size
align 64 symtab 0 alias set -1 canonical type 79eee690 precision 128
pointer_to_this >
visited var def_stmt D.1233_5 =
--- Comment #10 from gustcr at yahoo dot com dot ar 2009-05-01 15:59
---
dirac:~/local/gcc-4.4.0-obj$ cat ./i686-pc-linux-gnu/libgfortran/kinds.h
typedef int8_t GFC_INTEGER_1;
typedef uint8_t GFC_UINTEGER_1;
typedef GFC_INTEGER_1 GFC_LOGICAL_1;
#define HAVE_GFC_LOGICAL_1
#define HAVE_G
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2009-05-01 16:12
---
Oh, I think I see. Do you have a really old glibc? What happens if you use a
newer one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39971
As mentioned in this post:
http://gcc.gnu.org/ml/libstdc++/2009-05/msg0.html
gcc accepts the ill-formed code below. According to [except.spec], p2:
If any declaration of a function has an exception-specification,
all declarations, including the definition and an explicit
specialization,
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywo
--- Comment #12 from gustcr at yahoo dot com dot ar 2009-05-01 17:14
---
Yes, glibc is old:
dirac:~/local/gcc-4.4.0-obj$ /lib/libc.so.6
GNU C Library stable release version 2.1.3, by Roland McGrath et al.
Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation,
--- Comment #4 from matz at gcc dot gnu dot org 2009-05-01 17:22 ---
That shouldn't happen yes. We are trying to expand
__fixunstfdi (D.1248_5)
As far as the gimple side is concerned this is a normal pass-by-value call
hence the SSA name therein is perfectly fine. But it seems the se
--- Comment #11 from julian1844 at yahoo dot com 2009-05-01 17:26 ---
(In reply to comment #9, comment #10)
I did not build MinGW 4.3.0. I got it from the official MinGW site
(gcc-4.3.0-20080502-mingw32-alpha). I have also found that on www.equation.com
there are even newer versions (bin
There are currently no checks for LHS = RHS where RHS is an array constructor,
if -fbounds-check / -fcheck=bounds is used. (Neither is it detected by NAG f95,
ifort, g95.)
Example:
integer :: a(2), b(5), i
b = 0
i = 2
a = [1, 2, b(1:i)] ! RHS too many items
i = 1
a = [ b(1:i)] ! RHS too few items
The following error occurs on more than one system with more than one version
of the compiler!
I am running Ubuntu 8.04.
The output of uname -a is:
Linux ozhp 2.6.24-23-generic #1 SMP Wed Apr 1 21:47:28 UTC 2009 i686 GNU/Linux
Command line: and its output:
\gfortran -v -fopenmp simple.f90 -o junk
--- Comment #1 from mmsussman at gmail dot com 2009-05-01 18:26 ---
Created an attachment (id=17789)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17789&action=view)
copy of original source code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39995
--- Comment #5 from sje at cup dot hp dot com 2009-05-01 18:30 ---
The proposed patch fixed my bootstrap failure. I haven't run the testsuite yet
to look for regressions but the bootstrap is working.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39977
--- Comment #1 from janis at gcc dot gnu dot org 2009-05-01 18:57 ---
The problem is that in dfp.c, functions encode_decimal* and decode_decimal* use
memcpy from a 32-bit int to a long for 32 bits. This works fine with -32 where
long is 32 bits, but not for -m64 where long is 32 bits.
--- Comment #2 from janis at gcc dot gnu dot org 2009-05-01 19:03 ---
D'oh, I of course meant that long is 32-bits when GCC is build with default
-m32 and that long is 64-bits when GCC is built with default -m64; the host
size of long, not the target size.
--
http://gcc.gnu.org/bugz
Found at c.l.f where Giorgio Pastore reported it.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/a48b6b038baabd90
gfortran -std=f95 does not detect the following:
interface
function square (x) result (s)
real,intent (in) ::x
real ::s
end function squar
--- Comment #2 from kargl at gcc dot gnu dot org 2009-05-01 19:29 ---
(In reply to comment #1)
> Created an attachment (id=17789)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17789&action=view) [edit]
> copy of original source code.
>
Works for me with
REMOVE:kargl[208] gfc43 -
--- Comment #12 from dannysmith at users dot sourceforge dot net
2009-05-01 19:48 ---
(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 official MinGW site
> (gcc-4.3.0-20080502-mingw32-alpha). I have also found that on ww
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-05-01 19:54
---
Hm, with a cross configured like
configure --disable-nls --enable-languages=java --target=i686-apple-darwin9
and make all-gcc I just get
gcc$ ./jc1 -quiet
~/src/trunk/libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\$
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-01 19:56 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #6 from sje at cup dot hp dot com 2009-05-01 20:01 ---
I finished testing and it looks OK. The failures that I see also appear on
other platforms (hppa64 and ia64) so I think the patch is good.
FAIL: libgomp.c++/task-4.C -O (internal compiler error)
FAIL: libgomp.c++/task
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-01 20:01 ---
Which pass? p *pass in frame 20 should tell you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-01 20:03 ---
*** Bug 39980 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-01 20:03 ---
*** This bug has been marked as a duplicate of 39754 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-01 20:07 ---
> :
> # crkveuk_lsm.686_3635 = PHI
> # cikve_lsm.685_3640 = PHI
> # crkveuk_lsm.686_3564 = PHI
>
> Interesting, I wonder if that causes expand SSA to go crazy or do we go into
> closed loop form on purpose
This is a tracking bug. It partially applies directly and partially for the
almost ready proc-pointer components patch.
I first ask ask comp.lang.fortran, but Richard Maine's reply was that he sees
the problem but feels he cannot answer it:
http://groups.google.com/group/comp.lang.fortran/browse_
--- Comment #5 from danglin at gcc dot gnu dot org 2009-05-01 20:32 ---
I'm not in my office where the box is, however, I believe the ICE occurs in
stage2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-01 20:34 ---
We can't perform loop store sinking as in and res alias. And our other
store sinking pass is just too stupid for this case as we have a missed
CSE opportunity for the address stored to:
D.1243_8 = *D.1242_7;
if
--- Comment #3 from msussman at verizon dot net 2009-05-01 21:39 ---
Subject: Re: Open MP compile fails with "internal
compiler error"
On Fri, 2009-05-01 at 19:29 +, kargl at gcc dot gnu dot org wrote:
>
> --- Comment #2 from kargl at gcc dot gnu dot org 2009-05-01 19
According to the following passage of the Fortran 2003 standard, statement
functions and internal functions are forbidden in procedure pointer
assignments:
C727 (R742) A procedure-name shall be the name of an external, module, or dummy
procedure, a specific intrinsic function listed in 13.6 and no
--- Comment #4 from kargl at gcc dot gnu dot org 2009-05-01 21:50 ---
(In reply to comment #3)>
> On Fri, 2009-05-01 at 19:29 +, kargl at gcc dot gnu dot org wrote:
> >
> > > Created an attachment (id=17789)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17789&action=view) [ed
--- Comment #8 from steven at gcc dot gnu dot org 2009-05-01 21:51 ---
Crossjumping does nothing, because there is nothing to crossjump anymore at
that point. The two stores have been replaced with one and a conditional set:
- in .ce1 (ifcvt1) we haven't converted to a conditional set
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-01 21:13 ---
FE problem. In
extern const int b[1];
static const int * const c[] = { b };
b decays to type int * instead of const int *.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from steven at gcc dot gnu dot org 2009-05-01 22:27 ---
FWIW, early crossjumping (after ce1) doesn't work either.
The code before trying to crossjump looks like this:
44 pc={(cc:CC=0x0)?L50:pc}
REG_DEAD: cc:CC
REG_BR_PROB: 0x1388
45 NOTE_INSN_BASIC_BLOC
The following code...
#include
extern int *MMAPMON (int m, int *A);
extern void MMAPREM (int m, int *A, int *B);
int *MMAPGCD(p,A,B)
int p,*A,*B;
{
int *A1,*A2,*t,*C,m,n;
if (((A[-1]) == 0 && (A[0]) == 0)) {
C = MMAPMON(p,B);
goto Return; }
if (((B[-1]) == 0 && (B[
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-01 22:49 ---
So GCC hangs and not the compiled code?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
+++ This bug was initially created as a clone of Bug #5 +++
[C89 regression] C++ has too much stuff. Make it smaller.
Release:
C++98
--
Summary: [1.36.3/1.37/.../3.2/3.3/3.4 regression] C++ sucks,
can't you make it better?
Product: gcc
Vers
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-01 22:51 ---
*** This bug has been marked as a duplicate of 5 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-05-01 22:51
---
*** Bug 4 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from fang at csl dot cornell dot edu 2009-05-01 22:57
---
Congratulations, winner!
You are the 40,000th visitor!
Click here to claim your prize!
(or just mark as a dup of pr3 :P) Woo-hoo!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-05-01
23:00 ---
On Linux and Darwin, it seems to be constantly allocating memory and never
finishes the compilation (at least over 10+ minutes). The example code compiles
instantly at -O1. I've not discovered any -O2 switc
The following test case, simplified from newlib's libgloss/spu/sbrk.c, breaks a
combined SPU build. This test case works if sp_r1 is declared globally.
It fails at the new assert in cfgexpand.c:expand_one_var() which tests
DECL_HARD_REGISTER.
void *
sbrk (unsigned int increment)
{
volatile r
--- Comment #19 from dominiq at lps dot ens dot fr 2009-05-01 23:09 ---
The ICE is also produced by prev-gcc/jc1
[ibook-dhum] bug/java_test% /opt/gcc/i686-darwin/prev-gcc/jc1
/opt/gcc/_gcc_clean/libjava/classpath/lib/gnu/CORBA/Poa/gnuPOA\$RefTemplate.class
-fhash-synchronization -fuse-d
I have built a 4.4.0 version of GCC and built newlib with that version and
installed it in say /MYPREFIX and then go and try to build 4.5.0. I then build
GCC with the same /MYPREFIX but not a combined build, the testsuite is not able
to find the libc headers.
I don't know if this a regression bec
--- Comment #1 from matz at gcc dot gnu dot org 2009-05-02 02:34 ---
The assert triggers because of a real pre-existing bug. local variables
with DECL_HARD_REGISTER set must not be put into SSA form. is_gimple_reg
has to return false for them. It doesn't anymore since some changes by
See below. The output at -O0 looks good. At -O3 the wrong result is printed
and valgrind reports a read of uninitialized memory.
reg...@john-home:~/volatile/tmp160$ current-gcc -O0 -Wall small.c -o small
reg...@john-home:~/volatile/tmp160$ valgrind ./small
==26152== Memcheck, a memory error dete
--- Comment #1 from regehr at cs dot utah dot edu 2009-05-02 05:47 ---
Created an attachment (id=17790)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17790&action=view)
preprocessed failure-inducing input
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40003
77 matches
Mail list logo
