gcc-help needed

i have added my own pass and i am trying to find out the number of variable declarations in a C program the code is attached for your reference http://www.nabble.com/file/p24656019/gccwk09.c gccwk09.c i am getting an error like this whats wrong kindly help me mainD.1181 = 0; return D.1181; *

Re: merging VTA: what does it take?

On Sat, Jul 25, 2009 at 1:19 AM, Alexandre Oliva wrote: > So...  It's been a long journey, but I think I'm at a point in which, > even though VTA is not completely finished, it's already enough of an > improvement that it could go in, be useful and get wider testing. > > To the best of my knowledge

RE: As-if Infinitely Ranged Integer Model

Joseph, Comments below. Then you are building on the runtime-constraint mechanism and rsize_t of TR 24731-1. TR 24731-1 is considered useless in the Linux world, and not implemented in the GNU C Library, and with good reason; see . I

Re: Bootstrap failure configuring in-tree gmp in mainline

* Bradley Lucier wrote on Wed, Jul 15, 2009 at 10:37:56PM CEST: > After configuring > > Target: x86_64-unknown-linux-gnu > gcc version 4.5.0 20090715 (experimental) [trunk revision 149654] (GCC) > > with > > ../../mainline/configure --enable-checking=release > --prefix=/pkgs/gcc-mainline-mem-s

Re: Gimple Pass

Hi Nathan I looked into tree.def, I added a case in the new gimple pass to count the number of integer variables in the c code. the following is the piece of code. Here, the first case is working, but I'm not getting the second one. can u pls help in this regard. How to trace thru the other cod

Re: Gimple Pass

On Sat, Jul 25, 2009 at 1:28 PM, pms wrote: > > Hi Nathan >   I looked into tree.def, I added a case in the new gimple pass to count > the number of integer variables in the c code. the following is the piece of > code. > Here, the first case is working, but I'm not getting the second one. can u >

Re: gcc-help needed

anandulle wrote: > total no of increment count :: 0 > > > /home/ulle/gcc/native/cprog/pg1.c: In function ‘main’: > /home/ulle/gcc/native/cprog/pg1.c:7: internal compiler error: Segmentation > fault When you've been adding code to GCC and you see a seg fault crop up like this, it u

Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40857 There's a clash between the FOPEN macro used by Ada (defined in adaint.h to hide 32/64-bit file i/o selection) and an identically named macro defined in newlib's sys/_default_fcntl.h. Since they're only used in a few places, I think that pro

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

Dave Korn wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40857 There's a clash between the FOPEN macro used by Ada (defined in adaint.h to hide 32/64-bit file i/o selection) and an identically named macro defined in newlib's sys/_default_fcntl.h. Since they're only used in a few places

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

Dave Korn wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40857 There's a clash between the FOPEN macro used by Ada (defined in adaint.h to hide 32/64-bit file i/o selection) and an identically named macro defined in newlib's sys/_default_fcntl.h. Since they're only used in a few places

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

Robert Dewar wrote: > > __gnat_ seems like it would be more consistent with the other > definitions in adaint.h, but it's not critical certainly. Well, but they're macros rather than functions, and I personally don't like to hide the difference. I ended up doing this because it makes them look

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

> Ah, and I see you also had an after-thought in a second reply. I'll respin > this if you think it's horribly ugly, otherwise I'll send it to -patches with > a changelog once the build has finished. It is indeed ugly. I'd use GNAT_STRUCT_STAT and GNAT_FOPEN instead. Since these are macros, I

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

Isn't it the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578 Were I suggested GNAT_FOPEN (and you commented too)? Sincerely, Laurent On Sat, 2009-07-25 at 16:30 +0100, Dave Korn wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40857 > > > There's a clash between the FOPEN mac

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

Arnaud Charlet wrote: Ah, and I see you also had an after-thought in a second reply. I'll respin this if you think it's horribly ugly, otherwise I'll send it to -patches with a changelog once the build has finished. It is indeed ugly. I'd use GNAT_STRUCT_STAT and GNAT_FOPEN instead. That

Re: Any ada maintainers out there this afternoon? (Ada bootstrap broken on newlib targets)

Laurent GUERBY wrote: > Isn't it the same as > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578 > > Were I suggested GNAT_FOPEN (and you commented too)? Oh, thanks for the reminder. Yes, it is, so I marked the new one as a dup and took the assignment of the first one. I'll respin the patc

Re: Bootstrap failure configuring in-tree gmp in mainline

Thanks for your reply. On Jul 25, 2009, at 7:18 AM, Ralf Wildenhues wrote: Does /home/lucier/programs/gcc/objdirs/mainline/./prev-gcc/g++ exist, No. and if yes, is it a functioning executable? If it doesn't exist, that looks like the toplevel logic for which languages to build still has a

Re: Bootstrap failure configuring in-tree gmp in mainline

Am i missing something? No, it is a bug due to the build-with-C++ patches. Please file a PR and, in the meanwhile, try --enable-stage1-languages=c,c++ or --enable-build-with-cxx. Thanks! Paolo

Re: Bootstrap failure configuring in-tree gmp in mainline

On Jul 25, 2009, at 12:54 PM, Paolo Bonzini wrote: Am i missing something? No, it is a bug due to the build-with-C++ patches. Please file a PR and, in the meanwhile, try --enable-stage1-languages=c,c++ That seemed to work, thanks, bootstrap has gotten past my old problem. or --enable-b

Re: Bootstrap failure configuring in-tree gmp in mainline

On Jul 25, 2009, at 2:16 PM, Bradley Lucier wrote: On Jul 25, 2009, at 12:54 PM, Paolo Bonzini wrote: Am i missing something? No, it is a bug due to the build-with-C++ patches. Please file a PR and, in the meanwhile, try --enable-stage1-languages=c,c++ That seemed to work, thanks, bo

Re: Bootstrap failure configuring in-tree gmp in mainline

Am i missing something? No, it is a bug due to the build-with-C++ patches. Please file a PR and, in the meanwhile, try --enable-stage1-languages=c,c++ That seemed to work, thanks, bootstrap has gotten past my old problem. Ah, I was too quick, it failed again at the next bootstrap stage.

Compiling programs licensed under the GPL version 2 with GCC 4.4

Kalle Olavi Niemitalo discovered that as an operating system vendor, you are not allowed to distribute GPL version 2 programs if they are compiled with GCC 4.4. The run-time library is GPL version 3 or later, which is incompatible with GPL version 2, so it is not permitted to link this with the GP

Re: Failure in a complete build of current gcc snapshot

OK, it seems that this failure happens *only* on Cygwin: I have tried on GNU/Linux Kubuntu 8.04 and it works... For what I have understood, this failure remembers, in some manner, what is discussed in this thread [1], and beside this... Dave, ...are the files with an '*' in their names, like

Re: Failure in a complete build of current gcc snapshot

Angelo Graziosi wrote: > > ...are the files with an '*' in their names, like libstdc++*-gdb.py, > allowed on Cygwin? No, it's a glob match, the makefile expects there to be something to match that pattern but there isn't so the shell returns it verbatim instead of expanding it. The reason why

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

On Sat, Jul 25, 2009 at 01:53:40PM -0700, Florian Weimer wrote: > Kalle Olavi Niemitalo discovered that as an operating system vendor, > you are not allowed to distribute GPL version 2 programs if they are > compiled with GCC 4.4. The run-time library is GPL version 3 or > later, which is incompat

Re: Compiling programs licensed under the GPL version 2 with GCC 4.4

* Joe Buck: > On Sat, Jul 25, 2009 at 01:53:40PM -0700, Florian Weimer wrote: >> Kalle Olavi Niemitalo discovered that as an operating system vendor, >> you are not allowed to distribute GPL version 2 programs if they are >> compiled with GCC 4.4. The run-time library is GPL version 3 or >> later