[webkit-dev] Strang problem with the linux port.

[Mike Emmel]

gcc 4.1 seems to work fine for me must have been a 4.0 bug.

Mike


On 3/13/06, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Mar 11, 2006, at 11:05 AM, Mike Emmel wrote:
>
> > After making the change below and upgrading the port I now compile
> > and run under
> >
> > gcc-3.4 (GCC) 3.4.5 (Debian 3.4.5-1)
> > Copyright (C) 2004 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.
> > There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
>
> We're not really maintaining gcc 3.x support for WebKit - lots of
> things are likely not to work right. I recommend working with gcc 4.x
> instead.
>
> > I'll try 4.1.0 later. I think change is okay since the real type will
> > be picked up on the template return value but dunno for sure.
> >
> >
> >
> > [memmel at debian kxmlcore]$ svn diff HashMapPtrSpec.h
> > Index: HashMapPtrSpec.h
> > ===================================================================
> > --- HashMapPtrSpec.h    (revision 13261)
> > +++ HashMapPtrSpec.h    (working copy)
> > @@ -204,7 +204,7 @@
> >          iterator find(const KeyType& key) { return m_impl.find((void
> > *)(key)); }
> >          const_iterator find(const KeyType& key) const { return
> > m_impl.find((void *)(key)); }
> >          bool contains(const KeyType& key) const { return
> > m_impl.contains((void *)(key)); }
> > -        MappedType get(const KeyType &key) const { return
> > reinterpret_cast<MappedType>(m_impl.get((void *)(key))); }
> > +        MappedType get(const KeyType &key) const { return
> > (MappedType)(m_impl.get((void *)(key))); }
>
> I'm not sure it is a good idea to change a reinterpret_cast to a C-
> style cast. It was a bug in gcc 3.x that it made this error apply to
> casting between void* and a function pointer.
>
> Regards,
> Maciej
>
> >
> >          std::pair<iterator, bool> set(const KeyType &key, const
> > MappedType &mapped)
> >          { return m_impl.set((void *)(key), (void *)(mapped)); }
> > [memmel at debian kxmlcore]$
> >
> >
> > On 3/11/06, Mike Emmel <mike.emmel at gmail.com> wrote:
> >> I switched to gcc3.4  checking for compiler bugs and here is the
> >> error I got
> >>
> >> dom/NodeImpl.h:525:8: warning: extra tokens at end of #endif
> >> directive
> >> ../build/include/JavaScriptCore/HashMapPtrSpec.h: In member function
> >> `Q* KXMLCore::HashMap<P*, Q*, KXMLCore::PtrHash<P*>,
> >> KXMLCore::HashTraits<P*>, KXMLCore::HashTraits<Q*> >::get(P* const&)
> >> const [with P = WebCore::AtomicStringImpl, Q =
> >> KXMLCore::PassRefPtr<WebCore::HTMLElementImpl> ()(const
> >> WebCore::AtomicString&, WebCore::DocumentImpl*,
> >> WebCore::HTMLFormElementImpl*, bool)]':
> >> khtml/html/htmlfactory.cpp:425:   instantiated from here
> >> ../build/include/JavaScriptCore/HashMapPtrSpec.h:207: error: ISO C++
> >> forbids casting between pointer-to-function and pointer-to-object
> >>
> >> gcc-3.4 (GCC) 3.4.5 (Debian 3.4.5-1)
> >> Copyright (C) 2004 Free Software Foundation, Inc.
> >> This is free software; see the source for copying conditions.
> >> There is NO
> >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> >> PURPOSE.
> >>
> >> Trying 4.1.0 now...
> >>
> >>
> >> Mike
> >>
> >>
> >>
> >>
> >>
> >> On 3/9/06, Mike Emmel <mike.emmel at gmail.com> wrote:
> >>> On 3/9/06, Kimmo Kinnunen <kimmok at iki.fi> wrote:
> >>>> Mike Emmel wrote:
> >>>>> Hi all I'm having a strange problem with the linux port and maybe
> >>>>> someone can help.
> >>>>>
> >>>>> The problem is that the macros in
> >>>>>
> >>>>> khtml/html/htmlnames.cpp  fail under linux
> >>>>>
> >>>>> I dumped the cpp code and  I'm getting generated code like the
> >>>>> following.
> >>>>>
> >>>>>  new ((void*)&abbrTag) QualifiedName(nullAtom, "abbr", xhtmlNS);
> >>>>>
> >>>>> Now when I looked at the constructor for QualifiedName it takes
> >>>>> as args
> >>>>>
> >>>>> QualifiedName::QualifiedName(const AtomicString& p, const
> >>>>> AtomicString& l, const AtomicString& n)
> >>>>
> >>>> I've experienced this. I think it's g++-4.0 inlining bug.. It
> >>>> happened
> >>>> for me also, exactly at "abbr" tag..
> >>>>
> >>>
> >>> Yep thats one of them :)
> >>>
> >>>> In dom_qname.cpp (I don't know if this has been renamed) there's
> >>>> a hash
> >>>> function
> >>>>
> >>>> inline unsigned hashComponents(const QualifiedNameComponents& buf)
> >>>>
> >>>> which I believe will get optimized somehow wrong, and it always
> >>>> hashes
> >>>> to zero. I got it working by adding printf("%x", hash); before
> >>>> the zero
> >>>> comparison :)
> >>>>
> >>>> Doesn't make sense unless the printf disables some optimization.
> >>>> In my
> >>>> old code there seems also to be 0x80000000u instead of  0x80000000,
> >>>> which I believe was some sort of hazard at trying to make sure that
> >>>> signedness+bigendian/little endian differences don't matter..
> >>>>
> >>>> I know this sounds rediculous, but try it if you don't have any
> >>>> other
> >>>> clues. My compiler was (GCC) 4.0.2 20050728 (prerelease)
> >>>> [FreeBSD]..
> >>>>
> >>>> Kimmo
> >>>>
> >>>
> >>> So out of that whats the fix for this did you figure out a
> >>> workaround.
> >>> I'm even more puzzled.
> >>>
> >>> Mike
> >>>
> >>>>
> >>>> _______________________________________________
> >>>> webkit-dev mailing list
> >>>> webkit-dev at opendarwin.org
> >>>> http://www.opendarwin.org/mailman/listinfo/webkit-dev
> >>>>
> >>>
> >>
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at opendarwin.org
> > http://www.opendarwin.org/mailman/listinfo/webkit-dev
>
>