I have found this bug when playing a bit with the vector_size attribute. To
reproduce just compile the attached program with
gcc -march=pentium4 runsimd.c
Result:
runsimd.c:1: internal compiler error: in round_up, at fold-const.c:11606
Please submit a full bug report,
with preprocessed source if
--- Comment #1 from guilhem at kaffe dot org 2005-12-25 14:51 ---
Created an attachment (id=10554)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10554&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25559
--- Comment #2 from guilhem at kaffe dot org 2005-12-25 14:52 ---
Changing vector_size(2) to vector_size(4) does not show any problem by the way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25559
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-25 14:57 ---
Reduced testcase:
typedef int __m64 __attribute__ ((vector_size(2)));
This is invalid as int is 4 bytes but you are trying to fit a vector of 2bytes
which is just wrong
--
pinskia at gcc dot gnu dot org changed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|REOPENED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23430
GCOV works incorrectly with the Windows-style paths. There are lots of places
in GCOV where it assumes that '/' is the only path separator.
As a result 'make_gcov_file_name' function will return invalid paths like
"a\b\c.cpp".
--
Summary: Incorrect path assumptions
Product
--- Comment #1 from cyberax at elewise dot com 2005-12-25 16:51 ---
Created an attachment (id=10555)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10555&action=view)
Quick fix
A quick fix for 'make_gcov_file_name'.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25560
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-25 16:57 ---
*** This bug has been marked as a duplicate of 17040 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-25 16:57 ---
*** Bug 25560 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
Currently the gfortran IO library is based on a design called the "Alloc Stream
Facility" (ASF), described in the paper
* "Exploiting the advantages of mapped files for stream I/O",
* O. Krieger, M. Stumm and R. Umrau, "Proceedings of the 1992 Winter
* USENIX conference", p. 27-42.
The ide
Take the following code:
int main(void)
{
int i = 7;
int t[i];
int j;
for(j=0;jhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=25562
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25562
I'm not sure whether it's a bug in gcc or rather a bug in the code. When I
compile the attached code with just "-O0" I get
$ nm test.o | grep _mmx_one
r _mmx_one
but when I compile with "-O1" the variable is probably optimized out and I get
$ nm test.o | grep _mmx_one
U _mmx_on
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-26 00:22 ---
Bug in your code:
the compiler has no way to knowing that _mmx_one is used.
Use the attribute used to fix your code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |
I'm not sure whether it's a bug in gcc or rather a bug in the code. When I
compile the attached code with just "-O0" I get
$ nm test.o | grep _mmx_one
r _mmx_one
but when I compile with "-O1" the variable is probably optimized out and I get
$ nm test.o | grep _mmx_one
U _mmx_on
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-26 00:32 ---
*** This bug has been marked as a duplicate of 25563 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-26 00:32 ---
*** Bug 25564 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25563
I built GCC 4.0.2 with --target=powerpcle-440-eabi. The resulting GCC produces
little-endian objects but with big-endian logic (big-endian register and
load/store usage). I can force the compiler to use little-endian logic by
specifying -mlittle on the command line...but does powerpcle-*-eabi not i
According to the following comment:
/* We cannot inline a function of the form
void F (int i) { struct S { int ar[i]; } s; }
Attempting to do so produces a catch-22.
If walk_tree examines the TYPE_FIELDS chain of RECORD_TYPE/
UNION_TYPE nodes, then it g
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-26 03:58 ---
Oh, forgot to say this comment is in tree-inline.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25566
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25566
--- Comment #5 from drepper at redhat dot com 2005-12-26 05:52 ---
> What happens if you use -fno-common?
In this case the variable gets the index of .bss in the symbol table instead of
using SHN_COMMON.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25522
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-12-26 06:00
---
I have a fix for this already. Patch for submottal soon.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
23 matches
Mail list logo
