Hi,
I am converting my StarCore port of the gcc version 3.2 to the current version
4.1.1.
The following program ( part of the gcc's testsuite )
void bar(int *pc) {
static const void *l[] = {lab0, end};
foo(0);
goto *l[*pc];
lab0:
foo(0);
pc++;
goto *l[*pc];
end:
return;
}
Hello,
[EMAIL PROTECTED] /cygdrive/x
$ cat tmp.c
typedef unsigned size_t;
char *strncpy (char *pDest, const char *pSrc, size_t n)
{
return pDest;
}
[EMAIL PROTECTED] /cygdrive/x
$ powerpc-eabi-gcc -v
Using built-in specs.
Target: powerpc-eabi
Configured with: ../gcc-4.1.1/configure
Sorry please ignore, not enough coffee...
Etienne.
___
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Profitez des connaissances, des opinions et des
In general, I am agree with this. I am just opposing to the strong
words not allowed. I think it should be decided in each concrete case.
I agree that not allowed was a poor choice of words in a project
such as GCC and, although we, as a project, do tend to normally make
decisions one at a
Vladimir N. Makarov wrote:
Vlad,
I think that different people can have different perspectives.
You have been working on improving the register allocation for several
years, but very little has come of it because the reload
infrastructure does not suit itself to being integrated with modern
Regs_ever_live is the poster child of this. In theory regs_ever_live is
easy, it is just the set of hard registers that are used. In practice
this is a disaster to keep track of because it was only updated
occasionally and its values are randomly changed by the backends in
totally
David Livshin [EMAIL PROTECTED] writes:
x.c: In function bar:
x.c:13: error: unrecognizable insn:
(jump_insn 26 25 27 2 (set (pc)
(reg:SI 52)) -1 (nil)
(nil))
x.c:13: internal compiler error: in extract_insn, at recog.c:2084
The .md file defines ( mandatory )
Etienne Lorrain [EMAIL PROTECTED] writes:
Is there a magic flag? I want to test the source for null pointer...
This question would be appropriate on the mailing list
[EMAIL PROTECTED], not on [EMAIL PROTECTED] Please take any
followups gcc-help. Thanks.
I don't actually understand the
Richard Kenner wrote:
Regs_ever_live is the poster child of this. In theory regs_ever_live is
easy, it is just the set of hard registers that are used. In practice
this is a disaster to keep track of because it was only updated
occasionally and its values are randomly changed by the backends
--- Ian Lance Taylor [EMAIL PROTECTED] wrote:
I don't actually understand the question. gcc is compiling the
function as you wrote it. What do you want it to do differently?
This has been resolved today by:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30785
I was adding code to test a
Wow, I got so many emails. I'll try to answer them in one email in
order not to repeat.
Mark Mitchell wrote:
I was not trying to suggest that DF is necessarily as sweeping a change
as TREE-SSA. Certainly, it's not a completely change to the
representation.
It is not sweeping change as
Let us look at major RTL optimizations: combiner, scheduler, RA. Do
we need a global analysis for building def-use use-def chains? We
don't need it for combiner (only in bb scope),
Combine would work *far better* if it had some uniform data structure. For
one thing, that means it could
Do you realize how confrontational your emails sound? Have you
considered asking about the technical reasoning and justification instead
of making unfounded assertions? Do you want everyone to refute your
incorrect facts point by point?
David
On 2/13/07, Vladimir Makarov [EMAIL PROTECTED] wrote:
Wow, I got so many emails. I'll try to answer them in one email in
Let us look at major RTL optimizations: combiner, scheduler, RA.
...PRE, CPROP,SEE, RTL loop optimizers, if-conversion, ... It is easy
to make your arguments look valid
David Edelsohn wrote:
Do you realize how confrontational your emails sound? Have you
considered asking about the technical reasoning and justification instead
of making unfounded assertions? Do you want everyone to refute your
incorrect facts point by point?
David, I am sorry if
Ian Lance Taylor wrote:
David Livshin [EMAIL PROTECTED] writes:
x.c: In function bar:
x.c:13: error: unrecognizable insn:
(jump_insn 26 25 27 2 (set (pc)
(reg:SI 52)) -1 (nil)
(nil))
x.c:13: internal compiler error: in extract_insn, at recog.c:2084
The .md file defines (
On Tue, 2007-02-13 at 12:14 -0500, Vladimir Makarov wrote:
David Edelsohn wrote:
Do you realize how confrontational your emails sound? Have you
considered asking about the technical reasoning and justification instead
of making unfounded assertions? Do you want everyone to refute your
David Livshin [EMAIL PROTECTED] writes:
x.c: In function bar:
x.c:13: error: unrecognizable insn:
(jump_insn 26 25 27 2 (set (pc)
(reg:SI 52)) -1 (nil)
(nil))
x.c:13: internal compiler error: in extract_insn, at recog.c:2084
The .md file defines ( mandatory )
what happens with the data previously loaded by a previous pch include file?
I can't figure out why every GTY()-ed global data (extern or static) should
be overwritten at each PCH inclusion, but then maybe I am wrong.
Couple of big limiations of GCC PCH :
- Only one PCH can be loaded during
Jeffrey Law writes:
Jeff I think everyone would be best served if they realized none of this is
Jeff personal -- it's about technical decisions in an effort to improve GCC.
GCC development is far from perfect. The recent model generally
seems to be effective, although there is plenty
Steven Bosscher wrote:
On 2/13/07, Vladimir Makarov [EMAIL PROTECTED] wrote:
Wow, I got so many emails. I'll try to answer them in one email in
Let us look at major RTL optimizations: combiner, scheduler, RA.
...PRE, CPROP,SEE, RTL loop optimizers, if-conversion, ... It is easy
to make
Vladimir Makarov writes:
Vlad I am just trying to convince that the proposed df infrastructure is not
Vlad ready and might create serious problems for this release and future
Vlad development because it is slow. Danny is saying that the beauty of the
Vlad infrastracture is just in improving
I even have own tool for
this NONA http://cocom.sf.net . Although it might be a good research to
make it work on insns from diffrent BBs.
Of course instruction selection is usually done intra-BB. However, some
analyses that combine performs, such as nonzero_bits and
num_sign_bit_copies,
On 2/13/07, Vladimir Makarov [EMAIL PROTECTED] wrote:
I am just trying to convince that the proposed df infrastructure is not
ready and might create serious problems for this release and future
development because it is slow. Danny is saying that the beauty of the
infrastracture is just in
David Edelsohn wrote:
Vladimir Makarov writes:
Vlad I am just trying to convince that the proposed df infrastructure is not
Vlad ready and might create serious problems for this release and future
Vlad development because it is slow. Danny is saying that the beauty of the
On 2/13/07, Vladimir Makarov [EMAIL PROTECTED] wrote:
Why is it unacceptable for it to mature further on mainline like
Tree-SSA?
Two releases one after another to avoid. No one real experiment to try
to rewrite an RTL optimization to figure out how def-use chain will work.
Vlad, this
Paolo Bonzini wrote:
The problem is that to use the modern approach you need another
description of insns (with one pattern - one machine insn relation)
in tree representation with given cost for the tree. And it is a
huge work to rewrite current machine descriptions even only for this.
Vladimir Makarov writes:
Vlad I did investigate the current status of the infrastructure on future
Vlad mainstream processor Core2 ( 11% slower compiler, worse code and bigger
Vlad code size). That is the reason why I started this.
You do not believe that this is a concern of others?
Steven Bosscher wrote:
On 2/13/07, Vladimir Makarov [EMAIL PROTECTED] wrote:
Why is it unacceptable for it to mature further on mainline like
Tree-SSA?
Two releases one after another to avoid. No one real experiment to try
to rewrite an RTL optimization to figure out how def-use
David Edelsohn wrote:
Vladimir Makarov writes:
Vlad I did investigate the current status of the infrastructure on future
Vlad mainstream processor Core2 ( 11% slower compiler, worse code and bigger
Vlad code size). That is the reason why I started this.
You do not
On 2/13/07, Vladimir Makarov [EMAIL PROTECTED] wrote:
...
I am only affraid that solution for faster infrastructure
(e.g. another slimmer data representation) might change the interface
considerably. I am not sure that I can convinince in this. But I am
more worried about 4.3 release and I
Sorry for the long email, i find that i need to provide a whole lot of
history as to why i am doing things the way i am so people understand
what i am trying to ask...
If you want to know why i was doing things read on, otherwise i have
some simple questions at the end since i have discovered
On 2/12/07, Vladimir Makarov [EMAIL PROTECTED] wrote:
Getting 0.5% and 11.5% slowness
(308sec vs 275sec for compiling SPECINT2000) does not seems reasonable
Just to be sure: Did you build with --disable-checking for both
compilers? I often find myself comparing compilers with checking
On Feb 13, 2007, at 1:34 PM, Brendon Costa wrote:
Sorry for the long email
Complex questions are better long, as that allows for better answers,
which should be more useful to you.
This was based on an idea from Mike in Nov 2006 when i needed to
ensure that the FUNCTION_DECL nodes were
Thanks for the response.
* Is it possible to explicitly free garbage collected memory if i know i
will not be needing it any more
Yes, ggc_free.[1]
1 - Some people think that all the savings you'd get from this aren't
work the pain of doing it, if you have to track down any over zealous
On Feb 13, 2007, at 3:16 PM, Brendon Costa wrote:
There is no additional pain in doing this as I have already
developed my code using manual malloc/free in such a way that i am
reasonably sure there are no leaks, or double free calls or the like.
No, the pain would be a dangling pointer.
Mike Stump wrote:
On Feb 13, 2007, at 3:16 PM, Brendon Costa wrote:
There is no additional pain in doing this as I have already
developed my code using manual malloc/free in such a way that i am
reasonably sure there are no leaks, or double free calls or the like.
No, the pain would be a
On Feb 12, 2007, at 10:42 PM, Basile STARYNKEVITCH wrote:
A big thanks for the explanation, which is something I partly
guessed, but which leaves me in a deep trouble :-)
Glad to turn on the flashlight so that you may see the hole. I hope
you know which way to dig now. :-)
I can't
On Mon, 12 Feb 2007, Mark Mitchell wrote:
Given that we're not going to mess about further with DECL_REPLACEABLE_P
(since the case that Kaveh raised involving PIC compilation of functions
using exceptions is a non-bug), I don't think we need to do RC3.
The only changes that we've had since
Should __attribute__ ((gnu_inline)) be treated the same as a gnu89
extern inline definition? Or should the extern part be optional?
That is, should there be a difference between these two definitions?
extern __attribute__ ((gnu_inline)) inline int foo () { return 0; }
__attribute__
Kaveh R. GHAZI wrote:
What I need to work out is what combinations of target and flags this
problem occurs under. E.g. is this problem sparc-solaris only or does it
occur on any target using pic? Or is it some subset of all platforms?
What about targets that default to pic without any extra
The problem is that to use the modern approach you need another
description of insns (with one pattern - one machine insn relation)
in tree representation with given cost for the tree. And it is a
huge work to rewrite current machine descriptions even only for this.
This is not really
Can anyone here tell me who is (and the email of) the GCC bugzilla
administrator
Thanks in advance.
Jarl
The combination of the VALUE attribute with CHARACTER(*) gives segmentation
faults (SIGSEGV, SIGBUS). Without VALUE or with CHARACTER(10), VALUE it
works.
-- Test case
program x
implicit none
character(10) :: c
c = 'Main'
print *, c
call foo(c)
print *, c
contains
--- Comment #60 from jv244 at cam dot ac dot uk 2007-02-13 09:20 ---
When you have a moment, could you confirm that all is now well with trunk,
please? Once again, I am sorry about the breakage. Now I see Daniel's
testcase, I realise that I could easily have devised a test... with
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-13 09:43 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dominiq at lps dot ens dot fr 2007-02-13 09:54 ---
Compiling the test with xlf gives:
pr30783.f90, line 6.12: 1513-061 (S) Actual argument attributes do not match
those specified by an accessible explicit interface.
pr30783.f90, line 11.14: 1516-181 (S) Objects of
--- Comment #17 from patchapp at dberlin dot org 2007-02-13 10:15 ---
Subject: Bug number PR rtl-optimization/29841
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01134.html
--
$ cat a.c
void foo(void)
{
static int irows[5];
int i;
for (i = 1; i 1000; i++)
irows[i-1] = i;
}
$ gcc -c -O1 -march=athlon-xp -ftree-vectorize a.c
a.c: In function foo:
a.c:8: internal compiler error: in expand_simple_binop, at optabs.c:1192
Please submit a full bug report,
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-13 10:33 ---
This works fine with me on powerpc-darwin with -O1 -ftree-vectorize -maltivec
plus the loop was vectorized also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pluto at agmk dot net 2007-02-13 10:37 ---
(In reply to comment #8)
Does this work on mainline with no real issue?
If so, i'll try to backport the solver changes.
gcc43 works faster, but still needs lot of memory.
(...)
tree PTA : 1.33 ( 2%)
$ cat tmp.c
typedef unsigned size_t;
char *xxcpy( char *pDest, const char *pSrc, size_t n);
char *strncpy( char *pDest, const char *pSrc, size_t n) {
if (pDest == 0 || pSrc == 0) {
if (pDest)
*pDest = 0;
return pDest;
}
return xxcpy (pDest, pSrc, n);
}
$
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-13 12:48 ---
I get
./cc1 -quiet -O -march=athlon-xp -m32 -ftree-vectorize x.i
x.i: In function 'foo':
x.i:2: error: invalid reference prefix
{4, 4, 4, 4}
x.i:2: error: invalid reference prefix
{4, 4, 4, 4}
x.i:2:
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-13 13:00 ---
I suppose this is done by the VRP pass (-f[no-]tree-vrp) so target independent.
If so, this is fixed on current 4.1 branch. Can you verify this indeed is
broken by VRP by looking at and before the vrp tree dumps?
--- Comment #5 from patchapp at dberlin dot org 2007-02-13 13:20 ---
Subject: Bug number PR28772
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01137.html
--
--- Comment #7 from drow at gcc dot gnu dot org 2007-02-13 13:39 ---
Subject: Bug 30753
Author: drow
Date: Tue Feb 13 13:39:19 2007
New Revision: 121882
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121882
Log:
PR bootstrap/30753
* configure.ac: Remove obsolete
--- Comment #8 from drow at gcc dot gnu dot org 2007-02-13 13:40 ---
Should be better now.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from etienne_lorrain at yahoo dot fr 2007-02-13 13:44
---
Problem is fixed by -fno-tree-vrp and -O2
I am not a specialist of -fdump-tree-all, but it seems like that:
tmp.c.t35.copyprop1:
;; Function strncpy (strncpy)
strncpy (pDest, pSrc, n)
{
char * D.1282;
--- Comment #61 from pault at gcc dot gnu dot org 2007-02-13 13:51 ---
(In reply to comment #60)
Yes, current trunk compiles CP2K again at -O0
Great!
to time. It is very annoying to have to fight compilers, after the computer
center upgraded a machine. My hope is that CP2K being
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-02-13 13:57 ---
This is indeed fixed on the branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from Wolfgang_Lietz at t-online dot de 2007-02-13 14:21
---
Created an attachment (id=13046)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13046action=view)
log file with compiler info and *.i
4.2.0 20070212
ICE found while running the test suite
--
Compiling or preprocessing a file that ends immediately after _Pragma leads to
an ICE:
bug.c:1:1: error: _Pragma takes a parenthesized string literal
built-in:0: internal compiler error: Segmentation fault
Simply `echo _Pragma | cpp` is enough to show it.
I'm using gcc 4.1.1.
--
--- Comment #11 from manu at gcc dot gnu dot org 2007-02-13 15:12 ---
(In reply to comment #8)
Created an attachment (id=11520)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11520action=view) [edit]
proposed patch (with doc and test changes)
Thanks for the patch. However,
--- Comment #1 from tromey at gcc dot gnu dot org 2007-02-13 15:55 ---
Confirmed, with svn head and the FC6 gcc 4.1.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-02-13 15:59
---
The algorithm is O(n^2) in the number of ready insns at any given time in the
worst case.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from ben at decadent dot org dot uk 2007-02-13 16:16
---
Already posted as http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00885.html,
with no response.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
--- Comment #10 from dberlin at gcc dot gnu dot org 2007-02-13 16:17
---
Subject: Re: possible quadratic behaviour.
On 13 Feb 2007 10:37:55 -, pluto at agmk dot net
[EMAIL PROTECTED] wrote:
--- Comment #9 from pluto at agmk dot net 2007-02-13 10:37 ---
(In reply to
--- Comment #10 from danglin at gcc dot gnu dot org 2007-02-13 16:17
---
The R_CODE_ONE_SYMBOL error was caused by my inadvertantly using
an experimental (buggy) version of gas. Closing PR as fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed
struct S
{
int *s;
};
void
test (int x, struct S *y)
{
int i;
for (i = 0; i x; i++)
{
if (y)
y-s[i] += 1;
}
}
int
main ()
{
test (1, (void *) 0);
return 0;
}
is miscompiled at -O2 in 4.1.x, works with -O2 -fno-strength-reduction or
-O2 -floop-optimize2, works
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-13 16:24 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
All tests compiled with -DSTATIC failed while other passed
FAIL: libmudflap.cth/pass37-frag.c (-static -DSTATIC) execution test
FAIL: libmudflap.cth/pass37-frag.c (-static -DSTATIC) output pattern test
--
Summary: testsuite for libmudflap failed while using -DSTATIC
--- Comment #8 from manu at gcc dot gnu dot org 2007-02-13 16:55 ---
I wish to answer this because I am also a newbie and I understand your
frustration. On the other hand, I also understand why the current situation is
as it is now.
(In reply to comment #2)
It is not practical for gcc
--- Comment #1 from Wolfgang_Lietz at t-online dot de 2007-02-13 16:57
---
Created an attachment (id=13047)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13047action=view)
log file with compiler info and error message
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30788
--- Comment #13 from manu at gcc dot gnu dot org 2007-02-13 17:19 ---
(In reply to comment #12)
Already posted as http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00885.html,
with no response.
You need to insist. A week is normally considered an acceptable interval
between pings. You
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-13 18:19 ---
From the Fortran 2003 standard:
--
C528 (R501) If the VALUE attribute is specified, the length type parameter
values shall be omitted or specified by initialization expressions.
--
Which
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org
The constant folding of arithmetic on complex numbers is inexact and doesn't
support any of the C99 special cases and avoiding overflow done in libgcc.
Compile and run the following testcase with -std=c99.
#include float.h
int printf (const char *, ...);
#define C1 (DBL_MAX * 0.5 + DBL_MAX *
--- Comment #29 from eweddington at cso dot atmel dot com 2007-02-13 19:00
---
Can a bug master please close this bug as fixed?
Thanks
Eric Weddington
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
--- Comment #34 from fxcoudert at gcc dot gnu dot org 2007-02-13 19:04
---
(In reply to comment #32)
This was on my list of patches to submit today really, I finally actually got
time to able to submit patches today. I was able to submit two other patches
today and I have another
--- Comment #9 from eweddington at cso dot atmel dot com 2007-02-13 19:12
---
5 months later and this bug still needs to be marked as NEW. Will a bug master
please do this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27386
Both on FreeBSD and GNU/Linux, bootstrap is broken on i386.
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
warning: ./cc1obj-checksum.o differs
Bootstrap comparison failure!
./cp/call.o differs
./cp/expr.o differs
./cp/decl.o differs
--
gerald at pfeifer dot com changed:
What|Removed |Added
Severity|normal |blocker
Summary|[4.3 regression] Bootstrap |[4.3 regression]
--- Comment #62 from kargl at gcc dot gnu dot org 2007-02-13 19:50 ---
(In reply to comment #48)
Currently, there is a new ICE on CP2K (see initial comment) that happens at
any
optimisation level:
gfortran -c all_cp2k_gfortran.f90
all_cp2k_gfortran.f90:118549: internal compiler
Without aliasing information some passes and cleanups cannot be scheduled
early. See http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01176.html
--
Summary: Need to run may-alias early in IPA
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #63 from jv244 at cam dot ac dot uk 2007-02-13 20:04 ---
Well, I'd add it to my testsuite if weren't a PITA to figure out how to
make it build.
wget http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz
gunzip all_cp2k_gfortran.f90.gz
gfortran -c
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-02-13 20:13
---
Too bad 4.1.2 is being packaged... Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janis at gcc dot gnu dot org 2007-02-13 20:37 ---
Dan requested a regression hunt for this. An i686-linux cross compiler starts
failing with this mainline patch:
http://gcc.gnu.org/viewcvs?view=revrev=115614
r115614 | pbrook | 2006-07-20 13:57:31 +
--- Comment #4 from stuart at apple dot com 2007-02-13 21:00 ---
Committed a fix:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01171.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30757
--- Comment #3 from pault at gcc dot gnu dot org 2007-02-13 21:00 ---
Jerry is our expert on this side of things. Although he has said that he is in
temporary hiding from gfortran, I have CC'd him:)
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from ian at gcc dot gnu dot org 2007-02-13 22:18 ---
Subject: Bug 30751
Author: ian
Date: Tue Feb 13 22:18:26 2007
New Revision: 121894
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121894
Log:
PR middle-end/30751
* lower-subreg.c
--- Comment #6 from ian at airs dot com 2007-02-13 22:22 ---
Fixed. Thanks for reporting it.
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #8 from sandra at codesourcery dot com 2007-02-14 00:04 ---
Testing of the CALL_EXPR representation patch turned up a related ICE in
tree_ssa_useless_type_conversion() while compiling
libjava/java/lang/reflect/natMethod.cc. It was failing because the expansion
of memcpy
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-02-14 00:37
---
OK, then there is a similar, not necessarily related problem in write.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30780
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-02-14 00:43
---
I'll give it a go. Just be patient please. :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hubicka at gcc dot gnu dot org 2007-02-14 01:24 ---
Hi,
the reason is -msse3 that is supposed to be at both invocations. -msse3
enables the SSE builtins that do change declarations UIDs that in turn changes
function names:
;; Function ddx (ddx.1401)
---
;;
--- Comment #6 from hp at gcc dot gnu dot org 2007-02-14 05:08 ---
Identical failure also seen for native x86_64-unknown-linux-gnu since at least
r121846 (presumably the same cause), so I'm a bit worried that it wasn't
noticed when 121819 was committed. It seems best to xfail for cris-*
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-02-14 05:14
---
It's certainly my responsibility to fix it.
Personally, I don't think it's necessary to revert it, and I will try to get to
it soon, but if it's getting in other people's way, then we could potentially
revert.
--- Comment #5 from patchapp at dberlin dot org 2007-02-14 05:26 ---
Subject: Bug number PR tree-optimization/30771
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01186.html
--
--- Comment #11 from patchapp at dberlin dot org 2007-02-14 05:26 ---
Subject: Bug number PR26061
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01190.html
--
100 matches
Mail list logo
