[Bug lto/84044] Spurious -Wodr warning with -flto

[geoffrey at allott dot email]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044

--- Comment #2 from Geoffrey Allott  ---
Or even simply

A a;

[Bug lto/84044] Spurious -Wodr warning with -flto

[geoffrey at allott dot email]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044

--- Comment #1 from Geoffrey Allott  ---
I discovered that in b.cpp a free function

A get() {
return A();
}

also triggers the error. Struct B is not necessary.

[Bug lto/84044] New: Spurious -Wodr warning with -flto

[geoffrey at allott dot email]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84044

Bug ID: 84044
   Summary: Spurious -Wodr warning with -flto
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geoffrey at allott dot email
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

a.cpp
=

struct A {
virtual ~A();
};

A::~A() {}


b.cpp
=

struct A {
virtual ~A();
};

struct B {
A a;
A get();
};

A B::get() {
return a;
}


Makefile


main: a.cpp b.cpp
$(CXX) a.cpp -c -fno-semantic-interposition -fpic -flto
$(CXX) b.cpp -c -flto -O1
$(CXX) a.o b.o


This results in:

b.cpp:1:8: warning: virtual table of type ‘struct A’ violates one definition
rule   [-Wodr]
 struct A {
^
a.cpp:1:8: note: the conflicting type defined in another translation unit
 struct A {
^
a.cpp:5:1: note: virtual method ‘__base_dtor ’
 A::~A() {}
 ^
a.cpp:5:1: note: ought to match virtual method ‘__base_dtor ’ but does not



Note that even something as simple as inlining the definition of the destructor
or the `get` function cause the warning to go away. All of the flags are
necessary to reproduce the error.

[Bug tree-optimization/81834] loop with increment conditional on IV is not optimized out

[geoffrey at allott dot email]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81834

--- Comment #2 from Geoffrey Allott  ---
Hi Richard, I agree that this seems quite 'arcane' at first glance; I should
explain that I found it when an empty for loop failed to optimize out in rust -
the reduced test case failed to optimize in clang and also gcc, so I posted it
here. My thought is that this kind of pattern might be more common than it
seems at first glance, after other code has been reduced.
null

[Bug tree-optimization/81834] New: Simple loop with single variable is not optimized out

[geoffrey at allott dot email]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81834

Bug ID: 81834
   Summary: Simple loop with single variable is not optimized out
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geoffrey at allott dot email
  Target Milestone: ---

The following code:

int main() {
for(int i=0; i += i < 1000, i < 1000;);
}

optimizes on x86_64 to the following code:

main:
.LFB0:
xorl%eax, %eax
.L2:
xorl%edx, %edx
cmpl$999, %eax
setle   %dl
addl%edx, %eax
cmpl$999, %eax
jle .L2
xorl%eax, %eax
ret

I would expect the loop to be removed completely.