--- Comment #25 from pinskia at gcc dot gnu dot org 2006-05-16 06:11
---
This was fixed by the patch for PR 27603.
*** This bug has been marked as a duplicate of 27603 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-05-16 06:11
---
*** Bug 26304 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-05-16 08:01
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-05-16 08:02
---
Subject: Bug 27603
Author: rguenth
Date: Tue May 16 08:01:43 2006
New Revision: 113820
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113820
Log:
2006-05-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #8 from philipp at marek dot priv dot at 2006-05-16 08:20
---
If I remove the -funroll-loops, will it cause better code generation? I.e.
only save two registers at function start, and use just these two registers?
Can I achieve such an optimization without doing assembly
--- Comment #10 from mueller at gcc dot gnu dot org 2006-05-16 08:37
---
ok, rerunning regtest
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from saito at densan dot co dot jp 2006-05-16 09:13 ---
I can not look the problem of the testcase using gcc-4.1.0. I will try to use
gcc-4.1.0 on shlinux instead of gcc-3.4.6.
Thanks for your support.
--
saito at densan dot co dot jp changed:
What
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-16 09:28 ---
Confirmed. Works with -m64, though the docs say The 64-bit environment sets
int to 32 bits and long and pointer to 64 bits, and generates code for
PowerPC64, as for -mpowerpc64. for the -m64 option.
--
rguenth
Mike Frysinger reported this bug for 4.1 Blackfin gcc. See
http://blackfin.uclinux.org/tracker/index.php?func=detailaid=1287group_id=18atid=145.
$ gcc -o some/non/existent/dir/voodoo.o -c voodoo.i -pipe
Assembler messages:
FATAL: can't create some/non/existent/dir/voodoo.o: No such file or
--- Comment #2 from jakub at gcc dot gnu dot org 2006-05-16 10:12 ---
Subject: Bug 27499
Author: jakub
Date: Tue May 16 10:12:39 2006
New Revision: 113822
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113822
Log:
PR c/27499
* gimplify.c (gimplify_omp_for): Remove
--- Comment #1 from jakub at gcc dot gnu dot org 2006-05-16 10:16 ---
Subject: Bug 27573
Author: jakub
Date: Tue May 16 10:16:36 2006
New Revision: 113823
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113823
Log:
PR middle-end/27573
* omp-low.c
--- Comment #2 from jakub at gcc dot gnu dot org 2006-05-16 10:17 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2006-05-16 10:18 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from jakub at gcc dot gnu dot org 2006-05-16 10:20 ---
Guess the message should be sorry rather than error.
Without glibc and binutils support for .tinit_array/.tfini_array this really
isn't fixable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
--
Summary: invalid loop transformation.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
Number of loop iterations is calculated wrongly in the following bit of code.
extern char __dp0 ;
extern const long __reloc_table ;
extern const int __reloc_num ;
void
foo (void)
{
register char *dp = 0;
int cpu;
const long *reloc_ptr;
unsigned int num_relocs = 0;
dp = __dp0;
--- Comment #1 from ramana dot radhakrishnan at codito dot com 2006-05-16
10:45 ---
Clicked too early. Can be marked invalid.
--
ramana dot radhakrishnan at codito dot com changed:
What|Removed |Added
--- Comment #1 from jzhang918 at gmail dot com 2006-05-16 11:06 ---
Created an attachment (id=11475)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11475action=view)
The test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27622
hppa-unknown-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
+--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1
--- Comment #1 from soete dot joel at tiscali dot be 2006-05-16 11:51
---
Created an attachment (id=11476)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11476action=view)
precompile nan test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27627
When specifying a bitfield type, the compiler should generate assembly language
instructions that honor that type.
For example, with the following structure,
typedef struct {
unsigned long bitfA: 8;
unsigned long bitfB: 8;
unsigned long bitfC: 8;
unsigned long bitfD: 8;
}
--- Comment #1 from ramana dot radhakrishnan at codito dot com 2006-05-16
12:11 ---
Richi on IRC suggested that a weak attribute for reloc_num would fix this . The
assumption being made is that the address of reloc_num can never be 0 , which
ofcourse is not the case for a weak symbol .
--- Comment #1 from falk at debian dot org 2006-05-16 12:40 ---
There is no guarantee that this happens, and it would suppress many useful
optimizations.
However, if you mark the fields as volatile, the ARM ABI guarantees that
the access will be in the specified width (and after PR
--- Comment #14 from martin at mpa-garching dot mpg dot de 2006-05-16
12:49 ---
Even with PR 26304 fixed, the testsuite still crashes with a segfault in the
same place. I'm using FFTW 3.1.1 now, but the testing procedure is the same.
Again, the problem disappears with -fno-ivopts.
--
--- Comment #4 from jakub at gcc dot gnu dot org 2006-05-16 13:15 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2006-05-16 13:33 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hjl at gcc dot gnu dot org 2006-05-16 14:27 ---
Subject: Bug 26885
Author: hjl
Date: Tue May 16 14:27:18 2006
New Revision: 113824
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113824
Log:
gcc/
2006-05-16 H.J. Lu [EMAIL PROTECTED]
PR driver/26885
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-05-16 14:55
---
Fixed in 4.1.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-05-16 14:55
---
Subject: Bug 27339
Author: mmitchel
Date: Tue May 16 14:54:55 2006
New Revision: 113825
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113825
Log:
PR c++/27339
* cp-tree.h
--- Comment #20 from mmitchel at gcc dot gnu dot org 2006-05-16 14:57
---
Andrew --
Is there any news on this patch?
Is there anyone else available to review/test Andrew's patch?
Thanks,
-- Mark
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from Georg dot Baum at post dot rwth-aachen dot de
2006-05-16 15:04 ---
Yes, I think that would be good. Then you know that you are not doing something
wrong but that it is a tool chain limitation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557
--- Comment #21 from amacleod at redhat dot com 2006-05-16 15:16 ---
Actually, no, no new news :-). I had forgotten about this one. I'll run it
again today and check it in if no problems show up.
You want it against 4.1 and mainline? or do you want to try it against
mainline for a
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-05-16 15:34
---
Subject: Bug 22303
Author: rguenth
Date: Tue May 16 15:34:12 2006
New Revision: 113826
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113826
Log:
2006-05-16 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-05-16 15:34
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ryan at embedded-iq dot com 2006-05-16 15:54 ---
Subject: RE: Incorrect memory access type used used in accessing bitfields
Hi Falk,
Thanks for your reply. Any idea with what release PR 23623 will be fixed?
4.3.0?
Regards,
Ryan
-Original Message-
From:
--- Comment #2 from soete dot joel at tiscali dot be 2006-05-16 15:58
---
Created an attachment (id=11477)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11477action=view)
a very simpler test case
afaik don't need precompile (just rebuild) (e.g. gcc -o nan2 Nan2.c; ./nan2)
--
--- Comment #10 from hjl at lucon dot org 2006-05-16 16:32 ---
Hi Mark,
I realized that I had an updated patch
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00090.html
to address a concern from
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00050.html
Can I update gcc/doc/invoke.texi?
--- Comment #11 from mark at codesourcery dot com 2006-05-16 16:51 ---
Subject: Re: [4.1/4.2 regression] -m64 -m32 no longer creates
32-bit object
hjl at lucon dot org wrote:
--- Comment #10 from hjl at lucon dot org 2006-05-16 16:32 ---
Hi Mark,
I realized that I had
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-16 17:03 ---
This might turn out to be a kernel issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27619
--- Comment #12 from hjl at gcc dot gnu dot org 2006-05-16 17:06 ---
Subject: Bug 26885
Author: hjl
Date: Tue May 16 17:06:05 2006
New Revision: 113828
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113828
Log:
gcc/
2006-05-16 H.J. Lu [EMAIL PROTECTED]
PR driver/26885
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-16 17:07 ---
This is all undefined code:
for (reloc_ptr = __reloc_table, num_relocs = (unsigned
int)__reloc_num;num_relocs; reloc_ptr++,num_relocs--)
*(long *)(dp + *reloc_ptr) += (long)dp;
reloc_ptr can only extend one
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-16 17:15 ---
(In reply to comment #2)
Subject: RE: Incorrect memory access type used used in accessing bitfields
Hi Falk,
Thanks for your reply. Any idea with what release PR 23623 will be fixed?
4.2.0, the person who
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-16 17:16 ---
-m64 asm:
.L.main:
mflr %r0
std %r0,16(%r1)
stdu %r1,-128(%r1)
ld %r9,[EMAIL PROTECTED](%r2)
lwa %r0,0(%r9)
sradi %r9,%r0,53
rldicl %r11,%r0,0,53
addi
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-16 17:17 ---
Why do you think this is a GCC bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from olh at suse dot de 2006-05-16 17:24 ---
Created an attachment (id=11478)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11478action=view)
pr27619.s.diff
gcc -Wall -o pr27619 -O2 -g --save-temps pr27619.c -m64
vs.
gcc -Wall -o pr27619 -O2 -g --save-temps
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-16 17:27 ---
(In reply to comment #4)
does -mpowerpc64 default to 32bit by any chance? see stdu vs. stwu in fn
prologue.
Well I bet you have 32bit as the default.
Anyways -mpowerpc64 is the 64bit register in 32bit mode. And
C and C++ programs compiled with gcc 4.1 die with a SIGSEGV in Solaris 9
printstack(). The same programs run successfully when compiled with 4.0.2 and
prior. If this is due to a Solaris bug it would be great if gcc could work
around it.
$ cat t.c gcc -g t.c ./a.out || gdb -q a.out
int
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-05-16 17:28 ---
Yes it does:
[EMAIL PROTECTED]:/tmp gcc -o t -O -mpowerpc64 t.c -mregnames
[EMAIL PROTECTED]:/tmp file t
t: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), for
GNU/Linux 2.6.4, dynamically
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-05-16 17:29
---
Grrr, this broke bootstrap every where. Did you test this at all? -fno-common
added done by defualt to prevent cases like this.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
--- Comment #7 from olh at suse dot de 2006-05-16 17:30 ---
yes, mpowerpc64 creates 32bit apps.
-m64
(gdb) info float
f0 274 (raw 0x40712000)
f1 0(raw 0x)
f2 0(raw 0x)
f3 0
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-16 17:31 ---
(In reply to comment #0)
If this is due to a Solaris bug it would be great if gcc could work
around it.
And this attitute is wrong. Did you file this with Sun yet? If not, you
should say the same thing, if this
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-16 17:34 ---
The only thing I think we can do is warn that -mpowerpc64 might not work with
Linux as the linux kernel does not save and restore the full register while
doing a context switch (it is one reason why -mcpu=G5 -m32
--- Comment #2 from sebor at roguewave dot com 2006-05-16 17:35 ---
I'm not sure what you find wrong with my attitude but yes, I did send Sun a
note about it pointing them to this problem report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27629
--- Comment #14 from hjl at lucon dot org 2006-05-16 17:37 ---
I didn't see -fno-common in my build logs on Linux/x86, Linux/x86-64
and Linux/ia64. I am using:
../configure \
\
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld \
\
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-05-16 17:39
---
(In reply to comment #14)
--enable-checking=assert \
There is your issue. Why are you disabling all checking except for assert on
the mainline for testing?
--
--- Comment #9 from janis at gcc dot gnu dot org 2006-05-16 17:55 ---
Good grief, if it might not work with Linux then it shouldn't be available
for GNU/Linux targets.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from janis at gcc dot gnu dot org 2006-05-16 18:26 ---
By the way, I found this by running SPEC CPU2000, FreePOOMA, FTensor, and
Blitz++ with several sets of options plus either -m32, -m64, or -m32
-mpowerpc64 and this was the only failure I saw. This failure happens
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-05-16 19:14
---
I'm not working on the Ada problem.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from amacleod at redhat dot com 2006-05-16 20:48 ---
Bootstraps on the 4.1 branch on i686-pc-linux-gnu and produces no new testsuite
failures. It also allows the original testcase to compile.
The mainline version is now running.
Since it seems to be blocking other
--- Comment #23 from amacleod at redhat dot com 2006-05-16 20:51 ---
Subject: Bug 26757
Author: amacleod
Date: Tue May 16 20:51:14 2006
New Revision: 113829
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113829
Log:
Remove redundant hash table lookup when finding referenced vars.
--- Comment #10 from schwab at suse dot de 2006-05-16 20:56 ---
Testresults here http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg00858.html.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
--- Comment #4 from tbm at cyrius dot com 2006-05-16 21:11 ---
Hmm, that's interesting. When I call g++ from a Makefile I get a
unrecognizable insn error but calling it directly leads to the segfault.
I've no idea if this unrecognizable insn error is helpful in any way but I
thought
--- Comment #4 from tbm at cyrius dot com 2006-05-16 21:11 ---
Hmm, that's interesting. When I call g++ from a Makefile I get a
unrecognizable insn error but calling it directly leads to the segfault.
I've no idea if this unrecognizable insn error is helpful in any way but I
--- Comment #5 from pinskia at physics dot uc dot edu 2006-05-16 21:13
---
Subject: Re: segfault with virtual class and visibility (hidden)
--- Comment #4 from tbm at cyrius dot com 2006-05-16 21:11 ---
Hmm, that's interesting. When I call g++ from a Makefile I get
--- Comment #6 from tbm at cyrius dot com 2006-05-16 21:22 ---
(In reply to comment #2)
Looking at the backtrace, this looks like a target specific issue.
Yeah, cannot reproduce it on arm, i386, ia64, hppa, mips, powerpc.
Can we add some Alpha GCC folks to the CC list of this bug?
--- Comment #16 from bernds_cb1 at t-online dot de 2006-05-16 21:30 ---
I saw the fallout of this on the mailing list, but was the patch ever sent to
gcc-patches before it was committed?
--
bernds_cb1 at t-online dot de changed:
What|Removed
--- Comment #17 from mmitchel at gcc dot gnu dot org 2006-05-16 21:46
---
Yes, the patch was posted; see Comment #8.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26885
I got unaligned access on ia64 for
gcc/testsuite/gfortran.dg/transfer_array_intrinsic_2.f90
For
96subroutine test3 (ch1, ch2, ch3, clen)
97 integer clen
98 character(8) :: ch1(:)
99 character(*) :: ch2(2)
100 character(clen) :: ch3(2)
101
real val
character str*6
open(1,FILE=tmp.dat)
read(1,'(a6,f4)') str,val
print*,str,val
end
gfortran tells me as follows:
read(1,'(a6,f4)') str,val
1
Warning: Period required in format
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-16 22:19 ---
I already mentioned before it should be using VIEW_CONVERT_EXPR instead of an
address and a NOP_EXPR but nobody listened to me in the orginal bug report.
Note this effects both strict alignment targets and
Member variables of parent class are not found under template constructions
where the template type is passed to the parent class.
--
Summary: failure of template class with with inherited templated
classes
Product: gcc
Version: 4.0.2
--- Comment #1 from johnbrown at pentum dot com 2006-05-16 22:38 ---
Created an attachment (id=11479)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11479action=view)
Test case
gcc -v : gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
uname
Linux plinux 2.6.11-1.1369_FC4 #1 Thu Jun 2
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-16 22:39 ---
Please read:
http://gcc.gnu.org/gcc-3.4/changes.html
This is not a bug.
-- Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from johnbrown at pentum dot com 2006-05-16 22:40 ---
Created an attachment (id=11480)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11480action=view)
-save-temp file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27635
--- Comment #11 from janis at gcc dot gnu dot org 2006-05-16 22:42 ---
As mentioned above, the Linux kernel does not provide context switching support
needed for -m32 -mpowerpc64. I'm looking into disabling it for
powerpc64-linux.
--
--- Comment #4 from johnbrown at pentum dot com 2006-05-16 22:52 ---
(In reply to comment #2)
Please read:
http://gcc.gnu.org/gcc-3.4/changes.html
This is not a bug.
-- Pinski
(In reply to comment #2)
Thanks, you are correct.
Please read:
Compiling the following program:
#define STDCALL __attribute__((stdcall))
struct B1 {
int x;
virtual int STDCALL bar(int x) = 0;
};
struct B2 {
int x;
virtual int STDCALL foo(int x) = 0;
};
struct D: B1, B2 {
int a;
int STDCALL bar(int n);
--- Comment #1 from rridge at csclub dot uwaterloo dot ca 2006-05-16 23:38
---
LTHUNK0 should be aliased to [EMAIL PROTECTED].
The bug goes away if D::bar(int) is not defined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27636
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-16 23:54 ---
This looks related to Bug 27067.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-16 23:55 ---
Does the patch there fix this issue also?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27636
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-05-17 00:16
---
I will investigate this a bit.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-05-17 00:37
---
Subject: Bug 27575
Author: jvdelisle
Date: Wed May 17 00:36:53 2006
New Revision: 113837
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113837
Log:
2006-05-16 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-05-17 00:41
---
Subject: Bug 27575
Author: jvdelisle
Date: Wed May 17 00:40:23 2006
New Revision: 113838
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113838
Log:
2006-05-16 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #4 from danglin at gcc dot gnu dot org 2006-05-17 00:49 ---
This isn't a target bug as far as I can tell. The value generated
by __builtin_nanf() as shown by Nan2.c is 0x7fc0. The same
value is printed on x86. This is a signaling NaN. Positive quiet
NaNs range
--- Comment #6 from sven at physto dot se 2006-05-17 00:56 ---
I should update my previous comment: DataBuffers created by the user, i.e. the
DataBuffer implementations in the public API do wrap true java arrays.
However, when creating a BufferedImage on the JDK the corresponding
--- Comment #11 from sayle at gcc dot gnu dot org 2006-05-17 01:12 ---
Subject: Bug 26600
Author: sayle
Date: Wed May 17 01:11:59 2006
New Revision: 113839
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113839
Log:
PR target/26600
* config/i386/i386.c
--- Comment #4 from wszafran at users dot sourceforge dot net 2006-05-17
01:15 ---
(In reply to comment #2)
This looks related to Bug 27067.
Not only related but pretty much the same thing. And Ross' example program
compiles cleanly using the latest 4.1.1 (20060512) snapshot with
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-05-17 01:16 ---
Subject: Bug 27373
Author: dberlin
Date: Wed May 17 01:16:08 2006
New Revision: 113840
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113840
Log:
2006-05-16 Daniel Berlin [EMAIL PROTECTED]
Fix PR
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-17 02:36 ---
*** This bug has been marked as a duplicate of 27067 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-17 02:36 ---
*** Bug 27636 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rchapman at acm dot org 2006-05-17 03:44 ---
(In reply to comment #3)
I don't mind putting it back in, Jim described what needs to be done in
PR24357. I don't have a ratfor processor to test with, so I'd prefer if
someone else wrote (i.e. copied from gcc 4.0)
93 matches
Mail list logo
