Re: adding ability to scan few local variables in GGC?

Hello All, Andrew Pinski wrote: On Sun, Oct 12, 2008 at 1:15 PM, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: Hello All, I am sometimes wishing to be able to scan some few local variables in GCC garbage collector, GGC. The only time I can think of when you want to do that is when the pass

On the requirements of offsetof Macro in C++.

Hello, The standard header provides the macro 'offsetof(type, member-designator)'. The current C++ ISO/IEC standard 14882 dictates, I believe, that 'type' should be a POD. Recent versions of the working drafts have somewhat relaxed the requirements, introducing the concept of "Standard-Layout".

Re: Does GCC support segmented memory ?

Dong Phuong <[EMAIL PROTECTED]> writes: > I'm porting for a microcontroller which support > segment memory. But I don't know how to porting GCC so > that it can understand addresses in different memory > segment. > For example, I want to create seperate code segment > and data segment. > > Is it p

Re: install path in libgcc Makefile.in

On 17:36 Sat 11 Oct , Daniel Jacobowitz wrote: > > The patch is included. > > If you've tested it, send it to gcc-patches. I will test in 3 cases: build = host = target build = host != target build != host = target Now the first two are finished. I am using the compiler get in step to run ca

Re: adding ability to scan few local variables in GGC?

On Sun, Oct 12, 2008 at 1:15 PM, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > Hello All, > > I am sometimes wishing to be able to scan some few local variables in GCC > garbage collector, GGC. The only time I can think of when you want to do that is when the pass creates lots of garbage. The

adding ability to scan few local variables in GGC?

Hello All, I am sometimes wishing to be able to scan some few local variables in GCC garbage collector, GGC. One could imagine, for instance, that some passes would prefer, instead of using static GTY-ed variables, to declare some local GTY-ed structure LS , and to explicitly invoke the GGC

Re: For some class F, I can declare a variable of type F::F, or F::F::F, etc.

David Fang wrote: We come across what seems to be a bug in gcc. If a class F has a public zero argument constructor, then we can declare a variable of type F::F, F::F::F, etc. For example, the following source file: // foo.cpp class F {}; F::F::F::F::F f; See: http://gcc.gnu.org/bugzilla

Re: For some class F, I can declare a variable of type F::F, or F::F::F, etc.

We come across what seems to be a bug in gcc. If a class F has a public zero argument constructor, then we can declare a variable of type F::F, F::F::F, etc. For example, the following source file: // foo.cpp class F {}; F::F::F::F::F f; See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11

eamonn raymona deepak

camille laura maryam

Can not use correct shared lib version.

Hi, I use cross-compiler to build my code in my PC Linux environment, and put the executable binary to another hardware board ( embedded Linux in this board). I get the message said"error while loadingshard libraries: libdl.so.0: cannot open shared object file: No such file or directory ..." I h

Does GCC support segmented memory ?

I'm porting for a microcontroller which support segment memory. But I don't know how to porting GCC so that it can understand addresses in different memory segment. For example, I want to create seperate code segment and data segment. Is it possible in GCC ? and if the answer is "yes", how can I d

For some class F, I can declare a variable of type F::F, or F::F::F, etc.

Hi, We come across what seems to be a bug in gcc. If a class F has a public zero argument constructor, then we can declare a variable of type F::F, F::F::F, etc. For example, the following source file: // foo.cpp class F {}; F::F::F::F::F f; compiles with out errors in g++. The resu

Re: question. type long long

Александр Струняшев wrote: > Good afternoon. > I need some help. As from what versions your compiler understand that > "long long" is 64 bits ? > > Best regards, Alexander > > P.S. Sorry for my mistakes, I know English bad. No need to be sorry about English, but the topic is OK for gcc-help, not

Re: [graphite] Cleanup of command line parameters [PATCH]

Hi, On Sun, 2008-10-12 at 13:19 +0200, Tobias Burnus wrote: > Hi, > > Tobias Grosser wrote: > > another patch. It contains: > > > > - Removal of documentation outside of common.opts for (-fgraphite, > > -floop-block, -floop-interchange, -floop-strip-mine) > > This means doc/invoke.texi. > >

Re: [graphite] Cleanup of command line parameters [PATCH]

Hi, Tobias Grosser wrote: > another patch. It contains: > > - Removal of documentation outside of common.opts for (-fgraphite, > -floop-block, -floop-interchange, -floop-strip-mine) > This means doc/invoke.texi. > (Proposed by Richi) While I agree that -fgraphite does not make sense as use

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

On Fri, 10 Oct 2008 11:24:22 + (UTC) "Joseph S. Myers" <[EMAIL PROTECTED]> wrote: > On Fri, 10 Oct 2008, Thorsten Glaser wrote: > > > Thomas Schwinge dixit: > > > > >Ideally, IMO, this test (for stack-smashing-protection support in > > >glibc) should not be done by grepping through SYSROOT's

question. type long long

Good afternoon. I need some help. As from what versions your compiler understand that "long long" is 64 bits ? Best regards, Alexander P.S. Sorry for my mistakes, I know English bad.