Re: PowerPC lwsync Instruction

[Gabriel Paubert]

On Thu, Jun 19, 2008 at 03:50:34PM -0500, Joel Sherrill wrote:
> Andrew Pinski wrote:
> >On Thu, Jun 19, 2008 at 1:36 PM, Joel Sherrill
> ><[EMAIL PROTECTED]> wrote:
> >  
> >>Hi,
> >>
> >>I ran into something tracking down a test
> >>failure on psim and now thing there is a
> >>target specific issue that needs addressing.
> >>
> >
> >lwsync is sync with the bit 9 set.  So it should be ok as it was a
> >reserved field and was supposed to be ignored on the hardware which
> >did not implement those bits and have it as a sync (but I could be
> >wrong).
> >  
> I don't have access to a real 603e of this vintage but
> my Sept 1995 603e User's Manual shows the sync
> instruction has having:
> 
> 0-5  - all 1's (value in table is 31)
> 6-20   - all 0's (dark grey indicating not implemented)
> 21-30 - 598
> 31   - 0
> 

I have 6 PPC603ev (5 at revision 2.1 and one at 18.1
according to /proc/cpuinfo, some of them running almost 
nonstop for 11 years, all of them for 7 years at least) 
and they all accept an: 

asm volatile("lwsync" : : : "memory");

between two printf() without trapping  (I see the output of
the second printf).

I also tried with ptesync, which is also accepted.

Regards,
Gabriel

Back-End differences between 4.2.1 and 4.3.1

[Boris Boesler]

Hi!

 I upgraded from GCC 4.2.1 to GCC 4.3.1. But with this new version I  
can't compile any program with my back-end which works with GCC 4.2.1.  
I get the following error message:


empty-void.c: In function 'main':
empty-void.c:15: error: unrecognizable insn:
(insn 14 4 15 empty-void.c:14 (parallel [
(set (reg/f:SI 45 A13)
(plus:SI (reg/f:SI 45 A13)
(const_int -32 [0xffe0])))
(clobber (reg:CC 49 CONDSEL))
]) -1 (nil))
empty-void.c:15: internal compiler error: in insn_default_length, at  
insn-attrtab.c:417


 This insn belongs to the epilogue code. The error message is emitted  
AFTER expanding the prologue and the epilogue where I emit additional  
instructions but BEFORE reorganization. In 4.2.1 I solved this kind of  
errors by calling the functions "init_insn_lengths ();" and  
"shorten_branches (get_insns ());" I call "init_insn_lengths()" after  
expanding the prologue and the epilogue but that doesn't show any  
difference.


 The backtrace is:
(gdb) bt
#0  insn_default_length (insn=0x406e35a0) at insn-attrtab.c:415
#1  0x001569d0 in shorten_branches (first=0x40c83720) at ../../ 
gcc-4.3.1/gcc/final.c:1128
#2  0x00156b93 in rest_of_handle_shorten_branches () at ../../ 
gcc-4.3.1/gcc/final.c:4190
#3  0x0021a071 in execute_one_pass (pass=0x4b89e0) at ../../gcc-4.3.1/ 
gcc/passes.c:1122
#4  0x0021a247 in execute_pass_list (pass=0x4b89e0) at ../../gcc-4.3.1/ 
gcc/passes.c:1175


 Did I miss a change? Is emitting instructions more restrictive now?  
How can I solve this?


Thanks,
Boris

Re: reg "use" replacement vs match_dup operand ?

[Olivier Hainque]

Olivier Hainque wrote:
> move_invariant_reg has this code:
> 
>   /* Replace the uses we know to be dominated.

> and we're observing a case where this updates only one of two
> match_dup related operands. This is on i386-mingwin [...]

 This is causing nasty miscompilation of this very simple case:

 char * volatile buf;
 int size = 1024;

 void foo (void)
 {
   int i, len = size;

   for (i = 0; i < 5; i ++)
 buf = __builtin_alloca (len);
 }

 ./cc1 -O1 -fverbose-asm t.c

 # GNU C (GCC) version 4.4.0 20080618 (experimental) (pentium-mingw32msv)
 ...
 _foo:
pushl   %ebp #
movl%esp, %ebp   #,
pushl   %edi #
pushl   %esi #
pushl   %ebx #
subl$12, %esp#,
movl$0, %edx #, i
movl_size, %eax  # size, len
 L2:
call___chkstk
leal15(%esp), %eax   #, tmp68
andl$-16, %eax   #, tmp70
movl%eax, _buf   # tmp70, buf
addl$1, %edx #, i
cmpl$5, %edx #, i
jne L2   #,
 ...

 The way eax is clobbered and reused as an argument to chkstk is
 very, very wrong.

Re: gcc-in-cxx branch created

[Joseph S. Myers]

On Mon, 23 Jun 2008, Arnaud Charlet wrote:

> >> How can maintainers ensure this does not happen?
> > 
> > What is your suggestion, stay with C?  It doesn't have type safe enums 
> > either.
> 
> One possibility is to do what we do for Ada: have a style/coding checker
> built into the compiler (C++ front-end) as a special switch, and enable this
> switch during bootstrap, so that any such coding style violation is 
> transformed
> into an error (actually a warning, transformed then into an error with 
> -Werror).

I've thought such a thing would be useful for C style as well.

One slight complication is that while a limited subset of C++ should be 
fine for most of the compiler, there may be a use for many more features 
(provided those features are still supported by the baseline bootstrap 
compiler version, e.g. 3.4) in selected areas that provide infrastructure 
for use in the rest of the compiler (just as now we have complicated 
macros in vec.h, and maintainers need not care most of the time about the 
implementations of them, just about how to use them).  So you may have 
features that should not be freely spread throughout the compiler but 
should be allowed for particular pieces of code only.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: gcc-in-cxx branch created

[Arnaud Charlet]

> I've thought such a thing would be useful for C style as well.

Right. It just becomes more of an issue if people start using C++
which is a much more complex and large language, but it would also benefit
gcc developers today to have C coding standard checked automatically.

> One slight complication is that while a limited subset of C++ should be 
> fine for most of the compiler, there may be a use for many more features 
> (provided those features are still supported by the baseline bootstrap 
> compiler version, e.g. 3.4) in selected areas that provide infrastructure 
> for use in the rest of the compiler (just as now we have complicated 
> macros in vec.h, and maintainers need not care most of the time about the 
> implementations of them, just about how to use them).  So you may have 
> features that should not be freely spread throughout the compiler but 
> should be allowed for particular pieces of code only.

You can use special pragmas or attributes to tell the coding checker which
subset is allowed for a given file.

Arno

Re: gcc-in-cxx branch created

[Ian Lance Taylor]

Bruno Haible <[EMAIL PROTECTED]> writes:

> A comment regarding the GCC-in-C++ idea. In slide 16 you merely answer
>
>   "C++ is too complicated!"
>
> with
>
>   "Maintainers will ensure that gcc continues to be maintainable."
>
> C++ has, for example, 12 different ways to represent or invoke a function.
> It has no buikt-in typesafe "enum"s. Sooner or later developers will think
> more about
>   "should this better be a member function or a static inline function?"
>   or "how do I make dynamic_cast work with my enum sets?"
> than about the algorithm they want to implement.
>
> How can maintainers ensure this does not happen?

The point is not to ensure that any particular language feature is not
used.  The language features are not arbitrary; they serve particular
programming techniques.  When those techniques are appropriate, the
language features will be appropriate.

It is possible to write obscure code code in C just as in C++.
Obviously the canonical gcc example of this is vec.h.  Although that
code is obscure, it presents a relatively simple interface.  Thus it
is possible for most compiler developers to use the vec.h routines
without understanding how they actually work.  (As it happens, vec.h
would be much much simpler in C++, but that is not the point I am
making here.)

What matters for gcc going forward is that it continue to be
comprehensible and maintainable.  That is a struggle that gcc has
faced for its entire existence as a free software project.  It is
certainly true that using C++ unwisely can make that struggle more
difficult.  But this issue is not qualitatively different from the
issues we face today.

Whether we use C or C++, we need to try to ensure that interfaces are
easy to understand, that the code is reasonably modular, that the
internal documentation corresponds to the code, that it is possible
for new developers to write new passes and to fix bugs.  Those are the
important issues for us to consider.  The C++ features which are not
present in C--features which are well documented in many books and
many web sites--are not an important issue.

I certainly grant that some programmers new to C++ have been known to
try to use all the advanced C++ features at once, whether or not they
are appropriate.  However, that is not a problem we are going to face
with our existing maintainers, who are all experienced programmers.

Ian

Re: Should we remove java from the default bootstrap languages?

[Ian Lance Taylor]

Ben Elliston <[EMAIL PROTECTED]> writes:

> On Sun, 2008-06-22 at 07:32 -0700, Ian Lance Taylor wrote:
>
>> I think it would only be a few days of work for somebody familiar with
>> Tcl to add -j support to DejaGNU.  I think that would be a very useful
>> contribution to gcc development.
>
> What did you have in mind, Ian?  That DejaGnu would run .exps in
> parallel?  Perhaps what I tried is more complicated than what you are
> proposing.

Running .exps in parallel wouldn't help much with the gcc testsuite.
What would help is for functions like c-torture-execute and dg-runtest
to run tests in parallel.  It seems to me that that could be done
fairly easily by maintaining a fixed number of concurrent executions,
and using system to execute them all in the background.  As one
execution finished, the script would start another one.  Each
execution would write to its own temporary log file.  The master
script would gather the log files and write them out in the
appropriate order.  This assumes that executing a single test does not
change any DejaGNU global variable; it might be necessary to change
code to ensure that.  This feature could not be used when executing
programs on a target board or when using DejaGNU to drive a compiler
running on a different host; however, that is not the common case.

Ian

Re: gcc-in-cxx branch created

[Bruno Haible]

Arnaud Charlet wrote:
> One possibility is to do what we do for Ada: have a style/coding checker
> built into the compiler (C++ front-end) as a special switch, and enable this
> switch during bootstrap, so that any such coding style violation is 
> transformed
> into an error

Yes, this can be the technical implementation of limiting the set of C++
features.

Additionally, it needs to be avoided that the limits get pushed out year
after year, allowing, for example, inline templates in one year, template
member functions the next year, and complete template metaprogramming the
year after that. To this end, it must be made very hard to extend this
subset of C++. Possibly it should require agreement from the Steering Comittee
to do so.

Bruno

Re: PR 36599

[Richard Guenther]

On Sun, 22 Jun 2008, Jack Howarth wrote:

> Richard,
>  There is a regression in the induct polyhedron benchmark execution
> when gfortran compiled with -ffast-math -O3 introduced with gcc 4.3
> that isn't present in gcc 4.2.4.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36599
> 
> According to the SuSe polyhedron benchmark servers, the bottleneck
> in the induct benchmark was eliminated between 2008-04-27 and
> 2008-04-28 in gcc trunk. My guess is that your changes...
> 
> r134730 | rguenth | 2008-04-27 12:27:08 -0400 (Sun, 27 Apr 2008) | 42 lines
> 
> 2008-04-27  Richard Guenther  <[EMAIL PROTECTED]>
> 
> PR tree-optimization/18754
> PR tree-optimization/34223
> * tree-pass.h (pass_complete_unrolli): Declare.
> * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Print
> loop size before and after unconditionally of UL_NO_GROWTH in effect.
> Rewrite loop into loop closed SSA form if it is not already.
> (tree_unroll_loops_completely): Re-structure to iterate over
> innermost loops with intermediate CFG cleanups.
> Unroll outermost loops only if requested or the code does not grow
> doing so.
> * tree-ssa-loop.c (gate_tree_vectorize): Don't shortcut if no
> loops are available.
> (tree_vectorize): Instead do so here.
> (tree_complete_unroll): Also unroll outermost loops.
> (tree_complete_unroll_inner): New function.
> (gate_tree_complete_unroll_inner): Likewise.
> (pass_complete_unrolli): New pass.
> * tree-ssa-loop-manip.c (find_uses_to_rename_use): Only record
> uses outside of the loop.
> (tree_duplicate_loop_to_header_edge): Only verify loop-closed SSA
> form if it is available.  
> * tree-flow.h (tree_unroll_loops_completely): Add extra parameter.
> * passes.c (init_optimization_passes): Schedule complete inner
> loop unrolling pass before the first CCP pass after final inlining.
> 
> * gcc.dg/tree-ssa/loop-36.c: New testcase.
> * gcc.dg/tree-ssa/loop-37.c: Likewise.
> * gcc.dg/vect/vect-118.c: Likewise.
> * gcc.dg/Wunreachable-8.c: XFAIL bogus warning.
> * gcc.dg/vect/vect-66.c: Increase loop trip count.
> * gcc.dg/vect/no-section-anchors-vect-66.c: Likewise.
> * gcc.dg/vect/no-section-anchors-vect-69.c: Likewise.
> * gcc.dg/vect/vect-76.c: Likewise.
> * gcc.dg/vect/vect-outer-6.c: Likewise.
> * gcc.dg/vect/vect-outer-1.c: Likewise.
> * gcc.dg/vect/vect-outer-1a.c: Likewise.
> * gcc.dg/vect/vect-11a.c: Likewise.
> * gcc.dg/vect/vect-shift-1.c: Likewise.
> * gcc.target/i386/vectorize1.c: Likewise.
> 
> 
> ...solved this performance regression. Is it possible that these changes could
> be backported to gcc 4.3.2 to eliminate the performance regression in gcc 4.3
> compared to gcc 4.2?

No.  This patch adds a new feature.

Richard.

Re: Should we remove java from the default bootstrap languages?

[Ian Lance Taylor]

Ian Lance Taylor <[EMAIL PROTECTED]> writes:

> This feature could not be used when executing
> programs on a target board or when using DejaGNU to drive a compiler
> running on a different host; however, that is not the common case.

To be clear, when using an embedded target board, the compilations
could be parallelized, the executions (generally) could not be.  That
is not so bad, as the compilations are what take the most time; most
of the tests execute quite quickly.

Ian

Re: GCC 4.3.2 Status Report (2008-06-22)

[Joel Sherrill]

Joseph S. Myers wrote:

Status
==

The GCC 4.3 branch is open for commits under normal release branch
rules.  The 4.3.2 release is expected around 2008-08-06.

Quality Data


Priority  # Change from Last Report
--- ---
P18 +- 0
P2  112 -  2
P32 +- 0
--- ---
Total   122 -  2

Previous Report
===

http://gcc.gnu.org/ml/gcc/2008-06/msg00321.html

The next report for the 4.3 branch will be sent by Richard.

  

Is PR 36583 in your list? It is an ICE on the Coldfire that is a
regression from 4.2.x.

--
Joseph S. Myers
[EMAIL PROTECTED]
  



--
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: GCC 4.3.2 Status Report (2008-06-22)

[Richard Guenther]

On Mon, 23 Jun 2008, Joel Sherrill wrote:

> Joseph S. Myers wrote:
> > Status
> > ==
> >
> > The GCC 4.3 branch is open for commits under normal release branch
> > rules.  The 4.3.2 release is expected around 2008-08-06.
> >
> > Quality Data
> > 
> >
> > Priority  # Change from Last Report
> > --- ---
> > P18 +- 0
> > P2  112 -  2
> > P32 +- 0
> > --- ---
> > Total   122 -  2
> >
> > Previous Report
> > ===
> >
> > http://gcc.gnu.org/ml/gcc/2008-06/msg00321.html
> >
> > The next report for the 4.3 branch will be sent by Richard.
> >
> >   
> Is PR 36583 in your list? It is an ICE on the Coldfire that is a
> regression from 4.2.x.

Probably not, as ColdFire is neither a primary nor a secondary
architecture (and thus regressions on it would be P4 or P5).

Richard.

2008 GCC Summit Proceedings

[Benjamin Kosnik]

...expecting these documents to be put up on the gcc wiki at some point,
right? Does anybody have an ETA or know how this has worked in previous
years?

http://gcc.gnu.org/wiki

-benjamin

GCC 3.3.3 not on GNU servers...

[Paul Koning]

I was looking for GCC 3.3.3 just now, and noticed that it doesn't
exist on the generic GNU FTP server or its mirrors
(ftp://ftp.gnu.org/gnu/gcc for example).  3.3.2 and 3.3.4 are there,
as well as lots of other releases, but 3.3.3 is mysteriously missing.

It does exist on the specific GCC mirrors, fortunately, but this is a
puzzling glitch.

 paul

Re: GCC 4.3.2 Status Report (2008-06-22)

[Kaveh R. GHAZI]

On Sun, 22 Jun 2008, Joseph S. Myers wrote:

> Status
> ==
>
> The GCC 4.3 branch is open for commits under normal release branch
> rules.  The 4.3.2 release is expected around 2008-08-06.
>
> Quality Data
> 
>
> Priority# Change from Last Report
>   --- ---
> P1  8 +- 0
> P2112 -  2
> P3  2 +- 0
>   --- ---
> Total 122 -  2

I'd like to see PR bootstrap/33304 fixed for gcc-4.3.2.  It's a bootstrap
problem on solaris2 using sun's cc.  Patches have been posted to fix it
and I included links for them in the PR.  However they haven't been
approved for mainline yet.  I think we have enough time between now and
the Aug 6th gcc-4.3.2 release date to get them in the trunk and 4.3.x
branch.

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: GCC 3.3.3 not on GNU servers...

[Kai Ruottu]

Paul Koning wrote:


I was looking for GCC 3.3.3 just now, and noticed that it doesn't
exist on the generic GNU FTP server or its mirrors
(ftp://ftp.gnu.org/gnu/gcc for example).  3.3.2 and 3.3.4 are there,
as well as lots of other releases, but 3.3.3 is mysteriously missing.


I looked too and was curious about the 'releases' subdirectory. There
was that 'gcc-3.3.3' fully alone...


It does exist on the specific GCC mirrors, fortunately, but this is a
puzzling glitch.


So it was in 'ftp.gnu.org/gnu/gcc/releases' but not where the other
releases were. Maybe someone was too "creative" and created this subdir
for the releases but forgot to move the others there...

RE: GCC 3.3.3 not on GNU servers...

[Dave Korn]

Kai Ruottu wrote on 23 June 2008 20:05:

> Paul Koning wrote:
> 
>> I was looking for GCC 3.3.3 just now, and noticed that it doesn't
>> exist on the generic GNU FTP server or its mirrors
>> (ftp://ftp.gnu.org/gnu/gcc for example).  3.3.2 and 3.3.4 are there,
>> as well as lots of other releases, but 3.3.3 is mysteriously missing.
> 
> I looked too and was curious about the 'releases' subdirectory. There
> was that 'gcc-3.3.3' fully alone...
> 
>> It does exist on the specific GCC mirrors, fortunately, but this is a
>> puzzling glitch.
> 
> So it was in 'ftp.gnu.org/gnu/gcc/releases' but not where the other
> releases were. Maybe someone was too "creative" and created this subdir
> for the releases but forgot to move the others there...


  Check the list archives.

  I have a vague memory of something getting out of sync between gnu.gcc.org
(aka sourceware) and ftp.gnu.org a few years back.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Should we remove java from the default bootstrap languages?

[Jonathan Wakely]

2008/6/23 NightStrike:
> On 6/23/08, Laurent GUERBY wrote:
>> > I think it could also be addressed with the gcc compile farm.  I
>> > thought that there was some place where we could put patches, and they
>> > would be automatically picked up and tested by some sort of automatic
>> > scripts  am I dreaming about that?
>>
>> Sebastian already write a script to do that, see "Automatic bootstrap
>> and regression testing" on http://gcc.gnu.org/wiki/CompileFarm
>> (might not be up to date, Sebastian ?)
>
> Ok, maybe that can at least for the time being alleviate some of the concerns?
>

I tried using it last week and didn't have permission to write to
Sebastian's dir.

Jonathan

gcc-4.1-20080623 is now available

[gccadmin]

Snapshot gcc-4.1-20080623 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080623/
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/gcc-4_1-branch 
revision 137050

You'll find:

gcc-4.1-20080623.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20080623.tar.bz2 C front end and core compiler

gcc-ada-4.1-20080623.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20080623.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20080623.tar.bz2  C++ front end and runtime

gcc-java-4.1-20080623.tar.bz2 Java front end and runtime

gcc-objc-4.1-20080623.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20080623.tar.bz2The GCC testsuite

Diffs from 4.1-20080616 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [PATCH,rs6000] split up crtsavres into individual files

[Andrew Pinski]

http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00324.html

This introduced a few warnings while building libgcc for powerpc64-linux-gnu:
/home/apinski/src/local/gcc/libgcc/shared-object.mk:26: warning:
overriding commands for target `crtsavfpr.o'
/home/apinski/src/local/gcc/libgcc/config/rs6000/t-ppccomm:109:
warning: ignoring old commands for target `crtsavfpr.o'
/home/apinski/src/local/gcc/libgcc/shared-object.mk:26: warning:
overriding commands for target `crtresfpr.o'
/home/apinski/src/local/gcc/libgcc/config/rs6000/t-ppccomm:112:
warning: ignoring old commands for target `crtresfpr.o'
/home/apinski/src/local/gcc/libgcc/shared-object.mk:26: warning:
overriding commands for target `crtsavgpr.o'
/home/apinski/src/local/gcc/libgcc/config/rs6000/t-ppccomm:115:
warning: ignoring old commands for target `crtsavgpr.o'
etc.

This warning makes my log file bigger and also it is annoying to make
sure I did not mess up my porting of the PS3 changes to the trunk :).

Thanks,
Andrew Pinski

Re: [PATCH,rs6000] split up crtsavres into individual files

[Ben Elliston]

On Mon, 2008-06-23 at 15:52 -0700, Andrew Pinski wrote:

> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00324.html
> 
> This introduced a few warnings while building libgcc for powerpc64-linux-gnu:

I see lots and lots of these myself:

/home/bje/source/gcc-trunk/libgcc/shared-object.mk:26: warning: overriding 
commands for target `crtsavfpr.o'
/home/bje/source/gcc-trunk/libgcc/config/rs6000/t-ppccomm:109: warning: 
ignoring old commands for target `crtsavfpr.o'

Please fix! :-)

Thanks,
Ben

RFA and RFC: tweak -fstrict-aliasing docs, provide pointer-cast example

[Hans-Peter Nilsson]

There's background in
.  Neither
Richi nor me could find the union-assignment "gcc extension" at
a glance, probably because it's not an *extension* but an
implementation-defined behavior, and actually duly documented as
such.  However, to cross-reference that section together with
the clarifying type-punning blurb in the -fstrict-aliasing
documentation seems would be an improvement, and apparently
there's enough confusion about casting, pointers and unions to
call for an extra example, covering the offending code in the
PR.

So far the RFA.  The RFC is whether (to reject this patch and
call for another) to allow the cast-through-pointer-to-union in
the example and the PR as a variant of the blessed
implementation-defined type-punning using unions.  IMHO not, but
the offending code is from a canonical strtod implementation
imported into newlib, and enough people are confused already, so
better ask explicitly before what I fear will be the second
-fstrict-aliasing storm of bug-reports and flames.

Tested by "make info-gcc dvi-gcc" and inspecting output.

Ok to commit?  I'll suggest 4.3-branch too, though the
"miscompilation" doesn't show up there.

(Yes, I also have a fix for newlib.)

gcc:
* doc/invoke.texi (Optimize Options) : Add
anchor for the type-punning blurb.  Cross-reference "Structures
unions enumerations and bit-fields implementation".  Provide a
cast-through-pointer example.  Make final sentence self-contained.
* doc/implement-c.texi (Structures unions enumerations and
bit-fields implementation): Cross-reference the type-punning blurb
in the -fstrict-aliasing documentation.

Index: implement-c.texi
===
--- implement-c.texi(revision 137051)
+++ implement-c.texi(working copy)
@@ -433,8 +433,8 @@ used to determine if a function has not 
 different type (C90 6.3.2.3).}
 
 The relevant bytes of the representation of the object are treated as
-an object of the type used for the access.  This may be a trap
-representation.
+an object of the type used for the access.  @xref{Type-punning}.  This
+may be a trap representation.
 
 @item
 @cite{Whether a ``plain'' @code{int} bit-field is treated as a
Index: invoke.texi
===
--- invoke.texi (revision 137051)
+++ invoke.texi (working copy)
@@ -6146,7 +6146,7 @@ example, an @code{unsigned int} can alia
 @code{void*} or a @code{double}.  A character type may alias any other
 type.
 
-Pay special attention to code like this:
[EMAIL PROTECTED] special attention to code like this:
 @smallexample
 union a_union @{
   int i;
@@ -6163,7 +6163,8 @@ The practice of reading from a different
 recently written to (called ``type-punning'') is common.  Even with
 @option{-fstrict-aliasing}, type-punning is allowed, provided the memory
 is accessed through the union type.  So, the code above will work as
-expected.  However, this code might not:
+expected.  @xref{Structures unions enumerations and bit-fields
+implementation}.  However, this code might not:
 @smallexample
 int f() @{
   a_union t;
@@ -6174,7 +6175,18 @@ int f() @{
 @}
 @end smallexample
 
-Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
+Similarly, access by taking the address, casting the resulting pointer
+and dereferencing the result might not work, even if the cast uses a
+union type, e.g.:
[EMAIL PROTECTED]
+int f() @{
+  double d = 3.0;
+  return ((union a_union *) &d)->i;
[EMAIL PROTECTED]
[EMAIL PROTECTED] smallexample
+
+The @option{-fstrict-aliasing} option is enabled at levels
[EMAIL PROTECTED], @option{-O3}, @option{-Os}.
 
 @item -fstrict-overflow
 @opindex fstrict-overflow

brgds, H-P

Re: gcc-in-cxx branch created

[Tom Tromey]

> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:

Ian> The other major TODO is to work out the details of using STL
Ian> containers with GC allocated objects.  This means teaching gengtype
Ian> how to generate code to traverse STL containers, which would then be
Ian> used during GC.  This is not a task for the faint-hearted.

A related (and IMO probably more difficult) problem is that of
serializing such containers for PCH.

Tom