Re: Is this the expected behavior?

[Mohamed Shafi]

2008/7/15 Ramana Radhakrishnan <[EMAIL PROTECTED]>:
> Hi Mohamed,
>
>
>
> Why not ? Callee save registers are after all registers and the split
> is in the ABI's head (so to speak). So GCC is well within its right to
> use callee save registers. In fact if you were in a leaf function that
> did not make any function calls the first preference would be to
> allocate caller save registers and then to allocate callee save
> registers - Instead of spilling a caller save register , GCC could
> very well use a callee save register and the only extra cost would be
> saving and restoring context of the callee save register in the
> prologue and the epilogue respectively.
>

   I agree with you, but what about when there are still caller save
register are available and there are no register restrictions for any
instructions? In my case i find that GCC has used only the argument
registers, stack pointer and callee saved registers. So out of the 16
available registers ony 5+1+4 registers were used, even though there
was 6 caller save registers were available

>
> HTH.
>
>
> cheers
> Ramana
>
> On Tue, Jul 15, 2008 at 7:50 AM, Mohamed Shafi <[EMAIL PROTECTED]> wrote:
>>
>> Hello all,
>>
>> I am not sure if this the right mailing list.
>>
>> I am involved in the porting of gcc 4.1.2 for a 16 bit target.
>> In some cases i noticed that callee save registers were getting
>> allocated in the body even though there isn't any function call. I
>> believe that callee save registers will be allocated only if some
>> variable values are required across a function call. So if there is no
>> function call there shouldn't be any callee save registers used in a
>> function body. So my question is will GCC allocate callee save
>> registers for function even if the function doesn't call any other
>> function?
>> Or is this a gcc bug?
>>
>> Hope my question is clear.
>>
>> Regards,
>> Shafi
>
>
>
> --
> Ramana Radhakrishnan
>

Re: Is this the expected behavior?

[Ramana Radhakrishnan]

>
>   I agree with you, but what about when there are still caller save
> register are available and there are no register restrictions for any
> instructions? In my case i find that GCC has used only the argument
> registers, stack pointer and callee saved registers. So out of the 16
> available registers ony 5+1+4 registers were used, even though there
> was 6 caller save registers were available


Check your REG_ALLOC_ORDER macro ?


cheers
Ramana
>
>>
>> HTH.
>>
>>
>> cheers
>> Ramana
>>
>> On Tue, Jul 15, 2008 at 7:50 AM, Mohamed Shafi <[EMAIL PROTECTED]> wrote:
>>>
>>> Hello all,
>>>
>>> I am not sure if this the right mailing list.
>>>
>>> I am involved in the porting of gcc 4.1.2 for a 16 bit target.
>>> In some cases i noticed that callee save registers were getting
>>> allocated in the body even though there isn't any function call. I
>>> believe that callee save registers will be allocated only if some
>>> variable values are required across a function call. So if there is no
>>> function call there shouldn't be any callee save registers used in a
>>> function body. So my question is will GCC allocate callee save
>>> registers for function even if the function doesn't call any other
>>> function?
>>> Or is this a gcc bug?
>>>
>>> Hope my question is clear.
>>>
>>> Regards,
>>> Shafi
>>
>>
>>
>> --
>> Ramana Radhakrishnan
>>
>



-- 
Ramana Radhakrishnan

Re: Is this the expected behavior?

[Mohamed Shafi]

2008/7/15 Ramana Radhakrishnan <[EMAIL PROTECTED]>:
> 
>
>>
>>   I agree with you, but what about when there are still caller save
>> register are available and there are no register restrictions for any
>> instructions? In my case i find that GCC has used only the argument
>> registers, stack pointer and callee saved registers. So out of the 16
>> available registers ony 5+1+4 registers were used, even though there
>> was 6 caller save registers were available
>
>
> Check your REG_ALLOC_ORDER macro ?

  The order is argument registers, caller save registers and finally
the callee save registers.


>
>
> cheers
> Ramana
>>
>>>
>>> HTH.
>>>
>>>
>>> cheers
>>> Ramana
>>>
>>> On Tue, Jul 15, 2008 at 7:50 AM, Mohamed Shafi <[EMAIL PROTECTED]> wrote:

 Hello all,

 I am not sure if this the right mailing list.

 I am involved in the porting of gcc 4.1.2 for a 16 bit target.
 In some cases i noticed that callee save registers were getting
 allocated in the body even though there isn't any function call. I
 believe that callee save registers will be allocated only if some
 variable values are required across a function call. So if there is no
 function call there shouldn't be any callee save registers used in a
 function body. So my question is will GCC allocate callee save
 registers for function even if the function doesn't call any other
 function?
 Or is this a gcc bug?

 Hope my question is clear.

 Regards,
 Shafi
>>>
>>>
>>>
>>> --
>>> Ramana Radhakrishnan
>>>
>>
>
>
>
> --
> Ramana Radhakrishnan
>

Re: [tuples] Bootstrap failure building libjava on ppc64

[Richard Guenther]

On Mon, 14 Jul 2008, Daniel Berlin wrote:

> On Mon, Jul 14, 2008 at 5:22 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> > We are failing to build libjava on PPC64 because of this:
> >
> > /home/dnovillo/perf/sbox/tuples/local.ppc64/bld/./gcc/xgcc -shared
> > -libgcc -B/home/dnovillo/perf/sbox/tuples/local.ppc64/bld/./gcc
> > -nostdinc++ -L/home/d
> > novillo/perf/sbox/tuples/local.ppc64/bld/powerpc64-unknown-linux-gnu/libstdc++-v3/src
> >  
> > -L/home/dnovillo/perf/sbox/tuples/local.ppc64/bld/powerpc64-unknown-linux-gnu/libstd
> > c++-v3/src/.libs
> > -B/home/dnovillo/perf/sbox/tuples/local.ppc64/inst/powerpc64-unknown
> > -linux-gnu/bin/
> > -B/home/dnovillo/perf/sbox/tuples/local.ppc64/inst/powerpc64-unknown-
> > linux-gnu/lib/ -isystem
> > /home/dnovillo/perf/sbox/tuples/local.ppc64/inst/powerpc64-un
> > known-linux-gnu/include -isystem
> > /home/dnovillo/perf/sbox/tuples/local.ppc64/inst/pow
> > erpc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
> > -I/home/dnovillo/perf/sbox/t
> > uples/local.ppc64/src/libjava -I./include -I./gcj
> > -I/home/dnovillo/perf/sbox/tuples/l
> > ocal.ppc64/src/libjava -Iinclude
> > -I/home/dnovillo/perf/sbox/tuples/local.ppc64/src/li
> > bjava/include 
> > -I/home/dnovillo/perf/sbox/tuples/local.ppc64/src/libjava/classpath/inc
> > lude -Iclasspath/include
> > -I/home/dnovillo/perf/sbox/tuples/local.ppc64/src/libjava/cl
> > asspath/native/fdlibm
> > -I/home/dnovillo/perf/sbox/tuples/local.ppc64/src/libjava/../bo
> > ehm-gc/include -I../boehm-gc/include
> > -I/home/dnovillo/perf/sbox/tuples/local.ppc64/sr
> > c/libjava/libltdl
> > -I/home/dnovillo/perf/sbox/tuples/local.ppc64/src/libjava/libltdl -
> > I/home/dnovillo/perf/sbox/tuples/local.ppc64/src/libjava/.././libjava/../gcc
> > -I/home/
> > dnovillo/perf/sbox/tuples/local.ppc64/src/libjava/../zlib
> > -I/home/dnovillo/perf/sbox/
> > tuples/local.ppc64/src/libjava/../libffi/include -I../libffi/include
> > -fno-rtti -fnon-
> > call-exceptions -fdollars-in-identifiers -Wswitch-enum
> > -D_FILE_OFFSET_BITS=64 -mminim
> > al-toc -Wextra -Wall -D_GNU_SOURCE
> > -DPREFIX=\"/home/dnovillo/perf/sbox/tuples/local.p
> > pc64/inst\" 
> > -DTOOLEXECLIBDIR=\"/home/dnovillo/perf/sbox/tuples/local.ppc64/inst/lib/.
> > ./lib64\" -DJAVA_HOME=\"/home/dnovillo/perf/sbox/tuples/local.ppc64/inst\"
> > -DBOOT_CLA
> > SS_PATH=\"/home/dnovillo/perf/sbox/tuples/local.ppc64/inst/share/java/libgcj-4.4.0.ja
> > r\" 
> > -DJAVA_EXT_DIRS=\"/home/dnovillo/perf/sbox/tuples/local.ppc64/inst/share/java/ext
> > \" 
> > -DGCJ_ENDORSED_DIRS=\"/home/dnovillo/perf/sbox/tuples/local.ppc64/inst/share/java/
> > gcj-endorsed\" 
> > -DGCJ_VERSIONED_LIBDIR=\"/home/dnovillo/perf/sbox/tuples/local.ppc64/i
> > nst/lib/../lib64/gcj-4.4.0-10\" -DPATH_SEPARATOR=\":\"
> > -DECJ_JAR_FILE=\"\" -DLIBGCJ_D
> > EFAULT_DATABASE=\"/home/dnovillo/perf/sbox/tuples/local.ppc64/inst/lib/../lib64/gcj-4
> > .4.0-10/classmap.db\"
> > -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.4.0-10/classmap.db\
> > " -g -O2 -D_GNU_SOURCE -MT stacktrace.lo -MD -MP -MF
> > .deps/stacktrace.Tpo -c /home/dn
> > ovillo/perf/sbox/tuples/local.ppc64/src/libjava/stacktrace.cc  -fPIC
> > -DPIC -o .libs/s
> > tacktrace.o
> > /home/dnovillo/perf/sbox/tuples/local.ppc64/src/libjava/stacktrace.cc:
> > In static memb
> > er function 'static _Unwind_Reason_Code
> > _Jv_StackTrace::UnwindTraceFn(_Unwind_Context
> > *, void*)':
> > /home/dnovillo/perf/sbox/tuples/local.ppc64/src/libjava/stacktrace.cc:105:
> > internal c
> > ompiler error: in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:615
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See  for instructions.
> > make[3]: *** [stacktrace.lo] Error 1
> > make[3]: *** Waiting for unfinished jobs
> >
> 
> This error implies you have something in a "tcc_reference" operation
> (IE load or store) that we've never seen before (or we are improperly
> classifying something as a reference when it isn't).
> 
> 
> Can you go up a frame and print out the first argument to
> copy_reference_ops_from_ref using debug_tree (or it's equivalent. The
> important thing is to know what operations it contains, not that it
> look nice).
> The argument is reused locally during the function, hence the request
> to go up a frame :P

I'll have a look.

Richard.

Re: Optimising for size

[Hariharan]

Hi Joel,
I ran into a similar problem moving from 4.2.2 to 4.3.0. I looked a bit 
into it and found that 4.3 compiler inlines more aggressively than 4.2.x 
compiler. The reason was that the following two lines were removed from 
opts.c


  set_param_value ("max-inline-insns-single", 5); 



  set_param_value ("max-inline-insns-auto", 5);

Of course, there were other changes made to make sure code size didnt 
increase with this change. But, the other changes depend on 
PARAM_INLINE_CALL_COST. The default of 16 was too high for our target 
(picochip). You might want to try to reduce this value and see if your 
code-size woes go away.



Regards
Hari

Joe Buck wrote:

On Mon, Jul 14, 2008 at 10:04:08AM +1000, [EMAIL PROTECTED] wrote:

I have a piece of C code. The code, compiled to an ARM THUMB 
target using
gcc 4.0.2, with -Os results in 230 instructions. The exact same 
code,
using the exact same switches compiles to 437 instructions with 
gcc 4.3.1.

Considering that the compiler optimises to size and the much newer
compiler emits almost twice as much code as the old one, I 
think it is an

issue.


Agreed.  I think it's a regression.  Using -Os and getting
much larger code would qualify.


So the question is, how should I report it?


Open a PR with the complete test case, and the command line options you
used with 4.0.2 and 4.3.1.


Please cc me on the PR.  I would like to track this one and
if you provide a preprocessed  test case can quickly
check the size on 3.2.3, 4.1.1, 4.2.4, 4.3.1 and the trunk.


Use joel AT gcc DOT gnu.org

Thanks.

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: New branch for STL Advisor

[Paolo Carlini]

> This ties in with the main question I had... typically, a
> profiling layer is used on larger inputs where it is important that the
> profiling code itself have very low overhead. Piggybacking on
> the debug mode is a definite performance-killer, so I hope that
> the profiling version of the library will be in its own inline
> namespace alongside the parallel and debug modes.
> 
> My vote for the command-line switch is -fprofile-stdlib.

I agree, on both accounts.

Paolo.

Re: GCC/GCJ, SWT, and license lock-in

[Andrew Haley]

Steve Perkins wrote:
>I have a question about using GCC/GCJ to compile a Java application
> which uses the SWT framework for its GUI, and whether this locks you in
> or out of any licensing options.  I apologize in advance if this
> question is somewhat off-topic... I searched "gnu.org" for a mailing
> list specifically directed toward licensing discussion and came up empty.
> 
>The SWT is covered by the Eclipse Public License (EPL), which does
> not bind you to use the EPL for programs which merely link to SWT
> without modifying it (Question #27 at
> http://www.eclipse.org/legal/eplfaq.php#DERIV).
>However, the FSF considers the EPL to be incompatible with the GPL. 
> I'm not sure what impact (if any) this would have on my desire to write
> a GPL'ed application from scratch, which links to SWT for its GUI.

You couldn't do that.  However, libgcj carries with it an exception that
allows you to link non-GPL code.  Look at the licence for more details.

Andrew.

Re: refinements to definition of TREE_READONLY ?

[Olivier Hainque]

Hi Richard,

Still looking into this issue.

Our current understanding is that our initial bug was indirectly
caused by the Ada front-end setting TREE_STATIC on a DECL_EXTERNAL
constant, which it shouldn't do.

The straightforward fix to that uncovered corner issues with the
way we set DECL_CONTEXT in some special cases.

Investigating further ...

Thanks for your constructive feedback,

Olivier

Re: GCC/GCJ, SWT, and license lock-in

[Steve Perkins]

> You couldn't do that. However, libgcj carries with it an exception that
> allows you to link non-GPL code. Look at the license for more details.

   Can you perhaps elaborate?  No offense, but I think the original 
message makes clear that "looking at the licenses for more details" was 
the first step I took before writing. 

   I'm not really concerned about libgcj imposing terms on compiler 
output (I knew about the linking exception, just didn't know if that was 
dropped in the move from GPL v2 to v3).  What I asked about was 
voluntarily applying the GPL to my own new application.  That 
application links to a library under a different license, which does not 
require linking applications to adopt its license.  If I were doing 
something that required that other license to be applied to the whole, 
then I would clearly run into a conflict trying to apply it and the GPL 
to the whole simultaneously.  However, since I'm not required to apply 
that other license to my own code, I don't see any conflict in using the 
GPL for this new work.


   Is there something you have in mind that I'm missing there?

Re: GCC/GCJ, SWT, and license lock-in

[Andrew Haley]

Steve Perkins wrote:
>> You couldn't do that. However, libgcj carries with it an exception that
>> allows you to link non-GPL code. Look at the license for more details.
> 
>Can you perhaps elaborate?  No offense, but I think the original
> message makes clear that "looking at the licenses for more details" was
> the first step I took before writing.

The licence is the truth, the whole truth, and nothing but the truth.
Nothing I say can make any difference.

>I'm not really concerned about libgcj imposing terms on compiler
> output (I knew about the linking exception, just didn't know if that was
> dropped in the move from GPL v2 to v3).  What I asked about was
> voluntarily applying the GPL to my own new application. 

I think that depends on whether your work would be considered a derivative
work of Eclipse code.  I can't comment on that.

> That
> application links to a library under a different license, which does not
> require linking applications to adopt its license.  If I were doing
> something that required that other license to be applied to the whole,
> then I would clearly run into a conflict trying to apply it and the GPL
> to the whole simultaneously.  However, since I'm not required to apply
> that other license to my own code, I don't see any conflict in using the
> GPL for this new work.
> 
>Is there something you have in mind that I'm missing there?

It seems to me that you're seeking legal advice from people who aren't
lawyers.  We don't know, really: maybe FSF legal can help.

Andrew.

[WWW] Updating GCC Links and Selected Readings

[Santiago Urueña Pascual]

Hi, I've noticed that the Ada section of the following web page is
somewhat outdated:

  http://gcc.gnu.org/readings.html

For example, Ada Core Technologies is now named AdaCore, and there is
much more recent version of the book describing the internals of the
run-time by the same author (also describing the compiler internals).
I also propose adding the following list of links to the Ada
standandards and other useful documents for compiler writers.

Cheers,


--- readings.html.orig  2008-07-15 18:11:53.0 +0200
+++ readings.html.new   2008-07-15 18:45:43.0 +0200
@@ -545,11 +545,65 @@
 Ada information

 
-  http://www.adacore.com/home/";>Ada Core Technologies
-  http://www.iuma.ulpgc.es/users/jmiranda/";>A Detailed
-  Description of the GNU Ada Run Time
-  ftp://ftp.cs.nyu.edu/pub/gnat/";>GNAT sources and
-  binaries
+
+  Ada standards information:
+
+  
+http://www.open-std.org/jtc1/sc22/wg9/";>WG9 (Ada
+standards committee):
+
+  http://www.ada-auth.org/ais.html";>Ada Issues
+
+http://www.adaic.com/standards";>List of Ada standards (Ada
+Information Clearinghouse):
+
+  http://www.adaic.com/standards/05aarm/html/AA-TTL.html";>
+  Annotated Ada 2005 Reference Manual
+  http://www.adaic.com/standards/05rm/html/RM-TTL.html";>
+  Ada 2005 Reference Manual
+  http://www.adaic.com/standards/05rat/html/Rat-TTL.html";>
+  Ada 2005 Rationale
+  http://www.adaic.com/standards/95aarm/html/AA-TTL.html";>
+  Annotated Ada 95 Reference Manual
+  http://www.adaic.com/standards/95lrm/html/RM-TTL.html";>
+  Ada 95 Reference Manual
+  http://www.adaic.com/standards/95rat/RAThtml/rat95-copyright.html";>
+  Ada 95 Rationale
+  http://archive.adaic.com/standards/83lrm/html/ada_lrm.html";>
+  Ada 83 Reference Manual
+  http://archive.adaic.com/standards/83rat/html/Welcome.html";>
+  Ada 83 Rationale
+
+  
+
+  Related standards:
+
+  
+  http://www.sigada.org/WG/asiswg/";>Ada Semantic Interface
+  Specification (ASIS)
+   
+
+  Compiler validation:
+
+  
+http://www.ada-auth.org/acats.html";>Ada Conformity Assessment
+  Test Suite (ACATS)
+  
+
+   Other resources:
+  
+ http://www.adacore.com/";>AdaCore
+ https://libre.adacore.com/";>AdaCore —
Libre Site
+ https://www2.adacore.com/gap-static/GNAT_Book/html/";>GNAT:
+ The GNU Ada Compiler
+ http://www.adaic.org/docs/95style/html/cover.html";>Ada
+ Quality & Style Guide
+  http://polaris.dit.upm.es/~ork/documents/adahis.pdf";>Guide
for
+  the use of the Ada programming language in high integrity
systems
+  http://www.sigada.org/ada_letters/jun2004/ravenscar_article.pdf";>Guide
+  for the use of the Ada Ravenscar Profile in high integrity
systems
+  
+
 

-- 
Santiago Urueña Pascual <[EMAIL PROTECTED]>

Re: New branch for STL Advisor

[Silvius Rus]

Doug Gregor wrote:

On Mon, Jul 14, 2008 at 7:20 PM, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
  

In particular, design. The using bits seem pretty straightforward. It
would be nice if you could provide some detail in terms of scope (what
are the algorithms or data structures you intend to instrument),
and how this fits into the existing debug mode functionality. Do you
need the debug mode functionality, or are just piggy-backing off this
existing structure?



This ties in with the main question I had... typically, a profiling
layer is used on larger inputs where it is important that the
profiling code itself have very low overhead. Piggybacking on the
debug mode is a definite performance-killer, so I hope that the
profiling version of the library will be in its own inline namespace
alongside the parallel and debug modes.

  


Agree.  We will create a new namespace at the same level as the parallel 
and debug modes.



My vote for the command-line switch is -fprofile-stdlib.

  


Agree.


  - Doug
  


Thank you,
Silvius

Re: New branch for STL Advisor

[Silvius Rus]

Benjamin Kosnik wrote:

Hi Silvius Rus and Lixia Liu! Thanks for posting this, asking for
advice, and being willing to help improve libstdc++!

  

Goal:  Give performance improvement advice based on analysis of
dynamic STL usage.



Your project sounds intriguing, and something that could potentially be
useful for GNU C++ users. I look forward to seeing how your work
progresses, and encourage you to start a gcc branch to house your work
in progress. Progress can be evaluated at the next stage 1 window, to
see if things are solid enough to merge in to the trunk.

  


Thank you for the review and positive feedback.  We will create the 
branch immediately.



Method:  Instrumentation calls in libstdc++-v3/include/debug/*,
runtime support library in libstdc++-v3/libstladvisor, trace
analysis/report tool in libstdc++-v3/stladvisor.



I would like to see a bit more detail on your methodology, and
encourage you to immediately start working on user documentation and a
test strategy before you get too far along with anything else.

For documentation, you'll need something similar to:

http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html
http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html

In particular, design. The using bits seem pretty straightforward. It
would be nice if you could provide some detail in terms of scope (what
are the algorithms or data structures you intend to instrument),
and how this fits into the existing debug mode functionality. Do you
need the debug mode functionality, or are just piggy-backing off this
existing structure? It seems to me like you might want to provide a
third level of debug mode macro, in addition to the _GLIBCXX_DEBUG and
_GLIBCXX_DEBUG_PEDANTIC, maybe something like _GLIBCXX_DEBUG_PROFILE.
However, if this is not the way you wish to proceed, and the intention
is to be separate from debug mode, I would suggest
using a new directory hierarchy and naming convention, one that is more
descriptive to what you are attempting than "advisor". Perhaps
include/profile? _GLIBCXX_PROFILE? Etc etc. In any case, please explain
a bit more as to how this relates to debug mode. 

  


I would go for cleaner at this point, so we will develop a profile_mode 
at the same level as debug_mode and parallel_mode.



How do you intend to test this functionality?

Do you intend for this functionality to work on all, some, or most
platforms? What are the portability concerns or issues? 

  


As advised, we will start by documenting the design in more detail and 
send it out once it is ready for review.



There are other STL usage patterns that can be recognized and
reported to the application programmer.



Again, scope. It would be great to provide an initial list so we know
what is being attempted. Feel free to mark some of them as stretch
goals, or things that will not be attempted immediately. 

  


They will be included with the initial design document and will be sent 
for review shortly.



The effect of our instrumentation is a meaningful trace of the
behavior of containers, algorithms and iterators, and their
interaction.  This abstraction level is above what normal profiling
tools can offer.  If we used normal profiling tools, we would have to
reverse engineer the trace to get to this level of abstraction.  Let
me know if you want me to go into more detail.



More detail, please.

  


Will do.


Design
==

The usage model is intended to be similar to -fprofile-generate and 
-fprofile-use.


1. Compiler driver
Build with instrumentation: gcc -fstl-advisor=instrument:all foo.cc.  
The effect on the compiler is simply "|-D_GLIBCXX_DEBUG 
|-D_GLIBCXX_ADVISOR".  The effect on the linker is "-lstladvisor".



Seems fine.

  

Run program: ./a.out.



OK.

  

Produce advisory report: gcc -fstl-advisor=use:advise.



What other valid input do you anticipate -fstl-advisor having?

  


I hope that some of the profiling information could be picked up by the 
compiler.  This is not our immediate goal though, so for now I just want 
to leave the door open for it.



best,
benjamin
  


To sum it up:  We will create the branch, write the design doc and send 
it for review ASAP.  Development will be separated from the debug mode.


Thank you,
Silvius

POSIX in g++

[Peng Yu]

Hi,

There is an options -ansi to make g++ ANSI compatible. I'm wondering
if there is an option to make g++ POSIX compatible. Or g++ is already
POSIX compatible without an option?

Thanks,
Peng

[tuples] merge with mainline @137837

[Aldy Hernandez]

I have merged mainline @137837 into the branch.

Jakub reports:

I don't have a testsuite_summary log from after the PRE commit but
before this merge, only summary from yesterday.  There are many tests
fixed (most of them likely because of the PRE merge) and several
regressions (again, likely culprit will be PRE or invalid gimple PRE is
upset about), but your merge together with
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01066.html bootstrapped
fine and we can IMHO deal with the regressions tomorrow

Jakub, thanks for testing the merge.

Aldy

Re: POSIX in g++

[Ian Lance Taylor]

"Peng Yu" <[EMAIL PROTECTED]> writes:

> There is an options -ansi to make g++ ANSI compatible. I'm wondering
> if there is an option to make g++ POSIX compatible. Or g++ is already
> POSIX compatible without an option?

POSIX itself specifies features macros which you may define to compile
your source code in a strict POSIX environment.  These are
_POSIX_SOURCE and _POSIX_C_SOURCE.  These affect the header files
rather than the libraries.  To get a strict POSIX compiler, use those
in conjunction with -ansi or -std.

Ian

Re: POSIX in g++

[Peng Yu]

On Tue, Jul 15, 2008 at 5:57 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Peng Yu" <[EMAIL PROTECTED]> writes:
>
>> There is an options -ansi to make g++ ANSI compatible. I'm wondering
>> if there is an option to make g++ POSIX compatible. Or g++ is already
>> POSIX compatible without an option?
>
> POSIX itself specifies features macros which you may define to compile
> your source code in a strict POSIX environment.  These are
> _POSIX_SOURCE and _POSIX_C_SOURCE.  These affect the header files
> rather than the libraries.  To get a strict POSIX compiler, use those
> in conjunction with -ansi or -std.
>
> Ian
>

Re: POSIX in g++

[Peng Yu]

On Tue, Jul 15, 2008 at 5:57 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Peng Yu" <[EMAIL PROTECTED]> writes:
>
>> There is an options -ansi to make g++ ANSI compatible. I'm wondering
>> if there is an option to make g++ POSIX compatible. Or g++ is already
>> POSIX compatible without an option?
>
> POSIX itself specifies features macros which you may define to compile
> your source code in a strict POSIX environment.  These are
> _POSIX_SOURCE and _POSIX_C_SOURCE.  These affect the header files
> rather than the libraries.  To get a strict POSIX compiler, use those
> in conjunction with -ansi or -std.

Hi Ian,

Isn't ANSI C++ a subset of POSIX C++. Why do I need to specify
_POSIX_SOURCE,  _POSIX_C_SOURCE and -ansi?

Would you please let me know what is the difference between the option
-ansi and -std?

Thanks,
Peng

Re: POSIX in g++

[Ian Lance Taylor]

"Peng Yu" <[EMAIL PROTECTED]> writes:

I should have said in reply to your last message: this is the wrong
mailing list for this question.  Please take any followups to
[EMAIL PROTECTED]  Thanks.

> Isn't ANSI C++ a subset of POSIX C++. Why do I need to specify
> _POSIX_SOURCE,  _POSIX_C_SOURCE and -ansi?

ANSI C is a subset of POSIX C (as far as I know C++ is not a part of
POSIX).  Using -ansi restricts you to ANSI C.  Adding the POSIX
defines tells the library to declare POSIX functions in the POSIX
header files.


> Would you please let me know what is the difference between the option
> -ansi and -std?

Please read the fine manual.

Ian