Re: HEADS-UP: GCC 3.4.2 snapshot import is imminent

On Fri, Jul 30, 2004 at 04:07:41AM +0000, Alexander Kabaev wrote:
> On Fri, Jul 30, 2004 at 10:58:00AM +0700, Alexey Dokuchaev wrote:
> > On Thu, Jul 29, 2004 at 02:19:19AM +0000, Alexander Kabaev wrote:
> > > On Tue, Jul 27, 2004 at 05:20:21PM +0700, Max Khon wrote:
> > > > Hi, Alexander!
> > > > 
> > > > On Tue, Jul 27, 2004 at 02:18:20AM +0000, Alexander Kabaev wrote:
> > > > 
> > > > >   I am going to do an import of GCC 3.4.x snapshot in approximately
> > > > > 24 hours. At this time I would like to request anyone planning any
> > > > > sweeping changes in the tree to pospone them until new GCC is in.
> > > > > The snapshot will be followed by GCC 3.4.2 release when it is available.
> > > > 
> > > > Do you plan to enable HANDLE_PRAGMA_PACK_PUSH_POP feature?
> > > > 
> > > > /fjoe
> > > Is was too late in the game for me to enable it in this snapshot. I will
> > > consider doing that in the next GCC update. I do not recall anyone ever 
> > > mentioning this feature to me before, let alone aking me to enable it.
> > 
> > Actually, I did, in private mails to both you and obrien_at_ few days ago.
> 
> July 27th, to be exact.
> 
> % gcc --version
> gcc (GCC) 3.4.2 [FreeBSD] 20040728
> 
> One day before import is what I call 'too late in the game'.

No problem; I would be grateful to see it enabled in official 3.4.2
release imported in some (near?) future.

> 
> > I encountered this problem when porting CPP code to FreeBSD recently.
> > #pragma pack (push/pop) feature is enabled with some major Linux
> > distributed gcc (Fedora Core is one of them), which increases chances
> > that we'd have to do something about it, since people tend to write
> > software, test it under MSVC and Fedora's gcc, see it works there, and
> > release it.  Current solution of converting #pragma pack (push/pop) to
> > mere pack(n)/pack() could lead to potential problems (read: bugs) and
> > just isn't The Right Thing(tm).
> > 
> > Since you asked, I also hope you (or someone else) will upgrade manual
> > page for gcc, since it's really outdated for -CURRENT at this moment.
> > If memory serves me right, all necessary patches are in existence, and
> > probably were submitted to our GCC maintainers already.
> 
> Necessary patches, submitted to GCC maintainers are pretty much worthless.
> Let me repeat - new GCC man pages are automatically generated and applying
> patches to that is something I would never do. Whoever touches them
> automatically becomes new GCC documentation maintainer. You have been warned.

AFAIK, patches in question are against automatic generation
infrastructure, not against resulting documentation.  That is, after
being applied, correct and coherent manpages will be generated, just as
you want it to be.

Frankly, I fail to see any technical reason why we have to live with outdate
manpage for that long.  Users don't want to visit gcc.gnu.org every time
they want to see command line options, they want to type man gcc and see
the stuff.  I've always been under impression that keeping documentation
in sync with the code is FreeBSD's strong points, and gcc mans put a big
shadow on this.

./danfe