[Bug fortran/65024] [4.9/5 Regression] [OOP] ICE concerning unlimited polymorphic pointer

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #5)
> > The ICE for the reduced test in comment 2 [...]
> Started at r207986.

Huh, that was me committing a patch for PR 60234. Guess I should take a look
(but will probably not manage to do so before the weekend ...)

[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Fri, 13 Feb 2015, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217
> 
> --- Comment #7 from Jeffrey A. Law  ---
> But replacement with the most dominating name (presumably a default def
> dominates everything) isn't going to help here.
> 
> In many ways we'd be better off if we didn't propagate from those equality
> comparisons -- unless they allowed some other later simplification.  But we
> don't have a good way to make that determination.

That's true.  We can also always choose the most immediate dominating
definition for the reason that it might carry more information.

But that might be a loss in some cases as well.

>  Which ultimately let to the
> uncprop pass which we run very late to try and put things back the way they
> were.
>
> I wonder if running uncprop between DOM1 & the late unroller would be worth 
> the
> extra pass.  And if so, where does it make the most sense.

uncprop is mostly to help out-of-SSA PHI coalescing so it's sth different
(and should better be integrated with the out-of-SSA machinery)

[Bug middle-end/65074] [5 Regression] r220674 broke C++ PIEs

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 34772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34772&action=edit
gcc5-pr65074-test.patch

Testcase for the testsuite.

[Bug rtl-optimization/65067] regression on accessing volatile bit field

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||arm-eabi

--- Comment #1 from Richard Biener  ---
This looks more like a failure to use bfi rather than shifts and bit
operations.

[Bug middle-end/53623] [4.8 Regression] sign extension is effectively split into two x86-64 instructions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|4.7.4   |4.8.4
Summary|[4.7/4.8 Regression] sign   |[4.8 Regression] sign
   |extension is effectively|extension is effectively
   |split into two x86-64   |split into two x86-64
   |instructions|instructions

[Bug rtl-optimization/65067] regression on accessing volatile bit field

[terry.guo at arm dot com]

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

--- Comment #2 from Terry Guo  ---
(In reply to Richard Biener from comment #1)
> This looks more like a failure to use bfi rather than shifts and bit
> operations.

If the above IF clause returns false, which means we don't need to consider
strict bit field, the gcc will try to check whether we can use BFI instruction.
Is it a good idea to do same check and attempt when IF clause returns True?

[Bug rtl-optimization/65067] regression on accessing volatile bit field

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de  ---
On Mon, 16 Feb 2015, terry.guo at arm dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067
> 
> --- Comment #2 from Terry Guo  ---
> (In reply to Richard Biener from comment #1)
> > This looks more like a failure to use bfi rather than shifts and bit
> > operations.
> 
> If the above IF clause returns false, which means we don't need to consider
> strict bit field, the gcc will try to check whether we can use BFI 
> instruction.
> Is it a good idea to do same check and attempt when IF clause returns True?

I think actual code generation routines should be (are?) shared.
Definitely bfi should be tried instead of producing the rest.
It seems bfi doesn't work on memory anyway (or is that exposed only
very late?)

[Bug target/65064] [5.0 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors)

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

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

--- Comment #8 from Andreas Schwab  ---
It doesn't bootstrap though:

ada/ali.o: In function `ali__alis__reallocate':
ali.adb:(.text+0x2170): relocation truncated to fit: GPREL22 against `.rodata'
ada/ali.o: In function `ali__units__reallocate':
ali.adb:(.text+0x2f00): relocation truncated to fit: GPREL22 against `.rodata'
ada/ali.o: In function `ali__interrupt_states__reallocate':
ali.adb:(.text+0x4150): relocation truncated to fit: GPREL22 against `.rodata'
ada/ali.o: In function `ali__specific_dispatching__reallocate':
ali.adb:(.text+0x5540): relocation truncated to fit: GPREL22 against `.rodata'
ada/ali.o: In function `ali__withs__reallocate':
ali.adb:(.text+0x6a00): relocation truncated to fit: GPREL22 against `.rodata'
ada/ali.o: In function `ali__args__reallocate':
ali.adb:(.text+0x8080): relocation truncated to fit: GPREL22 against `.rodata'
ada/ali.o: In function `ali__linker_options__reallocate':
ali.adb:(.text+0x92b0): relocation truncated to fit: GPREL22 against `.rodata'
ada/ali.o: In function `ali__notes__reallocate':
ali.adb:(.text+0xa570): relocation truncated to fit: GPREL22 against `.rodata'
ada/ali.o: In function `ali__no_deps__reallocate':
ali.adb:(.text+0xc6b0): relocation truncated to fit: GPREL22 against `.rodata'
ada/ali.o: In function `ali__sdep__reallocate':
ali.adb:(.text+0xd850): relocation truncated to fit: GPREL22 against `.rodata'
ada/ali.o: In function `ali__xref_section__reallocate':
ali.adb:(.text+0xf3a0): additional relocation overflows omitted from the output
/usr/ia64-suse-linux/bin/ld: final link failed: Nonrepresentable section on
output
collect2: error: ld returned 1 exit status

[Bug c++/65061] [4.8/4.9/5 Regression] Issue with using declaration and member class template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/65061] [4.8/4.9/5 Regression] Issue with using declaration and member class template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |4.8.5

[Bug ipa/65059] [5 Regression] Chrome LTO: lto1: internal compiler error: in ipa_comdats, at ipa-comdats.c:360

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |5.0

[Bug fortran/61765] [4.9/5 Regression] Rejects valid BIND(C) ENTRY

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> The code is accepted up to r199034 (2013-05-17) and rejected after r199221
> (2013-05-22). Likely r199118, r199119, or r199120 (pr 48858).

It is r199120.

[Bug lto/65015] LTO produces randomly ordered debug information

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
(In reply to H.J. Lu from comment #18)
> Created attachment 34753 [details]
> A patch

even for -flto-partition=none we produce

45:  0 FILELOCAL  DEFAULT  ABS ccPyi2gu.o

In theory we can also emit a .file directive before each variable/function
we output (from location info).  I suppose the debugger consumes them
for backtraces?

Thus produce

.file   "test.c"
.text
.globl  main
.type   main, @function
main:
.LFB0:  
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
callhelper
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:  
.size   main, .-main
.file   "dependency.c"
.type   helper, @function
helper:
.LFB1:  
.cfi_startproc
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
movl$1, %eax
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE1:  
.size   helper, .-helper
.ident  "GCC: (GNU) 5.0.0 20150213 (experimental)"
.section.note.GNU-stack,"",@progbits

but appearantly as/ld doesn't handle multiple global .file directives well?
I get

45:  0 FILELOCAL  DEFAULT  ABS dependency.c
46:  0 FILELOCAL  DEFAULT  ABS test.c
47: 004005b111 FUNCLOCAL  DEFAULT   13 helper
...
71: 004005a611 FUNCGLOBAL DEFAULT   13 main

so 'helper' is associated with test.c wrongly(?)

Patch I was playing with (for functions only):

Index: gcc/varasm.c
===
--- gcc/varasm.c(revision 220677)
+++ gcc/varasm.c(working copy)
@@ -1713,6 +1713,10 @@ assemble_start_function (tree decl, cons
   char tmp_label[100];
   bool hot_label_written = false;

+  if (targetm.asm_file_start_file_directive
+  && in_lto_p)
+output_file_directive (asm_out_file, DECL_SOURCE_FILE (decl));
+
   if (flag_reorder_blocks_and_partition)
 {
   ASM_GENERATE_INTERNAL_LABEL (tmp_label, "LHOTB", const_labelno);
@@ -7042,7 +7046,9 @@ default_file_start (void)
   && !(flag_verbose_asm || flag_debug_asm || flag_dump_rtl_in_asm))
 fputs (ASM_APP_OFF, asm_out_file);

-  if (targetm.asm_file_start_file_directive)
+  if (targetm.asm_file_start_file_directive
+  /* LTO produced units have no meaningful main_input_filename.  */
+  && !in_lto_p)
 output_file_directive (asm_out_file, main_input_filename);
 }


which shows an alternative to  by picking a random source
file name via

  output_file_directive (asm_out_file, DEC_SOURCE_FILE
(symtab->first_defined_symbol ()->decl));


That said, I think we can go with  for now and try to improve
that later.  I'm going to test an adjusted patch using in_lto_p again.

[Bug lto/65015] LTO produces randomly ordered debug information

[rguenth at gcc dot gnu.org]

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

--- Comment #20 from Richard Biener  ---
The assember already produces

Symbol table '.symtab' contains 11 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
 0:  0 NOTYPE  LOCAL  DEFAULT  UND 
 1:  0 FILELOCAL  DEFAULT  ABS dependency.c
 2:  0 FILELOCAL  DEFAULT  ABS test.c
 3:  0 SECTION LOCAL  DEFAULT1 
 4:  0 SECTION LOCAL  DEFAULT2 
 5:  0 SECTION LOCAL  DEFAULT3 
 6: 000b11 FUNCLOCAL  DEFAULT1 helper
 7:  0 SECTION LOCAL  DEFAULT5 
 8:  0 SECTION LOCAL  DEFAULT6 
 9:  0 SECTION LOCAL  DEFAULT4 
10: 11 FUNCGLOBAL DEFAULT1 main

so not sure if multiple global .file directives are really supported.

[Bug c/65066] [5 Regression] ICE: Segmentation fault with -Wformat=2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/65064] [5 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0
Summary|[5.0 regression] FAIL:  |[5 regression] FAIL:
   |gcc.dg/torture/pr60115.c|gcc.dg/torture/pr60115.c
   |-O1  (test for excess   |-O1  (test for excess
   |errors) |errors)

[Bug c++/65075] [5 Regression] constexpr regression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P1

[Bug tree-optimization/51017] GCC 4.6 performance regression (vs. 4.4/4.5), PRE increases register pressure

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|WAITING |NEW
 CC||rguenth at gcc dot gnu.org
  Component|middle-end  |tree-optimization
Summary|GCC 4.6 performance |GCC 4.6 performance
   |regression (vs. 4.4/4.5)|regression (vs. 4.4/4.5),
   ||PRE increases register
   ||pressure

--- Comment #11 from Richard Biener  ---
As for movaps vs. movups when movaps actually works shouldn't make any
difference on modern architectures.  So I wonder if you could share the exact
CPU type
you are using?

We are putting quite heavy register-pressure on the thing by means of
partial redundancy elimination, thus disabling PRE using -fno-tree-pre
might help (we still spill a lot).

Benchmarking: BSDI DES (x725) [128/128 BS SSE2-16]... DONE
Many salts: 103296 c/s real, 103296 c/s virtual
Only one salt:  100736 c/s real, 100736 c/s virtual

improves to

Benchmarking: BSDI DES (x725) [128/128 BS SSE2-16]... DONE
Many salts: 126848 c/s real, 126848 c/s virtual
Only one salt:  123008 c/s real, 123008 c/s virtual

with that for me (gcc 4.8, SSE2).  Which is close to what 4.5.3 gets for me:

Benchmarking: BSDI DES (x725) [128/128 BS SSE2-16]... DONE
Many salts: 128384 c/s real, 128384 c/s virtual
Only one salt:  124800 c/s real, 124800 c/s virtual

albeit that doesn't need -fno-tree-pre to fix things.

Note that we have to use movups because DES_bs_all is not aligned as seen
from DES_bs_b.c (it's defined in DES_bs.c and only there annotated with
CC_CACHE_ALIGN, not at the point of declaration in DES_bs.h).  So the
unaligned moves are the sources fault.  Annotating that with CC_CACHE_ALIGN
produces the desired movaps instructions (with no effect on performance for
me).

I think for the effect of PRE increasing register pressure we do have some
duplicate bugs (but no good heuristic to fix anything).  LIM store-motion can
have the very same issue.

[Bug target/65064] [5 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors)

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

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

--- Comment #9 from Andreas Schwab  ---
before:
2170:   02 38 01 02 00 24   [MII]   addl r39=0,r1
2170: GPREL22   .sdata+0x38

after:
2170:   02 38 01 02 00 24   [MII]   addl r39=0,r1
2170: GPREL22   .rodata+0x114

[Bug tree-optimization/63593] ICE: verify_gimple failed: incompatible types in PHI argument 0 with -O3 -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/65063] [4.8/4.9/5 Regression] gcc.dg/vect/vect-double-reduc-6.c FAILs with -O3 -fno-tree-loop-ivcanon -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
-fno-predictive-commoning fixes it, so indeed related to PR63593.  Mine.

[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

[vogt at linux dot vnet.ibm.com]

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

--- Comment #13 from Dominik Vogt  ---
I see.

But what bug or bugs do we have here then?  Current symptoms are:

(1) A bogus call addres may be stored in the backtrace structure (i.e. next
instruction's address minus 1).

(2) The address from (1) in printed in the textual backtrace.  As I understand
it, the code should instead print the address calculated in printStackRecord().

(3) At least for s390[x], the caller's line number in the printed backtrace may
be wrong, but I guess that affects other targets as well.

--

So, what happens is this:

* The code in libbacktrace knows whether the pc points to the call instruction
or the instruction after that and handles the latter by decrementing the pc by
one before it's stored in some structure describing the stack trace.

* When the user prints a memory heap trace, writeHeap() is called, which prints
the address from the stack trace structure and then calls printStackRecord().

* printStackRecord() then deducts the guessed size of the call instruction from
the pc and uses this modified pc to determine the file and line number to print
in the stack trace.

--

I see at least two things that need to be fixed:

- printStackRecord() needs to know whether the pc has already been decremented
in libbacktrace and adapt the calculation accordingly.  On s390[x] this could
simply be done by looking at the pc, because odd pcs are invalid.  This is not
the case on other architectures though (e.g. ARM7).

- writeHeap should print the address calculated in printStackRecord() instead
of the address from the stack trace structure.

As an alternative, if the code in libbacktrace could properly determine the
call address, the address calculation code in printStackTrace() could be
removed and everything would be fine.

[Bug middle-end/65074] [5 Regression] r220674 broke C++ PIEs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-16
 Ever confirmed|0   |1

[Bug c/65066] [5 Regression] ICE: Segmentation fault with -Wformat=2

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Mon Feb 16 11:16:33 2015
New Revision: 220732

URL: https://gcc.gnu.org/viewcvs?rev=220732&root=gcc&view=rev
Log:
PR c/65066
* c-format.c (check_format_types): Handle null param.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr65066.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/testsuite/ChangeLog

[Bug c/65040] [5 Regression] gcc-5 -Wformat broken

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
Note that this patch had a followup: PR65066.

[Bug c/65066] [5 Regression] ICE: Segmentation fault with -Wformat=2

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug tree-optimization/55334] [4.8/4.9 Regression] mgrid regression (ipa-cp disables vectorization)

[andrew.n.senkevich at gmail dot com]

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

Andrew Senkevich  changed:

   What|Removed |Added

 CC||andrew.n.senkevich at gmail 
dot co
   ||m

--- Comment #47 from Andrew Senkevich  ---
Hi, Richard,

what about to fix this issue also for 4.9 branch?

[Bug tree-optimization/55334] [4.8/4.9 Regression] mgrid regression (ipa-cp disables vectorization)

[jakub at gcc dot gnu.org]

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

--- Comment #48 from Jakub Jelinek  ---
That sounds way too risky for the older release branches.

[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

[vogt at linux dot vnet.ibm.com]

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

--- Comment #14 from Dominik Vogt  ---
Created attachment 34773
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34773&action=edit
Experimental fix

The attached patch is a sketch of a possible fix (at the expense of duplicating
some code from printStackRecord() in a separate function).

This fixes the problems running the test runtime/pprof on s390 and should also
fix the inconsistencies in the printed stack trace.

[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

[vogt at linux dot vnet.ibm.com]

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

--- Comment #15 from Dominik Vogt  ---
P.S.: The patch only addresses s390 and s390x.

[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate

[anlauf at gmx dot de]

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

--- Comment #19 from Harald Anlauf  ---
(In reply to Jerry DeLisle from comment #17)
> Created attachment 34765 [details]
> Handle KIND=1 and KIND=2

Jerry,

I applied your patch on top of rev. 220730.
Unfortunately it ICEs on the following simple code:

  integer(4) :: count_rate_i4
  call system_clock (count_rate=count_rate_i4)
end

gfcbug128x.f90:2:0:

   call system_clock (count_rate=count_rate_i4)
 1
internal compiler error: Segmentation fault
0x882b340 crash_signal
../../trunk/gcc/toplev.c:383
0x834b500 conv_intrinsic_system_clock
../../trunk/gcc/fortran/trans-intrinsic.c:9479
0x834b500 gfc_conv_intrinsic_subroutine(gfc_code*)
../../trunk/gcc/fortran/trans-intrinsic.c:9529
0x82ebeba trans_code
../../trunk/gcc/fortran/trans.c:1718
0x831c353 gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:5850
0x82a461b translate_all_program_units
../../trunk/gcc/fortran/parse.c:5341
0x82a461b gfc_parse_file()
../../trunk/gcc/fortran/parse.c:5538
0x82e6613 gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:228

[Bug tree-optimization/63593] ICE: verify_gimple failed: incompatible types in PHI argument 0 with -O3 -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Ok, one issue is that predictive commoning removes statements and releases
SSA names while they are still in use, and then allocates new SSA names before
eventually releasing the using stmts.

Delaying that keeps released SSA names in the IL (better than filled with
invalid re-used ones) after the transform callback.  Now we enter
gimple_duplicate_loop_to_header_edge with that "invalid" IL...

But at least it fixes this testcase and the related one.

[Bug tree-optimization/55334] [4.8/4.9 Regression] mgrid regression (ipa-cp disables vectorization)

[rguenther at suse dot de]

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

--- Comment #49 from rguenther at suse dot de  ---
On Mon, 16 Feb 2015, andrew.n.senkevich at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
> 
> Andrew Senkevich  changed:
> 
>What|Removed |Added
> 
>  CC||andrew.n.senkevich at gmail 
> dot co
>||m
> 
> --- Comment #47 from Andrew Senkevich  
> ---
> Hi, Richard,
> 
> what about to fix this issue also for 4.9 branch?

The patch isn't suitable for backporting.

[Bug ipa/65059] [5 Regression] Chrome LTO: lto1: internal compiler error: in ipa_comdats, at ipa-comdats.c:360

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Mon Feb 16 12:28:40 2015
New Revision: 220733

URL: https://gcc.gnu.org/viewcvs?rev=220733&root=gcc&view=rev
Log:
Fix PR ipa/65059.

PR ipa/65059
* ipa-comdats.c (ipa_comdats): Do not categorize thunks to
external functions.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-comdats.c

[Bug target/65064] [5 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors)

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #10 from H.J. Lu  ---
(In reply to Andreas Schwab from comment #9)
> before:
> 2170:   02 38 01 02 00 24   [MII]   addl r39=0,r1
> 2170: GPREL22   .sdata+0x38
> 
> after:
> 2170:   02 38 01 02 00 24   [MII]   addl r39=0,r1
> 2170: GPREL22   .rodata+0x114

Can you provide a prepossessed Ada source file?

[Bug fortran/65024] [4.9/5 Regression] [OOP] ICE concerning unlimited polymorphic pointer

[matt at gneilson dot plus.com]

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

--- Comment #7 from homgran  ---
(In reply to Dominique d'Humieres from comment #4)
> AFAICT the ICE for the original test is as old as the first implementation
> of unlimited polymorphism.

In that case, should we remove the '[4.9/5 Regression]' tag from the summary
title?

[Bug target/65064] [5 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors)

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #11 from Andreas Schwab  ---
Ada doesn't preprocess.

[Bug target/65064] [5 regression] FAIL: gcc.dg/torture/pr60115.c -O1 (test for excess errors)

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Andreas Schwab from comment #11)
> Ada doesn't preprocess.

Can you try my first patch? If it works, I can explain why :-(.

[Bug ipa/65076] New: [5 Regression] 16% tramp3d-v4.cpp compile time regression

[trippels at gcc dot gnu.org]

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

Bug ID: 65076
   Summary: [5 Regression] 16% tramp3d-v4.cpp compile time
regression
   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
CC: hubicka at gcc dot gnu.org

Trunk build with --enable-checking=release and LTO/PGO is currently
~16% slower when compiling tramp3d-v4.cpp compared to 4.9.:

Trunk:
markus@x4 ~ % time g++ -w -Ofast tramp3d-v4.cpp
g++ -w -Ofast tramp3d-v4.cpp  25.92s user 0.35s system 99% cpu 26.303 total
4.9:
markus@x4 ~ % time g++ -w -Ofast tramp3d-v4.cpp
g++ -w -Ofast tramp3d-v4.cpp  21.56s user 0.36s system 99% cpu 21.963 total

It looks like r219452 is the culprit.

phase opt and generate  :  19.43 (87%) usr   1.44 (71%) sys  20.88 (85%) wall 
674052 kB (64%) ggc 
vs.
phase opt and generate  :  23.69 (89%) usr   1.51 (70%) sys  25.20 (87%) wall 
710029 kB (66%) ggc

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.0

--- Comment #1 from Richard Biener  ---
So it's either time spent in the inliner (unlikely, though the patch has an
extra update_callee_keys call) or different (early) inlining decisions.

I remember you saying that without LTO/PGO-ing GCC the difference is a lot
smaller?

[Bug c/65077] New: memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

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

Bug ID: 65077
   Summary: memcpy generates incorrect code with floating point
numbers and -O1
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.blomdell at control dot lth.se

Created attachment 34774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34774&action=edit
Program that triggers bug

The attached code (heavily downsized), generates incorrect code with -O1 and if
compiled with -fPIC or -fpic it generates incorrect code for most optimizations
(-O1, -O2, -O3, -Os, -Ofast).

Here is the command line and output.

> gcc -v -save-temps -o bug bug.c -fno-strict-aliasing -fwrapv 
> -fno-aggressive-loop-optimizations  -O1 -Wall -Werror

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --enable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.9.2-20141101/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.9.2-20141101/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-fno-strict-aliasing'
'-fwrapv' '-fno-aggressive-loop-optimizations' '-O1' '-Wall' '-Werror'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/cc1 -E -quiet -v bug.c
-mtune=generic -march=x86-64 -Wall -Werror -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -O1 -fpch-preprocess -o bug.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-fno-strict-aliasing'
'-fwrapv' '-fno-aggressive-loop-optimizations' '-O1' '-Wall' '-Werror'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/cc1 -fpreprocessed bug.i -quiet
-dumpbase bug.c -mtune=generic -march=x86-64 -auxbase bug -O1 -Wall -Werror
-version -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o
bug.s
GNU C (GCC) version 4.9.2 20141101 (Red Hat 4.9.2-1) (x86_64-redhat-linux)
compiled by GNU C version 4.9.2 20141101 (Red Hat 4.9.2-1), 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 C (GCC) version 4.9.2 20141101 (Red Hat 4.9.2-1) (x86_64-redhat-linux)
compiled by GNU C version 4.9.2 20141101 (Red Hat 4.9.2-1), 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
Compiler executable checksum: 03cfec3867418ce243292e9ba51d447c
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-fno-strict-aliasing'
'-fwrapv' '-fno-aggressive-loop-optimizations' '-O1' '-Wall' '-Werror'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o bug.o bug.s
GNU assembler version 2.24 (x86_64-redhat-linux) using BFD version version 2.24
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/:/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.9.2/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.9.2/:/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'bug' '-fno-strict-aliasing'
'-fwrapv' '-fno-aggressive-loop-optimizations' '-O1' '-Wall' '-Werror'
'-mtune=generic' '-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/collect2 -plugin
/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper
-plugin-opt=-fresolution=bug.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--no-add-needed --eh-frame

[Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization

[anders.blomdell at control dot lth.se]

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

anders.blomdell at control dot lth.se changed:

   What|Removed |Added

 CC||anders.blomdell at control dot 
lth
   ||.se

--- Comment #19 from anders.blomdell at control dot lth.se ---
Created attachment 34775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34775&action=edit
preprocessed program

[Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization

[anders.blomdell at control dot lth.se]

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

--- Comment #20 from anders.blomdell at control dot lth.se ---
Created attachment 34776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34776&action=edit
Shell-script for testing flag variations

[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Richard Biener from comment #1)
> So it's either time spent in the inliner (unlikely, though the patch has an
> extra update_callee_keys call) or different (early) inlining decisions.
> 
> I remember you saying that without LTO/PGO-ing GCC the difference is a lot
> smaller?

No, with --disable-bootstrap it still goes from 27.133 (r219451)
to 31.116 (r219452).

[Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization

[anders.blomdell at control dot lth.se]

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

--- Comment #21 from anders.blomdell at control dot lth.se ---
Sorry attachments belongs to bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

[Bug c/65077] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
You are writing beyond P in

  (s)->u.f1 = p;

the testcase works with -m32 (where S is of the same size as P).

[Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization

[anders.blomdell at control dot lth.se]

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

--- Comment #22 from anders.blomdell at control dot lth.se ---
Sorry attachments belongs to bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

[Bug middle-end/59990] [4.8 regression] incorrect memcpy optimization

[anders.blomdell at control dot lth.se]

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

--- Comment #23 from anders.blomdell at control dot lth.se ---
Sorry attachments belongs to bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65077

[Bug c/65077] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

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

--- Comment #2 from anders.blomdell at control dot lth.se ---
Created attachment 34777
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34777&action=edit
preprocessed program

[Bug c/65077] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

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

--- Comment #3 from anders.blomdell at control dot lth.se ---
Created attachment 34778
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34778&action=edit
Shell-script for testing flag variations

[Bug ipa/64963] [5 Regression] IPA Cloning/Splitting does not copy function section attributes resulting in kernel miscompilation

[jakub at gcc dot gnu.org]

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

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

Updated untested patch (well, tested with dg.exp=ipa/* ipa.exp so far), whcih
doesn't introduce these regressions and I think roughly matches what we used to
do with DECL_SECTION_NAME in the past.
Another thing is DECL_COMDAT_GROUP, seems we used to copy that and only clear
in some cases (non-local ones).

[Bug c/65077] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2015-02-16
 CC||rguenth at gcc dot gnu.org
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
Ah, the issue is actually that we simply disregard passing pointers through
floating point values in points-to analysis:

  if (FLOAT_TYPE_P (TREE_TYPE (lhsop)))
/* If the operation produces a floating point result then
   assume the value is not produced to transfer a pointer.  */
;

which results in

  # PT =
  s_13 = MEM[(char * {ref-all})&intSptr];

and DSE removing the store to

  # .MEM_15 = VDEF <.MEM_11>
  s_13->u.f1 = p_6;

we have similar handling for

  else if (truth_value_p (code))
/* Truth value results are not pointer (parts).  Or at least
   very very unreasonable obfuscation of a part.  */
;

so if you insist on writing rediculous testcases...

[Bug testsuite/64849] FAIL: gfortran.dg/class_allocate_18.f90 -O0 (test for excess errors)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #6 from Dominique d'Humieres  ---
Duplicate or pr64921.

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

[Bug c/65077] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

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

--- Comment #5 from anders.blomdell at control dot lth.se ---
No, but my users insists on using Matlab/Simulink, and the testcase is a
heavily downsized version of what is done in their S-functions.

[Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #11 from Dominique d'Humieres  ---
*** Bug 64849 has been marked as a duplicate of this bug. ***

[Bug c/65077] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to anders.blomdell from comment #5)
> No, but my users insists on using Matlab/Simulink, and the testcase is a
> heavily downsized version of what is done in their S-functions.

I mean - seriously storing a pointer as FP values of the upper/lower word
of the pointer?  So I suppose this is what Matlab/Simulink generate internally
and what gets compiled - thus this is machine generated?

A workaround is to use -fno-tree-pta btw (for 64bit pointers the out-of-bound
write still occurs, but that may be due to your simplification?).

[Bug fortran/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-16
  Component|rtl-optimization|fortran
 Ever confirmed|0   |1

--- Comment #12 from Dominique d'Humieres  ---
If I comment the line

  Deallocate (t)

the test compiled with -fsanitize=address runs without error. This is also the
case for the following variant

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)
  if (allocated(t)) then
print *,"allocated!"
select type (t)
  type is (t1)
print *, "type is t1"
  type is (t2)
print *, "type is t2"
  type is (t3)
print *, "type is t3"
t%i = 42
t%j = 99
print *, t%i, t%j
Deallocate (t%i, t%j)
end select
!deallocate (t)
  else
call abort ()
  end if
End

which outputs at run time

 allocated!
 type is t3
  42  99

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|REOPENED|ASSIGNED
  Component|c   |tree-optimization
  Known to work||4.8.2
   Target Milestone|--- |4.9.3
Summary|memcpy generates incorrect  |[4.9/5 Regression] memcpy
   |code with floating point|generates incorrect code
   |numbers and -O1 |with floating point numbers
   ||and -O1

--- Comment #7 from Richard Biener  ---
The

  if (FLOAT_TYPE_P (TREE_TYPE (lhsop)))
/* If the operation produces a floating point result then
   assume the value is not produced to transfer a pointer.  */
;

case is new in 4.9 (4.8 didn't have it - doing this improves points-to
results for scientific benchmarks which have both pointers and FP values
in aggregates).  Changed by r197158:

2013-03-27  Richard Biener  

   PR tree-optimization/37021
   * tree-vect-data-refs.c (vect_check_strided_load): Allow
   REALPART/IMAGPART_EXPRs around the supported refs.
   * tree-ssa-structalias.c (find_func_aliases): Assume that
   floating-point values are not used to transfer pointers.

[Bug fortran/64980] [5 Regression] ICE in trans-expr.c

[dominiq at lps dot ens.fr]

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

--- Comment #19 from Dominique d'Humieres  ---
> BTW: should we add the original test case from pr64230 the test suite,
> because class_allocate_18.f90 failed to spot this regression?

Why not? Better safe than sorry. Note that the original test does not suffer
the problem reported in pr64921.

[Bug c++/65075] [5 Regression] constexpr regression

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  ---
Hi Jakub. Something like the below passes testing and works for the testcase:

Index: constexpr.c
===
--- constexpr.c(revision 220731)
+++ constexpr.c(working copy)
@@ -415,8 +415,8 @@ check_constexpr_bind_expr_vars (tree t)
   gcc_assert (TREE_CODE (t) == BIND_EXPR);

   for (tree var = BIND_EXPR_VARS (t); var; var = DECL_CHAIN (var))
-if (TREE_CODE (var) == TYPE_DECL
-&& DECL_IMPLICIT_TYPEDEF_P (var))
+if (DECL_IMPLICIT_TYPEDEF_P (var)
+&& !LAMBDA_TYPE_P (TREE_TYPE (var)))
   return false;
   return true;
 }

Note that I will be traveling for a week or so, thus I'm not be able to fully
handle the issue. If we rather resolve the regression immediately, please feel
free to pick up the above / double check if it makes sense to Jason.

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

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

--- Comment #8 from anders.blomdell at control dot lth.se ---
(In reply to Richard Biener from comment #6)
> (In reply to anders.blomdell from comment #5)
> > No, but my users insists on using Matlab/Simulink, and the testcase is a
> > heavily downsized version of what is done in their S-functions.
> 
> I mean - seriously storing a pointer as FP values of the upper/lower word
> of the pointer?  So I suppose this is what Matlab/Simulink generate
> internally
> and what gets compiled - thus this is machine generated?
Nope, part of C-code that users should include in their S-functions.
Code used to work with gcc-4.8.3. This will become a major problem :-(

> 
> A workaround is to use -fno-tree-pta btw (for 64bit pointers the out-of-bound
> write still occurs, but that may be due to your simplification?).
The out of bound write is because I'm a klutz, the bug occurs with this as well

S theS;

double *getP(void *p) {
  union u {
void *p;
int i[2];
  } u;
  u.p = &theS;
  P[0] = u.i[0];
  P[1] = u.i[1];
  return P;
}

[Bug c++/65075] [5 Regression] constexpr regression

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Yeah, makes sense, I've just been looking for what the flag is for the lambda
types.  I can add the testcase and bootstrap/regtest it.

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[anders.blomdell at control dot lth.se]

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

--- Comment #9 from anders.blomdell at control dot lth.se ---
(In reply to Richard Biener from comment #7)
>* tree-ssa-structalias.c (find_func_aliases): Assume that
>floating-point values are not used to transfer pointers.

Assume nothing (except the worst) when dealing with MathWorks code :-(

[Bug go/64999] s390x libgo test failure in TestMemoryProfiler

[ian at airs dot com]

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

--- Comment #16 from Ian Lance Taylor  ---
Back in comment #9 I was trying to suggest that runtime.Callers should adjust
the PC that it returns to Go code.  That seems simpler and should have the same
effect as your patch.

[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[mstahl at redhat dot com]

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

Michael Stahl  changed:

   What|Removed |Added

 CC||caolanm at redhat dot com,
   ||mstahl at redhat dot com,
   ||sbergman at redhat dot com

--- Comment #5 from Michael Stahl  ---
the problem is that with -Os, the inline method
 WindowListenerMultiplexer::acquire()
results in an undefined symbol, whereas with -O2
weak symbols are emitted into the object.

can reproduce this with:

gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)

the command line parameters for compilation in the build system were:

g++ -m32 -fvisibility=hidden -fmessage-length=0 -fno-common
-fvisibility-inlines-hidden -fstack-protector-strong -fPIC -std=gnu++11  -ggdb2
 -fexceptions -fno-enforce-eh-specs -Os -c /tmp/fmgridif.ii -o /tmp/fmgridif.o

the minimal command line parameters to trigger the bug:

> g++ -m32 -std=gnu++11 -Os -c /tmp/fmgridif.ii -o /tmp/fmgridif.o

> nm --demangle /tmp/fmgridif.o | grep WindowListenerMultiplexer
 U non-virtual thunk to WindowListenerMultiplexer::acquire()

the minimal command line parameters to avoid the bug:

> g++ -m32 -std=gnu++11 -O2 -c /tmp/fmgridif.ii -o /tmp/fmgridif.o

> nm --demangle /tmp/fmgridif.o | grep WindowListenerMultiplexer
 W WindowListenerMultiplexer::acquire()
0020 W non-virtual thunk to WindowListenerMultiplexer::acquire()

[Bug fortran/60898] [4.8/4.9/5 Regression] model compile error with gfortran 4.7 and gcc 4.9

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mikael at gcc dot 
gnu.org

--- Comment #22 from Mikael Morin  ---
patch posted at:
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00917.html

[Bug regression/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[mstahl at redhat dot com]

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

--- Comment #6 from Michael Stahl  ---
Created attachment 34780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34780&action=edit
manually minimized reproducer

to reproduce, build with:
 g++ -m32 -std=gnu++11 -Os -c /tmp/fmgridif.ii -o /tmp/fmgridif.o

[Bug tree-optimization/65077] [4.9/5 Regression] memcpy generates incorrect code with floating point numbers and -O1

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Created attachment 34781
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34781&action=edit
untested patch

Patch which fixes the testcase and doesn't regress the vectorization testcase
from PR37021.

[Bug rtl-optimization/65078] New: [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[ysrumyan at gmail dot com]

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

Bug ID: 65078
   Summary: [5.0 Regression] 4.9 and 5.0 generate more spill-fill
in comparison with 4.8.2
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ysrumyan at gmail dot com

Using attached simple test-case extracted from codec we found out that 4.8.2
compiler generates more compact binaries in comparison with 4.9 & 5.0 compilers
('-O3 -msse2 -m32" options were used), for example 

grep -c "%esp" t1.4.8.2.s   
25
grep -c "%esp" t1.trunk.s   
75

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[ysrumyan at gmail dot com]

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

--- Comment #1 from Yuri Rumyantsev  ---
Created attachment 34782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34782&action=edit
test-case to reproduce

Options -m32 -msse2 -O3 must be used.

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-02-16
 Ever confirmed|0   |1

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

4.8 has

  _62 = MEM[(__m64 * {ref-all})dest_284];
  _63 = VIEW_CONVERT_EXPR(_62);
  _64 = {_63, 0};
  _65 = VIEW_CONVERT_EXPR(_64);
  _66 = __builtin_ia32_punpcklbw128 (_65, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0 });
  _67 = VIEW_CONVERT_EXPR<__m128i>(_66);
  _68 = VIEW_CONVERT_EXPR(_67);
  _70 = __builtin_ia32_paddw128 (pretmp_327, _68);
  _71 = __builtin_ia32_packuswb128 (_70, _70);
  _72 = VIEW_CONVERT_EXPR<__m128i>(_71);
  _73 = __builtin_ia32_vec_ext_v2di (_72, 0);
  MEM[(long long int *)dest_284] = _73;

while 5

  _79 = MEM[(__m64 * {ref-all})dest_268];
  _78 = VIEW_CONVERT_EXPR(_79);
  _77 = {_78, 0};
  _74 = VIEW_CONVERT_EXPR(_77);
  _73 = __builtin_ia32_punpcklbw128 (_74, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0 });
  _69 = VIEW_CONVERT_EXPR(_73);
  _68 = _69 + pretmp_312;
  _67 = VIEW_CONVERT_EXPR(_68);
  _64 = __builtin_ia32_packuswb128 (_67, _67);
  _63 = VIEW_CONVERT_EXPR<__m128i>(_64);
  _62 = BIT_FIELD_REF <_63, 64, 0>;
  MEM[(long long int *)dest_268] = _62;

so some intrinsics are no longer builtins.  But the real difference is
the following weird store sequence

packuswb%xmm1, %xmm2
movaps  %xmm2, (%esp)
movl(%esp), %esi
movl4(%esp), %edi
movl%esi, (%eax)
movl%edi, 4(%eax)

compared to just

packuswb%xmm1, %xmm1
movq%xmm1, (%edx)

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Similar to PR21182 ?

As suggested in the above PR, does "-fschedule-insns -fsched-pressure" make any
difference?

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra
 Target||i?86-*-*
 CC||vmakarov at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Seems LRA does a very bad job here for some reason.

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #3)
> Similar to PR21182 ?
> 
> As suggested in the above PR, does "-fschedule-insns -fsched-pressure" make
> any difference?

No.

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Seems this has started with r216247, and indeed, compiling the testcase with
-std=gnu89 even with latest trunk results in those 25 %esp references, while
using -std=gnu11 even with r19 results in 69 %esp references.

[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target|i?86-*-*|
 Status|WAITING |NEW
 CC||hubicka at gcc dot gnu.org
  Component|regression  |ipa
  Known to fail||5.0

--- Comment #7 from Markus Trippelsdorf  ---
markus@x4 tmp % cat fmgridif.ii
template  class A
{
  T *p;

public:
  A (T *p1) : p (p1) { p->acquire (); }
};

class B
{
public:
  virtual void acquire ();
};
class D : public B
{
};
class F : B
{
  int mrContext;
};
class WindowListenerMultiplexer : F, public D
{
  void
  acquire ()
  {
acquire ();
  }
};
class C
{
  void createPeer () throw ();
  WindowListenerMultiplexer maWindowListeners;
};
class FmXGridPeer
{
public:
  void addWindowListener (A);
} a;
void
C::createPeer () throw ()
{
  a.addWindowListener (&maWindowListeners);
}

markus@x4 tmp % g++ -Os -c fmgridif.ii && nm --demangle fmgridif.o | grep
WindowListenerMultiplexer
 U non-virtual thunk to WindowListenerMultiplexer::acquire()

markus@x4 tmp % g++ -O2 -c fmgridif.ii && nm --demangle fmgridif.o | grep
WindowListenerMultiplexer
 W WindowListenerMultiplexer::acquire()
0010 W non-virtual thunk to WindowListenerMultiplexer::acquire()

Not sure if the devirtualization is valid. Honza?

[Bug fortran/65079] New: -Werror= does not work on implicit-procedure warning

[nathanael.huebbe at informatik dot uni-hamburg.de]

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

Bug ID: 65079
   Summary: -Werror= does not work on implicit-procedure warning
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathanael.huebbe at informatik dot uni-hamburg.de

System: Ubuntu
Affected gfortran versions: at least 4.7.2 and 4.8.2

Description:
Compiling this fortran code

module bar
implicit none
contains
subroutine baz()
call bim()
end subroutine
end module

program foo
use bar

call baz()
end program

with the call

$ gfortran -c -Wimplicit-procedure -Werror=implicit-procedure foo.f90

correctly produces the warning, but fails to turn it into an error.

The behavior is the same if `-Wimplicit-procedure` is absent, and if
`implicit-procedure` is replaced by `-Wimplicit-interface`.

[Bug rtl-optimization/65078] [5.0 Regression] 4.9 and 5.0 generate more spill-fill in comparison with 4.8.2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Ah, if I hack up the preprocessed source, so that some functions like atoi,
gnu_dev_major etc. are __attribute__((__gnu_inline__)), I get 25 %esp
references both with latest trunk and 4.8.  So, I really can't reproduce...

[Bug tree-optimization/63593] ICE: verify_gimple failed: incompatible types in PHI argument 0 with -O3 -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||5.0
  Known to fail|5.0 |

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/63593] ICE: verify_gimple failed: incompatible types in PHI argument 0 with -O3 -fno-tree-vectorize

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Mon Feb 16 14:52:14 2015
New Revision: 220734

URL: https://gcc.gnu.org/viewcvs?rev=220734&root=gcc&view=rev
Log:
2015-02-16  Richard Biener  

PR tree-optimization/63593
* tree-predcom.c (execute_pred_commoning_chain): Delay removing
stmts and releasing SSA names until...
(execute_pred_commoning): ... after processing all chains.

* gcc.dg/pr63593.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr63593.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-predcom.c

[Bug lto/65015] LTO produces randomly ordered debug information

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
Finally fixed for 5.0 with reasonably backportable patches.

[Bug lto/65015] LTO produces randomly ordered debug information

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener  ---
Author: rguenth
Date: Mon Feb 16 14:53:23 2015
New Revision: 220735

URL: https://gcc.gnu.org/viewcvs?rev=220735&root=gcc&view=rev
Log:
2015-02-16  Richard Biener  

PR lto/65015
* varasm.c (default_file_start): For LTO produced units
emit  as file directive.

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

[Bug fortran/65079] -Werror= does not work on implicit-procedure warning

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-02-16
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on 4.9. It works with trunk (5.0).

pr65079.f90:6:22:

 call bim()
  1
Error: Procedure 'bim' called at (1) is not explicitly declared
[-Werror=implicit-procedure]
pr65079.f90:11:12:

 use bar
1
Fatal Error: Can't open module file 'bar.mod' for reading at (1): No such file
or directory
f951: some warnings being treated as errors
compilation terminated.

I doubt this will be back ported to 4.9.

[Bug fortran/65024] [4.9/5 Regression] [OOP] ICE concerning unlimited polymorphic pointer

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> > AFAICT the ICE for the original test is as old as the first implementation
> > of unlimited polymorphism.
>
> In that case, should we remove the '[4.9/5 Regression]' tag from the summary 
> title?

Please don't do that.

(1) The ICE for the reduced test in comment 2 is a regression. Leave some time
to Janus to look at the problem:

> > > The ICE for the reduced test in comment 2 [...]
> > Started at r207986.
>
> Huh, that was me committing a patch for PR 60234. Guess I should take a look
> (but will probably not manage to do so before the weekend ...)

(2) There are presently more than 800 open PRs, but less than 40 regressions
that can be fixed during stage 4.

[Bug testsuite/64145] [5 Regression] gcc.dg/graphite/isl-codegen-loop-dumping.c UNRESOLVED after r217315.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #6 from Marek Polacek  ---
So fixed?

[Bug ipa/65059] [5 Regression] Chrome LTO: lto1: internal compiler error: in ipa_comdats, at ipa-comdats.c:360

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
So fixed?

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #25 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #19)

Are we going with this fix? If so. please post it to gcc-patches with a
ChangeLog.

[Bug ipa/65006] [5 Regression] 252.eon in SPEC CPU 2000 miscompiled with LTO

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---
Summary|[5 Regression] 252.eon in   |[5 Regression] 252.eon in
   |SPEC CPU 2000 miscompiled   |SPEC CPU 2000 miscompiled
   ||with LTO

--- Comment #11 from H.J. Lu  ---
r220521 miscompiled 252.eon in SPEC CPU 2000 with LTO for both x86-32:

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01063.html

and x32:

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01047.html

X86-32 was fixed:

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01417.html

But not:

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01406.html

I got

[hjl@gnu-mic-2 0002]$ ../0002/eon_peak.lto chair.control.cook
chair.camera chair.surfaces chair.cook.ppm ppm pixels_out.cook
Segmentation fault
[hjl@gnu-mic-2 0002]$ gdb ../0002/eon_peak.lto
GNU gdb (GDB) Fedora 7.7.1-21.fc20
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../0002/eon_peak.lto...done.
(gdb) r chair.control.cook chair.camera chair.surfaces chair.cook.ppm ppm
pixels_out.cook
Starting program:
/export/project/git/gcc-regression/spec/2000/spec/benchspec/CINT2000/252.eon/run/0002/eon_peak.lto
chair.control.cook chair.camera chair.surfaces chair.cook.ppm ppm
pixels_out.cook

Program received signal SIGSEGV, Segmentation fault.
0x0042078c in operator*(ggSpectrum const&, ggSpectrum const&) ()
Missing separate debuginfos, use: debuginfo-install glibc-2.18-16.0.fc20.x32
libgcc-4.8.3-7.2.fc20.x86_64 libstdc++-4.8.3-7.2.fc20.x86_64
(gdb) bt
#0  0x0042078c in operator*(ggSpectrum const&, ggSpectrum const&) ()
#1  0x004452d4 in eonImageCalculator::eonImageCalculator() ()
#2  0x0040378a in main ()
(gdb) f 0
#0  0x0042078c in operator*(ggSpectrum const&, ggSpectrum const&) ()
(gdb) disass
Dump of assembler code for function _ZmlRK10ggSpectrumS1_:
   0x00420780 <+0>:movups (%esi),%xmm0
   0x00420784 <+4>:mov%rdi,%rax
   0x00420787 <+7>:movups 0x10(%esi),%xmm1
=> 0x0042078c <+12>:mulps  (%edx),%xmm0
   0x00420790 <+16>:mulps  0x10(%edx),%xmm1
   0x00420795 <+21>:movups %xmm0,(%edi)
   0x00420799 <+25>:movups %xmm1,0x10(%edi)
   0x0042079e <+30>:retq   
End of assembler dump.
(gdb) p $edx
$1 = -13304
(gdb) p/x $edx
$2 = 0xcc08

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[iains at gcc dot gnu.org]

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

--- Comment #26 from Iain Sandoe  ---
(In reply to howarth from comment #25)
> (In reply to Iain Sandoe from comment #19)
> 
> Are we going with this fix? If so. please post it to gcc-patches with a
> ChangeLog.

was posted 3rd Feb
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00122.html

[Bug fortran/65024] [4.9/5 Regression] [OOP] ICE concerning unlimited polymorphic pointer

[matt at gneilson dot plus.com]

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

--- Comment #9 from homgran  ---
(In reply to Dominique d'Humieres from comment #8)
> > > AFAICT the ICE for the original test is as old as the first implementation
> > > of unlimited polymorphism.
> >
> > In that case, should we remove the '[4.9/5 Regression]' tag from the 
> > summary title?
> 
> Please don't do that.
> 
> (1) The ICE for the reduced test in comment 2 is a regression. Leave some
> time to Janus to look at the problem:
> 
> > > > The ICE for the reduced test in comment 2 [...]
> > > Started at r207986.
> >
> > Huh, that was me committing a patch for PR 60234. Guess I should take a look
> > (but will probably not manage to do so before the weekend ...)
> 
> (2) There are presently more than 800 open PRs, but less than 40 regressions
> that can be fixed during stage 4.

No problem, I was just checking. This is my first time using bugzilla, so I'm
happy to just sit back and observe (perhaps making the occasional comment). I
certainly don't want to get in anybody's way!

[Bug bootstrap/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

[dje at gcc dot gnu.org]

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

--- Comment #12 from David Edelsohn  ---
Author: dje
Date: Mon Feb 16 15:19:20 2015
New Revision: 220736

URL: https://gcc.gnu.org/viewcvs?rev=220736&root=gcc&view=rev
Log:
Daniel Richard G. 
PR bootstrap/48009
PR bootstrap/53348
* inclhack.def (aix_strtof_const): New fix.
* fixincl.x: Regenerate.
* tests/base/inttypes.h: New test.

Modified:
trunk/fixincludes/ChangeLog
trunk/fixincludes/fixincl.x
trunk/fixincludes/inclhack.def

[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

[dje at gcc dot gnu.org]

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

--- Comment #10 from David Edelsohn  ---
Author: dje
Date: Mon Feb 16 15:19:20 2015
New Revision: 220736

URL: https://gcc.gnu.org/viewcvs?rev=220736&root=gcc&view=rev
Log:
Daniel Richard G. 
PR bootstrap/48009
PR bootstrap/53348
* inclhack.def (aix_strtof_const): New fix.
* fixincl.x: Regenerate.
* tests/base/inttypes.h: New test.

Modified:
trunk/fixincludes/ChangeLog
trunk/fixincludes/fixincl.x
trunk/fixincludes/inclhack.def

[Bug ipa/65059] [5 Regression] Chrome LTO: lto1: internal compiler error: in ipa_comdats, at ipa-comdats.c:360

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Fixed in 5.0.

[Bug bootstrap/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

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

[Bug target/65058] AIX: missing extern decorations "[DS]" for functions and "[UA]" for variables

[dje at gcc dot gnu.org]

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

--- Comment #3 from David Edelsohn  ---
Author: dje
Date: Mon Feb 16 15:33:09 2015
New Revision: 220737

URL: https://gcc.gnu.org/viewcvs?rev=220737&root=gcc&view=rev
Log:
2015-02-16  Michael Haubenwallner  
David Edelsohn  

PR target/65058
* config/rs6000/rs6000.c (rs6000_output_symbol_ref): Append storage
mapping class to external variable or function reference.
* config/rs6000/xcoff.h (ASM_OUTPUT_EXTERNAL): Do not append storage
mapping class.

2015-02-16  David Eelsohn  

PR target/53348
* config/rs6000/rs6000.c (rs6000_declare_alias): Only use
ASM_WEAKEN_DECL if defined.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/xcoff.h

[Bug bootstrap/53348] Conflicting fast-integer types on AIX: vs. gcc/config/rs6000/aix-stdint.h

[dje at gcc dot gnu.org]

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

--- Comment #11 from David Edelsohn  ---
Author: dje
Date: Mon Feb 16 15:33:09 2015
New Revision: 220737

URL: https://gcc.gnu.org/viewcvs?rev=220737&root=gcc&view=rev
Log:
2015-02-16  Michael Haubenwallner  
David Edelsohn  

PR target/65058
* config/rs6000/rs6000.c (rs6000_output_symbol_ref): Append storage
mapping class to external variable or function reference.
* config/rs6000/xcoff.h (ASM_OUTPUT_EXTERNAL): Do not append storage
mapping class.

2015-02-16  David Eelsohn  

PR target/53348
* config/rs6000/rs6000.c (rs6000_declare_alias): Only use
ASM_WEAKEN_DECL if defined.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/xcoff.h

[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Reduced test

program test
  implicit none
  type t
integer :: ii
  end type t
  type, extends(t) :: u
real :: rr
  end type u
  type, extends(t) :: v
real, allocatable :: rr(:)
  end type v
  type, extends(v) :: w
real, allocatable :: rrr(:)
  end type w

  type(v) :: b(3)

  b = func7() ! scalar daughter type to array - alloc comps in parent type

contains

  function func7() result(res)
class(v), allocatable :: res
allocate (res, source = w(3,[10.0,20.0],[100,200]))
  end function func7

end program test

There is no problem with the original test once the following lines are
commented

  b = func7() ! scalar daughter type to array - alloc comps in parent type
  if (any (b(2)%rr .ne. [10.0,20.0])) call abort

[Bug target/65058] AIX: missing extern decorations "[DS]" for functions and "[UA]" for variables

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

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

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

[Bug libstdc++/64883] FAIL: 17_intro/headers/c++*/all_attributes.cc (test for excess errors) on x86_64-apple-darwin14

[howarth at bromo dot med.uc.edu]

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

--- Comment #27 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #26)
> (In reply to howarth from comment #25)
> > (In reply to Iain Sandoe from comment #19)
> > 
> > Are we going with this fix? If so. please post it to gcc-patches with a
> > ChangeLog.
> 
> was posted 3rd Feb
> https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00122.html

Pinged but probably would had better exposure if posted as its a new thread for
your own patch proposal.

[Bug c++/65080] New: constexpr-ness lost by using alias in definition

[kaballo86 at hotmail dot com]

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

Bug ID: 65080
   Summary: constexpr-ness lost by using alias in definition
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaballo86 at hotmail dot com

In the following snippet, whether the expression `xxx` designates a
constexpr function or not depends on whether `foo::value` is defined with an
alias or not:

template 
static constexpr T xxx(){ return T(); }

template 
struct foo {
  using type = T(*)();
  static constexpr type value[1] = {&xxx};
};

template 
constexpr typename foo::type foo::value[1]; // fails
//constexpr T (*foo::value[1])(); // works

int main() {
  constexpr int x = foo::value[0](); // error here
}

Both definitions work fine in trunk. I couldn't find a PR for it, so I'm
reporting it anyways to make sure there is a test covering it.