https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87952
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail dot com
---
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=edit
testcase
Hi,
I've tried to "carve" a subset of files that show the problem. Apologies for
not really being
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=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
>
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
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
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail dot com
---
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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99032
Bug ID: 99032
Summary: GCC accepts attributes on friend declarations (not
definitions)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail dot com
---
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,
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99625
Bug ID: 99625
Summary: GCC does not detect narrowing in aggregate
initialization
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
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
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 &
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:
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
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
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
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
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=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 =
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
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
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
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=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=112477
Giuseppe D'Angelo changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from
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:
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:
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
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
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=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=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=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=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 &&) =
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://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/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/
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338
Giuseppe D'Angelo changed:
What|Removed |Added
CC||dangelog at gmail dot com
---
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
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://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=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
>
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
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=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
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=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
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=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
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=112637
Bug ID: 112637
Summary: Bogus -Wmaybe-uninitialized warning
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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
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
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
65 matches
Mail list logo
