[Bug c/25559] New: Internal compiler error when specifying vector_size(2)
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 appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: Internal compiler error when specifying vector_size(2) Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: guilhem at kaffe dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25559
[Bug c/25559] Internal compiler error when specifying vector_size(2)
--- 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
[Bug c/25559] Internal compiler error when specifying vector_size(2)
--- 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
[Bug c/25559] [4.0/4.1/4.2 Regression] Internal compiler error when specifying vector_size(2) of int
--- 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: What|Removed |Added Severity|major |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.0.0 4.1.0 4.2.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2005-12-25 14:57:06 date|| Summary|Internal compiler error when|[4.0/4.1/4.2 Regression] |specifying vector_size(2) |Internal compiler error when ||specifying vector_size(2) of ||int Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25559
[Bug bootstrap/23430] --with-comment configure option isn't documented
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23430
[Bug gcov/profile/25560] New: Incorrect path assumptions
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: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov/profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cyberax at elewise dot com GCC build triplet: i686-mingw32 GCC host triplet: i686-mingw32 GCC target triplet: i686-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25560
[Bug gcov/profile/25560] Incorrect path assumptions
--- 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
[Bug gcov/profile/25560] Incorrect path assumptions
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25560
[Bug gcov/profile/17040] GCOV not working properly on Windows platforms
--- 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 CC||cyberax at elewise dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17040
[Bug libfortran/25561] New: Eventually get rid of the Alloc Stream Facility
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 idea is to present an interface that avoids an extra copy when used together with mmap, and the application uses ASF directly instead of read/write. However, Fortran IO follows a traditional read/write model, and thus the buffer copy is still needed in the library. Thus, ASF makes the IO library unnecessarily complex and doesn't improve performance. If ASF would provide any real benefit, it could be implemented in the C library or the kernel, and any program using read/write, including the gfortran IO library, would benefit. -- Summary: Eventually get rid of the Alloc Stream Facility Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: jb at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
[Bug debug/25562] New: [4.1/4.2 Regression] cannot debug VLA local
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
[Bug debug/25562] [4.1/4.2 Regression] cannot debug VLA local
-- 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
[Bug tree-optimization/25563] New: Assembler referenced static variable optimized out (bug in gcc or in code?)
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_one
If it is a wrong code, what is the proper way to handle this situation to force
gcc not to optimize the static variable out completely?
--- test.c -
static short const _mmx_one[] = { 1, 1, 1, 1 };
void mmx_interpolate(unsigned char **ref,
int pitch,
int rounding)
{
int dummy = 0;
short _mmx_rc[4];
register short *rc = _mmx_rc;
_mmx_rc[0] = 1 - rounding;
_mmx_rc[1] = 1 - rounding;
_mmx_rc[2] = 1 - rounding;
_mmx_rc[3] = 1 - rounding;
asm volatile ("movl (%0), %3\n"
"pxor %%mm7, %%mm7\n"
"movq (%3), %%mm0\n"
"movq 1(%3), %%mm1\n"
"movq %%mm0, %%mm2\n"
"movq %%mm1, %%mm3\n"
"punpcklbw %%mm7, %%mm0\n"
"punpcklbw %%mm7, %%mm1\n"
"punpckhbw %%mm7, %%mm2\n"
"punpckhbw %%mm7, %%mm3\n"
"movq %%mm0, %%mm4\n"
"movq %%mm2, %%mm5\n"
"paddw %%mm1, %%mm0\n"
"paddw %%mm3, %%mm2\n"
"paddw (%2), %%mm0\n"
"paddw (%2), %%mm2\n"
"psrlw $1, %%mm2\n"
"psrlw $1, %%mm0\n"
"packuswb %%mm2, %%mm0\n"
"movq (%3, %1), %%mm1\n"
"movq 1(%3, %1), %%mm3\n"
"movq %%mm1, %%mm2\n"
"movq %%mm3, %%mm6\n"
"punpcklbw %%mm7, %%mm1\n"
"punpcklbw %%mm7, %%mm3\n"
"punpckhbw %%mm7, %%mm2\n"
"punpckhbw %%mm7, %%mm6\n"
"paddw %%mm1, %%mm4\n"
"paddw %%mm2, %%mm5\n"
"paddw (%2), %%mm4\n"
"paddw (%2), %%mm5\n"
"paddw %%mm4, %%mm3\n"
"paddw %%mm5, %%mm6\n"
"psrlw $1, %%mm4\n"
"psrlw $1, %%mm5\n"
"paddw " "_mmx_one, %%mm3\n"
"paddw " "_mmx_one, %%mm6\n"
"packuswb %%mm5, %%mm4\n"
"movq 1(%3), %%mm1\n"
"movq %%mm1, %%mm2\n"
"punpcklbw %%mm7, %%mm1\n"
"punpckhbw %%mm7, %%mm2\n"
"paddw %%mm1, %%mm3\n"
"paddw %%mm2, %%mm6\n"
"psrlw $2, %%mm3\n"
"psrlw $2, %%mm6\n"
"packuswb %%mm6, %%mm3\n"
"movl 4(%0), %3\n"
"movq %%mm0, (%3)\n"
"movl 8(%0), %3\n"
"movq %%mm4, (%3)\n"
"movl 12(%0), %3\n"
"movq %%mm3, (%3)\n"
: "=r"(ref), "=r"(pitch), "=r"(rc), "=r"(dummy)
: "0"(ref), "1"(pitch), "2"(rc), "3"(dummy)
: "memory");
}
--
Summary: Assembler referenced static variable optimized out (bug
in gcc or in code?)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drab at kepler dot fjfi dot cvut dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25563
[Bug tree-optimization/25563] Assembler referenced static variable optimized out (bug in gcc or in code?)
--- 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 |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25563
[Bug tree-optimization/25564] New: Assembler referenced static variable optimized out (bug in gcc or in code?)
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_one
If it is a wrong code, what is the proper way to handle this situation to force
gcc not to optimize the static variable out completely?
--- test.c -
static short const _mmx_one[] = { 1, 1, 1, 1 };
void mmx_interpolate(unsigned char **ref,
int pitch,
int rounding)
{
int dummy = 0;
short _mmx_rc[4];
register short *rc = _mmx_rc;
_mmx_rc[0] = 1 - rounding;
_mmx_rc[1] = 1 - rounding;
_mmx_rc[2] = 1 - rounding;
_mmx_rc[3] = 1 - rounding;
asm volatile ("movl (%0), %3\n"
"pxor %%mm7, %%mm7\n"
"movq (%3), %%mm0\n"
"movq 1(%3), %%mm1\n"
"movq %%mm0, %%mm2\n"
"movq %%mm1, %%mm3\n"
"punpcklbw %%mm7, %%mm0\n"
"punpcklbw %%mm7, %%mm1\n"
"punpckhbw %%mm7, %%mm2\n"
"punpckhbw %%mm7, %%mm3\n"
"movq %%mm0, %%mm4\n"
"movq %%mm2, %%mm5\n"
"paddw %%mm1, %%mm0\n"
"paddw %%mm3, %%mm2\n"
"paddw (%2), %%mm0\n"
"paddw (%2), %%mm2\n"
"psrlw $1, %%mm2\n"
"psrlw $1, %%mm0\n"
"packuswb %%mm2, %%mm0\n"
"movq (%3, %1), %%mm1\n"
"movq 1(%3, %1), %%mm3\n"
"movq %%mm1, %%mm2\n"
"movq %%mm3, %%mm6\n"
"punpcklbw %%mm7, %%mm1\n"
"punpcklbw %%mm7, %%mm3\n"
"punpckhbw %%mm7, %%mm2\n"
"punpckhbw %%mm7, %%mm6\n"
"paddw %%mm1, %%mm4\n"
"paddw %%mm2, %%mm5\n"
"paddw (%2), %%mm4\n"
"paddw (%2), %%mm5\n"
"paddw %%mm4, %%mm3\n"
"paddw %%mm5, %%mm6\n"
"psrlw $1, %%mm4\n"
"psrlw $1, %%mm5\n"
"paddw " "_mmx_one, %%mm3\n"
"paddw " "_mmx_one, %%mm6\n"
"packuswb %%mm5, %%mm4\n"
"movq 1(%3), %%mm1\n"
"movq %%mm1, %%mm2\n"
"punpcklbw %%mm7, %%mm1\n"
"punpckhbw %%mm7, %%mm2\n"
"paddw %%mm1, %%mm3\n"
"paddw %%mm2, %%mm6\n"
"psrlw $2, %%mm3\n"
"psrlw $2, %%mm6\n"
"packuswb %%mm6, %%mm3\n"
"movl 4(%0), %3\n"
"movq %%mm0, (%3)\n"
"movl 8(%0), %3\n"
"movq %%mm4, (%3)\n"
"movl 12(%0), %3\n"
"movq %%mm3, (%3)\n"
: "=r"(ref), "=r"(pitch), "=r"(rc), "=r"(dummy)
: "0"(ref), "1"(pitch), "2"(rc), "3"(dummy)
: "memory");
}
--
Summary: Assembler referenced static variable optimized out (bug
in gcc or in code?)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drab at kepler dot fjfi dot cvut dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25564
[Bug tree-optimization/25564] Assembler referenced static variable optimized out (bug in gcc or in code?)
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25564
[Bug tree-optimization/25563] Assembler referenced static variable optimized out (bug in gcc or in code?)
--- 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
[Bug c/25565] New: GCC compiled with --target=powerpcle-*-eabi produces big-endian logic with little-endian ordering
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 imply a
default of little-endian for both byte ordering and logic? Secondary issue is
that the GCC libaries built with --target=poerpcle-*-eabi contain big-endian
logic and so will break with compiled code meant to use -mlittle.
Source:
typedef long long LL;
LL increment(LL x) {
return x+1;
}
Object compiled with "-O2":
:
0: 01 00 84 30 addic r4,r4,1 /* big-endian logic, little-endian
ordering */
4: 94 01 63 7c addze r3,r3
8: 20 00 80 4e blr
Object compiled with "-O2 -mlittle":
:
0: 01 00 63 30 addic r3,r3,1 /* little-endian logic, little-endian
ordering */
4: 94 01 84 7c addze r4,r4
8: 20 00 80 4e blr
Object compiled with "-O2 -mbig":
:
0: 30 84 00 01 addic r4,r4,1 /* big-endian logic, big-endian
ordering */
4: 7c 63 01 94 addze r3,r3
8: 4e 80 00 20 blr
--
Summary: GCC compiled with --target=powerpcle-*-eabi produces
big-endian logic with little-endian ordering
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aweiner at lsil dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25565
[Bug middle-end/25566] New: Variable length types and inlining
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 goes into infinite recursion on a
structure containing a pointer to its own type. If it doesn't,
then the type node for S doesn't get adjusted properly when
F is inlined.
??? This is likely no longer true, but it's too late in the 4.0
cycle to try to find out. This should be checked for 4.1. */
We don't inline functions with variable length types but we should check this
out for 4.1 (but it is too late even for 4.1).
--
Summary: Variable length types and inlining
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization, FIXME
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25566
[Bug middle-end/25566] Variable length types and inlining
--- 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
[Bug middle-end/25566] Variable length types and inlining
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25566
[Bug middle-end/25522] zero-initialized constants are place in .bss
--- 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
[Bug libfortran/25419] gfortran read does not take comma for default on one entry
--- 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 AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-26 06:00:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25419
