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 w

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

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

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/

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 >

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.

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

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. > Andr

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

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..

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 th

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

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 worki

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/i3

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,

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.

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;

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

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

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, plea

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 >

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"

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.