nsCOMPtr operator== bustage on gcc 2.8.1

VERIFIED WONTFIX

Status

()

P5
normal
VERIFIED WONTFIX
18 years ago
17 years ago

People

(Reporter: jvance, Assigned: dbaron)

Tracking

Trunk
Future
Sun
Solaris
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
Compiling from 0.9 tarball.

using ./configure (no options)
gmake (no parameters)

compiler is gcc 2.8.1 (2.95.2 and 2.7.x unavailable, as is SPRO)
   (is this the source of the problem and therefore a duplicate bug?)

Error generated:

nsRDFContainerUtils.cpp
c++ -o nsRDFContainerUtils.o -c -DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\"
-DMOZ_REFLOW_PERF -DMOZ_REFLOW_PERF_DSP -DOJI   -I../../../dist/include
-I../../../dist/include
-I/export/home3/jvance/downloads/mozilla/dist/include/nspr     
-I/usr/openwin/include   -fPIC  -I/usr/openwin/include -fno-rtti -fno-exceptions
-pedantic -pipe  -DDEBUG -DDEBUG_jvance -DTRACING -g -I/usr/openwin/include
-DMOZILLA_CLIENT -include ../../../config-defs.h
-Wp,-MD,.deps/nsRDFContainerUtils.pp nsRDFContainerUtils.cpp
In file included from ../../../dist/include/nsDebug.h:27,
                 from ../../../dist/include/nsCOMPtr.h:44,
                 from nsRDFContainerUtils.cpp:31:
/export/home3/jvance/downloads/mozilla/dist/include/nspr/prtypes.h:318: warning:
ANSI C++ does not support `long long'
/export/home3/jvance/downloads/mozilla/dist/include/nspr/prtypes.h:319: warning:
ANSI C++ does not support `long long'
nsRDFContainerUtils.cpp: In method `unsigned int
RDFContainerUtilsImpl::IndexOf(class nsIRDFDataSource *, class nsIRDFResource *,
class nsIRDFNode *, int *)':
nsRDFContainerUtils.cpp:528: ambiguous overload for `nsCOMPtr<nsIRDFResource> &
== nsIRDFResource *&'
nsRDFContainerUtils.cpp:528: candidates are: operator ==(nsIRDFResource *,
nsIRDFResource *) <builtin>
../../../dist/include/nsCOMPtr.h:1166:                 operator
==<nsIRDFResource, nsIRDFResource>(const nsCOMPtr<nsIRDFResource> &, const
nsIRDFResource *)
gmake[3]: *** [nsRDFContainerUtils.o] Error 1
gmake[3]: Leaving directory
`/export/home3/jvance/downloads/mozilla/rdf/base/src'
gmake[2]: *** [install] Error 2
gmake[2]: Leaving directory `/export/home3/jvance/downloads/mozilla/rdf/base'
gmake[1]: *** [install] Error 2
gmake[1]: Leaving directory `/export/home3/jvance/downloads/mozilla/rdf'
gmake: *** [install] Error 2

I'd like to get this compiled on Solaris and then contribute the binaries.

Thx, 
John Vance

Comment 1

18 years ago
c++ compiler nuances.  Reassigning to scc.
Assignee: cls → scc

Comment 2

18 years ago
The line should read

  if ( source.get() == aContainer )

re-assigning to waterson to fix it (it's his bustage), and cc'ing dbaron as we
were under the impression this couldn't happen anymore.  You are building with
the latest version of "nsCOMPtr.h", are you not?

What do you think dbaron?
Assignee: scc → waterson
I'd be interested to see the error in config.log from the test in configure.in
for the "ac_nscap_nonconst_opeq_bug".

I don't think the solution is fixing the callers... we really should be able to
find some solution that works.
Taking this bug since I'd like to find a general solution for this for gcc 2.8.x
(although I won't have time in the next few days), and I think there will be
many other examples of this in the build.

If we manage to fix this, I'm not sure that there won't be other problems
compiling with gcc 2.8.x, though...  (I know we should compile with gcc 2.7.2.x
and with egcs-1.1.2 (gcc 2.91.66) and later (gcc 2.95, "2.96", and 3.0).)
Assignee: waterson → dbaron
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla0.9.1
The other possibility (if there isn't a better fix) is that --disable-pedantic
might fix it (and we could have an autoconf test to force that on compilers
broken in this way).
(Reporter)

Comment 6

18 years ago
Here's the relevant section of config.log that dbaron asked for:

configure:11573: checking for correct overload resolution with const and
templates
configure:11608: c++ -c  -pipe  -pedantic   -I/usr/openwin/include conftest.C
1>&5
configure: In function `int main()':
configure:11603: incomplete type unification
configure:11603: ambiguous overload for `Pointer<int> & == const int *&'
configure:11589: candidates are: operator ==<int, const int>(const Pointer<int>
&, const int *)
configure:11595:                 operator ==<int, int>(const Pointer<int> &,
const int *)
configure:11605: warning: control reaches end of non-void function `main()'
configure: failed program was:
#line 11578 "configure"
#include "confdefs.h"

                      template <class T>
                      class Pointer
                        {
                        public:
                          T* myPtr;
                        };
                      
                      template <class T, class U>
                      int operator==(const Pointer<T>& rhs, U* lhs)
                        {
                          return rhs.myPtr == lhs;
                        }
                      
                      template <class T, class U>
                      int operator==(const Pointer<T>& rhs, const U* lhs)
                        {
                          return rhs.myPtr == lhs;
                        }
                    
int main() {

                      Pointer<int> foo;
                      const int* bar;
                      return foo == bar;
                    
; return 0; }


I will attempt --disable-pedantic next.
Also, in the section of xpcom/base/nsCOMPtr.h beginning with 
"// Comparing two |nsCOMPtr|s", could you try commenting out the first through
the fourth functions and uncommenting the seventh through the tenth (they're
essentially commented since that autoconf test fails)?
(Reporter)

Comment 8

18 years ago
Compilation completed and mozilla runs after trying --disable-pedantic.  Please
point me to test cases that hit nsRDFContainerUtilsImpl::IndexOf() so that I can
determine whether I compiled a busted executable.

If it all works then mark as fixed (I see no category for workaround?)  As soon
as I get psm compiled and working too I'll contribute the dist for Solaris 2.7
If it compiles it almost definitely works.  (It doesn't matter which of the
overloaded operators you get because they all do the same thing in the end.)

So since --disable-pedantic is a workaround and it's on a compiler (gcc 2.8.x)
we probably don't officially support, pushing this off to 0.9.3, although
perhaps I should at least write an autoconf test to tell people to use
--disable-pedantic sooner than that...
Severity: blocker → normal
Status: NEW → ASSIGNED
Component: Build Config → XPCOM
Priority: -- → P4
Summary: Compilation fails at nsRDFContainerUtils.cpp → nsCOMPtr operator== bustage on gcc 2.8.1
Target Milestone: mozilla0.9.2 → mozilla0.9.3
egcs 1.0.3 has the same problem, and the error for the autoconf test is:

[dbaron@vorlon /tmp]$ g++ comptr-test.cpp 
comptr-test.cpp: In function `int main()':
comptr-test.cpp:24: incomplete type unification
comptr-test.cpp:24: ambiguous overload for `Pointer<int> & == const int *&'
comptr-test.cpp:10: candidates are: operator ==<int, const int>(const
Pointer<int> &, const int *)
comptr-test.cpp:16:                 operator ==<int, int>(const Pointer<int> &,
const int *)
cls -- Is this patch reasonable?  In particular, will my attempt to cache the
value only when the new test succeeds do what I want?

If so, I should test this on one of the compilers that fails.  I've tested it on
gcc 3.0 and gcc 2.7.2.3 and it works as expected with a modification that I'll
attach in a second (I missed something!).

Comment 14

18 years ago
Yes, I think the caching of the "part 2" test dependent upon the first test will
work.  r=cls
Except when I tried on vorlon, the test didn't catch the potential bustage.

Comment 16

17 years ago
As the original reporter, I suggest that this be changed to WONTFIX.  gcc 2.8.3
is getting ancient, and compiled nightlies are available for Solaris 2.6 that
work on my 2.7 box.  Let's make this one less bug for Mike Angelo to bitch about :-)
OK, WONTFIX.  We don't support gcc 2.7.2.x anymore, so really our minimum gcc
compiler requirement is for some version of egcs between 1.0.3 (1998-05-15) (see
comment 10) and egcs 1.1.12 (1999-03-15), which is what our nightly builds are
*still* done with.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX

Comment 18

17 years ago
verified wontfix.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.