Re: bug in gcc/cp/coroutines.cc line 4688
In my view it is a bug. It gives an error that it can't find
std::throw, but that is gcc's problem, not the problem according to
the standard. According to the standard, the problem is that ::operator
new(size_t, nothrow_t) has not been declared. In fact, the relevant
paragraph of the standard never mentions std::nothrow . It only
mentions std::nothrow_t. Not the same thing.
In other words, this is an error message for developers, not for
users...i.e. a bug.
On 1/18/2025 3:18 PM, Andrew Pinski wrote:
On Sat, Jan 18, 2025 at 2:12 PM Lee Brown via Gcc wrote:
Just to be clear, the appended 17 lines of very simple code breaks gcc
on every platform where header does not have in its
include hierarchywhich I assume to be every platform.
See the discussion in the bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 . That is there is
no bug in libstdc++ nor in GCC in theory. Any use of
get_return_object_on_allocation_failure for the promise_type requires
new to be included. Now there should be a note about a missing include
of new but that is just a small diagnostic issue.
Thanks,
Andrew Pinski
1) place code below in main.cpp
2) g++ -std=c++20 main.cpp
and you get
main.cxx: In function 'my_co do_co()':
main.cxx:16:7: error:
'my_co::promise_type::get_return_object_on_allocation_failure()' is
provided by 'std::__n4861::__coroutine_traits_impl::promise_type' {aka 'my_co::promise_type'} but *'std::nothrow'
cannot be found*
16 | my_co do_co() { co_return; }
| ^
Here's the code:
// begin code
#include
struct my_co {
struct promise_type {
staticmy_co get_return_object_on_allocation_failure() {
return my_co(); }
my_co get_return_object() { return my_co(); }
std::suspend_always initial_suspend() noexcept { return {}; }
std::suspend_always final_suspend() noexcept { return {}; }
void return_void() {}
void unhandled_exception() {}
};
};
my_co do_co() { co_return; }
int main()
{
do_co();
return 0;
}
// end code
Re: bug in gcc/cp/coroutines.cc line 4688
Just to be clear, the appended 17 lines of very simple code breaks gcc
on every platform where header does not have in its
include hierarchywhich I assume to be every platform.
1) place code below in main.cpp
2) g++ -std=c++20 main.cpp
and you get
main.cxx: In function 'my_co do_co()':
main.cxx:16:7: error:
'my_co::promise_type::get_return_object_on_allocation_failure()' is
provided by 'std::__n4861::__coroutine_traits_impl::promise_type' {aka 'my_co::promise_type'} but *'std::nothrow'
cannot be found*
16 | my_co do_co() { co_return; }
| ^
Here's the code:
// begin code
#include
struct my_co {
struct promise_type {
static my_co get_return_object_on_allocation_failure() {
return my_co(); }
my_co get_return_object() { return my_co(); }
std::suspend_always initial_suspend() noexcept { return {}; }
std::suspend_always final_suspend() noexcept { return {}; }
void return_void() {}
void unhandled_exception() {}
};
};
my_co do_co() { co_return; }
int main()
{
do_co();
return 0;
}
// end code
Re: bug in gcc/cp/coroutines.cc line 4688
On Sat, Jan 18, 2025 at 2:12 PM Lee Brown via Gcc wrote:
>
> Just to be clear, the appended 17 lines of very simple code breaks gcc
> on every platform where header does not have in its
> include hierarchywhich I assume to be every platform.
See the discussion in the bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95505 . That is there is
no bug in libstdc++ nor in GCC in theory. Any use of
get_return_object_on_allocation_failure for the promise_type requires
new to be included. Now there should be a note about a missing include
of new but that is just a small diagnostic issue.
Thanks,
Andrew Pinski
>
> 1) place code below in main.cpp
>
> 2) g++ -std=c++20 main.cpp
>
> and you get
>
> main.cxx: In function 'my_co do_co()':
> main.cxx:16:7: error:
> 'my_co::promise_type::get_return_object_on_allocation_failure()' is
> provided by 'std::__n4861::__coroutine_traits_impl void>::promise_type' {aka 'my_co::promise_type'} but *'std::nothrow'
> cannot be found*
> 16 | my_co do_co() { co_return; }
>| ^
>
>
> Here's the code:
>
> // begin code
>
> #include
>
> struct my_co {
> struct promise_type {
> staticmy_co get_return_object_on_allocation_failure() {
> return my_co(); }
> my_co get_return_object() { return my_co(); }
>
> std::suspend_always initial_suspend() noexcept { return {}; }
> std::suspend_always final_suspend() noexcept { return {}; }
> void return_void() {}
> void unhandled_exception() {}
> };
> };
>
> my_co do_co() { co_return; }
>
> int main()
> {
> do_co();
> return 0;
> }
>
> // end code
>
Re: Question about optimizing dynamic_cast call in C++ at GIMPLE Level
Hi Florian, Thank you very much for your reply. This is not related to ELF. What I am trying to do is simply obtain the 'Derived' type node from the parameter that is retrieved via the '__dynamic_cast' call. I believe this should be a relatively simple coding problem. However, I am not very familiar with GCC source code at present, and that is the reason why I am asking for help here. Thanks, Hanke Zhang Florian Weimer 于2025年1月18日周六 20:50写道： > > * Hanke Zhang via Gcc: > > > I have recently been delving into optimizing dynamic_cast calls in C++ > > within the context of GIMPLE code. In particular, for scenarios > > involving single inheritance, I'm aiming to convert the following > > code: > > > > _1 = __dynamic_cast (obj_1(D), &_ZTI7Base, &_ZTI10Derived, 0); > > if (_1!= 0B) > > > > into a more direct and efficient form, such as: > > > > _2 = MEM[obj_1(D)]; > > _3 = MEM[_2 + -8B]; > > if (_3 == &_ZTI10Derived) > > > > However, during this process, I encountered an issue. I attempted to > > obtain the type node of the Derived class through the _ZTI10Derived, > > which I believe should be a VAR_DECL. Regrettably, my efforts were > > unsuccessful. > > Is this for ELF? I think our ELF ABIs require that a full string > comparison is performed if the pointers do not match. Otherwise, types > with different vtables will suddenly be considered distinct under RTTI. > The symbols for vtables can be hidden if “local: *;” is used in a linker > script, for example. Currently, as far as I understand it, this does > not have a direct impact on RTTI. > > Thanks, > Florian >
gcc-14-20250118 is now available
Snapshot gcc-14-20250118 is now available on https://gcc.gnu.org/pub/gcc/snapshots/14-20250118/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 14 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-14 revision 511920a21d4096cfc1226e5ec6140551ddc9ca90 You'll find: gcc-14-20250118.tar.xz Complete GCC SHA256=2ad5fba397aabbfc8a24bdf2308e39110606c4ce67fab6ba965ab25f5e109eb2 SHA1=163a5ab8dfc2557b6bff0abae31e57f90bb49e7e Diffs from 14-20250111 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-14 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Question about optimizing dynamic_cast call in C++ at GIMPLE Level
Hi, I have recently been delving into optimizing dynamic_cast calls in C++ within the context of GIMPLE code. In particular, for scenarios involving single inheritance, I'm aiming to convert the following code: _1 = __dynamic_cast (obj_1(D), &_ZTI7Base, &_ZTI10Derived, 0); if (_1!= 0B) into a more direct and efficient form, such as: _2 = MEM[obj_1(D)]; _3 = MEM[_2 + -8B]; if (_3 == &_ZTI10Derived) However, during this process, I encountered an issue. I attempted to obtain the type node of the Derived class through the _ZTI10Derived, which I believe should be a VAR_DECL. Regrettably, my efforts were unsuccessful. I'm reaching out to inquire if there's a viable method to achieve this. Specifically, is there a way to retrieve the type node of the original class from the third parameter of the __dynamic_cast call? Additionally, if there are any other aspects I should be aware of during this optimization process, I would greatly appreciate your insights. Thank you very much for your time and assistance. Best regards, Hanke Zhang
Re: Question about optimizing dynamic_cast call in C++ at GIMPLE Level
* Hanke Zhang via Gcc: > I have recently been delving into optimizing dynamic_cast calls in C++ > within the context of GIMPLE code. In particular, for scenarios > involving single inheritance, I'm aiming to convert the following > code: > > _1 = __dynamic_cast (obj_1(D), &_ZTI7Base, &_ZTI10Derived, 0); > if (_1!= 0B) > > into a more direct and efficient form, such as: > > _2 = MEM[obj_1(D)]; > _3 = MEM[_2 + -8B]; > if (_3 == &_ZTI10Derived) > > However, during this process, I encountered an issue. I attempted to > obtain the type node of the Derived class through the _ZTI10Derived, > which I believe should be a VAR_DECL. Regrettably, my efforts were > unsuccessful. Is this for ELF? I think our ELF ABIs require that a full string comparison is performed if the pointers do not match. Otherwise, types with different vtables will suddenly be considered distinct under RTTI. The symbols for vtables can be hidden if “local: *;” is used in a linker script, for example. Currently, as far as I understand it, this does not have a direct impact on RTTI. Thanks, Florian
[SPARC] Fix PR target/118512
This is a regression present on the mainline only, but the underlying issue
has been latent for years: the compiler and the assembler disagree on the
support of the VIS 3B SIMD ISA, the former bundling it with VIS 3 but not the
latter. IMO the documentation is not very clear, so this patch just aligns
the compiler with the assembler.
Bootstrapped/regtested on SPARC64/Solaris 11, applied on the mainline.
2025-01-18 Eric Botcazou
PR target/118512
* config/sparc/sparc-c.cc (sparc_target_macros): Deal with VIS 3B.
* config/sparc/sparc.cc (dump_target_flag_bits): Likewise.
(sparc_option_override): Likewise.
(sparc_vis_init_builtins): Likewise.
* config/sparc/sparc.md (fpcmp_vis): Replace TARGET_VIS3 with
TARGET_VIS3B.
(vec_cmp): Likewise.
(fpcmpu_vis): Likewise.
(vec_cmpu): Likewise.
(vcond_mask_): Likewise.
* config/sparc/sparc.opt (VIS3B): New target mask.
* doc/invoke.texi (SPARC options): Document -mvis3b.
2025-01-18 Eric Botcazou
* gcc.target/sparc/20230328-1.c: Pass -mvis3b instead of -mvis3.
* gcc.target/sparc/20230328-4.c: Likewise.
* gcc.target/sparc/fucmp.c: Likewise.
* gcc.target/sparc/vis3misc.c: Likewise.
--
Eric Botcazoudiff --git a/gcc/config/sparc/sparc-c.cc b/gcc/config/sparc/sparc-c.cc
index 47a22d583b6..d365da3a10b 100644
--- a/gcc/config/sparc/sparc-c.cc
+++ b/gcc/config/sparc/sparc-c.cc
@@ -52,6 +52,11 @@ sparc_target_macros (void)
cpp_define (parse_in, "__VIS__=0x400");
cpp_define (parse_in, "__VIS=0x400");
}
+ else if (TARGET_VIS3B)
+{
+ cpp_define (parse_in, "__VIS__=0x310");
+ cpp_define (parse_in, "__VIS=0x310");
+}
else if (TARGET_VIS3)
{
cpp_define (parse_in, "__VIS__=0x300");
diff --git a/gcc/config/sparc/sparc.cc b/gcc/config/sparc/sparc.cc
index a62b8033954..2196a0c4498 100644
--- a/gcc/config/sparc/sparc.cc
+++ b/gcc/config/sparc/sparc.cc
@@ -1671,6 +1671,8 @@ dump_target_flag_bits (const int flags)
fprintf (stderr, "VIS2 ");
if (flags & MASK_VIS3)
fprintf (stderr, "VIS3 ");
+ if (flags & MASK_VIS3B)
+fprintf (stderr, "VIS3B ");
if (flags & MASK_VIS4)
fprintf (stderr, "VIS4 ");
if (flags & MASK_VIS4B)
@@ -1919,19 +1921,23 @@ sparc_option_override (void)
if (TARGET_VIS3)
target_flags |= MASK_VIS2 | MASK_VIS;
- /* -mvis4 implies -mvis3, -mvis2 and -mvis. */
- if (TARGET_VIS4)
+ /* -mvis3b implies -mvis3, -mvis2 and -mvis. */
+ if (TARGET_VIS3B)
target_flags |= MASK_VIS3 | MASK_VIS2 | MASK_VIS;
- /* -mvis4b implies -mvis4, -mvis3, -mvis2 and -mvis */
+ /* -mvis4 implies -mvis3b, -mvis3, -mvis2 and -mvis. */
+ if (TARGET_VIS4)
+target_flags |= MASK_VIS3B | MASK_VIS3 | MASK_VIS2 | MASK_VIS;
+
+ /* -mvis4b implies -mvis4, -mvis3b, -mvis3, -mvis2 and -mvis */
if (TARGET_VIS4B)
-target_flags |= MASK_VIS4 | MASK_VIS3 | MASK_VIS2 | MASK_VIS;
+target_flags |= MASK_VIS4 | MASK_VIS3B | MASK_VIS3 | MASK_VIS2 | MASK_VIS;
- /* Don't allow -mvis, -mvis2, -mvis3, -mvis4, -mvis4b, -mfmaf and -mfsmuld if
- FPU is disabled. */
+ /* Don't allow -mvis, -mvis2, -mvis3, -mvis3b, -mvis4, -mvis4b, -mfmaf and
+ -mfsmuld if FPU is disabled. */
if (!TARGET_FPU)
-target_flags &= ~(MASK_VIS | MASK_VIS2 | MASK_VIS3 | MASK_VIS4
- | MASK_VIS4B | MASK_FMAF | MASK_FSMULD);
+target_flags &= ~(MASK_VIS | MASK_VIS2 | MASK_VIS3 | MASK_VIS3B
+ | MASK_VIS4 | MASK_VIS4B | MASK_FMAF | MASK_FSMULD);
/* -mvis assumes UltraSPARC+, so we are sure v9 instructions
are available; -m64 also implies v9. */
@@ -11451,10 +11457,6 @@ sparc_vis_init_builtins (void)
def_builtin_const ("__builtin_vis_fmean16", CODE_FOR_fmean16_vis,
SPARC_BUILTIN_FMEAN16, v4hi_ftype_v4hi_v4hi);
- def_builtin_const ("__builtin_vis_fpadd64", CODE_FOR_fpadd64_vis,
- SPARC_BUILTIN_FPADD64, di_ftype_di_di);
- def_builtin_const ("__builtin_vis_fpsub64", CODE_FOR_fpsub64_vis,
- SPARC_BUILTIN_FPSUB64, di_ftype_di_di);
def_builtin_const ("__builtin_vis_fpadds16", CODE_FOR_ssaddv4hi3,
SPARC_BUILTIN_FPADDS16, v4hi_ftype_v4hi_v4hi);
@@ -11473,6 +11475,34 @@ sparc_vis_init_builtins (void)
def_builtin_const ("__builtin_vis_fpsubs32s", CODE_FOR_sssubv1si3,
SPARC_BUILTIN_FPSUBS32S, v1si_ftype_v1si_v1si);
+ def_builtin_const ("__builtin_vis_fhadds", CODE_FOR_fhaddsf_vis,
+ SPARC_BUILTIN_FHADDS, sf_ftype_sf_sf);
+ def_builtin_const ("__builtin_vis_fhaddd", CODE_FOR_fhadddf_vis,
+ SPARC_BUILTIN_FHADDD, df_ftype_df_df);
+ def_builtin_const ("__builtin_vis_fhsubs", CODE_FOR_fhsubsf_vis,
+ SPARC_BUILTIN_FHSUBS, sf_ftype_sf_sf);
+ def_builtin_const ("__builtin_vis_fhsubd", CODE_FOR_fhsubdf_vis,
+ SPARC_BUILTIN_FHSUBD, df_ftype_df_df);
+ def_builtin_const ("__builtin_vis_fnhadds", CODE_FOR_fnhaddsf_vis,
+ SPARC_BUILTIN_FNHADDS, sf_ftype_sf_sf);
+ def_bu
