[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906 --- Comment #10 from CVS Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:d4912dc76662ab434c897ab454e3285fbb6ca6df commit r10-6936-gd4912dc76662ab434c897ab454e3285fbb6ca6df Author: John David Anglin Date: Sat Feb 29 16:13:23 2020 + Fix baseline symbols on hppa-linux-gnu 2020-02-29 John David Anglin PR libstdc++/92906 * config/abi/post/hppa-linux-gnu/baseline_symbols.txt: Update.
[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|NEW |RESOLVED CC||danglin at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Yes, I think John needs to revert his r10-5705-ga8497ec6102474365d4a7e92ccd5f392d8e96161 commit but otherwise we should be all set.
[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #8 from Jeffrey A. Law --- Jakub, I think your fix resolved this BZ. Correct? If so can you go ahead and close this out?
[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:994e0ad41529f5518fd013474a657968807d9ca5 commit r10-6630-g994e0ad41529f5518fd013474a657968807d9ca5 Author: Jakub Jelinek Date: Fri Feb 14 00:11:24 2020 +0100 c++: Emit DFP typeinfos even when DFP is disabled [PR92906] Before Joseph's changes when compiling libstdc++-v3/libsupc++/fundamental_type_info.cc we were emitting _ZTIPDd, _ZTIPDe, _ZTIPDf, _ZTIPKDd, _ZTIPKDe, _ZTIPKDf, _ZTIDd, _ZTIDe, _ZTIDf symbols even when DFP wasn't usable, but now we don't and thus those 9 symbols @@CXXABI_1.3.4 are gone from libstdc++. While nothing could probably use it (except perhaps dlsym etc.), various tools don't really like symbols disappearing from symbol versioned shared libraries with stable ABI. Adding those in assembly would be possible, but would be a portability nightmare (the PR has something Red Hat uses in libstdc++_nonshared.a, but that can handle only a handful of linux ELF targets we care about). So, instead this patch hacks up the FE, so that it emits those, but in a way that won't make the DFP types available again on targets that don't support them. 2020-02-14 Jakub Jelinek PR libstdc++/92906 * cp-tree.h (enum cp_tree_index): Add CPTI_FALLBACK_DFLOAT32_TYPE, CPTI_FALLBACK_DFLOAT64_TYPE and CPTI_FALLBACK_DFLOAT128_TYPE. (fallback_dfloat32_type, fallback_dfloat64_type, fallback_dfloat128_type): Define. * mangle.c (write_builtin_type): Handle fallback_dfloat*_type like dfloat*_type_node. * rtti.c (emit_support_tinfos): Emit DFP typeinfos even when dfp is disabled for compatibility.
[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906
--- Comment #6 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > Yet another possibility is to create these in libsupc++ in assembly, but
> > that would need to be macroized.
>
> I was assuming we'd do that. It would be ugly, but no worse than some of the
> other compat hacks we aready have.
That is something we already have in the Red Hat Developer Toolset
libstdc++_nonshared.a, like below.
Just note that this isn't ifdefed completely out if DFP is enabled (could use
e.g. configure test
or something for that, compile:
namespace __cxxabiv1
{
class __class_type_info;
}
namespace std
{
struct type_info
{
virtual ~type_info();
virtual bool __is_pointer_p() const;
virtual bool __is_function_p() const;
virtual bool __do_catch(const type_info *__thr_type, void **__thr_obj,
unsigned __outer) const;
virtual bool __do_upcast(const __cxxabiv1::__class_type_info *__target,
void **__obj_ptr) const;
const char *__name;
explicit type_info(const char *__n): __name(__n) { }
type_info& operator=(const type_info&);
type_info(const type_info&);
};
}
namespace __cxxabiv1
{
struct __fundamental_type_info : public std::type_info
{
explicit
__fundamental_type_info(const char* __n) : std::type_info(__n) { }
virtual
~__fundamental_type_info();
};
__fundamental_type_info::~__fundamental_type_info () {}
}
and check for those DFP symbols in there) and supports only the architectures
RHEL cares about (plus ia64),
the abi-tag note also would need to be specific.
Or perhaps instead a script that would parse assembly emitted for the above
source code and adjust it
to contain the DFP symbols instead of all the others.
Though, the FE hack seems to be easiest to me.
/* Copyright (C) 2012-2017 Free Software Foundation, Inc.
This file is part of the GNU ISO C++ Library. This library is free
software; you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the
Free Software Foundation; either version 3, or (at your option)
any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Under Section 7 of GPL version 3, you are granted additional
permissions described in the GCC Runtime Library Exception, version
3.1, as published by the Free Software Foundation.
You should have received a copy of the GNU General Public License and
a copy of the GCC Runtime Library Exception along with this program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906
--- Comment #5 from Jakub Jelinek ---
The safer variant:
--- gcc/cp/cp-tree.h.jj 2020-01-20 10:04:52.335091019 +0100
+++ gcc/cp/cp-tree.h2020-01-20 17:09:15.350260384 +0100
@@ -206,6 +206,10 @@ enum cp_tree_index
CPTI_SOURCE_LOCATION_IMPL,
+CPTI_FALLBACK_DFLOAT32_TYPE,
+CPTI_FALLBACK_DFLOAT64_TYPE,
+CPTI_FALLBACK_DFLOAT128_TYPE,
+
CPTI_MAX
};
@@ -366,6 +370,12 @@ extern GTY(()) tree cp_global_trees[CPTI
#define access_default_nodenull_node
+/* Variant of dfloat{32,64,128}_type_node only used for fundamental
+ rtti purposes if DFP is disabled. */
+#define fallback_dfloat32_type
cp_global_trees[CPTI_FALLBACK_DFLOAT32_TYPE]
+#define fallback_dfloat64_type
cp_global_trees[CPTI_FALLBACK_DFLOAT64_TYPE]
+#define fallback_dfloat128_type
cp_global_trees[CPTI_FALLBACK_DFLOAT128_TYPE]
+
#include "name-lookup.h"
--- gcc/cp/mangle.c.jj 2020-01-12 11:54:36.487412292 +0100
+++ gcc/cp/mangle.c 2020-01-20 17:10:44.424920025 +0100
@@ -2569,11 +2569,11 @@ write_builtin_type (tree type)
write_char ('d');
else if (type == long_double_type_node)
write_char ('e');
- else if (type == dfloat32_type_node)
+ else if (type == dfloat32_type_node || type == fallback_dfloat32_type)
write_string ("Df");
- else if (type == dfloat64_type_node)
+ else if (type == dfloat64_type_node || type == fallback_dfloat64_type)
write_string ("Dd");
- else if (type == dfloat128_type_node)
+ else if (type == dfloat128_type_node || type == fallback_dfloat128_type)
write_string ("De");
else
gcc_unreachable ();
--- gcc/cp/rtti.c.jj2020-01-15 00:26:26.605526740 +0100
+++ gcc/cp/rtti.c 2020-01-20 17:10:06.683487951 +0100
@@ -1588,6 +1588,20 @@ emit_support_tinfos (void)
}
for (tree t = registered_builtin_types; t; t = TREE_CHAIN (t))
emit_support_tinfo_1 (TREE_VALUE (t));
+ /* For compatibility, emit DFP typeinfos even DFP isn't enabled,
+ because we've emitted that in the past. */
+ if (!targetm.decimal_float_supported_p ())
+{
+ gcc_assert (dfloat32_type_node == NULL_TREE
+ && dfloat64_type_node == NULL_TREE
+ && dfloat128_type_node == NULL_TREE);
+ fallback_dfloat32_type = make_node (REAL_TYPE);
+ fallback_dfloat64_type = make_node (REAL_TYPE);
+ fallback_dfloat128_type = make_node (REAL_TYPE);
+ emit_support_tinfo_1 (fallback_dfloat32_type);
+ emit_support_tinfo_1 (fallback_dfloat64_type);
+ emit_support_tinfo_1 (fallback_dfloat128_type);
+}
input_location = saved_loc;
}
[
[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906 --- Comment #4 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #3) > Yet another possibility is to create these in libsupc++ in assembly, but > that would need to be macroized. I was assuming we'd do that. It would be ugly, but no worse than some of the other compat hacks we aready have.
[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||redi at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
One way to handle this would be a hack like:
--- gcc/cp/rtti.c.jj2020-01-15 00:26:26.605526740 +0100
+++ gcc/cp/rtti.c 2020-01-20 16:56:50.600482313 +0100
@@ -1578,6 +1578,18 @@ emit_support_tinfos (void)
location_t saved_loc = input_location;
input_location = BUILTINS_LOCATION;
doing_runtime = 1;
+
+ /* For compatibility, emit DFP typeinfos even DFP isn't enabled,
+ because we've emitted that in the past. */
+ if (!targetm.decimal_float_supported_p ())
+{
+ gcc_assert (dfloat32_type_node == NULL_TREE
+ && dfloat64_type_node == NULL_TREE
+ && dfloat128_type_node == NULL_TREE);
+ dfloat32_type_node = make_node (REAL_TYPE);
+ dfloat64_type_node = make_node (REAL_TYPE);
+ dfloat128_type_node = make_node (REAL_TYPE);
+}
for (ix = 0; fundamentals[ix]; ix++)
emit_support_tinfo_1 (*fundamentals[ix]);
for (ix = 0; ix < NUM_INT_N_ENTS; ix ++)
unfortunately it doesn't work to clear dfloat*_type_node right after
emit_support_tinfo_1 call, because the mangling is done much later. I'd hope
that if the types aren't registered as builtin types and aren't complete it
might not cause that much harm. Or we could instead not touch
dfloat*_type_node at all, but have some GTY array of 3 trees (or put it into
C++ trees array) and emit_support_tinfo_1 for those instead and hack up
mangle.c to also check against those.
Yet another possibility is to create these in libsupc++ in assembly, but that
would need to be macroized.
Jason/Jonathan, thoughts on this?
[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I think it would be better if the FE just emitted those rtti infos even if DFP isn't otherwise supported for backwards compatibility.
[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-08 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- There was some mailing list discussion: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02510.html https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02510.html But no conclusion.
[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
