[Bug ipa/64325] New: [5 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Bug ID: 64325
   Summary: [5 Regression] ICE: Segmentation fault
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
 Build: powerpc64-unknown-linux-gnu

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

On ppc64 I get:

trippels@gcc2-power8 tools % g++ -c -O2 -std=c++11 regression_word_count.ii
regression_word_count.ii:183:55: internal compiler error: Segmentation fault
 int main () { word_count_grammar g (main_word_count); }
   ^
0x109d39eb crash_signal
../../gcc/gcc/toplev.c:358
0x1051bbb0 symtab_node::get_alias_target()
../../gcc/gcc/cgraph.h:2250
0x1051bbb0 symtab_node::verify_base()
../../gcc/gcc/symtab.c:1123
0x10528883 cgraph_node::verify_node()
../../gcc/gcc/cgraph.c:2747
0x1051c0a7 symtab_node::verify()
../../gcc/gcc/symtab.c:1154
0x1051c6f7 symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.c:1174
0x107e0fc7 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc/gcc/ipa.c:655
0x1101fe97 ipa_inline
../../gcc/gcc/ipa-inline.c:2196
0x1101fe97 execute
../../gcc/gcc/ipa-inline.c:2562
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

This issue might be related to PR64068.

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[trippels at gcc dot gnu.org]

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

Bug 63397 Summary: signed integer overflows in ira.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63397

   What|Removed |Added

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

[Bug rtl-optimization/63397] signed integer overflows in ira.c

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
Fixed. Thanks.

[Bug target/64217] LRA: generate wrong liveness info after r217947 for clobber in jump_insn

[jasonwucj at gcc dot gnu.org]

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

Chung-Ju Wu  changed:

   What|Removed |Added

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

--- Comment #4 from Chung-Ju Wu  ---
Fixed.

[Bug target/64217] LRA: generate wrong liveness info after r217947 for clobber in jump_insn

[jasonwucj at gcc dot gnu.org]

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

--- Comment #3 from Chung-Ju Wu  ---
Author: jasonwucj
Date: Tue Dec 16 06:22:35 2014
New Revision: 218774

URL: https://gcc.gnu.org/viewcvs?rev=218774&root=gcc&view=rev
Log:
PR target/64217
* config/nds32/nds32.md (casesi_internal): Add '=r' for clobber
register constraint.

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

[Bug fortran/64324] New: Deferred character specific functions not permitted in generic operator interface

[ian_harvey at bigpond dot com]

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

Bug ID: 64324
   Summary: Deferred character specific functions not permitted in
generic operator interface
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian_harvey at bigpond dot com

gfortran built from current trunk rejects the following with "Error: User
operator procedure ‘tostring’ at (1) cannot be assumed character length"

MODULE m
  IMPLICIT NONE
  INTERFACE OPERATOR(.ToString.)
MODULE PROCEDURE tostring
  END INTERFACE OPERATOR(.ToString.)
CONTAINS
  FUNCTION tostring(arg)
INTEGER, INTENT(IN) :: arg
CHARACTER(:), ALLOCATABLE :: tostring
tostring = '42'
  END FUNCTION tostring
END MODULE m


(The procedure has deferred length, not assumed length.)


$ gfortran -v -c 2014-12-16\ ToString.f90
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-unknown-linux-gnu
Configured with: .././src/configure --prefix=/home/MEGMS2/ian/usr/gcc-5.0.0
--enable-languages=c,c++,fortran --enable-libgomp --enable-checking=release
Thread model: posix
gcc version 5.0.0 20141215 (experimental) (GCC) 

COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'
 /home/MEGMS2/ian/usr/gcc-5.0.0/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/f951
2014-12-16 ToString.f90 -quiet -dumpbase 2014-12-16 ToString.f90 -mtune=generic
-march=x86-64 -auxbase 2014-12-16 ToString -version -fintrinsic-modules-path
/home/MEGMS2/ian/usr/gcc-5.0.0/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/finclude
-o /tmp/cctex4Ju.s
GNU Fortran (GCC) version 5.0.0 20141215 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 5.0.0 20141215 (experimental), GMP version 6.0.0,
MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 5.0.0 20141215 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 5.0.0 20141215 (experimental), GMP version 6.0.0,
MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
2014-12-16 ToString.f90:7:2:

   FUNCTION tostring(arg)
  1
Error: User operator procedure ‘tostring’ at (1) cannot be assumed character
length

[Bug fortran/56459] Wrongly rejects "TYPE(CHARACTER*1,)" (with comma)

[ian_harvey at bigpond dot com]

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

Ian Harvey  changed:

   What|Removed |Added

 CC||ian_harvey at bigpond dot com

--- Comment #2 from Ian Harvey  ---
As a result of interp f08/0097, F2008 corrigendum three introduced constraint
C406a ("In TYPE(intrinsic-type-spec) the intrinsic-type-spec shall not end with
a comma") that makes the original example non-conforming.

It is therefore now correct (and sensible) for the compiler to reject the
example.

[Bug ipa/64298] [5 Regression] ICE: Segmentation fault in get_binfo_at_offset at tree.c:11914

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from John David Anglin  ---
Fixed.

[Bug rtl-optimization/64323] New: LRA: ICE when compiling newlib for ARM.

[Hale.Wang at arm dot com]

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

Bug ID: 64323
   Summary: LRA: ICE when compiling newlib for ARM.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Hale.Wang at arm dot com

Created attachment 34287
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34287&action=edit
This temp file is generated from newlib/newlib/libc/stdlib/dtoa.c.

When compiling the newlib stdlib for ARM, GCC 5.0 reported:

newlib/newlib/libc/stdlib/dtoa.c:862:1: error: unable to generate reloads for:
(insn 2301 287 2302 16 (set (reg:CCFP 101 vfpcc)
(compare:CCFP (reg:DF 217 [ D.6454 ])
(const_double:DF 0.0 [0x0.0p+0])))
.../newlib/newlib/libc/stdlib/dtoa.c:282 679 {*cmpdf_vfp}
 (nil))

/work/tools/gcc-arm-none-eabi-5_0-2014q4-20141211/src/newlib/newlib/libc/stdlib/dtoa.c:862:1:
internal compiler error: in curr_insn_transform, at lra-constraints.c:3383

The command line is:
arm-none-eabi-gcc -marm  -O2  -mfloat-abi=hard dtoa.i

I have attached the temp file 'dtoa.i'. If I added the -mno-lra option, there
was no error.

[Bug target/64240] [5.0 Regression][AArch64] SMS-3.c causes runtime exception(segfault).

[fei.yang0953 at gmail dot com]

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

--- Comment #5 from Fei Yang  ---
I'm investigating for a solution, please assign me as owner. Thanks.

[Bug tree-optimization/64322] More optimize opportunity for constant folding

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
First of all, I wonder why already VRP can't handle this.
To do so it would need to add RSHIFT_EXPR to the codes that we handle different
range kinds form (like PLUS_EXPR, BIT_AND_EXPR etc.), and simply if the second
range is range_int_cst_p and the first range is not VR_RANGE, just pretend the
first range is VR_RANGE from min to max value.  Say on the x >> 63 from the
testcase it should figure out the VR is [-1, 0] and thus for double that
[-2, 0] and for division by 0x1L that it must be 0.

[Bug rtl-optimization/64300] [5 Regression] s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  ---
(In reply to Vladimir Makarov from comment #2)
> Thanks for reporting.  I've just committed a patch focusing on the same
> problem.  Could you check that the patch solves the problem.

It fixes the ICE for the given test case on s390 and the similar
ICEs on my local sh-lra branch.  Thanks!

[Bug tree-optimization/64322] New: More optimize opportunity for constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 64322
   Summary: More optimize opportunity for constant folding
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp

The two programs (A.c) and (B.c) only differ by one line
(marked by "// <---HERE"), where (B.c) change 0x1L to 0L.

Resulting codes by "x86_64-unknown-linux-gnu-gcc-5.0.0 -Os -S"
are different;
the code (A.s) for (A.c) is less optimized than (B.s) for (B.c).
Note that variable c is not referenced at all in this program.

(A.c)
int main (void)
{
  long a = -1L;
 volatile long b =  0L;
 volatile long c = 0x1L;  // <---HERE
 a = (1+b >> 63 << 1) / 0x1L;

 if (a == 0L);
 else __builtin_abort();

 return 0;
}

(B.c)
int main (void)
{
  long a = -1L;
 volatile long b =  0L;
 volatile long c =  0L;   // <---HERE
 a = (1+b >> 63 << 1) / 0x1L;

 if (a == 0L);
 else __builtin_abort();

 return 0;
}

+-+-+
|(A.s)|(B.s)|
+-+-+
|main:|main:|
|.LFB0:   |.LFB0:   |
|  .cfi_startproc |  .cfi_startproc |
|  subq  $24, %rsp|  movq  $0, -24(%rsp)|
|  .cfi_def_cfa_offset 32 |  movq  $0, -16(%rsp)|
|  movabsq  $4294967296, %rcx |  movq  -24(%rsp), %rax  |
|  movq  $0, (%rsp)   | |
|  movq  %rcx, 8(%rsp)| |
|  movq  (%rsp), %rax | |
|  incq  %rax | |
|  sarq  $63, %rax| |
|  addq  %rax, %rax   | |
|  cqto   | |
|  idivq  %rcx| |
|  testq  %rax, %rax  | |
|  je  .L2| |
|  call  abort| |
|.L2: | |
|  xorl  %eax, %eax   |  xorl  %eax, %eax   |
|  addq  $24, %rsp| |
|  .cfi_def_cfa_offset 8  | |
|  ret|  ret|
|  .cfi_endproc   |  .cfi_endproc   |
|.LHOTE0: |.LHOTE0: |
+-+-+

$ x86_64-unknown-linux-gnu-gcc-5.0.0 -v
Using built-in specs.
COLLECT_GCC=x86_64-unknown-linux-gnu-gcc-5.0.0
COLLECT_LTO_WRAPPER=/usr/local/x86_64-tools/gcc-5.0.0/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/hassy/gcc/configure
--prefix=/usr/local/x86_64-tools/gcc-5.0.0/
--with-gmp=/usr/local/gmp-5.1.1/ --with-mpfr=/usr/local/mpfr-3.1.2/
--with-mpc=/usr/local/mpc-1.0.1/ --disable-multilib --disable-nls
--enable-languages=c
Thread model: posix
gcc version 5.0.0 20141215 (experimental) (GCC)

[Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
Author: hubicka
Date: Mon Dec 15 22:35:20 2014
New Revision: 218767

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

PR lto/64043
* gcc.dg/lto/20110201-1_0.c: New testcase.

* tree-streamer.c (preload_common_nodes): Skip preloading
of main_identifier_node, pid_type and optimization/option nodes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/lto/20110201-1_0.c
trunk/gcc/tree-streamer.c

[Bug rtl-optimization/63397] signed integer overflows in ira.c

[vmakarov at gcc dot gnu.org]

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

--- Comment #1 from Vladimir Makarov  ---
Author: vmakarov
Date: Mon Dec 15 22:18:51 2014
New Revision: 218766

URL: https://gcc.gnu.org/viewcvs?rev=218766&root=gcc&view=rev
Log:
2014-12-15  Vladimir Makarov  

PR rtl-optimization/63397
* ira-int.h (ira_overall_cost, ira_reg_cost, ira_mem_cost): Use
int64_t.
(ira_load_cost, ira_store_cost, ira_shuffle_cost): Ditto.
* ira.c (ira_overall_cost, ira_overall_cost_before): Ditto.
(ira_reg_cost, ira_mem_cost): Ditto.
(ira_load_cost, ira_store_cost, ira_shuffle_cost): Ditto.
(calculate_allocation_cost, do_reload): Use the right
format for int64_t values.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-int.h
trunk/gcc/ira.c

[Bug target/58623] lack of ldp/stp optimization

[e.menezes at samsung dot com]

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

--- Comment #6 from Evandro  ---
What's the PR of the fwprop issue?

Thank you.

[Bug fortran/64321] New: -ffixed-line-length-none doesn't work

[burnus at gcc dot gnu.org]

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

Bug ID: 64321
   Summary: -ffixed-line-length-none doesn't work
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Keywords: diagnostic, rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org

The following program consists of two lines:

  print *,
'aa'
  end

With GCC 4.8 and 5, one gets the error:

  print *, 'aaa
1
Error: Unterminated character constant beginning at (1)

And that's independent of -ffixed-line-length-none or -ffixed-line-length-150.

[Bug middle-end/64309] if (1 & (1 << n)) not simplified to if (n == 0)

[glisse at gcc dot gnu.org]

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

--- Comment #12 from Marc Glisse  ---
(In reply to Marc Glisse from comment #11)
> ((pow2< p==n

Oups, it wasn't supposed to be the same power of 2, so:
(((1< p==n+(l-k)
(k and l are constants)

[Bug target/63347] m68k misoptimisation with -fschedule-insns

[mikpelinux at gmail dot com]

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

--- Comment #9 from Mikael Pettersson  ---
This wrong-code started with Bernd's r171845, possibly by exposing a latent
issue.

[Bug middle-end/64309] if (1 & (1 << n)) not simplified to if (n == 0)

[glisse at gcc dot gnu.org]

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

--- Comment #11 from Marc Glisse  ---
(In reply to Oleg Endo from comment #7)
> (1 << n) & 6 != 0 -> n > 0 && n < 3 (not beneficial)

We usually spell it (unsigned)n-1<2 (still not that great).

(In reply to Marek Polacek from comment #8)
> > > I don't think so.  I tried to come up with a more general transformation
> > > that would simplify ((CST << n) & CST) != 0, but I haven't found anything
> > 
> > If both CST are (possibly different) powers of 2 it works.
> 
> Yes, but I'm not sure if it's worth it (doing it for 1, 2, 4, 8, ... instead
> of just for 1).

I am not sure why 1 is so much more important than the others...

> > ((c< 
> I don't see how's that a simplification.

((c< n==0
((pow2< p==n

[Bug middle-end/64309] if (1 & (1 << n)) not simplified to if (n == 0)

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
(In reply to Oleg Endo from comment #7)
> (In reply to Marek Polacek from comment #5)
> > 
> > I don't think so.  I tried to come up with a more general transformation
> > that would simplify ((CST << n) & CST) != 0, but I haven't found anything
> > yet.  So maybe just this?
> > ((1 << n) & 1) != 0 -> n == 0
> > ((1 << n) & 1) == 0 -> n != 0
> 
> If I'm not mistaken...
> 
> (1 << n) & 2 != 0 -> n == 1
> (1 << n) & 3 != 0 -> n < 2 (unsigned)
> (1 << n) & 4 != 0 -> n == 2
> (1 << n) & 5 != 0 -> n == 0 || n == 2 (not beneficial)
> (1 << n) & 6 != 0 -> n > 0 && n < 3 (not beneficial)
> (1 << n) & 7 != 0 -> n < 3 (unsigned)
> ...

Right - but to me only the first one seems like a win.

[Bug middle-end/64309] if (1 & (1 << n)) not simplified to if (n == 0)

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
 (1 << n) & 5 != 0 -> n == 0 || n == 2 (not beneficial)

Not only that, we actually emit similar comparisons as a bit test intentionally
even if you write it in a switch or series of ifs that way, so undoing that
optimization would be a bad idea.

[Bug middle-end/64309] if (1 & (1 << n)) not simplified to if (n == 0)

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
(In reply to Marc Glisse from comment #6)
> (In reply to Marek Polacek from comment #5)
> > I don't think so.  I tried to come up with a more general transformation
> > that would simplify ((CST << n) & CST) != 0, but I haven't found anything
> 
> If both CST are (possibly different) powers of 2 it works.

Yes, but I'm not sure if it's worth it (doing it for 1, 2, 4, 8, ... instead of
just for 1).

> ((c< > yet.  So maybe just this?
> > ((1 << n) & 1) != 0 -> n == 0
> 
> That looks like what richi posted. For scalars, != 0 is useless and this
> could just be:
> (1< n==0

Yeah, it's what richi posted.

[Bug middle-end/64309] if (1 & (1 << n)) not simplified to if (n == 0)

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
(In reply to Marek Polacek from comment #5)
> 
> I don't think so.  I tried to come up with a more general transformation
> that would simplify ((CST << n) & CST) != 0, but I haven't found anything
> yet.  So maybe just this?
> ((1 << n) & 1) != 0 -> n == 0
> ((1 << n) & 1) == 0 -> n != 0

If I'm not mistaken...

(1 << n) & 2 != 0 -> n == 1
(1 << n) & 3 != 0 -> n < 2 (unsigned)
(1 << n) & 4 != 0 -> n == 2
(1 << n) & 5 != 0 -> n == 0 || n == 2 (not beneficial)
(1 << n) & 6 != 0 -> n > 0 && n < 3 (not beneficial)
(1 << n) & 7 != 0 -> n < 3 (unsigned)
...

[Bug rtl-optimization/64316] [5 Regression] ICE in simplify_const_unary_operation after r218503

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/64300] [5 Regression] s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  ---
(In reply to Kazumoto Kojima from comment #1)
> I get the same ICE on my local sh-lra branch after r218688.  I've looked
> at what is going on the test case in c#0 with the cross s390 compiler.
> It seems that the change at r218688
> 
> +   if (GET_MODE (*curr_id->operand_loc[nop]) != VOIDmode
> +   && ! hard_reg_set_empty_p (this_alternative_set)
> +   && ! HARD_REGNO_MODE_OK (ira_class_hard_regs
> +[this_alternative][0],
> +GET_MODE 
> (*curr_id->operand_loc[nop])))
> 
> doesn't work as intended for some targets.  These lines are to check
> whether a requested mode value can be held by the registers in
> this_alternative class or not.  In the problematic case, gdb shows
> that GET_MODE (*curr_id->operand_loc[nop]) is DImode and this_alternative
> is GENERAL_REGS.  ira_class_hard_regs[this_alternative] is
>   {1, 2, 3, 4, 5, 0, 11, 10, 9, 8, 7, 6, 0 }
> which is a set of regno for GENERAL_REGS in the preferred allocation order.
> Then ira_class_hard_regs[this_alternative][0] is 1 and HARD_REGNO_MODE_OK
> (1, DImode) is false.  I guess that s390 uses a register pair for DImode
> in this case and 1 is bad as the starting regno for DImode.  Is it right?
> SH uses the similar allocation order of which the first regno isn't match
> to the register pair.

Thanks for reporting.  I've just committed a patch focusing on the same
problem.  Could you check that the patch solves the problem.

[Bug go/61255] gccgo: spurious "error: argument 2 has incompatible type" [GoSmith]

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Dec 15 20:20:22 2014
New Revision: 218764

URL: https://gcc.gnu.org/viewcvs?rev=218764&root=gcc&view=rev
Log:
PR go/61255
compiler: Copied variadic calls should copy lowering state of arguments.

Modified:
trunk/gcc/go/gofrontend/expressions.cc
trunk/gcc/go/gofrontend/expressions.h

[Bug c++/64297] [5 Regression] ICE: canonical types differ for identical types

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/64297] [5 Regression] ICE: canonical types differ for identical types

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Mon Dec 15 20:19:51 2014
New Revision: 218763

URL: https://gcc.gnu.org/viewcvs?rev=218763&root=gcc&view=rev
Log:
PR c++/64297
* typeck.c (apply_memfn_quals): Correct wrong TYPE_CANONICAL.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/ref-qual16.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c

[Bug middle-end/64309] if (1 & (1 << n)) not simplified to if (n == 0)

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
(In reply to Marek Polacek from comment #5)
> I don't think so.  I tried to come up with a more general transformation
> that would simplify ((CST << n) & CST) != 0, but I haven't found anything

If both CST are (possibly different) powers of 2 it works. ((c< yet.  So maybe just this?
> ((1 << n) & 1) != 0 -> n == 0

That looks like what richi posted. For scalars, != 0 is useless and this could
just be:
(1< n==0

> ((1 << n) & 1) == 0 -> n != 0

[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mrestelli at gmail dot com

--- Comment #6 from janus at gcc dot gnu.org ---
*** Bug 61115 has been marked as a duplicate of this bug. ***

[Bug fortran/61115] ICE with generic type bound proc => non_overridable type bound proc

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from janus at gcc dot gnu.org ---
This seems to be a duplicate.

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

[Bug rtl-optimization/64316] [5 Regression] ICE in simplify_const_unary_operation after r218503

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Dec 15 20:10:45 2014
New Revision: 218762

URL: https://gcc.gnu.org/viewcvs?rev=218762&root=gcc&view=rev
Log:
PR rtl-optimization/64316
* simplify-rtx.c (simplify_relational_operation_1): For
(eq/ne (and x y) x) and (eq/ne (and x y) y) optimizations use
CONST0_RTX instead of const0_rtx.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr64316.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog

[Bug target/62642] [4.8/4.9/5 Regression] x86 rdtsc is moved through barrier

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
Author: vmakarov
Date: Mon Dec 15 20:04:04 2014
New Revision: 218761

URL: https://gcc.gnu.org/viewcvs?rev=218761&root=gcc&view=rev
Log:
2014-12-15  Vladimir Makarov  

PR target/62642
* ira.c (rtx_moveable_p): Prevent UNSPEC_VOLATILE moves.


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

[Bug bootstrap/64320] New: Missing config.h during findcomp.cc compilation

[townsend at astro dot wisc.edu]

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

Bug ID: 64320
   Summary: Missing config.h during findcomp.cc compilation
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu

I'm trying to build the latest trunk (rev. 218759) on Linux. Configuring with:

 ./configure CC=gcc --build=x86_64-pc-linux-gnu --prefix=/root/madsdk
--with-gmp=/root/madsdk --with-mpfr=/root/madsdk --with-mpc=/root/madsdk
--enable-languages=c,c++,fortran --disable-multilib --disable-nls
--disable-libsanitizer

...I get the following error during make:

libtool: compile:  /root/madsdk-src/gcc/host-x86_64-pc-linux-gnu/gcc/xg++
-B/root/madsdk-src/gcc/host-x86_64-pc-linux-gnu/gcc/ -nostdinc++ -nostdinc++
-I/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/root/madsdk-src/gcc/libstdc++-v3/libsupc++
-I/root/madsdk-src/gcc/libstdc++-v3/include/backward
-I/root/madsdk-src/gcc/libstdc++-v3/testsuite/util
-L/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/root/madsdk/x86_64-pc-linux-gnu/bin/ -B/root/madsdk/x86_64-pc-linux-gnu/lib/
-isystem /root/madsdk/x86_64-pc-linux-gnu/include -isystem
/root/madsdk/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../.././libcc1 -I ../.././libcc1/../include -I ../.././libcc1/../libgcc -I
../host-x86_64-pc-linux-gnu/gcc -I../.././libcc1/../gcc -I
../.././libcc1/../gcc/c -I ../.././libcc1/../gcc/c-family -I
../.././libcc1/../libcpp/include -I/root/madsdk/include -I/root/madsdk/include
-I/root/madsdk/include -W -Wall -fvisibility=hidden -g -O2 -D_GNU_SOURCE -MT
findcomp.lo -MD -MP -MF .deps/findcomp.Tpo -c ../.././libcc1/findcomp.cc  -fPIC
-DPIC -o .libs/findcomp.o
../.././libcc1/findcomp.cc:20:20: fatal error: config.h: No such file or
directory
compilation terminated.
make[3]: *** [findcomp.lo] Error 1
make[3]: Leaving directory
`/root/madsdk-src/gcc/host-x86_64-pc-linux-gnu/libcc1'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/root/madsdk-src/gcc/host-x86_64-pc-linux-gnu/libcc1'
make[1]: *** [all-libcc1] Error 2
make[1]: Leaving directory `/root/madsdk-src/gcc'
make: *** [all] Error 2

When attempting to build on OS X (10.6), I get the exact same error.

[Bug go/61255] gccgo: spurious "error: argument 2 has incompatible type" [GoSmith]

[cmang at google dot com]

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

Chris Manghane  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-12-15
 CC||cmang at google dot com
   Assignee|ian at airs dot com|cmang at google dot com
 Ever confirmed|0   |1

[Bug c++/64318] Using _Cilk_for with cause strange floating point exception

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
The original testcase does indeed have a data race. The revised testcase is
valid.

[Bug c++/64297] [5 Regression] ICE: canonical types differ for identical types

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/64318] Using _Cilk_for with cause strange floating point exception

[zhouyan at me dot com]

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

--- Comment #4 from zhouyan at me dot com ---
The new example can be unsafe, if the constructor of the two classes are
unsafe. However, I went through the source of  before (during 4.8, 4.9
release), unless something changed, it's not the case.

[Bug c++/64318] Using _Cilk_for with cause strange floating point exception

[zhouyan at me dot com]

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

--- Comment #3 from zhouyan at me dot com ---
Here is version that shall be thread-safe, that produce the same problem,

#include 

int main ()
{
_Cilk_for (int i = 0; i != 1; ++i) {
std::mt19937 eng(i);
std::normal_distribution<> rnorm;
rnorm(eng);
}
}


The original program which I first found the issue was thread-safe. The MWE I
first submitted was created a little too hasty. In fact, neither mt19937 nor
normal_distribution is thread-safe. Anyway, I don't think race condition was
the problem.

[Bug middle-end/64309] if (1 & (1 << n)) not simplified to if (n == 0)

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
(In reply to Oleg Endo from comment #4)
> (In reply to Richard Biener from comment #1)
> > Confirmed.  Sth like
> > 
> >  (simplify
> >   (ne (bit_and (lshift integer_onep @0) integer_onep) integer_zerop)
> >   (eq @0 { build_zero_cst (TREE_TYPE (@0)); })
> > 
> > with eventually also covering if ((1 & (1<< n)) == 0) -> if (n & 1 == 0)
> > 
> > You can extend this to cover the other cases you mention.
> 
> I thought you might suggest something like this. :)

Note that this transformation doesn't work.

> While the transform for the if (...) is probably going to be beneficial for
> all the targets, I'm not so sure about the 'return ((1 << 1) & (1 << n));'
> variant, though.  On some targets a shift+and might be cheaper than
> cmp+cstore.  Is there any way to get that information during tree
> optimization?  If not, it might be better to do that transformation on the
> RTL.

I don't think so.  I tried to come up with a more general transformation that
would simplify ((CST << n) & CST) != 0, but I haven't found anything yet.  So
maybe just this?
((1 << n) & 1) != 0 -> n == 0
((1 << n) & 1) == 0 -> n != 0

[Bug c++/64318] Using _Cilk_for with cause strange floating point exception

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Are the std::mt19937 and std::normal_distribution<> classes meant to be
thread-safe?  I mean, in your testcase you access (supposedly read and write)
the same objects from multiple threads, so unless the standard says it is
required to work in a thread-safe, your testcase is racy.

[Bug tree-optimization/64319] New: add alias runtime check to remove load after load redundancy

[spop at gcc dot gnu.org]

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

Bug ID: 64319
   Summary: add alias runtime check to remove load after load
redundancy
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spop at gcc dot gnu.org

Looking at the code generated at -O3 for the following function, we have to
load "*a" twice because "a" may alias "b":

$ cat foo.c
int foo(int *a, int *b)
{
  *a = 1;
  (*b)++;
  return *a;
}

Here is the code generated for aarch64 (for illustration only, ie., this is not
an aarch64 bug):

$ gcc foo.c -O3 -S -o -
[...]
foo:
 mov w2, 1
 str w2, [x0]
 ldr w2, [x1]
 add w2, w2, 1
 str w2, [x1]
 ldr w0, [x0]
 ret

GCC could insert a runtime check to disambiguate the two pointers: in
principle, we should obtain better code on both branches, because the compiler
knows something more about the program in each case.

$ cat bar.c
int bar(int *a, int *b)
{
  if (a == b)
{
  *a = 1;
  (*b)++;
  return *a;
}

  *a = 1;
  (*b)++;
  return *a;
}

GCC does optimize correctly the case "a==b" and still has an optimization
problem in the case "a!=b". Here is the code generated for aarch64:

bar:
 cmpx0, x1
 beq.L6
 movw2, 1
 strw2, [x0]
 ldrw2, [x1]
 addw2, w2, 1
 strw2, [x1]
 ldrw0, [x0]  <-- this load should be replaced by a "mov w0, 1" 
  because we know "x1 != x0" on this branch.
 ret
.L6:
 movw1, 2
 strw1, [x0]
 movw0, w1
 ret

[Bug tree-optimization/16797] Opportunity to remove unnecessary load instructions

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||spop at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #10 from Sebastian Pop  ---
Fixed in http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137631

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

[Bug tree-optimization/23455] tree load PRE is not working for global variables

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 CC||steinmtz at us dot ibm.com

--- Comment #18 from Sebastian Pop  ---
*** Bug 16797 has been marked as a duplicate of this bug. ***

[Bug fortran/64230] [4.9/5 Regression] Segmentation fault - invalid memory reference in a compiler-generated finalizer for a complicated type hierarchy when a polymorphic variable is allocated in an e

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
Here is a somewhat reduced test case, which gets rid of parts of the insane
inheritance chain:


Program main
  Implicit None
  Type :: t1
  End Type
  Type, Extends (t1) :: t2
Integer, Allocatable :: i
  End Type
  Type, Extends (t2) :: t3
Integer, Allocatable :: j
  End Type
  Class (t1), Allocatable :: t
  Allocate (t3 :: t)
  print *,"allocated!"
  Deallocate (t)
End


$ gfortran-5.0 -g -fsanitize=undefined c0.f90 && ./a.out
 allocated!
c0.f90:1: runtime error: member access within null pointer of type 'struct t2'

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7FC890D235F7
#1  0x7FC890D23C3E
#2  0x7FC88F557D9F
#3  0x402423 in __final_main_T2 at c0.f90:1 (discriminator 12)
#4  0x4015B1 in __final_main_T3 at c0.f90:1 (discriminator 8)
#5  0x401806 in MAIN__ at c0.f90:14 (discriminator 3)
Speicherzugriffsfehler (Speicherabzug geschrieben)


The segfault obviously happens in the deallocate statement, for which
-fdump-tree-original shows the following translation:

  if (t._data == 0B)
{
  _gfortran_runtime_error_at (...);
}
  else
{
  if (t._vptr->_final != 0B)
{
  {
struct array0_t1 desc.13;

desc.13.dtype = 40;
desc.13.data = (void * restrict) t._data;
t._vptr->_final (&desc.13, t._vptr->_size, 0);
  }
}
  __builtin_free ((void *) t._data);
}
  t._data = 0B;
  (struct __vtype_main_T1 *) t._vptr = &__vtab_main_T1;


So, yeah, the problem is somewhere in the finalizer call ("t._vptr->_final"),
but I don't directly see where in the finalization routine it occurs (the
compiler generates a 500+ line dump for a 15-line program here).

[Bug middle-end/64309] if (1 & (1 << n)) not simplified to if (n == 0)

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
(In reply to Richard Biener from comment #1)
> Confirmed.  Sth like
> 
>  (simplify
>   (ne (bit_and (lshift integer_onep @0) integer_onep) integer_zerop)
>   (eq @0 { build_zero_cst (TREE_TYPE (@0)); })
> 
> with eventually also covering if ((1 & (1<< n)) == 0) -> if (n & 1 == 0)
> 
> You can extend this to cover the other cases you mention.

I thought you might suggest something like this. :)
While the transform for the if (...) is probably going to be beneficial for all
the targets, I'm not so sure about the 'return ((1 << 1) & (1 << n));' variant,
though.  On some targets a shift+and might be cheaper than cmp+cstore.  Is
there any way to get that information during tree optimization?  If not, it
might be better to do that transformation on the RTL.

[Bug rtl-optimization/63804] [5 Regression] ice in find_oldest_value_reg with -g -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jakub Jelinek  ---
Assuming fixed.  Vlad, if you think this should be kept open, please reopen it.

[Bug target/62084] [avr] ICE: in convert_debug_memory_address

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Looking at this again, this might be a "debug" issue instead rather than
"target".

[Bug libgcc/63832] [5.0 Regression] crtstuff.c:400:19: warning: array subscript is above array bounds [-Warray-bounds]

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

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

[Bug target/61360] [5 Regression] ICE: in lra_update_insn_recog_data, at lra.c:1363 with -mtune=bdver4

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #17 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #16)
> I see r216557 has been committed, isn't this resolved by that change?

Yes, fixed by r216557.

[Bug target/61360] [5 Regression] ICE: in lra_update_insn_recog_data, at lra.c:1363 with -mtune=bdver4

[ubizjak at gmail dot com]

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

Bug 60704 Summary: [4.9 Regression] ICE: in extract_constrain_insn_cached, at 
recog.c:2156 with -flive-range-shrinkage -march=amdfam10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60704

   What|Removed |Added

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

[Bug target/60704] [4.9 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2156 with -flive-range-shrinkage -march=amdfam10

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #8 from Uroš Bizjak  ---
The introduced problems were fixed on mainline by r216557.

[Bug libgcc/63832] [5.0 Regression] crtstuff.c:400:19: warning: array subscript is above array bounds [-Warray-bounds]

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Dec 15 18:43:26 2014
New Revision: 218759

URL: https://gcc.gnu.org/viewcvs?rev=218759&root=gcc&view=rev
Log:
PR libgcc/63832
* crtstuff.c (__do_global_dtors_aux) [HIDDEN_DTOR_LIST_END]: Use
func_ptr *dtor_list temporary variable to avoid "array subscript
is above array bounds" warnings.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/crtstuff.c

[Bug rtl-optimization/63804] [5 Regression] ice in find_oldest_value_reg with -g -O2

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Dec 15 18:40:35 2014
New Revision: 218758

URL: https://gcc.gnu.org/viewcvs?rev=218758&root=gcc&view=rev
Log:
PR rtl-optimization/63804
* gcc.dg/pr63804.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr63804.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/61669] Error recovery ICE

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Mon Dec 15 18:37:59 2014
New Revision: 218757

URL: https://gcc.gnu.org/viewcvs?rev=218757&root=gcc&view=rev
Log:
PR fortran/61669
* gfortran.h (struct gfc_namespace): Add OLD_DATA field.
* decl.c (gfc_reject_data): New function.
* parse.c *use_modules): Record roll-back point.
(next_statement): Likewise.
(reject_statement): Roll back to last accepted DATA.

* gfortran.dg/pr61669.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr61669.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/parse.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/64318] Using _Cilk_for with cause strange floating point exception

[zhouyan at me dot com]

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

--- Comment #1 from zhouyan at me dot com ---
I forgot to mention that, the system is CentOS 7 (with all updates)

[Bug tree-optimization/64312] [5 Regression] ICE: Segmentation fault

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Mon Dec 15 18:33:16 2014
New Revision: 218756

URL: https://gcc.gnu.org/viewcvs?rev=218756&root=gcc&view=rev
Log:
2014-12-15  Richard Biener  

PR tree-optimization/64312
* tree-ssa-sccvn.c (vn_reference_lookup_pieces): Use
vuse_ssa_val as callback to walk_non_aliased_vuses.
(vn_reference_lookup): Likewise.

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

Added:
trunk/gcc/testsuite/g++.dg/torture/pr64312.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/64193] [4.8/4.9 Regression] Decreased performance after r173250

[rguenth at gcc dot gnu.org]

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

Bug 64312 Summary: [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64312

   What|Removed |Added

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

[Bug tree-optimization/64312] [5 Regression] ICE: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/64318] New: Using _Cilk_for with cause strange floating point exception

[zhouyan at me dot com]

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

Bug ID: 64318
   Summary: Using _Cilk_for with  cause strange floating
point exception
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhouyan at me dot com

Below is a minimum example,

#include 

int main ()
{
std::mt19937 eng;
std::normal_distribution<> rnorm;
_Cilk_for (int i = 0; i != 1; ++ i)
rnorm(eng);
}

It is compiled with the following,

$GCC_PATH/g++ -std=c++11 -fcilkplus -g -o test test.cpp $GCC_LDFLAGS

where $GCC_PATH expands to where I installed the trunk version of GCC and
$GCC_LDFLAGS is -L /opt/GCC/devel/lib/gcc/x86_64-redhat-linux-gnu/lib64 -L
/opt/GCC/devel/lib/gcc/x86_64-redhat-linux-gnu/5.0.0 -Wl,-rpath
-Wl,/opt/GCC/devel/lib/gcc/x86_64-redhat-linux-gnu/lib64 -Wl,-rpath
-Wl,/opt/GCC/devel/lib/gcc/x86_64-redhat-linux-gnu/5.0.0
(Basically it avoids the program to find the system libstdc++ etc., at runtime)

The GCC version is trunk, output of $GCC_PATH/g++ -v is
Using built-in specs.
COLLECT_GCC=/opt/GCC/devel/bin/g++
COLLECT_LTO_WRAPPER=/opt/GCC/devel/libexec/gcc/x86_64-redhat-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-redhat-linux-gnu
Configured with: ../GCC-src/configure --build=x86_64-redhat-linux-gnu
--prefix=/opt/GCC/devel --disable-multilib --disable-nls --disable-werror
--enable-checking=release --enable-languages=c,c++,fortran
--enable-libstdcxx-time=yes --enable-lto --enable-stage1-checking
--enable-version-specific-runtime-libs --with-system-zlib
Thread model: posix
gcc version 5.0.0 20141215 (experimental) (GCC)

The problem does not always shows up, but run the program enough times (or
increase the loop count), sooner or later I encounter a floating point
exception. Run the program through a debug, whenever the crash happens, it
always happen in the following frame,
thread #2: (some verbose output omitted) at random.tcc:3473
   3470=
std::min(static_cast(std::numeric_limits<_RealType>::digits),
   3471   __bits);
   3472  const long double __r = static_cast(__urng.max())
-> 3473- static_cast(__urng.min()) + 1.0L;
   3474  const size_t __log2r = std::log(__r) / std::log(2.0L);
   3475  size_t __k = std::max(1UL, (__b + __log2r - 1UL) /
__log2r);
   3476  _RealType __sum = _RealType(0);

It since the cast from integer to long double cause the exception, which makes
no sense. (And replace the random number generating to doing just this cast,
the problem disappears)

The problem does not occur with optimized code, and it seems that it does not
occur with other  distributions. For example, the frame at issue
suggest it might be a problem in std::uniform_real_distribuiton ,which is used
by normal_distribution, but replace the distribution, the problem disappears.
Also, change _Cilk_for to normal for loop, there is no issue. The only thing I
can think of is that _Cilk here somehow corrupted stack data.

[Bug target/62084] [avr] ICE: in convert_debug_memory_address

[gjl at gcc dot gnu.org]

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

--- Comment #3 from Georg-Johann Lay  ---
Marek, would you give a pointer for why this is a target issue and what the
backend should do to fix it?  Thanks.

[Bug c++/64297] [5 Regression] ICE: canonical types differ for identical types

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
struct A {
  typedef int X;
  template  X m_fn1() const;
};
template  struct is_function {};
is_function i;
struct D {
  template > D(Y);
} b(&A::m_fn1<0>);

[Bug target/61360] [5 Regression] ICE: in lra_update_insn_recog_data, at lra.c:1363 with -mtune=bdver4

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek  ---
I see r216557 has been committed, isn't this resolved by that change?

[Bug go/61248] gccgo: spurious "error: too many arguments" [GoSmith]

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Dec 15 17:33:43 2014
New Revision: 218754

URL: https://gcc.gnu.org/viewcvs?rev=218754&root=gcc&view=rev
Log:
PR go/61248
compiler: Ignore argument when typechecking converted recover calls.

Modified:
trunk/gcc/go/gofrontend/expressions.cc

[Bug ipa/64218] [5 Regression] ICE: Segmentation fault (symtab_node::get_alias_target()) running Boost testsuite

[antoshkka at gmail dot com]

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

--- Comment #8 from Antony Polukhin  ---
A few more observations:
* Same Boost test compiles and works well on -mcpu=power8 with -fno-rtti
* Test fails to compile on -mcpu=power8 *WITH RTTI on*:

0x109ccb0b crash_signal
?../../gcc/gcc/toplev.c:358
0x10513e10 symtab_node::get_alias_target()
?../../gcc/gcc/cgraph.h:2250
0x10513e10 symtab_node::ultimate_alias_target(availability*)
?../../gcc/gcc/symtab.c:1302
0x1101f367 cgraph_node::ultimate_alias_target(availability*)
?../../gcc/gcc/cgraph.h:2693
0x1101f367 want_inline_function_to_all_callers_p
?../../gcc/gcc/ipa-inline.c:840
0x1101f367 ipa_inline
?../../gcc/gcc/ipa-inline.c:2249
0x1101f367 execute
?../../gcc/gcc/ipa-inline.c:2562


Here's a whole comand line (just in case):
"g++"  -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC
-std=c++11 -mcpu=power8 -DBOOST_ALL_NO_LIB=1 -DNDEBUG  -I".." -c -o
"/home/trippels/results/boost/bin.v2/libs/variant/test/recursive_variant_test.test/gcc-5.0.0/release/pch-off/recursive_variant_test.o"
"../libs/variant/test/recursive_variant_test.cpp"

[Bug go/61253] gccgo: spurious "error: expected '<-' or '='" [GoSmith]

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Mon Dec 15 17:12:26 2014
New Revision: 218753

URL: https://gcc.gnu.org/viewcvs?rev=218753&root=gcc&view=rev
Log:
PR go/61253
compiler: Support RecvStmt = ExpressionList "=" RecvExpr.

Modified:
trunk/gcc/go/gofrontend/parse.cc

[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept

[thopre01 at gcc dot gnu.org]

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

thopre01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #18 from thopre01 at gcc dot gnu.org ---
Fixed in all currently supported branches

[Bug target/64149] -mno-lra bitrots, suggest to remove for GCC 5

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
Sounds sensible to me.  

We switched to LRA quite late in gcc-4.9, so keeping a way to switch back in
case of problems was pragmatic.  But we've been running with the new code now
for a year and not encountered any major issues that couldn't be fixed pretty
quickly.

[Bug c++/63889] [5 Regression] Ice with redundant static in class scope constexpr variable template.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
ICEs since r213641.

[Bug ipa/64314] [5 Regression] ICE in record_reference, at cgraphbuild.c:87

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-15
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Reduced testcase for -std=c++11:
class B {};
template  using E = B;
struct F : E { ~F(); };
struct C {
  struct D : F { D(int, F); };
  D d;
  C() : d(0, F()) {}
};
enum G {};
struct A { C a; };
struct {
  G b;
  A c[1];
} a {};

Started with r218653.

[Bug ipa/63313] [5 Regression] ICE in ipa-comdats.c:371

[spop at gcc dot gnu.org]

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

--- Comment #3 from Sebastian Pop  ---
Confirmed: https://gcc.gnu.org/viewcvs?rev=218640&root=gcc&view=rev
has fixed the bug that I was seeing.

[Bug c++/58882] ICE with invalid C99 style designated initializers

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |5.0

--- Comment #3 from Paolo Carlini  ---
Fixed.

[Bug c++/58882] ICE with invalid C99 style designated initializers

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Dec 15 16:16:29 2014
New Revision: 218752

URL: https://gcc.gnu.org/viewcvs?rev=218752&root=gcc&view=rev
Log:
/cp
2014-12-15  Paolo Carlini  

PR c++/58882
* decl.c (check_array_designated_initializer): Diagnose gracefully
C99 designators which aren't integral constant-expressions; allow
constexpr user-defined type conversion operators.

/testsuite
2014-12-15  Paolo Carlini  

PR c++/58882
* g++.dg/ext/desig8.C: New.
* g++.dg/cpp0x/desig1.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/desig1.C
trunk/gcc/testsuite/g++.dg/ext/desig8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/63727] [F03] Checks missing for proc-pointer components: Usage as actual argument when elemental

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from janus at gcc dot gnu.org ---
Fixed with r218751. Closing.

[Bug fortran/63727] [F03] Checks missing for proc-pointer components: Usage as actual argument when elemental

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Dec 15 16:10:50 2014
New Revision: 218751

URL: https://gcc.gnu.org/viewcvs?rev=218751&root=gcc&view=rev
Log:
2014-12-15  Janus Weil  

PR fortran/63727
* resolve.c (resolve_actual_arglist): Check for elemental procedure
pointer components.


2014-12-15  Janus Weil  

PR fortran/63727
* gfortran.dg/coarray_collectives_14.f90: Address FIXME item.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray_collectives_14.f90

[Bug rtl-optimization/64037] [4.8/4.9/5 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

 CC||temporal at gmail dot com

--- Comment #26 from H.J. Lu  ---
*** Bug 58192 has been marked as a duplicate of this bug. ***

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #13 from H.J. Lu  ---
Dup of PR 64037.  Will be fixed after 4.8.4 is released.

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

[Bug c++/64297] [5 Regression] ICE: canonical types differ for identical types

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-15
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Reduced testcase for -std=c++11:

namespace std {
template  struct integral_constant {
  static constexpr _Tp value = 0;
  typedef integral_constant type;
};
typedef integral_constant false_type;
template  using __bool_constant = integral_constant;
template  struct __and_;
struct B;
template  struct is_function;
template  struct C;
template 
struct C<_Tp _Cp::*> : integral_constant::value> {};
template  struct G : C<_Tp>::type {};
template  struct is_function : false_type {};
template 
struct is_function<_Res(_ArgTypes...) const &>;
template  _Tp declval();
template  using _Require = int;
template  class D;
template 
struct H : integral_constant {};
template  struct F;
template  struct _Mem_fn_traits_base {
  using __result_type = int;
  using __arg_types = H<_ArgTypes...>;
};
template 
struct F<_Res (_Class::*)(_ArgTypes...) const> : _Mem_fn_traits_base<
 _ArgTypes...> {
  using __lvalue = integral_constant;
};
template ::value> class _Mem_fn_base {
  using _Traits = F<_MemFunPtr>;
  using _ArgTypes = typename _Traits::__arg_types;
  template 
  using _CheckArgs = __bool_constant<_Args::value >= _ArgTypes::value>;

public:
  using result_type = typename _Traits::__result_type;
  template  > > >
  void operator()(...);
};
template 
struct D<_Res _Class::*> : _Mem_fn_base<_Res _Class::*> {};
template 
D<_Member _Class::*> __callable_functor(_Member _Class::*);
template  class function;
template  using __check_func_return_type = int;
template 
class function<_Res(_ArgTypes...)> {
  template 
  using _Invoke = decltype(__callable_functor(std::declval<_Functor &>())(
  std::declval<_ArgTypes>...));
  template  using _NotSelf = B;
  template 
  using _Callable = __and_<_NotSelf<_Functor>,
   __check_func_return_type<_Invoke<_Functor>, _Res> >;
  template  using _Requires = int;
  template , void>
>
  function(_Functor);
};
struct A {
  typedef bool X;
  template  X foo() const;
};
std::function b(&A::foo<0>);

This used to be rejected, but didn't ICE, still in r217241, and ICEs with
r217250, so almost certainly it is r217250 that changed it.

[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> Here is a draft patch which does this (making the ICE disappear):

Regtests cleanly.

[Bug target/64231] [5 Regression] SIGSEGV building glibc on aarch64-linux-gnu from r217852

[belagod at gcc dot gnu.org]

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

--- Comment #8 from Tejas Belagod  ---
Hi Sandra, I'm unable to reproduce this SEGV with a x-build of
aarch64-linux-gcc/native gcc with -O2 on the attached prepocessed test case.
Are there any other options I'm missing?

[Bug rtl-optimization/64316] [5 Regression] ICE in simplify_const_unary_operation after r218503

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 34286
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34286&action=edit
gcc5-pr64316.patch

Untested fix.

[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> 'resolve_typebound_generic_call' should probably communicate to its caller
> that the specific procedure it found is not overridable.

It turns out that resolve_typebound_generic_call actually does update this
information in the gfc_expr, but then resolve_typebound_call needs to pass it
outside, before it transforms the whole thing into an EXEC_CALL.

Here is a draft patch which does this (making the ICE disappear):

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(Revision 218748)
+++ gcc/fortran/resolve.c(Arbeitskopie)
@@ -5667,7 +5667,7 @@ success:
 /* Resolve a call to a type-bound subroutine.  */

 static bool
-resolve_typebound_call (gfc_code* c, const char **name)
+resolve_typebound_call (gfc_code* c, const char **name, bool *overridable)
 {
   gfc_actual_arglist* newactual;
   gfc_symtree* target;
@@ -5691,6 +5691,10 @@ static bool
   if (!resolve_typebound_generic_call (c->expr1, name))
 return false;

+  /* Pass along the NON_OVERRIDABLE attribute of the specific TBP. */
+  if (overridable)
+*overridable = !c->expr1->value.compcall.tbp->non_overridable;
+
   /* Transform into an ordinary EXEC_CALL for now.  */

   if (!resolve_typebound_static (c->expr1, &target, &newactual))
@@ -5950,7 +5954,7 @@ resolve_typebound_subroutine (gfc_code *code)
   if (c->ts.u.derived == NULL)
 c->ts.u.derived = gfc_find_derived_vtab (declared);

-  if (!resolve_typebound_call (code, &name))
+  if (!resolve_typebound_call (code, &name, NULL))
 return false;

   /* Use the generic name if it is there.  */
@@ -5982,7 +5986,7 @@ resolve_typebound_subroutine (gfc_code *code)
 }

   if (st == NULL)
-return resolve_typebound_call (code, NULL);
+return resolve_typebound_call (code, NULL, NULL);

   if (!resolve_ref (code->expr1))
 return false;
@@ -5995,10 +5999,10 @@ resolve_typebound_subroutine (gfc_code *code)
  || (!class_ref && st->n.sym->ts.type != BT_CLASS))
 {
   gfc_free_ref_list (new_ref);
-  return resolve_typebound_call (code, NULL);
+  return resolve_typebound_call (code, NULL, NULL);
 }

-  if (!resolve_typebound_call (code, &name))
+  if (!resolve_typebound_call (code, &name, &overridable))
 {
   gfc_free_ref_list (new_ref);
   return false;

[Bug rtl-optimization/64316] [5 Regression] ICE in simplify_const_unary_operation after r218503

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-15
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r218503.

[Bug c++/60511] [C++1y][N3652] Missing extended constexpr function support

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #2 from Jason Merrill  ---
Implemented for GCC 5.

[Bug c++/54890] [DR 1982] Incorrect SFINAE Rejection

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
Summary|Incorrect SFINAE Rejection  |[DR 1982] Incorrect SFINAE
   ||Rejection

--- Comment #10 from Jason Merrill  ---
This is 

http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_toc.html#1982

which was closed at the Urbana meeting.

[Bug rtl-optimization/64316] [5 Regression] ICE in simplify_const_unary_operation after r218503

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |5.0

[Bug rtl-optimization/64317] New: [5 Regression] Ineffective allocation of PIC base register

[izamyatin at gmail dot com]

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

Bug ID: 64317
   Summary: [5 Regression] Ineffective allocation of PIC base
register
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
CC: vmakarov at redhat dot com
Target: i686

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

For the attached test compiled with -O2  -m32 -fPIE -pie  after r218059 we
generate 

call__x86.get_pc_thunk.ax
addl$_GLOBAL_OFFSET_TABLE_, %eax
subl$28, %esp
.cfi_def_cfa_offset 48
movl48(%esp), %edi
movl%eax, 12(%esp)<--- PIC reg spill
testl%edi, %edi
je.L8
movl12(%esp), %eax<--- PIC reg fill
xorl%esi, %esi
movlc@GOT(%eax), %ebp
.p2align 4,,10
.p2align 3
.L4:
movl12(%esp), %ebx<--- PIC reg fill
addl$1, %esi
callbar@PLT

while for r218058 there is no spill and only reg-reg fill:

call__x86.get_pc_thunk.di
addl$_GLOBAL_OFFSET_TABLE_, %edi
subl$12, %esp
.cfi_def_cfa_offset 32
movl32(%esp), %eax
testl%eax, %eax
je.L8
movlc@GOT(%edi), %ebp
xorl%esi, %esi
.p2align 4,,10
.p2align 3
.L4:
movl%edi, %ebx
addl$1, %esi
callbar@PLT

[Bug target/63594] [5 Regression] ICE: in ix86_vector_duplicate_value, at config/i386/i386.c:39831 with -mavx512f

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #11)
> Does this still fail after r218720, AKA  [1]?
> 
> [1] https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01183.html

I think it is a dup of PR64037.

[Bug tree-optimization/64312] [5 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
Started with r218515.

[Bug rtl-optimization/64316] New: [5 Regression] ICE in simplify_const_unary_operation after r218503

[izamyatin at gmail dot com]

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

Bug ID: 64316
   Summary: [5 Regression] ICE in simplify_const_unary_operation
after r218503
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
Target: x86

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

For the attached reproducer compiled with -O3 -march=core-avx2 there is:

internal compiler error: in simplify_const_unary_operation, at
simplify-rtx.c:1676
 }
 ^ 
0xbd8b9b simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc/simplify-rtx.c:1676
0xbd6045 simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../gcc/simplify-rtx.c:822
0xbd4f75 simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
../../gcc/simplify-rtx.c:395
0x136761f if_then_else_cond
../../gcc/combine.c:8748
0x135e155 combine_simplify_rtx
../../gcc/combine.c:5394
0x135dea3 subst
../../gcc/combine.c:5331
0x135dca2 subst
../../gcc/combine.c:5276
0x135dca2 subst
../../gcc/combine.c:5276
0x1357a53 try_combine
../../gcc/combine.c:3250
0x1352ba8 combine_instructions
../../gcc/combine.c:1301
0x13740c3 rest_of_handle_combine
../../gcc/combine.c:14052
0x137416a execute
../../gcc/combine.c:14095
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


This actually leads to miscompilation of spec2006/403.gcc with -march=core-avx2

[Bug tree-optimization/64312] [5 Regression] ICE: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Mine.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC|uros at gcc dot gnu.org|hjl.tools at gmail dot 
com,
   ||ubizjak at gmail dot com

--- Comment #11 from Uroš Bizjak  ---
Does this still fail after r218720, AKA PR64037 [1]?

[1] https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01183.html

[Bug bootstrap/61524] [5 Regression] cgraph visibility aix bootstrap failure

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from David Edelsohn  ---
Fixed.

[Bug tree-optimization/64312] [5 Regression] ICE: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-12-15
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug tree-optimization/64312] [5 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

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

markus@x4 tmp % g++ -w -O2 -std=c++11 type_erased_mix_values.ii
type_erased_mix_values.ii: In function ‘void mix_values_impl() [with
 = int;  = int;
 = int;  = int;
 = int; TargetReference = int&]’:
type_erased_mix_values.ii:105:1: internal compiler error: Segmentation fault
 mix_values_impl ()
 ^
0xc6887f crash_signal
../../gcc/gcc/toplev.c:358
0xd5b8a4 gimple_code
../../gcc/gcc/gimple.h:1545
0xd5b8a4 gimple_nop_p
../../gcc/gcc/gimple.h:5589
0xd5b8a4 walk_non_aliased_vuses(ao_ref*, tree_node*, void* (*)(ao_ref*,
tree_node*, unsigned int, void*), void* (*)(ao_ref*, tree_node*, void*, bool),
tree_node* (*)(tree_node*), void*)
../../gcc/gcc/tree-ssa-alias.c:2675
0xdfb76c vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**)
../../gcc/gcc/tree-ssa-sccvn.c:2217
0xdd8143 eliminate_dom_walker::before_dom_children(basic_block_def*)
../../gcc/gcc/tree-ssa-pre.c:4264
0x12140c7 dom_walker::walk(basic_block_def*)
../../gcc/gcc/domwalk.c:188
0xdd9850 eliminate
../../gcc/gcc/tree-ssa-pre.c:4491
0xdd9aa5 execute
../../gcc/gcc/tree-ssa-pre.c:4910
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/58796] throw nullptr not caught by catch(type*)

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
However with that patch the caught pointer is not null, so it's not right.

[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> Likely r181107 for pr50919.

Yes, this commit (authored by myself) is definitely the culprit here.

The nontriviality in the given test case is that we have to deal with a generic
type-bound call, which is being resolved to a non-overridable type-bound call.

'resolve_typebound_generic_call' should probably communicate to its caller that
the specific procedure it found is not overridable.