[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#907632: [ppc64-el] Breaks building aspectc++



Hi Reinhard,

I took some time to try to analyze this and I see that ac++ processes
files based on llvm (it's compiled with 4.0) using puma.cfg which
is more or less an outpout of g++ defaults (g++ -E -dM -v -x c++
"/dev/null") with for example does #define __float128 __ieee128 which is
POWER specific.
Some sources parsed by ac++ includes c++ headers from libstdc++ .. that
make use of __float128 if support is enabled.

Since gcc-8, on ppc64el, -mfloat128 is default and __float128 is used,
based on __ieee128.
__ieee128 is gcc related and not known by llvm backend (same for
__KC__) and ac++ fails.

Though clang is able to compile with -mfloat128 (not a default option)
and deal with __float128 on ppc64el and we could workaround the gcc
definition of __float128 but I couldn't find a way to make clang
compiler instance to have knowledge of __float128 (I played a bit with
AspectC++/ACProject.cc)

The upstream which has more knowledge could fix this and take advantage
of float128 on ppc64el.
What I propose in the meantime is the following patch that just sticks to
the previous behaviour of gcc that, is -mno-float128 by default.

---
--- a/Ag++/PumaConfigFile.cc
+++ b/Ag++/PumaConfigFile.cc
@@ -118,7 +118,11 @@
     config_command_str = "\"" + _config.cc_bin() + "\" "
         + _config.optvec().getString(
             (OptionItem::OPT_GCC | OptionItem::OPT_CONFIG))
+#ifdef __powerpc__ && __powerpc64__ && __LITTLE_ENDIAN__
+        + " -mno-float128 -E -dM -v -x c++ \"" + empty_file_name + "\"";
+#else
         + " -E -dM -v -x c++ \"" + empty_file_name + "\"";
+#endif
   }
 
   // get c compiler output
---

F.

On Thu, 30 Aug 2018 08:11:27 -0400, Reinhard Tartler <siretart@tauware.de> wrote:
> Package: gcc-8
> Version: 8.2.0-4
> Affects: aspectc++
> X-Debbugs-CC: debian-powerpc@lists.debian.org
> 
> Relevant part from https://buildd.debian.org/status/fetch.php?pkg=aspectc%2B%2B&arch=ppc64el&ver=1%3A2.2%2Bgit20170823-8&stamp=1535500793&raw=0
> 
> In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/src/PrePrintVisitor.Icc:19:
> In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreSemIterator.h:24:
> In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreTreeIterator.h:24:
> In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/PreTree.h:26:
> In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Token.h:26:
> In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Location.h:25:
> In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Filename.h:26:
> In file included from /build/aspectc++-rtQXFn/aspectc++-2.2+git20170823/Puma/gen-release/step1/inc/Puma/Printable.h:25:
> In file included from /usr/include/c++/8/iostream:39:
> In file included from /usr/include/c++/8/ostream:38:
> In file included from /usr/include/c++/8/ios:38:
> In file included from /usr/include/c++/8/iosfwd:40:
> In file included from /usr/include/c++/8/bits/postypes.h:40:
> In file included from /usr/include/c++/8/cwchar:44:
> In file included from /usr/include/wchar.h:30:
> /usr/include/powerpc64le-linux-gnu/bits/floatn.h:72:52: error: unknown machine mode '__KC__'
> typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__)));
>                                                    ^
> /usr/include/powernpc64le-linux-gnu/bits/floatn.h:84:9: error: unknown type name '__ieee128'
> typedef __float128 _Float128;
>         ^
> <command line>:431:20: note: expanded from here
> #define __float128 __ieee128
>                    ^
> 
> If you look at https://buildd.debian.org/status/logs.php?pkg=aspectc%2B%2B&arch=ppc64el,
> you'll see that 1:2.2+git20170823-7 did build successfully. There are no relevant
> upstream code changes, but it was built with gcc-7, which works fine. 1:2.2+git20170823-8 uses gcc-8,
> and that breaks.
> 
> Also it seems this bug seems to affect the architecture ppc64-el only.
> 
> Any ideas, hints and suggestions are much appreciated.
> 
> Best,
> -rt
> 

Attachment: pgpSKPc7D31fO.pgp
Description: PGP signature


Reply to: