from:"matt at use dot net"

[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)

2013-02-05 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644



--- Comment #5 from Matt Hargett  2013-02-06 01:23:02 UTC 
---

the latest failure, with current trunk:



/work/mhargett/gcc-trunk-obj/./prev-gcc/xg++

-B/work/mhargett/gcc-trunk-obj/./prev-gcc/

-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++

-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include

-I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++

-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

  -g -O2 -O3 -march=nocona -mtune=core2 -floop-block -floop-interchange

-floop-strip-mine -flto=jobserver -frandom-seed=1 -DIN_GCC   -fno-exceptions

-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings

-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long

-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 

-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  gcc-ar.o -o gcc-ar \

file-find.o libcommon.a ../libcpp/libcpp.a  

../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a

../libdecnumber/libdecnumber.a  

In file included from ../../gcc-trunk/libbacktrace/mmapio.c:116:0,

 from :61:

../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add':

../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used

uninitialized in this function [-Werror=maybe-uninitialized]

   if (munmap (const_cast.v, view->len) < 0)

  ^

In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0,

 from :61:

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared

here

   struct backtrace_view ehdr_view;

 ^

In file included from ../../gcc-trunk/libbacktrace/mmapio.c:116:0,

 from :61:

../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.base' may be

used uninitialized in this function [-Werror=maybe-uninitialized]

   if (munmap (const_cast.v, view->len) < 0)

  ^

In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0,

 from :61:

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.base' was declared

here

   struct backtrace_view ehdr_view;

 ^

In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0,

 from :61:

../../gcc-trunk/libbacktrace/elf.c:516:10: error: 'ehdr_view.data' may be used

uninitialized in this function [-Werror=maybe-uninitialized]

   memcpy (&ehdr, ehdr_view.data, sizeof ehdr);

  ^

In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0,

 from :61:

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.data' was declared

here

   struct backtrace_view ehdr_view;

 ^

lto1: all warnings being treated as errors

make[4]: *** [/tmp/cc68SyuG.ltrans2.ltrans.o] Error 1

make[4]: *** Waiting for unfinished jobs

lto-wrapper: make returned 2 exit status

/u/mhargett/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed

collect2: error: ld returned 1 exit status

make[3]: *** [gcov-dump] Error 1

make[3]: *** Waiting for unfinished jobs

In file included from ../../gcc-trunk/libiberty/cp-demangle.c:877:0,

 from :73:

../../gcc-trunk/libbacktrace/elf.c: In function 'backtrace_initialize':

../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used

uninitialized in this function [-Werror=maybe-uninitialized]

   if (munmap (const_cast.v, view->len) < 0)

  ^

In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0,

 from :73:

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared

here

   struct backtrace_view ehdr_view;

 ^

In file included from ../../gcc-trunk/libiberty/cp-demangle.c:877:0,

 from :73:

../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.base' may be

used uninitialized in this function [-Werror=maybe-uninitialized]

   if (munmap (const_cast.v, view->len) < 0)

  ^

In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0,

 from :73:

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.base' was declared

here

   struct backtrace_view ehdr_view;

 ^

In file included from ../../gcc-trunk/libiberty/cp-demangle.c:879:0,

 from :73:

../../gcc-trunk/libbacktrace/elf.c:516:10: error: 'ehdr_view.data' may be used

uninitialized in this function [-Werror=maybe-uninitialized]

   memcpy

[Bug middle-end/56231] New: warning traces have bogus line information when using LTO

2013-02-06 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231



 Bug #: 56231

   Summary: warning traces have bogus line information when using

LTO

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: major

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: m...@use.net





>From bootstrapping GCC itself, one gets warnings that have bogus line entries,

like the ":61:" line below:

In file included from ../../gcc-trunk/libbacktrace/mmapio.c:116:0,

 from :61:

../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add':

../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used

uninitialized in this function [-Werror=maybe-uninitialized]





On large LTO compilation units, the final link can include some of these kinds

of warnings that contain literally hundreds of ":0:" and ":N:" entries per

warning.



To reproduce the above issue, bootstrap trunk like so:

../gcc-trunk/configure --program-suffix=-4.8 --enable-languages=c,c++,lto

--prefix=/u/mhargett --with-build-config=bootstrap-lto --enable-lto

--with-fpmath=sse --disable-isl-version-check --disable-libmudflap

--disable-libssp --enable-gold=yes --disable-multilib --disable-nls

BOOT_CFLAGS="-O3 -floop-block -floop-interchange -floop-strip-mine

-march=nocona =mtune=core2" CFLAGS_FOR_BUILD="-O3 -floop-block

-floop-strip-mine -floop-interchange -march=nocona -mtune=core2"

CXXFLAGS_FOR_BUILD="-O3 -floop-block -floop-interchange -floop-strip-mine

-march=nocona -mtune=core2"



make



more complete output from the bootstrap that illustrates this bug:

/work/mhargett/gcc-trunk-obj/./prev-gcc/xg++

-B/work/mhargett/gcc-trunk-obj/./prev-gcc/

-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++

-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include

-I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++

-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

  -g -O2 -O3 -march=nocona -mtune=core2 -floop-block -floop-interchange

-floop-strip-mine -flto=jobserver -frandom-seed=1 -DIN_GCC   -fno-exceptions

-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings

-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long

-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 

-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  gcov.o libcommon.a

../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a

../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -o gcov

/work/mhargett/gcc-trunk-obj/./prev-gcc/xg++

-B/work/mhargett/gcc-trunk-obj/./prev-gcc/

-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++

-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include

-I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++

-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

  -g -O2 -O3 -march=nocona -mtune=core2 -floop-block -floop-interchange

-floop-strip-mine -flto=jobserver -frandom-seed=1 -DIN_GCC   -fno-exceptions

-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings

-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long

-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 

-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  gcov-dump.o \

libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a

../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -o gcov-dump

In file included from ../../gcc-trunk/libbacktrace/mmapio.c:116:0,

 from :61:

../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add':

../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used

uninitialized in this function [-Werror=maybe-uninitialized]

   if (munmap (const_cast.v, view->len) < 0)

  ^

In file included from ../../gcc-trunk/libbacktrace/mmapio.c:119:0,

 from :61:

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared

here

   struct backtrace_view ehdr_view;

 ^

In file i

[Bug middle-end/55477] [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7

2013-02-10 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477



--- Comment #6 from Matt Hargett  2013-02-11 01:55:51 UTC 
---

I just tested with latest trunk (4.8.0 20130210). inline-devirt-2.C does indeed

pass when adding an outer loop, but only at -O3. That is probably fine, but I

could have sworn it used to work with the outer loop with just -O2.



inline-devirt-3.C has seemingly regressed further since my last test, for some

reason. I *have* to supply both -O3 *and* -funroll-loops now to see the correct

number of inlined printf statements in main():



#include 



class Calculable

{

public:

virtual unsigned char calculate() const = 0;

virtual ~Calculable() {}

};



class X : public Calculable

{

public:

virtual unsigned char calculate() const { return 0; }

};



class Y : public Calculable

{

public:

virtual unsigned char calculate() const { return 3; }

};



static void print(const Calculable& c)

{

for (int i = 0; i < c.calculate(); i++)

{

printf("%d\n", c.calculate());

}

}



int main()

{

X x;

Y y;



for (int i=3; i > 0; i--)

{

print(x);

print(y);

}



return 0;

}

[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4

2013-02-10 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478



--- Comment #9 from Matt Hargett  2013-02-11 02:02:46 UTC 
---

Just tested with latest trunk and it passes at -O3. With Maxim's previous

devirt patches, it passed at -O2. That being said, I'm happy and this can be

marked as RESOLVED.

[Bug middle-end/55498] [devirt] trunk fails inline-devirt test #6

2013-02-10 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498



--- Comment #3 from Matt Hargett  2013-02-11 02:11:36 UTC 
---

Just tested with latest trunk and things have regressed/changed a bit. This is

another test case where I *have* to use both -O3 and -funroll-loops to get the

desired effect. This didn't use to be the case. Also, even at -O3 the indirect

references to one() and two() are inlined, but the actual immediates returned

by those functions is not.



#include 



typedef unsigned char(*Calculable)(void);

typedef Calculable(*CalculateStrategy)(void);



unsigned char one() { return 1; }

Calculable oneStrategy() { return one; }

unsigned char two() { return 2; }

Calculable twoStrategy() { return two; }



static void print(CalculateStrategy calculateStrategy)

{

printf("%d\n", calculateStrategy()());

printf("+1: %d\n", calculateStrategy()() + 1);

}



int main()

{

for (int i = 3; i > 0; i--) {

print(oneStrategy);

print(twoStrategy);

}



return 0;

}

[Bug middle-end/56231] warning traces have bogus line information when using LTO

2013-02-11 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231



--- Comment #11 from Matt Hargett  2013-02-12 01:55:28 UTC 
---

can you add the reduced test case you came up with to the testsuite? I've seen

these issues come and go at various points.

[Bug middle-end/56231] warning traces have bogus line information when using LTO

2013-02-11 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56231



--- Comment #12 from Matt Hargett  2013-02-12 02:02:33 UTC 
---

looking at the patch for merging elsewhere, I noticed that



 location_t

 lto_input_location (struct bitpack_d *bp, struct data_in *data_in)

 {

+  static const char *current_file;

+  static int current_line;

+  static int current_col;

   bool file_change, line_change, column_change;

   unsigned len;

-  bool prev_file = data_in->current_file != NULL;

+  bool prev_file = current_file != NULL;





current_file is potentially of unknown value on the comparison in the last

line, right? or is there some static const initialization rule that implicitly

initializes it to 0?

[Bug c/44938] Variable origtypes in c-parser.c accessed uninitialized

2013-02-12 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44938



Matt Hargett  changed:



   What|Removed |Added



 CC||matt at use dot net



--- Comment #2 from Matt Hargett  2013-02-12 19:15:31 UTC 
---

also fails with current trunk with bootstrap-O3 and bootstrap-lto-O3.

[Bug middle-end/55496] False positive -Werror=uninitialized

2013-02-12 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55496



Matt Hargett  changed:



   What|Removed |Added



 CC||matt at use dot net



--- Comment #1 from Matt Hargett  2013-02-13 02:08:02 UTC 
---

Confirmed on current trunk, verified that it's not an issue in google/4_7

branch. Only happens with profiledbootstrap and bootstrap-lto. 



/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/./prev-gcc/xg++

-B/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/./prev-gcc/

-B/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/gcc-trunk-r195990/x86_64-unknown-linux-gnu/bin/

-nostdinc++

-B/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-B/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include

-I/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/libstdc++-v3/libsupc++

-L/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-L/var/lib/jenkins/jobs/gcc-trunk-lto-profiledbootstrap/workspace/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-c   -g -O2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC  

-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing

-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long

-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 

-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include

-I../../gcc/../libcpp/include  -I../../gcc/../libdecnumber

-I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace  

 ../../gcc/cfg.c -o cfg.o

../../gcc/cfg.c: In function

'scale_bbs_frequencies_gcov_type(basic_block_def**, int, long, long)':

../../gcc/cfg.c:943:8: error: 'e' may be used uninitialized in this function

[-Werror=maybe-uninitialized]

   edge e;

^

cc1plus: all warnings being treated as errors

make[3]: *** [cfg.o] Error 1

[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)

2013-02-14 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644



--- Comment #7 from Matt Hargett  2013-02-14 18:00:57 UTC 
---

Sorry, but wouldn't that be "papering over bugs"? I'm confounded by the

attitude around bootstrap failures, regardless of the basic supported options

being used: -O3 with LTO and profile-use. This combination has been in use in 3

different companies I have worked with, since 4.6.x. If it's not a supported

configuration to the point where an FSF GCC release can't bootstrap itself

consistently without wrong-code/diagnostic false positives, then I'll just plan

on sticking to vendor branches -- something I don't want to do since I would

prefer not to have another EGCS situation.



Let me know how to proceed with these classes of issues.

[Bug middle-end/55478] [devirt] trunk fails inline-devirt test #4

2013-02-14 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478



--- Comment #11 from Matt Hargett  2013-02-14 21:27:54 UTC 
---

Attached is an updated version of the tests Maxim committed to the google/4_7

branch. The only difference is that more of the tests are xfail'd than in the

older google branch.



We could unset the xfail for inline-devirt-4.C if we set it to -O3, but I'd

rather track the fact the test hasn't passed at -O2 since the patches Maxim

proposed ~2 years ago due to various (possibly nested) regressions in other

areas.

[Bug middle-end/55477] [devirt] trunk fails inline-devirt tests #2 and and #3 whereas they pass in google/4_7

2013-02-14 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477



--- Comment #7 from Matt Hargett  2013-02-14 21:28:33 UTC 
---

Created attachment 29455

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29455

diff against trunk adding new testcases

[Bug tree-optimization/55264] [4.6/4.7/4.8 Regression] ICE: in ipa_make_edge_direct_to_target, at ipa-prop.c:2141 with -O2 -fno-early-inlining -fno-weak

2013-02-19 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264



Matt Hargett  changed:



   What|Removed |Added



 CC||matt at use dot net



--- Comment #15 from Matt Hargett  2013-02-19 22:51:57 UTC 
---

Hey Martin,



I noticed that this doesn't apply cleanly to google/4_7 without some massaging.

The difference between trunk and google/4_7 might be worth pulling into trunk.

Unfortunately, the trail of merge commit log breadcrumbs leads to a dead end :/



>From a blame of google/main/gcc/ipa.c:



165972hubicka   || (before_inlining_p

195116davidxl   && DECL_VIRTUAL_P (node->symbol.decl)

195825davidxl   && cgraph_is_aux_decl_external (node



it's that last line that's unique to the google branches, and should probably

be merged to trunk.

[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)

2013-03-01 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644



--- Comment #10 from Matt Hargett  2013-03-01 23:11:50 UTC 
---

I'll file a new bug for each warning false positive that results in a bootstrap

failure. Feel free to close this one.

[Bug bootstrap/55644] maybe-uninitialized false positive

2013-03-01 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644



Matt Hargett  changed:



   What|Removed |Added



Summary|bootstrap-lto fails on  |maybe-uninitialized false

   |current trunk (with and |positive

   |without profiledbootstrap)  |



--- Comment #11 from Matt Hargett  2013-03-01 23:34:53 UTC 
---

The current false positives emitted:



mhargett@chert:/work/mhargett/gcc-trunk-lto-O3-debug/gcc$

/work/mhargett/gcc-trunk-lto-O3-debug/./prev-gcc/xg++

-B/work/mhargett/gcc-trunk-lto-O3-debug/./prev-gcc/

-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++

-B/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-B/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include

-I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++

-L/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-L/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

  -O3 -g -flto=jobserver -flto-partition=none -frandom-seed=1 -gtoggle -DIN_GCC

  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall

-Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic

-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common

 -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  gcov-dump.o

libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a

../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -o gcov-dump

../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add':

../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used

uninitialized in this function [-Werror=maybe-uninitialized]

   if (munmap (const_cast.v, view->len) < 0)

  ^

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared

here

   struct backtrace_view ehdr_view;

 ^

../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.base' may be

used uninitialized in this function [-Werror=maybe-uninitialized]

   if (munmap (const_cast.v, view->len) < 0)

  ^

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.base' was declared

here

   struct backtrace_view ehdr_view;

 ^

../../gcc-trunk/libbacktrace/elf.c:516:10: error: 'ehdr_view.data' may be used

uninitialized in this function [-Werror=maybe-uninitialized]

   memcpy (&ehdr, ehdr_view.data, sizeof ehdr);

  ^

../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.data' was declared

here

   struct backtrace_view ehdr_view;

 ^





which is a false positive, because



ehdr_view's fields are correctly initialized via a call from elf_add() to

backtrace_get_view()

  view->data = (char *) map + inpage;

  view->base = map;

  view->len = size;



if the mmap() earlier in the backtrace_get_view() didn't fail, view is

initialized and the backtrace_get_view() returns 1. if that mmap() fails, view

remains uninitialized and backtrace_get_view() returns 0.



elf_add()'s invocation checks the return value of backtrace_get_view(). in the

0 (failure) case, backtrace_release_view() is never invoked:

  if (!backtrace_get_view (state, descriptor, 0, sizeof ehdr, error_callback,

   data, &ehdr_view))

goto fail;



since backtrace_release_view() is never called in the case where the fields are

uninitialized, the warning is a false positive. while it occurs here with the

confluence of several optimizations, it looks like the same problem would

happen in a contrived single-file case.



attached are the temp files for the module the generated this false positive.

[Bug middle-end/55644] maybe-uninitialized false positive due to incorrect flow analysis when gotos are present

2013-03-01 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644



--- Comment #12 from Matt Hargett  2013-03-01 23:38:51 UTC 
---

Created attachment 29566

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29566

files generated during compilation where false positive happens with save-temps

[Bug middle-end/56526] New: [4.8 regression] false positive for maybe-uninitialized

2013-03-04 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526



 Bug #: 56526

   Summary: [4.8 regression] false positive for

maybe-uninitialized

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: m...@use.net





I haven't tracked down when this started happening, but it's a regression from

fsf/4.7 and google/4.7, as well as trunk from some months ago.



/work/mhargett/gcc-trunk-lto-O3/./prev-gcc/xg++

-B/work/mhargett/gcc-trunk-lto-O3/./prev-gcc/

-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++

-B/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-B/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include

-I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++

-L/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs

-L/work/mhargett/gcc-trunk-lto-O3/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

  -O3 -g -flto=jobserver -frandom-seed=1 -DIN_GCC   -fno-exceptions -fno-rtti

-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings

-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long

-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 

-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  gcc-nm.o -o gcc-nm \

file-find.o libcommon.a ../libcpp/libcpp.a  

../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a

../libdecnumber/libdecnumber.a

../../gcc-trunk/libiberty/simple-object-mach-o.c: In function

'simple_object_mach_o_find_sections':

../../gcc-trunk/libiberty/simple-object-mach-o.c:653:37: error:

'wrapper_sect_offset' may be used uninitialized in this function

[-Werror=maybe-uninitialized]

 secoffset = wrapper_sect_offset + subsect_offset;

 ^

lto1: all warnings being treated as errors

make[4]: *** [/tmp/ccGVpjK3.ltrans21.ltrans.o] Error 1

../../gcc-trunk/libiberty/simple-object-mach-o.c: In function

'simple_object_mach_o_find_sections':

../../gcc-trunk/libiberty/simple-object-mach-o.c:653:37: error:

'wrapper_sect_offset' may be used uninitialized in this function

[-Werror=maybe-uninitialized]

 secoffset = wrapper_sect_offset + subsect_offset;

 ^

lto1: all warnings being treated as errors

make[4]: *** [/tmp/ccGVpjK3.ltrans21.ltrans.o] Error 1

lto-wrapper: make returned 2 exit status

/u/mhargett/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed

collect2: error: ld returned 1 exit status

make[3]: *** [lto-wrapper] Error 1

make[3]: *** Waiting for unfinished jobs

mv -f Tcollect2 collect2

make[3]: Leaving directory `/work/mhargett/gcc-trunk-lto-O3/gcc'

make[2]: *** [all-stage2-gcc] Error 2



wrapper_sect_offset is initialized in the block predicated by

((gnu_sections_found & SOMO_WRAPPING) != 0), and is only accessed in a block

with the same (outer) predicate.



reproduced with bootstrap-lto on current trunk with -O3. save-temp outputs are

attached.

[Bug middle-end/56526] [4.8 regression] false positive for maybe-uninitialized

2013-03-04 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526



--- Comment #1 from Matt Hargett  2013-03-04 19:04:58 UTC 
---

Created attachment 29580

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29580

save-temps output from same commandline/path

[Bug middle-end/56526] [4.8 regression] false positive for maybe-uninitialized

2013-03-05 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56526



--- Comment #4 from Matt Hargett  2013-03-06 02:06:03 UTC 
---

It does fix that warning, but there's a bug in the analysis that makes it a

false positive. I've had difficulty reducing it to a self-contained example,

and I don't have the expertise to do more in-depth debugging.



This should stay open until the analysis is done to show that it's an accepted

limitation of the warning's capabilities, IMO.

[Bug middle-end/51233] [ipa-iterations] running multiple passes of early IPA on zlib produces more optimal code

2012-08-13 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233

--- Comment #2 from Matt Hargett  2012-08-14 00:26:35 UTC 
---
Okay. I filed this bug at your request last year because of your concerns that
some of the improvements seen with multiple iterations might be "papering over"
existing bugs in the optimizers. Does this mean that in this zlib case the
passes are all fine, but multiple iterations legitimately helps?

The original discussion was in the context of Maxim's devirt patches. Would the
approach you mention still allow for the testcases from his proposed patches to
pass? (We can discuss this second question on-list, if you like.)

Thanks for reviving this; we saw dramatic performance improvements with the
4.6-based deliverable we got from Maxim.

[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark

2012-08-14 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533

--- Comment #19 from Matt Hargett  2012-08-14 17:25:40 UTC 
---
Does this mean there will be a fix for this regression committed for 4.7.2? If
there's a patch I can test ahead of time, please let me know. Thanks!

[Bug middle-end/51233] [ipa-iterations] running multiple passes of early IPA on zlib produces more optimal code

2012-08-14 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233

--- Comment #4 from Matt Hargett  2012-08-14 17:43:30 UTC 
---
I agree it's more appropriate in LTO, but can still provide measurable benefit
for template-heavy C++ applications where lots of implementation bodies are in
header files by necessity.

With regard to zlib performance improving with multiple iterations, is there a
multiple iterations patch against trunk you'd like me to retest on this
specific testcase? We never did an RTL/tree dump in the 4.6/4.7 case for each
iteration to see if the improvements could have been caught in a single
iteration.

[Bug libstdc++/54307] New: [4.7 regression] increases in memory usage by some C++11 (and C++03) standard containers

2012-08-17 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54307

 Bug #: 54307
   Summary: [4.7 regression] increases in memory usage by some
C++11 (and C++03) standard containers
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


Between 4.6 and 4.7.x, the memory used by a few standard containers has
increased, resulting in some OOM and performance issues on an amd64 application
I work on.

4.7:
list size = 24
unordered_map size = 64
unordered_set size = 64

4.6:
list size = 16
unordered_map size = 56
unordered_set size = 56

comparing to VC11:
list size   = 16
unordered_map size = 64
unordered_set size = 64

compile commandline is just -std=c++0x. testcase program below:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std;

int main(void)
{
vector v; printf("vector size\t = %d\n", sizeof(v));
array a; printf("array size\t = %d\n", sizeof(a));
deque d; printf("deque size\t = %d\n", sizeof(d));
forward_list f; printf("forward_list size\t = %d\n", sizeof(f));
list l; printf("list size\t = %d\n", sizeof(l));
queue q; printf("queue size\t = %d\n", sizeof(q));
stack s; printf("stack size\t = %d\n", sizeof(s));
tuple t; printf("tuple size\t = %d\n",
sizeof(t));
map m; printf("map size\t = %d\n", sizeof(m));
set set; printf("set size\t = %d\n", sizeof(set));
unordered_map um; printf("unordered_map size\t = %d\n",
sizeof(um));
unordered_set us; printf("unordered_set size\t = %d\n",
sizeof(us));
string str; printf("string size\t = %d\n", sizeof(string));
return 0;
}

[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark

2012-08-20 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533

--- Comment #20 from Matt Hargett  2012-08-20 23:52:31 UTC 
---
Some additional information:
Compared to LLVM 3.1 with -O3, GCC 4.7 is twice as slow on these benchmarks.
LLVM even outperforms GCC 4.1, which previously had the best result. We are
very eager to hear about any resolution for this major regression in 4.7 so we
can deploy it. Even a return to GCC 4.1 performance levels would be fine.

Thanks!

[Bug libstdc++/54307] [4.7 regression] increases in memory usage by some C++11 (and C++03) standard containers

2012-08-21 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54307

--- Comment #3 from Matt Hargett  2012-08-21 17:26:55 UTC 
---
Paolo, what about list? Does VC11 achieve the size GCC 4.6 has by not
being compliant somehow?

[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now

2012-08-21 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676

--- Comment #12 from Matt Hargett  2012-08-21 21:40:11 UTC 
---
I've been doing research into LLVM 3.1 and other GCC versions. LLVM 3.1
correctly eliminate the (near) empty loop, and their current trunk does not
regress like 4.7 has.

Is the trunk patch coupled to other changes that are too invasive for 4.7? I'm
confused and curious about what optimization regressions are serious enough to
warrant a back port, if any.

[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now

2012-08-23 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676

--- Comment #16 from Matt Hargett  2012-08-23 18:01:08 UTC 
---
Back/forward-porting of the "trivial" restoration of the old behavior is
acceptable to me, as it would remove a major barrier to our adoption of 4.7.x.
That being said, if there's multi-platform testing I can do with a 'better' fix
based on trunk, I have SPARC and ARM qemu environments set up to regression
test on.

BTW, I realized that my initial analysis was wrong -- the int32_t and uint32_t
benchmarks are unaffected by this regression.

Let me know if there's an easy way to apply the restoration patch and I'll test
it locally on our amdfam10 and bdver2 hardware. If the testcase committed to
trunk would be applicable to a 4.7 fix as well, I can make a patch to integrate
that to ensure thie functionality doesn't regress again in future 4.7.x point
releases. I'm happy to do as much footwork as my expertise allows, just let me
know :)

Thanks!

[Bug lto/53572] Some public symbols don't get to serialized LTO

2012-09-04 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53572

Matt Hargett  changed:

   What|Removed |Added

 CC||matt at use dot net

--- Comment #11 from Matt Hargett  2012-09-04 23:48:40 UTC 
---
Applying this patch to my 4.7 branch checkout fixes my problem, which had the
same symptoms. Can someone please commit this to the 4.7 branch?

===
--- ../google-gcc-4_7/gcc/cgraph.h(revision 190939)
+++ ../google-gcc-4_7/gcc/cgraph.h(working copy)
@@ -1004,10 +1004,16 @@
 static inline bool
 varpool_can_remove_if_no_refs (struct varpool_node *node)
 {
-  return (!node->force_output && !node->used_from_other_partition
+  if (DECL_EXTERNAL (node->decl))
+ return true;
+ 
+   return (!node->force_output && !node->used_from_other_partition
   && (flag_toplevel_reorder || DECL_COMDAT (node->decl)
   || DECL_ARTIFICIAL (node->decl))
-&& (DECL_COMDAT (node->decl) || !node->externally_visible));
+&& ((DECL_COMDAT (node->decl) 
+&& !varpool_used_from_object_file_p (node))
+  || !node->externally_visible
+  || DECL_HAS_VALUE_EXPR_P (node->decl)));
 }

[Bug lto/53780] [l4.7.1 lto] linker fails with lto and "standard" object file

2012-10-11 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53780



Matt Hargett  changed:



   What|Removed |Added



 CC||matt at use dot net



--- Comment #11 from Matt Hargett  2012-10-11 19:10:00 UTC 
---

I am also seeing the message:

boost::exception_detail::clone_impl

 warning: relocation refers to discarded section



in my final link of a large C++ program compiled with LTO (with boost not

compiled as LTO). I tried compiling boost with LTO to work around the problem,

but got an ICE instead (will file that later).



Do the patches mentioned below (still) fix the problem in 4.7.x?

[Bug bootstrap/55074] New: error during bootstrap of trunk

2012-10-25 Thread matt at use dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55074

 Bug #: 55074
   Summary: error during bootstrap of trunk
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


On the same machine and same environment where I bootstrap 4.6, 4.7,
google-4.6, and google-4.7, I have not been able to bootstrap trunk as r192821.
It may be worth noting that I see similar errors when I attempt a
profiledbootstrap with google/4_7, but not with any FSF branch or google/4_6.

My configure line:
../gcc-trunk/configure --program-suffix=-4.8 --prefix=/u/mhargett --enable-lto 
--with-fpmath=sse --disable-libmudflap --disable-libssp --enable-gold=yes
--with-mpc=/u/mhargett --with-cloog=/u/mhargett/ --with-ppl=/u/mhargett/
--with-gmp=/u/mhargett/ --with-isl=/u/mhargett --with-mpfr=/u/mhargett/
--enable-cloog-backend=isl CC=gcc-4.7 CXX=g++-4.7 --enable-languages=c,c++,lto

Always results in this error, even without bootstrap-lto, and without
profiledbootstrap just "make -j8":

/work/mhargett/gcc-trunk-obj/./prev-gcc/g++
-B/work/mhargett/gcc-trunk-obj/./prev-gcc/
-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++
-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -fprofile-use -DIN_GCC   -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/.
-I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include
-I/u/mhargett//include -I/u/mhargett//include -I/u/mhargett/include 
-I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid
-I../libdecnumber -I../../gcc-trunk/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/u/mhargett//include -I/u/mhargett/include  ../../gcc-trunk/gcc/cfgrtl.c -o
cfgrtl.o
/work/mhargett/gcc-trunk-obj/./prev-gcc/g++
-B/work/mhargett/gcc-trunk-obj/./prev-gcc/
-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++
-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -fprofile-use -DIN_GCC   -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc-trunk/gcc -I../../gcc-trunk/gcc/.
-I../../gcc-trunk/gcc/../include -I../../gcc-trunk/gcc/../libcpp/include
-I/u/mhargett//include -I/u/mhargett//include -I/u/mhargett/include 
-I../../gcc-trunk/gcc/../libdecnumber -I../../gcc-trunk/gcc/../libdecnumber/bid
-I../libdecnumber -I../../gcc-trunk/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/u/mhargett//include -I/u/mhargett/include  ../../gcc-trunk/gcc/symtab.c -o
symtab.o
/work/mhargett/gcc-trunk-obj/./prev-gcc/g++
-B/work/mhargett/gcc-trunk-obj/./prev-gcc/
-B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++
-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/work/mhargett/gcc-trunk-obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-c   -g -O2 -fprofile-use -DIN_GCC   -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic

[Bug middle-end/55219] New: [4.7 regression] attempting to compile a pre-processed unit eats up memory until OOM kills the cc1 process

2012-11-05 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219



 Bug #: 55219

   Summary: [4.7 regression] attempting to compile a pre-processed

unit eats up memory until OOM kills the cc1 process

Classification: Unclassified

   Product: gcc

   Version: 4.7.3

Status: UNCONFIRMED

  Severity: critical

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: m...@use.net





Created attachment 28623

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28623

preprocessed source that exhibits the OOM



With the attached pre-preprocessed source, every GCC since 4.6 eats up memory

until killed. This is reproducible at -O[0-3]. It gets up to 10GB of RAM before

it gets killed. GCC 4.5 (from branch, bootstrapped on same machine with similar

configure line) has no such issues.

[Bug middle-end/55219] [4.7 regression] attempting to compile a pre-processed unit eats up memory until OOM kills the cc1 process

2012-11-05 Thread matt at use dot net



http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55219



--- Comment #1 from Matt Hargett  2012-11-06 01:31:22 UTC 
---

Perhaps worth noting that gcc/trunk and google/4_7 also still exhibit the

problem.

[Bug c++/46890] compile regression from 4.5 when building scummvm's player_v4a.cpp

2010-12-16 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46890

--- Comment #2 from Matt Hargett  2010-12-17 00:38:14 UTC 
---
Created attachment 22789
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22789
pre-processed source of the file that triggers the compilation regression

generated with this commandline using scummvm trunk sources:
/usr/lib/gcc-snapshot/bin/g++ -MMD -MF "engines/scumm/.deps/player_v4a.d" -MQ
"engines/scumm/player_v4a.o" -MP -Wall -O3 -flto  -g  -ansi -W
-Wno-unused-parameter -Wno-empty-body -pedantic -Wno-long-long -Wno-multichar
-Wno-unknown-pragmas -Wno-reorder -Wpointer-arith -Wcast-qual -Wshadow
-Wimplicit -Wnon-virtual-dtor -Wwrite-strings -fno-rtti -fno-exceptions
-fcheck-new -DSCUMMVM_SVN_REVISION=\"54939\" -DHAVE_CONFIG_H -DUNIX
-DDATA_PATH=\"/usr/local/share/scummvm\"
-DPLUGIN_DIRECTORY=\"/usr/local/lib/scummvm\" -DSDL_BACKEND
-DENABLE_SCUMM=STATIC_PLUGIN -DENABLE_SCUMM_7_8 -DENABLE_HE
-DENABLE_AGI=STATIC_PLUGIN -DENABLE_AGOS=STATIC_PLUGIN -DENABLE_AGOS2
-DENABLE_CINE=STATIC_PLUGIN -DENABLE_CRUISE=STATIC_PLUGIN
-DENABLE_DRACI=STATIC_PLUGIN -DENABLE_DRASCULA=STATIC_PLUGIN
-DENABLE_GOB=STATIC_PLUGIN -DENABLE_GROOVIE=STATIC_PLUGIN -DENABLE_GROOVIE2
-DENABLE_HUGO=STATIC_PLUGIN -DENABLE_KYRA=STATIC_PLUGIN -DENABLE_LOL
-DENABLE_LASTEXPRESS=STATIC_PLUGIN -DENABLE_LURE=STATIC_PLUGIN
-DENABLE_M4=STATIC_PLUGIN -DENABLE_MADE=STATIC_PLUGIN
-DENABLE_MOHAWK=STATIC_PLUGIN -DENABLE_PARALLACTION=STATIC_PLUGIN
-DENABLE_QUEEN=STATIC_PLUGIN -DENABLE_SAGA=STATIC_PLUGIN -DENABLE_IHNM
-DENABLE_SAGA2 -DENABLE_SCI=STATIC_PLUGIN -DENABLE_SCI32
-DENABLE_SKY=STATIC_PLUGIN -DENABLE_SWORD1=STATIC_PLUGIN
-DENABLE_SWORD2=STATIC_PLUGIN -DENABLE_SWORD25=STATIC_PLUGIN
-DENABLE_TESTBED=STATIC_PLUGIN -DENABLE_TEENAGENT=STATIC_PLUGIN
-DENABLE_TINSEL=STATIC_PLUGIN -DENABLE_TOON=STATIC_PLUGIN
-DENABLE_TOUCHE=STATIC_PLUGIN -DENABLE_TUCKER=STATIC_PLUGIN -I. -I. -I./engines
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -c engines/scumm/player_v4a.cpp
-E > player_v4a.i

[Bug c++/46890] compile regression from 4.5 when building scummvm's player_v4a.cpp

2010-12-16 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46890

--- Comment #3 from Matt Hargett  2010-12-17 00:39:27 UTC 
---
Created attachment 22790
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22790
original source file

[Bug c++/46890] compile regression from 4.5 when building scummvm's player_v4a.cpp

2010-12-16 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46890

--- Comment #4 from Matt Hargett  2010-12-17 00:40:55 UTC 
---
Attached original and pre-processed sources. Re-tested with 4.6.0 20101215,
problem is still happening.

[Bug middle-end/42371] dead code not eliminated during folding with whole-program

2011-01-11 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371

--- Comment #7 from Matt Hargett  2011-01-11 23:44:22 UTC 
---
Is the last remaining issue with this test case fixed by the patch for PR46076?

[Bug c++/46890] [4.6 Regression] Failed to compile scummvm's player_v4a.cpp

2011-01-27 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46890

--- Comment #8 from froydnj at codesourcery dot com  2011-01-26 15:06:09 UTC ---
Waiting on Jason to approve feedback-modified patch:

http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01667.html

--- Comment #9 from Matt Hargett  2011-01-27 20:11:26 UTC 
---
Still reproducible with this version:
g++ (Ubuntu/Linaro 20110126-0ubuntu1) 4.6.0 20110126 (experimental) [trunk
revision 169283]

[Bug bootstrap/57486] New: bootstrap fails on 4.8 and google/4.8 branch on RHEL6.1 platform

2013-05-31 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57486

Bug ID: 57486
   Summary: bootstrap fails on 4.8 and google/4.8 branch on
RHEL6.1 platform
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at use dot net

I'm getting this failure when trying to bootstrap on RHEL6.1, with either the
system compiler (gcc 4.4.x) or a 4.7-based compiler I bootstrapped successfully
before:

../configure --prefix=/u/mhargett --with-cloog=/usr/home/nfs-readonly/mhargett
--with-isl=/usr/home/nfs-readonly/mhargett
--with-gmp=/usr/home/nfs-readonly/mhargett
--with-mpfr=/usr/home/nfs-readonly/mhargett
--with-ppl=/usr/home/nfs-readonly/mhargett
--with-isl=/usr/home/nfs-readonly/mhargett/ --disable-isl-version-check
--with-build-config=bootstrap-lto  --enable-languages=c,c++,lto
--enable-gold=yes --enable-lto

/opt/gcc-google-4.7-v7/bin/g++-google-4.7 -c   -g -DIN_GCC   -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I.
-I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include -I/usr/home/nfs-readonly/mhargett/include
-I/usr/home/nfs-readonly/mhargett/include  -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace
-DCLOOG_INT_GMP -I/usr/home/nfs-readonly/mhargett/include
-I/usr/home/nfs-readonly/mhargett//include  ../../gcc/graphite-dependences.c -o
graphite-dependences.o
In file included from ../../gcc/dbgcnt.h:28:0,
 from ../../gcc/graphite.c:57:
../../gcc/dbgcnt.def:149:1: error: \u2018clone\u2019 redeclared as different
kind of symbol
In file included from /usr/include/sched.h:43:0,
 from /usr/include/pthread.h:25,
 from
/opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/x86_64-unknown-linux-gnu/bits/gthr-default.h:41,
 from
/opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/x86_64-unknown-linux-gnu/bits/gthr.h:150,
 from
/opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/ext/atomicity.h:34,
 from
/opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/bits/ios_base.h:41,
 from
/opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/ios:43,
 from
/opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/ostream:40,
 from
/opt/gcc-google-4.7-v7/lib/gcc/x86_64-unknown-linux-gnu/4.7.x-google/../../../../include/c++/4.7.x-google/iostream:40,
 from /usr/home/nfs-readonly/mhargett/include/isl/int.h:17,
 from /usr/home/nfs-readonly/mhargett/include/isl/ctx.h:16,
 from /usr/home/nfs-readonly/mhargett/include/isl/map_type.h:4,
 from /usr/home/nfs-readonly/mhargett/include/isl/set.h:13,
 from ../../gcc/graphite.c:38:
/usr/include/bits/sched.h:83:12: error: previous declaration of \u2018int
clone(int (*)(void*), void*, int, void*, ...)\u2019
make[3]: *** [graphite.o] Error 1
make[3]: *** Waiting for unfinished jobs


the problem is this line in dbgcnt.def:
DEBUG_COUNTER (clone)

unless there's a better suggestion, I'll attach a patch that renames the
counter to clone_function.

[Bug other/49284] -fdump-ipa-cgraph leads to ICE in generate_canonical_option, at opts-common.c:303

2011-08-18 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49284

Matt Hargett  changed:

   What|Removed |Added

 CC||matt at use dot net

--- Comment #7 from Matt Hargett  2011-08-18 18:28:04 UTC 
---
I get this when trying to compile scummvm with LTO and whole-program:

$ /usr/lib/gcc-snapshot/bin/g++ --version

g++ (Ubuntu/Linaro 20110813-1ubuntu1) 4.7.0 20110813 (experimental) [trunk
revision 177733]


$ CC=/usr/lib/gcc-snapshot/bin/gcc CXX=/usr/lib/gcc-snapshot/bin/g++
CFLAGS="-Ofast -flto" CXXFLAGS="-Ofast -flto" LDFLAGS="-flto -fwhole-program"
./configure

[...]

$ make -j9

[...]


RANLIB   base/libbase.a
LINK scummvm
lto1: internal compiler error: in generate_canonical_option, at
opts-common.c:303
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /usr/lib/gcc-snapshot/bin/g++ returned 1 exit status
/usr/bin/ld.bfd.real: lto-wrapper failed
collect2: error: ld returned 1 exit status


Removing -fwhole-program and changing the CXXFLAGS to -O1 doesn't change the
behaviour. I can attach a tarball if downloading the latest scummvm tarball is
too bothersome.

Note that I'm not using that dump-ipa-graph option at all.

[Bug lto/49844] Building CodeBlocks on Windows using mingw gcc 4.6.1 "-flto -fuse-linker-plugin" results in many linker stage errors

2011-08-18 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49844

Matt Hargett  changed:

   What|Removed |Added

 CC||matt at use dot net

--- Comment #4 from Matt Hargett  2011-08-18 19:01:29 UTC 
---
When building scummvm with gcc 4.6.1, I had a bunch of multiple definition
linker errors that also went away when adding -flto-partition=none . Here are
the errors I had before said workaround:

$ gcc --version
gcc-4.6.real (Ubuntu/Linaro 4.6.1-7ubuntu1) 4.6.1

$ CFLAGS="-Ofast -flto" CXXFLAGS="-Ofast -flto" LDFLAGS="-flto=8
-fuse-linker-plugin -fwhole-program" ./configure

[...]

$ make -j9

[...]

LINK scummvm
cup_player_he.o (symbol from plugin): warning: memset used with constant zero
length parameter; this could be due to transposed parameters
/tmp/ccMxgdJj.ltrans20.ltrans.o:(.rodata+0x1afa0): multiple definition of
`_ZTVN5Scumm9ScummFileE.local.7841'
/tmp/ccMxgdJj.ltrans0.ltrans.o:(.rodata+0xc320): first defined here
/tmp/ccMxgdJj.ltrans20.ltrans.o:(.rodata+0x1b080): multiple definition of
`_ZTTN5Scumm9ScummFileE.local.7842'
/tmp/ccMxgdJj.ltrans0.ltrans.o:(.rodata+0xc2a0): first defined here
/tmp/ccMxgdJj.ltrans20.ltrans.o:(.rodata+0x23780): multiple definition of
`_ZTVN6Common16MemoryReadStreamE.local.9080'
/tmp/ccMxgdJj.ltrans5.ltrans.o:(.rodata+0x6440): first defined here
/tmp/ccMxgdJj.ltrans20.ltrans.o:(.rodata+0x23840): multiple definition of
`_ZTTN6Common16MemoryReadStreamE.local.9093'
/tmp/ccMxgdJj.ltrans5.ltrans.o:(.rodata+0x6400): first defined here
collect2: ld returned 1 exit status
make: *** [scummvm] Error 1



Let me know if you want a tarball of this source tree attached; downloading the
latest scummvm source tarball should give the same results.

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

2011-08-30 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50182

Matt Hargett  changed:

   What|Removed |Added

 CC||matt at use dot net

--- Comment #12 from Matt Hargett  2011-08-30 20:30:15 UTC 
---
Can you determine which release introduced the regression?

[Bug middle-end/50397] New: openssl crash due to incorrect codegen when using LTO

2011-09-14 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50397

 Bug #: 50397
   Summary: openssl crash due to incorrect codegen when using LTO
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


When adding -flto and compiling openssl-1.0.0d with gcc-4.6.real (Ubuntu/Linaro
4.6.1-9ubuntu2) that comes with Ubuntu 11.10, the testsuite fails with a
segfault during the bignumber tests. 

To reproduce:
1. untar openssl-1.0.0d
2. make this change in the Configure file on the "debian-amd64" line:
"debian-amd64", "gcc:-m64 -DL_ENDIAN -DTERMIO -O2 -flto -floop-block
-floop-flatten -floop-interchange -floop-strip-mine -Wa,--noexecstack -g -Wall
-DMD32_REG_T=int::-D_REENTRANT::-Wl,-flto=2 -ldl
-Wl,-Bsymbolic-functions:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::",

3. make, which will run the tests and fail.
4. for extra grins, run the specific suite under valgrind:
matt@matt-desktop:~/openssl-1.0.0d/test$ valgrind -q --trace-children=yes
../util/shlib_wrap.sh ./bntest
[...]
==12136== Process terminating with default action of signal 8 (SIGFPE)
==12136==  Integer divide by zero at address 0x40359EA94
==12136==at 0x433C4D: BN_div (bn_div.c:342)
==12136==by 0x403B86: main (bntest.c:1951)
Floating point exception (core dumped)


PS: I filed this as 4.6.2, given the number of patches that Linaro has applied
to this 4.6.1 base version. If that's wrong, let me know.
I tried testing it on trunk, but that gets an ICE during compile (filing a
separate bug).

[Bug middle-end/50397] openssl crash due to incorrect codegen when using LTO

2011-09-14 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50397

--- Comment #1 from Matt Hargett  2011-09-15 00:37:43 UTC 
---
BTW, worth noting that this also happens with just -O1 as well.

[Bug middle-end/50398] New: ICE when compiling openssl-1.0.0d with graphite optimizations

2011-09-14 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50398

 Bug #: 50398
   Summary: ICE when compiling openssl-1.0.0d with graphite
optimizations
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


Created attachment 25276
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25276
pre-processed source of the file that triggers the ICE

During compile of openssl-1.0.0d using trunk r177733.

matt@matt-desktop:~/openssl-1.0.0d/engines/ccgost$
/usr/lib/gcc-snapshot/bin/gcc -I../../include -DZLIB -DOPENSSL_THREADS
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O2 
-floop-flatten -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM
-DWHIRLPOOL_ASM   -c gosthash.c
gosthash.c: In function 'hash_step':
gosthash.c:87:12: internal compiler error: in psct_dynamic_dim, at
graphite-poly.h:659

The crash goes away with "-O1 -floop-flatten", or if I remove -floop-flatten.
valgrind doesn't provide any output related to this issue.

Pre-processed source attached.

[Bug middle-end/50397] openssl crash due to incorrect codegen when using LTO

2011-09-16 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50397

--- Comment #2 from Matt Hargett  2011-09-16 22:00:25 UTC 
---
Verified this also happens on trunk with g++ (Ubuntu/Linaro 20110914-1) 4.7.0
20110914 (experimental) [trunk revision 178863]. Tried it with and without
lto-partition=none.


test BN_lshift1
test BN_lshift (fixed)
test BN_lshift
test BN_rshift1
test BN_rshift
Floating point exception (core dumped)

[Bug lto/50468] New: ICE in force_type_die when compiling binutils with -flto -O[12]

2011-09-20 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50468

 Bug #: 50468
   Summary: ICE in force_type_die when compiling binutils with
-flto -O[12]
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


Got this when building binutils-2.21.53.20110810 from source using g++-4.6.real
(Ubuntu/Linaro 4.6.1-9ubuntu3) or g++-4.7.0 20110914 on Ubuntu 11.10 amd64:

g++ -W -Wall-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=ld-new
-g -flto -O2  -Wl,-Bsymbolic-functions -o ld-new main.o i386.o x86_64.o sparc.o
powerpc.o arm.o arm-reloc-property.o libgold.a ../libiberty/libiberty.a   -ldl
-lz -lm
incremental.o (symbol from plugin): warning: memset used with constant zero
length parameter; this could be due to transposed parameters
In member function ‘__base_ctor ’:
lto1: internal compiler error: in force_type_die, at dwarf2out.c:21022



Interestingly, changing -O2 to -O1 introduces this variation:

incremental.o (symbol from plugin): warning: memset used with constant zero
length parameter; this could be due to transposed parameters
In file included from ../../gold/incremental.h:5152:0,
 from :4601:
../../gold/icf.h: In member function ‘__base_dtor ’:
../../gold/icf.h:62:5: internal compiler error: in force_type_die, at
dwarf2out.c:21022

[Bug lto/50490] New: ICE when compiling libglib2.0 with LTO

2011-09-22 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50490

 Bug #: 50490
   Summary: ICE when compiling libglib2.0 with LTO
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


Created attachment 25345
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25345
pre-processed source of the file that triggers the ICE

with trunk revision 178863:
"
gcc -O2 -flto -c mem-overflow.i

/home/matt/src/glib2.0-2.29.92/./glib/tests/mem-overflow.c:137:1: internal
compiler error: tree code 'optimization_node' is not supported in LTO streams
"

changing the -O2 to -O1 eliminates the ICE. valgrind shows nothing out of the
ordinary.

pre-processed file mentioned in the commandline above is attached.

[Bug middle-end/50561] New: [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine

2011-09-28 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561

 Bug #: 50561
   Summary: [4.7 regression] ICE when compiling zlib with -O2
-floop-flatten -floop-strip-mine
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


getting this with trunk r179143, on Ubuntu 11.10/x86-64:

/usr/lib/gcc-snapshot/bin/x86_64-linux-gnu-gcc  -O2 -floop-flatten
-floop-strip-mine -c ~/src/trees.i trees.c: In function 'init_block':
trees.c:414:13: internal compiler error: in psct_dynamic_dim, at
graphite-poly.h:659

It doesn't happen with -O1, or if you remove either of the loop options. This
doesn't happen with 4.6.1.

Pre-processed source is attached, but it quick to reproduce with zlib 1.2.3.4
sources.

[Bug middle-end/50561] [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine

2011-09-28 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561

--- Comment #1 from Matt Hargett  2011-09-28 20:59:07 UTC 
---
Created attachment 25378
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25378
pre-processed source of the file that triggers the ICE

[Bug middle-end/50561] [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine

2011-09-28 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561

Matt Hargett  changed:

   What|Removed |Added

   Severity|normal  |major

[Bug debug/51564] [4.7 Regression] ICE in force_type_die, at dwarf2out.c:19288

2012-05-03 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51564

Matt Hargett  changed:

   What|Removed |Added

 CC||matt at use dot net

--- Comment #5 from Matt Hargett  2012-05-03 20:56:40 UTC 
---
I believe I'm hitting (what I'm pretty sure is) this with same bug GCC 4.6
trunk as well. Can you apply the patch to lto-streamer-out.c on the 4_6 branch
as well? Thanks!

In member function ‘__base_dtor ’:
lto1: internal compiler error: in force_type_die, at dwarf2out.c:21059

[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers

2012-05-11 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797

--- Comment #5 from Matt Hargett  2012-05-11 17:58:27 UTC 
---
It's not an IRIX-specific thing AFAICS, but rather that newer versions of
cloog/ppl renamed the macro to avoid conflicts on IRIX. 4.6 still checks for
the old macro name, which is no longer set. I have applied the patch locally to
work around the issue and can verify it solved the problem for me.

Let me know if there's anything else you'd like me to test/validate to get it
back ported.

[Bug debug/51564] [4.7 Regression] ICE in force_type_die, at dwarf2out.c:19288

2012-05-11 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51564

--- Comment #7 from Matt Hargett  2012-05-11 20:19:01 UTC 
---
Applying the patch does allow DWARF serialization to get further, but now it
dies here:
internal compiler error: in add_AT_specification, at dwarf2out.c:7536

It looks like this problem (hiding beneath the original) is related to PR47839,
whose fix was fortran front-end specific.

Should I just file a new bug and reference these other bugs?

[Bug middle-end/53533] New: [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6

2012-05-30 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533

 Bug #: 53533
   Summary: [4.7 regression] loop unrolling as measured by Adobe's
C++Benchmark is twice as slow versus 4.4-4.6
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


Comparing GCC versions, branches, and optimization levels on Adobe's
C++Benchmark suite, I discovered that 4.7 has a major regression with their
loop unrolling tests. I have captures the data here:

https://docs.google.com/spreadsheet/ccc?key=0Amu19eOay72HdE1xYVRPUTFYWU1TSld3Y2FEOEt5LXc

All compilers were fresh checkouts by me from their trunk revisions as of a few
days ago. My configure command line:
/u/mhargett/src/gcc-4_7-branch/configure --program-suffix=-4.7
--prefix=/u/mhargett --enable-languages=c,c++,lto --enable-lto
--with-build-config=bootstrap-lto --with-fpmath=sse --disable-libmudflap
--disable-libssp --enable-build-with-cxx --enable-gold=yes
--with-mpc=/u/mhargett --with-cloog=/u/mhargett/ --with-ppl=/u/mhargett/
--with-gmp=/u/mhargett/ --with-mpfr=/u/mhargett/ --enable-cloog-backend=isl
--disable-cloog-version-check CC=gcc-4.7 CXX=g++-4.7

The 4.6 and 4.7 versions were both build against the same Cloog, ppl, mpfr,
etc.

Going from "-O3 -floop-block -floop-strip-mine -floop-interchange
-mtune=amdfam10" to "-Ofast -funsafe-loop-optimizations -funroll-loops
-floop-block -floop-strip-mine -floop-interchange" didn't help.

Attached is a tar ball of the 4.6 and 4.7 -O3 optimized builds. 'make report'
re-runs the tests, 'make clean && make' rebuilds.

[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6

2012-05-30 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533

--- Comment #1 from Matt Hargett  2012-05-31 00:55:36 UTC 
---
Created attachment 27526
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27526
tarball containing buildable sources and binaries that demonstrate the severe
performance regression on amdfam10

[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6

2012-06-11 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533

--- Comment #3 from Matt Hargett  2012-06-11 19:56:14 UTC 
---
Created attachment 27603
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27603
ZIP with pre-processed shorter example, callgrind output, and smaller binaries

[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6

2012-06-11 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533

--- Comment #4 from Matt Hargett  2012-06-11 19:57:12 UTC 
---
Created attachment 27604
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27604
shorter source example, ~150 lines w/o comments

[Bug middle-end/53533] [4.7 regression] loop unrolling as measured by Adobe's C++Benchmark is twice as slow versus 4.4-4.6

2012-06-11 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533

--- Comment #5 from Matt Hargett  2012-06-11 20:02:41 UTC 
---
Got rid of graphite options, it made no difference. I reduced the original test
from the suite and attached it's source, preprocessor output from 4.6 and 4.7
(no major difference), and callgrind output. To keep things simple, I'm just
using -O3 and -fwhole-program.

According to callgrind, 4.7's instruction references went up by 60% and D1
misses went up by 15% at -O3 versus 4.6 at -O3.

Let me know if you need any more information to continue triaging.

Thanks!

[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark

2012-06-12 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533

--- Comment #11 from Matt Hargett  2012-06-12 18:25:25 UTC 
---
Richard,

Thanks for the quick analysis! Sounds like a perfect storm of sorts :/

re: cprop failure: this may be indicated by another major regression in their
suite for the "simple constant folding" tests. in GCC 4.1-4.6, those tests are
all 0.0s but in 4.7 take tens of seconds. Let me know if you want me to file a
separate bug/reduced test case for that, and then have that new bug depend on
this one. Otherwise, I'll wait until this one sees some resolution and then
retest.

re: multiple passes: if you think that feature has enough merit to be revisited
now, I can look into re-proposing Maxim's patches from October/November 2011
that integrated your feedback at the time.

re: -march workaround: our deployment platform's minimum arch is nocona, and
enabling -march=nocona doesn't workaround the issue. For grins, I tried
-march=amdfam10 (another deployment target, but would require a separate
distributable binary), but that also didn't work around the issue.

I see a small improvement when using -fno-tree-vectorize, but not nearly as
dramatic as yours. For the int32_t for and while loop unrolling, the times go
from ~107s and ~105s to ~96s and ~95s, respectively. The do and goto loop
unrolling times get slightly worse (~2%), but it might be noise.

Let me know if there's any additional testing/footwork you'd like me to do.
Again, thanks for the quick turnaround on such a deep analysis!

[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark

2012-06-14 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533

--- Comment #15 from Matt Hargett  2012-06-14 18:01:31 UTC 
---
(In reply to comment #14)
> Mine, at least for a 4.8 solution.

What enhancement to 4.7 caused the regression? Can whatever the change was be
(partially) reverted to lessen the impact?

[Bug middle-end/53676] New: [4.7/4.8 regression] constant folding regression, shown as slowdown as measured by Adobe's C++Benchmark

2012-06-14 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676

 Bug #: 53676
   Summary: [4.7/4.8 regression] constant folding regression,
shown as slowdown as measured by Adobe's C++Benchmark
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


The attached ZIP contains two binaries and preprocessor output files, based on
a subset of a test in Adobe's C++Benchmark suite. All GCC versions I tested
prior to 4.7 do the folding correctly. I tried using Ofast and other tricks to
workaround this new regression to no avail.

-rw-r--r-- 1 mhargett users 143573 Jun 14 15:31 int8_folding_test.gcc47.i
mhargett@chert:~/src/C++Benchmarks-gcc47-google-fast$ ./int8_folding_test-gcc46
./int8_folding_test-gcc46 

test description   absolute   operations   ratio with
number time   per second   test0

 0 "int8_t constant"   0.00 sec inf M -nan

Total absolute time for int8_t simple constant folding: 0.00 sec
mhargett@chert:~/src/C++Benchmarks-gcc47-google-fast$ ./int8_folding_test-gcc47
./int8_folding_test-gcc47 

test description   absolute   operations   ratio with
number time   per second   test0

 0 "int8_t constant"   0.69 sec   2318.84 M 1.00

Total absolute time for int8_t simple constant folding: 0.69 sec

[Bug middle-end/53676] [4.7/4.8 regression] constant folding regression, shown as slowdown as measured by Adobe's C++Benchmark

2012-06-14 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676

--- Comment #1 from Matt Hargett  2012-06-14 22:48:49 UTC 
---
Created attachment 27622
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27622
ZIP containing pre-processed source and binaries that demonstrate the const
folding regression

[Bug middle-end/53676] [4.7/4.8 regression] constant folding regression, shown as slowdown as measured by Adobe's C++Benchmark

2012-06-14 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676

--- Comment #2 from Matt Hargett  2012-06-14 23:00:33 UTC 
---
I forgot to mention -- it's the same result on all types, both signed and
unsigned. the int8_t case is (hopefully) representative of the root cause for
all/most of them.

[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now

2012-06-27 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676

--- Comment #10 from Matt Hargett  2012-06-27 18:26:55 UTC 
---
Is there a fix targeted for 4.7.2? I can apply the patch and do some testing,
if that helps. Let me know what I can do, if anything, so we can make 4.7
deployable for us.

Thanks for the quick turnaround on the trunk commit!

[Bug tree-optimization/37242] missed FRE opportunity because of signedness of addition

2012-06-28 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37242

--- Comment #22 from Matt Hargett  2012-06-29 00:20:17 UTC 
---
Hey Andrew, any word on your patch?

[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers

2012-06-29 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797

--- Comment #6 from Matt Hargett  2012-06-29 18:49:35 UTC 
---
Pinging on this again since this patch has been back ported to a couple of
4.6-based branches now. Anyone attempting to use a recent cloog release with
GCC 4.6 will run into this problem. It is incredibly low-risk in an of itself,
and I can verify that it works with both latest cloog and the previous release.

[Bug lto/52159] New: ICE when building qemu with GCC 4.7 trunk: cannot read LTO decls

2012-02-07 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52159

 Bug #: 52159
   Summary: ICE when building qemu with GCC 4.7 trunk: cannot read
LTO decls
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


Using the attached tarball, which is the Ubuntu source package configured with
CFLAGS="-O3 -flto -floop-block -floop-interchange" and LDFLAGS="-O3 -flto":


matt@matt-desktop:~/src/qemu-linaro-1.0.50-2012.01$ dh_auto_build -B
system-build
dh_auto_build: warning: line 1 of /home/matt/.config/dpkg/buildflags.conf
mentions unknown flag BUILD_CONFIG
dh_auto_build: warning: line 5 of /home/matt/.config/dpkg/buildflags.conf is
invalid, it has been ignored.
  LINK  x86_64-softmmu/qemu-system-x86_64
lto1: error: two or more sections for .gnu.lto_fprintf.4f35e9dac4cf72f5
lto1: internal compiler error: cannot read LTO decls from
/tmp/cc9TN5Ma.ltrans1.o
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: gcc returned 1 exit status
/usr/bin/ld.gold.real: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[1]: *** [qemu-system-x86_64] Error 1
make: *** [subdir-x86_64-softmmu] Error 2
dh_auto_build: make -j1 returned exit code 2
matt@matt-desktop:~/src/qemu-linaro-1.0.50-2012.01$ gcc --version
gcc (GCC) 4.7.0 20120207 (experimental)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

matt@matt-desktop:~/src/qemu-linaro-1.0.50-2012.01$ ld --version
GNU gold (GNU Binutils for Ubuntu 2.22) 1.11
Copyright 2011 Free Software Foundation, Inc.

[Bug lto/52159] ICE when building qemu with GCC 4.7 trunk: cannot read LTO decls

2012-02-07 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52159

--- Comment #1 from Matt Hargett  2012-02-07 22:00:12 UTC 
---
Created attachment 26606
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26606
tarball of ltrans temporaries that reproduce this bug, from Ubuntu source
package for qemu-linaro

[Bug target/52610] New: mpfr fails to compile when specifying CFLAGS="-O3 -mcpu=leon"

2012-03-17 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610

 Bug #: 52610
   Summary: mpfr fails to compile when specifying CFLAGS="-O3
-mcpu=leon"
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


error when compiling MPFR 3.1.0:
debian-sparc:~/src/mpfr-3.1.0# CFLAGS="-O3 -mcpu=leon -flto" CXXFLAGS="-O3
-mcpu=v8 -flto" LDFLAGS="-flto -O3 -mcpu=v8"  ./configure
--prefix=/opt/gcc-4.7.0 --with-gnu-as --with-gnu-ld --with-gmp=/opt/gcc-4.7.0
[...]
make
[...]
libtool: compile:  gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1
-DHAVE_SYS_TIME_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1
-DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1
-DMPFR_HAVE_INTMAX_MAX=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1
-DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DMPFR_USE_THREAD_SAFE=1 -DLT_OBJDIR=\".libs/\"
-DHAVE_ATTRIBUTE_MODE=1 -DHAVE___GMPN_ROOTREM=1 -DHAVE___GMPN_SBPI1_DIVAPPR_Q=1
-I. -I/opt/gcc-4.7.0/include -O3 -mcpu=leon -flto -MT cmp.lo -MD -MP -MF
.deps/cmp.Tpo -c cmp.c  -fPIC -DPIC -o .libs/cmp.o
/tmp/ccjJFPW2.s: Assembler messages:
/tmp/ccjJFPW2.s:241: Error: Hardware capability "mul32" not enabled for "smul".
make[2]: *** [cmp.lo] Error 1

When I try to add -Av8 to CFLAGS, I get this error:
:0:1: error: missing '(' after predicate

I have a qemu-sparc virtual machine based on Debian/Sarge I can provide that
reproduces the problem. I'll work on attaching a pre-processed example.

[Bug middle-end/52630] New: [4.7 regression] ICE when compiling ppl-0.12 testsuite

2012-03-19 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52630

 Bug #: 52630
   Summary: [4.7 regression] ICE when compiling ppl-0.12 testsuite
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


While PPL 0.12 itself built okay, it's "make check" target did not. I bootstrap
all required GCC libraries with a given GCC release, and run all their
testsuites. It usually weeds out subtle wrong-code issues and ICEs. GMP, MPC,
CLOOG-ISL, and MPFR were all fine.

g++ -DHAVE_CONFIG_H -I. -I../..  -DANALYZER_FP_FORMAT=float
-DANALYZED_FP_FORMAT=IEEE754_SINGLE   -I../../src -I../../src -I../../tests
-I../../utils -I/opt/gcc-4.7.0/include -DNDEBUG=1   -g -O3 -frounding-math 
-mcpu=v8 -W -Wall -MT digitalfilters1.o -MD -MP -MF .deps/digitalfilters1.Tpo
-c -o digitalfilters1.o digitalfilters1.cc
In file included from ../../src/Box.defs.hh:2260:0,
 from ../../src/Linear_Form.templates.hh:29,
 from ../../src/ppl_include_files.hh:8,
 from ../../src/ppl_header.hh:38,
 from ../../tests/ppl_test.hh:27,
 from digitalfilters1.cc:24:
../../src/Box.templates.hh: In constructor
‘Parma_Polyhedra_Library::Box::Box(const
Parma_Polyhedra_Library::Generator_System&) [with ITV =
Parma_Polyhedra_Library::Interval >]’:
../../src/Box.templates.hh:222:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [digitalfilters1.o] Error 1
make[3]: Leaving directory `/root/src/ppl-0.12/tests/Concrete_Expression'

Pre-processed sources are attached. ICE still happens with -O2, but does not
happen with -O1:
g++ -g -O2 -frounding-math  -mcpu=v8 -W -Wall -c digitalfilters1.cc.i  
   
 In file included from
../../src/Octagonal_Shape.defs.hh:2316:0,
 from ../../src/BD_Shape.inlines.hh:31,
 from ../../src/BD_Shape.defs.hh:2361,
 from ../../src/Box.templates.hh:38,
 from ../../src/Box.defs.hh:2260,
 from ../../src/Linear_Form.templates.hh:29,
 from ../../src/ppl_include_files.hh:8,
 from ../../src/ppl_header.hh:38,
 from ../../tests/ppl_test.hh:27,
 from digitalfilters1.cc:24:
../../src/Octagonal_Shape.templates.hh: In member function ‘void
Parma_Polyhedra_Library::Octagonal_Shape::refine_with_linear_form_inequality(const
Parma_Polyhedra_Library::Linear_Form >&, const
Parma_Polyhedra_Library::Linear_Form >&) [with Interval_Info =
Parma_Polyhedra_Library::Interval_Info_Bitset; T =
float]’:
../../src/Octagonal_Shape.templates.hh:874:1: internal compiler error:
Segmentation fault

[Bug middle-end/52630] [4.7 regression] ICE when compiling ppl-0.12 testsuite

2012-03-19 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52630

--- Comment #1 from Matt Hargett  2012-03-20 00:00:46 UTC 
---
Created attachment 26926
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26926
pre-processed sources that exhibit the ICE

[Bug bootstrap/52674] New: [4.7 regression] profiledbootstrap-lean failues on Debian/SPARC

2012-03-22 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52674

 Bug #: 52674
   Summary: [4.7 regression] profiledbootstrap-lean failues on
Debian/SPARC
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


My top-level configure:
debian-sparc:~/src/gcc-4.7.0-RC-20120314/obj# head config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ ../configure --prefix=/opt/gcc-4.7.0/ --enable-lto
--with-gmp=/opt/gcc-4.7.0/ --with-mpfr=/opt/gcc-4.7.0/
--with-mpc=/opt/gcc-4.7.0/ --with-cloog=/opt/gcc-4.7.0/
--with-ppl=/opt/gcc-4.7.0 --enable-gold --enable-cloog-backend=isl
--disable-cloog-version-check --enable-plugins
--with-build-config=bootstrap-lto --disable-libstdcxx-pch --enable-thread-safe
--enable-threads=posix --with-libelf=/opt/gcc-4.7.0/

then I did a make profiledbootstrap-lean



Resulting in this from the intl/config.log:
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /root/src/gcc-4.7.0-RC-20120314/intl/configure --cache-file=./config.cache
--prefix=/opt/gcc-4.7.0/ --enable-lto --
with-gmp=/opt/gcc-4.7.0/ --with-mpfr=/opt/gcc-4.7.0/ --with-mpc=/opt/gcc-4.7.0/
--with-cloog=/opt/gcc-4.7.0/ --with-ppl
=/opt/gcc-4.7.0 --enable-gold --enable-cloog-backend=isl
--disable-cloog-version-check --enable-plugins --with-build-co
nfig=bootstrap-lto --disable-libstdcxx-pch --enable-thread-safe
--enable-threads=posix --with-libelf=/opt/gcc-4.7.0/ --
enable-languages=c,c++,fortran,java,lto,objc --program-transform-name=s,y,y,
--disable-option-checking --build=sparc-un
known-linux-gnu --host=sparc-unknown-linux-gnu --target=sparc-unknown-linux-gnu
--srcdir=../../intl --with-build-libsub
dir=. --enable-build-with-cxx

[...]

configure:2978: checking for C compiler default output file name
configure:3000:  /root/src/gcc-4.7.0-RC-20120314/obj/./prev-gcc/xgcc
-B/root/src/gcc-4.7.0-RC-20120314/obj/./prev-gcc/
-B/opt/gcc-4.7.0/sparc-unknown-linux-gnu/bin/
-B/opt/gcc-4.7.0/sparc-unknown-linux-gnu/bin/ -B/opt/gcc-4.7.0/sparc-unkn
own-linux-gnu/lib/ -isystem /opt/gcc-4.7.0/sparc-unknown-linux-gnu/include
-isystem /opt/gcc-4.7.0/sparc-unknown-linux-
gnu/sys-include-g -O2 -flto=jobserver -frandom-seed=1 -fprofile-generate
-fno-lto  -static-libstdc++ -static-libgcc
  conftest.c  >&5
configure:3004: $? = 0
configure:3041: result: a.out
configure:3057: checking whether the C compiler works
configure:3066: ./a.out
/root/src/gcc-4.7.0-RC-20120314/intl/configure: line 1: 17735 Segmentation
fault  ./$ac_file
configure:3070: $? = 139
configure:3077: error: in `/root/src/gcc-4.7.0-RC-20120314/obj/intl':
configure:3081: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

I have a qemu virtual machine I'm working in and can send it along if that
would help debug this issue.

[Bug bootstrap/52674] [4.7 regression] segfault during profiled LTO bootstrap

2012-03-23 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52674

--- Comment #2 from Matt Hargett  2012-03-23 20:26:44 UTC 
---
I was doing profiledbootstrap with the bootstrap-lto config on x64 just fine
until about 6 weeks ago. The speedup in the resulting binary was notable, and
was very useful to have for my shorter gcc build iterations where I use
--disable-bootstrap. If it's not supposed to work, then configure should not
allow it IMO.

If you can recommend an intermediate make target I can use to make the
iteration time shorter, I can try and debug this issue further on my own and
report back. I can't figure out how to capture the resulting binary that
crashes, since the source isn't listed in the config.log when it fails, so any
help on that front would be appreciated.

[Bug tree-optimization/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5

2012-03-23 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076

--- Comment #32 from Matt Hargett  2012-03-23 20:30:17 UTC 
---
Richard, if nothing's come to mind by now for the 4.6 branch, can this be
closed?
I'd like to see it fixed, of course, but so long as it still works in 4.7.0 and
there's a test in the suite that verifies as such, let's move on :)

[Bug target/52610] mpfr fails to compile when specifying CFLAGS="-O3 -mcpu=leon"

2012-03-24 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610

--- Comment #6 from Matt Hargett  2012-03-24 20:20:42 UTC 
---
Great. I verified the fix yesterday. Thanks!

[Bug middle-end/52704] New: thunk referenced in discarded section when combining -flto -ftree-vectorize -fipa-cp-clone on Debian/SPARC

2012-03-24 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52704

 Bug #: 52704
   Summary: thunk referenced in discarded section when combining
-flto -ftree-vectorize -fipa-cp-clone  on Debian/SPARC
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


To reproduce from scratch with 4.7.0 and sambe-3.6.3 (reduced case
below/attached):
debian-sparc:~/src/samba-3.6.3/source3# CFLAGS="-O2 -flto -mtune=leon
-floop-block -floop-interchange -floop-strip-mine -ftree-loop-distribution
-ftree-loop-distribute-patterns -ftree-loop-im -ftree-loop-ivcanon  -fivopts
-fpredictive-commoning -fipa-cp-clone -ftree-vectorize -ffast-math
-fgcse-after-reload -fgcse-sm -fgcse-las" LDFLAGS="-flto -O2" ./configure
--prefix=/opt/samba-3.6.4 --exec-prefix=/opt/samba-3.6.4
--sysconfdir=/opt/samba-3.6.4/etc --with-configdir=/opt/samba-3.6.4/etc
--with-quotas --with-pam --with-pam_smbpass --build=sparc-linux
--with-logfilebase=/opt/samba-3.6.4/var/log
--with-piddir=/opt/samba-3.6.4/var/run --with-lockdir=/opt/samba-3.6.4/var/lock

debian-sparc:~/src/samba-3.6.3/source3# make
[...]
Linking shared library bin/libtdb.so.1
gcc -I../lib/zlib -O2 -flto -mtune=leon -floop-block -floop-interchange
-floop-strip-mine -ftree-loop-distribution -ftree-loop-distribute-patterns
-ftree-loop-im -ftree-loop-ivcanon -fivopts -fpredictive-commoning
-fipa-cp-clone -ftree-vectorize -ffast-math -fgcse-after-reload -fgcse-sm
-fgcse-las -I. -I/root/src/samba-3.6.3/source3
-I/root/src/samba-3.6.3/source3/../lib/iniparser/src -Iinclude -I./include  -I.
-I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/talloc
-I../lib/tdb/include -DHAVE_CONFIG_H  -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iinclude -I./include -I. -I.
-I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/popt
-DLDAP_DEPRECATED  -I/root/src/samba-3.6.3/source3/lib -I.. -D_SAMBA_BUILD_=3
-D_SAMBA_BUILD_=3 -fPIC -shared -Wl,-Bsymbolic -Wl,-z,relro -flto -O2 -L./bin
-lc -Wl,-z,defs
-Wl,--version-script,/root/src/samba-3.6.3/source3/exports/`basename
bin/libtdb.so.1 | sed 's:\.so[\.0-9]*$:.syms:'` -o bin/libtdb.so.1
../lib/tdb/common/tdb.o ../lib/tdb/common/dump.o
../lib/tdb/common/transaction.o ../lib/tdb/common/error.o
../lib/tdb/common/traverse.o ../lib/tdb/common/freelist.o
../lib/tdb/common/freelistcheck.o ../lib/tdb/common/io.o
../lib/tdb/common/lock.o ../lib/tdb/common/open.o ../lib/tdb/common/check.o
../lib/tdb/common/hash.o ../lib/tdb/common/summary.o ./../lib/replace/replace.o
./../lib/replace/snprintf.o ./../lib/replace/getpass.o\
-Wl,-soname=`basename bin/libtdb.so.1`
`__sparc_get_pc_thunk.l7' referenced in section `.text' of
/tmp/ccUwrHhg.ltrans2.ltrans.o: defined in discarded section
`.text.__sparc_get_pc_thunk.l7.2305[__sparc_get_pc_thunk.l7.2305]' of
/tmp/ccUwrHhg.ltrans2.ltrans.o
collect2: error: ld returned 1 exit status

I reduced it to an interaction between tree-vectorize and ipa-cp-clone with
inline-functions is *not* present. when using -O3, or adding inline-functions
along with those two options, the problem goes away:
gcc -I../lib/zlib -O0 -flto -ftree-vectorize -fipa-cp-clone -I.
-I/root/src/samba-3.6.3/source3
-I/root/src/samba-3.6.3/source3/../lib/iniparser/src -Iinclude -I./include  -I.
-I. -I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/talloc
-I../lib/tdb/include -DHAVE_CONFIG_H  -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Iinclude -I./include -I. -I.
-I./../lib/replace -I./../lib/tevent -I./librpc -I./.. -I./../lib/popt
-DLDAP_DEPRECATED  -I/root/src/samba-3.6.3/source3/lib -I.. -D_SAMBA_BUILD_=3
-D_SAMBA_BUILD_=3 -fPIC -shared -Wl,-Bsymbolic -Wl,-z,relro -flto -O2 -L./bin
-lc -Wl,-z,defs
-Wl,--version-script,/root/src/samba-3.6.3/source3/exports/`basename
bin/libtdb.so.1 | sed 's:\.so[\.0-9]*$:.syms:'` -o bin/libtdb.so.1
../lib/tdb/common/tdb.o ../lib/tdb/common/dump.o
../lib/tdb/common/transaction.o ../lib/tdb/common/error.o
../lib/tdb/common/traverse.o ../lib/tdb/common/freelist.o
../lib/tdb/common/freelistcheck.o ../lib/tdb/common/io.o
../lib/tdb/common/lock.o ../lib/tdb/common/open.o ../lib/tdb/common/check.o
../lib/tdb/common/hash.o ../lib/tdb/common/summary.o ./../lib/replace/replace.o
./../lib/replace/snprintf.o ./../lib/replace/getpass.o   
-Wl,-soname=`basename bin/libtdb.so.1`

`__sparc_get_pc_thunk.l7' referenced in section `.text' of
libtdb.so.1.ltrans2.ltrans.o: defined in discarded section
`.text.__sparc_get_pc_thunk.l7.2305[__sparc_get_pc_thunk.l7.2305]' of
libtdb.so.1.ltrans2.ltrans.o

Attached are the save-temps outputs and (hopefully) enough of the original
source dir to reproduce otherwise.

[Bug middle-end/52704] thunk referenced in discarded section when combining -flto -ftree-vectorize -fipa-cp-clone on Debian/SPARC

2012-03-24 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52704

--- Comment #1 from Matt Hargett  2012-03-24 21:12:21 UTC 
---
Created attachment 26975
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26975
save-temps output from /tmp and linking dir

[Bug middle-end/52717] New: thunk referenced in discarded section when building samba with -flto

2012-03-25 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717

 Bug #: 52717
   Summary: thunk referenced in discarded section when building
samba with -flto
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


To reproduce from scratch with 4.7.0 and samba-3.6.3 (reduced case
below/attached):
debian-sparc:~/src/samba-3.6.3/source3# CFLAGS="-O2 -flto -mtune=leon
-floop-block -floop-interchange -floop-strip-mine -ftree-loop-distribution
-ftree-loop-distribute-patterns -ftree-loop-im -ftree-loop-ivcanon  -fivopts
-fpredictive-commoning -fipa-cp-clone -ffast-math -fgcse-after-reload -fgcse-sm
-fgcse-las" LDFLAGS="-flto -O2" ./configure --prefix=/opt/samba-3.6.4
--exec-prefix=/opt/samba-3.6.4 --sysconfdir=/opt/samba-3.6.4/etc
--with-configdir=/opt/samba-3.6.4/etc --with-quotas --with-pam
--with-pam_smbpass --build=sparc-linux
--with-logfilebase=/opt/samba-3.6.4/var/log
--with-piddir=/opt/samba-3.6.4/var/run --with-lockdir=/opt/samba-3.6.4/var/lock

debian-sparc:~/src/samba-3.6.3/source3# make
[...]
`__sparc_get_pc_thunk.l7' referenced in section `.text' of
smbta-util.ltrans24.ltrans.o: defined in discarded section
`.text.__sparc_get_pc_thunk.l7.4585[__sparc_get_pc_thunk.l7.4585]' of
smbta-util.ltrans24.ltrans.o

This is different from the previous bug -- there is no ipa-cp-clone here.
Attached is the output from save-temps.

I have yet to have any mid-sized C project fully build with LTO using -O2 or
variants, most coming down to this class of errors.

[Bug target/52717] thunk referenced in discarded section when building samba with -flto

2012-03-26 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717

--- Comment #5 from Matt Hargett  2012-03-26 17:09:55 UTC 
---
Attachment was too big. Here's a URL for an archive that includes the ltrans
objects, ltrans asm, and cc temp files:
http://www.clock.org/~matt/tmp/smbta-util-lto-failure-temps.tar.bz2

I can provide the whole source dir or a VM image if that helps.

binutils version is freshly compiled with GCC 4.7.0 RC1:
debian-sparc:~/src/samba-3.6.3/source3# ld --version
GNU ld (GNU Binutils) 2.22.52.20120317
Copyright 2012 Free Software Foundation, Inc.

using this configure line for binutils:
../configure --prefix=/opt/gcc-4.7.0/ --enable-lto --with-gmp=/opt/gcc-4.7.0/
--with-mpfr=/opt/gcc-4.7.0/ --with-mpc=/opt/gcc-4.7.0/
--with-cloog=/opt/gcc-4.7.0/ --with-ppl=/opt/gcc-4.7.0 --enable-gold
--enable-cloog-backend=isl --disable-cloog-version-check --enable-plugins

and then this configure line for gcc 4.7.0:
 ../configure --prefix=/opt/gcc-4.7.0/ --enable-lto --with-gmp=/opt/gcc-4.7.0/
--with-mpfr=/opt/gcc-4.7.0/ --with-mpc=/opt/gcc-4.7.0/
--with-cloog=/opt/gcc-4.7.0/ --with-ppl=/opt/gcc-4.7.0 --enable-gold
--enable-cloog-backend=isl --enable-plugins --with-build-config=bootstrap-lto
--disable-libstdcxx-pch --enable-thread-safe --enable-threads=posix
--with-libelf=/opt/gcc-4.7.0/ --enable-languages=c,c++,lto --disable-bootstrap
--with-tune=leon --enable-build-with-cxx --disable-cloog-version-check
--disable-nls

[Bug target/52717] thunk referenced in discarded section when building samba with -flto

2012-03-26 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717

--- Comment #6 from Matt Hargett  2012-03-26 17:32:51 UTC 
---
The link line that fails:
gcc -o bin/smbta-util utils/smbta-util.o dynconfig.o param/loadparm.o
param/loadparm_server_role.o param/util.o lib/sharesec.o
lib/ldap_debug_handler.o registry/reg_api.o registry/reg_dispatcher.o
registry/reg_cachehook.o registry/reg_objects.o registry/reg_util_internal.o
lib/util_nttoken.o registry/reg_backend_db.o registry/reg_init_basic.o
registry/reg_util_token.o registry/reg_api_util.o
registry/reg_backend_smbconf.o registry/reg_init_smbconf.o
../lib/smbconf/smbconf.o ../lib/smbconf/smbconf_util.o
../lib/smbconf/smbconf_txt.o lib/smbconf/smbconf_reg.o
lib/smbconf/smbconf_init.o ../libcli/security/privileges.o lib/popt_common.o
./../lib/replace/replace.o ./../lib/replace/snprintf.o
./../lib/replace/getpass.o ../lib/util/rbtree.o ../lib/util/signal.o
../lib/util/time.o ../lib/util/xfile.o ../lib/util/util_strlist.o
../lib/util/util_file.o ../lib/util/data_blob.o ../lib/util/util.o
../lib/util/fsusage.o ../lib/util/params.o ../lib/util/talloc_stack.o
../lib/util/genrand.o ../lib/util/util_net.o ../lib/util/become_daemon.o
../lib/util/system.o ../lib/util/tevent_unix.o ../lib/util/tevent_ntstatus.o
../lib/util/tevent_werror.o ../lib/util/smb_threads.o ../lib/util/util_id.o
../lib/util/blocking.o ../lib/util/rfc1738.o ../lib/util/select.o
../lib/util/util_pw.o ../lib/crypto/crc32.o ../lib/crypto/md5.o
../lib/crypto/hmacmd5.o ../lib/crypto/arcfour.o ../lib/crypto/md4.o
../lib/crypto/sha256.o ../lib/crypto/hmacsha256.o ../lib/crypto/aes.o
../lib/crypto/rijndael-alg-fst.o lib/messages.o librpc/gen_ndr/ndr_messaging.o
lib/messages_local.o lib/messages_ctdbd.o lib/packet.o lib/ctdbd_conn.o
lib/interfaces.o lib/memcache.o lib/talloc_dict.o lib/serverid.o
lib/util_sconn.o lib/util_transfer_file.o ../lib/async_req/async_sock.o
lib/addrchange.o lib/util_tdb.o ../lib/util/util_tdb.o ../lib/util/tdb_wrap.o
lib/dbwrap.o lib/dbwrap_tdb.o lib/dbwrap_ctdb.o lib/g_lock.o lib/dbwrap_rbt.o
lib/version.o lib/charcnv.o ../lib/util/debug.o ../lib/util/debug_s3.o
lib/fault.o lib/interface.o lib/pidfile.o lib/system.o lib/sendfile.o
lib/recvfile.o lib/time.o lib/username.o ../libds/common/flag_mapping.o
lib/access.o lib/smbrun.o lib/bitmap.o lib/dprintf.o
../libcli/registry/util_reg.o lib/wins_srv.o lib/util_str.o lib/clobber.o
lib/util_sid.o lib/util_unistr.o ../lib/util/charset/codepoints.o
lib/util_file.o lib/util.o lib/util_cmdline.o lib/util_names.o lib/util_sock.o
lib/sock_exec.o lib/util_sec.o lib/substitute.o lib/dbwrap_util.o
lib/ms_fnmatch.o lib/errmap_unix.o lib/tallocmsg.o lib/dmallocmsg.o
libsmb/clisigning.o libsmb/smb_signing.o ../lib/util/charset/iconv.o
intl/lang_tdb.o lib/conn_tdb.o lib/adt_tree.o lib/gencache.o
lib/sessionid_tdb.o lib/module.o lib/events.o ./../lib/tevent/tevent.o
./../lib/tevent/tevent_debug.o ./../lib/tevent/tevent_util.o
./../lib/tevent/tevent_fd.o ./../lib/tevent/tevent_timed.o
./../lib/tevent/tevent_immediate.o ./../lib/tevent/tevent_signal.o
./../lib/tevent/tevent_req.o ./../lib/tevent/tevent_wakeup.o
./../lib/tevent/tevent_queue.o ./../lib/tevent/tevent_standard.o
./../lib/tevent/tevent_select.o ./../lib/tevent/tevent_poll.o
./../lib/tevent/tevent_epoll.o lib/server_contexts.o lib/ldap_escape.o
lib/secdesc.o ../libcli/security/access_check.o ../libcli/security/secace.o
../libcli/security/object_tree.o ../libcli/security/sddl.o
../libcli/security/secacl.o lib/fncall.o libads/krb5_errs.o lib/system_smbd.o
lib/audit.o ../librpc/ndr/ndr_basic.o ../librpc/ndr/ndr.o
../librpc/ndr/ndr_misc.o librpc/gen_ndr/ndr_misc.o
librpc/gen_ndr/ndr_security.o ../librpc/ndr/ndr_sec_helper.o
../librpc/ndr/ndr_string.o ../librpc/ndr/uuid.o librpc/ndr/util.o
librpc/gen_ndr/ndr_server_id.o librpc/gen_ndr/ndr_dcerpc.o lib/file_id.o
lib/idmap_cache.o ../libcli/security/dom_sid.o
../libcli/security/security_descriptor.o ../libcli/security/security_token.o
../libcli/security/util_sid.o lib/dummysmbd.o lib/dummyroot.o libsmb/nterr.o
libsmb/smberr.o ../libcli/util/doserr.o libsmb/errormap.o
../librpc/rpc/dcerpc_error.o ../libcli/auth/smbdes.o
../libcli/auth/smbencrypt.o ../libcli/auth/msrpc_parse.o
../libcli/auth/session.o passdb/secrets.o passdb/machine_account_secrets.o
passdb/machine_sid.o librpc/gen_ndr/ndr_secrets.o lib/filename_util.o -pie
-Wl,-z,relro -O2 -flto -L./bin -Wl,--export-dynamic -lresolv -lresolv -lnsl
-ldl -lrt -lldap -llber -lpopt -ltalloc -ltdb

To make the failure go away, just add -finline-functions. Similarly, changing
-O2 to -O3 also eliminates the error.

[Bug target/52717] thunk referenced in discarded section when building samba with -flto

2012-03-27 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717

--- Comment #7 from Matt Hargett  2012-03-28 03:22:49 UTC 
---
Is there any more information I need to provide for this class of issues to be
resolved? Mozilla, WebKit, and others all eventually fail with similar errors.
If there's a proposed fix, I can rebuild and provide test results back in a few
days. Thanks!

[Bug target/52717] thunk referenced in discarded section when building samba with -flto

2012-04-23 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717

--- Comment #13 from Matt Hargett  2012-04-23 15:19:47 UTC 
---
*** Bug 52704 has been marked as a duplicate of this bug. ***

[Bug middle-end/52704] thunk referenced in discarded section when combining -flto -ftree-vectorize -fipa-cp-clone on Debian/SPARC

2012-04-23 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52704

Matt Hargett  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Matt Hargett  2012-04-23 15:19:47 UTC 
---
Went away when the fix for 52717 was applied.

*** This bug has been marked as a duplicate of bug 52717 ***

[Bug target/52610] mpfr fails to compile when specifying CFLAGS="-O3 -mcpu=leon"

2012-04-23 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52610

Matt Hargett  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #7 from Matt Hargett  2012-04-23 15:21:19 UTC 
---
Verified again with 4.7 trunk.

[Bug bootstrap/49797] CLooG use of LANGUAGE_C conflicts with MIPS compilers

2012-04-23 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49797

Matt Hargett  changed:

   What|Removed |Added

 CC||matt at use dot net

--- Comment #3 from Matt Hargett  2012-04-23 22:19:35 UTC 
---
Can you please back port this to 4.6 as well? Running into this on Scientific
Linux 6.1 on x64 with GCC 4.6 trunk and latest cloog-isl and ppl. Thanks!

[Bug bootstrap/51118] New: ICE when bootstrapping on Ubuntu 11.10/amd64 with stage1 checking enabled

2011-11-13 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51118

 Bug #: 51118
   Summary: ICE when bootstrapping on Ubuntu 11.10/amd64 with
stage1 checking enabled
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


$ ../configure --enable-bootstrap --prefix=/home/matt --enable-languages=c,c++
--enable-stage1-checking=all
[...]
$ make
[...]

/home/matt/src/gcc-trunk/obj/./gcc/xgcc -B/home/matt/src/gcc-trunk/obj/./gcc/
-B/home/matt/x86_64-unknown-linux-gnu/bin/
-B/home/matt/x86_64-unknown-linux-gnu/lib/ -isystem
/home/matt/x86_64-unknown-linux-gnu/include -isystem
/home/matt/x86_64-unknown-linux-gnu/sys-include -g -O2 -m32 -O2 -g -O2 -DIN_GCC
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -I. -I.
-I../../.././gcc -I../../../../libgcc -I../../../../libgcc/.
-I../../../../libgcc/../gcc -I../../../../libgcc/../include
-I../../../../libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS
-DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
../../../../libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../../../libgcc/libgcc2.c: In function __muldi3:
../../../libgcc/libgcc2.c:553:3: internal compiler error: tree check: expected
tree that contains ‘typed’ structure, have ‘block’ in fold_checksum_tree, at
fold-const.c:14160


I get the same results when setting CC and CXX to be gcc-4.4 and g++-4.4
respectively (the default system compiler on Ubuntu 11.10 is 4.6.1-based).

Running the commandline that causes the ICE with -O1 also elicits the problem.
Setting BOOT_CFLAGS and CFLAGS to -O1 doesn't help matters.

[Bug middle-end/51182] New: [ipa-iterations] running multiple passes of early IPA on a file produces difference code when it shouldn't

2011-11-16 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51182

 Bug #: 51182
   Summary: [ipa-iterations] running multiple passes of early IPA
on a file produces difference code when it shouldn't
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


Created attachment 25841
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25841
pre-procecessed source that produces the above code differances

As requested by Richard (http://gcc.gnu.org/ml/gcc-cvs/2011-11/msg00669.html),
I am testing the outstanding multiple iterations patch and reporting when
multiple early IPA passes produce differences in code generation that should
probably be gotten in one pass (or not at all).

The attached file is from the open source pmccabe project. When compiling with
-O1, there are register scheduling differences and the elimination of a nop
instruction when doing a second early IPA pass.

with -O1 --param eipa-iterations=1:
 2b3:   8d 6d 01lea0x1(%rbp),%ebp
 2b6:   48 98   cltq   
 2b8:   48 8d 5c c3 f8  lea-0x8(%rbx,%rax,8),%rbx
 2bd:   83 3d 00 00 00 00 00cmpl   $0x0,0x0(%rip)# 2c4 
 2c4:   74 12   je 2d8 
 2c6:   48 89 demov%rbx,%rsi
 2c9:   89 ef   mov%ebp,%edi
[...]
 429:   80 78 50 01 cmpb   $0x1,0x50(%rax)
 42d:   0f 1f 00nopl   (%rax)
 430:   76 2e   jbe460 


with -O1 --param eipa-iterations=2:
 2b3:   44 8d 65 01 lea0x1(%rbp),%r12d
 2b7:   48 98   cltq   
 2b9:   48 8d 5c c3 f8  lea-0x8(%rbx,%rax,8),%rbx
 2be:   83 3d 00 00 00 00 00cmpl   $0x0,0x0(%rip)# 2c5 
 2c5:   74 13   je 2da 
 2c7:   48 89 demov%rbx,%rsi
 2ca:   44 89 e7mov%r12d,%edi
[...]

 42f:   80 78 50 01 cmpb   $0x1,0x50(%rax)
 433:   76 2e   jbe463 

There are additional/different differences at -O2, but I'll file those in
another bug once I get feedback on this one.

[Bug middle-end/51182] [ipa-iterations] running multiple passes of early IPA on a file produces difference code when it shouldn't

2011-11-16 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51182

--- Comment #1 from Matt Hargett  2011-11-16 23:09:22 UTC 
---
I see the same seeming no-op register and instruction twiddles with inflate.c
from zlib, as well. Adding more iterations has a kind of ping-pong effect where
it goes between the two different versions.


diff inflate.o.-O3.ipa-iterations2.dump inflate.o.-O3.ipa-iterations3.dump2c2
< inflate.o.-O3.ipa-iterations2: file format elf64-x86-64
---
> inflate.o.-O3.ipa-iterations3: file format elf64-x86-64
897,898c897,898
<  d22:31 dbxor%ebx,%ebx
<  d24:45 31 d2 xor%r10d,%r10d
---
>  d22: 45 31 d2xor%r10d,%r10d
>  d25: 31 db   xor%ebx,%ebx
1731c1731
< 19a9:44 39 c7 cmp%r8d,%edi
---
> 19a9: 41 39 f8cmp%edi,%r8d
2192,2193c2192,2193
< 20e0:45 31 d2 xor%r10d,%r10d
< 20e3:31 dbxor%ebx,%ebx
---
> 20e0: 31 db   xor%ebx,%ebx
> 20e2: 45 31 d2xor%r10d,%r10d

[Bug middle-end/51182] [ipa-iterations] running multiple passes of early IPA on a file produces different code when it shouldn't

2011-11-17 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51182

--- Comment #3 from Matt Hargett  2011-11-18 01:41:04 UTC 
---
Created attachment 25850
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25850
pre-procecessed source that produces better-performing code with two iterations

[Bug middle-end/51182] [ipa-iterations] running multiple passes of early IPA on a file produces different code when it shouldn't

2011-11-17 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51182

--- Comment #4 from Matt Hargett  2011-11-18 01:43:32 UTC 
---
Ah, okay. I read in your email you were looking for evidence of bugs, and the
behaviour looked fishy to me. Regardless, here is a performance improvement
that perhaps should be gotten within one iteration.

Attached is the combined.i from pmccabe, which can be compiled and linked
directly to be an executable (on a Debian/Ubuntu-ish amd64 system, anyway).

Using -O3 (or -Ofast), two iterations produces a binary that performs better
than just one iteration. Performance was measured at the macro level, based on
timings when run against tens of thousands of files while in single-user mode
on a ramdisk. In addition, performance at the micro level was measured by
looking at cache misses and branch misprediction rates using callgrind (a tool
within valgrind), with output below. The second iteration reduces the I1 miss
rate, as well as the misprediction rate. (Multiple iterations of -O2 is more of
a mixed bag at the micro level, for some reason, and appears to have no
macro-level performance impact.)


matt@matt-desktop:~/src/pmccabe-2.7$ valgrind --tool=callgrind --branch-sim=yes
--cache-sim=yes ./pmccabe.o3i1.loop.whopr *.c test0[012][0123456]

==4119== 
==4119== Events: Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw Bc Bcm Bi Bim
==4119== Collected : 10312284 2549768 1398563 3869 3209 1417 1285 2045 990
2534056 74514 208896 8052
==4119== 
==4119== I   refs:  10,312,284
==4119== I1  misses: 3,869
==4119== LLi misses: 1,285
==4119== I1  miss rate:0.3%
==4119== LLi miss rate:0.1%
==4119== 
==4119== D   refs:   3,948,331  (2,549,768 rd + 1,398,563 wr)
==4119== D1  misses: 4,626  (3,209 rd + 1,417 wr)
==4119== LLd misses: 3,035  (2,045 rd +   990 wr)
==4119== D1  miss rate:0.1% (  0.1%   +   0.1%  )
==4119== LLd miss rate:0.0% (  0.0%   +   0.0%  )
==4119== 
==4119== LL refs:8,495  (7,078 rd + 1,417 wr)
==4119== LL misses:  4,320  (3,330 rd +   990 wr)
==4119== LL miss rate: 0.0% (  0.0%   +   0.0%  )
==4119== 
==4119== Branches:   2,742,952  (2,534,056 cond +   208,896 ind)
==4119== Mispredicts:   82,566  (   74,514 cond + 8,052 ind)
==4119== Mispred rate: 3.0% (  2.9% +   3.8%   )


matt@matt-desktop:~/src/pmccabe-2.7$ valgrind --tool=callgrind --branch-sim=yes
--cache-sim=yes ./pmccabe.o3i2.loop.whopr *.c test0[012][0123456]

==4122== 
==4122== Events: Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw Bc Bcm Bi Bim
==4122== Collected : 10312147 2549768 1398563 3054 3209 1416 1286 2049 989
2534056 74071 208896 7618
==4122== 
==4122== I   refs:  10,312,147
==4122== I1  misses: 3,054
==4122== LLi misses: 1,286
==4122== I1  miss rate:0.2%
==4122== LLi miss rate:0.1%
==4122== 
==4122== D   refs:   3,948,331  (2,549,768 rd + 1,398,563 wr)
==4122== D1  misses: 4,625  (3,209 rd + 1,416 wr)
==4122== LLd misses: 3,038  (2,049 rd +   989 wr)
==4122== D1  miss rate:0.1% (  0.1%   +   0.1%  )
==4122== LLd miss rate:0.0% (  0.0%   +   0.0%  )
==4122== 
==4122== LL refs:7,679  (6,263 rd + 1,416 wr)
==4122== LL misses:  4,324  (3,335 rd +   989 wr)
==4122== LL miss rate: 0.0% (  0.0%   +   0.0%  )
==4122== 
==4122== Branches:   2,742,952  (2,534,056 cond +   208,896 ind)
==4122== Mispredicts:   81,689  (   74,071 cond + 7,618 ind)
==4122== Mispred rate: 2.9% (  2.9% +   3.6%   )

[Bug bootstrap/51232] New: building the all-stage1 target requires several invocations to complete

2011-11-19 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51232

 Bug #: 51232
   Summary: building the all-stage1 target requires several
invocations to complete
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


As mentioned here:
http://gcc.gnu.org/ml/gcc-help/2011-11/msg00193.html

../configure --enable-bootstrap --prefix=/home/matt --enable-clocale=gnu
--with-system-zlib --enable-shared --with-demangler-in-ld --enable-lto
--with-build-config=bootstrap-lto --with-fpmath=sse
--enable-languages=c,c++,lto

'make all-stage1' has to be run several times in order to complete. there's no
errors, it just stops. it sometimes stops in different places depending on -j.

I sometimes get weird, difficult-to-reproduce bootstrap failures with -j8, and
this may be one of the root problems.

As mentioned in the thread, the same issue happens for "make
configure-stage2-gcc", which requires at least two runs. I can file that in a
separate bug, upon request.

Both Ian and I had the same issue, and while I'm unsure about his build
environment, mine is Ubuntu 11.10/amd64.

[Bug middle-end/51233] New: [ipa-iterations] running multiple passes of early IPA on zlib produces more optimal code

2011-11-19 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233

 Bug #: 51233
   Summary: [ipa-iterations] running multiple passes of early IPA
on zlib produces more optimal code
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


Using current trunk, with Maxim's eipa-iterations patch. I modified the zlib
1.2.3.4 makefile (from Ubuntu 11.10's source package) as such for building on
my Ubuntu 11.10/amd64 system:

CC=gcc
CFLAGS=--param eipa-iterations=3 -flto -Ofast
SFLAGS=$(CFLAGS) -shared -fPIC
LDFLAGS=-flto -L. libz.a

And then built and tested the resulting minigzip utility both at the
macro-level (total runtime), and the micro-level (using callgrind's cache miss
and branch misprediction benchmarks). Macro level, when run a single 50MB file
on a ramdisk in single user mode shows minor improvements that may qualify as
noise. At the micro level, callgrind shows 0.4% fewer branch mispredictions,
and a dramatic decrease in data accesses (but a slight uptick in data cache
misses).

While there are some notable code differences between 2 and 3 iterations, they
don't appear to have an effect on the performance at the macro- or micro-level.

Given the relative simplicity of the code in the library, these additional
optimizations could possibly have been gotten within a single iteration.

[Bug middle-end/51263] ICE in inline_small_functions when compiling scummvm with -O2 -flto

2011-11-21 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51263

--- Comment #1 from Matt Hargett  2011-11-21 23:58:48 UTC 
---
Created attachment 25876
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25876
pre-processed source of the file that triggers the ICE

[Bug middle-end/51263] New: ICE in inline_small_functions when compiling scummvm with -O2 -flto

2011-11-21 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51263

 Bug #: 51263
   Summary: ICE in inline_small_functions when compiling scummvm
with -O2 -flto
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


With current trunk, compiling scummvm 1.4.0
(http://prdownloads.sourceforge.net/scummvm/scummvm-1.4.0.tar.bz2?download):

$ CXXFLAGS="-O2 -flto" CFLAGS="-O2 -flto" ./configure --enable-all-engines

Running ScummVM configure...
[...]

$ make

[...]

engines/parallaction/balloons.cpp:756:1: internal compiler error: in
inline_small_functions, at ipa-inline.c:1421

with -j7, this one happens first, but is likely the same root issue:

In file included from video/smk_decoder.cpp:37:0:
./audio/audiostream.h:303:7: internal compiler error: in
inline_small_functions, at ipa-inline.c:1421

I tried reproducing with just -O1 -finline-small-functions, but that didn't
trip the issue.

Pre-processed source file attached, reproduce by:
bunzip2 balloons.i.bz2
g++ -O2 balloons.i

[Bug tree-optimization/50561] [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine

2011-12-09 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561

--- Comment #3 from Matt Hargett  2011-12-10 01:38:00 UTC 
---
Just re-verified that this is still a problem with trunk as of 2011-12-09.

[Bug tree-optimization/51493] New: [4.7 regression] ICE when compiling scummvm with -O2 and any graphite optimization

2011-12-09 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51493

 Bug #: 51493
   Summary: [4.7 regression] ICE when compiling scummvm with -O2
and any graphite optimization
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


With trunk as of 2011-12-09, on Ubuntu 11.10/amd64.

I was able to reproduce what *appears to be* the issue on the individual file
(pre-processed source attached), but only with a specific set of configure
flags to scummvm. An alternate testcase involving LTO is also here, which I can
split out to a separate bug if need be.

$ g++ -O2 -floop-block res_ami.i
engines/agos/res_ami.cpp: In member function ‘byte*
AGOS::AGOSEngine::convertImage(AGOS::VC10_state*, bool)’:
engines/agos/res_ami.cpp:143:7: internal compiler error: in
scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633

Note that pretty much any loop-based flag will trigger the issue. Only using
-O2, or using -O1 with -floop-* works around the crash. When running the above
test case under valgrind, I see:
==21219== Conditional jump or move depends on uninitialised value(s)
==21219==at 0xD02445: refs_may_alias_p_1(ao_ref_s*, ao_ref_s*, bool)
(tree-ssa-alias.c:1027)
==21219==by 0xA92139: stmt_may_clobber_ref_p_1(gimple_statement_d*,
ao_ref_s*) (tree-ssa-alias.c:1762)
==21219==by 0xA92210:
_ZL20walk_aliased_vdefs_1P8ao_ref_sP9tree_nodePFbS0_S2_PvES3_PP15bitmap_head_defj.955263.constprop.2845.16875
(tree-ssa-alias.c:2158)
==21219==by 0xA9238D: walk_aliased_vdefs(ao_ref_s*, tree_node*, bool
(*)(ao_ref_s*, tree_node*, void*), void*, bitmap_head_def**)
(tree-ssa-alias.c:2178)
==21219==by 0xA9335E:
_ZL20detect_type_change_1P9tree_nodeS0_S0_P18gimple_statement_dP13ipa_jump_funcl.498561.15992
(ipa-prop.c:460)
==21219==by 0xA9634B: ipa_analyze_node(cgraph_node*) (ipa-prop.c:1505)
==21219==by 0xA96F88: _ZL21ipcp_generate_summaryv.1445752 (ipa-cp.c:2490)
==21219==by 0xE3AF25: execute_ipa_summary_passes(ipa_opt_pass_d*)
(passes.c:1888)
==21219==by 0x9912C6: cgraph_optimize() (cgraphunit.c:2059)
==21219==by 0x991559: cgraph_finalize_compilation_unit()
(cgraphunit.c:1327)
==21219==by 0xCE3EBA: cp_write_global_declarations() (decl2.c:4050)
==21219==by 0xC8DA2F: toplev_main(int, char**) (toplev.c:573)
==21219==  Uninitialised value was created by a stack allocation
==21219==at 0xA934ED:
_ZL22detect_type_change_ssaP9tree_nodeP18gimple_statement_dP13ipa_jump_func.498569.15987
(ipa-prop.c:511)



The ICE is on any graphite-related flag and has potentally related valgrind
output; Otherwise, I would think this is a regression of PR42930 (which it may
actually be).

to reproduce with LTO:
-get latest scummvm sources, unpack and cd into the dir
-CXX=/path/to/gcc-trunk/bin/g++ CXXFLAGS="-O2 -flto -floop-block" LDFLAGS="-O2
-flto -floop-block" ./configure --disable-all-engines --enable-agos

-make
-during final link

result:
In file included from :422:0:
engines/agos/res_ami.cpp: In member function ‘convertImage’:
engines/agos/res_ami.cpp:143:0: internal compiler error: in
scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633

NOTE: looks like the fully qualified class name gets clobbered during LTO :(
I'll file in a separate bug.

[Bug middle-end/50913] [4.7 Regression] ICE in scan_tree_for_params_right_scev, at graphite-sese-to-poly.c:633 compiling libgfortran with -floop-interchange -m32

2011-12-09 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913

Matt Hargett  changed:

   What|Removed |Added

 CC||matt at use dot net

--- Comment #6 from Matt Hargett  2011-12-10 03:23:51 UTC 
---
I ran into this as well when compiling scummvm with "-O2 -floop-block". I can't
tell, but it may be a regression of PR42930. I filed a new bug as PR51943. If
this bug turns out to be a duplicate of PR51943, let me know and I'll add the
relevant info to this bug.

One way to tell is if you see this approximate valgrind output when reproducing
your testcase:

==21219== Conditional jump or move depends on uninitialised value(s)
==21219==at 0xD02445: refs_may_alias_p_1(ao_ref_s*, ao_ref_s*, bool)
(tree-ssa-alias.c:1027)
==21219==by 0xA92139: stmt_may_clobber_ref_p_1(gimple_statement_d*,
ao_ref_s*) (tree-ssa-alias.c:1762)
==21219==by 0xA92210:
_ZL20walk_aliased_vdefs_1P8ao_ref_sP9tree_nodePFbS0_S2_PvES3_PP15bitmap_head_defj.955263.constprop.2845.16875
(tree-ssa-alias.c:2158)
==21219==by 0xA9238D: walk_aliased_vdefs(ao_ref_s*, tree_node*, bool
(*)(ao_ref_s*, tree_node*, void*), void*, bitmap_head_def**)
(tree-ssa-alias.c:2178)
==21219==by 0xA9335E:
_ZL20detect_type_change_1P9tree_nodeS0_S0_P18gimple_statement_dP13ipa_jump_funcl.498561.15992
(ipa-prop.c:460)
==21219==by 0xA9634B: ipa_analyze_node(cgraph_node*) (ipa-prop.c:1505)
==21219==by 0xA96F88: _ZL21ipcp_generate_summaryv.1445752 (ipa-cp.c:2490)
==21219==by 0xE3AF25: execute_ipa_summary_passes(ipa_opt_pass_d*)
(passes.c:1888)
==21219==by 0x9912C6: cgraph_optimize() (cgraphunit.c:2059)
==21219==by 0x991559: cgraph_finalize_compilation_unit()
(cgraphunit.c:1327)
==21219==by 0xCE3EBA: cp_write_global_declarations() (decl2.c:4050)
==21219==by 0xC8DA2F: toplev_main(int, char**) (toplev.c:573)
==21219==  Uninitialised value was created by a stack allocation
==21219==at 0xA934ED:
_ZL22detect_type_change_ssaP9tree_nodeP18gimple_statement_dP13ipa_jump_func.498569.15987
(ipa-prop.c:511)

[Bug tree-optimization/51493] [4.7 regression] ICE when compiling scummvm with -O2 and any graphite optimization

2011-12-09 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51493

--- Comment #1 from Matt Hargett  2011-12-10 03:24:45 UTC 
---
Created attachment 26039
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26039
pre-processed source of the file that triggers the ICE when compiled with -O2
-floop-block

[Bug c/51542] New: bootstrap failure due to uninitialized variable use in c-parser

2011-12-13 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51542

 Bug #: 51542
   Summary: bootstrap failure due to uninitialized variable use in
c-parser
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


I checked by hand, and this looks real to me. It doesn't come up without
-O[3,fast] and LTO probably due to a lack of inlining that limits visibility of
the analysis.

NOTE: I have hand-modified my build/bootstrap-lto.mk to use -Ofast

$ ~/src/gcc-trunk/configure --enable-bootstrap --prefix=/home/matt
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-lto
--with-fpmath=sse --enable-languages=c,c++,lto
--with-build-config=bootstrap-lto --enable-build-with-cxx --disable-libmudflap
--with-cpu=core2 --with-tune=core2 --disable-libssp

$ make -j7 profiledbootstrap

/home/matt/src/gcc-trunk/gcc/c-parser.c: In function ‘c_expr
c_parser_postfix_expression_after_primary(c_parser*, location_t, c_expr)’:
/home/matt/src/gcc-trunk/gcc/c-parser.c:6880:16: error: ‘origtypes’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]

[Bug middle-end/51544] New: uninitialized variable false positive prevents bootstrap at -O3

2011-12-13 Thread matt at use dot net

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51544

 Bug #: 51544
   Summary: uninitialized variable false positive prevents
bootstrap at -O3
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


I checked by hand, and this looks like a false positive to me. It doesn't come
up without
-O[3,fast].

NOTE: I have hand-modified my build/bootstrap-lto.mk to use -Ofast. It's
possible that using the bootstrap-O3 build-config will reproduce it as well.

$ ~/src/gcc-trunk/configure --enable-bootstrap --prefix=/home/matt
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-lto
--with-fpmath=sse --enable-languages=c,c++,lto
--with-build-config=bootstrap-lto --enable-build-with-cxx --disable-libmudflap
--with-cpu=core2 --with-tune=core2 --disable-libssp

$ make -j7 profiledbootstrap

/home/matt/src/gcc-trunk/gcc/cp/parser.c: In function ‘bool
cp_parser_ctor_initializer_opt_and_function_body(cp_parser*)’:
/home/matt/src/gcc-trunk/gcc/cp/parser.c:17533:43: error: ‘list’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]

1 2 3 >

1 - 100 of 238 matches

Mail list logo