Zachary Turner writes:
> The codebase is large, but is new to linux. It was originally
> developed on windows and then ported to linux. It makes heavy use of
> C++, STL, and boost and we'd like to (if possible) link *everything*
> statically. This means libc, libgcc, libstdc++, boost, libpthre
Jerry Quinn writes:
> It does mean that we will always have to have c++ and c available to
> bootstrap. Was one of the goals to remove the need for a host C
> compiler?
No, removing the need for a host C compiler was not a goal.
> Meanwhile, I'm working on libdecnumber...
Actually, that is al
Hello, I've been trying to write a program that links to static
libraries, and I've been having a lot of difficulties. Was wondering
if someone can help me identify what's going wrong.
The codebase is large, but is new to linux. It was originally
developed on windows and then ported to linux. I
On Wed, 2009-07-15 at 19:07 -0700, Ian Lance Taylor wrote:
> Jerry Quinn writes:
>
> > Hi. I started looking at what it would take to convert zlib to build
> > with c++.
>
> The zlib library in gcc is actually a copy of upstream sources, so I
> don't think it would be a good idea to make this c
Jerry Quinn writes:
> Hi. I started looking at what it would take to convert zlib to build
> with c++.
The zlib library in gcc is actually a copy of upstream sources, so I
don't think it would be a good idea to make this change. We should stay
as close to the upstream source as possible.
Ian
Hi. I started looking at what it would take to convert zlib to build
with c++.
First off, it's not GPL. Are there any issues with modifying the code
checked into the tree?
Next, it uses automake, which seems to assume that a .c file should be
compiled with CC, and not CXX. I get the impression
LEB0 and LEB1 are duplicated in the attached ivms assembly file from
libgcc2. Note the first occurrence of each is at the prologue end,
which makes no sense to me.
FYI: I'm emitting the LPE labels at NOTE_INSN_FUNCTION_BEG and the LEB
labels at NOTE_INSN_EPILOGUE_BEG. I can send you the full
On Wed, 2009-07-15 at 22:48 +0200, Richard Guenther wrote:
> On Wed, Jul 15, 2009 at 10:46 PM, Richard
> Guenther wrote:
> > On Wed, Jul 15, 2009 at 9:15 PM, Tobias
> > Grosser wrote:
> >>> A note on Lis final graph algorithm. I don't understand why you want
> >>> to allow data-references to be pa
On 07/15/2009 10:47 PM, Joseph S. Myers wrote:
Unless libltdl can be statically linked in, using it is a bad idea for
other reasons as previously discussed at length.
I know of no program that dynamically links to libltdl, actually.
Paolo
Joseph S. Myers wrote:
On Wed, 15 Jul 2009, Paolo Bonzini wrote:
On 07/15/2009 09:36 PM, Joseph S. Myers wrote:
Before moving something out to a plugin (if we think that is technically
appropriate for the particular code in question) we should have a way to
build code, set up to be bui
On Wed, 15 Jul 2009, Paolo Bonzini wrote:
> On 07/15/2009 09:36 PM, Joseph S. Myers wrote:
> > Before moving something out to a plugin (if we think that is technically
> > appropriate for the particular code in question) we should have a way to
> > build code, set up to be built as a plugin, into
On Wed, Jul 15, 2009 at 10:46 PM, Richard
Guenther wrote:
> On Wed, Jul 15, 2009 at 9:15 PM, Tobias
> Grosser wrote:
>>> A note on Lis final graph algorithm. I don't understand why you want
>>> to allow data-references to be part of multiple alias-sets? (Of course
>>> I don't know how you are goi
On Wed, Jul 15, 2009 at 9:15 PM, Tobias
Grosser wrote:
>> A note on Lis final graph algorithm. I don't understand why you want
>> to allow data-references to be part of multiple alias-sets? (Of course
>> I don't know how you are going to use the alias-sets ...)
>
> Just to pass more information t
On 07/15/2009 09:36 PM, Joseph S. Myers wrote:
Before moving something out to a plugin (if we think that is technically
appropriate for the particular code in question) we should have a way to
build code, set up to be built as a plugin, into the compiler so that the
-fplugin options find the buil
After configuring
Target: x86_64-unknown-linux-gnu
gcc version 4.5.0 20090715 (experimental) [trunk revision 149654] (GCC)
with
../../mainline/configure --enable-checking=release
--prefix=/pkgs/gcc-mainline-mem-stats --enable-languages=c
--enable-gather-detailed-mem-stats
I get the
Richard Henderson wrote:
On 07/12/2009 12:30 PM, Douglas B Rupp wrote:
There really are multiple epilogues. The compiler is quite happy to
generate those, and has been happy to do so for some time.
What has changed is that we're now bothering to tell the debug info
about these epilogue copie
On Wed, 15 Jul 2009, Diego Novillo wrote:
> In general I think spinning off modules/passes that are not used very
> frequently (e.g. the tree browser) is a good idea since it reduces the
> size of our code base.
Before moving something out to a plugin (if we think that is technically
appropriate
On Wed, 2009-07-15 at 13:26 +0200, Richard Guenther wrote:
> On Wed, Jul 15, 2009 at 1:00 PM, Tobias
> Grosser wrote:
> > On Tue, 2009-07-14 at 23:34 +0200, Richard Guenther wrote:
> >> On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Pop wrote:
> >> > On Tue, Jul 14, 2009 at 11:03, Sebastian Pop wrote:
On Wed, Jul 15, 2009 at 14:50, Olatunji Ruwase wrote:
> Sorry that I wasn't very specific with my question. I m currently
> wrapping up the conversion of
> mudflap into a plugin. Most of the required patches have being
> approved and committed, so I was
> thinking ahead as to where the the plugi
On 07/13/2009 07:35 AM, Mohamed Shafi wrote:
So i made both TARGET_STRICT_ARGUMENT_NAMING and
PRETEND_OUTGOING_VARARGS_NAMED to return false. Is this correct?
Yes.
How to make the varargs argument to be promoted to 32bits when the
normal argument don't require promotion as mentioned in point
Sorry that I wasn't very specific with my question. I m currently
wrapping up the conversion of
mudflap into a plugin. Most of the required patches have being
approved and committed, so I was
thinking ahead as to where the the plugin code will reside.
Thanks for the information and the link
tu
[ Moved to gcc@ ]
On Wed, Jul 15, 2009 at 14:30, Olatunji Ruwase wrote:
> Has any decision being made on how plugins will be distributed with
> future releases. Is there going to be a plugins directory ?.
> Thanks
We may want to produce some plugins that are useful for GCC
development and dist
On 07/12/2009 12:30 PM, Douglas B Rupp wrote:
I've been working on bringing the VMS patches up to date. The VMS
Debugger requires a label at end prologue and begin_epilogue, and the
fact that final_scan_insn makes multiple calls to NOTE_INSN_EPILOGUE_BEG
for the same function makes this awkward.
The subreg pass has this :
(insn 5 2 6 2 ex1b.c:8 (set (reg/f:DI 74)
(const:DI (plus:DI (symbol_ref:DI ("data") )
(const_int 8 [0x8] 71 {movdi_internal} (nil))
(insn 6 5 7 2 ex1b.c:8 (set (reg/f:DI 75)
(symbol_ref:DI ("data") )) 71
{movdi_internal} (nil))
...
Jean Christophe Beyler writes:
> uint64_t foo (void)
> {
> return data[0] + data[1] + data[2];
> }
>
> And this generates :
>
> la r9,data
> la r7,data+8
> ldd r6,0(r7)
> ldd r8,0(r9)
> ldd r7,16(r9)
>
> I'm trying to see if there is a problem with my rtx costs function
>
I agree. I've actually pretty much finished that change and it seems
to be stable. I think it will be more maintainable in the
constraints.md state than it was before,
Thanks again,
Jc
On Wed, Jul 15, 2009 at 1:30 AM, Paolo Bonzini wrote:
> On 07/14/2009 10:31 PM, Jean Christophe Beyler wrote:
>>
Ah ok, so I can see why it would not be able to perform that
optimization around the loop but I changed the code to simply have
this:
uint64_t foo (void)
{
return data[0] + data[1] + data[2];
}
And this generates :
la r9,data
la r7,data+8
ldd r6,0(r7)
ldd r8,0(r9)
ldd r
Status
==
The trunk is in Stage 1. We expect that Stage 1 will last through
at least July and August.
There are still large pending merges we are aware of, specifically
the VTA, LTO and Graphite branches will be considered when deciding
when to go to Stage 3.
Quality Data
Prio
Status
==
GCC 4.4.1 Release Candidate 1 has been released, the branch is now
frozen until GCC 4.4.1 is released, all check-ins require explicit
approval from one of the RMs. Please report any 4.4.1 blockers
as soon as possible. If all goes well, 4.4.1 will be released next
week.
Quality Dat
A first release candidate for GCC 4.4.1 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4.1-RC-20090715
and shortly its mirrors. It has been generated from SVN revision 149684.
I have so far bootstrapped and tested the release candidate on
x86_64-linux and i686-linux. Please test it
On Wed, Jul 15, 2009 at 1:00 PM, Tobias
Grosser wrote:
> On Tue, 2009-07-14 at 23:34 +0200, Richard Guenther wrote:
>> On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Pop wrote:
>> > On Tue, Jul 14, 2009 at 11:03, Sebastian Pop wrote:
>> >>> Why do you need alias-set numbers?
>> >>
>> >> We want to repr
On Tue, 2009-07-14 at 23:34 +0200, Richard Guenther wrote:
> On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Pop wrote:
> > On Tue, Jul 14, 2009 at 11:03, Sebastian Pop wrote:
> >>> Why do you need alias-set numbers?
> >>
> >> We want to represent the alias set information as an extra subscript
> >> on
Hi Richard,
Maybe you could look into this thread and give us
some suggestion/confirmation.
Now we plan to use dr_may_alias_p (DR1, DR2) to partition
the alias set.
http://groups.google.de/group/gcc-graphite/browse_thread/thread/7bffbe9037b5adf4?hl=en
Thanks,
Li
On Wed, Jul 15, 2009 at 5:34 AM,
We are a young studio from Argentina that specializes in motion
graphics productions in both 2D & 3D for TV, films and web. We are very
interested to offer you our production services. I hope we can work
together soon, best!
check out our last reel http://www.bluna.tv
PATRICIO H. YAMUS
+5411 155
34 matches
Mail list logo
