[Bug c++/60585] Virtual function related memory access errors with multiple virtual inheritance

[andris.pavenis at iki dot fi]

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

--- Comment #1 from Andris Pavenis  ---
Reproduced also with gcc-5.0 20141123 snapshot on Linux x86_64

[Bug c++/12277] Warn on dynamic casts with known NULL results.

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #9 from Ville Voutilainen  ---
(In reply to Andrew Dixie from comment #7)
> With final, I believe the following dynamic_cast must always return NULL:
> 
> struct a1 { virtual ~a1() {} };
> struct a2 final { virtual ~a2() {} };
> 
> bool test(a1 *x)
> {
> return dynamic_cast(x) != 0;
> }

If a1 is final, sure. Whether a2 is final is irrelevant.

[Bug tree-optimization/64084] [5 Regression] match-and-simplify prefers complex matches

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Author: rguenth
Date: Fri Nov 28 08:57:43 2014
New Revision: 218141

URL: https://gcc.gnu.org/viewcvs?rev=218141&root=gcc&view=rev
Log:
2014-11-28  Richard Biener  

PR middle-end/64084
* genmatch.c (dt_node::gen_kids_1): New function, split out
from dt_node::gen_kids.
(decision_tree::cmp_node): DT_TRUE are generally not equal.
(decision_tree::find_node): Treat DT_TRUE as barrier for
node CSE on the same level.
(dt_node::append_node): Do not keep DT_TRUE last.
(dt_node::gen_kids): Emit code after each DT_TRUE node seen.

* gcc.dg/tree-ssa/ssa-ccp-34.c: New testcase.
* gcc.dg/tree-ssa/forwprop-31.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/forwprop-31.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-34.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/genmatch.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/64084] [5 Regression] match-and-simplify prefers complex matches

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/63790] [5 Regression] Tests XFAILed because of the match-and-simplify merge

[rguenth at gcc dot gnu.org]

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

Bug 64084 Summary: [5 Regression] match-and-simplify prefers complex matches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64084

   What|Removed |Added

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

[Bug c++/64092] when explicit using synthesized move operation (constructor and assignment operator), synthesize move constructor by calling member's copy constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID
Summary|when explicit uing  |when explicit using
   |synthesized move|synthesized move operation
   |operation（constructorand|(constructor and assignment
   |assignment  |operator), synthesize move
   |operator），synthesize move   |constructor by calling
   |constructor by calling  |member's copy constructor
   |member‘s copy constructor。  |

[Bug c/63862] C frontend converts shift-count to int while standard wants integer promotions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed, up to some point.

[Bug c/63862] C frontend converts shift-count to int while standard wants integer promotions

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Nov 28 09:06:48 2014
New Revision: 218142

URL: https://gcc.gnu.org/viewcvs?rev=218142&root=gcc&view=rev
Log:
PR c/63862
c-family/
* c-ubsan.c (ubsan_instrument_shift): Change the type of a MINUS_EXPR
to op1_utype.
* c-gimplify.c (c_gimplify_expr): Convert right operand of a shift
expression to unsigned_type_node.
c/
* c-typeck.c (build_binary_op) : Don't
convert the right operand to integer type.
cp/
* typeck.c (cp_build_binary_op) : Don't
convert the right operand to integer type.
testsuite/
* gcc.c-torture/execute/shiftopt-1.c: Don't XFAIL anymore.
* c-c++-common/ubsan/shift-7.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/shift-7.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-gimplify.c
trunk/gcc/c-family/c-ubsan.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/shiftopt-1.c

[Bug middle-end/63790] [5 Regression] Tests XFAILed because of the match-and-simplify merge

[mpolacek at gcc dot gnu.org]

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

Bug 63862 Summary: C frontend converts shift-count to int while standard wants 
integer promotions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63862

   What|Removed |Added

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

[Bug target/62128] Use vpalignr for AVX2 rotation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Jakub Jelinek  ---
Should be fixed now.

[Bug tree-optimization/64098] New: ICE isl_ctx.c:172: isl_ctx freed, but some objects still referenced

[rguenth at gcc dot gnu.org]

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

Bug ID: 64098
   Summary: ICE isl_ctx.c:172: isl_ctx freed, but some objects
still referenced
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: mircea.namolaru at inria dot fr

#include 
#include 
#include 

uint16_t dhcp_packet_checksum(void * restrict buf, int len) {
  uint32_t sum;
  uint16_t * restrict check;
  int i;
  uint8_t * restrict odd;
  sum = 0;
  check = buf;

for (i = 0; i < len / 2 ; i++)
  sum += check[i];

  if (len & 0x01) {
  odd = buf;
  sum += odd[len - 1]; 
  }

  while (sum >> 16)
  sum = (sum & 0x) + (sum >> 16);
  return ~sum;
  }

int main(void)

{
const uint8_t buf[20] = {
0x45, 0x00, 0x02, 0x40, 0x00, 0x00, 0x00, 0x00,
0x40, 0x11, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0xff, 0xff, 0xff, 0xff
};


return dhcp_packet_checksum(&buf, 20) == be16toh(0x78ae);

}


gcc-5 -Wall $(rpm --eval %optflags) -floop-unroll-and-jam test.c


isl_ctx.c:172: isl_ctx freed, but some objects still reference it
chk.c: In function ‘dhcp_packet_checksum’:
chk.c:5:10: internal compiler error: Abortado
 uint16_t dhcp_packet_checksum(void * restrict buf, int len) {
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/63908] [e500v2] "float_bessel"case failed on e500v2 platforms

[leimaohui at cn dot fujitsu.com]

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

--- Comment #3 from leimaohui  ---
Thanks for joseph's reply.

But I found the reason is the founction "pthread_exit(0)" can't execut
normally。
Because it will lead a SIGABRT signal and aborted .

I wrote a test program and make a test.The enviroment is below:

rootfs: 
http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/machines/p1022ds/core-image-sato-sdk-p1022ds-20141018182842.rootfs.tar.gz

toolchain:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/toolchain/x86_64/poky-glibc-x86_64-core-image-sato-ppce500v2-toolchain-1.7.sh

kernel: 3.14 and 3.4.74 have the same appearance

hostOS: RHEL 6.3

Below is my test program


[root@RHEL6U3 pthread-test]# cat pthread-test.c
#include 
#include 
#include 

pthread_t   tid1, tid2;
void*tret;

void *
thr_fn1(void *arg)
{
sleep(1);

printf("it's thread 1 \n");
pthread_exit(0);

//pthread_join(tid2, &tret);
}

int
main(void)
{
int err;

err = pthread_create(&tid1, NULL, thr_fn1, NULL);
if (err != 0)
printf("can't create thread 1\n");

printf("I will join thread 1... 1\n");
err = pthread_join(tid1, &tret);
if (err != 0)
printf("can't join with thread 1\n");

printf("thread 1 exit code %d\n", (int)tret);
}
[root@RHEL6U3 pthread-test]#.
/opt/poky/1.7/environment-setup-ppce500v2-poky-linux-gnuspe
[root@RHEL6U3 pthread-test]# ${CC} pthread-test.c -lpthread -o pthread-test


And then execut "pthread-test" in e500v2.The result is like below


root@p1022ds:/root# strace -f -o pthread-test.log ./pthread-test
I will join thread 1... 1
it's thread 1
Aborted
root@p1022ds:/root# cat pthread-test.log
...
1009  futex(0xfa999ac, FUTEX_WAKE_PRIVATE, 2147483647) = 0
1009  rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
1009  tgkill(1008, 1009, SIGABRT)   = 0
1009  --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=1008, si_uid=0}
---
1009  +++ killed by SIGABRT +++
1008  +++ killed by SIGABRT +++
root@p1022ds:/root# 
root@p1022ds:/root# 

But I dont't know the root cause. That's the gcc 's bug or the glibc's bug?

[Bug sanitizer/63697] -fsanitize=undefined doesn't detect some subtraction overflows

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/64024] [5 Regression] gcc.dg/vect/vect-simd-clone-6.c ICEs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/64099] New: [5 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

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

Bug ID: 64099
   Summary: [5 Regression] ~15% runtime increase for fatigue.f90.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: hubicka at ucw dot cz, rguenth at gcc dot gnu.org

On x86_64-apple-darwin14, I see a ~15% runtime increase for the polyhedron test
fatigue.f90 on the current trunk (r218134). It is split in two steps. The first
one occurred between r216631 and r216747:

[Book15] lin/test% /opt/gcc/gcc4.10p-216631p3/bin/gfortran -fprotect-parens
-Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program
-flto fatigue.f90
[Book15] lin/test% time a.out > /dev/null
1.373u 0.001s 0:01.37 100.0%0+0k 0+0io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-216747p2/bin/gfortran -fprotect-parens
-Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program
-flto fatigue.f90
[Book15] lin/test% time a.out > /dev/null  
1.462u
0.002s 0:01.47 99.3%0+0k 0+1io 40pf+0w

The second one occurred between r217816 and r217833:

[Book15] lin/test% /opt/gcc/gcc4.10p-217816p2/bin/gfortran -fprotect-parens
-Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program
-flto fatigue.f90
[Book15] lin/test% time a.out > /dev/null  
1.435u
0.002s 0:01.44 99.3%0+0k 0+2io 41pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217833p1/bin/gfortran -fprotect-parens
-Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program
-flto fatigue.f90
[Book15] lin/test% time a.out > /dev/null  
1.582u
0.001s 0:01.58 100.0%0+0k 0+1io 0pf+0w

[Bug c++/64100] New: A static assert using the the current class in a noexcept test leads to a segfault

[ville.voutilainen at gmail dot com]

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

Bug ID: 64100
   Summary: A static assert using the the current class in a
noexcept test leads to a segfault
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.voutilainen at gmail dot com

template struct foo 
{ 
static_assert(noexcept(((foo *)1)->~foo()), ""); 
}; 

template class foo;

Clang diagnoses the use of the constructor of foo as an attempt to
use an incomplete type, gcc segfaults. See
http://melpon.org/wandbox/permlink/Xz0rchej4eij4tOA
for the actual trace.

This looks like a regression, since my build from 20141121 just silently
eats the code. 20141127 produces the segfault.

[Bug target/63661] [4.9/5 Regression] -O2 miscompiles with -mtune=nehalem or corei7

[renlin at gcc dot gnu.org]

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

--- Comment #24 from renlin at gcc dot gnu.org ---
Author: renlin
Date: Fri Nov 28 11:01:27 2014
New Revision: 218143

URL: https://gcc.gnu.org/viewcvs?rev=218143&root=gcc&view=rev
Log:
Add testcase for PR63661.

2014-11-28  Renlin Li  

PR target/63661
* gcc.target/i386/pr63661.c: New test.

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

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-apple-darwin14
   Target Milestone|--- |5.0

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-11-28
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I don't see this on any of our testers.  What CPU do you have and what default
-march gets used for you?  (thus please show -v output)

Btw, -flto should be redundant for a single-file benchmark - -fwhole-program
is enough.  Does -ftree-loop-linear make a difference for you?

Our testers use -ffast-math -funroll-loops -O3.

Can you bisect the regressions to a single commit?

[Bug ada/64055] [5 regression] gnat.dg/derived_aggregate.adb FAILs on 32-bit i386

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
ix86_function_arg_advance calls chkp_type_bounds_count which dies on an array
type with variable bounds so the immediate workaround is:

Index: tree-chkp.c
===
--- tree-chkp.c (revision 218133)
+++ tree-chkp.c (working copy)
@@ -1565,7 +1565,9 @@ chkp_find_bound_slots_1 (const_tree type
   HOST_WIDE_INT esize = TREE_INT_CST_LOW (TYPE_SIZE (etype));
   unsigned HOST_WIDE_INT cur;

-  if (!maxval || integer_minus_onep (maxval))
+  if (!maxval
+ || integer_minus_onep (maxval)
+ || CONTAINS_PLACEHOLDER_P (maxval))
return;

   for (cur = 0; cur <= TREE_INT_CST_LOW (maxval); cur++)

but a specialist needs to have a look here.

[Bug target/64055] [5 regression] gnat.dg/derived_aggregate.adb FAILs on 32-bit i386

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org
  Component|ada |target

--- Comment #5 from Eric Botcazou  ---
Recategorizing.

[Bug libstdc++/64096] std::list, set and map violate a rule about allocator::construct

[palpatin91 at mail dot ru]

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

rylai  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from rylai  ---
Known issues

[Bug libstdc++/64096] std::list, set and map violate a rule about allocator::construct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|WONTFIX |FIXED

--- Comment #3 from Jonathan Wakely  ---
I'm going to mark it fixed, since std::list is fixed, and the other part of the
report is not a bug.

[Bug target/63661] [4.9/5 Regression] -O2 miscompiles with -mtune=nehalem or corei7

[renlin at gcc dot gnu.org]

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

--- Comment #25 from renlin at gcc dot gnu.org ---
Author: renlin
Date: Fri Nov 28 11:18:47 2014
New Revision: 218144

URL: https://gcc.gnu.org/viewcvs?rev=218144&root=gcc&view=rev
Log:
Use native tune. nehalem is not able to triggle the issue in trunk any more.

2014-11-28  Renlin Li  

PR  target/63661
* gcc.target/i386/pr63661.c: Use native tune.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr63661.c

[Bug libstdc++/64096] std::list, set and map violate a rule about allocator::construct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug ipa/63814] [5 Regression] g++.dg/ipa/pr61160-1.C fails with -m32 -fPIC

[jamborm at gcc dot gnu.org]

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

--- Comment #27 from Martin Jambor  ---
(In reply to Dominique d'Humieres from comment #26)
> > I proposed a fix on the mailing list:
> >
> > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02832.html
> 
> I have this patch in my working tree as well as the patch at
> 
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02838.html
> 
> and the regression is gone (x86_64-apple-darwin14).

Thanks for the confirmation, now we just need Honza to approve at
least the first patch if not both.  I will ping them on mailing list
soon.

[Bug target/62231] Exception handling broken on powerpc-e500v2-linux-gnuspe

[manfred.rudigier at omicron dot at]

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

--- Comment #3 from manfred.rudigier at omicron dot at ---
I was probably to enthusiastic, the problem is still there, even in GCC 4.9.2.
In order to reproduce the bug, you either have to use a root file system which
was also built with GCC 4.8.3 or 4.9.2, or you just link the example program
statically (which is probably the easier thing).

The problem does not seem to be in the generated binary of the compiler, but in
one of the used libs (probably libgcc_s.so). So when I link statically with the
"-static" option, I got this stacktrace in gdb:

Program received signal SIGABRT, Aborted.
0x1003d28c in raise ()
(gdb) bt
#0  0x1003d28c in raise ()
#1  0x10018e1c in abort ()
#2  0x100100bc in uw_init_context_1 ()
#3  0x10010cdc in _Unwind_RaiseException ()
#4  0x10001db4 in __cxa_throw ()
at
/home/manrud00/crosstool-ng/.build/src/gcc-4.9.2/libstdc++-v3/libsupc++/eh_throw.cc:82
#5  0x1c94 in doThrow() () at exception.cpp:14
#6  0x1cb8 in main () at exception.cpp:21

[Bug middle-end/64101] New: GCC considers that the erf math function does not set errno

[niva at niisi dot msk.ru]

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

Bug ID: 64101
   Summary: GCC considers that the erf math function does not set
errno
   Product: gcc
   Version: 4.7.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niva at niisi dot msk.ru

Created attachment 34131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34131&action=edit
The preprocessed source of the test program

We use a cross-conpiler configured as follows: 
/home/niva/src/gcc-4.7.4/configure --target=mips64-none-elf --enable-threads=no
--disable-shared --enable-long-long --enable-c99 --enable-languages=c
--enable-multilib --enable-symvers=gnu --disable-libmudflap --disable-libssp
--disable-libgcc_eh --with-newlib --with-dwarf2 --with-system-zlib
--enable-generated-files-in-srcdir --verbose --prefix=/home/niva/local
--enable-cpp

The following program (the preprocessed source is attached)

#include 
#include 
#include 

int main ()
{
   double res;
   errno = 0;
   res = erf (-1.2553634935946022721708238314E-308);
   assert (errno == ERANGE);
   return 0;
}

compiled as

  mips64-none-elf-gcc -O1 tst_erf.c

produces an assertion though we use a POSIX-compliant math
library and the erf function sets errno = ERANGE
according to erf description in POSIX Programmer's Manual.  

The test program works correctly (i.e. without the assertion)
if we compile it with -fno-builtin-erf.

Apparently GCC treats erf as a "clean" or "pure" function
(see gcc/builtins.def). IMHO this is not correct. 

ISO C 99 (see 7.12.8.1) does not state directly whether erf
may set errno. But in 7.12.1 (6) it is stated that
"If the result underflows, the function returns an
implementation-defined value whose magnitude is no greater than the smallest
normalized positive number in the specified type; if the integer expression
math_errhandling & MATH_ERRNO is nonzero, whether errno acquires the
value ERANGE is implementation-defined; if the integer expression
math_errhandling & MATH_ERREXCEPT is nonzero, whether the ‘‘underflow’’
floating-point exception is raised is implementation-defined."

In many Linux erf man pages we read that 
"These functions do not set errno". 

But there is a bug report
https://sourceware.org/bugzilla/show_bug.cgi?id=6785 :
"When erf() is given a subnormal argument, it raises an underflow exception. 
However errno is not set.  It should be set to ERANGE."

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> I don't see this on any of our testers.  What CPU do you have and what default
> -march gets used for you?  (thus please show -v output)

My CPU is a 2.8 GHz Intel Core i7. All the versions reported in comment 0 have
been configured with

../p_work/configure --prefix=/opt/gcc/gcc4.10p-#rev.p#patch
--enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp
--with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto
--enable-plugin --with-arch=core2 --with-cpu=core2

but r216631 for which --enable-checking=release has been omitted. #rev. is the
revision and #patch is the number of patches required to bootstrap.

> Btw, -flto should be redundant for a single-file benchmark - -fwhole-program
> is enough.  

I know, however I have seen in the past some regressions when -flto is added.
Since I can afford to double the compile time, I keep it in my reference
options.

> Does -ftree-loop-linear make a difference for you?

AFAICT it does not on fatigue.f90, but I see some (minor) improvements for
other tests in the suite.

> Our testers use -ffast-math -funroll-loops -O3.

Using '-O3 -ffast-math' instead of '-Ofast' almost double the runtime:

[Book15] lin/test% gfortran -O3 -ffast-math -fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
2.648u 0.002s 0:02.65 99.6%0+0k 0+3io 38pf+0w
[Book15] lin/test% gfortran -Ofast -fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
1.385u 0.002s 0:01.38 100.0%0+0k 0+1io 0pf+0w
[Book15] lin/test% gfc -O3 -ffast-math -fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
2.952u 0.002s 0:02.96 99.6%0+0k 0+0io 40pf+0w
[Book15] lin/test% gfc -Ofast -fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
1.643u 0.001s 0:01.64 100.0%0+0k 0+1io 0pf+0w

(gfortran is 4.9.2 and gfc is 5.0 r218134).

The runtime increase with '-O3 -ffast-math' is ~0.4s between r217816 and
r217833

[Book15] lin/test% /opt/gcc/gcc4.10p-217816p2/bin/gfortran -O3 -ffast-math
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
2.654u 0.002s 0:02.66 99.6%0+0k 0+1io 41pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217833p1/bin/gfortran -O3 -ffast-math
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
2.962u 0.001s 0:02.97 99.6%0+0k 0+1io 39pf+0w

> Can you bisect the regressions to a single commit?

I can do it for the range r217816-r217833 (the candidates are r217824 and
r217827, may be r217828 also). As indicated by the p? in my coding scheme, I
cannot bootstrap in the range r216631-r216747 without at least two patches, so
bisecting this range will take much longer.

[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables

[fxcoudert at gcc dot gnu.org]

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

--- Comment #2 from Francois-Xavier Coudert  ---
Additional (related) issue:

The following program

module precision_module
 implicit none
 integer, parameter :: &
   sp = selected_real_kind( 6,  37)
 integer, parameter :: &
   dp = selected_real_kind(15, 307)
 integer, parameter :: &
   qp = selected_real_kind(30, 291)
end module precision_module

program ch3406

 use precision_module
 use ieee_arithmetic
 implicit none

 real (sp)   :: x0= 0.0
 real (dp)   :: y0= 0.0_dp
 real (qp)   :: z0= 0.0_qp

 real (sp)   :: x1= 1.0
 real (dp)   :: y1= 1.0_dp
 real (qp)   :: z1= 1.0_qp

 real (sp)   :: xnan  = 1.0
 real (dp)   :: ynan  = 1.0_dp
 real (qp)   :: znan  = 1.0_qp

 real (sp)   :: xinfinite = 1.0
 real (dp)   :: yinfinite = 1.0_dp
 real (qp)   :: zinfinite = 1.0_qp

 xinfinite=x1/x0
 yinfinite=y1/y0
 zinfinite=z1/z0
 xnan=x0/x0
 ynan=y0/y0
 znan=z0/z0

 if ( ieee_support_datatype(x1) ) then
   print *,'  32 bit IEEE support'
   print *,' inf ' , ieee_support_inf(x1)
   print *,' nan ' , ieee_support_nan(x1)
   print *,' 1/0 finite',ieee_is_finite(xinfinite)
   print *,' 0/0 nan',ieee_is_nan(xnan)
 endif

 if ( ieee_support_datatype(y1) ) then
   print *,'  64 bit IEEE support'
   print *,' inf ' , ieee_support_inf(y1)
   print *,' nan ' , ieee_support_nan(y1)
   print *,' 1/0 finite',ieee_is_finite(yinfinite)
   print *,' 0/0 nan',ieee_is_nan(ynan)
 endif

 if ( ieee_support_datatype(z1) ) then
   print *,' 128 bit IEEE support'
   print *,' inf ' , ieee_support_inf(z1)
   print *,' nan ' , ieee_support_nan(z1)
   print *,' 1/0 finite',ieee_is_finite(zinfinite)
   print *,' 0/0 nan',ieee_is_nan(znan)
 endif

end program ch3406

generates the following compilation message

d:\document\fortran\third_edition\examples>gfortran ch3406.f90
ch3406.f90:50.26:

   print *,' 1/0 finite',ieee_is_finite(zinfinite)
 1
Error: There is no specific function for the generic 'ieee_is_finite' at (1)
ch3406.f90:51.23:

   print *,' 0/0 nan',ieee_is_nan(znan)
  1
Error: There is no specific function for the generic 'ieee_is_nan' at (1)

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Dominique d'Humieres from comment #2)
> > I don't see this on any of our testers.  What CPU do you have and what 
> > default
> > -march gets used for you?  (thus please show -v output)
> 
> My CPU is a 2.8 GHz Intel Core i7. All the versions reported in comment 0
> have been configured with
> 
> ../p_work/configure --prefix=/opt/gcc/gcc4.10p-#rev.p#patch
> --enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp
> --with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto
> --enable-plugin --with-arch=core2 --with-cpu=core2

Ok, so it is -march=core2

> but r216631 for which --enable-checking=release has been omitted. #rev. is
> the revision and #patch is the number of patches required to bootstrap.
> 
> > Btw, -flto should be redundant for a single-file benchmark - -fwhole-program
> > is enough.  
> 
> I know, however I have seen in the past some regressions when -flto is
> added. Since I can afford to double the compile time, I keep it in my
> reference options.
> 
> > Does -ftree-loop-linear make a difference for you?
> 
> AFAICT it does not on fatigue.f90, but I see some (minor) improvements for
> other tests in the suite.
> 
> > Our testers use -ffast-math -funroll-loops -O3.
> 
> Using '-O3 -ffast-math' instead of '-Ofast' almost double the runtime:

Ugh - -Ofast is an alias for -O3 -ffast-math.  Ah, no - it also enables
--param allow-store-data-races=1 ...

> [Book15] lin/test% gfortran -O3 -ffast-math -fwhole-program fatigue.f90
> [Book15] lin/test% time a.out > /dev/null
> 2.648u 0.002s 0:02.65 99.6%   0+0k 0+3io 38pf+0w
> [Book15] lin/test% gfortran -Ofast -fwhole-program fatigue.f90
> [Book15] lin/test% time a.out > /dev/null
> 1.385u 0.002s 0:01.38 100.0%  0+0k 0+1io 0pf+0w
> [Book15] lin/test% gfc -O3 -ffast-math -fwhole-program fatigue.f90
> [Book15] lin/test% time a.out > /dev/null
> 2.952u 0.002s 0:02.96 99.6%   0+0k 0+0io 40pf+0w
> [Book15] lin/test% gfc -Ofast -fwhole-program fatigue.f90
> [Book15] lin/test% time a.out > /dev/null
> 1.643u 0.001s 0:01.64 100.0%  0+0k 0+1io 0pf+0w
> 
> (gfortran is 4.9.2 and gfc is 5.0 r218134).
> 
> The runtime increase with '-O3 -ffast-math' is ~0.4s between r217816 and
> r217833
> 
> [Book15] lin/test% /opt/gcc/gcc4.10p-217816p2/bin/gfortran -O3 -ffast-math
> -fwhole-program fatigue.f90
> [Book15] lin/test% time a.out > /dev/null
> 2.654u 0.002s 0:02.66 99.6%   0+0k 0+1io 41pf+0w
> [Book15] lin/test% /opt/gcc/gcc4.10p-217833p1/bin/gfortran -O3 -ffast-math
> -fwhole-program fatigue.f90
> [Book15] lin/test% time a.out > /dev/null
> 2.962u 0.001s 0:02.97 99.6%   0+0k 0+1io 39pf+0w
> 
> > Can you bisect the regressions to a single commit?
> 
> I can do it for the range r217816-r217833 (the candidates are r217824 and
> r217827, may be r217828 also). As indicated by the p? in my coding scheme, I
> cannot bootstrap in the range r216631-r216747 without at least two patches,
> so bisecting this range will take much longer.

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Ugh - -Ofast is an alias for -O3 -ffast-math.  Ah, no - it also enables
> --param allow-store-data-races=1 ...

-Ofast
Disregard strict standards compliance. -Ofast enables all -O3 optimizations. It
also enables optimizations that are not valid for all standard-compliant
programs. It turns on -ffast-math and the Fortran-specific -fno-protect-parens
and -fstack-arrays. 

My guess is that -fstack-arrays makes the difference.

[Bug middle-end/64101] GCC considers that the erf math function does not set errno

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, mips64-none-elf
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-28
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I think the issue is that you don't use the result of erf() and the function
is marked as 'const' - thus does not use ATTR_MATHFN_FPROUNDING_ERRNO.
If you make 'res' global then it will work.

[Bug rtl-optimization/63659] [4.8/4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 28 13:32:57 2014
New Revision: 218150

URL: https://gcc.gnu.org/viewcvs?rev=218150&root=gcc&view=rev
Log:
Backported from mainline
2014-10-31  Jakub Jelinek  

PR rtl-optimization/63659
* ree.c (update_reg_equal_equiv_notes): New function.
(combine_set_extension, transform_ifelse): Use it.

* gcc.c-torture/execute/pr63659.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr63659.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ree.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/63913] [5 Regression] ICE: verify_gimple failed: statement marked for throw, but doesn't with -fnon-call-exceptions -fsanitize=bool

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 28 13:34:13 2014
New Revision: 218151

URL: https://gcc.gnu.org/viewcvs?rev=218151&root=gcc&view=rev
Log:
Backported from mainline
2014-11-19  Jakub Jelinek  

PR sanitizer/63913
* ubsan.c: Include tree-eh.h.
(instrument_bool_enum_load): Handle loads that can throw.

* g++.dg/ubsan/pr63913.C: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ubsan/pr63913.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/ubsan.c

[Bug tree-optimization/63915] gomp/pr60823-2.c:31:1: error: dead STMT in EH table

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 28 13:35:28 2014
New Revision: 218152

URL: https://gcc.gnu.org/viewcvs?rev=218152&root=gcc&view=rev
Log:
Backported from mainline
2014-11-19  Jakub Jelinek  

PR tree-optimization/63915
* tree-vect-stmts.c (vectorizable_simd_clone_call): Pass
true instead of false as last argument to gsi_replace.

* c-c++-common/gomp/pr60823-4.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/gomp/pr60823-4.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-vect-stmts.c

[Bug fortran/63938] OpenMP atomic update does not protect access to automatic array

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 28 13:36:36 2014
New Revision: 218153

URL: https://gcc.gnu.org/viewcvs?rev=218153&root=gcc&view=rev
Log:
Backported from mainline
2014-11-24  Jakub Jelinek  

PR fortran/63938
* trans-openmp.c (gfc_trans_omp_atomic): Make sure lhsaddr is
simple enough for goa_lhs_expr_p.

* libgomp.fortran/pr63938-1.f90: New test.
* libgomp.fortran/pr63938-2.f90: New test.

Added:
branches/gcc-4_9-branch/libgomp/testsuite/libgomp.fortran/pr63938-1.f90
branches/gcc-4_9-branch/libgomp/testsuite/libgomp.fortran/pr63938-2.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/trans-openmp.c
branches/gcc-4_9-branch/libgomp/ChangeLog

[Bug preprocessor/60436] [4.8/4.9/5 Regression] C preprocessor segfaults on assembly file

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 28 13:37:13 2014
New Revision: 218154

URL: https://gcc.gnu.org/viewcvs?rev=218154&root=gcc&view=rev
Log:
Backported from mainline
2014-11-25  Jakub Jelinek  

PR preprocessor/60436
* line-map.c (linemap_line_start): If highest is above 0x6000
and we are still tracking columns or highest is above 0x7000,
force add_map.

Modified:
branches/gcc-4_9-branch/libcpp/ChangeLog
branches/gcc-4_9-branch/libcpp/line-map.c

[Bug middle-end/64067] [4.8/4.9/5 Regression] ICE in expand_expr_real_1, at expr.c:10540, involving compound literal shenanigans

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 28 13:38:16 2014
New Revision: 218155

URL: https://gcc.gnu.org/viewcvs?rev=218155&root=gcc&view=rev
Log:
Backported from mainline
2014-11-27  Jakub Jelinek  

PR middle-end/64067
* expr.c (expand_expr_addr_expr_1) :
Handle it by returning address of COMPOUND_LITERAL_EXPR_DECL
not only if modifier is EXPAND_INITIALIZER, but whenever
COMPOUND_LITERAL_EXPR_DECL is non-NULL and TREE_STATIC.

* gcc.c-torture/compile/pr64067.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/compile/pr64067.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/expr.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/64102] New: ARM bootstrap fails with segfault with -mapcs in BOOT_CFLAGS

[ktkachov at gcc dot gnu.org]

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

Bug ID: 64102
   Summary: ARM bootstrap fails with segfault with -mapcs in
BOOT_CFLAGS
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org

I'm seeing a bootstrap segfault in stage2 on arm-none-linux-gnueabihf when
given BOOT_CFLAGS="-O2 -mapcs":

$BUILD/./gcc/xgcc -B$BUILD/./gcc/ -B$BUILD/armv7l-unknown-linux-gnueabihf/bin/
-B$BUILD/armv7l-unknown-linux-gnueabihf/lib/ -isystem
$BUILD/armv7l-unknown-linux-gnueabihf/include -isystem
$BUILD/armv7l-unknown-linux-gnueabihf/sys-include-g -O2 -O2  -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -fPIC -fno-inline -I. -I. -I../.././gcc -I$SRC/libgcc
-I$SRC/libgcc/. -I$SRC/libgcc/../gcc -I$SRC/libgcc/../include  -DHAVE_CC_TLS 
-o _eprintf.o -MT _eprintf.o -MD -MP -MF _eprintf.dep -DL_eprintf -c
$SRC/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS

$SRC/libgcc/libgcc2.c: In function '__eprintf':
$SRC/libgcc/libgcc2.c:2114:3: internal compiler error: Segmentation fault
   fprintf (stderr, string, expression, line, filename);
   ^
0x69c0cf crash_signal
$SRC/gcc/toplev.c:359
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
(kyrtka01@pdtl-cb1)~/builds/gcc-bootstrap-apcs-clean/

This is based on r218090 with configuration:
--with-float=hard --with-cpu=cortex-a15 --with-mode=arm --with-fpu=neon-vfpv4
--enable-languages=c,c++,fortran

Bootstrap without -mapcs works fine.
I don't know if this is a regression, didn't try released compilers.

Can someone please confirm this?

[Bug libstdc++/64103] New: conflicting definitions in parallel/algo.h and algorithmfwd.h

[doko at gcc dot gnu.org]

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

Bug ID: 64103
   Summary: conflicting definitions in parallel/algo.h and
algorithmfwd.h
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

[forwarded from https://bugs.debian.org/770843]

the bug reporter mentions this is accepted by g++, but not by clang++ (using
libstdc++), giving the following error message:

In file included from
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/parallel/algorithm:37:
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/parallel/algo.h:2207:53:
error: redefinition of default argument
   __gnu_parallel::_Parallelism __parallelism_tag
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/parallel/algorithmfwd.h:552:36:
note: previous definition is here
  __gnu_parallel::_Parallelism __parallelism

[Bug bootstrap/64102] ARM bootstrap fails with segfault with -mapcs in BOOT_CFLAGS

[ktkachov at gcc dot gnu.org]

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
attaching gdb for a better back trace:
Program received signal SIGSEGV, Segmentation fault.
0xbeffe4fc in ?? ()
(gdb) bt
#0  0xbeffe4fc in ?? ()
#1  0x001824b8 in build_function_call_vec(unsigned int, vec, tree_node*, vec*,
vec*) ()
at $SRC/gcc/c/c-typeck.c:2967
#2  0x001a433c in c_parser_postfix_expression_after_primary(c_parser*, unsigned
int, c_expr) () at $SRC/gcc/c/c-parser.c:7846
#3  0x001957d4 in c_parser_postfix_expression(c_parser*) () at
$SRC/gcc/c/c-parser.c:7667
#4  0x0019f318 in c_parser_unary_expression(c_parser*) () at
$SRC/gcc/c/c-parser.c:6554
#5  0x0019ff00 in c_parser_cast_expression(c_parser*, c_expr*) () at
$SRC/gcc/c/c-parser.c:6392
#6  0x001a00bc in c_parser_binary_expression(c_parser*, c_expr*, tree_node*) ()
at $SRC/gcc/c/c-parser.c:6207
#7  0x001a0bd0 in c_parser_conditional_expression(c_parser*, c_expr*,
tree_node*) () at $SRC/gcc/c/c-parser.c:5983
#8  0x001a11c0 in c_parser_expr_no_commas(c_parser*, c_expr*, tree_node*) () at
$SRC/gcc/c/c-parser.c:5901
#9  0x001a18e8 in c_parser_expression(c_parser*) () at
$SRC/gcc/c/c-parser.c:7974
#10 0x001a23dc in c_parser_expression_conv(c_parser*) () at
$SRC/gcc/c/c-parser.c:8007
#11 0x001b3e10 in c_parser_statement_after_labels(c_parser*) () at
$SRC/gcc/c/c-parser.c:5067
#12 0x001b58c4 in c_parser_compound_statement_nostart(c_parser*) () at
$SRC/gcc/c/c-parser.c:4676
#13 0x001b6054 in c_parser_compound_statement(c_parser*) () at
$SRC/gcc/c/c-parser.c:4513
#14 0x001b1a2c in c_parser_declaration_or_fndef(c_parser*, bool, bool, bool,
bool, bool, tree_node**, vec) () at
$SRC/gcc/c/c-parser.c:1966
#15 0x001b7678 in c_parser_external_declaration(c_parser*) () at
$SRC/gcc/c/c-parser.c:1436
#16 0x001b804c in c_parse_file() () at $SRC/gcc/c/c-parser.c:1323
#17 0x00213024 in c_common_parse_file() ()
#18 0x0069c11c in compile_file() () at $SRC/gcc/toplev.c:570
#19 0x00139e30 in toplev::main(int, char**) () at $SRC/gcc/toplev.c:2041
#20 0x0013a9a8 in main () at $SRC/gcc/main.c:38
(gdb)

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> My guess is that -fstack-arrays makes the difference.

Confirmed:

[Book15] lin/test% gfc -Ofast -fwhole-program fatigue.f90 -fno-stack-arrays
[Book15] lin/test% time a.out > /dev/null
2.982u 0.001s 0:02.98 100.0%0+0k 0+1io 0pf+0w

[Bug bootstrap/64102] ARM bootstrap fails with segfault with -mapcs in BOOT_CFLAGS

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
My hunch is that this is a miscompile of something earlier in the process

[Bug fortran/64104] New: [F2003][IEEE] Allow IEEE functions in specification expressions

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 64104
   Summary: [F2003][IEEE] Allow IEEE functions in specification
expressions
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org

Reported by James Van Buskirk on comp.lang.fortran:

Have you tested whether gfortran accepts IEEE functions syntactically?
The following should be OK I think, but gfortran shows a lot of errors.

module funcs
   use IEEE_ARITHMETIC
   use IEEE_EXCEPTIONS
   implicit none
   integer, parameter :: ep = selected_real_kind(18,4931)
   integer, parameter :: ik4 = selected_int_kind(9)
   integer, parameter :: ik8 = selected_int_kind(18)
   contains
  subroutine test_specification(x)
 real(ep) x
 integer src(IEEE_SELECTED_REAL_KIND())
 integer datatype(merge(1,2,IEEE_SUPPORT_DATATYPE(x)))
 integer denormal(merge(1,2,IEEE_SUPPORT_DENORMAL(x)))
 integer divide(merge(1,2,IEEE_SUPPORT_DIVIDE(x)))
 integer inf(merge(1,2,IEEE_SUPPORT_INF(x)))
 integer io(merge(1,2,IEEE_SUPPORT_IO(x)))
 integer nan(merge(1,2,IEEE_SUPPORT_NAN(x)))
 integer rounding(merge(1,2,IEEE_SUPPORT_ROUNDING(IEEE_TO_ZERO,x)))
 integer sqrt(merge(1,2,IEEE_SUPPORT_SQRT(x)))
 integer standard(merge(1,2,IEEE_SUPPORT_STANDARD(x)))
 integer 
underflow_control(merge(1,2,IEEE_SUPPORT_UNDERFLOW_CONTROL(x)))
 integer flag(merge(1,2,IEEE_SUPPORT_FLAG(IEEE_INEXACT,x)))
 integer halting(merge(1,2,IEEE_SUPPORT_HALTING(IEEE_INEXACT)))
 src = 1
 write(*,*) 'src',size(src), src
 datatype = 1
 write(*,*) 'datatype',size(datatype),datatype
 denormal = 1
 write(*,*) 'denormal',size(denormal),denormal
 divide = 1
 write(*,*) 'divide',size(divide),divide
 inf = 1
 write(*,*) 'inf',size(inf),inf
 io = 1
 write(*,*) 'io',size(io),io
 nan = 1
 write(*,*) 'nan',size(nan),nan
 rounding = 1
 write(*,*) 'rounding',size(rounding),rounding
 sqrt = 1
 write(*,*) 'sqrt',size(sqrt),sqrt
 standard = 1
 write(*,*) 'standard',size(standard),standard
 underflow_control = 1
 write(*,*) 
'underflow_control',size(underflow_control),underflow_control
 flag = 1
 write(*,*) 'flag',size(flag),flag
 halting = 1
 write(*,*) 'halting',size(halting),halting
  end subroutine test_specification
  subroutine test_constant(x)
 real(ep) x
 real(IEEE_SELECTED_REAL_KIND()) src
 integer(merge(ik4,ik8,IEEE_SUPPORT_DATATYPE(x))) datatype
 integer(merge(ik4,ik8,IEEE_SUPPORT_DENORMAL(x))) denormal
 integer(merge(ik4,ik8,IEEE_SUPPORT_DIVIDE(x))) divide
 integer(merge(ik4,ik8,IEEE_SUPPORT_INF(x))) inf
 integer(merge(ik4,ik8,IEEE_SUPPORT_IO(x))) io
 integer(merge(ik4,ik8,IEEE_SUPPORT_NAN(x))) nan
 integer(merge(ik4,ik8,IEEE_SUPPORT_ROUNDING(IEEE_TO_ZERO,x))) 
rounding
 integer(merge(ik4,ik8,IEEE_SUPPORT_SQRT(x))) sqrt
 integer(merge(ik4,ik8,IEEE_SUPPORT_STANDARD(x))) standard
 integer(merge(ik4,ik8,IEEE_SUPPORT_UNDERFLOW_CONTROL(x))) 
underflow_control
 integer(merge(ik4,ik8,IEEE_SUPPORT_FLAG(IEEE_INEXACT,x))) flag
 integer(merge(ik4,ik8,IEEE_SUPPORT_HALTING(IEEE_INEXACT))) halting
 src = 1
 write(*,*) 'src',kind(src), src
 datatype = 1
 write(*,*) 'datatype',kind(datatype),datatype
 denormal = 1
 write(*,*) 'denormal',kind(denormal),denormal
 divide = 1
 write(*,*) 'divide',kind(divide),divide
 inf = 1
 write(*,*) 'inf',kind(inf),inf
 io = 1
 write(*,*) 'io',kind(io),io
 nan = 1
 write(*,*) 'nan',kind(nan),nan
 rounding = 1
 write(*,*) 'rounding',kind(rounding),rounding
 sqrt = 1
 write(*,*) 'sqrt',kind(sqrt),sqrt
 standard = 1
 write(*,*) 'standard',kind(standard),standard
 underflow_control = 1
 write(*,*) 
'underflow_control',kind(underflow_control),underflow_control
 flag = 1
 write(*,*) 'flag',kind(flag),flag
 halting = 1
 write(*,*) 'halting',kind(halting),halting
  end subroutine test_constant
end module funcs

program ieee
   use funcs
   implicit none
   real(ep) x
   call test_specification(x)
   call test_constant(x)
end program ieee

[Bug testsuite/37630] gcc.dg/20001012-1.c depends on IEEE FP encoding

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Francois-Xavier Coudert  ---
This looks like it's fixed.

[Bug fortran/64104] [F2003][IEEE] Allow IEEE functions in specification expressions

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-11-28
   Assignee|unassigned at gcc dot gnu.org  |fxcoudert at gcc dot 
gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

[Bug c++/64105] New: ICE: in strip_typedefs, at cp/tree.c:1326

[mattipee at yahoo dot co.uk]

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

Bug ID: 64105
   Summary: ICE: in strip_typedefs, at cp/tree.c:1326
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattipee at yahoo dot co.uk

Created attachment 34132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34132&action=edit
simple source file to reproduce

Wasn't expecting this to compile with --std=c++11, but got an ICE (fine with
--std=c++14). Source attached.

From "g++ -v":
  - Target: x86_64-unknown-linux-gnu
  - Configured with: ./configure --enable-languages=c++ --disable-multilib
  - Thread model: posix
  - gcc version 4.9.2 (GCC) 

Happens on both:
  - Linux Mint, 64bit, 3.13.0-24-generic
  - CentOS 5.2, 32bit, 2.6.18-308.el5



user@host ~/crash $ g++ --std=c++11 -Wall -Wextra crash.cpp 
crash.cpp: In function ‘int main()’:
crash.cpp:18:10: warning: use of ‘auto’ in lambda parameter declaration only
available with -std=c++1y or -std=gnu++1y
   X::f([](auto... xs){});
  ^
In file included from crash.cpp:1:0:
/usr/local/include/c++/4.9.2/functional: In substitution of ‘template std::function<_Res(_ArgTypes ...)>::function(_Functor) [with
_Functor = main()::;  =
]’:
crash.cpp:10:8:   required from ‘static void X::f(T) [with T =
main()::]’
crash.cpp:18:24:   required from here
/usr/local/include/c++/4.9.2/functional:2225:9: internal compiler error: in
strip_typedefs, at cp/tree.c:1326
 typename = _Requires<_Callable<_Functor>, void>>
 ^
0x612ef7 strip_typedefs(tree_node*)
../.././gcc/cp/tree.c:1326
0x55961c canonicalize_type_argument
../.././gcc/cp/pt.c:6355
0x574986 type_unification_real
../.././gcc/cp/pt.c:16591
0x577b05 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../.././gcc/cp/pt.c:15933
0x534f01 add_template_candidate_real
../.././gcc/cp/call.c:2998
0x532854 add_template_candidate
../.././gcc/cp/call.c:3095
0x532854 add_candidates
../.././gcc/cp/call.c:5169
0x532bea build_user_type_conversion_1
../.././gcc/cp/call.c:3563
0x5335be implicit_conversion
../.././gcc/cp/call.c:1807
0x5348e2 add_function_candidate
../.././gcc/cp/call.c:2055
0x5327f7 add_candidates
../.././gcc/cp/call.c:5179
0x538759 build_new_method_call_1
../.././gcc/cp/call.c:7807
0x538759 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../.././gcc/cp/call.c:7998
0x5faaf8 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../.././gcc/cp/semantics.c:2318
0x562a44 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:14868
0x5660ac tsubst_expr
../.././gcc/cp/pt.c:14055
0x56517c tsubst_expr
../.././gcc/cp/pt.c:13457
0x565fad tsubst_expr
../.././gcc/cp/pt.c:13648
0x564d62 instantiate_decl(tree_node*, int, bool)
../.././gcc/cp/pt.c:19971
0x57b98b instantiate_pending_templates(int)
../.././gcc/cp/pt.c:20087
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
user@host ~/crash $

[Bug c++/64106] New: [5 Regression][C++14] internal compiler error: in cxx_eval_store_expression

[ai.azuma at gmail dot com]

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

Bug ID: 64106
   Summary: [5 Regression][C++14] internal compiler error: in
cxx_eval_store_expression
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ai.azuma at gmail dot com

Created attachment 34133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34133&action=edit
Output of -v option and preprocessed file

The following code causes an ICE on 5.0.0 20141123 with -std=c++1y.

//==
void f(long &c, int &lc, char *&out)
{
  while (lc >= 8) *out++ = (c >> (lc -= 8));
}
//==

The ICE message is "internal compiler error: in cxx_eval_store_expression",
which is the same as one reported in PR64080, so I suspect that this bug report
could be a dup. However, the above reproducer looks very different than one in
PR64080, so I think this is worth being reported independently.

The above code successfully compiles on GCC 4.9.3 20141119 with -std=c++1y, so
it seems a regression. The reproducer originally comes from an OpenCV 2.4.10
source code.

[Bug rtl-optimization/64037] [4.8/4.9/5 Regression] Miscompilation with -Os and enum class : char parameter

[hjl at gcc dot gnu.org]

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

--- Comment #14 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Nov 28 15:27:55 2014
New Revision: 218161

URL: https://gcc.gnu.org/viewcvs?rev=218161&root=gcc&view=rev
Log:
Pass unpromoted argument to promote_function_mode

This patch updates setup_incoming_promotions in combine.c to match what
is actually passed in assign_parm_setup_reg in function.c.

gcc/

PR rtl-optimization/64037
* combine.c (setup_incoming_promotions): Pass the argument
before any promotions happen to promote_function_mode.

gcc/testsuite/

PR rtl-optimization/64037
* g++.dg/pr64037.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr64037.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/64037] [4.8/4.9 Regression] Miscompilation with -Os and enum class : char parameter

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

Version|4.9.2   |4.8.4
   Target Milestone|4.9.3   |4.8.4
Summary|[4.8/4.9/5 Regression]  |[4.8/4.9 Regression]
   |Miscompilation with -Os and |Miscompilation with -Os and
   |enum class : char parameter |enum class : char parameter

--- Comment #15 from H.J. Lu  ---
Fixed on trunk so far.

[Bug tree-optimization/63941] [5 Regression] ICE on valid code at -O3 and above on x86_64-linux-gnu

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
My patch is responsible for ICE - I did not assume that before if-convert phase
cfg may contain redundant degenerative conditional branches:

:
...
_14 = d[pretmp_51];
if (_14 != 0)
  goto ;
else
  goto ;

  }
  bb_5 (preds = {bb_4 }, succs = {bb_6 })
  {
:

  }
  bb_6 (preds = {bb_5 bb_4 }, succs = {bb_10 bb_7 })

I deleted wrong assert and slightly changed code to set up predicate for join
bb conditionally. With this fix test is compiled successfully.

The patch was sent to GCC community for review.

[Bug target/64055] [5 regression] gnat.dg/derived_aggregate.adb FAILs on 32-bit i386

[enkovich.gnu at gmail dot com]

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

--- Comment #6 from Ilya Enkovich  ---
TREE_INT_CST_LOW (maxval) assumes integer constant anyway.  Therefore we may
use simpler check.  It fixes gnat.dg/derived_aggregate.adb.

diff --git a/gcc/tree-chkp.c b/gcc/tree-chkp.c
index 0fb78cc..84886da 100644
--- a/gcc/tree-chkp.c
+++ b/gcc/tree-chkp.c
@@ -1568,7 +1568,9 @@ chkp_find_bound_slots_1 (const_tree type, bitmap
have_bound,
   HOST_WIDE_INT esize = TREE_INT_CST_LOW (TYPE_SIZE (etype));
   unsigned HOST_WIDE_INT cur;

-  if (!maxval || integer_minus_onep (maxval))
+  if (!maxval
+ || TREE_CODE (maxval) != INTEGER_CST
+ || integer_minus_onep (maxval))
return;

   for (cur = 0; cur <= TREE_INT_CST_LOW (maxval); cur++)

[Bug rtl-optimization/64087] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in in lra_create_live_ranges, at lra-lives.c:1330

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Nov 28 15:39:52 2014
New Revision: 218162

URL: https://gcc.gnu.org/viewcvs?rev=218162&root=gcc&view=rev
Log:
2014-11-28  Vladimir Makarov  

PR rtl-optimization/64087
* lra-lives.c (process_bb_lives): Add debug output.
(lra_create_live_ranges): Don't remove dead insn on the second
call of lra_create_live_ranges_1.

2014-11-28  Vladimir Makarov  

PR rtl-optimization/64087
*  gcc.dg/pr64087.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/pr64087.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-lives.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/64107] New: [F95] Pure function as array size

[fxcoudert at gcc dot gnu.org]

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

Bug ID: 64107
   Summary: [F95] Pure function as array size
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxcoudert at gcc dot gnu.org

Let's consider the code below, which uses a pure function for size of arrays.
This is not allowed for the main program or a module array, as per Fortran
2008's C531:

"An explicit-shape-spec whose bounds are not constant expressions shall appear
only in a subprogram, derived type definition, BLOCK construct, or interface
body."

So we should reject x2 and x4. This should already be handled in
resolve.c:resolve_fl_variable(), but apparently it does not work.

Right now, we incorrectly accept x4, and x2 makes the compiler ICE.


!!!
module m1
contains
  pure integer function foo()
foo = 2
  end function
end module

subroutine test
  use m1
  integer :: x1(foo())
end subroutine

module m
  use m1
  integer :: x2(foo())
contains
  subroutine sub
integer :: x3(foo())
  end subroutine
end module

program p
  use m1
  integer :: x4(foo())
end program
!!!

[Bug fortran/64107] [F95] Pure function as array size

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-28
 Blocks||32834
 Ever confirmed|0   |1
  Known to fail||4.7.4, 4.8.2, 4.9.0, 5.0

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
The second runtime increase (with '-Ofast', the only one with '-O3
-ffast-math') is due to r217827

[Book15] lin/test% /opt/gcc/gcc4.10p-217825p1/bin/gfortran -Ofast
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
[Book15] lin/test% time a.out > /dev/null
1.498u 0.001s 0:01.49 100.0%0+0k 0+1io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217827p1/bin/gfortran -Ofast
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
1.622u 0.001s 0:01.62 100.0%0+0k 0+0io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217825p1/bin/gfortran -O3 -ffast-math
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
2.663u 0.002s 0:02.66 100.0%0+0k 0+2io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217827p1/bin/gfortran -O3 -ffast-math
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
2.964u 0.001s 0:02.96 100.0%0+0k 0+1io 0pf+0w

[Bug rtl-optimization/64087] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in in lra_create_live_ranges, at lra-lives.c:1330

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
Fixed, thanks.

[Bug target/64093] [5 Regression] ICE error: unrecognizable insn with -mcpu=cell

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Author: segher
Date: Fri Nov 28 16:25:33 2014
New Revision: 218164

URL: https://gcc.gnu.org/viewcvs?rev=218164&root=gcc&view=rev
Log:
PR target/64093
* config/rs6000/rs6000.md (and3): Don't generate
and3_imm unless rs6000_gen_cell_microcode is true.

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

[Bug target/64093] [5 Regression] ICE error: unrecognizable insn with -mcpu=cell

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #7 from Segher Boessenkool  ---
Fixed.

[Bug target/64055] [5 regression] gnat.dg/derived_aggregate.adb FAILs on 32-bit i386

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> TREE_INT_CST_LOW (maxval) assumes integer constant anyway.  Therefore we may
> use simpler check.  It fixes gnat.dg/derived_aggregate.adb.

FWIW fine with me.

[Bug libgomp/61200] internal compiler error: Segmentation fault, assert & openmp

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 28 17:03:01 2014
New Revision: 218165

URL: https://gcc.gnu.org/viewcvs?rev=218165&root=gcc&view=rev
Log:
Backported from mainline
2014-10-03  Jakub Jelinek  

PR libgomp/61200
* omp-low.c (taskreg_contexts): New variable.
(scan_omp_parallel): Push newly created context into taskreg_contexts
vector and move record layout code to finish_taskreg_scan.
(scan_omp_task): Likewise.
(finish_taskreg_scan): New function.
(execute_lower_omp): Call finish_taskreg_scan on all taskreg_contexts
vector elements and release it.

* c-c++-common/gomp/pr61200.c: New test.

* testsuite/libgomp.c/pr61200.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/gomp/pr61200.c
branches/gcc-4_8-branch/libgomp/testsuite/libgomp.c/pr61200.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/omp-low.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/libgomp/ChangeLog

[Bug rtl-optimization/63659] [4.8/4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 28 17:03:55 2014
New Revision: 218166

URL: https://gcc.gnu.org/viewcvs?rev=218166&root=gcc&view=rev
Log:
Backported from mainline
2014-10-31  Jakub Jelinek  

PR rtl-optimization/63659
* ree.c (update_reg_equal_equiv_notes): New function.
(combine_set_extension, transform_ifelse): Use it.

* gcc.c-torture/execute/pr63659.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr63659.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/ree.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug fortran/63938] OpenMP atomic update does not protect access to automatic array

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 28 17:04:51 2014
New Revision: 218167

URL: https://gcc.gnu.org/viewcvs?rev=218167&root=gcc&view=rev
Log:
Backported from mainline
2014-11-24  Jakub Jelinek  

PR fortran/63938
* trans-openmp.c (gfc_trans_omp_atomic): Make sure lhsaddr is
simple enough for goa_lhs_expr_p.

* libgomp.fortran/pr63938-1.f90: New test.
* libgomp.fortran/pr63938-2.f90: New test.

Added:
branches/gcc-4_8-branch/libgomp/testsuite/libgomp.fortran/pr63938-1.f90
branches/gcc-4_8-branch/libgomp/testsuite/libgomp.fortran/pr63938-2.f90
Modified:
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/trans-openmp.c
branches/gcc-4_8-branch/libgomp/ChangeLog

[Bug preprocessor/60436] [4.8/4.9/5 Regression] C preprocessor segfaults on assembly file

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 28 17:05:34 2014
New Revision: 218168

URL: https://gcc.gnu.org/viewcvs?rev=218168&root=gcc&view=rev
Log:
Backported from mainline
2014-11-25  Jakub Jelinek  

PR preprocessor/60436
* line-map.c (linemap_line_start): If highest is above 0x6000
and we are still tracking columns or highest is above 0x7000,
force add_map.

Modified:
branches/gcc-4_8-branch/libcpp/ChangeLog
branches/gcc-4_8-branch/libcpp/line-map.c

[Bug middle-end/64067] [4.8/4.9/5 Regression] ICE in expand_expr_real_1, at expr.c:10540, involving compound literal shenanigans

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Nov 28 17:06:23 2014
New Revision: 218169

URL: https://gcc.gnu.org/viewcvs?rev=218169&root=gcc&view=rev
Log:
Backported from mainline
2014-11-27  Jakub Jelinek  

PR middle-end/64067
* expr.c (expand_expr_addr_expr_1) :
Handle it by returning address of COMPOUND_LITERAL_EXPR_DECL
not only if modifier is EXPAND_INITIALIZER, but whenever
COMPOUND_LITERAL_EXPR_DECL is non-NULL and TREE_STATIC.

* gcc.c-torture/compile/pr64067.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/compile/pr64067.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/expr.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/63659] [4.8/4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/63915] gomp/pr60823-2.c:31:1: error: dead STMT in EH table

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed for 4.9.3+.

[Bug fortran/63938] OpenMP atomic update does not protect access to automatic array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug preprocessor/60436] [4.8/4.9/5 Regression] C preprocessor segfaults on assembly file

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/64067] [4.8/4.9/5 Regression] ICE in expand_expr_real_1, at expr.c:10540, involving compound literal shenanigans

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed for 4.8.4+ and 4.9.3+.

[Bug libgomp/61200] internal compiler error: Segmentation fault, assert & openmp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed for 4.8.4+ and 4.9.2+.

[Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-28
 CC||ebotcazou at gcc dot gnu.org
   Target Milestone|--- |4.8.4
Summary|Exception handling broken   |[4.8/4.9 regression]
   |on  |Exception handling broken
   |powerpc-e500v2-linux-gnuspe |on
   ||powerpc-e500v2-linux-gnuspe
 Ever confirmed|0   |1
   Severity|critical|normal

--- Comment #4 from Eric Botcazou  ---
It's a known issue:
  https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02625.html
and
  https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02605.html
have the complete fix I think.

[Bug target/62231] [4.8/4.9 regression] Exception handling broken on powerpc-e500v2-linux-gnuspe

[asolokha at gmx dot com]

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

--- Comment #5 from Arseny Solokha  ---
(In reply to manfred.rudigier from comment #3)
> In order to reproduce the bug, you either have to use a root file
> system which was also built with GCC 4.8.3 or 4.9.2, or you just link the
> example program statically (which is probably the easier thing).

My root file system was built w/ 4.10.0 snapshot back in March when it hadn't
yet diverged significantly from 4.9, so it's hardly a requirement. I'll try
however to link the test case statically in Monday.

[Bug target/63908] [e500v2] "float_bessel"case failed on e500v2 platforms

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
In such a case you need to debug the system as a whole until you have 
isolated the bug to one component and can then report it to that component 
with evidence for where the bug is.

It's quite possible pthread_exit could run into unwind info problems - 
make sure you have Olivier Hainque's patches 
 backported, 
together with my fix

2014-10-25  Joseph Myers  

* config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Do
not allow e500 double in registers not satisyfing
SPE_SIMD_REGNO_P.

before unwinding will work for e500v2 with 4.9.

[Bug target/64061] [5 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:894 with -O2 -g -fno-dce -fno-tree-dce

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Nov 28 19:33:35 2014
New Revision: 218171

URL: https://gcc.gnu.org/viewcvs?rev=218171&root=gcc&view=rev
Log:
2014-11-28  Vladimir Makarov  

PR target/64061
* lra.c (lra_substitute_pseudo): Ignore constant with int mode for
subreg.

2014-11-28  Vladimir Makarov  

PR target/64061
* gcc.target/i386/pr64061.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr64061.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/64099] [5 Regression] ~15% runtime increase for fatigue.f90.

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
The first runtime increase (with '-Ofast') is due to r216728:

[Book15] lin/test% /opt/gcc/gcc4.10p-216727p2/bin/gfortran -Ofast
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
1.380u 0.001s 0:01.38 100.0%0+0k 0+1io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-216728p2/bin/gfortran -Ofast
-fwhole-program fatigue.f90
[Book15] lin/test% time a.out > /dev/null
1.500u 0.001s 0:01.50 100.0%0+0k 0+2io 0pf+0w

I also confirm it for the test fatigue2.f90 of the pb11 test suite:

[Book15] lin/test% /opt/gcc/gcc4.10p-216727p2/bin/gfortran -Ofast
-fwhole-program fatigue2.f90
[Book15] lin/test% time a.out > /dev/null
28.473u 0.005s 0:28.48 99.9%0+0k 0+3io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-216728p2/bin/gfortran -Ofast
-fwhole-program fatigue2.f90
[Book15] lin/test% time a.out > /dev/null
30.699u 0.006s 0:30.71 99.9%0+0k 0+1io 40pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217825p1/bin/gfortran -Ofast
-fwhole-program fatigue2.f90
[Book15] lin/test% time a.out > /dev/null
30.840u 0.006s 0:30.84 100.0%0+0k 0+4io 0pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217827p1/bin/gfortran -Ofast
-fwhole-program fatigue2.f90
[Book15] lin/test% time a.out > /dev/null
33.387u 0.005s 0:33.39 99.9%0+0k 0+2io 0pf+0w

[Book15] lin/test% /opt/gcc/gcc4.10p-217825p1/bin/gfortran -O3 -ffast-math
-fwhole-program fatigue2.f90
[Book15] lin/test% time a.out > /dev/null
54.750u 0.013s 0:54.77 99.9%0+0k 0+6io 41pf+0w
[Book15] lin/test% /opt/gcc/gcc4.10p-217827p1/bin/gfortran -O3 -ffast-math
-fwhole-program fatigue2.f90
[Book15] lin/test% time a.out > /dev/null
62.117u 0.039s 1:02.18 99.9%0+0k 1+6io 53pf+0w

[Bug libstdc++/63497] std::regex can't handle [^class] correctly and cause runtime crash

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

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

--- Comment #9 from Tim Shen  ---
Mark as resolved

[Bug libstdc++/63199] Inserting std::wregex to std::vector loses some std::wregex values

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

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

--- Comment #5 from Tim Shen  ---
Mark as resolved

[Bug target/64108] New: ICE: SIGSEGV in decide_alg() with -mmemset-strategy=libcall:-1:align -minline-all-stringops

[zsojka at seznam dot cz]

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

Bug ID: 64108
   Summary: ICE: SIGSEGV in decide_alg() with
-mmemset-strategy=libcall:-1:align
-minline-all-stringops
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 34134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34134&action=edit
preprocessed source (gcc.target/i386/memset-strategy-1.c)

Compiler output:
$ gcc -mmemset-strategy=libcall:-1:align -minline-all-stringops
memset-strategy-1.i -wrapper valgrind,-q
==13391== Stack overflow in thread 1: can't grow stack to 0xffe001ff8
==13391== Can't extend stack to 0xffe0010a8 during signal delivery for thread
1:
==13391==   no stack segment
==13391== 
==13391== Process terminating with default action of signal 11 (SIGSEGV)
==13391==  Access not within mapped region at address 0xFFE0010A8
==13391==at 0xF047D2: decide_alg(long, long, unsigned long, unsigned long,
bool, bool, int*, bool*) (i386.c:24370)
==13391==  If you believe this happened as a result of a stack
==13391==  overflow in your program's main thread (unlikely but
==13391==  possible), you can try to increase the size of the
==13391==  main thread stack using the --main-stacksize= flag.
==13391==  The main thread stack size used in this run was 16777216.
==13391== Stack overflow in thread 1: can't grow stack to 0xffe001f71
==13391== 
==13391== Process terminating with default action of signal 11 (SIGSEGV)
==13391==  Access not within mapped region at address 0xFFE001F71
==13391==at 0x4A236B0: _vgnU_freeres (in
/usr/lib64/valgrind/vgpreload_core-amd64-linux.so)
==13391==  If you believe this happened as a result of a stack
==13391==  overflow in your program's main thread (unlikely but
==13391==  possible), you can try to increase the size of the
==13391==  main thread stack using the --main-stacksize= flag.
==13391==  The main thread stack size used in this run was 16777216.
gcc: internal compiler error: Segmentation fault (program valgrind)
0x40bff5 execute
/mnt/svn/gcc-trunk/gcc/gcc.c:2912
0x40c289 do_spec_1
/mnt/svn/gcc-trunk/gcc/gcc.c:4841
0x40e887 process_brace_body
/mnt/svn/gcc-trunk/gcc/gcc.c:6124
0x40e887 handle_braces
/mnt/svn/gcc-trunk/gcc/gcc.c:6038
0x40d287 do_spec_1
/mnt/svn/gcc-trunk/gcc/gcc.c:5495
0x40e887 process_brace_body
/mnt/svn/gcc-trunk/gcc/gcc.c:6124
0x40e887 handle_braces
/mnt/svn/gcc-trunk/gcc/gcc.c:6038
0x40d287 do_spec_1
/mnt/svn/gcc-trunk/gcc/gcc.c:5495
0x40c613 do_spec_1
/mnt/svn/gcc-trunk/gcc/gcc.c:5610
0x40e887 process_brace_body
/mnt/svn/gcc-trunk/gcc/gcc.c:6124
0x40e887 handle_braces
/mnt/svn/gcc-trunk/gcc/gcc.c:6038
0x40d287 do_spec_1
/mnt/svn/gcc-trunk/gcc/gcc.c:5495
0x40e887 process_brace_body
/mnt/svn/gcc-trunk/gcc/gcc.c:6124
0x40e887 handle_braces
/mnt/svn/gcc-trunk/gcc/gcc.c:6038
0x40d287 do_spec_1
/mnt/svn/gcc-trunk/gcc/gcc.c:5495
0x40e887 process_brace_body
/mnt/svn/gcc-trunk/gcc/gcc.c:6124
0x40e887 handle_braces
/mnt/svn/gcc-trunk/gcc/gcc.c:6038
0x40d287 do_spec_1
/mnt/svn/gcc-trunk/gcc/gcc.c:5495
0x40e887 process_brace_body
/mnt/svn/gcc-trunk/gcc/gcc.c:6124
0x40e887 handle_braces
/mnt/svn/gcc-trunk/gcc/gcc.c:6038
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
r218137 - ICE
4_9 r216937 - ICE

[Bug target/63661] [4.9/5 Regression] -O2 miscompiles with -mtune=nehalem or corei7

[vbraun.name at gmail dot com]

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

--- Comment #26 from Volker Braun  ---
I can confirm that r217783 fixes the original issue on in the GSL testsuite on
OSX Yosemite, too.

[Bug c++/60372] incorrect destruction order for function parameter objects

[harald at gigawatt dot nl]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #1 from Harald van Dijk  ---
This has recently come up on StackOverflow twice, and perhaps it's useful to
mention here too that this is core language issue 1880
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1880), according
to which GCC's current behaviour is to be made valid.

[Bug preprocessor/41698] "\uFFFF" converts incorrectly to two-byte character

[jsm28 at gcc dot gnu.org]

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

--- Comment #4 from Joseph S. Myers  ---
Author: jsm28
Date: Sat Nov 29 01:56:06 2014
New Revision: 218179

URL: https://gcc.gnu.org/viewcvs?rev=218179&root=gcc&view=rev
Log:
Fix off-by-one bug in utf16 conversion (PR preprocessor/41698).

libcpp:
2014-11-29  John Schmerge  

PR preprocessor/41698
* charset.c (one_utf8_to_utf16): Do not produce surrogate pairs
for 0x.

gcc/testsuite:
2014-11-29  Joseph Myers  

PR preprocessor/41698
* gcc/testsuite/g++.dg/cpp/utf16-pr41698-1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp/utf16-pr41698-1.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/charset.c

[Bug preprocessor/41698] "\uFFFF" converts incorrectly to two-byte character

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #5 from Joseph S. Myers  ---
Fixed for GCC 5.

[Bug target/55212] [SH] Switch to LRA

[kkojima at gcc dot gnu.org]

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

--- Comment #85 from Kazumoto Kojima  ---
Created attachment 34135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34135&action=edit
patch to add -mlra option

I'd like to apply the patch to add a transitional option -mlra
like ARM and the revised patches in c#78 and c#83 on sh-lra branch
after merge from trunk.  It helps me a lot when building, comparing
and testing sh-lra compilers.

[Bug c++/64110] New: ICE: Max. number of generated reload insns per insn is achieved (90)

[thiago at kde dot org]

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

Bug ID: 64110
   Summary: ICE: Max. number of generated reload insns per insn is
achieved (90)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org

When compiling the attached preprocessed sources, GCC 5 (trunk r218173) prints
the following:

/home/thiago/src/qt/qt5/qtbase/src/corelib/tools/qstringargbuilder.cpp: In
function ‘replaceArgEscapes(QString const&, ArgEscapeData const&, int, QString
const&, QString const&, QChar)’:
/home/thiago/src/qt/qt5/qtbase/src/corelib/tools/qstringargbuilder.cpp:236:1:
internal compiler error: Max. number of generated reload insns per insn is
achieved (90)

 }
 ^
0xb58ff0 lra_constraints(bool)
/home/thiago/src/gcc/gcc/lra-constraints.c:4225
0xb48f01 lra(_IO_FILE*)
/home/thiago/src/gcc/gcc/lra.c:2277
0xb08109 do_reload
/home/thiago/src/gcc/gcc/ira.c:5391
0xb08109 execute
/home/thiago/src/gcc/gcc/ira.c:5561

Original command-line:
g++ -c -pipe -pipe -march=core-avx2 -mno-rtm -mno-hle -std=c++0x -pthread -O3
-g -maccumulate-outgoing-args -O3 -fvisibility=hidden
-fvisibility-inlines-hidden -std=c++0x -flto -ffat-lto-objects -Wall -W -Werror
-Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow
-D_REENTRANT -fPIC -DQT_NO_USING_NAMESPACE -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05
-DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" -DQT_USE_ICU -DQT_CORE_LIB
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG
-I/home/thiago/src/qt/qt5/qtbase/mkspecs/linux-g++-optimised
-I/home/thiago/src/qt/qt5/qtbase/src/corelib -I../../include
-I../../include/QtCore -I../../include/QtCore/5.4.0
-I../../include/QtCore/5.4.0/QtCore -Iglobal
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/harfbuzz/src
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/md5
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/md4
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/sha3
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/forkfd -isystem
/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I.moc -I.
/home/thiago/src/qt/qt5/qtbase/src/corelib/tools/qstringargbuilder.cpp -o
.obj/qstringargbuilder.o

Minimal command-line for the .ii source:
g++ -c -march=core-avx2 -mno-rtm -mno-hle -std=c++0x -pthread -O3 -D_REENTRANT
-fPIC qstringargbuilder.ii -o .obj/qstringargbuilder.o

If I remove the -march=core-avx2 option and compile the original .cpp file,
there is no error.

[Bug c++/64111] New: [5.0 regression] ICE: conversion of register to a different size

[thiago at kde dot org]

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

Bug ID: 64111
   Summary: [5.0 regression] ICE: conversion of register to a
different size
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org

When compiling the attached preprocessed source, GCC 5 (trunk 218173) prints
the following ICE:

/home/thiago/src/qt/qt5/qtbase/src/corelib/io/qresource.cpp: In member function
‘QResourceRoot::findNode(QString const&, QLocale const&) const’:
/home/thiago/src/qt/qt5/qtbase/src/corelib/io/qresource.cpp:616:5: error:
conversion of register to a different size
 int QResourceRoot::findNode(const QString &_path, const QLocale &locale) const
 ^
VIEW_CONVERT_EXPR(vect__655.937_1129);

vect__656.938_1127 = VIEW_CONVERT_EXPR(vect__655.937_1129);
/home/thiago/src/qt/qt5/qtbase/src/corelib/io/qresource.cpp:616:5: error:
conversion of register to a different size
VIEW_CONVERT_EXPR(vect__655.937_1128);

vect__656.938_1126 = VIEW_CONVERT_EXPR(vect__655.937_1128);
/home/thiago/src/qt/qt5/qtbase/src/corelib/io/qresource.cpp:616:5: internal
compiler error: verify_gimple failed
0xcc5cd1 verify_gimple_in_cfg(function*, bool)
/home/thiago/src/gcc/gcc/tree-cfg.c:5049
0xbcbe3f execute_function_todo
/home/thiago/src/gcc/gcc/passes.c:1940
0xbcc713 execute_todo
/home/thiago/src/gcc/gcc/passes.c:1997

Original command-line:
g++ -c -include .pch/Qt5Core -pipe -pipe -march=core-avx2 -mno-rtm -mno-hle
-std=c++0x -pthread -O3 -g -maccumulate-outgoing-args -O3 -fvisibility=hidden
-fvisibility-inlines-hidden -std=c++0x -flto -ffat-lto-objects -Wall -W -Werror
-Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow
-D_REENTRANT -fPIC -DQT_NO_USING_NAMESPACE -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05
-DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" -DQT_USE_ICU -DQT_CORE_LIB
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG
-I/home/thiago/src/qt/qt5/qtbase/mkspecs/linux-g++-optimised
-I/home/thiago/src/qt/qt5/qtbase/src/corelib -I../../include
-I../../include/QtCore -I../../include/QtCore/5.4.0
-I../../include/QtCore/5.4.0/QtCore -Iglobal
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/harfbuzz/src
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/md5
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/md4
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/sha3
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/forkfd -isystem
/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I.moc -I. -o
.obj/qresource.o /home/thiago/src/qt/qt5/qtbase/src/corelib/io/qresource.cpp

This error disappears when the -include $(PCH) option is removed. Here's the
command-line for the precompilation:
g++ -pipe -pipe -march=core-avx2 -mno-rtm -mno-hle -std=c++0x -pthread -O3 -g
-maccumulate-outgoing-args -O3 -fvisibility=hidden -fvisibility-inlines-hidden
-std=c++0x -flto -ffat-lto-objects -Wall -W -Werror -Wno-error=cpp
-Wno-error=deprecated-declarations -Wno-error=strict-overflow -D_REENTRANT
-fPIC -DQT_NO_USING_NAMESPACE -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT
-DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05
-DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" -DQT_USE_ICU -DQT_CORE_LIB
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG
-I/home/thiago/src/qt/qt5/qtbase/mkspecs/linux-g++-optimised
-I/home/thiago/src/qt/qt5/qtbase/src/corelib -I../../include
-I../../include/QtCore -I../../include/QtCore/5.4.0
-I../../include/QtCore/5.4.0/QtCore -Iglobal
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/harfbuzz/src
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/md5
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/md4
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/sha3
-I/home/thiago/src/qt/qt5/qtbase/src/3rdparty/forkfd -isystem
/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I.moc -I. -x c++-header -c
/home/thiago/src/qt/qt5/qtbase/src/corelib/global/qt_pch.h -o
.pch/Qt5Core.gch/c++

[Bug c++/64111] [5.0 regression] ICE: conversion of register to a different size

[thiago at kde dot org]

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

--- Comment #1 from Thiago Macieira  ---
Created attachment 34136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34136&action=edit
Preprocessed output for the source file with the problem

[Bug c++/64110] ICE: Max. number of generated reload insns per insn is achieved (90)

[thiago at kde dot org]

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

--- Comment #1 from Thiago Macieira  ---
Created attachment 34138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34138&action=edit
Preprocessed sources for the build error

[Bug c++/64111] [5.0 regression] ICE: conversion of register to a different size

[thiago at kde dot org]

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

--- Comment #2 from Thiago Macieira  ---
Created attachment 34137
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34137&action=edit
Preprocessed output for the precompilation header

[Bug regression/64112] New: Optimized away string literal leads to a core dump

[fhansen at rocketmail dot com]

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

Bug ID: 64112
   Summary: Optimized away string literal leads to a core dump
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fhansen at rocketmail dot com

The following program prints "str" when compiled without optimizations but core
dumps when compiled with GCC 4.8.0 and optimization level -O2.

The compilation command used: g++ -O2 test.cpp

#include 

class X {
public:
  X(const char* str) : str_(str) {}
  const char* str_;
};

class Y {
public:
  Y(const X& x) : x_(x) {}
  void print() const { printf("%s\n", x_.str_); }

private:
  const X& x_;
};

int main() {
  Y y("str");
  y.print();
}

This appears to be a regression in 4.8.

Version and target:
g++ (GCC) 4.8.0
i686-pc-linux-gnu

[Bug regression/64112] Optimized away string literal leads to a core dump

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
  Y y("str");


Produces a temporary X which is destroyed after the statement as the life time
is not extended.

[Bug c++/64110] ICE: Max. number of generated reload insns per insn is achieved (90)

[thiago at kde dot org]

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

--- Comment #2 from Thiago Macieira  ---
creduce reduced to the following testcase:


class A {
public:
  short &m_fn1() { return ucs; }
  short ucs;
};

class C {
public:
  int m_fn2();
} a;
A *b;
C c;
void fn1(A p1) {
  while (&a) {
int d = c.m_fn2();
for (int i; i < d; ++i)
  b++->m_fn1() = p1.m_fn1();
  }
}

[Bug c++/64110] ICE: Max. number of generated reload insns per insn is achieved (90)

[thiago at kde dot org]

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

--- Comment #3 from Thiago Macieira  ---
This reduced testcase starts (apparently) with an uninitialised int i, but the
same problem happens if you initialise to 0 (for (int i = 0; i < d; ++i))

[Bug target/64113] New: Gcc on Alpha: Error: No lda !gpdisp!282 was found

[mcree at orcon dot net.nz]

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

Bug ID: 64113
   Summary: Gcc on Alpha: Error: No lda !gpdisp!282 was found
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcree at orcon dot net.nz
Target: alpha-linux-gnu

gcc-4.9.x (and the trunk a couple of weeks ago) compiling certain software
packages (e.g. systemd) on an Alpha running Debian Alpha Linux results in
errors at the link stage such as:

{standard input}: Assembler messages:
{standard input}:5327: Error: No lda !gpdisp!282 was found
lto-wrapper: gcc returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

These packages are successfully compiled with gcc-4.8.x.  

I have not been able to construct a minimal source exhibiting the problem.  But
because gcc-4.9.0 exhibits the failure and gcc-4.8.0 compiles the code
successfully I have been able to bisect to the first commit in gcc that
produces those errors, and that commit is:

commit c59258dcb37171743fdc6d393e767834aac9642b
Author: law 
Date:   Tue Nov 12 16:41:51 2013 +

* gimple-ssa-isolate-paths.c (check_loadstore): New function.
(insert_trap_and_remove_trailing_statements): New argument OP which
is the NULL pointer.  Emit the trap after the load/store through
the NULL pointer.  Simplify the RHS of a store through a NULL pointer
when trivial to do so.
(isolate_path): Corresponding changes.
(gimple_ssa_isolate_erroneous_path): Likewise.

* gcc.dg/tree-ssa/isolate-1.c: Update expected output.
* gcc.dg/tree-ssa/isolate-5.c: New test.

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