Closed Bug 170250 Opened 22 years ago Closed 22 years ago

Mozilla should build on gcc 3.3.

Categories

(SeaMonkey :: Build Config, defect, P2)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.2beta

People

(Reporter: dbaron, Assigned: dbaron)

Details

(Whiteboard: [patch])

Attachments

(1 file, 2 obsolete files)

I did a build of the gcc trunk (which will at some point become gcc 3.3), and
compiled a Mozilla non-DEBUG build with it.  I'll attach the patch I needed.  I
suspect I'd need more changes in order to get a DEBUG build to work.

We need to investigate whether gcc's recent changes bring it into line with the
C++ standard (in which case we should change) or whether we should file gcc bugs
in the hopes they'll be fixed before 3.3.

The changes in the patch are:
 * configure/configure.in: eliminate an option that causes a warning for every
file, since the option is C only and we're using it with g++.  It's been
documented as C only for ages.
 * Don't use pasting for things that are supposed to be separate tokens.  (It
only happened in one place, so I suspect this may only be an issue in certain
more-complicated situations, but I'm not sure.  I'm also not sure what the
standard says here.)
 * The "can't pass objects of non-POD type through ..." has become an error
instead of a warning.  I think there are a lot more of these in DEBUG builds.
 * strstream.h doesn't exist anymore.  <sstream> is in the main include
directory and <strstream> and <sstream.h> are in include/backward/.  Fortunately
we don't need it anymore, so the include can just be removed.
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: [patch]
Target Milestone: --- → mozilla1.2beta
See http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01413.html, which has the comment:

!       /* Undefined behaviour [expr.call] 5.2.2/7.  We used to just warn
! 	 here and do a bitwise copy, but now cp_expr_size will abort if we
! 	 try to do that.  */

Looking at that patch, it appears that it applied for 3.2.1, and so we need to
fix this sonner rather than later... I mainly see this when doing printfs of an
nsCOMPtr and forgetting the .get (which is a mistake anyway...).

Do you know how many of these there are?- the only tbox with a warning log is
brad, which doesn't have a new enough g++ version for this warning, I think (its
running 2.95.4). There are almost no clobber builds, and those didn't seem to
find anything, although AIX isn't building tests for me to look for a warning
message.

The ## stuff is correct - a##b is valid only if concat(a,b) gives you a single
valid token. The case you have is concatenating 'foo' and '(args)', which are
separate tokens.
Comment on attachment 100192 [details] [diff] [review]
patch that allows Mozilla to build (non-DEBUG) an run on 2002-09-22 gcc trunk

I'm building with this on gcc 2.96 now to check that it works (and look for
other POD warnings...) Its a full rebuild because of the xpidl change.
Comment on attachment 100192 [details] [diff] [review]
patch that allows Mozilla to build (non-DEBUG) an run on 2002-09-22 gcc trunk

This builds with gcc-2.96, and you've tested on 3.3-CVS, so r=bbaetz

A build log shows three other areas where the POD warning happens:

a) js/src/xpconnect/src/*.cpp, in DebugDump (4 files)

b) In content/base/src/{nsCommentNode, nsGenericElement, nsStyleContext,
nsTextNode, nsGenericHTMLElement}.cpp and
content/xml/content/src/{nsXMLCDATASection, nsXMLProcessingInstruction,
nsXMLEntity, nsXMLNamedNodeMap}.cpp

all in ::List

These are all for mRefCnt, which is now no longer a POD type.

c) directory/xpcom/base/src/nsLDAPOperation.cpp, line 174 and line 255 (twice)
- the PR_LOG for strings. Those are almost defainately bugs, needing a .get().
Attachment #100192 - Flags: review+
Lots more of the same (passing non-POD objects through ...), for DEBUG builds.
Attachment #100192 - Attachment is obsolete: true
Comment on attachment 100368 [details] [diff] [review]
above, with additional changes for DEBUG builds

>Index: directory/xpcom/base/src/nsLDAPOperation.cpp

>@@ -255,7 +255,8 @@
>     PR_LOG(gLDAPLogModule, PR_LOG_DEBUG, 
>            ("nsLDAPOperation::SearchExt(): called with aBaseDn = '%s'; "
>             "aFilter = '%s', aAttrCounts = %u, aSizeLimit = %d", 
>-            aBaseDn, aFilter, aAttrCount, aSizeLimit));
>+            nsCAutoString(aBaseDn).get(), nsCAutoString(aFilter).get(),
>+            aAttrCount, aSizeLimit));

PromiseFlatCString(foo).get() for these?

>Index: xpcom/typelib/xpidl/xpidl.h
>===================================================================
>RCS file: /cvsroot/mozilla/xpcom/typelib/xpidl/xpidl.h,v
>retrieving revision 1.44
>diff -u -d -r1.44 xpidl.h
>--- xpcom/typelib/xpidl/xpidl.h	26 Feb 2002 01:41:12 -0000	1.44
>+++ xpcom/typelib/xpidl/xpidl.h	24 Sep 2002 04:54:00 -0000
>@@ -71,10 +71,10 @@
>  * parens, e.g. XPIDL_WARNING((foo, bar, "sil"))
>  *
>  * Probably best removed when we leave 6.5.  */
>-#define XPIDL_WARNING(x) IDL_tree_warning##x
>+#define XPIDL_WARNING(x) IDL_tree_warning x
> #else
> extern void xpidl_tree_warning(IDL_tree p, int level, const char *fmt, ...);
>-#define XPIDL_WARNING(x) xpidl_tree_warning##x
>+#define XPIDL_WARNING(x) xpidl_tree_warning x
> #endif
> 

You probably want to remove the comment regarding the ## form, just above this.

I'm building now with 2.96, but I don't forsee any problems - r=bbaetz, and
I'll add another comment/patch if there are more issues.
Attachment #100368 - Flags: review+
.. and this compiled on 2.96 w/o any POD warnings.
Comment on attachment 100924 [details] [diff] [review]
revised according to bbaetz's comments

Transferring bbaetz's review (contains the two exact diffs he mentioned).
Attachment #100924 - Flags: review+
cc:ing dbradley, since a few of these changes are in xpidl/xpconnect
Just curious when did mRefCnt become a non-pod
A few weeks ago, when alecf changed it to automatically 0-initialize.
Comment on attachment 100924 [details] [diff] [review]
revised according to bbaetz's comments

gotta love fprintfs.
sr=alecf
r=dbradley for xpconnect & xpidl
Changes look good to me. The token pasting operator was abused a fair bit in
xpidl, thanks for cleaning some more of that up.
Fix checked in to trunk, 2002-09-30 07:17/18 PDT.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: