https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92856
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail do
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
CC: dangelog at gmail dot com, marc at kdab dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94590
--- Comment #2 from Giuseppe D'Angelo ---
A direct effect of this in SFINAE contexts seems to be the implementation of
P0608 (A sane variant converting constructor) that has landed in libstdc++ in
10.1.
This code:
struct S {
S(long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94590
--- Comment #8 from Giuseppe D'Angelo ---
Thank you!
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Testcase:
extern long double l;
struct S {
S(int) {}
};
S s[] = { l };
This is supposed to be ill-formed because of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail do
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
--- 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 #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=87952
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail do
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hi,
The following code is accepted by GCC 10.2:
struct S { [[deprecated]] friend void f(); };
No errors and no warnings are generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail do
: 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=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
--- 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 #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
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=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=100796
--- Comment #10 from Giuseppe D'Angelo ---
Thank you very much.
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=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 #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 #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=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=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 #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 #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=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=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=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 #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!
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=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
--- 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
: 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=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
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
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
: 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
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.
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=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
: 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
: 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
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
--- 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.
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=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=99625
--- Comment #5 from Giuseppe D'Angelo ---
No problem, thanks for working on GCC :)
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=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).
: 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
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=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
--- 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
Giuseppe D'Angelo changed:
What|Removed |Added
Attachment #58984|0 |1
is obsolete|
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
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
--- 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 #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; //
: 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=112477
Giuseppe D'Angelo changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Giuse
-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
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=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
--- 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
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 #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
--- 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=58338
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail do
: 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:
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=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=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"
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=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=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=103924
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail do
++
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
--- 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=85889
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail do
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
--- 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=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 #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=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
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=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=118542
--- Comment #2 from Giuseppe D'Angelo ---
Better testcase, I guess: https://gcc.godbolt.org/z/Yce4qEabM
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=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=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 #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
--- 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
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=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=119144
--- Comment #9 from Giuseppe D'Angelo ---
Erk, too slow. Thank you Jonathan.
1 - 100 of 107 matches
Mail list logo
