[Bug c++/91368] Implement P1301R4: [[nodiscard("with reason")]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91368 --- Comment #4 from JeanHeyd Meneide --- 🎉!!
[Bug testsuite/92165] [10 regression] g++.dg/cpp2a/nodiscard-once.C fails starting with r277205
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92165 --- Comment #3 from JeanHeyd Meneide --- Thanks for pinging me about this. I'm at a WG14 Meeting so I won't be able to get to it immediately, but when I get back I'll get right on fixing!
[Bug c++/93093] New: __builtin_source_location reports values for default arguments not aligned with the Standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093
Bug ID: 93093
Summary: __builtin_source_location reports values for default
arguments not aligned with the Standard
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: phdofthehouse at gmail dot com
Target Milestone: ---
Consider the following example from the C++ Standard N4842 (nice website
version: eel.is/c++draft/support.srcloc#cons-4):
===
struct s {
source_location member = source_location::current();
int other_member;
s(source_location loc = source_location::current())
: member(loc) // values of member refer to the location of the
calling function ([dcl.fct.default])
{}
s(int blather) :// values of member refer to this location
other_member(blather)
{}
s(double) // values of member refer to this location
{}
};
void f(source_location a = source_location::current()) {
source_location b = source_location::current(); // values in b refer to
this line
}
void g() {
f(); // f's first argument corresponds to this line of code
source_location c = source_location::current();
f(c); // f's first argument gets the same values as c, above
}
===
When source_location is implemented with __builtin_source_location, code like
the above does not report those locations. s{}.member does not refer to the
calling location, s(2.0).member does not refer to the constructor declaration
s, and s(1).member does not refer to that location, and so forth.
Some talking on IRC revealed that this might be because of constant evaluation
/ constant folding, changing how the source location attribute behaves in
instances like these. This also affects the patch at
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01579.html whose tests fail in
both static_assert and regular runtime VERIFYs.
[Bug c/12245] [8/9/10 regression] Uses lots of memory when compiling large initialized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245 JeanHeyd Meneide changed: What|Removed |Added CC||phdofthehouse at gmail dot com --- Comment #75 from JeanHeyd Meneide --- I would like to add to this post. I experience severe memory usage and compilation time consumption that ramps up heavily when dealing with binary data. I documented much of my struggles here: https://thephd.github.io/embed-the-details I am being told that the functionality I am developing is more suited for a bug report and that this should be compiler QoI. Upon attempting to file this bug, I decided to throw my own data and woes into the ring here. Is there a place I should start looking to help out with this? I would like to start getting closer to the theoretical near-perfect overhead of dealing with what essentially ends up being a large binary payload, without resorting to #embed or any special builtins.
[Bug c++/93093] __builtin_source_location reports values for default arguments not aligned with the Standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093 --- Comment #3 from JeanHeyd Meneide --- I guess we just throw out a handful of those test cases, then. It's not like the Standard is really impactful here, since most of Source Location's specification is "should...", which is encouragement and not requirement. Maybe this can be revisited later.
[Bug c++/93093] __builtin_source_location reports values for default arguments not aligned with the Standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093 --- Comment #4 from JeanHeyd Meneide --- I changed the library test cases, but maybe there needs to be something that helps the library developers tag a constant evaluation function as something that should be ran later / deferred. I don't have any good ideas, just spitballing. Either way, the new patch passes by not testing for some of the cases similar to what's in the Standard passage in [support.srcloc]: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00036.html
[Bug c++/93228] New: [[deprecated("message")]] on template struct/class drops message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93228
Bug ID: 93228
Summary: [[deprecated("message")]] on template struct/class
drops message
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: phdofthehouse at gmail dot com
Target Milestone: ---
Godbolt: https://godbolt.org/z/tBd8Ce
Inline minimal repro:
-
template
struct [[deprecated("foo")]] bar {};
struct [[deprecated("baz")]] baz {};
int main () {
bar b;
baz c;
}
--
Output:
--
: In function 'int main()':
:8:5: warning: 'template struct bar' is deprecated
[-Wdeprecated-declarations]
8 | bar b;
| ^~~
:2:30: note: declared here
2 | struct [[deprecated("foo")]] bar {};
| ^~~
:9:9: warning: 'baz' is deprecated: baz [-Wdeprecated-declarations]
9 | baz c;
| ^
:4:30: note: declared here
4 | struct [[deprecated("baz")]] baz {};
| ^~~
ASM generation compiler returned: 0
: In function 'int main()':
:8:5: warning: 'template struct bar' is deprecated
[-Wdeprecated-declarations]
8 | bar b;
| ^~~
:2:30: note: declared here
2 | struct [[deprecated("foo")]] bar {};
| ^~~
:9:9: warning: 'baz' is deprecated: baz [-Wdeprecated-declarations]
9 | baz c;
| ^
:4:30: note: declared here
4 | struct [[deprecated("baz")]] baz {};
| ^~~
--
Message is dropped. Probably just a corner case not considered.
[Bug c++/91368] Implement P1301R4: [[nodiscard("with reason")]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91368 JeanHeyd Meneide changed: What|Removed |Added CC||phdofthehouse at gmail dot com --- Comment #2 from JeanHeyd Meneide --- I'm the one who made the patch. I'd be happy to help field any questions or fix anything!
[Bug libstdc++/100057] There are no freestanding C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057 JeanHeyd Meneide changed: What|Removed |Added CC||phdofthehouse at gmail dot com --- Comment #5 from JeanHeyd Meneide --- Hey, so, I'm not much of a contributor anymore, but like. Are you sure you got everything passed to the compiler correctly? I was under the impression in order to turn of __STDC_HOSTED__, you need to pass -ffreestanding ? That defines __STDC_HOSTED__ to 0, which should make those definition checks choose the non-__STDC_HOSTED__ branches for the #if (as shown in this basic test: https://godbolt.org/z/7acoPT13M) https://gcc.gnu.org/onlinedocs/gcc/Standards.html#Standards
[Bug libstdc++/100057] There are no freestanding C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057 --- Comment #6 from JeanHeyd Meneide --- Oh, woops, my bad. This is for configuring and building GCC. I'm not sure which option turns on -ffreestanding for building the compiler itself! But it seems like that's missing, if __STDC_HOSTED__ is not 0.
[Bug c++/98576] std::source_location should return EBCDIC encoding strings under EBCDIC execution charset charsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98576 JeanHeyd Meneide changed: What|Removed |Added CC||phdofthehouse at gmail dot com --- Comment #4 from JeanHeyd Meneide --- https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560784.html A new version of GCC will include the execution charset and wide execution charset as a string option in the preprocessor that matches the iconv conversion name passed to the command line. I'm not sure what to do about the other stuff, though. 😅
