[Bug c++/59895] New: Updates to global variables not consistent across translation units when FLTO is enabled

2014-01-20 Thread adob321 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59895

Bug ID: 59895
   Summary: Updates to global variables not consistent across
translation units when FLTO is enabled
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adob321 at gmail dot com

Created attachment 31902
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31902&action=edit
PoC code

Modifications of global variables are sometimes not carried out properly when
FLTO is enabled. Short PoC follows.

// FILE bug-flto.cpp //
#include 
#include 

#include "shared.h"

std::vector globalvec;

S1::S1() {
printf("S1() called\n");
globalvec.push_back(42);
printf("S1() globalvec.size() = %d\n", (int) globalvec.size());
}

int main() {
printf("main globalvec.size() = %d\n", (int) globalvec.size());
return 0;
}

// FILE tu2.cpp
#include "shared.h"

S1 s1;

// FILE shared.h
#pragma once

struct S1 {
S1();
};

// FILE Makefile
run: bug-flto
./bug-flto

bug-flto: bug-flto.o tu2.o
g++-4.8 -O -flto -obug-flto bug-flto.o tu2.o

bug-flto.o: bug-flto.cpp
g++-4.8 -O -flto -obug-flto.o -c bug-flto.cpp

tu2.o: tu2.cpp
g++-4.8 -O -flto -otu2.o -c tu2.cpp

clean:
rm *.o
rm


[Bug c++/59895] Updates to global variables not consistent across translation units when FLTO is enabled

2014-01-20 Thread adob321 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59895

--- Comment #1 from Aleksandr Dobkin  ---
Output I get is:

S1() called
S1() globalvec.size() = 1
main globalvec.size() = 0

tested with g++-4.8 (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1


[Bug c++/59895] Updates to global variables not consistent across translation units when FLTO is enabled

2014-01-20 Thread adob321 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59895

--- Comment #4 from Aleksandr Dobkin  ---
(In reply to Andrew Pinski from comment #3)
> So in this case here, s1 is being initialized first and then globalvec gets
> initialized which changes the size back to 0.

Thanks for the explanation. I've verified this does appear to be the case.