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
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
When upgrading from GCC 11 to 13/14, some warnings start to appear from headers
that have been included via
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
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
When building under -ftrivial-auto-var-init, certain classes that contain
buffers (e.g. for SBO) and/or are used as
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 do
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.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hello,
The following reduced testcase: https://gcc.godbolt.org/z/1n1sdYvqe
constexpr bool test
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.
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hi,
This is a spin-off of bug 85889, comment 8 .
GCC 15 added a compatibility warning when capturing
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 do
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.
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
-Wexpansion-to-defined is currently enabled by -Wextra (or -pedantic).
While there is implementation divergence when expanding
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
++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hi,
This is a spin-off of PR103924.
The following testcase is rejected by GCC rejected by GCC but accepted by Clang
(with libstdc++):
https://gcc.godbolt.org/z/63Wss3Ej8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103924
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail do
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
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
The implementation of ranges::is_permutation may create a dangling reference,
which then results (sometimes) in a crash
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
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
If gcc is invoked with -fhardened and certain linker options are passed, a
warning is always generated, even under -Wno-hardened:
> $ g++ -fhardened -Wno-harde
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?
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hi,
Consider this testcase:
#include
struct NDC { NDC(int); };
template
struct Wrap
{
Wrap() = default
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
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hi,
This code fails to build on GCC 14 (CE link:
https://gcc.godbolt.org/z/qnYGd48Ko )
#include
struct X {
X& operato
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
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Testcase:
struct S
{
S(int) noexcept;
void f() noexcept(noexcept(S(42)));
friend void g() noexcept(noexcept(S(42)));
};
https://godbolt.org/z
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Testcase https://gcc.godbolt.org/z/n3zPPE7bq
const int test[]={1, 2, 3};
int main()
{
return test[3];
}
GCC doesn't warn under -O2 -Wall. It does e
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
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
GCC 14 implements P2280 (see #106650).
As a side effect of that, the "narrowing detector" used in std:
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Testcase from Qt: https://gcc.godbolt.org/z/6brn9Knra
class QBenchmarkIterationController
{
public:
QBenchmarkIterationController() noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477
Giuseppe D'Angelo changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Giuse
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
In debug mode there seems to be a difference between a value-initialized
iterator, and an iterator that gets assigned from a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail do
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 .
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hello,
This is the same report as bug 110375, however turned into a wishlist/feature
request for the C++ front-end
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
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
-ftrivial-auto-var-init=zero is documented to "Initialize automatic variables
with zeroes".
I assume that means t
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?
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hi,
Consider this testcase:
#include
using T = std::vector;
void f(T);
void use1(const T t) { f(std
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
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
propagate_const in the LFTSv3 has implicit conversion operators which have
constraints on them:
https
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Testcase:
template
struct Test {
template
operator T();
};
int main() {
Test t
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Testcase:
struct Test {
operator int *() const;
operator void *() const;
};
int main() {
Test t
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.
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hello,
If one tries to mix GCC's attribute syntax (__attribute__) and with C++11 / C23
([[attribute]]), GCC rejects the code (no matter what the order of the
attribut
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hi,
The available documentation for attributes syntax
https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hello,
This testcase (which gets accepted by Clang and MSVC) causes an ICE under
GCC-12-trunk, and an erroneous compilation error on GCC 11.2
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
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hello,
The following testcase has an "inconsistent" overload resolution:
templa
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Sorting/heaping/etc. an array/vector of unique_ptr generates worse codegen than
the equivalent code on an array of raw pointers. This is a missed
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
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hello,
This reduced testcase from Qt raises a -Wstring-overflow warning on GCC 11.1
when compiling under -O2 -g -Wall -Wextra
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
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hi,
When building the qtbase `dev` branch with GCC 11, a bunch of warnings are
generated even in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail do
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 do
1 - 100 of 107 matches
Mail list logo
