https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119822
--- Comment #3 from M Welinder ---
Thanks. Confirmed working.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119822
Bug ID: 119822
Summary: Linker failure with std::stacktrace
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87502
--- Comment #13 from M Welinder ---
> The reason why full destructor is inlined is that we do not know what
> foo is doing and it may make the string bigger. "const" does not promise
> that the callee does not modify the object.
:-(
> So I th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116473
Bug ID: 116473
Summary: std::ranges::to vs constexpr
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114309
--- Comment #11 from M Welinder ---
> Anyway, in GCC's testcase we have:
>
> 9 if (a == 123)
> 10 [[likely]] c = 5; // { dg-warning "both" }
> 11 else
> 12 [[likely]] b = 77;
> Here we have two possible paths, and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114309
--- Comment #1 from M Welinder ---
Created attachment 57672
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57672&action=edit
Preprocessed source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114309
Bug ID: 114309
Summary: Undesirable warning with [[unlikely]]
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113811
Bug ID: 113811
Summary: std::rotate does 64-bit signed division
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #48 from M Welinder ---
It's your (1). gcc is changing a program that can rely on errno not being
changed to one where the C library can change it. (The current C library or
any future library that the resulting binary may be dynami
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #46 from M Welinder ---
Should "-std=c99" imply turning off these optimizations?
Creating calls to, say, strlen is incompatible with the C99 standard and
perhaps better limited to "-std=gnu-something" or an opt-in f-flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112614
Bug ID: 112614
Summary: Compile-time float-to-_Decimal64 fails for -NAN
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903
--- Comment #11 from M Welinder ---
>/home/jwakely/gcc/14/include/c++/14.0.0/compare:160:5: note: declared here
> 160 | operator<=>(partial_ordering, __cmp_cat::__not_literal_zero auto)
> = delete;
> | ^~~~
I don't think we c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112569
Bug ID: 112569
Summary: libstdc++-v3/include/ranges:1456: missing check for
self-assignment
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102725
M Welinder changed:
What|Removed |Added
CC||terra at gnome dot org
--- Comment #10 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109909
Bug ID: 109909
Summary: vector: Writing 8 bytes into 1 allocated byte
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109536
Bug ID: 109536
Summary: Failure to compile constexpr std::vector with
-D_GLIBCXX_DEBUG
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109517
Bug ID: 109517
Summary: Failure to compile constexpr std::copy with
-D_GLIBCXX_DEBUG
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108108
--- Comment #4 from M Welinder ---
> Since it was not read again, the file is not considered included ...
It must have been read -- how else could gcc decide it was the same?
# strace -f gcc -MM c.c 2>&1 >Makefile | grep 'open.*\.h' | grep -v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108108
Bug ID: 108108
Summary: "gcc -MM" fails to list all dependencies
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566
--- Comment #5 from M Welinder ---
>From 108101:
Note also:
# gcc -MM c.c
c.o: c.c a.h
No b.h present!
I.e., Makefiles built with this will not pick up changes to the second file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108101
--- Comment #3 from M Welinder ---
Note also:
# gcc -MM c.c
c.o: c.c a.h
No b.h present!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108101
Bug ID: 108101
Summary: "#pragma once" causes other files not be included
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960
--- Comment #4 from M Welinder ---
And added to the link lines too, btw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960
M Welinder changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105960
Bug ID: 105960
Summary: Crash in 32-bit mode
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: una
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #9 from M Welinder ---
I went back and looked at the proposal's revision history.
TLDR: this just adds to the confusion.
r3 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r3.html):
* I read it as allowing "using enu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #7 from M Welinder ---
Maybe kick it up to the C++ people?
Note, that if the code is not allowed then a type alias is no longer as
powerful as the original type. I really doubt that was intended.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #6 from M Welinder ---
elaborated-enum-specifier can be a elaborated-type-specifier. It is in the
"enum Hog H;" case.
But elaborated-enum-specifier is NOT an elaborated-type-specifier in the "using
enum Hog;" case,
See http://eel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103084
--- Comment #3 from M Welinder ---
I actually think gcc is right there.
http://eel.is/c++draft/dcl.type.elab#nt:elaborated-enum-specifier
There are requirements for elaborated-type-specifier, but none for
elaborated-enum-specifier. It's a se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103087
Bug ID: 103087
Summary: "using enum" possibly incorrectly accepted
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081
--- Comment #4 from M Welinder ---
That version of clang does not do "using enum" at all. clang 13 accepts this
code, but it has other issues with "using enum".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081
Bug ID: 103081
Summary: [ICE] with "using enum"
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903
--- Comment #2 from M Welinder ---
IMHO, nullptr_t would not be an improvement here. We would still have the
combination of:
(1) Correct usage causing a warning
(2) The warning hinting at using the incorrect nullptr instead.
(3) po>>
bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903
Bug ID: 100903
Summary: Bogus "zero as null pointer constant" warning
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876
Bug ID: 99876
Summary: std::filesystem::absolute is inefficient
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc
35 matches
Mail list logo
