--- Comment #24 from ebotcazou at gcc dot gnu dot org 2006-08-07 07:04
---
> I think you meant to say, "not depend on the native compiler" :-)
Yes, the bootstrap compiler is the compiler you start the bootstrap with.
> Right, but... of course, whenever I say that I set such-and-such f
Since the fix to PR27770, we now miss opportunities to align some arrays when
-fsection-anchors is enabled. The patch for PR27770 increases the alignment of
(global) arrays only. We have a few testcases though (e.g.
section-anchors-vect-69.c) that have global structs that contain fields that
are ar
--- Comment #25 from dorit at il dot ibm dot com 2006-08-07 07:09 ---
(In reply to comment #24)
> Fixed, a new different bug for the missed optimization should be opened.
It's PR28628.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
--- Comment #2 from bonzini at gnu dot org 2006-08-07 07:38 ---
This gives an ICE-on-invalid.
template struct A
{
char d[i];
char &operator [] ( int indx ) { return d[indx]; }
};
struct B
{
A<44> a;
};
int main()
{
return __builtin_offsetof(B, a[0]);
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-07 07:41 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #25 from skunk at iskunk dot org 2006-08-07 07:42 ---
(In reply to comment #24)
> Of course you can override them on the line of the "make" command.
Right, but that's getting into mucking-with-the-build territory. (Hence my
tongue-in-cheek reply to Andreas in comment #4... i
--- Comment #18 from bonzini at gnu dot org 2006-08-07 07:54 ---
One element, but with some additional complication because it is a vector.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
--- Comment #26 from ebotcazou at gcc dot gnu dot org 2006-08-07 07:56
---
> Does all that sound good? Can we at least agree that the aforementioned
> inconsistency is a bug, even if the build system is too hopelessly complex to
> fix it, and 4.2 might not even have this issue anymore?
--- Comment #8 from pluto at agmk dot net 2006-08-07 07:56 ---
(In reply to comment #7)
> Firstly, using /bin/sh to build the compiler is unsupported on Solaris.
> Please
> read http://gcc.gnu.org/install/specific.html#x-x-solaris2
with /bin/bash and /bin/ksh it fails in the same way.
--- Comment #19 from bonzini at gnu dot org 2006-08-07 07:59 ---
This patchlet makes GCC use element-copy for struct FF:
Index: expr.c
===
--- expr.c (revision 115990)
+++ expr.c (working copy)
@@ -4763,7 +4763,7
--- Comment #14 from hubicka at gcc dot gnu dot org 2006-08-07 08:01
---
Created an attachment (id=12032)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12032&action=view)
Patch in testing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
--- Comment #5 from bonzini at gnu dot org 2006-08-07 08:08 ---
Dale Johannesen's patch for PR19653 would have fixed this, but it broke SH (it
caused PR27117).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
--- Comment #6 from bonzini at gnu dot org 2006-08-07 08:12 ---
Also, note that the problem is not only that SSE is used to store th. Even if
we enable SSE2, we do not use the SSE register to do the thdb.l++ and instead
do this:
movsd %xmm2, -8(%ebp)
movl-8(%ebp),
Error message:
filtbank.c: ÔÚº¯Êý ¡®MDCT¡¯ ÖУº
filtbank.c:498: ±àÒëÆ÷ÄÚ²¿´íÎó£ºSegmentation fault
ÇëÌá½»Ò»·ÝÍêÕûµÄ´íÎ󱨸棬
ÈçÓпÉÄÜÇ븽ÉϾԤ´¦ÀíºóµÄÔ´Îļþ¡£
¾ßÌå²½ÖèÇë²Î¼û http://gcc.gnu.org/bugs.html>¡£
Output from gcc -v:
´Ó c:/mingw/bin/../lib/gcc/mingw32/4.1.1/specs ¶ÁÈ¡ specs
Ä¿±ê£ºming
--- Comment #1 from zuxy dot meng at gmail dot com 2006-08-07 08:14 ---
Created an attachment (id=12033)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12033&action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28629
--- Comment #12 from bonzini at gnu dot org 2006-08-07 08:16 ---
The latent bug is blocking a pretty serious (P2) 4.x regression.
"Lie to reload, and it will take its revenge."
--
bonzini at gnu dot org changed:
What|Removed |Added
---
--- Comment #40 from hubicka at gcc dot gnu dot org 2006-08-07 08:18
---
Roger,
the patch for advance loc seems sane solution to me (in my limited
understanding
of dwarf2).
If I understand it right, we need the advance_loc only when crossing the
section boundary, so we ought to be abl
--- Comment #2 from zuxy dot meng at gmail dot com 2006-08-07 08:26 ---
(In reply to comment #0)
> It only appears when using both --march=pentium-m and optimization level
> higher
> than or equal to -O2.
Sorry, forgot to mention that I use -mfpmath=sse,387 in my spec file. So, more
p
--- Comment #3 from pluto at agmk dot net 2006-08-07 08:27 ---
gcc-4.1.2-20060712:
foo:subl$36, %esp #,
movq%mm0, (%esp)# x,
movl%ebx, 24(%esp) #,
movl(%esp), %ebx#, x
movl%esi, 28(%esp) #,
movl4(%esp),
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-08-07 08:30
---
> i see in my log only checking for awk.
> gcc/configure.in contains only AC_PROG_AWK.
Err... there is no gcc/configure.in in 4.1.2, only gcc/configure.ac. And the
configure fragment generated from AC_PROG_AWK w
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-08-07 08:40 ---
doesn't reproduce on i686-linux.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pluto at agmk dot net 2006-08-07 08:51 ---
(In reply to comment #9)
> > i see in my log only checking for awk.
> > gcc/configure.in contains only AC_PROG_AWK.
>
> Err... there is no gcc/configure.in in 4.1.2, only gcc/configure.ac.
sorry, typo.
> And the configure
--- Comment #7 from bonzini at gnu dot org 2006-08-07 08:51 ---
Created an attachment (id=12034)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12034&action=view)
patch that would fix it, but breaks SH
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
--- Comment #11 from pluto at agmk dot net 2006-08-07 08:58 ---
i should note that autoconf-2.59 works fine.
$ info autoconf
(...)
-- Macro: AC_PROG_AWK
Check for `awk', `mawk', `gawk', and `nawk', in that order, and
set output variable `AWK' to the first one that is found.
--- Comment #4 from bonzini at gnu dot org 2006-08-07 09:00 ---
Please disable your locale momentarily, and copy/paste the output of
gcc -### -O2 -march=pentium-m filtbank.i
or something like that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28629
--- Comment #12 from pluto at agmk dot net 2006-08-07 09:04 ---
(In reply to comment #11)
> i should note that autoconf-2.59 works fine.
>
> $ info autoconf
> (...)
> -- Macro: AC_PROG_AWK
> Check for `awk', `mawk', `gawk', and `nawk', in that order, and
> set output variable
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-08-07 09:09 ---
The IA-64 problem shall be fixed by my patch for PR target/26655.
The x86 problem is trickier. Reload is decided to merge all classes mentioned
in given alternative, so "ad" is equivalent to "A", while recog.c is wo
--- Comment #5 from zuxy dot meng at gmail dot com 2006-08-07 09:28 ---
(In reply to comment #4)
> Please disable your locale momentarily, and copy/paste the output of
> gcc -### -O2 -march=pentium-m filtbank.i
> or something like that.
C:\MSYS\source\faac\libfaac>gcc -### -O2 -march=p
This was reported by Mark Hesselink
http://gcc.gnu.org/ml/fortran/2006-08/msg00124.html
This:
MODULE types
TYPE :: t
INTEGER :: i
END TYPE
END MODULE types
MODULE foo
USE types
CONTAINS
FUNCTION bar (x) RESULT(r)
USE types
REAL, INTENT(IN) :: x
TYPE(t) :: r
--- Comment #15 from stephan at s11n dot net 2006-08-07 09:47 ---
(In reply to comment #12)
> This bug prevents the current release of the Globus toolkit
> (www.globus.org) from compiling.
A semi-workaround for getting SpiderMonkey to build is to export the
BUILD_OPT=1 environment varia
--- Comment #3 from aph at gcc dot gnu dot org 2006-08-07 09:54 ---
Sure, we should import the change.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
I have a code (usage of C++ binding for the Squirrel language in the
Code::Blocks IDE) that cannot be compiled with g++ from 4.1.1 (from FC devel)
and 4.2.0 (20060729), but can be compiled with 3.2, 3.4 and 4.0 (all on
Redhat/Fedora).
The output from the compiler is
--
scriptbindings.cc: In static
--- Comment #4 from pcarlini at suse dot de 2006-08-07 10:04 ---
I'm looking at C99, G.6/3 and it looks like the builtin (as implemented by
glibc) is "correct", or at least C99 complex conforming: the expected result is
(0, -1). indeed, this is also stated at the end of the mentioned C99
--- Comment #3 from hubicka at gcc dot gnu dot org 2006-08-07 10:18 ---
Hi,
because of quite serve register pressure issues, I don't like much idea of GCC
realocating stack transparently (it is also dificult to teach reload to decide
when alignment is needed). Safe bugfix for 4.2 seems
--- Comment #13 from amylaar at gcc dot gnu dot org 2006-08-07 10:28
---
(In reply to comment #12)
> The latent bug is blocking a pretty serious (P2) 4.x regression.
>
> "Lie to reload, and it will take its revenge."
Have you tried the patch from comments 5 to 8 ?
--
http://gcc.
--- Comment #14 from bonzini at gnu dot org 2006-08-07 11:11 ---
sure, and actually I have posted it to the GCC Patches mailing list to get
approval for the target-independent part.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
This patch adds value range propagation for (a&b), (a|b) operations.
I am not familiar with gcc internals, so please review carefully before
applying.
--
Summary: [PATCH] add VRP for bitwise OR and AND
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
--- Comment #1 from vda dot linux at googlemail dot com 2006-08-07 11:13
---
Created an attachment (id=12035)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12035&action=view)
The patch relative to 4.1.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28632
--- Comment #2 from vda dot linux at googlemail dot com 2006-08-07 11:14
---
Created an attachment (id=12036)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12036&action=view)
Test program which demonstrates how VRP generates simpler code
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #3 from vda dot linux at googlemail dot com 2006-08-07 11:26
---
Differences in *.vrp (-fdump-tree-vrp output) and assembly generated
with stock 4.1.1 and with patched one out of test program test_vrp.c
--- test_vrp.c.t36-411org.vrp 2006-08-06 22:40:04.0 +0200
++
--- Comment #9 from victork at gcc dot gnu dot org 2006-08-07 11:28 ---
Subject: Bug 26969
Author: victork
Date: Mon Aug 7 11:28:31 2006
New Revision: 115995
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115995
Log:
ChangeLog
PR tree-optimization/26969
* tree-v
--- Comment #3 from patchapp at dberlin dot org 2006-08-07 11:50 ---
Subject: Bug number PR28573
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-08/msg00170.html
--
http://gcc.gnu.org/bugzilla/sh
The following code fragment accesses a variable X (at fixed virtual address
0xc000) which is only guaranteed to be mapped in virtual memory if esp is
within a specific 4K range (from 0xcfcf to 0xcfcf0fff).
extern char _KERN_STACK;
register mword __esp asm ("esp");
printf ("[%d]\n",
(__esp
--- Comment #3 from hubicka at gcc dot gnu dot org 2006-08-07 11:59 ---
Created an attachment (id=12037)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12037&action=view)
patch
It looks like we should bite the bullet and let cgraph code to output the debug
info I am testing th
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
[ forwarded from http://bugs.debian.org/381710 ]
The following report has been submitted by Kurt Roeckx:
I've been looking at the perl testsuite failure on hppa. See
http://bugs.debian.org/374396
This code:
while (cdouble < 0.0)
cdouble += adouble;
Generated by gcc-4.1
--- Comment #1 from gary at gcc dot gnu dot org 2006-08-07 14:49 ---
Subject: Bug 28340
Author: gary
Date: Mon Aug 7 14:48:59 2006
New Revision: 115999
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115999
Log:
2006-08-07 Gary Benson <[EMAIL PROTECTED]>
PR libgcj/283
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-07 14:50 ---
GCC 4.1.0 is actually the correct behavior. This is a dup of bug 2922 which
changed the behavior to be what the standard says it should be.
*** This bug has been marked as a duplicate of 2922 ***
--
pinskia at
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-08-07 14:50
---
*** Bug 28631 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from gbenson at redhat dot com 2006-08-07 14:54 ---
I fixed it now
--
gbenson at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-07 14:54 ---
First patches should be off of the mainline. Second Patchs should be sent to
[EMAIL PROTECTED]
Third and this should be able to fix PR 18031 which I added a patch already
(though not officially sent it because I ha
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-07 15:03 ---
Two things:
1. don't file a bug with a code fragment.
2. this is not a bug as _KERN_STACK can never be unmapped memory at least to
the compiler.
Use the attribute weak and that should fix your issue.
--
pinskia a
--- Comment #38 from whaley at cs dot utsa dot edu 2006-08-07 15:32 ---
Paolo,
Thanks for all the help. I'm not sure I understand everything perfectly
though, so there's some questions below . . .
>I don't see how the last fmul[sl] can be removed without increasing code size.
Since t
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-08-07 15:35
---
(In reply to comment #19)
> This patchlet makes GCC use element-copy for struct FF:
You have to be careful when editing count_type_elements so that the elements of
a constructor that are not explict are zeroed.
I was experimenting with the way gcc does register allocation depending on
different flags. I encountered one strange test file where adding a second asm
statement made a first one fail which did work before. Even stranger, when I
have both parts as separate functions before, the combined version c
--- Comment #1 from Martin dot vGagern at gmx dot net 2006-08-07 15:49
---
Created an attachment (id=12038)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12038&action=view)
Testcase demonstrating interference between assembler statements
This test case exhibits the following beha
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-07 15:53 ---
I bet this is not a bug. x86 is known to be very register starved.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from Martin dot vGagern at gmx dot net 2006-08-07 16:02
---
One more observation: I tried adding the flags corresponding to -O1 according
to the info page:
-fdefer-pop -fdelayed-branch -fguess-branch-probability -fcprop-registers
-floop-optimize -fif-conversion -fif-conv
--- Comment #4 from Martin dot vGagern at gmx dot net 2006-08-07 16:14
---
(In reply to comment #2)
> I bet this is not a bug. x86 is known to be very register starved.
Yes, I know that. But this situation does not explain, why adding two more
functions containing the asm statements s
--- Comment #8 from tromey at gcc dot gnu dot org 2006-08-07 16:30 ---
I think comment #3 explains the problem.
So, this is either a more general GCC bug, or it is not a bug at all.
In any case it isn't a gcj problem :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28153
$ gcc -O2 input.c -o input
$ ./input
input: input.c:36: main: Assertion `s.buffer_position == s.buffer_end' failed.
The loop loses the increment of s.buffer_position.
--
Summary: [4.0/4.1 regression] Miscompiled loop
Product: gcc
Version: 4.1.2
Statu
--- Comment #1 from schwab at suse dot de 2006-08-07 16:34 ---
Created an attachment (id=12039)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12039&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||28067
Status|UNCONFIRMED |NEW
Ever Co
--- Comment #3 from tromey at gcc dot gnu dot org 2006-08-07 16:38 ---
Is this fixed by that commit?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28312
--- Comment #39 from whaley at cs dot utsa dot edu 2006-08-07 16:47 ---
Paolo,
OK, never mind about all the questions on assembly/patches/SVN/gcc3 perf: I
checked out the main branch, and vi'd the patched file, and I see that your
patch is there. I am presently building the SVN gcc on
--- Comment #40 from paolo dot bonzini at lu dot unisi dot ch 2006-08-07
16:58 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
>> I don't see how the last fmul[sl] can be removed without increasing code
>> size.
>>
> However, I c
--- Comment #5 from ian at airs dot com 2006-08-07 17:14 ---
Insofar as I understand this issue, it seems that C99 and the C++ standard
specify different results for the square root of (-1, -0).
If that is correct, then we can decide that we want libstdc++ to follow C99
rather than the
--- Comment #41 from whaley at cs dot utsa dot edu 2006-08-07 17:19 ---
Paolo,
>Actually, the peephole phase may not change the register usage, but it
>could peruse a scratch register if available. But it would be much more
>controversial (even if backed by your hard numbers on ATLAS)
The following invalid code snippet triggers a segfault on mainline
and 4.1 branch:
===
template struct A {};
A<0> a;
===
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
bug.cc:2: internal compiler error: Segment
--- Comment #6 from pcarlini at suse dot de 2006-08-07 17:24 ---
(In reply to comment #5)
> Insofar as I understand this issue, it seems that C99 and the C++ standard
> specify different results for the square root of (-1, -0).
>
> If that is correct, then we can decide that we want lib
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-08-07 17:25
---
Lee, this is fallout from your patch for PR 27668.
Would you mind having a look?
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pcarlini at suse dot de 2006-08-07 17:26 ---
By the way, as I read the cited LIA-3 draft, it's also consisten with C99. To
restate my point in a different way, if we believe there is an inconsistency
between C99 and C++03, then the former can only win about this speci
The following invalid code snippet triggers a ICE on mainline and 4.1 branch:
===
template struct A;
template class> struct B {};
B b;
===
bug.cc:1: error: 'void' is not a valid type for a template c
The following invalid code snippet triggers a ICE on mainline and 4.1 branch:
===
template struct A
{
static const int i = 1;
char a[i];
};
===
bug.cc:1: error: 'void' is not a valid type for a tem
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-07 17:34 ---
I bet this is a loop.c bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following invalid code snippet triggers an ICE on mainline and 4.1 branch:
===
template struct A;
template struct A;
===
bug.cc:1: error: 'void' is not a valid type for a template constant paramete
The following invalid code snippet triggers an ICE on mainline and 4.1 branch:
===
template void foo();
void bar() { foo<0>(); }
===
bug.cc:1: error: 'void' is not a valid type for a template constant
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28640
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28638
--- Comment #3 from schwab at suse dot de 2006-08-07 17:51 ---
-floop-optimize2 doesn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
--- Comment #8 from pcarlini at suse dot de 2006-08-07 18:16 ---
(In reply to comment #7)
> By the way, as I read the cited LIA-3 draft, it's also consisten with C99. To
> restate my point in a different way, if we believe there is an inconsistency
> between C99 and C++03, then the forme
--- Comment #42 from paolo dot bonzini at lu dot unisi dot ch 2006-08-07
18:19 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse
x87 code on all platforms than gcc 3
> We should get some idea by comparing gcc3 vs. your
> patched compiler on the various platforms, though oth
--- Comment #2 from hjl at lucon dot org 2006-08-07 18:24 ---
Here is the debug info generated by icc
The section .debug_info contains:
Compilation Unit @ offset 0x0:
Length:272
Version: 2
Abbrev Offset: 0
Pointer Size: 4
<0>: Abbrev Number: 1 (DW_TAG_comp
attribute((maybe_aliased)) in a union causes ICE
--
Summary: ICE in layout_type, at stor-layout.c:1851
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unass
--- Comment #1 from apl at alum dot mit dot edu 2006-08-07 18:27 ---
Created an attachment (id=12040)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12040&action=view)
test case causing ICE
compiled with: g++ -c ice.cxx
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28642
--
fche at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com
|dot org |
--- Comment #2 from apl at alum dot mit dot edu 2006-08-07 18:34 ---
Amending the "description"
attribute ((may_alias)) in a union causes ICE.
I'm using the 7/15/2006 snapshot of 4.2
I realize that unions are implicitly 'aliased', but in fact this problem was
encountered while I w
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--- Comment #11 from mathieu at malaterre dot com 2006-08-07 20:25 ---
Tested today (Aug 7, 2006) with:
$ /usr/lib/gcc-snapshot/bin/g++ --version
/tmp
g++ (GCC) 4.2.0 20060721 (experimental)
Copy
--- Comment #43 from dorit at il dot ibm dot com 2006-08-07 20:35 ---
> I'm all for this. info gcc says that w/o a guarantee of alignment, loops are
> duped, with an if selecting between vector and scalar loops, is this not
> accurate?
yes
>I spent a day trying to get gcc to vectori
--- Comment #2 from tromey at gcc dot gnu dot org 2006-08-07 20:37 ---
Subject: Bug 28609
Author: tromey
Date: Mon Aug 7 20:37:50 2006
New Revision: 116003
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116003
Log:
PR libgcj/28609:
* ltconfig: Copied from gcc.
--- Comment #3 from tromey at gcc dot gnu dot org 2006-08-07 20:39 ---
I took your advice and checked in the result of that cp.
Thanks!
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
Since the fix for PR26969, we now fail to vectorize loops that have redundant
phi-nodes in their (otherwise empty) latch block.
The testcase committed with the PR fix is an example for such a case.
See http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00034.html for more details.
--
Summar
--- Comment #6 from dannysmith at users dot sourceforge dot net 2006-08-07
21:04 ---
(In reply to comment #2)
> (In reply to comment #0)
> precisely, the bug can be reproduced with a combination of --march=pentium-m
> (or --march=pentium3 -msse2), -mfpmath=sse,387, and any optimization
Hi,
I've been trying to run perlbench (speccpu 2006 benchmark) compiled with gcc
4.1.0 with "-O3 -ffast-math -funroll-all-loops -m64". But when I run this
benchmark, it never completes (it goes on more than 3 hours) and I'd to kiil
it.
It completes when I added -fno-inline option. Just wanted to r
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-07 21:52 ---
4.1.0 is getting old and 4.1.1 has been released with bugs fixed. And this bug
really has no info about what the problem is.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
1 - 100 of 147 matches
Mail list logo
