error: 'uint_least32_t' is already declared in this scope #5
Comments
I haven't found an ultimate answer to what happens here, seems to be bad interaction of newlib and libstdc++. I used this workaround: |
|
I had the same problem with branch call0-4.9.2. This patch patch works seamlessly. |
|
A build under MinGW on Windows7 was also failing. This patch worked here as well. |
jcmvbkbc
pushed a commit
that referenced
this issue
May 30, 2017
* cp-tree.h (lookup_maybe_add): Add DEDUPING argument. * name-lookup.c (name_lookup): Add deduping field. (name_lookup::preserve_state, name_lookup::restore_state): Deal with deduping. (name_lookup::add_overload): New. (name_lookup::add_value, name_lookup::add_fns): Call add_overload. (name_lookup::search_adl): Set deduping. Don't unmark here. * pt.c (most_specialized_instantiation): Revert previous change, Assert not given duplicates. * tree.c (lookup_mark): Just mark the underlying decls. (lookup_maybe_add): Dedup using marked decls. PR c++/80891 (#5) * g++.dg/lookup/pr80891-5.C: New. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248578 138bc75d-0d04-0410-961f-82ee72b054a4
jcmvbkbc
pushed a commit
that referenced
this issue
Jun 18, 2018
When -fcf-protection -mcet is used, I got
FAIL: g++.dg/eh/sighandle.C
(gdb) bt
#0 _Unwind_RaiseException (exc=exc@entry=0x416ed0)
at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:140
#1 0x00007ffff7d9936b in __cxxabiv1::__cxa_throw (obj=<optimized out>,
tinfo=0x403dd0 <typeinfo for int@@CXXABI_1.3>, dest=0x0)
at /export/gnu/import/git/sources/gcc/libstdc++-v3/libsupc++/eh_throw.cc:90
#2 0x0000000000401255 in sighandler (signo=11, si=0x7fffffffd6f8,
uc=0x7fffffffd5c0)
at /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:9
#3 <signal handler called> <<<< Signal frame which isn't on shadow stack
#4 dosegv ()
at /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:14
#5 0x00000000004012e3 in main ()
at /export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/eh/sighandle.C:30
(gdb) p frames
$6 = 5
(gdb)
frame count should be 4, not 5. This patch skips signal frames when
unwinding shadow stack.
gcc/testsuite/
PR libgcc/85334
* g++.dg/torture/pr85334.C: New test.
libgcc/
PR libgcc/85334
* unwind-generic.h (_Unwind_Frames_Increment): New.
* config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment):
Likewise.
* unwind.inc (_Unwind_RaiseException_Phase2): Increment frame
count with _Unwind_Frames_Increment.
(_Unwind_ForcedUnwind_Phase2): Likewise.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@259502 138bc75d-0d04-0410-961f-82ee72b054a4
jcmvbkbc
pushed a commit
that referenced
this issue
May 8, 2023
I noticed that for member class templates of a class template we were
unnecessarily substituting both the template and its type. Avoiding that
duplication speeds compilation of this silly testcase from ~12s to ~9s on my
laptop. It's unlikely to make a difference on any real code, but the
simplification is also nice.
We still need to clear CLASSTYPE_USE_TEMPLATE on the partial instantiation
of the template class, but it makes more sense to do that in
tsubst_template_decl anyway.
#define NC(X) \
template <class U> struct X##1; \
template <class U> struct X##2; \
template <class U> struct X##3; \
template <class U> struct X##4; \
template <class U> struct X##5; \
template <class U> struct X##6;
#define NC2(X) NC(X##a) NC(X##b) NC(X##c) NC(X##d) NC(X##e) NC(X##f)
#define NC3(X) NC2(X##A) NC2(X##B) NC2(X##C) NC2(X##D) NC2(X##E)
template <int I> struct A
{
NC3(am)
};
template <class...Ts> void sink(Ts...);
template <int...Is> void g()
{
sink(A<Is>()...);
}
template <int I> void f()
{
g<__integer_pack(I)...>();
}
int main()
{
f<1000>();
}
gcc/cp/ChangeLog:
* pt.cc (instantiate_class_template): Skip the RECORD_TYPE
of a class template.
(tsubst_template_decl): Clear CLASSTYPE_USE_TEMPLATE.
jcmvbkbc
pushed a commit
that referenced
this issue
Mar 22, 2024
Consider
constexpr int VAL = 1;
struct foo {
template <int B>
void bar(typename std::conditional<B==VAL, int, float>::type arg) { }
};
template void foo::bar<1>(int arg);
where we since r11-291 fail to emit the code for the explicit
instantiation. That's because cp_walk_subtrees/TYPENAME_TYPE now
walks TYPE_CONTEXT ('conditional' here) as well, and in a template
finds the B==VAL template argument. VAL is constexpr, which implies const,
which in the global scope implies static. constrain_visibility_for_template
then makes "struct conditional<(B == VAL), int, float>" non-TREE_PUBLIC.
Then symtab_node::needed_p checks TREE_PUBLIC, sees it's 0, and we don't
emit any code.
I thought the fix would be some ODR-esque check to not consider
constexpr variables/fns that are used just for their value. But
it turned out to be tricky. For instance, we can't skip
determine_visibility in a template; we can't even skip it for value-dep
expressions. For example, no-linkage-expr1.C has
using P = struct {}*;
template <int N>
void f(int(*)[((P)0, N)]) {}
where ((P)0, N) is value-dep, but N is not relevant here: we have to
ferret out the anonymous type. When instantiating, it's already gone.
This patch uses decl_constant_var_p. This is to implement (an
approximation) [basic.def.odr]#14.5.1 and [basic.def.odr]#5.2.
PR c++/110323
gcc/cp/ChangeLog:
* decl2.cc (min_vis_expr_r) <case VAR_DECL>: Do nothing for
decl_constant_var_p VAR_DECLs.
gcc/testsuite/ChangeLog:
* g++.dg/template/explicit-instantiation6.C: New test.
* g++.dg/template/explicit-instantiation7.C: New test.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While compiling I've this error:
It's generated by this call:
/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/./gcc/xgcc -shared-libgcc -B/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/./gcc -nostdinc++ -L/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/src -L/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/src/.libs -L/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/libsupc++/.libs -B/home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/bin/ -B/home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/lib/ -isystem /home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/include -isystem /home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/sys-include -x c++-header -nostdinc++ -g -O2 -I/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include/xtensa-lx106-elf -I/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include -I/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/libstdc++-v3/include/precompiled/stdc++.h -o xtensa-lx106-elf/bits/stdc++.h.gch/O2ggnu++0x.gch
But I saw the same this call which works (only difference: no gnu++0x):
/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/./gcc/xgcc -shared-libgcc -B/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/./gcc -nostdinc++ -L/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/src -L/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/src/.libs -L/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/libsupc++/.libs -B/home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/bin/ -B/home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/lib/ -isystem /home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/include -isystem /home/toms/esp8266/esp8266-devkit/Espressif/xtensa-lx106-elf/xtensa-lx106-elf/sys-include -x c++-header -nostdinc++ -g -O2 -I/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include/xtensa-lx106-elf -I/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/build-2/xtensa-lx106-elf/libstdc++-v3/include -I/home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/libstdc++-v3/libsupc++ -O2 -g /home/toms/esp8266/esp8266-devkit/Espressif/dl/gcc-xtensa/libstdc++-v3/include/precompiled/stdc++.h -o xtensa-lx106-elf/bits/stdc++.h.gch/O2g.gch
Any idea ?
The text was updated successfully, but these errors were encountered: