[RFC] porting to gcc-4.3 docs

public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed

* [RFC] porting to gcc-4.3 docs
@ 2008-01-09  0:42 Benjamin Kosnik
  2008-01-09  1:04 ` Benjamin Kosnik
                   ` (4 more replies)
  0 siblings, 5 replies; 12+ messages in thread
From: Benjamin Kosnik @ 2008-01-09  0:42 UTC (permalink / raw)
  To: gcc, gerald

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

Hello all.

As many know, various linux distributors are working on re-compiling
their distros with GCC mainline in the hopes of helping GCC 4.3
stabilize. As part of this effort, many bugs have been filed in GCC
bugzilla, and many portability issues have been identified.

Attached is a rough cut of a detailed portability document for
GCC 4.3, compiled with the assistance of Fedora and Debian activists.
(Particular thanks to Jakub J and Martin Michlmayr). Currently it lists
the major issues each distribution has found when upgrading (minus ICE
type errors). It is our goal to have a detailed guide for users of GCC
who wish to upgrade, hosted on the gcc.gnu.org site. Although we'd
initially thought of putting this on the GCC wiki, the current thought
is a better placement would be to put this alongside the release notes,
ie:

http://gcc.gnu.org/gcc-4.3/changes.html

would be joined by

http://gcc.gnu.org/gcc-4.3/porting_to.html

This would imply that the porting document would be checked in to
wwwdocs and available to all the usual GCC contributors to edit and
update.

As such, I'd like to get a general indication from the greater GCC
community as to this plan. Does this document seem like a good idea?
(Previously, we've left this kind of document to the user community.
Often the passage of time has not been particularly kind to these
links.) Is the suggested placement ok for everybody?

If this is ok, some editing of duplicate info from changes.html should
take place. I volunteer to do this.

And, finally, we'd need an ok from the wwwdocs head dude, Gerald.

Thoughts and comments?

best,
benjamin

[-- Attachment #2: porting_to_gcc43.html.bz2 --]
[-- Type: application/x-bzip, Size: 4574 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC] porting to gcc-4.3 docs
  2008-01-09  0:42 [RFC] porting to gcc-4.3 docs Benjamin Kosnik
@ 2008-01-09  1:04 ` Benjamin Kosnik
  2008-01-09  1:06 ` Joe Buck
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 12+ messages in thread
From: Benjamin Kosnik @ 2008-01-09  1:04 UTC (permalink / raw)
  To: gcc; +Cc: gerald


> Attached is a rough cut of a detailed portability document

I also put this up here temporarily:

http://people.redhat.com/~bkoz/porting_to_gcc43.html

-benjamin

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC] porting to gcc-4.3 docs
  2008-01-09  0:42 [RFC] porting to gcc-4.3 docs Benjamin Kosnik
  2008-01-09  1:04 ` Benjamin Kosnik
@ 2008-01-09  1:06 ` Joe Buck
  2008-01-09 16:53 ` Ian Lance Taylor
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 12+ messages in thread
From: Joe Buck @ 2008-01-09  1:06 UTC (permalink / raw)
  To: Benjamin Kosnik; +Cc: gcc, gerald

On Tue, Jan 08, 2008 at 06:41:37PM -0600, Benjamin Kosnik proposes:
> http://gcc.gnu.org/gcc-4.3/changes.html
> 
> would be joined by
> 
> http://gcc.gnu.org/gcc-4.3/porting_to.html
> 
> This would imply that the porting document would be checked in to
> wwwdocs and available to all the usual GCC contributors to edit and
> update.

Fine with me; it should be linked from the "Caveats" section of
gcc-4.3/changes.html.

> Thoughts and comments?

Saw one error:

-----------------------------
Another preprocessor warning change is for trailing whitespace after and #endif, code like:

#ifdef TEST
#endif TEST
-----------------------------

s/trailing whitespace after and/extra tokens after an/

It's, of course, legal to have trailing whitespace and comments after
an #endif.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC] porting to gcc-4.3 docs
  2008-01-09  0:42 [RFC] porting to gcc-4.3 docs Benjamin Kosnik
  2008-01-09  1:04 ` Benjamin Kosnik
  2008-01-09  1:06 ` Joe Buck
@ 2008-01-09 16:53 ` Ian Lance Taylor
  2008-01-10 22:27 ` Gerald Pfeifer
  2008-01-12  6:20 ` Jonathan Wakely
  4 siblings, 0 replies; 12+ messages in thread
From: Ian Lance Taylor @ 2008-01-09 16:53 UTC (permalink / raw)
  To: Benjamin Kosnik; +Cc: gcc, gerald

Benjamin Kosnik <bkoz@redhat.com> writes:

> As such, I'd like to get a general indication from the greater GCC
> community as to this plan. Does this document seem like a good idea?
> (Previously, we've left this kind of document to the user community.
> Often the passage of time has not been particularly kind to these
> links.) Is the suggested placement ok for everybody?

I think this is a great idea.  Thanks for writing it.

Ian

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC] porting to gcc-4.3 docs
  2008-01-09  0:42 [RFC] porting to gcc-4.3 docs Benjamin Kosnik
                   ` (2 preceding siblings ...)
  2008-01-09 16:53 ` Ian Lance Taylor
@ 2008-01-10 22:27 ` Gerald Pfeifer
  2008-01-10 22:32   ` Joe Buck
  2008-01-12  6:20 ` Jonathan Wakely
  4 siblings, 1 reply; 12+ messages in thread
From: Gerald Pfeifer @ 2008-01-10 22:27 UTC (permalink / raw)
  To: Benjamin Kosnik; +Cc: gcc

On Tue, 8 Jan 2008, Benjamin Kosnik wrote:
> As such, I'd like to get a general indication from the greater GCC> community as to this plan. Does this document seem like a good idea?
> (Previously, we've left this kind of document to the user community.
> Often the passage of time has not been particularly kind to these
> links.) Is the suggested placement ok for everybody?
> 
> If this is ok, some editing of duplicate info from changes.html should
> take place. I volunteer to do this.

Sweet, that's really a nice one.  Thanks for stepping up with this,
Benjamin.

In addition to the link from the gcc-4.3/changes.html page I'd also like 
this to become a News item on the main page and we probably also will want 
to add a link from gcc-4.3/index.html itself.  Don't be shy. :-)

> And, finally, we'd need an ok from the wwwdocs head dude, Gerald.

Looks good.  I'll make a few comments below to avoid you getting hit by
the automatic web pages checker, and I hope the various maintainers will
also have a look at their respective domains but let's get this in!

  <?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE html
              PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
              "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
       <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
     <head>
      <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
      <link rev="made" href="mailto:gcc@gcc.gnu.org" />
      <link rel="shortcut icon" href="http://gcc.gnu.org/favicon.ico" />
      <link rel="stylesheet" type="text/css" href="/gnu.css" />
      <link rel="stylesheet" type="text/css" href="http://gcc.gnu.org/gcc.css" />

Most of this, and also the color settings in the <body> tag and the footer
you can omit.  The wwwdocs machinery is taking care of it automagically. 

  compilation or runt-time performance. Some of these changes are not
                   ^^^

Typo.  And, yes, I did spot the reference to naked users.  But heck,
we already knew those free software types all are old hippies, didn't
we? <lol>

  <h3>C language issues</h3>

  <h5>Semantic change of extern inline</h5>

I believe we'll want <h4> here?

  When compiling with -std=c99 or -std=gnu99, the <code>extern

Usually we write <code>-std=c99</code>, as you did later on.

  In addition, improvements to the GCC infrastructure allows several 
  existing warning flags new ability to spot problematic code.

Is this sentence okay?  I'm not a native speaker, so I might miss a
nuance here.

  trailing characters after a closing #endif are now hard errors. 

<code>#endif</code>

  <p>To get rid of this error, remove any trailing text after an #endif, like so.

<code>#endif</code>

I'd say, take the input from Joe and Andrew into account and shoot
ahead!

Gerald

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC] porting to gcc-4.3 docs
  2008-01-10 22:27 ` Gerald Pfeifer
@ 2008-01-10 22:32   ` Joe Buck
  2008-01-10 22:48     ` Joe Buck
  0 siblings, 1 reply; 12+ messages in thread
From: Joe Buck @ 2008-01-10 22:32 UTC (permalink / raw)
  To: Gerald Pfeifer; +Cc: Benjamin Kosnik, gcc

On Thu, Jan 10, 2008 at 11:26:29PM +0100, Gerald Pfeifer wrote:

>   In addition, improvements to the GCC infrastructure allows several 
>   existing warning flags new ability to spot problematic code.
> 
> Is this sentence okay?  I'm not a native speaker, so I might miss a
> nuance here.

No, it's badly worded, but fixing it seems to be more than a matter of
rephrasing.  It's basically saying that existing warning flags will
produce warnings, but I'd prefer to see something more specific.
That is, what kinds of additional warnings should be expected?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC] porting to gcc-4.3 docs
  2008-01-10 22:32   ` Joe Buck
@ 2008-01-10 22:48     ` Joe Buck
  2008-01-10 23:10       ` Dave Korn
  0 siblings, 1 reply; 12+ messages in thread
From: Joe Buck @ 2008-01-10 22:48 UTC (permalink / raw)
  To: Gerald Pfeifer; +Cc: Benjamin Kosnik, gcc

On Thu, Jan 10, 2008 at 02:32:28PM -0800, Joe Buck wrote:
> On Thu, Jan 10, 2008 at 11:26:29PM +0100, Gerald Pfeifer wrote:
> 
> >   In addition, improvements to the GCC infrastructure allows several 
> >   existing warning flags new ability to spot problematic code.
> > 
> > Is this sentence okay?  I'm not a native speaker, so I might miss a
> > nuance here.
> 
> No, it's badly worded, but fixing it seems to be more than a matter of
> rephrasing.  It's basically saying that existing warning flags will
> produce warnings, but I'd prefer to see something more specific.

           ^- s/warnings/additional warnings/, or maybe "fewer false
positives" as well.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: [RFC] porting to gcc-4.3 docs
  2008-01-10 22:48     ` Joe Buck
@ 2008-01-10 23:10       ` Dave Korn
  2008-01-10 23:28         ` Joe Buck
  0 siblings, 1 reply; 12+ messages in thread
From: Dave Korn @ 2008-01-10 23:10 UTC (permalink / raw)
  To: 'Joe Buck', 'Gerald Pfeifer'
  Cc: 'Benjamin Kosnik', gcc

On 10 January 2008 22:47, Joe Buck wrote:

> On Thu, Jan 10, 2008 at 02:32:28PM -0800, Joe Buck wrote:
>> On Thu, Jan 10, 2008 at 11:26:29PM +0100, Gerald Pfeifer wrote:
>> 
>>>   In addition, improvements to the GCC infrastructure allows several
>>>   existing warning flags new ability to spot problematic code.
>>> 
>>> Is this sentence okay?  I'm not a native speaker, so I might miss a
>>> nuance here.
>> 
>> No, it's badly worded, but fixing it seems to be more than a matter of
>> rephrasing.  It's basically saying that existing warning flags will
>> produce warnings, but I'd prefer to see something more specific.
> 
>            ^- s/warnings/additional warnings/, or maybe "fewer false
> positives" as well.

" In addition, improvements to the GCC infrastructure allow
improvements in the ability of several existing warnings to
spot problematic code" ?

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC] porting to gcc-4.3 docs
  2008-01-10 23:10       ` Dave Korn
@ 2008-01-10 23:28         ` Joe Buck
  2008-01-12  2:54           ` Benjamin Kosnik
  0 siblings, 1 reply; 12+ messages in thread
From: Joe Buck @ 2008-01-10 23:28 UTC (permalink / raw)
  To: Dave Korn; +Cc: 'Gerald Pfeifer', 'Benjamin Kosnik', gcc

On Thu, Jan 10, 2008 at 11:10:02PM -0000, Dave Korn wrote:
> On 10 January 2008 22:47, Joe Buck wrote:
> 
> > On Thu, Jan 10, 2008 at 02:32:28PM -0800, Joe Buck wrote:
> >> On Thu, Jan 10, 2008 at 11:26:29PM +0100, Gerald Pfeifer wrote:
> >> 
> >>>   In addition, improvements to the GCC infrastructure allows several
> >>>   existing warning flags new ability to spot problematic code.
> >>> 
> >>> Is this sentence okay?  I'm not a native speaker, so I might miss a
> >>> nuance here.
> >> 
> >> No, it's badly worded, but fixing it seems to be more than a matter of
> >> rephrasing.  It's basically saying that existing warning flags will
> >> produce warnings, but I'd prefer to see something more specific.
> > 
> >            ^- s/warnings/additional warnings/, or maybe "fewer false
> > positives" as well.
> 
> " In addition, improvements to the GCC infrastructure allow
> improvements in the ability of several existing warnings to
> spot problematic code" ?

I would start with Dave's fix, and then see if we can improve it
somehow.  Presumably this is talking about Manuel's work, at least
in part?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC] porting to gcc-4.3 docs
  2008-01-10 23:28         ` Joe Buck
@ 2008-01-12  2:54           ` Benjamin Kosnik
  0 siblings, 0 replies; 12+ messages in thread
From: Benjamin Kosnik @ 2008-01-12  2:54 UTC (permalink / raw)
  To: Joe Buck; +Cc: Dave Korn, 'Gerald Pfeifer', gcc

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]


> I would start with Dave's fix, and then see if we can improve it
> somehow.  Presumably this is talking about Manuel's work, at least
> in part?

In part. Actually, the new warnings are all over the place. 

I've attached a summary from:
http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/Werror/

Please go ahead and improve this wording and substance. I've checked in
a revised copy to wwwdocs.

-best,
benjamin

[-- Attachment #2: new_errors_from_better_warnings --]
[-- Type: text/plain, Size: 15529 bytes --]

anaconda-11.4.0.11-1.log:isys.c:522: error: 'i' may be used uninitialized in this function
anaconda-11.4.0.11-1.log:error: Bad exit status from /var/tmp/rpm-tmp.84415 (%build)
dhcp-3.1.0-12.fc9.log:dst_support.c:162: error: cast from pointer to integer of different size
dhcp-3.1.0-12.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.81355 (%build)
elfutils-0.131-1.fc9.log:common.h:116: error: 'libelf_acquire_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:135: error: 'libelf_release_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:116: error: 'libelf_acquire_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:135: error: 'libelf_release_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:116: error: 'libelf_acquire_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:135: error: 'libelf_release_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:116: error: 'libelf_acquire_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:135: error: 'libelf_release_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:116: error: 'libelf_acquire_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:135: error: 'libelf_release_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:116: error: 'libelf_acquire_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:135: error: 'libelf_release_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:116: error: 'libelf_acquire_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:135: error: 'libelf_release_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:116: error: 'libelf_acquire_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:135: error: 'libelf_release_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:116: error: 'libelf_acquire_all' defined but not used
elfutils-0.131-1.fc9.log:common.h:135: error: 'libelf_release_all' defined but not used
elfutils-0.131-1.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.74639 (%build)
evolution-exchange-2.21.4-1.fc9.log:e-book-backend-gal.c:2468: error: dereferencing type-punned pointer will break strict-aliasing rules
evolution-exchange-2.21.4-1.fc9.log:e-book-backend-gal.c:2477: error: dereferencing type-punned pointer will break strict-aliasing rules
evolution-exchange-2.21.4-1.fc9.log:e-book-backend-gal.c:2487: error: dereferencing type-punned pointer will break strict-aliasing rules
evolution-exchange-2.21.4-1.fc9.log:e-book-backend-gal.c:2497: error: dereferencing type-punned pointer will break strict-aliasing rules
evolution-exchange-2.21.4-1.fc9.log:e-book-backend-gal.c:2659: error: dereferencing type-punned pointer will break strict-aliasing rules
evolution-exchange-2.21.4-1.fc9.log:e-book-backend-gal.c:2665: error: dereferencing type-punned pointer will break strict-aliasing rules
evolution-exchange-2.21.4-1.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.39841 (%build)
gdb-6.7.1-6.fc9.log:../../gdb/symtab.c:2274: error: 'exact' may be used uninitialized in this function
gdb-6.7.1-6.fc9.log:../../gdb/remote.c:1687: error: 'done' may be used uninitialized in this function
gdb-6.7.1-6.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.38201 (%build)
grub-0.97-19.log:main.c:143: error: the address of 'config_file' will always evaluate as 'true'
grub-0.97-19.log:error: Bad exit status from /var/tmp/rpm-tmp.69254 (%build)
libcmpiutil-0.1-6.fc9.log:std_association.c:326: error: the address of 's' will always evaluate as 'true'
libcmpiutil-0.1-6.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.58272 (%build)
libflaim-4.9.989-18.fc9.log:src/kybuild.cpp:537: error: suggest parentheses around && within ||
libflaim-4.9.989-18.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.767 (%build)
libpfm-3.2-0.071017.1.fc9.log:pfmlib_pentium4.c:368: error: array subscript is above array bounds
libpfm-3.2-0.071017.1.fc9.log:pfmlib_pentium4.c:370: error: array subscript is above array bounds
libpfm-3.2-0.071017.1.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.27896 (%build)
linphone-1.7.1-4.fc8.log:alsa.c:56: error: the address of 'hwparams' will always evaluate as 'true'
linphone-1.7.1-4.fc8.log:alsa.c:129: error: the address of 'swparams' will always evaluate as 'true'
linphone-1.7.1-4.fc8.log:error: Bad exit status from /var/tmp/rpm-tmp.73293 (%build)
mkinitrd-6.0.24-1.fc9.log:procdev.h:60: error: inline function 'getDevsFromProc' declared but never defined
mkinitrd-6.0.24-1.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.76796 (%build)
nc-1.84-14.fc9.log:netcat.c:791: error: the address of 'obuf' will always evaluate as 'true'
nc-1.84-14.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.34150 (%build)
NetworkManager-0.7.0-0.8.svn3181.fc9.log:nm-utils.c:128: error: dereferencing type-punned pointer will break strict-aliasing rules
NetworkManager-0.7.0-0.8.svn3181.fc9.log:nm-utils.c:152: error: dereferencing type-punned pointer will break strict-aliasing rules
NetworkManager-0.7.0-0.8.svn3181.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.15894 (%build)
openhpi-2.10.1-1.fc9.log:safhpi.c:556: error: array subscript is above array bounds
openhpi-2.10.1-1.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.62135 (%build)
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:94: error: inline function 'ped_div_round_to_nearest' declared but never defined
parted-1.8.6-13.fc9.log:../../include/parted/natmath.h:91: error: inline function 'ped_div_round_up' declared but never defined
parted-1.8.6-13.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.71616 (%build)
trousers-0.3.1-5.fc9.log:tspi_nv.c:220: error: cast from pointer to integer of different size
trousers-0.3.1-5.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.74684 (%build)
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsCharTraits.h:308: error: conversion to 'PRUnichar' from 'int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsCharTraits.h:563: error: conversion to 'char' from 'int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentSubstring.h:74: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentSubstring.h:77: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentSubstring.h:74: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentSubstring.h:77: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTString.h:454: error: conversion to 'PRUint32' from 'size_t' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTString.h:454: error: conversion to 'PRUint32' from 'size_t' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:76: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:89: error: conversion to 'PRUint32' from 'size_t' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:117: error: conversion to 'PRUint32' from 'size_t' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:124: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:76: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:89: error: conversion to 'PRUint32' from 'size_t' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:117: error: conversion to 'PRUint32' from 'size_t' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:124: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:nsCookie.h:126: error: conversion to 'PRPackedBool' from 'PRBool' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsCharTraits.h:656: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsCharTraits.h:308: error: conversion to 'PRUnichar' from 'int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsCharTraits.h:563: error: conversion to 'char' from 'int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentSubstring.h:74: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentSubstring.h:77: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentSubstring.h:74: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentSubstring.h:77: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTString.h:454: error: conversion to 'PRUint32' from 'size_t' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTString.h:454: error: conversion to 'PRUint32' from 'size_t' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:76: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:89: error: conversion to 'PRUint32' from 'size_t' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:117: error: conversion to 'PRUint32' from 'size_t' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:124: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:76: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:89: error: conversion to 'PRUint32' from 'size_t' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:117: error: conversion to 'PRUint32' from 'size_t' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/string/nsTDependentString.h:124: error: conversion to 'PRUint32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:nsCookie.h:126: error: conversion to 'PRPackedBool' from 'PRBool' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:../../../dist/include/xpcom/nsVoidArray.h:409: error: conversion to 'PRBool' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:nsCookieService.cpp:403: error: conversion to 'PROffset32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:nsCookieService.cpp:403: error: conversion to 'PROffset32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:nsCookieService.cpp:403: error: conversion to 'PROffset32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:nsCookieService.cpp:403: error: conversion to 'PROffset32' from 'long int' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:nsCookieService.cpp:774: error: conversion to 'PRUint8' from 'PRInt32' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:nsCookieService.cpp:777: error: conversion to 'PRUint16' from 'PRInt32' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:nsCookieService.cpp:780: error: conversion to 'PRUint16' from 'PRInt32' may alter its value
xulrunner-1.9-0.beta2.1.fc9.log:nsCookieService.cpp:1050: error: suggest parentheses around && within ||
xulrunner-1.9-0.beta2.1.fc9.log:error: Bad exit status from /var/tmp/rpm-tmp.23252 (%build)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC] porting to gcc-4.3 docs
  2008-01-09  0:42 [RFC] porting to gcc-4.3 docs Benjamin Kosnik
                   ` (3 preceding siblings ...)
  2008-01-10 22:27 ` Gerald Pfeifer
@ 2008-01-12  6:20 ` Jonathan Wakely
  2008-01-14 16:36   ` Benjamin Kosnik
  4 siblings, 1 reply; 12+ messages in thread
From: Jonathan Wakely @ 2008-01-12  6:20 UTC (permalink / raw)
  To: Benjamin Kosnik; +Cc: gcc, gerald

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

"If the old GNU extern inline behavior is desired, one can use extern
inline __attribute__((__gnu_inline__)). The use of this attribute can
be guarded by #ifdef __GNUC_STDC_INLINE__ which is a macro which is
defined when inline has the ISO C99 behavior, or compiled with
-fgnu89-inline option."

I think this is phrased a bit confusingly, the "or compiled with ..."
branch refers to the first sentence, but is part of the second
sentence which makes it seem like it's related to the macro.

This must be the english language equivalent of a dangling else.

The attached patch makes it clearer to me, does anyone agree?

Jon

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gcc-wwwporting.patch --]
[-- Type: text/x-patch; name=gcc-wwwporting.patch, Size: 864 bytes --]

Index: htdocs/gcc-4.3/porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.3/porting_to.html,v
retrieving revision 1.1
diff -u -p -r1.1 porting_to.html
--- htdocs/gcc-4.3/porting_to.html	12 Jan 2008 00:35:30 -0000	1.1
+++ htdocs/gcc-4.3/porting_to.html	12 Jan 2008 03:29:16 -0000
@@ -63,8 +63,8 @@ If the old GNU extern inline behavior is
 use <code>extern inline __attribute__((__gnu_inline__))</code>. The
 use of this attribute can be guarded by <code>#ifdef
 __GNUC_STDC_INLINE__</code> which is a macro which is defined when
-inline has the ISO C99 behavior, or compiled
-with <code>-fgnu89-inline</code> option.
+inline has the ISO C99 behavior. Alternatively the code can be compiled
+with the <code>-fgnu89-inline</code> option.
 </p>
 
 <p>The resulting, changed code looks like:</p>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC] porting to gcc-4.3 docs
  2008-01-12  6:20 ` Jonathan Wakely
@ 2008-01-14 16:36   ` Benjamin Kosnik
  0 siblings, 0 replies; 12+ messages in thread
From: Benjamin Kosnik @ 2008-01-14 16:36 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: gcc, gerald


> The attached patch makes it clearer to me, does anyone agree?

Please check this in. Thanks Jonathan!

-benjamin

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2008-01-14 16:23 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-09  0:42 [RFC] porting to gcc-4.3 docs Benjamin Kosnik
2008-01-09  1:04 ` Benjamin Kosnik
2008-01-09  1:06 ` Joe Buck
2008-01-09 16:53 ` Ian Lance Taylor
2008-01-10 22:27 ` Gerald Pfeifer
2008-01-10 22:32   ` Joe Buck
2008-01-10 22:48     ` Joe Buck
2008-01-10 23:10       ` Dave Korn
2008-01-10 23:28         ` Joe Buck
2008-01-12  2:54           ` Benjamin Kosnik
2008-01-12  6:20 ` Jonathan Wakely
2008-01-14 16:36   ` Benjamin Kosnik

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).