I would like that svn print the URL of each file in the diff output,
like CVS's `RCS file'. One of the scripts I use to test GCC (which I
have not contributed yet because of the svn transition) used it to
detect the directory in which the patch should apply.
Danny, can you do it for 1.3? If
Hi,
someone at the computing center just told me that the version of "install"
that caused the problem was terribly obsolete and only got installed by
accident. It has been removed now.
If you want to add an autoconf check for this version, I can try to get
a copy of the binary. But I'm not sure
Paolo Bonzini wrote:
> I would like that svn print the URL of each file in the diff output, like
> CVS's
> `RCS file'. One of the scripts I use to test GCC (which I have not contributed
> yet because of the svn transition) used it to detect the directory in which
the > patch should apply.
Is it
BTW: Is there a way to include a C function heading in diff output? I have tried
'svn diff -x -p' to get:
svn: '-p' is not supported
To add this by default, I made diff-cmd point to this script I called
gcc-diff
#! /bin/sh
case "$1" in
-u|-U*) exec diff -p "$@" ;;
-c|-C*) exec diff -p
Uros Bizjak <[EMAIL PROTECTED]> wrote:
>> I would like that svn print the URL of each file in the diff output,
>> like CVS's `RCS file'. One of the scripts I use to test GCC (which I
>> have not contributed yet because of the svn transition) used it to
>> detect the directory in which the > patch
Richard Guenther wrote:
>Just to put some more thoughts on the table, I'm about to propose adding
>a __gcc_cpu_feature symbol to $suitable_place, similar to what Intel is
>doing with its __intel_cpu_indicator which is used in their runtime libraries
>to select different code paths based on process
On 11/8/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >Just to put some more thoughts on the table, I'm about to propose adding
> >a __gcc_cpu_feature symbol to $suitable_place, similar to what Intel is
> >doing with its __intel_cpu_indicator which is used in their runt
Richard Guenther wrote:
>What would be interesting to know, is what architectures apart from ia32 will
>likely profit from this?
>
A quick comment about this: *many*. It's not only about i386 vs i486+,
it's about all the arches that don't have the builtins *currently*
implemented not because of fu
Hi all,
To transform my java RMI code to windows native code, I followed Ranjit
Mathew's tutorial to compile gcc to a cross compiler.
http://ranjitmathew.hostingzero.com/phartz/gcj/bldgcj.html
The src packages I am using are:
binutils-2.16.1
gcc-4.0.2
The binary packages I am using are:
m
I really don't know what I could be doing wrong, but on a _stock_ FC4
install, I'm having a segfault in a pthread call when
statically linked and including iostream (or STL includes like string)
Here's the code:
#include
#include
int main(int argc, char *argv[])
{
pthread_mutexattr_t attr;
On Tue, Nov 08, 2005 at 09:31:56AM -0500, Dixon, Lee L. wrote:
> I really don't know what I could be doing wrong, but on a _stock_ FC4
> install, I'm having a segfault in a pthread call when
> statically linked and including iostream (or STL includes like string)
>
> Here's the code:
>
> #include
Thank you SOOO much for the reply. I'd been pulling hair out while
getting *no* responses on several forums and mail lists.
In my case, statically linking is important because of configuration
management of executable files for an airborne embedded flight control
system.
I'd like to find out i
Currently, on the gomp branch, I get this:
if /bin/sh ./libtool --mode=compile
/usr/local/src/branch/objdir.gomp/./gcc/xgcc
-B/usr/local/src/branch/objdir.gomp/./gcc/
-B/usr/local/sparc64-unknown-linux-gnu/bin/
-B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem
/usr/local/sparc64-unknown-linux-g
On Tue, Nov 08, 2005 at 04:05:20PM +0100, Christian Joensson wrote:
> Currently, on the gomp branch, I get this:
>
> if /bin/sh ./libtool --mode=compile
> /usr/local/src/branch/objdir.gomp/./gcc/xgcc
> -B/usr/local/src/branch/objdir.gomp/./gcc/
> -B/usr/local/sparc64-unknown-linux-gnu/bin/
> -B/us
On 11/8/05, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> Can you please paste the omp_check_defines routine as from libgomp_f.h
> and grep config_path Makefile
Sure, here's the (relevant(?) part of) generated libgomp_f.h:
static inline void
omp_check_defines (void)
{
char test[(24 != sizeof (omp
On Tue, Nov 08, 2005 at 05:00:43PM +0100, Christian Joensson wrote:
> Sure, here's the (relevant(?) part of) generated libgomp_f.h:
>
> static inline void
> omp_check_defines (void)
> {
> char test[(24 != sizeof (omp_lock_t)
>|| 4 != __alignof (omp_lock_t)
>|| 24 != sizeo
On Tue, Nov 08, 2005 at 09:17:10AM -0700, Mark Cuss wrote:
> Hi Eric
>
> sparc-sun-solaris2.9-objdump -f returns the following:
> libc.so:
> start address 0x
> ...
Congratulations, this must be the longest top-post ever.
--
Markus
- Original Message -
From: "Markus Trippelsdorf" <[EMAIL PROTECTED]>
To: "Mark Cuss" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>;
Sent: Tuesday, November 08, 2005 9:29 AM
Subject: Re: Skipping incompatable libaries on a SPARC cross compile
On Tue, Nov 08, 2005 at 09:17:10AM -0700, Mar
> Anyways, I found a mistake in my sysroot and these messages seem to have
> vanished I had a symlink pointing to my local (linux) /lib instead of
> the sysroot's /lib (oops)
That would indeed explain the problem you were having.
--
Eric Botcazou
On 11/8/05, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 08, 2005 at 05:00:43PM +0100, Christian Joensson wrote:
> > Sure, here's the (relevant(?) part of) generated libgomp_f.h:
> >
> > static inline void
> > omp_check_defines (void)
> > {
> > char test[(24 != sizeof (omp_lock_t)
> >
On 11/8/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
> On 11/8/05, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> > On Tue, Nov 08, 2005 at 05:00:43PM +0100, Christian Joensson wrote:
> > > Sure, here's the (relevant(?) part of) generated libgomp_f.h:
> > >
> > > static inline void
> > > omp_check
On 11/7/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
[snip]
> I have generated an SVK repository to go with this. As anyone who's
> doing or done this themselves can attest, it takes a long time and a
> lot of RAM and a whole ton of I/O.
Yes, it takes very long time, few hours before I inte
On Tue, Nov 08, 2005 at 10:37:13AM -0800, Devang Patel wrote:
> On 11/7/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> > I have generated an SVK repository to go with this. As anyone who's
> > doing or done this themselves can attest, it takes a long time and a
> > lot of RAM an
On Tue, 2005-11-08 at 13:42 -0500, Daniel Jacobowitz wrote:
> On Tue, Nov 08, 2005 at 10:37:13AM -0800, Devang Patel wrote:
> > On 11/7/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> >
> > [snip]
> >
> > > I have generated an SVK repository to go with this. As anyone who's
> > > doing or don
On Tue, Nov 08, 2005 at 01:47:52PM -0500, Daniel Berlin wrote:
> If you try to commit to the mirror, it will try to commit to the
> underlying repo.
>
> That's how svk push actually works.
Yes, of course, but what if you've checked out using a read-only
protocol? Is it going to fall down? Refus
On Tue, 2005-11-08 at 13:56 -0500, Daniel Jacobowitz wrote:
> On Tue, Nov 08, 2005 at 01:47:52PM -0500, Daniel Berlin wrote:
> > If you try to commit to the mirror, it will try to commit to the
> > underlying repo.
> >
> > That's how svk push actually works.
>
> Yes, of course, but what if you've
> > As mentioned before, there is a brace missing after the gcc_s_hpux64.
> > This brace is needed to close off the shared-libgcc rule before the
> > static-libgcc rule starts. You then must delete a brace from the end of
> > the !static rule which has one too many.
>
> Yes, doing so gives the
On Tue, Nov 08, 2005 at 07:28:45PM +0100, Christian Joensson wrote:
> > Before I experiment with that, pls note that the compiler is (default)
> > configured for target sparc64-unknown-linux-gnu and with the configure
> > option --with-cpu=v7 resulting in default v7 (32-bit) code. May this
> > "tri
Hello!
gcc-4.1.20051105
-fno-stack-protector-all is not recognised/implemented
apps built w/ -fstack-protector-all segfault
test env:
- uClibc-svn
- guard is set up like glibc does in ld.so as non-TLS version
- libssp is not used, gcc's configure check was enabled to recognize
__stack_chk_guard
Snapshot gcc-3.4-20051108 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051108/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Steve Ellcey wrote:
I am not convinced there is a bug here.
There is an extremely obvious bug here. Please look at the specs that
Albert Chin included in his email message. There is no way that
-static-libgcc should require -shared-libgcc, which is what happens in
his specs.
The only par
On Wed, 2005-11-02 at 18:02 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
>
> > For example, if the only use was inside an unreachable hunk of
> > code, does that count as a use or not?
>
> Yes, the EDG front-end does this:
>
> [EMAIL PROTECTED]:~/tmp$ cat test.cpp
> void f() {
> int i;
>
On Tue, Nov 08, 2005 at 04:00:42PM -0800, Jim Wilson wrote:
> The only part I don't understand is where these specs came from, as
> this doesn't match anything in the FSF tree. I'm guessing that HP
> is distributing a modified gcc with patches added to it, and these
> patches are buggy. I went to
On Tue, 2005-11-08 at 17:22, Albert Chin wrote:
> A .depot file is a tar file so just untar it.
Yeah, I knew that, it just took me a while to remember. I added
comments to PR 24718 explaining what the underlying problem is, and
confirming the bug. I probably can't do much more as I don't have an
> I've put a possible patch in the metabug (24639). As I mention in
> the comments, I'm not comfortable self-approving it given my lack of
> knowledge about the option processing code and the debate over what
> we want the default -Wuninitialized behavior to be.
> jeff
If it helps, I withdra
Hi All,
I'm wondering if the following behavior is:
1. An already reported bug.
2. Not reported, I need to file a bugzilla.
3. Disputed.
Here's the test case:
typedef unsigned short ushort;
namespace X
{
typedef unsigned short ushort;
}
using namespace X;
int main()
{
ushort us =
On 11/8/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> It will simply tell you you don't have access :)
However, it is rejecting local branch creation also.
---
$ svk ls /svkgcc/gcc/local_branches
Path /gcc/local_branches is not a versioned directory
bardoli:~ bardoli$ svk mkdir /svkgcc/gcc/loca
On Tue, Nov 08, 2005 at 06:41:05PM -0800, Devang Patel wrote:
> On 11/8/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>
> > It will simply tell you you don't have access :)
>
> However, it is rejecting local branch creation also.
>
> ---
> $ svk ls /svkgcc/gcc/local_branches
> Path /gcc/local_bra
On 11/8/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
>
> > Isn't this, creating local branches, is a local operation ?
>
> //gcc is a mirrored location. You have to create your branches outside
> of there; try /svkgcc/local-gcc in your example.
Yes, this works.
Thanks,
-
Devang
Howard Hinnant <[EMAIL PROTECTED]> writes:
| Hi All,
|
| I'm wondering if the following behavior is:
|
| 1. An already reported bug.
| 2. Not reported, I need to file a bugzilla.
| 3. Disputed.
|
| Here's the test case:
|
| typedef unsigned short ushort;
|
| namespace X
| {
| typedef
On 11/8/05, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 08, 2005 at 05:00:43PM +0100, Christian Joensson wrote:
> > Sure, here's the (relevant(?) part of) generated libgomp_f.h:
> >
> > static inline void
> > omp_check_defines (void)
> > {
> > char test[(24 != sizeof (omp_lock_t)
> >
I have been noticing the following error in trunk and in branch.
It looks look in libstdc++-v3 signbit,
Has it been reported yet?
/home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/
-B/usr/local/i686-pc-c
ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i686-pc-cygwin/i
nc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rui Wang wrote:
> Hi all,
>
> To transform my java RMI code to windows native code, I followed Ranjit
> Mathew's tutorial to compile gcc to a cross compiler.
> http://ranjitmathew.hostingzero.com/phartz/gcj/bldgcj.html
[...]
> After successfully
Bobby McNulty wrote:
> I have been noticing the following error in trunk and in branch.
I get no such error when compiling the trunk.
> /home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/
> -B/usr/local/i686-pc-c
> ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
> /usr/local/i686-pc-c
Brian Dessent wrote:
Bobby McNulty wrote:
I have been noticing the following error in trunk and in branch.
I get no such error when compiling the trunk.
/home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/
-B/usr/local/i686-pc-c
ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -
45 matches
Mail list logo
