[Bug middle-end/79399] GCC fails to compile big source at -O0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
You would save a lot of pain and even could compile it at -O2 if the generator
generated many, but much smaller, functions, for such sizes it certainly pays
off.
What I see is after allocating ~ 24GB of memory ira-costs.c (init_costs) tries
to allocate 124 * 17380077 bytes, but both values are ints, so the
multiplication result is int too and is negative, while it should have
allocated just slightly over 2GB.  So the following patch should cure this,
though not sure if that is the only problem (and will see if I manage to
compile, have only 32GB in my box).

--- gcc/ira-costs.c.jj  2017-01-16 12:28:35.0 +0100
+++ gcc/ira-costs.c 2017-02-07 09:07:00.744696695 +0100
@@ -1704,7 +1704,7 @@ find_costs_and_classes (FILE *dump_file)
  process_bb_node_for_costs, NULL);

  memcpy (total_allocno_costs, costs,
- max_struct_costs_size * ira_allocnos_num);
+ (size_t) max_struct_costs_size * ira_allocnos_num);
}
   else
{
@@ -2205,7 +2205,7 @@ static void
 init_costs (void)
 {
   init_subregs_of_mode ();
-  costs = (struct costs *) ira_allocate (max_struct_costs_size
+  costs = (struct costs *) ira_allocate ((size_t) max_struct_costs_size
 * cost_elements_num);
   pref_buffer = (enum reg_class *) ira_allocate (sizeof (enum reg_class)
 * cost_elements_num);
@@ -2235,8 +2235,9 @@ ira_costs (void)
   allocno_p = true;
   cost_elements_num = ira_allocnos_num;
   init_costs ();
-  total_allocno_costs = (struct costs *) ira_allocate (max_struct_costs_size
-  * ira_allocnos_num);
+  total_allocno_costs
+= (struct costs *) ira_allocate ((size_t) max_struct_costs_size
+* ira_allocnos_num);
   initiate_regno_cost_classes ();
   calculate_elim_costs_all_insns ();
   find_costs_and_classes (ira_dump_file);

[Bug middle-end/79399] GCC fails to compile big source at -O0

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
32GB is not enough. gcc-6 is using ~42GB on gcc112 and is still running for
over an hour...
And it is probably a good idea to use a "--enable-checking=release" compiler
for this testcase.

[Bug middle-end/79399] GCC fails to compile big source at -O0

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Ok, then I guess I'll just bootstrap/regtest my patch, it is a way forward
without testing it further.

Actually:
2017-02-07  Jakub Jelinek  

PR middle-end/79399
* ira-int.h (struct target_ira_int): Change x_max_struct_costs_size
type from int to size_t.

--- gcc/ira-int.h.jj2017-01-01 12:45:39.0 +0100
+++ gcc/ira-int.h   2017-02-07 09:29:32.694102809 +0100
@@ -782,7 +782,7 @@ struct target_ira_int {

   /* Initialized once.  It is a maximal possible size of the allocated
  struct costs.  */
-  int x_max_struct_costs_size;
+  size_t x_max_struct_costs_size;

   /* Allocated and initialized once, and used to initialize cost values
  for each insn.  */

is better, this field is followed by a pointer, so it just uses a padding on
64-bit hosts for something useful and on 32-bit hosts won't make any changes.

[Bug middle-end/79399] GCC fails to compile big source at -O0

[babokin at gmail dot com]

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

--- Comment #4 from Dmitry Babokin  ---
The purpose of the generator is to break a compiler, that's why it's a single
function in this case, but not many. Though with smaller functions we break
compilers too.

This is the generator: https://github.com/01org/yarpgen

[Bug middle-end/79399] GCC fails to compile big source at -O0

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Ah, ok then.  Note that e.g. vectors use unsigned int for length, so as long as
you need more than 4G elements in any vector, the game is over, but probably
testcase of this size doesn't reach that even close.  Anyway, thanks for the
report.  Can you try yourself with the #c3 patch?

[Bug c++/79400] [7 Regression] Confusing 'noexcept' suggestion on throw (X)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
noexcept(false) ?

[Bug middle-end/79396] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #1 from Richard Biener  ---
works for me on x86_64-linux

[Bug c++/79400] [7 Regression] Confusing 'noexcept' suggestion on throw (X)

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Maybe it should suggests

  Foo(int) noexcept(false);

but that's the same as omitting the exception specification?

[Bug middle-end/79399] GCC fails to compile big source at -O0

[babokin at gmail dot com]

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

--- Comment #6 from Dmitry Babokin  ---
I've started the compilation, it should take more than an hour to finish. Will
report back when it's done.

[Bug rtl-optimization/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ktkachov at gcc dot gnu.org
   Assignee|segher at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #25 from ktkachov at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #19)
> Fixed for PowerPC.  arm and aarch64 should probably do a similar
> implementation of the new hook; leaving the bug open for that.

Thanks, I'm testing an implementation of the hook for arm and aarch64

[Bug target/79282] [7 Regresion] FAIL: gcc.target/arm/neon-for-64bits-1.c scan-assembler-times vshr 0

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
I suspect just removing the last two alternatives in the pattern is the way to
go.

They are just copies of the first two but enabled for mneon-for-64bits.
If I remove them the test passes for the normal options (doesn't use a NEON
shift) but for -mneon-for-64bits still uses the NEON instruction as intended.
For the -mneon-for-64bits case I think we should let the register allocator
make the decision on which alternatives to use rather than duplicating them and
enabling/disabling them using attributes for tuning purposes.

[Bug c++/79401] New: [7 Regression] Protected inheriting ctor

[jakub at gcc dot gnu.org]

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

Bug ID: 79401
   Summary: [7 Regression] Protected inheriting ctor
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

class B
{
protected:
  B (int, int);
};
class C : public B
{
protected:
  using B::B;
};
class A : public C
{
  A (char *);
};
A::A (char *) : C (0, 0)
{
}

is rejected starting with r241765 :
rh1419687.C: In constructor ‘A::A(char*)’:
rh1419687.C:15:24: error: ‘B::B(int, int)’ is protected within this context
 A::A (char *) : C (0, 0)
^
rh1419687.C:4:3: note: declared protected here
   B (int, int);
   ^
it is accepted with -fno-new-inheriting-ctors
clang++ 4.0.0 (trunk 291659) accepts it and claims to implement P0136R1.

[Bug c++/79401] [7 Regression] Protected inheriting ctor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||jason at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug testsuite/78421] [7 Regression] vect-strided-a-u8-i2-gap.c fails on armeb

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ktkachov at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #4 from ktkachov at gcc dot gnu.org ---
I still see the test failing on arm-none-eabi when testing with, for example:
-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard

Christophe also has a report:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01806.html

[Bug middle-end/79396] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Can't reproduce either.  Can you please attach preprocessed source, if it is
something related to your libc headers?

[Bug c++/60615] bad location in error from initializer

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
I think I did, but it was rejected.  We'll have to add some USE_CONSTANT /
USE_DECL wrapper expressions that carry location.  Not trivial.  Hopefully to
be fixed in GCC 8.

[Bug middle-end/79399] GCC fails to compile big source at -O0

[babokin at gmail dot com]

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

--- Comment #7 from Dmitry Babokin  ---
It crashed.
> /usr/bin/time --format="Max %M kb\nreal %E\nuser %U\nsys%S" g++ -std=c++11 -w 
> -O0 -march=nehalem -o gcc_no_opt_func.o -c func.cpp
func.cpp: In function ‘void foo()’:
func.cpp:26656:1: internal compiler error: Segmentation fault
 }
 ^
0xd62f9f crash_signal
../../gcc_svn/gcc/toplev.c:333
0xbb902e find_costs_and_classes
../../gcc_svn/gcc/ira-costs.c:1697
0xbba119 ira_costs()
../../gcc_svn/gcc/ira-costs.c:2242
0xbb3569 ira_build()
../../gcc_svn/gcc/ira-build.c:3420
0xba9d42 ira
../../gcc_svn/gcc/ira.c:5236
0xba9d42 execute
../../gcc_svn/gcc/ira.c:5541
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Max 30306372 kb
real 40:09.53
user 2349.01
sys53.94

[Bug middle-end/79399] GCC fails to compile big source at -O0

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
/* It is the current size of struct costs.  */
static int struct_costs_size;


so similar issue.

[Bug middle-end/79399] GCC fails to compile big source at -O0

[jakub at gcc dot gnu.org]

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

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

Indeed.

[Bug rtl-optimization/79388] [6/7 Regression] wrong code with -O -fno-tree-coalesce-vars

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Seems this goes wrong during combine.
Before it is able to figure out that (p & 0xfffe) is identical to (p & 0xfffe)
% 0x (correct), and so we get:
(note 4 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (reg/v:SI 91 [ p ])
(reg:SI 5 di [ p ])) "pr79388.c":8 82 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 5 di [ p ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(note 6 3 7 2 NOTE_INSN_DELETED)
(note 7 6 9 2 NOTE_INSN_DELETED)
(note 9 7 11 2 NOTE_INSN_DELETED)
(note 11 9 12 2 NOTE_INSN_DELETED)
(note 12 11 14 2 NOTE_INSN_DELETED)
(note 14 12 15 2 NOTE_INSN_DELETED)
(note 15 14 16 2 NOTE_INSN_DELETED)
(note 16 15 18 2 NOTE_INSN_DELETED)
(note 18 16 20 2 NOTE_INSN_DELETED)
(note 20 18 21 2 NOTE_INSN_DELETED)
(insn 21 20 22 2 (parallel [
(set (reg/v:SI 91 [ p ])
(and:SI (reg/v:SI 91 [ p ])
(const_int 65534 [0xfffe])))
(clobber (reg:CC 17 flags))
]) "pr79388.c":11 389 {*andsi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 22 21 23 2 (set (mem/c:SI (symbol_ref:DI ("c") [flags 0x2] ) [1 c+0 S4 A32])
(reg/v:SI 91 [ p ])) "pr79388.c":12 82 {*movsi_internal}
 (nil))
(insn 23 22 24 2 (set (reg:SI 103 [ a ])
(mem/c:SI (symbol_ref:DI ("a") [flags 0x2] )
[1 a+0 S4 A32])) "pr79388.c":13 82 {*movsi_internal}
 (nil))
(insn 24 23 29 2 (parallel [
(set (reg:SI 102)
(plus:SI (reg/v:SI 91 [ p ])
(reg:SI 103 [ a ])))
(clobber (reg:CC 17 flags))
]) "pr79388.c":13 215 {*addsi_1}
 (expr_list:REG_DEAD (reg:SI 103 [ a ])
(expr_list:REG_DEAD (reg/v:SI 91 [ p ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (plus:SI (reg/v:SI 91 [ p ])
(mem/c:SI (symbol_ref:DI ("a") [flags 0x2] ) [1 a+0 S4 A32]))
(nil))
(insn 29 24 30 2 (set (reg/i:SI 0 ax)
(reg:SI 102)) "pr79388.c":14 82 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 102)
(nil)))
(insn 30 29 0 2 (use (reg/i:SI 0 ax)) "pr79388.c":14 -1
 (nil))

But then try_combine is called with i3 24 and i2 23 and for some reason
turns that into a load from the mem alone (as if (reg:SI 91) is 0).

[Bug c++/79400] [7 Regression] Confusing 'noexcept' suggestion on throw (X)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #2)
> but that's the same as omitting the exception specification?

In this context, yes.

[Bug c++/79394] Possible rejects-valid problem

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
The testcase is invalid because foo isn't defined.

[Bug rtl-optimization/79388] [6/7 Regression] wrong code with -O -fno-tree-coalesce-vars

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
This happens because apparently nonzero_bits ((reg/v:SI 91 [ p ]), SImode)
returns 0.

[Bug rtl-optimization/79388] [6/7 Regression] wrong code with -O -fno-tree-coalesce-vars

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
(gdb) p debug_rtx (reg_stat.m_vec.m_vecdata[91].last_set)
(insn 21 20 22 2 (parallel [
(set (reg/v:SI 91 [ p ])
(and:SI (reg/v:SI 91 [ p ])
(const_int 65534 [0xfffe])))
(clobber (reg:CC 17 flags))
]) "pr79388.c":11 389 {*andsi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

looks correct, but

(gdb) p debug_rtx (reg_stat.m_vec.m_vecdata[91].last_set_value)
(and:SI (const_int 0 [0])
(const_int 65534 [0xfffe]))

looks wrong.

The problem is that during:
#1  0x01849ddc in record_value_for_reg (reg=0x7fffefc124b0,
insn=0x7fffefad2700, value=0x7fffefc12570) at ../../gcc/combine.c:12959
#2  0x0184a105 in record_dead_and_set_regs_1 (dest=0x7fffefc124b0,
setter=0x7fffefc12588, data=0x7fffefad2700)
at ../../gcc/combine.c:13059
#3  0x00e16e6f in note_stores (x=0x7fffefc12588, fun=0x184a052
, data=0x7fffefad2700)
at ../../gcc/rtlanal.c:1846
#4  0x00e16eba in note_stores (x=0x7fffefbefa10, fun=0x184a052
, data=0x7fffefad2700)
at ../../gcc/rtlanal.c:1851
#5  0x0184a48a in record_dead_and_set_regs (insn=0x7fffefad2700) at
../../gcc/combine.c:13140
on insn 21 we have dest (reg/v:SI 91 [ p ]) and value (and:SI (reg/v:SI 91 [ p
]) (const_int 65534 [0xfffe])), and get_last_value on the REG 91 is wrong:
(gdb) p debug_rtx (reg_stat.m_vec.m_vecdata[91].last_set_value)
(const_int 0 [0])
$122 = void
(gdb) p debug_rtx (reg_stat.m_vec.m_vecdata[91].last_set)
(note 16 15 18 2 NOTE_INSN_DELETED)

insn 16 is former:
(insn 16 15 18 2 (parallel [
(set (reg/v:SI 91 [ p ])
(lshiftrt:SI (subreg:SI (reg:DI 98) 0)
(const_int 15 [0xf])))
(clobber (reg:CC 17 flags))
]) "pr79388.c":11 542 {*lshrsi3_1}
 (expr_list:REG_DEAD (reg:DI 98)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (udiv:SI (reg:SI 89 [ _7 ])
(const_int 65535 [0x]))
(nil)

so it seems something forgot to invalidate the last value or something similar.
REG_N_SETS (91) is 3.
Segher, any ideas?

[Bug fortran/79402] New: ICE with submodules: module procedure interface defined in parent module

[stefano.zaghi at cnr dot it]

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

Bug ID: 79402
   Summary: ICE with submodules: module procedure interface
defined in parent module
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefano.zaghi at cnr dot it
  Target Milestone: ---

Created attachment 40685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40685&action=edit
MCVE of ICE with submodule

Dear gfortran team,

I am writing on the behalf of Chris Coutinho who cannot create a bugzilla
account.

GNU gfortran generates and ICE when a submodule implementation of a procedure
inherits its signature from the parent module by means of the "module
procedure" syntax.

In the "gfortran_ice_submodule.f90" file attached there is a minimal example
raising the ICE (Arch Linux, 4.8.13-1-ARCH #1 SMP PREEMPT) with both 6.3.1 and
development trunk 7.0.0 (I have not yet installed 7.0.1 version). If you
comment lines 24-26 and un-comment lines 17-22 the program runs as expected.

Our best regards.

Stefano

[Bug target/79404] New: h8300: ICE at gcc/ira.c:5541 whilst building libgcc

[dhowells at redhat dot com]

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

Bug ID: 79404
   Summary: h8300: ICE at gcc/ira.c:5541 whilst building libgcc
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhowells at redhat dot com
  Target Milestone: ---

Created attachment 40686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40686&action=edit
Test code

When building a cross compiler for h8300, an ICE occurs whilst it is building
libgcc:

/data/fedora/cross-gcc/ice.i: In function ‘__lshrdi3’:
/data/fedora/cross-gcc/ice.i:80:1: internal compiler error: Segmentation fault
 }
 ^
0x92805f crash_signal
../../gcc-7.0.1-20170204/gcc/toplev.c:333
0x7e13fb allocno_copy_cost_saving
../../gcc-7.0.1-20170204/gcc/ira-color.c:2764
0x7e9f83 improve_allocation
../../gcc-7.0.1-20170204/gcc/ira-color.c:2837
0x7e9f83 color_allocnos
../../gcc-7.0.1-20170204/gcc/ira-color.c:3141
0x7eb5b7 color_pass
../../gcc-7.0.1-20170204/gcc/ira-color.c:3250
0x7d7465 ira_traverse_loop_tree(bool, ira_loop_tree_node*, void
(*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
../../gcc-7.0.1-20170204/gcc/ira-build.c:1781
0x7e6c67 do_coloring
../../gcc-7.0.1-20170204/gcc/ira-color.c:3401
0x7e6c67 color
../../gcc-7.0.1-20170204/gcc/ira-color.c:4771
0x7e6c67 ira_color()
../../gcc-7.0.1-20170204/gcc/ira-color.c:4886
0x7d0ce3 ira
../../gcc-7.0.1-20170204/gcc/ira.c:5249
0x7d0ce3 execute
../../gcc-7.0.1-20170204/gcc/ira.c:5541


gcc is configured as:

// Target: h8300-elf
// Configured with: ../gcc-7.0.1-20170204/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmpx --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/h8300-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls
--enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=h8300-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=h8300-elf --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-gcc-major-version-only --with-isl --with-newlib
--with-plugin-ld=/usr/bin/h8300-linux-gnu-ld
--with-sysroot=/usr/h8300-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers --with-linker-hash-style=gnu
// Thread model: single
// gcc version 7.0.1 20170204 (Red Hat Cross 7.0.1-1) (GCC)

using binutils-2.27 cross-built for target h8300-elf.

The command to build the test source is:

/data/fedora/cross-gcc/gcc-7.0.1-20170204/h8300-linux-gnu/gcc/xgcc \
-B/data/fedora/cross-gcc/gcc-7.0.1-20170204/h8300-linux-gnu/gcc/ \
-B/usr/h8300-elf/bin/ \
-B/usr/h8300-elf/lib/ \
-O2 \
-c /data/fedora/cross-gcc/ice.i \
-o _lshrdi3.o

[Bug ada/79403] New: Installation of Ada compiler gets permissions wrong

[vogt at linux dot vnet.ibm.com]

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

Bug ID: 79403
   Summary: Installation of Ada compiler gets permissions wrong
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vogt at linux dot vnet.ibm.com
  Target Milestone: ---
  Host: s390x
Target: s390x

"make install" of the Ada compiler installs the contests of the adainclude and
adalib directories with incorrect permissions. The installed compiler is only
usable by the user who installed it:

  $ su - root
  $ cd gcc/build
  # configure and build the compiler using e.g. --prefix=/usr/local
  $ umask 022
  $ make install
  $ cd /usr/local/lib/gcc/s390x-ibm-linux-gnu/6.3.0
  $ ls -l adainclude | head -10
total 15088
-r--r- 1 root root   2830 Feb  3 13:56 a-assert.adb
-r--r- 1 root root   3742 Feb  3 13:56 a-assert.ads
-r--r- 1 root root   3126 Feb  3 13:56 a-astaco.adb
-r--r- 1 root root   2111 Feb  3 13:56 a-astaco.ads
-r--r- 1 root root  21464 Feb  3 13:56 a-btgbso.adb
-r--r- 1 root root   5460 Feb  3 13:56 a-btgbso.ads
-r--r- 1 root root   4345 Feb  3 13:56 a-calari.adb
-r--r- 1 root root   3420 Feb  3 13:56 a-calari.ads
-r--r- 1 root root   5341 Feb  3 13:56 a-calcon.adb
  $ ls -l adalib | head -10 
total 43416
-r--r- 1 root root 1702 Feb  3 14:31 a-assert.ali
-r--r- 1 root root14582 Feb  3 14:31 a-btgbso.ali
-r--r- 1 root root 2587 Feb  3 14:31 a-calari.ali
-r--r- 1 root root 4169 Feb  3 14:31 a-calcon.ali
-r--r- 1 root root 3224 Feb  3 14:31 a-caldel.ali
-r--r- 1 root root19503 Feb  3 14:31 a-calend.ali
-r--r- 1 root root14967 Feb  3 14:31 a-calfor.ali
-r--r- 1 root root 1985 Feb  3 14:31 a-catizo.ali
-r--r- 1 root root38194 Feb  3 14:31 a-cbdlli.ali

For some reason, world read access is removed by the installation routines.

[Bug target/79404] h8300: ICE at gcc/ira.c:5541 whilst building libgcc

[dhowells at redhat dot com]

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

--- Comment #1 from dhowells at redhat dot com  ---
gcc is SVNREV 245184 plus the Fedora patches.

[Bug c++/69139] [4.9/5/6 Regression] deduction failure with trailing return type in function template argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|4.9.4   |6.0

[Bug rtl-optimization/79388] [6/7 Regression] wrong code with -O -fno-tree-coalesce-vars

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
At -O2 vrp would normally optimize this already much earlier.

[Bug tree-optimization/79256] [7 Regression] FAIL: gcc.dg/vect/pr25413a.c execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Tue Feb  7 11:29:06 2017
New Revision: 245245

URL: https://gcc.gnu.org/viewcvs?rev=245245&root=gcc&view=rev
Log:
2017-02-07  Richard Biener  

PR tree-optimization/79256
PR middle-end/79278
* builtins.c (get_object_alignment_2): Use min_align_of_type
to extract alignment for MEM_REFs to honor BIGGEST_FIELD_ALIGNMENT
and ADJUST_FIELD_ALIGN.

* doc/tm.texi.in (ADJUST_FIELD_ALIGN): Adjust to take additional
type parameter.
* doc/tm.texi: Regenerate.
* stor-layout.c (layout_decl): Adjust.
(update_alignment_for_field): Likewise.
(place_field): Likewise.
(min_align_of_type): Likewise.
* config/arc/arc.h (ADJUST_FIELD_ALIGN): Adjust.
* config/epiphany/epiphany.h (ADJUST_FIELD_ALIGN): Likewise.
* config/epiphany/epiphany.c (epiphany_adjust_field_align): Likewise.
* config/frv/frv.h (ADJUST_FIELD_ALIGN): Likewise.
* config/frv/frv.c (frv_adjust_field_align): Likewise.
* config/i386/i386.h (ADJUST_FIELD_ALIGN): Likewise.
* config/i386/i386.c (x86_field_alignment): Likewise.
* config/rs6000/aix.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/darwin.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/freebsd64.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/linux64.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/sysv4.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/rs6000.c (rs6000_special_adjust_field_align_p):
 Likewise.

go/
* go-backend.c (go_field_alignment): Adjust.

libobjc/
* encoding.c (objc_layout_structure_next_member): Adjust
ADJUST_FIELD_ALIGN usage.

Revert
2017-01-30  Richard Biener  

PR tree-optimization/79256
* targhooks.c (default_builtin_vector_alignment_reachable): Honor
BIGGEST_FIELD_ALIGNMENT and ADJUST_FIELD_ALIGN to fix up bogus
alignment on TYPE.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/config/arc/arc.h
trunk/gcc/config/epiphany/epiphany.c
trunk/gcc/config/epiphany/epiphany.h
trunk/gcc/config/frv/frv.c
trunk/gcc/config/frv/frv.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/config/rs6000/aix.h
trunk/gcc/config/rs6000/darwin.h
trunk/gcc/config/rs6000/freebsd64.h
trunk/gcc/config/rs6000/linux64.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/sysv4.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-backend.c
trunk/gcc/stor-layout.c
trunk/gcc/targhooks.c
trunk/libobjc/ChangeLog
trunk/libobjc/encoding.c

[Bug middle-end/79278] get_object_alignment and RTL expansion are wrong for ADJUST_FIELD_ALIGN using targets/types

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue Feb  7 11:29:06 2017
New Revision: 245245

URL: https://gcc.gnu.org/viewcvs?rev=245245&root=gcc&view=rev
Log:
2017-02-07  Richard Biener  

PR tree-optimization/79256
PR middle-end/79278
* builtins.c (get_object_alignment_2): Use min_align_of_type
to extract alignment for MEM_REFs to honor BIGGEST_FIELD_ALIGNMENT
and ADJUST_FIELD_ALIGN.

* doc/tm.texi.in (ADJUST_FIELD_ALIGN): Adjust to take additional
type parameter.
* doc/tm.texi: Regenerate.
* stor-layout.c (layout_decl): Adjust.
(update_alignment_for_field): Likewise.
(place_field): Likewise.
(min_align_of_type): Likewise.
* config/arc/arc.h (ADJUST_FIELD_ALIGN): Adjust.
* config/epiphany/epiphany.h (ADJUST_FIELD_ALIGN): Likewise.
* config/epiphany/epiphany.c (epiphany_adjust_field_align): Likewise.
* config/frv/frv.h (ADJUST_FIELD_ALIGN): Likewise.
* config/frv/frv.c (frv_adjust_field_align): Likewise.
* config/i386/i386.h (ADJUST_FIELD_ALIGN): Likewise.
* config/i386/i386.c (x86_field_alignment): Likewise.
* config/rs6000/aix.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/darwin.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/freebsd64.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/linux64.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/sysv4.h (ADJUST_FIELD_ALIGN): Likewise.
* config/rs6000/rs6000.c (rs6000_special_adjust_field_align_p):
 Likewise.

go/
* go-backend.c (go_field_alignment): Adjust.

libobjc/
* encoding.c (objc_layout_structure_next_member): Adjust
ADJUST_FIELD_ALIGN usage.

Revert
2017-01-30  Richard Biener  

PR tree-optimization/79256
* targhooks.c (default_builtin_vector_alignment_reachable): Honor
BIGGEST_FIELD_ALIGNMENT and ADJUST_FIELD_ALIGN to fix up bogus
alignment on TYPE.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/config/arc/arc.h
trunk/gcc/config/epiphany/epiphany.c
trunk/gcc/config/epiphany/epiphany.h
trunk/gcc/config/frv/frv.c
trunk/gcc/config/frv/frv.h
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/config/rs6000/aix.h
trunk/gcc/config/rs6000/darwin.h
trunk/gcc/config/rs6000/freebsd64.h
trunk/gcc/config/rs6000/linux64.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/sysv4.h
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-backend.c
trunk/gcc/stor-layout.c
trunk/gcc/targhooks.c
trunk/libobjc/ChangeLog
trunk/libobjc/encoding.c

[Bug middle-end/79278] get_object_alignment and RTL expansion are wrong for ADJUST_FIELD_ALIGN using targets/types

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/79402] ICE with submodules: module procedure interface defined in parent module

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
Dear Stefano (and Chris),

I can confirm that the bug is there on the latest 7.0.1. This is the
minimum testcase that exhibits the problem.

module mod
  interface myfun
module function fun1(n) result(y)
  integer,  intent(in):: n
  real, dimension(n)  :: y
end function fun1
  end interface myfun

end module mod

submodule (mod) submod
contains
  module procedure fun1

  end procedure fun1
end submodule

It appears that 'n' doesn't get treated as a dummy for reasons that I
do not see right now.

Bizarrely, this works perfectly and might be a good workaround for
you, omitting the 'source' part of the allocate, if you are assigning
to y somewhere else:

module mod
  interface myfun
module function fun1(n) result(y)
  integer,  intent(in):: n
  real, allocatable, dimension(:)  :: y
end function fun1
  end interface myfun

end module mod

submodule (mod) submod
contains
  module procedure fun1
allocate (y(n), source = [(float(i), i = 1,n)])
  end procedure fun1
end submodule

  use mod
  print *, fun1(5)
end

I don't feel much like a 'superhero' right now:-( I have spent the last month
moving between countries and have only just got set up to do anything
gfortran-ish in the last 24 hours.

Thanks

Paul

[Bug fortran/79402] ICE with submodules: module procedure interface defined in parent module

[stefano.zaghi at gmail dot com]

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

--- Comment #2 from stefano.zaghi at gmail dot com ---
Dear Paul,

thank you for the insight.

Trust me, all GNU gfortran developers are heroes!

Cheers

Stefano Zaghi  Ph.D. Aerospace Engineer

Research Scientist, Dept. of Computational Hydrodynamics at CNR-INSEAN
p: +39 0650299260 | m: +39 3497730036 | e: stefano.za...@gmail.com

Member of Fortran-FOSS-Programmers

Codes Showcase
OFF  Open source Finite volumes Fluid dynamics code
Lib_VTK_IO   Fortran library to write and read data conforming the VTK standard
FLAP Fortran command Line Arguments Parser for poor men
BeFoR64  Base64 encoding/decoding library for FoRtran poor men
FiNeRFortran INI ParseR and generator for FoRtran poor men
IR_Precision Fortran (standard 2003) module to develop portable codes
FoBis.py Fortran Building System for poor men
PreForM.py   Preprocessor for Fortran poor men
MaTiSSe.py   Markdown To Impressive Scientific Slides



On Tue, Feb 7, 2017 at 12:45 PM, pault at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79402
>
> Paul Thomas  changed:
>
>What|Removed |Added
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2017-02-07
>  CC||pault at gcc dot gnu.org
>Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot 
> gnu.org
>  Ever confirmed|0   |1
>
> --- Comment #1 from Paul Thomas  ---
> Dear Stefano (and Chris),
>
> I can confirm that the bug is there on the latest 7.0.1. This is the
> minimum testcase that exhibits the problem.
>
> module mod
>   interface myfun
> module function fun1(n) result(y)
>   integer,  intent(in):: n
>   real, dimension(n)  :: y
> end function fun1
>   end interface myfun
>
> end module mod
>
> submodule (mod) submod
> contains
>   module procedure fun1
>
>   end procedure fun1
> end submodule
>
> It appears that 'n' doesn't get treated as a dummy for reasons that I
> do not see right now.
>
> Bizarrely, this works perfectly and might be a good workaround for
> you, omitting the 'source' part of the allocate, if you are assigning
> to y somewhere else:
>
> module mod
>   interface myfun
> module function fun1(n) result(y)
>   integer,  intent(in):: n
>   real, allocatable, dimension(:)  :: y
> end function fun1
>   end interface myfun
>
> end module mod
>
> submodule (mod) submod
> contains
>   module procedure fun1
> allocate (y(n), source = [(float(i), i = 1,n)])
>   end procedure fun1
> end submodule
>
>   use mod
>   print *, fun1(5)
> end
>
> I don't feel much like a 'superhero' right now:-( I have spent the last month
> moving between countries and have only just got set up to do anything
> gfortran-ish in the last 24 hours.
>
> Thanks
>
> Paul
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug tree-optimization/79347] [7 regression] vect_do_peeling is messing up profile

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #4 from amker at gcc dot gnu.org ---
Thanks for investigating this, I will study the issue.

Thanks.

[Bug c++/79393] [7 Regression] cc1plus rejects valid code with noexcept

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-02-07
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/79405] New: [7 Regression] Compile-time hog w/ -O2 (-Os, -O3) on 32-bit BE powerpc targets

[asolokha at gmx dot com]

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

Bug ID: 79405
   Summary: [7 Regression] Compile-time hog w/ -O2 (-Os, -O3) on
32-bit BE powerpc targets
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*

gcc-7.0.0-alpha20170205 snapshot takes large (or indefinite?) time to compile
the following snippet at -O2 (-Os, -O3) for 32-bit BE powerpc:

char cz;
long long int xx, u2;

void
qv (int js, int wl)
{
  if (js != 0)
{
  short int sc;
  int *at = (int *)≻
  long long int gx = 0;

  for (;;)
{
  *at = 0;
  js /= sc;

  for (wl = 0; wl < 2; ++wl)
{
  xx = gx;
  u2 %= xx > 0;
  cz /= u2;

 fa:
  if (cz != u2)
{
  gx |= js;
  cz = gx / js;
}
}
}

 yq:
  wl /= 0x8000;
  u2 = wl;
  u2 |= (wl != 0) | (wl != 0 && gx != 0);
  js = u2;
  goto fa;
}
  goto yq;
}

[Bug c++/79369] namespace definition with qualified id

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Ah 'namespace X::Y' is permitted to create namespace X.  However the following
is ill-formed, but we accept w/o error:

namespace X {}
inline namespace X {} // ERROR

inline namespace Y {}
namespace Y {} // OK

[Bug c++/14179] [5/6/7 Regression] out of memory while parsing array with many initializers

[rguenth at gcc dot gnu.org]

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

--- Comment #76 from Richard Biener  ---
Top VM usage update:

4.7.2   14s1660M  (-O0)
7.0.1   20s1100M  (-O0 -fno-checking but checking enabled)

[Bug target/78945] [arm] libatomic inline asm is not compatible with armv7-m

[nsz at gcc dot gnu.org]

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

--- Comment #5 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Tue Feb  7 12:47:51 2017
New Revision: 245246

URL: https://gcc.gnu.org/viewcvs?rev=245246&root=gcc&view=rev
Log:
[ARM][PR target/78945] Fix libatomic on armv7-m

libatomic/

Backport from mainline:
2017-01-30  Szabolcs Nagy  

PR target/78945
* config/arm/exch_n.c (libat_exchange): Check __ARM_FEATURE_SIMD32.


Modified:
branches/gcc-6-branch/libatomic/ChangeLog
branches/gcc-6-branch/libatomic/config/arm/exch_n.c

[Bug c++/14179] [5/6/7 Regression] out of memory while parsing array with many initializers

[rguenth at gcc dot gnu.org]

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

--- Comment #77 from Richard Biener  ---
So the "low hanging fruit" remaining is reshape_init_array copying the whole
array even if not necessary.

INTEGER_CSTs still account for most of the memory use (200MB) apart from C++
preprocessor tokens (530MB) and the actual array of tree pointers for the
constructors (2x 130MB at peak).

[Bug target/78945] [arm] libatomic inline asm is not compatible with armv7-m

[nsz at gcc dot gnu.org]

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

--- Comment #6 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Tue Feb  7 12:51:00 2017
New Revision: 245247

URL: https://gcc.gnu.org/viewcvs?rev=245247&root=gcc&view=rev
Log:
[ARM][PR target/78945] Fix libatomic on armv7-m

libatomic/

Backport from mainline:
2017-01-30  Szabolcs Nagy  

PR target/78945
* config/arm/exch_n.c (libat_exchange): Check __ARM_FEATURE_SIMD32.


Modified:
branches/gcc-5-branch/libatomic/ChangeLog
branches/gcc-5-branch/libatomic/config/arm/exch_n.c

[Bug target/78945] [arm] libatomic inline asm is not compatible with armv7-m

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |7.0
  Known to fail||5.4.0, 6.3.0

--- Comment #7 from nsz at gcc dot gnu.org ---
fixed on trunk and backported to gcc-5 and gcc-6 branches.

[Bug demangler/79406] New: Demangler crash

[jeanmichael.celerier at gmail dot com]

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

Bug ID: 79406
   Summary: Demangler crash
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeanmichael.celerier at gmail dot com
  Target Milestone: ---

With the following symbol : 

_ZSt4moveIRZN5ossia8oscquery16websocket_server19set_message_handlerIZNS1_24oscquery_server_protocolC4EssEUlDpOT_E2_EEvT_EUlSt8weak_ptrIvESt10shared_ptrIN11websocketpp14message_buffer7messageINSE_5alloc15con_msg_managerE_EONSt16remove_referenceIS9_E4typeEOS9_

[Bug demangler/79406] Demangler crash

[jeanmichael.celerier at gmail dot com]

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

--- Comment #1 from Jean-Michaël Celerier  ---
This stems from the usage of the following lambda expression : 

[&] (auto&&... args) { return
this->fun(std::forward(args)...); }

Unlike bug 77950 the enclosing function is not a template but a simple class
constructor that takes two int16_t.

The arguments passed to the lambda are either : 

* (std::weak_ptr)
* (std::weak_ptr, const std::string&)

[Bug rtl-optimization/79405] [7 Regression] Compile-time hog w/ -O2 (-Os, -O3) on 32-bit BE powerpc targets

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
  Component|tree-optimization   |rtl-optimization
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
works on x86_64/i?86.  Confirmed with a cross:

(gdb) 
Run till exit from #0  fwprop ()
at /space/rguenther/src/svn/gcc-7-branch/gcc/fwprop.c:1481

[Bug rtl-optimization/79405] [7 Regression] Compile-time hog w/ -O2 (-Os, -O3) on 32-bit BE powerpc targets

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
(gdb) l
1476 end, and we'll go through them as well.
1477
1478 Do not forward propagate addresses into loops until after
unrolling.
1479 CSE did so because it was able to fix its own mess, but we are
not.  */
1480
1481  for (i = 0; i < DF_USES_TABLE_SIZE (); i++)
1482{
1483  df_ref use = DF_USES_GET (i);
1484  if (use)
1485if (DF_REF_TYPE (use) == DF_REF_REG_USE
(gdb) p i
$8 = 53321

so it looks like sth corrupts uses (dumping the function at this point only
shows 80 insns).

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[dje at gcc dot gnu.org]

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

--- Comment #48 from David Edelsohn  ---
Based on Comment #45, is this a problem in the Stage 1 compilers?  Note that
Alan and Segher adjusted the doloop patterns in this release cycle.  Does
backporting that patch or bootstrapping with current trunk function better?

[Bug c++/79407] New: -fcall-saved-rax flag causes an internal segmentation fault

[mini at cs dot technion.ac.il]

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

Bug ID: 79407
   Summary: -fcall-saved-rax flag causes an internal segmentation
fault
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mini at cs dot technion.ac.il
  Target Milestone: ---

I am getting internal error with the -fcall-saved-rax flag

gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) 

to reproduce:

$ cat main.c
int main() {
int* x = new int;
return 0;
}
$ g++ -fcall-saved-rax main.c 
main.c: In function ‘int main()’:
main.c:16:15: internal compiler error: Segmentation fault
  int* x = new int;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/79407] -fcall-saved-rax flag causes an internal segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
  Component|c++ |middle-end
 Ever confirmed|0   |1
  Known to fail||7.0.1

--- Comment #1 from Richard Biener  ---
Confirmed on trunk:

Program received signal SIGSEGV, Segmentation fault.
0x00bc2d08 in expand_call (exp=, target=0x0, 
ignore=0) at /space/rguenther/src/svn/gcc-7-branch/gcc/calls.c:3973
3973  rtx temp = gen_reg_rtx (GET_MODE (valreg));
(gdb) p valreg
$1 = (rtx) 0x0


I suppose this falls under the "don't do that" category of bugs though.

[Bug middle-end/79407] -fcall-saved-rax flag causes an internal segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Richard Biener  ---
Quote:

"It is an error to use this flag with the frame pointer or stack pointer.
Use of this flag for other registers that have fixed pervasive roles in
the machine's execution model produces disastrous results.

A different sort of disaster results from the use of this flag for
a register in which function values may be returned.
"

so you get that different sort of disaster results.

[Bug rtl-optimization/79405] [7 Regression] Compile-time hog w/ -O2 (-Os, -O3) on 32-bit BE powerpc targets

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r242075 (though, being a RTL problem, most likely latent before).

[Bug tree-optimization/79408] New: Missed VRP optimization of integer modulo

[jakub at gcc dot gnu.org]

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

Bug ID: 79408
   Summary: Missed VRP optimization of integer modulo
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

While looking at PR79388, I've noticed that while VRP optimizes well integer
modulo if say first operand is [0, 133] and second operand 134, we don't do the
same if second operand is [134, 237] or [134, +INF].

Testcase:
unsigned int
foo (unsigned int x, unsigned int y)
{
  if (x > 7312)
return 7;
  if (y <= 7312)
return 12;
  return x % y;
}

int
bar (int x, int y)
{
  if (x > 7312 || x < 0)
return 8;
  if (y <= 7312)
return 13;
  return x % y;
}

int
baz (int x, int y)
{
  if (x > 7312 || x < -7312)
return 9;
  if (y <= 7312)
return 14;
  return x % y;
}

[Bug tree-optimization/79408] Missed VRP optimization of integer modulo

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-02-07
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[law at redhat dot com]

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

--- Comment #49 from Jeffrey A. Law  ---
Note there's also been a series of fixes to the generic doloop code over the
last 18 months.  So that's another avenue that might be worth pursuing.

[Bug tree-optimization/79408] Missed VRP optimization of integer modulo

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 40687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40687&action=edit
gcc7-pr79408.patch

Untested fix.

[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #12 from wilco at gcc dot gnu.org ---
Does wp512 use 64-bit types? If so, this is likely PR77308.

[Bug target/79299] [7 Regression] Operand size mismatch for `vpgatherqd' w/ -O3 -masm=intel -mavx512bw

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  7 15:42:42 2017
New Revision: 245248

URL: https://gcc.gnu.org/viewcvs?rev=245248&root=gcc&view=rev
Log:
PR target/79299
* config/i386/sse.md (xtg_mode, gatherq_mode): New mode attrs.
(*avx512f_gathersi, *avx512f_gathersi_2,
*avx512f_gatherdi, *avx512f_gatherdi_2): Use them,
fix -masm=intel patterns.

* gcc.target/i386/avx512vl-pr79299-1.c: New test.
* gcc.target/i386/avx512vl-pr79299-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr79299-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-pr79299-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/79299] [7 Regression] Operand size mismatch for `vpgatherqd' w/ -O3 -masm=intel -mavx512bw

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[aldyh at gcc dot gnu.org]

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

--- Comment #50 from Aldy Hernandez  ---
(In reply to David Edelsohn from comment #48)
> Based on Comment #45, is this a problem in the Stage 1 compilers?  Note that
> Alan and Segher adjusted the doloop patterns in this release cycle.  Does
> backporting that patch or bootstrapping with current trunk function better?

The stage2 compiler fails to build anything (libgcc in this case) because the
stage1 compiler miscompiled the testcase I posted.

I tried backporting the following two patches to no avail:

commit b2d4fe71855caaae720f7839d3e33b061d2069ca
Author: amodra 
Date:   Sat Jan 14 13:24:46 2017 +

Avoid PR72749 by not using unspecs

Rather than using unspecs in doloop insns to stop combine creating
these insns, use legitimate_combined_insn.

PR target/72749
* combine.c (recog_for_combine_1): Set INSN_CODE before calling
target legitimate_combined_insn.
* config/rs6000/rs6000.c (TARGET_LEGITIMATE_COMBINED_INSN): Define.
(rs6000_legitimate_combined_insn): New function.
* config/rs6000/rs6000.md (UNSPEC_DOLOOP): Delete, and remove
all uses.
(ctr_internal3): Rename from *ctr_internal5.
(ctr_internal4): Rename from *ctr_internal6.
(ctr_internal1, ctr_internal2): Remove '*' from name.

commit d7a73763f9dfa9cec35bcf40d926ee03ae85fb2d
Author: amodra 
Date:   Mon Jul 11 10:28:48 2016 +

[RS6000] Don't allow combine to form doloop pattern

* config/rs6000/rs6000.md (UNSPEC_DOLOOP): New unspec.
(ctr): Add unspec.
(ctr_internal*): Likewise.

And yes, I'm sure bootstrapping the current trunk would work, but that would
have us back at square one, having no idea why the patch in question is now
bootstrapping ;-).

I suppose we could remove Richi's patch that makes the problem disappear, and
bisect forward to see if there's another set of patches that also fix the
problem but are related to doloop or the patch at hand.  Though at this point,
I'd rather we figure out why the erroneous code is being generated in comment
45.  Bisecting AIX and the hand-holding required takes a good hour and a half
at each of the 13 iterations it would at least take.

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[dje at gcc dot gnu.org]

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

--- Comment #51 from David Edelsohn  ---
If you use /scratch for source, build and TMPDIR, as well as

SHELL=/usr/bin/bash CONFIG_SHELL=/usr/bin/bash

it should build faster on AIX.

[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases

[arnd at linaro dot org]

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

--- Comment #13 from Arnd Bergmann  ---
(In reply to wilco from comment #12)
> Does wp512 use 64-bit types? If so, this is likely PR77308.

Yes, as seen in the attachment it uses lots of 64-bit operations. However, it
sounds like PR77308 is ARM specific, but I see the same behavior
on most other architectures, including 64-bit ones. Quoting the
kernel patch I linked to, with stack frame sizes for the function
depending on architecture, optimization flags and compiler version
(only 4.9 and 7.0 here, there is little difference anyway)

default: -O2
press:   -O2 -fsched-pressure
nopress: -O2 -fschedule-insns -fno-sched-pressure
nosched: -O2 -no-schedule-insns (disables sched-pressure)

default press   nopress nosched
alpha-linux-gcc-4.9.3   1136848 1136176
am33_2.0-linux-gcc-4.9.32100207621002104
arm-linux-gnueabi-gcc-4.9.3 848 848 1048352
cris-linux-gcc-4.9.3272 272 272 272
frv-linux-gcc-4.9.3 112810001128280
hppa64-linux-gcc-4.9.3  1128336 1128184
hppa-linux-gcc-4.9.3644 308 644 276
i386-linux-gcc-4.9.3352 352 352 352
m32r-linux-gcc-4.9.3720 656 720 268
microblaze-linux-gcc-4.9.3  1108604 1108256
mips64-linux-gcc-4.9.3  1328592 1328208
mips-linux-gcc-4.9.31096624 1096240
powerpc64-linux-gcc-4.9.3   1088432 1088160
powerpc-linux-gcc-4.9.3 1080584 1080224
s390-linux-gcc-4.9.3456 456 624 360
sh3-linux-gcc-4.9.3 292 292 292 292
sparc64-linux-gcc-4.9.3 992 240 992 208
sparc-linux-gcc-4.9.3   680 592 680 312
x86_64-linux-gcc-4.9.3  224 240 272 224
xtensa-linux-gcc-4.9.3  1152704 1152304

aarch64-linux-gcc-7.0.0 224 224 1104208
arm-linux-gnueabi-gcc-7.0.1 824 824 1048352
mips-linux-gcc-7.0.01120648 1120272
mips64-linux-gcc-7.0.0  1072608 1072224
x86_64-linux-gcc-7.0.1  240 240 304 240

[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Fails since r241187, aka http://wg21.link/p0017
Jonathan, is it rejected correctly after P0017R1 or not?

[Bug libgomp/42125] check libgomp fails

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Martin Sebor  ---
The latest Cygwin test results reported for GCC 6.4.1 show only a handful of
libgomp failures
(https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg02442.html).  Since this
report is older than 7 years, never been confirmed, and GCC 4.4 is not
supported anymore I'm closing it.

[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

 CC||Casey at Carter dot net

--- Comment #4 from Casey Carter  ---
(In reply to Jonathan Wakely from comment #3)
> I think this is a bug. derived is not an aggregate, because it inherits a
> user-provided constructor, so braced-init should call the base(int, int)
> constructor, not attempt aggregate init.

This. N4618 [dcl.init.aggr]/1 says:

1 An aggregate is an array or a class with

  1.1 --- no user-provided, explicit, or inherited constructors

  [...]

[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Yeah, found the same in the mean time.
Following works, I bet in the #c0 CLASSTYPE_NON_AGGREGATE isn't set on derived
for some reason.

struct base {
  base(int, int) {}
};

template
struct derived : base {
  derived(int, int) : base(0, 0) {}
};

int main() {
  base(13, 42); // Fine
  derived(13, 42); // Fine
  base{13, 42}; // Fine
  derived{13, 42}; // Fine
}

[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
I think this is a bug. derived is not an aggregate, because it inherits a
user-provided constructor, so braced-init should call the base(int, int)
constructor, not attempt aggregate init.

[Bug tree-optimization/79409] New: [7 Regression] [graphite] ICE in outermost_loop_in_sese, at sese.c:300 w/ -fgraphite-identity -ftree-loop-distribution -O1 (or above)

[asolokha at gmx dot com]

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

Bug ID: 79409
   Summary: [7 Regression] [graphite] ICE in
outermost_loop_in_sese, at sese.c:300 w/
-fgraphite-identity -ftree-loop-distribution -O1 (or
above)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20170205 snapshot ICEs when compiling the following snippet w/
-O1 (-O2, -O3, -Ofast) -fgraphite-identity -ftree-loop-distribution:

struct
{
  int bz;
} od, ka[2];
int fw;

void
pc (void)
{
  for (od.bz = 0; od.bz < 2; ++od.bz)
{
  ++fw;
  ka[0] = ka[1];
}
}

% gcc-7.0.0-alpha20170205 -O1 -fgraphite-identity -ftree-loop-distribution -c
ady9pcky.c
ady9pcky.c: In function 'pc':
ady9pcky.c:8:1: internal compiler error: in outermost_loop_in_sese, at
sese.c:300
 pc (void)
 ^~

[Bug bootstrap/42176] bootstrap fails while building libstdc++-v3 on debian sarge (related to cstdio and similar to #30915)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #4 from Martin Sebor  ---
The most recent test results for the oldest Debian I could find are for 5.4.1:
https://gcc.gnu.org/ml/gcc-testresults/2017-02/msg00656.html.  Since those are
successful (as are other Debian test results) and since GCC 4.4 is no longer
maintained I'll close this.  Please open a new bug if the problems persist with
recent versions of GCC.

[Bug driver/42106] Simplistic build works, then fails to find cc1plus on its own

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Martin Sebor  ---
There isn't enough information here to tell what may have been the problem but
current Solaris test results show no such failures with recent versions of GCC:

https://gcc.gnu.org/ml/gcc-testresults/2017-02/msg00616.html

Since GCC 4.3 is no lo longer maintained I'm closing this report.  Please open
a new bug if the problem persists with the current GCC.

[Bug target/42102] ICE of optimize

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Current trunk (GCC 7) configured for the rx-elf target compiles the test case
successfully.  Resolving as fixed. 

$ /build/rx-elf/gcc-trunk/gcc/xgcc -B /build/rx-elf/gcc-trunk/gcc  -S -O2 -v
t.c
Reading specs from /build/rx-elf/gcc-trunk/gcc/specs
COLLECT_GCC=/build/rx-elf/gcc-trunk/gcc/xgcc
Target: rx-elf
Configured with: /src/gcc/trunk/configure --enable-languages=c,c++
--prefix=/build/sysroot/rx-elf --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=rx-elf --without-headers
Thread model: single
gcc version 7.0.1 20170207 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-B' '/build/rx-elf/gcc-trunk/gcc' '-S' '-O2' '-v'
 /build/rx-elf/gcc-trunk/gcc/cc1 -quiet -v -iprefix
/home/msebor/build/rx-elf/gcc-trunk/gcc/../lib/gcc/rx-elf/7.0.1/ -isystem
/build/rx-elf/gcc-trunk/gcc/include -isystem
/build/rx-elf/gcc-trunk/gcc/include-fixed t.c -quiet -dumpbase t.c -auxbase t
-O2 -version -o t.s
GNU C11 (GCC) version 7.0.1 20170207 (experimental) (rx-elf)
compiled by GNU C version 5.3.1 20151207 (Red Hat 5.3.1-2), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
...
#include "..." search starts here:
#include <...> search starts here:
 /build/rx-elf/gcc-trunk/gcc/include
 /build/rx-elf/gcc-trunk/gcc/include-fixed
End of search list.
GNU C11 (GCC) version 7.0.1 20170207 (experimental) (rx-elf)
compiled by GNU C version 5.3.1 20151207 (Red Hat 5.3.1-2), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 982af928627021b9f23f5068d2fd4ae5
t.c: In function ‘pagevec_release’:
t.c:27:6: warning: implicit declaration of function ‘pagevec_count’; did you
mean ‘pagevec_release’? [-Wimplicit-function-declaration]
  if (pagevec_count(pvec))
  ^
  pagevec_release
t.c:28:3: warning: implicit declaration of function ‘__pagevec_release’; did
you mean ‘pagevec_release’? [-Wimplicit-function-declaration]
   __pagevec_release(pvec);
   ^
   pagevec_release
t.c: In function ‘write_cache_pages’:
t.c:52:14: warning: implicit declaration of function ‘pagevec_lookup_tag’
[-Wimplicit-function-declaration]
   nr_pages = pagevec_lookup_tag(&pvec, mapping, &index,
  ^~
t.c:57:4: warning: implicit declaration of function ‘lock_page’
[-Wimplicit-function-declaration]
lock_page(page);
^
t.c:60:5: warning: implicit declaration of function ‘unlock_page’
[-Wimplicit-function-declaration]
 unlock_page(page);
 ^~~
t.c:64:9: warning: implicit declaration of function ‘clear_page_dirty_for_io’
[-Wimplicit-function-declaration]
if (!clear_page_dirty_for_io(page))
 ^~~
t.c:67:28: warning: implicit declaration of function ‘bdi_write_congested’
[-Wimplicit-function-declaration]
if (wbc->nonblocking && bdi_write_congested(bdi)) {
^~~
COMPILER_PATH=/build/rx-elf/gcc-trunk/gcc/
LIBRARY_PATH=/build/rx-elf/gcc-trunk/gcc/
COLLECT_GCC_OPTIONS='-B' '/build/rx-elf/gcc-trunk/gcc' '-S' '-O2' '-v'

[Bug debug/42065] DWARF .debug_macinfo contains unused macros

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
It doesn't look like this has changed between GCC 4.5 and GCC 7 so I'll confirm
it as a missing space optimization.

$ cat t.c && gcc -g3 -Wall -feliminate-unused-debug-symbols
-feliminate-unused-debug-types t.c && readelf -wm a.out | grep -e NOT -e USED
#define NOT used
#define USED(x) x
int main (void) { return USED (0); }
 DW_MACRO_GNU_define_indirect - lineno : 1 macro : NOT used
 DW_MACRO_GNU_define_indirect - lineno : 2 macro : USED(x) x

With GCC 7, even an empty object file contains 345 macro definitions (one for
each macro predefined by GCC):

$ /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -c -g3 -xc -ot.o -

[Bug c++/79410] New: [6 Regression] internal compiler error: in gimplify_init_ctor_preeval, at gimplify.c:3489

[redi at gcc dot gnu.org]

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

Bug ID: 79410
   Summary: [6 Regression] internal compiler error: in
gimplify_init_ctor_preeval, at gimplify.c:3489
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This gives an ICE with -O1

struct duration {
  long val;
  static constexpr duration max() { return {}; }
};
struct S {
  duration max = duration::max();
};
void Ice(S& s) {
  s = {};
}

ice.cc: In function ‘void Ice(S&)’:
ice.cc:9:9: internal compiler error: in gimplify_init_ctor_preeval, at
gimplify.c:3489
   s = {};
 ^
0x8e5582 gimplify_init_ctor_preeval
../../gcc-6.3.0/gcc/gimplify.c:3489
0x8e5acf gimplify_init_constructor
../../gcc-6.3.0/gcc/gimplify.c:4063
0x8e6421 gimplify_modify_expr_rhs
../../gcc-6.3.0/gcc/gimplify.c:4346
0x8e652f gimplify_modify_expr
../../gcc-6.3.0/gcc/gimplify.c:4683
0x8dcd99 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-6.3.0/gcc/gimplify.c:10386
0x8dfae6 gimplify_stmt(tree_node**, gimple**)
../../gcc-6.3.0/gcc/gimplify.c:5687
0x8dc8d8 gimplify_cleanup_point_expr
../../gcc-6.3.0/gcc/gimplify.c:5463
0x8dc8d8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-6.3.0/gcc/gimplify.c:10751
0x8dfae6 gimplify_stmt(tree_node**, gimple**)
../../gcc-6.3.0/gcc/gimplify.c:5687
0x8e0cac gimplify_body(tree_node*, bool)
../../gcc-6.3.0/gcc/gimplify.c:11532
0x8e1077 gimplify_function_tree(tree_node*)
../../gcc-6.3.0/gcc/gimplify.c:11688
0x7bfd27 cgraph_node::analyze()
../../gcc-6.3.0/gcc/cgraphunit.c:625
0x7c26df analyze_functions
../../gcc-6.3.0/gcc/cgraphunit.c:1086
0x7c2e58 symbol_table::finalize_compilation_unit()
../../gcc-6.3.0/gcc/cgraphunit.c:2542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 40688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40688&action=edit
gcc7-pr79143.patch

Untested fix.

[Bug c++/79410] [6 Regression] internal compiler error: in gimplify_init_ctor_preeval, at gimplify.c:3489

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
No ICE with -std=gnu++11 so maybe related to C++14 constexpr rules.

Similar to Bug 60951.

[Bug preprocessor/42014] Inconsistent column number display for "In file incuded from"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Martin Sebor  ---
Looks like a fix was proposed but the approval was made contingent on getting
some a suite issue sorted out.  Marcin, did you manage to resolve the test
suite issue with David's suggestion?

I'm moving the status to New.

[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll

[segher at gcc dot gnu.org]

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

--- Comment #52 from Segher Boessenkool  ---
(In reply to Aldy Hernandez from comment #50)
> Though at this
> point, I'd rather we figure out why the erroneous code is being generated in
> comment 45.

If you can send me the output (.s and .c.*) with -dap I can probably
figure it out.  But please with a cut-down testcase -- this 2.5MB source
file results in 2.5GB of output files.

[Bug c/30552] gcc crashed when compiling an example

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #1 from Gerhard Steinmetz  
---
Update :


$ gcc-7-20170205 -c pr30552.c
pr30552.c: In function 'fun':
pr30552.c:6:5: internal compiler error: Segmentation fault
 int a[({void h(){}2;})];
 ^~~
0xbf633f crash_signal
../../gcc/toplev.c:333
0x670701 c_push_function_context()
../../gcc/c/c-decl.c:9504
0x6cf8a2 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2038
0x6d3ea2 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:4831
0x6af37a c_parser_postfix_expression
../../gcc/c/c-parser.c:7665
0x6b939a c_parser_unary_expression
../../gcc/c/c-parser.c:7052
0x6ba1a7 c_parser_cast_expression
../../gcc/c/c-parser.c:6881
0x6ba3c2 c_parser_binary_expression
../../gcc/c/c-parser.c:6690
0x6bb0a5 c_parser_conditional_expression
../../gcc/c/c-parser.c:6458
0x6bb800 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6375
0x6ccebe c_parser_direct_declarator_inner
../../gcc/c/c-parser.c:3591
0x6cea04 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:1797
0x6cf7ce c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2073
0x6d3ea2 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:4831
0x6d44ce c_parser_compound_statement
../../gcc/c/c-parser.c:4740
0x6cf90c c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2112
0x6d791b c_parser_external_declaration
../../gcc/c/c-parser.c:1468
0x6d8379 c_parser_translation_unit
../../gcc/c/c-parser.c:1348
0x6d8379 c_parse_file()
../../gcc/c/c-parser.c:18185
0x736892 c_common_parse_file()
../../gcc/c-family/c-opts.c:1107

[Bug c/30552] gcc crashed when compiling an example

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
Other test cases :


$ cat z1.c
void f()
{
  void g()
void a[( {void b} )];
}


$ cat z2.c
int f()
{
  int g()
int a[( {int b} )];
}

[Bug c/43374] ICE with __builtin_isinf() and _Decimal argument

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #5 from Gerhard Steinmetz  
---
Update :


$ gcc-7-20170205 -c pr43374.c
pr43374.c: In function 'func':
pr43374.c:4:10: internal compiler error: in decimal_to_decnumber, at dfp.c:134
   return __builtin_isinf(v);
  ^~
0x12b9f38 decimal_to_decnumber
../../gcc/dfp.c:134
0x12ba0bf encode_decimal32(real_format const*, long*, real_value const*)
../../gcc/dfp.c:161
0xb51d15 real_to_target(long*, real_value const*, format_helper)
../../gcc/real.c:2835
0xbc73bc simplify_immed_subreg
../../gcc/simplify-rtx.c:5824
0xbd3578 simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned
int)
../../gcc/simplify-rtx.c:6260
0x8ba3b5 emit_move_via_integer
../../gcc/expr.c:3301
0x8c7198 emit_move_insn_1(rtx_def*, rtx_def*)
../../gcc/expr.c:3652
0x8c7494 emit_move_insn(rtx_def*, rtx_def*)
../../gcc/expr.c:3738
0x7a1434 emit_library_call_value_1
../../gcc/calls.c:4895
0x7a82af emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, int, ...)
../../gcc/calls.c:5159
0xaf5ab6 prepare_float_lib_cmp
../../gcc/optabs.c:4172
0xaf5ab6 prepare_cmp_insn
../../gcc/optabs.c:3945
0xaf5bf5 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, int)
../../gcc/optabs.c:4051
0x8314cc do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, int)
../../gcc/dojump.c:1145
0x8319e7 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, int)
../../gcc/dojump.c:1140
0x8b6314 emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, int, int)
../../gcc/expmed.c:5936
0x8d7cde do_store_flag
../../gcc/expr.c:11453
0x8d7cde expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:9203
0x7b6382 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3676
0x7b6382 expand_gimple_stmt
../../gcc/cfgexpand.c:3737

[Bug c/61342] Segfault when using default clause and VLA in OpenMP task

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

 CC||gerhard.steinmetz.fortran@t
   ||-online.de

--- Comment #1 from Gerhard Steinmetz  
---
Update :


$ gcc-7-20170205 -fopenmp -c pr61342.c
'
In function 'main':
Segmentation fault
 (*f)[i][j] = 1;
 ~~~^~~
0xbf633f crash_signal
../../gcc/toplev.c:333
0x6aa870 c_tree_printer
../../gcc/c/c-objc-common.c:169
0x13df6cf pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:679
0x13d2aa8 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:961
0x13d2e03 diagnostic_impl
../../gcc/diagnostic.c:1084
0x13d36d4 error(char const*, ...)
../../gcc/diagnostic.c:1310
0x96e275 omp_default_clause
../../gcc/gimplify.c:6825
0x96e275 omp_notice_variable
../../gcc/gimplify.c:7118
0x96ee85 gimplify_var_or_parm_decl
../../gcc/gimplify.c:2587
0x97387b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11646
0x972426 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11931
0x97b74c gimplify_compound_lval
../../gcc/gimplify.c:2826
0x972653 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11155
0x985e45 gimplify_modify_expr
../../gcc/gimplify.c:5473
0x9743ca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11203
0x9773e6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0x9786cd gimplify_bind_expr
../../gcc/gimplify.c:1290
0x9745ba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11402
0x9773e6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0x975b71 gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.c:435

[Bug c/79411] New: ICE: SSA corruption (fail_abnormal_edge_coalesce)

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 79411
   Summary: ICE: SSA corruption (fail_abnormal_edge_coalesce)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With a modified test pr57026.c at -Os, -O1 or above, down to gcc 4.9 :


$ cat z1.c
typedef struct __jmp_buf_tag { char buf[1024]; } jmp_buf[1];
extern int setjmp (jmp_buf);
extern int bar (unsigned int *);
extern jmp_buf *baz (void);
struct C { int c1; unsigned int c2, c3, c4; };
void
foo (struct C *x, const int *y, unsigned int *z, unsigned int e, unsigned int
g)
{
  unsigned int d = 0;
  unsigned long f;
  setjmp (*baz ());
  f = 1 + d;
  if ((x->c1 || x->c2) && g && (!e || d >= 8))
d = 16;
  else
d = 8;
  if ((!x->c3 && !x->c4 || *y == 0) && !e && bar (z))
*z = 1 + f;
}


$ gcc-7-20170205 -O2 -c z1.c

Unable to coalesce ssa_names 12 and 13 which are marked as MUST COALESCE.
d_12(ab) and  d_13(ab)
z1.c: In function 'foo':
z1.c:7:1: internal compiler error: SSA corruption
 foo (struct C *x, const int *y, unsigned int *z, unsigned int e, unsigned int
g)
 ^~~
0xd152af fail_abnormal_edge_coalesce
../../gcc/tree-ssa-coalesce.c:1010
0xd152af coalesce_partitions
../../gcc/tree-ssa-coalesce.c:1399
0xd152af coalesce_ssa_name()
../../gcc/tree-ssa-coalesce.c:1889
0xca3d03 remove_ssa_form
../../gcc/tree-outof-ssa.c:948
0xca3d03 rewrite_out_of_ssa(ssaexpand*)
../../gcc/tree-outof-ssa.c:1172
0x7bdf30 execute
../../gcc/cfgexpand.c:6164

[Bug c/79412] New: ICE in fold_convert_loc, at fold-const.c:2239

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 79412
   Summary: ICE in fold_convert_loc, at fold-const.c:2239
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code down to at least gcc 4.8 (configured with
--enable-checking=yes) on x86_64 GNU/Linux.
(official releases: confused by earlier errors, bailing out)


$ cat z1.c
int a;
void fn1 ()
{
  a++;
}
int a[] = {2};


$ gcc-7-20170205 -c z1.c
z1.c:6:5: error: conflicting types for 'a'
 int a[] = {2};
 ^
z1.c:1:5: note: previous declaration of 'a' was here
 int a;
 ^
z1.c: In function 'fn1':
z1.c:4:4: internal compiler error: in fold_convert_loc, at fold-const.c:2239
   a++;
   ~^~
0x90910f fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2238
0x97abe8 gimplify_self_mod_expr(tree_node**, gimple**, gimple**, bool,
tree_node*)
../../gcc/gimplify.c:2966
0x973f70 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11135
0x9773e6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0x9786cd gimplify_bind_expr
../../gcc/gimplify.c:1290
0x9745ba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:11402
0x9773e6 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6478
0x9793b9 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12396
0x979a54 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12554
0x7f17c7 cgraph_node::analyze()
../../gcc/cgraphunit.c:655
0x7f4ce3 analyze_functions
../../gcc/cgraphunit.c:1116
0x7f5a3a symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2597

[Bug c/79413] New: ICE in make_ssa_name_fn, at tree-ssanames.c:265

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 79413
   Summary: ICE in make_ssa_name_fn, at tree-ssanames.c:265
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Seen with test-version 7 at -Os, -O2 or higher :


$ cat z1.c
void fn1 ()
{
  typeof (int [1/0]) a;
}
void fn2 ()
{
  fn1();
}


$ gcc-6 -O2 -c z1.c
$ gcc-7-20170205 -O1 -c z1.c
$ gcc-7-20170205 -O2 -c z1.c
z1.c: In function 'fn2':
z1.c:7:3: internal compiler error: Segmentation fault
   fn1();
   ^
0xbf633f crash_signal
../../gcc/toplev.c:333
0xe150aa make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
../../gcc/tree-ssanames.c:265
0xc704d6 make_ssa_name
../../gcc/tree-ssanames.h:113
0xc704d6 remap_ssa_name
../../gcc/tree-inline.c:238
0xc76d1c copy_tree_body_r(tree_node**, int*, void*)
../../gcc/tree-inline.c:1081
0xec walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11796
0xec2676 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:12113
0xc6eba0 remap_type_1
../../gcc/tree-inline.c:565
0xc6fac1 remap_type(tree_node*, copy_body_data*)
../../gcc/tree-inline.c:593
0xc6e456 remap_decl(tree_node*, copy_body_data*)
../../gcc/tree-inline.c:370
0xc6fbfd remap_decls
../../gcc/tree-inline.c:642
0xc70e60 remap_block
../../gcc/tree-inline.c:700
0xc70fa1 remap_blocks
../../gcc/tree-inline.c:721
0xc79823 expand_call_inline
../../gcc/tree-inline.c:4617
0xc7b834 gimple_expand_calls_inline
../../gcc/tree-inline.c:4868
0xc7b834 optimize_inline_calls(tree_node*)
../../gcc/tree-inline.c:5008
0x1323321 early_inliner(function*)
../../gcc/ipa-inline.c:2721

[Bug bootstrap/42176] bootstrap fails while building libstdc++-v3 on debian sarge (related to cstdio and similar to #30915)

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Bug 30915 is similar, and the problem was related to gentoo-specific patches to
glibc. Possibly caused by A mismatched combination of libstdc++ and glibc.

I've never been able to reproduce it, and I don't think it's a GCC problem, so
I agree with closing this. Thanks, Martin.

[Bug c++/42000] missing -Wuninitialized warning on a user-defined class ctor

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
With the top of trunk (GCC 7) the test case in comment #0 isn't diagnosed with
-O2 or at any other optimization level.

I suspect this does fall under one of the existing -Wuninitialized bugs.  I'm
not sure bug 2972 covers this case.  Just quickly eyeballing the patch in bug
19808, I don't think it's meant to detect this problem either since it's
front-end only solution focused solely on dependencies between members in ctor
initializer lists.

I'll confirm this for now and if someone finds a pre-existing duplicate it can
be closed then.

[Bug c/79412] [5/6/7 Regression] ICE in fold_convert_loc, at fold-const.c:2239

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICE in fold_convert_loc, at |[5/6/7 Regression] ICE in
   |fold-const.c:2239   |fold_convert_loc, at
   ||fold-const.c:2239
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  GCC 4.7 doesn't ICE.

[Bug c/79412] [5/6/7 Regression] ICE in fold_convert_loc, at fold-const.c:2239

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Likely started with r193882.

[Bug rtl-optimization/79386] [7 Regression] ICE: segmentation fault in cprop w/ -O2 on 32-bit BE powerpc

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb  7 17:45:57 2017
New Revision: 245251

URL: https://gcc.gnu.org/viewcvs?rev=245251&root=gcc&view=rev
Log:
PR rtl-optimization/79386
* cprop.c (bypass_conditional_jumps): Initialize
bypass_last_basic_block already before splitting bbs after
unconditional traps...
(bypass_conditional_jumps): ... rather than here.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr79386.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cprop.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/68606] Reduce or disable the static emergency pool for C++ exceptions

[tss at iki dot fi]

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

Timo Sirainen  changed:

   What|Removed |Added

 CC||tss at iki dot fi

--- Comment #4 from Timo Sirainen  ---
I ran into this issue as well while looking at where all the memory is going
to. I've potentially tens of thousands of processes running, and 71 kB of
memory per process for something that almost never happens is too expensive. I
wouldn't mind std::bad_alloc just killing the process immediately if it
happens.

So at least having the LIBSTDCXX_EMERGENCY_EH_POOL_SIZE environment would be
helpful in future.

[Bug middle-end/79396] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O2

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
Created attachment 40689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40689&action=edit
preprocessed source

[Bug target/41880] CONSTANT_ADDRESS_P undefined.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||build
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Martin Sebor  ---
The top of trunk (GCC 7) builds successfully for rx-elf, and according to
comment #3, GCC 5 apparently does as well.  Resolving as fixed.

[Bug c/79413] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:265

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE in make_ssa_name_fn, at |[7 Regression] ICE in
   |tree-ssanames.c:265 |make_ssa_name_fn, at
   ||tree-ssanames.c:265
 Ever confirmed|0   |1

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

[Bug c/79411] [5/6/7 Regression] ICE: SSA corruption (fail_abnormal_edge_coalesce)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-02-07
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICE: SSA corruption |[5/6/7 Regression] ICE: SSA
   |(fail_abnormal_edge_coalesc |corruption
   |e)  |(fail_abnormal_edge_coalesc
   ||e)
 Ever confirmed|0   |1

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

[Bug c++/41847] warning: array subscript is above array bounds

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Martin Sebor  ---
With the top of trunk (GCC 7) the test case from attachment 18916 compiles
cleanly both with a s390x cross-compiler and natively on x86_64:

$ /build/s390x-linux/gcc-trunk/gcc/xgcc -B /build/s390x-linux/gcc-trunk/gcc -O2
-S -Wall -Wextra t.C
t.C: In instantiation of ‘void ImplHomMatrixTemplate<_RowSize>::ludcmp(short
unsigned int*) [with unsigned int _RowSize = 4]’:
t.C:89:21:   required from here
t.C:62:36: warning: unused parameter ‘nIndex’ [-Wunused-parameter]
  void ludcmp(unsigned short nIndex[])
^

Resolving as fixed.

[Bug tree-optimization/56456] [meta-bug] bogus warning when inlining or unrolling: "array subscript is above array bounds"

[msebor at gcc dot gnu.org]

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

Bug 41847 Summary: warning: array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41847

   What|Removed |Added

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

[Bug middle-end/41838] Incorrect "dereferencing pointer '' does break strict-aliasing rules"

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Martin Sebor  ---
The test case from attachment 18908 compiles with just a -Wunused-parameter
warning on trunk.  Resolving as fixed.

t.c: In function ‘Twine operator+(const Twine&, const Twine&)’:
t.c:16:63: warning: unused parameter ‘RHS’ [-Wunused-parameter]
  inline Twineoperator + (const Twine & LHS, const Twine & RHS) {
   ^~~

[Bug c++/79369] namespace definition with qualified id

[nathan at gcc dot gnu.org]

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

--- Comment #2 from Nathan Sidwell  ---
r245252 on c++-modules has a patch (for when stage 1 opens)

[Bug c++/79369] namespace definition with qualified id

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Tue Feb  7 18:02:05 2017
New Revision: 245252

URL: https://gcc.gnu.org/viewcvs?rev=245252&root=gcc&view=rev
Log:
PR c++/79369 inline namespaces
gcc/cp
* cp-tree.h (NAMESPACE_CHECK): New.
(NAMESPACE_INLINE_P): New.
* name-lookup.h (push_namespace): Return int.
* name-lookup.c (push_namespace): Return int. Adjust.
* parser.c (cp_parser_namespace_definition): Reorder nested
parsing.  Check inline redefinition.
gcc/testsuite/
* g++.dg/cpp0x/pr65558.C: Adjust error loc.
* g++.dg/cpp0x/pr79369.C: New.
* g++.dg/cpp1z/nested-namespace-def1.C: Adjust.

Added:
branches/c++-modules/gcc/testsuite/g++.dg/cpp0x/pr79369.C
Modified:
branches/c++-modules/ChangeLog.modules
branches/c++-modules/gcc/cp/cp-tree.h
branches/c++-modules/gcc/cp/name-lookup.c
branches/c++-modules/gcc/cp/name-lookup.h
branches/c++-modules/gcc/cp/parser.c
branches/c++-modules/gcc/testsuite/g++.dg/cpp0x/pr65558.C
branches/c++-modules/gcc/testsuite/g++.dg/cpp1z/nested-namespace-def1.C