On Thu, Apr 30, 2009 at 6:54 AM, Eus
reply.to.eus.at.member.fsf@gmail.com wrote:
Hi Ho!
Sorry, if I sort of hijack this thread.
On Wed, 2009-04-29 at 15:43 +, Joseph S. Myers wrote:
int i; is not the same as extern int i;.
Sorry for my ignorance but I have been reading and
Hello,
I experienced asm operand requires impossible reload error in our private
porting.
After digging into the reloading pass, I found something a bit fishy.
The error message is produced in reload_as_needed function (reload1.c)
...
/* If this was an ASM, make sure that all
On Thu, Apr 30, 2009 at 11:39, Janis Johnson janis...@us.ibm.com wrote:
Thanks to Janis, Andrew, and David.
I see inside the script all you say, but it seems to be throwing up on
some ill-formed screen output from some of the tests, e.g.,
gawk: cmd. line:50: { next; }
gawk: cmd. line:50:
Hello,
The GCC source tree is getting really big. We currently have in gcc/:
- 337 .c files
- 171 .h files
Personally, I think the source tree is quite a mess, the way it is
now. A long time ago (I can't find the threads involved) there was
some discussion about re-ordering the source tree a
I'm in favor of such a reorganization, but would suggest:
(1) tree-* to go to gcc/tree-opt
(2) Not distinguish between the various rtl passes (why is sched code
generation, for example?) and put all in gcc/rtl
(3) Not do this:
- basic intermediate language support stays in gcc/ or goes to
2009/5/1 Steven Bosscher stevenb@gmail.com:
Hello,
Now that GCC uses subversion, we can move files around without
destroying the file revision history, right? And we are in stage1, the
perfect time for Big Changes like re-ordering the source tree.
If you going to tackle this, I would
I am working on Cortex-A9 and M3 of ARM. I am using gcc 4.4.0, uClibc
0.9.30.1 and binutils 2.19.1 and building it for Cortex-m3. While
building for m3 if I specify arch as armv7-m alonmg with cpu
cortex-m3, the build fails.
Using the same set, if I build the toolchain for Cortex-A9
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
Nitin Garg
Sent: 01 May 2009 14:11
To: gcc@gcc.gnu.org; gcc-h...@gcc.gnu.org
Subject: Problem with gcc-4.4.0 with Cortex-m3 and cortex-a9 cpu
I am working on Cortex-A9 and M3 of ARM. I am
On Fri, 1 May 2009, Steven Bosscher wrote:
- c-* go to gcc/c (including c-common.*, 29 files)
I still suggest using a separate c-family/ directory for those files also
shared with C++. There are some cleanups that need doing of files that
include C headers that shouldn't, and of c-family
On Fri, 1 May 2009, Joseph S. Myers wrote:
On Fri, 1 May 2009, Steven Bosscher wrote:
- c-* go to gcc/c (including c-common.*, 29 files)
I still suggest using a separate c-family/ directory for those files also
shared with C++. There are some cleanups that need doing of files that
On Fri, May 1, 2009 at 3:54 PM, Joseph S. Myers jos...@codesourcery.com wrote:
On Fri, 1 May 2009, Joseph S. Myers wrote:
On Fri, 1 May 2009, Steven Bosscher wrote:
- c-* go to gcc/c (including c-common.*, 29 files)
I still suggest using a separate c-family/ directory for those files also
On Fri, 1 May 2009, Steven Bosscher wrote:
Eh, ouch.
I'll see if I can clean this up. I don't believe for 90% of these
files that they should include c-common.h / c-tree.h. Looks like
history and the usual carelessness when adding #include lines to new
files/passes.
Thanks! I agree
Bingfeng Mei b...@broadcom.com writes:
I experienced asm operand requires impossible reload error in our private
porting.
After digging into the reloading pass, I found something a bit fishy.
The error message is produced in reload_as_needed function (reload1.c)
...
/* If
-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com]
Sent: 01 May 2009 15:32
To: Bingfeng Mei
Cc: gcc@gcc.gnu.org; bernd.schm...@analog.com; weig...@de.ibm.com
Subject: Re: Reload problem: asm operand requires impossible reload
Bingfeng Mei b...@broadcom.com
Bingfeng Mei b...@broadcom.com writes:
Actually, they do contain references to pseudo-registers. Only in following
code (reload function in reload1.c, after the reload_as_needed function
that emits error message), pseudo registers are replaced with requivalent
memory operands.
Yes, but the
On Fri, May 1, 2009 at 4:13 PM, Joseph S. Myers jos...@codesourcery.com wrote:
On Fri, 1 May 2009, Steven Bosscher wrote:
Eh, ouch.
I'll see if I can clean this up. I don't believe for 90% of these
files that they should include c-common.h / c-tree.h. Looks like
history and the usual
On Fri, 1 May 2009, Steven Bosscher wrote:
Actually nothing uses it, except one case of %qE. And some passes
forgot to include splay-tree.h but got it via c-*.h.
There should be no problem with %qE in non-front-end files, since:
2009-04-23 Rafael Avila de Espindola espind...@google.com
On Fri, May 1, 2009 at 6:48 PM, Joseph S. Myers jos...@codesourcery.com wrote:
On Fri, 1 May 2009, Steven Bosscher wrote:
Actually nothing uses it, except one case of %qE. And some passes
forgot to include splay-tree.h but got it via c-*.h.
There should be no problem with %qE in
On Fri, 1 May 2009, Steven Bosscher wrote:
On Fri, May 1, 2009 at 6:48 PM, Joseph S. Myers jos...@codesourcery.com
wrote:
On Fri, 1 May 2009, Steven Bosscher wrote:
Actually nothing uses it, except one case of %qE. And some passes
forgot to include splay-tree.h but got it via c-*.h.
On Fri, May 1, 2009 at 7:01 PM, Joseph S. Myers jos...@codesourcery.com wrote:
On Fri, 1 May 2009, Steven Bosscher wrote:
On Fri, May 1, 2009 at 6:48 PM, Joseph S. Myers jos...@codesourcery.com
wrote:
On Fri, 1 May 2009, Steven Bosscher wrote:
Actually nothing uses it, except one case
On Fri, May 1, 2009 at 2:05 PM, Steven Bosscher stevenb@gmail.com wrote:
Hello,
The GCC source tree is getting really big. We currently have in gcc/:
- 337 .c files
- 171 .h files
Personally, I think the source tree is quite a mess, the way it is
now. A long time ago (I can't find
Richard Guenther wrote:
Branches will get confused. SVN does not really track file moves. So
I think this is not a stage1 but more a stage3 thing.
It also will make grepping even more painful than it is now (remember
that ada change to introduce a 3rd directory level here ...).
I would
On Fri, May 1, 2009 at 2:05 PM, Steven Bosscher stevenb@gmail.com wrote:
Hello,
The GCC source tree is getting really big. We currently have in gcc/:
- 337 .c files
- 171 .h files
Personally, I think the source tree is quite a mess, the way it is
now. A long time ago (I
Yes, I have done that and now am looking to limit those numbers. For
example, I don't copy back the ones that are not live-out registers.
It works well but I am have an issue when recompiling the whole
compiler.
I've simplified this to this, if in my reorg function, I do only this :
Ok, I added a df_analyze at the beginning of my target reorg function
and now it works. Is there anything I should add to cleanup afterwards
?
Sorry about this, I'm slowly learning different parts of the GCC
compiler as I go,
Thanks again for all your help,
Jc
On Fri, May 1, 2009 at 4:33 PM,
On Fri, May 1, 2009 at 3:54 PM, Joseph S. Myers jos...@codesourcery.com wrote:
attribs.c:#include c-common.h
cgraphunit.c:#include c-common.h
ipa-pure-const.c:#include c-common.h
ipa-reference.c:#include c-common.h
ipa-struct-reorg.c:#include c-tree.h
ipa-struct-reorg.c:#include c-common.h
Ok, I added a df_analyze at the beginning of my target reorg function
and now it works. Is there anything I should add to cleanup afterwards
?
As far as DF is concerned, no, probably nothing.
--
Eric Botcazou
On Fri, 1 May 2009, Steven Bosscher wrote:
And these are the problem inclusions of files specific to C and ObjC from
files also shared with C++:
c-common.c:#include c-tree.h
c-dump.c:#include c-tree.h
c-gimplify.c:#include c-tree.h
c-lex.c:#include c-tree.h
c-opts.c:#include
--- Comment #1 from carrot at google dot com 2009-05-01 06:12 ---
Created an attachment (id=17787)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17787action=view)
sample code showing the optimization opportunity
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39989
--- Comment #2 from carrot at google dot com 2009-05-01 06:21 ---
Actually gcc has already implemented this optimization, but it doesn't work for
this case.
Reload pass tries to determine the stack frame, so it needs to check the
push/pop lr optimization opportunity. One of the
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
--- 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=17788action=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
--- 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
$ 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 at
--- 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
--- 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%
--- 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
--- 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).
Using
--- 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.
--
--- 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
--- 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:
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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:
ssa_name 79f80070
type real_type 79f56e70 TFtype TF
size integer_cst 79edb760 constant 128
unit size integer_cst 79edb780 constant 16
--- 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
--- 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
--- 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
--- 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
--- 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
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
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
--- 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=17789action=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.
--
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
--- 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=17789action=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
--- 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
--- 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
--- 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:
--- 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 ---
bb 45:
# crkveuk_lsm.686_3635 = PHI crkveuk_lsm.686_517(44)
# cikve_lsm.685_3640 = PHI cikve_lsm.685_528(44)
# crkveuk_lsm.686_3564 = PHI crkveuk_lsm.686_517(44)
Interesting, I wonder if that causes
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:
--- 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;
--- 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:29
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
--- 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=17789action=view) [edit]
--- 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
The following code...
#include stdlib.h
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
--- 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
--- 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
---
shakeblink
Congratulations, winner!
You are the 40,000th visitor!
Click here to claim your prize!
/blink/shake
(or just mark as a dup of pr3 :P) Woo-hoo!
--
--- 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
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
1 - 100 of 105 matches
Mail list logo
