https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #5 from Jonathan Wakely ---
Yep, that fixes the testcases above, thanks. Retrying the libstdc++ tests ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92285
--- Comment #9 from Jonathan Wakely ---
Now documented too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94971
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97549
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
--- Comment #6 from Jonathan Wakely ---
(In reply to frankhb1989 from comment #1)
> To clarify a bit: is installed by the VC++ toolchain or WDK, not by
> Windows SDK. Nevertheless, it is a system header both MS's CRT and Win32
> headers rely on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67135
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994
Bug 59994 depends on bug 69775, which changed state.
Bug 69775 Summary: thread_local extern variable causes linkage error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69775
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69775
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77285
Jonathan Wakely changed:
What|Removed |Added
CC||saarraz2 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66360
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |RESOLVED
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994
Bug 59994 depends on bug 58366, which changed state.
Bug 58366 Summary: invocation of thread_local class containing bound function
leads to : "Illegal instruction: 4"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58366
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702
Jonathan Wakely changed:
What|Removed |Added
CC||tobias.bruell at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88292
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96817
--- Comment #21 from Jonathan Wakely ---
The abi_check failures are of course expected if you configure with an option
that alters the library ABI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96746
--- Comment #3 from Jonathan Wakely ---
The standard says "no diagnostic required". It's not a bug if a compiler
accepts the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95977
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96184
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88725
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618
Jonathan Wakely changed:
What|Removed |Added
CC||haining.cpp at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91618
--- Comment #7 from Jonathan Wakely ---
>From Bug 88725
gcc fails to deduce that the friend declaration refers to ::func in the
below
```
template
void func(T);
class Cls {
friend void ::func(int);
};
```
Rejecting with
```
error: 'voi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97716
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97719
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-11-04
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97719
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=97719
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
--- Comment #10 from Jonathan Wakely ---
r11-4269 and r11-4270 made a bit difference on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> r11-4269 and r11-4270 made a bit difference on trunk.
s/bit/big/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97702
--- Comment #4 from Jonathan Wakely ---
N.B. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2593.htm proposes to
standardise typeof.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97728
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729
Jonathan Wakely changed:
What|Removed |Added
Keywords||build
Summary|Link failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729
--- Comment #3 from Jonathan Wakely ---
It could be a difference in the linker. I'm using the mingw cross-binutils that
comes with Fedora:
$ /usr/bin/x86_64-w64-mingw32-ld --version
GNU ld version 2.32-%{release}
Copyright (C) 2019 Free Software
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97731
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97731
--- Comment #1 from Jonathan Wakely ---
Looks like I fixed it for std::filesystem::recursive_directory_iterator but not
the experimental version:
if (ecptr ? sp->top().advance(*ecptr) : sp->top().advance())
_M_dirs.swap(sp);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729
--- Comment #5 from Jonathan Wakely ---
Yes sorry, I get the same error. I should have tested it first! Working patch
on the way ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
--- Comment #3 from Jonathan Wakely ---
I don't think this is a bug in std::optional, I think it's how C++20 works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67453
Jonathan Wakely changed:
What|Removed |Added
Blocks||97729
Last reconfirmed|2015-09-04 00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
--- Comment #7 from Jonathan Wakely ---
(In reply to sshannin from comment #6)
> I guess to rephrase, should there also be a specialized spaceship overload
> for the (nullopt_t, optional) direction to complement the (optional,
> nullopt) one?
No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-11-05
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.3
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97731
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729
Jonathan Wakely changed:
What|Removed |Added
Known to work|10.2.1 |
Target Milestone|11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|8.5 |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97729
--- Comment #10 from Jonathan Wakely ---
Great, thanks for the report and testing the fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96269
--- Comment #12 from Jonathan Wakely ---
Fixed by r10-8983 for gcc-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97758
Jonathan Wakely changed:
What|Removed |Added
Known to work||10.2.1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352
--- Comment #16 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #13)
> If we could get in touch with an actual lawyer to review which laws
> specifically are getting in the way here, that could be helpful. I won my
> election to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759
--- Comment #6 from Jonathan Wakely ---
As an aside, libstdc++ does already use the ((x-1) & x) == 0 idiom in
where we are happy for zero to be treated as a power
of two (because we call _Power_of_2(n+1) and we want the result to be true for
n==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96835
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97758
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111
--- Comment #12 from Jonathan Wakely ---
(In reply to Martin Sebor from comment #11)
> It detects the bug in the test case in comment #0 but only with optimization
> (to see through inlined calls) and with -Wsystem-headers.
This seems like a war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97731
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97740
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97740
--- Comment #1 from Jonathan Wakely ---
N.B. the "diagnostic" keyword is for poor quality diagnostics, not ones that
shouldn't happen at all. Code that shouldn't give an error at all should use
"rejects-valid" instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97759
--- Comment #12 from Jonathan Wakely ---
r11-4843 should have removed the small difference between the std and popcount
benchmarks.
I still see a small advantage to arithmetic for skylake i7-6700 CPU @ 3.40GHz
and i7-8650U CPU @ 1.90GHz though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-11-10
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
Jonathan Wakely changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #8 from Jonathan Wakely ---
(In reply to Janez Zemva from comment #6)
> try -std=c++20 ?
Which is why the instructions at https://gcc.gnu.org/bugs clearly say you need
to provide the options used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #7 from Jonathan Wakely ---
N.B. your program has undefined behaviour. Specializing std::hash for standard
library types is forbidden. GCC shouldn't crash though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #7)
> N.B. your program has undefined behaviour. Specializing std::hash for
> standard library types is forbidden. GCC shouldn't crash though.
Oh, you didn't! I mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #10 from Jonathan Wakely ---
Reduced:
using size_t = decltype(sizeof(0));
template struct remove_reference { using type = T; };
template struct remove_reference { using type = T; };
template struct remove_reference { using type = T;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #13 from Jonathan Wakely ---
I think it's just a dup of PR 82099.
Reduced further to only use C++14
template
struct hash
{
int operator()(T) const noexcept { return 0; }
};
template
int hash_combine(T v) noexcept(noexcept(hash(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82099
Jonathan Wakely changed:
What|Removed |Added
CC||janezz55 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97773
--- Comment #15 from Jonathan Wakely ---
(In reply to Martin Liška from comment #12)
> Started to ICE with -std=c++17 since r6-3372-g378b307d0d7e789c.
That's the commit that added C++17 fold expressions, but the ICE doesn't depend
on fold expres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85468
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97781
Bug ID: 97781
Summary: basic_stringbuf::swap is not exception safe
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97778
--- Comment #3 from Jonathan Wakely ---
Looks like a dup of PR 64194, checking ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194
Jonathan Wakely changed:
What|Removed |Added
CC||janezz55 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97778
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97785
Bug ID: 97785
Summary: const_cast shows diagnostic about Y*
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71219
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2016-05-26 00:00:00 |2020-11-10
--- Comment #4 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94057
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65943
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56842
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857
--- Comment #8 from Jonathan Wakely ---
Probably changed by one of the patches for PR 94749 or PR 96161, although I
still see two reads for the first example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42857
--- Comment #10 from Jonathan Wakely ---
Untested patch:
--- a/libstdc++-v3/src/c++98/compatibility.cc
+++ b/libstdc++-v3/src/c++98/compatibility.cc
@@ -88,7 +88,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
--- Comment #15 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #14)
> > --- a/libgcc/gthr-posix.h
> > +++ b/libgcc/gthr-posix.h
> > @@ -684,7 +684,12 @@ __gthread_equal (__gthread_t __t1, __gthread_t __t2)
> > static inline _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
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=96416
--- Comment #5 from Jonathan Wakely ---
But on third thoughts, I don't know how to implement this reliably.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|redi at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #8 from Jonathan Wakely ---
I suppose I could change the static_assert message to also suggest defining
your own specialization of std::pointer_traits, which is another way to make it
work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
--- Comment #6 from Jonathan Wakely ---
I think the reduction is not a fair representation of the original code.
Obviously shifting by -1 is not OK, but the code doesn't do that ... at least
not for most targets.
The problem is specific to msp43
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
Jonathan Wakely changed:
What|Removed |Added
Assignee|mpolacek at gcc dot gnu.org|redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
--- Comment #8 from Jonathan Wakely ---
My attempt to build msp430 fails with:
In file included from
/home/jwakely/gcc/msp430-elf/msp430-elf/include/stdint.h:13,
from /home/jwakely/src/gcc/build-16bit/gcc/include/stdint.h:9,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
--- Comment #11 from Jonathan Wakely ---
Fixed for gcc-11 but it should be backported too. Even if the compiler doesn't
reject the overflow in the constant expressions, the values of the trait are
still wrong for __int20.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048
--- Comment #7 from Jonathan Wakely ---
(In reply to Christian Fersch from comment #6)
> It seems like the solution would be to use codecvt_utf8 if wchar_t is 32bit
> and codecvt_utf8_utf16 if wchar_t is 16bit. This also seems to be what
> libc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048
--- Comment #8 from Jonathan Wakely ---
We do have a codecvt specialization that uses iconv, which would allow us to
convert from the native wide encoding to UTF-8, independent of the locale's
narrow encoding.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
--- Comment #13 from Jonathan Wakely ---
I tried a bootstrap of gcc-10 and I get this error during libgcc/configure
conftest.s: Assembler messages:
conftest.s:168: Error: unknown pseudo-op: `.mspabi_attribute'
conftest.s:169: Error: unknown pseu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97813
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-11-12
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96042
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97798
--- Comment #15 from Jonathan Wakely ---
Hmm, I get the same error for a out-of-tree binutils built from today's git
sources:
GNU assembler (GNU Binutils) 2.35.50.20201112
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
--- Comment #3 from Jonathan Wakely ---
I tried to implement this by adding a macro definition to c_cpp_builtins in
gcc/c-family/c-cppbuiltin.c but failed. I think we want to inspect the
'thread_model' global variable and see if it is "single", b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97814
--- Comment #2 from Jonathan Wakely ---
There is no copy in C++17, it is elided, so lock(S(1)) is equivalent to lock(1)
in C++17, and that constructor exists.
GCC is correct.
501 - 600 of 7031 matches
Mail list logo
