Hello,
It too is possible that you
have completed your assignment process with the FSF, but have yet to be
removed from the list of outstanding assignments. If this is the case
please let me know so that I can update the record.
This is the case: I have had a copyright assignment on file for a
Hi,
I have been given a set of cross-compiler binaries (like arch-gcc,
arch-as, arch-ld, arch-ar, arch-gdb, etc.,).
How can i test "arch-gcc" cross-compiler binary using GCC testsuite ?
i have downloaded and extracted gcc-testsuite.x.y.tar.gz. I have also
installed dejagnu, TCL and expect for te
The differences you are seeing now are likely caused by differences in
autoconf configuration for the case of GCC compiler versus non-GCC
compiler.
One of the results of toplevel bootstrap is to eliminate these
differences in autoconf configuration.
Paolo
Snapshot gcc-4.1-20070625 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070625/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Jun 25, 2007, at 3:31 PM, Hui-May Chang via RT wrote:
> I thought I have completed it earlier. Can you check for me? Thanks!
Don't worry, they just spammed the entire list with a seemingly off-
list issue I think they just meant to ping Francois.
On Jun 25, 2007, at 3:31 PM, Hui-May Chang via RT wrote:
> I thought I have completed it earlier. Can you check for me? Thanks!
Don't worry, they just spammed the entire list with a seemingly off-
list issue I think they just meant to ping Francois.
On Jun 25, 2007, at 3:31 PM, Hui-May Chang via RT wrote:
I thought I have completed it earlier. Can you check for me? Thanks!
Don't worry, they just spammed the entire list with a seemingly off-
list issue I think they just meant to ping Francois.
I thought I have completed it earlier. Can you check for me? Thanks!
Hui-May Chang
On Jun 25, 2007, at 3:14 PM, Jonas Jacobson via RT wrote:
> Hello,
>
> This email is to follow up on your communication with the Free
> Software
> Foundation. Previously, you had expressed interest in contributin
Hello,
This email is to follow up on your communication with the Free Software
Foundation. Previously, you had expressed interest in contributing to
the GNU Project. If this is still the case please respond so that we
can move the process along. If you did not receive the assignment
please let us
On Mon, Jun 18, 2007 at 02:08:15PM -0700, H. J. Lu wrote:
> On Mon, Jun 18, 2007 at 11:10:43AM -0700, Steve Ellcey wrote:
> > > BTW: IA64 has the same issues with two FP types (long double XFmode and
> > > "longer double" TFmode). How is this solved for IA64?
> > >
> > > Uros.
> >
> > This is di
On Jun 25, 2007, at 10:59 AM, Eric Botcazou wrote:
Probably. But, as Mike told me privately, STABS are sensitive to
the build
directory, so I tried again and got identical executables byte-for-
byte:
Cool. Glad you could verify them on a byte for byte basis. This
helps keep your compiler
> Jakub Jelinek writes:
Jakub> I guess the right thing to do would be to replace the current
Jakub> 3 uses of SYMBOL_REF_LOCAL_P (x) macro in config/rs6000/*.md
Jakub> with
Jakub> SYMBOL_REF_LOCAL_P (x) && (!TARGET_ARCH64 || !SYMBOL_REF_EXTERNAL_P (x))
Jakub> where TARGET_ARCH64 is replaced b
> Still, if you use these two bootstrapped, slightly different compilers
> as base for a fresh bootstrap in a new build directory, you'll likely
> get identical results and that would still prove that there is no
> self-propagating back door in GCC on that configuration.
Probably. But, as Mike to
2007/6/25, Basile STARYNKEVITCH <[EMAIL PROTECTED]>:
Jiahua He wrote:
> Hi All,
>
> I am looking for an open source compiler, such as GCC, Open64, Scale
> and SUIF, as the infrastructure of my research. Though I have read
> some of their documents, they are still complicate to me and it is
> diff
Jiahua He wrote:
Hi All,
I am looking for an open source compiler, such as GCC, Open64, Scale
and SUIF, as the infrastructure of my research. Though I have read
some of their documents, they are still complicate to me and it is
difficult to decide which one is better. Can you please help me to
c
On Mon, Jun 25, 2007 at 12:48:10PM -0400, Mark Mitchell wrote:
> I was suggesting leaving the hook alone, but modifying the test for the
> sibling call optimization in rs6000_function_ok_for_sibcall to:
>
> !DECL_EXTERNAL (decl) && binds_local_p (decl)
>
> In other words, per Jakub's argument,
Hi All,
I am looking for an open source compiler, such as GCC, Open64, Scale
and SUIF, as the infrastructure of my research. Though I have read
some of their documents, they are still complicate to me and it is
difficult to decide which one is better. Can you please help me to
compare these compi
David Edelsohn wrote:
>> Mark Mitchell writes:
>
> Mark> Good point -- if there's no definition in the current translation unit,
> Mark> then I guess we aren't going to make any bad assumptions about the
> Mark> contents of the function. So, I guess that just means that the Power
> Mark> back
> Mark Mitchell writes:
Mark> Good point -- if there's no definition in the current translation unit,
Mark> then I guess we aren't going to make any bad assumptions about the
Mark> contents of the function. So, I guess that just means that the Power
Mark> back end needs to check for !DECL_EXT
Jakub Jelinek wrote:
> For replacability the current definition is just fine. Weak functions
> must be assumed to be always replaceable and non-weak functions which are
> known to bind within the same executable resp. shared library are not
> replaceable - linker will issue error if two non-weak
On Mon, Jun 25, 2007 at 10:15:55AM -0400, Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
>
> >> I think the DECL_EXTERNAL case should go before the visibility checks in
> >> default_binds_local_p_1. A DECL_EXTERNAL entity never binds locally.
> >
> > That isn't the meaning that most callers of
On Jun 24, 2007, at 16:20, Eric Botcazou wrote:
Indeed. It would be interesting to confirm whether or not a copy
of gcc
bootstrapped with a non-gcc compiler matched byte-for-byte with a
copy
of gcc bootstrapped from gcc.
I just made the experiment on an old SPARC/Solaris 2.5.1 machine
a
Hello Andreas,
Hello Jeff,
I have recently started on implementing processor pipeline model for
m68k target. At this point I am trying to figure out the best way of
annotating instructions in m68k.md, so that appropriate cpu unit
reservations could be assigned to each one of them.
The probl
Daniel Jacobowitz wrote:
>> I think the DECL_EXTERNAL case should go before the visibility checks in
>> default_binds_local_p_1. A DECL_EXTERNAL entity never binds locally.
>
> That isn't the meaning that most callers of this function want,
> however. They want same shared object, which is what
On Mon, Jun 25, 2007 at 07:06:01AM -0400, Jakub Jelinek wrote:
> Hi!
>
> extern void bar (void) __attribute__((visibility ("hidden")));
> void foo (void)
> {
> bar ();
> bar ();
> }
> compiled on ppc64-linux with -O2 -m64 -mminimal-toc
> leads to bl bar without nop in the following instruction
On Mon, Jun 25, 2007 at 09:31:14AM -0400, Mark Mitchell wrote:
> David Edelsohn wrote:
>
> > /* If defined in this object and visibility is not default, must be
> > local. */
> > else if (DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT)
> > local_p = true;
> >
> > Why does binds_local_p
> Mark Mitchell writes:
Mark> I think the DECL_EXTERNAL case should go before the visibility checks in
Mark> default_binds_local_p_1. A DECL_EXTERNAL entity never binds locally.
Jakub,
Do you want to follow up with a patch to change the ordering of
tests in default_binds_local_p_1()
David Edelsohn wrote:
> /* If defined in this object and visibility is not default, must be
> local. */
> else if (DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT)
> local_p = true;
>
> Why does binds_local_p return true for non-default visibility?
I was just about to ask that.
It's a
On Mon, Jun 25, 2007 at 09:15:40AM -0400, David Edelsohn wrote:
> Emitting a NOP depends on SYMBOL_FLAG_LOCAL.
>
>if (targetm.binds_local_p (decl))
> flags |= SYMBOL_FLAG_LOCAL;
>
> PPC64 uses the default binds_local_p() hook, default_binds_local_p_1():
>
> /* If defined in this
Emitting a NOP depends on SYMBOL_FLAG_LOCAL.
if (targetm.binds_local_p (decl))
flags |= SYMBOL_FLAG_LOCAL;
PPC64 uses the default binds_local_p() hook, default_binds_local_p_1():
/* If defined in this object and visibility is not default, must be
local. */
else if (DECL
> Mark Mitchell writes:
Mark> That would be my recommendation: limit optimizations that require a
Mark> short branch to calls to functions in the same translation unit, not
Mark> just in the same shared object. But, that's just my two cents; the
Mark> Power maintainers might have a different
[EMAIL PROTECTED] wrote:
Hi
For example i hear that native posix threads has portions of it implemented in
kernel and also requires glibc support. In such cases if i attempt to run an
application compiled with gcc-4 on a linux-2.4 kernel, wont there be problems??
With changes in binutils, would
Jakub Jelinek wrote:
> Hi!
>
> extern void bar (void) __attribute__((visibility ("hidden")));
> void foo (void)
> {
> bar ();
> bar ();
> }
> compiled on ppc64-linux with -O2 -m64 -mminimal-toc
> leads to bl bar without nop in the following instruction
> and to sibling call.
> Shouldn't -mmin
On Mon, Jun 25, 2007 at 07:32:48AM -0400, David Edelsohn wrote:
> > Jakub Jelinek writes:
>
> Jakub> compiled on ppc64-linux with -O2 -m64 -mminimal-toc
> Jakub> leads to bl bar without nop in the following instruction
> Jakub> and to sibling call.
> Jakub> Now, when this together with bar's d
> As for C++, I think we need more OO language specific
> optimizations. I don't know what the status of
> devirtualizion which was reported on the previous
> summit.
Sorry for the late replay.
The devirtualization is on hold. Currently GCC is lacking the necessary
infrastructure needed by C
On 6/25/07, David Edelsohn <[EMAIL PROTECTED]> wrote:
Just out of curiosity, are you using a version of GCC with or
without the section anchor support? Is the application still overrunning
the TOC with sectcion anchors?
I have access to programs that overflow the TOC even with section
> Jakub Jelinek writes:
Jakub> compiled on ppc64-linux with -O2 -m64 -mminimal-toc
Jakub> leads to bl bar without nop in the following instruction
Jakub> and to sibling call.
Jakub> Now, when this together with bar's definition is linked
Jakub> into a big binary and foo and bar need to have di
Hi!
extern void bar (void) __attribute__((visibility ("hidden")));
void foo (void)
{
bar ();
bar ();
}
compiled on ppc64-linux with -O2 -m64 -mminimal-toc
leads to bl bar without nop in the following instruction
and to sibling call.
Now, when this together with bar's definition is linked
into
Hi
For example i hear that native posix threads has portions of it implemented in
kernel and also requires glibc support. In such cases if i attempt to run an
application compiled with gcc-4 on a linux-2.4 kernel, wont there be problems??
With changes in binutils, would there be changes in the ba
39 matches
Mail list logo
