[Bug fortran/47191] Misleading error message if part-ref starts with DATA

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P5
   Severity|normal  |enhancement

--- Comment #2 from Dominique d'Humieres  ---
Compiling the following code

module library
  implicit none
  type parameters
private
integer :: steps
   !real:: result
  end type parameters
contains
  subroutine set_parameters (datos, steps)
type (parameters):: datos
integer, intent (in) :: steps
datos % steps  = steps
datos % result = 0.0
  end subroutine set_parameters
end module library

gives the error

 datos % result = 0.0
  1

Error: 'result' at (1) is not a member of the 'parameters' structure

[Bug fortran/47040] Make error message for empty array constructor more helpful/correct

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P5
   Assignee|unassigned at gcc dot gnu.org  |dominiq at lps dot 
ens.fr
   Severity|normal  |enhancement

--- Comment #5 from Dominique d'Humieres  ---
> Do you want me to do it?

No feedback for more than two years. I am taking it.

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #4 from Joost VandeVondele  
---
(In reply to Dominique d'Humieres from comment #3)
> I am still not convinced. IMO enhancements have only two realistic status:
> WONTFIX or ASSIGNED.

not sure, project that do not engage with their community of users and
encourage feedback in various forms, including enhancement requests, might be
at risk. If only to keep track of these ideas/requests, they should be kept
'NEW'. 

In the original post I suggested that I already looked at the code, if anybody
posts suggests how to deal with the coding, I could look into this.

[Bug fortran/65751] Bogus &L in error message

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #8 from Dominique d'Humieres  ---
Test case committed to trunk and 5.2.1, closing as FIXED. Please file new PR(s)
for remaining issue(s).

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P5
   Severity|normal  |enhancement

--- Comment #3 from Dominique d'Humieres  ---
> In our code, we have about a 400 allocates that are checked for istat,
> and do nothing else than abort after signalling the size of the allocation.
> It is error prone (e.g. wrong sizes, missing check after istat, etc. etc.),
> and would like to get rid of this, as the compiler can do this much better.

I am still not convinced. IMO enhancements have only two realistic status:
WONTFIX or ASSIGNED.

[Bug rtl-optimization/68432] New: [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 68432
   Summary: [6 Regression] internal compiler error: in
expand_insn, at optabs.c:6947
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

Between r230516 and r230587, I run into an ICE, but it triggers only with
-fprofile-use  making it difficult to reduce. It always involves ANINT in the
error message:

/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/cell_types.F: In function ‘pbc1’:
/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/cell_types.F:424:0: internal
compiler error: in expand_insn, at optabs.c:6947
   r_pbc(1) = r(1) -
cell%hmat(1,1)*cell%perd(1)*ANINT(cell%h_inv(1,1)*r(1))


0x932745 expand_insn
../../gcc/gcc/optabs.c:6947
0x932745 expand_insn(insn_code, unsigned int, expand_operand*)
../../gcc/gcc/optabs.c:6943
0x809a43 expand_direct_optab_fn
../../gcc/gcc/internal-fn.c:2124
0x618bec expand_call_stmt
../../gcc/gcc/cfgexpand.c:2565
0x618bec expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3525
0x618bec expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3688
0x61a637 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5694
0x620671 execute
../../gcc/gcc/cfgexpand.c:6309
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [/tmp/ccTaPmg4.ltrans3.ltrans.o] Error 1

[Bug c/68431] New: Regression in GCC-6.0.0's optimizer

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

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

Bug ID: 68431
   Summary: Regression in GCC-6.0.0's optimizer
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

We compiled a program (A.c) by GCC-5.2.1 and GCC-6.0.0 with -O3 option.
GCC-5.2.1 performed better optimization than GCC-6.0.0.
Note that "unsigned int" is 32 bit and "long long int" is 64 bit.

(A.c)
unsigned int x = 1;
int main (void)
{
long long int a = -2LL;
int t = 1<=(a/x);
if (t != 0) { __builtin_abort(); }

return 0;
}

+---+--+
|   gcc-5.2.1s (gcc-5.2.1 A.c -O3 -S)   |  gcc-6.0.0.s (gcc-6.0.0 A.c -O3 -S) 
|
+---+--+
|main:  |main:
|
|.LFB0: |.LFB0:   
|
|.cfi_startproc |.cfi_startproc   
|
|   |movlx(%rip), %ecx
|
|   |movq$-2, %rax
|
|   |cqto 
|
|   |idivq   %rcx 
|
|   |testq   %rax, %rax   
|
|   |jg  .L7  
|
|xorl%eax, %eax |xorl%eax, %eax   
|
|ret|ret  
|
|   |.L7: 
|
|   |pushq   %rax 
|
|   |.cfi_def_cfa_offset 16   
|
|   |callabort
|
|.cfi_endproc   |.cfi_endproc 
|
|.LFE0: |.LFE0:   
|
|.size   main, .-main   |.size   main, .-main 
|
|.section.text.unlikely | 
|
|.LCOLDE0:  | 
|
|.section.text.startup  | 
|
|.LHOTE0:   | 
|
|.globl  x  |.globl  x
|
|.data  |.data
|
|.align 4   |.align 4 
|
|.size   x, 4   |.size   x, 4 
|
|x: |x:   
|
|.long   1  |.long   1
|
|.ident  "GCC: (Ubuntu 5.2.1 ...|.ident  "GCC: (GNU) 6.0.0 
...|
|.section.note.GNU-  ...|.section.note.GNU-
...|
+---+--+



$ gcc-6.0 -v
Using built-in specs.
COLLECT_GCC=gcc-6.0
COLLECT_LTO_WRAPPER=/home/iwatsuji/opt/gcc-6.0.0/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
configured with: ../gcc/configure --prefix=/home/iwatsuji/opt/gcc-6.0.0
--program-suffix=-6.0 --disable-multilib --enable-languages=c
Thread model: posix
gcc versin 6.0.0 20151119 (experimental) (GCC) 

$ gcc-5 -v
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.2.1-23ubuntu1~14.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=am

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #2 from Joost VandeVondele  
---
(In reply to Dominique d'Humieres from comment #1)
> > This would help users and/or developers to take the right actions.
> 
> Would this really help? I am not convinced. 
> 

In our code, we have about a 400 allocates that are checked for istat, and do
nothing else than abort after signalling the size of the allocation. It is
error prone (e.g. wrong sizes, missing check after istat, etc. etc.), and would
like to get rid of this, as the compiler can do this much better.

[Bug c++/68430] New: std::is_constructible::value == true for unconstructable type T

[ytj000 at gmail dot com]

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

Bug ID: 68430
   Summary: std::is_constructible::value == true for
unconstructable type T
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ytj000 at gmail dot com
  Target Milestone: ---

// The following code compiles in gcc (http://goo.gl/gFGc9K), but not clang
(http://goo.gl/woxdi1).
#include 
template struct Foo { Foo(T = nullptr) {} };
using U = std::is_constructible>;
bool b = U::value;  // If we remove this line, it compiles in both gcc and
clang. 
// The value of `b` is true in gcc, which is
counterintuitive since `Foo a;` results compile-error.
int main() {}

[Bug middle-end/68393] internal compiler error: in convert_move, at expr.c:286

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #4 from Bill Schmidt  ---
Could we have the patch upstream, please?  Except for a gap of about four
hours, bootstrap has been broken for powerpc64le since Friday.

[Bug c++/68295] internal compiler error / segmentation fault

[liupeifeng at live dot com]

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

--- Comment #6 from Peifeng Liu  ---
Just a clue: when processing float/double consts/variables in the source code
files, this issue is very likely to be reproduced.

[Bug c++/68295] internal compiler error / segmentation fault

[liupeifeng at live dot com]

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

Peifeng Liu  changed:

   What|Removed |Added

 CC||liupeifeng at live dot com

--- Comment #5 from Peifeng Liu  ---
(In reply to Thomas Maier-Komor from comment #1)
> The bug is reproduceable with gcc 5.2.0 on cygwin.

yes, I meet the issue as well. Does anybody have a fix?

[Bug c++/68429] New: [concepts] ICE in in placeholder_extract_concept_and_args, at cp/constraint.cc:1401

[ryan.burn at gmail dot com]

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

Bug ID: 68429
   Summary: [concepts] ICE in in
placeholder_extract_concept_and_args, at
cp/constraint.cc:1401
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The below code causes this ICE:

bug.cpp: In function ‘int main()’:
bug.cpp:19:8: internal compiler error: in placeholder_extract_concept_and_args,
at cp/constraint.cc:1401
   f(A());
^

0x83f181 placeholder_extract_concept_and_args(tree_node*, tree_node*&,
tree_node*&)
../../src/gcc/cp/constraint.cc:1399
0x83f6a1 hash_placeholder_constraint(tree_node*)
../../src/gcc/cp/constraint.cc:1472
0x65f310 auto_hash::hash(tree_node*)
../../src/gcc/cp/pt.c:23537
0x65f310 hash_table::find_slot(tree_node* const&,
insert_option)
../../src/gcc/hash-table.h:408
0x65f310 extract_autos_r
../../src/gcc/cp/pt.c:23571
0x664590 for_each_template_parm_r
../../src/gcc/cp/pt.c:8791
0xfa01f2 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 >*))
../../src/gcc/tree.c:11497
0x66409c for_each_template_parm
../../src/gcc/cp/pt.c:8889
0x6658c8 extract_autos
../../src/gcc/cp/pt.c:23599
0x6658c8 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context)
../../src/gcc/cp/pt.c:23690
0x840415 satisfy_argument_deduction_constraint
../../src/gcc/cp/constraint.cc:1903
0x840415 satisfy_constraint_1
../../src/gcc/cp/constraint.cc:2010
0x840493 satisfy_conjunction
../../src/gcc/cp/constraint.cc:1959
0x840493 satisfy_constraint_1
../../src/gcc/cp/constraint.cc:2019
0x83feed satisfy_parameterized_constraint
../../src/gcc/cp/constraint.cc:1941
0x83feed satisfy_constraint_1
../../src/gcc/cp/constraint.cc:2016
0x840886 satisfy_constraint
../../src/gcc/cp/constraint.cc:2049
0x8409ea constraints_satisfied_p(tree_node*)
../../src/gcc/cp/constraint.cc:2156
0x60865d add_function_candidate
../../src/gcc/cp/call.c:1994
0x609811 add_template_candidate_real
../../src/gcc/cp/call.c:3118
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



//
template 
concept bool C1() {
  return true;
}

template 
concept bool C2() {
  return requires(Expr expr, decltype(expr.identity) x) {
{ expr }
->C1;
  };
}

void f(C2) {}

struct A {};

int main() {
  f(A());
}
//

[Bug c/68425] Enhanced error message when an array is initialized with too many elements

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-19
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to Morwenn from comment #0)

It does say "[2]", no? It could say "too many initializers (3) for 'const int
[2]'"

> I guess that it is rather cheap to implement and can help to diagnose the
> actual problem faster.

If you guess that, you should really give it a try :)

Just launch cc1 under gdb, break at the line that prints that message and
figure out how to find out the number of initializers. Then follow:

https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

[Bug web/50642] onlinedocs formated text too small to read

[manu at gcc dot gnu.org]

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

--- Comment #14 from Manuel López-Ibáñez  ---
(In reply to Jon Grant from comment #13)
> Hello
> Could this be committed to the trunk please?

Not everybody reads all messages in bugzilla. Patches go to gcc-patches. See
comment #8. CC Gerald (see MAINTAINERS for email address).

[Bug tree-optimization/68428] New: [6 Regression] [graphite] ICE in outermost_loop_in_sese w/ -O2 -floop-strip-mine or -O2 -floop-nest-optimize

[asolokha at gmx dot com]

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

Bug ID: 68428
   Summary: [6 Regression] [graphite] ICE in
outermost_loop_in_sese w/ -O2 -floop-strip-mine or -O2
-floop-nest-optimize
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

At least gcc-6.0.0-alpha20151108 and gcc-6.0.0-alpha20151115 ICE when compiling
the following reduced case:

int au[4] = { 0 };

int
main(void)
{
  int dc;
  int m7;
  int lv;
  int f2;
  int uq[3] = { 1 };
  for (dc = 0; dc < 2; ++dc) {
for (lv = 0; lv < 2; ++lv)
  for (m7 = 0; m7 < 3; ++m7) {
if (uq[dc] == 0)
  continue;
for (f2 = 0; f2 < 3; ++f2)
  au[dc+2] = uq[f2];
  }
  }
  return 0;
}

% gcc-6.0.0-alpha20151115 -O2 -floop-strip-mine y7cav5se.c 
y7cav5se.c: In function 'main':
y7cav5se.c:4:1: internal compiler error: in outermost_loop_in_sese, at
sese.c:1892
 main(void)
 ^~~~

I cannot reproduce it w/ gcc-6.0.0-alpha20150802, though.

[Bug c++/68427] New: GCC (G++) flunks legal ANSI-C code

[wam at hiwaay dot net]

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

Bug ID: 68427
   Summary: GCC (G++) flunks legal ANSI-C code
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wam at hiwaay dot net
  Target Milestone: ---
  Host: FreeBSD 9.3R AMD64
Target: FreeBSD 9.3R AMD64

Created attachment 36768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36768&action=edit
Tar file of code to reproduce bug & logs of my 2 attempts to compile 

I try to compile some code containing unit testing coding which references
routines declared in included headers, compiler balks, says routine is not
declared in this scope. Code compiles under Intel icc every night for the last
couple of years. I tried GCC 5.2.1 1st, then GCC 4.8.5, both failed to compile
the (I say ANSI-C) legal code snippet, cut down from original file I tried.

[wam@kabini1, ~, 7:18:14pm] 787 % uname -a
FreeBSD kabini1.local 9.3-RELEASE-p24 FreeBSD 9.3-RELEASE-p24 #0: Sat Aug 22
01:54:44 UTC 2015
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
[wam@kabini1, ~, 7:19:49pm] 788 %

[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX

[pageexec at gmail dot com]

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

--- Comment #2 from PaX Team  ---
do you have a few examples of expected input/output path pairs perhaps?

[Bug fortran/68401] improve 'Allocation would exceed memory limit'

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> This would help users and/or developers to take the right actions.

Would this really help? I am not convinced. 

If there are only a few ALLOCATE, it would be quite easy to spot the biggest
one. If there are a large number of them, mixing big and small sizes, would
'Allocation of 10 bytes would exceed memory limit' be really helpful?

[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
I am traveling now so I cannot double check your hint.
What do you suggest?

[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||talebi.hossein at gmail dot com

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

[Bug fortran/68415] Internal compiler error on Class variable containing array of allocatable polymorphic variable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Duplicate of pr61819 fixed on trunk at revision r229303 and for 5.3 at r229777.

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

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
Should be fixed on the trunk now.  I went from some absurd time down to less
than a second for the critical code in 453.povray.

[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Thu Nov 19 00:33:27 2015
New Revision: 230586

URL: https://gcc.gnu.org/viewcvs?rev=230586&root=gcc&view=rev
Log:
[PATCH][PR tree-optimization/68198] Avoid CFG explosion due to threading

PR tree-optimization/68198
* tree-ssa-threadupdate.c (valid_jump_thread_path): Distinguish
between threading a multi-way branch and a thread path that contains
a multi-way branch.  Disallow the case where a path contains a
multi-way branch and does not thread a multi-way branch.
(thread_through_all_blocks): Update comment.

PR tree-optimization/68198
* gcc.dg/tree-ssa/pr66752-3.c: Update expected output for VRP1.
* gcc.dg/tree-ssa/pr68198.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68198.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr66752-3.c
trunk/gcc/tree-ssa-threadupdate.c

[Bug fortran/68426] Simplification of SPREAD with a derived type element causes ICE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The second PARAMETER is not needed: compiling the following code

  module m
implicit none
type t
  integer :: i
end type t
type(t), dimension(2), parameter :: a1  = (/ t(1), t(2) /)
type(t), dimension(1) :: c = spread ( a1(1), 1, 1 )
  end module m

gives the same ICE

f951: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:5704

[Bug fortran/68426] New: Simplification of SPREAD with a derived type element causes ICE

[kargl at gcc dot gnu.org]

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

Bug ID: 68426
   Summary: Simplification of SPREAD with a derived type element
causes ICE
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

In fixing PR 59910, I mentioned that the patch may not
fix a potential problem with similar code in a PARAMETER.
Dominiq posted


  module m
implicit none
type t
  integer :: i
end type t
type(t), dimension(2), parameter :: a1  = (/ t(1), t(2) /)
type(t), dimension(1), parameter :: c = spread ( a1(1), 1, 1 )
  end module m

which indeed leads to an ICE   

f951: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:5704

The problem is that gfc_simplify_spread bails out because
soource->expr_type == EXPR_STRUCTURE and SPREAD is not
simplified.  This then generates a function and
gfc_conv_array_initializer gets expr->expt_type==EXPR_FUNCTION
which she can't deal with.

The fix lies in gfc_simplify_spread.

[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from kargl at gcc dot gnu.org ---
A patch to fix the problem exposed by code in comment #1
has been committed to trunk.  Same patch does not fix
5-branch.  Closing as fixed.

[Bug fortran/43996] ICE in gfc_conv_array_initializer due to incomplete simplification of init expressions

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #22 from kargl at gcc dot gnu.org ---
Don't know why the simple patch committed to trunk
causes a regression of the branch.  Don't care.
Closing as fixed.

[Bug fortran/43996] ICE in gfc_conv_array_initializer due to incomplete simplification of init expressions

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-18
   Assignee|ebotcazou at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Severity|normal  |minor

--- Comment #1 from Eric Botcazou  ---
$target_alias needs to be stripped from the executable name though.  I guess
it's just a matter of writing the proper regex for sed, but no plan to work on
it in the foreseeable future as far as I'm concerned.

[Bug fortran/43996] ICE in gfc_conv_array_initializer due to incomplete simplification of init expressions

[kargl at gcc dot gnu.org]

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

--- Comment #21 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #20)
> Author: kargl
> Date: Wed Nov 18 22:58:47 2015
> New Revision: 230581
> 
> URL: https://gcc.gnu.org/viewcvs?rev=230581&root=gcc&view=rev
> Log:
> 2015-11-18  Steven G. Kargl  
> 
>   PR fortran/43996
>   * simplify.c (gfc_simplify_spread): Issue error for too large array 
>   constructor in a PARAMETER statement.
> 
> 2015-11-18  Steven G. Kargl  
> 
>   PR fortran/43996
>   * gfortran.dg/pr43996.f90: New test.
> 
> Added:
> branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr43996.f90
> Modified:
> branches/gcc-5-branch/gcc/fortran/ChangeLog
> branches/gcc-5-branch/gcc/fortran/simplify.c
> branches/gcc-5-branch/gcc/testsuite/ChangeLog

I have reverted this commit due to a regression in the 5-branch.

[Bug target/68424] static_cast(0.29 * 100) == "28"

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #3 from Andreas Schwab  ---
None of the fractional numbers are exactly representable, and different
rounding (conversion to int rounds to zero, formatting floating point numbers
round to nearest) produce different restults.

[Bug c/16351] NULL dereference warnings

[jg at jguk dot org]

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

--- Comment #45 from Jon Grant  ---
(In reply to Manuel López-Ibáñez from comment #39)
> (In reply to David Binderman from comment #38)
> > It could even be the case that the "potential NULL" code gets
> > put into some backwater flag away from -Wall, and, after a suitable period
> > of more testing, the "definately NULL" code gets to go into
> > prime time of -Wall. 
> 
> We could split the flag into -Wnull-dereference and -Wmaybe-null-dereference.

Sounds good. I'm keen to see it in :)

[Bug web/50642] onlinedocs formated text too small to read

[jg at jguk dot org]

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

--- Comment #13 from Jon Grant  ---
Hello
Could this be committed to the trunk please?

[Bug plugins/41757] Add PLUGIN_FINISH_DECL

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #7 from Jeffrey A. Law  ---
Fixed for 4.7.  There are no plans to backport the change to older compilers.

[Bug fortran/43996] ICE in gfc_conv_array_initializer due to incomplete simplification of init expressions

[kargl at gcc dot gnu.org]

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

--- Comment #20 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Nov 18 22:58:47 2015
New Revision: 230581

URL: https://gcc.gnu.org/viewcvs?rev=230581&root=gcc&view=rev
Log:
2015-11-18  Steven G. Kargl  

PR fortran/43996
* simplify.c (gfc_simplify_spread): Issue error for too large array 
constructor in a PARAMETER statement.

2015-11-18  Steven G. Kargl  

PR fortran/43996
* gfortran.dg/pr43996.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr43996.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/simplify.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/68408] broken support for attribute init_priority

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target||sparc-elf
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-18
 CC||ebotcazou at gcc dot gnu.org
Summary|sparc-elf, c++: broken  |broken support for
   |support for attribute   |attribute init_priority
   |init_priority.  |
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Probably in the entire 4.x series.

[Bug target/68408] broken support for attribute init_priority

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Investigating.

[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Nov 18 22:55:17 2015
New Revision: 230580

URL: https://gcc.gnu.org/viewcvs?rev=230580&root=gcc&view=rev
Log:
2015-11-18  Steven G. Kargl  

PR fortran/59910
* primary.c (gfc_match_structure_constructor): Reduce a structure
constructor in a DATA statement.

2015-11-18  Steven G. Kargl  

PR fortran/59910
* gfortran.dg/pr59910.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr59910.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/43996] ICE in gfc_conv_array_initializer due to incomplete simplification of init expressions

[kargl at gcc dot gnu.org]

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

--- Comment #19 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Nov 18 22:51:39 2015
New Revision: 230579

URL: https://gcc.gnu.org/viewcvs?rev=230579&root=gcc&view=rev
Log:
2015-11-18  Steven G. Kargl  

PR fortran/43996
* simplify.c (gfc_simplify_spread): Issue error for too large array 
constructor in a PARAMETER statement.

2015-11-18  Steven G. Kargl  

PR fortran/43996
* gfortran.dg/pr43996.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr43996.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug target/68424] static_cast(0.29 * 100) == "28"

[alex.piliev at gmail dot com]

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

--- Comment #2 from Alex Piliev  ---
#include 

int main(int argc, char* argv[]) {

std::cout << static_cast(0.28 * 100) << std::endl;
std::cout << 0.29 * 100 << std::endl;
std::cout << static_cast(0.29 * 100) << std::endl;
std::cout << static_cast(0.30 * 100) << std::endl;

  return 0;
}


g++ -std=c++11 -o test29 test29.cpp

[Bug target/68424] static_cast(0.29 * 100) == "28"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |target

--- Comment #1 from Andrew Pinski  ---
What is the exact options are you using?  Can you provide the exact source you
are using also?

[Bug target/68421] unused copy of global register variable into another gpr

[bergner at gcc dot gnu.org]

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

--- Comment #1 from Peter Bergner  ---
This seems somewhat related to PR24644 which was "fixed".  That bug showed we
do not want to copy global registers to other "tmp" registers and use them from
the "tmp" reg.  In this case, at least we're still using the global register,
but it would be interesting to know how is creating those copies.

Aaron, can you look thru the dump files to see where these are being generated?

[Bug c/65083] Can not indirectly call some C11 atomic library functions

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #4 from Joseph S. Myers  ---
Fixed for GCC 6.

[Bug c/65083] Can not indirectly call some C11 atomic library functions

[jsm28 at gcc dot gnu.org]

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

--- Comment #3 from Joseph S. Myers  ---
Author: jsm28
Date: Wed Nov 18 22:13:44 2015
New Revision: 230578

URL: https://gcc.gnu.org/viewcvs?rev=230578&root=gcc&view=rev
Log:
Add out-of-line versions of some  functions (PR c/65083).

PR c/65083 notes that some functions in  are normal
functions, not generic functions, and so need to have out-of-line
copies that can be called when macro expansion is suppressed (unlike
the generic functions where DR#419 makes it undefined if you suppress
a macro expansion).

This patch adds such out-of-line definitions in libatomic for those
six functions, at a new LIBATOMIC_1.2 symbol version, as trivial
wrappers to the  macros, along with declarations of those
functions in .  Tests are added that are based on the
corresponding tests for the macros, but with parentheses around the
function names to force the out-of-line functions to be used.

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

gcc:
* ginclude/stdatomic.h (atomic_thread_fence, atomic_signal_fence)
(atomic_flag_test_and_set, atomic_flag_test_and_set_explicit)
(atomic_flag_clear, atomic_flag_clear_explicit): Declare as
functions before defining as macros.

gcc/testsuite:
* gcc.dg/atomic/stdatomic-fence-2.c,
gcc.dg/atomic/stdatomic-flag-2.c: New tests.

libatomic:
* fence.c, flag.c: New files.
* Makefile.am (libatomic_la_SOURCES): Add fence.c and flag.c.
* Makefile.in: Regenerate.
* configure.ac (libtool_VERSION): Change to 3:0:2.
* configure: Regenerate.
* libatomic.map (LIBATOMIC_1.2): New symbol version.

Added:
trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-fence-2.c
trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-flag-2.c
trunk/libatomic/fence.c
trunk/libatomic/flag.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ginclude/stdatomic.h
trunk/gcc/testsuite/ChangeLog
trunk/libatomic/ChangeLog
trunk/libatomic/Makefile.am
trunk/libatomic/Makefile.in
trunk/libatomic/configure
trunk/libatomic/configure.ac
trunk/libatomic/libatomic.map

[Bug c/68425] New: Enhanced error message when an array is initialized with too many elements

[morwenn29 at hotmail dot fr]

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

Bug ID: 68425
   Summary: Enhanced error message when an array is initialized
with too many elements
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: morwenn29 at hotmail dot fr
  Target Milestone: ---

The current error message when trying to initialize a fixed-size C array with
too many elements (with both gcc and g++):

error: too many initializers for 'const int [2]'
const int array[2] = { 1, 2, 3 };

When there are many elements, it is sometimes interesting to know whether we
initialized the array with too many or not enough elements. I would expect such
a message instead:

error: too many initializers for 'const int [2]' (3 elements, expected 2)
const int array[2] = { 1, 2, 3 };

I guess that it is rather cheap to implement and can help to diagnose the
actual problem faster.

[Bug c++/68424] New: static_cast(0.29 * 100) == "28"

[alex.piliev at gmail dot com]

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

Bug ID: 68424
   Summary: static_cast(0.29 * 100) == "28"
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alex.piliev at gmail dot com
  Target Milestone: ---

On my system (Debian 8 Jessie x64) with g++ (Debian 4.9.2-10) this code:

std::cout << static_cast(0.28 * 100) << std::endl;
std::cout << 0.29 * 100 << std::endl;
std::cout << static_cast(0.29 * 100) << std::endl;
std::cout << static_cast(0.30 * 100) << std::endl;

produces the following output:
28
29
28
30

[Bug other/67868] ICE in handling VTV sections for targets with section anchors.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #9 from Ramana Radhakrishnan  ---
The ICEs are fixed on arm and aarch64 when turning on vtv. I haven't done the
work to verify this on powerpc but I expect the problem to be fixed there too
as the bug really was in varasm.c

[Bug libgomp/68403] FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/loop-auto-1.c (internal compiler error)

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org,
   ||seurer at linux dot 
vnet.ibm.com,
   ||wschmidt at gcc dot gnu.org

--- Comment #6 from Bill Schmidt  ---
Also fails on powerpc64le-linux-gnu.

[Bug middle-end/68221] libgomp reduction-11/12 failures

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org,
   ||seurer at linux dot 
vnet.ibm.com,
   ||wschmidt at gcc dot gnu.org

--- Comment #3 from Bill Schmidt  ---
Just FYI, we are getting XPASSes on these for powerpc64le-linux-gnu.

[Bug c++/68423] override/final doesn't cause error in templated class without base

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
You get an error as soon as you instantiate the templates. I don't know if the
standard requires an error even for uninstantiated templates, but there are
LOTS of things g++ doesn't diagnose in uninstantiated templates.

[Bug target/64835] -fno-ipa-cp is inconsitently supported when attributes optimize or target are used

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org,
   ||seurer at linux dot 
vnet.ibm.com,
   ||wschmidt at gcc dot gnu.org

--- Comment #9 from Bill Schmidt  ---
Also fails on powerpc64le-linux-gnu.

[Bug c++/68423] New: override/final doesn't cause error in templated class without base

[rhainin1 at binghamton dot edu]

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

Bug ID: 68423
   Summary: override/final doesn't cause error in templated class
without base
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rhainin1 at binghamton dot edu
  Target Milestone: ---

The following does not produce a compile time error, though it should because
Cls doesn't ever have a base class.

template 
struct Cls {
  void fun() override { }
};

nor does:

template 
struct Cls {
  void fun() final { }
};

[Bug rtl-optimization/66669] FAIL: gcc.dg/loop-8.c

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org,
   ||seurer at linux dot 
vnet.ibm.com,
   ||wschmidt at gcc dot gnu.org

--- Comment #1 from Bill Schmidt  ---
Fails also on powerpc64le-linux-gnu.  We only see this FAIL:

FAIL: gcc.dg/loop-8.c scan-rtl-dump-times loop2_invariant "Decided" 1

[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
I've opened PR 68422 for the sizeof... inefficiency.

[Bug c++/68422] compile-time cost of sizeof... is quadratic

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|compile-time cost of|compile-time cost of
   |sizeof... is exponential|sizeof... is quadratic

--- Comment #1 from Jonathan Wakely  ---
Oops, I meant to change the title - it seems to be quadratic

[Bug target/68421] New: unused copy of global register variable into another gpr

[acsawdey at gcc dot gnu.org]

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

Bug ID: 68421
   Summary: unused copy of global register variable into another
gpr
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
CC: bergner at gcc dot gnu.org
  Target Milestone: ---
Target: ppc64le

Created attachment 36767
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36767&action=edit
test case for unused registers

There are unneeded moves from the global register variables to other registers
generated.

register zend_execute_data *execute_data __asm__("r28");
register const zend_op *opline __asm__("r29");
int ZEND_IS_SMALLER_SPEC_CV_CV_HANDLER(void)
{
 zval *op1, *op2, *result;
 op1 = _get_zval_ptr_cv_undef(execute_data, opline->op1.var);
 if (__builtin_expect(!!(zval_get_type(&(*(op1))) == 4), 1)) {
  if (__builtin_expect(!!(zval_get_type(&(*(op2))) == 4), 1)) {
   do { (*(((zval*)(((char*)(execute_data)) +
((int)(opline->result.var)).u1.type_info = ((*(op1)).value.lval <
(*(op2)).value.lval) ? 3 : 2; } while (0);
  }
 }
 ((execute_data)->opline) = opline;
}

generates:

ZEND_IS_SMALLER_SPEC_CV_CV_HANDLER:
lwa 6,0(29)
mr 8,29
mr 10,28
add 9,28,6
lbz 9,8(9)
cmpwi 7,9,4
bne 7,.L3
li 7,0
lbz 9,8(7)
cmpwi 7,9,4
bne 7,.L3
ldx 9,28,6
ld 6,0(7)
lwa 7,4(29)
cmpd 7,9,6
add 7,28,7
mfcr 9,1
rlwinm 9,9,29,1
addi 9,9,2
stw 9,8(7)
.L3:
std 8,0(10)

Registers 8 and 10 are never used, 28 and 29 are used directly.

Generated by trunk 230468 on ppc64le with:

gcc -O3 -S min_unused_regs10.c

[Bug c++/68422] New: compile-time cost of sizeof... is exponential

[redi at gcc dot gnu.org]

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

Bug ID: 68422
   Summary: compile-time cost of sizeof... is exponential
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

using size_t = decltype(sizeof(0));

template struct Index_tuple { };

template struct Itup_cat;

template
  struct Itup_cat, Index_tuple, ITup1Len>
  {
#ifdef NO_SIZEOF
using type = Index_tuple;
#else
using type = Index_tuple;
#endif
  };

template
  struct Build_index_tuple
  : Itup_cat::type,
  typename Build_index_tuple::type, Num / 2>
  { };

// Specializations to terminate Build_index_tuple recursion:

template<>
  struct Build_index_tuple<1> { typedef Index_tuple<0> type; };

template<>
  struct Build_index_tuple<0> { typedef Index_tuple<> type; };

// And actually use it:
Build_index_tuple<5000> x;


With recent trunk:

$ g++11 intseq.cc -c -ftime-report 

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 1%) wall 
  1396 kB ( 1%) ggc
 phase parsing   :   1.24 (98%) usr   0.04 (100%) sys   1.27 (98%) wall
 112465 kB (99%) ggc
 phase lang. deferred:   0.02 ( 2%) usr   0.00 ( 0%) sys   0.02 ( 2%) wall 
 0 kB ( 0%) ggc
 |overload resolution:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 2%) wall 
   328 kB ( 0%) ggc
 garbage collection  :   0.02 ( 2%) usr   0.00 ( 0%) sys   0.02 ( 2%) wall 
 0 kB ( 0%) ggc
 template instantiation  :   1.24 (98%) usr   0.04 (100%) sys   1.27 (98%) wall
 111544 kB (98%) ggc
 TOTAL :   1.26 0.04 1.30
113894 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.

But when NO_SIZEOF is defined it is an order of magnitude better:

$ g++11 intseq.cc -c -ftime-report -DNO_SIZEOF

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
  1396 kB (22%) ggc
 phase parsing   :   0.09 (100%) usr   0.01 (100%) sys   0.10 (91%)
wall4974 kB (78%) ggc
 phase lang. deferred:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 9%) wall 
 0 kB ( 0%) ggc
 |overload resolution:   0.00 ( 0%) usr   0.01 (100%) sys   0.03 (27%) wall
424 kB ( 7%) ggc
 garbage collection  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 9%) wall 
 0 kB ( 0%) ggc
 template instantiation  :   0.09 (100%) usr   0.01 (100%) sys   0.10 (91%)
wall4053 kB (63%) ggc
 TOTAL :   0.09 0.01 0.11  
6404 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.


Changing the sequence length from 5000 to 5 increases memory use for the
NO_SIZEOF case roughly linearly:

 TOTAL :   0.84 0.04 0.90 
38420 kB


But when using sizeof... it uses two orders of magnitude more time and memory:

 TOTAL : 116.79 2.15   119.13   
8584131 kB

[Bug testsuite/68232] gcc.dg/ifcvt-4.c fails on some arm configurations

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #2 from Bill Schmidt  ---
Fails also on powerpc64le-linux-gnu, with the same symptoms.

[Bug lto/67548] [5/6 Regression] LTO drops weak binding with "ld -r"

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #9 from Jan Hubicka  ---
Aha, missed HJ's comment. If we have the info on type of file, this ought to be
relatively easy to fix.  I will look into it.

[Bug go/68420] Errors with go escape analysis

[boger at us dot ibm.com]

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

boger at us dot ibm.com changed:

   What|Removed |Added

 Target||ppc64le, x86_64

--- Comment #1 from boger at us dot ibm.com ---
Fails on ppc64le and x86_64.

[Bug lto/67548] [5/6 Regression] LTO drops weak binding with "ld -r"

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #8 from Jan Hubicka  ---
There are two incremental link implementations:

 1) HJ's binutils will concat the sections, 
 2) mainline binutils will invoke GCC via plugin and produce .o file with final
assembly.
The correct implementation IMO is 
 3) invoke GCC via plugin and produce the merge LTO file (i.e. cut the process
before WPA optimization starts and stream out everything again).

3) would be only way to also support fat LTO files.  Sadly we do not have
plugin API interface for 2) or 3).  2) would be relatively easy - we only need
to make GCC know it does incremental linking and assume that every symbol can
be bound externally.  I did not find way how to get this situation detected
from the plugin/wrapper though and I am not sure how useful it is in practice
given that it won't give you whole program optimization.

[Bug go/68420] New: Errors with go escape analysis

[boger at us dot ibm.com]

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

Bug ID: 68420
   Summary: Errors with go escape analysis
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: boger at us dot ibm.com
CC: cmang at google dot com
  Target Milestone: ---

Escape analysis for Go was added to gcc trunk, but there are errors when using
it.  It is not enabled by default, but requires the option -fgo-optimize-allocs
to enable it.

Details on the problem are documented in the golang issue tracker
https://github.com/golang/go/issues/12965.

I was asked to open this as a bugzilla in addition to the Go issue for gcc
tracking purposes.

[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #7)
> The version I came up with is very close to Xeo's at stackoverflow. I tried
> something more like yours and it used a LOT more memory.
> 
> Here's what I tested:
> 
> #include 
> 
> namespace std
> {
>   template struct _Index_tuple { };
> 
> #if DUP
>   template struct _Itup_dup;
> 
>   template
> struct _Itup_dup<_Index_tuple<_Ind...>, 0>
> {
>   static constexpr size_t _Nm = sizeof...(_Ind);
>   using __type = _Index_tuple<_Ind..., _Nm + _Ind...>;
> };

It turns out that the huge cost of this version is not due to sizeof... it's
due to the static variable, _Nm

Avoiding sizeof... helps too, but not as much as eliminating the variable and
writing it as:

  using __type = _Index_tuple<_Ind..., sizeof...(_Ind) + _Ind...>;

[Bug tree-optimization/65424] gcc does not recognize byte swaps implemented as loop.

[fuz at fuz dot su]

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

--- Comment #4 from Robert Clausecker  ---
Sorry, comment was posted to the wrong bug. I have trouble using your
bug reporting software, the “automatically go to next bug after making
a change” behaviour is weird and unintuitive.

[Bug rtl-optimization/68173] gcc takes a long time and a lot of memory with -O0 on source file with very large expression

[fuz at fuz dot su]

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

--- Comment #8 from Robert Clausecker  ---
I checked this again on a computer with more RAM and compilation does indeed
terminate
after 23 minutes. On the original machine, the compiler most likely swapped a
lot contrary
to my original report in which I didn't let the compiler run long enough to
start swapping.

Can someone mark this as CONFIRMED?

[Bug tree-optimization/65424] gcc does not recognize byte swaps implemented as loop.

[fuz at fuz dot su]

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

--- Comment #3 from Robert Clausecker  ---
I checked this again on a computer with more RAM and compilation does indeed
terminate
after 23 minutes. On the original machine, the compiler most likely swapped a
lot contrary
to my original report in which I didn't let the compiler run long enough to
start swapping.

Can someone mark this as CONFIRMED?

[Bug libstdc++/66059] make_integer_sequence should use a log(N) implementation

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Adrian Wielgosik from comment #9)
>  TOTAL :   0.97 0.01 0.99   
> 119627 kB

By passing in the length of the first sequence instead of using sizeof... the
std::make_integer_sequence result comes down to:

 TOTAL :   0.23 0.01 0.25 
15114 kB

Which is very reasonable, and within an order of magnitude of Daniel's, which I
think is good enough (especially if we're going to get a compiler intrinsic
eventually anyway).

But rather than making that change I think the right thing to do is to fix the
front-end so that sizeof... doesn't make such a big difference and we don't
have to jump through hoops to avoid it. I'll file a PR for that tomorrow.

[Bug target/68410] config/nios2/nios2.c: 4123: duplicates in expression

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from sandra at gcc dot gnu.org ---
Fixed now.

[Bug target/68410] config/nios2/nios2.c: 4123: duplicates in expression

[sandra at gcc dot gnu.org]

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

--- Comment #3 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Wed Nov 18 19:45:47 2015
New Revision: 230563

URL: https://gcc.gnu.org/viewcvs?rev=230563&root=gcc&view=rev
Log:
2015-11-18  Sandra Loosemore  

PR target/68410
* config/nios2/nios2.c (cdx_and_immed): Remove duplicate tests
from || expression.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nios2/nios2.c

[Bug rtl-optimization/68173] gcc does not terminate with -O0 on source file with a very large expression

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
GCC on trunk is 50 times slower than LLVM-3.7 in -O0 mode on this test.  In -O2
mode GCC is only 20% slower than LLVM-3.7 in the same mode and faster than
LLVM-3.7 with -O0.

About 80% of compile time GCC spent in RA, more accurately in bitmap code used
by LRA (actually bitmap code takes even more if we take their usage from other
passes).

Conversion bitmaps to sparsets where memory requirements permit did not help at
all.  After analyzing RA dumps (working with 8GB dump files in emacs even on
machine with 128GB memory is not fun as it reacts to any key press with big
delays), I believe the problem is not in RA but somewhere before as we have
*5M* allocnos and *10M* program points in -O0 mode and only *6K* allocnos and
*20K* program points in -O2 mode.  Even if I make RA instant, GCC will be still
10 times slower in -O0 mode than LLVM.  I guess solution for the PR would be
switching on some optimizations in -O0 mode which can help decreasing number of
pseudos but I am not sure it is a right thing to do in general.

[Bug c++/68348] [6 regression] ICE: segfault in cxx_eval_constant_expression at cp/constexpr.c:3172

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
A bit shorter:

struct C {
  constexpr C() : w(), x(), y() {}
  constexpr double fn() const noexcept;
  double w;
  double x;
  double y;
};
constexpr double C::fn() const noexcept { return w; }
C foo()
{
  C c;
  c.fn ();
  return c;
}

[Bug tree-optimization/68341] [6 Regression] FAIL: gcc.dg/graphite/interchange-{1,11,13}.c (internal compiler error)

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #2 from sandra at gcc dot gnu.org ---
I'm also seeing these failures on nios2-elf.

[Bug tree-optimization/68398] coremark regression due to r229685

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #1 from Jeffrey A. Law  ---
Sebastian,

That change was to avoid creating irreducible loops, which should be considered
a design requirement for the threader.  We've been willing to relax that
requirement in cases where we're able to collapse a multi-way branch.

So I think the thing to do is first verify whether or not the threading
opportunity we suppress would result in a multi-way branch being removed.  If
it doesn't, then we'll have to look and see if there's another relaxation we
can reasonably do.

The other possibility is cases where applying multiple jump threads results in
a reducible loop, but applying a subset results in an irreducible loop.  I know
of at least one case of that occurring (it's in the testsuite).  We haven't
tried to handle those situations to the best of my knowledge.

[Bug ipa/68419] ICE segfault in determine_locally_known_aggregate_parts / ipa_compute_jump_functions_for_edge

[cand at gmx dot com]

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

--- Comment #1 from Lauri Kasanen  ---
This is very similar to 64551, but not a dup. Another part of IPA failing.

[Bug ipa/68419] New: ICE segfault in determine_locally_known_aggregate_parts / ipa_compute_jump_functions_for_edge

[cand at gmx dot com]

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

Bug ID: 68419
   Summary: ICE segfault in
determine_locally_known_aggregate_parts /
ipa_compute_jump_functions_for_edge
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cand at gmx dot com
  Target Milestone: ---

Created attachment 36766
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36766&action=edit
Preprocessed source

Trying to build GCC 5.2 for m68k segfaults in bootstrap. Preprocessed source
attached.

Configure line:
../gcc-5.2.0/configure --prefix=/tmp/tmpgcc --target=m68k-elf
--enable-languages=c --disable-libssp --disable-tls --enable-threads=single

../../../../gcc-5.2.0/libgcc/unwind-dw2.c: In function 'uw_init_context_1':
../../../../gcc-5.2.0/libgcc/unwind-dw2.c:1695:0: internal compiler error:
Segmentation fault

Valgrind output:
==27154==
==27155== Memcheck, a memory error detector
==27155== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==27155== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==27155== Command: /tmp/gccbuild/./gcc/cc1 -quiet -I . -I . -I ../../.././gcc
-I ../../../../gcc-5.2.0/libgcc -I ../../../../gcc-5.2.0/libgcc/. -I
../../../../gcc-5.2.0/libgcc/../gcc -I ../../../../gcc-5.2.0/libgcc/../include
-imultilib m68000 -iprefix /tmp/gccbuild/gcc/../lib/gcc/m68k-elf/5.2.0/
-isystem /tmp/gccbuild/./gcc/include -isystem /tmp/gccbuild/./gcc/include-fixed
-MD unwind-dw2.d -MF unwind-dw2.dep -MP -MT unwind-dw2.o -D IN_GCC -D
CROSS_DIRECTORY_STRUCTURE -D IN_LIBGCC2 -D inhibit_libc -D HIDE_EXPORTS
-isystem /tmp/tmpgcc/m68k-elf/include -isystem /tmp/tmpgcc/m68k-elf/sys-include
-isystem ./include ../../../../gcc-5.2.0/libgcc/unwind-dw2.c -quiet -dumpbase
unwind-dw2.c -mcpu=68000 -auxbase-strip unwind-dw2.o -g -g -g -O2 -O2 -O2
-Wextra -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -fbuilding-libgcc
-fno-stack-protector -fexceptions -fvisibility=hidden -o /tmp/ccQM5a7W.s
==27155==
==27155== Conditional jump or move depends on uninitialised value(s)
==27155==at 0x7CF980: determine_locally_known_aggregate_parts(gcall*,
tree_node*, tree_node*, ipa_jump_func*) (in /tmp/gccbuild/gcc/cc1)
==27155==by 0x7D3D1E: ipa_compute_jump_functions_for_edge(func_body_info*,
cgraph_edge*) (in /tmp/gccbuild/gcc/cc1)
==27155==by 0x7D4B0C:
analysis_dom_walker::before_dom_children(basic_block_def*) (in
/tmp/gccbuild/gcc/cc1)
==27155==by 0xC91083: dom_walker::walk(basic_block_def*) (in
/tmp/gccbuild/gcc/cc1)
==27155==by 0x7D93DD: ipa_analyze_node(cgraph_node*) (in
/tmp/gccbuild/gcc/cc1)
==27155==by 0xCCF973: ipcp_generate_summary() (in /tmp/gccbuild/gcc/cc1)
==27155==by 0x8AE13E: execute_ipa_summary_passes(ipa_opt_pass_d*) (in
/tmp/gccbuild/gcc/cc1)
==27155==by 0x5EDFFF: symbol_table::compile() (in /tmp/gccbuild/gcc/cc1)
==27155==by 0x5EF15C: symbol_table::finalize_compilation_unit() (in
/tmp/gccbuild/gcc/cc1)
==27155==by 0x4CF6B6: c_write_global_declarations() (in
/tmp/gccbuild/gcc/cc1)
==27155==by 0x97DB6B: compile_file() (in /tmp/gccbuild/gcc/cc1)
==27155==by 0x97EBDF: do_compile() (in /tmp/gccbuild/gcc/cc1)
==27155==
==27155== Use of uninitialised value of size 8
==27155==at 0x7CF982: determine_locally_known_aggregate_parts(gcall*,
tree_node*, tree_node*, ipa_jump_func*) (in /tmp/gccbuild/gcc/cc1)
==27155==by 0x7D3D1E: ipa_compute_jump_functions_for_edge(func_body_info*,
cgraph_edge*) (in /tmp/gccbuild/gcc/cc1)
==27155==by 0x7D4B0C:
analysis_dom_walker::before_dom_children(basic_block_def*) (in
/tmp/gccbuild/gcc/cc1)
==27155==by 0xC91083: dom_walker::walk(basic_block_def*) (in
/tmp/gccbuild/gcc/cc1)
==27155==by 0x7D93DD: ipa_analyze_node(cgraph_node*) (in
/tmp/gccbuild/gcc/cc1)
==27155==by 0xCCF973: ipcp_generate_summary() (in /tmp/gccbuild/gcc/cc1)
==27155==by 0x8AE13E: execute_ipa_summary_passes(ipa_opt_pass_d*) (in
/tmp/gccbuild/gcc/cc1)
==27155==by 0x5EDFFF: symbol_table::compile() (in /tmp/gccbuild/gcc/cc1)
==27155==by 0x5EF15C: symbol_table::finalize_compilation_unit() (in
/tmp/gccbuild/gcc/cc1)
==27155==by 0x4CF6B6: c_write_global_declarations() (in
/tmp/gccbuild/gcc/cc1)
==27155==by 0x97DB6B: compile_file() (in /tmp/gccbuild/gcc/cc1)
==27155==by 0x97EBDF: do_compile() (in /tmp/gccbuild/gcc/cc1)
==27155==
==27155== Use of uninitialised value of size 8
==27155==at 0x7CF991: determine_locally_known_aggregate_parts(gcall*,
tree_node*, tree_node*, ipa_jump_func*) (in /tmp/gccbuild/gcc/cc1)
==27155==by 0x7D3D1E: ipa_compute_jump_functions_for_edge(func_body_info*,
cgraph_edge*) (in /tmp/gccbuild/gcc/cc1)
==27155==by 0x7D4B0C:
analysis_dom_walker::before_dom_children(basic_block_def*) (in
/tmp/gccbuild/gcc/cc1)
==27155==

[Bug tree-optimization/68402] [6 Regression] FAIL: gcc.dg/tree-ssa/split-path-1.c execution test with -m32

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law  ---
I've installed Ajit's fix for the testcase on the trunk, which should fix this
problem.

[Bug target/67770] [4.9/5/6 Regression] i386: -fshrink-wrap can interact badly with trampolines

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 36765
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36765&action=edit
gcc6-pr67770.patch

Untested fix.

[Bug fortran/68268] configure: error: GNU Fortran is not working;

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to isearcher from comment #8)
> Now here is a new problem. Gfortran can now produce the a.out, but when i
> run ./a.out, there is an error:
> 
> ./a.out: error while loading shared libraries: libgfortran.so.3: cannot open
> shared object file: No such file or directory
> 
> Ahy sugguestions?

GCC bugzilla is not a user support forum.
Post to gcc-help with questions of this 
nature.  The answer to your question lies
in the ldconfig documentation.

[Bug middle-end/68375] [6 Regression] ICE in get_loop_body_in_bfs_order when dumping cfg with -fdump-tree-optimized-graph

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-18
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
It does.
I'll test it out and submit a patch.
Thanks

[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch

[bonzini at gnu dot org]

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

Paolo Bonzini  changed:

   What|Removed |Added

 CC||bonzini at gnu dot org

--- Comment #4 from Paolo Bonzini  ---
Using

#define UNKNOWN_DEP_COST (-1u<<19)

is dangerous in case UNKNOWN_DEP_COST is later assigned to a long.  Do not do
this please.

[Bug sanitizer/68418] ubsan complains about left shifts even with -fwrapv

[bonzini at gnu dot org]

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

Paolo Bonzini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-11-18
   Assignee|unassigned at gcc dot gnu.org  |bonzini at gnu dot org
 Ever confirmed|0   |1

--- Comment #1 from Paolo Bonzini  ---
I have a patch.

[Bug sanitizer/68418] New: ubsan complains about left shifts even with -fwrapv

[bonzini at gnu dot org]

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

Bug ID: 68418
   Summary: ubsan complains about left shifts even with -fwrapv
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bonzini at gnu dot org
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
  Target Milestone: ---

Left shifts into the sign bit is a kind of overflow, and the standard chooses
to treat left shifts of negative values the same way.

However, the -fwrapv option modifies the language to one where integers are
defined as two's complement---which also defines entirely the behavior of
shifts.  Sanitization of left shifts should be disabled when -fwrapv is in
effect.

[Bug tree-optimization/68373] autopar fails on loop exit phi with argument defined outside loop

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #36762|0   |1
is obsolete||

--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 36764
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36764&action=edit
Updated patch v2, to be tested

[Bug fortran/65751] Bogus &L in error message

[dominiq at gcc dot gnu.org]

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

--- Comment #7 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Nov 18 16:29:58 2015
New Revision: 230553

URL: https://gcc.gnu.org/viewcvs?rev=230553&root=gcc&view=rev
Log:
2015-11-18  Dominique d'Humieres 

PR fortran/65751
* expr.c (gfc_check_pointer_assign): Fix error message.

* gfortran.dg/unlimited_polymorphic_2.f03: Update test.


Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03

[Bug tree-optimization/68317] [6 regression] ice in set_value_range, at tree-vrp.c:380

[jiwang at gcc dot gnu.org]

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

--- Comment #9 from Jiong Wang  ---
(In reply to Richard Biener from comment #7)
> (In reply to Jiong Wang from comment #6)
> > Created attachment 36741 [details]
> > prototype-fix
> > 
> > diff --git a/gcc/tree-ssa-loop-manip.c b/gcc/tree-ssa-loop-manip.c
> > index b614412..55a6334 100644
> > --- a/gcc/tree-ssa-loop-manip.c
> > +++ b/gcc/tree-ssa-loop-manip.c
> > @@ -136,6 +136,11 @@ create_iv (tree base, tree step, tree var, struct loop
> > *loop,
> >  gsi_insert_seq_on_edge_immediate (pe, stmts);
> >  
> >phi = create_phi_node (vb, loop->header);
> > +  if (TREE_OVERFLOW (initial)
> > +  && TREE_CODE (initial) == INTEGER_CST
> > +  && int_fits_type_p (initial, TREE_TYPE (vb)))
> > +initial = drop_tree_overflow (initial);
> > +
> >add_phi_arg (phi, initial, loop_preheader_edge (loop), UNKNOWN_LOCATION);
> >add_phi_arg (phi, va, loop_latch_edge (loop), UNKNOWN_LOCATION);
> >  }
> 
> I think it's better to track down where the constant is generated.  I
> see initial is created by
> 
>   initial = force_gimple_operand (base, &stmts, true, var);
> 
> thus likely base is already the same constant (passed from the caller).
> 
> I usually set a breakpoint on the return statement of ggc_internal_alloc
> conditional on the return value being the tree with the overflow.
> 
> Once the overflow value is returned from fold_* () it should be stripped
> off its overflow flag.  Unconditionally so with just
> 
>   if (TREE_OVERFLOW_P (..))
>.. = drop_tree_overflow (..);

Richard,

 After further investigation on where the overflow flag comes
 from. I found there are too many possibility.

 For example, for the testcase reported in PR68326, it's originated at
 fully_constant_expression, at tree-ssa-pre.c when handling tcc_unary,
 the fold_unary will set overflag flag.

 While for the testcase in this PR, there are quite a few OVF variables,
 For the one caused the ICE, the OVF is inherited from another OVF
 variable and the most early I can track down is at tree-ssa-ccp.c, tree
 variable "simplified" is simplifed by gimple-fold infrastructure, and
 conclude to be overflowed which is correct (C source code is
 print(..."0x%08x...", (0xff4 + i) * 0x10..., the multiply are
 assumed to be generating signed int, thus overflowed.), While my understanding
 is it's only used to generate warning. So I tested to call drop_tree_overflow,
 but then later passes will re-calculate the variable, and re-set the overflow
 flag, for example in chrec_fold*.

 I don't undertand related code base, and fell it will be dangerous to 
 just call drop_tree_overflow in those places.

 After a second thinking, this ICE is caused by adjust_range_with_scev
 getting range with overflowed constants min or max. So given there are
 too many places to generate OVF, can we just do a check in
 adjust_range_with_scev, if the constant min or max in the range info
 can fit into the variable type, then naturally we should treat those
 OVF as false alarm and drop them? something like the following, which I
 think can fix the OVF side-effect caused by r230150.

diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index e2393e4..56440b1 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -4331,6 +4331,16 @@ adjust_range_with_scev (value_range *vr, struct loop
*loop,
  && is_positive_overflow_infinity (max)))
 return;

+  if (TREE_CODE (min) == INTEGER_CST
+  && TREE_OVERFLOW (min)
+  && int_fits_type_p (min, type))
+min = drop_tree_overflow (min);
+
+  if (TREE_CODE (max) == INTEGER_CST
+  && TREE_OVERFLOW (max)
+  && int_fits_type_p (max, type))
+max = drop_tree_overflow (max);
+
   set_value_range (vr, VR_RANGE, min, max, vr->equiv);
 }

[Bug tree-optimization/66131] [6 Regression] Wrong code w/ -O2 -ftree-loop-linear

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
(In reply to Bernd Edlinger from comment #1)
> Note: the test case as-it-is, does no longer reproduce on trunk.

You're right. I've just tried and failed to reproduce it w/
gcc-6.0.0-alpha20151115 and all Graphite-related flags that I normally use.

[Bug tree-optimization/68417] [6 Regression] Missed vectorization opportunity when setting struct field

[afomin.mailbox at gmail dot com]

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

--- Comment #2 from Alexander Fomin  ---
Sorry once again - looks like smth is also wrong with me today :)
I'm talking about r230454 and r230453 of course.

[Bug target/67770] [4.9/5/6 Regression] i386: -fshrink-wrap can interact badly with trampolines

[bernds at gcc dot gnu.org]

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

--- Comment #3 from Bernd Schmidt  ---
Shrink-wrapping is disabled if !HAVE_simple_return. So the predicate for that
pattern should detect that condition.

[Bug tree-optimization/68417] [6 Regression] Missed vectorization opportunity when setting struct field

[afomin.mailbox at gmail dot com]

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

--- Comment #1 from Alexander Fomin  ---
I'm sorry for the typo above.
Vectorization is OK for r230453, but we miss if-conversion since r230434.

[Bug lto/68384] LTO error for global register variables in PHP 7 compiling on powerpc64le

[acsawdey at gcc dot gnu.org]

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

--- Comment #7 from acsawdey at gcc dot gnu.org ---
Testing with 270468, -flto-partition=max does work and the code runs. However
-flto-partition=1to1 gets the register global error.

[Bug target/68416] [MPX] GCC emits a lot of redundant bndmov instructions

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #2 from Ilya Enkovich  ---
Vladimir, could you please help with this issue?  Do you know what may cause
such weird allocation?  May it be caused by wrong config for BND registers or
something in MPX instruction patterns?

[Bug target/67770] [4.9/5/6 Regression] i386: -fshrink-wrap can interact badly with trampolines

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
So, the problem is that ix86_static_chain_on_stack is incompatible with
shrink-wrapping, if that i386 backend flag is on, then the function is either
called directly at function address + 0, or through trampoline at function
address + 1 (i.e. it bypasses the initial pushl %esi instruction).
But that of course relies on the first instruction being always pushl %esi, so
we have to ensure shrink wrapping does not change this.

Unfortunately, there is no target hook right now where the target would state
that shrink wrapping is undesirable for the current function for hard to
discover reasons like the above.
Bernd, do you think it is ok to add a target hook for this?  Or try to come up
with some other way how to tell that it is undesirable (some new insn note, ...
?).

[Bug tree-optimization/66131] [6 Regression] Wrong code w/ -O2 -ftree-loop-linear

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
Note: the test case as-it-is, does no longer reproduce on trunk.

[Bug target/68416] [MPX] GCC emits a lot of redundant bndmov instructions

[ienkovich at gcc dot gnu.org]

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

--- Comment #1 from Ilya Enkovich  ---
Seems the problem is in register allocation.  Before allocation we have:

1: NOTE_INSN_DELETED  
6: NOTE_INSN_BASIC_BLOCK 2
2: r95:DI=di:DI   
  REG_DEAD di:DI  
3: r96:SI=si:SI   
  REG_DEAD si:SI  
4: r97:BND64=bnd0:BND64   
  REG_DEAD bnd0:BND64 
5: NOTE_INSN_FUNCTION_BEG 
8: {unspec[r97:BND64,r95:DI] 92;[r95:DI]=unspec[[r95:DI]] 95;}
9: NOTE_INSN_DELETED  
   10: {unspec[r97:BND64,r95:DI+0x7] 93;[r95:DI+0x7]=unspec[[r95:DI+0x7]] 95;}
  REG_DEAD r97:BND64  
   11: r87:DI=[r95:DI]
   12: {r92:BND64=unspec[[unspec[r95:DI,r87:DI] 91]] 90;use [r95:DI];}
  REG_DEAD r95:DI 
   13: r99:DI=sign_extend(r96:SI) 
  REG_DEAD r96:SI 
   14: NOTE_INSN_DELETED  
   15: r90:DI=r99:DI<<0x2+r87:DI  
  REG_DEAD r99:DI 
  REG_DEAD r87:DI 
   16: {unspec[r92:BND64,r90:DI] 92;[r90:DI]=unspec[[r90:DI]] 95;}
   17: NOTE_INSN_DELETED  
   18: {unspec[r92:BND64,r90:DI+0x3] 93;[r90:DI+0x3]=unspec[[r90:DI+0x3]] 95;}
  REG_DEAD r92:BND64  
   19: r103:SI=[r90:DI]   
  REG_DEAD r90:DI 
   24: ax:SI=r103:SI  
  REG_DEAD r103:SI
   25: use ax:SI  

After allocation:

1: NOTE_INSN_DELETED
6: NOTE_INSN_BASIC_BLOCK 2
4: [sp:DI-0x18]=bnd0:BND64
5: NOTE_INSN_FUNCTION_BEG
   28: bnd1:BND64=[sp:DI-0x18]
8: {unspec[bnd1:BND64,di:DI] 92;[di:DI]=unspec[[di:DI]] 95;}
9: NOTE_INSN_DELETED
   29: bnd2:BND64=[sp:DI-0x18]
   10: {unspec[bnd2:BND64,di:DI+0x7] 93;[di:DI+0x7]=unspec[[di:DI+0x7]] 95;}
   11: ax:DI=[di:DI]
   12: {bnd3:BND64=unspec[[unspec[di:DI,ax:DI] 91]] 90;use [di:DI];}
   30: [sp:DI-0x18]=bnd3:BND64
   13: si:DI=sign_extend(si:SI)
   14: NOTE_INSN_DELETED
   15: ax:DI=si:DI<<0x2+ax:DI
   31: bnd0:BND64=[sp:DI-0x18]
   16: {unspec[bnd0:BND64,ax:DI] 92;[ax:DI]=unspec[[ax:DI]] 95;}
   17: NOTE_INSN_DELETED
   32: bnd1:BND64=[sp:DI-0x18]
   18: {unspec[bnd1:BND64,ax:DI+0x3] 93;[ax:DI+0x3]=unspec[[ax:DI+0x3]] 95;}
   19: ax:SI=[ax:DI]
   24: ax:SI=ax:SI
   25: use ax:SI
   27: NOTE_INSN_DELETED

Here even simple r97:BND64=bnd0:BND64 goes through stack with a load at each
use like if bounds register usage kills it.

[Bug tree-optimization/68417] New: [6 Regression] Missed vectorization opportunity when setting struct field

[afomin.mailbox at gmail dot com]

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

Bug ID: 68417
   Summary: [6 Regression] Missed vectorization opportunity when
setting struct field
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: afomin.mailbox at gmail dot com
CC: izamyatin at gmail dot com,
venkataramanan.kumar.gnu at gmail dot com, ysrumyan at 
gmail dot com
  Target Milestone: ---
Target: i686-*-*

Created attachment 36763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36763&action=edit
A reproducer

A loop in the test attached compiled with -m32 -msse4.2 -O2 -ftree-vectorize is
no more vectorized after r230454(while on r223524.

[Bug c++/68385] [6 Regression] ICE building libstdc++ on arm-none-eabi

[andre.simoesdiasvieira at arm dot com]

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

Andre Vieira  changed:

   What|Removed |Added

 CC||andre.simoesdiasvieira@arm.
   ||com

--- Comment #2 from Andre Vieira  ---
Hi Jason,

I don't fully understand what is going wrong here, but when debugging I found
that the tree it complains about is coming from a call to
convert_to_integer_nofold in  the line in ocp_convert, this used to have a
fold_if_not_in_template. I found that I no longer got the ICE after reverting
the code there to fold 'converted'. Not sure this actually fixes it, I'd need
to look further into your patch for this. Hopefully this saves you some
debugging yourself.

The issue seemed to originate from a nop_expr around a param_declaration and
fold gets rid of it.

Hope this helps.

Cheers,
Andre

[Bug rtl-optimization/67609] [5 Regression] Generates wrong code for SSE2 _mm_load_pd

[rth at gcc dot gnu.org]

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

--- Comment #37 from Richard Henderson  ---
Author: rth
Date: Wed Nov 18 15:45:26 2015
New Revision: 230552

URL: https://gcc.gnu.org/viewcvs?rev=230552&root=gcc&view=rev
Log:
PR rtl-opt/67609

Backport from mainline
* config/i386/i386.c (ix86_cannot_change_mode_class): Tighten
sse check to the exact conditions of PR 67609. 

* config/i386/i386.c (ix86_cannot_change_mode_class): Disallow
narrowing subregs on SSE and MMX registers.
* doc/tm.texi.in (CANNOT_CHANGE_MODE_CLASS): Clarify when subregs that
appear to be sub-words of multi-register pseudos must be rejected.
* doc/tm.texi: Regenerate.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr67609-2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr67609.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/doc/tm.texi
branches/gcc-5-branch/gcc/doc/tm.texi.in

[Bug tree-optimization/68373] autopar fails on loop exit phi with argument defined outside loop

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Created attachment 36762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36762&action=edit
Updated patch, to be tested

[Bug tree-optimization/68402] [6 Regression] FAIL: gcc.dg/tree-ssa/split-path-1.c execution test with -m32

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from vries at gcc dot gnu.org ---
patch: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02217.html