Hi,
Do you guys know if the problem with the access() standard library function has
been worked around?
Windows vista has an updated MSVCRT.DLL which returns false for access() using
X_OK, this parameter was previously ignored, and returned true. MinGW / GCC
does not work on Vista as a result.
Because it's the semantics of libcall sequences. My take is that the
lower subreg pass breaks it in this case.
I could fix it at -O2 with -fno-split-wide-types or at -O1 with
-fno-move-loop-invariants or -fno-split-wide-types.
Can you also check -fno-forward-propagate?
Yes. It'll
On 5/8/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
Because it's the semantics of libcall sequences. My take is that the
lower subreg pass breaks it in this case.
I could fix it at -O2 with -fno-split-wide-types or at -O1 with
-fno-move-loop-invariants or -fno-split-wide-types.
Can you
But without libcall notes, we just see a call_insn and a set to a hard
register, and we have no way to tell that the call_insn is dead and
can safely be removed.
Even if CONST_OR_PURE_CALL_P is set to 1??? :-(
Paolo
On 5/8/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
But without libcall notes, we just see a call_insn and a set to a hard
register, and we have no way to tell that the call_insn is dead and
can safely be removed.
Even if CONST_OR_PURE_CALL_P is set to 1??? :-(
I don't know, but in any
Here's what it looks like in the jump dump, right before the lower subreg
pass:
[...]
(insn 63 59 61 3 memcmp.c:81 (clobber (reg:SI 75)) -1 (nil)
(insn_list:REG_LIBCALL 62 (nil)))
(insn 61 63 62 3 memcmp.c:81 (parallel [
(set (subreg:HI (reg:SI 75) 0)
Even if CONST_OR_PURE_CALL_P is set to 1??? :-(
I don't know, but in any case __tls_get_addr is neither pure nor const
rs6000 says it is, I should try doing the same for x86-64 and see what
happens.
(and for non-TLS libcalls, we don't have to know because we never make
them dead anyway
Rask Ingemann Lambertsen [EMAIL PROTECTED] writes:
I'm seeing miscompilation of newlib's memcmp() for my 16-bit ix86 port. The
REG_RETVAL and REG_LIBCALL notes seem to play an important part in the
failure. From the first subreg dump:
Try this:
Index: gcc/lower-subreg.c
Hi,
Fix for PR31264 doesn't seem to be checked into 4.2.0 branch which breaks
MPlayer SVN compilation with :
cc -I../libavcodec -I../libavformat -Wdeclaration-after-statement -I. -I..
-I../libavutil -O4 -march=pentium-m -mtune=pentium-m -pipe
-ffast-math -fomit-frame-pointer -D_REENTRANT
Paolo Bonzini wrote:
Even if CONST_OR_PURE_CALL_P is set to 1??? :-(
I don't know, but in any case __tls_get_addr is neither pure nor const
rs6000 says it is, I should try doing the same for x86-64 and see what
happens.
See the patches I've posted; with those I can remove
Patrick Olinet writes:
Hi there,
I'm running an embedded platform based on a powerpc 405EP CPU and a
gcc 4.1.0 cross-toolchain. My initial problem was that gcj compiled
binaries crash at runtime when interpreting java bytecode (Illegal
instruction message).
After many
[EMAIL PROTECTED] wrote:
Do you guys know if the problem with the access() standard library function
has
been worked around?
Windows vista has an updated MSVCRT.DLL which returns false for access() using
X_OK, this parameter was previously ignored, and returned true. MinGW / GCC
does not
Hi all,
I am working with GCC 4.1.1 for a private target. For the sample
program given below, frame description entry generated is not proper.
PROGRAM #
#include stdio.h
void fun();
int main()
{
fun();
return 0;
}
void fun()
{
int a;
int b, c;
return;
}
Hi,
On Wed, May 02, 2007 at 01:34:18PM -0700, Mark Mitchell wrote:
GCC 4.2.0 RC3 is now available from:
Successfully built on s390 and s390x:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00142.html
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00143.html
Bye,
-Andreas-
On 5/8/07, Ismail Dönmez [EMAIL PROTECTED] wrote:
Hi,
Fix for PR31264 doesn't seem to be checked into 4.2.0 branch which breaks
MPlayer SVN compilation with :
cc -I../libavcodec -I../libavformat -Wdeclaration-after-statement -I. -I..
-I../libavutil -O4 -march=pentium-m -mtune=pentium-m -pipe
On Tuesday 08 May 2007 14:35:26 Richard Guenther wrote:
On 5/8/07, Ismail Dönmez [EMAIL PROTECTED] wrote:
Hi,
Fix for PR31264 doesn't seem to be checked into 4.2.0 branch which breaks
MPlayer SVN compilation with :
cc -I../libavcodec -I../libavformat -Wdeclaration-after-statement -I.
On Tuesday 08 May 2007 14:35:26 Richard Guenther wrote:
[...]
Did you verify this is actually the same problem? Note that this PR
isn't marked as
broken on 4.2.0 or as a regression, so you should probably file a new
bugreport against 4.2.0 and link to the old one.
Filed as PR31865.
--
Le
Hi all,
I'm writing a new compilation pass in gcc, and I'm working on GIMPLE
code. When gcc produce GIMPLE code, it creates new temporary
variables, in order to simplify expressions and statements. For
example, if source C file contains
a=a+b+19;
then GIMPLE code is
D.1295 = a + b;
a = D.1295 +
On 5/8/07, Andrea Callia D'Iddio [EMAIL PROTECTED] wrote:
how can I recognize temporary variables, such as D.1295?
DECL_ARTIFICIAL is set on all compiler-generated symbols and labels.
I'm CC'ing Howard, the master of the rvalue reference, and Russell,
the author of the rvalue references patch... see below for my take on
this.
On 5/7/07, Sylvain Pion [EMAIL PROTECTED] wrote:
I have done some experiments with the rvalue reference feature on the
cxx0x-branch.
Great!
I am
At the request of a few developers, I set up a mercurial
(http://www.selenic.com/mercurial/) repository that mirrors our SVN
one.
It is updated automatically from SVN every 30 minutes.
Note *only GCC developers have access right now*. I will make it
available by http anonymously soon.
The url
Brian Dessent wrote:
[EMAIL PROTECTED] wrote:
Do you guys know if the problem with the access() standard library function
has
been worked around?
Windows vista has an updated MSVCRT.DLL which returns false for access()
using
X_OK, this parameter was previously ignored, and returned
Mark Mitchell writes:
In my opinion, this is a GCC bug: there's no such thing as X_OK on
Windows (it's not in the Microsoft headers, or documented by Microsoft
as part of the API), and so GCC shouldn't be using it.
Strictly speaking, access() (or _access()) isn't a documented part of
any Windows
On 5/8/07, Daniel Berlin [EMAIL PROTECTED] wrote:
At the request of a few developers, I set up a mercurial
(http://www.selenic.com/mercurial/) repository that mirrors our SVN
one.
The repo does not currently contain the full history of GCC, but this
is my fault :)
I started the pulling on my
2007/5/2, Casey Marshall [EMAIL PROTECTED] wrote:
From Sun, there are not notice, news, etc about the process of GPLing
the OpenJDK.
JavaOne begins May 8th.
Cheers.
Today,
there are any news from JavaOne?
Andrea Callia D'Iddio [EMAIL PROTECTED] wrote:
Hi all,
I'm writing a new compilation pass in gcc, and I'm working on GIMPLE
code. When gcc produce GIMPLE code, it creates new temporary
variables, in order to simplify expressions and statements. For
example, if source C file contains
a=a+b+19;
On Tue, 08 May 2007 21:40:32 +0200, J.C. Pizarro [EMAIL PROTECTED] said:
2007/5/2, Casey Marshall [EMAIL PROTECTED] wrote:
From Sun, there are not notice, news, etc about the process of GPLing
the OpenJDK.
JavaOne begins May 8th.
Today,
there are any news from JavaOne?
My apologies to
Hi Pizarro,
Please stop complaining here. We can do nothing about Sun opening or not
opening, although we have
few reason to doubt they will release the code. It's not our fault you cannot
use common senseand
you can't see the real and concrete progress Sun made so far.
Either complain
Just another data point, my git-svn clone of trunk comes in at 414MB,
excluding the size of checked out files. I'm assuming the public svn
is the complete history.
I'm about 35% through the process of cloning the entire gcc repository
via git-svnimport, and the .git directory is 5.0GB. This
git-svnimport will not pack incrementally as it runs, so it might get
pretty large. git-svn offers and incremental repack every x commits
(I chose 1000) and that did wonders for the import time for me.
Otherwise it will create a huge number of files before the final pack.
Cheers,
Harvey
On
Mark Mitchell wrote:
I'm disappointed to hear that MinGW made this change. As a MinGW user,
I don't want MinGW to interpose anything between me and the MSVCRT
libraries. I want MinGW to give me headers and import libraries for the
Microsoft DLLs, with all their warts; nothing more, nothing
On Tue, May 08, 2007 at 09:43:58PM +0200, J.C. Pizarro wrote:
Andrea Callia D'Iddio [EMAIL PROTECTED] wrote:
Hi all,
I'm writing a new compilation pass in gcc, and I'm working on GIMPLE
code. When gcc produce GIMPLE code, it creates new temporary
variables, in order to simplify expressions
And today we learn why I think version control systems that think
repacking is something the user should be doing are worthless beasts
:)
It generally just means you didn't think through your storage
subsystem enough, but in git's case it's probably that the project it
was originally developed
Ross Ridge wrote:
Mark Mitchell writes:
In my opinion, this is a GCC bug: there's no such thing as X_OK on
Windows (it's not in the Microsoft headers, or documented by Microsoft
as part of the API), and so GCC shouldn't be using it.
Strictly speaking, access() (or _access()) isn't a
On 5/8/07, Daniel Berlin [EMAIL PROTECTED] wrote:
And today we learn why I think version control systems that think
repacking is something the user should be doing are worthless beasts
:)
It generally just means you didn't think through your storage
subsystem enough, but in git's case it's
git-svnimport will not pack incrementally as it runs, so it might get
pretty large. git-svn offers and incremental repack every x commits
(I chose 1000) and that did wonders for the import time for me.
Otherwise it will create a huge number of files before the final pack.
FYI, doing a repack
The faster way to build your website traffic with articles.
http://www.workoninternet.com/article_15891.html
On 5/8/07, Ollie Wild [EMAIL PROTECTED] wrote:
git-svnimport will not pack incrementally as it runs, so it might get
pretty large. git-svn offers and incremental repack every x commits
(I chose 1000) and that did wonders for the import time for me.
Otherwise it will create a huge number of
Sjodin, Jan wrote:
I agree. Also, the LTO requirements and high-level design document
states that the external format should be compiler-independent and it
should be possible for other tools to read and write that format. Is
this still a goal?
It was a goal for me, but I don't think other
According to http://gcc.gnu.org/bugs.html here is what is requested for
a bug report.
Regards,
Miguel Luis.
## the exact version of GCC;
$ gcc --version
gcc (GCC) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying
--- Comment #7 from cgf at gcc dot gnu dot org 2007-05-08 13:04 ---
reverting spamassassin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31858
--- Comment #8 from cgf at gcc dot gnu dot org 2007-05-08 13:06 ---
I reverted spamassassin to v3.1.8.
Comments on the net seemed to indicate that 3.2.0 was slower anyway and it
certainly doesn't seem ready for prime time yet.
--
cgf at gcc dot gnu dot org changed:
What
With -O1, the following testcase
int
foo (void)
{
return ({
unsigned int resultvar = ({
long int arg = (long int) 0;
register long int reg asm (eax) = arg;
asm volatile (nop
: =a (resultvar)
: 0 (reg)
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-08 13:45 ---
Subject: Bug 31692
Author: pault
Date: Tue May 8 12:45:31 2007
New Revision: 124546
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124546
Log:
2007-05-08 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-08 13:49 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-08 13:51 ---
I'll submit a fix tonight.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-08 13:51 ---
I'll submit a fix tonight.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pault at gcc dot gnu dot org 2007-05-08 13:52 ---
Oops!
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--- Comment #1 from dnovillo at acm dot org 2007-05-08 14:10 ---
Subject: Re: New: Loop IM and other optimizations harmful for -fopenmp
On 8 May 2007 07:59:03 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
See http://openmp.org/pipermail/omp/2007/000840.html
and the
--- Comment #12 from angray at beeb dot net 2007-05-08 15:07 ---
(In reply to comment #11)
MSC includes the calling convention as part of its C++ name mangling. Would
this bug be easier to solve if the calling convention was also included as
part
of the C++ name mangling in GCC,
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-08 15:30 ---
WTF, this is just sad we have to disable optimizations because openmp folks
don't know how to program threaded code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #13 from bangerth at dealii dot org 2007-05-08 15:34 ---
(In reply to comment #12)
The summary says g++ misses warning for on temporary. But something that
is
always an error can be called a warning?
The point is that the standard doesn't call it an error, but
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-08 15:35 ---
EDG accepts this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-08 15:36 ---
*** This bug has been marked as a duplicate of 31793 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-08 15:36 ---
*** Bug 31865 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-08 15:37 ---
OMP is not a good generic programming model for threaded code. Exactly because
of this issues.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
--- Comment #4 from dnovillo at acm dot org 2007-05-08 15:39 ---
Subject: Re: Loop IM and other optimizations harmful for -fopenmp
On 8 May 2007 14:30:45 -, pinskia at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-08
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-08 15:41 ---
Subject: Bug 31630
Author: pault
Date: Tue May 8 14:40:58 2007
New Revision: 124550
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124550
Log:
2007-05-08 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from dnovillo at acm dot org 2007-05-08 15:44 ---
Subject: Re: Loop IM and other optimizations harmful for -fopenmp
On 8 May 2007 14:37:05 -, rguenth at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
OMP is not a good generic programming model for threaded code.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-08 15:45 ---
Created an attachment (id=13530)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13530action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-08 15:47 ---
This is related to PR29433, but still unresolved.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-08 15:52 ---
Until I killed cc1plus we have (mainline):
samples %symbol name
5011528.3000 push_fields_onto_fieldstack
12370 6.9853 bitpos_of_field
10174 5.7453 tree_low_cst
8825 4.9835
On 8 May 2007 14:44:16 -, dnovillo at acm dot org
[EMAIL PROTECTED] wrote:
The original code did not have a race condition. The compiler
transformations introduced a race-condition. This *is* a compiler
bug.
Actually the original code has a race condition, if another thread is
reading
--- Comment #6 from pinskia at gmail dot com 2007-05-08 15:59 ---
Subject: Re: Loop IM and other optimizations harmful for -fopenmp
On 8 May 2007 14:44:16 -, dnovillo at acm dot org
[EMAIL PROTECTED] wrote:
The original code did not have a race condition. The compiler
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-08 16:01 ---
cc1plus: out of memory allocating 1764584 bytes after a total of 16482304
bytes
so this actually killed even the 16GB box.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-05-08 16:03 ---
Danny, push_fields_onto_fieldstack is going crazy on this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #37 from james dot kanze at gmail dot com 2007-05-08 16:11
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
On 7 May 2007 21:08:05 -, gianni at mariani dot ws
[EMAIL PROTECTED] wrote:
--- Comment #35 from gianni at mariani dot ws
--- Comment #38 from james dot kanze at gmail dot com 2007-05-08 16:21
---
Subject: Re: Lack of Posix compliant thread safety in std::basic_string
On 8 May 2007 05:24:35 -, gianni at mariani dot ws
[EMAIL PROTECTED] wrote:
--- Comment #36 from gianni at mariani dot ws
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-05-08 16:21 ---
Note the interesting debuggable testcase is if you remove from getInstance()
all
template params from ClassSpecKey, A020, 21 on. Around that one you'll
clearly
see exponential behavior in memory use ;)
--
The program
module util_mod
implicit none
contains
function join(words,sep) result(str)
! trim and concatenate a vector of character variables,
! inserting sep between them
character (len=*), intent(in):: words(:),sep
character (len=(size(words)-1)*len(sep) + sum(len_trim(words))) :: str
--- Comment #3 from simartin at gcc dot gnu dot org 2007-05-08 16:34
---
Subject: Bug 31847
Author: simartin
Date: Tue May 8 15:33:56 2007
New Revision: 124551
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124551
Log:
2007-05-08 Simon Martin [EMAIL PROTECTED]
PR
--- Comment #4 from simartin at gcc dot gnu dot org 2007-05-08 16:47
---
This should be fixed (see
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00527.html for an explanation of
the patch).
--
simartin at gcc dot gnu dot org changed:
What|Removed
--- Comment #14 from raf2 at msux dot cjb dot net 2007-05-08 17:18 ---
I first was hit by an error using MinGW... when I compiled and executed the
first attached file, it wrote:
John drives a: bus
Otto drives a: bus
Which was wrong, I reported the bug and a guy from
--- Comment #15 from raf2 at msux dot cjb dot net 2007-05-08 17:22 ---
Created an attachment (id=13531)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13531action=view)
File with wrong code that leads to an unexpected result
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
--- Comment #16 from bangerth at dealii dot org 2007-05-08 17:25 ---
(In reply to comment #14)
Which was wrong, I reported the bug and a guy from MinGW kindly explained that
if it worked then that would be purely by accident and added:
When you declare the argument without '' then
X86-64 crtend.o with DWARF EH is broken when compiled with
-fasynchronous-unwind-tables, which is the default:
http://gcc.gnu.org/ml/gcc/2002-11/msg00799.html
It was fixed for Linux only:
http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01671.html
That leaves all non-Linux x86-64 with DWARF EH
--- Comment #1 from hjl at lucon dot org 2007-05-08 18:12 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00557.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31868
--- Comment #5 from ismail at pardus dot org dot tr 2007-05-08 18:48
---
I had to apply http://gcc.gnu.org/viewcvs?view=revrevision=122255 to the 4.2.0
branch to be able to bootstrap, else I get :
from gcc-4.2.0-20070430/libstdc++-v3/include/precompiled/stdc++.h:71:
--- Comment #2 from hjl at lucon dot org 2007-05-08 18:55 ---
Patches against 4.1, 4.2 and 4.3 are at
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00563.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31868
--- Comment #6 from ismail at pardus dot org dot tr 2007-05-08 19:02
---
Never mind my last comment, it was a local patch causing the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31793
--- Comment #7 from jakub at gcc dot gnu dot org 2007-05-08 19:08 ---
This really is not specific to OpenMP, I believe the following is valid
threaded program:
#define _XOPEN_SOURCE 600
#include pthread.h
#include stdlib.h
int v;
pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
--- Comment #8 from pinskia at gmail dot com 2007-05-08 19:45 ---
Subject: Re: Loop IM and other optimizations harmful for -fopenmp
On 8 May 2007 18:08:26 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #7 from jakub at gcc dot gnu dot org 2007-05-08
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #39 from pcarlini at suse dot de 2007-05-08 19:50 ---
The proper status of this PR is SUSPENDED. Today, mid of 2007, we all more or
less concur that string is better implemented without reference-counting,
optimized for short strings, and, of course, exploiting rvalue
--- Comment #13 from mark at codesourcery dot com 2007-05-08 20:11 ---
Subject: Re: Compile errors with multiple inheritance where
the stdcall attribute is applied to virtual functions.
rridge at csclub dot uwaterloo dot ca wrote:
--- Comment #11 from rridge at csclub dot
#include stdio.h
#define MKSTR(x) STR(x)
#define STR(x) #x
#define EMPTY /* nothing */
int main(void) {
puts(MKSTR(.EMPTY.));
puts(MKSTR(.EMPTY .));
}
Using gcc 4.1.2, configured with
../gcc-4.1.2/configure --prefix=$HOME/gcc --enable-languages=c,c++
--disable-multilib, on
--- Comment #7 from fang at csl dot cornell dot edu 2007-05-08 20:44
---
Still accepts-invalid as of 4.2-20070430 (RC2).
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
--- Comment #9 from fang at csl dot cornell dot edu 2007-05-08 20:48
---
Still accepts-invalid with 4.2-20070430 (RC2).
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
--- Comment #2 from dorit at il dot ibm dot com 2007-05-08 21:00 ---
Here is what happens in the three loops that don't get vectorized:
(1) the loop in testvectdp2:
This is the loop we analyze:
# prephitmp.192_37 = PHI storetmp.191_30(3), D.1443_42(5)
# i_1 = PHI 1(3), i_44(5)
--- Comment #2 from sje at cup dot hp dot com 2007-05-08 21:18 ---
I am seeing this slow compile too. It compiles OK on HPPA in 32 bit mode (1.5
minutes) but takes over 30 minutes in 64 bit mode. It also takes 6+ minutes on
IA64 HP-UX. On an X86 box it took less than 1 minute.
Using
--- Comment #7 from spop at gcc dot gnu dot org 2007-05-08 21:19 ---
Subject: Re: -ftree-vectorize results in internal compiler error on AMD64
On 5/8/07, Sjodin, Jan [EMAIL PROTECTED] wrote:
Okay, I looked at the code, and the problem is that we have to pass to
--- Comment #8 from Jan dot Sjodin at amd dot com 2007-05-08 21:30 ---
Subject: RE: -ftree-vectorize results in
internal compiler error on AMD64
I would prefer to make it work instead of disabling the vectorizer for
these cases.
- Jan
-Original Message-
From: [EMAIL
--- Comment #3 from sje at cup dot hp dot com 2007-05-08 21:55 ---
I now think the loc_mentioned_in_p calls are coming from the checking code at
the top of subst_reload. I commented out this checking code and my compile
speed up by more than 10X.
--
sje at cup dot hp dot com
--- Comment #14 from angray at beeb dot net 2007-05-08 22:02 ---
(In reply to comment #13)
Subject: Re: Compile errors with multiple inheritance where
the stdcall attribute is applied to virtual functions.
rridge at csclub dot uwaterloo dot ca wrote:
--- Comment #11 from
--- Comment #35 from mmitchel at gcc dot gnu dot org 2007-05-08 22:05
---
Ian Taylor suggests:
The way to fix this is to add a HOST_HOOKS_GT_PCH_GET_ADDRESS to
host-solaris.c. That hook should try to allocate the space in some
address area that is normally free on Solaris. See the
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-08 23:08
---
Created an attachment (id=13532)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13532action=view)
New patch
Here's a new patch from a completely different perspective, using C99 lround
and llround functions
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-05-08 23:11 ---
It turned out that this is a generic reload issue rather than
a target problem. See
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00476.html
--
kkojima at gcc dot gnu dot org changed:
What
--- Comment #3 from steven at gcc dot gnu dot org 2007-05-08 23:15 ---
This patch would fix it, but it's brute-force and it causes a ~1.5% slowdown.
Some form of DCE a little more delicate than this will be necessary to fix this
bug, though.
Index: cfgcleanup.c
1 - 100 of 118 matches
Mail list logo
