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.

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

[Tobias Burnus]

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 user option, I'm
not sure about -floop-block and -floop-interchange. I could imagine that
some users would like to play with this option (though I have no real
opinion about this).

> - Removal of flag "-floop-strip-mine", as it never will improve 
>   performance and so there will be no use for it.
>   (Proposed by Harsha)

I might have misunderstood Harsha, but I think he said that it only does
not improve the performance if used by itself, i.e. combined with other
options it is/might be profitable. Thus one may leave it in as
undocumented option. (I have no opinion about this and I did no tests, I
only wanted to stress the "by itself".)

In any case, those changes should also be documented at
http://gcc.gnu.org/gcc-4.4/changes.html, which currently lists all options.

Tobias B

Re: build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

[Kai Henningsen]

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
> > >features.h, but instead by using the CPP for doing that.
> > 
> > Why not just autoconf?
> > 
> > Check for the presence of __stack_smash_handler() in libc… or am I
> > missing something important here?
> 
> It's desirable to be able to configure GCC correctly in the presence
> of installed headers and only a dummy libc.so, so as to get a GCC
> that can be used to build the full glibc.  See e.g. the documented
> bootstrap procedure at 
> .
>   
> As such, testing for features of the libc binary in order to build
> the core compiler is a bad idea.  The more configuration dependencies
> you put between the compiler and the library, the more complicated
> the bootstrap procedure becomes.

So ... we have a list of possible paths for various target variants.
Why not simply look into all of them? The list isn't particularly long,
and there's no reason to assume more than one will be available ... or
is there?

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

[Tobias Grosser]

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.
> >   (Proposed by Richi)
> 
> While I agree that -fgraphite does not make sense as user option, I'm
> not sure about -floop-block and -floop-interchange. I could imagine that
> some users would like to play with this option (though I have no real
> opinion about this).

The problem I see is, that these options are for me like intermediate
demonstration options, as graphite should get an automatic optimizer. So
I am not sure what to do. I see these options:

1. Keep them until we have these optimizer:

Here we have the problem what to do after that. We could simply ignore
them or we make them like hints to allow the optimizer trying specific
transformations. But I think, it may not even be possible to try to
disable specific optimizations in all cases while using the polytop
model.
So we may have options just used in one or two releases.

2. Keep them like the -fgraphite options hidden, but allow interested
user to try graphite. So we get interested testers, but do not have to
keep these - maybe later misleading - options forever.

> 
> > - Removal of flag "-floop-strip-mine", as it never will improve 
> >   performance and so there will be no use for it.
> >   (Proposed by Harsha)
> 
> I might have misunderstood Harsha, but I think he said that it only does
> not improve the performance if used by itself, i.e. combined with other
> options it is/might be profitable. Thus one may leave it in as
> undocumented option. (I have no opinion about this and I did no tests, I
> only wanted to stress the "by itself".)

No I am quite sure, we do not need this flag. Yes you are right strip
mining can help combined with loop interchange to improve performance.
But this is -floop-block and already available.

> 
> In any case, those changes should also be documented at
> http://gcc.gnu.org/gcc-4.4/changes.html, which currently lists all options.
> 
> Tobias B

Thanks for your comments and please correct me, if I said something
wrong/could say something better. I am quite new to the gcc development
so every hint is appreciated. 

see you

Tobias

Re: question. type long long

[Tim Prince]

Александр Струняшев 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
gcc development.
gcc was among the first compilers to support long long (always as 64-bit),
the only problem being that it was a gnu extension for g++. In that form,
the usage may not have settled down until g++ 4.1. The warnings for
attempting long long constants in 32-bit mode, without the LL suffix, have
been a subject of discussion:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13358
The warning doesn't mean that long long could be less than 64 bits; it
means the constant without the LL suffix is less than 64 bits.

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

[Weiqi Gao]

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 result is as if  f  is declared with

  F f;

This is the case with the stock/latest GCC in Debian GNU/Linux x86_64 
(v.4.1.2) and in Cygwin (v.3.4.4).


Is this the intended behavior?

--
Weiqi Gao
[EMAIL PROTECTED]
http://www.weiqigao.com/blog/

Does GCC support segmented memory ?

[Dong Phuong]

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 do that ? 

Thank you very much.


  

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 have add library path to environment, but I still encountered this error.
Actually, my Linux only has libdl.so.2 file, not have libdl.so.0. However, if I 
build this code with the gcc tool chain of my PC Linux, the executable binary 
can be exectued in PC.

Anything I need to do?

Many thanks!!

Chiyung Liao.



  
__
付費才容量無上限？Yahoo!奇摩電子信箱2.0免費給你，信件永遠不必刪！ http://tw.mg0.mail.yahoo.com/dc/landing

eamonn raymona deepak

[bryce ramana]

camille 
laura maryam 

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

[David Fang]

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=11764

Still accepts-invalid with g++-4.3.2.


compiles with out errors in g++.  The result is as if  f  is declared with
 F f;
This is the case with the stock/latest GCC in Debian GNU/Linux x86_64 
(v.4.1.2) and in Cygwin (v.3.4.4).

Is this the intended behavior?


No.  :)

Fang

David Fang
Computer Systems Laboratory
Electrical & Computer Engineering
Cornell University
http://www.csl.cornell.edu/~fang/
-- (2400 baud? Netscape 3.0?? lynx??? No problem!)

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

[Weiqi Gao]

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/show_bug.cgi?id=11764

Still accepts-invalid with g++-4.3.2.


Thanks for the pointer.

--
Weiqi Gao
[EMAIL PROTECTED]
http://www.weiqigao.com/blog/

adding ability to scan few local variables in GGC?

[Basile STARYNKEVITCH]

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 collector with a pointer to LS and 
its marking routine (as generated by gengtype).


As a fictional example, suppose some pass is building a gimple_seq 
stored in a local gs. It could perhaps call the GGC garbage collector as

ggc_collect_with_local(gs, gt_ggc_mx_gimple_seq_node_d);


So I am suggesting that we could extend the API in gcc/ggc.h with an 
additional function ggc_collect_with_local which takes a pointer to a 
single local structure (inside the call stack) and a marking routine 
(usually generated by gengtype) for this pointer and do a collection 
with marking the additional stuff. We might restrict that the passed 
pointer is on the call stack (or on the contrary in the GGC heap).


what do people think about this idea? I might consider writing such a 
patch (last time I looked, it seems not too hard) when GCC goes back 
into stage 1.


(and such a patch actually could help the MELT branch).

Regards.
--
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} ***

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

[Andrew Pinski]

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 only pass I can think of that might
cause that much garbage is the inliner but even then it would only be
make stuff dead rather than creating new data structures which are
dead.

Can you give a more concrete example of why you want this?  I would
say stay away from using the GC for internal pass data structures,
this is what most passes do (PRE is a good example of where it stays
away from the GC for internal data structures).

Thanks,
Andrew Pinski

Re: install path in libgcc Makefile.in

[Zhang Le]

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

I will send the patch to gcc-patches after testing.

Zhang Le

Re: Does GCC support segmented memory ?

[Ian Lance Taylor]

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 possible in GCC ? and if the answer is "yes",
> how can I do that ? 

gcc can support systems with different code and data segments.  It
doesn't take any special work in gcc itself; gcc already uses
different sections for different types of objects.  The harder work is
in the assembler and linker.  I've done it by using extra bits in the
addresses to distinguish code and data, and having the linker scripts
set section addresses accordingly; of course, these bits are masked
out of the final output.

Ian

On the requirements of offsetof Macro in C++.

[Rodolfo Federico Gamarra]

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". The change
was introduced in
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2369.pdf";
and was developed in the paper "POD's Revisited" regarding an issue
reported to the standard ("Definition of POD is too strict"), in
particular its second revision (
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2172.html).

I'd like to ask about the status or the consequences over GNU/gcc of
that change in the standard. Nowadays I'm working with

g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

Actually trying and compiling ("g++ main.cc -o main") the following example:

#include 
class A {
//public:
void f(){ offsetof(A,i); }
int i;
};
int main(){}

causes the following warning message

main.cc:4: warning: invalid access to non-static data member 'A::i' of
NULL object
main.cc:4: warning: (perhaps the 'offsetof' macro was used incorrectly)

If the 'public' access control modifier is introduced (deleting the //
at the beginning) no message is given.

I suppose that in this particular case the warning may be ignored
without risk, but in other cases may not.

Are there any guarantees besides what's currently dictated by the standard?

In particular, may 'offsetof' in GNU/gcc work properly with types that
only respect the (new) requirement of having "standard-layout"? If so,
does it happen in any particular version?

Thanks a lot for your help.

--
Rodolfo Federico Gamarra

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

[Basile STARYNKEVITCH]

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
creates lots of garbage.  The only pass I can think of that might
cause that much garbage is the inliner but even then it would only be
make stuff dead rather than creating new data structures which are
dead.

Can you give a more concrete example of why you want this?  


Yes, the MELT branch. There is some incomplete documentation on the 
wiki, and in the MELT branch itself, file gcc/doc/melt.texi.


The MELT runtime (file gcc/basilys.c) provides a copying garbage 
collector backed up by GGC. So a minor MELT GC copy live MELT values out 
of MELT nursery zone into the GGC heap; a full MELT garbage collector 
triggers in addition ggc_collect.


MELT handle MELT values (like MELT closures, MELT objects, MELT boxed 
gimples) and unboxed stuff. Stuff means any GCC data which is not boxed 
as MELT value. For instance, gimple & gimple_seq are stuff.


The point is that a MELT garbage collection can essentially occur at any 
time within MELT code. More precisely, a MELT GC basilys_garbcoll can 
occur at any invocation of basilysgc_allocate which allocate MELT values 
in the MELT nursery; this happens very often in the C code generated by 
MELT. Most such collections are only minor (so do not call ggc_collect) 
but some of them are full (they do call ggc_collect after copying out of 
the nursery). So potentially ggc_collect can be called (via 
basilysgc_allocate which calls basilys_garbcoll which may call 
ggc_collect) at many places in MELT generated code. Remember that all 
MELT code (including the MELT translator itself) is machine-translated 
to C code.


MELT is currently only used for analysis passes, ie passes which are 
acessing GCC internal representations (like gimple & tree & edge & cfg 
etc..) but which do not modify them (like any optimizing pass should 
do). For such passes the current MELT code (ie the generated code and 
the gcc/basilys.c file) is enough and safe.


Now suppose you want to prototype in MELT a pass which does some cute & 
expensive optimisation. (This does not happen yet; MELT is currently 
only used for analysis purposes, and I am still working on such analysis 
code - see files gcc/melt/ana-*.bysl). So this pass wants to build a new 
gimple_seq using e.g. gimple_seq_alloc_with_stmt. Interfacing this to 
MELT is extremely easy, just code

  (defprimitive new_gimpleseq_with_stmt (:gimple stmt) :gimple_seq
"gimple_seq_alloc_with_stmt(" stmt ")")
Et voilà, you can later code in your MELT code
  (new_gimpleseq_with_stmt s)
with the s variable containing a gimple stuff (of course it can be a 
more complex MELT expression giving a gimple).


Imagine that just after such an expression a MELT full garbage 
collection occur. This can happen when you code in MELT an expression 
which boxes the newly make gimple_seq, like

  (make_gimpleseq (new_gimpleseq_with_stmt s))
This just asks to box the newly made gimple_seq stuff into a MELT value. 
You'll need that to put the gimple_seq inside a MELT closure or a MELT 
object (since these contains only MELT values, not unboxed stuff!).


In the rare case a MELT full garbage collection occurs at the 
make_gimpleseq step, chaos will happen. Because the 
gimple_seq_alloc_with_stmt has been called and returned the new 
gimple_seq NGS, and then ggc_collect has been called, and the NGS is not 
accessible yet.


There is a TODO comment line 35 in file gcc/basilys.h of the MELT branch

/* TODO:

   if GGC-collected data, e.g. tree-s, edge-s, ... is computed by
   basilys/MELT routines and is referenced only by the
   basilys/MELT call frames, it is lost on full basilys garbage
   collections, because the GGC collector is invoked (on full
   basilys GC) without being aware of such data.

   For basilys code which only inspects but does not create or
   modify such data this won't happen.

   A possible solution might be to generate code which copy such
   GGC data outside (e.g. into some specific GGC vector) on full
   garbage collections. This code might either be another routine
   pointer in our basilysroutine_st structure, or simply be
   invoked by calling the closure routine with a magic incantation,
   i.e. with the xargdescr_ set to (char*)-1

 */

I could quite easily enhance MELT such that :
  code is generated which traverse all the non-value stuff of MELT call 
frames and mark them (in the GGC sense).
  the MELT garbage collector would call ggc_collect_with_local with 
appropriate arguments to invoke all the above generated code.


Without any ggc_collect_with_local the enhancement would be more 
tedious. For each stuff datatype (ie any GCC internal data which is not 
boxed as a MELT value