> 1/ Ada multilib build is enabled unless --disable-multilib is used in
> configure: this means that the Ada build has more opportunity to fail
> because of code generation bugs or libada source selection issue, but in
> this later case it will be a only few lines in gcc/ada/Makefile.in to
> fix it
Raksit Ashok wrote:
>There is a more optimized version for 64-bit:
>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s
>I think this looks similar to your implementation, Agner.
Yes it is similar to my code.
Gnu libc could borrow a lot of optimized function
On Fri, 2008-07-25 at 09:00 +0200, Arnaud Charlet wrote:
> > 1/ Ada multilib build is enabled unless --disable-multilib is used in
> > configure: this means that the Ada build has more opportunity to fail
> > because of code generation bugs or libada source selection issue, but in
> > this later ca
> When danny and it wrote the ipa-type-escape pass, mark mitchell was all
> over us because we assumed that the type system had some semantic meaning.
> We ended up with a pass that generally finds nothing useful. I would very
> much like to redo that pass once we can mark a type as coming fro
> Yes I volunteer. We're in stage1 so we have some time to sort out
> reported issues before release.
OK. I'm still concerned that there is no simple fallback for all targets
that will break, except for --disable-multilib which is too strong since
it impacts other languages.
I'd be much more conf
Arnaud Charlet wrote:
Yes I volunteer. We're in stage1 so we have some time to sort out
reported issues before release.
OK. I'm still concerned that there is no simple fallback for all targets
that will break, except for --disable-multilib which is too strong since
it impacts other languages.
Thanks Paolo for your explanations, things are getting much clearer!
> I volunteer to check if there is support for
> --enable-multilib=libstdc++-v3,libjava and if not add it. Unfortunately,
> --disable-multilib=ada cannot work (because --disable-xxx is the same as
> --enable-multilib=no).
Doe
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> Arnaud Charlet wrote:
>>> Yes I volunteer. We're in stage1 so we have some time to sort out
>>> reported issues before release.
>>
>> OK. I'm still concerned that there is no simple fallback for all targets
>> that will break, except for --disable-multil
On Fri, Jul 25, 2008 at 7:01 AM, Chris Lattner <[EMAIL PROTECTED]> wrote:
>>> I dunno, this seems like a thing you could better figure out by trying
>>> it and seeing where the problems are than by trying to anticipate
>>> every single possible problem
>>> (not that there should be no design, but t
Something LIKE the below diff SEEMS "better".
It allows -with-build-sysroot to default like -with-sysroot.
I'm not sure that's really a goal. Depending on the direction,
it is reasonable. Or very unnecessary. Like, either I'm inventing
a new use of -with-build-sysroot, and then default it,
Hi,
I'm a new poster here. I am porting some Solaris code over to Linux and
using the GNU compiler and linker. Now I have a "meta library"(creating a
"master" shared object from mayny shared objects) which creates fine in
Solaris but in Linux it doesn't create as a meta library - ldd suggests
I volunteer to check if there is support for
--enable-multilib=libstdc++-v3,libjava and if not add it. Unfortunately,
--disable-multilib=ada cannot work (because --disable-xxx is the same as
--enable-multilib=no).
Does that mean that libgcc is implicitely multilibed if --enable-multilib=
is
>>> As an alternative, people that don't want multilibbed libada can not use
>>> libada altogether. More on this in a second.
>>
>> Still not clear to me what you mean here.
>
> I was thinking about using --disable-libada and instead using the "make -C
> gcc gnatlib" target. You will get no m
On Fri, 2008-07-25 at 09:35 +0200, Arnaud Charlet wrote:
> > I think this will help review and this is useful change on its own,
> > should I test and submit this first part separately?
>
> Yes, although I'd wait for the tuples branch and gcc-interface restructuration
> which will happen end of ju
On Fri, 25 Jul 2008, Jay wrote:
> It allows -with-build-sysroot to default like -with-sysroot.
The purpose of --with-build-sysroot is if you have installed your sysroot
in a different location from the configured --prefix. For example, you
have configured with --prefix=/opt/somewhere, the fina
On Fri, 25 Jul 2008, Laurent GUERBY wrote:
> The attached patch implements Arnaud suggestion of changing the arch
> to select the appropriate source (done and tested for x86_64-linux only
> for now) and doesn't touch anymore system-*.ads.
As a general comment on x86_64 handling, not having checke
On Fri, 2008-07-25 at 10:55 +, Joseph S. Myers wrote:
> i686-linux-gnu --enable-targets=all and x86_64-linux-gnu are equivalent,
> differing only in whether the default is 32-bit or 64-bit. Do you select
> the right files for both multilibs of i686-linux-gnu, as well as for both
> multilibs
Laurent GUERBY wrote:
On Fri, 2008-07-25 at 10:55 +, Joseph S. Myers wrote:
i686-linux-gnu --enable-targets=all and x86_64-linux-gnu are equivalent,
differing only in whether the default is 32-bit or 64-bit. Do you select
the right files for both multilibs of i686-linux-gnu, as well as for
Arnaud Charlet wrote:
When danny and it wrote the ipa-type-escape pass, mark mitchell was all
over us because we assumed that the type system had some semantic meaning.
We ended up with a pass that generally finds nothing useful. I would very
much like to redo that pass once we can mark a typ
On Fri, Jul 25, 2008 at 1:47 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
> Arnaud Charlet wrote:
>>>
>>> When danny and it wrote the ipa-type-escape pass, mark mitchell was all
>>> over us because we assumed that the type system had some semantic meaning.
>>> We ended up with a pass that general
Richard Guenther wrote:
On Fri, Jul 25, 2008 at 1:47 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
Arnaud Charlet wrote:
When danny and it wrote the ipa-type-escape pass, mark mitchell was all
over us because we assumed that the type system had some semantic meaning.
We ended up with a
Richard Guenther wrote:
On Fri, Jul 25, 2008 at 7:01 AM, Chris Lattner <[EMAIL PROTECTED]> wrote:
I dunno, this seems like a thing you could better figure out by trying
it and seeing where the problems are than by trying to anticipate
every single possible problem
(not that there should be no
On Thu, 26 Jun 2008 Uros wrote:
>Please also add a runtime test that can be used to analyze the problem.
I am a temporary guest on the gcc mailing list and I haven't seen your
mail before. In case your problem hasn't been solved yet, I can inform
you that I have a disassembler which puts comme
On Fri, Jul 25, 2008 at 2:06 AM, eoin <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I'm a new poster here. I am porting some Solaris code over to Linux and
> using the GNU compiler and linker. Now I have a "meta library"(creating a
> "master" shared object from mayny shared objects) which creates fine i
Laurent GUERBY wrote:
Joel did test (a previous iteration of) this patch on many RTEMS
multilibed targets and it worked (RTEMS system.ads already use Standard
attributes to be portable so no issue there).
I thought I would follow up with some details. I tested
on mips, powerpc, x86, and spar
We were discussing the status of the tuples branch on IRC today and we
collectively agreed that it would be a good idea to merge the branch
into mainline today.
I am planning to start the merge process, but first I wanted to freeze
mainline to minimize merge issues.
Any objections to this
Diego Novillo wrote:
We were discussing the status of the tuples branch on IRC today and we
collectively agreed that it would be a good idea to merge the branch
into mainline today.
I think it would be good to post a summary of the current state. Are
there any regressions? Any known featur
On Fri, Jul 25, 2008 at 8:03 AM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
> We were discussing the status of the tuples branch on IRC today and we
> collectively agreed that it would be a good idea to merge the branch into
> mainline today.
>
> I am planning to start the merge process, but first
H.J. Lu wrote:
Mainline is currently broken on a few platforms:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
I think we should fix it first before another big merge.
Diego, what do you think?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Jul 25, 2008, at 1:54 AM, Richard Guenther wrote:
Sure, typedefs in C/C++ seem clearly useless. I'm just curious how
you plan
to go about deciding whether things are useless in a more general
context.
How fine of a granularity do you intend to inspect bits? Trees
have lots
of random stu
On Fri, 25 Jul 2008, Mark Mitchell wrote:
> H.J. Lu wrote:
>
> > Mainline is currently broken on a few platforms:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36907
> >
> > I think we should fix it first before another big merge.
>
> Diego, what do you think?
Of the 7 platforms I can t
are the matrix-reorg pass that still has not been
converted. It also fixes 4 libstdc++ testcases that are currently
broken in trunk:
Fixed regressions in
tuples/00testsuite.x86_64.legolas/20080725/libstdc++.sum.gz:
FAIL: ext/pb_ds/regression/hash_data_map_rand.cc (test for
excess
Diego Novillo wrote:
In terms of regressions versus mainline, the only regressions introduced
by tuples wrt mainline are the matrix-reorg pass that still has not been
converted.
Why not fix that before merging, then?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x7
On Fri, 2008-07-25 at 08:40 -0500, Joel Sherrill wrote:
> Attached is the Ada library parts of my install
> tree with multilib'ed Ada for mips, powerpc, i386,
> and sparc on RTEMS. It is the output of doing this:
>
> cd ${prefix}
> find `find . -name adainclude` >ada-include.txt
> find . -name li
On Fri, Jul 25, 2008 at 13:03, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Diego Novillo wrote:
>
>> In terms of regressions versus mainline, the only regressions introduced
>> by tuples wrt mainline are the matrix-reorg pass that still has not been
>> converted.
>
> Why not fix that before merging,
Diego Novillo wrote:
Why not fix that before merging, then?
Because it is not a pass that is run by default, it is not receiving
active maintenance and the cost/benefit of doing it pre-merge is lower
than fixing the pass post-merge. If that is a problem, we can keep
delaying the merge until i
Hi,
On Fri, 25 Jul 2008, Chris Lattner wrote:
> >the frontends, but can concentrate on what is useful and needed for the
> >middle-end right now.
>
> Sure, this makes plenty of sense to me (and sounds very *very*
> familiar). Do you intend to include things like TBAA in the initial
> type sy
On Fri, Jul 25, 2008 at 6:19 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Diego Novillo wrote:
>
>>> Why not fix that before merging, then?
>>
>> Because it is not a pass that is run by default, it is not receiving
>> active maintenance and the cost/benefit of doing it pre-merge is lower
>> than
Diego Novillo wrote on 25 July 2008 17:15:
> On Fri, Jul 25, 2008 at 13:03, Mark Mitchell <[EMAIL PROTECTED]>
> wrote:
>> Diego Novillo wrote:
>>
>>> In terms of regressions versus mainline, the only regressions introduced
>>> by tuples wrt mainline are the matrix-reorg pass that still has not b
Steven Bosscher wrote:
If this pass is effectively unmaintained, why not just remove it?
Unmaintained passes that are not enabled at any optimization level are
usually broken anyway.
That's an option, too; the question is whether it has any value. I
don't know.
--
Mark Mitchell
CodeSourcer
Mark Mitchell wrote on 25 July 2008 17:30:
> Steven Bosscher wrote:
>
>> If this pass is effectively unmaintained, why not just remove it?
>> Unmaintained passes that are not enabled at any optimization level are
>> usually broken anyway.
>
> That's an option, too; the question is whether it has
> I think that someone, though, should be committed to fixing this pass ASAP
> after it's checked in; waiting until late August to fix it seems bad. Is
> there someone else who can commit to working on it as a high priority after
> the main tuples checkin?
I would obviously vote in favor of re
> In terms of regressions versus mainline, the only regressions introduced by
> tuples wrt mainline are the matrix-reorg pass that still has not been
> converted. It also fixes 4 libstdc++ testcases that are currently broken
> in trunk:
Apart from the matrix-reorg regressions, there are the Di
> > I think that someone, though, should be committed to fixing this pass ASAP
> > after it's checked in; waiting until late August to fix it seems bad. Is
> > there someone else who can commit to working on it as a high priority after
> > the main tuples checkin?
>
> I would obviously vote in
Jan Hubicka wrote:
So while the passes are probably now well in "benchmark toy" category
and they will need many changes to be useful in general, I think it is
good to have something we can test the framework at.
Do these passes actually help on benchmarks?
I don't think we should be dismissiv
Aldy Hernandez wrote:
I would obviously vote in favor of removal if the pass is unmaintained,
but if it is agreed that it will be maintained, I can commit to working
on it as soon as we merge.
My understanding is that this patch originated at IBM Haifa. Razya, can
you commit to helping Aldy
While doing the final trunk->tuples merge, I was surprised to find
several changes to the inliner and IPA cprop that I was convinced were
not going to happen until after the branch was merged.
So, I will now review the changes that Martin had posted for tuples, let
him commit the reviewed pa
Thanks for the help everyone.
I would like to begin working on this (== supporting this natively in
the compiler with a keyword/modifier (not sure about the correct term
:))).
What steps do I need to take before beginning in order to ensure this
effort will go into the main branch once it's comple
On Fri, Jul 25, 2008 at 9:35 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
> While doing the final trunk->tuples merge, I was surprised to find several
> changes to the inliner and IPA cprop that I was convinced were not going to
> happen until after the branch was merged.
>
> So, I will now revie
> Mark Mitchell writes:
Mark> Do these passes actually help on benchmarks?
Mark> I don't think we should be dismissive of "benchmark toy" passes if they
Mark> actually improve benchmarks significantly. We don't have to like it,
Mark> but we should accept that people are going to benchmark
> Jan Hubicka wrote:
> >So while the passes are probably now well in "benchmark toy" category
> >and they will need many changes to be useful in general, I think it is
> >good to have something we can test the framework at.
>
> Do these passes actually help on benchmarks?
Yes, those help signifca
On Fri, Jul 25, 2008 at 09:08:42AM +0200, Agner Fog wrote:
> Raksit Ashok wrote:
> >There is a more optimized version for 64-bit:
> >http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s
> >I think this looks similar to your implementation, Agner.
>
> Yes it is s
Snapshot gcc-4.4-20080725 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080725/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Kenneth Zadeck wrote:
1) Screw the debugging. The motivation behind this option is that
not only is it easy, but the reality is that we have changed the
program so much that even if we did "fix up the types" so that the
matched the generated program, that the code is so different from
On Fri, Jul 25, 2008 at 10:45 PM, <[EMAIL PROTECTED]> wrote:
> Snapshot gcc-4.4-20080725 is now available on
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080725/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
>
> This snapshot has been generated
Mark Mitchell wrote:
Kenneth Zadeck wrote:
1) Screw the debugging. The motivation behind this option is that
not only is it easy, but the reality is that we have changed the
program so much that even if we did "fix up the types" so that the
matched the generated program, that the code
On Jul 25, 2008, at 9:20 AM, Michael Matz wrote:
That is one example of extremely important information which requires
pulling in almost the entire source type system.
But not all the trees implementing those types (and all the
cross-references between those, that are important for parsing but
Hi Dear Gcc developers,
When I am trying to build Mozilla with gcc-mingw, I came across
the linkage error of undefined symbols in multiple inheritance case.
And I have made a simple test case to reproduce the problem. But the
test case is still very complex, I think. So, I came down to find th
58 matches
Mail list logo
