Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
> Andreas Jaeger writes: Andreas> I'm not a build machinery expert - if anybody has a patch, I'll happily test it, Andreas> I'm building on Linux/Powerpc64. Andreas> Adding the above line to rs6000/x-linux64 did not help me. Btw. Andreas> we would need it for other files - like gnat1 - as well, Andreas Schwab removed x-linux64 yesterday because it was not referenced by any configuration. I know that the tmake_files are the wrong place, but just to test that it works, try adding the line to t-linux64, which is included in the powerpc64-linux configuration. Once we confirm the command is appended to LDFLAGS for executables that need it, we can figure out the correct Makefile fragment. David
dumping the tree
Hello,
I am working on a research project in which I want to export a whole
syntax/semantic tree of a c++ program from the compiler. My current
solution is to use the -fdump-tree-all option and take the *.t00.tu
files (translation unit dump). I've hacked the gcc/tree-dump.c so the
exported graph is in a machine-readable xml file.
This all works quite well in gcc 4.1.0. But I've hit a problem with
gcc 4.2 and newer - the dump now doesn't contain any function bodies.
Specificaly, in tree-dump.c::dequeue_and_dump() there is
case FUNCTION_DECL:
...
dump_child ("body", DECL_SAVED_TREE (t));
where 't' points to the FUNCTION_DECL tree. It seems that
DECL_SAVED_TREE(t) is always NULL in gcc >= 4.2.
Practically I am only interested in the gimple cfg and its basic
blocks, which I used to get via DECL_STRUCT_FUNCTION(t) - but that
doesn't work now either. Working copy of my patches is available for
your reference at http://necago.ic.cz/prj/scc/
--
Infinite diversity in infinite combinations (IDIC).
Re: getting gcc mailing list archives
Hi Ho! --- On Mon, 6/30/08, Mojmir Svoboda <[EMAIL PROTECTED]> wrote: > i have registered gcc mailing list as [EMAIL PROTECTED] > via web form, > but my client was sending the requests as > [EMAIL PROTECTED] when i fixed this > everything seems > to be working. I am glad to hear that! > thanks for kicking me in the right direction! although i am > quite > ashamed that i had to take your time, i could find this > myself, sorry > for that :) That's okay. We are here to help each other :) > many thanks again, Your welcome. > mojmir Best regards, Eus
No warning of violating strict aliasing rule and produce wrong code
Hello,
In following code, gcc (mainline version as well as previous versions)
produces wrong code without giving any warning regarding strict aliasing
violation.
~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -Wstrict-aliasing=2
./tst
barrier1
Miscompilation
If I compile with
~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -fno-strict-aliasing
./tst
Barrier1
Then it executes correctly. The problem is with LSocketId, which is cast
to a different pointer type. GCC thinks the dereferenced pointer does
not alias with the original variable and goes on to produce wrong code.
This kind of error is really difficult to detect. It would be nice to at
least give a warning. Should I report it as a bug?
Cheers,
Bingfeng Mei
Broadcom UK
tst.c
#include
unsigned long long core_id;
unsigned long bar(unsigned long extchan, unsigned long* intchan)
{
*intchan = extchan + 6;
return extchan-5;
}
__attribute__((noinline)) int foo (unsigned long *channelId)
{
long long LSocketId = *channelId;
printf("barrier1\n");
if ((core_id) == 0)
{
unsigned long destcore = bar(LSocketId, (unsigned
long*)&LSocketId);
}
return LSocketId;
}
int main(){
unsigned long a = 5;
core_id = 0;
if(foo(&a) != 11)
printf("Miscompilation\n");
}
Re: No warning of violating strict aliasing rule and produce wrong code
Bingfeng Mei wrote:
> Hello,
>
> In following code, gcc (mainline version as well as previous versions)
> produces wrong code without giving any warning regarding strict aliasing
> violation.
>
> ~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -Wstrict-aliasing=2
> ./tst
> barrier1
> Miscompilation
>
>
> If I compile with
> ~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -fno-strict-aliasing
> ./tst
> Barrier1
>
> Then it executes correctly. The problem is with LSocketId, which is cast
> to a different pointer type. GCC thinks the dereferenced pointer does
> not alias with the original variable and goes on to produce wrong code.
Actually, that's not true: the program is undefined, and therefore gcc
is not generating wrong code.
> This kind of error is really difficult to detect. It would be nice to at
> least give a warning. Should I report it as a bug?
It warns me:
zorro:~ $ gcc --version
gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
Copyright (C) 2008 Free Software Foundation, Inc.
zorro:~ $ gcc t.c -O3 -o tst -Wstrict-aliasing=2
t.c: In function 'foo':
t.c:20: warning: dereferencing type-punned pointer will break strict-aliasing
rules
zorro:~ $ ~/gcc/trunk/install/bin/gcc --version
gcc (GCC) 4.4.0 20080618 (experimental)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
zorro:~ $ ~/gcc/trunk/install/bin/gcc t.c -O3 -o tst -Wstrict-aliasing=2
t.c: In function 'foo':
t.c:20: warning: dereferencing type-punned pointer will break strict-aliasing
rules
Andrew.
#include
unsigned long long core_id;
unsigned long bar(unsigned long extchan, unsigned long* intchan)
{
*intchan = extchan + 6;
return extchan-5;
}
__attribute__((noinline)) int foo (unsigned long *channelId)
{
long long LSocketId = *channelId;
printf("barrier1\n");
if ((core_id) == 0)
{
unsigned long destcore = bar(LSocketId, (unsigned
long*)&LSocketId);
}
return LSocketId;
}
int main(){
unsigned long a = 5;
core_id = 0;
if(foo(&a) != 11)
printf("Miscompilation\n");
}
RE: No warning of violating strict aliasing rule and produce wrong code
Sorry, I made a mistake. My local copy of mainline version (still 4.3.0
20080213) doesn't gave warning. I just updated my mainline GCC and it
does give warning now.
-Original Message-
From: Andrew Haley [mailto:[EMAIL PROTECTED]
Sent: 30 June 2008 13:45
To: Bingfeng Mei
Cc: gcc@gcc.gnu.org
Subject: Re: No warning of violating strict aliasing rule and produce
wrong code
Bingfeng Mei wrote:
> Hello,
>
> In following code, gcc (mainline version as well as previous versions)
> produces wrong code without giving any warning regarding strict
aliasing
> violation.
>
> ~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -Wstrict-aliasing=2
> ./tst
> barrier1
> Miscompilation
>
>
> If I compile with
> ~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -fno-strict-aliasing
> ./tst
> Barrier1
>
> Then it executes correctly. The problem is with LSocketId, which is
cast
> to a different pointer type. GCC thinks the dereferenced pointer does
> not alias with the original variable and goes on to produce wrong
code.
Actually, that's not true: the program is undefined, and therefore gcc
is not generating wrong code.
> This kind of error is really difficult to detect. It would be nice to
at
> least give a warning. Should I report it as a bug?
It warns me:
zorro:~ $ gcc --version
gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8)
Copyright (C) 2008 Free Software Foundation, Inc.
zorro:~ $ gcc t.c -O3 -o tst -Wstrict-aliasing=2
t.c: In function 'foo':
t.c:20: warning: dereferencing type-punned pointer will break
strict-aliasing rules
zorro:~ $ ~/gcc/trunk/install/bin/gcc --version
gcc (GCC) 4.4.0 20080618 (experimental)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
zorro:~ $ ~/gcc/trunk/install/bin/gcc t.c -O3 -o tst -Wstrict-aliasing=2
t.c: In function 'foo':
t.c:20: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Andrew.
#include
unsigned long long core_id;
unsigned long bar(unsigned long extchan, unsigned long* intchan)
{
*intchan = extchan + 6;
return extchan-5;
}
__attribute__((noinline)) int foo (unsigned long *channelId)
{
long long LSocketId = *channelId;
printf("barrier1\n");
if ((core_id) == 0)
{
unsigned long destcore = bar(LSocketId, (unsigned
long*)&LSocketId);
}
return LSocketId;
}
int main(){
unsigned long a = 5;
core_id = 0;
if(foo(&a) != 11)
printf("Miscompilation\n");
}
Re: No warning of violating strict aliasing rule and produce wrong code
Bingfeng Mei wrote: > Sorry, I made a mistake. My local copy of mainline version (still 4.3.0 > 20080213) doesn't gave warning. I just updated my mainline GCC and it > does give warning now. I think that you'll find the release 4.3 version does too. While we try to ensure that gcc warns whenever it can about incorrect pointer conversions, we certainly don't do so in all cases, and the general case is, I suspect, incomputable. Andrew.
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
David Edelsohn <[EMAIL PROTECTED]> writes: >> Andreas Jaeger writes: > > Andreas> I'm not a build machinery expert - if anybody has a patch, I'll > happily test it, > Andreas> I'm building on Linux/Powerpc64. > > Andreas> Adding the above line to rs6000/x-linux64 did not help me. Btw. > Andreas> we would need it for other files - like gnat1 - as well, > > Andreas Schwab removed x-linux64 yesterday because it was not > referenced by any configuration. Ah, that explains it. > > I know that the tmake_files are the wrong place, but just to test > that it works, try adding the line to t-linux64, which is included in the > powerpc64-linux configuration. > > Once we confirm the command is appended to LDFLAGS for executables > that need it, we can figure out the correct Makefile fragment. I added now to t-linux64: cc1-dummy$(exeext) : override LDFLAGS += -Wl,--relax cc1$(exeext) : override LDFLAGS += -Wl,--relax gnat1$(exeext) : override LDFLAGS += -Wl,--relax This gets me a bit further but I do get later a build failure in configure: checking for powerpc64-suse-linux-gnu-strip... strip checking whether ln -s works... yes checking for powerpc64-suse-linux-gnu-gcc... /abuild/aj/gcc-tst/./gcc/xgcc -B/abuild/aj/gcc-tst/./gcc/ -B/opt/gcc/4.4-devel/powerpc64-suse-linux-gnu/bin/ -B/opt/gcc/4.4-devel/powerpc64-suse-linux-gnu/lib/ -isystem /opt/gcc/4.4-devel/powerpc64-suse-linux-gnu/include -isystem /opt/gcc/4.4-devel/powerpc64-suse-linux-gnu/sys-include checking for suffix of object files... configure: error: in `/abuild/aj/gcc-tst/powerpc64-suse-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 Andreas -- Andreas Jaeger, Director Platform / openSUSE, [EMAIL PROTECTED] SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpxGX4UhXEgW.pgp Description: PGP signature
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
Selon Andreas Jaeger <[EMAIL PROTECTED]>: > This gets me a bit further but I do get later a build failure in > configure: > > checking for powerpc64-suse-linux-gnu-strip... strip > checking whether ln -s works... yes > checking for powerpc64-suse-linux-gnu-gcc... /abuild/aj/gcc-tst/./gcc/xgcc > -B/abuild/aj/gcc-tst/./gcc/ > -B/opt/gcc/4.4-devel/powerpc64-suse-linux-gnu/bin/ > -B/opt/gcc/4.4-devel/powerpc64-suse-linux-gnu/lib/ -isystem > /opt/gcc/4.4-devel/powerpc64-suse-linux-gnu/include -isystem > /opt/gcc/4.4-devel/powerpc64-suse-linux-gnu/sys-include > checking for suffix of object files... configure: error: in > `/abuild/aj/gcc-tst/powerpc64-suse-linux-gnu/libgcc': > configure: error: cannot compute suffix of object files: cannot compile > See `config.log' for more details. > make[2]: *** [configure-stage1-target-libgcc] Error 1 If you've run configure even once by mistake in the source directory this is usually what you get as error when you configure and build in a build dir later on. The solution is to restart from a clean source dir. Other possibility is that you linked a base compiler with mpfr as dynamic library and you don't have them anymore in your LD_LIBRARY_PATH so it doesn't work. There's a configure flag --disable-shared or some such for MPFR, otherwise you can move the lib/*mpfr.so* somewhere else. Hope this helps, Laurent
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
[EMAIL PROTECTED] writes: > Selon Andreas Jaeger <[EMAIL PROTECTED]>: > >> This gets me a bit further but I do get later a build failure in >> configure: >> >> checking for powerpc64-suse-linux-gnu-strip... strip >> checking whether ln -s works... yes >> checking for powerpc64-suse-linux-gnu-gcc... /abuild/aj/gcc-tst/./gcc/xgcc >> -B/abuild/aj/gcc-tst/./gcc/ >> -B/opt/gcc/4.4-devel/powerpc64-suse-linux-gnu/bin/ >> -B/opt/gcc/4.4-devel/powerpc64-suse-linux-gnu/lib/ -isystem >> /opt/gcc/4.4-devel/powerpc64-suse-linux-gnu/include -isystem >> /opt/gcc/4.4-devel/powerpc64-suse-linux-gnu/sys-include >> checking for suffix of object files... configure: error: in >> `/abuild/aj/gcc-tst/powerpc64-suse-linux-gnu/libgcc': >> configure: error: cannot compute suffix of object files: cannot compile >> See `config.log' for more details. >> make[2]: *** [configure-stage1-target-libgcc] Error 1 > > If you've run configure even once by mistake in the source directory this is > usually what you get as error when you configure and build in a build dir > later > on. The solution is to restart from a clean source dir. I'm not building inside the source directory. > Other possibility is that you linked a base compiler with mpfr as dynamic > library and you don't have them anymore in your LD_LIBRARY_PATH so it doesn't > work. There's a configure flag --disable-shared or some such for MPFR, > otherwise you can move the lib/*mpfr.so* somewhere else. > > Hope this helps, The bootstrap works with make STAGE1_CFLAGS but fails when I add the LDFLAGS lines to t-linux64, so this looks different. config.log has: xgcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. Andreas -- Andreas Jaeger, Director Platform / openSUSE, [EMAIL PROTECTED] SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpdD9eEtuJfX.pgp Description: PGP signature
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
>> checking for suffix of object files... configure: error: in >> `/abuild/aj/gcc-tst/powerpc64-suse-linux-gnu/libgcc': >> configure: error: cannot compute suffix of object files: cannot compile >> See `config.log' for more details. This is the friendly way the GCC build process reports that the compiler built during the previous stage does not work. In other words, -Wl,--relax allowed cc1 to link, but the resulting executable does not run. David
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
David Edelsohn <[EMAIL PROTECTED]> writes: >>> checking for suffix of object files... configure: error: in >>> `/abuild/aj/gcc-tst/powerpc64-suse-linux-gnu/libgcc': >>> configure: error: cannot compute suffix of object files: cannot compile >>> See `config.log' for more details. > > This is the friendly way the GCC build process reports that the > compiler built during the previous stage does not work. In other words, > -Wl,--relax allowed cc1 to link, but the resulting executable does not > run. So, it means that --relax is not the right solution for the problem. I'll continue with the STAGE1_CFLAG flag but if anybody else wants me to test something, please tell me, Andreas -- Andreas Jaeger, Director Platform / openSUSE, [EMAIL PROTECTED] SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpw9pU7Kk1L9.pgp Description: PGP signature
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
> Andreas Jaeger writes: Andreas> So, it means that --relax is not the right solution for the problem. Andreas> I'll continue with the STAGE1_CFLAG flag but if anybody else wants me to Andreas> test something, please tell me, Maybe Alan will have some insight about --relax not working. Otherwise, in the past Alan has had some suggestions for swapping around the crt file order or using linker scripts to place those sections more effectively. David
Bootstrap fails on i386-pc-solaris2.10
Hi. This mornings bootstrap failed on my Solaris machine due to the recent introduction of the various C++ compatibility warnings. Here's the snippet from the build log where things failed: /export/home/arth/gnu/gcc-0630/./prev-gcc/xgcc -B/export/home/arth/gnu/gcc-0630/./prev-gcc/ -B/usr/local/i386-pc-solaris2.10/bin/ -c -O2 -march=pentium4 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wc++-compat -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -I. -I/export/home/arth/gnu/gcc.git/gcc -I/export/home/arth/gnu/gcc.git/gcc/. -I/export/home/arth/gnu/gcc.git/gcc/../include -I/export/home/arth/gnu/gcc.git/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I/export/home/arth/gnu/gcc.git/gcc/../libdecnumber -I/export/home/arth/gnu/gcc.git/gcc/../libdecnumber/dpd -I../libdecnumber /export/home/arth/gnu/gcc.git/gcc/ggc-common.c -o ggc-common.o cc1: warnings being treated as errors /export/home/arth/gnu/gcc.git/gcc/ggc-common.c: In function 'mmap_gt_pch_get_address': /export/home/arth/gnu/gcc.git/gcc/ggc-common.c:641: error: request for implicit conversion from 'void *' to 'caddr_t' not permitted in C++ /export/home/arth/gnu/gcc.git/gcc/ggc-common.c: In function 'mmap_gt_pch_use_address': /export/home/arth/gnu/gcc.git/gcc/ggc-common.c:666: error: request for implicit conversion from 'void *' to 'caddr_t' not permitted in C++ make[3]: *** [ggc-common.o] Error 1 The build also failed on my sparc-sun-solaris2.10 system. The mmap()/munmap() calls in these functions are the cause of the problem. Art Haas
Access the BIND_EXPR of a function
Hi, When I encounter a FUNCTION_DECL, I want to access the node BIND_EXPR where I can find the artificial declarations of the current functions that the compiler adds. Following what the documentation says, I use the macro DECL_SAVED_TREE which should point to the node BIND_EXPR (used as follows, DECL_SAVED_TREE (current_function_decl)). Unfortunately, this returns the STATEMENT_LIST node instead. In theory in the GIMPLE, if there are artificial declarations, FUNCTION_DECL has a child called body which points to BIND_EXPR and then BIND_EXPR has a child body which points to STATEMENT_LIST. Btw, I use GCC 4.1. Any ideas for accessing the BIND_EXPR node? Thomas
Re: Bootstrap fails on i386-pc-solaris2.10
Art Haas wrote: The build also failed on my sparc-sun-solaris2.10 system. The mmap()/munmap() calls in these functions are the cause of the problem. I have a fix in the queue. There are some more failures. Stay tuned. Andreas
trivial error in *.texi files.
Hello all,
in the MELT branch (I just committed rev 137290)
http://gcc.gnu.org/wiki/MiddleEndLispTranslator
I have the attached melt.texi file in gcc/doc/
and my gcc/doc/gccint.texi file contains
@include c-tree.texi
@include tree-ssa.texi
@include melt.texi
@include loop.texi
@include rtl.texi
@include cfg.texi
As you can see, I just added (line 147 of gccint.texi) an @include for
melt.texi
When compiling my stuff, I'm getting the following end of make output:
if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --no-split -I . -I
/usr/src/Lang/basile-melt-gcc/gcc/doc \
-I /usr/src/Lang/basile-melt-gcc/gcc/doc/include -o
doc/gccint.info /usr/src/Lang/basile-melt-gcc/gcc/doc/gccint.texi; \
fi
/usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:146: `Reference on MELT' has
no Up field (perhaps incorrect sectioning?).
/usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:138: `Tutorial about MELT' has
no Up field (perhaps incorrect sectioning?).
/usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:125: `Invoking MELT' has no Up
field (perhaps incorrect sectioning?).
/usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:101: `Building the MELT
branch' has no Up field (perhaps incorrect sectioning?).
/usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:35: `MELT overview' has no Up
field (perhaps incorrect sectioning?).
/usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:146: warning: unreferenced
node `Reference on MELT'.
/usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:138: warning: unreferenced
node `Tutorial about MELT'.
/usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:125: warning: unreferenced
node `Invoking MELT'.
/usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:101: warning: unreferenced
node `Building the MELT branch'.
/usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:35: warning: unreferenced node
`MELT overview'.
makeinfo: Removing output file `doc/gccint.info' due to errors; use --force to
preserve.
I obvious made some trivial mistake, which I cannot find easily. I am
not very familiar with *.texi & texinfo (and surprisingly, at the last
GCC summit, most of the old timers are not very familiar with it neither).
Any clues?
Thanks & regards.
PS. BTW, I would dream of using hevea http://pauillac.inria.fr/hevea/
for documentation. It accepts a familiar LaTeX format as input (more
precisely a subset of LaTeX) and produces *.texi or *.html files!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
@c Copyright (c) 2008 Free Software Foundation, Inc.
@c Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
@c -
@c MELT
@c -
@node MELT
@chapter MELT (Middle End Lisp Tranlator)
@cindex MELT
@cindex Middle End Lisp Translator
The MELT branch introduces a Lisp dialect to express middle-end analysers.
This chapter describes the dialect and how to use it.
A working knowledge of Scheme or Lisp is presupposed.
MELT was formerly known as Basilys, hence many functions or variables
have basilys in their name, and the conventional file extensions for
MELT source files is @code{.bysl}
See the @uref{http://gcc.gnu.org/wiki/MiddleEndLispTranslator,,MELT wiki page}
@menu
* MELT overview:: An overview of MELT.
* Building the MELT branch:: How to build the MELT branch.
* Invoking MELT:: Command line invocation of MELT
* Tutorial about MELT::Tutorial on how to use MELT.
* Reference on MELT:: Small MELT language reference.
@end menu
@c ===
@node MELT overview
@section MELT overview
@cindex MELT overview
Any MELT enabling compilation is really a long lasting compilation. It
is supposed that you use a powerful workstation (or laptop), and that
the MELT-enabled compilation will run a lot slower than a simple
@code{gcc -O1} compilation (hopefully doing some useful stuff). Notice
that a MELT compilation actually generates C code, compile it (using
another GCC compilation process) to a dynamically loadable library, and
load its into the MELT compilation process.
@c some sentences copied from the Wiki page. I (Basile) wrote all of them.
The MELT branch contains several (related) stuff. Everything can be
enabled or disabled at GCC configure time or at GCC run time:
@enumerate
@item a compiler probe, which enable an advanced user to display some of
the compilers internals data (but not to change them or change the
GCC compiler's behavior.
@item a Lisp dialect compiled into C code, with which one can code
sophisticated or prototypical middle end passes.
@item
Re: trivial error in *.texi files.
On Mon, Jun 30, 2008 at 11:09:28PM +0200, Basile STARYNKEVITCH wrote: >> /usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:146: `Reference on MELT' >> has no Up field (perhaps incorrect sectioning?). You have to add it to the menu manually. Look at any of the other included files for an example; the menu should be before the @include somewhere. -- Daniel Jacobowitz CodeSourcery
Re: RFC: Adding non-PIC executable support to MIPS
On Mon, Jun 30, 2008 at 01:59:19PM -0700, David VomLehn wrote: > This sounds like really good stuff and, on first reading, it all seems to > make sense to me. My only real concern is documentation of these changes. FWIW, I'll be posting our version of this project shortly, and it includes an ABI supplement. Supplemental to a somewhat hypothetical document, but there you go... -- Daniel Jacobowitz CodeSourcery
gcc-4.1-20080630 is now available
Snapshot gcc-4.1-20080630 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080630/ 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/gcc-4_1-branch revision 137297 You'll find: gcc-4.1-20080630.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20080630.tar.bz2 C front end and core compiler gcc-ada-4.1-20080630.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20080630.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20080630.tar.bz2 C++ front end and runtime gcc-java-4.1-20080630.tar.bz2 Java front end and runtime gcc-objc-4.1-20080630.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20080630.tar.bz2The GCC testsuite Diffs from 4.1-20080623 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
On Mon, Jun 30, 2008 at 11:04:43AM -0400, David Edelsohn wrote:
> > Andreas Jaeger writes:
>
> Andreas> So, it means that --relax is not the right solution for the problem.
>
> Andreas> I'll continue with the STAGE1_CFLAG flag but if anybody else wants
> me to
> Andreas> test something, please tell me,
>
> Maybe Alan will have some insight about --relax not working.
I'm definitely interested in trying to reproduce the problem as it
sounds like there might be a linker bug. Andreas, can you send me
your configure options?
> Otherwise, in the past Alan has had some suggestions for swapping
> around the crt file order or using linker scripts to place those sections
> more effectively.
These tricks would only help the particular case of reloc overflow in
branches to __do_global_{c,d}tors_aux. Something like the following
(untested!) in place of the .text output section description in
ld/scripttempl/elf.sc ought to work.
.text ${RELOCATING-0} :
{
${RELOCATING+${TEXT_START_SYMBOLS}}
*crtend.o(.text .stub${RELOCATING+ .text.* .gnu.linkonce.t.*})
*crtend?.o(.text .stub${RELOCATING+ .text.* .gnu.linkonce.t.*})
*(EXCLUDE_FILE (*crtbegin.o *crtbegin?.o) .text .stub${RELOCATING+ .text.*
.gnu.linkonce.t.*})
*crtbegin.o(.text .stub${RELOCATING+ .text.* .gnu.linkonce.t.*})
*crtbegin?.o(.text .stub${RELOCATING+ .text.* .gnu.linkonce.t.*})
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
${RELOCATING+${OTHER_TEXT_SECTIONS}}
} =${NOP-0}
--
Alan Modra
Australia Development Lab, IBM
Re: How to implement conditional execution
On Fri, Jun 27, 2008 at 03:52:22PM +0530, Mohamed Shafi wrote: > Hello all, > > For the 16-bit target that i porting now to gcc 4.1.2 doesn't have any > branch instructions. It only has jump instructions. For comparison > operation it has this instruction: > > if cond Rx Ry > execute this insn > > So compare and branch is implemented as > > if cond Rx Ry > jmp Label > > If the condition in the 'if' instruction is satisfied the processor > will execute the next instruction or it will replace with a nop. So > this means that i can instructions similar to: > > if eq Rx, Ry > add Rx, Ry > add Rx, 2 > > This is similar to conditional execution. This way any instruction can > be executed conditionally. But this is different from normal. Normally > the comparison operations set the status flags. An instruction gets > conditionally executed based on these flags. This means that GCC can > schedule instructions between the comparison instruction and the > conditional instruction, provided none of the scheduled instructions > are altering the status flags. This is not possible in my case as > there shouldn't be any instruction between 'if eq Rx, Ry' and 'add Rx, > Ry' and this is not as such an comparison operation and 'if' > instruction doesn't set any status flags. > > Will it be possible to implement this in the Gcc backend ? > Does any other targets have similar instructions? This is do-able. The usual method is to store the operands to the comparison in global variables, and then when you issue the branch, conditional move, etc. use the global variables, and recreate appropriate branch. Be sure to mark the global variables with the GTY(()) macro. I would suggest having the JUMP insn patterns look like other ports, using the IF_THEN_ELSE pattern, and then add the full COND_EXEC support. -- Michael Meissner email: [EMAIL PROTECTED] http://www.the-meissners.org
Feature request - a macro defined for GCC
I would like to see that GCC define a macro in the case it is being used to compile a program. Currently there is a __GNUC__ macro defined by the GNU C preprocessor CPP. That does not suit the need. As the CPP Manual says: __GNUC__ is "defined by all GNU compilers that use the C preprocessor". It seems to imply that any (non-GNU) compiler that uses the GNU C preprocessor would also have __GNUC__ defined. According to their respective manuals, Intel C++ Compiler and Portable C Compiler also pre-define __GNUC__, possibly because they use the GNU CPP. Therefore, the fact that __GNUC__ is defined does not necessarily mean the GCC compiler proper is being used. There is a need for a macro that definitely confirms that GCC is being used. (It is another matter if another complier deliberately misleads people by defining the same macro.) And I hope that macro can be documented in the GCC Manual. _ Need to know now? Get instant answers with Windows Live Messenger. http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_062008
free (static_array)
Hi All,
Can you please let me know why GCC does not crib when we try to free a static
array?
main ()
{
char array[100];
free (array);
}
The above code compiles without any hitch.
Thanks,
Sajish.
