Reported by Harald Anlauf:
---
Hi,
the IMPORT statement of Fortran2003 is not yet implemented.
Trying to use it provokes an ICE:
module gfcbug29_import
integer, parameter :: dp = kind (1d0)
interface
subroutine foo (x)
import :: dp
real (kind=dp)
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-05-11 06:08
---
(In reply to comment #7)
FX: Fixing gfortran's error recovery is not the answer to this PR,
but to the other one.
Yes, I know. Since this PR was already used for tracking the ICE, I planned on
opening a new PR
Since GCC 3.4.0 the C++ frontend ICEs on the following invalid code snippet:
int operator=(int);
void foo()
{
operator=(0);
}
bug.cc:1: error: 'int operator=(int)' must be a nonstatic member function
bug.cc: In function 'void foo()':
bug.cc:5:
--- Comment #4 from agner at agner dot org 2006-05-11 07:11 ---
Thanks for confirming this bug. If Gcc relies on the stack being aligned then
it has to be an official ABI requirement.
It makes perfectly sense to compile the whole program, or some of it, with -Os
and also use XMM. -Os
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot
|dot org
--- Comment #3 from patchapp at dberlin dot org 2006-05-11 07:15 ---
Subject: Bug number PR27384
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-05/msg00443.html
--
--- Comment #3 from patchapp at dberlin dot org 2006-05-11 07:15 ---
Subject: Bug number PR27488
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-05/msg00444.html
--
--- Comment #1 from patchapp at dberlin dot org 2006-05-11 07:16 ---
Subject: Bug number PR c++/27547
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-05/msg00445.html
--
--- Comment #3 from kazu at gcc dot gnu dot org 2006-05-11 07:31 ---
Some analysis at:
http://gcc.gnu.org/ml/gcc/2006-05/msg00263.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27505
--- Comment #7 from tbm at cyrius dot com 2006-05-11 08:22 ---
While the test case submitted to this PR indeed works now, the software program
which originally showed the bug shows that it's still there. Here's a new test
case.
--
tbm at cyrius dot com changed:
What
--- Comment #8 from tbm at cyrius dot com 2006-05-11 08:24 ---
Created an attachment (id=11438)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11438action=view)
new test case
1657:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O1 mini.c
Conflict NewMins$maxdex_407(ab)
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-11 08:26 ---
The orginal problem is fixed and Martin is opening a new bug for the other
issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I get a SSA corruption ICE with the following test case. This is not the same
as PR27283 which I originally submitted: the test case from the previous bug
indeed works now, but the original software package still ICEs. Here's a test
case that still procudes an ICE.
gcc version 4.2.0 20060508
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-11 08:30 ---
Subject: Bug 27529
Author: rguenth
Date: Thu May 11 08:29:40 2006
New Revision: 113692
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113692
Log:
2006-05-11 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-05-11 08:30 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #10 from tbm at cyrius dot com 2006-05-11 08:30 ---
See PR27548 for the new one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27283
--- Comment #1 from tbm at cyrius dot com 2006-05-11 08:31 ---
Created an attachment (id=11439)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11439action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
typedef __SIZE_TYPE__ size_t;
struct E
{
virtual ~E () {}
virtual size_t e () const = 0;
virtual void f (char *x) const = 0;
};
struct F : public E
{
virtual ~F () {}
virtual size_t e () const { return 0; }
virtual void f (char *x) const { *x = '\0'; }
};
struct S
{
S () { a = new
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-11 08:44 ---
The good news is that IV-OPTs is not the cause.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-11 08:48 ---
This worked in 4.1.0 20060208 and in 4.1.0 20051026.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27549
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-11 08:50 ---
Does the patch for PR 27283 fix this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27549
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-11 08:56 ---
Reduced testcase:
double zero;
double matmul_c8 (_Complex double * dest)
{
*dest += 1;
return zero;
}
we go from before cplxlower
matmul_c8 (dest)
{
double D.1526;
complex double D.1525;
complex double
--- Comment #3 from schwab at suse dot de 2006-05-11 09:03 ---
(gdb) bt
#0 fancy_abort (file=0x10849bb8 ../../gcc/emit-rtl.c, line=1784,
function=0x10849954 change_address_1) at ../../gcc/diagnostic.c:642
#1 0x103d975c in change_address_1 (memref=0xf7976af0, mode=BLKmode,
typedef __SIZE_TYPE__ size_t;
struct E
{
virtual ~E () {}
virtual size_t e () const = 0;
virtual void f (char *x) const = 0;
};
struct F : public E
{
virtual ~F () {}
virtual size_t e () const { return 0; }
virtual void f (char *x) const { *x = '\0'; }
};
struct S
{
S () { a = new
typedef __SIZE_TYPE__ size_t;
struct E
{
virtual ~E () {}
virtual size_t e () const = 0;
virtual void f (char *x) const = 0;
};
struct F : public E
{
virtual ~F () {}
virtual size_t e () const { return 0; }
virtual void f (char *x) const { *x = '\0'; }
};
struct S
{
S () { a = new
--- Comment #1 from jakub at gcc dot gnu dot org 2006-05-11 09:06 ---
Oops, sorry.
*** This bug has been marked as a duplicate of 27549 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2006-05-11 09:06 ---
*** Bug 27550 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27549
--- Comment #1 from jakub at gcc dot gnu dot org 2006-05-11 09:06 ---
Oops, sorry.
*** This bug has been marked as a duplicate of 27549 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2006-05-11 09:06 ---
*** Bug 27551 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27549
--- Comment #5 from jakub at gcc dot gnu dot org 2006-05-11 09:07 ---
Yes, PR 27283 patch fixes this. So, we need it on gcc-4_1-branch too...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27549
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-11 09:22 ---
This is a SCCP issue:
--- t.cc.073t.lim 2006-05-11 02:21:50.0 -0700
+++ t.cc.075t.sccp 2006-05-11 02:21:50.0 -0700
@@ -53,8 +53,8 @@ void f(int) (to_be_zapped)
L16:;
goto bb 6 (L7);
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-11 09:23 ---
Oh, note with my reduced testcase you have to compile with -fno-ivopts.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27548
--- Comment #1 from paul dot richard dot thomas at cea dot fr 2006-05-11
10:22 ---
The following patch fixes this bug. It makes use of existing calls to
gfc_resolve_expr, whilst resolving specification expressions, to check that
variables used are parameters of each and every entry.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #19 from tbm at cyrius dot com 2006-05-11 11:03 ---
(In reply to comment #17)
Created an attachment (id=11336)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11336action=view) [edit]
Possible patch
Maybe. there is a work around I have an initial patch for. It
--- Comment #9 from tbm at cyrius dot com 2006-05-11 11:05 ---
(In reply to comment #8)
4.1.0 is correct as it is the same as 3.4.x. 4.0.x is incorrect and does not
correspond to 3.4.x. So this is a bug in 4.0.x and not in 4.1.0.
Confirmed. Thanks for the short testcase.
Do you
The following testcases encounter an ICE when compiled with -fdump-parse-tree:
hollerith2.f90, hollerith4.f90, hollerith_f95.f90 and hollerith_legacy.f90 (in
the gfortran.dg testsuite directory)
(I've been compiling the whole testsuite with -fdump-parse-tree to isolate
potential problems with
label_2.f90, from the testsuite, encounters an ICE when compiled with -Wall:
$ cat src/label_2.f90
! { dg-do compile }
! PR fortran/24640. We needed to check that whitespace follows
! a statement label in free form.
!
program pr24640
10: a=10 ! { dg-error character in statement }
end
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-05-11 11:36
---
File entry-4.f90 from the gfortran testsuite also ICEs with -ff2c:
$ gfortran -c entry_4.f90 -ff2c
src/entry_4.f90: In function f2:
src/entry_4.f90:12: internal compiler error: in make_decl_rtl, at
I found an other bug in gfortran now for the Linux distribution only.
You must be able to link the gfortran libraries static or linked.
For the linked *.so no problem
For the static *.a it did not work and at the compilation time.
To force the linker to compile the gfortran libraries static and
Humpf, that one is scary... can't even think of what to put as a Summary :)
$ cat abs_complex.f90
real x
x = abs(x)
call foo(abs)
end
$ ./bin/gfortran abs_complex.f90 -c
/tmp/ccdGqqDj.s: Assembler messages:
/tmp/ccdGqqDj.s:14: Error: junk `(intrinsic)__abs' after expression
Indeed, the
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-05-11
14:02 ---
The patch is simple:
12.5.2.6 RETURN statement
R1226 return-stmt is RETURN [ scalar-int-expr ]
The int-expr part is implemented in resolve.c(resolve_code); a further
condition has been imposed to
--- Comment #16 from sayle at gcc dot gnu dot org 2006-05-11 14:17 ---
Subject: Bug 27158
Author: sayle
Date: Thu May 11 14:17:19 2006
New Revision: 113695
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113695
Log:
PR target/27158
* reload.c
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-05-11 14:19 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00463.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
I found a bug in gcc compiler. I'm trying to cross compile simple program using
debian package avr-gcc (gcc version 4.1.0) using command
avr-gcc -mmcu=attiny2313 -Wall -Os -c test.c
I have problem with very simple code when using array bigger than 128 bytes.
char text[] = AB... YZ; // 128
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-05-11 14:41
---
Subject: Bug 27547
Author: reichelt
Date: Thu May 11 14:41:03 2006
New Revision: 113696
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113696
Log:
PR c++/27547
* decl.c (copy_fn_p): Return
Compiling the fragment
struct A {
A() {}
};
extern A a;
#pragma omp threadprivate(a)
A a;
with svn from yesterday yields
LANG=C g++-4.2 -fopenmp -c x.cpp -o x.o
x.cpp:6: error: 'a' cannot be thread-local because it has non-POD type 'A'
x.cpp:6: error: 'a' is thread-local and so cannot be
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-05-11 14:46
---
Subject: Bug 27547
Author: reichelt
Date: Thu May 11 14:45:56 2006
New Revision: 113697
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113697
Log:
PR c++/27547
* decl.c (copy_fn_p): Return
Compiling this code:
#include stdio.h
void f(char* line) {
char test_char[40];
sscanf(line, %s, test_char);
}
gives the following warning:
warning: format '%s' expects type 'char *', but argument 3 has type 'char
(*)[39u]'
I'd have though that test_char had type char (*)[40].
--
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-11 14:49
---
Subject: Bug 27547
Author: reichelt
Date: Thu May 11 14:49:17 2006
New Revision: 113698
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113698
Log:
PR c++/27547
* decl.c (copy_fn_p): Return
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-05-11 14:53
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-11 14:59
---
Subject: Bug 27488
Author: reichelt
Date: Thu May 11 14:58:54 2006
New Revision: 113699
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113699
Log:
PR middle-end/27488
* fold-const.c
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-05-11 15:01
---
Subject: Bug 27488
Author: reichelt
Date: Thu May 11 15:01:40 2006
New Revision: 113700
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113700
Log:
PR middle-end/27488
* fold-const.c
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-05-11 15:02
---
Fixed on mainline and 4.1 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-11 15:07 ---
That's not a complete testcase, which we need to reproduce/fix the bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-11 15:08
---
Subject: Bug 27384
Author: reichelt
Date: Thu May 11 15:07:45 2006
New Revision: 113701
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113701
Log:
PR middle-end/27384
* fold-const.c
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-05-11 15:12
---
Subject: Bug 27384
Author: reichelt
Date: Thu May 11 15:11:50 2006
New Revision: 113702
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113702
Log:
PR middle-end/27384
* fold-const.c
--- Comment #4 from dje at gcc dot gnu dot org 2006-05-11 15:13 ---
It looks like something in exception handling is creating a new object very
late, after reload, and the new address is not validized before being handed to
replace_equiv_address().
Should
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-05-11 15:17
---
Subject: Bug 27384
Author: reichelt
Date: Thu May 11 15:16:49 2006
New Revision: 113703
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113703
Log:
PR middle-end/27384
* fold-const.c
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-05-11 15:17
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
The following testcase ICEs on mainline:
===
struct A
{
templatetypename T
static void* operator new(T) {}
};
===
bug.cc:4: error: 'operator new' takes type 'size_t' ('long unsigned int') as
first parameter
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-05-11 15:35
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Compiling this file, with mainline, gcc 4.0, or 4.1
templatetypename t void f(t a) { }
void g() { enum e { v }; f(v); }
gives this error message:
foo.cc: In function void g():
foo.cc:2: error: no matching function for call to f(g()::e)
If the enum definition is moved out of the function,
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-05-11
15:54 ---
I think what is happening is that lbound's type is becoming a scalar and not
an array with size of 1.
I believe that I fixed this with either the bounds scalarization patch or some
of the work on
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-11 15:55 ---
I cannot reproduce this in 4.1.0 20060208 or 4.2.0 20060507.
t.c:5: warning: format '%s' expects type 'char *', but argument 3 has type
'char (*)[40]'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27558
--- Comment #5 from richard at codesourcery dot com 2006-05-11 15:56
---
Subject: Re: [4.2 Regression] -fsection-anchors breaks Ada
dje at gcc dot gnu dot org [EMAIL PROTECTED] writes:
It looks like something in exception handling is creating a new object
very late, after reload,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-11 15:58 ---
This is not valid, the type is a local type which causes it be rejected for
templates. The same happens with local classes.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-11 16:07 ---
14.3.1/2
A local type, a type with no linkage, an unnamed type or a type compounded from
any of these types shall
not be used as atemplate-argument for a template type-parameter.
--
--- Comment #6 from schwab at suse dot de 2006-05-11 16:08 ---
addr_expr 0xf7f78680
type pointer_type 0xf7ede888 gnat__os_lib__copy_file__A25b
type record_type 0xf7ed9bc8 exception sizes-gimplified asm_written BLK
size integer_cst 0xf7ed7b80 constant invariant
--- Comment #28 from perry at kundert dot ca 2006-05-11 16:12 ---
This test case *still* exhibits the failure using only g++ 3.3.6, and binutils
2.16.1:
[EMAIL PROTECTED]:binutils-bug$ apt-show-versions g++-3.3
g++-3.3/testing uptodate 1:3.3.6-13
[EMAIL PROTECTED]:binutils-bug$
--- Comment #29 from pinskia at gcc dot gnu dot org 2006-05-11 16:16
---
(In reply to comment #28)
This test case *still* exhibits the failure using only g++ 3.3.6, and binutils
2.16.1:
Well 3.3.x is no longer being updated (likewise for 3.4.x).
--
--- Comment #7 from richard at codesourcery dot com 2006-05-11 16:18
---
Subject: Re: [4.2 Regression] -fsection-anchors breaks Ada
Thanks Andreas. I might be barking up the wrong tree here, but it seems
odd to me is that output_ttype is using expand_normal () to expand this
tree.
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-05-11 16:19
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from gdr at integrable-solutions dot net 2006-05-11 16:24
---
Subject: Re: New: template function not recognized when invoked with enum
defined in function
ian at airs dot com [EMAIL PROTECTED] writes:
| Compiling this file, with mainline, gcc 4.0, or 4.1
|
|
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-05-11 16:32
---
Subject: Bug 27421
Author: reichelt
Date: Thu May 11 16:32:20 2006
New Revision: 113705
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113705
Log:
PR target/27421
* config/i386/i386.c
--- Comment #4 from gdr at gcc dot gnu dot org 2006-05-11 16:33 ---
See
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#488
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1945.pdf
The later paper is under active consideration.
The PR should be suspended,
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-05-11 16:34
---
Subject: Bug 27421
Author: reichelt
Date: Thu May 11 16:34:39 2006
New Revision: 113706
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=113706
Log:
PR target/27421
* config/i386/i386.c
--- Comment #10 from reichelt at gcc dot gnu dot org 2006-05-11 16:35
---
Now also fixed on 4.1 branch and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-11 16:38 ---
(In reply to comment #4)
The PR should be suspended, instead of being hastly closed.
It was not hastly closed, the current standard says this is invalid.
Anyways there is already a PR open about DR 488.
*** This
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-05-11 16:38
---
*** Bug 27560 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from gdr at integrable-solutions dot net 2006-05-11 16:47
---
Subject: Re: template function not recognized when invoked with enum defined
in function
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| It was not hastly closed, the current standard says this
--- Comment #6 from halcy0n at gentoo dot org 2006-05-11 17:01 ---
You can't build with objc-gc at all right now since only half of these patches
were applied. It tries to use the internal boehm-gc, but that hasn't been
built yet since the patch in the first email was never applied.
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-11 17:08
---
I think this is taken care of by the following patch:
Index: dump-parse-tree.c
===
--- dump-parse-tree.c (revision 113671)
+++ dump-parse-tree.c
The i386-pc-mingw32 version errors incorrectly on this program fragment -
[EMAIL PROTECTED] /d/Docume~1/rantad/mydocu~1/tests
$ gfortran -c eps.f90
In file eps.f90:10
xmax1 = min ( xx, ONE / epsilon ( xx ) )
1
Error: Division by zero at (1)
[EMAIL
--- Comment #8 from roger at eyesopen dot com 2006-05-11 17:22 ---
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00472.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26600
--- Comment #2 from daney at gcc dot gnu dot org 2006-05-11 17:54 ---
Test case committed as:
* testsuite/libjava.compile/PR20418.java: New.
* testsuite/libjava.compile/PR20418.xfail: New.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20418
--- Comment #1 from daney at gcc dot gnu dot org 2006-05-11 17:55 ---
New testcase for this problme is testsuite/libjava.compile/PR20418.java
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24128
GCC provides the programmer the ability to use SIMD instructions by primitives.
These are defined in header files. Unfortunately, GCC follows Intel compiler
conventions. But these conventions, dictated by Intel interests, not always
reflect correctly the reality, specially of AMD processors.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-11 18:37 ---
Which Athlon processor, there are so many and some support full SSE2 also (K8).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ramon dot garcia dot f+gcc at gmail dot com 2006-05-11
18:42 ---
That is correct. However for those developerers that want to target the
existing installed base of Pentium IV and Athlon processors, a set of flags and
headers that provide the common subset of them is
--- Comment #1 from kazu at gcc dot gnu dot org 2006-05-11 18:44 ---
Just for a reference, here is execute/20030128-1.c.
unsigned char x = 50;
volatile short y = -5;
int main ()
{
x /= y;
if (x != (unsigned char) -10)
abort ();
exit (0);
}
Now, with -O1, the load of y
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-11 18:45 ---
Have you tried using the -march=athlon options (where is replaced with
your CPU type)?
Also do you have a list of instructions which supported on which Athlon?
--
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-05-11 18:46
---
The ICE is due to -Wunused-labels. We try to issue a warning about the label
(already marked as an error because it contains a non-numeric character) being
unused, but said label has no locus (because the parser
--- Comment #2 from kazu at gcc dot gnu dot org 2006-05-11 18:54 ---
Here is a reduced testcase.
volatile short y;
int
foo (void)
{
return y;
}
With -O1, this function magically turns into return 0; like so
foo:
@ Function supports interworking.
@ args = 0, pretend
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2006-05-11 19:23 ---
Subject: Re: Testsuite ICE with -Wunused-labels
On Thu, May 11, 2006 at 06:46:22PM -, fxcoudert at gcc dot gnu dot org
wrote:
The ICE is due to -Wunused-labels. We try to issue a warning
--- Comment #3 from kazu at gcc dot gnu dot org 2006-05-11 19:40 ---
The combiner combines
=== i1 ===
(insn 10 8 11 2 (set (reg/f:SI 103)
(symbol_ref:SI (y) var_decl 0xf7f71de0 y)) 145 {*arm_movsi_insn}
(nil)
(nil))
=== i2 ===
(insn 11 10 13 2 (set (reg:SI 105 [ y ])
--- Comment #4 from kazu at gcc dot gnu dot org 2006-05-11 20:36 ---
I just confirmed that 4.1 generates correct code with -O1,
so this is a regression.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-05-11 20:58
---
Patched formally submitted for review on the ml:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00485.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Many GCC tests such as gcc.c-torture/compile/simd-3.c fail on
powerpc-none-eabispe with an ICE in assign_stack_temp_for_type. This happens
with trunk and 4.1 branch but not with 4.0 branch. Reduced testcase:
typedef double V __attribute__((vector_size (16)));
void f(void)
{
volatile V t = {
1 - 100 of 130 matches
Mail list logo
