https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040
--- Comment #10 from Matt Whitlock ---
So using declarations are not a direct replacement for user-defined thunks.
Today I learned! This makes using declarations decidedly less useful than I
believed.
Thank you for your time, Jonathan Wakely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040
--- Comment #8 from Matt Whitlock ---
Maybe this example will demonstrate it more clearly.
/* begin example */
class PublicBase {
public:
void pub_base_pub_memb();
protected:
void pub_base_prot_memb();
};
class ProtectedBase {
oduct: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at mattwhitlock dot name
Target Milestone: ---
Host: x86_64-pc
RMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at mattwhitlock dot name
Target Milestone: ---
// BEGIN test.cpp
#include
int main() {
using std::filesystem::path;
path p1{ "
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at mattwhitlock dot name
Target Milestone: ---
/* BEGIN bug.cpp */
template
struct Base {
void func(int);
};
struct Derived : Base&l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89519
Matt Whitlock changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89519
--- Comment #3 from Matt Whitlock ---
(In reply to Andrew Pinski from comment #2)
> If there is a change, then using two sources one compiled with -std=c++98
> and one with -std=c++11 (or later) will not be ABI compatible.
ABI compatibility isn'
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at mattwhitlock dot name
Target Milestone: ---
/* === BEGIN TEST CASE === */
#include
class S {
int i;
};
struct P {
char c;
S s;
} __attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86008
--- Comment #2 from Matt Whitlock ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Matt Whitlock from comment #0)
> > The following shim allows the code above to compile, although it is
> > sub-optimal because it captures a std::b
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at mattwhitlock dot name
Target Milestone: ---
The following code should compile without error in C++17 mode:
/* BEGIN TEST CODE */
#include
#include
#include
#include
using namespace std::literals;
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58040
--- Comment #5 from Matt Whitlock ---
FYI, this is still a problem in G++ 5.3.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
--- Comment #17 from Matt Whitlock ---
(In reply to Segher Boessenkool from comment #16)
Thanks for the fix, Segher. Your patch seems more "right" than mine, although I
will point out that it doesn't precisely address this bug report, as it places
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
--- Comment #15 from Matt Whitlock ---
(In reply to Jakub Jelinek from comment #14)
> This doesn't really look like a good idea to me. Instead, perhaps ld's
> --gc-sections or new special option should just remove unused string
> literals from mer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
--- Comment #13 from Matt Whitlock ---
(In reply to H.J. Lu from comment #12)
> Would it better to use MD5 checksum on string contents?
MD5 would be slower for not much gain in uniqueness (assuming its output is
truncated to 32 bits). This applica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303
--- Comment #16 from Matt Whitlock ---
Here's a working solution:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192#c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
--- Comment #11 from Matt Whitlock ---
Created attachment 35479
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35479&action=edit
put string literals into unique sections when -fmerge-constants -fdata-sections
This patch puts each string lite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=192
--- Comment #10 from Matt Whitlock ---
(In reply to Rahul from comment #9)
> I am also experiencing the same issue. Is there any solution for it?
You can wrap a preprocessor macro around string literals that you want to
subject to the linker's gar
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at mattwhitlock dot name
$ cat < test.cpp
struct Base {
void foo() { }
void bar() { }
};
struct Derived : protected Base {
void foo() { this->Bas
18 matches
Mail list logo
