[Bug lto/66014] 5.1 mingw64 fails to perform slim bootstrap-lto: ccEt8YNj.ltrans4.ltrans.o::(.text+0x628): undefined reference to `stpcpy'

[rai...@emrich-ebersheim.de]

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

Rainer Emrich  changed:

   What|Removed |Added

 CC||rai...@emrich-ebersheim.de

--- Comment #2 from Rainer Emrich  ---
Confirmed, issue still present.

[Bug bootstrap/66801] [6 Regression] gcc miscompiled during PGO/LTO bootstrap

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #12 from Richard Biener  ---
Also fails for HJ https://gcc.gnu.org/ml/gcc-regression/2015-07/msg00224.html,
from what I can see it's plain LTO/FDO bootstrap (but with checking enabled
and multilibs).

I suppose using LTO really means the bug might be hard to trigger.

Now trying your config.

[Bug middle-end/66807] [6 Regression] --enable-libmpx failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Blocks||66794
 Resolution|--- |FIXED

--- Comment #1 from Richard Biener  ---
Should be fixed now.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66794
[Bug 66794] [4.9/5 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu

[Bug tree-optimization/66794] [4.9/5 Regression] ICE at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66794
Bug 66794 depends on bug 66807, which changed state.

Bug 66807 Summary: [6 Regression] --enable-libmpx failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66807

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/66807] [6 Regression] --enable-libmpx failed

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Thu Jul  9 07:47:38 2015
New Revision: 225600

URL: https://gcc.gnu.org/viewcvs?rev=225600&root=gcc&view=rev
Log:
2015-07-09  Richard Biener  

PR tree-optimization/66807
* tree-chkp-opt.c (chkp_opt_fini): Free post dominator info.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-chkp-opt.c

[Bug target/66814] ICE: gcc.target/i386/avx512f-klogic-2.c

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #2 from Uroš Bizjak  ---
Created attachment 35937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35937&action=edit
Patch that introduces nonimmediate_gr_operand predicate

I have patch in testing.

[Bug c++/65186] internal compiler error: in tsubst, at cp/pt.c:11738

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #7 from Paolo Carlini  ---
I see, too bad. Remember to ping your new patch, anyway! ;)

[Bug bootstrap/66801] [6 Regression] gcc miscompiled during PGO/LTO bootstrap

[trippels at gcc dot gnu.org]

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

--- Comment #13 from Markus Trippelsdorf  ---
(In reply to Richard Biener from comment #12)
> Also fails for HJ
> https://gcc.gnu.org/ml/gcc-regression/2015-07/msg00224.html,
> from what I can see it's plain LTO/FDO bootstrap (but with checking enabled
> and multilibs).

H.J.'s config was failing before r225504 went in, so it must be a 
different issue: https://gcc.gnu.org/ml/gcc-regression/2015-07/msg00014.html

[Bug gcov-profile/43341] pragma pack changes padding in struct gcov_info on 64-bit archs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0

--- Comment #11 from Richard Biener  ---
Fixed on trunk with

2015-07-09  Richard Biener  

* toplev.c (compile_file): Reset maximum_field_alignment after parsing.

and queued for backporting.

[Bug bootstrap/66801] [6 Regression] gcc miscompiled during PGO/LTO bootstrap

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Hmpf, bootstrap passed on x86_64-linux with

/space/rguenther/src/svn/trunk2/configure --disable-libstdcxx-pch
--disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp
--disable-libgomp --disable-werror --disable-multilib --enable-languages=c,c++
--enable-checking=release --with-build-config=bootstrap-lto bootstrap-O3
make -j12 profiledbootstrap

(r225542)

[Bug tree-optimization/66718] Non-invariant ADDR_EXPR not vectorized

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Thu Jul  9 09:01:51 2015
New Revision: 225604

URL: https://gcc.gnu.org/viewcvs?rev=225604&root=gcc&view=rev
Log:
PR tree-optimization/66718
* Makefile.in (OBJS): Add gimple-laddress.o. 
* passes.def: Schedule pass_laddress.
* timevar.def (DEFTIMEVAR): Add TV_GIMPLE_LADDRESS.
* tree-pass.h (make_pass_laddress): Declare.
* gimple-laddress.c: New file.

* gcc.dg/vect/vect-126.c: New test.

Added:
trunk/gcc/gimple-laddress.c
trunk/gcc/testsuite/gcc.dg/vect/vect-126.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/timevar.def
trunk/gcc/tree-pass.h

[Bug tree-optimization/66718] Non-invariant ADDR_EXPR not vectorized

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Marek Polacek  ---
The test in the description is fully vectorized now, so fixed.

[Bug c++/57565] variadic template and type inference failure

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Paolo Carlini  ---
Dup.

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

[Bug c++/66421] G++ fails compilation when assigning tuple created with variadic template to auto variable

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||anass.lasram at gmail dot com

--- Comment #7 from Paolo Carlini  ---
*** Bug 57565 has been marked as a duplicate of this bug. ***

[Bug c++/58074] [C++11] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Paolo Carlini  ---
CC-ing Jason about the ABI issue.

[Bug middle-end/66817] ICE in hard_function_value, at explow.c:1844 with -miamcu

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Jul  9 09:26:47 2015
New Revision: 225605

URL: https://gcc.gnu.org/viewcvs?rev=225605&root=gcc&view=rev
Log:
Check int_size_in_bytes in ix86_return_in_memory

ix86_return_in_memory should check negative return from int_size_in_bytes,
similar to other ports.

gcc/

PR target/66817
* config/i386/i386.c (ix86_return_in_memory): Return true
if int_size_in_bytes returns negative for IA MCU.

gcc/testsuite/

PR target/66817
* gcc.target/i386/pr66817.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr66817.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug target/66818] Wrong alignment value for attribute ((aligned)) with -miamcu

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Jul  9 09:28:19 2015
New Revision: 225606

URL: https://gcc.gnu.org/viewcvs?rev=225606&root=gcc&view=rev
Log:
Define ATTRIBUTE_ALIGNED_VALUE to 32 for IA MCU

attribute ((aligned)) should align to the minimum of BIGGEST_ALIGNMENT,
which is 4 bytes for -miamcu.

gcc/

PR target/66818
* config/i386/i386.h (ATTRIBUTE_ALIGNED_VALUE): Defined to 32
for IA MCU.

gcc/testsuite/

PR target/66818
* gcc.target/i386/pr66818.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr66818.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.h
trunk/gcc/testsuite/ChangeLog

[Bug target/66818] Wrong alignment value for attribute ((aligned)) with -miamcu

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from H.J. Lu  ---
Fixed.

[Bug middle-end/66817] ICE in hard_function_value, at explow.c:1844 with -miamcu

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from H.J. Lu  ---
Fixed.

[Bug c++/65790] compilation error : receive std::index_sequence

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
This is fixed for 5.2. Let's add the testcase and close the bug.

[Bug libgomp/66820] New: internal compiler error: in get_expr_operands, at tree-ssa-operands.c:910

[simon at sconseil dot fr]

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

Bug ID: 66820
   Summary: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:910
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at sconseil dot fr
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 35938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35938&action=edit
Code to reproduce the bug

Hi,
I get this error when compiling a C code using OpenMP, since the upgrade to GCC
5.1, it was compiling without error with GCC 4.9. I'm using Archlinux.
The attached merging.c file is the C code where I removed everything I could to
get a minimal code to reproduce the bug. If I remove the strcat call in the omp
parallel block (and replace it with the commented sprintf) then it compiles.

The C code is wrapped in a python module, below is the compilation log:

$ LANG=C python setup.py build_ext -i 
running build_ext
building 'libCmethods' extension
gcc -pthread -fno-strict-aliasing -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong --param=ssp-buffer-size=4 -DNDEBUG -march=x86-64
-mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4
-fPIC -I/usr/include/python2.7 -c src/tools.c -o
build/temp.linux-x86_64-2.7/src/tools.o -freport-bug -fopenmp
gcc -pthread -fno-strict-aliasing -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong --param=ssp-buffer-size=4 -DNDEBUG -march=x86-64
-mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4
-fPIC -I/usr/include/python2.7 -c src/subtract_slice_median.c -o
build/temp.linux-x86_64-2.7/src/subtract_slice_median.o -freport-bug -fopenmp
gcc -pthread -fno-strict-aliasing -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong --param=ssp-buffer-size=4 -DNDEBUG -march=x86-64
-mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4
-fPIC -I/usr/include/python2.7 -c src/merging.c -o
build/temp.linux-x86_64-2.7/src/merging.o -freport-bug -fopenmp
src/merging.c: In function 'mpdaf_merging_median._omp_fn.0':
src/merging.c:36:1: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:910
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/simon/ccsj0rjP.out file, please attach
this to your bugreport.
error: command 'gcc' failed with exit status 1

[Bug libgomp/66820] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:910

[simon at sconseil dot fr]

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

--- Comment #1 from Simon Conseil  ---
Created attachment 35939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35939&action=edit
Preprocessed source from -freport-bug

[Bug c++/65790] compilation error : receive std::index_sequence

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jul  9 09:51:09 2015
New Revision: 225607

URL: https://gcc.gnu.org/viewcvs?rev=225607&root=gcc&view=rev
Log:
2015-07-09  Paolo Carlini  

PR c++/65790
* g++.dg/cpp0x/vt-65790.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/vt-65790.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/65790] compilation error : receive std::index_sequence

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.2

--- Comment #4 from Paolo Carlini  ---
Done.

[Bug target/66821] New: reassoc-37.c fails on -march=pentium

[julia.koval at intel dot com]

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

Bug ID: 66821
   Summary: reassoc-37.c fails on -march=pentium
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: julia.koval at intel dot com
  Target Milestone: ---

FAIL: gcc.dg/tree-ssa/reassoc-37.c scan-tree-dump optimized
"(8784908|0x0*860c0c)"
FAIL: gcc.dg/tree-ssa/reassoc-37.c scan-tree-dump optimized "(<<|>>)"

./gcc -m32 reassoc-37.c
193.t.optimised pass generates:
  :
  _26 = (unsigned int) x_2(D);
  if (_26 > 23)
goto ;
  else
goto ;

  :
  _28 = 8784908 >> x_2(D);
  _29 = _28 & 1;
  _34 = ~_28;
  _32 = _34 & 1;
  _30 = (_Bool) _34;
  if (_30 != 0)
goto ;
  else
goto ;

./gcc -m32 -march=pentium
193.t.optimised pass generates:
:
  _22 = (unsigned int) x_2(D);
  _23 = _22 & 4294967287;
  _24 = _23 + 4294967294;
  if (_24 > 1)
goto ;
  else
goto ;

  :
  _20 = _22 + 4294967279;
  if (_20 > 1)
goto ;
  else
goto ;

[Bug libgomp/66820] [5/6 Regression] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:910

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-09
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.3
Summary|internal compiler error: in |[5/6 Regression] internal
   |get_expr_operands, at   |compiler error: in
   |tree-ssa-operands.c:910 |get_expr_operands, at
   ||tree-ssa-operands.c:910
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed.  With checking:

$ ./cc1 -quiet ccsj0rjP.out.i -fopenmp
src/merging.c: In function ‘mpdaf_merging_median’:
src/merging.c:35:12: error: non-register as LHS of binary operation
<<< error >>> = &filename + D.2786;
src/merging.c:35:12: error: invalid argument to gimple call
<<< error >>>
__builtin_memcpy (<<< error >>>, "[data]", 7);
src/merging.c:35:12: internal compiler error: verify_gimple failed
0xf63acd verify_gimple_in_seq(gimple_statement_base*)
/home/marek/src/gcc/gcc/tree-cfg.c:4804
0xe1afd4 execute_function_todo
/home/marek/src/gcc/gcc/passes.c:1949
0xe1a0ac do_per_function
/home/marek/src/gcc/gcc/passes.c:1638
0xe1b19f execute_todo
/home/marek/src/gcc/gcc/passes.c:2004
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libgomp/66820] [5/6 Regression] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:910

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Started with r213753.

[Bug middle-end/66820] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:910

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||openmp
   Last reconfirmed|2015-07-09 00:00:00 |
  Component|libgomp |middle-end
   Target Milestone|5.3 |5.2
Summary|[5/6 Regression] internal   |internal compiler error: in
   |compiler error: in  |get_expr_operands, at
   |get_expr_operands, at   |tree-ssa-operands.c:910
   |tree-ssa-operands.c:910 |

--- Comment #4 from Jakub Jelinek  ---
Started with r213753, though more likely OpenMP lowering or expansion bug
somewhere, not handling addressable variables properly.

[Bug rtl-optimization/62265] [4.8/4.9/5 regression] FAIL: gcc.dg/20111227-2.c scan-rtl-dump ree "Elimination opportunities = 3 realized = 3"

[julia.koval at intel dot com]

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

Yulia Koval  changed:

   What|Removed |Added

 CC||julia.koval at intel dot com

--- Comment #6 from Yulia Koval  ---
This test still fails on -march=pentium

[Bug middle-end/66820] [5/6 Regression] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:910

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
I guess related to PR66633.

[Bug bootstrap/66801] [6 Regression] gcc miscompiled during PGO/LTO bootstrap

[trippels at gcc dot gnu.org]

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

--- Comment #15 from Markus Trippelsdorf  ---
For x86_64 additional --with-arch=native (sandybridge) is needed during
configuration.

[Bug fortran/66775] Allocatable function result type(t) produces segfault when uninitialized

[vehre at gcc dot gnu.org]

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

--- Comment #1 from vehre at gcc dot gnu.org ---
This bug is somehow related with 55603.

[Bug fortran/66775] Allocatable function result type(t) produces segfault when uninitialized

[vehre at gcc dot gnu.org]

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

--- Comment #2 from vehre at gcc dot gnu.org ---
This bug is somehow related with pr55603.

[Bug fortran/58586] ICE with derived type with allocatable component passed by value

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from vehre at gcc dot gnu.org ---
No objections yet, declaring it fixed with r225447.

[Bug fortran/66578] [F2008] Invalid free on allocate(...,source=a(:)) in block

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #19 from vehre at gcc dot gnu.org ---
No objections so far. Closing as fixed with r225507.

[Bug libgomp/66714] ICE in loc_list_from_tree with -g

[vries at gcc dot gnu.org]

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

--- Comment #19 from vries at gcc dot gnu.org ---
This ( https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00711.html ) patch fixes
the ICE (perhaps without fixing the root cause).

[Bug bootstrap/66801] [6 Regression] gcc miscompiled during PGO/LTO bootstrap

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
So, if it is related to vectorization (if I ever get to reproduce it I'll try
-fno-tree-vectorize) then it might be the

/* If arg0 is derived from the address of an object or function, we may
   be able to fold this expression using the object or function's
   alignment.  */
(simplify
 (bit_and (convert? @0) INTEGER_CST@1)
 (if (POINTER_TYPE_P (TREE_TYPE (@0))
  && tree_nop_conversion_p (type, TREE_TYPE (@0)))
  (with
   {
 unsigned int align;
 unsigned HOST_WIDE_INT bitpos;
 get_pointer_alignment_1 (@0, &align, &bitpos);
   }
   (if (wi::ltu_p (@1, align / BITS_PER_UNIT))
{ wide_int_to_tree (type, wi::bit_and (@1, bitpos / BITS_PER_UNIT)); }

pattern somehow going wild (from triggering within CCP itself?).  Thus as
third step I'll try disabling that one.

[Bug tree-optimization/66642] transform_to_exit_first_loop_alt doesn't use result of low iteration count loop

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |vries at gcc dot gnu.org

--- Comment #7 from vries at gcc dot gnu.org ---
patch committed, marking resolved-fixed.

[Bug target/66821] reassoc-37.c fails on -march=pentium

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
Which code is better?

[Bug target/65951] [AArch64] Will not vectorize 64bit integer multiplication

[vekumar at gcc dot gnu.org]

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

vekumar at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vekumar at gcc dot gnu.org

--- Comment #6 from vekumar at gcc dot gnu.org ---
I found similar pattern in SPEC2006 hmmer benchmark, when comparing x86_64 (
-O3 + -march=bdver3 vs. -O3 + -mcpu=cortex-a57). x86_64 was able to vectorize 5
additional loops. Out of 5 loops, two were cost model related and aarch64
rejects because of running high vector cost. 

Remaining three loops are of this pattern. one used a constant 104. 
The other two of them used multiplication by 4 and that could be converted to
vector shifts.

I made a simple test case and wanted to open a PR. James pointed me to this PR.
Thought of posting it as comments.


unsigned long int __attribute__ ((aligned (64)))arr[100];
int i;

void test_vector_shifts()
{
for(i=0; i<=99;i++)
arr[i]=arr[i]<<2;
}


void test_vectorshift_via_mul()
{
for(i=0; i<=99;i++)
arr[i]=arr[i]*4;

}

Assembly

.cpu cortex-a57+fp+simd+crc
.file   "test.c"
.text
.align  2
.p2align 4,,15
.global test_vector_shifts
.type   test_vector_shifts, %function
test_vector_shifts:
adrpx0, arr
add x0, x0, :lo12:arr
adrpx1, arr+800
add x1, x1, :lo12:arr+800
.p2align 2
.L2:
ldr q0, [x0]
shl v0.2d, v0.2d, 2 <==vector shifts 
str q0, [x0], 16
cmp x0, x1
bne .L2
adrpx0, i
mov w1, 100
str w1, [x0, #:lo12:i]
ret
.size   test_vector_shifts, .-test_vector_shifts
.align  2
   .p2align 4,,15
.global test_vectorshift_via_mul
.type   test_vectorshift_via_mul, %function
test_vectorshift_via_mul:
adrpx0, arr
add x0, x0, :lo12:arr
adrpx2, arr+800
add x2, x2, :lo12:arr+800
.p2align 2
.L6:
ldr x1, [x0]
lsl x1, x1, 2
str x1, [x0], 8 <==scalar shifts 
cmp x0, x2
bne .L6
adrpx0, i
mov w1, 100
str w1, [x0, #:lo12:i]
ret
.size   test_vectorshift_via_mul, .-test_vectorshift_via_mul

[Bug middle-end/66741] loops not fused nor vectorized

[aldot at gcc dot gnu.org]

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

--- Comment #4 from Bernhard Reutner-Fischer  ---
Created attachment 35940
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35940&action=edit
Manually expanded variant

expanding builtins early should arrive at that

[Bug middle-end/66741] loops not fused nor vectorized

[aldot at gcc dot gnu.org]

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

--- Comment #5 from Bernhard Reutner-Fischer  ---
Created attachment 35941
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35941&action=edit
Variant perusing builtins

This is (essentially) the motivating real-world example

[Bug middle-end/66741] loops not fused nor vectorized

[aldot at gcc dot gnu.org]

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

--- Comment #6 from Bernhard Reutner-Fischer  ---
Created attachment 35942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35942&action=edit
Variant demonstrating strcpy+tolower fused loop, vectorized, SSE4.x

Code like this should be emitted for such strcpy+tolower "patterns" (on
SSE4.x), like for the motivating -1.c

[Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier

[amacleod at redhat dot com]

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

Andrew Macleod  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from Andrew Macleod  ---
GCC emits the fence on stores, and thus loads don't need a fence.

[Bug middle-end/66741] loops not fused nor vectorized

[aldot at gcc dot gnu.org]

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

--- Comment #7 from Bernhard Reutner-Fischer  ---
folding tolower (and toupper while at it) gives:

for i in 0 1 2;do
gcc -o tolower_strcpy-$i tolower_strcpy-$i.c -Ofast -W -Wall -Wextra -pedantic
-DMAIN -msse4.2
done

/tmp/inp is 200MB random binary data (flash video)
gcc (Debian 4.9.2-22) 4.9.2:
for j in 0 1 2;do echo "# tolower_strcpy-$j"; time for i in $(seq 1 10);do
./tolower_strcpy-$j < /tmp/inp;done;done
# tolower_strcpy-0

real0m6.237s
user0m3.268s
sys 0m2.956s
# tolower_strcpy-1

real0m7.776s
user0m4.896s
sys 0m2.856s
# tolower_strcpy-2

real0m3.578s
user0m0.760s
sys 0m2.800s


gcc-5 (Debian 5.1.1-12) 5.1.1 20150622
# tolower_strcpy-0

real0m6.061s
user0m3.196s
sys 0m2.856s
# tolower_strcpy-1

real0m7.737s
user0m4.872s
sys 0m2.844s
# tolower_strcpy-2

real0m3.562s
user0m0.708s
sys 0m2.840s

gcc (GCC) 6.0.0 20150703 (experimental) [sibcall-elim revision
9e8ac6a:b79ca3b:17a501138f5bad51638cd4bbb290dffd9978b706] +
fold_builtin_tolower

# tolower_strcpy-0

real0m6.019s
user0m3.148s
sys 0m2.852s
# tolower_strcpy-1

real0m5.360s
user0m2.480s
sys 0m2.856s
# tolower_strcpy-2

real0m3.559s
user0m0.776s
sys 0m2.764s

But it's a complete mystery how to generate any sensible SSE4.x for the
tolower_strcpy-0 code. I'd had hoped that the loops would magically end up
using some fast sse4.2 but -Ofast -msse4.2 is not enough?

[Bug target/66822] New: Turn off X86_TUNE_ZERO_EXTEND_WITH_AND for IAMCU

[hjl.tools at gmail dot com]

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

Bug ID: 66822
   Summary: Turn off X86_TUNE_ZERO_EXTEND_WITH_AND for IAMCU
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: julia.koval at intel dot com
  Target Milestone: ---

Since X86_TUNE_ZERO_EXTEND_WITH_AND generates bigger code, should
it be turned off for IAMCU?

[Bug tree-optimization/66522] handle casts in nr of iterations in try_transform_to_exit_first_loop_alt

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to vries from comment #3)
> New patch: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02085.html

Pinged: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00729.html

[Bug target/66821] reassoc-37.c fails on -march=pentium

[julia.koval at intel dot com]

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

--- Comment #2 from Yulia Koval  ---
Well, second one looks better, but first one generates 9b smaller code.
Can we disable this test for this target if it is not an issue?

[Bug tree-optimization/66823] New: -ftree-loop-if-convert-stores miscompiles gfortran.dg/elemental_optional_args_3.f90

[rguenth at gcc dot gnu.org]

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

Bug ID: 66823
   Summary: -ftree-loop-if-convert-stores miscompiles
gfortran.dg/elemental_optional_args_3.f90
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-*-*

On x86_64 with -m32/-ftree-loop-if-convert-stores I see

FAIL: gfortran.dg/elemental_optional_args_3.f90   -O3 -fomit-frame-pointer 
execution test
FAIL: gfortran.dg/elemental_optional_args_3.f90   -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/elemental_optional_args_3.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/elemental_optional_args_3.f90   -O3 -g  execution test

if-conversion changes

 if (p != 0)
  val = *p;
 else
  val = 1;

to

 tem = *p;
 val = p != 0 ? tem : 1;

[Bug target/66822] Turn off X86_TUNE_ZERO_EXTEND_WITH_AND for -miamcu

[julia.koval at intel dot com]

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

Yulia Koval  changed:

   What|Removed |Added

 CC||izamyatin at gmail dot com

--- Comment #1 from Yulia Koval  ---
I think it's a good idea.

[Bug tree-optimization/66823] -ftree-loop-if-convert-stores miscompiles gfortran.dg/elemental_optional_args_3.f90

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
And with -m64/-ftree-loop-if-convert-stores

FAIL: gcc.c-torture/execute/pr51933.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr51933.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr51933.c   -O3 -fomit-frame-pointer  execution
test
FAIL: gcc.c-torture/execute/pr51933.c   -O3 -fomit-frame-pointer -funroll-loops
 execution test
FAIL: gcc.c-torture/execute/pr51933.c   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gcc.c-torture/execute/pr51933.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr51933.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  execution test
FAIL: gcc.c-torture/execute/pr51933.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test

[Bug tree-optimization/66823] -ftree-loop-if-convert-stores miscompiles gfortran.dg/elemental_optional_args_3.f90

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Created attachment 35943
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35943&action=edit
patch triggering fails without -ftree-loop-if-convert-stores

Discovered while testing attached patch to improve if-conversion of loads

[Bug target/66821] reassoc-37.c fails on -march=pentium

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Yulia Koval from comment #2)
> Well, second one looks better, but first one generates 9b smaller code.
> Can we disable this test for this target if it is not an issue?

This is a tuning issue.  We want smaller codes for IA MCU.  Please check
-march=iamcu, not -march=pentium.  We can't change Pentium tuning.  But
we can change IA MCU tuning.

[Bug bootstrap/66801] [6 Regression] gcc miscompiled during PGO/LTO bootstrap

[trippels at gcc dot gnu.org]

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

--- Comment #17 from Markus Trippelsdorf  ---
Nothing helps; neither -fno-ipa-cp-alignment, nor -fno-tree-vectorize,
nor disabling the pattern above.

[Bug target/66824] New: -miamcu doesn't load FP constant into register directly

[hjl.tools at gmail dot com]

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

Bug ID: 66824
   Summary: -miamcu doesn't load FP constant into register
directly
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: izamyatin at gmail dot com, julia.koval at intel dot com,
zinovy.nis at gmail dot com
  Target Milestone: ---

[hjl@gnu-6 gcc]$ cat x.i
void bar (float);

void
foo (void)
{
  bar (3.0);
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S -m32 -miamcu -O2 x.i
[hjl@gnu-6 gcc]$ cat x.s
.file   "x.i"
.section.text.unlikely,"ax",@progbits
.LCOLDB1:
.text
.LHOTB1:
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movl.LC0, %eax
jmp bar
.cfi_endproc
.LFE0:
.size   foo, .-foo
.section.text.unlikely
.LCOLDE1:
.text
.LHOTE1:
.section.rodata.cst4,"aM",@progbits,4
.align 4
.LC0:
.long   1077936128
    .ident  "GCC: (GNU) 6.0.0 20150709 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 gcc]$ 

We should generate "mov $1077936128 %eax".

[Bug target/66824] -miamcu doesn't load FP constant into register directly

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-09
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Normally, we can't load FP constants into FP registers directly on x86.
Since IA MCU uses GPR for FP, it isn't a problem.  We need to add some
SF and DF constant load patterns to i386.md for !TARGET_80387.

[Bug tree-optimization/66823] -ftree-loop-if-convert-stores miscompiles gfortran.dg/elemental_optional_args_3.f90

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-07-09
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Index: gcc/tree-if-conv.c
===
--- gcc/tree-if-conv.c  (revision 225610)
+++ gcc/tree-if-conv.c  (working copy)
@@ -642,7 +642,7 @@ memrefs_read_or_written_unconditionally
|| TREE_CODE (ref_base_b) == REALPART_EXPR)
   ref_base_b = TREE_OPERAND (ref_base_b, 0);

-   if (!operand_equal_p (ref_base_a, ref_base_b, 0))
+   if (operand_equal_p (ref_base_a, ref_base_b, 0))
  {
tree cb = bb_predicate (gimple_bb (DR_STMT (b)));

[Bug target/66813] gcc.target/i386/asm-flag-5.c failed with -march=pentium

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-09
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00741.html

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Done in this patch.  I don't claim it's beautiful, but oh well.

diff --git gcc/fold-const.c gcc/fold-const.c
index 61eee4a..ce4e989 100644
--- gcc/fold-const.c
+++ gcc/fold-const.c
@@ -7050,11 +7050,18 @@ fold_plusminus_mult_expr (location_t loc, enum
tree_code code, tree type,
 }

   if (same)
-return fold_build2_loc (loc, MULT_EXPR, type,
-   fold_build2_loc (loc, code, type,
-fold_convert_loc (loc, type, alt0),
-fold_convert_loc (loc, type, alt1)),
-   fold_convert_loc (loc, type, same));
+{
+  /* Perform the expression in unsigned type to avoid introducing
+undefined behavior, then convert it back to the original type.  */
+  tree utype = unsigned_type_for (type);
+  utype = utype ? utype : type;
+  tree op0 = fold_build2_loc (loc, code, utype,
+ fold_convert_loc (loc, utype, alt0),
+ fold_convert_loc (loc, utype, alt1));
+  tree op1 = fold_convert_loc (loc, utype, same);
+  return fold_convert_loc (loc, type, fold_build2_loc (loc, MULT_EXPR,
+  utype, op0, op1));
+}

   return NULL_TREE;
 }
diff --git gcc/testsuite/gcc.dg/fold-plusmult-2.c
gcc/testsuite/gcc.dg/fold-plusmult-2.c
index 82f9898..c74688b 100644
--- gcc/testsuite/gcc.dg/fold-plusmult-2.c
+++ gcc/testsuite/gcc.dg/fold-plusmult-2.c
@@ -16,4 +16,4 @@ int bar (int i)
 /* But eventually this to be canonicalized to (i + 2) * 2.  */

 /* { dg-final { scan-tree-dump "i \\\* 4 \\\+ 2" "original" } } */
-/* { dg-final { scan-tree-dump "\\\(i \\\+ 2\\\) \\\* 2" "original" } } */
+/* { dg-final { scan-tree-dump "i \\\+ 2\\\) \\\* 2" "original" } } */
diff --git gcc/testsuite/gcc.dg/fold-plusmult.c
gcc/testsuite/gcc.dg/fold-plusmult.c
index 1781552..f30fcbf 100644
--- gcc/testsuite/gcc.dg/fold-plusmult.c
+++ gcc/testsuite/gcc.dg/fold-plusmult.c
@@ -11,4 +11,4 @@ int test2 (int a)
   return (a + a)*2;
 }

-/* { dg-final { scan-tree-dump-times " \\\* 4" 2 "original" } } */
+/* { dg-final { scan-tree-dump-times "a.? \\\* 4" 2 "original" } } */

[Bug middle-end/65534] tailcall not optimized away

[aldot at gcc dot gnu.org]

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

--- Comment #2 from Bernhard Reutner-Fischer  ---
(In reply to Jan Hubicka from comment #1)
> > #ifndef OPTIMIZE_MANUALLY
> > void setutent(void) {
> > ((void)0);
> > __setutent_unlocked();
> > ((void)0);
> > }
> > #else
> > extern __typeof (__setutent_unlocked) setutent
> > __attribute__ ((alias ("__setutent_unlocked")));
> > #endif
> 
> I do not think GCC can safely optimize this, becuase in the first
> case &setutent != &__setutent_unlocked, wile in the optimized
> case the addresses are equal.

Note that __setutent_unlocked is static, so i don't see how this specific case
would prevent optimization?

[Bug target/66821] reassoc-37.c fails on -march=pentium

[julia.koval at intel dot com]

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

--- Comment #4 from Yulia Koval  ---
The issue remains for -march=iamcu but not for -miamcu.

[Bug target/66821] reassoc-37.c fails on -march=pentium

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Yulia Koval from comment #4)
> The issue remains for -march=iamcu but not for -miamcu.

Let's fix -march=iamcu.

[Bug target/66821] reassoc-37.c fails on -march=pentium

[julia.koval at intel dot com]

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

--- Comment #6 from Yulia Koval  ---
msticlxl58$ size miam
   textdata bss dec hex filename
 72   0   0  72  48 miam
msticlxl58$ size march
   textdata bss dec hex filename
 81   0   0  81  51 march

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I'm actually testing a patch that moves all of this to match.pd  (without
fixing this, that said)

[Bug target/66821] reassoc-37.c fails on -march=pentium

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to Yulia Koval from comment #6)
> msticlxl58$ size miam
>textdata bss dec hex filename
>  72   0   0  72  48 miam
> msticlxl58$ size march
>textdata bss dec hex filename
>  81   0   0  81  51 march

Which one is -march=iamcu?

[Bug middle-end/66313] Unsafe factorization of a*b+a*c

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Ok, then I'll try to fix it up there.

A testcase:
/* PR middle-end/66313 */
/* { dg-do run } */
/* { dg-options "-fsanitize=undefined -fsanitize-undefined-trap-on-error" } */

int __attribute__ ((__noinline__))
f (int a, int b, int c)
{
  return a * b + a * c;
}

int
main ()
{
  int a = f (0, __INT_MAX__, __INT_MAX__);
  asm ("" : : "r" (a));
  a = f (-1, __INT_MAX__, 1);
  asm ("" : : "r" (a));
}

[Bug target/66821] reassoc-37.c fails on -march=pentium

[julia.koval at intel dot com]

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

--- Comment #8 from Yulia Koval  ---
(In reply to H.J. Lu from comment #7)
> (In reply to Yulia Koval from comment #6)
> > msticlxl58$ size miam
> >textdata bss dec hex filename
> >  72   0   0  72  48 miam
> > msticlxl58$ size march
> >textdata bss dec hex filename
> >  81   0   0  81  51 march
> 
> Which one is -march=iamcu?

miam is -miamcu, the same as just "-m32"
march is -march=iamcu

[Bug c++/65790] compilation error : receive std::index_sequence

[faithandbrave at gmail dot com]

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

--- Comment #5 from Akira Takahashi  ---
Thanks Paolo!!

[Bug middle-end/66820] [5/6 Regression] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:910

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
So, the problem is that the fold_stmt folding added in that revision creates
new decls that it doesn't put into the current gimplification context vars, but
instead creates whole function temporaries.

So we have in *.gimple:
  #pragma omp parallel num_threads(num_nthreads) shared(filenames)
{
  char * D.2570;
  long unsigned int D.2571;

  {
char filename[508];
int i;

try
  {
i = 0;
D.2570 = filenames[i];
strcpy (&filename, D.2570);
D.2571 = __builtin_strlen (&filename);
D.2572 = &filename + D.2571;
__builtin_memcpy (D.2572, "[data]", 7);
  }
finally
  {
filename = {CLOBBER};
  }
  }
where the D.2572 temporary has been created by fold_stmt, but it hasn't been
added into the parallel region (nor has private(D.2572) clause which would work
too).
Right now in gimplify.c maybe_fold_stmt has a hack to avoid folding anything
inside of ORT_TARGET regions, perhaps we should extend that also to
(ctx->region_type & (ORT_PARALLEL | ORT_TASK)) != 0 too (and adjust lower_omp
to fold_stmt accordingly even when taskreg_nesting_level is non-zero).
Or get rid of fold_stmt during gimplification altogether, though that is
supposedly not suitable for gcc 5 (and keep doing it only in forwprop and
later)?

[Bug c++/61491] An explicit specialization of a member enumeration of a class template is rejected

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #3 from Paolo Carlini  ---
Mine.

[Bug middle-end/66820] [5/6 Regression] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:910

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Note, this is unrelated to PR66633, that one even after the fix is a bug
somewhere in tree-nested.c.

[Bug target/66814] ICE: gcc.target/i386/avx512f-klogic-2.c

[uros at gcc dot gnu.org]

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

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jul  9 15:18:44 2015
New Revision: 225616

URL: https://gcc.gnu.org/viewcvs?rev=225616&root=gcc&view=rev
Log:
PR target/66814
* config/i386/predicates.md (nonimmediate_gr_operand): New predicate.
* config/i386/i386.md (not peephole2): Use nonimmediate_gr_operand.
(varous peephole2s): Use {GENERAL,SSE,MMX}_REGNO_P instead of
{GENERAL_SSE_MMX}_REG_P where appropriate.

testsuite/ChangeLog:

PR target/66814
* gcc.target/i386/pr66814.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr66814.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/predicates.md
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/66782] [5/6 Regression] Unable to run 64-bit wine after MS->SYSV register changes

[vmakarov at gcc dot gnu.org]

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

--- Comment #13 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Jul  9 15:39:53 2015
New Revision: 225618

URL: https://gcc.gnu.org/viewcvs?rev=225618&root=gcc&view=rev
Log:
2015-07-09  Vladimir Makarov  

PR rtl-optimization/66782
* lra-int.h (struct lra_insn_recog_data): Add comment about
clobbered hard regs for arg_hard_regs.
* lra.c (lra_set_insn_recog_data): Add clobbered hard regs.
* lra-lives.c (process_bb_lives): Process clobbered hard regs.
Add condition for processing used hard regs.
* lra-constraints.c (update_ebb_live_info, inherit_in_ebb):
Process clobbered hard regs.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/lra-int.h
trunk/gcc/lra-lives.c
trunk/gcc/lra.c

[Bug target/66523] the new clang-based assembler in Xcode 7 on 10.11 fails on libobjc/NXConstStr.m

[howarth.at.gcc at gmail dot com]

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

--- Comment #17 from Jack Howarth  ---
Any response on the request for RM approval for adding this to 5.2.0?

[Bug middle-end/66633] [5/6 regression] ICE on valid "verify_gimple failed" with OpenMP

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
Created attachment 35944
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35944&action=edit
gcc6-pr66633.patch

Untested fix.

[Bug target/66523] the new clang-based assembler in Xcode 7 on 10.11 fails on libobjc/NXConstStr.m

[mrs at gcc dot gnu.org]

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

--- Comment #18 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Thu Jul  9 17:50:58 2015
New Revision: 225623

URL: https://gcc.gnu.org/viewcvs?rev=225623&root=gcc&view=rev
Log:
2015-07-09  Iain Sandoe  

PR target/66523
* config/darwin.c (darwin_mark_decl_preserved): Exclude 'L' label names
from
preservation.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/darwin.c

[Bug target/66523] the new clang-based assembler in Xcode 7 on 10.11 fails on libobjc/NXConstStr.m

[mrs at gcc dot gnu.org]

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

--- Comment #19 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Thu Jul  9 17:56:23 2015
New Revision: 225624

URL: https://gcc.gnu.org/viewcvs?rev=225624&root=gcc&view=rev
Log:
2015-07-09  Iain Sandoe  

PR target/66523
* config/darwin.c (darwin_mark_decl_preserved): Exclude 'L' label names
from
preservation.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/darwin.c

[Bug target/66523] the new clang-based assembler in Xcode 7 on 10.11 fails on libobjc/NXConstStr.m

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.9.4, 5.1.1, 5.2.0
 Resolution|--- |FIXED
  Known to fail||4.9.3, 5.1.0

--- Comment #20 from mrs at gcc dot gnu.org  ---
Fixed.

[Bug target/66821] reassoc-37.c fails on -march=iamcu

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-09
 Ever confirmed|0   |1

--- Comment #9 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00806.html

[Bug target/66822] Turn off X86_TUNE_ZERO_EXTEND_WITH_AND for -miamcu

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Yulia Koval from comment #1)
> I think it's a good idea.

If we do that, we may also adjust iamcu_cost:

  COSTS_N_INSNS (3),/* cost of movsx */
  COSTS_N_INSNS (2),/* cost of movzx */

[Bug pch/14940] PCH largefile test fails on various platforms

[xricht17 at stud dot fit.vutbr.cz]

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

--- Comment #50 from Martin Richter  ---
The following patch fixes segfault when gt_pch_use_address fails (returns -1).
fatal_error now correctly shows an error message and terminates the program.
I have basicly only reordered reads, and placed them after the file mapping
itself. Global pointers are changed only after gt_pch_use_address succeeds, so
in case of failure they still contain valid addresses.

This patch is meant for the master branch. However, it should not be hard to
modify it for others.


diff --git a/gcc/ggc-common.c b/gcc/ggc-common.c
index 5096837..f741f2c 100644
--- a/gcc/ggc-common.c
+++ b/gcc/ggc-common.c
@@ -599,7 +599,9 @@ gt_pch_restore (FILE *f)
   size_t i;
   struct mmap_info mmi;
   int result;
-
+  long pch_tabs_off;
+  long pch_data_off;
+  
   /* Delete any deletable objects.  This makes ggc_pch_read much
  faster, as it can be sure that no GCable objects remain other
  than the ones just read in.  */
@@ -607,20 +609,24 @@ gt_pch_restore (FILE *f)
 for (rti = *rt; rti->base != NULL; rti++)
   memset (rti->base, 0, rti->stride);

-  /* Read in all the scalar variables.  */
+  /* We need to read tables after mapping, or fatal_error will
+ segfault when gt_pch_use_address returns -1. Skip them for now. */
+  pch_tabs_off = ftell(f);
+ 
+  /* Skip all the scalar variables. */
   for (rt = gt_pch_scalar_rtab; *rt; rt++)
 for (rti = *rt; rti->base != NULL; rti++)
-  if (fread (rti->base, rti->stride, 1, f) != 1)
-   fatal_error (input_location, "can%'t read PCH file: %m");
+  if (fseek (f, rti->stride, SEEK_CUR) != 0)
+fatal_error (input_location, "can%'t read PCH file: %m");

-  /* Read in all the global pointers, in 6 easy loops.  */
+  /* Skip all the global pointers. */
   for (rt = gt_ggc_rtab; *rt; rt++)
 for (rti = *rt; rti->base != NULL; rti++)
   for (i = 0; i < rti->nelt; i++)
-   if (fread ((char *)rti->base + rti->stride * i,
-  sizeof (void *), 1, f) != 1)
- fatal_error (input_location, "can%'t read PCH file: %m");
-
+if (fseek (f, sizeof (void *), SEEK_CUR) != 0)
+  fatal_error (input_location, "can%'t read PCH file: %m");
+  
+  /* mmi still has to be read now. */  
   if (fread (&mmi, sizeof (mmi), 1, f) != 1)
 fatal_error (input_location, "can%'t read PCH file: %m");

@@ -631,12 +637,35 @@ gt_pch_restore (FILE *f)
   if (result == 0)
 {
   if (fseek (f, mmi.offset, SEEK_SET) != 0
- || fread (mmi.preferred_base, mmi.size, 1, f) != 1)
-   fatal_error (input_location, "can%'t read PCH file: %m");
+  || fread (mmi.preferred_base, mmi.size, 1, f) != 1)
+fatal_error (input_location, "can%'t read PCH file: %m");
 }
   else if (fseek (f, mmi.offset + mmi.size, SEEK_SET) != 0)
 fatal_error (input_location, "can%'t read PCH file: %m");
+
+  /* File mapping done, read tables now. */
+  pch_data_off = ftell(f);
+  
+  if (fseek (f, pch_tabs_off, SEEK_SET) != 0)
+fatal_error (input_location, "can%'t read PCH file: %m");

+  /* Read in all the scalar variables.  */
+  for (rt = gt_pch_scalar_rtab; *rt; rt++)
+for (rti = *rt; rti->base != NULL; rti++)
+  if (fread (rti->base, rti->stride, 1, f) != 1)
+fatal_error (input_location, "can%'t read PCH file: %m");
+
+  /* Read in all the global pointers, in 6 easy loops.  */
+  for (rt = gt_ggc_rtab; *rt; rt++)
+for (rti = *rt; rti->base != NULL; rti++)
+  for (i = 0; i < rti->nelt; i++)
+if (fread ((char *)rti->base + rti->stride * i,
+sizeof (void *), 1, f) != 1)
+  fatal_error (input_location, "can%'t read PCH file: %m");
+
+  if (fseek (f, pch_data_off, SEEK_SET) != 0)
+fatal_error (input_location, "can%'t read PCH file: %m");
+
   ggc_pch_read (f, mmi.preferred_base);

   gt_pch_restore_stringpool ();

[Bug jit/66812] jit code-generation example that unexpectedly required -fno-strict-aliasing to work

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Created attachment 35945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35945&action=edit
Minimal reproducer

[Bug jit/66812] jit code-generation example that unexpectedly required -fno-strict-aliasing to work

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Output from fre1 dump (at e.g. optlevel 3) (with TDF_DETAILS enabled) is:

;; Function test_pr66812 (test_pr66812, funcdef_no=0, decl_uid=56,
cgraph_uid=0, symbol_order=0)

Setting value number of .MEM_4(D) to .MEM_4(D) (changed)
Value numbering .MEM_5 stmt = MEM[(struct value *)arr_2(D) +
16B].union_field.i_field = 0;
RHS 0 simplified to 0
No store match
Value numbering store MEM[(struct value *)arr_2(D) + 16B].union_field.i_field
to 0
Setting value number of .MEM_5 to .MEM_5 (changed)
Value numbering .MEM_8 stmt = MEM[(struct value *)arr_2(D) + 16B].type_code =
0;
RHS 0 simplified to 0
No store match
Value numbering store MEM[(struct value *)arr_2(D) + 16B].type_code to 0
Setting value number of .MEM_8 to .MEM_8 (changed)
Value numbering .MEM_11 stmt = MEM[(struct value *)arr_2(D) +
16B].union_field.ll_field = 10;
RHS 10 simplified to 10
No store match
Value numbering store MEM[(struct value *)arr_2(D) + 16B].union_field.ll_field
to 10
Setting value number of .MEM_11 to .MEM_11 (changed)
Value numbering .MEM_14 stmt = MEM[(struct value *)arr_2(D) + 16B].type_code =
19;
RHS 19 simplified to 19
No store match
Value numbering store MEM[(struct value *)arr_2(D) + 16B].type_code to 19
Setting value number of .MEM_14 to .MEM_14 (changed)
Value numbering .MEM_17 stmt = MEM[(struct value *)arr_2(D) +
16B].union_field.i_field = 0;
RHS 0 simplified to 0
No store match
Value numbering store MEM[(struct value *)arr_2(D) + 16B].union_field.i_field
to 0
Setting value number of .MEM_17 to .MEM_17 (changed)
Value numbering .MEM_20 stmt = MEM[(struct value *)arr_2(D) + 16B].type_code =
0;
RHS 0 simplified to 0
No store match
Value numbering store MEM[(struct value *)arr_2(D) + 16B].type_code to 0
Setting value number of .MEM_20 to .MEM_20 (changed)
Value numbers:
Deleted redundant store MEM[(struct value *)arr_2(D) + 16B].union_field.i_field
= 0;
Removing dead stmt MEM[(struct value *)arr_2(D) + 16B].union_field.i_field = 0;
test_pr66812 (struct value * arr)
{
:
  MEM[(struct value *)arr_2(D) + 16B].union_field.i_field = 0;
  MEM[(struct value *)arr_2(D) + 16B].type_code = 0;
  MEM[(struct value *)arr_2(D) + 16B].union_field.ll_field = 10;
  MEM[(struct value *)arr_2(D) + 16B].type_code = 19;
  MEM[(struct value *)arr_2(D) + 16B].type_code = 0;
  return;

}

[Bug jit/66812] jit code-generation example that unexpectedly required -fno-strict-aliasing to work

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
(In reply to David Malcolm from comment #2)
> Output from fre1 dump (at e.g. optlevel 3) (with TDF_DETAILS enabled) is:
 (snip)

> Removing dead stmt MEM[(struct value *)arr_2(D) + 16B].union_field.i_field = 
> 0;

I believe that this statement *isn't* dead, and that removing it is the bug.


> test_pr66812 (struct value * arr)
> {
> :
>   MEM[(struct value *)arr_2(D) + 16B].union_field.i_field = 0;
>   MEM[(struct value *)arr_2(D) + 16B].type_code = 0;
>   MEM[(struct value *)arr_2(D) + 16B].union_field.ll_field = 10;
>   MEM[(struct value *)arr_2(D) + 16B].type_code = 19;
>   MEM[(struct value *)arr_2(D) + 16B].type_code = 0;
>   return;

Hence union_field.ll_field == 10 rather than == 0.

[Bug target/66824] -miamcu doesn't load FP constant into register directly

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00809.html

[Bug jit/66812] jit code-generation example that unexpectedly required -fno-strict-aliasing to work

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Created attachment 35946
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35946&action=edit
Equivalent C code

(generated using gcc_jit_context_dump_to_file and lightly editing until valid
C)

[Bug jit/66812] jit code-generation example that unexpectedly required -fno-strict-aliasing to work

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
(In reply to David Malcolm from comment #4)
> Created attachment 35946 [details]
> Equivalent C code
> 
> (generated using gcc_jit_context_dump_to_file and lightly editing until
> valid C)

Compiling this with trunk with -O3 *doesn't* show the fre1 issue exhibited by
libgccjit; dump from cc1's fre1 looks like this:

;; Function test_pr66812 (test_pr66812, funcdef_no=0, decl_uid=1762,
cgraph_uid=0, symbol_order=0)

Setting value number of .MEM_3(D) to .MEM_3(D) (changed)
Value numbering .MEM_4 stmt = MEM[(struct value *)arr_1(D) +
16B].union_field.i_field = 0;
RHS 0 simplified to 0
No store match
Value numbering store MEM[(struct value *)arr_1(D) + 16B].union_field.i_field
to 0
Setting value number of .MEM_4 to .MEM_4 (changed)
Value numbering .MEM_6 stmt = MEM[(struct value *)arr_1(D) + 16B].type_code =
0;
RHS 0 simplified to 0
No store match
Value numbering store MEM[(struct value *)arr_1(D) + 16B].type_code to 0
Setting value number of .MEM_6 to .MEM_6 (changed)
Value numbering .MEM_8 stmt = MEM[(struct value *)arr_1(D) +
16B].union_field.ll_field = 10;
RHS 10 simplified to 10
No store match
Value numbering store MEM[(struct value *)arr_1(D) + 16B].union_field.ll_field
to 10
Setting value number of .MEM_8 to .MEM_8 (changed)
Value numbering .MEM_10 stmt = MEM[(struct value *)arr_1(D) + 16B].type_code =
19;
RHS 19 simplified to 19
No store match
Value numbering store MEM[(struct value *)arr_1(D) + 16B].type_code to 19
Setting value number of .MEM_10 to .MEM_10 (changed)
Value numbering .MEM_12 stmt = MEM[(struct value *)arr_1(D) +
16B].union_field.i_field = 0;
RHS 0 simplified to 0
No store match
Value numbering store MEM[(struct value *)arr_1(D) + 16B].union_field.i_field
to 0
Setting value number of .MEM_12 to .MEM_12 (changed)
Value numbering .MEM_14 stmt = MEM[(struct value *)arr_1(D) + 16B].type_code =
0;
RHS 0 simplified to 0
No store match
Value numbering store MEM[(struct value *)arr_1(D) + 16B].type_code to 0
Setting value number of .MEM_14 to .MEM_14 (changed)
Value numbers:
test_pr66812 (struct value * arr)
{
  :
  MEM[(struct value *)arr_1(D) + 16B].union_field.i_field = 0;
  MEM[(struct value *)arr_1(D) + 16B].type_code = 0;
  MEM[(struct value *)arr_1(D) + 16B].union_field.ll_field = 10;
  MEM[(struct value *)arr_1(D) + 16B].type_code = 19;
  MEM[(struct value *)arr_1(D) + 16B].union_field.i_field = 0;
  MEM[(struct value *)arr_1(D) + 16B].type_code = 0;
  return;

}


Note that the final:
  MEM[(struct value *)arr_1(D) + 16B].union_field.i_field = 0;
is still present, and the lack of the:
> Deleted redundant store MEM[(struct value *)arr_2(D) + 
> 16B].union_field.i_field = 0;
from the TDF_DETAILS version of the dump.

So for some reason fre1 is more aggressive on this with libgccjit than with
cc1.

[Bug target/66523] the new clang-based assembler in Xcode 7 on 10.11 fails on libobjc/NXConstStr.m

[howarth.at.gcc at gmail dot com]

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

--- Comment #21 from Jack Howarth  ---
(In reply to m...@gcc.gnu.org from comment #15)
> Jack, can you spin a gcc-4.9 test?

Regression test results for current gcc-4_9-branch with patch applied posted at
https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg00953.html

[Bug target/66822] Turn off X86_TUNE_ZERO_EXTEND_WITH_AND for -miamcu

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Please hold a bit with this change, I have a patch that improves generation of
zero_extend substantially.

[Bug target/66821] reassoc-37.c fails on -march=iamcu

[hjl at gcc dot gnu.org]

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

--- Comment #10 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Thu Jul  9 20:35:56 2015
New Revision: 225635

URL: https://gcc.gnu.org/viewcvs?rev=225635&root=gcc&view=rev
Log:
Adjust variable shift costs for IA MCU

We reduce code size for IA MCU by adjusting variable shift costs for IA
MCU

PR target/66821
* config/i386/i386.c (iamcu_cost): Adjust variable shift costs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug target/66821] reassoc-37.c fails on -march=iamcu

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #11 from H.J. Lu  ---
Fixed.

[Bug jit/66812] jit code-generation example that unexpectedly required -fno-strict-aliasing to work

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||alias, wrong-code

--- Comment #6 from Andrew Pinski  ---
This sounds like there is an aliasing set problem.

In the C front-end we have:


5174   /* Permit type-punning when accessing a union, provided the access
5175  is directly through the union.  For example, this code does not
5176  permit taking the address of a union member and then storing
5177  through it.  Even the type-punning allowed here is a GCC
5178  extension, albeit a common and useful one; the C standard says
5179  that such accesses have implementation-defined behavior.  */
5180   for (u = t;
5181TREE_CODE (u) == COMPONENT_REF || TREE_CODE (u) == ARRAY_REF;
5182u = TREE_OPERAND (u, 0))
5183 if (TREE_CODE (u) == COMPONENT_REF
5184 && TREE_CODE (TREE_TYPE (TREE_OPERAND (u, 0))) == UNION_TYPE)
5185   return 0;
5186 


In c_common_get_alias_set .  Maybe that is missing on the libjit side.

[Bug jit/66783] No error-checking for creating structs containing opaque structs

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Root cause found: it's because of the langhook:
  LANG_HOOKS_GET_ALIAS_SET
which it looks like I need to implement for libgccjit.

[Bug jit/66812] jit code-generation example that unexpectedly required -fno-strict-aliasing to work

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-07-09
 Ever confirmed|0   |1

--- Comment #7 from David Malcolm  ---
(In reply to Andrew Pinski from comment #6)
> This sounds like there is an aliasing set problem.
> 
> In the C front-end we have:
> 
> 
> 5174   /* Permit type-punning when accessing a union, provided the access
> 5175  is directly through the union.  For example, this code does not
> 5176  permit taking the address of a union member and then storing
> 5177  through it.  Even the type-punning allowed here is a GCC
> 5178  extension, albeit a common and useful one; the C standard says
> 5179  that such accesses have implementation-defined behavior.  */
> 5180   for (u = t;
> 5181TREE_CODE (u) == COMPONENT_REF || TREE_CODE (u) == ARRAY_REF;
> 5182u = TREE_OPERAND (u, 0))
> 5183 if (TREE_CODE (u) == COMPONENT_REF
> 5184 && TREE_CODE (TREE_TYPE (TREE_OPERAND (u, 0))) == UNION_TYPE)
> 5185   return 0;
> 5186 
> 
> 
> In c_common_get_alias_set .  Maybe that is missing on the libjit side.

Thanks.  Yes; I'd just figured that out, by single-stepping.

[Bug jit/66783] No error-checking for creating structs containing opaque structs

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
(In reply to David Malcolm from comment #3)
> Root cause found: it's because of the langhook:
>   LANG_HOOKS_GET_ALIAS_SET
> which it looks like I need to implement for libgccjit.

Ooops, wrong bug; ignore this comment

[Bug jit/66812] jit code-generation example that unexpectedly required -fno-strict-aliasing to work

[dmalcolm at gcc dot gnu.org]

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

--- Comment #8 from David Malcolm  ---
Root cause found: it's because of the langhook:
  LANG_HOOKS_GET_ALIAS_SET
which it looks like I need to implement for libgccjit.

[Bug c/66825] New: RFE: Add attributes for symbol versioning.

[carlos at redhat dot com]

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

Bug ID: 66825
   Summary: RFE: Add attributes for symbol versioning.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlos at redhat dot com
  Target Milestone: ---

At present gcc supports alias, weak, section, optimize, used, visibility,
tls_model, and that lets user application do a lot of things with functions,
particularly with respect to creating aliases, changing their visibility and
linkage properties (weak vs. strong). I expect that some of these attributes
apply only to ELF support in the toolchain as a whole.

What we are missing is symbol versioning for ELF, and the alias attribute can't
be used for this (treats the target as the function name without understanding
versions).

At present in glibc we need to do the following:

#  define _symbol_version(real, name, version) \
 __asm__ (".symver " #real "," #name "@" #version)
#  define _default_symbol_version(real, name, version) \
 __asm__ (".symver " #real "," #name "@@" #version)

It would be nice if symbol versioning did not require __asm__ directives which
in general hide such information from the compiler and potential plugins.

I have no requirements as to how it should or could be implemented, and I leave
that up to the gcc developers to think about.

My suggestion is that at a minimum it needs a name, version, and default flag
(to avoid conflating "@" or "@@" into the version name), and it might look like
this:

version_def (target, version, default)
* The attribute may only be applied to a function definition. The attribute
creates a definition of a versioned symbol. The function is aliased under the
symbol TARGET with version VERSION. The symbol TARGET is the default symbol,
resolves other references without versions, only if DEFAULT is true.

Example:

int foo (void) __attribute__ ((version (bar, "BARLIB_1.0", true)))
{
  return 0;
}

int foo2 (void) __atttribute__ ((version (bar, "BARLIB_0.9", false)))
{
  return 2;
}

These functions will be available for linking and if that is not what you want
then you must use the features of your linker to limit the set of exported
functions. For GNU ld the link map nodes will correspond to the versions and a
link map will be required.

e.g.
BARLIB_1.0 {
  global: bar;
  local: *;
}
BARLIB_0.9 {
  global: bar;
  local: *;
}

Implementation note:
- Use `.symver` to implement the attribute, and if default is true you use @@
otherwise one @ for the symbol version.

Notes:
- After implementing this we could make gcc us it also and update the wiki
page:
https://gcc.gnu.org/wiki/SymbolVersioning
- A follow-up to this is "version_ref" attribute which allows you to create a
declaration of a function e.g. extern int memcpy (void) __attribute__
((version_ref (memcpy, GLIBC_2.2.5, false))); at a particular version/default
(for symmetry with version_def) and then all callers in the compilation unit
will call through that version (the version you want to reference, hence
"version_ref"). This can be used to create test applications that call old
versions of symbols without needing the old DSOs to link against. This again
works using .symver, but requires that memcpy not be implemented in the present
object file. The .symver without a definition of the function causes the object
to reference the alias at that particular version and thus lets you link
against old versions of functions. This is limited in scope to just the single
file you compiled. So you could for example write tests that test each of the
new and old symbol versions without using asm inlines and the compiler could be
aware of function versions (for some future purpose).

[Bug jit/66812] jit code-generation example that unexpectedly required -fno-strict-aliasing to work

[dmalcolm at gcc dot gnu.org]

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

--- Comment #9 from David Malcolm  ---
Notes to self:
For the given stmt, fre1's call to:
  val = vn_reference_lookup (gimple_assign_lhs (stmt),
 gimple_vuse (stmt), VN_WALK, NULL);
is returning NULL for "val", whereas libgccjit is returning the const_int 0
node,
hence the latter regards stmt as as redundant assignment and eliminates it.

Within the call to vn_reference_lookup:

2232  vr1.set = get_alias_set (op);

For cc1:
  (gdb) p vr1.set
  $24 = 0

  (gdb) p wvnresult
  $26 = (vn_reference_t) 0x0

and it bails out of vn_reference_lookup here:
  2262return NULL_TREE;

Whereas for libgccjit, the call to vn_reference_lookup does this:

  (gdb) p vr1.set
  $6 = 2

and walk_non_aliased_vuses returns non-NULL:
  (gdb) p wvnresult
  $7 = (vn_reference_t) 0x677dd0


libgccjit:
  (gdb) call get_alias_set (op)
  $11 = 2

cc1:
  (gdb) call get_alias_set(op)
  $27 = 0

and this is because of a langhook, implemented for C/C++/ObjC, but not (yet)
for libgccjit:

837 alias_set_type
838 get_alias_set (tree t)
839 {
(snip)
849 
850   /* We can be passed either an expression or a type.  This and the
851  language-specific routine may make mutually-recursive calls to
each other
852  to figure out what to do.  At each juncture, we see if this is a
tree
853  that the language may need to handle specially.  First handle
things that
854  aren't types.  */
855   if (! TYPE_P (t))
856 {
857   /* Give the language a chance to do something with this tree
858  before we look at it.  */
859   STRIP_NOPS (t);
860   set = lang_hooks.get_alias_set (t);
861   if (set != -1)
862 return set;

c/c-objc-common.h:45:#undef LANG_HOOKS_GET_ALIAS_SET
c/c-objc-common.h:46:#define LANG_HOOKS_GET_ALIAS_SET c_common_get_alias_set

c-family/c-common.c:
5157/* Return the typed-based alias set for T, which may be an expression
5158   or a type.  Return -1 if we don't do anything special.  */
5159
5160alias_set_type
5161c_common_get_alias_set (tree t)
5162{
5163  tree u;
(snip)
5173
5174  /* Permit type-punning when accessing a union, provided the access
5175 is directly through the union.  For example, this code does not
5176 permit taking the address of a union member and then storing
5177 through it.  Even the type-punning allowed here is a GCC
5178 extension, albeit a common and useful one; the C standard says
5179 that such accesses have implementation-defined behavior.  */
5180  for (u = t;
5181   TREE_CODE (u) == COMPONENT_REF || TREE_CODE (u) == ARRAY_REF;
5182   u = TREE_OPERAND (u, 0))
5183if (TREE_CODE (u) == COMPONENT_REF
5184&& TREE_CODE (TREE_TYPE (TREE_OPERAND (u, 0))) == UNION_TYPE)
5185  return 0;

For C, it's exiting at line 5185 for the given statement's LHS.

[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #49 from Matthias Klose  ---
Kaz, please could you propose these patches for 5.2 too, even if the branch is
currently frozen?

[Bug tree-optimization/66718] Non-invariant ADDR_EXPR not vectorized

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul  9 21:11:28 2015
New Revision: 225637

URL: https://gcc.gnu.org/viewcvs?rev=225637&root=gcc&view=rev
Log:
PR tree-optimization/66718
* tree-vect-stmts.c (struct simd_call_arg_info): Add simd_lane_linear
field.
(vect_simd_lane_linear): New function.
(vectorizable_simd_clone_call): Support using linear arguments for
addresses of arrays elements indexed by GOMP_SIMD_LANE result.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-stmts.c