[v3] libstdc++ vs. icc 8.1

[Andrew Pinski]

On Apr 7, 2004, at 00:00, Benjamin Kosnik wrote:

> I'm not putting in workarounds. Read my ChangeLog: I put in fixups.
> You'll note that the issues were small indeed.

Yes but some I see look as they should have been accepted by ICC in the
first place.  I will also note having two compilers can help but not 
always,
see the bug reports about rvalue of a class type binding to a 
reference, the
copy constructor must be accessed.  No other compiler enforces this.

> If IBM puts in the work to fixup libstdc++ for XLC, I'm interested,
> provided the patch is sane. However, I don't have access to that
> compiler, or for that matter that platform.

I looked into the patch and I see that there is one part which I do not
understand why it is wrong as enum in classes are okay and they are even
were public accessed, if ICC rejects this one, I think it is wrong:

*************** struct _Rope_rep_base
*** 459,464 ****
--- 459,469 ----
   # undef __ROPE_DEFINE_ALLOC
   };

+ namespace _Rope_constants
+ {
+   enum { _S_max_rope_depth = 45 };
+   enum _Tag {_S_leaf, _S_concat, _S_substringfn, _S_function};
+ }

   template<class _CharT, class _Alloc>
   struct _Rope_RopeRep : public _Rope_rep_base<_CharT,_Alloc>
*************** struct _Rope_RopeRep : public _Rope_rep_
*** 467,475 ****
   # endif
   {
       public:
!     enum { _S_max_rope_depth = 45 };
!     enum _Tag {_S_leaf, _S_concat, _S_substringfn, _S_function};
!     _Tag _M_tag:8;
       bool _M_is_balanced:8;
       unsigned char _M_depth;
       __GC_CONST _CharT* _M_c_string;
--- 472,478 ----
   # endif
   {
       public:
!     _Rope_constants::_Tag _M_tag:8;
       bool _M_is_balanced:8;
       unsigned char _M_depth;
       __GC_CONST _CharT* _M_c_string;




> Both IBM and Intel have mentioned in passing that they had problems 
> with
> libstdc++ when they tried to compile it with their ABI-compatible linux
> compilers. Since the goal, as far as I understand it, is to have a
> common C++ ABI on linux,  I thought I'd try it myself and see what
> happened. I found the results entertaining, educational, and completely
> harmless to myself.

But we are connected with the FSF and the GNU project if they want to be
compatible the rest of the way with us fine.

<flame protection>
If you are taking about the kernel here fine but it really should be
referenced as GNU/Linux otherwise sorry but as you should know we (you
included) should get some credit in the whole OS and not just Linux.
</flame protection>