--- 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
--- 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"
"pcmpg
--- 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 1
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 d
--- 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 bett
--- 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 #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
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 us
--- 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=15357&action=view)
FIX for ICE
This patches disables instruction pattern that causes ICE. This pattern is used
for the case of addi
--- 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=gcc&view=rev&rev=133439
Log:
2008-03-21 Andrew Pinski <[EMAIL PROTECTED]>
PR ta
--- 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 #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 #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 #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 #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 #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
Status|UNCONFI
--- 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 #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 #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 t
--- 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=gcc&view=rev&rev=133436
Log:
2008-03-21 Andreas Tobler <[EMAIL PROTECTED]>
P
--- 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=gcc&view=rev&rev=133435
Log:
PR target/13958
* config/i386/i386.md ("*floatunssi
--- 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 Cy
--- 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|Re
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35661
--
zuxy dot meng at gmail dot com changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35661
--- 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=15356&action=view)
Sample C file that gets compiled incorrectly
Compile with "gcc -march=pentium-m -mtune=generic -O3 -fomit-frame
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
http:
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: __attribute
--- 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 -I./.
--
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: unassigned
--- 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
Status|UNCONF
--- 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
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 hi
--- 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/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 #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
--- 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
---
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 #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
(i
--- 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 #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=15355&action=view)
Full errors from compilation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35656
sort.cxx:
=
#include
#include
void
foo()
{
std::vector 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
--prefix=/usr/local/gcc-4.3.0-x86_64-redhat-linux --wi
--- 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
--- 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 #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=gcc&view=rev&rev=133428
Log:
2008-03-21 Thomas Koenig <[EMAIL PROTECTED]>
PR
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
/home/mstein/build/m68hc11-elf/build/m68hc11
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
--- 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
--- 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 #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=gcc&view=rev&rev=133427
Log:
2008-03-21 Thomas Koenig <[EMAIL PROTECTED]>
PR
--- 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=15354&action=view)
gcc compilation script
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35654
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
chec
--- 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), %e
--- 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 thi
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||3.4.6
Priority|P3 |P2
--- 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 t
--- 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=15353&action=view)
reduced testcase
$ gcc-4.3 -O1 -g -ftree-vectorize test.i -o fails
$ gdb ./fails
GNU gdb 6.7.1-debian
Copyright (
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
$ gcc-
--- 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 bett
--- 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 typ
--- 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, %mm1
--- 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__ __vola
--- 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 #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=gcc&view=rev&rev=133416
Log:
Backport from mainline:
2008-03-20 Victor Kaplansk
--- 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 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 gen
66 matches
Mail list logo
