On 3/24/06, David S. Miller <[EMAIL PROTECTED]> wrote:
> From: Eric Botcazou <[EMAIL PROTECTED]>
> Date: Fri, 24 Mar 2006 00:04:41 +0100
>
> > Or maybe ELF 64-bit MSB since I'm seeing -m64 on the command line?
>
> Hey might have showed the wrong command line, since this
> library is multi-libbed.
On Mar 18, 2006, at 6:47 AM, jayaraj wrote:
I want to profile an application in linux. I used -pg option and
profiled the data with gprof. Here I am getting the resolution in
seconds only. but I wants in terms of milliseconds and microseconds.
can anybody help me. or any other options and tools a
Hi,
Building glibc 4.0.2 with gcc 3.2.2 on a redhat machine causes a
compile error about some CFI assembler support. Any ideas would be
welcome
Cheers
Piyush
Is there any solution to fix the troubles which result from the change
to the name mangling algorithm between 3.2 and 2.95 ?
thanks
Piyush
--
My blog http://verypondycherry.blogspot.com
I meant other than recompiling the code of course. I have some
binaries without the source code. does 3.2 support the old mangling
algorithm.
thanks
Piyush
--
My blog http://verypondycherry.blogspot.com
On 3/24/06, Piyush Garyali <[EMAIL PROTECTED]> wrote:
> Is there any solution to fix the trou
I have successfully forward ported libffi changes from 4.0 to 4.2,
but I have some problems running the testsuite. Here are the results:
# of expected passes1052
# of unexpected failures8
# of unsupported tests 8
Looking at the failures, I have:
FAIL: libffi.call/
On Mar 23, 2006, at 2:02 PM, Laura Tardivo wrote:
Hello, my name is Laura and I need to know where I could find or
download the
oldest version of de "C" compiler. I look forward to hearing from you.
You can find what we have in svn, see our web site. -r1 would be the
oldest bits we have, t
On Mar 24, 2006, at 1:49 AM, Piyush Garyali wrote:
I meant other than recompiling the code of course. I have some
binaries without the source code. does 3.2 support the old mangling
algorithm.
Sure, just re-implement the 2.95 abi in 3.2 if you think that is
better than re-implementing code th
On 24/mar/2006, at 10:50, Sandro Tolaini wrote:
I'm attaching the patch against a current svn checkout.
Forgot to say that boehm-gc needs to be upgraded to 6.7. I've not
included patches for this, simply import it from the original
distribution.
Cheers,
Sandro
smime.p7s
Descriptio
Dear gcc/binutils maintainers,
During bootstrap of gcc-4.0 (4.0.3-1 Debian) on ARM
with VFP (--with-float=soft, --with-fpu=vfp) and binutils
2.16.1cvs20060117-1.my I stumbled upon the following issue. The
linkage of libgcc_s.so.1 fails because of multiple errors such as:
"ld: *_s.o uses VFP ins
Hello,
I was one of the developers of the GCC Hello World, together with
Rafael Espíndola and I want to assign my copyright to GNU so it can be
included in GCC trunk.
What do I have to do?
Thanks,
--
Gustavo Sverzut Barbieri
--
Jabber: [EMAIL PROTECTED]
MS
On Mar 24, 2006, at 4:50 AM, Sandro Tolaini wrote:
I have successfully forward ported libffi changes from 4.0 to 4.2,
but I have some problems running the testsuite. Here are the results:
# of expected passes1052
# of unexpected failures8
# of unsupported tests 8
Hi,
We have a problem with Kazu's following patch:
2005-12-26 Kazu Hirata <[EMAIL PROTECTED]>
PR tree-optimization/25125
* convert.c (convert_to_integer): Don't narrow the type of a
PLUX_EXPR or MINUS_EXPR if !flag_wrapv and the unwidened type
is signed.
that i
On Fri, 24 Mar 2006, Eric Botcazou wrote:
> After the change it is simplified to (int)((unsigned int)j + (unsigned int)o).
> Now take j=0 and o=-1. There is signed-overflow undefinedness neither in the
> original expression nor in the original simplified expression while there is
> in the new s
> This is of course a definition of C semantics rather than tree semantics,
> but I believe our trees follow the C semantics here.
Not quite, TREE_OVERFLOW is set on the result. And the C front-end has
explicit code to unset it:
build_c_cast:
/* Ignore any integer overflow caused by the c
On Tuesday 21 March 2006 21:59, Jeffrey A Law wrote:
> On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
>
> > Hi Jeff, on the subject of seeing through typecasts, I was playing around
> > with VRP and noticed that the following "if" statement is not eliminated:
> >
> > int u (unsigned char
On Fri, 24 Mar 2006, Eric Botcazou wrote:
> > This is of course a definition of C semantics rather than tree semantics,
> > but I believe our trees follow the C semantics here.
>
> Not quite, TREE_OVERFLOW is set on the result. And the C front-end has
> explicit code to unset it:
Setting TREE_
On Fri, 2006-03-24 at 18:50 +0100, Duncan Sands wrote:
> Hi Jeff, while your patch catches many cases, the logic seems a bit wonky
> for types with TYPE_MIN/TYPE_MAX different to those that can be deduced
> from TYPE_PRECISION. For example, there is nothing stopping inner_type
> having a bigger T
On Fri, Mar 24, 2006 at 03:15:58PM +0530, Piyush Garyali wrote:
> Is there any solution to fix the troubles which result from the change
> to the name mangling algorithm between 3.2 and 2.95 ?
The troubles do not result from the name mangling algorithm. If anything,
the incompatible name mangling
Snapshot gcc-4.1-20060324 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060324/
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
Hi,
I'm trying to port bring the GNU Modula-2 front end up to gcc-4.1.0
and have found out that SET_TYPE has been removed :-)
I see the patch from Dec 2004:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00670.html
and understand the reason (no front ends in gcc tree use SET_TYPE
etc). I suppose
> Pragmatically I guess it is best for me to maintain a reversed patch
> which can be applied to a gcc-4.1.0 tar ball which reintroduces this
> TYPE. Any thoughts?
Integrating the Modula-2 front-end?
--
Eric Botcazou
Hello all,
>From a call like
categorize_ctor_elements (ctor, &num_nonzero_elements,
&num_nonconstant_elements,
is 'num_nonconstant_elements == 0' expected to convey the same as
initializer_constant_valid_p (ctor, TREE_TYPE (ctor)) ?
The code in gimplify
23 matches
Mail list logo
