[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 19 07:56:36 2016
New Revision: 233545

URL: https://gcc.gnu.org/viewcvs?rev=233545&root=gcc&view=rev
Log:
PR target/69671
* config/i386/sse.md (*floatv2div2sf2_mask_1,
*avx512vl_v2div2qi2_mask_1, *avx512vl_v4qi2_mask_1,
*avx512vl_v8qi2_mask_1, *avx512vl_v4hi2_mask_1,
*avx512vl_v2div2hi2_mask_1, *avx512vl_v2div2si2_mask_1,
*avx512f_v8div16qi2_mask_1): New insns.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md

[Bug c++/69865] -trigraphs option broken

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger  ---
also the -fno-extended-identifiers option is broken:

cat test1.cc
// \u00e4 = ä, \u00f6 = ö, \u00fc = ü, \u00df = ß
int test\u00e4\u00f6\u00fc\u00df ()
{
  return 0;
}

gcc -fno-extended-identifiers -c test1.cc
compiles OK (which is actually wrong)

gcc -std=gnu++14 -fno-extended-identifiers -c test1.cc
test1.cc:2:9: error: stray '\' in program
 int test\u00e4\u00f6\u00fc\u00df ()
 ^
test1.cc:2:15: error: stray '\' in program
 int test\u00e4\u00f6\u00fc\u00df ()
   ^
test1.cc:2:21: error: stray '\' in program
 int test\u00e4\u00f6\u00fc\u00df ()
 ^
test1.cc:2:27: error: stray '\' in program
 int test\u00e4\u00f6\u00fc\u00df ()
   ^
test1.cc:2:10: error: expected initializer before 'u00e4'
 int test\u00e4\u00f6\u00fc\u00df ()
  ^

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenther at suse dot de]

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

--- Comment #58 from rguenther at suse dot de  ---
On February 19, 2016 6:48:38 AM GMT+01:00, "tkoenig at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
>
>--- Comment #57 from Thomas Koenig  ---
>(In reply to Dominique d'Humieres from comment #56)
>> > >   FUNCTION FOO(I, J)
>> > >   COMMON /BLK/ K(1)
>> > >   FOO = K(I) + K(J) + K(2*I) + K(2*J)
>> > >   END FUNCTION
>> 
>> This piece of code is also invalid (out of bound access to K): K(I) +
>K(J)
>> is valid iff I=J=1, but K(2*I) + K(2*J) is always accessing elements
>outside
>> the array K(1).
>> 
>> > The correct solution to me is to detect the unequal sizes and
>convert
>> > the COMMON /BLK/ K(1) to the larger size, ie K(64).
>> 
>> This can be done at link time only if the two TU are in different
>files.
>
>There are two kinds of people to consider here.
>
>One is sPEC.  I think they are wrong in their policy, but I doubt we
>are
>going to change it.
>
>The other are normal users, who have an existing code base relying
>on such behavior.  What can we do for them?
>
>I think it would be appropriate to warn (with -Wall) if code
>
>- uses this idiom (one-element array as trailing common block member)
>
>- uses a non-constant expression to access an element
>
>while telling the user how to get around this issue.
>
>If we can prove that the access is out of bounds, then we
>could also issue an error.
>
>This appears to be a frequent idiom in old-style Fortran, which is
>not always easy to fix in legacy code.  We would do a large part
>of our user base a disservice if there was no way to get around this.

We already warn about mismatches sizes at LTO link time

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[tkoenig at gcc dot gnu.org]

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

--- Comment #57 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #56)
> > >   FUNCTION FOO(I, J)
> > >   COMMON /BLK/ K(1)
> > >   FOO = K(I) + K(J) + K(2*I) + K(2*J)
> > >   END FUNCTION
> 
> This piece of code is also invalid (out of bound access to K): K(I) + K(J)
> is valid iff I=J=1, but K(2*I) + K(2*J) is always accessing elements outside
> the array K(1).
> 
> > The correct solution to me is to detect the unequal sizes and convert
> > the COMMON /BLK/ K(1) to the larger size, ie K(64).
> 
> This can be done at link time only if the two TU are in different files.

There are two kinds of people to consider here.

One is sPEC.  I think they are wrong in their policy, but I doubt we are
going to change it.

The other are normal users, who have an existing code base relying
on such behavior.  What can we do for them?

I think it would be appropriate to warn (with -Wall) if code

- uses this idiom (one-element array as trailing common block member)

- uses a non-constant expression to access an element

while telling the user how to get around this issue.

If we can prove that the access is out of bounds, then we
could also issue an error.

This appears to be a frequent idiom in old-style Fortran, which is
not always easy to fix in legacy code.  We would do a large part
of our user base a disservice if there was no way to get around this.

[Bug fortran/69870] New: ICE while detecting undeclared parameter

[jwmwalrus at gmail dot com]

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

Bug ID: 69870
   Summary: ICE while detecting undeclared parameter
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwmwalrus at gmail dot com
  Target Milestone: ---

Hi.  

The (invalid) code below throws an ICE with both gfortran 5 and 6.

-
module somemod
implicit none
contains
subroutine output()
character(STRING_TEXT) :: msg
end subroutine
end module somemod
-

With gfortran 5 I get:

~$ gfortran-5 -c somemod.f90 
somemod.f90:4:0:

 subroutine output()
 1
internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1084
0x683cc8 gfc_typenode_for_spec(gfc_typespec*)
../../src/gcc/fortran/trans-types.c:1084
0x683cc8 gfc_sym_type(gfc_symbol*)
../../src/gcc/fortran/trans-types.c:2170
0xd4f548 gfc_get_symbol_decl(gfc_symbol*)
../../src/gcc/fortran/trans-decl.c:1511
0xd4e482 generate_local_decl
../../src/gcc/fortran/trans-decl.c:5055
0x64bce2 expr_decls
../../src/gcc/fortran/trans-decl.c:5003
0x5c4294 gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*,
gfc_symbol*, int*), int)
../../src/gcc/fortran/expr.c:4161
0x645a0b generate_expr_decls
../../src/gcc/fortran/trans-decl.c:5010
0x645a0b generate_dependency_declarations
../../src/gcc/fortran/trans-decl.c:5025
0x645a0b generate_local_decl
../../src/gcc/fortran/trans-decl.c:5052
0xd4405e do_traverse_symtree
../../src/gcc/fortran/symbol.c:3646
0xd4ce0b generate_local_vars
../../src/gcc/fortran/trans-decl.c:5245
0xd4ce0b gfc_generate_function_code(gfc_namespace*)
../../src/gcc/fortran/trans-decl.c:5781
0x62dd77 gfc_generate_module_code(gfc_namespace*)
../../src/gcc/fortran/trans.c:2072
0xd2afea translate_all_program_units
../../src/gcc/fortran/parse.c:5330
0xd2afea gfc_parse_file()
../../src/gcc/fortran/parse.c:5540
0x11e9fa5 gfc_be_parse_file
../../src/gcc/fortran/f95-lang.c:229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



With gfortran 6 I get:

~$ gfortran-6 -c somemod.f90 
somemod.f90:4:0:

 subroutine output()


internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.



Ironically, removing the "implicit none" line shows the actual issue ---since
STRING_TEXT becomes an implicitly REAL parameter/expression.

System and compiler information follows:

~$ lsb_release -rd && gfortran-5 -v && gfortran-6 -v
Description:Debian GNU/Linux testing-updates (sid)
Release:testing-updates
Using built-in specs.
COLLECT_GCC=gfortran-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-8'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160205 (Debian 5.3.1-8) 
Using built-in specs.
COLLECT_GCC=gfortran-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20160125-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --with-system-zlib --disable-bro

[Bug target/66337] __alignof__(s.d) incorrect for a double member with -malign-power

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Martin Sebor  ---
Thank you for the background.   I agree that the __alignof__ operator doesn't
seem to be returning the correct result in this case.  Based on the GCC manual,
I would expect __alignof__(member) to evaluate to the alignment of the member's
type, or 8 in this case, not 4.

After some debugging I believe the reduced alignment is due to the definition
of the ADJUST_FIELD_ALIGN macro in config/rs6000/linux64.h.  Testing shows even
though the double field alignment is set to 32 bits the overall layout of the
struct (e.g., adjacent fields and padding between them) respects the 64-bit
double alignment.  I don't know enough of the history to guess why it's done
this way but this is what I found in commit logs:

/* PowerPC64 Linux word-aligns FP doubles when -malign-power is given.  */
#undef  ADJUST_FIELD_ALIGN
#define ADJUST_FIELD_ALIGN(FIELD, COMPUTED) \
  (rs6000_special_adjust_field_align_p ((FIELD), (COMPUTED))\
   ? 128\
   : (TARGET_64BIT  \
  && TARGET_ALIGN_NATURAL == 0  \
  && TYPE_MODE (strip_array_types (TREE_TYPE (FIELD))) == DFmode)   \
   ? MIN ((COMPUTED), 32)   \
   : (COMPUTED))

The comment under it explains why the struct containing the double field is
doubleword aligned:

/* PowerPC64 Linux increases natural record alignment to doubleword if
   the first field is an FP double, only if in power alignment mode.  */

The ADJUST_FIELD_ALIGN macro was introduced into the rs6000 back end in r56135
with the following comment:

/* AIX word-aligns FP doubles but doubleword-aligns 64-bit ints.  */

[Bug c++/69736] [4.9/5/6 Regression] "error: too few arguments to function" in c++14 but not c++11

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #6 from Patrick Palka  ---
Seems to only happen when fn1 is not overloaded.  If it is overloaded then the
code is accepted in C++14:

void fn1(int, int);
void fn1(bool = true) { (fn1)(); }

[Bug rtl-optimization/57676] [4.9/5/6 Regression] ICE: Maximum number of LRA constraint passes is achieved (30)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org
   Assignee|vmakarov at redhat dot com |bernds at gcc dot 
gnu.org

--- Comment #11 from Bernd Schmidt  ---
We've discussed a few things and I'll submit a patch.

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[wilson at gcc dot gnu.org]

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

--- Comment #5 from Jim Wilson  ---
Created attachment 37737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37737&action=edit
Patch to add missing vcond_mask* patterns.

Tested with the subset of CPU2006 that currently works at -O3 on aarch64 and
arm.

[Bug testsuite/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[edlinger at gcc dot gnu.org]

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

--- Comment #12 from Bernd Edlinger  ---
Author: edlinger
Date: Thu Feb 18 22:27:09 2016
New Revision: 233538

URL: https://gcc.gnu.org/viewcvs?rev=233538&root=gcc&view=rev
Log:
PR testsuite/68580
* c-c++-common/tsan/pr65400-1.c (v, q, o): Make 8-byte aligned.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/tsan/pr65400-1.c

[Bug preprocessor/69869] New: internal compiler error: Segmentation fault in call to skip_macro_block_comment when using '-traditional-cpp'

[geir at cray dot com]

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

Bug ID: 69869
   Summary: internal compiler error: Segmentation fault in call to
skip_macro_block_comment when using '-traditional-cpp'
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geir at cray dot com
  Target Milestone: ---

The following test case fails in all versions of GCC I tried (4.7.3 through
5.3,0)


$ gcc --version
gcc (GCC) 5.3.0 20151204 (Cray Inc.)
Copyright (C) 2015 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.

$ cat test.c
#define Concat2(a,b)a/**/b

all:
$(RM)  Concat2(./bin/,*)
$ gcc -E -traditional-cpp test.c >/dev/null
test.c:1:0: internal compiler error: Segmentation fault
 #define Concat2(a,b)a/**/b
 ^
0xa1c58f crash_signal
../../cray-gcc-5.3.0/gcc/toplev.c:383
0x1002b30 skip_macro_block_comment
../../cray-gcc-5.3.0/libcpp/traditional.c:129
0x1002b30 copy_comment
../../cray-gcc-5.3.0/libcpp/traditional.c:161
0x100336e _cpp_scan_out_logical_line
../../cray-gcc-5.3.0/libcpp/traditional.c:489
0x1003fcb _cpp_read_logical_line_trad
../../cray-gcc-5.3.0/libcpp/traditional.c:310
0x6bbe77 scan_translation_unit_trad
../../cray-gcc-5.3.0/gcc/c-family/c-ppoutput.c:326
0x6bbe77 preprocess_file(cpp_reader*)
../../cray-gcc-5.3.0/gcc/c-family/c-ppoutput.c:108
0x6ba6f0 c_common_init()
../../cray-gcc-5.3.0/gcc/c-family/c-opts.c:1033
0x62e9cc lang_dependent_init
../../cray-gcc-5.3.0/gcc/toplev.c:1836
0x62e9cc do_compile
../../cray-gcc-5.3.0/gcc/toplev.c:2053
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$

[Bug c++/69865] -trigraphs option broken

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger  ---
Created attachment 37736
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37736&action=edit
possible patch

this tries to be compatible to previous gcc versions (option a).

always define __GNUC_GNU_INLINE__ and flag_gnu89_inline=1

[Bug c++/69865] -trigraphs option broken

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger  ---
when working on a patch I noticed that there is something more...

that is if the preprocessor macro __GNUC_GNU_INLINE__ or __GNUC_STDC_INLINE__
is defined on C++.  Actually that is irrellevant to C++, but it can trigger
bugs in c++ headers for instance in gcc/cp/cfns.h:

we have there:

#ifdef __GNUC__
__inline
#endif
const char * libc_name_p (const char *, unsigned int);
...
#ifdef __GNUC__
__inline
#ifdef __GNUC_STDC_INLINE__
__attribute__ ((__gnu_inline__))
#endif
#endif
const char *
libc_name_p (register const char *str, register unsigned int len)

=> error: different attributes.

The status quo is:

if we do not sepecify -std= on the command line (implicitly -std=gnu++14)
we have __GNUC_GNU_INLINE__ defined.

but if we define -std=gnu++14 to -std=c++11 on the command line,
we have __GNUC_STDC_INLINE__ defined.

if we define -std=c++03 on the command line, we get __GNUC_GNU_INLINE__.

I think the c++ FE does nothing with the flag_gnu89_inline.

I dont know what the right fix is here:
a) define __GNUC_GNU_INLINE__ in C++

b) define __GNUC_STDC_INLINE__ in C++ and fix gcc/cp/cfns.h

c) define neither __GNUC_GNU_INLINE__ nor _GNUC_STDC_INLINE__  in C++


c feels right, but may break other things on other header files.
a feels wrong, this is what probably most header files expect.

[Bug debug/60812] gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or corrupted

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

[Bug debug/60812] gcc -g -gpubnames statically linked produces a .debug_pubnames that is wrong or corrupted

[geir at cray dot com]

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

--- Comment #2 from Geir Johansen  ---
(In reply to Jakub Jelinek from comment #1)
> You haven't said which target it is, and we need preprocessed source as well.
> Couldn't reproduce this on x86_64-linux.

Problem does not occur in GCC 4.9.0, so this bug can be closed.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[dominiq at lps dot ens.fr]

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

--- Comment #56 from Dominique d'Humieres  ---
> >   FUNCTION FOO(I, J)
> >   COMMON /BLK/ K(1)
> >   FOO = K(I) + K(J) + K(2*I) + K(2*J)
> >   END FUNCTION

This piece of code is also invalid (out of bound access to K): K(I) + K(J) is
valid iff I=J=1, but K(2*I) + K(2*J) is always accessing elements outside the
array K(1).

> The correct solution to me is to detect the unequal sizes and convert
> the COMMON /BLK/ K(1) to the larger size, ie K(64).

This can be done at link time only if the two TU are in different files.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[jvdelisle at gcc dot gnu.org]

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

--- Comment #55 from Jerry DeLisle  ---
(In reply to H.J. Lu from comment #54)
> (In reply to alalaw01 from comment #53)
> > >
> > >So, there is nothing to fix in GCC? Why isn't this bug closed as invalid?
> > 
> > Not everyone wants to patch SPEC sources.
> 
> If the SPEC source is invalid according to Fortran standard, why should
> we change GCC for it?  This isn't the only invalid source in SPEC CPU
> 2006. There are at least 3.

The Fortran code is obviously legacy code. I think handling it behind
-std=legacy is the correct flag.

snip
> > 
> > --- Comment #45 from Jakub Jelinek  ---
> > Consider e.g. one source file
> >   INTEGER FOO
> >   COMMON /BLK/ K(64)
> >   DO I=1,64
> >   K(I)=1!!! typo should be =I
> >   END DO
> >   IF (FOO(5,12).NE.51) CALL ABORT
> >   END
> > and another one:
> >   FUNCTION FOO(I, J)
> >   COMMON /BLK/ K(1)
> >   FOO = K(I) + K(J) + K(2*I) + K(2*J)
> >   END FUNCTION

Note: Typo in the example

The correct solution to me is to detect the unequal sizes and convert the
COMMON /BLK/ K(1) to the larger size, ie K(64).

Currently we accept this code when it is all in one file and give a warning
only.  Playing with the test case in two files I see the problem is only with
K(1), K(2) or anything else gives correct results when optimized -O2, O3 etc.

Based on what I am seeing, I see no need for a flag at all, just a warning and
create the block to the size of the largest specified.

[Bug fortran/69867] ICE on initializing character in type with array of incompatible data

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). Note that compiling the first test in
comment 1 gives and ICE with gcc 4.9.3, while I get an ICE for the two tests
with gcc 4.8.5.

[Bug target/69868] New: vec_perm built-in is not handled by swap optimization on powerpc64le

[wschmidt at gcc dot gnu.org]

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

Bug ID: 69868
   Summary: vec_perm built-in is not handled by swap optimization
on powerpc64le
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: wschmidt at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
CC: dje.gcc at gmail dot com, uweigand at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64le-unknown-linux-gnu

The following test case, compiled with --std=c++11 -maltivec -O3 on
powerpc64le-unknown-linux-gnu, produces assembly code from which the endian
swaps have not been removed.  The problem is that swap optimization is not
smart enough to recognize the patterns produced by the vec_perm built-in. 
Although we do recognize a vperm instruction whose permute control vector is
loaded from the constant pool, the vec_perm built-in produces a sequence in
which the PCV is loaded and then complemented, which requires more work to get
right.

This provides an opportunity for further performance improvement, since swap
optimization should be able to perform the complement at compile time, swap the
results, and create this as a new constant to be loaded in the generated code. 
This is something we've wanted to do anyway, and doing it in the context of
swap optimization will catch these opportunities immediately after expand.

Opening this against myself as a reminder to fix this during next stage 1.

Test case:

#include 
#include 

using VecUC = vector unsigned char;
using VecUI = vector unsigned int;

void bar(VecUC *vpInput, VecUI *vpOut)
{
  VecUI v1 = {0,};
  VecUI vMask = { 0xff, 0xff,0xff,0xff};
  VecUI vShift = { 0xf, 0xff,0xff,0xff};
  VecUC vPermControl = { 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 };

#define FOO(a,b,c)  v1 = (VecUI)vec_perm(vpInput[a], vpInput[b], vPermControl);
\
  v1 = vec_sr(v1, vShift); \
  v1 = vec_and(v1, vMask);  \
  vpOut[c] = v1;

  FOO(0,0,0);
  FOO(0,0,1);
  FOO(0,1,2);
  FOO(0,1,3);
  FOO(1,0,4);
  FOO(1,0,5);
}

[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

[meissner at gcc dot gnu.org]

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

--- Comment #35 from Michael Meissner  ---
Author: meissner
Date: Thu Feb 18 19:59:03 2016
New Revision: 233535

URL: https://gcc.gnu.org/viewcvs?rev=233535&root=gcc&view=rev
Log:
Merge in fix for PR 68404

Modified:
branches/ibm/power9/   (props changed)
branches/ibm/power9/gcc/ChangeLog
branches/ibm/power9/gcc/ChangeLog.ibm
branches/ibm/power9/gcc/ChangeLog.meissner
branches/ibm/power9/gcc/REVISION
branches/ibm/power9/gcc/config/rs6000/predicates.md
branches/ibm/power9/gcc/config/rs6000/rs6000.md
branches/ibm/power9/gcc/testsuite/ChangeLog
branches/ibm/power9/gcc/testsuite/ChangeLog.ibm
branches/ibm/power9/gcc/testsuite/gcc.target/powerpc/fusion.c
branches/ibm/power9/gcc/testsuite/gcc.target/powerpc/fusion3.c
branches/ibm/power9/libgcc/ChangeLog.ibm

Propchange: branches/ibm/power9/
('svn:mergeinfo' modified)

Propchange: branches/ibm/power9/
('svnmerge-integrated' modified)

[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #34 from Michael Meissner  ---
Fixed in subversion id 233532.

[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

[meissner at gcc dot gnu.org]

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

--- Comment #33 from Michael Meissner  ---
Author: meissner
Date: Thu Feb 18 19:36:39 2016
New Revision: 233532

URL: https://gcc.gnu.org/viewcvs?rev=233532&root=gcc&view=rev
Log:
[gcc]
2016-02-18  Michael Meissner  

PR target/68404
* config/rs6000/predicates.md (fusion_gpr_addis): Revert
2016-02-09 change.

* config/rs6000/rs6000.md (fusion_gpr_load_): Remove
earlyclobber from target.  Use wF constraint for fused memory
address.
(fusion_gpr___load): Likewise.

[gcc/testsuites]
2016-02-18  Michael Meissner  

PR target/68404
* gcc.target/powerpc/fusion.c: Revert the 2016-02-09 change.
* gcc.target/powerpc/fusion3.c: Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/fusion.c
trunk/gcc/testsuite/gcc.target/powerpc/fusion3.c

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 Ever confirmed|0   |1

--- Comment #9 from David Edelsohn  ---
Thanks for investigating, Vlad!

This issue seems likely to occur on all RISC architectures, especially
including ARM and SPARC in addition to PPC.

[Bug fortran/69867] ICE on initializing character in type with array of incompatible data

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
One exception from comment 1 :

$ cat z7.f90
program p
   type t
  character(1) :: b = null()
  character(1) :: c(1) = null()
   end type
end

$ gfortran-6 z7.f90
f951: internal compiler error: Segmentation fault

[Bug fortran/69867] ICE on initializing character in type with array of incompatible data

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #3 from Gerhard Steinmetz  
---
These issues are thematically related to pr67804 (... more or less).

[Bug fortran/69867] ICE on initializing character in type with array of incompatible data

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
Detected when lhs is a scalar :

$ cat z4.f90
program p
   type t
  character(1) :: c(1) = 1
   end type
end

$ gfortran-6 z4.f90
z4.f90:3:28:

   character(1) :: c(1) = 1
1
Error: Can't convert INTEGER(4) to CHARACTER(1) at (1)



And detected outside of a type, e.g. :

$ cat z5.f90
program p
   character(1) :: b = [1]
   character(1) :: c(1) = [1]
end

$ gfortran-6 z5.f90
z5.f90:2:20:

character(1) :: b = [1]
1
Error: Incompatible ranks 0 and 1 in assignment at (1)
z5.f90:3:25:

character(1) :: c(1) = [1]
 1
Error: Can't convert INTEGER(4) to CHARACTER(1) at (1)

[Bug fortran/69867] New: ICE on initializing character in type with array of incompatible data

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 69867
   Summary: ICE on initializing character in type with array of
incompatible data
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

An array on lhs with incompatible data :

$ cat z1.f90
program p
   type t
  character(1) :: c(1) = [1]
   end type
end

$ gfortran-6 z1.f90
f951: internal compiler error: Segmentation fault



More variants :

$ cat z2.f90
program p
   type t
  character(1) :: d(1) = [1.]
  character(1) :: e(1) = [1d1]
  character(1) :: f(1) = [(0.,1.)]
  character(1) :: g(1) = [.true.]
  character(1) :: h(1) = [.false.]
  character(1) :: n(1) = [null()]
   end type
end


rhs needs not to be an array to trigger an ICE :
(incompatible ranks 0 and 1 in assignment)

$ cat z3.f90
program p
   type t
  character(1) :: c = [1]
  character(1) :: d = [1.]
  character(1) :: e = [1d1]
  character(1) :: f = [(0.,1.)]
  character(1) :: g = [.true.]
  character(1) :: h = [.false.]
  character(1) :: n = [null()]
   end type
end

[Bug fortran/69859] Non-deterministic ICEs on incomplete character declaration statement

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Running under valgrind, it looks like it's a use-after-free error:

$ cat ../../src/z7.f90 
program p
   type t
  character(2), allocatable :: a(*)
  character(*), allocatable :: b(2)
  character(*), allocatable :: c(*)
   end type
end

$ ./gfortran -B. ../../src/z7.f90 -wrapper valgrind
==6758== Memcheck, a memory error detector
==6758== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==6758== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==6758== Command: ./f951 ../../src/z7.f90 -quiet -dumpbase z7.f90
-mtune=generic -march=x86-64 -auxbase z7 -fintrinsic-modules-path finclude -o
/tmp/ccdQqEXb.s
==6758== 
../../src/z7.f90:3:39:

   character(2), allocatable :: a(*)
   1
Error: Allocatable component of structure at (1) must have a deferred shape
../../src/z7.f90:4:39:

   character(*), allocatable :: b(2)
   1
Error: Allocatable component of structure at (1) must have a deferred shape
../../src/z7.f90:5:39:

   character(*), allocatable :: c(*)
   1
Error: Allocatable component of structure at (1) must have a deferred shape
==6758== Invalid read of size 8
==6758==at 0x8399CF: resolve_fl_derived0(gfc_symbol*) (resolve.c:13196)
==6758==by 0x83A53D: resolve_fl_derived(gfc_symbol*) (resolve.c:13402)
==6758==by 0x83B161: resolve_symbol(gfc_symbol*) (resolve.c:13676)
==6758==by 0x85DED8: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) (symbol.c:3817)
==6758==by 0x85DF93: gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
(symbol.c:3842)
==6758==by 0x83F7B0: resolve_types(gfc_namespace*) (resolve.c:15465)
==6758==by 0x83FC39: gfc_resolve(gfc_namespace*) (resolve.c:15575)
==6758==by 0x813CD0: resolve_all_program_units(gfc_namespace*)
(parse.c:5551)
==6758==by 0x814557: gfc_parse_file() (parse.c:5803)
==6758==by 0x868BC5: gfc_be_parse_file() (f95-lang.c:201)
==6758==by 0xF44FE3: compile_file() (toplev.c:465)
==6758==by 0xF47FD2: do_compile() (toplev.c:1988)
==6758==  Address 0x4dba140 is 0 bytes inside a block of size 48 free'd
==6758==at 0x4A07577: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==6758==by 0x85DA05: gfc_free_charlen(gfc_charlen*, gfc_charlen*)
(symbol.c:3664)
==6758==by 0x80E7E0: reject_statement() (parse.c:2318)
==6758==by 0x808C52: match_word(char const*, match (*)(), locus*)
(parse.c:70)
==6758==by 0x809888: decode_statement() (parse.c:372)
==6758==by 0x80CE20: next_free() (parse.c:1076)
==6758==by 0x80D481: next_statement() (parse.c:1310)
==6758==by 0x80EF6E: parse_derived() (parse.c:2672)
==6758==by 0x810505: parse_spec(gfc_statement) (parse.c:3368)
==6758==by 0x813252: parse_progunit(gfc_statement) (parse.c:5189)
==6758==by 0x814222: gfc_parse_file() (parse.c:5698)
==6758==by 0x868BC5: gfc_be_parse_file() (f95-lang.c:201)

(this is with r233261)

[Bug target/66337] __alignof__(s.d) incorrect for a double member with -malign-power

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-02-18
 CC||dje at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from David Edelsohn  ---
I don't understand this bug report.  AIX does not use natural alignment because
the AIX ABI was created before "long long" existed and the team chose to not
create a larger alignment only for "double".  When the team realized the
mistake, they retrofitted the ABI to allow stricter alignment where the freedom
still existed -- singleton double and structures where double is the first
element (so the entire structure could transparently be aligned more strictly).

When ELF support was added to the rs6000 port, some customers wanted AIX
compatibility.  Support was added for ELF with and without function descriptors
and with and without AIX alignment.  -malign=power enables AIX-style alignment
for ELF.

The bug seems to be in the output of GCC builtin __alignof__.  How can a single
element member of a structure have weaker alignment, in reality, than the
structure itself?

The rs6000 port bumped the alignment of the structure but GCC still believes
that the element itself has the default alignment.  XLC correctly reports the
stricter interior alignment of the element.

[Bug rtl-optimization/69847] Spec 2006 403.gcc slows down with -mlra vs. reload on PowerPC

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
(In reply to Michael Meissner from comment #7)
> The following options were used for LRA code generation:
> -DSPEC_CPU -DNDEBUG -I.  -g -mlittle -save-temps=obj -ffast-math -O3
> -mveclibabi=mass -mcpu=power8 -mrecip=rsqrt -fpeel-loops -funroll-loops
> -ftree-vectorize -fvect-cost-model -msave-toc-indirect
> -fno-aggressive-loop-optimizations -mno-pointers-to-nested-functions -mlra 
> -m64 -I/opt/at8.0/include
> -I/opt/at8.0/lib/gcc/powerpc64le-linux-gnu/4.9.4/include -fgnu89-inline 
> -DSPEC_CPU_LP64 -DSPEC_CPU -DSPEC_CPU2006 -DINLINE=
> 
> The following options were used for reload code generation:
> -DSPEC_CPU -DNDEBUG -I.  -g -mlittle -save-temps=obj -ffast-math -O3
> -mveclibabi=mass -mcpu=power8 -mrecip=rsqrt -fpeel-loops -funroll-loops
> -ftree-vectorize -fvect-cost-model -msave-toc-indirect
> -fno-aggressive-loop-optimizations -mno-pointers-to-nested-functions  -m64
> -I/opt/at8.0/include
> -I/opt/at8.0/lib/gcc/powerpc64le-linux-gnu/4.9.4/include -fgnu89-inline 
> -DSPEC_CPU_LP64 -DSPEC_CPU -DSPEC_CPU2006 -DINLINE=

Mike, thanks for a good and detail report.  After spending some time on
comparison of code generated by reload and LRA, at least I found that LRA
generates unnecessary address reloads:

  Creating newreg=225, assigning class BASE_REGS to addr r225
  alt=0,overall=0,losers=0,rld_nregs=0
 Choosing alt 0 in insn 15:  (0) =Y  (1) r {*movdi_internal64}
   15: [r225:DI+low(unspec[`*.LANCHOR0',%2:DI] 47)]=r181:DI
  REG_DEAD r181:DI
  REG_DEAD %2:DI
Inserting insn reload before:
  133: r225:DI=high(unspec[`*.LANCHOR0',%2:DI] 47)

After checking what reload pass do in this situation, I found that reload
transforms the memnory address into sum of hi and low in the insn through
*LEGITIMIZE_RELOAD_ADDRESS* before actual reloading.

LRA does not use LEGITIMIZE_RELOAD_ADDRESS at all as the macro frequently uses
push_reload which is not a part of LRA.

I'll think how to fix it better.  Probably it will need introduction analogous
macro for LRA.

[Bug c/69866] New: lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

[acrsofter at gmail dot com]

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

Bug ID: 69866
   Summary: lto1: internal compiler error: in
add_symbol_to_partition_1, at lto/lto-partition.c:158
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acrsofter at gmail dot com
  Target Milestone: ---

lto1: internal compiler error: in add_symbol_to_partition_1, at
lto/lto-partition.c:158
0x58b14d add_symbol_to_partition_1
../../gcc-5.3.0/gcc/lto/lto-partition.c:157
0x58aeb2 add_symbol_to_partition_1
../../gcc-5.3.0/gcc/lto/lto-partition.c:202
0x58c10c lto_balanced_map(int)
../../gcc-5.3.0/gcc/lto/lto-partition.c:550
0x58640d do_whole_program_analysis
../../gcc-5.3.0/gcc/lto/lto.c:3324
0x58640d lto_main()
../../gcc-5.3.0/gcc/lto/lto.c:3485
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: arm-none-eabi-gcc returned 1 exit status
compilation terminated.
/files/work/acr/wip_elibos/elibos_toolchains/gcc-arm/gcc-arm-none-eabi-5.3.0-a/bin/../lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
../../../os/common/ports/ARMCMx/compilers/GCC/rules.mk:238: recipe for target
'build/ch.elf' failed
make: *** [build/ch.elf] Error 1



buildind ChibiOS_16.1.3/demos/STM32/RT-STM32F401RE-NUCLEO

https://sourceforge.net/projects/chibios/files/


./arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=./arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/files/work/acr/wip_elibos/elibos_toolchains/gcc-arm/gcc-arm-none-eabi-5.3.0-a/bin/../libexec/gcc/arm-none-eabi/5.3.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-5.3.0/configure --prefix=/opt/arm_cross
--target=arm-none-eabi --enable-languages=c,c++ --disable-multilib
--with-newlib
Thread model: single
gcc version 5.3.0 (GCC)

[Bug fortran/69668] [4.9/5/6 Regression] Error reading namelist opened with DELIM='NONE'

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #9 from Jerry DeLisle  ---
Fixed on trunk, 5, and 4.9, closing

[Bug fortran/69668] [4.9/5/6 Regression] Error reading namelist opened with DELIM='NONE'

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Author: jvdelisle
Date: Thu Feb 18 18:23:09 2016
New Revision: 233528

URL: https://gcc.gnu.org/viewcvs?rev=233528&root=gcc&view=rev
Log:
2016-02-18  Jerry DeLisle  

Backport from gcc-5-branch.
PR libgfortran/69668
* io/list_read.c (read_character): Remove code related to DELIM_NONE.
* gfortran.dg/namelist_38.f90: Update test.
* gfortran.dg/namelist_84.f90: Update test.

Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/namelist_38.f90
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/namelist_84.f90
branches/gcc-4_9-branch/libgfortran/ChangeLog
branches/gcc-4_9-branch/libgfortran/io/list_read.c

[Bug fortran/69860] ICE on missing end apostrophe with character(kind=4)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.4 up to trunk (6.0), except 4.8.5 and 4.8.4 (r217778).

Note that I don't see any ICE for

   character(len=2, kind=4) :: a = 'aa

[Bug fortran/69861] ICE on declaring class parameter array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.7 up to trunk (6.0).

[Bug fortran/69859] Non-deterministic ICEs on incomplete character declaration statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 CC||dmalcolm at gcc dot gnu.org,
   ||manu at gcc dot gnu.org
Summary|ICE on incomplete character |Non-deterministic ICEs on
   |declaration statement   |incomplete character
   ||declaration statement
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
I have compiled the tests from 4.8 up to trunk (6.0). While I have seen ICEs,
it happens that sometime they are were not seen:

[Book15] f90/bug% gfortran-fsf-4.8 pr69859_2.f90
pr69859_2.f90:3.19:

  character a ,
   1
Error: Invalid character in name at (1)
...
pr69859_2.f90:8.17:

  character f %
 1
Error: Syntax error in data declaration at (1)
pr69859_2.f90:3.17:

  character a ,
 1
Error: Character length of component 'a' needs to be a constant specification
expression at (1)

[Book15] f90/bug% gfortran-fsf-4.8 pr69859_2.f90
pr69859_2.f90:3.19:

  character a ,
   1
Error: Invalid character in name at (1)
...
pr69859_2.f90:8.17:

  character f %
 1
Error: Syntax error in data declaration at (1)
f951: internal compiler error: Segmentation fault: 11

f951: internal compiler error: Abort trap: 6
gfortran-fsf-4.8: internal compiler error: Abort trap: 6 (program f951)
Abort

[Book15] f90/bug% gfcc pr69859_3.f90
pr69859_3.f90:3:36:

   character, allocatable :: x(:) y(:)
1
Error: Syntax error in data declaration at (1)
pr69859_3.f90:3:36:

   character, allocatable :: x(:) y(:)
1
Error: Character length of component 'x' needs to be a constant specification
expression at (1)
[Book15] f90/bug% gfcc pr69859_3.f90
pr69859_3.f90:3:36:

   character, allocatable :: x(:) y(:)
1
Error: Syntax error in data declaration at (1)
f951: internal compiler error: Segmentation fault: 11

f951: internal compiler error: Abort trap: 6
gfcc: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gfcc: trunk revision 233414).

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Created attachment 37735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37735&action=edit
gcc6-pr69850-3.patch

Untested incremental fix for the dynamic_cast issue.

[Bug sanitizer/69863] no_sanitize_address doesn't disable stack instrumentation

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug sanitizer/69863] no_sanitize_address doesn't disable stack instrumentation

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Thu Feb 18 17:15:25 2016
New Revision: 233524

URL: https://gcc.gnu.org/viewcvs?rev=233524&root=gcc&view=rev
Log:
Do not emit red stack zones for a fn with no_sanitize_address

PR sanitizer/69863
* cfgexpand.c (asan_sanitize_stack_p): New function.
(partition_stack_vars): Use the function.
(expand_stack_vars): Likewise.
(defer_stack_allocation): Likewise.
(expand_used_vars): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c

[Bug rtl-optimization/56069] [4.9/5/6 Regression] RA pessimization

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

   Assignee|vmakarov at redhat dot com |bernds at gcc dot 
gnu.org

--- Comment #13 from Bernd Schmidt  ---
I think I got far enough that I'll just assign myself. Patches in testing.

[Bug objc/69844] [6 Regression] Possibly bogus error: unknown type name in ObjC code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-18
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug rtl-optimization/44281] [4.9/5/6 Regression] Global Register variable pessimisation

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

   Assignee|vmakarov at redhat dot com |bernds at gcc dot 
gnu.org

--- Comment #23 from Bernd Schmidt  ---
Ok, I know what's causing it - ebx could take part in register allocation since
we seem to have proper lifetime information for it and it dies in some places,
but IRA ignores it since global regs get added to fixed_regs.

[Bug target/69663] [ARM] Implement overflow arithmetic standard names {u,}{add,sub,mul}v4

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 CC||ramana at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
confirmed.

[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Ramana Radhakrishnan  ---
Confirmed.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[hjl.tools at gmail dot com]

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

--- Comment #54 from H.J. Lu  ---
(In reply to alalaw01 from comment #53)
> >
> >So, there is nothing to fix in GCC? Why isn't this bug closed as invalid?
> 
> Not everyone wants to patch SPEC sources.

If the SPEC source is invalid according to Fortran standard, why should
we change GCC for it?  This isn't the only invalid source in SPEC CPU
2006. There are at least 3.

[Bug objc/69844] [6 Regression] Possibly bogus error: unknown type name in ObjC code

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase:
@class D;

void
foo (void)
{
  for (;;)
;
  D *d = (id) 0;
  (void) d;
}

[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[hjl.tools at gmail dot com]

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

--- Comment #18 from H.J. Lu  ---
Created attachment 37733
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37733&action=edit
Fix for 416.gamess in SPEC CPU 2006

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[trippels at gcc dot gnu.org]

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

--- Comment #15 from Markus Trippelsdorf  ---
markus@x4 c++11 % /var/tmp/gcc_build_dir_/./gcc/xgcc -shared-libgcc
-B/var/tmp/gcc_build_dir_/./gcc -nostdinc++
-L/var/tmp/gcc_build_dir_/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/var/tmp/gcc_build_dir_/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/var/tmp/gcc_build_dir_/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include
-I/var/tmp/gcc/libstdc++-v3/../libgcc
-I/var/tmp/gcc_build_dir_/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/var/tmp/gcc_build_dir_/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/var/tmp/gcc/libstdc++-v3/libsupc++ -std=gnu++11 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=cow-shim_facets.lo -march=native -O2 -pipe -c -o
cow-shim_facets.lo ../../../../../gcc/libstdc++-v3/src/c++11/cow-shim_facets.cc
In file included from
../../../../../gcc/libstdc++-v3/src/c++11/cow-shim_facets.cc:35:0:
../../../../../gcc/libstdc++-v3/src/c++11/cxx11-shim_facets.cc: In member
function ‘const std::locale::facet* std::locale::facet::_M_cow_shim(const
std::locale::id*) const’:
../../../../../gcc/libstdc++-v3/src/c++11/cxx11-shim_facets.cc:792:19: warning:
nonnull argument ‘this’ compared to NULL [-Wnonnull-compare]
 if (auto* p = dynamic_cast(this))
   ^

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[alalaw01 at gcc dot gnu.org]

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

--- Comment #53 from alalaw01 at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #44)
> I don't have access to SPEC, so I can only guess... Is there maybe an 
> equivalence involved, something like

Turns out the COMMON is accessed via a MEM_REF in a loop, or as a VAR_DECL
inside. Go figure! :)

(In reply to Dominique d'Humieres from comment #49)
> I don't see the point to add yet another option just because "SPEC does not
> want to change the invalid Fortran". I think SPEC should be run with the
> option(s) causing the problem disabled.

Anecdotally I hear from Fortran-using colleagues this may occur in other places
too. Moreover, the list of phases using get_ref_base_and_extent, is long; we
could end up compiling with an ever-growing -fno-this -fno-that as more and
more phases make use of the "bad" analysis results (that is correct by the
language spec after all). In this case, there are a few other equivalences
found due to the tree-ssa-scopedtables.c changes, that we'd lose with
-fno-tree-dominator-opts, too.

(In reply to H.J. Lu from comment #52)
>
>So, there is nothing to fix in GCC? Why isn't this bug closed as invalid?

Not everyone wants to patch SPEC sources.

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #15 from Bernd Schmidt  ---
I think 4.9 doesn't use a pseudo pic register on x86, so no big need to
backport to that branch.

[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686

[bernds at gcc dot gnu.org]

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

--- Comment #14 from Bernd Schmidt  ---
Author: bernds
Date: Thu Feb 18 15:23:11 2016
New Revision: 233523

URL: https://gcc.gnu.org/viewcvs?rev=233523&root=gcc&view=rev
Log:
Backport PR69648 fix from mainline (set of picreg removed during lra).

PR rtl-optimization/69648
* lra-constraints.c (update_ebb_live_info): Don't remove sets of
pic_offset_table_rtx.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/lra-constraints.c

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #37730|0   |1
is obsolete||

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

Updated fix.

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

[dev-zero at gentoo dot org]

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

Tiziano Müller  changed:

   What|Removed |Added

 CC||dev-zero at gentoo dot org

--- Comment #5 from Tiziano Müller  ---
Found my way here via bug #52159. When building Qemu with -flto I get with
gcc-5.3.0:

[...]
lto1: error: two or more sections for .gnu.lto_fprintf.288635079aa9eb60
(null):0: confused by earlier errors, bailing out
lto-wrapper: fatal error:
/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0/x86_64-pc-linux-gnu-g++ returned 1 exit
status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[hjl.tools at gmail dot com]

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

--- Comment #52 from H.J. Lu  ---
(In reply to rguent...@suse.de from comment #51)
> > --- Comment #50 from H.J. Lu  ---
> > Has my fix for 416.gamess source been applied when the failure happened?
> 
> No.

So, there is nothing to fix in GCC? Why isn't this bug closed as invalid?

[Bug c++/69865] -trigraphs option broken

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-18
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  ---
(In reply to Bernd Edlinger from comment #2)
> in gcc/c-family/c-opts.c:
> 
> following code in line 805:
> 
>   /* Set C++ standard to C++14 if not specified on the command line.  */
>   if (c_dialect_cxx () && cxx_dialect == cxx_unset)
> set_std_cxx14 (/*ISO*/false);

The default for C is set in c_common_init_options, which seems more logical.

> 
> case OPT_trigraphs:
>   cpp_opts->trigraphs = 1;
>   break;


If you use CPP(trigraphs) in c.opt, this code is auto-generated (and also the
default of libcpp becomes the default of GCC, unless overriden).

[Bug c++/68585] [5/6 Regression] c++14 code accepted by 4.9 not accepted by 5 and 6

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Thu Feb 18 14:49:22 2016
New Revision: 233522

URL: https://gcc.gnu.org/viewcvs?rev=233522&root=gcc&view=rev
Log:
PR c++/68585
* constexpr.c (cxx_eval_bare_aggregate): Fix 'changed' detection.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-initlist9.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/constexpr.c

[Bug c++/68679] [5/6 Regression] gcc-5.2.1 ICE in C++11 anon union of structs with template fns, OK in gcc <= 4.9.3

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Feb 18 14:49:16 2016
New Revision: 233521

URL: https://gcc.gnu.org/viewcvs?rev=233521&root=gcc&view=rev
Log:
PR c++/68679
* decl2.c (reset_type_linkage_2): Look through member templates.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/other/anon8.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/decl2.c

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenther at suse dot de]

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

--- Comment #51 from rguenther at suse dot de  ---
On Thu, 18 Feb 2016, hjl.tools at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> H.J. Lu  changed:
> 
>What|Removed |Added
> 
>  CC||hjl.tools at gmail dot com
> 
> --- Comment #50 from H.J. Lu  ---
> Has my fix for 416.gamess source been applied when the failure happened?

No.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #50 from H.J. Lu  ---
Has my fix for 416.gamess source been applied when the failure happened?

[Bug middle-end/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Thu Feb 18 14:34:59 2016
New Revision: 233520

URL: https://gcc.gnu.org/viewcvs?rev=233520&root=gcc&view=rev
Log:
2016-02-18  Richard Biener  

PR middle-end/69553
* fold-const.c (operand_equal_p): Properly compare offsets for
IMAGPART_EXPR and ARRAY_REF.

* g++.dg/torture/pr69553.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr69553.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[trippels at gcc dot gnu.org]

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

--- Comment #13 from Markus Trippelsdorf  ---
template  struct A {
  static void release(T *p1) { p1->Release(); }
};
template  class IntrusiveRefCntPtr {
  T Obj;
public:
  void operator=(IntrusiveRefCntPtr) { A::release(&Obj); }
};
struct RopeRefCountString {
  void Release() { delete[] this; }
};
struct RopePiece {
  IntrusiveRefCntPtr StrData;
};
class RopePieceBTreeNode {
protected:
  enum { WidthFactor };
};
class RopePieceBTreeLeaf : RopePieceBTreeNode {
  RopePiece Pieces[WidthFactor];
  RopePieceBTreeNode *insert(const RopePiece &);
};
int a;
RopePieceBTreeNode *RopePieceBTreeLeaf::insert(const RopePiece &) {
  Pieces[a] = Pieces[1];
}

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #12 from Manuel López-Ibáñez  ---
Since it seems this has to be explained repeatedly (and I had to read this in
detail to understand why this is a pedwarn enabled by -Wall), I created a FAQ:
https://gcc.gnu.org/wiki/FAQ#Wnarrowing

Jonathan, I used most of your comment #4 verbatim, I hope this is OK. Feel free
to edit it for corrections or further clarification.

[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||mgsergio at yandex dot ru

--- Comment #11 from Manuel López-Ibáñez  ---
*** Bug 69864 has been marked as a duplicate of this bug. ***

[Bug c++/69864] Narrowing conversion warning instead of an error

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
 Resolution|WONTFIX |DUPLICATE

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #3)
> Or use -pedantic-errors.

I find it a bit ironic that Clang does inform the user when something is
accepted as a GNU extension, but *GNU* GCC does not clarify this. Perhaps the
pedwarn below would be clearer with something like?

warning: narrowing conversion of '(double)u' from 'double' to 'int' inside { }
is a GNU extension

Or even something fancier:

warning: narrowing conversion of '(double)u' from 'double' to 'int' inside { }
(error in c++11, allowed by gnu++11)

or

warning: (GNU extension to c++11) narrowing conversion of '(double)u' from
'double' to 'int' inside { }

It would be not too difficult to automatically print the current base standard
and the corresponding gnu standard on every pedwarn.

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

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[trippels at gcc dot gnu.org]

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

--- Comment #12 from Markus Trippelsdorf  ---
Created attachment 37731
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37731&action=edit
unreduced testcase

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Can you attach it again?

[Bug c++/69865] -trigraphs option broken

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
in gcc/c-family/c-opts.c:

following code in line 805:

  /* Set C++ standard to C++14 if not specified on the command line.  */
  if (c_dialect_cxx () && cxx_dialect == cxx_unset)
set_std_cxx14 (/*ISO*/false);

... defeats this in line 667 above:

case OPT_trigraphs:
  cpp_opts->trigraphs = 1;
  break;

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
Still happening even with latest patch:

[1763/2142] Building CXX object
tools/clang/lib/StaticAnalyzer/Core/CMakeFiles/clangStaticAnalyzerCore.dir/HTMLDiagnostics.cpp.o
In file included from
/home/trippels/llvm/tools/clang/include/clang/Rewrite/Core/RewriteBuffer.h:15:0,
 from
/home/trippels/llvm/tools/clang/include/clang/Rewrite/Core/Rewriter.h:19,
 from
/home/trippels/llvm/tools/clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp:21:
/home/trippels/llvm/tools/clang/include/clang/Rewrite/Core/RewriteRope.h: In
member function ‘void clang::RopeRefCountString::Release()’:
/home/trippels/llvm/tools/clang/include/clang/Rewrite/Core/RewriteRope.h:43:30:
warning: nonnull argument ‘this’ compared to NULL [-Wnonnull-compare]
 delete [] (char*)this;
  ^

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[dominiq at lps dot ens.fr]

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

--- Comment #49 from Dominique d'Humieres  ---
> Yeah, I plan to add a fortran-specific option for this, it's easy enough,

I don't see the point to add yet another option just because "SPEC does not
want to change the invalid Fortran". I think SPEC should be run with the
option(s) causing the problem disabled.

> but I can't run the gfortran testsuite with that, because there are lots
> of C files in there too, for which the compiler doesn't accept the option...

You can use something along the following

--- ../_clean/gcc/testsuite/lib/prune.exp   2016-01-04 19:51:06.0
+0100
+++ gcc/testsuite/lib/prune.exp 2016-01-04 20:30:13.0 +0100
@@ -51,6 +51,9 @@ proc prune_gcc_output { text } {
 regsub -all "(^|\n)\[^\n\]*: Additional NOP may be necessary to workaround
Itanium processor A/B step errata" $text "" text
 regsub -all "(^|\n)\[^\n*\]*: Assembler messages:\[^\n\]*" $text "" text

+# Ignore warning for gfortran options passed to the C compilers.
+regsub -all "(^|\n)cc1(plus)?: warning: command line option .-f\[^\"\]*.
is valid for Fortran but not for C\[^\n\]*" $text "" text
+
 # Ignore harmless VTA note.
 regsub -all "(^|\n)\[^\n\]*: note: variable tracking size limit exceeded
with -fvar-tracking-assignments, retrying without\[^\n\]*" $text "" text

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[jakub at gcc dot gnu.org]

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

--- Comment #47 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #46)
> Which is odd since FRE already should optimize it that way.

Bet FRE punts on that because it considers it poor man's flexible array member.
But, you know FRE better than me ;)

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenther at suse dot de]

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

--- Comment #48 from rguenther at suse dot de  ---
On Thu, 18 Feb 2016, rguenther at suse dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> --- Comment #46 from rguenther at suse dot de  ---
> On Thu, 18 Feb 2016, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> > 
> > --- Comment #45 from Jakub Jelinek  ---
> > Consider e.g. one source file
> >   INTEGER FOO
> >   COMMON /BLK/ K(64)
> >   DO I=1,64
> >   K(I)=1
> >   END DO
> >   IF (FOO(5,12).NE.51) CALL ABORT
> >   END
> > and another one:
> >   FUNCTION FOO(I, J)
> >   COMMON /BLK/ K(1)
> >   FOO = K(I) + K(J) + K(2*I) + K(2*J)
> >   END FUNCTION
> > If the second source file is compiled with -O2, it will return "wrong" 
> > value,
> > as if all accesses to K were using the same index (because the only valid 
> > index
> > is 1).  If you compile with -O2 -fno-tree-dominator-opts, then it "works".
> 
> Which is odd since FRE already should optimize it that way.

Ok, it does not.  Supposedly more complicated situations are needed to
trigger sth wrong in FRE.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenther at suse dot de]

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

--- Comment #46 from rguenther at suse dot de  ---
On Thu, 18 Feb 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
> 
> --- Comment #45 from Jakub Jelinek  ---
> Consider e.g. one source file
>   INTEGER FOO
>   COMMON /BLK/ K(64)
>   DO I=1,64
>   K(I)=1
>   END DO
>   IF (FOO(5,12).NE.51) CALL ABORT
>   END
> and another one:
>   FUNCTION FOO(I, J)
>   COMMON /BLK/ K(1)
>   FOO = K(I) + K(J) + K(2*I) + K(2*J)
>   END FUNCTION
> If the second source file is compiled with -O2, it will return "wrong" value,
> as if all accesses to K were using the same index (because the only valid 
> index
> is 1).  If you compile with -O2 -fno-tree-dominator-opts, then it "works".

Which is odd since FRE already should optimize it that way.

Richard.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[jakub at gcc dot gnu.org]

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

--- Comment #45 from Jakub Jelinek  ---
Consider e.g. one source file
  INTEGER FOO
  COMMON /BLK/ K(64)
  DO I=1,64
  K(I)=1
  END DO
  IF (FOO(5,12).NE.51) CALL ABORT
  END
and another one:
  FUNCTION FOO(I, J)
  COMMON /BLK/ K(1)
  FOO = K(I) + K(J) + K(2*I) + K(2*J)
  END FUNCTION
If the second source file is compiled with -O2, it will return "wrong" value,
as if all accesses to K were using the same index (because the only valid index
is 1).  If you compile with -O2 -fno-tree-dominator-opts, then it "works".

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Reopening for the #c7 issue.

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[tkoenig at gcc dot gnu.org]

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

--- Comment #44 from Thomas Koenig  ---
I don't have access to SPEC, so I can only guess...

Is there maybe an equivalence involved, something like

  COMMON /FOO/ X(1)
  EQUIVALENCE (X,Y)

?

[Bug c++/69865] -trigraphs option broken

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
weird:
If I add -std=c++14 (or any other c++ version, including -ansi)
to the command line, it works.

[Bug target/62254] [4.9/5/6 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #8 from Nick Clifton  ---
I have now checked in the patch.

[Bug target/69610] [5/6 Regression] ICE: SIGSEGV in arm_reload_in_hi (arm.c:15446) with -march=armv3

[nickc at gcc dot gnu.org]

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

--- Comment #3 from Nick Clifton  ---
Author: nickc
Date: Thu Feb 18 13:00:07 2016
New Revision: 233518

URL: https://gcc.gnu.org/viewcvs?rev=233518&root=gcc&view=rev
Log:
PR target/62554
PR target/69610
gcc * config/arm/arm.c (arm_option_override_internal): Disable
interworking if the target does not support thumb instructions.
(arm_reload_in_hi): Handle the case where a register to register
move needs reloading because there is no simple pattern to handle
it.
(arm_reload_out_hi): Likewise.

tests   * gcc.target/arm/pr62554.c: New test.
* gcc.target/arm/pr69610-1.c: New test.
* gcc.target/arm/pr69610-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/arm/pr62554.c
trunk/gcc/testsuite/gcc.target/arm/pr69610-1.c
trunk/gcc/testsuite/gcc.target/arm/pr69610-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/69865] New: -trigraphs option broken

[bernd.edlinger at hotmail dot de]

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

Bug ID: 69865
   Summary: -trigraphs option broken
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Hi,

I know, nobody likes them, but...

cat test.cc
int
main ()
??<
  return 0;
??>

gcc -trigraphs test.cc
test.cc:3:1: warning: trigraph ??< ignored, use -trigraphs to enable
[-Wtrigraphs]
 ??<
 ^
test.cc:5:1: warning: trigraph ??> ignored, use -trigraphs to enable
[-Wtrigraphs]
 ??>
 ^
test.cc:3:1: error: expected initializer before '?' token
 ??<
 ^
test.cc:5:1: error: expected unqualified-id before '?' token
 ??>
 ^

[Bug objc/69844] [6 Regression] Possibly bogus error: unknown type name in ObjC code

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
I think a safe fix would be to just add if (!c_dialect_objc ()) to the change
that caused this.

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
(wow, llvm approaches Boost in the complexity of testcases. It takes ages to
reduce them.) 


class RefCountedBaseVPTR {
  virtual ~RefCountedBaseVPTR();
  void Release() const { delete this; }
  template  friend struct A;
};
template  struct A {
  static void release(T *p1) { p1->Release(); }
};
template  class B {
  T Obj;
public:
  void reset() { A::release(&Obj); }
};
class C {
  class Payload : public RefCountedBaseVPTR {
~Payload();
  };
  void reset();
  B Value;
};
void C::reset() { Value.reset(); }

[Bug c/69819] [4.9/5/6 Regression] ICE on invalid code on x86_64-linux-gnu in tree check: expected function_type or method_type, have array_type in function_args_iter_init, at tree.h:4536

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
This fixes it but I'd like to think about this some more.

--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -4743,7 +4743,7 @@ finish_decl (tree decl, location_t init_loc, tree init,
  struct c_binding *b_ext = I_SYMBOL_BINDING (DECL_NAME (decl));
  while (b_ext && !B_IN_EXTERNAL_SCOPE (b_ext))
b_ext = b_ext->shadowed;
- if (b_ext)
+ if (b_ext && TREE_CODE (decl) == TREE_CODE (b_ext->decl))
{
  if (b_ext->u.type && comptypes (b_ext->u.type, type))
b_ext->u.type = composite_type (b_ext->u.type, type);

[Bug c++/69855] Missing diagnostic for overload that only differs by return type

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Minimal reproducer:

int get();
void f() {
  char get();
}

Slightly sneakier version that defeated my first attempt to fix it (because the
overload set causes us to discard the previous decls):

int get();
char get(int);
void f() {
  char get();
}

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[alalaw01 at gcc dot gnu.org]

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

--- Comment #43 from alalaw01 at gcc dot gnu.org ---
Yeah, I plan to add a fortran-specific option for this, it's easy enough, but I
can't run the gfortran testsuite with that, because there are lots of C files
in there too, for which the compiler doesn't accept the option...

I'm having trouble writing a testcase though. My subroutine with

IMPLICIT DOUBLE PRECISION (X)
COMMON /MYCOMMON / X(1)

produces "mycommon.x" a COMPONENT_REF, but with "mycommon" being a MEM_REF,
which requires only the hunk to tree-dfa.c to handle correctly; whereas in
SPEC2006, what looks to me to be equivalent FORTRAN, ends up with "mycommon"
being a VAR_DECL, which requires the much-bigger patch to the fortran FE...

I've very little fortran experience here, any tips?

Thanks, Alan

[Bug c++/69864] Narrowing conversion warning instead of an error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Or use -pedantic-errors.

[Bug testsuite/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org ---
Alternative patch proposed by Bernd Edlinger :
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00976.html .

Patch approved by sanitizer reviewer :
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00985.html .

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
I've already posted the patch for review:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01201.html

[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?

[kyukhin at gcc dot gnu.org]

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

--- Comment #24 from Kirill Yukhin  ---
(In reply to rguent...@suse.de from comment #23)
> On Wed, 17 Feb 2016, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
> > 
> > --- Comment #22 from Jakub Jelinek  ---
> > Created attachment 37722 [details]
> >   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37722&action=edit
> > gcc6-pr69671.patch
> > 
> > Actually, on a closer look, I believe the only problem are the patterns that
> > use a vector_move_operand "0C" inside of vec_select with only constants as 
> > the
> > parallel's operands.  Because fwprop is able to propagate constants into
> > instructions (thus undo the CSE effect), but doesn't do anything on these,
> > because it also simplifies them, so instead of the expected say
> > (vec_select:V4QI (const_vector:V16QI [
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > ])
> > (parallel [
> > (const_int 0 [0])
> > (const_int 1 [0x1])
> > (const_int 2 [0x2])
> > (const_int 3 [0x3])
> > ]))
> > we get in there simplified:
> > (const_vector:V4QI [
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > (const_int 0 [0])
> > ])
> > So, by adding extra patterns for that simplification fwprop is able to do 
> > its
> > job even if CSE did a better job.
> 
> Of course then I wonder why we didn't simplify this in the first place
> when generating RTL and need to wait for forwprop ...
> 
> But yes, sounds like the easiest way to go forward.

Agree.

[Bug rtl-optimization/69764] [5 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Doesn't ICE for me...
Can you please debug what is going on?

[Bug driver/69849] Some spec functions are undocumented in doc/invoke.texi

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
In addition, the '%{%:function(args):X}' construct is undocumented, as noted
here: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01243.html .

[Bug rtl-optimization/69764] [5 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

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

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

--- Comment #13 from Andreas Schwab  ---
Created attachment 37729
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37729&action=edit
Preprocessed source

[Bug c++/69864] Narrowing conversion warning instead of an error

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Markus Trippelsdorf  ---
This is done so intentionally.

Note that you could suppress the error in clang with -Wno-narrowing.

If you need an error in gcc use -Werror=narrowing.

[Bug rtl-optimization/69764] [5 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
(In reply to Andreas Schwab from comment #11)
> /daten/aranym/gcc/gcc-20160218/Build/./gcc/xgcc
> -B/daten/aranym/gcc/gcc-20160218/Build/./gcc/
> -B/daten/cross/m68k-linux/m68k-linux/bin/
> -B/daten/cross/m68k-linux/m68k-linux/lib/ -isystem
> /daten/cross/m68k-linux/m68k-linux/include -isystem
> /daten/cross/m68k-linux/m68k-linux/sys-include-g -O2 -O2  -g -O2
> -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
> -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
> -Wold-style-definition  -isystem ./include   -fPIC -g -DIN_LIBGCC2
> -fbuilding-libgcc -fno-stack-protector   -fPIC -I. -I. -I../.././gcc
> -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc
> -I../../../libgcc/../include  -DHAVE_CC_TLS  -o _mulvsi3.o -MT _mulvsi3.o
> -MD -MP -MF _mulvsi3.dep -DL_mulvsi3 -c ../../../libgcc/libgcc2.c
> -fvisibility=hidden -DHIDE_EXPORTS
> In file included from ../../../libgcc/libgcc2.c:56:0:
> ../../../libgcc/libgcc2.c: In function ‘__mulvsi3’:
> ../../../libgcc/libgcc2.h:208:19: internal compiler error: in
> maybe_legitimize_operand, at optabs.c:6903
>  #define __NW(a,b) __ ## a ## si ## b
>^

Can you attach preprocessed source for this?

[Bug rtl-optimization/69764] [5 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)

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

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

--- Comment #11 from Andreas Schwab  ---
/daten/aranym/gcc/gcc-20160218/Build/./gcc/xgcc
-B/daten/aranym/gcc/gcc-20160218/Build/./gcc/
-B/daten/cross/m68k-linux/m68k-linux/bin/
-B/daten/cross/m68k-linux/m68k-linux/lib/ -isystem
/daten/cross/m68k-linux/m68k-linux/include -isystem
/daten/cross/m68k-linux/m68k-linux/sys-include-g -O2 -O2  -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -I. -I. -I../.././gcc -I../../../libgcc
-I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include 
-DHAVE_CC_TLS  -o _mulvsi3.o -MT _mulvsi3.o -MD -MP -MF _mulvsi3.dep
-DL_mulvsi3 -c ../../../libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from ../../../libgcc/libgcc2.c:56:0:
../../../libgcc/libgcc2.c: In function ‘__mulvsi3’:
../../../libgcc/libgcc2.h:208:19: internal compiler error: in
maybe_legitimize_operand, at optabs.c:6903
 #define __NW(a,b) __ ## a ## si ## b
   ^

[Bug target/69857] gcc/config/arm/arm.c:15949: return in strange place ?

[ktkachov at gcc dot gnu.org]

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Yes, that's an approach that can be taken. Once such a case is found, you could
also try using a reducer program like creduce to create a small testcase
appropriate for the testsuite.

Removing the return there would probably be an optimisation, which is why I
recommended it for GCC 7. GCC 6 is now in a regression fixing stage, so for it
to go in now we would need to find a testcase where we were performing an
optimisation before r197530 and after r197530 (with the bogus return) we
stopped doing. Considering that r197530 was supposed to introduce that
optimisation, it's unlikely that such a case can be found.

[Bug c++/69864] Narrowing conversion warning instead of an error

[mgsergio at yandex dot ru]

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

--- Comment #1 from mgsergio  ---

*gcc emits a warning on narrowing_check although an error should be generated
instead.

[Bug target/69857] gcc/config/arm/arm.c:15949: return in strange place ?

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
(In reply to ktkachov from comment #5)
> We'd need a testcase that shows a regression resulting from this code not
> being run i.e. code that became worse after r197530 (or wrong code or an
> ICE) and is fixed by removing that "return false;".
> Then, a normal bootstrap and test should be enough and the change could go
> in as a regression fix at this stage. But finding such a testcase would not
> be easy, I suspect.

A step on the way to finding that test case would be to put a marker
into the code. Something like

   else if (TARGET_ARM)
   {
   // Either this
   fprintf( stderr, "dcb: Got to interesting place\n");
   // or this
   inform (0, "dcb: Got to interesting place");
   return false;

Then compile a lot of code, looking for the "interesting place" comment.
This can be left unattended, so need not consume valuable developer time.
A simple grep through some build logs would do.

Once we've got example code that gets to that place, merely do a before'n'after
with and without the "return false" and see what happens. If there is
a regression, then we are done.

I suspect the "return false;" merely prevents us doing some ARM
specific optimisation, so removing the "return false" is likely IMHO 
to make the code go faster.

Just an idea.

[Bug c++/69864] New: Narrowing conversion

[mgsergio at yandex dot ru]

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

Bug ID: 69864
   Summary: Narrowing conversion
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mgsergio at yandex dot ru
  Target Milestone: ---

#include 
#include 
using namespace std;

template 
inline T narrowing_check(U const u)
{
  // Also gives only warning
  // T t{u};
  // return t;
  return {u};
}

int main() {
  auto a = narrowing_check(3.5);
  cout << a;
  // int b{2.3};
  return 0;
}

gcc emits a waring on narrowing_check although it should be generated instead.
On int b{2.3} gcc correctly rejects the code. 

g++-5 -Wall -Wextra -std=c++11 1.cc
1.cc: In instantiation of 'T narrowing_check(U) [with T = int; U = double]':
1.cc:15:36:   required from here
1.cc:11:12: warning: narrowing conversion of '(double)u' from 'double' to 'int'
inside { } [-Wnarrowing]
   return {u};

clang rejects this code.
1.cc:11:11: error: type 'double' cannot be narrowed to 'int' in initializer
list [-Wc++11-narrowing]
  return {u};
  ^
1.cc:15:12: note: in instantiation of function template specialization
'narrowing_check' requested here
  auto a = narrowing_check(3.5);
   ^
1.cc:11:11: note: insert an explicit cast to silence this issue
  return {u};
  ^
  static_cast( )
1 error generated.