https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114986
Bug ID: 114986
Summary: Seemingly incorrect "ignoring packed attribute"
warning
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #19 from Peter Dimov ---
This should work.
I still don't understand why JF so insisted on all these padding shenanigans.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #13 from Peter Dimov ---
(In reply to Andrew Pinski from comment #10)
> #if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding)
> if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>())
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #11 from Peter Dimov ---
So, basically, C++14 and above initialize the padding of
```
std::atomic state{{ 0, 0x }};
```
in `main` to zero, which masks the problem in `generate`. (The problem in
`generate` still exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #9 from Peter Dimov ---
Oh, my mistake. C++14 does mov QWORD, and C++11 does mov WORD.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #8 from Peter Dimov ---
(In reply to Andrew Pinski from comment #6)
> No it is dependent on the standard level. C++11 fails but C++14, C++17 and
> C++20 all pass.
That's interesting because I see basically no difference in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #4 from Peter Dimov ---
This
https://raw.githubusercontent.com/boostorg/uuid/feature/gcc_pr_114865/test/test_gcc_pr114865.cpp
exhibits the problem for me on GCC 13/14. I'm only seeing the hang with
-std=c++11 -m32 in the CI run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #2 from Peter Dimov ---
The issue is also present for GCC 14 on Ubuntu 24.04:
https://github.com/boostorg/uuid/actions/runs/8853249656/job/24313667955
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #1 from Peter Dimov ---
> The problem may well be inside libatomic, of course; I have no way to tell.
Narrator: but he did, in fact, have a way to tell.
This is a GHA run with GCC 9 to 13 tested on both Ubuntu 23.04 and Ubuntu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
Bug ID: 114865
Summary: std::atomic::compare_exchange_strong seems to hang
under GCC 13 on Ubuntu 23.04
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113256
Bug ID: 113256
Summary: False -Wdangling-reference positive
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200
--- Comment #4 from Peter Dimov ---
I didn't notice your subsequent comment, sorry. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200
--- Comment #3 from Peter Dimov ---
I think that the compiler is correct; string literal address comparisons aren't
constant expressions. Clang gives the same error:
https://godbolt.org/z/xPWEf4z63.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200
Bug ID: 113200
Summary: std::char_traits::move is not constexpr when the
argument is a string literal
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #10 from Peter Dimov ---
Maybe the right thing to do is to use dynamic_cast only for virtual inheritance
(either have a trait or check whether static_cast isn't a valid expression),
otherwise static_cast, in both cases (standard and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
--- Comment #7 from Peter Dimov ---
You don't necessarily need dynamic_cast because facets are always installed and
obtained by their exact type, not via a reference to base. You can store the
Facet* as given (like shared_ptr does), and return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86355
--- Comment #14 from Peter Dimov ---
Should I open another bug for the failure to compile the original example?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110476
--- Comment #2 from Peter Dimov ---
Discussion of FLT_EVAL_METHOD notwithstanding, I think that this behavior is
not allowed by https://eel.is/c++draft/lex.fcon#3.
"If the scaled value is not in the range of representable values for its type,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #8 from Peter Dimov ---
As I commented on the duplicate bug, I don't think this behavior is allowed by
https://eel.is/c++draft/lex.fcon#3.
"If the scaled value is not in the range of representable values for its type,
the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #13 from Peter Dimov ---
I think that https://eel.is/c++draft/lex.fcon#3 disagrees.
"If the scaled value is not in the range of representable values for its type,
the program is ill-formed. Otherwise, the value of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #6 from Peter Dimov ---
I suppose this is unfixable because there's all sorts of code assuming that the
value of (long double)3.14 is 3.14L and not (long double)(double)3.14L.
I doubt that anyone sane expects this from (long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #3 from Peter Dimov ---
That's true, but the normal expectation of anyone using
-fexcess-precision=standard would be for it to apply consistently everywhere
(that is, as if FLT_EVAL_METHOD is 0.)
Of course given that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110476
--- Comment #1 from Peter Dimov ---
As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742, this is a
consequence of applying the FLT_EVAL_METHOD=2 rules, and can be fixed by
casting 3.14f to (float).
That's... incredibly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #1 from Peter Dimov ---
Looks like a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
and is fixed by casting the rhs to (float), but any ordinary programmer would
be baffled.
For context, I encountered this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
Bug ID: 110477
Summary: -fexcess-precision=standard not applied consistently
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110476
Bug ID: 110476
Summary: constexpr floating point regression with -std=c++XX
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
--- Comment #13 from Peter Dimov ---
Even if we assume that WFE on lock (and SEV on unlock) is the correct approach
on ARM instead of YIELD (though this seems very much domain-specific, depending
on the expected amount of contention and who
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
--- Comment #9 from Peter Dimov ---
I don't think I want WFE here, based on what I read about it. Putting the core
to sleep seems like something to do in an embedded system where I have full
control of what cores do, not something to do on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
--- Comment #7 from Peter Dimov ---
These intrinsics are typically used in spinlocks as in
```
while( flag_.test_and_set() )
{
// issue a power-saving NOP here
}
```
(where `flag_` is `std::atomic_flag`) and this use is generic and not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
--- Comment #5 from Peter Dimov ---
This works for the specific case of ARM, even though I don't find it
substantially better than just using `asm("yield")`, but the benefit of having
a portable intrinsic for this functionality is that as such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
--- Comment #3 from Peter Dimov ---
How does the user know when to include `arm_acle.h`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110096
Bug ID: 110096
Summary: Would be nice if __builtin_ia32_pause had a portable
equivalent as it's applicable to ARM
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
Bug ID: 109985
Summary: __builtin_prefetch ignored by GCC 12/13
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108952
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108836
--- Comment #4 from Peter Dimov ---
A compromise between no mutex at all, and a mutex that is silently a no-op,
could be a no-op mutex with [[deprecated]] members, although the atomic_flag is
probably better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108836
--- Comment #2 from Peter Dimov ---
That's good to hear, but I don't think the issue is specific to mingw32. The
other report, https://github.com/boostorg/system/issues/92, was about "B
PLC", whatever this means. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108836
Bug ID: 108836
Summary: std::mutex disappears in single-threaded libstdc++
builds
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #9 from Peter Dimov ---
The easiest way to reproduce the issue is with the following test:
https://github.com/boostorg/smart_ptr/blob/c577d68b0272fd0bddc88ea60a8db07219391589/test/spinlock_test.cpp
This crashes because -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545
--- Comment #9 from Peter Dimov ---
My Godbolt link above no longer reproduces the warning because of
https://github.com/boostorg/describe/commit/c8c46bfdf78022a8a7e9e06983d8b04ccb921991,
but this one does: https://godbolt.org/z/oT1M31osa.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105992
Bug ID: 105992
Summary: memcmp(p, q, 7) == 0 can be optimized better on x86
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102168
--- Comment #6 from Peter Dimov ---
Yes, I suppose you're right. The warning warns that Derived _can be_ deleted
via Base*, and that's correct - if not very useful in practice in this specific
case.
In fact the private destructor case is even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102168
--- Comment #4 from Peter Dimov ---
Warning on a private destructor + a friend declaration makes sense, because a
private destructor implies that the type is not intended to be derived from.
But warning on a protected destructor + a friend does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102168
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105482
Bug ID: 105482
Summary: Regression with `>=` in a template argument
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104945
Bug ID: 104945
Summary: std::hash ignores the top 32 bits when
size_t is 32 bit
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104867
Bug ID: 104867
Summary: Base class matching ignores type of `auto` template
parameter
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104426
--- Comment #4 from Peter Dimov ---
FWIW, I agree with everything Martin Sebor says in PR71962.
-fallow-address-zero is an entirely separate feature, and shouldn't be implied
by -fsanitize=undefined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104426
Bug ID: 104426
Summary: -fsanitize=undefined causes constexpr failures
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102651
Bug ID: 102651
Summary: typeid(X**) instantiates X
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425
Bug ID: 102425
Summary: std::error_code() does not compare equal to
std::error_condition()
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #18 from Peter Dimov ---
I would use it like this: https://godbolt.org/z/1eqEx6678
#include
struct error_category
{
};
error_category const& system_category();
struct error_code
{
error_code( int v, error_category const&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #16 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #14)
> But we haven't done that that way and how would headers know if the
> __builtin_source_location that is available is the old or new one?
The header could do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #15 from Peter Dimov ---
(In reply to Jonathan Wakely from comment #13)
> It wouldn't work correctly in all cases, as Jakub points out, because
> std::source_location::current() is part of the magic.
>
> And I'm not convinced we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #10 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #9)
> That would be an aliasing violation.
> The artificial vars created by __builtin_source_location have the
> std::source_location::__impl type, so accessing those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #8 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #6)
> Note, having the struct somewhere else isn't that useful unless you know
> exactly how its non-static data members are named and what they mean, so
> ideally a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #7 from Peter Dimov ---
(In reply to Jonathan Wakely from comment #5)
> Sure. It's just a question of whether we're trying to provide a general
> purpose extension available for users, or an internal helper for the
> std::lib. IIRC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #4 from Peter Dimov ---
On the surface this looks not hard to fix - use ::__source_location_impl (or
std::__source_location_impl) instead of std::source_location:__impl as the
layout struct - but I'm not sure whether this would pose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
--- Comment #2 from Peter Dimov ---
(In reply to Jakub Jelinek from comment #1)
> __builtin_source_location doesn't require -std=c++20, but indeed does
> require or some compatible definition of
> std::source_location::__impl class, and as it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102350
Bug ID: 102350
Summary: __builtin_source_location not available in earlier
language modes
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100827
--- Comment #1 from Peter Dimov ---
Update: GCC 10.2 doesn't have the issue, but 10.1 and 10.3 do. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100827
Bug ID: 100827
Summary: Compiler crash with Boost.Bimap and Boost.Xpressive
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99495
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14721
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98649
Bug ID: 98649
Summary: Trivial jump table not eliminated
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707
Peter Dimov changed:
What|Removed |Added
CC||pdimov at gmail dot com
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97464
Bug ID: 97464
Summary: Missed redundant store optimization opportunity
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
69 matches
Mail list logo
