--- Comment #6 from pault at gcc dot gnu dot org 2008-03-21 08:02 ---
(In reply to comment #5)
Subject: Re: ICE in fold_const.c (fold_convert) when reordering USE
statements
On 4 Sep 2007 19:03:39 -, ubizjak at gmail dot com
[EMAIL PROTECTED] wrote:
and c never generates
--- Comment #2 from pault at gcc dot gnu dot org 2008-03-21 08:05 ---
I'll take this on as relief from memory leaks
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from uros at gcc dot gnu dot org 2008-03-21 09:19 ---
Subject: Bug 34168
Author: uros
Date: Fri Mar 21 09:18:37 2008
New Revision: 133416
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133416
Log:
Backport from mainline:
2008-03-20 Victor Kaplansky
--- Comment #7 from ubizjak at gmail dot com 2008-03-21 09:25 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rurality dot wq at gmail dot com 2008-03-21 09:33
---
I modified the source as below.
It seems that It does not work.
I am not sure whether it is a bug.Or gcc can not treat this situation?
// copy 128 bit one time
#define burst_copy(dst,src,len) {\
__asm__
--- Comment #5 from ubizjak at gmail dot com 2008-03-21 10:17 ---
Inner loop, generated with -O2 -mmmx -fno-strict-aliasing,
gcc version 4.0.2 20051125 (Red Hat 4.0.2-8):
.L45:
movq(%ebx), %mm0
psubw (%ecx), %mm0
movq%mm0, %mm1
psraw $15,
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-03-21 10:20 ---
Last night, I tracked this to resolve.c (resolve_structure_cons), but I was not
100% sure what to do.
With the simplified testcase, Intel complains:
$ ifort pr34813.f90
fortcom: Error: pr34813.f90, line 15: The
--- Comment #36 from ubizjak at gmail dot com 2008-03-21 10:33 ---
(In reply to comment #35)
Also ffmpeg uses almost entirely asm() instead of intrinsics so this alone is
not so much a problem for ffmpeg than it is for others who followed the
recommandition of intrinsics are better
On x86-64 when clamav is compiled with gcc-4.3 -O3, it crashes in mew.c.
Compiling a reduced testcase shows -ftree-vectorize introduces the bug.
This happens only on gcc-4.3, gcc-4.2 and gcc-4.1 work ok with
-O3/-ftree-vectorize.
$ gcc-4.3 -O3 test.i -o fails ./fails
Segmentation fault
$
--- Comment #1 from edwintorok at gmail dot com 2008-03-21 12:42 ---
Created an attachment (id=15353)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15353action=view)
reduced testcase
$ gcc-4.3 -O1 -g -ftree-vectorize test.i -o fails
$ gdb ./fails
GNU gdb 6.7.1-debian
Copyright
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-21 12:49 ---
The warning happens when for example constant propagation tries to optimize
the read from the constant string and calls builtins.c:c_strlen which
produces this warning. As that warning doesn't specify any location
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||3.4.6
Priority|P3 |P2
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-21 13:01 ---
With that approach we'd get
./cc1plus -quiet -O /tmp/t.ii
t.C: In function 'int main()':
t.C:2: warning: offset outside bounds of constant string
thus a single warning still with wrong location information (at
--- Comment #3 from ubizjak at gmail dot com 2008-03-21 13:45 ---
This is due to partial memory access penalty. For TARGET_INTER_UNIT_MOVES, we
can create:
movda(,%eax,4), %xmm0
movq%xmm0, (%esp)
fildll (%esp)
instead of:
movla(,%eax,4),
Compilation of gcc 4.3.0 with the attached script failed on a 64-bit Ubuntu
7.10 server system with the following error message:
[...]
checking how to run the C preprocessor... /lib/cpp
checking whether decimal floating point is supported... yes
checking whether fixed-point is supported... no
--- Comment #1 from bart dot vanassche at gmail dot com 2008-03-21 14:16
---
Created an attachment (id=15354)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15354action=view)
gcc compilation script
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35654
--- Comment #19 from tkoenig at gcc dot gnu dot org 2008-03-21 14:37
---
Subject: Bug 32972
Author: tkoenig
Date: Fri Mar 21 14:37:03 2008
New Revision: 133427
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133427
Log:
2008-03-21 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-21 14:56 ---
You probably fool the vectorizers alignment analysis.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-21 14:57 ---
You need 32bit glibc includes installed or specify --disable-multilib at
configure time.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Hello,
My Operating system is Windows-xp-sp2. I used gcc-3.2.3 to build
cygwin on my machine.
The GCC files are in f:\project\gcc-3.2.3
i created a gcc_build folder in ..project/ and while i was inside that
folder,the cmd used is
$f:/project/gcc-3.2.3/configure
it showed like
configuring
Hi,
I get a Segmentation fault when compiling libgcc2.c for m68hc11.
Rev: 133402
/home/mstein/build/m68hc11-elf/build/./gcc/xgcc
-B/home/mstein/build/m68hc11-elf/build/./gcc/ -nostdinc
-B/home/mstein/build/m68hc11-elf/build/m68hc11-elf/newlib/ -isystem
--- Comment #20 from tkoenig at gcc dot gnu dot org 2008-03-21 15:33
---
Subject: Bug 32972
Author: tkoenig
Date: Fri Mar 21 15:33:13 2008
New Revision: 133428
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133428
Log:
2008-03-21 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #1 from andreasmeier80 at gmx dot de 2008-03-21 16:07 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01158.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35440
--- Comment #2 from andreasmeier80 at gmx dot de 2008-03-21 16:08 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01158.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35332
sort.cxx:
=
#include algorithm
#include vector
void
foo()
{
std::vectorint v;
std::stable_sort(v.begin(), v.end());
}
===
% gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /disks/arlene/gnu/gcc-4.3.0/configure
--- Comment #1 from Andrew_Pollard at amat dot com 2008-03-21 17:04 ---
Created an attachment (id=15355)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15355action=view)
Full errors from compilation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35656
--- Comment #2 from kmccarty at debian dot org 2008-03-21 17:06 ---
Hi gfortran developers,
I can confirm that this ICE still happens on arm with gfortran 4.3 rc2 [*], and
with the optimization reduced to -O2 (-funroll-loops -O1 is OK, as is -O3
without -funroll-loops).
[*] This is on
--- Comment #8 from mmitchel at gcc dot gnu dot org 2008-03-21 17:19
---
Greg --
I'm sorry it's taken me so long to comment on this issue. I've been traveling
for most of the time since you reported this issue.
The change in driver behavior is intentional. Using the sysroot flags
ix86_function_arg_boundary returns PARM_BOUNDARY for TDmode
for ia32. Should it return 128bit? The psABI isn't clear on
it. I think it should be aligned at 128bit.
--
Summary: TDmode isn't aligned at 128bit when passing to a
function
Product: gcc
--- Comment #3 from hjl dot tools at gmail dot com 2008-03-21 17:47 ---
It is caused by revision 129764:
http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00870.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hjl dot tools at gmail dot com 2008-03-21 17:53 ---
I think revision 129764 exposed a latent vectorizer bug. Before revision
129764, the loop wasn't vectorized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
Hi,
[This bug was initially submitted to the Debian BTS at
http://bugs.debian.org/466911 -- at the request of Debian's gcc maintainer, I
am also sending it here]
In porting CERNLIB to gfortran, I've found an apparent gfortran compiler bug
that results in incorrect code on ia64 (Itanium) with the
--- Comment #2 from bill at cse dot ucdavis dot edu 2008-03-21 18:00
---
(In reply to comment #1)
This is a bug in how GMP and MPFR tries to figure out the target platform, it
tries to always build a 64bit
library on a 64bit machine even when the default is 32bits.
Configure
Hi,
[This bug was initially submitted to the Debian BTS at
http://bugs.debian.org/466948 -- at the request of Debian's gcc maintainer, I
am also sending it here]
There is apparently a miscompilation of CERNLIB code in the kernlib library
on ia64 with gfortran-4.3 at optimization level -O2 or
--- Comment #5 from hjl dot tools at gmail dot com 2008-03-21 18:56 ---
I don't think peeling in vect_enhance_data_refs_alignment checks
if there is only one data reference.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
--- Comment #13 from drow at gcc dot gnu dot org 2008-03-21 19:30 ---
Closing, then.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--
Summary: Bootstrap failure on i686-apple-darwin9 at revision
133434.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo:
--- Comment #1 from dominiq at lps dot ens dot fr 2008-03-21 20:03 ---
Hit return too soon!-( The failure is:
/gcc/objc -I../../gcc-4.4-work/gcc/cp -fno-common -DHAVE_CONFIG_H -I. -Iobjcp
-I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/objcp
-I../../gcc-4.4-work/gcc/../include
On MinGW32, GCC 4.3.0 marks the .text.unlikely section as w(writable) instead
of x(executable), which makes the assembler to pad the section with zeros
instead of NOPs. Runtime behavior is almost always incorrect and in many cases
an application will crash.
--
Summary:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
--- Comment #1 from zuxy dot meng at gmail dot com 2008-03-21 20:18 ---
Created an attachment (id=15356)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15356action=view)
Sample C file that gets compiled incorrectly
Compile with gcc -march=pentium-m -mtune=generic -O3
--
zuxy dot meng at gmail dot com changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35661
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35661
--- Comment #2 from zuxy dot meng at gmail dot com 2008-03-21 20:23 ---
Subject: Re: __attribute__((cold)) generates wrong code
21 Mar 2008 20:17:53 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED]:
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-21 20:35 ---
FX,
You'll be glad to know that your memory leak patch reports:
!! Memory deallocation error in the code generated by the GNU Fortran compiler.
!! Please report this issue to http://gcc.gnu.org/bugzilla/
Even on
--- Comment #4 from uros at gcc dot gnu dot org 2008-03-21 20:43 ---
Subject: Bug 13958
Author: uros
Date: Fri Mar 21 20:43:12 2008
New Revision: 133435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133435
Log:
PR target/13958
* config/i386/i386.md
--- Comment #2 from andreast at gcc dot gnu dot org 2008-03-21 20:50
---
Subject: Bug 35660
Author: andreast
Date: Fri Mar 21 20:49:25 2008
New Revision: 133436
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133436
Log:
2008-03-21 Andreas Tobler [EMAIL PROTECTED]
PR
--- Comment #1 from ubizjak at gmail dot com 2008-03-21 20:53 ---
(In reply to comment #0)
ix86_function_arg_boundary returns PARM_BOUNDARY for TDmode
for ia32. Should it return 128bit? The psABI isn't clear on
it. I think it should be aligned at 128bit.
Yes, because it is moved
--- Comment #5 from ubizjak at gmail dot com 2008-03-21 20:58 ---
The inner loop is compiled (-O2 -march=pentium4 -malign-double) to:
.L4:
movl%ecx, %eax
andl$1, %eax
movla(,%eax,4), %eax
xorl%edx, %edx
(*)pushl %edx
(*)pushl %eax
--- Comment #6 from ubizjak at gmail dot com 2008-03-21 20:58 ---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13958
--- Comment #3 from andreast at gcc dot gnu dot org 2008-03-21 21:01
---
fixed
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2008-03-21 21:15 ---
*** This bug has been marked as a duplicate of 35541 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #8 from pcarlini at suse dot de 2008-03-21 21:15 ---
*** Bug 35656 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from george at gcc dot gnu dot org 2008-03-21 21:49 ---
Here is the relevant info for the build system:
#gcc -v -o /tmp/test /tmp/test.c
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-21 21:52 ---
What glibc version are you using?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35471
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-03-21 22:18 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-03-21 22:19 ---
Subject: Bug 27946
Author: pinskia
Date: Fri Mar 21 22:18:23 2008
New Revision: 133439
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133439
Log:
2008-03-21 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #4 from hutchinsonandy at aim dot com 2008-03-21 22:52 ---
Created an attachment (id=15357)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15357action=view)
FIX for ICE
This patches disables instruction pattern that causes ICE. This pattern is used
for the case of
Hi,
On Debian's mips and mipsel ports, gfortran 4.3 at -O1 or higher generates
object code that calls the sincosf() function in glibc's libm. Unfortunately
the function call does not produce the correct result: it returns 0 for the
sine and 1 for the cosine. Since an equivalent C program that
--- Comment #2 from hjl dot tools at gmail dot com 2008-03-22 00:27 ---
It is a question how TDmode should be aligned on stack when
passing to a function. I will ask it on the ia32 psABI group.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35657
--- Comment #3 from wilson at tuliptree dot org 2008-03-22 02:13 ---
Subject: Re: New: Incorrect printf warning: expect double has
float
6yxwfq202 at sneakemail dot com wrote:
foo.c:3: warning: format '%f' expects type 'double', but argument 2 has type
'float'
I believe this is
--- Comment #6 from michaelni at gmx dot at 2008-03-22 02:15 ---
As Uros has challenged me to beat performance of gcc-4.4 generated code by
hand-crafted assembly using the example of PR 21395 heres my entry, sadly i
only have gcc-4.3 compiled ATM for comparission but 4.3 generates
se7en_hills wrote:
[EMAIL PROTECTED] /cygdrive/f/project/gcc_build
$ make all-gcc
make.exe: *** No rule to make target `Makefile.in', needed by `Makefile'.
Stop.
If you look in Makefile, you should find a line that reads something like
Makefile: $(srcdir)/Makefile.in ...
which means Makefile
--- Comment #37 from michaelni at gmx dot at 2008-03-22 02:39 ---
Subject: Re: compiled trivial vector intrinsic code is
inefficient
On Fri, Mar 21, 2008 at 10:34:00AM -, ubizjak at gmail dot com wrote:
--- Comment #36 from ubizjak at gmail dot com 2008-03-21
--- Comment #7 from michaelni at gmx dot at 2008-03-22 02:51 ---
You can also replace the inner loop by:
2: \n\t
pxor %%mm1, %%mm1 \n\t
movq (%%eax, %%ecx), %%mm0\n\t
psubw (%%esi, %%ecx), %%mm0\n\t
pcmpgtw
--- Comment #1 from astrange at ithinksw dot com 2008-03-22 04:28 ---
I encountered this myself with 4.4.0 20080321.
If the data is static, gcc generates LC0 but not the copy with the original
name, which impedes debugging.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31043
66 matches
Mail list logo
