[Bug target/70014] [ARM] Predicate does not match constraint (*subsi3_carryin_const)

[collison at gcc dot gnu.org]

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

--- Comment #2 from collison at gcc dot gnu.org ---
Author: collison
Date: Thu Mar  3 07:42:02 2016
New Revision: 233927

URL: https://gcc.gnu.org/viewcvs?rev=233927=gcc=rev
Log:
2016-03-03  Michael Collison  

PR target/70014
* config/arm/arm.md (*subsi3_carryin_const): Change predicate
for operand 1 to s_register_operand. Change predicate for operand
2 to arm_not_immediate_operand.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.md

[Bug testsuite/70055] gcc.target/i386/chkp-stropt-16.c is incompatible with glibc 2.23

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
These glibc inlines are just wrong, they should trust the compiler doing the
right thing at least for contemporary versions.
05a910f7b420c2b831f35ba90e61c80f001c0606 should be IMHO reverted, it should be
approached at the compiler side if the ARM folks see any performance issues
with what is generated.

[Bug tree-optimization/69196] [5/6 Regression] code size regression with jump threading at -O2

[vogt at linux dot vnet.ibm.com]

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

--- Comment #18 from Dominik Vogt  ---
Which dumps do you need?

[Bug fortran/45179] Support UTF-8 (and other encodings) in the source file (.f90) for CHARACTER(kind=4)

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #5 from Jerry DeLisle  ---
We have UTF-8 read function in libgfortran, we could just incorporate these
into scanner.c  Adding to my TODO list.

[Bug fortran/66709] ICE on formatted io with parameter array specifier fmt

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #3 from Jerry DeLisle  ---
This I think gets into array constructors to build the parameter constants and
we don't address it yet.

[Bug ipa/69990] [6 Regression] decl alignment not respected

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.4 |6.0
Summary|[5/6 Regression] decl   |[6 Regression] decl
   |alignment not respected |alignment not respected

--- Comment #7 from Alan Modra  ---
Fixed.  Testcase doesn't fail on gcc-5 due to sem_variable::equals_wpa
rejecting DECL_ALIGN diferences.

[Bug fortran/70058] New: Segmentation fault when open file with existing file and status = "UNKNOWN"

[ranftmaps at hotmail dot com]

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

Bug ID: 70058
   Summary: Segmentation fault when open file with existing file
and status = "UNKNOWN"
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ranftmaps at hotmail dot com
  Target Milestone: ---

For the Windows 64 bit gfortran version 5.1.0, a segmentation fault will occur
if the open statement with status = 'UNKNOWN' is used when the file exists.  
Earlier versions of gfortran (such as 4.6.2) do not have this issue.  Example
code is as follows:

   OPEN(UNIT=5,FILE='exists.txt',STATUS='UNKNOWN')
   CLOSE(UNIT=5,STATUS='KEEP')
   STOP 'NORMAL TERMINATION'
   END 

gfortran version information is as follows:

C:\TDM-GCC-64\bin>gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=C:/TDM-GCC-64/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-5.1.0/configure --build=x86_64-w64-mingw32
--enable-targets=all --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++
--enable-libgomp --enable-lto --enable-graphite
--enable-cxx-flags=-DWINPTHREAD_STATIC --disable-build-with-cxx
--disable-build-poststage1-with-cxx --enable-libstdcxx-debug
--enable-threads=posix --enable-version-specific-runtime-libs
--enable-fully-dynamic-string --enable-libstdcxx-threads
--enable-libstdcxx-time --with-gnu-ld --disable-werror --disable-nls
--disable-win32-registry --prefix=/mingw64tdm --with-local-prefix=/mingw64tdm
--with-pkgversion=tdm64-1 --with-bugurl=http://tdm-gcc.tdragon.net/bugs
Thread model: posix
gcc version 5.1.0 (tdm64-1)

[Bug target/65501] [5 Regression] v850 ICE at c_register_pragma_1, at c-family/c-pragma.c:1317

[yselkowi at redhat dot com]

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

--- Comment #6 from Yaakov Selkowitz  ---
Created attachment 37849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37849=edit
patch for gcc-5

(In reply to Jeffrey A. Law from comment #5)
> Fixed on the trunk by the change for 68271.  I'm not currently planning to
> backport to gcc-5.

Thanks, those commits fixed the build of v850-elf.  I'm attaching a backport
for 5.3.0 in case anyone wants it.

[Bug libffi/70024] [5/6 Regression] libffi ABI change w/o SONAME bump

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Henderson  ---
FIXED for gcc6, WONTFIX for gcc5.

[Bug c++/70057] duplicate integer overflow diagnostic in constant expressions

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #1)
> The C++ FE has the tendency to give diagnostics very deep in the call stack,
> where there is little knowledge of the context. It would be much better to
> signal to the caller that something went wrong and let them decide what to
> say. It would also probably be faster by avoiding checking error conditions
> multiple times and not passing down information that is only used to provide
> context.

And constexpr.c is just full of this. An endless supply of duplicated
diagnostics:

prog.cc:1:17: warning: division by zero [-Wdiv-by-zero]
 static_assert(7 / 0, "X");
   ~~^~~
prog.cc:1:1: error: non-constant condition for static assertion
 static_assert(7 / 0, "X");
 ^
prog.cc:1:1: error: division by zero is not a constant-expression


And pretty-printing arbitrary expressions is... not pretty:

prog.cc:1:25: warning: division by zero [-Wdiv-by-zero]
   constexpr int x = 0.3 / 0;
 ^~~
prog.cc:1:25: error: '(2.e-1 / 0.0)' is not a constant
expression

[Bug libffi/70024] [5/6 Regression] libffi ABI change w/o SONAME bump

[rth at gcc dot gnu.org]

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

--- Comment #6 from Richard Henderson  ---
Author: rth
Date: Thu Mar  3 01:40:29 2016
New Revision: 233926

URL: https://gcc.gnu.org/viewcvs?rev=233926=gcc=rev
Log:
PR libffi/70024

  * Makefile.am (libffi_version_script): Look in cwd for libffi.map.
  (libffi_version_dep, libffi.map-sun): Likewise.
  (libffi.map): New target.
  * libffi.map.in: Rename from libffi.map.  Add required defines,
  includes, and conditionals.

Added:
trunk/libffi/libffi.map.in
  - copied, changed from r233925, trunk/libffi/libffi.map
Removed:
trunk/libffi/libffi.map
Modified:
trunk/libffi/ChangeLog
trunk/libffi/Makefile.am
trunk/libffi/Makefile.in

[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
(In reply to Leon Winter from comment #7)
> Maybe a better solution is to hint the compiler that the loop body will be
> run at least once. A do-while seems to imply that (and the compiler does not
> print a warning).

Not for the minimized testcase. Unless you declare 'a' within the loop body,
which is not exactly equivalent.

If you declare it outside the loop body, gcc generates exactly the same code
for a 'for' and a 'do-while'.

[Bug c++/70034] wrong column and repetitive -Wvla warning for each non-constant dimension of a VLA

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-03
 CC||manu at gcc dot gnu.org
Summary|repetitive -Wvla warning|wrong column and repetitive
   |for each non-constant   |-Wvla warning for each
   |dimension of a VLA  |non-constant dimension of a
   ||VLA
 Ever confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Andrew Pinski from comment #1)
> I actually think three is more correct.  The issue is column for where the
> VLA is referenced is incorrect.

I think it would be ok to give just one warning per declaration, but Andrew is
right that the column is wrong and that makes them look repetitive when they
actually refer to the three dimensions.

[Bug rtl-optimization/67856] callee-saved register saves should be shrink-wrapped

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

[Bug c++/70057] duplicate integer overflow diagnostic in constant expressions

[manu at gcc dot gnu.org]

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

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to Bernd Schmidt from comment #3)
> The C++ errors become even more entertaining when you add -fpermissive:
> 
> 69972-b.cc:2:16: warning: integer overflow in expression [-Woverflow]
> 69972-b.cc:2:20: warning: overflow in constant expression [-fpermissive]
> 69972-b.cc:2:20: note: in template argument for type ‘int’ 
> 69972-b.cc: In instantiation of ‘struct S<-2147483648>’:
> 69972-b.cc:2:22:   required from here
> 69972-b.cc:1:27: warning: overflow in constant expression [-fpermissive]
> 69972-b.cc:1:27: note: in template argument for type ‘int’ 
> 69972-b.cc:1:27: warning: overflow in constant expression [-fpermissive]
> 69972-b.cc:1:27: note: in template argument for type ‘int’ 
> 69972-b.cc:1:27: warning: overflow in constant expression [-fpermissive]
> 69972-b.cc:1:27: note: in template argument for type ‘int’


The C++ FE has the tendency to give diagnostics very deep in the call stack,
where there is little knowledge of the context. It would be much better to
signal to the caller that something went wrong and let them decide what to say.
It would also probably be faster by avoiding checking error conditions multiple
times and not passing down information that is only used to provide context.

Oh, well, I guess this won't change until the GCC FEs start being used by other
GPL software that wishes to be in control of the errors (GDB compile command?
but that project seems to be dead in the water) or replaced completely by Clang
or a Clang fork like Richi proposed some time ago.

[Bug c/69972] duplicate integer overflow diagnostic in constant expressions

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Bernd Schmidt from comment #3)
> For C I'm thinking it should be straightforward to set/check TREE_NO_WARNING
> (I have an untested patch).

The duplicate warning shows that we are doing two times the same work. Wouldn't
it be better to avoid that?

> For the C++ testcase the problem is that the first one is a warning, while
> the second one is an error - we can't really omit that.

The C/C++ FEs share almost no code in this respect. It doesn't make sense to
keep both issues conflated. C++ bug is now PR70057.

[Bug c++/70057] New: duplicate integer overflow diagnostic in constant expressions

[manu at gcc dot gnu.org]

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

Bug ID: 70057
   Summary: duplicate integer overflow diagnostic in constant
expressions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manu at gcc dot gnu.org
CC: bernds at gcc dot gnu.org, mpolacek at gcc dot gnu.org,
msebor at gcc dot gnu.org, unassigned at gcc dot gnu.org
Depends on: 69972
  Target Milestone: ---

+++ This bug was initially created as a clone of Bug #69972 +++

G++ issues two similar kinds of diagnostics for the following code, one
-Woverflow and another -fpermissive:

$ cat t.c && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -S -Wall -Wextra
-Wpedantic -o/dev/null -xc++ t.c
template  struct S { };
S<(__INT_MAX__ + 1)> s;
t.c:2:16: warning: integer overflow in expression [-Woverflow]
 S<(__INT_MAX__ + 1)> s;
^~~
t.c:2:20: error: overflow in constant expression [-fpermissive]
 S<(__INT_MAX__ + 1)> s;
^
t.c:2:20: note: in template argument for type ‘int’


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69972
[Bug 69972] duplicate integer overflow diagnostic in constant expressions

[Bug libstdc++/67903] std::locale compatibility between gcc4.9 and gcc5.1

[ylow at graphlab dot com]

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

--- Comment #5 from Yucheng Low  ---
After some deep investigation on a related issue, I think might finally have a
root cause.

Introduction

 - We compile as a shared library to be imported into Python as part of a
python 
module. 
 - We want to use C++11 features yet we want to be able to run on 
relatively old Linux distributions, hence we must package our own libstdc++.
 - However, there are other Python modules which are source distributions and
 compile on the system itself hence depends on the system's existing libtsdc++.
 - Since the system will only load 1 instance of libstdc++ at a time, we can't
 merely distribute libstdc++.so. Doing so will mean whether we load correctly
 or not will depend on import ordering.
 - Therefore we must static link libstdc++ into our shared library.
 - As a result there are actually 2 instances of libstdc++ symbols loaded into 
 Python (This ought to work since Python uses RTLD_LOCAL)

Issue
-
When any other libstdc++ is loaded, our iostreams have issues. Specifically,
the former will fail with std::bad_Cast, and the latter will give nonsense.


```
boost::lexical_cast("0.01")
```

```
double d;
std::stringstream strm("0.01");
strm >> d;
```



Investigation
-
std::locale is associated with a collection of facets. 
(like std::codecvt, std::ctype, std::num_get std::num_put, etc).

Every facet has a static member, internally holds an index value initially
assigned to 0.

[facet]::id._M_id() when first called, assigns the internal index
based on an atomic incrementing integer. On subsequent calls will return the
internal index. This index represents a position into a facet array.

Key Issue
-
Now, the key issue is that all [facet]::id are a UNIQUE symbol which crosses 
RTLD_LOCAL boundaries, EXCEPT for ctype::id, codecvt::id, 
ctype::id, and codecvt::id which are WEAK.

This means that all IDs are shared across mulitple libstdc++ libraries (which
is not a problem if the number of facets do not change). 

But the 2nd loaded libstdc++ will reassign the indexes 0-3 to the 4 id's above
(since it gets its own copy of those 4 symbols). which causes the
codecvt to be assigned the same index as std::num_get, overwriting
its position in the locale, and causing the above to code to fail the dynamic
cast from std::locale::facet to std::num_get.

Solution

It might be easy to solve this problem for libstdc++'s going forward. Make all
the [facet]::id variables WEAK. 

However, that is not sufficient to solve compatibility with older versions of
libstdc++. The better solution will be to change all the symbol names
[facet]::id. However, [facet]::id is part of the C++ spec which makes
renaming it somewhat problematic.  (might be possible to use a version script
to add a version to the symbol?)

(Internal Hack)
---
To solve this in our project we change all usage of facet::id to facet::id_2.
So when installing new facets, we will look for the existance of facet::id_2
first.  This requires introducing id_2 to all the facets, and modifying
_M_install_facet and _M_replace_facet to use SFINAE to preferably select
facet::id_2 if it exists, then use facet::id otherwise.

This is a rather unhappy hack and I would like to avoid this if possible.
If anyone has a better suggestion I am all ears.

[Bug rtl-optimization/69942] gcc.dg/ifcvt-5.c FAILs

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #7 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||aarch64-linux-gnu
   ||powerpc64el-linux-gnu
  Known to work||4.8.2
   Target Milestone|--- |6.0
Summary|packed structure tree-sra   |[6 Regression] packed
   |loses initialization|structure tree-sra loses
   ||initialization

--- Comment #2 from Andrew Pinski  ---
This used to work with 4.8.2 on aarch64-linux-gnu but fails on the trunk the
same way as mentioned on powerpc64el.

[Bug c/62184] [C/C++] Extend -Wempty-body to 'while' loops

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Last reconfirmed|2014-11-12 00:00:00 |2016-3-3

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to imitrichev from comment #6)
> I think, while patching one should consider also warn on `for` loop empty
> body.

Sure, but it is always better to submit a sequence of smaller patches than one
large one. Once you get the details right for while() it should be easy to
implement for().

> It is really would be helpful to detect infinite loops caused by odd ';'
> after `for` and `while` without debugger.

It just needs someone to implement it. GCC devs are already very busy with
other things. We need as much help as we can get.

[Bug rtl-optimization/69942] gcc.dg/ifcvt-5.c FAILs

[law at gcc dot gnu.org]

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

--- Comment #6 from Jeffrey A. Law  ---
Author: law
Date: Thu Mar  3 00:11:03 2016
New Revision: 233922

URL: https://gcc.gnu.org/viewcvs?rev=233922=gcc=rev
Log:
PR rtl-optimization/69942
* gcc.dg/ifcvt-5.c: Use "word_mode" rather than "int" to limit the
effects of argument promotions.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ifcvt-5.c

[Bug c++/70056] Linker error when using variable template

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Juan Arrieta from comment #1)
> Possibly related to bug 65719.

Not only related but an exact dup as you said:
> The original code (with the unary minus) compiles and runs fine using
> clang 3.6.0 and gcc 5.2.0.

So you are reporting a bug that was already fixed in a newer maintenance
release of GCC 5 series.  GCC changed how version numbers are assigned starting
with GCC 5, please read https://gcc.gnu.org/develop.html#num_scheme about it. 
What was X.Y.Z became A.Z.0 where A increases by 1 every non-maintenance
release.

[Bug c++/65719] Link error with constexpr variable template

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||Juan.Arrieta at jpl dot 
nasa.gov

--- Comment #10 from Andrew Pinski  ---
*** Bug 70056 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/69942] gcc.dg/ifcvt-5.c FAILs

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
So the radical differences in coalescing are due to PROMOTE_MODE & friends, so
essentially they're expected.  I expect there's several other ports exhibiting
the same behavior.

[Bug c++/70056] Linker error when using variable template

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 65719.

Note 5.2.0 is the maintenance release after 5.1.0

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

[Bug c++/70056] Linker error when using variable template

[Juan.Arrieta at jpl dot nasa.gov]

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

--- Comment #1 from Juan Arrieta  ---
Possibly related to bug 65719.

[Bug c++/70056] New: Linker error when using variable template

[Juan.Arrieta at jpl dot nasa.gov]

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

Bug ID: 70056
   Summary: Linker error when using variable template
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Juan.Arrieta at jpl dot nasa.gov
  Target Milestone: ---

The following code:

template
constexpr T foo { 1.2345 };

template
T fun(T x) {
  return -foo * x;
}

int main() {
  fun(2.0);
}

compiled using gcc version 5.1.0 on Linux

g++ gcc-bug.cpp -std=c++14

fails during the linking step with the following message:

/tmp/ccuciovi.o: In function `double fun(double)':
gcc-bug.cpp:(.text._Z3funIdET_S0_[_Z3funIdET_S0_]+0xd): undefined reference
to `foo'
collect2: error: ld returned 1 exit status

Removing the unary minus (which changes the meaning of the code), gets rid of
the linking error. Prepending zero (which does not change the meaning of the
code) also gets rid of the error. In other words, the following two
implementations of `foo` lead to successful compilation:

template
T fun(T x) {
  return foo * x; // different meaning
}

template
T fun(T x) {
  return 0 - foo * x; // same meaning
}

I do not observe this behavior in other compilers. The original code (with the
unary minus) compiles and runs fine using clang 3.6.0 and gcc 5.2.0.

[Bug testsuite/70055] New: gcc.target/i386/chkp-stropt-16.c is incompatible with glibc 2.23

[hjl.tools at gmail dot com]

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

Bug ID: 70055
   Summary: gcc.target/i386/chkp-stropt-16.c is incompatible with
glibc 2.23
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ienkovich at gcc dot gnu.org
  Target Milestone: ---

 in glibc 2.23 has

#if defined __USE_GNU && defined __OPTIMIZE__ \
&& defined __extern_always_inline && __GNUC_PREREQ (3,2)
# if !defined _FORCE_INLINES && !defined _HAVE_STRING_ARCH_mempcpy

#undef mempcpy
#undef __mempcpy
#define mempcpy(dest, src, n) __mempcpy_inline (dest, src, n)
#define __mempcpy(dest, src, n) __mempcpy_inline (dest, src, n)

__extern_always_inline void *
__mempcpy_inline (void *__restrict __dest,
  const void *__restrict __src, size_t __n)
{
  return (char *) memcpy (__dest, __src, __n) + __n;
}

# endif
#endif

gcc.target/i386/chkp-stropt-16.c, gcc.target/i386/chkp-stropt-4.c and
gcc.target/i386/chkp-stropt-8.c have

#define _GNU_SOURCE
#include "string.h"

void test (int *buf1, int *buf2, size_t len)
{
  mempcpy (buf1, buf2, len);
}

But GCC never sees mempcpy at all.

[Bug rtl-optimization/69942] gcc.dg/ifcvt-5.c FAILs

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-02
 CC||law at redhat dot com
 Ever confirmed|0   |1

--- Comment #4 from Jeffrey A. Law  ---
I'm not sure I follow the logic in c#2.

As we leave the tree optimizers, we have this in the .optimized dump:

 :
  if (x_3(D) > y_4(D))
goto ;
  else
goto ;

  :

  :
  # i_1 = PHI 
  # j_2 = PHI 
  _6 = i_1 * j_2;
  return _6;


Which is basically what I'd expect and is consistent with x86-64.

What's awful strange is how the sparc & x86-64 differ in how they coalesce (or
fail to).  That ultimately leads to changes in the initial code generation and
changes in what CE1 does.

Before changing the expected output of .ce1 I think we should look more closely
at the coalescing differences between x86-64 and sparc.




The difference is on the sparc, we don't see a conflict between i_1/a_5 and
j_2/a_5.  The lack of conflicts changes coalescing and we end up with different
code at expansion time.  That ultimately leads to a change in the code seen by
CE and the differences in behavior.

But I think we should look more closely at coalescing before jumping to
changing the expected output from .ce1.

[Bug libffi/70024] [5/6 Regression] libffi ABI change w/o SONAME bump

[rth at gcc dot gnu.org]

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

--- Comment #5 from Richard Henderson  ---
Author: rth
Date: Wed Mar  2 23:28:11 2016
New Revision: 233921

URL: https://gcc.gnu.org/viewcvs?rev=233921=gcc=rev
Log:
PR libffi/70024

  * Makefile.am (libffi_version_script): New.
  (libffi_version_dep): New.
  (libffi_version_info): New.
  (libffi_la_LDFLAGS): Include libffi_version_info, libffi_version_script.
  (libffi_la_DEPENDENCIES): Include libffi_version_dep.
  * acinclude.m4 (LIBAT_ENABLE, LIBAT_CHECK_LINKER_FEATURES): New.
  (LIBAT_ENABLE_SYMVERS, LIBAT_BUILD_VERSIONED_SHLIB): New.
  (LIBAT_BUILD_VERSIONED_SHLIB_GNU): New.
  (LIBAT_BUILD_VERSIONED_SHLIB_SUN): New.
  * configure.ac: Invoke LIBAT_ENABLE_SYMVERS.
  * libffi.map: New file.
  * libtool-version: Increase to 5.0.0.
  * Makefile.in, configure: Rebuild.
  * man/Makefile.in, testsuite/Makefile.in: Rebuild.

Added:
trunk/libffi/libffi.map
Modified:
trunk/libffi/ChangeLog
trunk/libffi/Makefile.am
trunk/libffi/Makefile.in
trunk/libffi/acinclude.m4
trunk/libffi/configure
trunk/libffi/configure.ac
trunk/libffi/include/Makefile.in
trunk/libffi/libtool-version
trunk/libffi/man/Makefile.in
trunk/libffi/testsuite/Makefile.in

[Bug libffi/70024] [5/6 Regression] libffi ABI change w/o SONAME bump

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rth at gcc dot gnu.org

[Bug middle-end/68621] [6 Regression] FAIL: gcc.dg/tree-ssa/ifc-8.c scan-tree-dump-times ifcvt "Applying if-conversion" 1

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #7 from Jeffrey A. Law  ---
Resolved by commit on trunk.

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

[seurer at linux dot vnet.ibm.com]

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

--- Comment #83 from Bill Seurer  ---
I tried that patch and the 416.gamess test still fails on power.

[Bug middle-end/70054] New: GCC 6 gives a strict-aliasing warning on use of std::aligned_storage

[tavianator at gmail dot com]

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

Bug ID: 70054
   Summary: GCC 6 gives a strict-aliasing warning on use of
std::aligned_storage
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tavianator at gmail dot com
  Target Milestone: ---

GCC 6 warns on this code; GCC 5 didn't.

boost::container::string uses this pattern as part of its SSO implementation,
so I'm getting a lot of new warnings with GCC 6 as a result.  As well, I'm
seeing what appears to be a miscompilation as a result, but I haven't reduced
that yet.

$ cat foo.cpp
#include 

struct foo {
  std::aligned_storage::type raw;

  long& cooked() {
return *static_cast(static_cast());
  }
};
$ g++ -O2 -Wall -c foo.cpp
foo.cpp: In member function ‘long int& foo::cooked()’:
foo.cpp:7:56: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
 return *static_cast(static_cast());

[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Related to bug 30271, bug 38532, bug 69493.  There might be more bugs too.

[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
One interesting point is if we delete the "return result;" that is within the
then clause and fall thru to the end "return result;" with is logically
identical, then we get the code we want:

D256_add_finite:
dcmpuq 7,4,6
bnelr 7
fmr 5,7
fmr 4,6
fmr 3,7
fmr 2,6
blr

[Bug target/70053] Returning a struct of _Decimal128 values generates extraneous stores and loads

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Target||powerpc64le-linux
 CC||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||munroesj at us dot ibm.com,
   ||wschmidt at gcc dot gnu.org
  Known to fail||4.9.4, 5.3.1

--- Comment #1 from Peter Bergner  ---
A quick check seems to show this happens on older compiler versions too.

[Bug tree-optimization/70013] packed structure tree-sra loses initialization

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

--- Comment #1 from David Edelsohn  ---
New.

[Bug target/70053] New: Returning a struct of _Decimal128 values generates extraneous stores and loads

[bergner at gcc dot gnu.org]

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

Bug ID: 70053
   Summary: Returning a struct of _Decimal128 values generates
extraneous stores and loads
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

If we compile the following testcase, we see uneeded stores to the stack
followed by immediate loads from the same stack slots just before the return. 
One set of stores/loads is completely unneeded and the others can be replaced
by simple fmrs.

bergner@genoa:~/gcc/BUGS/DFP/arith128-P8AT9/src$ cat t.i 
typedef struct
{
  _Decimal128 td0;
  _Decimal128 td1;
} TDx2_t;


TDx2_t
D256_add_finite (_Decimal128 a, _Decimal128 b, _Decimal128 c)
{
  TDx2_t result;

  result.td0 = a;
  result.td1 = b;

  if (b == c)
  {
result.td0 = c;
result.td1 = c;
return result;
  }

  return result;
}

bergner@genoa:~/gcc/BUGS/DFP/$
/home/bergner/gcc/build/gcc-fsf-mainline-base-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-base-debug/gcc -O2 -mcpu=power8 -S
t.i 
bergner@genoa:~/gcc/BUGS/DFP/$ cat t.s 
.file   "t.i"
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl D256_add_finite
.type   D256_add_finite, @function
D256_add_finite:
dcmpuq 7,4,6
beq 7,.L5
stfd 3,-64(1)
stfd 2,-56(1)
stfd 5,-48(1)
stfd 4,-40(1)
ori 2,2,0
lfd 3,-64(1)
lfd 2,-56(1)
lfd 5,-48(1)
lfd 4,-40(1)
blr
.p2align 4,,15
.L5:
stfd 7,-64(1)
stfd 6,-56(1)
stfd 7,-48(1)
stfd 6,-40(1)
ori 2,2,0
lfd 3,-64(1)
lfd 2,-56(1)
lfd 5,-48(1)
lfd 4,-40(1)
blr

[Bug tree-optimization/69196] [5/6 Regression] code size regression with jump threading at -O2

[law at redhat dot com]

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

--- Comment #17 from Jeffrey A. Law  ---
I've fixed the ChangeLog entry.  It's safe to assume I added the -1 to the
testsuite name because I suspect there's going to be more tests around this BZ
in the future :-)

I may end up restricting the test to the known affected targets (ppc, sparc). 
But I'm going to want to look at the dumps from s390 and arm before doing so.

Thanks Dominik!

[Bug target/70052] New: ICE compiling _Decimal128 test case

[bergner at gcc dot gnu.org]

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

Bug ID: 70052
   Summary: ICE compiling _Decimal128 test case
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

We ICE with the following test case.

bergner@genoa:~/gcc/BUGS/DFP/arith128-P8AT9/src$ cat ice.i 
typedef struct
{
  _Decimal128 td0;
  _Decimal128 td1;
} TDx2_t;


TDx2_t
D256_add_finite (void)
{
  _Decimal128 z, zz;
  TDx2_t result = {0.DL, 0.DL};

  if (zz == 0.DL)
  {
result.td0 = z;
return result;
  }

  return result;
}

bergner@genoa:~/gcc/BUGS/DFP/$
/home/bergner/gcc/build/gcc-fsf-mainline-base-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-base-debug/gcc -O2 -mcpu=power8 -S
ice.i 
ice.i: In function ‘D256_add_finite’:
ice.i:21:1: error: unrecognizable insn:
 }
 ^
(insn 110 19 111 3 (set (reg:DD 33 1)
(const_double:DD 0E-398 [N/A])) ice.i:17 -1
 (nil))
ice.i:21:1: internal compiler error: in extract_insn, at recog.c:2287
0x10c0b3d7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/rtl-error.c:108
0x10c0b44f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/rtl-error.c:116
0x10b8f313 extract_insn(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/recog.c:2287
0x10b8eddf extract_insn_cached(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/recog.c:2178
0x10712067 cleanup_subreg_operands(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/final.c:3104
0x10b916b7 split_insn
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/recog.c:2901
0x10b918a7 split_all_insns()
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/recog.c:2955
0x10b94973 rest_of_handle_split_after_reload
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/recog.c:3891
0x10b94a33 execute
/home/bergner/gcc/gcc-fsf-mainline-base/gcc/recog.c:3920
Please submit a full bug report,

[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #18 from Jeffrey A. Law  ---
Thanks Alexander.  It looks like Richard and Segher have agreed on a fix for
gcc-6 (and it's been installed) and deferred the wider-scoped change for gcc-7.

[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[afomin at gcc dot gnu.org]

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

afomin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||afomin at gcc dot gnu.org

--- Comment #17 from afomin at gcc dot gnu.org ---
This regression caused performance loss on EEMBC DEN djpeg* benchmark up to 6%.
But it affects only i686, not x86_64.

[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[rth at gcc dot gnu.org]

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

--- Comment #16 from Richard Henderson  ---
Author: rth
Date: Wed Mar  2 21:09:54 2016
New Revision: 233916

URL: https://gcc.gnu.org/viewcvs?rev=233916=gcc=rev
Log:
PR rtl-opt/67145

  * simplify-rtx.c (simplify_plus_minus): Allow reassoc without
  simplification when all args are positive non-fixed registers.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c

[Bug libstdc++/69879] Create a pointer to the default operator new and delete

[gabriel.ibarra at tallertechnologies dot com]

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

Gabriel Ibarra  changed:

   What|Removed |Added

 CC||gabriel.ibarra@tallertechno
   ||logies.com

--- Comment #2 from Gabriel Ibarra  ---
Created attachment 37848
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37848=edit
[RFC] Added default functions for new and delete operators.

Hello, I was working this issue

I created a default function for each of the next operators:

 - void* operator new(std::size_t) _GLIBCXX_THROW (std::bad_alloc)
 - void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
 - void operator delete(void*) _GLIBCXX_USE_NOEXCEPT
 - void operator delete[](void*) _GLIBCXX_USE_NOEXCEPT
 - void operator delete(void*, std::size_t) _GLIBCXX_USE_NOEXCEPT
 - void operator delete[](void*, std::size_t) _GLIBCXX_USE_NOEXCEPT
 - void* operator new(std::size_t, const std::nothrow_t&) _GLIBCXX_USE_NOEXCEPT
 - void* operator new[](std::size_t, const std::nothrow_t&)
_GLIBCXX_USE_NOEXCEPT
 - void operator delete(void*, const std::nothrow_t&) _GLIBCXX_USE_NOEXCEPT
 - void operator delete[](void*, const std::nothrow_t&) _GLIBCXX_USE_NOEXCEPT

I had to add the new functions in the gnu.ver in order to be acceded from the
application. They were added in the GLIBCXX_3.4.22 section, is it the right
place?

(tests will be added later)

[Bug c++/69687] Buffer Overflow in libiberty

[manu at gcc dot gnu.org]

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

--- Comment #11 from Manuel López-Ibáñez  ---
The policy of GNU software is to avoid arbitrary implementation limits whenever
possible.

(In reply to Marcel Böhme from comment #4)
> with n=2*(length of decl + length of arg) characters. Since n is a signed
> int, n wraps over at some iteration. Since, realloc expects n to be
> unsigned, we end up allocating less memory then actually needed. In the

Why n is signed if realloc expects it to be unsigned? Aren't the lengths
measured in size_t also? Moreover, it should be trivial to check for overflow
before computing n (both from the sum and from *2) by using SIZE_MAX. It should
fail only if any intermediate step overflows size_t.

[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.

[amker at gcc dot gnu.org]

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

--- Comment #16 from amker at gcc dot gnu.org ---
(In reply to amker from comment #14)
> Author: amker
> Date: Wed Mar  2 14:10:56 2016
> New Revision: 233907
> 
> URL: https://gcc.gnu.org/viewcvs?rev=233907=gcc=rev
> Log:
> 
>   PR tree-optimization/69052
>   * loop-invariant.c (canonicalize_address): New function.
>   (inv_can_prop_to_addr_use): Check validity of address expression
>   which is canonicalized by above function.
> 
>   gcc/testsuite/ChangeLog
>   PR tree-optimization/69052
>   * gcc.target/i386/pr69052.c: New test.
> 
> 
> Added:
> trunk/gcc/testsuite/gcc.target/i386/pr69052.c
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/loop-invariant.c
> trunk/gcc/testsuite/ChangeLog

Just realized that CONST_INT and CONST_WIDE_INT both have the same precedence. 
The patch I applied could be broken in cases which have both CONST_INT and
CONST_WIDE_INT address parts and the CONST_WIDE_INT one happens to be sorted
after CONST_INT, as below code:

  /* Simplify all constant int summary if possible.  */
  for (i = 0; i < addr_parts.length (); i++)
if (CONST_INT_P (addr_parts[i]))
  break;

  for (j = i + 1; j < addr_parts.length (); j++)
{
  gcc_assert (CONST_INT_P (addr_parts[j]));  <-assertion failure
  addr_parts[i] = simplify_gen_binary (PLUS, mode,
   addr_parts[i],
   addr_parts[j]);
}

Although I don't think we can really run into such complicated address
expression, I will work out a patch to compare_address_parts to force CONST_INT
after CONST_WIDE_INT during sorting.

[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #15 from Jeffrey A. Law  ---
Fixed by Bin's patch on the trunk.

[Bug sanitizer/70051] New: ubsan doesn't detect VLA overflow

[msebor at gcc dot gnu.org]

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

Bug ID: 70051
   Summary: ubsan doesn't detect VLA overflow
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

The undefined behavior sanitizer tries to detect some simple invalid uses of
VLAs (negative bounds, AFAICS) but misses overflow/wraparound in the unsigned
bounds.  For example, the test case below crashes (or aborts when the memset
loop is removed), when one would expect or hope to have the sanitizer
instrumentation to detect this.

$ cat z.c && /home/msebor/build/gcc-trunk-svn/gcc/xg++
-B/home/msebor/build/gcc-trunk-svn/gcc  -L
/home/msebor/build/gcc-trunk-svn/stage3-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L
/home/msebor/build/gcc-trunk-svn/stage3-x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs
-O2 -Wall -Wextra -Wpedantic -fsanitize=undefined -xc++ z.c &&
LD_LIBRARY_PATH=/home/msebor/build/gcc-trunk-svn/stage3-x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs
./a.out 
typedef __SIZE_TYPE__ size_t;

void __attribute__ ((noclone, noinline))
foo (void *p) { }

void __attribute__ ((noclone, noinline))
bar (size_t m, size_t n)
{
int a [m][n];
for (size_t i = 0; i != m; ++i)
__builtin_memset (a [i], 0, n * sizeof (int));
foo (a);
}

#define M (__SIZE_MAX__ / 1024)
#define N (__SIZE_MAX__ / 1024)

int main (void)
{
#if __cplusplus
try {
bar (M, N);
__builtin_abort ();
}
catch (...) {
}
#else
bar (M, N);
#endif
}

z.c: In function ‘void foo(void*)’:
z.c:4:12: warning: unused parameter ‘p’ [-Wunused-parameter]
 foo (void *p) { }
^
z.c: In function ‘void bar(size_t, size_t)’:
z.c:9:16: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
 int a [m][n];
^
z.c:9:16: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
Bus error (core dumped)

[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[segher at gcc dot gnu.org]

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

--- Comment #15 from Segher Boessenkool  ---
Thanks Richard, that is a much safer solution for now.

FWIW, your original patch regressed at least code generation for
0xULL - a  on powerpc (-m32), and various other
things change (although the end result is the same for trivial
testcases).

It's not just rs6000 btw, at least the sh backend has the same
issues.

[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law  ---
Alexander,


Can you comment on how serious this regression is for whatever benchmark your
test was derived from?

Can you also indicate whether or not similar issues have been seen with x86_64
(the report mentions -m32, but it's not clear to me if the issue also affects
x86_64)

Those tidbits of information would help everyone balance the difficult choice
we have here.

[Bug target/30417] Section .data cannot be moved with -mmcu=atmega88

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #6 from Georg-Johann Lay  ---
As of GCC 5 this should be no issue any more:  The new device specs might
specify -Tdata e.g. specs-atmega88 reads

*link_data_start:
-Tdata 0x800100

The file is located in $prefix/lib/gcc/avr/$version/device-specs/ provided
default paths are used with configure.  Cf. also the relevant release notes. 
Hence you could

-- Drop that -Tdata from the device specs and specify appropriate -Tdata on the
command line.

-- Provide custom specs file derived from the one above.

Sounds strange that bootloader and application are managed that way.  Ususally,
after the bootloader has finished, its memory is no more needed and will be
cleaned up by the application's start-up code and used by the application
without any conflicts.

[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[rth at gcc dot gnu.org]

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

--- Comment #13 from Richard Henderson  ---
I can clean up the rs6000 some more to avoid some objections
that Segher raised -- by-hand rtl generation etc.

Or, I've just about finished testing the simplify-rtx-only
patch suggested in

  https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01858.html

So, that at least is a working option to fix the x86 regression
without touching the rs6000 backend during stage4.

[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Hopefully fixed now.

[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar  2 19:16:14 2016
New Revision: 233913

URL: https://gcc.gnu.org/viewcvs?rev=233913=gcc=rev
Log:
PR libgomp/69555
* gimplify.c (gimplify_decl_expr): For decls with REFERENCE_TYPE, also
gimplify_type_sizes the type they refer to.
(omp_notice_variable): Handle reference vars to VLAs.
* omp-low.c (lower_omp_target): Emit setup of OMP_CLAUSE_PRIVATE
reference
to VLA decls in the second pass instead of first pass.

* testsuite/libgomp.c++/pr69555-1.C: New test.
* testsuite/libgomp.c++/pr69555-2.C: New test.

Added:
trunk/libgomp/testsuite/libgomp.c++/pr69555-1.C
trunk/libgomp/testsuite/libgomp.c++/pr69555-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/omp-low.c
trunk/libgomp/ChangeLog

[Bug rtl-optimization/70023] [4.9/5/6 Regression] ICE: in assign_by_spills, at lra-assigns.c:1417 with -fno-sched-critical-path-heuristic -fschedule-insns -m8bit-idiv

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
In the past we've not supported the first instruction scheduling pass on the
x86 because of the problems with extension of hard register lifetimes.

Is that still the case?  If so, what's the mechanism by which that happens
these days (I didn't see if with some quick scanning).

[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
I'm with rth here, I think we should apply his patch.

[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com,
   ||rguenth at gcc dot gnu.org

--- Comment #11 from Jeffrey A. Law  ---
So does anyone agree with Segher's assessment here:

https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg133974.html

Essentially that this is a minor regression and that the rs6000 backend changes
necessary to fix the regression are too risky for stage4?

In which case we should consider downgrading to P2.

Thoughts?

[Bug middle-end/69987] [6 Regression] internal compiler error: in verify_loop_structure, at cfgloop.c:1639

[law at gcc dot gnu.org]

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

--- Comment #6 from Jeffrey A. Law  ---
Author: law
Date: Wed Mar  2 18:45:26 2016
New Revision: 233912

URL: https://gcc.gnu.org/viewcvs?rev=233912=gcc=rev
Log:
PR tree-optimization/69987
* gfortran.dg/pr69987.f90: Use "-w" to avoid failures when the
target does not support -fprefetch-loop-arrays.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr69987.f90

[Bug target/70008] [ARM] Reverse subtract with carry can be generated in thumb2 mode

[michael.collison at linaro dot org]

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

--- Comment #2 from Michael Collison  ---
Richard,

As discussed upstream you are correct.

[Bug c++/69694] type incomplete depending if constructing function is templated

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

[Bug middle-end/70050] [6 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have vector_type in generic_simplify_162, at generic-mat

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug middle-end/70050] [6 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have vector_type in generic_simplify_162, at generic-mat

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
LGTM.

[Bug tree-optimization/70046] [6 Regression] 410.bwaves regression on Haswell

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
I checked "-Ofast -march=native/-march=haswell" for GCC@230647 on Xeon, there
is no regression.  I also checked "-Ofast -mtune=core-avx2" for GCC@230689,
there is no regression either.
I looked into the generated assembly and the hot loops (the innermost two) is
actually improved by the change with these options.

So do I need some other options?  Or it's a u-arch hazard that doesn't exist on
Xeon?

Thanks.

[Bug middle-end/70050] [6 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have vector_type in generic_simplify_162, at generic-mat

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Maybe missing INTEGRAL_TYPE_P (type)
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -293,7 +293,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
 /* X % -Y is the same as X % Y.  */
 (simplify
  (trunc_mod @0 (convert? (negate @1)))
- (if (!TYPE_UNSIGNED (type)
+ (if (INTEGRAL_TYPE_P (type)
+  && !TYPE_UNSIGNED (type)
   && !TYPE_OVERFLOW_TRAPS (type)
   && tree_nop_conversion_p (type, TREE_TYPE (@1))
   /* Avoid this transformation if X might be INT_MIN or

[Bug c++/70035] [5/6 Regression] Calling a non-virtual member in base-class constructor call with ubsan causes segfault when superclass has virtual member with same name

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The call to a member function before all base classes are initialized is
undefined behaviour:

12.6.2 [class.base.init] p16

  Member functions (including virtual member functions, 10.3) can be called for
  an object under construction.[...] However, if these operations are performed
  in a ctor-initializer (or in a function called directly or indirectly from a
  ctor-initializer) before all the mem-initializers for base classes have
  completed, the result of the operation is undefined.

There is a very similar example below that paragraph.

[Bug target/70049] [6 Regression] Error: operand size mismatch for `vpextrw' (wrong assembly generated) with -masm=intel

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 37847
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37847=edit
gcc6-pr70049.patch

Untested fix.

[Bug middle-end/70050] [6 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have vector_type in generic_simplify_162, at generic-mat

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r232188.

[Bug middle-end/70050] [6 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have vector_type in generic_simplify_162, at generic-mat

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-02
 CC||ktkachov at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug middle-end/70050] New: [6 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have vector_type in generic_simplify_162, at generi

[zsojka at seznam dot cz]

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

Bug ID: 70050
   Summary: [6 Regression] ICE: tree check: expected integer_type
or enumeral_type or boolean_type or real_type or
fixed_point_type, have vector_type in
generic_simplify_162, at generic-match.c:6175
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 37846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37846=edit
reduced testcase

Compiler output:
$ gcc testcase.c testcase.c: In function 'foo':
testcase.c:5:1: warning: AVX vector return without AVX enabled changes the ABI
[-Wpsabi]
 {
 ^
testcase.c:6:3: internal compiler error: tree check: expected integer_type or
enumeral_type or boolean_type or real_type or fixed_point_type, have
vector_type in generic_simplify_162, at generic-match.c:6175
   return v %= -v;
   ^~
0xe4a36c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/repo/gcc-trunk/gcc/tree.c:9637
0x10047a7 tree_check5
/repo/gcc-trunk/gcc/tree.h:3097
0x10047a7 generic_simplify_162
   
/repo/build-trunk-233861-checking-yes-rtl-df-nographite-i686/gcc/generic-match.c:6175
0x1006045 generic_simplify_TRUNC_MOD_EXPR
   
/repo/build-trunk-233861-checking-yes-rtl-df-nographite-i686/gcc/generic-match.c:19020
0x1006045 generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
   
/repo/build-trunk-233861-checking-yes-rtl-df-nographite-i686/gcc/generic-match.c:25932
0x86b89e fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/repo/gcc-trunk/gcc/fold-const.c:9257
0x88c03b fold(tree_node*)
/repo/gcc-trunk/gcc/fold-const.c:12113
0x647360 c_fully_fold_internal
/repo/gcc-trunk/gcc/c/c-fold.c:307
0x647e5b c_fully_fold(tree_node*, bool, bool*)
/repo/gcc-trunk/gcc/c/c-fold.c:90
0x607e4a build_modify_expr(unsigned int, tree_node*, tree_node*, tree_code,
unsigned int, tree_node*, tree_node*)
/repo/gcc-trunk/gcc/c/c-typeck.c:5681
0x6183c6 c_parser_expr_no_commas
/repo/gcc-trunk/gcc/c/c-parser.c:6263
0x6189e2 c_parser_expression
/repo/gcc-trunk/gcc/c/c-parser.c:8401
0x619449 c_parser_expression_conv
/repo/gcc-trunk/gcc/c/c-parser.c:8434
0x62f868 c_parser_statement_after_labels
/repo/gcc-trunk/gcc/c/c-parser.c:5201
0x6314e9 c_parser_compound_statement_nostart
/repo/gcc-trunk/gcc/c/c-parser.c:4856
0x631d7e c_parser_compound_statement
/repo/gcc-trunk/gcc/c/c-parser.c:4692
0x632fa7 c_parser_declaration_or_fndef
/repo/gcc-trunk/gcc/c/c-parser.c:2104
0x63c085 c_parser_external_declaration
/repo/gcc-trunk/gcc/c/c-parser.c:1548
0x63c919 c_parser_translation_unit
/repo/gcc-trunk/gcc/c/c-parser.c:1429
0x63c919 c_parse_file()
/repo/gcc-trunk/gcc/c/c-parser.c:17840
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


All tested targets seem to be affected (arm, x86, powerpc, sparc; 32bit,
64bit).

Tested revisions:
trunk r233897 - FAIL
trunk r233861 - FAIL
5-branch r233800 - OK

[Bug c++/70018] [4.9/5/6 Regression] Possible issue around IPO and C++ comdats discovered as pure/const

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #9 from Jan Hubicka  ---
To properly track possible loads/stores w/o any optimizations we probably need
an info from Frontend, because we optimize out things prior gimplification.
Jason, how feasible it is to do that?

For pure/const a workaround is -fno-ipa-pure-const. The bug also affects
nothrow at least with -fnoncall-exceptions and nothrow discovery is not
controled by a flag.

Fixing this correctly will need bit of work, because we really want to track
nothrow/pure/const for the inline functions and make us of it when we know the
call bids to current def. This can change during the optimization queue, so we
probably want two sets of these flags.

[Bug target/70049] [6 Regression] Error: operand size mismatch for `vpextrw' (wrong assembly generated) with -masm=intel

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Testcase adjusted for testsuite purposes:
/* PR target/70049 */
/* { dg-do assemble { target avx } } */
/* { dg-require-effective-target masm_intel } */
/* { dg-options "-Og -mavx -masm=intel" } */

typedef unsigned short A;
typedef unsigned short B __attribute__ ((vector_size (32)));
typedef unsigned int C;
typedef unsigned int D __attribute__ ((vector_size (32)));
typedef unsigned long long E;
typedef unsigned long long F __attribute__ ((vector_size (32)));

C
foo(A a, C b, E c, F d, B e, D f, F g)
{
  b <<= 28;
  e[1] += b;
  d %= (F){0, f[4]} | 1;
  return a + b + c + d[3] + e[1] + g[3];
}

[Bug target/69685] GCC cross compiler build failed

[gjl at gcc dot gnu.org]

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

--- Comment #4 from Georg-Johann Lay  ---
FYI, as you are using Newlib (and not avr-libc as all the folks does) you want
to configure with --with-avrlibc=no.

[Bug target/69685] GCC cross compiler build failed

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #3 from Georg-Johann Lay  ---
(In reply to Pieter Cardoen from comment #2)
> How do you mean: appending -v? The only command I execute is: 

Above, you pasted a call of xgcc.  Add -v -save-temps to that command and
execute it from the right directory.  Usually make prints the directory where
it stops execution due to some tool error; this will be some libgcc multilib
directory.  The -save-temps gives you a preprocessed input file fixed-bit.i
(provided it's not the preprocessor that hangs).

[Bug c/62184] [C/C++] Extend -Wempty-body to 'while' loops

[imitrichev at muctr dot ru]

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

imitrichev  changed:

   What|Removed |Added

 CC||imitrichev at muctr dot ru

--- Comment #6 from imitrichev  ---
I think, while patching one should consider also warn on `for` loop empty body.

Whilst we can write something like

int i=0;
for (; i<5; a[i]=10, i++);

it is assumed to be not a great programming style.

int main()
{
for (; 1<2; );
if (1==1);
while (1==1);
return 0;
}

Now it warns only on `if` loop:

g++ empty.cpp -Wempty-body -o empty.out

empty.cpp: In function "int main()":
empty.cpp:4:10: warning: suggest braces around empty body in an «if» statement
[-Wempty-body]

It is really would be helpful to detect infinite loops caused by odd ';' after
`for` and `while` without debugger.

[Bug c++/69481] ICE with C++11 alias using with templates

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Started with r181118 aka PR c++/45114 - Support C++11 alias-declaration.

[Bug target/70021] [6 Regression] Test miscompiled with -O3 option for -march=core-avx2.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #37834|0   |1
is obsolete||
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Created attachment 37845
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37845=edit
gcc6-pr70021.patch

Fix that passed bootstrap/regtest on x86_64-linux and i686-linux.  I'm now
testing it on powerpc64{,le}, s390{,x}, aarch64 and armv7hl too, to make sure
it doesn't break anything there either.

[Bug target/70049] New: [6 Regression] Error: operand size mismatch for `vpextrw' (wrong assembly generated) with -masm=intel

[zsojka at seznam dot cz]

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

Bug ID: 70049
   Summary: [6 Regression] Error: operand size mismatch for
`vpextrw' (wrong assembly generated) with -masm=intel
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
Target: i686-pc-linux-gnu

Created attachment 37844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37844=edit
reduced testcase

Output:
$ i686-pc-linux-gnu-gcc -Og -march=ivybridge -masm=intel testcase.c
/tmp/ccVYtsb4.s: Assembler messages:
/tmp/ccVYtsb4.s:29: Error: operand size mismatch for `vpextrw'

@@ -26,7 +26,7 @@
vmovdqa ymm4, ymm0
mov ebp, DWORD PTR [esp+164]
sal ebp, 28
-   vpextrw DWORD PTR [esp+118], xmm1, 1
+   vpextrw WORD PTR [esp+118], xmm1, 1
vextractf128xmm2, ymm2, 0x1
vmovd   DWORD PTR [esp], xmm2
mov DWORD PTR [esp+4], 0

fixes the assembly.
This particular testcase fails only in trunk, but other branches might be
affected as well.

[Bug c/68187] [6 Regression] Poor error message from -Wmisleading-indentation on glibc's ../stdlib/strtol_l.c

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

[Bug c++/70035] [5/6 Regression] Calling a non-virtual member in base-class constructor call with ubsan causes segfault when superclass has virtual member with same name

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Seems to be caused by -fsanitize=vptr.

[Bug tree-optimization/70045] [6 Regression] ICE error: mismatching comparison operand types

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug c++/68087] [5/6 Regression] ICE with constexpr in array with negative index

[clyon at gcc dot gnu.org]

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

--- Comment #11 from Christophe Lyon  ---
gcc-5-branch fixed by r233903.

[Bug c/69960] "initializer element is not constant"

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Martin said almost exactly what I was going to say :-)

Compilers are allowed to accept this, as Clang does, but they are not required
to.

[Bug c/69972] duplicate integer overflow diagnostic in constant expressions

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #3 from Bernd Schmidt  ---
For C I'm thinking it should be straightforward to set/check TREE_NO_WARNING (I
have an untested patch).

For the C++ testcase the problem is that the first one is a warning, while the
second one is an error - we can't really omit that.

The C++ errors become even more entertaining when you add -fpermissive:

69972-b.cc:2:16: warning: integer overflow in expression [-Woverflow]
69972-b.cc:2:20: warning: overflow in constant expression [-fpermissive]
69972-b.cc:2:20: note: in template argument for type ‘int’ 
69972-b.cc: In instantiation of ‘struct S<-2147483648>’:
69972-b.cc:2:22:   required from here
69972-b.cc:1:27: warning: overflow in constant expression [-fpermissive]
69972-b.cc:1:27: note: in template argument for type ‘int’ 
69972-b.cc:1:27: warning: overflow in constant expression [-fpermissive]
69972-b.cc:1:27: note: in template argument for type ‘int’ 
69972-b.cc:1:27: warning: overflow in constant expression [-fpermissive]
69972-b.cc:1:27: note: in template argument for type ‘int’

[Bug c/69960] "initializer element is not constant"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #9 from Martin Sebor  ---
I also agree that accepting it would be a useful extension (perhaps when
diagnosed in pedantic mode to aid portability since other compilers reject it).

As to where C11 rules it out, I believe it's in 6.6 which says that "constant
expressions in initializers ... shall be, or evaluate to, one of the following:

-- an /arithmetic constant expression/,
-- a null pointer constant,
-- an address constant, or
-- an address constant for a complete object type plus or minus an integer
constant expression."

An /arithmetic constant expression/ shall have arithmetic type and shall only
have operands that are integer constants, floating constants, enumeration
constants, character constants, sizeof expressions whose results are integer
constants, and _Alignof expressions.

"f"[0] is none of the above expressions.

C also says that "An implementation may accept other forms of constant
expressions" so accepting it wouldn't be out of line with the requirements.

[Bug c++/70029] [6 Regression] ICE with C++11 and -flto

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
In other words, build_ref_qualified_type creates method_type T with
TYPE_CANONICAL (t) = t;
but
TYPE_MAIN_VARIANT (t) is not t (it differs because the main variant doesn't
have FUNCTION_RVALUE_QUALIFIED and FUNCTION_REF_QUALIFIED  flags set and has a
different canonical type).
Using build_distinct_type_copy instead of build_variant_type_copy fixes the ICE
but causes another ICEs, so that is wrong, but I don't know what to do with
this.

[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing

[wdijkstr at arm dot com]

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

--- Comment #5 from Wilco  ---
(In reply to amker from comment #4)
> (In reply to ktkachov from comment #3)
> > Started with r233136.
> 
> That's why I forced base+offset out of memory reference and kept register
> scaling in in the first place.  I think my statement still holds, that
> GIMPLE optimizers should be improved to CSE register scaling expression
> among different memory references, then force base(sp)+offset parts out of
> memory reference in legitimize_address so that it can be merged.  I suspect
> this case is going to be very inefficient in loop context.  Unfortunately
> GIMPLE optimizers are weak now and r233136 is a workaround to it.  I want to
> revisit slsr sometime after stage4 to fix this issue.

The issue is that the new version splits immediates from virtual stack
variables, this is what GCC used to generate:

(insn 8 7 9 2 (set (reg:DI 82)
(plus:DI (reg/f:DI 68 virtual-stack-vars)
(const_int -4000 [0xf060]))) addroff.c:38 -1

However latest GCC does:

(insn 9 8 10 2 (set (reg:DI 84)
(plus:DI (reg/f:DI 68 virtual-stack-vars)
(reg:DI 83))) addroff.c:38 -1
 (nil))
(insn 10 9 11 2 (set (reg:DI 85)
(plus:DI (reg:DI 84)
(const_int -4096 [0xf000]))) addroff.c:38 -1
 (nil))

So we need to recoginize virtual-stack-vars+offset as a special case rather
than like any other add with immediate.

[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
I find it strange that we do all operations on masks and not on "booleans" for
vectors.

typedef int T;
T f(T a,T b,T c,T d){
  return (a;
  _6 = VEC_COND_EXPR ;
  _7 = _3 & _6;
  return _7;

yielding this code:

vpcmpgtd%zmm0, %zmm1, %k1
vpternlogd  $0xFF, %zmm4, %zmm4, %zmm4
vmovdqa32   %zmm4, %zmm0{%k1}{z}
vpcmpgtd%zmm2, %zmm3, %k1
vmovdqa32   %zmm4, %zmm2{%k1}{z}
vpandd  %zmm2, %zmm0, %zmm0

We perform the bit_and on the mask type, whereas it would be better to do it on
the boolean type and use 'kandw'. For most platforms, (vec_cnd x -1 0) should
be a NOP so it doesn't really matter, and for the few remaining (AVX512 and
Sparc IIRC) we want to use "booleans" as much as possible and only convert to a
mask late. I think that implies that we should pull operations on masks into
operations on booleans (as in the original patch in comment #1 maybe, plus
canonicalizing (vec_cnd x 0 -1)), and probably that forwarding conditions into
the first argument of vec_cond should only be done late (around expand).

But it is quite possible that my intuition is completely bogus here.

[Bug tree-optimization/55936] [4.9/5/6 Regression] Missed VRP optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Created attachment 37843
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37843=edit
patch

So I am testing the following.

[Bug tree-optimization/55936] [4.9/5/6 Regression] Missed VRP optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
The main issue is that the PHI merging i and i = baz () has both edges
executable.

Visiting statement:
if (i_22 < 0)

Visiting conditional with predicate: if (i_22 < 0)

With known ranges
i_22: [j_12(D), j_12(D)]  EQUIVALENCES: { i_9(D) j_12(D) i_24 i_26 } (4
elements)

Predicate evaluates to: DON'T KNOW

but

Found new range for i_24: [10, 30]

so it's the old issue of not being able to use equivalences during iteration.
Quote:

  /* Compute the value of the predicate COND by checking the known
 ranges of each of its operands.

 Note that we cannot evaluate all the equivalent ranges here
 because those ranges may not yet be final and with the current
 propagation strategy, we cannot determine when the value ranges
 of the names in the equivalence set have changed.
...

we have a similar issue for match-and-simplify valueization where we now
conveniently track and update whether stmts are going to be simulated
again.

[Bug c/69960] "initializer element is not constant"

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
I don't think it is forbidden.  The C standard allows some latitude for
constant expressions in initializers, so I think we could accept code as in
Comment 5, i.e. evaluate it to an arithmetic constant expression.

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #21 from vries at gcc dot gnu.org ---
patch with test-case committed, marking resolved-fixed.

[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)

[vries at gcc dot gnu.org]

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

--- Comment #20 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Mar  2 15:10:34 2016
New Revision: 233909

URL: https://gcc.gnu.org/viewcvs?rev=233909=gcc=rev
Log:
Handle addr_expr and component_ref in graphite-ast-to-ast

2016-03-02  Tom de Vries  

PR tree-optimization/68659
* graphite-isl-ast-to-gimple.c (collect_all_ssa_names): Handle
new_expr == NULL_TREE.
(get_new_name): Handle ADDR_EXPR.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c

[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
(In reply to ktkachov from comment #3)
> Started with r233136.

That's why I forced base+offset out of memory reference and kept register
scaling in in the first place.  I think my statement still holds, that GIMPLE
optimizers should be improved to CSE register scaling expression among
different memory references, then force base(sp)+offset parts out of memory
reference in legitimize_address so that it can be merged.  I suspect this case
is going to be very inefficient in loop context.  Unfortunately GIMPLE
optimizers are weak now and r233136 is a workaround to it.  I want to revisit
slsr sometime after stage4 to fix this issue.

[Bug c/69960] "initializer element is not constant"

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #7 from Bernd Schmidt  ---
Cc'ing Jonathan in the hope he can answer the question.

[Bug c/69960] "initializer element is not constant"

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #6 from Bernd Schmidt  ---
I'm also curious why this wouldn't be considered constant. I only have an old
draft C standard, but I see no language forbidding this, and it can be
evaluated at compile-time.

We even have a fold_read_from_constant_string, but for whatever reason it's not
called when folding an ARRAY_REF.

[Bug target/64402] mep-elf ICE in pre_and_rev_post_order_compute, at cfganal.c:1022

[yselkowi at redhat dot com]

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

--- Comment #4 from Yaakov Selkowitz  ---
(In reply to Bernd Edlinger from comment #3)
> Created attachment 37172 [details]
> Patch to fix ICE and make interrupt restore r0

That allows me to finish the --without-headers build of 5.3.0 and subsequently
build newlib.  However, once I rebuild gcc *with* newlib installed, I get:

/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/build/mep-elf/./gcc/xgcc
-B/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/build/mep-elf/./gcc/
-B/usr/mep-elf/bin/ -B/usr/mep-elf/lib/ -isystem /usr/mep-elf/include -isystem
/usr/mep-elf/sys-include -mlibrary-g -O2 -mel -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 -mlibrary  -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -I. -I. -I../../.././gcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc/.
-I/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc/../gcc
-I/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc/../include
 -DHAVE_CC_TLS -DUSE_EMUTLS -o _gcov_indirect_call_topn_profiler.o -MT
_gcov_indirect_call_topn_profiler.o -MD -MP -MF
_gcov_indirect_call_topn_profiler.dep -DL_gcov_indirect_call_topn_profiler -c
/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc/libgcov-profiler.c
/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc/libgcov-profiler.c:
In function ‘__gcov_topn_value_profiler_body’:
/usr/src/ports/cross-gcc/cross-gcc-5.3.0-1.x86_64/src/gcc-5.3.0/libgcc/libgcov-profiler.c:194:1:
internal compiler error: in create_trace_edges, at dwarf2cfi.c:2409
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:880: recipe for target '_gcov_indirect_call_topn_profiler.o' failed
make[4]: *** [_gcov_indirect_call_topn_profiler.o] Error 1

[Bug target/70048] [6 Regression][AArch64] Inefficient local array addressing

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Started with r233136.

[Bug fortran/70040] [6 Regression] ICE in gimplify.c with deferred-length strings

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> Could be r233797 .

It is.