[Bug tree-optimization/48052] loop not vectorized if index is "unsigned int"

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
That's an interesting idea - your argument is that if niter analysis was able
to compute an expression for the number of iterations and the cast we are
looking at
is a widening of a BIV then it is ok to assume the BIV does not wrap.

Unfortunately this breaks down (eventually not in practice due to your
exclusion of constant initial BIV value) for cases like


  for (unsigned i = 3; i != 2; i+=7)
;

where niter analysis can still compute the number of iterations (I've made
the numbers up, so maybe that loop will never terminate...).

Still the idea is interesting as we might be able to record whether BIVs
overflow or not.

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[dominiq at lps dot ens.fr]

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

--- Comment #15 from Dominique d'Humieres  ---
> Created attachment 35464 [details]
> Follow-up patch fixing latest regression.
>
> With this patch all code samples and the code in the tar-archive compile
> and execute well. This patch will need most of my previous patches. The total
> set of all of my patches is available on the gitmirror in the branch
> vehre/head_cosmo

With this patch I still get the ICE when compiling the file evaluators.f90.

[Bug fortran/62283] basic-block vectorization fails

[rguenth at gcc dot gnu.org]

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

--- Comment #27 from Richard Biener  ---
Author: rguenth
Date: Wed May  6 06:47:38 2015
New Revision: 222843

URL: https://gcc.gnu.org/viewcvs?rev=222843&root=gcc&view=rev
Log:
2015-05-06  Richard Biener  

PR tree-optimization/62283
* gcc.dg/vect/bb-slp-14.c: Adjust.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-14.c

[Bug fortran/62283] basic-block vectorization fails

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #26 from Richard Biener  ---
Fixed.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

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

Bug 62283 Summary: basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/62283] basic-block vectorization fails

[rguenth at gcc dot gnu.org]

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

--- Comment #25 from Richard Biener  ---
(In reply to Rainer Orth from comment #23)
> The bb-slp-14.c testcase now FAILs on Solaris/SPARC.  Attaching the dump.
> 
>   Rainer

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/bb-slp-14.c:19:10: note:
not vectorized: relevant stmt not supported: _11 = a0_4 * x_10(D);

ok, so we miss to test for vect_int_mult.

[Bug libgcc/66032] RTEMS MIPS build fails on FreeBSD

[chris at contemporary dot net.au]

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

--- Comment #3 from Chris Johns  ---
Built GNU sed from source and added to my path:

ruru rtems $ sed --version
GNU sed version 4.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE,
to the extent permitted by law.

The build was successful.

[Bug tree-optimization/65957] Loop with if-statement yields different results for -O3 vs -O3 -fno-tree-vectorize

[sbrozell at rci dot rutgers.edu]

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

--- Comment #2 from Scott Brozell  ---
Ok, we shall add this to the todo list.

[Bug target/66033] New: rs6000 nops removed by rtl_dce

[amodra at gmail dot com]

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

Bug ID: 66033
   Summary: rs6000 nops removed by rtl_dce
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

gen_nop() is called in various places in rs6000.c.  These nops don't survive
rtl_dce, thus breaking darwin's TARGET_FIX_AND_CONTINUE, and the scheduler nop
insertion.

[Bug libgcc/66032] RTEMS MIPS build fails on FreeBSD

[chris at contemporary dot net.au]

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

--- Comment #2 from Chris Johns  ---
(In reply to Andrew Pinski from comment #1)
> Have you tried GNU sed rather than BSD sed?

No and a good idea. I will. 

FYI I tend to keep the machines used for testing builds clean and minimal to
minimised the interactions. It makes supporting users easier.

[Bug ipa/66004] [6 Regression]: performance of 26_numerics/random/negative_binomial_distribution/operators/values.cc

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
  Component|libstdc++   |ipa

--- Comment #2 from Hans-Peter Nilsson  ---
Bisecting shows that revision r221859 is the culprit, adding Honza to CC.

I hope to add analysis of the compiled code showing (an example of) the
regressed code, but it would be really nice if Someone could
performance-regression test r221859 (compared to r221858) on another target.

Weird that a performance-regression of 16% is supposed to be *fixed* by that
commit (see PR65076). While it refers to *compile-time* regression, that is
just another name for a *run-time* performance-regression of the bootstrapped
compiler, apparently typical for at least the execution-path when compiling
tramp3d-v4.cpp supposedly for x86_64-linux and
26_numerics/random/negative_binomial_distribution/operators/values.cc for
cris-elf.

Note that the regression is not fixed for cris-elf at r222305 (a later
additional commit referencing PR65076).

Revision-numbers and cycle numbers while bisecting follows. Note the very
stable numbers:

r221618 34633750695
r221758 34633750695
r221828 34633750695
r221845 34633750695
r221854 34633750695
r221858 34633750695
r221859 40068917595
r221860 40068917595
r221863 40068917595
r221899 40068917595
r222180 40068917595
r222742 40111446541

[Bug lto/65995] LTO: ICE in add_symbol_to_partition_1 for debug build

[daniel.f.starke at freenet dot de]

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

--- Comment #4 from Daniel Starke  ---
I was able to build r222810 without bootstrap. However, the result remains the
same. I am still getting the following error when linking all together:
lto1.exe: internal compiler error: in add_symbol_to_partition_1, at
lto/lto-partition.c:211
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper.exe: fatal error: E:\msys\mingw64-64\bin\g++.exe returned 1 exit
status
compilation terminated.
collect2.exe: fatal error: lto-wrapper returned 1 exit status
compilation terminated.

[Bug libgcc/66032] RTEMS MIPS build fails on FreeBSD

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Have you tried GNU sed rather than BSD sed?

[Bug libgcc/66032] New: RTEMS MIPS build fails on FreeBSD

[chris at contemporary dot net.au]

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

Bug ID: 66032
   Summary: RTEMS MIPS build fails on FreeBSD
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chris at contemporary dot net.au
  Target Milestone: ---

Created attachment 35473
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35473&action=edit
RSB Report for RTEMS 4.1  MIPS failure on FreeBSD.

Build RTEMS 4.11 MIP tool set fails on FreeBSD. The attached log file shows the
error.

The configure command line is:

../gcc-4.9.2/configure --prefix=/opt/work/rtems/4.11
--bindir=/opt/work/rtems/4.11/bin --exec_prefix=/opt/work/rtems/4.11
--includedir=/opt/work/rtems/4.11/include --libdir=/opt/work/rtems/4.11/lib
--libexecdir=/opt/work/rtems/4.11/libexec
--mandir=/opt/work/rtems/4.11/share/man
--infodir=/opt/work/rtems/4.11/share/info --datadir=/opt/work/rtems/4.11/share
--build=x86_64-freebsd10.1 --host=x86_64-freebsd10.1 --target=m32r-rtems4.11
--disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib
--with-system-zlib --disable-nls --without-included-gettext
--disable-win32-registry --enable-version-specific-runtime-libs --disable-lto
--enable-newlib-io-c99-formats --enable-newlib-iconv
--enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
--enable-threads --disable-plugin --enable-languages=c,c++

newlib is the newlib-2.2.0-20150423 snapshot provided by Jeff this week.

I tracked the issue down to the sed commands that handle the file sets for each
multilib variant but I started to get lost. Sed is not a natural language for
me and I do not a linux box around to see what is expected.

[Bug target/66020] [6.0 regression] FAIL: gcc.target/powerpc/ppc64-abi-2.c execution test

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-06
 Ever confirmed|0   |1

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  ---
Author: jason
Date: Wed May  6 02:07:34 2015
New Revision: 222836

URL: https://gcc.gnu.org/viewcvs?rev=222836&root=gcc&view=rev
Log:
DR 1518
DR 1630
PR c++/54835
PR c++/60417
* call.c (convert_like_real): Check value-initialization before
explicit.
* typeck2.c (process_init_constructor_record): Don't set
CONSTRUCTOR_IS_DIRECT_INIT.
(process_init_constructor_array): Likewise.
* init.c (build_vec_init): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-dr1518.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/g++.dg/cpp0x/initlist40.C

[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill  ---
Author: jason
Date: Wed May  6 02:07:34 2015
New Revision: 222836

URL: https://gcc.gnu.org/viewcvs?rev=222836&root=gcc&view=rev
Log:
DR 1518
DR 1630
PR c++/54835
PR c++/60417
* call.c (convert_like_real): Check value-initialization before
explicit.
* typeck2.c (process_init_constructor_record): Don't set
CONSTRUCTOR_IS_DIRECT_INIT.
(process_init_constructor_array): Likewise.
* init.c (build_vec_init): Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist-dr1518.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/init.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/g++.dg/cpp0x/initlist40.C

[Bug c/66031] New: Spurious array bounds warning

[jmattson at vmware dot com]

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

Bug ID: 66031
   Summary: Spurious array bounds warning
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmattson at vmware dot com
  Target Milestone: ---

Created attachment 35472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35472&action=edit
Preprocessed source file

As a result of inlining, gcc generates an unreachable out-of-bounds array
access and then complains about it.

% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--program-suffix=-4.8 --enable-linux-futex --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux) 

% gcc -O2 -Wall v.i
v.c: In function ‘main’:
v.c:7:28: warning: array subscript is above array bounds [-Warray-bounds]
if (n - 1 >= f) return p[n];
^

[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin

[mrs at gcc dot gnu.org]

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

--- Comment #12 from mrs at gcc dot gnu.org  ---
Author: mrs
Date: Wed May  6 00:33:49 2015
New Revision: 222835

URL: https://gcc.gnu.org/viewcvs?rev=222835&root=gcc&view=rev
Log:
2015-05-05  Jack Howarth  

Backport from mainline
2014-05-29  Mike Stump  
PR debug/61352
* collect2.c (maybe_run_lto_and_relink): Be sure to always run
post ld passes when lto is used.

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

[Bug middle-end/66021] GCC miscompiles Z3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|critical|normal

--- Comment #4 from Andrew Pinski  ---
(In reply to Nuno Lopes from comment #3)
> Created attachment 35467 [details]
> reduced test case

The reduced testcase is compiled correctly in that the deallocate is called
unconditional with zero argument:
  bit_vector() : m_num_bits(0), m_capacity(0), m_data(0) {
memory::deallocate(m_data);
  }

m_data will be NULL always when deallocate is called.

[Bug libstdc++/66030] [5.1.0] std::codecvt_byname missing from libstdc++ DLL

[sailer at sailer dot dynip.lugs.ch]

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

--- Comment #1 from Thomas Sailer  ---
Created attachment 35471
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35471&action=edit
preprocessed testcase

[Bug libstdc++/66030] New: [5.1.0] std::codecvt_byname missing from libstdc++ DLL

[sailer at sailer dot dynip.lugs.ch]

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

Bug ID: 66030
   Summary: [5.1.0] std::codecvt_byname missing from libstdc++ DLL
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sailer at sailer dot dynip.lugs.ch
  Target Milestone: ---

Created attachment 35470
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35470&action=edit
testcase

Compiling the attached simple test case fails linking for mingw32, because
libstdc++ DLL misses codecvt_byname symbols. This test case works with mingw32
gcc 4.9.2.

$ i686-w64-mingw32-g++ -o x.exe x.c 
/tmp/ccIXAXf0.o:x.c:(.text+0x74): undefined reference to
`std::codecvt_byname::codecvt_byname(char const*, unsigned
int)'
collect2: error: ld returned 1 exit status


$ i686-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-w64-mingw32/5.1.0/lto-wrapper
Target: i686-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --disable-plugin --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-languages=c,c++,objc,obj-c++,fortran
--with-bugurl=http://bugzilla.redhat.com/bugzilla --with-cloog
--enable-threads=posix --enable-libgomp --target=i686-w64-mingw32
--with-sysroot=/usr/i686-w64-mingw32/sys-root
--with-gxx-include-dir=/usr/i686-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
gcc version 5.1.0 20150422 (Fedora MinGW 5.1.0-1.fc23) (GCC)

[Bug lto/66027] lto1: internal compiler error: in odr_types_equivalent_p

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-05
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This is not enough information as we need to be able to reproduce it.  Can you
provide the preprocessed source for each of the objects and each of the
libraries? Or better yet reduce how the number of object files you need to
reproduce the failure.

[Bug lto/66029] Build error compiling gcc5.1 using LTO

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Also what version of binutils is on the system?  Can you try using latest
release from FSF rather than SUSE one?

[Bug lto/66029] Build error compiling gcc5.1 using LTO

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-05-05
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
(In reply to JD from comment #0)
> Created attachment 35469 [details]
> complete command line
> 
> I compiled gcc5.1 without LTO optimizations and tried to compile it again
> with LTO using the new 5.1 compiler.
> 
> 
> "openSUSE 13.2 (Harlequin) (x86_64)"
> 
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=gcc5.1/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
> Target: x86_64-unknown-linux-gnu
> Configured with: ../gcc-5.1.0/configure --prefix=gcc5.1
> --enable-languages=c,c++ --enable-gold=yes --enable-ld=yes --enable-lto
> --enable-bootstrap --disable-multilib
> Thread model: posix
> gcc version 5.1.0 (GCC)

Please configure GCC with --with-build-config=bootstrap-lto for LTO build.
BTW, which linker are you using?

[Bug fortran/59678] [F03] Segfault on equalizing variables of a complex derived type

[talebi.hossein at gmail dot com]

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

--- Comment #19 from Hossein Talebi  ---
Hi,

This patch goes to Gfortran 4.8 or the current version? Thank you.

Cheers
H.

On Tue, May 5, 2015 at 7:03 PM, vehre at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59678
>
> vehre at gcc dot gnu.org changed:
>
>What|Removed |Added
>
> 
>  Status|WAITING |RESOLVED
>  Resolution|--- |FIXED
>
> --- Comment #18 from vehre at gcc dot gnu.org ---
> Resolved with commit r222477. No objections so far, closing.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You reported the bug.
>

[Bug target/65916] Unnecessary floating-point instruction causes runtime exception on PowerPC

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #1 from Segher Boessenkool  ---
GCC 5 does not do this for me.

You need to add -msoft-float if you have no hardware float; doing
that solves the problem for me (with a GCC 4.7 I had handy).  Does
that work for you?

[Bug lto/66029] Build error compiling gcc5.1 using LTO

[t at sharklasers dot com]

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

--- Comment #1 from JD  ---
I compiled with used:
-O3 -flto -fuse-linker-plugin -fno-fat-lto-objects

and tried to link with:
-flto=4 -O3 -fuse-linker-plugin

[Bug lto/66029] New: Build error compiling gcc5.1 using LTO

[t at sharklasers dot com]

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

Bug ID: 66029
   Summary: Build error compiling gcc5.1 using LTO
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t at sharklasers dot com
  Target Milestone: ---

Created attachment 35469
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35469&action=edit
complete command line

I compiled gcc5.1 without LTO optimizations and tried to compile it again with
LTO using the new 5.1 compiler.


"openSUSE 13.2 (Harlequin) (x86_64)"

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=gcc5.1/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=gcc5.1
--enable-languages=c,c++ --enable-gold=yes --enable-ld=yes --enable-lto
--enable-bootstrap --disable-multilib
Thread model: posix
gcc version 5.1.0 (GCC)


/usr/bin/ld: error in /tmp/cc4PfHUo.ltrans1.ltrans.o(.eh_frame); no
.eh_frame_hdr table will be created.
`_Unwind_Resume' referenced in section `.text' of
/tmp/cc4PfHUo.ltrans1.ltrans.o: defined in discarded section `.text' of
unwind-dw2.o (symbol from plugin)
`_Unwind_Resume' referenced in section `.text' of
/tmp/cc4PfHUo.ltrans3.ltrans.o: defined in discarded section `.text' of
unwind-dw2.o (symbol from plugin)
`_Unwind_Resume' referenced in section `.text' of
/tmp/cc4PfHUo.ltrans3.ltrans.o: defined in discarded section `.text' of
unwind-dw2.o (symbol from plugin)
`_Unwind_Resume' referenced in section `.text.unlikely' of
/tmp/cc4PfHUo.ltrans8.ltrans.o: defined in discarded section `.text' of
unwind-dw2.o (symbol from plugin)
collect2: error: ld returned 1 exit status
Makefile:2606: recipe for target 'build/genmatch' failed

[Bug target/66020] [6.0 regression] FAIL: gcc.target/powerpc/ppc64-abi-2.c execution test

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org

--- Comment #1 from Andreas Schwab  ---
e95d0248daced44bf127beded55b18633fa8b5b1 is the first bad commit
commit e95d0248daced44bf127beded55b18633fa8b5b1
Author: amodra 
Date:   Thu Apr 23 05:36:55 2015 +

* config/rs6000/rs6000.c (rs6000_output_function_prologue): No
need for -mprofile-kernel to save LR to stack.



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

:04 04 a9b41bf1f26ec2f4b351c5c4f43fc6c65c2d74c3
e1bde8f53a887465d50436003502d0723e4451c2 M  gcc

[Bug libstdc++/66018] opendir configure test not working when GCC_NO_EXECUTABLES

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/66028] New: false positive, unused loop variable

[ncm at cantrip dot org]

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

Bug ID: 66028
   Summary: false positive, unused loop variable
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ncm at cantrip dot org
  Target Milestone: ---

struct range {
int start; int stop;
struct iter {
int i;
bool operator!=(iter other) { return other.i != i; };
iter& operator++() { ++i; return *this; };
int operator*() { return i; }
};
iter begin() { return iter{start}; }
iter end() { return iter{stop}; }
};
int main()
{
   int power = 1;
   for (int i : range{0,10})
   power *= 10;
}
bug.cc: In function ‘int main()’:
bug.cc:15:13: warning: unused variable ‘i’ [-Wunused-variable]
for (int i : range{0,10})

Manifestly, i is used to count loop iterations.  The warning cannot be
suppressed by any decoration of the declaration; the best we can do is

  void(i), power *= 10;

in the loop body.  The warning is useful in most cases.  The exception might be
that, here, the iterator has no reference or pointer members, and the loop body
changes external state.

[This matches clang bug https://llvm.org/bugs/show_bug.cgi?id=23416)

[Bug lto/66027] New: lto1: internal compiler error: in odr_types_equivalent_p

[t at sharklasers dot com]

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

Bug ID: 66027
   Summary: lto1: internal compiler error: in
odr_types_equivalent_p
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: t at sharklasers dot com
  Target Milestone: ---

Created attachment 35468
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35468&action=edit
complete commandline used to link

"openSUSE 13.2 (Harlequin) (x86_64)"

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=gcc5.1/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=gcc5.1
--enable-languages=c,c++ --enable-gold=yes --enable-ld=yes --enable-lto
--enable-bootstrap --disable-multilib
Thread model: posix
gcc version 5.1.0 (GCC)

llvm[4]: Linking Release+Asserts Shared Library libclang.so
  constant 64>
unit size  constant 8>
align 8 symtab 0 alias set 0 canonical type 0x7f717e5c92a0
pointer_to_this  reference_to_this
>
lto1: internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1543
0x807397 odr_types_equivalent_p
../../gcc-5.1.0/gcc/ipa-devirt.c:1543
0x8076ad odr_types_equivalent_p
../../gcc-5.1.0/gcc/ipa-devirt.c:1440
0x804ca1 add_type_duplicate
../../gcc-5.1.0/gcc/ipa-devirt.c:1770
0x804ca1 get_odr_type(tree_node*, bool)
../../gcc-5.1.0/gcc/ipa-devirt.c:1959
0x80642c register_odr_type(tree_node*)
../../gcc-5.1.0/gcc/ipa-devirt.c:2034
0x63876d lto_read_decls
../../gcc-5.1.0/gcc/lto/lto.c:1952
0x6394ae lto_file_finalize
../../gcc-5.1.0/gcc/lto/lto.c:2249
0x6394ae lto_create_files_from_ids
../../gcc-5.1.0/gcc/lto/lto.c:2259
0x6394ae lto_file_read
../../gcc-5.1.0/gcc/lto/lto.c:2300
0x6394ae read_cgraph_and_symbols
../../gcc-5.1.0/gcc/lto/lto.c:3005
0x6394ae lto_main()
../../gcc-5.1.0/gcc/lto/lto.c:3475

[Bug target/64835] -fno-ipa-cp is inconsitently supported when attributes optimize or target are used

[sch...@linux-m68k.org]

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

--- Comment #8 from Andreas Schwab  ---
Also fails on powerpc{-m32,-m64}.

[Bug c++/66026] New: C++14] throw-expression is not a valid constant-expression

[rhalbersma at gmail dot com]

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

Bug ID: 66026
   Summary: C++14] throw-expression is not a valid
constant-expression
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rhalbersma at gmail dot com
  Target Milestone: ---

g++ 5.1.0 and current trunk 20150505 won't compile the following code with
-std=c++1y:

constexpr auto fun(int n)
{
switch(n) {
case 0: return 0;
default: return throw 42, 42;  
}
}

int main()
{
static_assert(fun(0) == 0, "");
}

yielding the error: expression '' is not a
constant-expression

The same code compiles with -std=c++14 with all recent Clang versions (3.4.0
through SVN trunk).

[Bug target/66025] New: Implement ThreadSanitizer support for IBM z Systems

[krebbel at gcc dot gnu.org]

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

Bug ID: 66025
   Summary: Implement ThreadSanitizer support for IBM z Systems
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Enable the ThreadSanitizer in GCC for IBM z Systems.  The goal is to pass the
ThreadSanitizer testsuite on a z machine.

[Bug target/66025] Implement ThreadSanitizer support for IBM z Systems

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/66024] Implement AddressSanitizer support for IBM z Systems

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/66024] New: Implement AddressSanitizer support for IBM z Systems

[krebbel at gcc dot gnu.org]

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

Bug ID: 66024
   Summary: Implement AddressSanitizer support for IBM z Systems
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Enable the AddressSanitizer in GCC for IBM z Systems.  The goal is to pass the
AddressSanitizer testsuite on a z machine.

[Bug target/66023] Investigate and fix IBM z Systems `guality' testsuite failures

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/66023] New: Investigate and fix IBM z Systems `guality' testsuite failures

[krebbel at gcc dot gnu.org]

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

Bug ID: 66023
   Summary: Investigate and fix IBM z Systems `guality' testsuite
failures
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Running the GCC guality testsuite on z currently shows many
fails. These fails need to be investigated, classified, and fixed.

The goal is to fix as many as possible guality testsuite fails on
-march level z196 with GDB 7.9.  For all remaining fails a detailled
description of the problem is required which either points out why
this is a fundamental problem in GCC or why the problem does not lie
within the scope of GCC.

[Bug middle-end/66021] GCC miscompiles Z3

[nunoplopes at sapo dot pt]

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

--- Comment #3 from Nuno Lopes  ---
Created attachment 35467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35467&action=edit
reduced test case

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[vehre at gcc dot gnu.org]

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

--- Comment #14 from vehre at gcc dot gnu.org ---
That solely depends on the availability of reviews. At the moment getting a
review is quite difficult.

Btw, when you can use docker, then there is docker image available at:

https://registry.hub.docker.com/u/cmbant/docker-gcc-build/

But this also needs to compile first. Check the "Build Details" tab, whether it
succeeded. I do not maintain this docker file, just for info.

[Bug go/66016] Accessing nil Func's name results in crash

[ian at gcc dot gnu.org]

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

--- Comment #5 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue May  5 17:46:31 2015
New Revision: 222820

URL: https://gcc.gnu.org/viewcvs?rev=222820&root=gcc&view=rev
Log:
PR go/66016
runtime: Don't crash in Func.Name if the Func is nil.

Related to Go issue 10696

Modified:
branches/gcc-5-branch/libgo/runtime/go-caller.c

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[juergen.reuter at desy dot de]

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

--- Comment #13 from Jürgen Reuter  ---
I will give it a try as soon as possible. Any idea how long propagation into
the trunk might last?

[Bug bootstrap/66022] New: 4.8.4 build fails with stage 2 and 3 comparison error

[jrm at exa dot com]

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

Bug ID: 66022
   Summary: 4.8.4 build fails with stage 2 and 3 comparison error
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrm at exa dot com
  Target Milestone: ---

Created attachment 35466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35466&action=edit
Shell script used to extract tar ball, obtain pre-reqs, configure and run gcc
build

Attempting as non-clever a build of 4.8.4 as possible.  Same behavior with
binutils 2.19.1 or 2.25.   Prerequisites obtained w/"download_prerequisites"
script (MPFR 2.4.2, GMP 4.3.2 and MPC 0.8.1).   Ordinary linux machine:

plasma:/opt/SRC-gcc-4.8.4/gcc-4.8.4% cat /etc/issue
CentOS release 5.9 (Final)
Kernel \r on an \m

plasma:/opt/SRC-gcc-4.8.4/gcc-4.8.4% uname -a
Linux plasma 2.6.18-348.12.1.el5 #1 SMP Wed Jul 10 05:28:41 EDT 2013 x86_64
x86_64 x86_64 GNU/Linux


Last bits of the build log showing failure:

gmake[3]: Entering directory `/opt/BUILD-gcc-4.8.4'
rm -f stage_current
gmake[3]: Leaving directory `/opt/BUILD-gcc-4.8.4'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/coverage.o differs
gcc/asan.o differs
gcc/sel-sched-ir.o differs
gcc/passes.o differs
gcc/sel-sched.o differs
gcc/value-prof.o differs
gcc/cfg.o differs
gcc/dse.o differs
gcc/tree-ssa-pre.o differs
gcc/haifa-sched.o differs
gcc/sched-deps.o differs
gcc/tree-ssa-tail-merge.o differs
gcc/cp/class.o differs
gcc/cp/semantics.o differs
gcc/alloc-pool.o differs
gcc/tree-ssa-threadupdate.o differs
gmake[2]: *** [compare] Error 1
gmake[2]: Leaving directory `/opt/BUILD-gcc-4.8.4'

[Bug middle-end/66021] GCC miscompiles Z3

[nunoplopes at sapo dot pt]

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

--- Comment #2 from Nuno Lopes  ---
Created attachment 35465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35465&action=edit
test case

[Bug lto/65995] LTO: ICE in add_symbol_to_partition_1 for debug build

[daniel.f.starke at freenet dot de]

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

--- Comment #3 from Daniel Starke  ---
I have yet to bootstrap the current trunk (r222810). It currently fails with
/usr/new-gcc/bin32/./prev-gcc/xg++ -B/usr/new-gcc/bin32/./prev-gcc/
-B/mingw/mingw32/bin/ -nostdinc++
-B/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/src/.libs
-B/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/libsupc++/.libs 
-I/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/mingw32 
-I/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/include 
-I/usr/new-gcc/src/gcc-trunk/libstdc++-v3/libsupc++
-L/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/src/.libs
-L/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/libsupc++/.libs -c   -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -gtoggle -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../src/gcc-trunk/gcc
-I../../src/gcc-trunk/gcc/build -I../../src/gcc-trunk/gcc/../include 
-I../../src/gcc-trunk/gcc/../libcpp/include -DPTW32_STATIC_LIB \
-o build/genmddeps.o ../../src/gcc-trunk/gcc/genmddeps.c
In file included from ../../src/gcc-trunk/gcc/genmddeps.c:19:0:
../../src/gcc-trunk/gcc/system.h:1024:0: error: "CONST_CAST2" redefined
[-Werror]
 #define CONST_CAST2(TOTYPE,FROMTYPE,X) (const_cast (X))
 ^
In file included from
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/mingw32/bits/gthr.h:148:0,
 from
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/ext/atomicity.h:35,
 from
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/bits/basic_string.h:39,
 from
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/string:52,
 from ../../src/gcc-trunk/gcc/system.h:201,
 from ../../src/gcc-trunk/gcc/genmddeps.c:19:
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/mingw32/bits/gthr-default.h:33:0:
note: this is the location of the previous definition
 #define CONST_CAST2(TOTYPE,FROMTYPE,X) ((__extension__(union {FROMTYPE _q;
TOTYPE _nq;})(X))._nq)
 ^
cc1plus.exe: all warnings being treated as errors

I will try to compile the trunk without bootstrap.

[Bug middle-end/66021] GCC miscompiles Z3

[nunoplopes at sapo dot pt]

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

--- Comment #1 from Nuno Lopes  ---
Sorry, a bit more information the problem:

On function void
reduce_args_tactic::imp::populate_decl2args_proc::operator()(app * n), when
compiled with -O0 no call to memory::deallocate(void* p) is made, while with
-O2 memory::deallocate is called with p == 0, which cannot happen (since it's
called through dealloc_svect, which bails out if the pointer is null).

Apologies for not being able to reduce the test case; I don't have much
experience with the gcc internals.

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #35407|0   |1
is obsolete||

--- Comment #12 from vehre at gcc dot gnu.org ---
Created attachment 35464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35464&action=edit
Follow-up patch fixing latest regression.

With this patch all code samples and the code in the tar-archive compile and
execute well. This patch will need most of my previous patches. The total set
of all of my patches is available on the gitmirror in the branch
vehre/head_cosmo

[Bug middle-end/66021] New: GCC miscompiles Z3

[nunoplopes at sapo dot pt]

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

Bug ID: 66021
   Summary: GCC miscompiles Z3
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nunoplopes at sapo dot pt
  Target Milestone: ---

GCC 4.92 miscompiles Z3. I've tried Cygwin and Linux, 32 and 64 bits, and all
miscompile.

[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.3

[Bug target/66020] New: [6.0 regression] FAIL: gcc.target/powerpc/ppc64-abi-2.c execution test

[sch...@linux-m68k.org]

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

Bug ID: 66020
   Summary: [6.0 regression] FAIL:
gcc.target/powerpc/ppc64-abi-2.c execution test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: powerpc64-*-*

$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.target/powerpc/ppc64-abi-2.c -O2
-fprofile -mprofile-kernel -maltivec -mabi=altivec -lm -m64 -o
./ppc64-abi-2.exe
$ ./ppc64-abi-2.exe
Segmentation fault
(gdb) bt
#0  0x in ?? ()
#1  0x3fffb7d24dcc in generic_start_main (
main=@0x10012190: 0x15d0 , argc=, 
argv=0x3fffef48, auxvec=0x3220, init=, 
rtld_fini=, stack_end=, fini=)
at ../csu/libc-start.c:269
#2  0x3fffb7d24fd4 in __libc_start_main (argc=, 
argv=, ev=, auxvec=, 
rtld_fini=, stinfo=, 
stack_on_entry=)
at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:80
#3  0x in ?? ()


Breakpoint 3, fcvi (s=0x100011e0 "vv", v=..., i=2)
at ../gcc/testsuite/gcc.target/powerpc/ppc64-abi-2.c:138
138   reg_parms_t lparms = gparms;
(gdb) disass
Dump of assembler code for function fcvi:
   0x1900 <+0>: mflrr0
   0x1904 <+4>: bl  0x1820 
   0x1908 <+8>: mflrr0
=> 0x190c <+12>:nop
   0x1910 <+16>:li  r8,176
   0x1914 <+20>:ld  r10,-32744(r2)
   0x1918 <+24>:std r0,16(r1)
   0x191c <+28>:stdur1,-112(r1)
   0x1920 <+32>:ld  r9,0(r10)
   0x1924 <+36>:ld  r6,32(r10)
   0x1928 <+40>:cmpdcr7,r3,r9
   0x192c <+44>:lvx v0,r10,r8
   0x1930 <+48>:bne-cr7,0x1954 
   0x1934 <+52>:vcmpequw. v2,v2,v0
   0x1938 <+56>:bge-cr6,0x1954 
   0x193c <+60>:cmpdcr7,r7,r6
   0x1940 <+64>:bne-cr7,0x1954 
   0x1944 <+68>:addir1,r1,112
   0x1948 <+72>:ld  r0,16(r1)
   0x194c <+76>:mtlrr0
   0x1950 <+80>:blr
   0x1954 <+84>:bl  0x15bc
<0044.plt_call.abort@@GLIBC_2.3>
   0x1958 <+88>:ld  r2,40(r1)
   0x195c <+92>:.long 0x0
   0x1960 <+96>:.long 0x1
   0x1964 <+100>:   lwz r0,0(0)
End of assembler dump.
(gdb) i reg r0
r0 0x0  0

[Bug target/66020] [6.0 regression] FAIL: gcc.target/powerpc/ppc64-abi-2.c execution test

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/65915] [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #6 from Uroš Bizjak  ---
Fixed.

[Bug target/65915] [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Blocks|65983   |

--- Comment #5 from Uroš Bizjak  ---
*** Bug 65983 has been marked as a duplicate of this bug. ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65983
[Bug 65983] [6 Regression] ICE: SIGSEGV in mark_label_nuses (emit-rtl.c:3618)
with -fsanitize=thread -mavx512ifma -march=barcelona

[Bug target/65983] [6 Regression] ICE: SIGSEGV in mark_label_nuses (emit-rtl.c:3618) with -fsanitize=thread -mavx512ifma -march=barcelona

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Depends on|65915   |
 Resolution|--- |DUPLICATE

--- Comment #3 from Uroš Bizjak  ---
Confirmed dup of PR65915.

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65915
[Bug 65915] [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c
(internal compiler error)

[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue May  5 16:53:27 2015
New Revision: 222817

URL: https://gcc.gnu.org/viewcvs?rev=222817&root=gcc&view=rev
Log:
PR target/65990
* config/i386/i386.c (ix86_parse_stringop_strategy_string): Error out
if rep_8byte stringop strategy was specified for 32-bit target.

testsuite/ChangeLog:

PR target/65990
* gcc.target/i386/pr65990.c: New test.


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

[Bug go/66016] Accessing nil Func's name results in crash

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Fixed.  Thanks for reporting it.

[Bug go/66016] Accessing nil Func's name results in crash

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue May  5 16:38:57 2015
New Revision: 222816

URL: https://gcc.gnu.org/viewcvs?rev=222816&root=gcc&view=rev
Log:
PR go/66016
runtime: Don't crash in Func.Name if the Func is nil.

Related to Go issue 10696

Modified:
trunk/libgo/runtime/go-caller.c

[Bug go/66016] Accessing nil Func's name results in crash

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue May  5 16:38:45 2015
New Revision: 222815

URL: https://gcc.gnu.org/viewcvs?rev=222815&root=gcc&view=rev
Log:
PR go/66016
runtime: Don't crash in Func.Name if the Func is nil.

Related to Go issue 10696

Modified:
branches/gcc-4_9-branch/libgo/runtime/go-caller.c

[Bug target/64304] AArch64 miscompilation with -mgeneral-regs-only

[fyang at gcc dot gnu.org]

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

--- Comment #8 from fyang at gcc dot gnu.org ---
Author: fyang
Date: Tue May  5 15:59:12 2015
New Revision: 222814

URL: https://gcc.gnu.org/viewcvs?rev=222814&root=gcc&view=rev
Log:
Backported from mainline
2015-01-19  Jiong Wang  
Andrew Pinski  

PR target/64304
* config/aarch64/aarch64.md (define_insn "*ashl3_insn"): Deleted.
(ashl3): Don't expand if operands[2] is not constant.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/aarch64/pr64304.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/aarch64/aarch64.md
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[thiago at kde dot org]

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

--- Comment #31 from Thiago Macieira  ---
(In reply to Jakub Jelinek from comment #29)
> You are missing the point of copy relocations.  Consider:
> int a = 1;
> extern int b, c;
> int foo (void)
> {
>   return a + b + c;
> }
> compiled with -fno-pic or -fpie.  a is known to be defined in the
> executable, but b and c are externals.  Without copy relocations you'd need
> to emit significantly slower code (extra .got reference or similar) for all
> the accesses to the externals, with copy relocations you can optimistically
> assume they will likely be defined in the executable (usual case for larger
> programs, at least for C shared libraries people avoid exporting variables
> from shared libraries if easily possible), and if not, the linker will
> create copy relocations.

That is true.

But if you place the same code in a library, then now all accesses must be
indirect, even for a. My assertion isn't about the usefulness of copy
relocations, it's that they are optimising for the wrong thing. The size and
complexity of libraries and plugins in desktop applications is orders of
magnitude above that of the application codebases.

> Only with whole program (LTO or similar) compilation, when you can talk to
> the linker, you could find out if the externals from some TU are defined
> within the executable or not.

Or if we tag them appropriately.

int a = 1;
extern int b;
__attribute__((dllimport)) extern int c;
int foo(void)
{
return a + b + c;
}

Now the compiler knows that a is in the local executable and it can assume that
b is too, but it  also knows that c isn't and must be accessed indirectly. This
did not require LTO.

Modern libraries already all have a macro preceding all the function and
variable declarations meant to be used by other DSOs, ever since Ulrich
Drepper's "dso-howto" manual. The macro tags are required so that we have a
proper __attribute__((visibility("default"))) when the library is compiled with
-fvisibility=hidden. Moreover, the same tag expands to __declspec(dllexport) or
__declspec(dllimport) on Windows if the library is cross-platform. So the
precedent is there and modern libraries are mostly ready to make use of the
feature.

[Bug target/64304] AArch64 miscompilation with -mgeneral-regs-only

[fyang at gcc dot gnu.org]

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

--- Comment #7 from fyang at gcc dot gnu.org ---
Author: fyang
Date: Tue May  5 15:50:18 2015
New Revision: 222812

URL: https://gcc.gnu.org/viewcvs?rev=222812&root=gcc&view=rev
Log:
Backported from mainline
2015-01-19  Jiong Wang  
Andrew Pinski  

PR target/64304
* config/aarch64/aarch64.md (define_insn "*ashl3_insn"): Deleted.
(ashl3): Don't expand if operands[2] is not constant.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/pr64304.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/aarch64/aarch64.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[thiago at kde dot org]

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

--- Comment #30 from Thiago Macieira  ---
(In reply to H.J. Lu from comment #28)
> (In reply to Thiago Macieira from comment #27)
> > (In reply to Jakub Jelinek from comment #26)
> > Can you guarantee that the linker won't generate copy relocs for -fPIC?
> 
> Yes.

Thanks. We'll start requiring -fPIC as of Qt 5.4.2 and we'll advise Linux
distributions to backport the patch if they also upgrade GCC from 4.9.

For reference: https://codereview.qt-project.org/111787

Please treat this bug report now as a feature suggestion.

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek  ---
(In reply to Thiago Macieira from comment #27)
> Still, if this were solved properly, relocations that resolved back into the
> executable itself would still be bound locally, even position-dependently if
> that's how the binary were built. I am asking that it stop doing copy
> relocations, which only applies to symbols the linker *did* detect came from
> elsewhere.

You are missing the point of copy relocations.  Consider:
int a = 1;
extern int b, c;
int foo (void)
{
  return a + b + c;
}
compiled with -fno-pic or -fpie.  a is known to be defined in the executable,
but b and c are externals.  Without copy relocations you'd need to emit
significantly slower code (extra .got reference or similar) for all the
accesses to the externals, with copy relocations you can optimistically assume
they will likely be defined in the executable (usual case for larger programs,
at least for C shared libraries people avoid exporting variables from shared
libraries if easily possible), and if not, the linker will create copy
relocations.

Only with whole program (LTO or similar) compilation, when you can talk to the
linker, you could find out if the externals from some TU are defined within the
executable or not.

[Bug target/65915] [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error)

[tocarip at gcc dot gnu.org]

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

--- Comment #4 from tocarip at gcc dot gnu.org ---
Author: tocarip
Date: Tue May  5 15:43:13 2015
New Revision: 222811

URL: https://gcc.gnu.org/viewcvs?rev=222811&root=gcc&view=rev
Log:
PR target/65915
* config/i386/i386.md (vector convert to float spltiter): Check for
xmm16+, when splitting scalar float conversion.
* config/i386/sse.md (sse2_cvtsi2sd): Support EVEX version.

testsuite/ChangeLog:

PR target/65915
* gcc.target/i386/pr65915.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr65915.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[hjl.tools at gmail dot com]

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

--- Comment #28 from H.J. Lu  ---
(In reply to Thiago Macieira from comment #27)
> (In reply to Jakub Jelinek from comment #26)
> > Plus, if KDE uses so small binaries, why don't just compile them with -fPIC
> > then?
> > You can then link them as normal executables or PIEs, depending on what you
> > prefer, and still it supposedly wouldn't use copy relocations, as all
> > references to externals would be through .got.
> 
> Can you guarantee that the linker won't generate copy relocs for -fPIC?

Yes.

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[thiago at kde dot org]

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

--- Comment #27 from Thiago Macieira  ---
(In reply to Jakub Jelinek from comment #26)
> Plus, if KDE uses so small binaries, why don't just compile them with -fPIC
> then?
> You can then link them as normal executables or PIEs, depending on what you
> prefer, and still it supposedly wouldn't use copy relocations, as all
> references to externals would be through .got.

Can you guarantee that the linker won't generate copy relocs for -fPIC?

Anyway, I know I am generalising from a sample of 1, but in my experience as a
desktop developer, the mass of library code is much bigger and more complex
than the application code. This is probably not true in large single-instance
applications -- for example, mysqld's text segment is of comparable size to the
total size of the libraries it uses.

Still, if this were solved properly, relocations that resolved back into the
executable itself would still be bound locally, even position-dependently if
that's how the binary were built. I am asking that it stop doing copy
relocations, which only applies to symbols the linker *did* detect came from
elsewhere.

I've also said I'll gladly tag each of those symbols with an __attribute__ so
that GCC also knows it comes from elsewhere and generate the proper indirect
load sequence via the GOT.

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

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

--- Comment #29 from Manuel López-Ibáñez  ---
(In reply to Tim Ruehsen from comment #28)
> I far as I can read, not a patch is missing. A review + commit is missing.
> How can you ask for more developers (=patches) when the work is ignored ?
> Don't get me wrong, I just try to understand how this should work.

I'm actually not asking for more patches. As you can see, many of those PRs
already have patches. People send patches all the time. Sometimes very large
ones, and many times they never get committed, because they do not ping them,
or they do not address the reviewers' comments, or simply they get bored and
move to something else. 

What we need is people that are "patient and motivated" to get their code
committed to the upstream repository.

Unfortunately, getting reviews is hard because there are few developers and
they are busy, and new developers often fail to insist because they feel their
work is being ignored or they do not have time to follow-up and do the changes
asked by the reviewers. It is a vicious circle that I do not know how to solve.

As a volunteer, I know a patch of mine may take weeks/months to get reviewed. I
simply keep pinging (see https://gcc.gnu.org/wiki/Community for tips on how to
do this effectively). If I have free time, I work on something else; if not,
well, then it doesn't matter that it did not get reviewed yet. I am not in a
hurry. I don't have a deadline or a boss to present results. It is better that
it gets fixed in a year or two than never. 

For example, it took many years to get something as simple as coloured output
for diagnostics, but it finally happened. This was not because the core GCC
devs had a meeting and said "Oh, Clang is kicking our ass with their colors,
let's make this a priority". No, it took one volunteer insisting during many
months, revisions of patches and compromises. It did not actually take a lot of
coding time in total, but it was a process spread across many months.

[Bug c++/65854] [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211591

[tom at honermann dot net]

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

Tom Honermann  changed:

   What|Removed |Added

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

--- Comment #3 from Tom Honermann  ---
Thank you!  I confirmed that this is corrected with r222769.  Changing status
to resolved/fixed.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[ktkachov at gcc dot gnu.org]

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

--- Comment #26 from ktkachov at gcc dot gnu.org ---
So, out of interest, what is needed to make this work properly with target
attributes?

What hooks do we need to implement?
Looking at
https://gcc.gnu.org/onlinedocs/gccint/Target-Attributes.html#Target-Attributes

I think it should be TARGET_OPTION_SAVE and TARGET_OPTION_RESTORE and also the
builtin initialisation hook should be changed, but I can't figure out how
TARGET_OPTION_{SAVE, RESTORE} are used (are they even relevant?)

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
Plus, if KDE uses so small binaries, why don't just compile them with -fPIC
then?
You can then link them as normal executables or PIEs, depending on what you
prefer, and still it supposedly wouldn't use copy relocations, as all
references to externals would be through .got.

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
(In reply to Thiago Macieira from comment #23)
> $ pmap `pidof qtcreator` | perl -ne '@_ = split / +/; if ($_[6] eq "r-xp" &&
> $_[7] !~ /\[/) { $_[1] =~ s/K//; $total += $_[1]; $bin = $_[1] unless $bin;
> } END { print "$bin $total\n"; }'
> 72 166164
> 
> That is, the size of the binary's text segment is 72k and the size of all
> the library's text segments is 162 MB (granted, this includes .rodata
> sections).
> 
> My assertion is that keeping copy relocations is optimising for 0.05% of the
> codebase.

You can't judge everything from these numbers, just because KDE for some reason
decides to use very small binaries.  Many programs have much larger binaries,
especially if they care about performance.

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[hjl.tools at gmail dot com]

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

--- Comment #24 from H.J. Lu  ---
(In reply to Thiago Macieira from comment #23)
> $ pmap `pidof qtcreator` | perl -ne '@_ = split / +/; if ($_[6] eq "r-xp" &&
> $_[7] !~ /\[/) { $_[1] =~ s/K//; $total += $_[1]; $bin = $_[1] unless $bin;
> } END { print "$bin $total\n"; }'
> 72 166164
> 
> That is, the size of the binary's text segment is 72k and the size of all
> the library's text segments is 162 MB (granted, this includes .rodata
> sections).
> 
> My assertion is that keeping copy relocations is optimising for 0.05% of the
> codebase.

Copy relocation is the part of the psABI.  What you did violates the psABI,
as it is incompatible with the normal executable.

> I am asking that we begin reversing that decision. We can do it by opt-in,
> like Qt 5 tried to do: some large libraries, when they do their next binary
> incompatible release, enable the feature, causing the applications to stop
> doing copy relocations. I'd also like ld to refuse to link if copy
> relocations are required and the symbol comes from a library that used
> -fvisibility=protected -fsymbolic -Wl,-Bsymbolic (isn't that what
> DF_SYMBOLIC is for?)

Link-time library != run-time library.  You can't enforce run-time behavior
at link-tome.

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[thiago at kde dot org]

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

--- Comment #23 from Thiago Macieira  ---
$ pmap `pidof qtcreator` | perl -ne '@_ = split / +/; if ($_[6] eq "r-xp" &&
$_[7] !~ /\[/) { $_[1] =~ s/K//; $total += $_[1]; $bin = $_[1] unless $bin; }
END { print "$bin $total\n"; }'
72 166164

That is, the size of the binary's text segment is 72k and the size of all the
library's text segments is 162 MB (granted, this includes .rodata sections).

My assertion is that keeping copy relocations is optimising for 0.05% of the
codebase.

I am asking that we begin reversing that decision. We can do it by opt-in, like
Qt 5 tried to do: some large libraries, when they do their next binary
incompatible release, enable the feature, causing the applications to stop
doing copy relocations. I'd also like ld to refuse to link if copy relocations
are required and the symbol comes from a library that used
-fvisibility=protected -fsymbolic -Wl,-Bsymbolic (isn't that what DF_SYMBOLIC
is for?)

[Bug target/64579] __TM_end __builtin_tend failed to return transactional state

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
Author: bergner
Date: Tue May  5 14:27:30 2015
New Revision: 222809

URL: https://gcc.gnu.org/viewcvs?rev=222809&root=gcc&view=rev
Log:
gcc/

Backport from mainline.
2015-04-27  Peter Bergner  

PR target/64579
* config/rs6000/htm.md: Remove all define_expands.
(UNSPECV_HTM_TABORTDC, UNSPECV_HTM_TABORTDCI, UNSPECV_HTM_TABORTWC,
UNSPECV_HTM_TABORTWCI): Remove.
(UNSPECV_HTM_TABORTXC, UNSPECV_HTM_TABORTXCI, UNSPECV_HTM_TTEST): New.
(tabort_internal, tbegin_internal, tcheck_internal, tend_internal,
trechkpt_internal, treclaim_internal, tsr_internal): Rename from
this...
(tabort, tbegin, tcheck, tend, trechkpt, treclaim, tsr): ...to this.
(tabortdc_internal, tabortdci_internal, tabortwc_internal,
tabortwci_internal): Remove define_insns.
(tabortc, tabortci): New define_insns.
(tabort): Use gpc_reg_operand.
(tcheck): Remove operand.
(htm_mfspr_, htm_mtspr_): Use GPR mode macro.
* config/rs6000/htmxlintrin.h (__TM_end): Use _HTM_TRANSACTIONAL as
expected value.
* config/rs6000/rs6000-builtin.def (BU_HTM_SPR0): Remove.
(BU_HTM_SPR1): Rename to BU_HTM_V1.  Remove use of RS6000_BTC_SPR.
(tabort, tabortdc, tabortdci, tabortwc, tabortwci, tbegin,
tcheck, tend, tendall, trechkpt, treclaim, tresume, tsuspend,
tsr, ttest): Pass in the RS6000_BTC_CR attribute.
(get_tfhar, set_tfhar, get_tfiar, set_tfiar, get_texasr, set_texasr,
get_texasru, set_texasru): Pass in the RS6000_BTC_SPR attribute.
(tcheck): Remove builtin argument.
* config/rs6000/rs6000.c (rs6000_htm_spr_icode): Use TARGET_POWERPC64
not TARGET_64BIT.
(htm_expand_builtin): Fix usage of expandedp.  Disallow usage of the
tabortdc and tabortdci builtins when not in 64-bit mode.
Modify code to handle the loss of the HTM define_expands.
Emit code to copy the CR register to TARGET.
(htm_init_builtins): Modify code to handle the loss of the HTM
define_expands.
* config/rs6000/rs6000.h (RS6000_BTC_32BIT): Delete.
(RS6000_BTC_64BIT): Likewise.
(RS6000_BTC_CR): New macro.
* doc/extend.texi: Update documentation for htm builtins.

gcc/testsuite/

Backport from mainline.
2015-04-27  Peter Bergner  

PR target/64579
* gcc.target/powerpc/htm-1.c: New test.
* gcc.target/powerpc/htm-builtin-1.c (__builtin_tabortdc): Only test
on 64-bit compiles.
(__builtin_tabortdci): Likewise.
(__builtin_tcheck): Remove operand.
* lib/target-supports.exp (check_htm_hw_available): New function.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/htm-1.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/rs6000/htm.md
branches/gcc-4_8-branch/gcc/config/rs6000/htmxlintrin.h
branches/gcc-4_8-branch/gcc/config/rs6000/rs6000-builtin.def
branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.h
branches/gcc-4_8-branch/gcc/doc/extend.texi
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/htm-builtin-1.c
branches/gcc-4_8-branch/gcc/testsuite/lib/target-supports.exp

[Bug target/64579] __TM_end __builtin_tend failed to return transactional state

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
Author: bergner
Date: Tue May  5 14:25:35 2015
New Revision: 222808

URL: https://gcc.gnu.org/viewcvs?rev=222808&root=gcc&view=rev
Log:
gcc/

Backport from mainline.
2015-04-27  Peter Bergner  

PR target/64579
* config/rs6000/htm.md: Remove all define_expands.
(UNSPECV_HTM_TABORTDC, UNSPECV_HTM_TABORTDCI, UNSPECV_HTM_TABORTWC,
UNSPECV_HTM_TABORTWCI): Remove.
(UNSPECV_HTM_TABORTXC, UNSPECV_HTM_TABORTXCI, UNSPECV_HTM_TTEST): New.
(tabort_internal, tbegin_internal, tcheck_internal, tend_internal,
trechkpt_internal, treclaim_internal, tsr_internal): Rename from
this...
(tabort, tbegin, tcheck, tend, trechkpt, treclaim, tsr): ...to this.
(tabortdc_internal, tabortdci_internal, tabortwc_internal,
tabortwci_internal): Remove define_insns.
(tabortc, tabortci): New define_insns.
(tabort): Use gpc_reg_operand.
(tcheck): Remove operand.
(htm_mfspr_, htm_mtspr_): Use GPR mode macro.
* config/rs6000/htmxlintrin.h (__TM_end): Use _HTM_TRANSACTIONAL as
expected value.
* config/rs6000/rs6000-builtin.def (BU_HTM_SPR0): Remove.
(BU_HTM_SPR1): Rename to BU_HTM_V1.  Remove use of RS6000_BTC_SPR.
(tabort, tabortdc, tabortdci, tabortwc, tabortwci, tbegin,
tcheck, tend, tendall, trechkpt, treclaim, tresume, tsuspend,
tsr, ttest): Pass in the RS6000_BTC_CR attribute.
(get_tfhar, set_tfhar, get_tfiar, set_tfiar, get_texasr, set_texasr,
get_texasru, set_texasru): Pass in the RS6000_BTC_SPR attribute.
(tcheck): Remove builtin argument.
* config/rs6000/rs6000.c (rs6000_htm_spr_icode): Use TARGET_POWERPC64
not TARGET_64BIT.
(htm_expand_builtin): Fix usage of expandedp.  Disallow usage of the
tabortdc and tabortdci builtins when not in 64-bit mode.
Modify code to handle the loss of the HTM define_expands.
Emit code to copy the CR register to TARGET.
(htm_init_builtins): Modify code to handle the loss of the HTM
define_expands.
* config/rs6000/rs6000.h (RS6000_BTC_32BIT): Delete.
(RS6000_BTC_64BIT): Likewise.
(RS6000_BTC_CR): New macro.
* doc/extend.texi: Update documentation for htm builtins.

gcc/testsuite/

Backport from mainline.
2015-04-27  Peter Bergner  

PR target/64579
* gcc.target/powerpc/htm-1.c: New test.
* gcc.target/powerpc/htm-builtin-1.c (__builtin_tabortdc): Only test
on 64-bit compiles.
(__builtin_tabortdci): Likewise.
(__builtin_tcheck): Remove operand.
* lib/target-supports.exp (check_htm_hw_available): New function.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/htm-1.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/rs6000/htm.md
branches/gcc-4_9-branch/gcc/config/rs6000/htmxlintrin.h
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000-builtin.def
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.h
branches/gcc-4_9-branch/gcc/doc/extend.texi
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/htm-builtin-1.c
branches/gcc-4_9-branch/gcc/testsuite/lib/target-supports.exp

[Bug c/16351] NULL dereference warnings

[tim.ruehsen at gmx dot de]

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

--- Comment #28 from Tim Ruehsen  ---
I far as I can read, not a patch is missing. A review + commit is missing.
How can you ask for more developers (=patches) when the work is ignored ?
Don't get me wrong, I just try to understand how this should work.

[Bug target/64579] __TM_end __builtin_tend failed to return transactional state

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
Author: bergner
Date: Tue May  5 14:22:33 2015
New Revision: 222807

URL: https://gcc.gnu.org/viewcvs?rev=222807&root=gcc&view=rev
Log:
gcc/

Backport from mainline.
2015-04-27  Peter Bergner  

PR target/64579
* config/rs6000/htm.md: Remove all define_expands.
(UNSPECV_HTM_TABORTDC, UNSPECV_HTM_TABORTDCI, UNSPECV_HTM_TABORTWC,
UNSPECV_HTM_TABORTWCI): Remove.
(UNSPECV_HTM_TABORTXC, UNSPECV_HTM_TABORTXCI, UNSPECV_HTM_TTEST): New.
(tabort_internal, tbegin_internal, tcheck_internal, tend_internal,
trechkpt_internal, treclaim_internal, tsr_internal): Rename from
this...
(tabort, tbegin, tcheck, tend, trechkpt, treclaim, tsr): ...to this.
(tabortdc_internal, tabortdci_internal, tabortwc_internal,
tabortwci_internal): Remove define_insns.
(tabortc, tabortci): New define_insns.
(tabort): Use gpc_reg_operand.
(tcheck): Remove operand.
(htm_mfspr_, htm_mtspr_): Use GPR mode macro.
* config/rs6000/htmxlintrin.h (__TM_end): Use _HTM_TRANSACTIONAL as
expected value.
* config/rs6000/rs6000-builtin.def (BU_HTM_SPR0): Remove.
(BU_HTM_SPR1): Rename to BU_HTM_V1.  Remove use of RS6000_BTC_SPR.
(tabort, tabortdc, tabortdci, tabortwc, tabortwci, tbegin,
tcheck, tend, tendall, trechkpt, treclaim, tresume, tsuspend,
tsr, ttest): Pass in the RS6000_BTC_CR attribute.
(get_tfhar, set_tfhar, get_tfiar, set_tfiar, get_texasr, set_texasr,
get_texasru, set_texasru): Pass in the RS6000_BTC_SPR attribute.
(tcheck): Remove builtin argument.
* config/rs6000/rs6000.c (rs6000_htm_spr_icode): Use TARGET_POWERPC64
not TARGET_64BIT.
(htm_expand_builtin): Fix usage of expandedp.  Disallow usage of the
tabortdc and tabortdci builtins when not in 64-bit mode.
Modify code to handle the loss of the HTM define_expands.
Emit code to copy the CR register to TARGET.
(htm_init_builtins): Modify code to handle the loss of the HTM
define_expands.
* config/rs6000/rs6000.h (RS6000_BTC_32BIT): Delete.
(RS6000_BTC_64BIT): Likewise.
(RS6000_BTC_CR): New macro.
* doc/extend.texi: Update documentation for htm builtins.

gcc/testsuite/

Backport from mainline.
2015-04-27  Peter Bergner  

PR target/64579
* gcc.target/powerpc/htm-1.c: New test.
* gcc.target/powerpc/htm-builtin-1.c (__builtin_tabortdc): Only test
on 64-bit compiles.
(__builtin_tabortdci): Likewise.
(__builtin_tcheck): Remove operand.
* lib/target-supports.exp (check_htm_hw_available): New function.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/htm-1.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/htm.md
branches/gcc-5-branch/gcc/config/rs6000/htmxlintrin.h
branches/gcc-5-branch/gcc/config/rs6000/rs6000-builtin.def
branches/gcc-5-branch/gcc/config/rs6000/rs6000.c
branches/gcc-5-branch/gcc/config/rs6000/rs6000.h
branches/gcc-5-branch/gcc/doc/extend.texi
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/htm-builtin-1.c
branches/gcc-5-branch/gcc/testsuite/lib/target-supports.exp

[Bug c/16351] NULL dereference warnings

[pmatos at gcc dot gnu.org]

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

--- Comment #27 from pmatos at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #26)
> A good place to start is
> https://gcc.gnu.org/bugzilla/buglist.
> cgi?keywords=easyhack&list_id=116934&order=bug_id&query_format=advanced
> 

Thanks for the input. I will take a look.

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

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

--- Comment #26 from Manuel López-Ibáñez  ---
(In reply to pmatos from comment #25)
> (In reply to Manuel López-Ibáñez from comment #24)
> > I can give you many examples of old "must-have" bugs that are "easy" to fix,
> > but simply there is no one with enough time and motivation to get them done.
> 
> It would be interesting to have that list. Or just those on the top of your
> head. I might not necessarily look at them now but I know I will have some
> time in the near future to work on a few of these, so it would be
> interesting to have this list so I can look at them.

A good place to start is
https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=easyhack&list_id=116934&order=bug_id&query_format=advanced

In particular, PR19808 should be fairly easy and there is some work already
done. It is also a prerequisite for PR2972. 

PR7652 has an initial patch.
PR23087 is very straightforward. 
PR17896 has a patch already.
PR99 is the oldest bug in my list and it is still a mystery. It needs proper
debugging to understand what goes wrong.

Of course, there are also quite a few very old bugs where the fix is not so
straight-forward but the impact would be very high: PR19430 (do the warning in
the FE?) and PR18501 (the most common Wuninitialized bug).

[Bug libstdc++/66011] [6 Regression] call to '__open_missing_mode' declared with attribute error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-05
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
I'll fix this ASAP. In the meanwhile, you can configure with
--disable-libstdcxx-filesystem-ts

[Bug c/16351] NULL dereference warnings

[pmatos at gcc dot gnu.org]

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

pmatos at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pmatos at gcc dot gnu.org

--- Comment #25 from pmatos at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #24)
> I can give you many examples of old "must-have" bugs that are "easy" to fix,
> but simply there is no one with enough time and motivation to get them done.

It would be interesting to have that list. Or just those on the top of your
head. I might not necessarily look at them now but I know I will have some time
in the near future to work on a few of these, so it would be interesting to
have this list so I can look at them.

Thanks.

[Bug target/65456] powerpc64le autovectorized copy loop missed optimization

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #24 from Bill Schmidt  ---
> No, I don't think so.  The same change was made in GCC 4.9, and it didn't 
> cause
> it to XPASS there (looking at gcc-testresults).  Also, my change restricted 
> the
> number of cases for which a test is expected to fail, rather than adding 
> cases,
> so if it XPASSes now, it should have XPASSed prior to the change.
>
> Have you bisected to see which revision corresponds to the regression?

Not yet: those sparc boxes are slow, and it will take ages.  I'll check
if I can reproduce in a cross compiler.

Rainer

[Bug target/66019] New: Corrupt libstdc++ on AIX 6.1

[joerg.rich...@pdv-fs.de]

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

Bug ID: 66019
   Summary: Corrupt libstdc++ on AIX 6.1
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg.rich...@pdv-fs.de
  Target Milestone: ---
  Host: powerpc-ibm-aix6.1.0.0
Target: powerpc-ibm-aix6.1.0.0
 Build: powerpc-ibm-aix6.1.0.0

I am building GCC 4.9.2 on AIX 6.1 with the same script I used for AIX 5.3.

$ configure --enable-languages=c,c++ --disable-bootstrap --disable-nls
--with-local-prefix=/not_existing_directory --enable-frame-pointer
--with-ld=/bin/ld --with-as=/bin/as --prefix=/tools/pkg/gcc/4.9.2

make && make install

During build of GCC are a lot of warnings like this:

ld: 0711-768 WARNING: Object
../src/c++98/.libs/libc++98convenience.a[locale-inst.o], section 1, function
.std::istreambuf_iterator >::_M_get() const:
The branch at address 0x15534 is not followed by a recognized no-op
or TOC-reload instruction. The unrecognized instruction is 0x8D3C0001.

There are 3728 ld 0711-768 warnings.  On AIX 5.3 there are no warnings using
the same script.

Nevertheless GCC builds without errors.

But when compiling and running application code that calles
std::istreambuf_iterator::_M_get() 
the process termines with SIGSEGV or SIGILL.

Here is a gdb/bt of a crashed process:

#0  0x090002edc554 in std::istreambuf_iterator
>::_M_get ()
   from libstdc++.a(libstdc++.so.6)
#1  0x090002e6dce4 in std::istreambuf_iterator
> std::num_get >
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator
>, std::ios_base&, std::_Ios_Iostate&, unsigned int&) const [clone
.localalias.77] () from libstdc++.a(libstdc++.so.6)
#2  0x090002e6db6c in std::num_get > >::do_get(std::istreambuf_iterator >, std::istreambuf_iterator
>, std::ios_base&, std::_Ios_Iostate&, unsigned int&) const [clone
.localalias.236] ()
   from libstdc++.a(libstdc++.so.6)
#3  0x090002e92658 in std::istream& std::istream::_M_extract(unsigned int&) [clone .localalias.69] ()
   from libstdc++.a(libstdc++.so.6)

Searching for ld: 0711-768 seem to indicate that this warnings should not be
ignored.

The error might be related to some missing GNU-tool.  The 6.1 machine is not
using the same 
GNU tools like the 5.3 maschine.  I know that GCC does not build with
AIX-sed/awk.  Might 
be that I missed another GNU tool that will fix this problem.  But I have no
idea what it can be.

[Bug libstdc++/66018] New: opendir configure test not working when GCC_NO_EXECUTABLES

[green at moxielogic dot com]

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

Bug ID: 66018
   Summary: opendir configure test not working when
GCC_NO_EXECUTABLES
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: green at moxielogic dot com
  Target Milestone: ---

I'm building a moxie-elf toolchain, which defines GCC_NO_EXECUTABLES during
part of the build process.

The new filesystem-ts code forces an opendir configure test that fails when
GCC_NO_EXECUTABLES is defined.

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

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

--- Comment #24 from Manuel López-Ibáñez  ---
(In reply to Tim Ruehsen from comment #23)

> The requested warning is an absolutely must-have (enabled by default).
> Seeing this bug open since 2004 is... well ... I have no words.

GCC needs lots of more developers. Not "experts" or "hackers", but simply
people with some patience and curiosity and basic knowledge about C/C++ and
compiling and debugging code in GNU/Linux. We need people that can focus on
things like this for a couple of hours every week for months and get it done
from start to finish.

Paid developers are paid to work on other things (targets, optimizations,
extensions) and rarely have the time and focus necessary to get projects like
this finished. Volunteers are few and we already have our hands very full with
our own little projects.

I can give you many examples of old "must-have" bugs that are "easy" to fix,
but simply there is no one with enough time and motivation to get them done.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

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

--- Comment #37 from Jürgen Reuter  ---
(In reply to vehre from comment #36)
> I am waiting for an official review of the patch, to be allowed to commit to
> trunk. So I am not waiting on you. :-)

I see. Got it. :D

[Bug lto/59000] lto can't merge user-defined weak builtin functions

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||matt at use dot net

--- Comment #4 from Markus Trippelsdorf  ---
*** Bug 52159 has been marked as a duplicate of this bug. ***

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Markus Trippelsdorf  ---
dup

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

[Bug libstdc++/66017] Undefined behaviour in std::set

[public at hansmi dot ch]

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

--- Comment #2 from M. Hanselmann  ---
This may be related to bug 63345.

[Bug libstdc++/66017] Undefined behaviour in std::set

[public at hansmi dot ch]

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

--- Comment #1 from M. Hanselmann  ---
Forgot to add that A. Bougacha has analyzed the issue. According to him it's a
cast (or casts) invoking undefined behaviour.

https://llvm.org/bugs/show_bug.cgi?id=23413#c2

[Bug libstdc++/66017] New: Undefined behaviour in std::set

[public at hansmi dot ch]

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

Bug ID: 66017
   Summary: Undefined behaviour in std::set
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: public at hansmi dot ch
  Target Milestone: ---

Created attachment 35463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35463&action=edit
Test program and output after building with Clang 3.6 (using GCC toolchain
5.1.0)

When building for Linux x86 (Debian 8 (Jessie), 32 bit) using `long long' as
std::set's value type causes UBSan as included in Clang 3.5 and 3.6 to report
an downcast/upcast of a misaligned address at runtime and ASan to report
undefined behaviour, all of them in _Rb_tree.

The simplest example I could find:

---
#include 

int main(int, char **)
{
  std::set foo {1LL};
}
---

std::set::begin, std::set::end, set::set::empty cause reports too.

This is not reproducible when compiling with GCC 5.1.0 (with the same options
sans those specific to Clang) and neither when building for x86-64 with either
compiler.

Reproduced using:

- Clang 3.5 w/ GCC toolchain 4.9
- Clang 3.6 w/ GCC toolchain 4.9
- Clang 3.6 w/ GCC toolchain 5.1.0

Shorter value types for std::set, e.g. `long' or `char', work. Packaging the
`long long' in another type, e.g. a struct, works too. The issue does not occur
with libc++.

Bug 60734 reported something similar, though there seem to be more issues. I'm
uncertain as to whether it's an issue in _Rb_tree, __aligned_buffer or another
place altogether.

Original report at LLVM/Clang: https://llvm.org/bugs/show_bug.cgi?id=23413

[Bug tree-optimization/46029] -ftree-loop-if-convert-stores causes FAIL: libstdc++-v3/testsuite/ext/pb_ds/example/tree_intervals.cc

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alalaw01 at gcc dot gnu.org

--- Comment #4 from alalaw01 at gcc dot gnu.org ---
I'm still seeing this problem with -ftree-loop-if-convert-stores, introducing
faults by converting conditional to unconditional loads. It doesn't look as if
Sebastian Pop's patches went in (after being approved,
https://gcc.gnu.org/ml/gcc-patches/2010-11/msg01670.html). Can anyone shed any
light on this?

[Bug middle-end/65947] Vectorizer misses conditional assignment of constant

[alalaw01 at gcc dot gnu.org]

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

--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Yeah, you're right, it's not commutative, but then, it doesn't need to be.

If f(x,y) is "(a[x] ? 7 : y)", then f(0, f(1, ...)) = f(1, f(0, ...))
(associative but not commutative), which is all we need to reorder the
iterations of the loop?

So if at the end of the loop we have a vector

v_tmp_result = { f(8, f(4, f(0, ))), f(9, f(5, f(1, ))), f(10, f(6,
f(2, ))), f(11, f(7, f(3, ))) }

obtained by standard technique for reductions, we then need to reduce the
vector to a scalar, which could be

(a) if any of the vector elements are equal to the constant 7, then return the
constant 7, else the initial value:

cond_expr (vec_reduc_or (vec_equals (v_tmp_result, 7)), 7, )

indeed you might just vectorize to get the predicates

v_tmp2 = { a[8] | a[4] | a[0], a[9] | a[5] | a[1], a[10] | a[6] | a[2], a[11] |
a[7] | a[3] }

and then reduce to scalar with cond_expr (vec_reduc_or (v_tmp2), 7, 3)

(b) alternatively one could exploit the initial value (3) also being a constant
and choose an appropriate operator from {max, min, or, and}, e.g. for 3 and 7
either reduc_max_expr(3,7) or reduc_or_expr(3,7) would work.

[Bug target/65955] [arm] ICE during movcond_addsi split

[ktkachov at gcc dot gnu.org]

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---

> > I can't reproduce it on my cross build with
> > -mthumb/-march=armv7-a/-mfloat-abi=hard/-mfpu=vfpv3-d16 unfortunately
> 
> with checking=yes,rtl?

Ah yes, with --enable-checking=yes,rtl I can reproduce it, and confirm that it
goes away with the patch.
I have posted the patch at
 https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00284.html

Thanks for investigating!

[Bug c++/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #8 from Yuri Gribov  ---
> So, I wonder, if it's a testcase problem and
> it should be disabled for CA8?

Perhaps add CA8 check in check_effective_target_arm_vect_no_misalign in
gcc/testsuite/lib/target-supports.exp?

[Bug go/66016] Accessing nil Func's name results in crash

[jcajka at redhat dot com]

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

--- Comment #1 from Jakub Čajka  ---
Golang upstream ticket:

https://github.com/golang/go/issues/10696