https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119488
--- Comment #4 from Giuseppe D'Angelo ---
Hi,
Apologies for the testsuite regression; I think this is fixed now in trunk by
r15-8971-g6acfb68dc0a479 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #12 from Giuseppe D'Angelo ---
The testcase was just meant to show that a warning originating in a system
header was still be emitted, not that the specific warning didn't make sense :)
Of course it was silly/extreme.
But I understa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #8 from Giuseppe D'Angelo ---
Well, that's a laudable goal, but I'm very afraid it'll just cause the
corresponding warnings to be entirely disabled instead -- since in many cases
the end-user can't upgrade the system header, nor the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
--- Comment #5 from Giuseppe D'Angelo ---
Hi,
Thanks for the link. However this isn't just about -Wuninitialized, but also
about a bunch of other (middle-end?) warnings, as I wrote in the first message.
(To add insult to injury, they're also fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119388
Bug ID: 119388
Summary: [12/13/14/15 Regression] -isystem does not disable
warnings coming from system headers
Product: gcc
Version: 15.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119179
--- Comment #2 from Giuseppe D'Angelo ---
For instance something like this:
class VLA
{
private:
static constexpr int DEFAULT_CAP = 256;
int m_size = 0;
int m_capacity = DEFAULT_CAP;
int m_data[DEFAULT_CAP]; // uninit; just sto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119179
Bug ID: 119179
Summary: Allow the [[gnu:::uninitialized]] attribute on classes
/ non-static data members
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119144
--- Comment #9 from Giuseppe D'Angelo ---
Erk, too slow. Thank you Jonathan.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119144
--- Comment #8 from Giuseppe D'Angelo ---
Please assign this to me, I'll post a patch shortly.
> Oh and the test uses std::string fails with -D_GLIBCXX_USE_CXX11_ABI=0
> because the COW std::string isn't usable in constexpr. Sorry for not noti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115402
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110357
--- Comment #1 from Giuseppe D'Angelo ---
I have posted a preliminary patch, but it needs a rebase and more work
(basically some implementation design choice).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119045
--- Comment #3 from Giuseppe D'Angelo ---
Thank you, the fix seems to work on my actual testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119045
Bug ID: 119045
Summary: ICE when using _Complex accessors, in
cxx_eval_store_expression, at cp/constexpr.cc:6418
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85889
--- Comment #15 from Giuseppe D'Angelo ---
Unfortunately not; that is https://cplusplus.github.io/CWG/issues/2313.html .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85889
--- Comment #13 from Giuseppe D'Angelo ---
Not sure; N4659 says
https://timsong-cpp.github.io/cppwp/n4659/expr.prim.lambda.capture#4
"The identifier in a simple-capture is looked up using the usual rules for
unqualified name lookup; each such l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118719
--- Comment #2 from Giuseppe D'Angelo ---
Sorry, I assumed that, since 14 accepted valid code without warnings, but 15
introduces a spurious warning, then it would classify as a 14->15 regression.
Please do amend the subject if that reasoning is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85889
--- Comment #11 from Giuseppe D'Angelo ---
Sure thing! It's PR118719.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118719
Bug ID: 118719
Summary: [14/15 regression] Spurious -Wc++20-extensions warning
emitted when capturing a structured binding
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85889
--- Comment #9 from Giuseppe D'Angelo ---
> For comparison, Clang doesn't warn.
... doesn't warn on (2) and (3), that is. (Those are the cases for which I
think GCC is wrong at emitting the warning.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85889
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118542
--- Comment #2 from Giuseppe D'Angelo ---
Better testcase, I guess: https://gcc.godbolt.org/z/Yce4qEabM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118542
--- Comment #1 from Giuseppe D'Angelo ---
Uhm, I think I am wrong about MSVC -- without the new preprocessor enabled, it
doesn't seem it likes function-like macros anyhow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118542
Bug ID: 118542
Summary: Split -Wexpansion-to-defined for function vs. object
like macros
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924
--- Comment #8 from Giuseppe D'Angelo ---
> Interesting, mind creating a separate PR for this? It could be a considered a
> regression since GCC 13 accepts the code.
Done! It's PR118285.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118285
--- Comment #1 from Giuseppe D'Angelo ---
As noted PR103924, the testcase is actually accepted by GCC 13 (in C++23 mode),
so this looks like a regression. https://gcc.godbolt.org/z/zMK3ceE5M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118285
Bug ID: 118285
Summary: GCC rejects some constexpr std::string usages
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118160
--- Comment #1 from Giuseppe D'Angelo ---
Posted so to cross reference it from a commit; patch discussion
https://gcc.gnu.org/pipermail/libstdc++/2024-December/060224.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118160
Bug ID: 118160
Summary: Dangling reference in std::ranges::is_permutation may
cause a crash
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117967
--- Comment #2 from Giuseppe D'Angelo ---
Well, I'm wondering if it's OK that passing -shared causes that warning. I'm
not a fan of suppressing warnings; I'd rather have `-fhardened` always enabled
and always "do the right thing", that is, only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117967
Bug ID: 117967
Summary: -Wno-hardened does not disable all -fhardened warnings
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116769
--- Comment #4 from Giuseppe D'Angelo ---
Hi, thanks for investigating.
That divergence is a bit worrying, I can't quite understand what's going on.
Also, all compilers seem to accept this variation, which one would naively
assume "equivalent"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116769
--- Comment #2 from Giuseppe D'Angelo ---
> * rejects the code due to the default constructor being invalid.
That would be Clang?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116769
Bug ID: 116769
Summary: Instantiation of defaulted default constructor with
non default constructible NDSMIs
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116471
Giuseppe D'Angelo changed:
What|Removed |Added
Attachment #58984|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116471
--- Comment #4 from Giuseppe D'Angelo ---
Created attachment 58984
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58984&action=edit
patch v1
Attaching a patch for this + PR108846 , since the testcases basically cover
both in one go.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116471
--- Comment #3 from Giuseppe D'Angelo ---
> You might be right that we never needed it in ranges::copy because it's
> already constrained correctly.
So would it be OK to just remove the static_assert from the range-based
algorithms?
> N.B. Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116471
Bug ID: 116471
Summary: Strange/bogus static_assert in ranges::copy / move
algorithms
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764
--- Comment #7 from Giuseppe D'Angelo ---
I get it :)
If you wanted an actual use-case (rather than a synthetic testcase), we
stumbled upon this bug from implementing a friend operator==:
```
class S {
bool comparesEqual(S, S) noexcept; //
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764
--- Comment #5 from Giuseppe D'Angelo ---
Just to understand, are we talking about an implementation challenge (because
within a class you may refer to stuff not yet declared when parsing the
noexcept spec, or similar), or that using noexcept on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764
--- Comment #3 from Giuseppe D'Angelo ---
I guess you're referring to https://lists.isocpp.org/core/2019/07/6785.php ?
I'm really not sure why a friend function declaration is different from a free
function, where multiple equivalent declaratio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114764
Bug ID: 114764
Summary: noexcept on a friend complains about incomplete type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114029
Bug ID: 114029
Summary: -Warray-bounds does not warn for global arrays
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113060
--- Comment #9 from Giuseppe D'Angelo ---
Thank you, I'll amend P3146 with this new information, and try and make sure
that LEWG/LWG see the updated draft (if they discuss this before the next
mailing).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113060
--- Comment #7 from Giuseppe D'Angelo ---
Hi,
> Note that this example adds a mediate function template
> (test_array_element_initializable) to "reduce" the non-constexpr-ness of
> std::declval.
That's very clever, thank you!
Is it _suppos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477
--- Comment #7 from Giuseppe D'Angelo ---
Hi,
To be honest I didn't even notice it was a regression, but you're absolutely
right, I can't reproduce my problem with GCC 12, only with GCC 13 (both in
C++17 mode).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113060
--- Comment #2 from Giuseppe D'Angelo ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Giuseppe D'Angelo from comment #0)
> > GCC 14 implements P2280 (see #106650).
>
> N.B. if you say "Bug 106650" or "PR 106650" or "bug #10665
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113060
Bug ID: 113060
Summary: std::variant converting constructor/assignment is
non-conforming after P2280?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112637
Bug ID: 112637
Summary: Bogus -Wmaybe-uninitialized warning
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477
Giuseppe D'Angelo changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Giuse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477
Bug ID: 112477
Summary: Assignment of value-initialized iterators differs from
value-initialization
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404
--- Comment #2 from Giuseppe D'Angelo ---
(In reply to Richard Biener from comment #1)
> But your testcase is invoking undefined behavior when inspecting 'ptr'?
> That doesn't change with -ftrivial-auto-var-init=zero, so getting a trap is
> goo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375
--- Comment #5 from Giuseppe D'Angelo ---
Done in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404
Bug ID: 110404
Summary: Feature request: make -ftrivial-auto-var-init=zero
zero-initialize, not zero-fill
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375
--- Comment #4 from Giuseppe D'Angelo ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Giuseppe D'Angelo from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > The code is undefined,
> >
> > Sure, although there ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375
--- Comment #2 from Giuseppe D'Angelo ---
(In reply to Andrew Pinski from comment #1)
> The code is undefined,
Sure, although there are C++ proposals to make it well-defined /
implementatiopn-defined (see
https://www.open-std.org/jtc1/sc22/wg21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375
Bug ID: 110375
Summary: -ftrivial-auto-var-init=zero issues with pointers to
data members
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #20 from Giuseppe D'Angelo ---
Thanks for the patch!
Should ranges_algobase.h also be similarly changed? There's a memmove in its
copy/move code as well:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #15 from Giuseppe D'Angelo ---
That's not what I meant; a type can be trivial(ly copyable) and move-only.
Here's a modification of Arthur's example:
// move-only
struct B {
B(int i, short j) : i(i), j(j) {}
B(B &&) = defaul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #12 from Giuseppe D'Angelo ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Giuseppe D'Angelo from comment #5)
> > https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/
> > stl_algobase.h#L417-L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #5 from Giuseppe D'Angelo ---
> In the case of copy family algorithms, I believe it's OK to specially handle
> cases where last - first == 1.
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_algobase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99625
--- Comment #5 from Giuseppe D'Angelo ---
No problem, thanks for working on GCC :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99625
--- Comment #3 from Giuseppe D'Angelo ---
Hi,
Sorry to ping, but some time has gone by -- I guess this fell through the
cracks?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107697
Bug ID: 107697
Summary: -Wredundant-move misses std::move applied to const
objects (instead of const references)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525
--- Comment #9 from Giuseppe D'Angelo ---
(In reply to Jonathan Wakely from comment #5)
> Please don't! At least not in the next 9 days. We intend to vote out LFTSv3
> at next week's meeting, there will be no more proposals for LFTS considered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525
--- Comment #4 from Giuseppe D'Angelo ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Giuseppe D'Angelo from comment #0)
> > So. ideally, the conversion operators should be using C++20 constraints, but
> > of course that's not p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107525
Bug ID: 107525
Summary: propagate_const should not be using SFINAE on its
conversion operators
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107507
Bug ID: 107507
Summary: Conversion function templates are not sometimes not
considered if the return type is type dependent
Product: gcc
Version: 12.2.1
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107495
--- Comment #1 from Giuseppe D'Angelo ---
Variation of the above:
struct Test {
template
operator int *() const;
};
Test t;
delete t;
also fails:
: In function 'int main()':
:32:12: error: default type conversion cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107495
Bug ID: 107495
Summary: GCC does not consider the right contextual implicit
conversions
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102396
--- Comment #6 from Giuseppe D'Angelo ---
That's brilliant! I really hadn't thought that pushing the hidden friend into a
private base would work nonetheless. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102396
--- Comment #4 from Giuseppe D'Angelo ---
To elaborate on the last comment, this testcase does complain about the
redefinition.
#include
#include
template class S;
template
static inline std::true_type is_S_impl(con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102396
--- Comment #3 from Giuseppe D'Angelo ---
Hello Patrick,
Thank you for the insights. I'm left wondering however if the CWG resolution
would possibly ever allow the operator== to be defined as a hidden friend; the
workaround you mentioned may le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102221
--- Comment #6 from Giuseppe D'Angelo ---
Hi,
(Sorry for chiming in after all this time); given this might not entirely be
libstdc++ related (cf. the latest testcase), would it be possible for someone
on the optimizer to gave their opinion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102283
--- Comment #5 from Giuseppe D'Angelo ---
(Sorry for the delay)
Thank you for the analysis. I'm now not really sure if GCC is doing something
wrong (vs Clang/MSVC). Feel free to close/suspend this task if you strongly
believe GCC is right here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102399
Bug ID: 102399
Summary: Cannot mix GCC and C++11 / C23 attribute syntax
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102397
Bug ID: 102397
Summary: Documentation of attribute syntax does not discuss
C++11 / C23 attribute syntax
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102396
Bug ID: 102396
Summary: ICE when using concepts, in get, at
cp/constraint.cc:2637
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102283
--- Comment #2 from Giuseppe D'Angelo ---
Hi,
Do you think that in my original testcase the call should be rejected as
ambiguous as well? (It seems "reasonable" to me, but maybe I'm missing some
niche detail about overload resolution when combi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102283
Bug ID: 102283
Summary: Inconsistent/wrong overload resolution when using an
initializer list and a defaulted template parameter
Product: gcc
Version: 11.2.1
Status: UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102221
--- Comment #5 from Giuseppe D'Angelo ---
Here's a further testcase that doesn't even use unique_ptr:
#include
#include
using ptr = int *;
using rawptr = int *;
#ifndef RESTRICT
#define RESTRICT
#endif
void swap(ptr & RESTRICT a, ptr & RE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102221
--- Comment #2 from Giuseppe D'Angelo ---
Hi,
Thanks for the analysis!
That basically allows me to reduce the testcase to something as simple as a
swap:
#include
#include
#if defined(SMART)
using ptr = std::unique_ptr;
#else
using ptr = i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102221
Bug ID: 102221
Summary: Missed optimizations for algorithms over
std::unique_ptr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
--- Comment #13 from Giuseppe D'Angelo ---
Hi,
(In reply to Martin Sebor from comment #12)
> So in general, the distinction between the two cases can only be made when
> it can be discerned from the IL, and the IL doesn't always preserve the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
--- Comment #8 from Giuseppe D'Angelo ---
In a -Wall build, it's a bit unfair to pretend the users to know if a warning
is being generated by the frontend, the middleend, the backend and so on. All
they get is a list of warnings saying "this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
--- Comment #6 from Giuseppe D'Angelo ---
(In reply to Martin Sebor from comment #5)
> It wouldn't be right to change the wording of just one warning because the
> problem applies to all flow based diagnostics. They all depend on various
> opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
--- Comment #4 from Giuseppe D'Angelo ---
Could the warning messages then be changed to point out that the issue is only
a mere possibility? Using an "assertive" wording makes users believe that GCC
has positively and conclusively proved that th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100796
--- Comment #10 from Giuseppe D'Angelo ---
Thank you very much.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
--- Comment #2 from Giuseppe D'Angelo ---
As I said,
> Adding enough __builtin_unreachable() for that condition removes the
> warnings, but it should not be necessary.
I disagree with the resolution, though. While I understand that GCC cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
Bug ID: 101134
Summary: Bogus -Wstringop-overflow warning about non-existent
overflow
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100796
--- Comment #6 from Giuseppe D'Angelo ---
Hi,
Wow, that was quick!
I can't really judge the merit of the patch, but I've picked it on top of the
GCC 11.1.0 tarball and can confirm that it seems to fix all the warnings for
us. Thank you very mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100796
--- Comment #4 from Giuseppe D'Angelo ---
Created attachment 51011
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51011&action=edit
testcase
Hi,
I've tried to "carve" a subset of files that show the problem. Apologies for
not really bein
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100796
--- Comment #2 from Giuseppe D'Angelo ---
Well, GCC 8-9-10 don't have this problem at all for us. This appeared only when
upgrading to 11.
Anyways, I'm not sure if it's the same issue. PR 53431 seems to be about the
preprocessor itself ignoring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100796
Bug ID: 100796
Summary: [11 Regression] GCC does not honor #pragma diagnostic
ignored when using the integrated preprocessor
Product: gcc
Version: unknown
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #18 from Giuseppe D'Angelo ---
Hello,
(In reply to Jonathan Wakely from comment #17)
> (In reply to Giuseppe D'Angelo from comment #14)
> > To summarize:
> >
> > * should a wording defect be raised against std::to_address(Ptr), to s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #14 from Giuseppe D'Angelo ---
Hello,
(In reply to Glen Joseph Fernandes from comment #11)
> > if it can never be used.
>
> You're misunderstanding. to_address(p) requires that pointer_traits is
> valid. It just doesn't need to ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #10 from Giuseppe D'Angelo ---
(By the way, finding this bug is quite hard. Could "address_of" be changed to
"to_address" , in the bug description? I think that's the intended meaning.
And, "to_pointer", mentioned a few times, doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail dot com
--- Commen
1 - 100 of 103 matches
Mail list logo
