[Bug lto/65380] [5 Regression] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  ---
(In reply to Jan Hubicka from comment #4)
> Hmm, this one compiles just fine for me with today mainline.  Does the
> problem still reproduce for you?  Can you possibly dump out node->debug()
> and c?

Unfortunately, it still fails for me with today's r221445 (for the very first
invocation of line lto-partition.c:158). For

157   gcc_assert (c != SYMBOL_EXTERNAL
158   && (c == SYMBOL_DUPLICATE || !symbol_partitioned_p (node)));


Running

lto1 -quiet -dumpbase one.o -mtune=generic -march=x86-64 -mtune=generic
-march=x86-64 -auxbase one -O2 -version -fexceptions -fmath-errno
-fsigned-zeros -ftrapping-math -fno-trapv -fno-openmp -fno-openacc
-fltrans-output-list=/tmp/ccX5yPa0.ltrans.out -fwpa -fresolution=two.res
@/tmp/ccYbGLe0

in the debugger gives:


(gdb) p c
$1 = SYMBOL_EXTERNAL

(gdb) p node->debug()
_ZTCSt14basic_ofstreamIcSt11char_traitsIcEE0_So/188
(_ZTCSt14basic_ofstreamIcSt11char_traitsIcEE0_So) @0x71d38880
  Type: variable definition analyzed alias
  Visibility: externally_visible external public visibility_specified
visibility:hidden virtual artificial
  References: _ZTCN7Utility2IO12GUnzipStreamE0_So/7 (alias)
  Referring: _ZTTSt14basic_ofstreamIcSt11char_traitsIcEE/178
(addr)_ZTTSt14basic_ofstreamIcSt11char_traitsIcEE/178 (addr)
  Availability: available
  Varpool flags: read-only const-value-known
$2 = void

[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

Summary|[5 Regression] LTO: ICE in  |[5 Regression][ICF] LTO:
   |add_symbol_to_partition_1,  |ICE in
   |at lto/lto-partition.c:158  |add_symbol_to_partition_1,
   ||at lto/lto-partition.c:158

--- Comment #6 from Tobias Burnus  ---
Note that it compiles if I add "-fno-ipa-icf".

[Bug debug/46136] ICE: in size_of_dcall_table, at dwarf2out.c:12387 with -fenable-icf-debug

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Tobias Burnus  ---
-fenable-icf-debug has been removed March 2011 in commit r171037.

Thus, I close this bug as WONTFIX; if the issue can be reproduced with still
existing options in the current GCC version, feel free to reopen.

[Bug debug/46135] ICE: in splice_child_die, at dwarf2out.c:7627 with -g1 -femit-class-debug-always -fenable-icf-debug

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Tobias Burnus  ---
-fenable-icf-debug has been removed March 2011 in commit r171037.

Thus, I close this bug as WONTFIX; if the issue can be reproduced with still
existing options in the current GCC version, feel free to reopen

[Bug debug/46132] ICE: in force_decl_die, at dwarf2out.c:20525 with -fenable-icf-debug

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from Tobias Burnus  ---
-fenable-icf-debug has been removed March 2011 in commit r171037.

Thus, I close this bug as WONTFIX; if the issue can be reproduced with still
existing options in the current GCC version, feel free to reopen

[Bug debug/46138] ICE: SIGSEGV in htab_hash_string (hashtab.c:847) with -g -fenable-icf-debug for almost any fortran program

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #1 from Tobias Burnus  ---
-fenable-icf-debug has been removed March 2011 in commit r171037.

Thus, I close this bug as WONTFIX; if the issue can be reproduced with still
existing options in the current GCC version, feel free to reopen

[Bug debug/44689] -fenable-icf-debug causes segfault in cp_function_decl_explicit_p

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #4 from Tobias Burnus  ---
-fenable-icf-debug has been removed March 2011 in commit r171037.

Thus, I close this bug as WONTFIX; if the issue can be reproduced with still
existing options in the current GCC version, feel free to reopen

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #20 from Paul Thomas  ---
Patch posted last night: https://gcc.gnu.org/ml/fortran/2015-03/msg00069.html

A somewhat better version might emerge tonight now that I understand better
what was happening.

Thanks for your patience on this one Juergen! As you were aware, I kept coming
back to it but did not have much joy until yesterday because I was sniffing
around the wrong symptoms.

Cheers

Paul

[Bug regression/63150] [4.9 Regression] FAIL: gcc.target/powerpc/pr53199.c scan-assembler-times *

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[4.9/5 regression] FAIL:|[4.9 Regression] FAIL:
   |gcc.target/powerpc/pr53199. |gcc.target/powerpc/pr53199.
   |c scan-assembler-times *|c scan-assembler-times *

--- Comment #6 from Jakub Jelinek  ---
So fixed on the trunk.

[Bug c++/65390] ICE in strip_typedefs, at cp/tree.c:1361

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.  It appears that 4.9/4.8 ICE too.

[Bug c++/65390] ICE in strip_typedefs, at cp/tree.c:1361

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Might be a dup of PR63584.

[Bug c++/65390] ICE in strip_typedefs, at cp/tree.c:1361

[alserkli at inbox dot ru]

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

--- Comment #3 from Alexander Klimov  ---
(In reply to Marek Polacek from comment #2)
> Might be a dup of PR63584.

PR63584 does not produce ICE in 5.0

[Bug c++/65340] [5 Regression] [C++14]ICE in mark_used, at decl2.c:5040

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-16
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.0
Summary|[C++14]ICE in mark_used, at |[5 Regression] [C++14]ICE
   |decl2.c:5040|in mark_used, at
   ||decl2.c:5040
 Ever confirmed|0   |1

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

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
Created attachment 35039
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35039&action=edit
Patch for discussion

OK so this is a frustrating area to debug.  One can see the problem easily
enough - but finding where it's introduced ... 

Question:
 Is there a reason that we don't have a constraint for DS-mode operands?
 Since there are so few constraint letters left, I have not attempted to add
one - but curious about the reason.

The patch is intended to do the following:
 1. record that macho-pic indirections are always sufficiently aligned that a
ds-mode offset is applicable (they reside in special sections with guaranteed
alignment) - the picbase is also guaranteed to be aligned to 32b since it's a
code label.
 - changes to config/darwin.{c,h}

 2. I've added a new predicate (put it in darwin.md, for now since I'm just
testing).
 - the predicate tries to look through the various cases to determine when a
ds-mode operand is safe.

 3. This is the bit that is in generic code and needs review:

ISTM that the Y constraint code needs an additional check - at least for Darwin
- if *only* for darwin, then I'm happy to conditionalise it on TARGET_MACHO. 
However, it's not obvious to me that no other target could be affected.

What can happen is that the offset to the mem returns NULL_RTX (no offset) but
there's actually quite a complex address expression - and that might not
resolve to a sufficiently aligned object.  Presently, the code just assumes
that no offset means it's OK.


--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -6378,11 +6378,20 @@ mem_operand_gpr (rtx op, machine_mode mode)
 {
   unsigned HOST_WIDE_INT offset;
   int extra;
+  unsigned align = MEM_ALIGN (op);
   rtx addr = XEXP (op, 0);
-
   op = address_offset (addr);
   if (op == NULL_RTX)
-return true;
+{
+  /* No offset:
+ A naked reg is OK - any alignment works.  */
+  if (REG_P (addr))
+return true ;
+  /* Otherwise, we assume there will be a relocation, and we can't
+guarantee it will fit unless the object referred to is sufficiently
+aligned.  */
+  return align >= 32;
+}


NOTE: there are some debug changes in the patch - this is not intended for
submission until point 3 is reviewed.

[Bug c++/65327] GCC rejects "constexpr volatile int i = 5;"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Confirmed then.  I wonder if

--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -10134,8 +10134,9 @@ grokdeclarator (const cp_declarator *declarator,
  the object as `const'.  */
   if (constexpr_p && innermost_code != cdk_function)
 {
-  if (type_quals & TYPE_QUAL_VOLATILE)
-error ("both % and % cannot be used here");
+  /* DR1688 says that a `constexpr' specifier in combination with
+ `volatile' is valid.  */
+
   if (TREE_CODE (type) != REFERENCE_TYPE)
 {
   type_quals |= TYPE_QUAL_CONST;

is enough...

[Bug rtl-optimization/64895] RA picks the wrong register for -fipa-ra

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Mar 16 09:42:21 2015
New Revision: 221448

URL: https://gcc.gnu.org/viewcvs?rev=221448&root=gcc&view=rev
Log:
Revert 'Use actual_call_used_reg_set to find conflicting regs'

2015-03-16  Tom de Vries  

PR middle-end/65414
Revert:
2015-03-12  Tom de Vries  

PR rtl-optimization/64895
* lra-lives.c (check_pseudos_live_through_calls): Use
actual_call_used_reg_set instead of call_used_reg_set, if available.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-lives.c

[Bug middle-end/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu

[vries at gcc dot gnu.org]

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

--- Comment #13 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Mar 16 09:42:21 2015
New Revision: 221448

URL: https://gcc.gnu.org/viewcvs?rev=221448&root=gcc&view=rev
Log:
Revert 'Use actual_call_used_reg_set to find conflicting regs'

2015-03-16  Tom de Vries  

PR middle-end/65414
Revert:
2015-03-12  Tom de Vries  

PR rtl-optimization/64895
* lra-lives.c (check_pseudos_live_through_calls): Use
actual_call_used_reg_set instead of call_used_reg_set, if available.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-lives.c

[Bug rtl-optimization/64895] RA picks the wrong register for -fipa-ra

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Patch has been reverted.

[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.

[jakub at gcc dot gnu.org]

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

Bug 64895 Summary: RA picks the wrong register for -fipa-ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895

   What|Removed |Added

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

[Bug middle-end/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from vries at gcc dot gnu.org ---
Problematic patch has been reverted, so this PR should be fixed.

The original PR related to the PR, PR 64895 has beeen reopened.

[Bug c++/65314] invalid type for array subscript

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Marek Polacek  ---
Closing out, see Daniel's reply.

[Bug c++/65327] GCC rejects "constexpr volatile int i = 5;"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |4.8.5

--- Comment #3 from Marek Polacek  ---
Seems it is, taking.  4.8/4.9 have the same problem.

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Mar 16 10:26:28 2015
New Revision: 221453

URL: https://gcc.gnu.org/viewcvs?rev=221453&root=gcc&view=rev
Log:
PR middle-end/65409
* expr.c (store_field): Do not do a direct block copy if the source is
a PARALLEL with BLKmode.

Added:
trunk/gcc/testsuite/g++.dg/pr65049.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Mar 16 10:28:39 2015
New Revision: 221454

URL: https://gcc.gnu.org/viewcvs?rev=221454&root=gcc&view=rev
Log:
PR middle-end/65409
* expr.c (store_field): Do not do a direct block copy if the source is
a PARALLEL with BLKmode.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr65049.C
  - copied unchanged from r221453, trunk/gcc/testsuite/g++.dg/pr65049.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/expr.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c++/65327] GCC rejects "constexpr volatile int i = 5;"

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Presumably started with r166013.

Note that in
constexpr volatile int a = 42;
constexpr int b = a;
the initialization of b should be rejected, but it is not.  This is a related
problem though, my patch doesn't change it.

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Mar 16 10:30:29 2015
New Revision: 221456

URL: https://gcc.gnu.org/viewcvs?rev=221456&root=gcc&view=rev
Log:
PR middle-end/65409
* expr.c (store_field): Do not do a direct block copy if the source is
a PARALLEL with BLKmode.

Added:
branches/gcc-4_8-branch/gcc/testsuite/g++.dg/pr65049.C
  - copied unchanged from r221454, trunk/gcc/testsuite/g++.dg/pr65049.C
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/expr.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug middle-end/65409] [4.8/4.9/5 Regression] ICE in store_field

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #14 from Eric Botcazou  ---
Thanks for reporting the problem.

[Bug c++/65340] [5 Regression] [C++14]ICE in mark_used, at decl2.c:5040

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r214396.

[Bug ipa/65432] [5 Regression] Invalid read of size 1: ipa_icf::sem_item_optimizer::merge_classes(unsigned int) (ipa-icf.c:2958)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Can't reproduce on x86_64-linux.

[Bug c++/65312] Implicitly-declared default constructor must be defined as deleted

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Looks like this PR could be resolved as a NOTABUG?

[Bug middle-end/65431] [5 Regression] Invalid read of size 8 at 0x105DBBF8: delete_omp_context(unsigned long) (omp-low.c:1586)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-03-16
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

[Bug middle-end/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu

[vries at gcc dot gnu.org]

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

--- Comment #15 from vries at gcc dot gnu.org ---
If somebody happens to have a commandline and .i file with which the problem
can be reproduced using a non-bootstrap compiler, please attach it here.

Thanks,
- Tom

[Bug c++/65269] internal compiler error: Segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Assuming fixed.

[Bug libstdc++/65434] New: Memory leak in pool constructor

[mitya57 at gmail dot com]

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

Bug ID: 65434
   Summary: Memory leak in pool constructor
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mitya57 at gmail dot com

Constructor of `pool' class in eh_alloc.c has the following code:

pool::pool()
  {
// Allocate the arena - we could add a GLIBCXX_EH_ARENA_SIZE environment
// to make this tunable.
arena_size = (EMERGENCY_OBJ_SIZE * EMERGENCY_OBJ_COUNT
  + EMERGENCY_OBJ_COUNT * sizeof (__cxa_dependent_exception));
arena = (char *)malloc (arena_size);

  }

The memory allocated by `malloc (arena_size)' is never freed, because that
class does not have a destructor. This results in a memory leak. Valgrind
reports:

18,944 bytes in 1 blocks are still reachable in loss record 1 of 1
   at 0x40291CC: malloc (vg_replace_malloc.c:296)
   by 0x40D630A: pool (eh_alloc.cc:117)
   by 0x40D630A: __static_initialization_and_destruction_0 (eh_alloc.cc:244)
   by 0x40D630A: _GLOBAL__sub_I_eh_alloc.cc (eh_alloc.cc:307)
   by 0x400E86D: call_init.part.0 (dl-init.c:78)
   by 0x400E963: call_init (dl-init.c:36)
   by 0x400E963: _dl_init (dl-init.c:126)
   by 0x4000D3E: ??? (in /lib/i386-linux-gnu/ld-2.19.so)

This happens with the current gcc-5 snapshot, but did not happen with 4.9.

It was broken in revision 219988 (PR libstdc++/64535).

[Bug c++/65071] ICE on valid, sizeof...() of template template parameter pack in return type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I can confirm the ICE.

[Bug tree-optimization/65427] [4.8/4.9/5 Regression] ICE in emit_move_insn with wide vector types

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-16
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.8.5
Summary|ICE in emit_move_insn with  |[4.8/4.9/5 Regression] ICE
   |wide vector types   |in emit_move_insn with wide
   ||vector types
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
r178392 works, r178445 already ICEs, so r178408 looks like the most probable
candidate.
Reduced testcase for -O2 -ftree-vectorize:
typedef int V __attribute__ ((vector_size (32)));
V a, d, e, f;

void
foo (int b, int c)
{
  do
{
  if (b)
f = a ^ d;
  else
f = e = a ^ d;
}
  while (c);
}

[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.

[chefmax at gcc dot gnu.org]

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

--- Comment #2 from Maxim Ostapenko  ---
Author: chefmax
Date: Mon Mar 16 11:17:32 2015
New Revision: 221457

URL: https://gcc.gnu.org/viewcvs?rev=221457&root=gcc&view=rev
Log:
2015-03-16  Max Ostapenko  

PR sanitizer/64820

gcc/
* cfgexpand.c (align_base): New function.
(alloc_stack_frame_space): Call it.
(expand_stack_vars): Align prev_frame to be sure
data->asan_vec elements aligned properly.

gcc/testsuite/
* c-c++-common/asan/pr64820.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/asan/pr64820.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[juergen.reuter at desy dot de]

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

--- Comment #21 from Jürgen Reuter  ---
(In reply to Paul Thomas from comment #20)
> Patch posted last night: https://gcc.gnu.org/ml/fortran/2015-03/msg00069.html
> 
> A somewhat better version might emerge tonight now that I understand better
> what was happening.
> 
> Thanks for your patience on this one Juergen! As you were aware, I kept
> coming back to it but did not have much joy until yesterday because I was
> sniffing around the wrong symptoms.
> 
> Cheers
> 
> Paul

Paul, no worries, we were able to find a workaround in our code, so the issue
was not too pressing. But thanks for looking into it!

[Bug sanitizer/65435] New: UBsan runtime error reports in OpenSSL aes_core.c

[bernd.edlinger at hotmail dot de]

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

Bug ID: 65435
   Summary: UBsan runtime error reports in OpenSSL aes_core.c
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Hi,

I am not quite sure if this is a bug in OpenSSL or in UBSan.
This gets reported by ubsan in OpenSSL 1.0.0m 5 Jun 2014:

aes_core.c:1144:30: runtime error: left shift of 136 by 24 places cannot be
represented in type 'int'
aes_core.c:1151:30: runtime error: left shift of 158 by 24 places cannot be
represented in type 'int'
aes_core.c:1137:30: runtime error: left shift of 239 by 24 places cannot be
represented in type 'int'
aes_core.c:1130:30: runtime error: left shift of 139 by 24 places cannot be
represented in type 'int'


when I look at that lines, I see the following (repeated 4 times):

s0 =
(Td4[(t0 >> 24)   ] << 24) ^
(Td4[(t3 >> 16) & 0xff] << 16) ^
(Td4[(t2 >>  8) & 0xff] <<  8) ^
(Td4[(t1  ) & 0xff])   ^
rk[0];

and
static const u8 Td4[256] = {
0x52U, 0x09U, 0x6aU, 0xd5U, 0x30U, 0x36U, 0xa5U, 0x38U, ...

I assume u8 means unsigned char.
So are we correct to convert u8 to int before << 24,
or should it be u8 to unsigned int before << 24, what OpenSSL
apparently expects?

[Bug sanitizer/65435] UBsan runtime error reports in OpenSSL aes_core.c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Marek Polacek  ---
The integer promotions are performed on each of the operands (6.5.7#3).  So
we're correct to convert u8 to int.

[Bug sanitizer/65435] UBsan runtime error reports in OpenSSL aes_core.c

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
OpenSSL of course.  136 << 24 is not representable in int.
This is undefined behavior in C99/C11, and defined behavior in C++11.
Quoting C99 6.5.7/4:
"The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are
filled with zeros. If E1 has an unsigned type, the value of the result is E1 ×
2 ^ E2, reduced modulo one more than the maximum value representable in the
result type. If E1 has a signed type and nonnegative value, and E1 × 2 ^ E2 is
representable in the result type, then that is the resulting value; otherwise,
the behavior is undefined."

[Bug tree-optimization/65427] [4.8/4.9/5 Regression] ICE in emit_move_insn with wide vector types

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
I think the bug is that tree-vect-generic.c doesn't lower COND_EXPRs, only
VEC_COND_EXPRs.

[Bug target/65358] wrong parameter passing code with tail call optimization on arm

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #10 from ktkachov at gcc dot gnu.org ---
Hmmm, I have a fix to check_sibcall_argument_overlap in calls.c that's supposed
to catch the overlap in accesses on the stack and correctly identify the
conflict. This detection has the effect of getting gcc to decide that it can't
do a tail-call here. I wonder, is this the way to go i.e. should we indeed be
disabling sibcalls in this case? I think so, if the ABI demands that part of
the struct is passed on the stack...

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[amodra at gmail dot com]

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

--- Comment #12 from Alan Modra  ---
We won't want that mem_operand_gpr change for Linux or AIX as we do the
alignment checking of more complex expressions in legitimate_address_p.
Do take heed to the comment about accepting odd rtl generated by reload..

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[iains at gcc dot gnu.org]

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

--- Comment #13 from Iain Sandoe  ---
(In reply to Alan Modra from comment #12)
> We won't want that mem_operand_gpr change for Linux or AIX as we do the
> alignment checking of more complex expressions in legitimate_address_p.
> Do take heed to the comment about accepting odd rtl generated by reload..

Hmm.. OK.
FWIW, I did try to track through legitimate_address_p to see if i could
identify where the problem was being introduced (without much luck). Will have
to look again.

[Bug fortran/60500] [4.8/4.9/5 Regression] Spurious warning on derived type initialization

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #5 from Mikael Morin  ---
(In reply to Richard Biener from comment #2)
> possibly the L.1 label is misplaced?  At least the result would crash if
> malloc returned NULL.
> 
Mmh, yes;  it seems L.1 should come after the (default-)initialization of the
just allocated array.
There is nothing that can be done inside gfc_trans_allocate, because
initialization comes from a frontend-generated statement after the allocate
statement (introduced at revision r164305).

[Bug c++/64954] GCC incorrectly rejects constexpr variable initialization.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/64261] false branch of conditional operator ?: evaluated in a template constexpr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Me neither.  Closing out.

[Bug c/65436] New: Max number of extended asm +input operands currently limited to 15

[adam at consulting dot net.nz]

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

Bug ID: 65436
   Summary: Max number of extended asm +input operands currently
limited to 15
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam at consulting dot net.nz

 states:
"The total number of input + output + goto operands is limited to 30."

It appears a "+" input operand is internally counted as a dual input plus
output operand which limits the total number of such registers to 15:

30_operands.c:
#include 

typedef uint8_t u8x16_t __attribute__ ((vector_size (16)));

int main(void) {
  register uint64_t rdi asm ("rdi");
  register uint64_t rsi asm ("rsi");
  register uint64_t r10 asm ("r10");
  register uint64_t r11 asm ("r11");
  register uint64_t rbx asm ("rbx");
  register uint64_t rbp asm ("rbp");
  register uint64_t r12 asm ("r12");
  register uint64_t r14 asm ("r14");
  register uint64_t r15 asm ("r15");
  register uint64_t r13 asm ("r13");
  register u8x16_t xmm2 asm ("xmm2");
  register u8x16_t xmm3 asm ("xmm3");
  register u8x16_t xmm4 asm ("xmm4");
  register u8x16_t xmm5 asm ("xmm5");
  register u8x16_t xmm6 asm ("xmm6");
  register u8x16_t xmm7 asm ("xmm7");

  //15 operands is OK
  asm volatile ("" : "+r" (rdi),   "+r" (rsi),   "+r" (r10),   "+r" (r11),  
"+r" (rbx),   "+r" (rbp),
 "+r" (r12),   "+r" (r14),   "+r" (r15),   "+r" (r13),   "+x"
(xmm2),  "+x" (xmm3),
 "+x" (xmm4),  "+x" (xmm5),  "+x" (xmm6));

  //16 operands
  asm volatile ("" : "+r" (rdi),   "+r" (rsi),   "+r" (r10),   "+r" (r11),  
"+r" (rbx),   "+r" (rbp),
 "+r" (r12),   "+r" (r14),   "+r" (r15),   "+r" (r13),   "+x"
(xmm2),  "+x" (xmm3),
 "+x" (xmm4),  "+x" (xmm5),  "+x" (xmm6),  "+x" (xmm7));

  register u8x16_t xmm8 asm ("xmm8");
  register u8x16_t xmm9 asm ("xmm9");
  register u8x16_t xmm10 asm ("xmm10");
  register u8x16_t xmm11 asm ("xmm11");
  register u8x16_t xmm12 asm ("xmm12");
  register u8x16_t xmm13 asm ("xmm13");
  register u8x16_t xmm14 asm ("xmm14");
  register u8x16_t xmm15 asm ("xmm15");

  //24 operands
  asm volatile ("" : "+r" (rdi),   "+r" (rsi),   "+r" (r10),   "+r" (r11),  
"+r" (rbx),   "+r" (rbp),
 "+r" (r12),   "+r" (r14),   "+r" (r15),   "+r" (r13),   "+x"
(xmm2),  "+x" (xmm3),
 "+x" (xmm4),  "+x" (xmm5),  "+x" (xmm6),  "+x" (xmm7),  "+x"
(xmm8),  "+x" (xmm9),
 "+x" (xmm10), "+x" (xmm11), "+x" (xmm12), "+x" (xmm13), "+x"
(xmm14), "+x" (xmm15));

  register u8x16_t xmm0 asm ("xmm0");
  register u8x16_t xmm1 asm ("xmm1");
  register uint64_t rax asm ("rax");
  register uint64_t rcx asm ("rcx");
  register uint64_t rdx asm ("rdx");
  register uint64_t r8 asm ("r8");
  register uint64_t r9 asm ("r9");

  //31 operands
  asm volatile ("" : "+r" (rdi),   "+r" (rsi),   "+r" (r10),   "+r" (r11),  
"+r" (rbx),   "+r" (rbp),
 "+r" (r12),   "+r" (r14),   "+r" (r15),   "+r" (r13),   "+x"
(xmm2),  "+x" (xmm3),
 "+x" (xmm4),  "+x" (xmm5),  "+x" (xmm6),  "+x" (xmm7),  "+x"
(xmm8),  "+x" (xmm9),
 "+x" (xmm10), "+x" (xmm11), "+x" (xmm12), "+x" (xmm13), "+x"
(xmm14), "+x" (xmm15),
 "+x" (xmm0),  "+x" (xmm1),  "+r" (rax),   "+r" (rcx),   "+r"
(rdx),   "+r" (r8),
 "+r" (r9));

  register uint64_t mmx0 asm ("mm0");
  register uint64_t mmx1 asm ("mm1");
  register uint64_t mmx2 asm ("mm2");
  register uint64_t mmx3 asm ("mm3");
  register uint64_t mmx4 asm ("mm4");
  register uint64_t mmx5 asm ("mm5");
  register uint64_t mmx6 asm ("mm6");
  register uint64_t mmx7 asm ("mm7");

  //39 operands
  asm volatile ("" : "+r" (rdi),   "+r" (rsi),   "+r" (r10),   "+r" (r11),  
"+r" (rbx),   "+r" (rbp),
 "+r" (r12),   "+r" (r14),   "+r" (r15),   "+r" (r13),   "+x"
(xmm2),  "+x" (xmm3),
 "+x" (xmm4),  "+x" (xmm5),  "+x" (xmm6),  "+x" (xmm7),  "+x"
(xmm8),  "+x" (xmm9),
 "+x" (xmm10), "+x" (xmm11), "+x" (xmm12), "+x" (xmm13), "+x"
(xmm14), "+x" (xmm15),
 "+x" (xmm0),  "+x" (xmm1),  "+r" (rax),   "+r" (rcx),   "+r"
(rdx),   "+r" (r8),
 "+r" (r9),"+y" (mmx0),  "+y" (mmx1),  "+y" (mmx2),  "+y"
(mmx3),  "+y" (mmx4),
 "+y" (mmx5),  "+y" (mmx6),  "+y" (mmx7));

  return 0;
}

$ gcc-snapshot.sh -O3 30_operands.c
30_operands.c: In function 'main':
30_operands.c:29:3: error: more than 30 operands in 'asm'
   asm volatile ("" : "+r" (rdi),   "+r" (rsi),   "+r" (r10),   "+r" (r11),  
"+r" (rbx),   "+r" (rbp),
   ^
30_operands.c:43:3: error: more than 30 operands in 'asm'
   asm volatile ("" : "+r" (rdi),   "+r" (rsi),   "+r" (r10),   "+r" (r11),  
"+r" (rbx),   "+r" (rbp),
   ^
30_operands.c:57:3: error: more than 30 operands in 'asm'
   asm volatile ("" : "+r" (rdi),   "+r" (rsi),   "+r" (r

[Bug c++/65159] Linker forgets definition of type_info::__is_pointer_p

[potswa at mac dot com]

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

--- Comment #10 from David Krauss  ---
I made a clean build of r220825, and it succeeded. Then I downgraded to
r22, and it produced similar link errors, although not in type_info.

[Bug c++/65390] ICE in strip_typedefs, at cp/tree.c:1361

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 CC||ktietz at gcc dot gnu.org

--- Comment #4 from Kai Tietz  ---
This sample is undefined behavior.  It will use delete on the allocated memory,
and not delete [] as it would need.
Additionally the type 'int [n]' is no valid type for template argument.

[Bug c++/65390] ICE in strip_typedefs, at cp/tree.c:1361

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Reduced:

template struct shared_ptr { };

template
shared_ptr make_shared(Arg) { return {}; }

auto f(int n){
  return make_shared(1);
}

[Bug c++/65390] ICE in strip_typedefs, at cp/tree.c:1361

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Further reduced so it doesn't rely on any C++11 or C++14 features:

template struct shared_ptr { };

template
shared_ptr make_shared(Arg) { return shared_ptr(); }

void f(int n){
  make_shared(1);
}

[Bug libgomp/65437] New: acc_update_device and acc_update_self fail to initialize runtime.

[u17263 at att dot net]

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

Bug ID: 65437
   Summary: acc_update_device and acc_update_self fail to
initialize runtime.
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: u17263 at att dot net
CC: jakub at gcc dot gnu.org

Both acc_update_device and acc_update_self fail to initialize the runtime
through the common function update_dev_host (oacc-mem.c).

[Bug inline-asm/65436] Max number of extended asm +input operands currently limited to 15

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Bumping this is very expensive, there are lots of data structures with
MAX_RECOG_OPERANDS sized arrays and some even MAX_RECOG_OPERANDS x
MAX_RECOG_OPERANDS arrays.

[Bug target/65358] wrong parameter passing code with tail call optimization on arm

[ktkachov at gcc dot gnu.org]

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

--- Comment #11 from ktkachov at gcc dot gnu.org ---
Thinking about it again, there's no reason not to do sibcalls, it's just the
code gets confused on how to shuffle the arguments around. Will investigate
deeper

[Bug middle-end/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
While I couldn't reproduce this on aarch64-linux, on arm-linux-gnueabihf
without the revert all my bootstraps since Friday ended up with ICEs, both
profiledbootstrap and normal bootstraps; for --with-default-libstdcxx-abi=c++98
builds somewhere in gnat-tools build (but with corrupted backtraces, didn't
figure out anything useful yet how to debug) and for the default new C++ ABI
builds somewhere during PCH creation in libstdc++.
With the problematic patch reverted normal bootstrap build is now already in
make check phase past the bootstrap failure point, and two differently
configured profiledbootstraps are progressing nicely so far.  But really don't
have a short reproducer for either, sorry.

[Bug fortran/65438] New: Unnecessary ptr check

[u17263 at att dot net]

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

Bug ID: 65438
   Summary: Unnecessary ptr check
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: u17263 at att dot net

The function check_array_not_assumed (openmp.c) performs an unnecessary check
on pointers.

[Bug ipa/65439] New: [5.0 Regression] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++98 scan-ipa-dump icf "Equal symbols: 6"

[danglin at gcc dot gnu.org]

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

Bug ID: 65439
   Summary: [5.0 Regression] FAIL: g++.dg/ipa/ipa-icf-4.C
-std=gnu++98  scan-ipa-dump icf "Equal symbols: 6"
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

In revision 221432:

Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu
/gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/ipa/
ipa-icf-4.C  -fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hp
ux11.11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/tes
t/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/ba
ckward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=
gnu++98 -O2 -fdump-ipa-icf -fno-inline  -S   -o ipa-icf-4.s(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/g
cc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.dg/ipa/ipa-icf-4.C
-
fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/test/gnu/gcc
/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test
/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/l
ibstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/
gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O2
-fdu
mp-ipa-icf -fno-inline -S -o ipa-icf-4.s
PASS: g++.dg/ipa/ipa-icf-4.C  -std=gnu++98 (test for excess errors)
PASS: g++.dg/ipa/ipa-icf-4.C  -std=gnu++98  scan-ipa-dump icf "(Unified;
Variabl
e alias has been created)|(Symbol aliases are not supported by target)"
FAIL: g++.dg/ipa/ipa-icf-4.C  -std=gnu++98  scan-ipa-dump icf "Equal symbols:
6"

Revision 221202 was okay.

[Bug tree-optimization/65440] New: pass_lim misses support for predicated code motion

[vries at gcc dot gnu.org]

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

Bug ID: 65440
   Summary: pass_lim misses support for predicated code motion
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org

tree-ssa-loop-im.c (
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/tree-ssa-loop-im.c;h=9aba79ba776944ec6fba8459354deabe8c126b75;hb=HEAD#l74
):
...
/* TODO:  Support for predicated code motion.  I.e.

   while (1)
 {
   if (cond)
 {
   a = inv;
   something;
 }
 }

   Where COND and INV are invariants, but evaluating INV may trap or be
   invalid from some other reason if !COND.  This may be transformed to

   if (cond)
 a = inv;
   while (1)
 {
   if (cond)
 something;
 }  */
...

[Bug libffi/65441] New: FAIL: libffi.call/float2.c -W -Wall -Wno-psabi (test for excess errors)

[danglin at gcc dot gnu.org]

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

Bug ID: 65441
   Summary: FAIL: libffi.call/float2.c -W -Wall -Wno-psabi (test
for excess errors)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libffi
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Host: hppa*-*-hpux*
Target: hppa*-*-hpux*
 Build: hppa*-*-hpux*

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c  -W -Wall -Wno-psabi -O0 
-
I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libffi/include
-I/test/gnu/gcc/gcc
/libffi/testsuite/../include 
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./lib
ffi/include/.. -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libffi/.libs
-L/te
st/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs  -lffi -lm  
-o
 ./float2.exe(timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/libffi/testsuite/libffi.call/float2.c -W -Wall -Wno-psabi -O0
-I/test/gnu/gcc/
objdir/hppa2.0w-hp-hpux11.11/./libffi/include
-I/test/gnu/gcc/gcc/libffi/testsui
te/../include -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libffi/include/..
-
L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libffi/.libs
-L/test/gnu/gcc/objdi
r/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs -lffi -lm -o ./float2.exe
ESC[01mESC[K/test/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c:ESC[mESC[K
I
n function 'ESC[01mESC[KmainESC[mESC[K':
ESC[01mESC[K/test/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c:52:7:ESC[m
ESC[K ESC[01;35mESC[Kwarning: ESC[mESC[Kimplicit declaration of function
'ESC[01
mESC[KfabslESC[mESC[K' [-Wimplicit-function-declaration]
   if (fabsl(ld - ldblit(f)) < LDBL_EPSILON)
ESC[01;32mESC[K   ^ESC[mESC[K
ESC[01mESC[K/test/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c:52:7:ESC[m
ESC[K ESC[01;35mESC[Kwarning: ESC[mESC[Kincompatible implicit declaration of
bui
lt-in function 'ESC[01mESC[KfabslESC[mESC[K'
ESC[01mESC[K/test/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c:52:7:ESC[m
ESC[K ESC[01;36mESC[Knote: ESC[mESC[Kinclude 'ESC[01mESC[KESC[mESC[K'
or provide a declaration of 'ESC[01mESC[KfabslESC[mESC[K'
output is:
ESC[01mESC[K/test/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c:ESC[mESC[K
In function 'ESC[01mESC[KmainESC[mESC[K':
ESC[01mESC[K/test/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c:52:7:ESC[m
ESC[K ESC[01;35mESC[Kwarning: ESC[mESC[Kimplicit declaration of function
'ESC[01mESC[KfabslESC[mESC[K' [-Wimplicit-function-declaration]
   if (fabsl(ld - ldblit(f)) < LDBL_EPSILON)
ESC[01;32mESC[K   ^ESC[mESC[K
ESC[01mESC[K/test/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c:52:7:ESC[m
ESC[K ESC[01;35mESC[Kwarning: ESC[mESC[Kincompatible implicit declaration of
built-in function 'ESC[01mESC[KfabslESC[mESC[K'
ESC[01mESC[K/test/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c:52:7:ESC[m
ESC[K ESC[01;36mESC[Knote: ESC[mESC[Kinclude 'ESC[01mESC[KESC[mESC[K'
or provide a declaration of 'ESC[01mESC[KfabslESC[mESC[K'

FAIL: libffi.call/float2.c -W -Wall -Wno-psabi -O0 (test for excess errors)
ESC[01mESC[K/test/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c:ESC[mESC[K
In function 'ESC[01mESC[KmainESC[mESC[K':
ESC[01mESC[K/test/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c:52:7:ESC[m
ESC[K ESC[01;35mESC[Kwarning: ESC[mESC[Kimplicit declaration of function
'ESC[01mESC[KfabslESC[mESC[K' [-Wimplicit-function-declaration]
   if (fabsl(ld - ldblit(f)) < LDBL_EPSILON)
ESC[01;32mESC[K   ^ESC[mESC[K
ESC[01mESC[K/test/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c:52:7:ESC[m
ESC[K ESC[01;35mESC[Kwarning: ESC[mESC[Kincompatible implicit declaration of
built-in function 'ESC[01mESC[KfabslESC[mESC[K'
ESC[01mESC[K/test/gnu/gcc/gcc/libffi/testsuite/libffi.call/float2.c:52:7:ESC[m
ESC[K ESC[01;36mESC[Knote: ESC[mESC[Kinclude 'ESC[01mESC[KESC[mESC[K'
or provide a declaration of 'ESC[01mESC[KfabslESC[mESC[K'

System libm doesn't provide C99 long double math routines.

[Bug c++/65071] ICE on valid, sizeof...() of template template parameter pack in return type

[maltsevm at gmail dot com]

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

--- Comment #3 from Mikhail Maltsev  ---
For the record: a patch for this PR
https://gcc.gnu.org/ml/gcc-patches/2015-02/msg01067.html

[Bug tree-optimization/65440] pass_lim misses support for predicated code motion

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Concrete example ( based on example at
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/tree-ssa-loop-im.c;h=9aba79ba776944ec6fba8459354deabe8c126b75;hb=HEAD#l333)

test.c:
...
#include 

const char *something (void);

size_t
f (unsigned int n)
{
  const char *s = something ();
  size_t sum = 0;
  size_t t;
  unsigned int i;

  for (i = 0; i < n; ++i)
{
  if (s)
t = strlen (s);
  else
t = i * 2;
  sum += t;
}
  return sum;
}
...


The resulting code with -O2 from the optimized dump is: 
...
f (unsigned int n)
{
  unsigned int i;
  size_t t;
  size_t sum;
  const char * s;
  unsigned int _9;

  :
  s_6 = something ();
  if (n_7(D) != 0)
goto ;
  else
goto ;

  :
  # sum_13 = PHI <0(2)>
  # i_1 = PHI <0(2)>

  :
  # sum_14 = PHI 
  # i_17 = PHI 
  if (s_6 != 0B)
goto ;
  else
goto ;

  :
  t_8 = strlen (s_6);
  goto ;

  :
  _9 = i_17 * 2;
  t_10 = (size_t) _9;

  :
  # t_2 = PHI 
  sum_11 = t_2 + sum_14;
  i_12 = i_17 + 1;
  if (n_7(D) != i_12)
goto ;
  else
goto ;

  :
  # sum_16 = PHI 
  return sum_16;

}
...

[ The same code is generated with -O3 -fno-tree-vectorize -fno-unswitch-loops.
-funswitch-loops manages to take the strlen out of the loop, but by generating
two loops. ]

[Bug sanitizer/65435] UBsan runtime error reports in OpenSSL aes_core.c

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger  ---
FYI, I've now opened an issue in the OpenSSL bug tracker:

http://rt.openssl.org/Ticket/Display.html?id=3751

[Bug tree-optimization/65442] New: pass_lim misses support for exit-first loops

[vries at gcc dot gnu.org]

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

Bug ID: 65442
   Summary: pass_lim misses support for exit-first loops
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org

Consider test.c:
...
#include 

const char *something (void);

size_t
f (unsigned int n)
{
  const char *s = something ();
  size_t sum = 0;
  size_t t;
  unsigned int i;

  if (!s)
return 0;

  for (i = 0; i < n; ++i)
{
  t = strlen (s);
  sum += t;
}

  return sum;
}
...

The resulting code with -O2 -fno-tree-ch from the optimized dump is: 
...
f (unsigned int n)
{
  unsigned int i;
  size_t t;
  size_t sum;
  const char * s;
  size_t _3;

  :
  s_6 = something ();
  if (s_6 == 0B)
goto ;
  else
goto ;

  :
  # sum_14 = PHI <0(2)>
  # i_12 = PHI <0(2)>
  goto ;

  :
  t_9 = strlen (s_6);
  sum_10 = sum_1 + t_9;
  i_11 = i_2 + 1;

  :
  # sum_1 = PHI 
  # i_2 = PHI 
  if (i_2 != n_8(D))
goto ;
  else
goto ;

  :
  # _3 = PHI <0(2), sum_1(5)>
  return _3;

}
...

The strlen is not taken out of the loop. It could be taken out of the loop,
provided it's guarded with the loop condition.

This PR is similar to PR65440. There the strlen is conditional in the loop
body, which is entered unconditionally. Here the strlen is unconditional in the
loop body, which is entered conditionally.

[Bug tree-optimization/65440] pass_lim misses support for predicated code motion

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #2 from vries at gcc dot gnu.org ---
See also related PR65442 - pass_lim misses support for exit-first loops

[Bug c++/59991] Recursive lambda capture in C++1y constexpr function template causes internal compiler error

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-16
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.8.5
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Confirmed with 4.9/4.8.  This has been fixed on trunk with r210829.

[Bug ipa/65439] [5.0 Regression] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++98 scan-ipa-dump icf "Equal symbols: 6"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.0

[Bug c++/65159] Linker forgets definition of type_info::__is_pointer_p

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to David Krauss from comment #10)
> I made a clean build of r220825, and it succeeded. Then I downgraded to
> r22, and it produced similar link errors, although not in type_info.

This is rather vague, did you do a clean build of r22?

If not, there's nothing we need to fix here, it's user error.

[Bug c++/59761] ICE: g++ segfaults in test case involving constexpr default constructor with uninitialized member and template type alias

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-16
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |4.8.5
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
4.8 ICEs, 4.9/trunk work fine.

[Bug libstdc++/65434] Memory leak in pool constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Dmitry Shachnev from comment #0)
> 18,944 bytes in 1 blocks are still reachable in loss record 1 of 1

"still reachable" is not a leak, the memory is still in use by the runtime.

This is intentional.

[Bug c/65430] false negative of -Wsequence-point

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
(a = 3, 8) * (a = 0); 
is folded into
a = 3;, (a = 0) * 8;
and that is what verify_sequence_points gets -- so it doesn't think there's
anything wrong here.

[Bug c/65430] Missing -Wsequence-point warning with COMPOUND_EXPRs

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |6.0
Summary|false negative of   |Missing -Wsequence-point
   |-Wsequence-point|warning with COMPOUND_EXPRs

--- Comment #2 from Marek Polacek  ---
Updating summary.

[Bug c/51562] missing -Wsequence-point warning for expression with commas.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
PR65430 has a better testcase + explanation why that happens, so closing this
one as a dup.

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

[Bug c/65430] Missing -Wsequence-point warning with COMPOUND_EXPRs

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||willus0 at hotmail dot com

--- Comment #3 from Marek Polacek  ---
*** Bug 51562 has been marked as a duplicate of this bug. ***

[Bug libstdc++/65434] Memory leak in pool constructor

[mitya57 at gmail dot com]

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

--- Comment #2 from Dmitry Shachnev  ---
Will anything bad happen if that memory is freed in the destructor?

For me, the issue is mostly aesthetic — I got used to not seeing any Valgrind
warnings in my programs :)

[Bug c/37303] const compound initializers in structs are written to .data instead of .rodata

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
This one should be fixed.

[Bug c/59491] compiler can't detect if xpression is always fixed value

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

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

[Bug c/65423] No warning on always-true/false predicates containing bitwise operations

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

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

[Bug c/17534] gcc fails to diagnose suspect expressions that have incompatible bit masks

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||chengniansun at gmail dot com

--- Comment #8 from Marek Polacek  ---
*** Bug 65423 has been marked as a duplicate of this bug. ***

[Bug c/17534] gcc fails to diagnose suspect expressions that have incompatible bit masks

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #7 from Marek Polacek  ---
*** Bug 59491 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/65443] New: Don't peel last iteration from loop in transform_to_exit_first_loop

[vries at gcc dot gnu.org]

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

Bug ID: 65443
   Summary: Don't peel last iteration from loop in
transform_to_exit_first_loop
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org

tree-parloops.c (
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/tree-parloops.c;h=fbb9eebddcf23e0c3498668e7aaa4708d302f255;hb=HEAD#l1503
):
...
   TODO: the common case is that latch of the loop is empty and immediately
   follows the loop exit.  In this case, it would be better not to copy the
   body of the loop, but only move the entry of the loop directly before the
   exit check and increase the number of iterations of the loop by one.
   This may need some additional preconditioning in case NIT = ~0.
   REDUCTION_LIST describes the reductions in LOOP.  */

static void
transform_to_exit_first_loop (struct loop *loop,
  reduction_info_table_type *reduction_list,
  tree nit)
...

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/65434] Memory leak in pool constructor

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Dmitry Shachnev from comment #2)
> Will anything bad happen if that memory is freed in the destructor?

Yes, because other destructors could run later, and could (potentially) need to
use the pool after it had been destroyed. That would be undefined behaviour.

> For me, the issue is mostly aesthetic — I got used to not seeing any
> Valgrind warnings in my programs :)

Then add a valgrind suppression, or ask upstream valgrind to add it.

[Bug middle-end/65431] [5 Regression] Invalid read of size 8 at 0x105DBBF8: delete_omp_context(unsigned long) (omp-low.c:1586)

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 16 16:10:17 2015
New Revision: 221459

URL: https://gcc.gnu.org/viewcvs?rev=221459&root=gcc&view=rev
Log:
PR middle-end/65431
* omp-low.c (delete_omp_context): Only splay_tree_delete
reduction_map in GIMPLE_OMP_TARGET is_gimple_omp_offloaded
is_gimple_omp_oacc contexts.  Don't look at ctx->outer.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c

[Bug c++/59324] C++11: -Wsequence-point

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
Clang also thinks this is UB:

warning: multiple unsequenced modifications to 'b' [-Wunsequenced]

[Bug c/53064] -Wsequence-point behaves inconsistently

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-16
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1
   Severity|trivial |normal

--- Comment #4 from Manuel López-Ibáñez  ---
This is a bug caused by early folding of (x ? 0 : 0). Similar to PR65430. The
actual code produced by GCC is:

 int a = 0;
 ++a;, NON_LVALUE_EXPR ;;

and you actually get a warning for the unused value, which is even more
confusing:

test.c:5:5: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
   a + (++a ? 0 : 0);
 ^

If one prevents the folding, the warning is given:

test.c:5:8: warning: operation on ‘a’ may be undefined [-Wsequence-point]
   a + (++a ? 0 : 1);
^

[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Consider test.c, compiled with -O2 -tree-parallelize-loops=2:
...
#include 

extern unsigned int *a;

void
f (unsigned int n)
{
  int i;
  unsigned int sum = 1;

#pragma omp parallel
  {
#pragma omp for
for (i = 0; i < n; ++i)
  sum += a[i];
  }

  printf ("%u\n", sum);
}
...

Before tranform_to_exit_first_loop, the loop looks like this:
...
  :
  # sum_18 = PHI <1(11), sum_11(6)>
  # ivtmp_25 = PHI <0(11), ivtmp_6(6)>
  i_17 = (int) ivtmp_25;
  _7 = (long unsigned int) i_17;
  _8 = _7 * 4;
  _9 = pretmp_24 + _8;
  _10 = *_9;
  sum_11 = _10 + sum_18;
  i_12 = i_17 + 1;
  i.1_3 = (unsigned int) i_12;
  if (ivtmp_25 < _20)
goto ;
  else
goto ;

  :
  # sum_21 = PHI 
  goto ;

  :
  ivtmp_6 = ivtmp_25 + 1;
  goto ;
...

You might say that the transformation applied by tranform_to_exit_first_loop is
that all the statements in bb4 before the if are moved past the if, into both
bb5 and bb6.

After, it looks like:
...
  :
  # sum_28 = PHI <1(11), sum_11(6)>
  # ivtmp_29 = PHI <0(11), ivtmp_6(6)>
  if (ivtmp_29 < _20)
goto ;
  else
goto ;

  :
  # sum_18 = PHI 
  # ivtmp_25 = PHI 
  i_17 = (int) ivtmp_25;
  _7 = (long unsigned int) i_17;
  _8 = _7 * 4;
  _9 = pretmp_24 + _8;
  _10 = *_9;
  sum_11 = _10 + sum_18;
  i_12 = i_17 + 1;
  i.1_3 = (unsigned int) i_12;
  goto ;

  :
  # sum_30 = PHI 
  ivtmp_31 = _20;
  i_32 = (int) ivtmp_31;
  _33 = (long unsigned int) i_32;
  _34 = _33 * 4;
  _35 = pretmp_24 + _34;
  _36 = *_35;
  sum_37 = _36 + sum_30;
  i_38 = i_32 + 1;
  i.1_39 = (unsigned int) i_38;

  :
  # sum_21 = PHI 
  goto ;

  :
  ivtmp_6 = ivtmp_25 + 1;
  goto ;
...

[Bug sanitizer/65400] tsan mis-compiles inlineable C functions

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Both patches look wrong to me.
For the first change, it is wrong to add TSAN_FUNC_EXIT (), you should never
add it out of nothing.  First of all, you might consider allowing
TSAN_FUNC_EXIT () in find_return_bb - there is no reason why any harm would be
done if it is considered a part of a return bb.  On your first testcase that is
not the case though, so instead you need to either duplicate or move it.  I'd
say best would be to bail out early with fnsplitting if TSAN_FUNC_EXIT is
present in a bb that is not return_bb itself or one of its predecessors; or
when it is present in one of the predecessors of return_bb and not in all the
other predecessors.  The case when TSAN_FUNC_EXIT is in the return_bb (after
you change find_return_bb) should work fine without any extra work, and for the
case when it is in the predecessors of return_bb, add it.

The second change doesn't make any sense at all, but from the testcase it isn't
obvious what you are trying to do at all.  If the problem is that fnsplit has
set tail call flag and you've added the TSAN_FUNC_EXIT after it, then that
should be where you clear the flag; if it is something different, please
explain what you are trying to do and why.

[Bug ipa/65439] [5.0 Regression] FAIL: g++.dg/ipa/ipa-icf-4.C -std=gnu++98 scan-ipa-dump icf "Equal symbols: 6"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,
   ||x86_64-apple-darwin1*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-03-16
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Host|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,
   ||x86_64-apple-darwin1*
 Ever confirmed|0   |1
  Build|hppa2.0w-hp-hpux11.11   |hppa2.0w-hp-hpux11.11,
   ||x86_64-apple-darwin1*

--- Comment #1 from Dominique d'Humieres  ---
Also seen on darwin
(https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg01785.html) at r221412
(likely r221406): the test fails due to

Equal symbols: 7

[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
AFAIU, this is meant with the todo:
...
  :
  goto ;

  :
  i_17 = (int) ivtmp_6;
  _7 = (long unsigned int) i_17;
  _8 = _7 * 4;
  _9 = pretmp_24 + _8;
  _10 = *_9;
  sum_11 = _10 + sum_y;
  i_12 = i_17 + 1;
  i.1_3 = (unsigned int) i_12;

  :
  # sum_y = PHI <1(x), sum_11(4)>
  # ivtmp_y = PHI <0(x), ivtmp_6(4)>
  if (ivtmp_y < _20 + 1)
goto ;
  else
goto ;

  :
  # sum_21 = PHI 
  goto ;

  :
  ivtmp_6 = ivtmp_y + 1;
  goto ;
...

So, sort of:
- Split bb 4 before the loop condition, creating bb y.
- Don't enter the loop at bb 4 as before, instead jump to before the loop
  condition, to bb y (creating bb x in the process) 
- For each phi in bb 4, add a corresponding phi to bb y: 
  - For the values for entry from bb x, use the values in the phis in bb 4 for
entry from bb 11.
  - For the values for entry from bb 4, use the reaching definitions.
- increase loop bound with 1 (_20 + 1)
- simplify the phis in bb 4
- use the new phis in bb y as defs for the reachable uses

The problem with this transformation is that '_20 + 1' might overflow, that's
what the comment 'This may need some additional preconditioning in case NIT =
~0' refers to.

[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to vries from comment #2)
> The problem with this transformation is that '_20 + 1' might overflow,
> that's what the comment 'This may need some additional preconditioning in
> case NIT = ~0' refers to.

AFAIU, we might also move 'ivtmp_6 = ivtmp_y + 1' to the end of bb4. That way
it's not triggered at loop entry, as before the transformation,  eliminating
the need for '_20 + 1'.

[Bug middle-end/65414] [5 Regression] ICE while building libgcc after stage 2, bootstrap failure on aarch64-linux-gnu

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #17 from H.J. Lu  ---
(In reply to vries from comment #15)
> If somebody happens to have a commandline and .i file with which the problem
> can be reproduced using a non-bootstrap compiler, please attach it here.
> 

I don't know if it is relevant. On Linux/x86-64, r221372 may have caused

FAIL: gcc.dg/guality/pr43051-1.c   -O2  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2  line 36 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O2  line 39 c == &a[0]
FAIL: gcc.dg/guality/pr43051-1.c   -O2  line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2  line 41 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 36 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 39 c == &a[0]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 41 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 36 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 39 c == &a[0]
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 41 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer  line 36 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer  line 39 c == &a[0]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer  line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer  line 41 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  line 36 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  line 39 c == &a[0]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  line 41 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops 
line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops 
line 36 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops 
line 39 c == &a[0]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops 
line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -fomit-frame-pointer -funroll-loops 
line 41 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -g  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -g  line 36 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -g  line 39 c == &a[0]
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -g  line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -O3 -g  line 41 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -Os  line 35 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -Os  line 36 e == &a[1]
FAIL: gcc.dg/guality/pr43051-1.c   -Os  line 39 c == &a[0]
FAIL: gcc.dg/guality/pr43051-1.c   -Os  line 40 v == 1
FAIL: gcc.dg/guality/pr43051-1.c   -Os  line 41 e == &a[1]
FAIL: gcc.dg/guality/pr43177.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 15 l == 10
FAIL: gcc.dg/guality/pr43177.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 15 x == 7
FAIL: gcc.dg/guality/pr43177.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 24 l == 10
FAIL: gcc.dg/guality/pr43177.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 24 x == 7
FAIL: gcc.dg/guality/pr54519-3.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 20 x == 36
FAIL: gcc.dg/guality/pr54519-3.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 23 x == 98
FAIL: gcc.dg/guality/pr54519-4.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 17 x == 6
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 21 a.j == 14
FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  line 43 a.i == 4
FAIL: gcc.dg/guality/sra-1.c 

[Bug driver/65444] New: -z bndplt isn't passed to linker for -mmpx when building dynamic objects

[hjl.tools at gmail dot com]

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

Bug ID: 65444
   Summary: -z bndplt isn't passed to linker for -mmpx when
building dynamic objects
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: enkovich.gnu at gmail dot com
  Reporter: hjl.tools at gmail dot com

[root@skylakeclient bug-1]# /home/gkammela/mpx/bin/gcc -mmpx
-fcheck-pointer-bounds -g -Wl,-R,/home/gkammela/mpx/lib64  -o x x.o -v
Using built-in specs.
COLLECT_GCC=/home/gkammela/mpx/bin/gcc
COLLECT_LTO_WRAPPER=/home/gkammela/mpx/bin/../libexec/gcc/x86_64-pc-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/sharedws/users/saguriev/gcc/T/gcc_mpx_master_20150310/configure
--enable-bootstrap=no --enable-languages=c,c++,fortran,objc,lto --enable-plugin
--enable-shared --build=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-gmp=/sharedws/users/saguriev/gcc/util
--with-mpc=/sharedws/users/saguriev/gcc/util
--with-mfpr=/sharedws/users/saguriev/gcc/util
--prefix=/sharedws/users/saguriev/gcc/T/gcc_install_mpx_master_20150310
--enable-multilib --enable-initfini-array --enable-cloog-backend=isl
--with-fpmath=sse
--with-as=/sharedws/users/saguriev/binutils/T/FC19/binutils-gdb_install_Apr22/bin/as
--with-ld=/sharedws/users/saguriev/binutils/T/FC19/binutils-gdb_install_Apr22/bin/ld
--enable-libmpx=yes LDFLAGS='-static -static-libgcc'
CC=/sharedws/users/saguriev/gcc/bin/gcc
CXX=/sharedws/users/saguriev/gcc/bin/g++
Thread model: posix
gcc version 5.0.0 20150302 (experimental) (GCC) 
COMPILER_PATH=/home/gkammela/mpx/bin/../libexec/gcc/x86_64-pc-linux-gnu/5.0.0/:/home/gkammela/mpx/bin/../libexec/gcc/
LIBRARY_PATH=/home/gkammela/mpx/bin/../lib/gcc/x86_64-pc-linux-gnu/5.0.0/:/home/gkammela/mpx/bin/../lib/gcc/:/home/gkammela/mpx/bin/../lib/gcc/x86_64-pc-linux-gnu/5.0.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/gkammela/mpx/bin/../lib/gcc/x86_64-pc-linux-gnu/5.0.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-mmpx' '-fcheck-pointer-bounds' '-g' '-o' 'x' '-v'
'-mtune=generic' '-march=x86-64'
 /home/gkammela/mpx/bin/../libexec/gcc/x86_64-pc-linux-gnu/5.0.0/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o x
/lib/../lib64/crt1.o /lib/../lib64/crti.o
/home/gkammela/mpx/bin/../lib/gcc/x86_64-pc-linux-gnu/5.0.0/crtbegin.o
-L/home/gkammela/mpx/bin/../lib/gcc/x86_64-pc-linux-gnu/5.0.0
-L/home/gkammela/mpx/bin/../lib/gcc
-L/home/gkammela/mpx/bin/../lib/gcc/x86_64-pc-linux-gnu/5.0.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/gkammela/mpx/bin/../lib/gcc/x86_64-pc-linux-gnu/5.0.0/../../.. -R
/home/gkammela/mpx/lib64 x.o -lmpx -lmpxwrappers -lgcc --as-needed -lgcc_s
--no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/home/gkammela/mpx/bin/../lib/gcc/x86_64-pc-linux-gnu/5.0.0/crtend.o
/lib/../lib64/crtn.o
[root@skylakeclient bug-1]#

[Bug c++/65327] GCC rejects "constexpr volatile int i = 5;"

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Mon Mar 16 18:30:49 2015
New Revision: 221463

URL: https://gcc.gnu.org/viewcvs?rev=221463&root=gcc&view=rev
Log:
DR 1688
PR c++/65327
* decl.c (grokdeclarator): Allow volatile and constexpr together.

* g++.dg/cpp0x/constexpr-object1.C: Change dg-error to dg-bogus.
* g++.dg/cpp0x/pr65327.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr65327.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-object1.C

[Bug c++/65327] GCC rejects "constexpr volatile int i = 5;"

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed for GCC 5.  Not going to backport it.

[Bug middle-end/65431] [5 Regression] Invalid read of size 8 at 0x105DBBF8: delete_omp_context(unsigned long) (omp-low.c:1586)

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/65427] [4.8/4.9 Regression] ICE in emit_move_insn with wide vector types

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||5.0
Summary|[4.8/4.9/5 Regression] ICE  |[4.8/4.9 Regression] ICE in
   |in emit_move_insn with wide |emit_move_insn with wide
   |vector types|vector types

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug tree-optimization/65427] [4.8/4.9/5 Regression] ICE in emit_move_insn with wide vector types

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 16 18:50:43 2015
New Revision: 221464

URL: https://gcc.gnu.org/viewcvs?rev=221464&root=gcc&view=rev
Log:
PR tree-optimization/65427
* tree-vect-generic.c (do_cond, expand_vector_scalar_condition): New
functions.
(expand_vector_operations_1): Handle BLKmode vector COND_EXPR.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr65427.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-generic.c

[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #34956|0   |1
is obsolete||

--- Comment #14 from Michael Meissner  ---
Created attachment 35040
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35040&action=edit
Latest patch

This patch completely eliminates the -ffast-math actions that keep non-0
floating point constants arround until reload time.