[Bug bootstrap/37061] New: Build fails with REGISTER_TARGET_PRAGMAS redefined
I'm compiling gcc snapshot 20080801 on a Solaris 2.10 (amd64) machine with host
tools from binutils 2.18 and gcc 4.3.
I've configured with:
../gcc-4.4-20080801/configure --disable-static --enable-shared
--prefix=/home/huron/jeffga/sfw/gcc-4.4
--with-gmp=/home/huron/jeffga/sfw/gcc-4.4
--with-mpfr=/home/huron/jeffga/sfw/gcc-4.4 --with-gnu-as --with-gnu-ld
But make fails with:
[... snipped ..]
/home/huron/jeffga/src/obj/./prev-gcc/xgcc
-B/home/huron/jeffga/src/obj/./prev-gcc/
-B/home/huron/jeffga/sfw/gcc-4.4/i386-pc-solaris2.10/bin/ -c -g -O2 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.4-20080801/gcc
-I../../gcc-4.4-20080801/gcc/build -I../../gcc-4.4-20080801/gcc/../include
-I./../intl -I../../gcc-4.4-20080801/gcc/../libcpp/include
-I/home/huron/jeffga/sfw/gcc-4.4/include
-I/home/huron/jeffga/sfw/gcc-4.4/include
-I../../gcc-4.4-20080801/gcc/../libdecnumber
-I../../gcc-4.4-20080801/gcc/../libdecnumber/dpd -I../libdecnumber -o
build/genconstants.o ../../gcc-4.4-20080801/gcc/genconstants.c
In file included from ./tm.h:19,
from ../../gcc-4.4-20080801/gcc/genconstants.c:31:
../../gcc-4.4-20080801/gcc/config/sol2.h:237:1: error:
"REGISTER_TARGET_PRAGMAS" redefined
In file included from ./tm.h:12,
from ../../gcc-4.4-20080801/gcc/genconstants.c:31:
../../gcc-4.4-20080801/gcc/config/i386/i386.h:542:1: error: this is the
location of the previous definition
make[3]: *** [build/genconstants.o] Error 1
make[3]: Leaving directory `/home/huron/jeffga/src/obj/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/huron/jeffga/src/obj'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/huron/jeffga/src/obj'
make: *** [all] Error 2
The same REGISTER_TARGET_PRAGMAS redefined warning also showed up repeatedly in
the earlier compilation but as that all happened without -Werror, it continued.
Line 237 of gcc/config/sol2.h in the source does have:
#define REGISTER_TARGET_PRAGMAS() solaris_register_pragmas ()
Line 542 of gcc/config/i386/i386.h has:
#define REGISTER_TARGET_PRAGMAS() ix86_register_pragmas ()
The same configure command, with the same tools, will build gcc 4.3.1 without
issue.
--
Summary: Build fails with REGISTER_TARGET_PRAGMAS redefined
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jeff at jgarrett dot org
GCC host triplet: i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37061
[Bug debug/87308] New: pretty printer for std::any fails with: Python Exception Unknown manager function in std::any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308
Bug ID: 87308
Summary: pretty printer for std::any fails with: Python
Exception Unknown
manager function in std::any
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff at jgarrett dot org
Target Milestone: ---
Using g++-8.1 and gdb-8.2 both built from source on a CentOS 7.3 host, pretty
printing a std::any fails with an exception for unknown manager function.
$ gdb ./erased-lambda
GNU gdb (GDB) 8.2
(gdb) run
Starting program: .../erased-lambda
Program received signal SIGILL, Illegal instruction.
main () at erased-lambda.cpp:6
6 __builtin_trap();
(gdb) print a1
$1 = Python Exception Unknown manager
function in std::any:
Python Exception Unknown manager function in
std::any:
{
_M_manager = 0x4007b2
>::_S_manage(std::any::_Op, const std::any *, std::any::_Arg *)>, _M_storage =
{_M_ptr = 0x1, _M_buffer = {__data = "\001\000\000\000\000\000\000",
__align = {
It would appear that the printer attempts to match the manager function name
with the following regex:
rx = r"""({0}::_Manager_\w+<.*>)::_S_manage\({0}::_Op, {0} const\*,
{0}::_Arg\*\)""".format(typename)
Note that the second argument as printed by my gdb is 'const std::any *' versus
the regex 'std::any const*' (east vs west const and space before *) and the
third argument as printed by gdb is 'std::any::_Arg *' versus the regex
'std::any::_Arg*' (space before *). Applying the following patch "fixed" the
regex for my particular set of versions:
--- a/printers.py
+++ b/printers.py
@@ -1040,7 +1040,7 @@ class StdExpAnyPrinter(SingleObjContainerPrinter):
func =
gdb.block_for_pc(int(mgr.cast(gdb.lookup_type('intptr_t'
if not func:
raise ValueError("Invalid function pointer in %s" %
self.typename)
-rx = r"""({0}::_Manager_\w+<.*>)::_S_manage\({0}::_Op, {0}
const\*, {0}::_Arg\*\)""".format(typename)
+rx = r"""({0}::_Manager_\w+<.*>)::_S_manage\({0}::_Op, const
{0} \*, {0}::_Arg \*\)""".format(typename)
m = re.match(rx, func.function.name)
if not m:
raise ValueError("Unknown manager function in %s" %
self.typename)
However, even with that applied, pretty printing a lambda prints the wrong type
due to a bad type lookup:
(gdb) print a1
$1 = std::any containing = {[contained value] = {__j = 1, __k =
0}}
(gdb) print a2
$2 = std::any containing = {[contained value] = {__j = 2, __k =
3}}
Note that both a1 and a2 are interpreted as holding type main::{lambda()#2},
but a1 actually holds main::{lambda()#1}.
GCC version:
$ g++-8.1 -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-8.1.0/bin/g++-8.1
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.1.0/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-8.1.0/configure --program-suffix=-8.1
--prefix=/usr/local/gcc-8.1.0 --disable-multilib --enable-gold --enable-ld
--enable-lto
Thread model: posix
gcc version 8.1.0 (GCC)
Please let me know if I can provide anything else to help.
== erased-lambda.cpp ==
// g++-8.1 -g -std=c++17 erased-lambda.cpp -o erased-lambda
#include
int main() {
std::any a1 = [i=1] {};
std::any a2 = [j=2,k=3] {};
__builtin_trap();
}
[Bug libstdc++/87308] pretty printer for std::any fails with: Python Exception Unknown manager function in std::any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308
--- Comment #3 from Jeff Garrett ---
That's such a good point about the local types in general.
Considering that the gdb python API seems to prefer readable names, e.g. for
lookup, and those are not standard nor unique, might it be perhaps preferable
to avoid going through the regex to get the manager type, and from that the
contained type? Something like this?
mgr = self.val['_M_manager']
if mgr != 0:
# cast to uintptr_t doesn't seem to be necessary
func = gdb.block_for_pc(long(mgr))
if not func:
raise ValueError("Invalid function pointer in %s" %
self.typename)
self.contained_type = gdb.lookup_symbol('_Tp', func)[0].type
valptr = None
mgrfuncname = func.function.name
if
mgrfuncname.startswith('{0}::_Manager_internal'.format(self.typename)):
valptr = self.val['_M_storage']['_M_buffer'].address
elif
mgrfuncname.startswith('{0}::_Manager_external'.format(self.typename)):
valptr = self.val['_M_storage']['_M_ptr']
else:
raise ValueError("Unknown manager function in %s" %
self.typename)
contained_value =
valptr.cast(self.contained_type.pointer()).dereference()
We can lookup the symbol for the formal template parameter of the manager by
its name ('_Tp') in the context of the block for the _S_manage function. I'm
not an expert in any of this, so there may be a reason this is not preferable.
It does seem to work with some fundamental types and std::string as well (with
no magic to handle the typedef).
It still fails in the multiple local lambdas case... But that seems like an
easier to solve problem, because I believe the DWARF debugging has enough
information to know which lambda is _Tp in each of the instantiations, and gdb
is just getting confused. I think it should work in principle.
[Bug c++/105774] New: Bogus overflow in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105774
Bug ID: 105774
Summary: Bogus overflow in constant expression
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jeff at jgarrett dot org
Target Milestone: ---
The following is diagnosed as ill-formed by GCC but not by Clang:
int main() {
constexpr auto _ = [] {
char x = 127;
return ++x;
}();
}
:5:5: error: overflow in constant expression [-fpermissive]
On godbolt https://godbolt.org/z/91oeGsEbh
Originally from
https://stackoverflow.com/questions/72425404/still-unsure-about-signed-integer-overflow-in-c
I believe that this is well-formed. [expr.pre.incr]/1 says x++ is equivalent to
x+=1. [expr.ass]/6 says that x+=1 is equivalent to x=x+1 except that x is only
evaluated once. That expression x=x+1 avoids overflow through integer
promotion.
The same code with x+=1 instead of ++x is allowed by GCC.
