--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-01 06:51 ---
The same thing happens with arrays:
typedef char cptr[2];
__attribute__ ((vector_size(16))) cptr t;
--
And pointer to arrays:
typedef char cptr[1];
typedef cptr *cptr1;
extern
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-01 06:45 ---
Actually this is weird, we are applying the vector_size attribute to the inner
type instead of to the typedef type which seems more appropriate. It is
evident we are applying the attribute by adding * infront of t i
Testcase:
typedef char *cptr;
char *a;
__attribute__ ((vector_size(16))) cptr t;
int f(void)
{
__attribute__ ((vector_size(16))) int t1 =
(__attribute__ ((vector_size(16))) int )t;
}
We get an error about converting t to a vector int but t looks to me a vector
of a char pointer. This happe
Take the following testcase:
extern char lanip[3][40];
typedef struct
{
char *t[4];
}tx_typ;
int set_names (void)
{
static tx_typ tt1;
int ln;
for (ln = 0; ln < 4; ln++)
tt1.t[ln] = lanip[1];
}
-
With -O2 -ftree-vectorize -maltivec, we produce a vector long long and we get
worse
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-01 06:27 ---
Here is a testcase which ICEs for i686-linux-gnu with -msse:
extern char lanip[3][40];
typedef struct
{
char *t[4];
}tx_typ;
int set_names (void)
{
static tx_typ tt1;
int ln;
for (ln = 0; ln < 4; ln++)
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-01 06:11 ---
Here is an even more reduced testcase:
void f(void)
{
unsigned l, l1;
l1 = l = ({unsigned __v; __v;});
}
Note the double use is required to ICE, otherwise we are ok.
There is no question about it after looking a
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.0.4 |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27115
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-01 05:52 ---
(In reply to comment #4)
> No, 4.1.2 20060831 works.
Well the ICE can only happen with checking turned on so it could still be a bug
in 4.1.2.
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-01 05:46 ---
Janis,
Could you run a regression hunt on this bug?
Thanks,
Andrew
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from dorit at il dot ibm dot com 2006-09-01 05:43 ---
oops - I didn't notice it was open against 4.1.
So hopefully porting Victor's patch to 4.1 would fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-01 05:14 ---
For 4.1, we get:
i_1: VARYING
size_2: VARYING
size_3: [size_2, size_2] EQUIVALENCES: { size_2 } (1 elements)
i_4: [0, +INF] EQUIVALENCES: { i_1 i_7 i_8 i_9 } (4 elements)
n_5: [0, size_2 - 1] EQUIVALENCES: { i_1 i
--- Comment #21 from paulthomas2 at wanadoo dot fr 2006-09-01 04:58 ---
Subject: Re: [4.1/4.2 Regression]: fold_convert fails
for Fortran operator
hjl at lucon dot org wrote:
Thanks HJ. It seems that I am going to have to revert this one; I have
spent way too much time on it and was
--- Comment #12 from patchapp at dberlin dot org 2006-09-01 04:51 ---
Subject: Bug number PR C++/28906
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/2006-09/msg7.html
--
http://gcc.gnu.org/bugzi
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-01 04:49
---
I did not add a testcase for one that just ICE but I did add two testcases, one
for the wrong code and one for the rejecting valid. The ICE is because of
templates which I don't feel like needing a testcase for th
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-01 04:20 ---
Also what version of Xcode do you have installed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28916
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-01 04:02 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-01 04:01
---
(In reply to comment #9)
> Actually, can you please check when you get home if this is the same bug?
Yes this is the same bug as my patch (which I am about to submut) fixes it.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #5 from tbptbp at gmail dot com 2006-09-01 02:53 ---
(In reply to comment #4)
> Actually this is just a problem of IV selection, what is happening is the IV
> selection chooses the 1024+(const char *)&base[quad] as the IV instead of just
> &base[quad] which causes the bigger
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-01 02:46 ---
Actually this is just a problem of IV selection, what is happening is the IV
selection chooses the 1024+(const char *)&base[quad] as the IV instead of just
&base[quad] which causes the bigger encoding.
--
pinskia
--- Comment #3 from tbptbp at gmail dot com 2006-09-01 02:04 ---
Hmm, that description is a bit wrong. What i really mean is that gcc trades x
long encodings for 1 short instead of other way around.
Bear with me, it's rather late here :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #2 from tbptbp at gmail dot com 2006-09-01 01:56 ---
Created an attachment (id=12165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12165&action=view)
test case preprocessed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
--- Comment #1 from tbptbp at gmail dot com 2006-09-01 01:55 ---
Created an attachment (id=12164)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12164&action=view)
test case source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
With code like this (see attachement for a complete silly test case),
unsigned int quad = 0;
for (unsigned int dec=node.count/4; dec; --dec) {
_mm_prefetch(1024+(const char *)&base[quad], _MM_HINT_NTA);
sampler.countl[0] = _mm_add_epi32(sampler.countl[0],
_mm_cmpgt_epi32(sampler.pos
--- Comment #18 from jconner at gcc dot gnu dot org 2006-08-31 23:44
---
Subject: Bug 25505
Author: jconner
Date: Thu Aug 31 23:44:00 2006
New Revision: 116613
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116613
Log:
2006-08-31 Josh Conner <[EMAIL PROTECTED]>
PR c+
--- Comment #20 from hjl at lucon dot org 2006-08-31 22:24 ---
Here it is:
[EMAIL PROTECTED] wrf-1]$ cat zzz.f90
module bar
implicit none
public
type ESMF_Time
sequence
integer :: MM
end type
public operator (+)
private add
interface operator (+)
module procedure a
--- Comment #19 from bkoz at gcc dot gnu dot org 2006-08-31 22:20 ---
Subject: Bug 28671
Author: bkoz
Date: Thu Aug 31 22:20:09 2006
New Revision: 116608
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116608
Log:
2006-08-31 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libst
--- Comment #7 from echristo at apple dot com 2006-08-31 22:14 ---
After discussion with DJ I'm going to mark this as WONTFIX. We'll just allow
people to shoot themselves in the foot if they try to disable a directory that
they shouldn't.
--
echristo at apple dot com changed:
--- Comment #9 from tromey at gcc dot gnu dot org 2006-08-31 22:00 ---
Subject: Bug 28698
Author: tromey
Date: Thu Aug 31 22:00:06 2006
New Revision: 116607
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116607
Log:
PR libgcj/28698:
* libgcj_bc.c (DECLARE_PRIM_TY
--- Comment #4 from luke dot powell at bjservices dot com 2006-08-31 21:59
---
(In reply to comment #3)
> It is the SVN trunk, so a svn snapshot will be a snapshot of the mainline.
>
I attempted a rebuild with the trunk at SVN revision 116602. The compilation
did get past the previous
--- Comment #19 from hjl at lucon dot org 2006-08-31 21:00 ---
The new patch works for the testcase. But wrf still fails:
[EMAIL PROTECTED] build_base_o2.]$ /usr/gcc-4.2/bin/gfortran -c -o
ESMF_Clock.fppized.o -I. -I./netcdf/include -O2 -ffast-math
-DSPEC_CPU_LINUX -DSPEC_CP
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 20:45 ---
This extension was removed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
We're now rejecting the minimum/maximum operator in some c++ code.
This is a new regression. It works with 20060806.
(sid)106:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c orig.c
orig.c: In member function 'virtual void IBox::Rebuild()':
orig.c:10: error: expected primary-expression befo
--- Comment #4 from janis at gcc dot gnu dot org 2006-08-31 20:29 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=116213
r116213 | rakdver | 2006-08-17 08:22:05 + (Thu, 17 Aug 2006)
--
janis at gcc dot gnu dot org ch
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-31 20:28 ---
(In reply to comment #5)
> A regression hunt on powerpc-linux identified this patch:
That means it is a latent bug :) oh well, nothing useful really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28900
--- Comment #5 from janis at gcc dot gnu dot org 2006-08-31 20:27 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=99691
r99691 | kazu | 2005-05-14 00:46:12 + (Sat, 14 May 2005)
--
janis at gcc dot gnu dot org changed
--- Comment #7 from pluto at agmk dot net 2006-08-31 20:22 ---
(In reply to comment #6)
> The author didn't respond to my question about copyright assignment, so I
> don't
> think the patch can be applied.
it's weird to waiting years for respond about such trivial patch.
--
http:/
--- Comment #9 from tbm at cyrius dot com 2006-08-31 20:21 ---
Created an attachment (id=12163)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12163&action=view)
preprocessed source
Actually, can you please check when you get home if this is the same bug?
--
http://gcc.gnu.org
--- Comment #8 from tbm at cyrius dot com 2006-08-31 20:10 ---
Is this the same bug?
(sid)59:[EMAIL PROTECTED]: ~/delta/bin] /usr/lib/gcc-snapshot/bin/g++ -c mini.c
mini.c:40: error: variable-size type declared outside of any function
mini.c:40: error: variable-size type declared outsi
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-08-31 19:34 ---
Subject: Bug 28839
Author: rakdver
Date: Thu Aug 31 19:33:56 2006
New Revision: 116605
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116605
Log:
PR tree-optimization/28839
* tree-into-ssa.c
--- Comment #5 from tbm at cyrius dot com 2006-08-31 19:28 ---
(In reply to comment #4)
> Can someone add the dump of -fdump-tree-final_cleanup ?
;; Function set_names (set_names)
set_names (ob, idx)
{
char * * vect_ptt1.38;
vector char * vect_cst_.34;
static struct tx_typ tt1;
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-31 19:27 ---
Actually yes it is branched because it should be but movl$0, 0
Means store 0 into the address of 0 so it works. The branch over is ok because
well this is the way zero overhead exceptions works.
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-31 19:21 ---
Can someone add the dump of -fdump-tree-final_cleanup ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
--- Comment #3 from uros at kss-loka dot si 2006-08-31 19:15 ---
Confirmed on x86_64.
Backtrace:
(gdb) bt
#0 build_vector (type=0x2db3e6e0, vals=0x2db37cc0) at
../../gcc-svn/trunk/gcc/tree.c:973
#1 0x007b829d in force_const_mem (mode=V2DImode, x=0x2da089e0) at
../
--- Comment #2 from pluto at agmk dot net 2006-08-31 19:13 ---
it doesn't help. `jmp .L2` skips catch block :)
main:
pushq %rbx
movl$_Z13signalHandleri, %esi
movl$11, %edi
callsignal
movl$0, 0
jmp .L2
.L8:
cmp
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 19:08 ---
I think you forgot "-fnon-call-exceptions" which is need to be used if you want
non calls to be able to throw.
Can you try with that option and report if that fixes the problem?
--
http://gcc.gnu.org/bugzilla/sh
with fixed PR26208 we can throw exceptions from signal handlers.
catch() works pretty fine with complex call-chain but fails on
simple testcase.
#include
void signalHandler( int signalNumber )
{
throw 0;
}
int main()
{
signal( SIGSEGV, signalHandler );
try
{
--- Comment #18 from paulthomas2 at wanadoo dot fr 2006-08-31 18:41 ---
Subject: Re: [4.1/4.2 Regression]: fold_convert fails
for Fortran operator
hjl,
>--- Comment #17 from hjl at lucon dot org 2006-08-31 18:28 ---
>The previous gfc_get_derived_type tries to reuse the same
--- Comment #17 from hjl at lucon dot org 2006-08-31 18:28 ---
The previous gfc_get_derived_type tries to reuse the same TREE_TYPE:
/* In a module, if an equal derived type is already available in the
specification block, use its backend declaration and those of its
--- Comment #16 from paulthomas2 at wanadoo dot fr 2006-08-31 18:20 ---
Subject: Re: [4.1/4.2 Regression]: fold_convert fails
for Fortran operator
HJ
Yes, I think that function interfaces in general are of the same
horrible kind.
Thanks
Paul
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-08-31 18:16 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01171.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #15 from hjl at lucon dot org 2006-08-31 18:11 ---
I think the issue may be that gfc_get_derived_type creates a new TREE_TYPE for
the same type when there is an existing one. type1 == type2 no longer
works when type1 and type2 have different memory locations even if they are
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-31 18:09 ---
Confirmed by Janis.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependi
--- Comment #8 from pcarlini at suse dot de 2006-08-31 18:08 ---
Now I know how to fix it...
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|un
--- Comment #14 from hjl at lucon dot org 2006-08-31 18:08 ---
I don't think it is specific to operator. I got the same failure with function:
[EMAIL PROTECTED] wrf-1]$ cat yyy.f90
! { dg-do compile }
! Tests the fix for a further regression caused by the
! fix for PR28788 and posted as
--- Comment #3 from janis at gcc dot gnu dot org 2006-08-31 17:57 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=116276
r116276 | mmitchel | 2006-08-20 23:53:10 + (Sun, 20 Aug 2006)
--
janis at gcc dot gnu dot org c
--- Comment #42 from pinskia at gcc dot gnu dot org 2006-08-31 17:53
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from paulthomas2 at wanadoo dot fr 2006-08-31 17:41 ---
Subject: Re: [4.1/4.2 Regression]: fold_convert fails
for Fortran operator
hjl at lucon dot org wrote:
>--- Comment #12 from hjl at lucon dot org 2006-08-31 16:57 ---
>It also fails with gcc 4.1 revision
--- Comment #41 from sayle at gcc dot gnu dot org 2006-08-31 17:35 ---
Subject: Bug 22313
Author: sayle
Date: Thu Aug 31 17:35:32 2006
New Revision: 116604
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116604
Log:
PR other/22313
* dwarf2out.c (add_fde_cfi): Use
--- Comment #8 from tromey at gcc dot gnu dot org 2006-08-31 17:24 ---
Subject: Bug 28698
Author: tromey
Date: Thu Aug 31 17:23:57 2006
New Revision: 116603
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116603
Log:
PR libgcj/28698:
* libgcj_bc.c (DECLARE_PRIM_TY
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-08-31 16:59
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #12 from hjl at lucon dot org 2006-08-31 16:57 ---
It also fails with gcc 4.1 revision 116602.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-31 16:13 ---
I cannot reproduce this on either a powerpc64-linux-gnu build or a
i686-linux-gnu build.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 16:02 ---
What version of gfortran are you trying to build?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #22 from eweddington at cso dot atmel dot com 2006-08-31 15:41
---
Created an attachment (id=12162)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12162&action=view)
Patch to add a note to the ELF file to notify the difference between old ELF
files and new ELF files wit
--- Comment #21 from eweddington at cso dot atmel dot com 2006-08-31 15:39
---
Created an attachment (id=12161)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12161&action=view)
Patch to select 32 bit DWARF addresses for the AVR target.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #35 from dje at watson dot ibm dot com 2006-08-31 14:23 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
> guenter at roeck-us dot net writes:
guenter> Hmm ... what would be the point ? evlwwsplat copies 32 bit memory
content into
guenter> the upper and
--- Comment #1 from aph at gcc dot gnu dot org 2006-08-31 13:58 ---
-findirect-dispatch doesn't work with Java source. Compile to.class first.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #34 from dje at watson dot ibm dot com 2006-08-31 13:50 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
> guenter at roeck-us dot net writes:
guenter> Hmm ... what would be the point ? evlwwsplat copies 32 bit memory
content into
guenter> the upper and
build of gfortran fails. Configure is
../configure --prefix=/opt/gcc-4_0 --with-gmp=/sw
--enable-languages=fortran,c++
built fails with
[...rwin8.7.1/libgfortran] /usr/local/gcc-4_0/build/./gcc/xgcc
-B/usr/local/gcc-4_0/build/./gcc/ -B/opt/gcc-4_0/i686-apple-darwin8.7.1/bin/
-B/opt/gcc-4_0/i686
--- Comment #1 from tbm at cyrius dot com 2006-08-31 12:30 ---
Created an attachment (id=12160)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12160&action=view)
test case
Testcase from application "xskat".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
ICE/tree check with ftree-vectorize -O2:
(sid)44:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-gcc -ftree-vectorize -O2
-c
xskat-xdial.c
xskat-xdial.c: In function 'di_eigenertisch':
xskat-xdial.c:9694: internal compiler error: tree check: expected class
'constant', have 'declaration' (var_decl)
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-31 11:18 ---
Mine, we want/need to use build_distinct_type_copy instead but other than that
it should be ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-31 11:06 ---
Doing:
Index: init.c
===
--- init.c (revision 116553)
+++ init.c (working copy)
@@ -1628,7 +1628,7 @@ build_new_1 (tree placement, tree type,
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-08-31 11:00
---
(In reply to comment #12)
> So, how's this going for 4.1?
Well a regression was found in 4.2 caused by this patch so I am going to fix
that first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27184
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-31 10:59 ---
Yes this was casued by that patch.
Anyways we do:
1627 /* ??? The middle-end will error on us for building a VLA outside
a
1628 function context. Methinks that's not it's purvey. So we'll
do
16
--- Comment #17 from bkoz at gcc dot gnu dot org 2006-08-31 10:46 ---
Subject: Bug 28671
Author: bkoz
Date: Thu Aug 31 10:45:59 2006
New Revision: 116601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116601
Log:
2006-08-31 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libst
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-08-31 10:34
---
(In reply to comment #10)
> I think this can be closed?
Except we still crash on the 4.1 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
--- Comment #10 from pinskia at physics dot uc dot edu 2006-08-31 10:33
---
Subject: Re: [4.2 regression] ICE with
-ftree-vectorizer-verbose
On Thu, 2006-08-31 at 08:08 +, dorit at il dot ibm dot com wrote:
>
> --- Comment #9 from dorit at il dot ibm dot com 2006-08-
On Thu, 2006-08-31 at 08:08 +, dorit at il dot ibm dot com wrote:
>
> --- Comment #9 from dorit at il dot ibm dot com 2006-08-31 08:08 ---
> I have been unsuccessful in reproducing this problem on a i386-redhat-linux.
I think the failure can only reproduce on x86_64-linux-gnu and I c
--- Comment #4 from tbm at cyrius dot com 2006-08-31 09:55 ---
(In reply to comment #3)
> I almost think it was caused by the patch which fixed PR 27115.
> Martin, can you try a newer gcc 4.1.2 to double check that it is not a
> regression there also?
No, 4.1.2 20060
--- Comment #16 from bkoz at gcc dot gnu dot org 2006-08-31 09:08 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #10 from dorit at il dot ibm dot com 2006-08-31 08:22 ---
I think this can be closed?
(I opened a missed-optimization PR instead - PR28643)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
--- Comment #9 from dorit at il dot ibm dot com 2006-08-31 08:08 ---
I have been unsuccessful in reproducing this problem on a i386-redhat-linux.
I don't get a failure compiling the testcase from comment 8.
I tried to compile the testcase from comment 7 and got the following errors:
g
--- Comment #8 from krebbel at gcc dot gnu dot org 2006-08-31 08:06 ---
Although the bug is latent in gcc 4.0 as well I've applied the patch to 4.1 and
4.2 only. I could not reproduce a failure with gcc 4.0 so I've left it as is
rather than risking new problems.
--
krebbel at gcc dot
--- Comment #7 from krebbel at gcc dot gnu dot org 2006-08-31 07:50 ---
Subject: Bug 24367
Author: krebbel
Date: Thu Aug 31 07:50:19 2006
New Revision: 116600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116600
Log:
2006-08-31 Andreas Krebbel <[EMAIL PROTECTED]>
PR
--- Comment #6 from krebbel at gcc dot gnu dot org 2006-08-31 07:43 ---
Subject: Bug 24367
Author: krebbel
Date: Thu Aug 31 07:43:36 2006
New Revision: 116599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116599
Log:
2006-08-31 Andreas Krebbel <[EMAIL PROTECTED]>
PR
87 matches
Mail list logo
