Can someone please help me getting the following information?
1) I would like to obtain the loop bounds (constant case) of all nested
loops
of a RTL insn. Is there a data structure over which I can iterate to get
bounds
for each nested loop of a RTL insn?
2) Is there a way of determining
On 10 sep 2005, at 02:03, Richard Henderson wrote:
On Sat, Sep 10, 2005 at 01:00:04AM +0930, Alan Modra wrote:
2) Next, I defined parallels to keep things together. Like the
following, with another for DImode.
This seems most reasonable to me.
Especially as the ABI states that the write
I realise that according to the C++ standard it isn't legal to compare
two pointers which are not from the same array. Is anyone aware of
anything in g++ which would actually forbid this, and if there is any
way of checking if will be valid?
I want to be able to perform two main operations.
chris jefferson wrote:
I realise that according to the C++ standard it isn't legal to compare
two pointers which are not from the same array. Is anyone aware of
anything in g++ which would actually forbid this, and if there is any
way of checking if will be valid?
In my opinion we should first
Paolo Carlini wrote:
Then, as far as *our* library (and compiler) are concerned, there is the
interesting example of basic_string::_M_disjunct: with Nathan's
substantive insight we came to the conclusion that such kind of
comparisons can be always meaningful to do (at the C++ library level) if
we
On Tue, Sep 13, 2005 at 11:28:07AM +0200, Segher Boessenkool wrote:
Especially as the ABI states that the write of the backlink
and the stack pointer update _have_ to be done in one insn.
That's on allocation. Deallocation isn't so critical. You just need to
ensure the backchain is written
Especially as the ABI states that the write of the backlink
and the stack pointer update _have_ to be done in one insn.
That's on allocation. Deallocation isn't so critical. You just need
to
ensure the backchain is written before updating sp.
Yes, but your example generated code showed
Hello,
I have the following insn:
(insn 522 521 523 87 (set (reg:SI 308)
(reg:SI 0 ax)) 40 {*movsi_1} (nil)
(insn_list:REG_RETVAL 520 (expr_list:REG_EQUAL (parity:DI (reg:DI 248 [
D.1874 ]))
(nil
Is this correct? I have a piece of code that breaks if mode of the
I am now going to start spinning 4.0.2 RC1.
(I was planning to do that last weekend, but it didn't happen.)
Therefore, as of now, the GCC 4.0 branch is frozen. If you've had a
patch approved for 4.0.2 that's not yet been checked in, and you want to
check it in, please send me the patch URL;
On Fri, 9 Sep 2005, Jonathan wrote:
i could become a mirror if you want
i'm from rome italy
the server is in Arezzo Italy
i have 3 domains that you could mirror though if u wanted
let me know please :)
win.ac3bf1.com
lnx.ac3bf1.com
rjn.it
P.S. = send me the files to upload
Is there any plan to support Windows/x86-64?
I haven't heard of anyone wanting to work on such a port.
What are needed for the port?
What you'ld need for any OS port. GCC needs to support the Windows
x64 ABI, you need a suitable runtime library, and you need a suitable
assembler and linker.
On Mon, 12 Sep 2005, Mark Mitchell wrote:
In summary, I think that splitting GCC optimization efforts between FSF
and ORC back-ends is unfortunate. I would far rather that the free
software community be united behind a single optimizer. But,
fundamentally, I don't see much that we can do
Gerald Pfeifer wrote:
Do I understand correctly that the new backend is not planned to be
included in FSF GCC?
That seems unlikely, in the medium-term, at least. Some people have
rasied legal issues, which I know nothing about, but the code has not
been assigned to the FSF. But, those are
On Sep 13, 2005, at 12:23 PM, Rafael Espíndola wrote:
I have seen both in gcc. I have found that type* variable is
preferred in C++ code but I haven't found any guidelines for C code.
If you ask gcc, you find:
mrs $ grep 'int\* ' *.c | wc -l
4
mrs $ grep 'int \*' *.c | wc -l
369
On 9/13/05, Mike Stump [EMAIL PROTECTED] wrote:
If you ask gcc, you find:
mrs $ grep 'int\* ' *.c | wc -l
4
mrs $ grep 'int \*' *.c | wc -l
369
pretty clear to me.
In treelang/parse.y all variables named tok (and some others) are
declared with
struct prod_token_parm_item*
thanks, that works but it seems to require a -g. is there any flag
which might also generate just this line information but avoid most of
the other debug information.
shrey
On 9/11/05, Dale Johannesen [EMAIL PROTECTED] wrote:
On Sep 11, 2005, at 8:09 AM, shreyas krishnan wrote:
Hi,
On Tue, 13 Sep 2005, Rafael Espíndola wrote:
On 9/13/05, Mike Stump [EMAIL PROTECTED] wrote:
If you ask gcc, you find:
mrs $ grep 'int\* ' *.c | wc -l
4
mrs $ grep 'int \*' *.c | wc -l
369
pretty clear to me.
In treelang/parse.y all variables named tok (and some others) are
Joe Buck wrote:
You might want to first make sure that your program has no memory
access errors. You could try building it for x86 and debugging
with valgrind, to see if that catches anything.
A good idea. I built it for x86. Unfortunately, from the output it
appears that 'clone' is not
The interesting thing to note is that if I edit this and only do one
clone call, things work. As soon as I attempt to do a second clone,
things fall apart when debugging symbols with '-O0 -g' are compiled.
Again, the source link is below. I am going to have to make a note
of this bug and come
On Tue, 13 Sep 2005, Steven J. Hill wrote:
You might want to first make sure that your program has no memory
access errors. You could try building it for x86 and debugging
with valgrind, to see if that catches anything.
A good idea. I built it for x86. Unfortunately, from the output it
On Tuesday 13 September 2005 18:11, Daniel Berlin wrote:
So, uh, change them :)
I have just submitted a patch :)
Rafael
pgpOrEeEKuddE.pgp
Description: PGP signature
Any reason why we blindly assume destination registers will be hard
registers here?
Index: regmove.c
===
RCS file: /cvs/gcc/gcc/gcc/regmove.c,v
retrieving revision 1.173
diff -p -U3 -r1.173 regmove.c
--- regmove.c 25 Aug 2005
Snapshot gcc-3.4-20050913 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050913/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050913
You'll find
For a while gccadmin's crontab has been out of sync with the version in
CVS (maintainer-scripts/crontab). That in use has
43 10 * * 5 sh /home/gccadmin/scripts/gcc_release -s 4.1:HEAD -l -d
/sourceware/snapshot-tmp/gcc all
while that in CVS has
43 17 * * 6 sh
On Tue, Sep 13, 2005 at 11:22:18AM +0100, chris jefferson wrote:
I realise that according to the C++ standard it isn't legal to compare
two pointers which are not from the same array. Is anyone aware of
anything in g++ which would actually forbid this, and if there is any
way of checking if
--- Additional Comments From falk at debian dot org 2005-09-13 06:19
---
(In reply to comment #16)
Oh? I had -Werror on, and was not getting any warning at all from my code
that
was generating 'int $0x5' with gcc 3.4.1. It's perhaps a slightly different
case than comment 0,
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-09-13 07:11 ---
Patch.
--
What|Removed |Added
URL|
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
07:15 ---
Subject: Bug 19269
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 07:15:02
Modified files:
gcc/testsuite : ChangeLog
libgfortran:
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-13
07:24 ---
Patch committed to mainline.
--
What|Removed |Added
Status|ASSIGNED
--
Bug 19276 depends on bug 19269, which changed state.
Bug 19269 Summary: transpose(reshape(...)) of character array segfaults.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19269
What|Old Value |New Value
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
07:33 ---
Subject: Bug 23817
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 07:33:50
Modified files:
gcc: ChangeLog tree-cfg.c
Log message:
failing versions: 4.0.1 (FSF), 4.0.0 (Apple, build 5026), 3.4.0 (FSF) --
platform-independent
working vesions: 3.3 (Apple, build 4061), 3.3 (FSF) -- platform-independent
to reproduce: g++ visibug.cc
'failing' versions reject with the same diagnostic:
visibug.cc: In member function 'void
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-13
07:50 ---
Re crti.o and crtn.o: can I just check that you unpacked unmodified
FSF sources, configured with those arguments, ran make, and that
make completed successfully, but that crti.o and crtn.o were
somehow not
--- Additional Comments From fang at csl dot cornell dot edu 2005-09-13
07:57 ---
correction: g++ 3.3.3 (FSF, i386-linux) *rejects* the test case with the same
error message.
That should narrow down the search to somewhere in the 3.3 series.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
08:07 ---
Subject: Bug 18899
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 08:07:16
Modified files:
gcc/testsuite : ChangeLog
gcc/fortran:
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-13
08:08 ---
Patch applied to mainline.
--
What|Removed |Added
Status|ASSIGNED
--
What|Removed |Added
Target Milestone|4.1.1 |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18899
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-13
08:34 ---
After the patch for 18899, this now works for:
program main
implicit none
real :: a(0:9)
integer :: bn(10)
bn(1:1) = lbound(a)
print *, bn(1)
end program main
but like FX says, we probably
Now we allow array and array element as format specification. The array should
be assigned HOLLERITH constant first. The question is that if we should allow
array element here.
g77, pgf deny this, but intel accepts.
Some discussions:
http://gcc.gnu.org/ml/fortran/2005-09/msg00191.html
When I compile the small program below using the actual snapshot
(20050909) I get an ICE. This ICE is new, the snapshot from last week is
working.
Michael Cieslinski
file tc.i
int Foo ()
{
int a[16];
int i;
for (i=0; isizeof(void*); ++i)
{
int *p;
for (p=a+1;
--- Additional Comments From jakub at gcc dot gnu dot org 2005-09-13 09:04
---
At least on i?86, this seems to be introduced by reload, .lreg dump is still
sane.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
void bar(void);
void foo(int ie, int je)
{
int i, j;
for (j=0; jje; ++j)
for (i=0; iie; ++i)
bar();
}
should _not_ be transformed to
foo (ie, je)
{
int j;
int i;
bb 0:
if (je 0) goto L23; else goto L5;
L23:;
j = 0;
goto bb 3 (L2);
L22:;
i = 0;
L1:;
bar ();
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-13
10:27 ---
Bloody hell. Stupid bug.
Alright then, let's see if I can fix this one.
--
What|Removed |Added
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-13
10:42 ---
We do not CONFIRM bugs without a small testcase (which would be 2 small files in
this case). Even if I could confirm it (I didn't try to reproduce with the
PR22574 testcase).
--
I am filing this bug because we still diverge from Classpath for java.util.zip
and we need to track this issue.
The base bug is PR classpath/23854 and it also applies to libgcj.
See:
http://gcc.gnu.org/ml/java/2005-09/msg00070.html
http://gcc.gnu.org/ml/java/2005-09/msg00072.html
The
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-13
13:12 ---
Unswitching should clean this up, but unfortunately(?) only looks at innermost
loops. For a reason it seems, just removing this checks results in an ICE.
Testcase for unswitching:
void bar(void);
void
When I compile the small program below using the actual snapshot
(20050909) I get an ICE.
last working snapshot is gcc-4.1-20050723
first failing snapshot is gcc-4.1-20050730
Michael Cieslinski
file tc.cpp
extern int *F2 (void) __attribute__ ((__const__));
struct S1{};
struct S3;
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-09-13
13:29 ---
It is not clear to me why you find the code without header copying better --
number of checks of each condition is exactly the same in both cases, and with
right ordering of basic blocks, there should be
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
13:46 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-13
13:47 ---
Well, it is the case that I have some numerical application that has
such loops and the case of small ie (1 or 2) does happen during boundary
updates, so instead of
if (ie = 0)
return;
for (j=0;
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-13
13:54 ---
it's ICEing because host_integerp complains that TREE_OVERFLOW is set:
#1 0x084f7397 in tree_low_cst (t=0x4022daf8, pos=1) at tree.c:4273
Line number 4273 out of range; tree.c has 2318 lines.
(gdb) call
When I compile the small program below using the actual snapshot
(20050909) I get a segfault. This segfault occurs whith all the gcc41 snapshots
I have, my oldest is gcc-4.1-20050604, gcc40 does not segfault.
Michael Cieslinski
file tc.c
typedef struct Data
{
unsigned int Table [256];
}
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
14:01 ---
On PPC, we get optimal and almost unswitched loop:
L4:
ble- cr4,L7
li r31,0
L6:
addi r31,r31,1
bl _bar
cmpw cr7,r30,r31
bne+ cr7,L6
L7:
addi r29,r29,1
--- Additional Comments From bangerth at dealii dot org 2005-09-13 14:04
---
Here's a slightly smaller version:
-
struct A {};
struct B : private A {};
B *p = static_castB*((A*)0);
-
g/x /home/bangerth/bin/gcc-3.2.3/bin/c++ -c x.cc
g/x
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
14:05 ---
*** This bug has been marked as a duplicate of 23049 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
14:05 ---
*** Bug 23858 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23049
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-13
14:06 ---
Patch that could be obvious (but I'm always hesitant to apply such right
away...)
Index: tree-vect-analyze.c
===
RCS file:
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-13
14:09 ---
Heh - you unswitched the comparison but not the jump!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
14:09 ---
This is invalid code. See PR 12265 which this is a dup of.
*** This bug has been marked as a duplicate of 12265 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
14:09 ---
*** Bug 23849 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
14:20 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From dank at kegel dot com 2005-09-13 14:31 ---
Keating wrote in http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01345.html
Needs a ChangeLog entry, but otherwise OK.
A key detail that you left out of your patch description is that
SYSTEM_HEADER_DIR is used *only*
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
14:40 ---
Subject: Bug 23842
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-13 14:39:57
Modified files:
gcc/cp :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
14:42 ---
Subject: Bug 23839
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-13 14:42:39
Modified files:
gcc/cp :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
14:44 ---
Subject: Bug 23842
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 14:44:08
Modified files:
gcc/cp : ChangeLog pt.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
14:45 ---
Subject: Bug 23839
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 14:45:14
Modified files:
gcc/cp : ChangeLog typeck.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
14:50 ---
This is done for me correctly on PPC-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23845
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-09-13
14:53 ---
(In reply to comment #8)
Bloody hell. Stupid bug.
Alright then, let's see if I can fix this one.
Steven, it seems to disappear on current gcc4.1 and gcc4.0. I once send you a
patch to fix the gimple
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-13
14:55 ---
Fixed in 4.0.2.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-13
14:55 ---
Fixed in 4.0.2.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
15:16 ---
Subject: Bug 16171
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 15:15:37
Modified files:
gcc/cp : ChangeLog mangle.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
15:17 ---
Subject: Bug 16171
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-13 15:17:12
Modified files:
gcc/cp :
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-13
15:19 ---
Fixed in GCC 4.0.2.
--
What|Removed |Added
Status|NEW
--- Additional Comments From sje at cup dot hp dot com 2005-09-13 15:47
---
I don't have a 10.20 machine around anymore. All my machines are 11.00 or
later.
10.20 was released in 1996.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23734
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-09-13 16:00 ---
Subject: Re: [4.1 Regression] make[4]: execvp: /usr/local/bin/bash: Arg list
too long
I don't have a 10.20 machine around anymore. All my machines are 11.00 or
later.
10.20 was released in
Bootstrapping with Fortran enabled fails for 4.0.1 if -pipe is included
among flags passed through to library builds. It used to work for 4.0.0.
The reason is libgfortran/intrinsics/f2c_specifics.F90, which is new to
4.0.1, and the %| operator used in the specs
(gcc/fortran/lang-specs.h)
--- Additional Comments From macro at linux-mips dot org 2005-09-13 16:03
---
Created an attachment (id=9718)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9718action=view)
gcc-4.0.1-specs-pipe-suffix.patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23861
When -pipe is used for .F90 and .F95 sources this warning is produced:
Warning: Reading file 'stdin' as free form.
The reason is the compiler cannot deduce the form from the file name
suffix as in this case it's only known to the preprocessor.
Here is an obvious patch following the approach
--- Additional Comments From macro at linux-mips dot org 2005-09-13 16:06
---
Created an attachment (id=9719)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9719action=view)
gcc-4.0.1-fortran-form-free.patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23862
--- Additional Comments From benjamin at smedbergs dot us 2005-09-13 16:34
---
Created an attachment (id=9720)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9720action=view)
Failure even with the latest patch
I'm wrong. attachment 9035 fixes the compile errors in the main mozilla
--
What|Removed |Added
Attachment #9720 is|1 |0
patch||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
--- Additional Comments From janis at gcc dot gnu dot org 2005-09-13 18:17
---
I'm still looking at this. My earlier comment about having fixed it on
mainline was wrong; I thought it was a problem in altivec.h, but it's in
the compiler itself and this problem never showed up on
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-13
18:29 ---
Please provide a standalone testcase.
gcc -O2 -S matmul_r8.c
matmul_r8.c:31:20: error: config.h: No such file or directory
matmul_r8.c:35:25: error: libgfortran.h: No such file or directory
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
18:51 ---
This is what we get one the mainline:
.L4:
movl(%ecx), %eax
addl$4, %ecx
movl%eax, (%edi,%edx,4)
movl(%ebp,%edx,4), %eax
movl%eax, (%esi,%edx,4)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
19:02 ---
Subject: Bug 23816
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 19:02:05
Modified files:
gcc: ChangeLog
gcc/config/i386:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
19:03 ---
Subject: Bug 19358
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-13 19:02:57
Modified files:
gcc/fortran:
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-13
19:19 ---
Just for the record:
This was fixed by Richard Sandiford's patch for PR19239:
http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00346.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21063
The libstdc++ ABI testsuite does not work when testing an installed compiler
because:
* abi.exp checks for ../src/.libs/libstdc++.so, which of course is not
available with an installed compiler.
* abi.exp requires baseline_file to be set in site.exp; with installed compiler
testing, site.exp is
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
19:23 ---
Subject: Bug 22554
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 19:22:52
Modified files:
libstdc++-v3 : ChangeLog
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
19:23 ---
Subject: Bug 23734
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 19:22:52
Modified files:
libstdc++-v3 : ChangeLog
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 19:29
---
Moving to c++ component, maybe they can help him...
--
What|Removed |Added
--
What|Removed |Added
GCC target triplet||sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22612
--- Additional Comments From callahan at sci dot utah dot edu 2005-09-13
19:32 ---
Subject: Re: SSA Crash, reproducable
This still crashes for me with the latest Ubuntu g++ build.
g++ (GCC) 4.0.2 20050808 (prerelease) (Debian 4.0.1-4ubuntu6)
The error is the same, but the crash is
--
What|Removed |Added
Known to work||3.3.2
Summary|linking error while |linking error while
|compiling ddd
--
What|Removed |Added
Known to fail||3.4.0
Summary|linking error while |linking error while
|compiling ddd
apply_result_size uses reg_raw_mode for every register that is flagged with
FUNCTION_VALUE_REGNO_P. However, reg_raw_mode is the mode to save a single
hard register, while a return value can be held in multiple consecutive hard
registers, and FUNCTION_VALUE_REGNO_P has to be true only for the
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 19:35
---
Mine.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot
--
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
||patches/2005-
|
--
What|Removed |Added
GCC build triplet||sparc-sun-solaris2.9
GCC host triplet||sparc-sun-solaris2.9
1 - 100 of 170 matches
Mail list logo
