[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #12 from Oliver Rosten --- Yes, I am aware that I homebrewed gcc. What I don't understand is the extent to which this a homebrew problem and not a gcc problem. Forgive my ignorance but I would like to understand what submitting this issue to homebrew implies/achieves. I simply don't have much awareness of the broader context. On Sat, 15 Apr 2023 at 22:51, pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 > > --- Comment #11 from Andrew Pinski --- > (In reply to Oliver Rosten from comment #10) > > Can do, but I don't have sufficient understanding to understand why! Can > you > > kindly explain? > > Because that is where you got the GCC you are using from. It is listed in > the > configure line: > "--with-bugurl=https://github.com/Homebrew/homebrew-core/issues; > > -- > You are receiving this mail because: > You reported the bug.
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #10 from Oliver Rosten --- Can do, but I don't have sufficient understanding to understand why! Can you kindly explain?
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #8 from Oliver Rosten --- Created attachment 54870 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54870=edit Output from gcc -v
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #6 from Oliver Rosten --- I've added a simple makefile to the project: https://github.com/ojrosten/SourceLoc
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #3 from Oliver Rosten --- Created attachment 54852 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54852=edit Preprocessed file for Test.cpp
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #2 from Oliver Rosten --- Created attachment 54851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54851=edit Preprocessed file
[Bug c++/109494] New: inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494
Bug ID: 109494
Summary: inline const variables interfere with source_location
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oliver.rosten at googlemail dot com
Target Milestone: ---
The bug, (for which I'm not sure if it is a front end problem or a library
problem), is reproduced here: https://github.com/ojrosten/SourceLoc
The project comprises three files in the Test directory:
Main.cpp
Test.cpp
Test.hpp
Both the cpps depend on the hpp. The latter contains an unused variable
inline const std::string foo{};
The presence of this seems to cause:
1. The appearance of a warning: "ld: warning: direct access in function ...
from file ... to global weak symbol ... from file ... means the weak symbol
cannot be overridden at runtime..."
2. std::source_location::current() to misbehave: building and running causes
the path to Main.cpp to be output twice, whereas it should just be printed
once, with the path to Test.cpp appearing second.
Any of the following cures both of the problems:
1. Removing foo;
2. Removing inline;
3. Replacing const with constexpr
In the much more complex project where I first encountered this, I reliably got
a segmentation fault. I was able to cure this by removing inline in a handful
of places.
[Bug other/89856] `ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime` using LTO with optimization and -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856 --- Comment #6 from Oliver Rosten --- If you're sure. The only thing which gives me pause for thought is that the problem I see with source_location only occurs when I also see ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime This is the only time I've ever come across this in my code...
[Bug other/89856] `ld: warning: direct access to global weak symbol means the weak symbol cannot be overridden at runtime` using LTO with optimization and -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89856
Oliver Rosten changed:
What|Removed |Added
CC||oliver.rosten at googlemail
dot co
||m
--- Comment #4 from Oliver Rosten ---
I think I've come across a case where this is symptomatic of a serious problem
-see https://github.com/ojrosten/SourceLoc
The project comprises three files in the Test directory:
Main.cpp
Test.cpp
Test.hpp
Both the cpps depend on the hpp. The latter contains an unused variable
inline const std::string foo{};
The presence of this seems to cause:
1. The ld warning related to this bug report;
2. std::source_location::current() to misbehave: building and running causes
the path to Main.cpp to be output twice, whereas it should just be printed
once, with the path to Test.cpp appearing second.
Any of the following cures both of the problems:
1. Removing foo;
2. Removing inline;
3. Replacing const with constexpr
In the much more complex project where I first encountered this, I reliably got
a segmentation fault. I was able to cure this by removing inline in a handful
of places.
[Bug c++/108974] New: std::barrier except completion function which is not manifestly noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
Bug ID: 108974
Summary: std::barrier except completion function which is not
manifestly noexcept
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oliver.rosten at googlemail dot com
Target Milestone: ---
std::barrier> b{1, [](){}};
is accepted by gcc (and clang).
However, it fails on MSVC - as I think it should - since std::function's call
operator isn't manifestly noexcept.
https://godbolt.org/z/7vfoa1qhn
[Bug c++/96848] Inherited conditionally explicit constructors via using declaration do not enforce explicitness if dependent on template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96848 Oliver Rosten changed: What|Removed |Added CC||oliver.rosten at googlemail dot co ||m --- Comment #3 from Oliver Rosten --- I just came across an issue which I think has the same underlying cause: https://godbolt.org/z/Ph8xbeM7s
[Bug c++/104575] New: noexcept operator rejects call to templated base class member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104575
Bug ID: 104575
Summary: noexcept operator rejects call to templated base class
member function
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oliver.rosten at googlemail dot com
Target Milestone: ---
struct Y
{
void swap(Y& rhs) noexcept {}
};
template
struct D : B
{
void swap(D& rhs) noexcept (noexcept(B::swap(rhs))) {}
};
struct E : Y
{
void swap(E& rhs) noexcept (noexcept(Y::swap(rhs))) {}
};
void foo()
{
D x{}, y{};
x.swap(y); // Rejected
E u{}, v{};
u.swap(v); // OK
}
---
error: cannot call member function 'void Y::swap(Y&)' without object
https://godbolt.org/z/E3P9MEd6z
[Bug c++/104411] New: Cannot capture by reference using braced initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104411
Bug ID: 104411
Summary: Cannot capture by reference using braced initializer
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oliver.rosten at googlemail dot com
Target Milestone: ---
int bar{};
auto f = [b{bar}](){}; // fine
auto g = [=bar](){}; // fine
auto h = [{bar}](){}; // error
https://godbolt.org/z/aqMb8K9Tv
[Bug c++/104410] New: Internal error using default-initialized constexpr bool in requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104410
Bug ID: 104410
Summary: Internal error using default-initialized constexpr
bool in requires clause
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oliver.rosten at googlemail dot com
Target Milestone: ---
#include
template
constexpr bool use_func_v{};
// Using this instead is fine!
//template
//constexpr bool use_func_v{false};
struct func_obj
{
template
requires use_func_v
void operator()(T, T) const
{}
};
constexpr bool bar{std::is_invocable_v};
> internal error, see
https://godbolt.org/z/qsbPYq67a
