[Bug jit/114105] --disable-bootstrap based builds vs libcc1 and gcc/jit use of gcc/system.h poisoning policy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114105 --- Comment #7 from Mark Millard --- (In reply to Andrew Pinski from comment #6) > . . . > It is documented here: > https://gcc.gnu.org/install/prerequisites.html > > "To build all languages in a cross-compiler or other configuration where > 3-stage bootstrap is not performed, you need to start with an existing GCC > binary (version 4.8.3 or later) because source code for language frontends > other than C might use GCC extensions. > " > > Though it should say other than `C and C++` but that is a minor thing. Ahh, not text I can find by looking for "--disable-bootstrap" or "disable-bootstrap" and not explicit in terms of any command line options syntax in general for the overall issue. That probably explains why I did not run into it. Again: Thanks. (I do like the wording about the front-end vs. not distinctions for --disable-bootstrap .)
[Bug jit/114105] --disable-bootstrap based builds vs libcc1 and gcc/jit use of gcc/system.h poisoning policy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114105 --- Comment #5 from Mark Millard --- (In reply to Andrew Pinski from comment #2) > . . . > >Part of the reason FreeBSD puts effort into making --disable-bootstrap work > This should not be done unless you are building with GCC itself. The reason > is only the C, C++ front-ends are supposed to be able to compile with a > (non-GCC) C++11 compiler. So FreeBSD is doing it wrong anyways. Thanks for that wording. I did not get that relationship from the wording in the standard documentation that talks about --disable-bootstrap . It might be good if that documentation did also have such wording. I'll note that the FreeBSD lang/gcc* ports do not normally use --disable-bootstrap .
[Bug c++/114105] New: --disable-bootstrap based builds vs libcc1 and gcc/jit use of gcc/system.h poisoning policy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114105 Bug ID: 114105 Summary: --disable-bootstrap based builds vs libcc1 and gcc/jit use of gcc/system.h poisoning policy Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: markmigm at gmail dot com Target Milestone: --- [ Note: not limited to gcc14 : FreeBSD ports lang/gcc12 (& -devel) and lang/gcc13 (& -devel) had to be patched for libcc1 , not just lang/gcc14-devel ] Attempting --disable-bootstrap builds of various gcc versions under clang & libc++ gets errors from, appearently, assuming that the sources and toolchain will follow the gcc internal poisoning principles. The results are errors like: In file included from /wrkdirs/share/dim/ports/lang/gcc13/work/gcc-13.2.0/libcc1/libcc1plugin.cc:72: In file included from /usr/include/c++/v1/vector:321: In file included from /usr/include/c++/v1/__format/formatter_bool.h:20: In file included from /usr/include/c++/v1/__format/formatter_integral.h:32: /usr/include/c++/v1/locale:289:36: error: attempt to use a poisoned identifier 289 | __status = (unsigned char*)malloc(__nkw); |^ /usr/include/c++/v1/locale:1584:28: error: attempt to use a poisoned identifier 1584 | __ob = (char_type*)malloc(2*static_cast(__nc)*sizeof(char_type)); |^ (FreeBSD patches lang/gcc12* and lang/gcc13* and lang/gcc14-devel for the libcc1 issues involving poisoning identifiers.) and: In file included from /wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240218/gcc/jit/dummy-frontend.cc:23: In file included from /wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240218/gcc/jit/jit-playback.h:26: In file included from /usr/include/c++/v1/vector:321: In file included from /usr/include/c++/v1/__format/formatter_bool.h:20: In file included from /usr/include/c++/v1/__format/formatter_integral.h:32: /usr/include/c++/v1/locale:289:36: error: attempt to use a poisoned identifier 289 | __status = (unsigned char*)malloc(__nkw); |^ (FreeBSD is still working on patching lang/gcc14-devel for its gcc/jit issues involving poisoning identifiers. It is possible that after that is done more issues will be exposed.) Part of the reason FreeBSD puts effort into making --disable-bootstrap work, despite it not being the default in the ports, is to allow builds that stay in the bounds of the free version of, for example, cirrus.
[Bug target/114091] gcc/config/aarch64/aarch64.cc has code requiring c++14 instead of c++11, so g++14 bootsrap fails in my example context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114091 --- Comment #2 from Mark Millard --- (In reply to Andrew Pinski from comment #1) > This has already been fixed, over 2 weeks ago. > > >20240114 > > You are using a GCC 14 snapshot from a month ago even. Please try a newer > snapshot before reporting a bug next time. > > *** This bug has been marked as a duplicate of bug 113763 *** Sorry. I was building a FreeBSD port and I'm not a port maintainer, much less one for FreeBSD's lang/gcc14-devel . I've sent the port maintainer a copy of your reply. Thanks.
[Bug c++/114091] New: gcc/config/aarch64/aarch64.cc has code requiring c++14 instead of c++11, so g++14 bootsrap fails in my example context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114091
Bug ID: 114091
Summary: gcc/config/aarch64/aarch64.cc has code requiring c++14
instead of c++11, so g++14 bootsrap fails in my
example context
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markmigm at gmail dot com
Target Milestone: ---
[I'm not sure where gcc/config/aarch64/aarch64.cc fits in the
component alternatives. Feel free to correct that if I got it
wrong.]
gcc bootstrap is based on c++11, which predates the constructors for pair
being constexpr. The gcc/config/aarch64/aarch64.cc specific code can fail
because of using pair constructors where constant expressions are required:
/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc/config/aarch64/aarch64.cc:13095:50:
error: constexpr variable 'tiles' must be initialized by a constant expression
static constexpr std::pair tiles[] = {
^ ~
/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc/config/aarch64/aarch64.cc:13096:5:
note: non-constexpr constructor 'pair' cannot be used in a
constant expression
{ 0xff, 'b' },
^
This stops the bootstrap in the example context.
This is detected when clang is doing the bootstrapping on FreeBSD.
For reference:
c++ -std=c++11 -fPIC -c -g -DIN_GCC -fno-strict-aliasing -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -fPIC -I. -I.
-I/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc
-I/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc/.
-I/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc/../include
-I/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc/../libcpp/include
-I/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc/../libcody
-I/usr/local/include
-I/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc/../libdecnumber
-I/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc/../libdecnumber/bid
-I../libdecnumber
-I/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc/../libbacktrace
-DLIBICONV_PLUG -o aarch64.o -MT aarch64.o -MMD -MP -MF ./.deps/aarch64.TPo
/wrkdirs/usr/ports/lang/gcc14-devel/work/gcc-14-20240114/gcc/config/aarch64/aarch64.cc
where clang used its libc++ (its a FreeBSD context):
/usr/include/c++/v1/__utility/pair.h:225:5: note: declared here
225 | pair(_U1&& __u1, _U2&& __u2)
| ^
having -std=c++11 on the command line. That results in lack of
constexpr status in libc++ .
It would appear that until gcc bootstrap intends on being based on
c++14 (or later) that the gcc/config/aarch64/aarch64.cc code
reported is presuming a post-c++11 context when it should not be.
[Bug c++/103499] C++20 modules error: invalid use of non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103499 --- Comment #6 from Mark Millard --- (In reply to Jonathan Wakely from comment #5) The relationship I was thinking of was that, without this being fixed, the full set of header units for the standard library probably could not be completed: a blocking issue relative to completing "header-units of STL header files". (Likely necessary but not sufficient for such completion.) I was not trying to say that the issue was limited to just "header-units of STL header files". As long as the problem is fixed, the relationship would be handled, just more implicitly relative to the completion of the "header-units of STL header files". It is good to have examples that do not involve materials from /usr/include/c++/ , for sure.
[Bug c++/103499] C++20 modules error: invalid use of non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103499
--- Comment #3 from Mark Millard ---
(In reply to Mark Millard from comment #2 and #1)
Since my example shows that std::is_nothrow_constructible_v<. . .>
can run into the problem, adding bugzilla 99227 ("[meta] [modules]
Bugs relating to header-units of STL header files") to the Blocks
list might be appropriate here. (Not something I can do.)
[Bug c++/99426] [modules] failed to read compiled module cluster 1186: Bad file data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99426
Mark Millard changed:
What|Removed |Added
CC||markmigm at gmail dot com
--- Comment #5 from Mark Millard ---
I've run into this sort of problem under Fedora 36 with its g++ 12.2.1 :
# rm -fr gcm.cache/*
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -g -fPIC ios
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -g -fPIC iostream
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -g -fPIC ostream
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -g -fPIC iomanip
In module imported at /usr/include/c++/12/istream:38:1,
included from /usr/include/c++/12/sstream:38,
from /usr/include/c++/12/bits/quoted_string.h:38,
from /usr/include/c++/12/iomanip:45:
/usr/include/c++/12/ios: error: failed to read compiled module cluster 927: Bad
file data
/usr/include/c++/12/ios: note: compiled module file is
‘gcm.cache/./usr/include/c++/12/ios.gcm’
In file included from /usr/include/c++/12/string:53,
from /usr/include/c++/12/bits/locale_classes.h:40,
from /usr/include/c++/12/bits/ios_base.h:41,
from /usr/include/c++/12/iomanip:40:
/usr/include/c++/12/bits/basic_string.h:3972:40: fatal error: failed to load
pendings for ‘__gnu_cxx::__stoa’
3972 | { return __gnu_cxx::__stoa(::strtol, "stoi",
__str.c_str(),
|
^
3973 | __idx, __base); }
| ~~
compilation terminated.
But moving ios to be the last of the 4 did not generate any messages:
# rm -fr gcm.cache/*
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -g -fPIC iostream
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -g -fPIC ostream
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -g -fPIC iomanip
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -g -fPIC ios
I've run into other examples of order dependencies. I've not found a
way to predict a order that will be tolerated.
The "Last reconfirmed" could be updated.
[Bug c++/106820] [modules] internal compiler error: in function_and_variable_visibility [for std::shared_ptr{b,??} use via header unit]: mishandling of "weak" usage generated via __gthr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820 --- Comment #5 from Mark Millard --- I probably should have reported the backtrace when fancy_abort has been called (stopped there via breakpoint): (lldb) bt * thread #1, name = 'cc1plus', stop reason = breakpoint 1.1 * frame #0: 0x02e43108 cc1plus`fancy_abort(file="/wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/gcc/ipa-visibility.cc", line=716, function="function_and_variable_visibility") at diagnostic.cc:2024:7 frame #1: 0x022ca8ac cc1plus`function_and_variable_visibility(whole_program=false) at ipa-visibility.cc:712:7 frame #2: 0x022cc768 cc1plus`pass_ipa_function_and_variable_visibility::execute(this=0x8bc7a600, (null)=0x) at ipa-visibility.cc:993:14 frame #3: 0x02474ca8 cc1plus`execute_one_pass(pass=0x8bc7a600) at passes.cc:2638:22 frame #4: 0x02476890 cc1plus`execute_ipa_pass_list(pass=0x8bc7a600) at passes.cc:3078:11 frame #5: 0x01ad7794 cc1plus`ipa_passes() at cgraphunit.cc:2161:7 frame #6: 0x01ad7448 cc1plus`symbol_table::compile(this=0x8dd5c000) at cgraphunit.cc:2282:5 frame #7: 0x01ad88c0 cc1plus`symbol_table::finalize_compilation_unit(this=0x8dd5c000) at cgraphunit.cc:2530:3 frame #8: 0x02786338 cc1plus`compile_file() at toplev.cc:479:15 frame #9: 0x0278568c cc1plus`do_compile(no_backend=false) at toplev.cc:2144:11 frame #10: 0x02783b88 cc1plus`toplev::main(this=0x837baafe, argc=17, argv=0x837bab68) at toplev.cc:2296:7 frame #11: 0x02e1da3c cc1plus`main(argc=17, argv=0x837bab68) at main.cc:39:18 frame #12: 0x0105b448 cc1plus`__start(argc=17, argv=0x837bab68, env=0x837babf8, cleanup=) at crt1_c.c:72:7 frame #13: 0x31f1ad9570d8 ld-elf.so.1`.rtld_start at rtld_start.S:41
[Bug c++/106820] internal compiler error: in function_and_variable_visibility [for std::shared_ptr{b,??} use via module]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820 --- Comment #4 from Mark Millard --- (In reply to Mark Millard from comment #3) > . . . > And in a debugger I see: > > (lldb) print node->decl->decl_with_vis.weak_flag > (unsigned int) $2 = 1 > (lldb) print node->decl->decl_with_vis.comdat_flag > (unsigned int) $3 = 0 > (lldb) print node->weakref > (unsigned int) $4 = 0 > (lldb) print node->decl->decl_common.decl_flag_1 > (unsigned int) $5 = 0 > > and: > > (lldb) call debug_tree(node->decl) > type type size > unit-size > align:32 warn_if_not_align:0 symtab:0 alias-set -1 > canonical-type 0x8cd415e8 precision:32 min -2147483648> max > pointer_to_this reference_to_this > > > SI size unit-size 0x8cd40270 4> > align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type > 0x939e7f18 > arg-types > chain >> > pointer_to_this > > addressable used static tree_3 weak in_system_header decl_5 decl_6 DI > /usr/local/lib/gcc12/include/c++/aarch64-portbld-freebsd14.0/bits/gthr- > default.h:121:1 align:32 warn_if_not_align:0 context 0x8cd3e000 module_shared_ptr_alias_construction_failure.cpp> > attributes purpose normal local bindings <0x0>> > value value > readonly constant static "pthread_mutex_unlock\000">> > chain purpose normal local bindings <0x0 > full-name "int __gthrw_pthread_mutex_unlock(pthread_mutex**)" > module 1:/usr/local/lib/gcc12/include/c++/memory exported chain > > And, sure enough, __gthrw_pthread_mutex_unlock looks to involve "weak" via https://github.com/gcc-mirror/gcc/blob/master/libgcc/gthr-posix.h having in use: # define __gthrw2(name,name2,type) \ static __typeof(type) name \ __attribute__ ((__weakref__(#name2), __copy__ (type))); \ __gthrw_pragma(weak type) . . . /* Typically, __gthrw_foo is a weak reference to symbol foo. */ #define __gthrw(name) __gthrw2(__gthrw_ ## name,name,name) . . . __gthrw(pthread_mutex_unlock) There could be more examples of the type of issue but the build stops at the first to fail the gcc_assert.
[Bug c++/106820] internal compiler error: in function_and_variable_visibility [for std::shared_ptr{b,??} use via module]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820 --- Comment #3 from Mark Millard --- (In reply to Mark Millard from comment #2) I managed to build lang/gcc12 with -g -O0 in use and so can report: The failing assert looks like: gcc_assert ((!DECL_WEAK (node->decl) && !DECL_COMDAT (node->decl)) || TREE_PUBLIC (node->decl) || node->weakref || DECL_EXTERNAL (node->decl)); And in a debugger I see: (lldb) print node->decl->decl_with_vis.weak_flag (unsigned int) $2 = 1 (lldb) print node->decl->decl_with_vis.comdat_flag (unsigned int) $3 = 0 (lldb) print node->weakref (unsigned int) $4 = 0 (lldb) print node->decl->decl_common.decl_flag_1 (unsigned int) $5 = 0 and: (lldb) call debug_tree(node->decl) unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x8cd415e8 precision:32 min max pointer_to_this reference_to_this > SI size unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x939e7f18 arg-types chain >> pointer_to_this > addressable used static tree_3 weak in_system_header decl_5 decl_6 DI /usr/local/lib/gcc12/include/c++/aarch64-portbld-freebsd14.0/bits/gthr-default.h:121:1 align:32 warn_if_not_align:0 context attributes > value readonly constant static "pthread_mutex_unlock\000">> chain >>> full-name "int __gthrw_pthread_mutex_unlock(pthread_mutex**)" module 1:/usr/local/lib/gcc12/include/c++/memory exported chain >
[Bug c++/106820] internal compiler error: in function_and_variable_visibility [for std::shared_ptr{b,??} use via module]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820
Mark Millard changed:
What|Removed |Added
Summary|internal compiler error: in |internal compiler error: in
|function_and_variable_visib |function_and_variable_visib
|ility [for |ility [for
|std::dynamic_pointer_cast |std::shared_ptr{b,??}
|use via module]|use via module]
--- Comment #2 from Mark Millard ---
I've produced a more reduced example source:
import ;
struct data
{
virtual ~data() = default;
};
auto test(std::shared_ptr b)
{
return std::shared_ptr{b,nullptr};
}
nullptr is not special here: other alternative raw pointers also get
the "internal compiler error: in function_and_variable_visibility"
notice. nullptr is just the simplest example.
Using a #include instead also gets the error (as expected) --unless
the -fmodules-ts command line option is then omitted. -fmodules-ts
is important to getting the message in the FreeBSD lang/gcc12 context.
[Bug c++/106825] header unit based std::shared_ptr<...>(...) use gets: undefined reference to `std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()', aarch64 example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106825 --- Comment #4 from Mark Millard --- (In reply to Mark Millard from comment #3) . . . > I'll also report that the tiny test also fails for clang++15 > (from FreeBSD's devel/llvm15 port) . . . Not true: I figured out that, for how the clang++15 command lines work in this area, I was missing a step (and a resulting file). With the step and file reference added the tiny example compiles and links just fine.
[Bug c++/106825] header unit based std::shared_ptr<...>(...) use gets: undefined reference to `std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()', aarch64 example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106825
--- Comment #3 from Mark Millard ---
(In reply to Mark Millard from comment #2)
. . .
> export module module_template_specialization_intf;
>
> export template int test();
> export template<> int test<0>() { return -1; };
> export template<> int test<1>() { return -2; };
. . .
In case it is unclear: libstdc++ is using such specializations
that lead to the libstdc++ tied instances of such failures that
was the basis for my original submittal.
Technically libstdc++ could avoid such specializations as an
implementation technique and avoid the problem for code using
libstdc++ .
If that happened, the tiny test would still not be covered and
would become a separate issue.
I'll also report that the tiny test also fails for clang++15
(from FreeBSD's devel/llvm15 port) but libc++ does not have
the problem for the original example I submitted here. So,
apparently, libc++ avoids use of template specializations
in its implementation of the specific original example.
[Bug c++/106825] header unit based std::shared_ptr<...>(...) use gets: undefined reference to `std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()', aarch64 example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106825
--- Comment #2 from Mark Millard ---
An tiny example that avoids all involvement of libstdc++ is (showing
g++12 from FreeBSD in the comments, instead of c++ for fedora
--but both contexts fail):
# more module_template_specialization_failure.cppm
// g++12 -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -xc++-system-header
memory
// g++12 -std=c++20 -fmodules-ts -g -fPIC -xc++ -c
module_template_specialization_failure.cppm
export module module_template_specialization_intf;
export template int test();
export template<> int test<0>() { return -1; };
export template<> int test<1>() { return -2; };
# more module_template_specialization_failure.cpp
// g++12 -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -xc++-system-header
memory
// g++12 -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -fPIC -c
-xc++ module_template_specialization_failure.cppm
// g++12 -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -fPIC
-omain_using_plugin module_template_specialization_failure.cpp
import module_template_specialization_intf;
int main()
{
return test<0>()-test<1>();
}
The sequence and result is:
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -xc++-system-header
memory
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -fPIC -c -xc++
module_template_specialization_failure.cppm
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -fPIC -omain_using_plugin
module_template_specialization_failure.cpp
/usr/bin/ld: /tmp/ccmyKNjk.o: in function `main':
module_template_specialization_failure.cpp:(.text+0xc): undefined reference to
`_ZW35module_template_specialization_intf4testILi0EEiv'
/usr/bin/ld: module_template_specialization_failure.cpp:(.text+0x14): undefined
reference to `_ZW35module_template_specialization_intf4testILi1EEiv'
/usr/bin/ld: /tmp/ccmyKNjk.o: in function
`_GLOBAL__sub_I_module_template_specialization_failure.cpp':
module_template_specialization_failure.cpp:(.text+0x30): undefined reference to
`_ZGIW35module_template_specialization_intf'
collect2: error: ld returned 1 exit status
[Bug c++/106825] header unit based std::shared_ptr<...>(...) use gets: undefined reference to `std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()', aarch64 example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106825 --- Comment #1 from Mark Millard --- (In reply to Mark Millard from comment #0) FYI: I also see this on FreeBSD via the lang/gcc12 port (that, in my installed context, is at 12.2.0), using the default library: libstdc++ . I do not see any failure on FreeBSD when I use -stdlib=libc++ on the two command lines: # g++12 -std=c++20 -stdlib=libc++ -pedantic -Wall -Wextra -fmodules-ts -fPIC -xc++-system-header memory # g++12 -std=c++20 -stdlib=libc++ -pedantic -Wall -Wextra -fmodules-ts -fPIC -omodule_shared_ptr_failure module_shared_ptr_failure.cpp #
[Bug c++/106825] New: header unit based std::shared_ptr<...>(...) use gets: undefined reference to `std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()', aarch64 example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106825
Bug ID: 106825
Summary: header unit based std::shared_ptr<...>(...)
use gets: undefined reference to
`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M
_release()', aarch64 example
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markmigm at gmail dot com
Target Milestone: ---
In, for example, aarch64 Fedora 36, with its g++ 12.2.1 related
toolchain, the program:
// c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -fPIC
-xc++-system-header memory
// c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -fPIC
-omodule_shared_ptr_failure module_shared_ptr_failure.cpp
import ;
struct base{int v=0;};
int main()
{
return std::shared_ptr(new base{})->v;
}
gets the following failure for the shown command sequence:
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -fPIC -xc++-system-header
memory
# c++ -std=c++20 -pedantic -Wall -Wextra -fmodules-ts -fPIC
-omodule_shared_ptr_failure module_shared_ptr_failure.cpp
/usr/bin/ld: /tmp/ccm2DaSN.o: in function
`std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count()':
module_shared_ptr_failure.cpp:(.text._ZNSt14__shared_countILN9__gnu_cxx12_Lock_policyE2EED2Ev[_ZNSt14__shared_countILN9__gnu_cxx12_Lock_policyE2EED5Ev]+0x24):
undefined reference to
`std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()'
collect2: error: ld returned 1 exit status
The -fPIC use is not required to see the problem.
For reference:
# c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/12/lto-wrapper
Target: aarch64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-12.2.1-20220819/obj-aarch64-redhat-linux/isl-install
--enable-gnu-indirect-function --build=aarch64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.1 20220819 (Red Hat 12.2.1-1) (GCC)
[Bug c++/106820] internal compiler error: in function_and_variable_visibility [for std::dynamic_pointer_cast use via module]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820 --- Comment #1 from Mark Millard --- (In reply to Mark Millard from comment #0) > Failing command sequence (from a FreeBSD context) for a reduced/small test > case: > > // g++12 -std=c++20 -fmodules-ts -xc++-system-header memory > // g++12 -std=c++20 -freport-bug -fmodules-ts -c > gpp12_module_dynamic_pointer_cast_failure.cpp . . . I've now tried this on fedora 36 with copies of the source code and got no failure in the fedora context. This was with: # c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/12/lto-wrapper Target: aarch64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-libstdcxx-backtrace --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-12.2.1-20220819/obj-aarch64-redhat-linux/isl-install --enable-gnu-indirect-function --build=aarch64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.1 20220819 (Red Hat 12.2.1-1) (GCC) # uname -ap Linux usbfedora 5.17.8-300.fc36.aarch64 #1 SMP Mon May 16 00:40:35 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
[Bug c++/103499] C++20 modules error: invalid use of non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103499
--- Comment #2 from Mark Millard ---
(In reply to Mark Millard from comment #1)
> // g++12 -std=c++20 -fmodules-ts -xc++ -c gpp12_module_iostream_failure.cppm
> // g++12 -freport-bug -std=c++20 -fmodules-ts -c
> gpp12_module_iostream_failure.cpp
The iostream based file names were from before I reduced
the test to the smaller test case. The updated comments are:
// g++12 -std=c++20 -fmodules-ts -xc++ -c
gpp12_module_is_nothrow_constructible_v_failure.cppm
// g++12 -std=c++20 -fmodules-ts -xc++ -c
gpp12_module_is_nothrow_constructible_v_failure.cpp
On Fedora 26, where "c++" is g++ 12.2.1, I've tried the same,
with the copies of the source code, and it gets the same error.
The -freport-bug outout is shown below.
# more /tmp/ccRnanx8.out
// Target: aarch64-redhat-linux
// Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzil
la.redhat.com/bugzilla --enable-shared --enable-threads=posix
--enable-checking=release --enable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-ob
ject --enable-linker-build-id --with-gcc-major-version-only
--enable-libstdcxx-backtrace --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-12.2.
1-20220819/obj-aarch64-redhat-linux/isl-install --enable-gnu-indirect-function
--build=aarch64-redhat-linux --with-build-config=bootstrap-lto
--enable-link-serialization=1
// Thread model: posix
// Supported LTO compression algorithms: zlib zstd
// gcc version 12.2.1 20220819 (Red Hat 12.2.1-1) (GCC)
//
// In module /usr/include/c++/12/type_traits, imported at
gpp12_module_is_nothrow_constructible_v_failure.cpp:7:
// /usr/include/c++/12/type_traits: In substitution of ‘template using __is_nothrow_constructible_impl =
std::__bool_constant<__is_nothrow_constructible(_Tp)> [with _Tp = d
erived@derived_interface; _Args = {}]’:
// /usr/include/c++/12/type_traits:1047:12: required from ‘struct
std::is_nothrow_constructible’
// /usr/include/c++/12/type_traits:3243:46: required from ‘constexpr const
bool std::is_nothrow_constructible_v’
// gpp12_module_is_nothrow_constructible_v_failure.cpp:11:11: required from
here
// /usr/include/c++/12/type_traits:1041:11: error: invalid use of non-static
member function ‘virtual constexpr derived@derived_interface::~derived()’
// 1041 | using __is_nothrow_constructible_impl
// | ^~~
// In module derived_interface, imported at
gpp12_module_is_nothrow_constructible_v_failure.cpp:5:
// gpp12_module_is_nothrow_constructible_v_failure.cppm:10:15: note: declared
here
//10 | export struct derived : base
// | ^~~
// /usr/include/c++/12/type_traits:1041: confused by earlier errors, bailing
out
// /usr/libexec/gcc/aarch64-redhat-linux/12/cc1plus -quiet -D_GNU_SOURCE
gpp12_module_is_nothrow_constructible_v_failure.cpp -quiet -dumpbase
gpp12_module_is_nothrow_constructible_v_failure.cpp -dumpb
ase-ext .cpp -mlittle-endian -mabi=lp64 -std=c++20 -freport-bug -fmodules-ts -o
- -frandom-seed=0 -fdump-noaddr
# 0 "gpp12_module_is_nothrow_constructible_v_failure.cpp"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "gpp12_module_is_nothrow_constructible_v_failure.cpp"
import derived_interface;
import "/usr/include/c++/12/type_traits";
void test()
{
if (std::is_nothrow_constructible_v);
}
[Bug c++/106820] New: internal compiler error: in function_and_variable_visibility [for std::dynamic_pointer_cast use via module]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106820
Bug ID: 106820
Summary: internal compiler error: in
function_and_variable_visibility [for
std::dynamic_pointer_cast use via module]
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markmigm at gmail dot com
Target Milestone: ---
Failing command sequence (from a FreeBSD context) for a reduced/small test
case:
// g++12 -std=c++20 -fmodules-ts -xc++-system-header memory
// g++12 -std=c++20 -freport-bug -fmodules-ts -c
gpp12_module_dynamic_pointer_cast_failure.cpp
For:
# more /tmp/ccvYB09K.out
// Target: aarch64-portbld-freebsd14.0
// Configured with: /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/configure
--disable-multilib --disable-bootstrap --disable-nls
--enable-gnu-indirect-function --enable-host-shared --enable-plugin
--libdir=/usr/local/lib/gcc12 --libexecdir=/usr/local/libexec/gcc12
--program-suffix=12 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc12/include/c++/
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-ld=/usr/local/bin/ld
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --without-zstd
--enable-languages=c,c++,objc,fortran,jit --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/share/info/gcc12 --build=aarch64-portbld-freebsd14.0
// Thread model: posix
// Supported LTO compression algorithms: zlib
// gcc version 12.2.0 (FreeBSD Ports Collection)
//
// during IPA pass: visibility
// gpp12_module_dynamic_pointer_cast_failure.cpp:21:1: internal compiler error:
in function_and_variable_visibility, at ipa-visibility.cc:716
//21 | }
// | ^
// Please submit a full bug report, with preprocessed source.
// See <https://gcc.gnu.org/bugs/> for instructions.
// /usr/local/libexec/gcc12/gcc/aarch64-portbld-freebsd14.0/12.2.0/cc1plus
-quiet gpp12_module_dynamic_pointer_cast_failure.cpp -quiet -dumpbase
gpp12_module_dynamic_pointer_cast_failure.cpp -dumpbase-ext .cpp
-mlittle-endian -mabi=lp64 -std=c++20 -freport-bug -fmodules-ts -o -
-frandom-seed=0 -fdump-noaddr
# 0 "gpp12_module_dynamic_pointer_cast_failure.cpp"
# 0 ""
# 0 ""
# 1 "gpp12_module_dynamic_pointer_cast_failure.cpp"
# 11 "gpp12_module_dynamic_pointer_cast_failure.cpp"
import "/usr/local/lib/gcc12/include/c++/memory";
struct data
{
virtual ~data() = default;
};
void test(std::shared_ptr b)
{
auto dpc = std::dynamic_pointer_cast(b);
}
[Bug c++/103499] C++20 modules error: invalid use of non-static member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103499
Mark Millard changed:
What|Removed |Added
CC||markmigm at gmail dot com
--- Comment #1 from Mark Millard ---
I see this in G++ 12.2.0 on FreeBSD. Reduced to a small example below.
Compiled via:
// g++12 -std=c++20 -fmodules-ts -xc++-system-header type_traits
// g++12 -std=c++20 -fmodules-ts -xc++ -c gpp12_module_iostream_failure.cppm
// g++12 -freport-bug -std=c++20 -fmodules-ts -c
gpp12_module_iostream_failure.cpp
# more gpp12_module_is_nothrow_constructible_v_failure.cppm
export module derived_interface;
export struct base
{
virtual ~base() noexcept = default;
};
export struct derived : base
{
};
# more /tmp/ccrTCTqv.out
// Target: aarch64-portbld-freebsd14.0
// Configured with: /wrkdirs/usr/ports/lang/gcc12/work/gcc-12.2.0/configure
--disable-multilib --disable-bootstrap --disable-nls
--enable-gnu-indirect-function --enable-host-shared --enable-plugin
--libdir=/usr/local/lib/gcc12 --libexecdir=/usr/local/libexec/gcc12
--program-suffix=12 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc12/include/c++/
--with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-ld=/usr/local/bin/ld
--with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --without-zstd
--enable-languages=c,c++,objc,fortran,jit --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/share/info/gcc12 --build=aarch64-portbld-freebsd14.0
// Thread model: posix
// Supported LTO compression algorithms: zlib
// gcc version 12.2.0 (FreeBSD Ports Collection)
//
// In module /usr/local/lib/gcc12/include/c++/type_traits, imported at
gpp12_module_is_nothrow_constructible_v_failure.cpp:7:
// /usr/local/lib/gcc12/include/c++/type_traits: In substitution of
'template using __is_nothrow_constructible_impl =
std::__bool_constant<__is_nothrow_constructible(_Tp)> [with _Tp =
derived@derived_interface; _Args = {}]':
// /usr/local/lib/gcc12/include/c++/type_traits:1047:12: required from
'struct std::is_nothrow_constructible'
// /usr/local/lib/gcc12/include/c++/type_traits:3243:46: required from
'constexpr const bool
std::is_nothrow_constructible_v'
// gpp12_module_is_nothrow_constructible_v_failure.cpp:11:11: required from
here
// /usr/local/lib/gcc12/include/c++/type_traits:1041:11: error: invalid use of
non-static member function 'virtual constexpr
derived@derived_interface::~derived()'
// 1041 | using __is_nothrow_constructible_impl
// | ^~~
// In module derived_interface, imported at
gpp12_module_is_nothrow_constructible_v_failure.cpp:5:
// gpp12_module_is_nothrow_constructible_v_failure.cppm:10:15: note: declared
here
//10 | export struct derived : base
// | ^~~
// /usr/local/lib/gcc12/include/c++/type_traits:1041: confused by earlier
errors, bailing out
// /usr/local/libexec/gcc12/gcc/aarch64-portbld-freebsd14.0/12.2.0/cc1plus
-quiet gpp12_module_is_nothrow_constructible_v_failure.cpp -quiet -dumpbase
gpp12_module_is_nothrow_constructible_v_failure.cpp -dumpbase-ext .cpp
-mlittle-endian -mabi=lp64 -std=c++20 -freport-bug -fmodules-ts -o -
-frandom-seed=0 -fdump-noaddr
# 0 "gpp12_module_is_nothrow_constructible_v_failure.cpp"
# 0 ""
# 0 ""
# 1 "gpp12_module_is_nothrow_constructible_v_failure.cpp"
import derived_interface;
import "/usr/local/lib/gcc12/include/c++/type_traits";
void test()
{
if (std::is_nothrow_constructible_v);
}
[Bug bootstrap/81315] powerpc64 vs building lang/gcc7-devel (on FreeBSD head): xgcc gets segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81315
--- Comment #6 from Mark Millard ---
(In reply to Segher Boessenkool from comment #5)
> This was BE, on a compiler that defaults to power4 ("970 without altivec").
> I.e. the default for powerpc64-linux.
Good to know. Thanks.
I've no clue what or how to build a match to the
test environment and test technique that you used.
So unless I get the time to explore, I'll not be
establishing the repeatability of your result for
comparison to what happened under FreeBSD.
[Bug bootstrap/81315] powerpc64 vs building lang/gcc7-devel (on FreeBSD head): xgcc gets segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81315 --- Comment #4 from Mark Millard --- (In reply to Segher Boessenkool from comment #3) > Builds fine on powerpc64-linux, both trunk and 7. Could you give information on how to set up and run this test, including pointing to what distribution to install and the like? (In my context it would be installed on an old PowerMac G5 so-called "quad core", if possible.) Knowing in more detail what type of context was able to check this would be handy. I'm not as familiar with Linux as with FreeBSD. There may be an issue of big-endian powerp64 vs. little-endian: FreeBSD is big-endian for the PowerMac G5 context.
[Bug bootstrap/81315] powerpc64 vs building lang/gcc7-devel (on FreeBSD head): xgcc gets segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81315 --- Comment #2 from Mark Millard --- (In reply to Martin Liška from comment #1) > Any chance to reproduce with a cross compiler on Linux? I assume that amd64 as a host is implicit in this request. It is less clear if the target is intended as a powerpc64 linux vs. powerpc64 freebsd. I do not have a linux environment set up for amd64 in order to install a such cross compiler (either case) and then to have that in turn process class_type_info.ii (from the attachment). I'm less familiar with Linux. It would take a while for me to set up such. It may be better for someone that runs an amd64 linux normally to install whatever cross compiler is intended. (Or build and install if required.) If I'm to do this it would be better for me to have explicit instructions about what cross compiler to install (in, say, ubuntu) -- or steps to build and install what is desired if no re-built installer is around. Either way instructions about how to run the test may be appropriate as well if there is anything special about how to best run it.
[Bug bootstrap/81315] New: powerpc64 vs building lang/gcc7-devel (on FreeBSD head): xgcc gets segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81315 Bug ID: 81315 Summary: powerpc64 vs building lang/gcc7-devel (on FreeBSD head): xgcc gets segmentation fault Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: markmigm at gmail dot com Target Milestone: --- Created attachment 41678 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41678=edit class_type_info.ii file from a -save-temps run I was trying to build lang/gcc7-devel on FreeBSD head -r320570 on a powerpc64. The xgcc stage got the following segmentation fault. (By contrast 32-bit powerpc's build of it under head -r320570 completed without having this problem: somehow powerpc64 specific.) /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++-v3/libsupc++/class_type_info.cc: In member function 'virtual bool __cxxabiv1::__class_type_info::__do_upcast(const __cxxabiv1::__class_type_info*, void**) const': /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++-v3/libsupc++/class_type_info.cc:45:6: internal compiler error: Segmentation fault bool __class_type_info:: ^ The rest of the -save-temps output was: xgcc: warning: -pipe ignored because -save-temps specified Reading specs from /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/specs COLLECT_GCC=/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/xgcc Target: powerpc64-portbld-freebsd12.0 Configured with: /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/configure --enable-multilib --with-build-config=bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc7 --libexecdir=/usr/local/libexec/gcc7 --program-suffix=7 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc7/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --enable-languages=c,c++,objc,fortran --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/gcc7 --build=powerpc64-portbld-freebsd12.0 Thread model: posix gcc version 7.1.1 20170629 (FreeBSD Ports Collection) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-B' '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc' '-nostdinc++' '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld-freebsd12.0/libstdc++-v3/src' '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld-freebsd12.0/libstdc++-v3/src/.libs' '-L/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld-freebsd12.0/libstdc++-v3/libsupc++/.libs' '-B' '/usr/local/powerpc64-portbld-freebsd12.0/bin/' '-B' '/usr/local/powerpc64-portbld-freebsd12.0/lib/' '-isystem' '/usr/local/powerpc64-portbld-freebsd12.0/include' '-isystem' '/usr/local/powerpc64-portbld-freebsd12.0/sys-include' '-I' '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++-v3/../libgcc' '-I' '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld-freebsd12.0/libstdc++-v3/include/powerpc64-portbld-freebsd12.0' '-I' '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld-freebsd12.0/libstdc++-v3/include' '-I' '/usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++-v3/libsupc++' '-D' '_GLIBCXX_SHARED' '-fno-implicit-templates' '-Wall' '-Wextra' '-Wwrite-strings' '-Wcast-qual' '-Wabi' '-fdiagnostics-show-location=once' '-ffunction-sections' '-fdata-sections' '-frandom-seed=class_type_info.lo' '-O2' '-pipe' '-B' '/usr/local/bin/' '-D' 'LIBICONV_PLUG' '-g' '-fno-strict-aliasing' '-B' '/usr/local/bin/' '-D' 'LIBICONV_PLUG' '-c' '-fPIC' '-D' 'PIC' '-D' '_GLIBCXX_SHARED' '-o' 'class_type_info.o' /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/cc1plus -E -quiet -nostdinc++ -v -I /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++-v3/../libgcc -I /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld-freebsd12.0/libstdc++-v3/include/powerpc64-portbld-freebsd12.0 -I /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/powerpc64-portbld-freebsd12.0/libstdc++-v3/include -I /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/gcc-7-20170629/libstdc++-v3/libsupc++ -iprefix /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/gcc/../lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.1.1/ -isystem /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/include -isystem /usr/obj/portswork/usr/ports/lang/gcc7-devel/work/.build/./gcc/include-fixed -D _GLIBCXX_SHARED -D LIBICONV_PLUG -D LIBICONV_PLUG -D PIC -D _GLIBCXX_SHARED -isystem /usr/local/powerpc64-portbld-freebsd12.0/include -isystem /usr/local/powerpc64-portbld-freebsd12.0/sys-include /usr/obj/portswork/usr/ports/l
