On Sun, Nov 20, 2005 at 05:02:11AM +0100, Gabriel Dos Reis wrote:
> svk depotmap --list shows:
>
>Depot Path
>
>// /home/gdr/.svk/local
>/gcc/ /home/gdr/svk
If you'
There are a lot of projects on Wiki page, and I want to do something
in one of them, but I do not which project I could start with?
I am interested in SSA, so I want to do some projects about SSA to
solidify my knowledge and apply this theory to practical applications.
I browsed description of ev
Hi,
I'm back to home where I can actually experiment with the new
switch to SVN.
I installed the experimental release (1.3.0-rc2) of SVN, OpenSSH-4.2p1,
SVK (0.29 coming with my GNU/Linux distribution), downloaded the
entire GCC SVK tarball (which took ages to decompress with rzip),
followed t
>
> > > And this is just recent too.
> > >
> > > Anyways here is the reduced testcase:
> > > long long
> > > __fixunsdfdi (unsigned hi, unsigned lo)
> > > {
> > > return ((unsigned long long) hi << (32)) | lo;
> > > }
> >
> > flow2 is where the diference comes in:
> > I don't understand why it
> > And this is just recent too.
> >
> > Anyways here is the reduced testcase:
> > long long
> > __fixunsdfdi (unsigned hi, unsigned lo)
> > {
> > return ((unsigned long long) hi << (32)) | lo;
> > }
>
> flow2 is where the diference comes in:
> I don't understand why it is not being split at al
>
> >
> > tail -n 30
> > /work/built/mbuild/g148-rguenther-61/x86_64/Logfile.gcc-mainline.spec
> > -o 32/crtbeginT.o
> > ../../gcc/libgcc2.c: In function '__fixunsdfdi':
> > ../../gcc/libgcc2.c:1228: error: could not split insn
> > (insn:TI 17 65 66 ../../gcc/libgcc2.c:1219 (parallel [
> >
>
> tail -n 30
> /work/built/mbuild/g148-rguenther-61/x86_64/Logfile.gcc-mainline.spec
> -o 32/crtbeginT.o
> ../../gcc/libgcc2.c: In function '__fixunsdfdi':
> ../../gcc/libgcc2.c:1228: error: could not split insn
> (insn:TI 17 65 66 ../../gcc/libgcc2.c:1219 (parallel [
> (set (reg:
On Sunday 20 November 2005 00:49, Chris Lattner wrote:
> On Sun, 20 Nov 2005, Steven Bosscher wrote:
> > On Saturday 19 November 2005 18:56, Chris Lattner wrote:
> >>> Only the Ada frontend seems to be in a state to maybe support direct
> >>> frontend IR to LLVM translation.
> >>
> >> Sure, also ma
On Sun, 20 Nov 2005, Steven Bosscher wrote:
Can you explain what you mean?
I mean it would take a complete re-write of the translation phase from
gfortran's native program representation to GENERIC trees. Even if it
is "quite possible" to make it write out LLVM directly, it would be a
huge job
On Sunday 20 November 2005 01:49, Chris Lattner wrote:
> On Sun, 20 Nov 2005, Steven Bosscher wrote:
> > On Saturday 19 November 2005 18:56, Chris Lattner wrote:
> >>> Only the Ada frontend seems to be in a state to maybe support direct
> >>> frontend IR to LLVM translation.
> >>
> >> Sure, also ma
On Sun, 20 Nov 2005, Steven Bosscher wrote:
On Saturday 19 November 2005 18:56, Chris Lattner wrote:
Only the Ada frontend seems to be in a state to maybe support direct
frontend IR to LLVM translation.
Sure, also maybe Fortran?
I wouldn't count on it...
Can you explain what you mean? The
On Saturday 19 November 2005 18:56, Chris Lattner wrote:
> > Only the Ada frontend seems to be in a state to maybe support direct
> > frontend IR to LLVM translation.
>
> Sure, also maybe Fortran?
I wouldn't count on it...
Gr.
Steven
On Thursday 17 November 2005 17:53, Andrew MacLeod wrote:
> http://people.redhat.com/dnovillo/rable.pdf
How are the insn annotations and caches you propose different from
what df.c already does?
Gr.
Steven
Ian Lance Taylor wrote:
> Reload inheritance is a complex idea threaded through reload.
In fact, this was cleared up in the reload-branch (as documented here:
http://gcc.gnu.org/wiki/BerndSchmidt), which seems that nobody has enough skill
and time to get into a mergeable state. Now that we're en
On 11/19/05, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Fri, 18 Nov 2005, Chris Lattner wrote:
>
> > 1. The build system is taught about C++ code.
>
> With toplevel bootstrap this will bootstrap libstdc++ so that the compiler
> ends up linked with the new libstdc++ not the (in general
> ABI-in
Kenneth Zadeck writes:
This quickly becomes
difficult and messy, which is presumably why the link-time proposal
allows the linker to "give up" linking two translation units.
The reason for the complexity of the type system handling in our
proposal was motivated primarily by two concerns:
1)
tail -n 30 /work/built/mbuild/g148-rguenther-61/x86_64/Logfile.gcc-mainline.spec
-o 32/crtbeginT.o
../../gcc/libgcc2.c: In function '__fixunsdfdi':
../../gcc/libgcc2.c:1228: error: could not split insn
(insn:TI 17 65 66 ../../gcc/libgcc2.c:1219 (parallel [
(set (reg:DI 0 ax [66])
On Sat, Nov 19, 2005 at 01:26:47PM -0800, Richard Henderson wrote:
> > There are a small number
> > of static tests in the linuxthreads testsuite and I've run it on HEAD
> > recently.
>
> It's entirely possible that it's been fixed, but the systems in
> question are old enough that they pre-date
On Fri, Nov 18, 2005 at 10:47:40PM -0500, Daniel Jacobowitz wrote:
> Got a handy testcase, or is it catastrophic?
It's all-pervasive.
__thread int x;
int main() { return x; }
> There are a small number
> of static tests in the linuxthreads testsuite and I've run it on HEAD
> recently.
It's ent
On Sat, Nov 19, 2005 at 09:00:38PM +0100, Giovanni Bajo wrote:
> Steve Kargl <[EMAIL PROTECTED]> wrote:
>
> > Perhaps, I missed the required options, but I'll
> > ask an obvious question anyway. Often when testing
> > a patch, one will often place a new testcase in
> > gcc/testsuite/*. This new
> Specifically, advocates of the recent link-time-optimization proposal
> [1] may claim that exposing all of the information that DWARF captures
> (e.g. about the type system) at link-time is a good thing: it makes it
> easier to do specific high-level optimizations, because all of the
> info
Ian Lance Taylor writes:
> The current reload pass includes general heuristics to handle
> reloading memory addresses. This code knows things like "if stack
> pointer plus displacement is not a valid memory address, try loading
> the displacement into a register." Many targets currently rely on
On Saturday 19 November 2005 19:48, you wrote:
> On 11/19/05, Panagiotis Papadakos <[EMAIL PROTECTED]> wrote:
> > I am trying to build 4.1 branch but make profiledbootstrap stops here:
>
> See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00857.html for
> a patch that fixes the problem.
>
> Richard.
On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote:
> On 11/19/05, Steve Kargl <[EMAIL PROTECTED]> wrote:
> > which is indeed correct. So, is there an option to tell
> > svn to blow away files that conflict with files in the
> > repository.
>
> Subversion is reluctant to blow away users'
Steve Kargl <[EMAIL PROTECTED]> wrote:
> Perhaps, I missed the required options, but I'll
> ask an obvious question anyway. Often when testing
> a patch, one will often place a new testcase in
> gcc/testsuite/*. This new file is not under control
> of svn. After review, the patch is committed t
Andrew MacLeod <[EMAIL PROTECTED]> writes:
> The document is intended as a starting point and consists mostly of my
> thoughts at the moment. By the time the underlying RTL bits are done, I
> would like it to have evolved to include input from others. The more
> useful comments there are, the bet
On 11/19/05, Steve Kargl <[EMAIL PROTECTED]> wrote:
> which is indeed correct. So, is there an option to tell
> svn to blow away files that conflict with files in the
> repository.
Subversion is reluctant to blow away users' files; this was one of the
qualities of CVS we thought we should try to
On Sat, 2005-11-19 at 10:14 -0500, Kaveh R. Ghazi wrote:
> Hi Dan,
>
> (BTW, sorry for the reposted messages.)
>
> While I was waiting for some svn commands to finish (cleanup, update)
> on my solaris2.7 box, which has a slow filesystem, I happened to run
> truss -p out of curiosity to see what
On Sat, 19 Nov 2005, Joseph S. Myers wrote:
On Fri, 18 Nov 2005, Chris Lattner wrote:
1. The build system is taught about C++ code.
With toplevel bootstrap this will bootstrap libstdc++ so that the compiler
ends up linked with the new libstdc++ not the (in general
ABI-incompatible) old one? (
Richard Guenther writes:
I would propose to even think of doing only IPO at LLVM and go back to
gimple for the rest of the tree-ssa pipeline. At least that should be
possible. Would we get link-time optimization this way, or is the LLVM
link-time optimization architected differently?
Sure,
Well, seems related to PR 22313
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
--
Papadakos Panagiotis
On 11/19/05, Panagiotis Papadakos <[EMAIL PROTECTED]> wrote:
> I am trying to build 4.1 branch but make profiledbootstrap stops here:
See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00857.html for
a patch that fixes the problem.
Richard.
I am trying to build 4.1 branch but make profiledbootstrap stops here:
stage1/xgcc -Bstage1/ -B/usr/gcc_4.1/i486-slackware-linux/bin/ -c -O2 -g
-fomit-frame-pointer -fprofile-use -freorder-blocks-and-partition -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedant
On Fri, 18 Nov 2005 17:50:52 -0800, Chris Lattner wrote:
> Recently, at Apple, I have been working on a new version of the llvm-
> gcc translation layer, built on GCC 4 ... I plan to have this work
> committed to the Apple branch within a month.
I'm curious as to why Apple is doing this. Is it s
Perhaps, I missed the required options, but I'll
ask an obvious question anyway. Often when testing
a patch, one will often place a new testcase in
gcc/testsuite/*. This new file is not under control
of svn. After review, the patch is committed to the
tree. Now, I want to update my local reposi
Hi Dan,
(BTW, sorry for the reposted messages.)
While I was waiting for some svn commands to finish (cleanup, update)
on my solaris2.7 box, which has a slow filesystem, I happened to run
truss -p out of curiosity to see what was taking so long.
Turns out that svn does many file operations on lon
On Fri, 18 Nov 2005, Chris Lattner wrote:
> 1. The build system is taught about C++ code.
With toplevel bootstrap this will bootstrap libstdc++ so that the compiler
ends up linked with the new libstdc++ not the (in general
ABI-incompatible) old one? (This question applies to all projects
invo
On Fri, 18 Nov 2005, Mark Mitchell wrote:
> # Generate the next mainline snapshot manually, using the -p option of
> the gcc_release script. For that single run, adjust the script such that
> the announcement mail is sent to you personally so that you can adjust
> references to the previous snapsh
On 11/19/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 18, 2005 at 05:50:52PM -0800, Chris Lattner wrote:
> > * This will not support !
> >
> > As describe above, we won't support every target that GCC currently
> > does. Three options are possible:
> >
> > 1. We (the GCC communit
Richard Henderson writes:
>
> I will say that staticly linked linuxthreads tls is known to be
> broken. Or at least known to me. I encountered this while doing
> OpenMP work on RHEL3. The problem I saw doesn't appear with nptl.
Ah, that's a useful clue. I can confirm that this is definit
40 matches
Mail list logo
