Just really ! The array arr has the type void ***, the cast happens on the
first derefencing of arr. So the result remains a void **, which is for
sure a pointer. This leads to a pointer truncation,
therefore to a warning and a build failure. It is clear, that the first
element of the array ar
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> We should use current CVS HEAD libtool. We definitely can't use 1.5
> releases without *a lot* of auditing of local changes: we've allowed local
> changes into GCC's libtool on the basis that there are equivalents in CVS
> HEAD (this is the polic
Please stop top-posting.
Kai Tietz writes:
>
> Richard Henderson <[EMAIL PROTECTED]>
> 08.03.2007 19:08
>
> > On Thu, Mar 08, 2007 at 06:06:57PM +0100, Kai Tietz wrote:
> > > > In gcc the file emutls.c assumes that a long has sizeof void * in
> > function
> > > > emutls_destroy.
> >
Aurora SPARC Linux release 2.90 (Aurora Corona)/TI UltraSparc IIi (Sabre) sun4u:
binutils-2.17.50.0.3-6.sparc.sparc
bison-2.3-2.1.sparc
dejagnu-1.4.4-5.1.noarch
expect-5.43.0-5.1.sparc
gcc-4.1.1-30.1.sparc
glibc-2.5-3.1.sparcv9
glibc-2.5-3.1.sparc64
glibc-devel-2.5-3.1.sparc
glibc-devel-2.5-3.1.s
Hallo,
There is another point in libiberty, which has a problem with
integer-values and pointer sizes. This small patch should fix.
ChangeLog:
2007-03-06 Kai Tietz <[EMAIL PROTECTED]>
* splay-tree.h (splay_tree_key): type declared as ptrdiff_t
(splay_tree_value): Ditto
Pa
Hallo,
I detected, that ptrdiff_t is not declared in all places, therefore the
use of size_t seems to be more correct.
Regards,
i.A. Kai Tietz
jimmy wrote:
Steven Bosscher wrote:
Hi,
I found this old patch
(http://gcc.gnu.org/ml/gcc-patches/2003-06/msg01669.html) that refers
to pages 202-214 of Muchnick's "Advanced Compiler Design and
Implementation" book. That book still is not in my own compiler books
collection because of its pri
Dear GCC Developers,
I have a rather simple piece of a "call_value" instruction pattern in my
machine description:
---snip---
(define_insn "call_value"
[(set (match_operand 0 "" "")
(call (match_operand:QI 1 "" "")
(match_operand:SI 2 "" "")))]
""
"jal\\t%S0%("
[(set_attr
Hi,
If you like maths, a short book "Scheduling and Automatic Parallelization"
by Alain Darte, Yves Robert, and Frederic Vivien, not publicized as much
as the books proposed by Vladimir, provides more formal background
than what you can find in classical compiler literature.
I would also recommen
Markus Franke <[EMAIL PROTECTED]> writes:
> What am I doing wrong? It seems so simple but I can't figure out what's
> wrong with my pattern.
Run the compiler under gdb and do a backtrace to see where the ICE is
coming from.
Ian
Vladimir, you forgot a good book:
o Y.N. Srikant P.Shankar.
The Compiler Design Handbook: Optimizations and Machine Code Generation.
CRC Press 2003. Upto page 916.
Good topics:
9. Scalar Compiler Optimizations on the Static Single Assignment (SSA) Form
and the Flow Graph
by Y.N. Sr
Thus we may consider adding a -fstdcall option to gfortran, which
appends the @n. The -mrtd would be needed additionally and it seems to
work. (That I don't get @n in C for __stdcall might because I tested
under Linux.)
On mingw, I get the following:
$ cat a.c
int foo(int x) { return x+1; }
$ g
J.C. wrote:
Vladimir, you forgot a good book:
o Y.N. Srikant P.Shankar.
The Compiler Design Handbook: Optimizations and Machine Code
Generation.
CRC Press 2003. Upto page 916.
Thanks for reminding. I know about this book but I did not read it. It
looks very interesting but it is e
It might be considered a backend issue, but in general it
is a binutils (so OP is in the wrong list!).
I beg to disagree with the "in general it is a binutils issue" part.
One of the posters explained why the information needed for name
decoration can't be determined at link-time (nor at assembl
On Fri, Mar 09, 2007 at 08:36:25AM -0500, Vladimir N. Makarov wrote:
> o Muchnik book is a fat one. Muchnick's book is rather encyclopedia
> of optimizations and can be considered as collection of articles with
> many details (sometimes too many). But some themes (like RA and
> scheduling) are d
On 3/9/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
o Muchnik book is a fat one. Muchnick's book is rather encyclopedia
of optimizations and can be considered as collection of articles with
many details (sometimes too many). But some themes (like RA and
scheduling) are described not dee
Maxim Kuvyrkov <[EMAIL PROTECTED]> wrote on 04/03/2007 11:53:47:
> Hi.
>
> I want to share some of my thoughts and doings on improving / cleaning
> up current GCC instruction scheduler (Haifa) - most of them are just
> small obvious improvements.
>
> I have semi-ready patches for about a half of t
Snapshot gcc-4.3-20070309 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070309/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
I have made some progress in updating libtool in the src (binutils) tree
and I have attached the various changes (but not the actual new libtool
files) to this email in case anyone wants to see what I am doing.
I am having more trouble with the GCC tree. I put the new libtool in
the toplevel dire
Steve Ellcey <[EMAIL PROTECTED]> writes:
> $ aclocal
> autom4te: unknown language: Autoconf-without-aclocal-m4
> aclocal: autom4te failed with exit status: 1
Looks like you have an out-of-date autom4te.cache.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Ma
> Steve Ellcey <[EMAIL PROTECTED]> writes:
>
> > $ aclocal
> > autom4te: unknown language: Autoconf-without-aclocal-m4
> > aclocal: autom4te failed with exit status: 1
>
> Looks like you have an out-of-date autom4te.cache.
>
> Andreas.
I removed autom4te.cache and reran aclocal. Same results.
Andrew MacLeod wrote:
> There are a handful I've been involved with which are labeled as
> 4.0/4.1/4.2/4.3 regressions which I don't see ever being fixed in 4.0
> through 4.2. There is perhaps some hope for 4.3, but 4.4 is the more
> likely case. They require new development work that I think is u
>
> On mingw, I get the following:
>
> $ cat a.c
> int foo(int x) { return x+1; }
> $ gcc.exe -mrtd a.c -shared -o a.dll
> $ nm a.dll | grep foo
> 100011c0 T _foo
>
> $ cat b.c
> int __stdcall foo(int x) { return x+1; }
> $ gcc.exe b.c -shared -o b.dll
> $ nm b.dll | grep foo
> 100011c0 T [EMA
On Fri, Mar 09, 2007 at 03:58:40PM -0800, Steve Ellcey wrote:
> I am having more trouble with the GCC tree. I put the new libtool in
> the toplevel directory, just like I did in the binutils src tree and
> then I went to the boehm-gc (and libffi) directories to try and rerun
> autoconf. If I just
24 matches
Mail list logo
