--- Additional Comments From uros at kss-loka dot si 2005-06-22 06:08
---
Uh, it was a cut-n-pasto...
--
What|Removed |Added
URL|
--- Additional Comments From uros at kss-loka dot si 2005-06-22 07:02
---
As this bug is getting a bit confused, I have summarised testcases below:
--cut here--
#include mmintrin.h
__m64 moo_1 (int i)
{
__m64 tmp = _mm_cvtsi32_si64 (i);
return tmp;
}
__m64 moo_2 (__m64 mmx1)
{
--- Additional Comments From uros at kss-loka dot si 2005-06-22 10:14
---
Just for fun, I have compiled the testcase with MMX/x87 mode switching patch
included, to check MMX vector extensions. This little patch is needed to enable
MMX vector extensions (only MMX vector add expander is
In the attached example, the store of type_t is not optimized by gcc. Instead
of storing one 32-bit value, four 8-bit values are stored.
gcc-4.0.1 produces the following code:
/home/fm3/foo.c:16
80483b7: c6 05 13 96 04 08 04movb $0x4,0x8049613
80483be: c6 05 12 96 04
--- Additional Comments From hubicka at ucw dot cz 2005-06-22 11:12 ---
Subject: Re: [4.1 Regression] -ftree-vectorize ICE get_loop_body, at
cfgloop.c:819
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21
12:51 ---
Hmm, reconfirmed, then.
Strange,
Another corner case of eoshift that's not correct...
in eoshift3, this time.
$ cat eoshift.f90
program main
implicit none
integer, dimension (3,3) :: a, b, w
integer, dimension (3) :: bo, sh
integer :: i,j
a = reshape((/(i,i=1,9)/),shape(a))
sh = (/ 3, -1, -3 /)
bo = (/-999, -99,
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-22
11:41 ---
This can be made to fail on any architecture by increasing
the amount of shifting:
$ cat eoshift-really-fails.f90
program main
character(len=20) line
write (line,'(I4)') eoshift((/1, 3/), 1000)
end
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-22
11:42 ---
This is a duplicate of 21592. The problem is that
we are really running off the end here, as Andrew suggested.
*** This bug has been marked as a duplicate of 21592 ***
--
What|Removed
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-22
11:42 ---
*** Bug 22124 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
12:07 ---
Patch was posted here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01764.html
--
What|Removed |Added
$ cat shift-kind.f90
program main
implicit none
integer, dimension (3,3) :: a, b, w
integer(kind=2), dimension (3) :: sh2
integer(kind=1), dimension (3) :: sh1
integer, dimension(3) :: bo
integer :: i,j
a = reshape((/(i,i=1,9)/),shape(a))
sh1 = (/ -3, -1, 3 /)
sh2 = (/ -3, -1, 3
$ cat cshift-alloc.f90
program main
implicit none
integer, dimension (:,:),allocatable :: a
integer, dimension (3) :: sh
integer :: i
allocate (a(3,3))
a = reshape((/(i,i=1,9)/),shape(a))
sh = (/ 2, -1, -2 /)
write(*,fmt='(10I5)') cshift(a, shift=sh)
end program main
$ gfortran
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
13:07 ---
Reduced testcase for the regression:
typedef struct type
{
char a;
char b;
char c;
char d;
} type_t;
type_t u;
void
f(void)
{
u = (type_t){ 1, 2, 3, 4};
}
3.3 produced:
lis r0,0x102
For Obj-C++, /usr/include/objc/objc-runtime.h contains
Class class;
which will not work with Obj-C++ at all.
This causes testsuite failures and causes you not to be able to compile almost
any obj-C++ program.
--
Summary: /usr/include/objc/objc-runtime.h on
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
13:37 ---
I committed the patch to the mainline after testing and will commit to the 4.0
branch once reopened so
mine.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-22
13:38 ---
Subject: Bug 20593
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-22 13:38:25
Modified files:
gcc: ChangeLog varasm.c
Log message:
--- Additional Comments From bangerth at dealii dot org 2005-06-22 14:09
---
Um, Thomas, PR 21592 which you claim this is a duplicate of, is a C++ front
end bug. Did you mean that?
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22124
--- Additional Comments From denis dot nagorny at intel dot com 2005-06-22
14:34 ---
Ok. It seems like this issue is mostly fixed now. I incresead NIT counter up
to 200 and obtained following results:
3.4.2 ~ 3.4s
old 4.0 ~ 6.4s
mainline ~ 4.0s
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
14:37 ---
I think this is the normal register pressure issue in GCC's RA.
See http://www.gccsummit.org/2005/view_abstract.php?content_key=1 for a
discussion which will
happen later today.
--
What
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-22
15:34 ---
Subject: Bug 21034
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-06-22 15:34:02
Modified files:
gcc/fortran: ChangeLog symbol.c
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-06-22
16:00 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From osv at javad dot ru 2005-06-22 16:00 ---
Reproducible on 4.1.0 (mainline) by adding -ffast-math to the command-line:
$ ppc-eabi-gcc -v -msdata=default -ffast-math -c test.cc -o test.o
Using built-in specs.
Target: ppc-eabi
Configured with:
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-22
16:03 ---
What about 4.0? Right now, we've been trying to keep all patches applied on both
branches. Doesn't this bug happen on 4.0 too?
--
What|Removed |Added
--
What|Removed |Added
GCC build triplet|i686-pc-linux-gnu |
GCC host triplet|i686-pc-linux-gnu |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571
--
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571
--- Additional Comments From marcus at jet dot franken dot de 2005-06-22
17:26 ---
gcc-Version 4.1.0 20050622 (experimental)
../BIN/bin/gcc -ftree-vectorize -O2 -c ~/thread.i
/home/marcus/thread.i: In function 'f':
/home/marcus/thread.i:2: internal compiler error: in get_loop_body
$ cat gfortranbug.f90
module buggy
contains
elemental subroutine foo(a)
integer, intent(out) :: a
a = 0
end subroutine foo
subroutine bar()
integer :: a(10)
call foo(a)
end subroutine bar
end module buggy
$ gfortran41 -c gfortranbug.f90
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
17:52 ---
Confirmed. here is the backtrace:
#0 0x080a7931 in gfc_conv_function_call (se=0xbfe81c08, sym=0xa52cf80,
arg=0xa52d5b8)
at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/trans-expr.c:1287
#1
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 17:59
---
I am running into this as well. Turning off all optimizations (-O0) allows
compilation, anything over -O1 hits it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071
The following code ICEs:
// Line 1
class A {
public:
A() { };
~A() { };
};
class B {
public:
B();
B(const A a) { };
~B();
};
template typename X class T;
template typename X, typename Y
TX* func(TY* p);
template typename X class T {
X*m_;
public:
T(X* x) : m_(x) { };
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147
The following FAILs have appeared on ia64-hpux (both -milp32 and -mlp64) on
mainline on 20050622. gcc-testresults shows them also on ia64-linux.
FAIL: gcc.dg/vect/vect-reduc-1char.c (test for excess errors)
FAIL: gcc.dg/vect/vect-reduc-1.c (test for excess errors)
The first is a new test
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 18:17
---
I'd like to move this to gcc-4_0-branch.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Keywords|
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-06-22
18:51 ---
Reopening until 4.0 is unforzen and the patch applied there
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot
|dot org |org
Status|REOPENED
--
What|Removed |Added
Keywords||ice-on-valid-code
Summary|internal compiler error: in |[4.0 only] internal compiler
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-22
18:54 ---
Subject: Re: [4.1 regression] ICE in
first_vi_for_offset, at tree-ssa-structalias.c:2506
On Wed, 2005-06-22 at 17:59 +, bkoz at gcc dot gnu dot org wrote:
--- Additional Comments From
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 18:59
---
Ah, the old can't find the tunnel at the end of the bridge at the end of this
hole problem. Bummer. I hate it when that happens.
Is there an easier way than -O0 to revert back to the old behavior?
--
I notice that program1 (the 1st program attached below) fails to compile, but
very similar programs 2 and 3 (attached further below) do. The only difference
being related to how the non-type template parameter is declared void (*FOOBAR)
() vs void FOOBAR () vs void (FOOBAR) ().
Implementation not complete
--
Summary: BasicTreeUI Implementation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: SWING
AssignedTo: langel at redhat dot com
On Jun 22, 2005, at 2:59 PM, bkoz at gcc dot gnu dot org wrote:
--- Additional Comments From bkoz at gcc dot gnu dot org
2005-06-22 18:59 ---
Ah, the old can't find the tunnel at the end of the bridge at the end
of this
hole problem. Bummer. I hate it when that happens.
Is
--- Additional Comments From pinskia at physics dot uc dot edu 2005-06-22
19:02 ---
Subject: Re: [4.1 regression] ICE in first_vi_for_offset, at
tree-ssa-structalias.c:2506
On Jun 22, 2005, at 2:59 PM, bkoz at gcc dot gnu dot org wrote:
--- Additional Comments From bkoz at
--- Additional Comments From langel at redhat dot com 2005-06-22 19:06
---
I am working on this!
--
What|Removed |Added
Status|UNCONFIRMED
JInternalFrame causes OutOfMemory error when maximized.
Run the test case below, maximize the JInternalFrame, wait a while. OutOfMemory
error.
When the JInternalFrame is positioned at (10,10) rather than (60,60) the error
doesn't occur.
==TEST CASE==
import java.awt.*;
import javax.swing.*;
--
What|Removed |Added
Known to fail||2.95.3 3.0.4 3.2.3 3.3.3
||3.4.0 4.0.0 4.1.0
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-22
19:23 ---
Subject: Re: [4.1 regression] ICE in
first_vi_for_offset, at tree-ssa-structalias.c:2506
On Wed, 2005-06-22 at 19:02 +, pinskia at physics dot uc dot edu
wrote:
--- Additional Comments
--- Additional Comments From mark at codesourcery dot com 2005-06-22 19:46
---
Subject: Re: [4.0 Regression] libstdc++ abi_check
bkoz at gcc dot gnu dot org wrote:
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22
18:17 ---
I'd like to move this to
In the following trivial test case, gcc-4.1 produces very ineffecient code for
the loop. gcc-3.3 produces
much better code.
typedef int __m64 __attribute__ ((__vector_size__ (8)));
__m64 unsigned_add3( const __m64 *a, const __m64 *b, unsigned long count )
{
__m64 sum;
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 20:13
---
Can somebody do a binary search and find out what patch or patches broke this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
20:16 ---
This is a MMX builtin and not a SSE builtin.
--
What|Removed |Added
GCC build
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-22
20:18 ---
(In reply to comment #3)
Um, Thomas, PR 21592 which you claim this is a duplicate of, is a C++ front
end bug. Did you mean that?
No, I meant 21594.
Thomas
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
20:26 ---
This comes down to PR 14552 and PR 19161. Since this is MMX code, it is very
hard to get correct as
GCC does not currently output emms and vector code without you doing it which
is what PR 19161 is
--
What|Removed |Added
OtherBugsDependingO||22152
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22076
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
20:27 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
20:29 ---
(In reply to comment #11)
Can somebody do a binary search and find out what patch or patches broke this?
No need to as it is obvious what caused it as the person who caused it already
commented on this,
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-22
20:47 ---
Subject: Bug 22111
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-06-22 20:39:41
Modified files:
libstdc++-v3 :
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-22
20:49 ---
Subject: Bug 17383
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-06-22 20:42:06
Modified files:
. :
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-22
20:50 ---
Subject: Re: [4.1 regression] ICE in
first_vi_for_offset, at tree-ssa-structalias.c:2506
On Wed, 2005-06-22 at 20:13 +, bkoz at gcc dot gnu dot org wrote:
--- Additional Comments From
--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-22
20:53 ---
Fixed
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From mark at gcc dot gnu dot org 2005-06-22 21:29
---
This seems to have been fixed in GNU Classpath by Sven de Marothy.
http://fitzsim.org/blog/?p=5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19840
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-22
21:41 ---
Confirmed. Reduced testcase:
templatetypename struct A;
templatetypename T void foo(AT* p) { *p; }
templatetypename struct A
{
friend void fooclass
Since GCC 3.4.0 we get an ICE on the following invalid code snippet:
===
templateint void foo();
templateint struct A
{
template friend void foo0();
};
===
bug.cc:5: error: invalid explicit specialization before ''
--- Additional Comments From guardia at sympatico dot ca 2005-06-22 21:59
---
Yup, excited, today, I just compiled the mainbranch to check this out
(gcc-4.1-20050618) and it seems to be fixed! I don't see any strange movlps in
any of the code I tried to compile with it. Can be moved to
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
22:10 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22
22:17 ---
Fixed.
--
What|Removed |Added
Status|WAITING |RESOLVED
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-22
22:34 ---
Fixed in gcc 4.0.1 and mainline by the new .po file.
--
What|Removed |Added
--- Additional Comments From guardia at sympatico dot ca 2005-06-22 22:59
---
Thanks to Uros and everybody!
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23
00:21 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23
01:19 ---
(In reply to comment #5)
Here's the same thing with overloaded functions, causing a wrong-code error.
If the last definition of
'bar' is commented out, the testcase passes, but otherwise not.
That
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23
01:27 ---
(In reply to comment #6)
(In reply to comment #5)
Here's the same thing with overloaded functions, causing a wrong-code
error. If the last definition
of
'bar' is commented out, the testcase
--- Additional Comments From bangerth at dealii dot org 2005-06-23 02:45
---
Is this really valid? class Y is undeclared at the point of the friend
declaration...
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23
03:47 ---
(In reply to comment #7)
-
template typename struct X {
enum { N = 10 };
int items[N+1];
};
template typename A, typename B
The following should compile according to this DR report (but it is only in
ready state so I am going to
confirm it and then suspend it):
class a {};
typename ::a f();
Also the following should not compile as a is not qualified then:
class a {};
typename a f();
--
Summary: [DR 382]
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23
04:27 ---
Confirmed, to ...
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23
04:28 ---
Suspend this as it only in the ready state.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22154
I get an ICE for gcc 4.0.0 when trying to use mudflap and libstdc++ debug mode
together; This is the smallest testcase I could make:
test.cc:
#include vector
struct S { unsigned i; };
void g(const unsigned u, std::vectorunsigned s);
void f(const S s) {
std::vectorstd::vectorunsigned t(1);
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23
04:43 ---
I thought there was a bug about something like this before (and it was fixed
too) but I cannot find it
right now, maybe I am not looking hard enough.
--
--
What|Removed |Added
BugsThisDependsOn||22156
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466
Take the following code:
struct s
{
int i1:1;
int i2:1;
int i3:1;
};
void f(struct s *x, struct s *y) { *x = *y; }
In 3.4.0 (and currently with the C++ compiler too), we were able to get optimal
code:
movl8(%esp), %eax
movl(%eax), %edx
movl4(%esp), %eax
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23
05:04 ---
Note this also effects PPC, though not as badly as there is only one load:
in 3.3.3:
_f:
lwz r0,0(r4)
stw r0,0(r3)
blr
in 4.0.0 and above:
_f:
lwz r11,0(r4)
lwz
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23
05:05 ---
Oh and I thought I saw a bug or two about this before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22154
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23
05:11 ---
The main difference between the C++ front-end and the C front-end in this
respect is how they
repesent bit-fields.
for the C++ front-end we get the following output from SRA:
Cannot scalarize variable
Take the following code:
struct s
{
short t;
short y1;
};
void f(struct s *x, struct s *y)
{
struct s t = *x;
*y = t;
}
In 3.4.0, we produced:
_f:
lwz r0,0(r3)
stw r0,0(r4)
blr
but in 4.0.0 and above:
_f:
lhz r2,2(r3)
lha r0,0(r3)
sth
--
What|Removed |Added
BugsThisDependsOn||22157
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22157
86 matches
Mail list logo
