[Bug target/56309] -O3 optimizer generates conditional moves instead of compare and branch resulting in almost 2x slower code

[izamyatin at gmail dot com]

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



--- Comment #21 from Igor Zamyatin  2013-02-15 
06:49:53 UTC ---

(In reply to comment #18)

> Following patch is a big hammer approach to the problem, intended only for

> benchmarking

> 

> --cut here--

> Index: common/config/i386/i386-common.c

> ===

> --- common/config/i386/i386-common.c(revision 195988)

> +++ common/config/i386/i386-common.c(working copy)

> @@ -710,6 +710,8 @@

>  /* Turn off -fschedule-insns by default.  It tends to make the

> problem with not enough registers even worse.  */

>  { OPT_LEVELS_ALL, OPT_fschedule_insns, NULL, 0 },

> +/* Turn off -ftree-loop-if-convert by default.  */

> +{ OPT_LEVELS_ALL, OPT_ftree_loop_if_convert, NULL, 0 },

> 

>  #ifdef SUBTARGET_OPTIMIZATION_OPTIONS

>  SUBTARGET_OPTIMIZATION_OPTIONS,

> --cut here--

> 



But in this case we are giving up vectorization for some cases, aren't we?

[Bug target/56511] memcpy misses chance to use AVX instructions

[izamyatin at gmail dot com]

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



Igor Zamyatin  changed:



   What|Removed |Added



 CC||izamyatin at gmail dot com



--- Comment #3 from Igor Zamyatin  2013-03-04 
20:10:09 UTC ---

This seems to be the old issue with non-optimal memcpy,memset etc expanding for

x86. See for instance http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052.

There were some attempts to imrove that expanding (e.g. here -

http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00853.html) but with no success

yet.

[Bug target/56511] memcpy misses chance to use AVX instructions

[izamyatin at gmail dot com]

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



--- Comment #4 from Igor Zamyatin  2013-03-07 
08:52:53 UTC ---

Doesn't first argument of memcpy which is called from memcpy_vec have unknown

(1byte) alignment? If yes, how PPC managed to produce vector instructions?

[Bug fortran/55362] [4.6/4.7 Regression] ICE with size() on character pointer

[izamyatin at gmail dot com]

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



Igor Zamyatin  changed:



   What|Removed |Added



 CC||izamyatin at gmail dot com



--- Comment #11 from Igor Zamyatin  2013-03-11 
06:20:02 UTC ---

r196583 seems to break 4_6 branch bootstrap with



/export/gnu/import/git/gcc-test/bld/./prev-gcc/xgcc

-B/export/gnu/import/git/gcc-test/bld/./prev-gcc/

-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/bin/

-B/usr/local/i686-pc-linux-gnu/lib/ -isystem

/usr/local/i686-pc-linux-gnu/include -isystem

/usr/local/i686-pc-linux-gnu/sys-include-c  -DIN_GCC_FRONTEND -g -O2

-fomit-frame-pointer -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual

-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic

-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings

-Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -Ifortran

-I../../src-4.6/gcc -I../../src-4.6/gcc/fortran -I../../src-4.6/gcc/../include

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

-I../../src-4.6/gcc/../libdecnumber/bid -I../libdecnumber   

../../src-4.6/gcc/fortran/check.c -o fortran/check.o

../../src-4.6/gcc/fortran/check.c: In function 'array_check':

../../src-4.6/gcc/fortran/check.c:268:50: error: expected statement before ')'

token

make[6]: *** [fortran/check.o] Error 1

[Bug target/56676] unnecesary splitted load when using avx2

[izamyatin at gmail dot com]

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



Igor Zamyatin  changed:



   What|Removed |Added



 CC||izamyatin at gmail dot com



--- Comment #4 from Igor Zamyatin  2013-03-21 
15:18:24 UTC ---

We (at Intel) used to try to remove splitting for avx2 but saw no reasonable

gains in general

[Bug middle-end/56680] New: ICE for spec2K's 178.galgel and 200.sixtrack for x86_64 at O3

[izamyatin at gmail dot com]

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



 Bug #: 56680

   Summary: ICE for spec2K's 178.galgel and 200.sixtrack for

x86_64 at O3

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

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

ReportedBy: izamya...@gmail.com





On Linux/x86-64, for O3 level revision  

Author: rguenth

Date: Wed Mar 20 09:01:52 2013

New Revision: 196810



URL: http://gcc.gnu.org/viewcvs?rev=196810&root=gcc&view=rev

Log:

2013-03-20  Richard Biener  



* tree-vect-loop-manip.c (slpeel_can_duplicate_loop_p): Do not

check whether an SSA update is needed.





produces ICE for 178 and 200:

internal compiler error: tree check: expected ssa_name, have var_decl in

verify_ssa, at tree-ssa.c:1008



0xb2ff0a tree_check_failed(tree_node const*, char const*, int, char const*,

...)

../../gcc/tree.c:8944

0xac92da tree_check

../../gcc/tree.h:3684

0xac92da verify_ssa(bool)

../../gcc/tree-ssa.c:1008

0x8a9f82 execute_function_todo

../../gcc/passes.c:1964

0x8aa96d execute_todo

../../gcc/passes.c:1996

[Bug c++/34949] Dead code in empty destructors.

[izamyatin at gmail dot com]

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



Igor Zamyatin  changed:



   What|Removed |Added



 CC||izamyatin at gmail dot com



--- Comment #27 from Igor Zamyatin  2013-04-04 
07:18:07 UTC ---

Still, I see that r197375 breaks spec2006/483.xalancbmk compilation:



g++ -mavx  -static -c -o DOMDocumentImpl.o -DSPEC_CPU -DNDEBUG 

-DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom

-Ixercesc/dom/impl -Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory

-Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER

-DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM

-DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER -O3

-funroll-loops -ffast-math -march=corei7   -DSPEC_CPU_LP64  -DSPEC_CPU_LINUX   

 DOMDocumentImpl.cpp



DOMDocumentImpl.cpp: In destructor

'xercesc_2_5::DOMDocumentImpl::~DOMDocumentImpl()':

DOMDocumentImpl.cpp:207:1: error: definition in block 47 does not dominate use

in block 92

 DOMDocumentImpl::~DOMDocumentImpl()

 ^

for SSA_NAME: _36 in statement:

# .MEM_250 = VDEF <.MEM_8>

MEM[(struct BaseRefVectorOf *)_36 + 8B] ={v} {CLOBBER};

DOMDocumentImpl.cpp:207:1: internal compiler error: verify_ssa failed

0xc06b54 verify_ssa(bool)

../../gcc/tree-ssa.c:1046

0x9e6662 execute_function_todo

../../gcc/passes.c:1964

0x9e704d execute_todo

../../gcc/passes.c:1996

[Bug rtl-optimization/56885] ICE: in assign_by_spills, at lra-assigns.c:1268 with -O -fschedule-insns -fselective-scheduling

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #3 from Igor Zamyatin  2013-04-09 
06:58:22 UTC ---
(In reply to comment #1)
> Confirmed with trunk/4.8, but with 4.6/4.7 I see:
> 
> x.c:20:1: error: unable to find a register to spill in class ‘DIREG’
> x.c:20:1: error: this is the insn:
> (insn 33 36 35 5 (parallel [
> (set (reg:DI 2 cx [80])
> (const_int 0 [0]))
> (set (reg/f:DI 0 ax [78])
> (plus:DI (reg/f:DI 1 dx [77])
> (reg:DI 2 cx [80])))
> (set (mem:BLK (reg/f:DI 1 dx [77]) [0 S15 A8])
> (const_int 0 [0]))
> (use (reg:QI 6 bp [81]))
> (use (reg:DI 2 cx [80]))
> ]) x.c:16 884 {*rep_stosqi}
>  (expr_list:REG_DEAD (reg/f:DI 1 dx [77])
> (expr_list:REG_UNUSED (reg:DI 2 cx [80])
> (expr_list:REG_UNUSED (reg/f:DI 0 ax [78])
> (nil)
> x.c:20: confused by earlier errors, bailing out

The same error on 4.9 when IRA is turned on

[Bug rtl-optimization/56885] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1268 with -O -fschedule-insns -fselective-scheduling

[izamyatin at gmail dot com]

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



Igor Zamyatin  changed:



   What|Removed |Added



 CC||ysrumyan at gmail dot com



--- Comment #4 from Igor Zamyatin  2013-04-09 
10:53:09 UTC ---

Adding the author of the changes that fix failures of pre-alloc scheduler

[Bug lto/57084] New: 483. xalancbmk run fails with -O2 -flto for i686

[izamyatin at gmail dot com]

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



 Bug #: 57084

   Summary: 483. xalancbmk run fails with -O2 -flto for i686

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: lto

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

ReportedBy: izamya...@gmail.com





Happens after r198088



More precise flags:

-m32 -flto -O2 -msse2 -mfpmath=sse -ffast-math -march=corei7

[Bug tree-optimization/57124] New: 254.gap@spec2000 got miscompare after r198413

[izamyatin at gmail dot com]

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



 Bug #: 57124

   Summary: 254.gap@spec2000 got miscompare after r198413

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: tree-optimization

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

ReportedBy: izamya...@gmail.com





Happens for example for option set "-O2 -ffast-math -march=corei7".



Unfortunately, now have no possibility to make some reproducer

[Bug tree-optimization/57124] 254.gap@spec2000 got miscompare after r198413

[izamyatin at gmail dot com]

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

--- Comment #5 from Igor Zamyatin  ---
Indeed, -fwrapv helps to run 254.gap successfully

[Bug lto/54095] Unnecessary static variable renaming

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #18 from Igor Zamyatin  ---
Fix seems to break compilation of 176.gcc from spec2000 with -O2 -flto on x86:

`n_occurrences' referenced in section `.text' of
/tmp/ccnjpEMk.ltrans14.ltrans.o: defined in discarded section `.text' of
reload.o (symbol from plugin)
collect2: error: ld returned 1 exit status

[Bug rtl-optimization/53942] [4.6/4.7/4.8 Regression] unable to find a register to spill in class 'CREG'

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #6 from Igor Zamyatin  2012-08-10 
14:40:53 UTC ---
So trunk is ok. Any plans to backport changes to 4.7 and 4.6 and close this?

[Bug tree-optimization/54200] copyrename generates wrong debuginfo

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #9 from Igor Zamyatin  2012-08-13 
12:13:54 UTC ---
I see following in report for x86:

FAIL: gcc.dg/guality/pr54200.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 20 z == 3

[Bug tree-optimization/54200] copyrename generates wrong debuginfo

[izamyatin at gmail dot com]

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

--- Comment #11 from Igor Zamyatin  2012-08-13 
12:46:48 UTC ---
Right! Sorry for the noise...

[Bug debug/53671] [4.8 Regression] Many guality test failures

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #11 from Igor Zamyatin  2012-08-22 
10:13:03 UTC ---
For r190586:

FAIL: gfortran.dg/guality/pr41558.f90  -O0  line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O1  line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O2  line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O3 -fomit-frame-pointer  line 7 s ==
'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O3 -fomit-frame-pointer -funroll-loops 
line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -O3 -g  line 7 s == 'foo'
FAIL: gfortran.dg/guality/pr41558.f90  -Os  line 7 s == 'foo'

[Bug debug/53671] [4.8 Regression] Many guality test failures

[izamyatin at gmail dot com]

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

--- Comment #14 from Igor Zamyatin  2012-08-22 
11:24:17 UTC ---
Thanks!

[Bug regression/54390] New: [AVX] FAIL: gcc.dg/vect/no-tree-sra-bb-slp-pr50730.c

[izamyatin at gmail dot com]

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

 Bug #: 54390
   Summary: [AVX] FAIL: gcc.dg/vect/no-tree-sra-bb-slp-pr50730.c
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com


For avx target on x86_64 there is one fail introduced by r190492:

FAIL: gcc.dg/vect/no-tree-sra-bb-slp-pr50730.c scan-tree-dump-times slp "not
vectorized: more than one data ref in stmt" 0

r190492:

Author: hjl 
Date:   Fri Aug 17 19:59:46 2012 +

Define MAX_FIXED_MODE_SIZE/TARGET_MEMBER_TYPE_FORCES_BLK for i386

[Bug rtl-optimization/50557] [4.7/4.8 Regression] Register pressure increase after reassociation (x86, 32 bits)

[izamyatin at gmail dot com]

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



--- Comment #16 from Igor Zamyatin  2012-10-04 
11:17:00 UTC ---

Seems with LRA code is fast again

[Bug tree-optimization/54889] New: [4.8 Regression] Revision 191983 gives compfail for 465.tonto in SPEC CPU 2006 when use -O3 -mavx

[izamyatin at gmail dot com]

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

 Bug #: 54889
   Summary: [4.8 Regression] Revision 191983 gives compfail for
465.tonto in SPEC CPU 2006 when use -O3 -mavx
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com


Revision 191983 gives

gfortran -c -o binmat.fppized.o -O3binmat.fppized.f90 -mavx

binmat.fppized.f90: In function ‘expand’:
binmat.fppized.f90:268:0: error: incorrect type of vector CONSTRUCTOR elements
subroutine expand(self,dim1,dim2)
 ^
{_211, _213, _215, _217, _219, _221, _223, _225}

vect_cst_.193_227 = {_211, _213, _215, _217, _219, _221, _223, _225};

binmat.fppized.f90:268:0: internal compiler error: verify_gimple failed
0x9498ac verify_gimple_in_cfg(function*)
../../gcc/tree-cfg.c:4727
0x886b88 execute_function_todo
../../gcc/passes.c:1956
0x8878ad execute_todo
../../gcc/passes.c:1989
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Without -mavx compilation is fine

[Bug tree-optimization/54889] [4.8 Regression] Revision 191983 gives compfail for 465.tonto in SPEC CPU 2006 when use -O3 -mavx

[izamyatin at gmail dot com]

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



--- Comment #2 from Igor Zamyatin  2012-10-11 
11:40:39 UTC ---

Now I see no compfails on the whole spec test 465

[Bug tree-optimization/54889] [4.8 Regression] Revision 191983 gives compfail for 465.tonto in SPEC CPU 2006 when use -O3 -mavx

[izamyatin at gmail dot com]

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



--- Comment #3 from Igor Zamyatin  2012-10-16 
11:12:47 UTC ---

Jakub, are you going to commit the fix or there are some issues with it?

[Bug tree-optimization/54942] [4.8 Regression] ICE: OOM with -O3 -fno-cse-follow-jumps -funroll-loops

[izamyatin at gmail dot com]

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



Igor Zamyatin  changed:



   What|Removed |Added



 CC||izamyatin at gmail dot com



--- Comment #2 from Igor Zamyatin  2012-10-17 
05:30:47 UTC ---

I see similar for r192219

[Bug rtl-optimization/54944] 400.perlbench fails with segmentation fault

[izamyatin at gmail dot com]

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



Igor Zamyatin  changed:



   What|Removed |Added



 CC||izamyatin at gmail dot com



--- Comment #1 from Igor Zamyatin  2012-10-17 
11:36:00 UTC ---

Probably this is a dup of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54942

[Bug rtl-optimization/54942] [4.8 Regression] ICE: OOM with -O3 -fno-cse-follow-jumps -funroll-loops

[izamyatin at gmail dot com]

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



--- Comment #4 from Igor Zamyatin  2012-10-23 
08:52:30 UTC ---

Does it still happen? I don't see oom now for my test

[Bug rtl-optimization/54472] ICE (spill_failure): unable to find a register to spill in class 'AREG' with -O -fschedule-insns -fselective-scheduling

[izamyatin at gmail dot com]

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



--- Comment #6 from Igor Zamyatin  2012-10-24 
11:09:49 UTC ---

Have you managed to check the patch?

[Bug tree-optimization/55104] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:269

[izamyatin at gmail dot com]

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



Igor Zamyatin  changed:



   What|Removed |Added



 CC||izamyatin at gmail dot com



--- Comment #1 from Igor Zamyatin  2012-10-29 
15:22:50 UTC ---

Caused by r192821

[Bug tree-optimization/55006] [4.8 Regression] aermod.f90 is miscompiled with '-m64 -O2 -funroll-loops' after revision 192526

[izamyatin at gmail dot com]

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



Igor Zamyatin  changed:



   What|Removed |Added



 CC||izamyatin at gmail dot com



--- Comment #3 from Igor Zamyatin  2012-10-29 
19:25:26 UTC ---

It's also can be seen for x86_64-unknown-linux-gnu. In particular, 447.dealII

fails with -O3 and -funroll-loops

[Bug tree-optimization/54985] [4.7/4.8 Regression] dom optimization erroneous remove conditional goto.

[izamyatin at gmail dot com]

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



--- Comment #11 from Igor Zamyatin  2012-10-30 
08:32:01 UTC ---

Are there any plans to backport this to 4.7?

[Bug lto/57289] New: ICE during 454.calculix compilation with -O3 -flto

[izamyatin at gmail dot com]

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

Bug ID: 57289
   Summary: ICE during 454.calculix compilation with -O3 -flto
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
CC: mjambor at suse dot cz
Target: x86

Happens due to r198821.

Fail:
lto1: internal compiler error: in propagate_controlled_uses, at ipa-prop.c:2552
0x71753f propagate_controlled_uses
../../gcc/ipa-prop.c:2551
0x71753f ipa_propagate_indirect_call_infos(cgraph_edge*, vec*)
../../gcc/ipa-prop.c:2659
0x70fe24 inline_call(cgraph_edge*, bool, vec*,
int*, bool)
../../gcc/ipa-inline-transform.c:255
0x7010d7 inline_small_functions
../../gcc/ipa-inline.c:1613
0x7010d7 ipa_inline
../../gcc/ipa-inline.c:1794
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: gfortran returned 1 exit status
/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug tree-optimization/57337] New: 416.gamess ICE on x86 after r199048

[izamyatin at gmail dot com]

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

Bug ID: 57337
   Summary: 416.gamess ICE on x86 after r199048
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
CC: eraman at google dot com
Target: x86

gfortran  -c -o mp2ddi.fppized.o -O2 -ffast-math -ffixed-form mp2ddi.fppized.f

mp2ddi.fppized.f: In function 'pmp2chk':
mp2ddi.fppized.f:5365:0: error: definition in block 11 follows the use
   SUBROUTINE PMP2CHK
 ^
for SSA_NAME: _314 in statement:
_319 = _314 + _320;
mp2ddi.fppized.f:5365:0: internal compiler error: verify_ssa failed
0xaf0aa4 verify_ssa(bool)
../../gcc/tree-ssa.c:1046
0x8c3e72 execute_function_todo
../../gcc/passes.c:1970
0x8c47cd execute_todo
../../gcc/passes.c:2002
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
specmake: *** [mp2ddi.fppized.o] Error 1

[Bug tree-optimization/57349] New: ICE on 253.perlbmk with pgo after r198096

[izamyatin at gmail dot com]

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

Bug ID: 57349
   Summary: ICE on 253.perlbmk with pgo after r198096
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
CC: rguenther at suse dot de
Target: x86

Output:
gcc  -c -o perl.o   -DSPEC_CPU2000_LP64 -DSPEC_CPU2000_LINUX_I386
-DSPEC_CPU2000_NEED_BOOL -DSPEC_CPU2000_GLIBC22-fprofile-use   -O3
-ffast-math -funroll-loops   perl.c
Error from fdo_make_pass2 'specmake  FDO=PASS2 build > fdo_make_pass2.out 2>
fdo_make_pass2.err':

Unable to coalesce ssa_names 1 and 7 which are marked as MUST COALESCE.
argc_1(ab) and  argc_7(ab)
perl.c: In function 'perl_parse':
perl.c:630:1: internal compiler error: SSA corruption
 perl_parse(PerlInterpreter *sv_interp, void (*xsinit) (void), int argc, char
**argv, char **env)
 ^
0x9c56dd fail_abnormal_edge_coalesce
../../gcc/tree-ssa-coalesce.c:898
0x9c56dd coalesce_partitions
../../gcc/tree-ssa-coalesce.c:1200
0x9c56dd coalesce_ssa_name()
../../gcc/tree-ssa-coalesce.c:1337
0x97eaff remove_ssa_form
../../gcc/tree-outof-ssa.c:900
0x97eaff rewrite_out_of_ssa(ssaexpand*)
../../gcc/tree-outof-ssa.c:1133
0x5fdeca gimple_expand_cfg
../../gcc/cfgexpand.c:4541
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
specmake: *** [perl.o] Error 1

Issue seems related to http://gcc.gnu.org/ml/gcc/2013-05/msg00162.html.
although I haven't managed to make reproducer so far

[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #2 from Igor Zamyatin  ---
Dup of PR57337?

[Bug tree-optimization/57337] [4.9 Regression] 416.gamess ICE on x86 after r199048

[izamyatin at gmail dot com]

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

--- Comment #4 from Igor Zamyatin  ---
For the record - 191.fma3d from spec2K fails with similar error

[Bug rtl-optimization/57447] New: [4.9 Regression] ICE on 435.gromacs from spec2006 after r199298

[izamyatin at gmail dot com]

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

Bug ID: 57447
   Summary: [4.9 Regression] ICE on 435.gromacs from spec2006
after r199298
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
CC: vmakarov at redhat dot com
Target: x86_64

Happens only on x86_64 with just "-O2 -ffast-math" flags:


comlib.c: In function 'put_serverbyte':
comlib.c:49:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3007
 }
 ^
0x80d66b curr_insn_transform
../../gcc/lra-constraints.c:3006
0x80e2a4 lra_constraints(bool)
../../gcc/lra-constraints.c:3785
0x800bf4 lra(_IO_FILE*)
../../gcc/lra.c:2278
0x7c7688 do_reload
../../gcc/ira.c:4641
0x7c7688 rest_of_handle_reload
../../gcc/ira.c:4753

[Bug c++/57208] Latest chromium compilation fails with enabled LTO

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #5 from Igor Zamyatin  ---
Probably it is ok now due to
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00198.html

[Bug lto/57554] New: [4.9 regression] 176.gcc built with -flto miscompared after r198917 for x86

[izamyatin at gmail dot com]

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

Bug ID: 57554
   Summary: [4.9 regression] 176.gcc built with -flto miscompared
after r198917 for x86
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
CC: jh at suse dot cz
Target: x86

Note that before r198917 there was compilation fail for this test.

Compile flags: -O3 -funroll-loops -ffast-math -flto

[Bug rtl-optimization/57468] [4.9 Regression] 26% performance drop on important benchmark after r199298.

[izamyatin at gmail dot com]

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

--- Comment #3 from Igor Zamyatin  ---
Patch is here http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00357.html

[Bug rtl-optimization/57468] [4.9 Regression] 26% performance drop on important benchmark after r199298.

[izamyatin at gmail dot com]

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

--- Comment #4 from Igor Zamyatin  ---
So following commit fixed the issue

commit 3620f4de1b49b0bfffe5f812b2d259e5c72c5c61
Author: vmakarov 
Date:   Thu Jun 6 21:12:06 2013 +

2013-06-06  Vladimir Makarov  

PR rtl-optimization/57468
* config/i386/i386.c (inline_secondary_memory_needed): Ignore
spilled pseudos.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@199764
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug lto/57602] New: Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422

[izamyatin at gmail dot com]

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

Bug ID: 57602
   Summary: Runfails for several C/C++ benchmarks from spec2000
for i686 with -flto after r199422
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
CC: jh at suse dot cz
Target: i686

For instance, 164.gzip has Segmentation fault. (tried on trunk, revision
200055)

Compiler options

-m32 -Ofast -flto -funroll-loops -msse2 -mfpmath=sse.

[Bug lto/57602] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422

[izamyatin at gmail dot com]

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

--- Comment #2 from Igor Zamyatin  ---
For both cases we have calls of static routines where address of some static
variable is being passed.

Since all this could be seen only for 32 bits, problem looks like some
attribute which allows the routine to pass parameters on registers lost
somewhere (but callee still rely on this fact).

[Bug lto/57602] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz

--- Comment #3 from Igor Zamyatin  ---
I believe the problem happens because cleanup that was made in
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01644.html
sometimes changes field 'analyzed' to 'symbol.definition' but at the same time
in other places to 'symbol.analyzed'.
It looks like 'symbol.definition' corresponds to the former 'finalized' field
not 'analyzed' and 'symbol.definition' are not always the same as
'symbol.analyzed'.

I'm attaching the patch (no bootstrap and make check testing though) which
fixes this (but not in all places across the compiler, sort of minimum
intrusion) and runfails disappeared with these changes.

Jan, could you please take a close look since now many x86 32-bit apps built
with lto are broken.

[Bug lto/57602] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422

[izamyatin at gmail dot com]

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

--- Comment #4 from Igor Zamyatin  ---
Created attachment 30377
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30377&action=edit
Untested patch that corrects the cleanup

[Bug lto/57602] Runfails for several C/C++ benchmarks from spec2000 for i686 with -flto after r199422

[izamyatin at gmail dot com]

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

--- Comment #6 from Igor Zamyatin  ---
Jan, have you had a chance to look at the problem?

[Bug lto/57879] GCC with -flto generates invalid code for genmddeps program

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #2 from Igor Zamyatin  ---
Dup of PR57602, I suppose

[Bug lto/58298] [4.9 regression] ICE in mentions_vars_p_field_decl, at lto/lto.c:1392

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #1 from Igor Zamyatin  ---
Fails for x86 also

[Bug target/50176] New: [4.6/4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[izamyatin at gmail dot com]

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

 Bug #: 50176
   Summary: [4.6/4.7 Regression] 4.7 generates spill-fill dealing
with char->int conversion
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com


Created attachment 25088
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25088
testcase for the problem

I observe that for attached testcase (made from one of tests from EEMBC 2.0
suite) 4.7 generates spill-fill pair when (I suspect) dealing with char->int
conversion while 4.6 doesn't generate them.

Asm for 4.7 for lines 42-47 from the testcase:

.LVL7:
# test_4_6.c:42
.loc 1 42 0 discriminator 2
movl8(%esp), %edx
# test_4_6.c:45
.loc 1 45 0 discriminator 2
movl0(,%edi,4), %esi
# test_4_6.c:42
.loc 1 42 0 discriminator 2
movzbl  (%edx,%eax), %edx< edx contains cb frome line 42
# test_4_6.c:40
.loc 1 40 0 discriminator 2
addl$1, %eax
# test_4_6.c:45
.loc 1 45 0 discriminator 2
addl%ebx, %esi
# test_4_6.c:42
.loc 1 42 0 discriminator 2
movb%dl, 3(%esp)  <- spill, line 42
.LVL8:
# test_4_6.c:45
.loc 1 45 0 discriminator 2
movzbl  (%esi), %edx
# test_4_6.c:47
.loc 1 47 0 discriminator 2
movzbl  3(%esp), %esi <- fill, line 47
# test_4_6.c:45
.loc 1 45 0 discriminator 2
movb%dl, (%ecx)
# test_4_6.c:47
.loc 1 47 0 discriminator 2
movl0(,%esi,4), %edx <--- using cb, line 47
addl0(,%edi,4), %edx
sarl$16, %edx
# test_4_6.c:46
.loc 1 46 0 discriminator 2
movzbl  (%ebx,%edx), %edx
# test_4_6.c:49
.loc 1 49 0 discriminator 2
addl0(,%esi,4), %ebx  <- using cb, line 49


 Meanwhile, 4.6 does not have such problem:

.LVL7:
# test_4_6.c:42
.loc 1 42 0 discriminator 2
movl4(%esp), %edx
movzbl  (%edx,%eax), %esi <-- esi=cb and is used later without spills
.LVL8:
# test_4_6.c:40
.loc 1 40 0 discriminator 2
addl$1, %eax
# test_4_6.c:45
.loc 1 45 0 discriminator 2
movl0(,%edi,4), %edx
addl%ebx, %edx
movzbl  (%edx), %edx
movb%dl, (%ecx)
# test_4_6.c:47
.loc 1 47 0 discriminator 2
movl0(,%esi,4), %edx< using cb, line 47
addl0(,%edi,4), %edx
sarl$16, %edx
# test_4_6.c:46
.loc 1 46 0 discriminator 2
movzbl  (%ebx,%edx), %edx
# test_4_6.c:49
.loc 1 49 0 discriminator 2
addl0(,%esi,4), %ebx   < using cb, line 49

 After expanding 4.7 contains:

(insn 52 51 53 6 (set (reg:QI 83 [ D.2723 ])
(mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ])
(reg/v:SI 117 [ col ])) [0 MEM[base: inptr1_19, index: col_90,
offset: 0B]+0 S1 A8])) test_4_6.c:42 -1
 (nil))

 and 4.6 contains

(insn 52 51 53 6 (parallel [
(set (reg/v:SI 86 [ cb ])
(zero_extend:SI (mem:QI (plus:SI (reg/v/f:SI 76 [ inptr1 ])
(reg/v:SI 78 [ col ])) [0 MEM[base: inptr1_19, 
index: col_22, offset: 0B]+0 S1 A8])))
(clobber (reg:CC 17 flags))
]) test_4_6.c:42 -1
 (nil))


Options are: -c -g -m32 -O2 test.c


GCC 4.6 is 

Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/export/users/izamyati/prefix
Thread model: posix
gcc version 4.6.0 20110215 (experimental) (GCC)

GCC 4.7 is 

Target: x86_64-unknown-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-languages=c,c++
--prefix=/export/users/izamyati/prefix_4_7
Thread model: posix
gcc version 4.7.0 20110824 (experimental) (GCC)

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[izamyatin at gmail dot com]

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

--- Comment #2 from Igor Zamyatin  2011-08-25 
13:17:36 UTC ---
For gcc with 
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-languages=c,c++
--prefix=/export/users/izamyati/gcc_4_6_2_prefix/
Thread model: posix
gcc version 4.6.2 20110825 (prerelease) (GCC)

everything is fine, no that spill-fill generated

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[izamyatin at gmail dot com]

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

--- Comment #5 from Igor Zamyatin  2011-08-29 
11:48:12 UTC ---
Yes, looks like this revision is the reason

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[izamyatin at gmail dot com]

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

--- Comment #7 from Igor Zamyatin  2011-09-14 
14:30:35 UTC ---
In RTL everythin is vice-versa, additional instruction appears:

For the "bad" case couple instructions are responsible for cb load (asmcons
dump):

(insn 52 51 53 5 (set (reg:QI 83 [ D.2685 ])
  (mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ])
  (reg/v:SI 117 [ col ])) [0 MEM[base: inptr1_19, index:
col_90, offset: 0B]+0 S1 A8])) ../test_bad_4_6.c:42 66 {*movqi_internal}
   (nil))

and later 

 (insn 62 61 122 5 (parallel [
  (set (reg:SI 152 [ D.2685 ])
  (zero_extend:SI (reg:QI 83 [ D.2685 ])))
  (clobber (reg:CC 17 flags))
  ]) ../test_bad_4_6.c:47 123 {*zero_extendqisi2_movzbl_and}
   (expr_list:REG_DEAD (reg:QI 83 [ D.2685 ])
  (expr_list:REG_UNUSED (reg:CC 17 flags)
  (nil


while in "good" case only one:

(insn 52 51 53 5 (parallel [
(set (reg/v:SI 84 [ cb ])
(zero_extend:SI (mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ])
(reg/v:SI 119 [ col ])) [0 MEM[base: inptr1_19,
index: col_90, offset: 0B]+0 S1 A8])))
(clobber (reg:CC 17 flags))
]) ../test_good_4_6.c:42 123 {*zero_extendqisi2_movzbl_and}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

 And life ranges in "bad" case became splitted:

 a34(r152): [71..82]
  
  a38(r83): [83..92]

 And in "good" case only:

  a34(r84): [71..90]

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #8 from Igor Zamyatin  2011-09-16 
14:35:34 UTC ---
I was checking coalescing part in IRA but it looks like coalescing is fine.

Adding Vladimir, maybe he could give some advice here

[Bug tree-optimization/50557] New: [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)

[izamyatin at gmail dot com]

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

 Bug #: 50557
   Summary: [4.7 Regression] Register pressure increase after
reassociation (x86, 32 bits)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com


After the fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49749
(http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176984) I observed a
degradation for the attached test. (~9% on Core)
Before the fix RA managed to use registers for code related to line #30. After
the fix an order of operations has been changed and this apparently led to
change in live ranges and hence to increased register pressure.

Asm snippet for fast case

# 4long.c:30
.loc 1 30 0
movl8(%ecx), %esi
xorl%edi, %edi
addl%eax, %esi
movl52(%esp), %eax
adcl%edx, %edi
mull8(%ebp)
addl%eax, %esi
adcl%edx, %edi

Asm snippet for slow case

# 4long.c:30
.loc 1 30 0
movl52(%esp), %eax
mull8(%ebp)
movl%eax, (%esp)
movl8(%ecx), %eax
movl%edx, 4(%esp)
xorl%edx, %edx
addl%eax, (%esp)
adcl%edx, 4(%esp)
addl%esi, (%esp)
adcl%edi, 4(%esp)

gcc is:
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-languages=c,c++
--prefix=/export/users/izamyati/build/
Thread model: posix
gcc version 4.7.0 20110731 (experimental) (GCC) 

Compilation flags:
-O2 -mssse3 -mfpmath=sse -ffast-math -m32

[Bug tree-optimization/50557] [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)

[izamyatin at gmail dot com]

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

--- Comment #1 from Igor Zamyatin  2011-09-28 
11:52:18 UTC ---
Created attachment 25373
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25373
testcase

[Bug tree-optimization/50557] [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)

[izamyatin at gmail dot com]

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

--- Comment #3 from Igor Zamyatin  2011-09-29 
08:34:45 UTC ---
William, thanks for quick response!

With -funroll-loops regression is still present.
Do you want me to attach some dumps?

[Bug tree-optimization/50557] [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)

[izamyatin at gmail dot com]

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

--- Comment #6 from Igor Zamyatin  2011-10-07 
10:33:33 UTC ---
Indeed, overall register pressure is not increased. Even before IRA dumps show
that register pressure is actually kept on the same level. 

Looks like it is a tricky case we met.

First, we can see that loop consists of 4 same group of instructions. The only
difference is the index value used by arrays in each group. Before the
reassociation improvement the group located on lines 30-33 of the attached test
for some reasons (I haven't checked this yet) got a different sequence of
instructions than others. After William's reassociation changes all groups got
similar sequence. (Maybe there were some good reason for that group to be
different? :) )

Now the tricky part.
In "fast" (i.e. before William's commit) version for group on lines 30-33 IRA
managed to hold "c" in eax register. Moreover because of shorter live range of
"c" IRA managed to reuse eax inside the operations of 30-th line. For others
group all work was made through memory. 
Since reassociation improvement made all groups to have the same look, we
unsurprisingly got memory instead of registers which led to the performance
drop.

That is sort of my vision of the whole picture. Any comments, ideas?

[Bug target/50164] [IRA, 4.7 Regression] Performance degradation due to increased memory instructions count

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #10 from Igor Zamyatin  2011-10-27 
20:28:47 UTC ---
I see that currently code for reproducer looks good. Surprisingly it happened
after revision 179275 (fix for PR 43864) which seems to be irrelevant here. And
indeed I have another test that shows a problem apparently in IRA or somewhere
near it. 
This new problem actually is not about regression so I suggest to close this
tracker and I will open another one once I prepare good test case.

[Bug rtl-optimization/50898] New: Register allocation depends on function return expression on x86 32-bits

[izamyatin at gmail dot com]

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

 Bug #: 50898
   Summary: Register allocation depends on function return
expression on x86 32-bits
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com


Created attachment 25643
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25643
Testcase

This problem has been noticed during investigation for PR50164.
For attached test case allocator's assignment of registers in some piece of
code depends on how return expression looks like. And it seems that there are
no reasons for this.

For attached case we have following code snippet obtained by fresh compiler:

.L13:
movzbl  (%esi), %ecx   
leal3(%esi), %ebp
movb%cl, 48(%esp)
notb48(%esp)
movzbl  1(%esi), %ecx
movzbl  2(%esi), %ebx
notl%ecx
notl%ebx
cmpb%cl, 48(%esp)
movl%ebp, %esi
movb%bl, 32(%esp)
jb  .L18
cmpb%cl, 32(%esp)
movzbl  32(%esp), %ebx
cmova   %ecx, %ebx
movl%ebx, %edi
jmp .L10


But if return expression turn to "return 0" we will see following code which is
actually more optimal:

.L13:
movzbl  (%esi), %edx  <--- edx is used instead of ecx
leal3(%esi), %ebp
movzbl  1(%esi), %ecx
notl%edx
movzbl  2(%esi), %ebx
notl%ecx
notl%ebx
cmpb%cl, %dl
movl%ebp, %esi
movb%dl, 48(%esp)
movb%bl, 32(%esp)
jb  .L18
cmpb%cl, 32(%esp)
movzbl  32(%esp), %ebx
cmova   %ecx, %ebx
movl%ebx, %edi
jmp .L10


 So for some reasons in the first case edx is not used and code contains more
memory instructions.

 gcc -v:
Using built-in specs.
COLLECT_GCC=/export/users/izamyati/compiler/build/bin/gcc
COLLECT_LTO_WRAPPER=/export/users/izamyati/compiler/build/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-languages=c,c++
--prefix=/export/users/izamyati/compiler/build/
Thread model: posix
gcc version 4.7.0 20111026 (experimental) (GCC) 

Options for slow code: " -m32  -march=atom -O2 -c"
Options for fast code: " -m32  -march=atom -O2 -DGOOD -c"

[Bug target/50962] New: Additional opportunity for AGU stall avoidance optimization for Atom processor

[izamyatin at gmail dot com]

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

 Bug #: 50962
   Summary: Additional opportunity for AGU stall avoidance
optimization for Atom processor
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com


We have now following code for attached testcase:

foo:
.LFB0:
.cfi_startproc
movl4(%esp), %eax
testl   %eax, %eax
je  .L4
xorl%ecx, %ecx
jmp .L3
.p2align 4,,7
.p2align 3
.L5:
movl%eax, %ecx
movl%edx, %eax
.L3:
movl(%eax), %edx <--- AGU stall here on Atom since eax produced on
previous cycle. We should use lea in previous instruction.
movl%ecx, (%eax)
testl   %edx, %edx
jne .L5
ret
.L4:
xorl%eax, %eax
ret
.cfi_endproc

 So we can use lea before movl (%eax), %edx which is better for Atom.

[Bug target/50962] Additional opportunity for AGU stall avoidance optimization for Atom processor

[izamyatin at gmail dot com]

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

--- Comment #1 from Igor Zamyatin  2011-11-02 
12:00:55 UTC ---
Created attachment 25688
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25688
testcase

[Bug tree-optimization/53128] [4.8 Regression] Compiler produces infinite loop on regular O2

[izamyatin at gmail dot com]

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

--- Comment #4 from Igor Zamyatin  2012-05-03 
11:09:15 UTC ---
Isn't it too aggressive from user perspective to perform such transformation
even without warning? Especially for the case when that "wrong" read is not
used later.
Sure it is dangerous anyway to make such access but at he same time it seems
this could affect lot of existing code...

[Bug tree-optimization/53128] [4.8 Regression] Compiler produces infinite loop on regular O2

[izamyatin at gmail dot com]

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

--- Comment #6 from Igor Zamyatin  2012-05-04 
13:19:07 UTC ---
Compiler does not simply see such code, it happens after some analysis, right?
For example, after work of infer_loop_bounds_from_undefined which makes some
assumptions and I believe can produce some information for user.

Again, I'm worrying about all this from user-perspective and especially after
discovering 2 such things in spec2006 sources(PR53086 and PR53073).

Interesting, could people have problems with SPEC results reporting since they
have to modify sources for this?

[Bug c++/53209] [4.7/4.8 Regression] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #7 from Igor Zamyatin  2012-05-05 
06:46:26 UTC ---
This patch fixes problem for me

[Bug middle-end/53161] [4.8 Regression] ICE with weakref function and a function which takes vector types

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #6 from Igor Zamyatin  2012-05-11 
10:00:51 UTC ---
I also see that LTO bootstrap fails with following message

../../src-trunk/gcc/gcov.c:2348:1: internal compiler error: vector
VEC(inline_edge_summary_t,base) index domain error, in inline_edge_summary at
ipa-inline.h:200
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[6]: *** [gcov.o] Error 1
make[6]: *** Waiting for unfinished jobs
rm gcj-dbtool.pod jcf-dump.pod jv-convert.pod grmic.pod gcj.pod gc-analyze.pod
gcov.pod gfdl.pod cpp.pod gij.pod gfortran.pod gcc.pod fsf-funding.pod
make[6]: Leaving directory `/export/gnu/import/git/gcc-test-profile/bld/gcc'
make[5]: *** [all-stageprofile-gcc] Error 2
make[5]: Leaving directory `/export/gnu/import/git/gcc-test-profile/bld'
make[4]: *** [stageprofile-bubble] Error 2
make[4]: Leaving directory `/export/gnu/import/git/gcc-test-profile/bld'
make[3]: *** [profiledbootstrap] Error 2
make[3]: Leaving directory `/export/gnu/import/git/gcc-test-profile/bld'
6968.90user 244.95system 24:30.58elapsed 490%CPU (0avgtext+0avgdata
567304maxresident)k
16256inputs+8351248outputs (112major+65804975minor)pagefaults 0swaps
make[2]: *** [profiledbootstrap] Error 2
make[2]: Leaving directory `/export/gnu/import/git/gcc-test-profile'

[Bug middle-end/53161] [4.8 Regression] ICE with weakref function and a function which takes vector types

[izamyatin at gmail dot com]

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

--- Comment #7 from Igor Zamyatin  2012-05-11 
10:07:07 UTC ---
Error message for x86 compilation

[Bug regression/53437] New: FAIL: gcc.dg/guality/inline-params.c -O0

[izamyatin at gmail dot com]

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

 Bug #: 53437
   Summary: FAIL: gcc.dg/guality/inline-params.c  -O0
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com
Target: x86


Fail appeared after rev 187593 
http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00590.html

Test's output:

FAIL: b is -1, not 3003
FAIL: ab is -1, not 6296656
FAIL: ac is -1, not 6296660
FAIL: msg is -1, not 4198594
FAIL: 0 PASS, 4 FAIL, 0 UNRESOLVED

[Bug bootstrap/53555] [4.8 Regression] Bootstrap failure

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #3 from Igor Zamyatin  2012-06-02 
11:17:41 UTC ---
Hmm, it seems it's not quite correct to check ix86_tune, proper way is to use
ix86_arch here. Following change fixes he bootstrap

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index c6c2c5e..a272411 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -23881,7 +23881,7 @@ ix86_sched_reorder(FILE *dump, int sched_verbose, rtx
*ready, int *pn_ready,
   issue_rate = ix86_issue_rate();

   /* Do reodering for Atom only.  */
-  if (ix86_tune != PROCESSOR_ATOM)
+  if (ix86_arch != PROCESSOR_ATOM)
 return issue_rate;
   /* Nothing to do if ready list contains only 1 instruction.  */
   if (n_ready <= 1)

[Bug tree-optimization/53588] New: [4.8 Regression] FAIL: gfortran.dg/vect/pr32380.f

[izamyatin at gmail dot com]

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

 Bug #: 53588
   Summary: [4.8 Regression] FAIL: gfortran.dg/vect/pr32380.f
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com
Target: i686


Failing report:
New failures:
FAIL: gfortran.dg/vect/pr32380.f  -O  scan-tree-dump-times vect "vectorized 7
loops" 1


Happened after fix for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081.
Test fails at least for i686 with -march=core2

[Bug tree-optimization/53081] memcpy/memset loop recognition

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #15 from Igor Zamyatin  2012-06-06 
12:43:09 UTC ---
Fix causes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53588

[Bug tree-optimization/53081] memcpy/memset loop recognition

[izamyatin at gmail dot com]

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

--- Comment #16 from Igor Zamyatin  2012-06-20 
08:44:44 UTC ---
Also cause of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53726

[Bug bootstrap/53750] New: x86 bootstrap failure since 188876

[izamyatin at gmail dot com]

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

 Bug #: 53750
   Summary: x86 bootstrap failure since 188876
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com
Target: x86


Output snippet:
...
trunk/gcc/../libdecnumber -I../../src-trunk/gcc/../libdecnumber/bid
-I../libdecnumber\
-o build/gcov-iov.o ../../src-trunk/gcc/gcov-iov.c
../../src-trunk/gcc/gcov-iov.c: In function 'int main(int, char**)':
../../src-trunk/gcc/gcov-iov.c:58:39: error: 'strcmp' was not declared in this
scope
   || strcmp (argv[2], "prerelease") == 0)
   ^
make[6]: *** [build/gcov-iov.o] Error 1
make[6]: *** Waiting for unfinished jobs
/bin/sh ../../src-trunk/gcc/../move-if-change tmp-recog.c insn-recog.c echo
timestamp > s-recog /bin/sh ../../src-trunk/gcc/../move-if-change tmp-output.c
insn-output.c echo timestamp > s-output
/bin/sh ../../src-trunk/gcc/../move-if-change tmp-attrtab.cinsn-attrtab.c
/bin/sh ../../src-trunk/gcc/../move-if-change tmp-dfatab.c insn-dfatab.c
/bin/sh ../../src-trunk/gcc/../move-if-change tmp-latencytab.c
insn-latencytab.c echo timestamp > s-attrtab /bin/sh
../../src-trunk/gcc/../move-if-change tmp-automata.c insn-automata.c echo
timestamp > s-automata rm gcj-dbtool.pod jcf-dump.pod jv-convert.pod grmic.pod
gcj.pod gc-analyze.pod gcov.pod gfdl.pod cpp.pod gij.pod gfortran.pod gcc.pod
fsf-funding.pod
make[6]: Leaving directory
`/export/gnu/import/git/gcc-test-intel64corei7/bld/gcc'
make[5]: *** [all-stage2-gcc] Error 2
make[5]: Leaving directory `/export/gnu/import/git/gcc-test-intel64corei7/bld'
make[4]: *** [stage2-bubble] Error 2
make[4]: Leaving directory `/export/gnu/import/git/gcc-test-intel64corei7/bld'
make[3]: *** [bootstrap] Error 2
make[3]: Leaving directory `/export/gnu/import/git/gcc-test-intel64corei7/bld'
1994.22user 127.22system 8:17.26elapsed 426%CPU (0avgtext+0avgdata
560092maxresident)k
157512inputs+6632280outputs (9major+56001851minor)pagefaults 0swaps
make[2]: *** [bootstrap] Error 2
make[2]: Leaving directory `/export/gnu/import/git/gcc-test-intel64corei7'

[Bug bootstrap/53750] x86 bootstrap failure since 188876

[izamyatin at gmail dot com]

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

--- Comment #1 from Igor Zamyatin  2012-06-22 
10:14:40 UTC ---
Oh, I see that fix was already checked in. Great!

[Bug lto/53787] New: Possible lto improvement

[izamyatin at gmail dot com]

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

 Bug #: 53787
   Summary: Possible lto improvement
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com


For following Fortan test t.f90 icc can propagate loop counter value and then
perform complete unroll and gcc doesn't do it

  real x(10)
  n = 10
  call init(x,n)
  print *, x
  end

  subroutine init(x, n)
  real x(10)
   do i=1,n
 x(i) = i*i + 1
   enddo

   return
   end

 Not sure it's completely lto problem though...

ifort flags- -O3 -ipo -inline-level=0
gfortran flags - -O3 -flto -fwhole-program -fno-inline

[Bug lto/53787] Possible lto improvement

[izamyatin at gmail dot com]

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

--- Comment #2 from Igor Zamyatin  2012-06-27 
17:56:48 UTC ---
The testcase was reduced from some real app. No inlining happened there. 
Do you think this testcase is bad?

[Bug lto/53787] Possible lto improvement

[izamyatin at gmail dot com]

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

--- Comment #4 from Igor Zamyatin  2012-06-28 
08:17:13 UTC ---
Created attachment 27714
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27714
gfort assembler

"Init" routine should be inspected here

[Bug lto/53787] Possible lto improvement

[izamyatin at gmail dot com]

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

--- Comment #5 from Igor Zamyatin  2012-06-28 
08:22:11 UTC ---
Created attachment 27715
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27715
ifort assembler

"Init" routine looks much better here

[Bug tree-optimization/53787] Possible IPA-SRA / IPA-CP improvement

[izamyatin at gmail dot com]

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

--- Comment #7 from Igor Zamyatin  2012-07-19 
19:09:49 UTC ---
Any thoughts here?

[Bug regression/54084] New: Bunch of fails for x86

[izamyatin at gmail dot com]

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

 Bug #: 54084
   Summary: Bunch of fails for x86
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com
Target: x86


After r189803 (http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00708.html) regression
mailer shows bunch of errors for x86_64:
FAIL: g++.dg/opt/pr44919.C -std=gnu++11 (internal compiler error)
FAIL: g++.dg/opt/pr46640.C -std=gnu++11 (internal compiler error)
FAIL: g++.dg/opt/pr46640.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/opt/pr46640.C -std=gnu++98 (internal compiler error)
FAIL: gcc.dg/pr45352-3.c (internal compiler error)
FAIL: gcc.dg/pr45352.c (internal compiler error)
FAIL: gcc.dg/pr45570.c (internal compiler error)
FAIL: gcc.dg/pr46521.c (internal compiler error)
FAIL: gcc.dg/pr46522.c (internal compiler error)
FAIL: gcc.dg/pr48144.c (internal compiler error)
FAIL: gcc.dg/pr48235.c (internal compiler error)
FAIL: gcc.dg/pr51557.c (internal compiler error)
FAIL: gcc.target/i386/pr45352-1.c (internal compiler error)
FAIL: gcc.target/i386/pr45352.c (internal compiler error)
FAIL: gcc.target/i386/pr45352.c (test for excess errors)
FAIL: gfortran.dg/pr44691.f  -O  (internal compiler error)


and i686:
FAIL: gcc.dg/pr45570.c (internal compiler error)
FAIL: gcc.dg/pr46585.c (internal compiler error)
FAIL: gcc.dg/pr48144.c (internal compiler error)
FAIL: gcc.dg/pr48235.c (internal compiler error)
FAIL: gcc.dg/pr48442.c (internal compiler error)
FAIL: gcc.dg/pr50205.c (internal compiler error)
FAIL: gcc.dg/pr50340.c (internal compiler error)
FAIL: gcc.dg/pr51557.c (internal compiler error)
FAIL: gcc.target/i386/pr45352-1.c (internal compiler error)
FAIL: gcc.target/i386/pr45352-2.c (internal compiler error)
FAIL: gcc.target/i386/pr45352.c (internal compiler error)
FAIL: gcc.target/i386/pr45913.c (internal compiler error)
FAIL: gcc.target/i386/pr48237.c (internal compiler error)

Error message looks like
internal compiler error: in free_regset_pool, at sel-sched-ir.c:994^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M
 status 1

[Bug regression/54084] Bunch of fails for x86

[izamyatin at gmail dot com]

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

--- Comment #3 from Igor Zamyatin  2012-07-24 
17:16:11 UTC ---
Seems ok now

[Bug regression/54084] Bunch of fails for x86

[izamyatin at gmail dot com]

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

--- Comment #5 from Igor Zamyatin  2012-07-26 
08:44:01 UTC ---
Looks like r189812 fixed some failures but not all of them.

Patch from comment 2 fixes all problems

[Bug target/54156] [4.8 Regression] New fail on AVX target: gcc.dg/vect/pr53773.c. 190010 vs revision 189996

[izamyatin at gmail dot com]

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

--- Comment #2 from Igor Zamyatin  2012-08-01 
15:57:42 UTC ---
Author: wschmidt 
Date:   Tue Jul 31 12:25:04 2012 +

gcc:

2012-07-31  Bill Schmidt  

PR tree-optimization/53773
* tree-vectorizer.h (struct _loop_vec_info): Add operands_swapped.
(LOOP_VINFO_OPERANDS_SWAPPED): New macro.
* tree-vect-loop.c (new_loop_vec_info): Initialize
LOOP_VINFO_OPERANDS_SWAPPED field.
(destroy_loop_vec_info): Restore canonical form.
(vect_is_slp_reduction): Set LOOP_VINFO_OPERANDS_SWAPPED field.
(vect_is_simple_reduction_1): Likewise.

gcc/testsuite:

2012-07-31  Bill Schmidt  

PR tree-optimization/53773
* testsuite/gcc.dg/vect/pr53773.c: New test

 Seems for x86 output is different

[Bug target/54156] [4.8 Regression] New fail on AVX target: gcc.dg/vect/pr53773.c. 190010 vs revision 189996

[izamyatin at gmail dot com]

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

--- Comment #3 from Igor Zamyatin  2012-08-03 
13:38:05 UTC ---
There are 6 "* 10" in a dump for AVX (additional 2 occur when vectorizer
consider 32-byte vectorization)

[Bug target/54156] [4.8 Regression] New fail on AVX target: gcc.dg/vect/pr53773.c. 190010 vs revision 189996

[izamyatin at gmail dot com]

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

--- Comment #7 from Igor Zamyatin  2012-08-03 
19:24:40 UTC ---
There are no those fails now, thanks! The bug could be closed.

[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.

[izamyatin at gmail dot com]

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

--- Comment #1 from Igor Zamyatin  2012-02-15 
09:06:49 UTC ---
BTW, this is a 4.7 regression

[Bug c++/52241] Performance degradation of 447.dealII on corei7 at spec2006_base32.

[izamyatin at gmail dot com]

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

--- Comment #16 from Igor Zamyatin  2012-02-19 
18:58:41 UTC ---
Jakub, could you please clarify your statement - "But libstdc++.so.6's tree.cc
has been compiled with
-fPIC -DPIC before Benjamin's change and is compiled with those flags after
those changes as well"

Compiler logs show somwhat opposite to this statement:

Before Benjamin's commit libtool is called without -prefer-pic:

/bin/sh ../libtool --tag CXX   --mode=compile  -fno-implicit-templates
-Wall -Wextra -Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once
-Wabi  -ffunction-sections -fdata-sections  -frandom-seed=tree.lo -g -O2
-D_GNU_SOURCE -c -o tree.lo ../../../../libstdc++-v3/src/tree.cc

and then 

libtool: compile:  /export/users/izamyati/././gcc/xgcc  
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -Wabi -ffunction-sections -fdata-sections
-frandom-seed=tree.lo -g -O2 -D_GNU_SOURCE -c
../../../../libstdc++-v3/src/tree.cc -o tree.o >/dev/null 2>&1.

But in the same time there is the following

libtool: compile:  /export/users/izamyati/././gcc/xgcc 
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -Wabi -ffunction-sections -fdata-sections
-frandom-seed=tree.lo -g -O2 -D_GNU_SOURCE -c
../../../../libstdc++-v3/src/tree.cc  -fPIC -DPIC -o .libs/tree.o   which is
absent after Benjamin's commit.

Does all this mean that actually tree.cc compiled with fPIC?

[Bug tree-optimization/52395] New: [4.7 Regression] Alignment issue at O2

[izamyatin at gmail dot com]

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

 Bug #: 52395
   Summary: [4.7 Regression] Alignment issue at O2
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com


Created attachment 26759
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26759
Test case for the issue

I noticed that after the following commit 

commit 25b3bbad6624357c1ac6a31e0be6fca37182fb78
Author: rguenth 
Date:   Fri Jan 27 14:56:54 2012 +

2012-01-27  Richard Guenther  

PR tree-optimization/50444
* tree-sra.c (build_ref_for_offset): Properly adjust the
MEM_REF type for unaligned accesses.

* gcc.dg/torture/pr50444.c: New testcase.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@183630
138bc75d-0d04-0410-961f-82ee72b054a4

 alignment of some memory references was spoiled. For attached test case I see
following:

  before commit (A32):

#(insn:TI 6 11 7 2 (set (mem:SF (reg/v/f:DI 5 di [orig:61 __x ] [61]) [2
__x_1(D)->re+0 S4 A32])
#(const_double:SF 0.0 [0x0.0p+0])) test.cpp:13 108 {*movsf_internal}
# (nil))
movl$0x, (%rdi)# 6*movsf_internal/5[length = 16]


  after commit (A8):

#(insn:TI 6 11 7 2 (set (mem:SF (reg/v/f:DI 5 di [orig:61 __x ] [61]) [2
__x_1(D)->re+0 S4 A8])
#(const_double:SF 0.0 [0x0.0p+0])) test.cpp:13 108 {*movsf_internal}
# (nil))
movl$0x, (%rdi)# 6*movsf_internal/5[length = 16]


 Compiled just with O2.

 Originally I saw this after compilation of complex_io.cc from libstdc++-v3

[Bug tree-optimization/52395] [4.7 Regression] Alignment issue at O2

[izamyatin at gmail dot com]

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

--- Comment #2 from Igor Zamyatin  2012-02-27 
09:47:38 UTC ---
Right, more conservative :)

[Bug tree-optimization/52395] [4.7 Regression] Alignment issue at O2

[izamyatin at gmail dot com]

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

--- Comment #3 from Igor Zamyatin  2012-02-27 
09:49:38 UTC ---
x86_64 indeed, sorry

[Bug testsuite/52563] New: FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[izamyatin at gmail dot com]

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

 Bug #: 52563
   Summary: FAIL: gcc.dg/tree-ssa/scev-[3,4].c
scan-tree-dump-times optimized "&a" 1
Classification: Unclassified
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com
CC: jiangning@arm.com
Target: x86_64-unknown-linux-gnu


Fails appeared after revision 185129:

2012-03-09 Jiangning Liu  

tree-scalar-evolution (interpret_rhs_expr): generate chrec for
array reference and component reference.
(analyze_scalar_evolution_for_address_of): New. 
2012-03-09 Jiangning Liu  

gcc.dg/tree-ssa/scev-3.c: New. 
gcc.dg/tree-ssa/scev-4.c: New. 


 Probably some simple misprint in tests - there are 2 "&a" in dumps...

[Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #10 from Igor Zamyatin  2012-03-14 
08:47:54 UTC ---
This caused http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52580

[Bug other/52626] New: make check fixinclude test FAILURES

[izamyatin at gmail dot com]

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

 Bug #: 52626
   Summary: make check fixinclude test FAILURES
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com
Target: x86_64-unknown-linux-gnu


Issue appeared after revision 185392:

Author: ro 
Date:   Wed Mar 14 17:08:03 2012 +

Remove obsolete Solaris 8 support


Snippet from make check report:
pthread.h
/export/users/izamyati/trunk_for_check/fixincludes/tests/base/pthread.h differ:
byte 2526, line 86
*** pthread.h2012-03-20 00:03:27.660335543 +0400
--- /export/users/izamyati/trunk_for_check/fixincludes/tests/base/pthread.h   
2012-03-16 13:25:18.787318293 +0400
***
*** 83,91 
  #define PTHREAD_MUTEX_INITIALIZER{{{0},0}, {{{0}}}, {0}}
  #endif
  #if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)
! #define PTHREAD_COND_INITIALIZER{{{0}, 0}, 0}/* DEFAULTCV */
  #else
! #define PTHREAD_COND_INITIALIZER{{{0}, 0}, {0}}/* DEFAULTCV */
  #endif
  #if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)
  #definePTHREAD_MUTEX_INITIALIZER/* = DEFAULTMUTEX */\
--- 83,91 
  #define PTHREAD_MUTEX_INITIALIZER{{{0},0}, {{{0}}}, {0}}
  #endif
  #if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)
! #define PTHREAD_COND_INITIALIZER{{{0}, 0, 0x4356}, 0}/* DEFAULTCV */
  #else
! #define PTHREAD_COND_INITIALIZER{{{0}, 0, 0x4356}, {0}}/* DEFAULTCV
*/
  #endif
  #if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)
  #definePTHREAD_MUTEX_INITIALIZER/* = DEFAULTMUTEX */\

There were fixinclude test FAILURES
make: *** [check] Error 1

[Bug c/52632] GCC compfail on O0

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #6 from Igor Zamyatin  2012-03-21 
07:52:46 UTC ---
So is it ok that compiler behaves differently with and without optimizations?

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[izamyatin at gmail dot com]

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

Igor Zamyatin  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #8 from Igor Zamyatin  2012-03-26 
11:05:52 UTC ---
Sort of experimental patch

Index: tree-ssa-loop-ivopts.c
===
--- tree-ssa-loop-ivopts.c  (revision 185039)
+++ tree-ssa-loop-ivopts.c  (working copy)
@@ -4114,6 +4114,7 @@
   else if (ratio == 1)
 {
   tree real_cbase = cbase;
+  int diff_cost, add_cost1;

   /* Check to see if any adjustment is needed.  */
   if (cstepi == 0 && stmt_is_after_inc)
@@ -4133,7 +4134,10 @@
  ubase, real_cbase,
  &symbol_present, &var_present, &offset,
  depends_on);
+  diff_cost = cost.cost;
   cost.cost /= avg_loop_niter (data->current_loop);
+  if (diff_cost > (add_cost1 = add_cost(TYPE_MODE (ctype), data->speed)))
+  cost.cost += add_cost1;
 }
   else if (address_p
   && !POINTER_TYPE_P (ctype)


 It was found during some side investigation regarding ivopts phase work. 
Patch fixes the regression.

[Bug tree-optimization/52272] [4.7/4.8 regression] Performance regresswion of 410.bwaves on x86.

[izamyatin at gmail dot com]

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

--- Comment #10 from Igor Zamyatin  2012-03-29 
11:04:27 UTC ---
Is it possible to look at the regressed test-case and gcc dumps with
-fdump-tree-ivopts-details option w/o that change? 
Thanks in advance

[Bug fortran/52865] New: GCC can't vectorize fortran loop but able to vectorize similar c-loop

[izamyatin at gmail dot com]

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

 Bug #: 52865
   Summary: GCC can't vectorize fortran loop but able to vectorize
similar c-loop
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com
Target: x86-64


Created attachment 27087
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27087
Fortran test

That looks strange but the compiler behaves differently on O3 for attached test
cases. 
Fortran can't vectorize loop which looks quite simple

Is it expected behavior?

[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop

[izamyatin at gmail dot com]

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

--- Comment #1 from Igor Zamyatin  2012-04-04 
13:27:11 UTC ---
Created attachment 27088
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27088
C test

[Bug tree-optimization/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop

[izamyatin at gmail dot com]

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

--- Comment #5 from Igor Zamyatin  2012-04-04 
15:20:41 UTC ---
Seems it doesn't like non-empty latch block in Fortran case

[Bug tree-optimization/52868] New: [4.6/4.7/4.8 Regression] 4.6 is faster on Atom

[izamyatin at gmail dot com]

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

 Bug #: 52868
   Summary: [4.6/4.7/4.8 Regression] 4.6 is faster on Atom
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com
Target: i386


Created attachment 27090
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27090
Testcase

For attached case 4.6 is ~10% faster than 4.7 and trunk.

IVopts works differently and it leads to performance degradation

THis is possibly related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272

Command line to reproduce:
-O2 -march=atom -m32 -mtune=atom -msse2 -static

[Bug fortran/52916] [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build

[izamyatin at gmail dot com]

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

--- Comment #5 from Igor Zamyatin  2012-04-12 
13:55:54 UTC ---
With this patch 481.wrf is ok

[Bug tree-optimization/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop

[izamyatin at gmail dot com]

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

--- Comment #6 from Igor Zamyatin  2012-04-16 
07:16:56 UTC ---
Any ideas what exactly does prevent the vectorization in the case of Fortran?