https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95245
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983
--- Comment #7 from Jonathan Wakely ---
(In reply to Lyberta from comment #0)
> #include
> #include
>
> struct Foo
> {
> Foo(const std::filesystem::path& p);
> };
>
> static_assert(std::copyable);
The problem is that copyable considers t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983
--- Comment #9 from Jonathan Wakely ---
Thanks, Tim. I'd forgotten about that issue and was about to reinvent the
resolution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95233
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983
Jonathan Wakely changed:
What|Removed |Added
CC||s_gccbugzilla at nedprod dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 93983, which changed state.
Bug 93983 Summary: std::filesystem::path is not concept-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93983
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95209
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-05-21
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95209
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> You didn't provide the requested information when creating a new bug report,
> please see https://gcc.gnu.org/bugs/
We're missing the output of 'gcc -v' but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95209
--- Comment #5 from Jonathan Wakely ---
(In reply to M Welinder from comment #4)
> Sorry about the missing "-v". It is indeed a x86_64-suse-linux system.
> (It's not internet facing or I'd go get the full output.)
>
> "Implementation defined",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282
--- Comment #6 from Jonathan Wakely ---
(In reply to Rustam Abdullaev from comment #5)
> (In reply to Jonathan Wakely from comment #3)
> > https://wg21.link/cwg727
> >
> > N.B. this is a C++17 feature that does not seem to have been approved as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282
--- Comment #7 from Jonathan Wakely ---
Compare to e.g.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1825 which says
"[Moved to DR at the November, 2016 meeting.]" That means it's a retroactive
fix for previous standards. That isn
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2020-05-23
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95286
--- Comment #6 from Jonathan Wakely ---
I don't think this is a bug, the result of uniform_real_distribution depends on
floating point arithmetic which depends on optimisations.
The output of the mt19937_64 engine is portable between different
i
]
|is not C++11 constexpr |__gnu_debug::__get_distance
|compliant |is not C++11 constexpr
||compliant
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Known to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95289
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95307
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-05-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90212
--- Comment #6 from Jonathan Wakely ---
Not important for me. I don't remember where the yesterday came from.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90212
--- Comment #7 from Jonathan Wakely ---
Oops, autocorrect.
s/yesterday/testcase/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95330
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-05-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95334
--- Comment #1 from Jonathan Wakely ---
My guess is that G++ folds the constants early and the overflow happens at
compile time, so is never seen by UBsan.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
--- Comment #2 from Jonathan Wakely ---
There's an implicit conversion from sentinel to sentinel, but that
would only happen if the operator== had been found, and since it's a hidden
friend it can't be found unless one of the operands is already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
--- Comment #3 from Jonathan Wakely ---
Adding this to transform_view::_Sentinel fixes it:
friend constexpr bool
operator==(const _Iterator& __x, const _Sentinel& __y)
requires (!_Const)
{ return _Sentinel
|--- |11.0
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159
--- Comment #6 from Jonathan Wakely ---
Hmm, my patch doesn't actually fix the bogus warning, it just makes it possible
to disable it. A front end wizard will need to fix the real bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242
--- Comment #2 from Jonathan Wakely ---
Another way to implement the __unspec constructor would be:
consteval __unspec(int __n) { if (__n != 0) throw __n; }
But I think I discussed this with Richard Smith in Prague and we realised there
was a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242
--- Comment #4 from Jonathan Wakely ---
It's consteval, the throw is there to make it not a constant expression and
give an error if anything except 0 is used. i.e. it can never throw, it either
compiles or it doesn't.
But I've remembered the pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242
--- Comment #6 from Jonathan Wakely ---
It was just a sketch to show the idea.
Obviously the real thing would need noexcept, but we have a regression test for
that. How to construct it is what's relevant here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #2 from Jonathan Wakely ---
Using
auto t = new(p) std::uint64_t;
std::memcpy(t, std::launder(storage), sizeof(storage));
return t;
also prevents GCC from propagating the dynamic type of p to t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95354
--- Comment #2 from Jonathan Wakely ---
Allowing the attribute on individual parameters might be nice though.
I hate the fact that for C++ member functions the first parameter is the
implicit 'this' pointer which always has to be non-null anyway
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #7 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360
--- Comment #2 from Jonathan Wakely ---
(In reply to Yibiao Yang from comment #0)
> As showed, Line 6 is hit first and then hit Line 7 with stepi.
> However, when using step, gdb is first hit Line 7 and then hit Line 6.
> This is an inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95354
--- Comment #4 from Jonathan Wakely ---
(In reply to Haoxin Tu from comment #3)
> I see. Are there any cases that can trigger the UB of nonnull-attribute? I
> doubt the usage of “-fsanitize=nonnull-attribute” in GCC...
Yes, just use the attribut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #4 from Jonathan Wakely ---
I don't know the answer, and I don't know why it's useful to try this anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95337
--- Comment #2 from Jonathan Wakely ---
The duplicate "dob" was probably fixed by r10-7159 for PR 67960.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #6 from Jonathan Wakely ---
(In reply to Andrew Downing from comment #5)
> Also, I'm not sure if operations that implicitly create
> objects in storage are allowed to do so if an object has already explicitly
> created in that storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.2
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
--- Comment #8 from Jonathan Wakely ---
Thanks Daniel, I'm just testing Casey's resolution, and extending it to
join_view, so I'll send another mail once that testing is complete.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94354
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95322
--- Comment #10 from Jonathan Wakely ---
Fixed on master so far, backport to follow soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95305
--- Comment #6 from Jonathan Wakely ---
Created attachment 48621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48621&action=edit
preprocessed source
Compile with -std=gnu++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95301
--- Comment #1 from Jonathan Wakely ---
95301.cc:1:24: error: 'int_fast64_t' does not name a type
1 | template< typename T = int_fast64_t, T zero = 0 >
|^~~~
95301.cc:14:10: error: explicit specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95301
--- Comment #2 from Jonathan Wakely ---
(In reply to Wouter van Ooijen from comment #0)
> This code emits an excessive amount of error messages, which seem to repeat.
It looks like it, but actually it's about a different template each time, each
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95301
--- Comment #3 from Jonathan Wakely ---
Reduced:
template
struct range {
int start;
int limit;
range():
start(1, limit(2) // missing ) after 1
{ }
};
template
struct _no_inline_box_init : T {};
Which gives:
95301.cc:10:10:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95305
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from Jonathan Wakel
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
GCC happily compiles this:
void f()
{
int i = 1;
const int c = 0;
__atomic_load(&i, &c, __ATOMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95282
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Target Milestone|---
gcc dot gnu.org |redi at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-05-27
--- Comment #1 from Jonathan Wakely ---
I'm testing a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95378
--- Comment #2 from Jonathan Wakely ---
Every __atomic_xxx built-in has the same problem. They'll all accept
cv-qualified types as output parameters.
This seems to fix it, but I'll finish testing it and submit it tomorrow:
--- a/gcc/c-family/c-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91304
--- Comment #7 from Jonathan Wakely ---
(In reply to fsmoke from comment #6)
> I am sorry..I am new in gcc bugzilla. But.. i have gcc 9.3 and this issue
> still takes a place.
Because it's fixed in GCC 10.1
||11.0
Keywords||build
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely ---
Oops, I meant to check it on mingw-w64 before pushing that commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95392
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95417
--- Comment #2 from Jonathan Wakely ---
GCC, Clang and EDG all destroy b before a.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
Jonathan Wakely changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94749
--- Comment #3 from Jonathan Wakely ---
I have a patch but was waiting until after the GCC 11 release.
I'll look into it next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95392
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|10.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95407
Jonathan Wakely changed:
What|Removed |Added
Summary|G++ allows access to base |[DR 1873] G++ allows access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |SUSPENDED
--- Comment #6 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95545
--- Comment #2 from Jonathan Wakely ---
(In reply to David Edelsohn from comment #0)
> which creates an ambiguity when a user references thread:: without
> std::thread.
Could you show an example of code that's ambiguous?
> Would libstdc++ consi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95545
--- Comment #5 from Jonathan Wakely ---
The problem is that 'using namespace std;' introduces an ambiguity. That is in
the user's code, there's nothing we can do in libstdc++ to avoid it.
We could add a different name for std::thread eg.
namesp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95545
--- Comment #6 from Jonathan Wakely ---
See
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-using
in the C++ Core Guidelines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95547
--- Comment #1 from Jonathan Wakely ---
(In reply to M Welinder from comment #0)
> This is with a fairly old compiler, but same behaviour observed with gcc10.
Old and unsupported, bugs should really be reported for current versions.
As you say,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95547
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95561
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86577
--- Comment #2 from Jonathan Wakely ---
Is this a dup of PR 51577 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596
--- Comment #3 from Jonathan Wakely ---
gcc/cp/typeck.c does:
if (cxx_dialect >= cxx11)
pedwarn (loc, OPT_Wwrite_strings,
"ISO C++ forbids converting a string constant to %qT",
totype);
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95610
Jonathan Wakely changed:
What|Removed |Added
Summary|GCC fails to get global |bogus error: "global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95609
--- Comment #1 from Jonathan Wakely ---
(In reply to Niall Douglas from comment #0)
> I would assume that the ABI ship has sailed, as usual
Nope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95606
--- Comment #1 from Jonathan Wakely ---
The testcase is:
#include
#include
template
class basic_json;
using json = basic_json;
class json_ref
{
public:
template ::value>
json_ref(T &&){}
};
template
class basic_json
{
public:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95606
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95606
--- Comment #3 from Jonathan Wakely ---
And probably one or both of the basic_json and json_ref constructors should be
explicit, so that you can't implicitly convert them both to each other.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95623
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95624
Jonathan Wakely changed:
What|Removed |Added
Blocks||86976
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95626
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92102
Jonathan Wakely changed:
What|Removed |Added
CC||godeffroy.valet at m4x dot org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10037
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95609
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95641
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95638
--- Comment #4 from Jonathan Wakely ---
I don't see anything obviously wrong with the code. Nothing seems to write to
the storage before the constructor, let alone rely on those writes being
preserved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94749
--- Comment #5 from Jonathan Wakely ---
Fixed in master. I'll keep the bug open as I will probably backport the fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95642
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90704
Jonathan Wakely changed:
What|Removed |Added
CC||manx-bugzilla@problemloesun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
--- Comment #20 from Jonathan Wakely ---
I'll ask the new LWG chair to bump the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95657
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #2 from Jonathan Wakely ---
(In reply to Richard Biener from comment #1)
> I suppose the C++ standard says static_cast(nullptr) == nullptr
> and
> we literally follow that. Note it will make a difference for very large
> objects (and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #3 from Jonathan Wakely ---
Or to be more clear:
struct Large {
char pad[1024*1024];
int x;
};
Large* p = 0;
int i = p->x;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87515
--- Comment #6 from Jonathan Wakely ---
(In reply to ipelupes from comment #4)
> also: adding __builtin_unreachable(); hides the warning making it even
> harder to find
Don't do that then :)
Adding that promises the compiler your program will n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #6 from Jonathan Wakely ---
Dereferencing in the null case is undefined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #7 from Jonathan Wakely ---
So yes, the static_cast should evaluate to zero, but if it's followed by a
dereference then it seems reasonable to expect -fdelete-null-pointer-checks to
optimize away the handling for zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95693
--- Comment #3 from Jonathan Wakely ---
(In reply to Martin Liška from comment #1)
> I'm not a C++ expert, but it seems to me an invalid code.
I don't see anything wrong with the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95493
--- Comment #8 from Jonathan Wakely ---
This also fixes a regression introduced by:
alias.c (ao_ref_from_mem): Move stack-slot sharing rewrite ...
2019-05-22 Richard Biener
* alias.c (ao_ref_from_mem): Move stack-slot sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
--- Comment #14 from Jonathan Wakely ---
*** Bug 94644 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94644
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90925
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> This is probably another dup of PR 41437
Apparently not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95700
--- Comment #2 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #1)
> I don't think it is a good idea to allow (uintptr_t) 0 as valid sentinel.
Definitely not. (uintptr_t)0 is not a null pointer constant, and is not a valid
defin
401 - 500 of 21748 matches
Mail list logo
