https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120577
Bug ID: 120577
Summary: Another crash with [[no_unique_address]] and constexpr
functions
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120502
Bug ID: 120502
Summary: GCC Crash at cp/constexpr.cc:5462 when trying to
constant evaluate constructor
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118655
Bug ID: 118655
Summary: __is_bounded_array returns true for zero-size arrays
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113958
Nikolas Klauser changed:
What|Removed |Added
CC||nikolasklauser at berlin dot de
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116673
Bug ID: 116673
Summary: __builtin_launder accepts function pointers and void
pointers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479
Bug ID: 114479
Summary: std::is_array_v changed from false to true in
GCC 14
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110904
Bug ID: 110904
Summary: __is_convertible incorrectly reports non-referenceable
function prototypes as convertible
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #8 from Nikolas Klauser ---
I agree that the wording is a bit ambiguous, but GCC should decide on one of
them instead of returning different results between the type trait builtins and
the noexcept operator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110084
Bug ID: 110084
Summary: defaulted constexpr operator== causes crash
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #12 from Nikolas Klauser ---
(In reply to Jonathan Wakely from comment #10)
> Using always_inline on everything is simply wrong: GCC will refuse to inline
> some functions and the user gets an error that they cannot avoid. There's no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #8 from Nikolas Klauser ---
(In reply to Florian Weimer from comment #7)
> (In reply to Nikolas Klauser from comment #6)
> > Does that make sense?
>
> Not quite. I was trying to suggest that you also need to suppress all
> inter-pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #6 from Nikolas Klauser ---
(In reply to Florian Weimer from comment #5)
> How hard is this to use in practice? With current Clang, this:
>
> “
> template
> class S {
> __attribute__ ((visibility ("hidden"),
> exclude_from_explic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
--- Comment #4 from Nikolas Klauser ---
(In reply to Andrew Pinski from comment #3)
> I am getting a feeling this attribute is well defined enough.
>
> Is it really just supposed to block explicit instantiation of templates?
> Is there a decent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
Bug ID: 11
Summary: GCC should implement
exclude_from_explicit_instantiation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108393
Bug ID: 108393
Summary: circular concept false-positive
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108223
--- Comment #3 from Nikolas Klauser ---
It doesn't have to work, but it works for some inputs, so I would expect that
it works for all. https://godbolt.org/z/KsrjEP77c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108223
Bug ID: 108223
Summary: GCC reject QNaN in constant expressions
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #6 from Nikolas Klauser ---
Is there any update on this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107388
--- Comment #2 from Nikolas Klauser ---
Shouldn't -Wconversion also enable -Wsign-conversion? -Wconversion sounds to me
like it should diagnose all conversions, especially since it's the same kind of
bug I want to catch by enabling the flags. In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107388
Bug ID: 107388
Summary: GCC should diagnose unsigned to signed conversion
with -Wconversion
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107187
Bug ID: 107187
Summary: [feature request] Add `trivial_abi` attribute
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106759
Bug ID: 106759
Summary: __has_builtin doesn't report
__is_nothrow_constructible as supported
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #5 from Nikolas Klauser ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Nikolas Klauser from comment #2)
> > static_assert(!noexcept(std::declval(;
> >
> > is fine.
>
> It doesn't look fine to me! Is there a '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #3 from Nikolas Klauser ---
I did some more digging and it looks like nobody can agree on what the right
result is.
This is the result of the question whether the listed operation on struct S {
noexcept(false) = default; } is noexc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #2 from Nikolas Klauser ---
(In reply to Jonathan Wakely from comment #1)
> The noexcept specifier is wrong, but is ignored. The implicitly defined copy
> constructor is noexcept, so the trait gives the right answer.
static_assert(!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
Bug ID: 106611
Summary: std::is_nothrow_copy_constructible returns wrong
result
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Pri
26 matches
Mail list logo
