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.
jcmvbkbc
pushed a commit
that referenced
this issue
Nov 10, 2024
We can make use of the integrated rotate step of the XAR instruction
to implement most vector integer rotates, as long we zero out one
of the input registers for it. This allows for a lower-latency sequence
than the fallback SHL+USRA, especially when we can hoist the zeroing operation
away from loops and hot parts. This should be safe to do for 64-bit vectors
as well even though the XAR instructions operate on 128-bit values, as the
bottom 64-bit results is later accessed through the right subregs.
This strategy is used whenever we have XAR instructions, the logic
in aarch64_emit_opt_vec_rotate is adjusted to resort to
expand_rotate_as_vec_perm only when it's expected to generate a single REV*
instruction or when XAR instructions are not present.
With this patch we can gerate for the input:
v4si
G1 (v4si r)
{
return (r >> 23) | (r << 9);
}
v8qi
G2 (v8qi r)
{
return (r << 3) | (r >> 5);
}
the assembly for +sve2:
G1:
movi v31.4s, 0
xar z0.s, z0.s, z31.s, #23
ret
G2:
movi v31.4s, 0
xar z0.b, z0.b, z31.b, #5
ret
instead of the current:
G1:
shl v31.4s, v0.4s, 9
usra v31.4s, v0.4s, 23
mov v0.16b, v31.16b
ret
G2:
shl v31.8b, v0.8b, 3
usra v31.8b, v0.8b, 5
mov v0.8b, v31.8b
ret
Bootstrapped and tested on aarch64-none-linux-gnu.
Signed-off-by: Kyrylo Tkachov <ktkachov@nvidia.com>
gcc/
* config/aarch64/aarch64.cc (aarch64_emit_opt_vec_rotate): Add
generation of XAR sequences when possible.
gcc/testsuite/
* gcc.target/aarch64/rotate_xar_1.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: