[Bug c++/105656] remove BROKEN_VALUE_INITIALIZATION workaround

2023-01-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105656

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||internal-improvement
   Last reconfirmed||2023-01-06
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Confirmed.

[Bug c++/105656] remove BROKEN_VALUE_INITIALIZATION workaround

2022-05-19 Thread aldot at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105656

--- Comment #2 from Bernhard Reutner-Fischer  ---
Yes, i've seen your bigger patch to remove all of these version conditionals.

But please note that this BROKEN_VALUE_INITIALIZATION was explicitly taylored
to catch aforementioned GCC versions, and really GCC itself. It even explicitly
excluded clang as that announces itself as 4.2.

/* GCC older than 4.4 have broken C++ value initialization handling, see
   PR11309, PR30111, PR33916, PR82939 and PR84405 for more details.  */
#if GCC_VERSION > 0 && GCC_VERSION < 4004 && !defined(__clang__)
# define BROKEN_VALUE_INITIALIZATION
#endif

Your big patch could maybe be refined a bit. For example, i think newer GCC do
recognize popcount patterns, so i assume that the conditions in
bitmap_count_bits_in_word should no longer be needed; Also, i assume that any
compiler that is used to build gcc will have to implement builtins like
__builtin_popcount{,l,ll} anyway. Same should hold true for ctz, clz, ffs.
I'm not sure what the standard has to say about unknown pragmas, but i'd assume
that a compiler should silently ignore "#pragma GCC whatever" if it doesn't
feel responsible for that identifier. If so, then using the GCC pragmas
unconditionally should be fine.
Maybe we should have an ATTRIBUTE_FORMAT macro to handle all of these
occurrences.
All in all, i think now that we require c++, and c++11 even, most of these
guards should probably key off plain __GNUC__, as Richard said.

[Bug c++/105656] remove BROKEN_VALUE_INITIALIZATION workaround

2022-05-19 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105656

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
I was suggesting a similar change, but it's more complicated.
Please read the following thread:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594102.html