[Bug c/69381] New: Maximum long loop completes immediately

[alexander.gantman at intel dot com]

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

Bug ID: 69381
   Summary: Maximum long loop completes immediately
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.gantman at intel dot com
  Target Milestone: ---

The case (taken from U_BOOT code)

size_t strnlen(const char * s, size_t count)  
{
const char *sc;

for (sc = s; count-- && *sc != '\0'; ++sc)
/* nothing */;
return sc - s;
}

int main()
{
signed int prec = -1;
size_t res=0;
char* str = "mordy";
res = strnlen(str, prec);
}

Expectation res = 5;
Actual Result res = 0;


gcc line:

home/shaharmo/bin/ext_toolchain/bin/arc-linux-uclibc-gcc -Wp,-MD,post/.post.o.d
 -nostdinc -isystem
/home/shaharmo/bin/ext_toolchain/bin/../lib/gcc/arc-snps-linux-ucl
ibc/4.8.4/include -Iinclude   -I./arch/arc/include -include
./include/linux/kconfig.h -D__KERNEL__ -D__UBOOT__
-DCONFIG_SYS_TEXT_BASE=0xE010 -Wall -Wstrict-prototypes -Wno-format-sec
urity -fno-builtin -ffreestanding -Os -fno-stack-protector
-fno-delete-null-pointer-checks -g -fstack-usage -Wno-format-nonliteral
-mlittle-endian -marchs -ffixed-r25 -D__ARC__ -gdwarf-2
-pipe-D"KBUILD_STR(s)=\#s" -D"KBUILD_BASENAME=KBUILD_STR(post)" 
-D"KBUILD_MODNAME=KBUILD_STR(post)" -c -o post/post.o post/post.c


Gcc build

Using built-in specs.
COLLECT_GCC=/home/shaharmo/bin/ext_toolchain/bin/arc-linux-uclibc-gcc
COLLECT_LTO_WRAPPER=/home/shaharmo/bin/ext_toolchain/bin/../libexec/gcc/arc-snps-linux-uclibc/4.8.4/lto-wrapper
Target: arc-snps-linux-uclibc
Configured with: /home/akolesov/ws/arc-2015.06-rc2/gcc/configure
--target=arc-snps-linux-uclibc --with-cpu=archs --disable-multilib
--with-pkgversion='ARCv2 ISA Linux uClibc toolchain 2015.06'
--with-bugurl=https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues
--enable-fast-install=N/A --with-endian=little --disable-werror
--enable-languages=c,c++
--prefix=/home/akolesov/ws/arc-2015.06-rc2/toolchain/../release_output/arc_gnu_2015.06_prebuilt_uclibc_le_archs_linux_install
--enable-shared --without-newlib --disable-libgomp --with-python=no
LDFLAGS=-static
--with-sysroot=/home/akolesov/ws/arc-2015.06-rc2/toolchain/../release_output/arc_gnu_2015.06_prebuilt_uclibc_le_archs_linux_install/arc-snps-linux-uclibc/sysroot
Thread model: posix
gcc version 4.8.4 (ARCv2 ISA Linux uClibc toolchain 2015.06)

[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi

[jakub at gcc dot gnu.org]

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

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

Nothing happened since then.  I'm willing to commit this as obvious, just want
to double check with Stefan if he is ok with that attribution (and whether to
use that email or some other one; as it is a one liner change, it is below the
threshold for copyright assignment and I could just use Maxim's attribution too
otherwise, as the patch is just a port of his patch from aarch64 to arm).

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[rogero at howzatt dot demon.co.uk]

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

Roger Orr  changed:

   What|Removed |Added

 CC||rogero at howzatt dot 
demon.co.uk

--- Comment #12 from Roger Orr  ---
Alas, revision 232071 appears to break the cygwin full build of gcc.

$ cd /cygdrive/c/projects/gcc/gcctrunk
$ svn update -r 232071
$ ./contrib/download_prerequisites
$ mkdir ../build
$ cd ../build
$ ../gcctrunk/configure --enable-languages=c,c++ --prefix=/usr/share/gcctrunk
$ make -j4 2>&1 | tee /var/tmp/build.log
...
libtool: link:  /cygdrive/c/projects/gcc/build/./gcc/xgcc -shared-libgcc
-B/cygdrive/c/projects/gcc/build/./gcc -nostdinc++
-L/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src
-L/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src/.libs
-L/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/libsupc++/.libs
-B/usr/share/gcctrunk/x86_64-unknown-cygwin/bin/
-B/usr/share/gcctrunk/x86_64-unknown-cygwin/lib/ -isystem
/usr/share/gcctrunk/x86_64-unknown-cygwin/include -isystem
/usr/share/gcctrunk/x86_64-unknown-cygwin/sys-include-shared -nostdlib
/cygdrive/c/projects/gcc/build/./gcc/crtbeginS.o  .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o
.libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o
.libs/compatibility-condvar.o  -Wl,--whole-archive
../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive 
-L/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/libsupc++/.libs
-L/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src
-L/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src/.libs
-L/usr/lib/w32api -L/cygdrive/c/projects/gcc/build/./gcc -L/lib/../lib
-L/usr/lib/../lib -lgcc_s -lgcc -lcygwin -ladvapi32 -lshell32 -luser32
-lkernel32 -lgcc_s -lgcc /cygdrive/c/projects/gcc/build/./gcc/crtend.o  -Wl,-O1
-Wl,--gc-sections -Wl,--version-script=libstdc++-symbols.ver   -o
.libs/cygstdc++-6.dll -Wl,--enable-auto-image-base -Xlinker --out-implib
-Xlinker .libs/libstdc++.dll.a
.libs/compatibility.o: In function `std::basic_istream >::ignore(long)':
/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src/../../../../gcctrunk/libstdc++-v3/src/c++98/compatibility.cc:67:
undefined reference to `std::basic_istream
>::sentry::sentry(std::basic_istream >&, bool)'

(many similar errors elided)...

../src/c++11/.libs/libc++11convenience.a(wstring-inst.o):/cygdrive/c/projects/gcc/gcctrunk/libstdc++-v3/include/bits/basic_string.h:196:
more undefined references to `void std::__cxx11::basic_string, std::allocator >::_M_construct(wchar_t const*, wchar_t const*, std::forward_iterator_tag)' follow
collect2: error: ld returned 1 exit status
Makefile:606: recipe for target 'libstdc++.la' failed
make[6]: *** [libstdc++.la] Error 1
make[6]: Leaving directory
'/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src'
Makefile:638: recipe for target 'all-recursive' failed
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory
'/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3/src'
Makefile:507: recipe for target 'all-recursive' failed
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
'/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3'
Makefile:414: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory
'/cygdrive/c/projects/gcc/build/x86_64-unknown-cygwin/libstdc++-v3'
Makefile:16346: recipe for target 'all-stage1-target-libstdc++-v3' failed
make[2]: *** [all-stage1-target-libstdc++-v3] Error 2
make[2]: Leaving directory '/cygdrive/c/projects/gcc/build'
Makefile:21374: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory '/cygdrive/c/projects/gcc/build'
Makefile:916: recipe for target 'all' failed
make: *** [all] Error 2

[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi

[stefan.sorensen at spectralink dot com]

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

--- Comment #10 from Stefan Sørensen  
---
Sorry, I got caught up in trying to do a bootstrap on my arm board and then got
distracted by other stuff. I am fine with you committing it.

[Bug target/69345] [6 Regression] 459.GemsFDTD regression

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Wed Jan 20 08:36:32 2016
New Revision: 232603

URL: https://gcc.gnu.org/viewcvs?rev=232603&root=gcc&view=rev
Log:
2016-01-20  Richard Biener  

PR tree-optimization/69345
* tree-ssa-sccvn.h (VN_INFO_RANGE_INFO): New inline function.
(VN_INFO_PTR_INFO): Likewise.
* tree-ssa-sccvn.c (set_ssa_val_to): Avoid clearing points-to
info when it is equal between non-dominating SSA names.
* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
Make sure to look at original SSA infos.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-pre.c
trunk/gcc/tree-ssa-sccvn.c
trunk/gcc/tree-ssa-sccvn.h

[Bug target/69345] [6 Regression] 459.GemsFDTD regression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Blocks||69117
 Resolution|--- |FIXED

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69117
[Bug 69117] [6 Regression] wrong code at -O1 -fstrict-aliasing

[Bug tree-optimization/69117] [6 Regression] wrong code at -O1 -fstrict-aliasing

[rguenth at gcc dot gnu.org]

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

Bug 69345 Summary: [6 Regression] 459.GemsFDTD regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69345

   What|Removed |Added

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

[Bug c/69382] New: noinit()

[svabiramiece at gmail dot com]

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

Bug ID: 69382
   Summary: noinit()
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: svabiramiece at gmail dot com
  Target Milestone: ---

Hello,

I am using Atmel Studio 7. The GNU c compiler version used in the Studio is
4.9.2.

I have doubts regarding .noinit() section. Before asking my doubts I want to
clarify something. Please check the below statements are correct or not
1. The variable stored in I/O and Extended I/O register space purely depends on
the compiler. The user can’t have the access to store the variables in this
section.

2.The variables stored in the noinit() shouldn’t be initialized to zero at any
concern. On any reset, the variables in the noinit section shouldn’t be
initialized to zero.

 3. The noinit() should be given in the linker script before compiling.

Looking forward for your reply.

[Bug c/69382] noinit()

[svabiramiece at gmail dot com]

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

svabiramiece at gmail dot com changed:

   What|Removed |Added

 CC||svabiramiece at gmail dot com
Version|unknown |4.9.2
   Severity|normal  |major

[Bug target/68973] [6 regression] Internal compiler error on power for gcc/testsuite/g++.dg/pr67211.C

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Mike, could you please have a look at this?  This is a P1 blocker.
It ICEs also with -mcpu=power7 -mtune=power7.  And is again fixed with LRA as
various other PPC ICEs.
In IRA we have:
(insn 155 153 156 8 (set (reg/f:DI 178 [ p3$_M_first ])
(mem/f:DI (pre_inc:DI (reg/f:DI 185 [ p3$_M_node ])) [3 MEM[base: _9,
offset: 0B]+0 S8 A64])) pr67211.C:28 540 {*movdi_internal64}
 (expr_list:REG_INC (reg/f:DI 185 [ p3$_M_node ])
(nil)))
and disposition for pseudo 185 looks good: 9:r185 l0
but reload decides to put r185 into a floating point register despite of that,
because it is used in some VSX instruction.

[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed.

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[tony at kelman dot net]

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

--- Comment #13 from Tony Kelman  ---
Should this change be for ming-but-not-cyg then?

[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi

[ktkachov at gcc dot gnu.org]

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

--- Comment #11 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 37403 [details]
> gcc6-pr69187.patch
> 
> Nothing happened since then.  I'm willing to commit this as obvious, just
> want to double check with Stefan if he is ok with that attribution (and
> whether to use that email or some other one; as it is a one liner change, it
> is below the threshold for copyright assignment and I could just use Maxim's
> attribution too otherwise, as the patch is just a port of his patch from
> aarch64 to arm).

Thanks, please do.
This will also need a backport to GCC 5

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
(In reply to Jan Hubicka from comment #8)
> Jakub, why this is refused?

Dunno.  Weakrefs have been added for undefined weak references, so I fail to
see why you'd like to emit a weakref if the symbol is defined in the current
file, IMHO you should just then transparently redirect in the assembly all
references from callmealias.lto_priv.0 to callmesecond.  That said, it might be
a gas bug too, if you say that the assembler should do the work for the
compiler, but it has been years since I've touched binutils, you want some of
the current binutils maintainers to have a look at that instead.

[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Started with:

commit 3c77e6e51f3def12b1ad416dac4b907f2245b047
Author: jason 
Date:   Tue Nov 17 21:49:23 2015 +

PR bootstrap/68346

* typeck.c (build_static_cast_1): Force a NOP when converting to
the same type.

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

Reduced testcase would be much appreciated!

[Bug tree-optimization/69359] Warn about constant comparisons between pointers and arrays

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I'd find warning about p <= weird, warning about p < a makes sense, as well as
e.g.
int g (void)
{
  int a[3], b;
  int *p = f (a, &b);
  return (p < a)
 + (p < &a[0])
 + (p > &a[3])
 + (p < &b)
 + (p > &b + 1);
}
Not a stage4 material though.

[Bug target/69381] Maximum long loop completes immediately

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||arc
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-20
  Component|c   |target
Version|unknown |4.8.4
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
works fine on x86_64.  Note your testcase doesn't compile and is likely
optimized to nothing (you don't use 'res').  I've fixed it to

typedef __SIZE_TYPE__ size_t;
size_t strnlen(const char * s, size_t count)  
{
  const char *sc;

  for (sc = s; count-- && *sc != '\0'; ++sc)
/* nothing */;
  return sc - s;
}

int main()
{
  signed int prec = -1;
  size_t res=0;
  char* str = "mordy";
  res = strnlen(str, prec);
  return res;
}

note also that GCC 4.8 is no longer supported so please try a more recent
version
(preferably 5.3).

[Bug testsuite/69380] [6 Regression] FAIL: g++.dg/tree-ssa/pr69336.C scan-tree-dump-not optimized "cmap"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC|rguenther at suse dot de   |alan.lawrence at arm 
dot com,
   ||rguenth at gcc dot gnu.org
  Component|tree-optimization   |testsuite
   Target Milestone|--- |6.0
Summary|FAIL:   |[6 Regression] FAIL:
   |g++.dg/tree-ssa/pr69336.C   |g++.dg/tree-ssa/pr69336.C
   |scan-tree-dump-not  |scan-tree-dump-not
   |optimized "cmap"|optimized "cmap"

--- Comment #1 from Richard Biener  ---
Ah.  arm fails to SRA the constant pool load.  Alan, how'd you annotate
testcases for this?  I believe it's a known failure and thus the testcase
should be XFAILed for affected targets.

[Bug testsuite/69380] [6 Regression] FAIL: g++.dg/tree-ssa/pr69336.C scan-tree-dump-not optimized "cmap"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 Ever confirmed|0   |1

[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/69378] [6 Regression] FAIL: g++.dg/tree-ssa/pr61034.C

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-20
 CC|rguenther at suse dot de   |
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Blocks||69117
 Ever confirmed|0   |1
Summary|FAIL:   |[6 Regression] FAIL:
   |g++.dg/tree-ssa/pr61034.C   |g++.dg/tree-ssa/pr61034.C
   Target Milestone|--- |6.0

--- Comment #1 from Richard Biener  ---
Did r232603 fix it by chance?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69117
[Bug 69117] [6 Regression] wrong code at -O1 -fstrict-aliasing

[Bug rtl-optimization/69377] [6 Regression] wrong code at -O2 on x86_64-linux-gnu (in 32-bit mode)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|wrong code at -O2 on|[6 Regression] wrong code
   |x86_64-linux-gnu (in 32-bit |at -O2 on x86_64-linux-gnu
   |mode)   |(in 32-bit mode)

[Bug tree-optimization/69376] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |6.0
Summary|wrong code at -Os and above |[6 Regression] wrong code
   |on x86_64-linux-gnu |at -Os and above on
   ||x86_64-linux-gnu

[Bug target/69374] install.texi is bit-rotten

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  One issue is that the version presented on the web is always taken
from trunk, not from the respective branches.  That is,
https://gcc.gnu.org/onlinedocs/5.3.0/ does not reference any install
instructions but there is only gcc.gnu.org/install which is for trunk.

[Bug target/69369] [6 Regression] internal compiler error: in remove_unreachable_nodes, at ipa.c:457

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Also many other MPX ICEs in the testsuite.

[Bug fortran/69360] loop optimization produces invalid code when a common array has dimension 1 in some files

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
Invalid thus.

[Bug tree-optimization/69378] [6 Regression] FAIL: g++.dg/tree-ssa/pr61034.C

[thopre01 at gcc dot gnu.org]

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

--- Comment #2 from Thomas Preud'homme  ---
Sadly no, it didn't.

[Bug tree-optimization/69376] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.

commit 4345b86806dabf41d683fa4b697a60c449c93e5f
Author: rguenth 
Date:   Fri Jan 15 08:16:08 2016 +

2016-01-15  Richard Biener  

PR tree-optimization/69117
* tree-ssa-sccvn.h (struct vn_ssa_aux): Add info member.
* tree-ssa-sccvn.c (set_ssa_val_to): Save and adjust SSA name info
of the leader conservatively.
(free_scc_vn): Restore original SSA name infos.

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


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

[Bug libstdc++/69383] New: [6 Regression] r232586 breaks Firefox build

[trippels at gcc dot gnu.org]

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

Bug ID: 69383
   Summary: [6 Regression] r232586 breaks Firefox build
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

With r232586 I get:

trippels@gcc2-power8 src % /home/trippels/gcc_test/usr/local/bin/c++ -o
Unified_cpp_gfx_graphite2_src0.o -c -I../../../dist/stl_wrappers
-I../../../dist/system_wrappers -include
/home/trippels/gecko-dev/config/gcc_hidden.h -DGRAPHITE2_STATIC
-DPACKAGE_VERSION='"moz"' -DPACKAGE_BUGREPORT='"http://bugzilla.mozilla.org/";'
-DGRAPHITE2_NFILEFACE -DGRAPHITE2_NTRACING -DGRAPHITE2_NSEGCACHE
-DGRAPHITE2_CUSTOM_HEADER='"MozGrMalloc.h"' -DMOZ_GLUE_IN_PROGRAM -DAB_CD=en-US
-DNO_NSPR_10_SUPPORT -I/home/trippels/gecko-dev/gfx/graphite2/src -I. 
-I../../../dist/include   -I/usr/include/nspr4
-I/home/trippels/moz-build-dir/dist/include/nss-I/usr/include/pixman-1   
-fPIC   -DMOZILLA_CLIENT -include ../../../mozilla-config.h -MD -MP -MF
.deps/Unified_cpp_gfx_graphite2_src0.o.pp  -Wall -Wempty-body
-Woverloaded-virtual -Wsign-compare -Wwrite-strings -Werror=endif-labels
-Werror=int-to-pointer-cast -Werror=missing-braces -Werror=pointer-arith
-Werror=return-type -Werror=sequence-point -Werror=unused-label
-Werror=trigraphs -Werror=type-limits -Wno-invalid-offsetof -Wcast-align
-std=c++1z -w -flto=60 --param lto-partitions=60 -ffunction-sections
-fdata-sections -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions
-fno-math-errno -std=gnu++0x -pthread -pipe  -DNDEBUG -DTRIMMED -O3
-fomit-frame-pointer
/home/trippels/moz-build-dir/gfx/graphite2/src/Unified_cpp_gfx_graphite2_src0.cpp
In file included from ../../../dist/system_wrappers/stdlib.h:3:0,
 from ../../../dist/include/mozilla/mozalloc.h:15,
 from ../../../dist/stl_wrappers/cstdlib:39,
 from /home/trippels/gecko-dev/gfx/graphite2/src/inc/Main.h:29,
 from /home/trippels/gecko-dev/gfx/graphite2/src/Bidi.cpp:27,
 from
/home/trippels/moz-build-dir/gfx/graphite2/src/Unified_cpp_gfx_graphite2_src0.cpp:2:
/home/trippels/gcc_test/usr/local/include/c++/6.0.0/stdlib.h:37:12: error:
‘std::abort’ has not been declared
 using std::abort;
^

/home/trippels/gcc_test/usr/local/include/c++/6.0.0/stdlib.h:38:12: error:
‘std::atexit’ has not been declared
 using std::atexit;
^~

/home/trippels/gcc_test/usr/local/include/c++/6.0.0/stdlib.h:39:12: error:
‘std::exit’ has not been declared
 using std::exit;
^~~~
...

trippels@gcc2-power8 tmp % cat foo.cpp
#include 

trippels@gcc2-power8 tmp % cat stdlib.h
#include_next 

trippels@gcc2-power8 tmp % cat cstdlib
#include 

trippels@gcc2-power8 tmp % g++ -c -I./ foo.cpp
In file included from ./stdlib.h:1:0,
 from foo.cpp:1:
/home/trippels/gcc_test/usr/local/include/c++/6.0.0/stdlib.h:37:12: error:
‘std::abort’ has not been declared
 using std::abort;
^

/home/trippels/gcc_test/usr/local/include/c++/6.0.0/stdlib.h:38:12: error:
‘std::atexit’ has not been declared
 using std::atexit;
^~

/home/trippels/gcc_test/usr/local/include/c++/6.0.0/stdlib.h:39:12: error:
‘std::exit’ has not been declared
 using std::exit;
^~~~

[Bug target/69381] Maximum long loop completes immediately

[alexander.gantman at intel dot com]

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

--- Comment #2 from Alexander Gantman  ---
We also had checked it on x86 and it was ok.The problem is only on ARC.
more over it works fine with Arc Compiler. Only GCC generates wrong assembly.

[Bug libstdc++/69383] [6 Regression] r232586 breaks Firefox build

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
If firefox provides its own wrappers of system headers, then it is responsible
for making it work with the system headers.  The question is how many packages
do something like that and will need fixing.

[Bug tree-optimization/69377] [6 Regression] wrong code at -O2 on x86_64-linux-gnu (in 32-bit mode)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 CC||mpolacek at gcc dot gnu.org
  Component|rtl-optimization|tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r225722:

2015-07-12  Kugan Vivekanandarajah  

PR middle-end/66726
* tree-ssa-phiopt.c(factor_out_conditional_conversion): New function.
tree_ssa_phiopt_worker): Call it.

[Bug tree-optimization/69378] [6 Regression] FAIL: g++.dg/tree-ssa/pr61034.C

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Ok, difference is in PRE:

--- a/pr61034.C.123t.pre2016-01-20 10:27:14.052404275 +0100
+++ b/pr61034.C.123t.pre2016-01-20 10:26:24.331842158 +0100
@@ -778,289 +778,344 @@
 Value numbering store SR.21_304->count to 2
 Setting value number of .MEM_132 to .MEM_132 (changed)
 Value numbering _48 stmt = _48 = MEM[(struct O *)_248].count;
-Setting value number of _48 to 2 (changed)
+Setting value number of _48 to _48 (changed)
 Value numbering _49 stmt = _49 = _48 + -1;
-Match-and-simplified _48 + -1 to 1
-RHS _48 + -1 simplified to 1
-Setting value number of _49 to 1 (changed)
+Setting value number of _49 to _49 (changed)
...

and the reason is that the dominance queries I do for the PR69117 fix do not
honor the edges we computed as unreachable.  The first case we hit that ends
up pessimizing points-to info during VN is quite simple:

:
# RANGE [2, 2147483647] NONZERO 2147483647
_57 = _56 + 1;
MEM[(struct O *)_248].count = _57;
if (_75 > 1)
  goto ;
else
  goto ;

:
goto ;

:
# PT = { D.5028 }
# ALIGN = 8, MISALIGN = 0
# USE = nonlocal 
# CLB = nonlocal 
_266 = __builtin_malloc (16);
MEM[(struct O *)_266].num = _202;
# RANGE [1, 2147483646] NONZERO 2147483647
_280 = _74;
MEM[(struct O *)_194].count = _74;
MEM[(struct O *)_266].count = 1;
D.4995 ={v} {CLOBBER};

:
# PT = { D.5024 D.5028 }
# ALIGN = 8, MISALIGN = 0
# SR.21_304 = PHI <_194(41), _266(15)>

with _75 > 1 known to be true and the edge 41 -> 16 not executable we
value-number SR.21_304 to _266 but clear points-to info of that on the
way unnecessarily.

So we can open-code a wrapper around dominated_by_p and handle some
simple CFG cases with not executable edges.  I'm not sure it's worth
to covering everything like by looking up the common immediate dominator
and figuring out if there is an always executed path through both nodes
starting from it.  [I believe it's enough to handle the case with
equal immediate dominator]

[Bug libstdc++/69383] [6 Regression] r232586 breaks Firefox build

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Firefox could use
#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next 
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
instead of just
#include_next 
to get the old behavior I guess.

[Bug libstdc++/69383] [6 Regression] r232586 breaks Firefox build

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-20
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Please provide preprocessed source so I can see what silliness Firefox does
this time, but basically this is undefined behaviour:

In file included from ../../../dist/system_wrappers/stdlib.h:3:0,
 from ../../../dist/include/mozilla/mozalloc.h:15,
 from ../../../dist/stl_wrappers/cstdlib:39,

I'm not going to hold off fixing bugs in the real standard library because of
projects that have their own fake standard library with undefined behaviour.

[Bug c++/69384] New: defaulted default constructor not defined as deleted for class with a const data member which does not have a user-provided default constructor

[sensorflo at gmail dot com]

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

Bug ID: 69384
   Summary: defaulted default constructor not defined as deleted
for class with a const data member which does not have
a user-provided default constructor
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sensorflo at gmail dot com
  Target Milestone: ---

The standard (N4140) says in 12.1 p4: 

... A defaulted default constructor for class X is defined as deleted if:
...
(4.3) any non-variant non-static data member of const-qualified type (or array
thereof) with no brace-or-equal-initializer does not have a user-provided
default constructor, 

However the following compiles without error (g++ -std=c++14 -Wall -pedantic
main.cpp)

class A {  };
class B {
  const A a_;
};
int main() {
  B b{};
}

If I add a member to class A I rightfully get a compile error. I assume it's an
extension of gcc that it does not respect 12.1 p4.3 if the class type of the
const member has no non-static members, since in this case the intention of
12.1 p4.3 is not given. Still, using -pedantic I expect gcc to 'reject all
programs that use forbidden extensions'. I now have the portability problem
that gcc wrongly accepts my real world program, but other compilers rightfully
reject it.

[Bug libstdc++/69383] [6 Regression] r232586 breaks Firefox build

[trippels at gcc dot gnu.org]

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

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

[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #4 from Markus Trippelsdorf  ---
markus@x4 tmp % cat DictDataInfoPyWrap.ii
typedef int Trans_NS___cxx11_string;
class A {
public:
  template  A(char *, DerivedT);
  template 
  void m_fn1(char *, Fn, A1 const &, A2);
};
struct Dict {
  void m_fn2();
};
void fn1() {
  A a("", "");
  typedef void *Get;
  typedef void (Dict::*d)(Trans_NS___cxx11_string);
  a.m_fn1("", Get(), d(&Dict::m_fn2), "");
}

markus@x4 tmp % g++ -w -c -Wformat DictDataInfoPyWrap.ii
DictDataInfoPyWrap.ii: In function ‘void fn1()’:
DictDataInfoPyWrap.ii:15:41: internal compiler error: in fold_convert_loc, at
fold-const.c:2366

[Bug libstdc++/69383] [6 Regression] r232586 breaks Firefox build

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Markus Trippelsdorf  ---
invalid

[Bug libstdc++/69383] [6 Regression] r232586 breaks Firefox build

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #2)
> Firefox could use
> #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
> #include_next 
> #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
> instead of just
> #include_next 
> to get the old behavior I guess.

That would mean they don't get a non-conforming  because they would
circumvent the fix for PR60401, but I doubt non-conformance will worry them. It
might be the simplest hack to compile again, although I wouldn't call it a fix.

[Bug fortran/69385] New: [6 regression] ICE on valid with -fcheck=all

[mar...@mpa-garching.mpg.de]

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

Bug ID: 69385
   Summary: [6 regression] ICE on valid with -fcheck=all
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 37405
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37405&action=edit
test case

Compiling the attached testcase using yesterday's trunk with the command line

gfortran -v -c bugrep.f90 -fcheck=all 

produces

/scratch/martin/mysvn/Crash_polish>gfortran -v -c bugrep.f90 -fcheck=all 
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-pc-linux-gnu
Configured with: /scratch/martin/gccgit/configure --disable-bootstrap
--prefix=/scratch/martin/utrunk --enable-languages=c++,fortran
--enable-target=all --enable-checking=release
Thread model: posix
gcc version 6.0.0 20160118 (experimental) [trunk revision
6ccd18c:cc8cc97:131468370faeb6ea8a1d21081d7e6a593bf40170] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-fcheck=all' '-mtune=generic' '-march=x86-64'
 /scratch/martin/utrunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/f951 bugrep.f90
-quiet -dumpbase bugrep.f90 -mtune=generic -march=x86-64 -auxbase bugrep
-version -fcheck=all -fintrinsic-modules-path
/scratch/martin/utrunk/lib/gcc/x86_64-pc-linux-gnu/6.0.0/finclude -o
/tmp/ccvKz9Tq.s
GNU Fortran (GCC) version 6.0.0 20160118 (experimental) [trunk revision
6ccd18c:cc8cc97:131468370faeb6ea8a1d21081d7e6a593bf40170] (x86_64-pc-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 5.1.3, MPFR version 3.1.3,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 6.0.0 20160118 (experimental) [trunk revision
6ccd18c:cc8cc97:131468370faeb6ea8a1d21081d7e6a593bf40170] (x86_64-pc-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 5.1.3, MPFR version 3.1.3,
MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
bugrep.f90:18:0:

   allocate(getCmdLine(command_argument_count()))


internal compiler error: in wide_int_to_tree, at tree.c:1486
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


If "-fcheck=all" is omitted, the code is compiled without complaint.

[Bug bootstrap/69386] New: [6 regression] r232586 breaks mingw-w64 bootstrap

[ismail at i10z dot com]

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

Bug ID: 69386
   Summary: [6 regression] r232586 breaks mingw-w64 bootstrap
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ismail at i10z dot com
  Target Milestone: ---

With r232586 getting:

/bin/sh ../libtool --tag CXX --tag disable-shared   --mode=compile
x86_64-w64-mingw32-c++ -L/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/lib
-L/havana/mingw-w64-6.0.0/mingw/lib -isystem
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include -isystem
/havana/mingw-w64-6.0.0/mingw/include   
-I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/../libgcc
-I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include
-I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/libsupc++   -prefer-pic
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi  -fdiagnostics-show-location=once-ffunction-sections
-fdata-sections  -frandom-seed=eh_arm.lo -g -O2  -c -o eh_arm.lo
../../../../combined-6.0.0/libstdc++-v3/libsupc++/eh_arm.cc
libtool: compile:  x86_64-w64-mingw32-c++
-L/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/lib
-L/havana/mingw-w64-6.0.0/mingw/lib -isystem
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include -isystem
/havana/mingw-w64-6.0.0/mingw/include
-I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/../libgcc
-I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include
-I/havana/mingw-w64-build/combined-6.0.0/libstdc++-v3/libsupc++
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=eh_arm.lo -g -O2 -c
../../../../combined-6.0.0/libstdc++-v3/libsupc++/eh_arm.cc -o eh_arm.o
In file included from
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/stdlib.h:35:0,
 from
/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/include/mm_malloc.h:27,
 from
/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/include/xmmintrin.h:34,
 from
/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/include/x86intrin.h:31,
 from
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include/winnt.h:1519,
 from
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include/minwindef.h:163,
 from
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include/windef.h:8,
 from
/havana/mingw-w64-6.0.0/x86_64-w64-mingw32/include/windows.h:69,
 from
/usr/lib64/gcc/x86_64-w64-mingw32/5.3.0/include/unwind.h:33,
 from
../../../../combined-6.0.0/libstdc++-v3/libsupc++/unwind-cxx.h:36,
 from
../../../../combined-6.0.0/libstdc++-v3/libsupc++/eh_arm.cc:26:
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:
In function 'long long int std::abs(long long int)':
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:178:20:
error: conflicting declaration of C function 'long long int std::abs(long long
int)'
   abs(long long __x) { return __builtin_llabs (__x); }
^
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:170:3:
note: previous declaration 'long int std::abs(long int)'
   abs(long __i) { return __builtin_labs(__i); }
   ^
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:
In function '__int128 std::abs(__int128)':
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:183:33:
error: conflicting declaration of C function '__int128 std::abs(__int128)'
   abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
 ^
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:178:3:
note: previous declaration 'long long int std::abs(long long int)'
   abs(long long __x) { return __builtin_llabs (__x); }
   ^
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:183:33:
error: conflicting declaration of C function '__int128 std::abs(__int128)'
   abs(__GLIBCXX_TYPE_INT_N_0 __x) { return __x >= 0 ? __x : -__x; }
 ^
/havana/mingw-w64-build/build-6.0.0/x86_64-w64-mingw32/libstdc++-v3/include/cstdlib:170:3:
note: previous declaration 'long int std::abs(long int)'
   abs(long __i) { return __builtin_labs(__i); }
   ^

[Bug c++/69387] New: undefined reference to constant in template

[bernd.edlinger at hotmail dot de]

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

Bug ID: 69387
   Summary: undefined reference to constant in template
   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,

the following example is miss-compiled at -O0

cat test.cc
class StatusCode
{
public:
  static const int TEST_VALUE = 0x2;
};

typedef bool AssertionResult;

template 
AssertionResult CmpHelperEQ(const T1& expected,
const T2& actual)
{
  if (expected == actual)
return true;

  return false;
}

int
main()
{
  return CmpHelperEQ(2, StatusCode::TEST_VALUE) ? 0 : 1;
}
gcc test.cc
test.cc:(.text+0x14): undefined reference to `StatusCode::TEST_VALUE'
collect2: error: ld returned 1 exit status

[Bug tree-optimization/69378] [6 Regression] FAIL: g++.dg/tree-ssa/pr61034.C

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
The dominator walk (recording temporary relations / equivalences) is
pessmimized
by not considering not executable edges as well (by unnecessarily popping off
those).  Consider a diamond with one half not executable - the conditional
relations / equivalences still hold in the merger.

The following patch fixes this regression though dominated_by_p_w_unex
is somewhat awkward.  We could do better by iterating but the key
issue is to identify quickly if there is any (exeecutable) path from bb2 to
bb1,
otherwise we'll iterate to entry or exit (dependent on which direction
we iterate) - that'll be too costly.

For example we could iterate by following bb2s single executable
successors, verifying they do have a single executable predecessor,
until we hit bb1 (or exit ...).  [if not single executable successor
continue with the successor that has the executable path from bb2 to bb1...]

Maybe the patch is already too sophisticated and I should simply do
a max. n (1?) depth walk like that.

That said, "fixing" the dominator walk for DOM / SCCVN would certainly
be interesting as well - I'm not sure we can compute dominators
"on-the-fly" though, that is, keep the efficient stack of cond
equivalences, for all but very simple CFG shapes.

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 232603)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -2969,6 +2969,31 @@ print_scc (FILE *out, vec scc)
   fprintf (out, "\n");
 }

+/* Return true if BB1 is dominated by BB2 taking into account edges
+   that are not executable in the region starting from the
+   common immediate dominator.  */
+
+static bool
+dominated_by_p_w_unex (basic_block bb1, basic_block bb2)
+{
+  if (dominated_by_p (CDI_DOMINATORS, bb1, bb2))
+return true;
+
+  /* Go up to the immediate dominator of bb2 and see if that is post-dominated
+ by bb2 taking into account un-executable edges.  */
+  basic_block idom2 = get_immediate_dominator (CDI_DOMINATORS, bb2);
+  if (EDGE_COUNT (idom2->succs) != 2)
+return false;
+  if ((! (EDGE_SUCC (idom2, 0)->flags & EDGE_EXECUTABLE)
+   && dominated_by_p (CDI_DOMINATORS, bb2, EDGE_SUCC (idom2, 1)->dest))
+  || (! (EDGE_SUCC (idom2, 1)->flags & EDGE_EXECUTABLE)
+ && dominated_by_p (CDI_DOMINATORS, bb2, EDGE_SUCC (idom2, 0)->dest)))
+/* Re-do the dominance check with the immediate dominator.  */
+return dominated_by_p (CDI_DOMINATORS, bb1, idom2);
+
+  return false;
+}
+
 /* Set the value number of FROM to TO, return true if it has changed
as a result.  */

@@ -3046,13 +3071,13 @@ set_ssa_val_to (tree from, tree to)
  && SSA_NAME_RANGE_INFO (to))
{
  if (SSA_NAME_IS_DEFAULT_DEF (to)
- || dominated_by_p (CDI_DOMINATORS,
+ || dominated_by_p_w_unex (
 gimple_bb (SSA_NAME_DEF_STMT (from)),
 gimple_bb (SSA_NAME_DEF_STMT (to
/* Keep the info from the dominator.  */
;
  else if (SSA_NAME_IS_DEFAULT_DEF (from)
-  || dominated_by_p (CDI_DOMINATORS,
+  || dominated_by_p_w_unex (
  gimple_bb (SSA_NAME_DEF_STMT (to)),
  gimple_bb (SSA_NAME_DEF_STMT
(from
{
@@ -3076,13 +3101,13 @@ set_ssa_val_to (tree from, tree to)
   && SSA_NAME_PTR_INFO (to))
{
  if (SSA_NAME_IS_DEFAULT_DEF (to)
- || dominated_by_p (CDI_DOMINATORS,
+ || dominated_by_p_w_unex (
 gimple_bb (SSA_NAME_DEF_STMT (from)),
 gimple_bb (SSA_NAME_DEF_STMT (to
/* Keep the info from the dominator.  */
;
  else if (SSA_NAME_IS_DEFAULT_DEF (from)
-  || dominated_by_p (CDI_DOMINATORS,
+  || dominated_by_p_w_unex (
  gimple_bb (SSA_NAME_DEF_STMT (to)),
  gimple_bb (SSA_NAME_DEF_STMT
(from
{


Alternative "algorithm":

/* Return true if BB1 is dominated by BB2 taking into account edges
   that are not executable.  */

static bool
dominated_by_p_w_unex (basic_block bb1, basic_block bb2)
{
  if (dominated_by_p (CDI_DOMINATORS, bb1, bb2))
return true;

  /* Before iterating we'd like to know if there exists a
 (executable) path from bb2 to bb1 at all, if not we can
 directly return 

[Bug tree-optimization/69378] [6 Regression] FAIL: g++.dg/tree-ssa/pr61034.C

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Created attachment 37406
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37406&action=edit
patch for testing

Patch I am testing.

[Bug c++/69387] undefined reference to constant in template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
You are missing a definition of TEST_VALUE.  Add


const int StatusCode::TEST_VALUE;

[Bug libstdc++/69386] [6 regression] r232586 breaks mingw-w64 bootstrap

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Target||mingw-w64
   Priority|P3  |P1
  Component|bootstrap   |libstdc++
   Target Milestone|--- |6.0

[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=all

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. The ICE appeared between revisions r231990 (2015-12-29, OK) and
r232451 (2016-01-15, ICE), possibly r232450 (pr64324, ... ).

[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=all

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |6.0

[Bug tree-optimization/69378] [6 Regression] FAIL: g++.dg/tree-ssa/pr61034.C

[thopre01 at gcc dot gnu.org]

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

--- Comment #6 from Thomas Preud'homme  ---
This patch works for me on this testcase.

[Bug testsuite/69366] All MPX tests are unsupported

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
Suppose you mean tests related to i386.exp which misses mpx_init call.  But
probably runtime tests should be simply moved into mpx subdir.

[Bug libstdc++/69386] [6 regression] r232586 breaks mingw-w64 bootstrap

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c++/69363] ICE when doing a pragma simd reduction with max

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
The bug is that cp_parser_cilk_simd_all_clauses and
c_parser_cilk_simd_all_clauses calls c_finish_cilk_clauses rather than the
OpenMP clauses finalization routines in each of the FEs, perhaps with some
argument that would say it wants Cilk+ semantics instead of OpenMP.
That way, it misses lots of important actions that need to be performed on the
clauses.
E.g. for reduction performs in C++ finish_omp_reduction_clause, which looks up
the reduction, handles the placeholder, handles array reductions (not sure if
Cilk+ means to support them, if not, it should reject them during parsing), but
many other things (e.g. arrange for the ctors/copy ctors/assignment op/dtors to
be made available for the omp lowering purposes on privatization clauses where
needed, diagnosing invalid clause combinations (c_finish_cilk_clauses seems to
only reject the same var being in linear and some other clause, but the
gimplifier/middle-end will be certainly upset about many other duplications,
like
the same var both private and firstprivate, etc.).
So, I'd strongly recommend to just use the OpenMP clause finalization and if
you really need to tweak anything in there for Cilk+ compared to OpenMP rules,
test some cilk flag on those and add sufficient testsuite coverage for that.

As expected, with -fopenmp
#include 

double t1(double* x, int N) {
  double result = 0;
  int i;
#pragma omp simd reduction(max:result) private(i)
  for(int i=0; i

[Bug c++/69362] ICE when doing a pragma reduction with the wrong variable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 CC||jakub at gcc dot gnu.org,
   ||kyukhin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Like for PR69363, this is a bug in bad finalization of Cilk+ clauses.
With -fopenmp and s/simd/omp simd/ I get expected:
/tmp/j.C:3:32: error: user defined reduction not found for ‘x’
 #pragma omp simd reduction(+:x)
^

[Bug c++/69363] ICE when doing a pragma simd reduction with max

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-20
 CC||jakub at gcc dot gnu.org,
   ||kyukhin at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug libstdc++/69386] [6 regression] r232586 breaks mingw-w64 bootstrap

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Hmm, those functions should not be extern "C". Could you please re-run that
compile command for eh_arm.cc with -save-temps and send me the preprocessed
source?

I'll start looking through the mingw-w64 headers for a cause.

[Bug libstdc++/69386] [6 regression] r232586 breaks mingw-w64 bootstrap

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
OK I see the problem, this is a MinGW-w64 bug, but I can solve it in libstdc++.

windows.h includes windef.h which includes minwindef.h which does:

#ifdef __cplusplus
extern "C" {
#endif
...
#include 

and then winnt.h includes  from inside the extern "C" block.

We can add extern "C++" to the libstdc++ headers to ensure our overloads get
the right language linkage even when included inside an extern "C" block.

[Bug c/68513] [5 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL

[mpolacek at gcc dot gnu.org]

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

--- Comment #15 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan 20 11:24:51 2016
New Revision: 232605

URL: https://gcc.gnu.org/viewcvs?rev=232605&root=gcc&view=rev
Log:
PR c/68513
* match.pd ((x & ~m) | (y & m)): Only perform on GIMPLE.

* gcc.dg/pr68513.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr68513.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/match.pd
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c/68513] [5 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #16 from Marek Polacek  ---
Done.

[Bug target/69369] [6 Regression] internal compiler error: in remove_unreachable_nodes, at ipa.c:457

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
I will take a look. It works in my tree with changes to avoid use of
IDENTIFIER_TRANSPARENT_ALIAS.

[Bug libstdc++/69386] [6 regression] r232586 breaks mingw-w64 bootstrap

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Created attachment 37407
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37407&action=edit
Set language linkage for C++ headers

Does this fix it?

[Bug libstdc++/69386] [6 regression] r232586 breaks mingw-w64 bootstrap

[ismail at i10z dot com]

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

--- Comment #4 from İsmail Dönmez  ---
(In reply to Jonathan Wakely from comment #3)
> Created attachment 37407 [details]
> Set language linkage for C++ headers
> 
> Does this fix it?

Yes it does. Thanks!

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
OK, I would say it is bug in gas, too, but I do have patch for "optimizing"
weakrefs into transparent aliases queued for next stage 1.  I will break it out
and re-test.  The only not 100% trivial part is copying the visibility from the
target symbol to weakref. It seems I will need that stuff for MPX anyway.

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #11 from Jan Hubicka  ---
Filled in GAS bug as https://sourceware.org/bugzilla/show_bug.cgi?id=19498 and
will see how much more of transparent alias patchset I need to implement the
weakref->direct reference optimization at GCC side.

[Bug c++/69387] undefined reference to constant in template

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger  ---
Do you mean that is invalid?

class StatusCode
{
public:
  static const int TEST_VALUE = 0x2;
};


I thought it is like defining
const int XXX = 123; which is actually only
a #define not a linker symbol.

I found that syntax in production code,
and it seems to be working everywhere, only
in the template context not, but it is working
other compilers.

We can write this declaration in the .h file

class StatusCode
{
public:
  static const int TEST_VALUE;
};

and have this definition somewhere:
const int StatusCode::TEST_VALUE=2;

that works, but it means something completely different.
The value will be an extern const int in that case.

like

extern const int TEST_VALUE; // in .h file

and

extern const int TEST_VALUE=0x2; // at one place

[Bug libstdc++/69310] [6 Regression] Revision r232454 breaks bootstrap on x86_64-apple-darwin15

[torvald at gcc dot gnu.org]

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

--- Comment #11 from torvald at gcc dot gnu.org ---
(In reply to Jack Howarth from comment #10)
> It is unclear if the changes in r232454, to avoid the explicit linkage on
> libitm, can ever be made darwin-friendly. On darwin, every single executable
> linked against libstdc++ would require -Wl,-undefined,dynamic_lookup on the
> linkage to avoid linkage errors from the undefined symbols from libitm
> within libstdc++.

Is Darwin declaring __GXX_WEAK__?  I suppose that it does because after r232539
the failing code isn't compiled unless __GXX_WEAK__ is supported.  But if it
is, weak references must be supported.  Or are you saying that specifically the
alias attribute is a problem?

If indeed weak references to symbols not declared are a problem, then we
probably should disable the transactional clones the same way we did on AIX,
which doesn't support weak references without definitions either.

What about putting this:

// No support for referencing weak symbols without a definition.
#define _GLIBCXX_USE_WEAK_REF 0

into ./config/os/bsd/darwin/os_defines.h?  This would disable the transactional
clones altogether.  Could you give this a try?

[Bug ipa/66223] [5/6 Regression] Diagnostic of pure virtual function call broken, including __cxa_pure_virtual

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #13 from Jan Hubicka  ---
OK, I will keep the current code as I do not see any noticeable code quality
cost and it makes life developer's life easier.  I will also add logic to
disable devirtualization when the list of possible targets contains one
cxa_pure_virtual and one real target (this is the case where we take advantage
that cxa_pure_virtual call is undefined and we redirect to the real target).

I wonder if we want to redirect into better diagnostics in the cases where we
know the object instance is of a wrong type. In this case -fsanitize=undefined
will claim that __builtin_unreachable was called.  We could do better and
report that the polymorphic call is undefined becuase there is no instance of
an object of the given type or its ancestor.

I also wonder if we don't want to generalize __builtin_unreachable code in
fixup_cfg and friends that elinates all code when we know the execution will
fall into it to sometihng like attribute ((trap)) which can be then assigned to
__builtin_trap and C++ undefined effect cruft (cxa_terminate and
cxa_pure_virtual)

[Bug middle-end/69347] [6 regression] excessive compile time with -O2

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
There is still a big difference between gcc-5 and trunk for this testcase:

gcc-5: 
...
 TOTAL :  27.97 1.2129.21
213855 kB

gcc-6:
...
 tree VRP:   2.01 ( 4%) usr   0.03 ( 2%) sys   2.05 ( 4%) wall
3344102 kB (63%) ggc
...
 dominator optimization  :   1.24 ( 3%) usr   0.01 ( 1%) sys   1.23 ( 2%) wall
1745685 kB (33%) ggc
...
 TOTAL :  48.80 1.5850.39   
5294277 kB

gcc-6 uses 96% more memory and is still 42% slower.

[Bug ipa/69239] [5/6 Regression] g++.dg/ipa/devirt-c-3.C FAILs with -O2 -fPIC --param=early-inlining-insns=196

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
Works for me now.  I believe it was fixed by:
2016-01-13  Jan Hubicka 

PR ipa/66487
* ipa-polymorphic-call.c (inlined_polymorphic_ctor_dtor_block_p):   
use block_ultimate_origin   
(noncall-stmt_may_be_vtbl_ptr_store): Likewise. 

which fixes bugs WRT iterated inlining and/or clonning. I will commit the
testcase next time I do regstrap.

[Bug tree-optimization/69347] [6 regression] excessive compile time with -O2

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Component|middle-end  |tree-optimization
 Resolution|FIXED   |---

--- Comment #9 from Markus Trippelsdorf  ---
Reopening.

[Bug tree-optimization/69359] Warn about constant comparisons between pointers and arrays

[fw at gcc dot gnu.org]

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

--- Comment #2 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #1)
> I'd find warning about p <= weird, warning about p < a makes sense, as well
> as e.g.
> int g (void)
> {
>   int a[3], b;
>   int *p = f (a, &b);
>   return (p < a)
>  + (p < &a[0])
>  + (p > &a[3])
>  + (p < &b)
>  + (p > &b + 1);
> }
> Not a stage4 material though.

Agreed.

>From my perspective, p <= a is suspicious for the same reason why u <= 0 for an
unsigned variable u is suspicious.  If the range of the variable is limited and
the condition can only be true if there is equality, why not use == instead of
<=?  <= suggests that the programmer expected something to happen in the code
which is impossible, which could point to a logic bug or illegal program, and I
think it is fine to warn in such cases.

[Bug tree-optimization/69347] [6 regression] excessive compile time with -O2

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||memory-hog

--- Comment #10 from Markus Trippelsdorf  ---
Forgot to mention: Both gcc-5 and trunk were PGO bootstrapped with
checking=release.

[Bug c++/69355] [5/6 Regression] Wrong results with -O1 optimization

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Reduced testcase:

template  struct A;
template <> struct A<1> {};
template  struct B
{
  template  struct C
  {
typedef T *iterator;
C (iterator p1) : m_iter (p1) {}
void operator, (T p1) { *m_iter = p1; }
iterator m_iter;
  };
  typedef double *iterator;
  B (Obj &p1, double) : m_object (p1) {}
  C operator, (double);
  Obj &m_object;
};
template 
typename B::template C
B::operator, (double p1)
{
  iterator a = m_object.data (), b = a + 1;
  *a = 1;
  *b = p1;
  return C(b + 1);
}
class D {};
inline double operator+(const double &p1, D) { return p1; }
template  class U;
template  struct F
{
  enum { doIt = K < Sz - 1 ? 1 : 0 };
  template 
  static void assign (Dest &p1, Src &p2, Assign &p3)
  {
p3.apply_on (p1 (K), p2 (K));
F::assign (p1, p2, p3);
  }
  template  static double dot (Dest &p1, Src &p2)
  {
return p1 (K) * p2 (K) + F::dot (p1, p2);
  }
};
template <> struct F<0>
{
  template 
  static void assign (Dest &, Src &, Assign &) {}
  template  static D dot (Dest &, Src &) { return D ();
}
};
template  struct G
{
  enum { ops_assign, use_meta };
  G (const E &p1) : m_expr (p1) {}
  double operator()(int p1) const { return m_expr (p1); }
  template 
  static void do_assign (A<1>, Dest &p2, Src &p3, Assign &p4)
  {
F::assign (p2, p3, p4);
  }
  template 
  void assign_to (Dest &p1, const Assign &p2) const
  {
do_assign (A<1>(), p1, *this, p2);
  }
  E m_expr;
};
struct H
{
  static double apply_on (double p1, long double p2) { return p1 / p2; }
  static void apply_on (double & __restrict p1, double p2) { p1 = p2; }
};
template  struct I
{
  I (const E1 &p1, const E2 &p2) : m_lhs (p1), m_rhs (p2) {}
  double operator()(int p1) const
  {
double c = m_lhs (p1);
return H::apply_on (c, m_rhs (0));
  }
  E1 m_lhs;
  const E2 m_rhs;
};
struct J
{
  J (double p1) : m_data (p1) {}
  long double operator()(int) const { return m_data; }
  long double m_data;
};
template  struct K
{
  K (const U &p1) : m_data (p1.data ()) {}
  double operator()(int p1) const { return m_data[p1]; }
  const double *m_data;
};
template  struct U
{
  U () {}
  U (const U &p1)
  {
*this = G(p1.const_ref ());
  }
  B operator=(double) { return B(*this, 0); }
  double *data () { return m_data; }
  const double *data () const { return m_data; }
  double &operator()(int p1) { return m_data[p1]; }
  double operator()(int p1) const { return m_data[p1]; }
  typedef K ConstReference;
  ConstReference const_ref () const { return *this; }
  template  void operator=(const G &p1)
  {
p1.assign_to (*this, H ());
  }
  double m_data[Sz];
};
template 
G, J>, Sz> div (U &p1, double p2)
{
  typedef I, J> expr_type;
  return G(expr_type (p1.const_ref (), p2));
}
template  double norm2 (U &p1)
{
  return __builtin_sqrt (F::dot (p1, p1));
}
template 
G, J>, Sz> operator/(U &p1, double p2)
{
  return div (p1, p2);
}
typedef U<3> V;
V foo (V p1)
{
  double e = norm2 (p1);
  V r;
  r = p1 / e;
  return r;
}
int
main ()
{
  V f;
  f = 1, 2, 3;
  V r = foo (f);
  if (__builtin_fabs (r (0) - 0.267261) > 0.001
  || __builtin_fabs (r (1) - 0.534522) > 0.001
  || __builtin_fabs (r (2) - 0.801784) > 0.001)
__builtin_abort ();
}

[Bug libgomp/40374] OpenMP version needs updating in GCC 4.4.0 manual

[weeks at iastate dot edu]

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

Nathan Weeks  changed:

   What|Removed |Added

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

--- Comment #1 from Nathan Weeks  ---
The man page was apparently updated long ago...

[Bug libstdc++/69388] New: Allow functexcept.cc definitions to be replaced

[redi at gcc dot gnu.org]

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

Bug ID: 69388
   Summary: Allow functexcept.cc definitions to be replaced
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Choosing the non-throwing versions of the __throw_* definitions in
src/c++11/functexcept.cc requires rebuilding libstdc++ with -fno-exceptions,
which is not usually practical.

It would be helpful to allow them to be replaced by the application, so that a
custom libstdc++ isn't needed. Maybe they could be declared weak, and we could
provide an extension header for users to include (or an object file to link to)
that has alternative definitions.

This would mean that even exceptions thrown from inside the compiled library
code (rather than just inline/template code in headers) could be transformed
into abort calls per-application without using a rebuilt libstdc++.so

The Taller Technologies guys are looking into using different multlib builds
for -fexceptions / -fno-exceptions, this might make that unnecesary (at least
for targets that support symbol interposition and/or weak symbols).

[Bug libstdc++/69388] Allow functexcept.cc definitions to be replaced

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
It would also offer a better way for Firefox to do:
https://dxr.mozilla.org/mozilla-central/source/memory/mozalloc/throw_gcc.h

[Bug libstdc++/69386] [6 regression] r232586 breaks mingw-w64 bootstrap

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Wed Jan 20 12:34:25 2016
New Revision: 232607

URL: https://gcc.gnu.org/viewcvs?rev=232607&root=gcc&view=rev
Log:
Ensure C++ language linkage in cmath and cstdlib

PR libstdc++/69386
* include/c_global/ccomplex: Ensure C++ language linkage.
* include/c_global/cmath: Likewise.
* include/c_global/cstdlib: Likewise.
* include/c_global/ctgmath: Likewise.
* testsuite/17_intro/headers/c++2011/linkage.cc: New.

Added:
trunk/libstdc++-v3/testsuite/17_intro/headers/c++2011/linkage.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/c_global/ccomplex
trunk/libstdc++-v3/include/c_global/cmath
trunk/libstdc++-v3/include/c_global/cstdlib
trunk/libstdc++-v3/include/c_global/ctgmath

[Bug libstdc++/69386] [6 regression] r232586 breaks mingw-w64 bootstrap

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
It should be fixed at r232607

[Bug tree-optimization/69328] [6 Regression] ice in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1379 with -O3

[ienkovich at gcc dot gnu.org]

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

--- Comment #7 from Ilya Enkovich  ---
Author: ienkovich
Date: Wed Jan 20 12:37:01 2016
New Revision: 232608

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

PR tree-optimization/69328
* tree-vect-stmts.c (vect_is_simple_cond): Check compared
vectors have same number of elements.
(vectorizable_condition): Fix masked version recognition.

gcc/testsuite/

PR tree-optimization/69328
* gcc.dg/pr69328.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr69328.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug c++/69355] [5/6 Regression] Wrong results with -O1 optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
--- gcc/tree-dfa.c.jj   2016-01-04 14:55:50.0 +0100
+++ gcc/tree-dfa.c  2016-01-20 11:06:15.226682927 +0100
@@ -395,7 +395,7 @@ get_ref_base_and_extent (tree exp, HOST_
   if (mode == BLKmode)
size_tree = TYPE_SIZE (TREE_TYPE (exp));
   else
-   bitsize = int (GET_MODE_PRECISION (mode));
+   bitsize = int (GET_MODE_BITSIZE (mode));
 }
   if (size_tree != NULL_TREE
   && TREE_CODE (size_tree) == INTEGER_CST)

fixes that and DJ has tested it on msp430 without regressions.
As that is consistent with what e.g. get_inner_reference does, I'd prefer to
apply it this way, but I must say I still don't really understand, even on the
simplified testcase, what is going on during SRA there with the shorter access
sizes.
On the reduced testcase there are 7 calls of get_ref_base_and_extent where mode
here is XFmode (one with different precision from bitsize).
 Created a replacement for D.3172 offset: 0, size: 64: SR.24
-Created a replacement for D.3174 offset: 0, size: 64: SR.25
-Created a replacement for D.3592 offset: 0, size: 64: SR.26
-Created a replacement for D.3593 offset: 0, size: 64: SR.27
+Created a replacement for D.3173 offset: 0, size: 128: SR.25
+Created a replacement for D.3174 offset: 0, size: 64: SR.26
+Created a replacement for D.3174 offset: 128, size: 128: SR.27
+Created a replacement for D.3592 offset: 0, size: 64: SR.28
+Created a replacement for D.3593 offset: 0, size: 64: SR.29
is unpatched to patched gcc for the div function.  Is SRA assuming the access
sizes are power of two and misbehaving if it gets access size 80 bits?

[Bug c++/69387] undefined reference to constant in template

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
Oh, now I see, you mean:

C++ Standard, Sec. 9.4.2 paragraph 4 says:
If a static data member is of const integral or const enumeration type, its
declaration in the class definition can specify a constant-initializer which
shall be an integral constant expression (5.19). In that case, the member can
appear in integral constant expressions. The member shall still be defined in a
name-space scope if it is used in the program and the namespace scope
definition shall not contain an initializer.

right?

[Bug testsuite/69371] UNRESOLVED: special_functions/18_riemann_zeta/check_value.cc compilation failed to produce executable

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Lots of other files use that function and don't have those directives either,
e.g. testsuite/special_functions/18_riemann_zeta/compile.cc

Is that also failing?

Could you attach or send me preprocessed source for the failing test?

[Bug c++/69387] undefined reference to constant in template

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Yes. This is a FAQ:
https://gcc.gnu.org/wiki/VerboseDiagnostics#missing_static_const_definition

[Bug c++/69355] [5/6 Regression] Wrong results with -O1 optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #11)
> --- gcc/tree-dfa.c.jj 2016-01-04 14:55:50.0 +0100
> +++ gcc/tree-dfa.c2016-01-20 11:06:15.226682927 +0100
> @@ -395,7 +395,7 @@ get_ref_base_and_extent (tree exp, HOST_
>if (mode == BLKmode)
>   size_tree = TYPE_SIZE (TREE_TYPE (exp));
>else
> - bitsize = int (GET_MODE_PRECISION (mode));
> + bitsize = int (GET_MODE_BITSIZE (mode));
>  }
>if (size_tree != NULL_TREE
>&& TREE_CODE (size_tree) == INTEGER_CST)
> 
> fixes that and DJ has tested it on msp430 without regressions.
> As that is consistent with what e.g. get_inner_reference does, I'd prefer to
> apply it this way, but I must say I still don't really understand, even on
> the simplified testcase, what is going on during SRA there with the shorter
> access sizes.
> On the reduced testcase there are 7 calls of get_ref_base_and_extent where
> mode here is XFmode (one with different precision from bitsize).
>  Created a replacement for D.3172 offset: 0, size: 64: SR.24
> -Created a replacement for D.3174 offset: 0, size: 64: SR.25
> -Created a replacement for D.3592 offset: 0, size: 64: SR.26
> -Created a replacement for D.3593 offset: 0, size: 64: SR.27
> +Created a replacement for D.3173 offset: 0, size: 128: SR.25
> +Created a replacement for D.3174 offset: 0, size: 64: SR.26
> +Created a replacement for D.3174 offset: 128, size: 128: SR.27
> +Created a replacement for D.3592 offset: 0, size: 64: SR.28
> +Created a replacement for D.3593 offset: 0, size: 64: SR.29
> is unpatched to patched gcc for the div function.  Is SRA assuming the
> access sizes are power of two and misbehaving if it gets access size 80 bits?

No, it has various checks to verify % BITS_PER_UNIT is zero but no
unchecked division by it.  Even though the above suggests otherwise.

It must be a more subtle bug.

[Bug c/69389] New: bit field incompatible with OpenMP atomic update

[weeks at iastate dot edu]

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

Bug ID: 69389
   Summary: bit field incompatible with OpenMP atomic update
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: weeks at iastate dot edu
  Target Milestone: ---

gcc 5.2.0 cannot utilize bit fields within an OpenMP atomic update.

Consider the following code (atomic_bitwise_or.c):


#include 

struct BGZF {
unsigned errcode:16, is_write:2, is_be:2;
};

int main(void) {
   struct BGZF A = {0};

#pragma omp parallel
#pragma omp master
#pragma omp atomic update
   A.errcode |= 1;

   if (A.errcode != 1) {
   printf("failed\n");
   return 1;
   } else {
   printf("success\n");
   return 0;
   }
}


When compiled without OpenMP, it produces the expected result:


$ gcc atomic_bitwise_or.c
$ ./a.out
success


However, it fails to compile when OpenMP is enabled:


$ gcc -fopenmp atomic_bitwise_or.c
atomic_bitwise_or.c: In function 'main':
atomic_bitwise_or.c:13:4: error: cannot take address of bit-field 'errcode'
A.errcode |= 1;
^


gcc version info:


$ gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/5.2.0/bin/../snos/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc/5.2.0/snos/libexec/gcc/x86_64-suse-linux/5.2.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../cray-gcc-5.2.0/configure --prefix=/opt/gcc/5.2.0/snos
--disable-nls --libdir=/opt/gcc/5.2.0/snos/lib --enable-languages=c,c++,fortran
--with-gxx-include-dir=/opt/gcc/5.2.0/snos/include/g++
--with-slibdir=/opt/gcc/5.2.0/snos/lib --with-system-zlib --enable-shared
--enable-__cxa_atexit --build=x86_64-suse-linux --with-ppl --with-cloog
Thread model: posix
gcc version 5.2.0 20150716 (Cray Inc.) (GCC)

[Bug c++/69384] defaulted default constructor not defined as deleted for class with a const data member which does not have a user-provided default constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The standard has a defect:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#253

GCC implements the proposed resolution already, this is documented at:
https://gcc.gnu.org/gcc-4.6/changes.html#cplusplus

Other compilers will catch up one day :-)

[Bug c++/69384] defaulted default constructor not defined as deleted for class with a const data member which does not have a user-provided default constructor

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
N.B. if you just do "B b;" you get an error, but "B b{};" explicitly
zero-initializes the entire object, so nothing is left uninitialized.

[Bug c++/69355] [5/6 Regression] Wrong results with -O1 optimization

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
So, without the tree-dfa.c change current trunk in esra transforms:
 G, J>, Sz> div(U&, double) [with int Sz = 3] (struct U & p1,
double p2)
 {
+  const double * SR.27;
+  const double * SR.26;
+  const double * SR.25;
+  const double * SR.24;
   struct ConstReference D.3593;
   struct ConstReference D.3592;
   struct ConstReference D.3172;
   const struct J D.3173;
   struct expr_type D.3174;
   const double * _11;
   long double _12;

   :
   MEM[(struct  &)&D.3173] ={v} {CLOBBER};
   _12 = (long double) p2_2(D);
   D.3173.m_data = _12;
   _11 = &MEM[(const struct U *)p1_4(D)].m_data;
-  MEM[(struct K *)&D.3593] = _11;
-  D.3592 = D.3593;
-  D.3172 = D.3592;
+  SR.27_3 = _11;
+  SR.26_5 = SR.27_3;
+  SR.24_6 = SR.26_5;
   MEM[(struct  &)&D.3174] ={v} {CLOBBER};
-  D.3174.m_lhs = D.3172;
+  SR.25_23 = SR.24_6;
   MEM[(struct J *)&D.3174 + 16B] = D.3173;
   MEM[(struct  &)&] ={v} {CLOBBER};
-  .m_expr = D.3174;
+  MEM[(struct G *)&] = SR.25_23;
   D.3174 ={v} {CLOBBER};
-  D.3172 ={v} {CLOBBER};
   D.3173 ={v} {CLOBBER};
   return ;

 }

ConstReference (aka K<3>) contains a single const double *m_data member (thus
it is likely a DImode struct), J contains a single long double m_data member,
thus it is XFmode struct,
and expr_type is I, which contains two fields, one ConstReference aka K<3>
m_lhs and another one const J m_rhs.  Scalarization of the DImode struct is of
course just fine, and after scalarization the J store into D.3174 still
remains:
MEM[(struct J *)&D.3174 + 16B] = D.3173;
but what is lost is the read of that or store of D.3173 into MEM[(struct G
*)& + 16B].
Compared to this, with patched tree-dfa.c esra changes the same function:
 G, J>, Sz> div(U&, double) [with int Sz = 3] (struct U & p1,
double p2)
 {
+  const double * SR.29;
+  const double * SR.28;
+  long double SR.27;
+  const double * SR.26;
+  long double SR.25;
+  const double * SR.24;
   struct ConstReference D.3593;
   struct ConstReference D.3592;
   struct ConstReference D.3172;
   const struct J D.3173;
   struct expr_type D.3174;
   const double * _11;
   long double _12;

   :
-  MEM[(struct  &)&D.3173] ={v} {CLOBBER};
   _12 = (long double) p2_2(D);
-  D.3173.m_data = _12;
+  SR.25_5 = _12;
   _11 = &MEM[(const struct U *)p1_4(D)].m_data;
-  MEM[(struct K *)&D.3593] = _11;
-  D.3592 = D.3593;
-  D.3172 = D.3592;
-  MEM[(struct  &)&D.3174] ={v} {CLOBBER};
-  D.3174.m_lhs = D.3172;
-  MEM[(struct J *)&D.3174 + 16B] = D.3173;
+  SR.29_6 = _11;
+  SR.28_7 = SR.29_6;
+  SR.24_23 = SR.28_7;
+  SR.26_26 = SR.24_23;
+  SR.27_27 = SR.25_5;
   MEM[(struct  &)&] ={v} {CLOBBER};
-  .m_expr = D.3174;
-  D.3174 ={v} {CLOBBER};
-  D.3172 ={v} {CLOBBER};
-  D.3173 ={v} {CLOBBER};
+  MEM[(struct G *)&] = SR.26_26;
+  MEM[(struct G *)& + 16B] = SR.27_27;
   return ;

 }

i.e. scalarizes also the long double stores and reads (thus, the proposed
tree-dfa.c change would improve it too), but the bug really is that the long
double assignment of
(80 or 96 or 128 bits from D.3174 starting from offset 16 bytes into the struct
into corresponding  field is lost in vanilla trunk.

So, I think we want to change back tree-dfa.c plus fix the SRA bug that causes
this if tree-dfa.c is not changed.
Martin, can you please take over the SRA part?

[Bug c++/69355] [5/6 Regression] Wrong results with -O1 optimization

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Note the above dumps are with -O1 -g0 -fno-asynchronous-unwind-tables
-fno-exceptions (what I've been using in the testsuite reduction).

[Bug fortran/69385] [6 regression] ICE on valid with -fcheck=all

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #2 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed. The ICE appeared between revisions r231990 (2015-12-29, OK) and
> r232451 (2016-01-15, ICE), possibly r232450 (pr64324, ... ).

I can confirm that it is my doing! I am taking a look

I have taken the PR.

Paul

[Bug target/69369] [6 Regression] internal compiler error: in remove_unreachable_nodes, at ipa.c:457

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Jan 20 13:48:49 2016
New Revision: 232612

URL: https://gcc.gnu.org/viewcvs?rev=232612&root=gcc&view=rev
Log:
Require non-x32 target for compile-time MPX tests

Compile-time MPX tests don't need the MPX run-time library.  They
should pass for non-x32 target.

PR testsuite/69369
* g++.dg/pr63995-1.C: Require non-x32 target, instead of,
the MPX run-time library, for compile-time MPX test.
* gcc.target/i386/chkp-always_inline.c: Likewise.
* gcc.target/i386/chkp-bndret.c: Likewise.
* gcc.target/i386/chkp-builtins-1.c: Likewise.
* gcc.target/i386/chkp-builtins-2.c: Likewise.
* gcc.target/i386/chkp-builtins-3.c: Likewise.
* gcc.target/i386/chkp-builtins-4.c: Likewise.
* gcc.target/i386/chkp-const-check-1.c: Likewise.
* gcc.target/i386/chkp-const-check-2.c: Likewise.
* gcc.target/i386/chkp-hidden-def.c: Likewise.
* gcc.target/i386/chkp-label-address.c: Likewise.
* gcc.target/i386/chkp-lifetime-1.c: Likewise.
* gcc.target/i386/chkp-narrow-bounds.c: Likewise.
* gcc.target/i386/chkp-pr69044.c: Likewise.
* gcc.target/i386/chkp-remove-bndint-1.c: Likewise.
* gcc.target/i386/chkp-remove-bndint-2.c: Likewise.
* gcc.target/i386/chkp-strchr.c: Likewise.
* gcc.target/i386/chkp-strlen-1.c: Likewise.
* gcc.target/i386/chkp-strlen-2.c: Likewise.
* gcc.target/i386/chkp-strlen-3.c: Likewise.
* gcc.target/i386/chkp-strlen-4.c: Likewise.
* gcc.target/i386/chkp-strlen-5.c: Likewise.
* gcc.target/i386/chkp-stropt-1.c: Likewise.
* gcc.target/i386/chkp-stropt-10.c: Likewise.
* gcc.target/i386/chkp-stropt-11.c: Likewise.
* gcc.target/i386/chkp-stropt-12.c: Likewise.
* gcc.target/i386/chkp-stropt-13.c: Likewise.
* gcc.target/i386/chkp-stropt-14.c: Likewise.
* gcc.target/i386/chkp-stropt-15.c: Likewise.
* gcc.target/i386/chkp-stropt-16.c: Likewise.
* gcc.target/i386/chkp-stropt-2.c: Likewise.
* gcc.target/i386/chkp-stropt-3.c: Likewise.
* gcc.target/i386/chkp-stropt-4.c: Likewise.
* gcc.target/i386/chkp-stropt-5.c: Likewise.
* gcc.target/i386/chkp-stropt-6.c: Likewise.
* gcc.target/i386/chkp-stropt-7.c: Likewise.
* gcc.target/i386/chkp-stropt-8.c: Likewise.
* gcc.target/i386/chkp-stropt-9.c: Likewise.
* gcc.target/i386/pr63995-2.c: Likewise.
* gcc.target/i386/pr64805.c: Likewise.
* gcc.target/i386/pr65044.c: Likewise.
* gcc.target/i386/pr65167.c: Likewise.
* gcc.target/i386/pr65183.c: Likewise.
* gcc.target/i386/pr65184.c: Likewise.
* gcc.target/i386/thunk-retbnd.c: Likewise.

Modified:
trunk/gcc/testsuite/g++.dg/pr63995-1.C
trunk/gcc/testsuite/gcc.target/i386/chkp-always_inline.c
trunk/gcc/testsuite/gcc.target/i386/chkp-bndret.c
trunk/gcc/testsuite/gcc.target/i386/chkp-builtins-1.c
trunk/gcc/testsuite/gcc.target/i386/chkp-builtins-2.c
trunk/gcc/testsuite/gcc.target/i386/chkp-builtins-3.c
trunk/gcc/testsuite/gcc.target/i386/chkp-builtins-4.c
trunk/gcc/testsuite/gcc.target/i386/chkp-const-check-1.c
trunk/gcc/testsuite/gcc.target/i386/chkp-const-check-2.c
trunk/gcc/testsuite/gcc.target/i386/chkp-hidden-def.c
trunk/gcc/testsuite/gcc.target/i386/chkp-label-address.c
trunk/gcc/testsuite/gcc.target/i386/chkp-lifetime-1.c
trunk/gcc/testsuite/gcc.target/i386/chkp-narrow-bounds.c
trunk/gcc/testsuite/gcc.target/i386/chkp-pr69044.c
trunk/gcc/testsuite/gcc.target/i386/chkp-remove-bndint-1.c
trunk/gcc/testsuite/gcc.target/i386/chkp-remove-bndint-2.c
trunk/gcc/testsuite/gcc.target/i386/chkp-strchr.c
trunk/gcc/testsuite/gcc.target/i386/chkp-strlen-1.c
trunk/gcc/testsuite/gcc.target/i386/chkp-strlen-2.c
trunk/gcc/testsuite/gcc.target/i386/chkp-strlen-3.c
trunk/gcc/testsuite/gcc.target/i386/chkp-strlen-4.c
trunk/gcc/testsuite/gcc.target/i386/chkp-strlen-5.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-1.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-10.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-11.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-12.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-13.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-14.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-15.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-16.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-2.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-3.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-4.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-5.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-6.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-7.c
trunk/gcc/testsuite/gcc.target/i386/chkp-s

[Bug testsuite/69366] All MPX tests are unsupported

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Jan 20 13:51:42 2016
New Revision: 232613

URL: https://gcc.gnu.org/viewcvs?rev=232613&root=gcc&view=rev
Log:
Require non-x32 target for compile-time MPX tests

Compile-time MPX tests don't need the MPX run-time library.  They
should pass for non-x32 target.

PR testsuite/69366
* g++.dg/pr63995-1.C: Require non-x32 target, instead of,
the MPX run-time library, for compile-time MPX test.
* gcc.target/i386/chkp-always_inline.c: Likewise.
* gcc.target/i386/chkp-bndret.c: Likewise.
* gcc.target/i386/chkp-builtins-1.c: Likewise.
* gcc.target/i386/chkp-builtins-2.c: Likewise.
* gcc.target/i386/chkp-builtins-3.c: Likewise.
* gcc.target/i386/chkp-builtins-4.c: Likewise.
* gcc.target/i386/chkp-const-check-1.c: Likewise.
* gcc.target/i386/chkp-const-check-2.c: Likewise.
* gcc.target/i386/chkp-hidden-def.c: Likewise.
* gcc.target/i386/chkp-label-address.c: Likewise.
* gcc.target/i386/chkp-lifetime-1.c: Likewise.
* gcc.target/i386/chkp-narrow-bounds.c: Likewise.
* gcc.target/i386/chkp-pr69044.c: Likewise.
* gcc.target/i386/chkp-remove-bndint-1.c: Likewise.
* gcc.target/i386/chkp-remove-bndint-2.c: Likewise.
* gcc.target/i386/chkp-strchr.c: Likewise.
* gcc.target/i386/chkp-strlen-1.c: Likewise.
* gcc.target/i386/chkp-strlen-2.c: Likewise.
* gcc.target/i386/chkp-strlen-3.c: Likewise.
* gcc.target/i386/chkp-strlen-4.c: Likewise.
* gcc.target/i386/chkp-strlen-5.c: Likewise.
* gcc.target/i386/chkp-stropt-1.c: Likewise.
* gcc.target/i386/chkp-stropt-10.c: Likewise.
* gcc.target/i386/chkp-stropt-11.c: Likewise.
* gcc.target/i386/chkp-stropt-12.c: Likewise.
* gcc.target/i386/chkp-stropt-13.c: Likewise.
* gcc.target/i386/chkp-stropt-14.c: Likewise.
* gcc.target/i386/chkp-stropt-15.c: Likewise.
* gcc.target/i386/chkp-stropt-16.c: Likewise.
* gcc.target/i386/chkp-stropt-2.c: Likewise.
* gcc.target/i386/chkp-stropt-3.c: Likewise.
* gcc.target/i386/chkp-stropt-4.c: Likewise.
* gcc.target/i386/chkp-stropt-5.c: Likewise.
* gcc.target/i386/chkp-stropt-6.c: Likewise.
* gcc.target/i386/chkp-stropt-7.c: Likewise.
* gcc.target/i386/chkp-stropt-8.c: Likewise.
* gcc.target/i386/chkp-stropt-9.c: Likewise.
* gcc.target/i386/pr63995-2.c: Likewise.
* gcc.target/i386/pr64805.c: Likewise.
* gcc.target/i386/pr65044.c: Likewise.
* gcc.target/i386/pr65167.c: Likewise.
* gcc.target/i386/pr65183.c: Likewise.
* gcc.target/i386/pr65184.c: Likewise.
* gcc.target/i386/thunk-retbnd.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #12 from H.J. Lu  ---
(In reply to Jan Hubicka from comment #8)
> .weakrefcallmealias.lto_priv.0,callmesecond 
> 

Please use

.setcallmealias.lto_priv.0,callmesecond
.weakcallmealias.lto_priv.0

if callmesecond is defined.

[Bug c++/69390] New: dynamic_cast on rvalue fails

[colu...@gmx-topmail.de]

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

Bug ID: 69390
   Summary: dynamic_cast on rvalue fails
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colu...@gmx-topmail.de
  Target Milestone: ---

The following code spuriously fails, because a "conversion to non-const
reference type 'struct main()::A&' from rvalue of type 'main()::A'" is
necessitated:

-

int main(){
struct A { virtual ~A() {}; };
struct B : A {} b;
dynamic_cast(static_cast(b));
}

[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 #4 from amker at gcc dot gnu.org ---
(In reply to Igor Zamyatin from comment #3)
> (In reply to amker from comment #2)
> > It's my change, I will look into it.
> 
> Any plans on this?

Sorry for late response, I will try to get to this one in one or two weeks.

[Bug target/68674] ARM/AARCH64 attribute target neon internal compiler error: in copy_to_mode_reg, at explow.c:595

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #15 from chrbr at gcc dot gnu.org ---
*** Bug 68895 has been marked as a duplicate of this bug. ***

[Bug target/68895] [ARM] ICE with target attributes

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from chrbr at gcc dot gnu.org ---
duplicate, expand needs to know the simd type mode. Fix under discussion:

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01429.html

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

[Bug testsuite/69371] UNRESOLVED: special_functions/18_riemann_zeta/check_value.cc compilation failed to produce executable

[3dw4rd at verizon dot net]

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

--- Comment #2 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
On 01/19/2016 10:19 PM, thopre01 at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69371
>
>  Bug ID: 69371
> Summary: UNRESOLVED:
>  special_functions/18_riemann_zeta/check_value.cc
>  compilation failed to produce executable
> Product: gcc
> Version: 6.0
>  Status: UNCONFIRMED
>Severity: normal
>Priority: P3
>   Component: testsuite
>Assignee: unassigned at gcc dot gnu.org
>Reporter: thopre01 at gcc dot gnu.org
>  CC: 3dw4rd at verizon dot net, CaptainSifff at gmx dot de,
>  redi at gcc dot gnu.org
>Target Milestone: ---
>  Target: arm-none-eabi
>
> Hi,
>
> special_functions/18_riemann_zeta/check_value.cc fails to build on
> arm-none-eabi targets with the following error:
>
> libstdc++-v3/testsuite/special_functions/18_riemann_zeta/check_value.cc: In
> function 'void test(const testcase_riemann_zeta (&)[Num], Tp)':
> libstdc++-v3/testsuite/special_functions/18_riemann_zeta/check_value.cc:285:15:
> error: 'riemann_zeta' is not a member of 'std'
>
> Since special_functions/18_riemann_zeta/check_nan.cc builds successfully, I
> suppose that's due to missing one or all of the following directives:
>
> // { dg-require-c-std "" }
> // { dg-add-options ieee }
>
> which are present for check_nan.cc but not for check_value.cc
>
I would expect that the whole special function test suite would fail.
I do remember we had a timeout issue with riemann zeta on some targets.

The message looks more like a header - cmath - is not included or that 
the line
// { dg-options "-D__STDCPP_WANT_MATH_SPEC_FUNCS__" }
or equivalent is not set.

But my fresh checkout has the necessary things..

[Bug testsuite/69366] Compile-time MPX tests may be unsupported

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.4
Summary|All MPX tests are   |Compile-time MPX tests may
   |unsupported |be unsupported

--- Comment #4 from H.J. Lu  ---
(In reply to Ilya Enkovich from comment #1)
> Suppose you mean tests related to i386.exp which misses mpx_init call.  But

MPX tests in i386 are compile-time tests.  The MPX link test may fail

1. If you run

make  check-gcc RUNTESTFLAGS="--target_board='unix{-mx32,-m32,}'
i386.exp=pr65167.c"

2. If the MPX library isn't enabled.

> probably runtime tests should be simply moved into mpx subdir.

There is no MPX run-time test in i386.  They are only in mpx.

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2
   Target Milestone|6.0 |7.0

--- Comment #13 from Jakub Jelinek  ---
Test xfailed for gcc 6, for gcc 7 something should be done about this, but
better in stage1.