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 oth
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 numbe
The faster way to build your website traffic with articles.
http://www.workoninternet.com/article_15891.html
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 br
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 pr
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
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 f
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
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, nothi
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 5/8
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 in
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 directl
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
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;
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?
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
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 Window
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
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
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
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> 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:
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.
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 + 1
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.
--
L
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-
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
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-
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
void fun();
int main()
{
fun();
return 0;
}
void fun()
{
int a;
int b, c;
return;
}
### Re
[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
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 in
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
maybe_encapsulat
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 -D_LA
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
=
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 ;-)
> 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)
>
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
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:
>>> 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-type
38 matches
Mail list logo
