[Bug tree-optimization/78692] New: [7 Regression] ICE (segfault)

[doko at gcc dot gnu.org]

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

Bug ID: 78692
   Summary: [7 Regression] ICE (segfault)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with r243108 on x86_64-linux-gnu, works with -O1

$ cat jni_channel.ii
int a;
void *b;
extern "C" {
struct c {
  virtual int d();
};
struct e {
  virtual int operator()(int, const void *, int) = 0;
};
class f {
  int g();
  int h;
  e 
};
struct : c, e {
  int operator()(int, const void *, int) { throw int(); }
} j;
int f::g() { a = i(h, b, 0); }
}

$ g++ -std=c++98 -c -O2 jni_channel.iijni_channel.ii: In member function 'int
f::g()':
jni_channel.ii:18:19: internal compiler error: Segmentation fault
 int f::g() { a = i(h, b, 0); }
  ~^
0xb0bb0f crash_signal
../../src/gcc/toplev.c:333
0xb43df4 is_complex_reg
../../src/gcc/tree-complex.c:177
0xb43df4 init_dont_simulate_again
../../src/gcc/tree-complex.c:231
0xb43df4 tree_lower_complex
../../src/gcc/tree-complex.c:1662
0xb43df4 execute
../../src/gcc/tree-complex.c:1788
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug middle-end/78642] [7 regression] invalid rtl sharing found in the insn

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #16 from Eric Botcazou  ---
.

[Bug middle-end/78642] [7 regression] invalid rtl sharing found in the insn

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  ---
Author: ebotcazou
Date: Tue Dec  6 07:03:04 2016
New Revision: 243282

URL: https://gcc.gnu.org/viewcvs?rev=243282=gcc=rev
Log:
PR middle-end/78642
* emit-rtl.c (verify_rtx_sharing) : Relax condition.
(copy_rtx_if_shared_1) : Likewise.
(copy_insn_1) : Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/emit-rtl.c

[Bug middle-end/78691] [7 Regression] ICE compiling Linux boot code

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-06
 CC||trippels at gcc dot gnu.org
  Component|c   |middle-end
Summary|ICE compiling Linux PPC |[7 Regression] ICE
   |boot code   |compiling Linux boot code
 Ever confirmed|0   |1

--- Comment #3 from Markus Trippelsdorf  ---
testcase.i: In function ‘fn1’:
testcase.i:1:5: internal compiler error: tree check: expected integer_type or
enumeral_type or boolean_type or real_type or fixed_point_type, have
pointer_type in int_fits_type_p, at tree.c:9152
 int fn1(char *p1, char *p2) {
 ^~~
0xe2b2ec tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9814
0xe3e74e tree_check5(tree_node const*, char const*, int, char const*,
tree_code, tree_code, tree_code, tree_code, tree_code)
../../gcc/gcc/tree.h:3393
0xe3e74e int_fits_type_p(tree_node const*, tree_node const*)
../../gcc/gcc/tree.c:9152
0xfc922c generic_simplify_88
/var/tmp/gcc_build_dir/gcc/generic-match.c:3681
0xfdabf7 generic_simplify_CONVERT_EXPR
/var/tmp/gcc_build_dir/gcc/generic-match.c:9469
0xfee06a generic_simplify(unsigned int, tree_code, tree_node*, tree_node*)
/var/tmp/gcc_build_dir/gcc/generic-match.c:11309
0x88cbc2 fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:7524
0x88f38a fold_build1_stat_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:12135
0xfdb07f generic_simplify_CONVERT_EXPR
/var/tmp/gcc_build_dir/gcc/generic-match.c:9742
0xfee06a generic_simplify(unsigned int, tree_code, tree_node*, tree_node*)
/var/tmp/gcc_build_dir/gcc/generic-match.c:11309
0x88cbc2 fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:7524
0x88f38a fold_build1_stat_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:12135
0x135e2a8 chrec_convert_1
../../gcc/gcc/tree-chrec.c:1366
0xc692e4 add_to_evolution_1
../../gcc/gcc/tree-scalar-evolution.c:638
0xc69bdd add_to_evolution
../../gcc/gcc/tree-scalar-evolution.c:833
0xc6e593 follow_ssa_edge_binary
../../gcc/gcc/tree-scalar-evolution.c:956
0xc6e8b5 follow_ssa_edge_expr
../../gcc/gcc/tree-scalar-evolution.c:1096
0xc6e16d follow_ssa_edge_inner_loop_phi
../../gcc/gcc/tree-scalar-evolution.c:1308
0xc6e16d follow_ssa_edge
../../gcc/gcc/tree-scalar-evolution.c:1357
0xc6e527 follow_ssa_edge_binary
../../gcc/gcc/tree-scalar-evolution.c:1010

[Bug c/78691] ICE compiling Linux PPC boot code

[g...@d-silva.org]

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

--- Comment #2 from Alastair D'Silva <g...@d-silva.org> ---
The same problem also occurs when compiling the linux x86 boot code
arch/x86/boot/printf.c, which results in a very similar testcase:


~/tmp/gcc-c46915880dca92/bin/x86_64-unknown-linux-gnu-cc -m16  -Os -c
testcase.i
testcase.i: In function 'fn1':
testcase.i:1:5: internal compiler error: tree check: expected integer_type or
enumeral_type or boolean_type or real_type or fixed_point_type, have
pointer_type in int_fits_type_p, at tree.c:9152
 int fn1(char *p1, char *p2) {
 ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

~/tmp/gcc-c46915880dca92/bin/x86_64-unknown-linux-gnu-cc -v
Using built-in specs.
COLLECT_GCC=/home/adsilva/tmp/gcc-c46915880dca92/bin/x86_64-unknown-linux-gnu-cc
COLLECT_LTO_WRAPPER=/home/adsilva/tmp/gcc-c46915880dca92/bin/../libexec/gcc/x86_64-unknown-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /workspace/.build/src/gcc-git/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=x86_64-unknown-linux-gnu --prefix=/workspace/x-tools
--with-sysroot=/workspace/x-tools/x86_64-unknown-linux-gnu/sysroot
--enable-languages=c,c++ --with-pkgversion='crosstool-NG
crosstool-ng-1.22.0-201-g11cb2dd' --enable-__cxa_atexit --enable-libmudflap
--disable-libgomp --disable-libssp --disable-libquadmath
--disable-libquadmath-support --enable-libsanitizer
--with-gmp=/workspace/.build/x86_64-unknown-linux-gnu/buildtools
--with-mpfr=/workspace/.build/x86_64-unknown-linux-gnu/buildtools
--with-mpc=/workspace/.build/x86_64-unknown-linux-gnu/buildtools
--with-isl=/workspace/.build/x86_64-unknown-linux-gnu/buildtools --enable-lto
--enable-threads=posix --enable-target-optspace --with-linker-hash-style=both
--enable-plugin --enable-gold --disable-nls --disable-multilib
--with-local-prefix=/workspace/x-tools/x86_64-unknown-linux-gnu/sysroot
--enable-long-long
Thread model: posix
gcc version 7.0.0 20161205 (experimental) (crosstool-NG
crosstool-ng-1.22.0-201-g11cb2dd)

[Bug c/78691] ICE compiling Linux PPC boot code

[g...@d-silva.org]

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

--- Comment #1 from Alastair D'Silva  ---
Created attachment 40262
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40262=edit
minimal testcase to reproduce the ICE for x86

[Bug c/78691] New: ICE compiling Linux PPC boot code

[g...@d-silva.org]

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

Bug ID: 78691
   Summary: ICE compiling Linux PPC boot code
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: g...@d-silva.org
  Target Milestone: ---

Created attachment 40261
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40261=edit
minimal testcase to reproduce the ICE

When building the Linux kernel targeting ppc64, using the latest development
branch of GCC, we get the following ICE:

/var/lib/jenkins/workspace/r-RWR32HYWO3ZTAR3XC4UADJ4YQDQRVLEPEAHCW7LD3RYUCNDKDJ2Q/COMPILER/gcc-master/PLATFORM/ppc64/cctarget/bin/powerpc64-unknown-linux-gnu-cc
-m32 -Os -c testcase.i
testcase.i: In function 'fn1':
testcase.i:2:5: internal compiler error: tree check: expected integer_type or
enumeral_type or boolean_type or real_type or fixed_point_type, have
pointer_type in int_fits_type_p, at tree.c:9152
 int fn1() {
 ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


The testcase is attached, and was generated using creduce against
linux/arch/powerpc/boot/stdio.c


Version info
gcc -v:
Using built-in specs.
COLLECT_GCC=/var/lib/jenkins/workspace/r-RWR32HYWO3ZTAR3XC4UADJ4YQDQRVLEPEAHCW7LD3RYUCNDKDJ2Q/COMPILER/gcc-master/PLATFORM/ppc64/cctarget/bin/powerpc64-unknown-linux-gnu-cc
COLLECT_LTO_WRAPPER=/var/lib/jenkins/workspace/r-RWR32HYWO3ZTAR3XC4UADJ4YQDQRVLEPEAHCW7LD3RYUCNDKDJ2Q/COMPILER/gcc-master/PLATFORM/ppc64/cctarget/bin/../libexec/gcc/powerpc64-unknown-linux-gnu/7.0.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: /workspace/.build/src/gcc-git/configure
--build=powerpc64le-build_unknown-linux-gnu
--host=powerpc64le-build_unknown-linux-gnu --target=powerpc64-unknown-linux-gnu
--prefix=/workspace/x-tools
--with-sysroot=/workspace/x-tools/powerpc64-unknown-linux-gnu/sysroot
--enable-languages=c,c++ --with-pkgversion='crosstool-NG
crosstool-ng-1.22.0-201-g11cb2dd' --enable-__cxa_atexit --enable-libmudflap
--disable-libgomp --disable-libssp --disable-libquadmath
--disable-libquadmath-support --enable-libsanitizer
--with-gmp=/workspace/.build/powerpc64-unknown-linux-gnu/buildtools
--with-mpfr=/workspace/.build/powerpc64-unknown-linux-gnu/buildtools
--with-mpc=/workspace/.build/powerpc64-unknown-linux-gnu/buildtools
--with-isl=/workspace/.build/powerpc64-unknown-linux-gnu/buildtools
--enable-lto --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix
--enable-target-optspace --enable-plugin --disable-nls --disable-multilib
--with-local-prefix=/workspace/x-tools/powerpc64-unknown-linux-gnu/sysroot
--enable-long-long --disable-multilib
Thread model: posix
gcc version 7.0.0 20161205 (experimental) (crosstool-NG
crosstool-ng-1.22.0-201-g11cb2dd) 

Git revision: c46915880dca927bcbc2371336acee8110009143

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #4)
> I have the ICE resolved, but also note that the Fortran 95 standard has the
> constraint on namelist statements and F2003 does not.
> 
> Constraint - namelist-group-object shall not be an array dummy argument with
> a nonconstant bound, a variable with nonconstant character length, an
> automatic object, a pointer, a variable of a type that has an ultimate
> component that is a pointer, or an allocatable array.
> 
> We can got two ways here, forget about the F95 standard and accept it, or
> give an error with -std=f95. This is sort of troublsome because we have to
> maintain two or more behaviors if a user wants to check against F95.  I
> wonder if we should get rid of the -std=f95 altogether and just keep
> -std=F2003 or similar.
> 
> Any opinions?

I would prefer an error with -std=f95.  This is what 
gfc_notify_std() is used for.  ISTR that list of things
in others places, but don't recall if we have a simply
function where you could do

   if (check_list_of_stuff () && gfc_notify_std (GFC_F95,...))

[Bug target/78688] PowerPC fails bootstrap

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #3 from Michael Meissner  ---
Fixed in subversion id 243278.

[Bug target/78688] PowerPC fails bootstrap

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Tue Dec  6 00:58:40 2016
New Revision: 243278

URL: https://gcc.gnu.org/viewcvs?rev=243278=gcc=rev
Log:
2016-12-05  Michael Meissner  

PR target/78688
* config/rs6000/rs6000.h (FUNCTION_VALUE_REGNO_P): Use IN_RANGE
instead of ((N) >= (X) && (N) <= (Y-X)) to silence warnings about
comparing signed to unsigned values.
(FUNCTION_ARG_REGNO_P): Likewise.


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

[Bug libstdc++/78677] __gthread_key_create assumed not to fail in eh_globals.cc

[chrisj at rtems dot org]

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

--- Comment #2 from Chris Johns  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Chris Johns from comment #0)
> > Some operating system, for example RTEMS, may fail to create a POSIX key if
> > not configured with enough resources. The lack of any error reporting in
> > __eh_globals_init::__eh_globals_init() means exceptions are silently
> > switched from thread safe to not being thread safe and this is not a concern
> > for RTEMS.
> 
> I assume this is a typo and you mean this *is* a concern for RTEMS? :-)
> 

Yes, sorry about that.

> > A way to report errors would be welcomed by RTEMS. We could hook this is a
> > fatal error so the user is aware there is a critical issue that needs to be
> > addressed.
> 
> I agree there should be some code to deal with the error there.
> 
> This seems like a specific example of the broader problem you described in
> PR 60645.

It is similar and I think a more critical issue. Thread-safe exceptions is
something users expect to be working if there is no error.

Reviewing the code a little more I am confused about the detail of how it
works.

Is it reasonable to assume the static constructor needs to be called before any
thread local exceptions are thrown?

We call constructors from the initial thread with the kernel up and running and
user static constructors could start threads and these could raise exceptions.

[Bug c++/78690] New: [7 Regression] ICE in cxx_incomplete_type_diagnostic, at cp/typeck2.c:552

[doko at gcc dot gnu.org]

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

Bug ID: 78690
   Summary: [7 Regression] ICE in cxx_incomplete_type_diagnostic,
at cp/typeck2.c:552
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with  r243108 on x86_64-linux-gnu

$ cat dchroot-session-base.iistruct a;
template  class c {
  using b::a;
  void d() { a. }
};

$ g++ -std=c++11 -c -g -O2 dchroot-session-base.ii
dchroot-session-base.ii: In member function 'void c::d()':
dchroot-session-base.ii:4:15: internal compiler error: in
cxx_incomplete_type_diagnostic, at cp/typeck2.c:552
   void d() { a. }
   ^
0x63b96a cxx_incomplete_type_diagnostic(unsigned int, tree_node const*,
tree_node const*, diagnostic_t)
../../src/gcc/cp/typeck2.c:552
0x69898f cxx_incomplete_type_diagnostic(tree_node const*, tree_node const*,
diagnostic_t)
../../src/gcc/cp/cp-tree.h:6817
0x69898f complete_type_or_maybe_complain(tree_node*, tree_node*, int)
../../src/gcc/cp/typeck.c:152
0x676e00 cp_parser_postfix_dot_deref_expression
../../src/gcc/cp/parser.c:7332
0x67a0dd cp_parser_postfix_expression
../../src/gcc/cp/parser.c:7047
0x67b4e0 cp_parser_unary_expression
../../src/gcc/cp/parser.c:8099
0x67be63 cp_parser_cast_expression
../../src/gcc/cp/parser.c:8776
0x67c5d7 cp_parser_binary_expression
../../src/gcc/cp/parser.c:8877
0x67cc94 cp_parser_assignment_expression
../../src/gcc/cp/parser.c:9164
0x67fdea cp_parser_expression
../../src/gcc/cp/parser.c:9333
0x684698 cp_parser_expression_statement
../../src/gcc/cp/parser.c:10877
0x6718e2 cp_parser_statement
../../src/gcc/cp/parser.c:10693
0x67261d cp_parser_statement_seq_opt
../../src/gcc/cp/parser.c:11019
0x6726df cp_parser_compound_statement
../../src/gcc/cp/parser.c:10973
0x682dd4 cp_parser_function_body
../../src/gcc/cp/parser.c:21357
0x682dd4 cp_parser_ctor_initializer_opt_and_function_body
../../src/gcc/cp/parser.c:21393
0x689b20 cp_parser_function_definition_after_declarator
../../src/gcc/cp/parser.c:26151
0x689e44 cp_parser_late_parsing_for_member
../../src/gcc/cp/parser.c:27033
0x66b6dd cp_parser_class_specifier_1
../../src/gcc/cp/parser.c:22244
0x66c869 cp_parser_class_specifier
../../src/gcc/cp/parser.c:22270
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose  ---
a test case without a processor specific option.

$ cat RapMapSAIndex.ii
class a {
public:
  a(long);
  void operator<<=(long) {
long b;
for (unsigned long c; c; c--)
  d[c + b] = d[c];
  }
  a ();
  long d[28];
};
long e;
int f;
void j() {
  a h(e), i = h;
  i.g() <<= f;
}

$ g++ -c -std=c++11 -Ofast RapMapSAIndex.ii
RapMapSAIndex.ii: In function 'void j()':
RapMapSAIndex.ii:14:6: internal compiler error: in
create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
 void j() {
  ^
0xcdb7be create_intersect_range_checks_index
../../src/gcc/tree-vect-loop-manip.c:2073
0xcdb7be create_intersect_range_checks
../../src/gcc/tree-vect-loop-manip.c:2131
0xcdb7be vect_create_cond_for_alias_checks(_loop_vec_info*, tree_node**)
../../src/gcc/tree-vect-loop-manip.c:2219
0xcdbf7c vect_loop_versioning(_loop_vec_info*, unsigned int, bool)
../../src/gcc/tree-vect-loop-manip.c:2293
0xccc064 vect_transform_loop(_loop_vec_info*)
../../src/gcc/tree-vect-loop.c:6773
0xce8d62 vectorize_loops()
../../src/gcc/tree-vectorizer.c:621
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/78688] PowerPC fails bootstrap

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

[Bug middle-end/78689] New: [7 Regression] ICE (segfault)

[doko at gcc dot gnu.org]

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

Bug ID: 78689
   Summary: [7 Regression] ICE (segfault)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with r243108 on x86_64-linux-gnu (building the yosys package in Debian),
also crashes with -O1 and -O0.

$ g++ -std=c++11 -c -O2 share.ii 
share.ii: In constructor 'e::e()':
share.ii:14:3: internal compiler error: Segmentation fault
   e() {
   ^
0xb0bb0f crash_signal
../../src/gcc/toplev.c:333
0xb33b03 main_block_label
../../src/gcc/tree-cfg.c:1380
0xb33ffd cleanup_dead_labels()
../../src/gcc/tree-cfg.c:1563
0xb3ec31 build_gimple_cfg
../../src/gcc/tree-cfg.c:237
0xb3ec31 execute_build_cfg
../../src/gcc/tree-cfg.c:396
0xb3ec31 execute
../../src/gcc/tree-cfg.c:432
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ cat share.ii
class b {
  struct B {
B(int, int);
  } ah;

public:
  int c;
  b(const char *) : ah(0, c) {}
};
struct d {
  d(b);
};
struct e {
  e() {
goto aj;
if (0)
aj:;
  }
};
struct f : d {
  f() : d("") { e(); }
} a;

[Bug target/78688] PowerPC fails bootstrap

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 40260
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40260=edit
Proposed patch to fix the problem

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
I have the ICE resolved, but also note that the Fortran 95 standard has the
constraint on namelist statements and F2003 does not.

Constraint - namelist-group-object shall not be an array dummy argument with a
nonconstant bound, a variable with nonconstant character length, an automatic
object, a pointer, a variable of a type that has an ultimate component that is
a pointer, or an allocatable array.

We can got two ways here, forget about the F95 standard and accept it, or give
an error with -std=f95. This is sort of troublsome because we have to maintain
two or more behaviors if a user wants to check against F95.  I wonder if we
should get rid of the -std=f95 altogether and just keep -std=F2003 or similar.

Any opinions?

Possible bug with switch when optimization is turned on.

[luke B]

Hi

The following code seems to be correctly executed when compiled with
GCC 4.4.7 and LLVM 6.1. It does not correctly compile with gcc version
5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4).

The following is what I have reduced the problem to:

#include 
#include 

#define GENERAL 1
#define BRACKETS 2
#define QUOTES 3

//This method contains the issue.
void foo(char *qb, char* into) {
  //The starting state is important for the bug.
  int state = QUOTES;
  int save_state = BRACKETS;

  while (qb) { //Always true, it seems this can't just be '1'
printf("State is %d\n", state);
switch (state) {
case BRACKETS:
  printf("Yay this was correctly executed\n");
  exit(0);
  break;
case GENERAL:
printf("Oh no how did you get here?\n");
printf("State is %d\n", state);
exit(1);
  break;
case QUOTES:
state = save_state;
printf("State went to %d btw BRACKETS is %d\n", state, BRACKETS);
save_state = GENERAL; //Remove this line and it will work even
when optimised.
printf("After save state, state went to %d btw BRACKETS is
%d\n", state, BRACKETS);
  break;
default: ;
}
printf("State %d btw GENERAL %d\n", state, GENERAL);
  }
  printf("If you see this then something is really wrong.\n");
  exit(4);
}

int main() {
//These don't seem to matter don't concern yourself with them.
char *b = "123";
char out[4];
foo(b, out);
return 1;
}

If I compile this with:
gcc -O0 -g -Wall -Werror sillyswitch.c -o sillyswitch

It will correctly print "Yay this was correctly executed"

However if I compile this with:
gcc -O -g -Wall -Werror sillyswitch.c -o sillyswitch

It will print "Oh no how did you get here?"

I suspect this is a bug. I am unable to create an account to report
this as a bug though.

-Luke

[Bug middle-end/17308] nonnull attribute not as useful as it could

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #15 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00399.html

[Bug c/78673] sprintf missing attribute nonnull on destination argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=17308

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00399.html

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #10 from Kazumoto Kojima  ---
Ah, don't mind.  Your patch accidentally hides this PR.  Now
the SH build failure comes back on trunk :-)

[Bug target/71977] powerpc64: Use VSR when operating on float and integer

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
(In reply to Michael Meissner from comment #1)
> Note in terms of the code in general, you have to make sure that the float
> value is converted to vector form before you do AND/OR/etc. on it.  This is
> because within the register, 32-bit floats are actually stored as 64-bit
> double precision values.

I have a work in progress patch that I need to get back to once these
other bugs I'm working on get fixed/resolved.  I'll try and see what
happens with it when using -mcpu=power9.

[Bug middle-end/49774] [meta-bug] restrict qualification aliasing issues

[law at redhat dot com]

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

Bug 48390 Summary: Multiple setting to restricted pointer variable not 
optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48390

   What|Removed |Added

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

[Bug middle-end/48390] Multiple setting to restricted pointer variable not optimized away

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Verified that DSE is removing the a = 1 statements in both the Fortran and C
testcases on the trunk.  Did not bisect to a specific commit.

[Bug target/78688] PowerPC fails bootstrap

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Target||powerpc64le-gnu-linux
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-05
 CC||dje at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Host||powerpc64le-gnu-linux
 Ever confirmed|0   |1
  Build||powerpc64le-gnu-linux
   Severity|normal  |blocker

[Bug target/78688] New: PowerPC fails bootstrap

[meissner at gcc dot gnu.org]

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

Bug ID: 78688
   Summary: PowerPC fails bootstrap
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

GCC subversion id 243270 does not bootstrap due to the following error:

/home/meissner/fsf-build-ppc64le/trunk/./prev-gcc/xg++
-B/home/meissner/fsf-build-ppc64le/trunk/./prev-gcc/
-B/home/meissner/fsf-install-ppc64le/trunk/powerpc64le-unknown-linux-gnu/bin/
-nostdinc++
-B/home/meissner/fsf-build-ppc64le/trunk/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/meissner/fsf-build-ppc64le/trunk/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/meissner/fsf-build-ppc64le/trunk/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu

-I/home/meissner/fsf-build-ppc64le/trunk/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include
 -I/home/meissner/fsf-src/trunk/libstdc++-v3/libsupc++
-L/home/meissner/fsf-build-ppc64le/trunk/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/meissner/fsf-build-ppc64le/trunk/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -I. -I. -I/home/meissner/fsf-src/trunk/gcc
-I/home/meissner/fsf-src/trunk/gcc/.
-I/home/meissner/fsf-src/trunk/gcc/../include
-I/home/meissner/fsf-src/trunk/gcc/../libcpp/include 
-I/home/meissner/fsf-src/trunk/gcc/../libdecnumber
-I/home/meissner/fsf-src/trunk/gcc/../libdecnumber/dpd -I../libdecnumber
-I/home/meissner/fsf-src/trunk/gcc/../libbacktrace   -o targhooks.o -MT
targhooks.o -MMD -MP -MF ./.deps/targhooks.TPo
/home/meissner/fsf-src/trunk/gcc/targhooks.c
In file included from ./tm.h:26:0,
 from /home/meissner/fsf-src/trunk/gcc/target.h:52,
 from /home/meissner/fsf-src/trunk/gcc/targhooks.c:52:
/home/meissner/fsf-src/trunk/gcc/targhooks.c: In function 'bool
default_function_value_regno_p(unsigned int)':
/home/meissner/fsf-src/trunk/gcc/config/rs6000/rs6000.h:1871:41: error:
comparison between signed and unsigned integer expressions
[-Werror=sign-compare]
|| ((N) >= ALTIVEC_ARG_RETURN && (N) <= ALTIVEC_ARG_MAX_RETURN \
 ^
/home/meissner/fsf-src/trunk/gcc/targhooks.c:920:10: note: in expansion of
macro 'FUNCTION_VALUE_REGNO_P'
   return FUNCTION_VALUE_REGNO_P (regno);
  ^~
cc1plus: all warnings being treated as errors
make: *** [targhooks.o] Error 1

[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #9 from Bill Schmidt  ---
Fixed.

[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Dec  5 21:48:27 2016
New Revision: 243272

URL: https://gcc.gnu.org/viewcvs?rev=243272=gcc=rev
Log:
2016-12-05  Bill Schmidt  
Stefan Freudenberger  

PR tree-optimization/78646
* gimple-ssa-strength-reduction.c (replace_ref): The pointer
addition used for the memory base expression should have the type
of the candidate.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c

[Bug fortran/78226] Fill out location information everywhere

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
Hi Andre,

the patch at

https://gcc.gnu.org/ml/fortran/2016-12/msg00048.html

is OK (or, at your choice, obvious and simple).

I don't have access to my e-mail at the moment, so I cannot
reply to the list directly.

Regards

Thomas

[Bug target/71977] powerpc64: Use VSR when operating on float and integer

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Unfortunately, the code gets even worse if you use -mcpu=power9:

.L.mask_float:
stfs 1,-16(1)
lwz 9,-16(1)
and 4,4,9
stw 4,-16(1)
lfs 1,-16(1)
blr

I.e. instead of doing direct moves to the GPRs and doing the AND, it now stores
the value on the stack and reloads it.

Note in terms of the code in general, you have to make sure that the float
value is converted to vector form before you do AND/OR/etc. on it.  This is
because within the register, 32-bit floats are actually stored as 64-bit double
precision values.

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[nathan at acm dot org]

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

--- Comment #10 from Nathan Sidwell  ---
On 12/05/2016 03:44 PM, jakub at gcc dot gnu.org wrote:

> I thought that such constructs are widely used though, I believe e.g. glibc
> used arrays of structs with flexible array members in several places.  Maybe 
> it
> has changed, I've lost track.  So, before changing anything like that we'd 
> need
> to make sure e.g. glibc still builds.

Remarkable.  I wonder what meaning such code is expected to have. 
Anyway, I've noted on bug 68489.  I guess we want both C & C++ modes to 
agree whether such array types are meaningful.

nathan

[Bug c++/68489] arrays of flexible array members are silently accepted

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #3 from Nathan Sidwell  ---
Jakub commented on 78635:
I thought that such constructs are widely used though, I believe e.g. glibc
used arrays of structs with flexible array members in several places.  Maybe it
has changed, I've lost track.  So, before changing anything like that we'd need
to make sure e.g. glibc still builds.

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Nathan Sidwell from comment #8)
> The fix for both bugs is the same -- reject creation of arrays of trailing
> array elements.  We used to reject initializers for such arrays, then we
> silently accepted them (generating wrong code), now we ICE.  It seems
> perverse to think going from 'silent wrong code' to 'ICE' to be a regression.
> 
> I suspect we could easily generate wrong code even without an initializer,
> as the array layout would overlay a previous element's trailing array with a
> subsequent element.  That's bound to confuse optimizers.

I thought that such constructs are widely used though, I believe e.g. glibc
used arrays of structs with flexible array members in several places.  Maybe it
has changed, I've lost track.  So, before changing anything like that we'd need
to make sure e.g. glibc still builds.

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #40258|0   |1
is obsolete||

--- Comment #14 from Eric Botcazou  ---
Created attachment 40259
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40259=edit
Tentative fix #2

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

--- Comment #13 from Eric Botcazou  ---
Created attachment 40258
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40258=edit
Tentative fix

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[nathan at gcc dot gnu.org]

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

--- Comment #8 from Nathan Sidwell  ---
The fix for both bugs is the same -- reject creation of arrays of trailing
array elements.  We used to reject initializers for such arrays, then we
silently accepted them (generating wrong code), now we ICE.  It seems perverse
to think going from 'silent wrong code' to 'ICE' to be a regression.

I suspect we could easily generate wrong code even without an initializer, as
the array layout would overlay a previous element's trailing array with a
subsequent element.  That's bound to confuse optimizers.

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
> But verify_rtx_sharing also has:
> 
> case CLOBBER:
>   /* Share clobbers of hard registers (like cc0), but do not share
> pseudo reg
>  clobbers or clobbers of hard registers that originated as pseudos.
>  This is needed to allow safe register renaming.  */
>   if (REG_P (XEXP (x, 0)) && REGNO (XEXP (x, 0)) < FIRST_PSEUDO_REGISTER
>   && ORIGINAL_REGNO (XEXP (x, 0)) == REGNO (XEXP (x, 0)))
> return;
>   break;
> 
> So why doesn't it return?  Has ORIGINAL_REGNO changed on the hard reg?

No, but the REGNO has, because of the leaf registers optimization.

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
But this one has been marked as regression, the other PR is not.  So, either it
needs to be turned into a regression, or this one can't be a dup.

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #15 from James Greenhalgh  ---
(In reply to Segher Boessenkool from comment #14)
> I used trunk.  --disable-bootstrap fails the same, just much faster ;-)
> 
> Maybe the binutils etc. version matters?

Do you have a "modern" GCC on path? I'll just be bootstrapping with the system
compiler for stage 1, so might be missing newer warnings?

[Bug fortran/78682] [Coarray] [OOP] ICE calling (locally) a TBP of a remote CAF derived type

[stefano.zaghi at cnr dot it]

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

--- Comment #4 from Stefano Zaghi  ---
(In reply to janus from comment #3)
> I see the ICE with 5.4.1 and 6.2.0, but I can confirm that it is gone on
> current trunk.
> 
> For which reason do you think the code is invalid?

I have not yet studied in details what the standard states (if it says anything
about), but Damian Rouson is very sure that it is invalid and I have great
respect of Damian's words...

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[segher at gcc dot gnu.org]

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

--- Comment #14 from Segher Boessenkool  ---
I used trunk.  --disable-bootstrap fails the same, just much faster ;-)

Maybe the binutils etc. version matters?

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Nathan Sidwell  ---
This is a dup of 68489.  We should reject creation of the array type way before
getting to grok an initializer for it.

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

[Bug c++/68489] arrays of flexible array members are silently accepted

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #2 from Nathan Sidwell  ---
*** Bug 78635 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #13 from James Greenhalgh  ---
(In reply to Segher Boessenkool from comment #12)
> It still happens here, also on gcc110.  Note you need --disable-werror,
> to avoid another bootstrap error.
> 
> Did you perchance use --disable-bootstrap?

I didn't need disable-werror either, which makes me think I'm building a
completely different toolchain to you.

Maybe I'm missing something very obvious?

All I'm doing is cloning from the git mirror, checking out the revisions we've
discussed here and on IRC, creating a new folder out of tree, running
configure, then running make -j41.

  ssh gcc110.fsffrance.org
  git clone git://gcc.gnu.org/git/gcc.git
  cd gcc
  git checkout 
  mkdir ../build-gcc
  cd ../build-gcc
  ../gcc/configure --enable-languages=all,ada,go,obj-c++
  make -j41 >& build.log

And that works for me.

If I'm missing a step or an environment variable, I'm happy to try again.

[Bug fortran/77903] [F08] gfortran 6.1.0/7.0.0 accept invalid code with conflicting module/submodule interfaces

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

  Attachment #40256|0   |1
is obsolete||

--- Comment #11 from Paul Thomas  ---
Created attachment 40257
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40257=edit
It helps to attach the right patch!

duuh!

[Bug fortran/77903] [F08] gfortran 6.1.0/7.0.0 accept invalid code with conflicting module/submodule interfaces

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

  Attachment #40237|0   |1
is obsolete||

--- Comment #10 from Paul Thomas  ---
Created attachment 40256
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40256=edit
An infinitely better fix

This one bootstraps and regtests OK.

Will submit in a couple of minutes.

Paul

[Bug c++/78621] lambda mangling not ABI compliant

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Created attachment 40255
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40255=edit
squangling too

This testcase shows problems with the mangling of auto parms themeselves, and
with subsequent fallout of squangling references.  The two forwarding function
instantiations should mangle similarly (with 'i'->'Da' substitution), but they
mangle quite differently.

[Bug rtl-optimization/78561] Constant pool size (offset) can become stale where constant pool entires become unused

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
It still happens here, also on gcc110.  Note you need --disable-werror,
to avoid another bootstrap error.

Did you perchance use --disable-bootstrap?

[Bug tree-optimization/78687] New: inefficient code generated for eggs.variant

[vanyacpp at gmail dot com]

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

Bug ID: 78687
   Summary: inefficient code generated for eggs.variant
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Created attachment 40254
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40254=edit
gcc-eggs-variant-missing-opt.cpp

I have a piece of code that actively uses library called Eggs.Variant. It is a
library that implements C++17-like variant class. Profiling of this piece of
code revealed that the generated code for the most expensive function is quite
inefficient. Here is the generated code (with percentage of time spent in each
instruction and my comments):

 Percent |  Source code & Disassembly of a.out for cycles:pp

 :  ref_proxy f()
 :  {
0.00 :400710:   sub$0x140,%rsp
0.00 :400717:   mov%rdi,%rax
1.54 :40071a:   movq   $0x2,0x28(%rdi)
0.00 :400722:   movl   $0x0,0x128(%rsp)
   22.36 :40072d:   mov0x128(%rsp),%rdx
!!! reading of stack memory immediately after writing to it
1.63 :400735:   mov%rdx,0xe8(%rsp)
0.00 :40073d:   movl   $0x0,0xe8(%rsp)
!!! writing 0 immediately after writing some other value to it
   22.74 :400748:   mov0xe8(%rsp),%rdx
1.59 :400750:   mov%rdx,0xa8(%rsp)
0.00 :400758:   movl   $0x0,0xa8(%rsp)
   22.72 :400763:   mov0xa8(%rsp),%rdx
!!! writing 0 immediately after writing some other value to it, then reading
from it
2.16 :40076b:   mov%rdx,0x128(%rsp)
0.00 :400773:   mov-0x78(%rsp),%rdx
0.00 :400778:   movl   $0x0,0x128(%rsp)
!!! writing some value to stack memory, then writing 0 to it
0.01 :400783:   mov%rdx,(%rdi)
1.66 :400786:   mov-0x70(%rsp),%rdx
0.00 :40078b:   mov%rdx,0x8(%rdi)
0.00 :40078f:   mov-0x68(%rsp),%rdx
0.01 :400794:   mov%rdx,0x10(%rdi)
1.72 :400798:   mov-0x60(%rsp),%rdx
0.00 :40079d:   mov%rdx,0x18(%rdi)
0.00 :4007a1:   mov-0x58(%rsp),%rdx
0.02 :4007a6:   mov%rdx,0x20(%rdi)
   20.15 :4007aa:   mov0x128(%rsp),%rdx
!!! again reading stack memory where 0 was written several instruction ago
1.68 :4007b2:   mov%rdx,0x30(%rdi)
0.00 :4007b6:   add$0x140,%rsp
0.00 :4007bd:   retq   

Initially I thought that there must be some aliasing issue. But the memory
accessed is the memory of local variables. The program doesn't use volatile
qualifier either. And aliasing does not explain why compiler did two writes to
the same memory location in a row. As you can see this function does not little
more than copying data from one memory location to another.

It turned out that clang generates much better code for the function:

 Percent |  Source code & Disassembly of a.out for cycles:pp

   31.86 :400670:   movq   $0x2,0x28(%rdi)
   32.27 :400678:   movl   $0x0,0x30(%rdi)
0.23 :40067f:   mov%rdi,%rax
   35.65 :400682:   retq   

Unfortunately I didn't manage to make a small snippet to reproduce the issue.
The attached file is quite big (about 500 lines long), still I hope it allows
reproducing the issue.

The command line I used is:
g++ -pthread -Wall -O2 -g -DNDEBUG -fvisibility=hidden -std=gnu++14
gcc-eggs-variant-missing-opt.cpp

The compiler version was 6.2.

[Bug fortran/65173] ICE while compiling wrong code

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #9)
> Another example, together with LANG=de_DE.UTF-8 :
> 
> 
> $ cat zz1.f90
> program p
>type t
>   character, allocatable :: z1(:), z1(:)
>end type
> end
> 
> 
> $ gfortran-7-20161204 -m32 zz1.f90
> zz1.f90:3:37-44:
> 
>character, allocatable :: z1(:), z1(:)
>  2  1
> Error: Component »z1« at (1) already declared at (2)
> f951: internal compiler error: Speicherzugriffsfehler
> 0xc4940f crash_signal
> ../../gcc/toplev.c:333
> 0x6f3aea gfc_resolve_expr(gfc_expr*)
> ../../gcc/fortran/resolve.c:6465

(gdb) bt
(gdb) bt
#0  gfc_is_constant_expr (e=0x837f) at ../../gcc7/gcc/fortran/expr.c:894
#1  0x0065a320 in resolve_component (c=0x20365f8c0, sym=0x203635f00)
at ../../gcc7/gcc/fortran/resolve.c:13507
#2  0x0065a9ab in resolve_fl_derived0 (sym=sym@entry=0x203635f00)
at ../../gcc7/gcc/fortran/resolve.c:13738
...
(gdb) up
#1  0x0065a320 in resolve_component (c=0x20365f8c0, sym=0x203635f00)
at ../../gcc7/gcc/fortran/resolve.c:13507
13507|| !gfc_is_constant_expr (c->ts.u.cl->length))
(gdb) p *c->ts.u.cl
$5 = {length = 0x837f, next = 0x20362b5d0, length_from_typespec = false, 
  backend_decl = 0x2039d8040, passed_length = 0x0, resolved = 56844672}

length=0x837f is an invalid pointer.  So, gfortran ICE's.  This 
looks similar to the fight that Janus waged this weekend.  For
some reason, a CHARACTER(LEN=) component in a derived type
does not set the length correctly.

[Bug target/72742] [7 Regression] ICE in extract_insn, at recog.c:2309 (error: unrecognizable insn) w/ -Os -mlra

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-05
 CC||aldyh at gcc dot gnu.org,
   ||bergner at gcc dot gnu.org,
   ||rguenther at suse dot de,
   ||vmakarov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
Confirmed.  Started with the commit below, though I doubt it has anything to do
with generic changes to the compiler. It looks like an LRA/backend problem.

commit 410372fef14173261ce8e547db98eafb3174921f
Author: rguenth 
Date:   Thu May 19 07:39:52 2016 +

2016-05-19  Richard Biener  

PR tree-optimization/70729
* passes.def: Move LIM pass before PRE.  Remove no longer
required copyprop and move first DCE out of the loop pipeline.

* gcc.dg/autopar/outer-6.c: Adjust to avoid redundant store.
* gcc.dg/graphite/scop-18.c: Likewise.
* gcc.dg/pr41783.c: Disable LIM.
* gcc.dg/tree-ssa/loadpre10.c: Likewise.
* gcc.dg/tree-ssa/loadpre23.c: Likewise.
* gcc.dg/tree-ssa/loadpre24.c: Likewise.
* gcc.dg/tree-ssa/loadpre25.c: Likewise.
* gcc.dg/tree-ssa/loadpre4.c: Likewise.
* gcc.dg/tree-ssa/loadpre8.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-16.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-18.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-20.c: Likewise.
* gcc.dg/tree-ssa/ssa-pre-3.c: Likewise.
* gfortran.dg/pr42108.f90: Likewise.

[Bug c++/78647] ICE on invalid C++ code on x86_64-linux-gnu (internal compiler error: tree check: expected tree_list, have error_mark in get_attribute_name, at attribs.c:664)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-05
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

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

[Bug tree-optimization/78681] [7 Regressions] ICE in determine_value_range, at tree-ssa-loop-niter.c:413

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Yeah:
--- gcc/ipa-prop.c.jj   2016-11-25 18:11:05.0 +0100
+++ gcc/ipa-prop.c  2016-12-05 18:48:48.853882864 +0100
@@ -5709,8 +5709,23 @@ ipcp_update_vr (struct cgraph_node *node
{
  tree type = TREE_TYPE (ddef);
  unsigned prec = TYPE_PRECISION (type);
+ unsigned mprec = wi::get_precision (vr[i].min);
+ gcc_assert (mprec == wi::get_precision (vr[i].max));
  if (INTEGRAL_TYPE_P (TREE_TYPE (ddef)))
{
+ if (prec < mprec)
+   {
+ /* If there is a disagreement between callers and callee
+on the argument type, e.g. when using K function
+definitions, punt if vr[i].min or vr[i].max are outside
+of type's precision.  */
+ wide_int m = wi::ext (vr[i].min, prec, TYPE_SIGN (type));
+ if (m != vr[i].min)
+   continue;
+ m = wi::ext (vr[i].max, prec, TYPE_SIGN (type));
+ if (m != vr[i].max)
+   continue;
+   }
  if (dump_file)
{
  fprintf (dump_file, "Setting value range of param %u ", i);
@@ -5729,6 +5744,7 @@ ipcp_update_vr (struct cgraph_node *node
}
  else if (POINTER_TYPE_P (TREE_TYPE (ddef))
   && vr[i].type == VR_ANTI_RANGE
+  && mprec <= prec
   && wi::eq_p (vr[i].min, 0)
   && wi::eq_p (vr[i].max, 0))
{
works for me (i.e. if the callers expect higher precision and the range doesn't
fit into the smaller type, punt).
Not sure if one can construct a testcase where prec == mprec, but the
signedness differ (either vr[i].min/vr[i].max is from signed type and type is
unsigned, or vice versa).  Tried:
static void foo (int, unsigned int);

static int
foo (x, y)
  unsigned int x;
  int y;
{
  return x + y;
}

void
bar (int x, unsigned int y)
{
  if (x < - __INT_MAX__ + 3 || x >= __INT_MAX__ - 19)
return;
  if (y < 5 || y >= ~19U)
return;
  x++;
  y++;
  foo (x, y);
  x++;
  y++;
  foo (x, y);
}

but that is rejected.

[Bug tree-optimization/78681] [7 Regressions] ICE in determine_value_range, at tree-ssa-loop-niter.c:413

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Seems like j_16(D) ends up having VR_RANGE [127, 126].  This range seems to
come from ipcp_update_vr.

[Bug c/78666] conflicting attribute alloc_size accepted

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
And nonnull, sentinel, destructor, constructor too.

[Bug c/78666] conflicting attribute alloc_size accepted

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
diagnose_mismatched_attributes should diagnose this -- it needs to look at
TYPE_ATTRIBUTES, too.  At least assume_aligned and alloc_align should be
diagnosed, too.

[Bug target/71721] uclinux posix threads

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Fixed by Waldemar's patch on the trunk.

[Bug target/71721] uclinux posix threads

[law at gcc dot gnu.org]

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

--- Comment #1 from Jeffrey A. Law  ---
Author: law
Date: Mon Dec  5 17:49:41 2016
New Revision: 243269

URL: https://gcc.gnu.org/viewcvs?rev=243269=gcc=rev
Log:
PR target/71721
* config.gcc (*-*-uclinux*): Enable posix threads.
Adding BZ marker

Modified:
trunk/gcc/ChangeLog

[Bug target/71607] [5/6/7 Regression] [ARM] ice due to forbidden enabled attribute dependency on instruction operands

[avieira at gcc dot gnu.org]

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

--- Comment #8 from avieira at gcc dot gnu.org ---
Author: avieira
Date: Mon Dec  5 17:36:03 2016
New Revision: 243266

URL: https://gcc.gnu.org/viewcvs?rev=243266=gcc=rev
Log:
[ARM] PR71607: New approach to arm_disable_literal_pool

gcc/ChangeLog.arm:
2016-12-05  Andre Vieira  

PR target/71607
* config/arm/arm.md (use_literal_pool): Removes.
(64-bit immediate split): No longer takes cost into consideration
if 'arm_disable_literal_pool' is enabled.
* config/arm/arm.c (arm_use_blocks_for_constant_p): New.
(TARGET_USE_BLOCKS_FOR_CONSTANT_P): Define.
(arm_max_const_double_inline_cost): Remove use of
arm_disable_literal_pool.
* config/arm/vfp.md (no_literal_pool_df_immediate): New.
(no_literal_pool_sf_immediate): New.

gcc/testsuite/ChangeLog.arm:
2016-12-05  Andre Vieira  
Thomas Preud'homme  

PR target/71607
* gcc.target/arm/thumb2-slow-flash-data.c: Renamed to ...
* gcc.target/arm/thumb2-slow-flash-data-1.c: ... this.
* gcc.target/arm/thumb2-slow-flash-data-2.c: New.
* gcc.target/arm/thumb2-slow-flash-data-3.c: New.
* gcc.target/arm/thumb2-slow-flash-data-4.c: New.
* gcc.target/arm/thumb2-slow-flash-data-5.c: New.


Added:
   
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-1.c
   
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-2.c
   
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-3.c
   
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-4.c
   
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data-5.c
Removed:
   
branches/ARM/embedded-6-branch/gcc/testsuite/gcc.target/arm/thumb2-slow-flash-data.c
Modified:
branches/ARM/embedded-6-branch/gcc/ChangeLog.arm
branches/ARM/embedded-6-branch/gcc/config/arm/arm.c
branches/ARM/embedded-6-branch/gcc/config/arm/arm.md
branches/ARM/embedded-6-branch/gcc/config/arm/vfp.md
branches/ARM/embedded-6-branch/gcc/testsuite/ChangeLog.arm

[Bug fortran/78682] ICE calling (locally) a TBP of a remote CAF derived type

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|WAITING |RESOLVED
 CC||janus at gcc dot gnu.org
  Known to work||7.0
 Resolution|--- |FIXED
   Target Milestone|--- |7.0
  Known to fail||5.4.1, 6.2.1

--- Comment #3 from janus at gcc dot gnu.org ---
I see the ICE with 5.4.1 and 6.2.0, but I can confirm that it is gone on
current trunk.

For which reason do you think the code is invalid?

[Bug tree-optimization/78646] incorrect result type for pointer addition in slsr

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-05
 Ever confirmed|0   |1

--- Comment #7 from Bill Schmidt  ---
Confirmed with a powerpc64le->x86_64 cross.  The suggested patch looks correct
to me.  Will regtest it shortly.  Thanks for the report!

[Bug fortran/78686] ICE in gfc_apply_init, at fortran/expr.c:4124

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

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

--- Comment #1 from Gerhard Steinmetz  
---

Whereas, for example with "real" :


$ cat z2.f90
program p
   type t
  real :: c(1) = [t()]
   end type
end


$ gfortran-7-20161204 z2.f90
z2.f90:3:20:

   real :: c(1) = [t()]
1
Error: Can't convert TYPE(t) to REAL(4) at (1)

[Bug middle-end/35361] Missing IPA DCE and DSE

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
This was fixed a couple years ago:
Author: hubicka 
Date:   Fri May 16 17:49:06 2014 +

* varpool.c (dump_varpool_node): Dump write-only flag.
* lto-cgraph.c (lto_output_varpool_node, input_varpool_node): Stream
write-only flag.
* tree-cfg.c (execute_fixup_cfg): Remove statements setting write-only
variables.


* gcc.c-torture/execute/20101011-1.c: Update testcase.
* gcc.dg/ira-shrinkwrap-prep-1.c: Update testcase.
* gcc.dg/tree-ssa/writeonly.c: New testcase.
* gcc.dg/tree-ssa/ssa-dse-6.c: Update testcase.
* gcc.dg/tree-ssa/pr21559.c: Update testcase.
* gcc.dg/debug/pr35154.c: Update testcase.
* gcc.target/i386/vectorize1.c: Update testcase.
* ipa.c (process_references): New function.
(set_readonly_bit): New function.
(set_writeonly_bit): New function.
(clear_addressable_bit): New function.
(ipa_discover_readonly_nonaddressable_var): Mark write only variables;
fix
handling of aliases.
* cgraph.h (struct varpool_node): Add writeonly flag.

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

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

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

--- Comment #7 from Gerhard Steinmetz  
---
Sequence changed, still ok :

$ cat zz3.f90
program p
   character(3) :: c1(2) = ['b', 'c'] // ''
   character(3) :: c2(2) = ['b', 'c'] // 'a'
   character(3) :: c3(2) = ['b', 'c'] // 'ax'
   character(3) :: c4(2) = ['b', 'c'] // 'axy'
   print *, size(c1), len(c1), c1
   print *, size(c2), len(c2), c2
   print *, size(c3), len(c3), c3
   print *, size(c4), len(c4), c4
end

$ gfortran-7-20161204 zz3.f90
$ a.out
   2   3 b  c
   2   3 ba ca
   2   3 baxcax
   2   3 baxcax

---


Similar, embedded :

$ cat zz4.f90
program p
   type t
  character(3) :: c1(2) = ['b', 'c'] // ''
  character(3) :: c2(2) = ['b', 'c'] // 'a'
  character(3) :: c3(2) = ['b', 'c'] // 'ax'
  character(3) :: c4(2) = ['b', 'c'] // 'axy'
   end type
   type(t) :: z
   print *, size(z%c1), len(z%c1), z%c1
   print *, size(z%c2), len(z%c2), z%c2
   print *, size(z%c3), len(z%c3), z%c3
   print *, size(z%c4), len(z%c4), z%c4
end

$ gfortran-7-20161204 zz4.f90
zz4.f90:13:0:

 end

internal compiler error: in output_constructor_regular_field, at varasm.c:5017
0xf3fcc4 output_constructor_regular_field
../../gcc/varasm.c:5017
0xf3fcc4 output_constructor
../../gcc/varasm.c:5325
0xf3e7c1 output_constant
../../gcc/varasm.c:4702
0xf3e7c1 output_constructor_regular_field
../../gcc/varasm.c:5055
0xf3e7c1 output_constructor
../../gcc/varasm.c:5325
0xf40064 output_constant
../../gcc/varasm.c:4702
0xf40064 assemble_variable_contents
../../gcc/varasm.c:2083
0xf479c9 assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2259
0xf4d1e8 varpool_node::assemble_decl()
../../gcc/varpool.c:588
0xf4de75 varpool_node::assemble_decl()
../../gcc/cgraph.h:2631
0xf4de75 symbol_table::output_variables()
../../gcc/varpool.c:754
0x855a77 symbol_table::compile()
../../gcc/cgraphunit.c:2495
0x857ea2 symbol_table::compile()
../../gcc/cgraphunit.c:2558
0x857ea2 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2584

[Bug fortran/78686] New: ICE in gfc_apply_init, at fortran/expr.c:4124

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

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

Bug ID: 78686
   Summary: ICE in gfc_apply_init, at fortran/expr.c:4124
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code, down to at least 4.8 :


$ cat z1.f90
program p
   type t
  character :: c(1) = [t()]
   end type
end


$ gfortran-7-20161204 z1.f90
f951: internal compiler error: in gfc_apply_init, at fortran/expr.c:4124
0x6911be gfc_apply_init(gfc_typespec*, symbol_attribute*, gfc_expr*)
../../gcc/fortran/expr.c:4124
0x684d98 build_struct
../../gcc/fortran/decl.c:1942
0x684d98 variable_decl
../../gcc/fortran/decl.c:2437
0x684d98 gfc_match_data_decl()
../../gcc/fortran/decl.c:4892
0x6dca79 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6e002e match_word
../../gcc/fortran/parse.c:377
0x6e002e decode_statement
../../gcc/fortran/parse.c:377
0x6e1e34 next_free
../../gcc/fortran/parse.c:1180
0x6e1e34 next_statement
../../gcc/fortran/parse.c:1413
0x6e337a parse_derived
../../gcc/fortran/parse.c:3233
0x6e337a parse_spec
../../gcc/fortran/parse.c:3773
0x6e5bb3 parse_progunit
../../gcc/fortran/parse.c:5615
0x6e71a4 gfc_parse_file()
../../gcc/fortran/parse.c:6124
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug fortran/65173] ICE while compiling wrong code

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

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

--- Comment #9 from Gerhard Steinmetz  
---
Another example, together with LANG=de_DE.UTF-8 :


$ cat zz1.f90
program p
   type t
  character, allocatable :: z1(:), z1(:)
   end type
end


$ gfortran-7-20161204 -m32 zz1.f90
zz1.f90:3:37-44:

   character, allocatable :: z1(:), z1(:)
 2  1
Error: Component »z1« at (1) already declared at (2)
f951: internal compiler error: Speicherzugriffsfehler
0xc4940f crash_signal
../../gcc/toplev.c:333
0x6f3aea gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6465
0x6f3e45 resolve_operator
../../gcc/fortran/resolve.c:3639
0x6f3e45 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6475
0x6f6f08 resolve_index_expr
../../gcc/fortran/resolve.c:11379
0x6f6f74 resolve_charlen
../../gcc/fortran/resolve.c:11424
0x702da8 resolve_charlen
../../gcc/fortran/resolve.c:13580
0x702da8 resolve_component
../../gcc/fortran/resolve.c:13506
0x702f0a resolve_fl_derived0
../../gcc/fortran/resolve.c:13738
0x7032d7 resolve_fl_derived0
../../gcc/fortran/resolve.c:13122
0x7032d7 resolve_fl_derived
../../gcc/fortran/resolve.c:13815
0x6fe0a7 resolve_symbol
../../gcc/fortran/resolve.c:14146
0x71825b do_traverse_symtree
../../gcc/fortran/symbol.c:3994
0x70125a resolve_types
../../gcc/fortran/resolve.c:15948
0x6fcdac gfc_resolve(gfc_namespace*)
../../gcc/fortran/resolve.c:16061
0x6e71fa resolve_all_program_units
../../gcc/fortran/parse.c:5977
0x6e71fa gfc_parse_file()
../../gcc/fortran/parse.c:6224
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
But verify_rtx_sharing also has:

case CLOBBER:
  /* Share clobbers of hard registers (like cc0), but do not share pseudo
reg
 clobbers or clobbers of hard registers that originated as pseudos.
 This is needed to allow safe register renaming.  */
  if (REG_P (XEXP (x, 0)) && REGNO (XEXP (x, 0)) < FIRST_PSEUDO_REGISTER
  && ORIGINAL_REGNO (XEXP (x, 0)) == REGNO (XEXP (x, 0)))
return;
  break;

So why doesn't it return?  Has ORIGINAL_REGNO changed on the hard reg?

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
It's copy_insn_1:

case CLOBBER:
  /* Share clobbers of hard registers (like cc0), but do not share pseudo
reg
 clobbers or clobbers of hard registers that originated as pseudos.
 This is needed to allow safe register renaming.  */
  if (REG_P (XEXP (orig, 0)) && REGNO (XEXP (orig, 0)) <
FIRST_PSEUDO_REGISTER
  && ORIGINAL_REGNO (XEXP (orig, 0)) == REGNO (XEXP (orig, 0)))
return orig;

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

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

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

Gerhard Steinmetz  changed:

   What|Removed |Added

Version|5.2.1   |7.0

--- Comment #6 from Gerhard Steinmetz  
---
Valid code :

$ cat zz1.f90
program p
   character(3) :: c1(2) = '' // ['b', 'c']
   character(3) :: c2(2) = 'a' // ['b', 'c']
   character(3) :: c3(2) = 'ax' // ['b', 'c']
   character(3) :: c4(2) = 'axy' // ['b', 'c']
   print *, size(c1), len(c1), c1
   print *, size(c2), len(c2), c2
   print *, size(c3), len(c3), c3
   print *, size(c4), len(c4), c4
end

$ gfortran-7-20161204 zz1.f90
$ a.out
   2   3 b  c
   2   3 ab ac
   2   3 axbaxc
   2   3 axyaxy

---


Similar, embedded in a type :

$ cat zz2.f90
program p
   type t
  character(3) :: c1(2) = '' // ['b', 'c']
  character(3) :: c2(2) = 'a' // ['b', 'c']
  character(3) :: c3(2) = 'ax' // ['b', 'c']
  character(3) :: c4(2) = 'axy' // ['b', 'c']
   end type
   type(t) :: z
   print *, size(z%c1), len(z%c1), z%c1
   print *, size(z%c2), len(z%c2), z%c2
   print *, size(z%c3), len(z%c3), z%c3
   print *, size(z%c4), len(z%c4), z%c4
end

$ gfortran-7-20161204 zz2.f90
zz2.f90:13:0:

 end

internal compiler error: in output_constructor_regular_field, at varasm.c:5017
0xf3fcc4 output_constructor_regular_field
../../gcc/varasm.c:5017
0xf3fcc4 output_constructor
../../gcc/varasm.c:5325
0xf3e7c1 output_constant
../../gcc/varasm.c:4702
0xf3e7c1 output_constructor_regular_field
../../gcc/varasm.c:5055
0xf3e7c1 output_constructor
../../gcc/varasm.c:5325
0xf40064 output_constant
../../gcc/varasm.c:4702
0xf40064 assemble_variable_contents
../../gcc/varasm.c:2083
0xf479c9 assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2259
0xf4d1e8 varpool_node::assemble_decl()
../../gcc/varpool.c:588
0x85501b output_in_order
../../gcc/cgraphunit.c:2248
0x8553ed symbol_table::compile()
../../gcc/cgraphunit.c:2488
0x857ea2 symbol_table::compile()
../../gcc/cgraphunit.c:2558
0x857ea2 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2584

[Bug middle-end/78548] [7 Regression ]ICE on valid C code on x86_64-linux-gnu at -O2 and -O3 in 64-bit mode with -Wall (*** Error in `/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1': d

[aldyh at gcc dot gnu.org]

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

--- Comment #7 from Aldy Hernandez  ---
The following patch has been approved to fix this:

https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00039.html

But it depends on the approval pending patch for pr78566.

[Bug fortran/78570] ICE in free_expr0, at fortran/expr.c:494

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

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

Gerhard Steinmetz  changed:

   What|Removed |Added

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

--- Comment #3 from Gerhard Steinmetz  
---
> The code is supposed to be valid, I guess?
It's valid, and effectively covered via pr68155.

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

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

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

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

--- Comment #5 from Gerhard Steinmetz  
---
*** Bug 78570 has been marked as a duplicate of this bug. ***

[Bug fortran/68155] ICE on initializing character array in type (len_lhs <> len_rhs)

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

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

--- Comment #4 from Gerhard Steinmetz  
---
Update, new backtrace :


$ gfortran-7-20161127 z1t.f90
z1t.f90:3:28:

   character(2) :: z(1) = '' // ['y']
1
Warning: CHARACTER expression at (1) is being truncated (2/1)
[-Wcharacter-truncation]
f951: internal compiler error: free_expr0(): Bad expr type
0x68ea6f gfc_internal_error(char const*, ...)
../../gcc/fortran/error.c:1327
0x68f7cb free_expr0
../../gcc/fortran/expr.c:494
0x68f81d gfc_free_expr(gfc_expr*)
../../gcc/fortran/expr.c:513
0x71b273 gfc_free_charlen(gfc_charlen*, gfc_charlen*)
../../gcc/fortran/symbol.c:3840
0x71b349 gfc_free_namespace(gfc_namespace*)
../../gcc/fortran/symbol.c:3890
0x71b89c gfc_symbol_done_2()
../../gcc/fortran/symbol.c:3926
0x6c33d8 gfc_done_2()
../../gcc/fortran/misc.c:264
0x6e61f6 translate_all_program_units
../../gcc/fortran/parse.c:6057
0x6e61f6 gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x729ee2 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

---


Different ICEs using LANG=de_DE.UTF-8, for example :

$ gfortran-7-20161204 -O2 -fcheck=all z1t.f90
f951: internal compiler error: Speicherzugriffsfehler
0xc4940f crash_signal
../../gcc/toplev.c:333
0x856200 process_function_and_variable_attributes
../../gcc/cgraphunit.c:726
0x856200 analyze_functions
../../gcc/cgraphunit.c:1029
0x857e28 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2562

[Bug rtl-optimization/78652] [7 regression]LRA generates wrong code by inheriting changed register

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
Indeed, it was fixed by that.  I will a test for this and then close.

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
It's apparently the bbro pass.  Fixing.

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
So in what other insn does the clobber appear and which pass introduced it?
Easiest is to
b error
run
then notice the address passed to verify_rtx_sharing and put a breakpoint on
verify_rtx_sharing conditional on orig == $ (of course only in the
same verify_rtl_sharing call).

[Bug debug/78685] New: -Og generates too many ""s

[eggert at gnu dot org]

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

Bug ID: 78685
   Summary: -Og generates too many ""s
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---
  Host: x86-64

Created attachment 40253
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40253=edit
preprocessed C program illustrating -Og problem

Emacs developers are having trouble using -Og to debug Emacs, and so are still
using -O0; see, for example:

http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00199.html

I reproduced the problem and came up with a small program (attached) that
illustrates it. Here's a sample transcript on Fedora 24 x86-64, which uses gcc
(GCC) 6.2.1 20160916 (Red Hat 6.2.1-2):

$ gcc -Og -g3 Ogbug.i
$ gdb a.out
GNU gdb (GDB) Fedora 7.11.1-86.fc24
...
Reading symbols from a.out...done.
(gdb) b call_debugger
Breakpoint 1 at 0x4004d6: file Ogbug.i, line 6.
(gdb) r
Starting program: /home/eggert/junk/a.out 

Breakpoint 1, call_debugger (x=3) at Ogbug.i:6
6 v = x;
(gdb) bt
#0  call_debugger (x=3) at Ogbug.i:6
#1  0x00400519 in apply_lambda (fun=1, args=2, count=)
at Ogbug.i:14
#2  0x00400547 in main (argc=, argv=)
at Ogbug.i:22


It's hard to debug a program with all those ""s getting in the
way.

[Bug rtl-optimization/78652] [7 regression]LRA generates wrong code by inheriting changed register

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
Looks like Vlad already fixed this @ below commit:

commit 6526e1b66785b76d71926b20c9eb299e74a2d255
Author: vmakarov 
Date:   Wed Nov 30 17:35:40 2016 +

2016-11-30  Vladimir Makarov  

PR tree-optimization/77856
* lra-constraints.c (inherit_in_ebb): Check original regno for
invalid invariant regs too.  Set only clobbered hard regs for the
invalid invariant regs.

2016-11-30  Vladimir Makarov  

PR tree-optimization/77856
* gcc.target/i386.c (pr77856.c): New.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@243038
138bc75d-0d04-0410-961f-82ee72b054a4


I will double check and close this PR.

Thanks.

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #7 from Eric Botcazou  ---
Never mind, I can reproduce with 20070121.c:

eric@polaris:~/build/gcc/sparc-sun-solaris2.10> gcc/cc1 -quiet 20070121.c -O3
20070121.c: In function 'add234_internal':
20070121.c:18:1: error: invalid rtl sharing found in the insn
 }
 ^
(insn 195 29 194 (clobber (reg/i:SI 8 %o0 [24])) "20070121.c":18 -1
 (nil))
20070121.c:18:1: error: shared rtx
(clobber (reg/i:SI 8 %o0 [24]))
20070121.c:18:1: internal compiler error: internal consistency failure

[Bug middle-end/78684] New: [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074

[doko at gcc dot gnu.org]

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

Bug ID: 78684
   Summary: [7 Regression] ICE in
create_intersect_range_checks_index, at
tree-vect-loop-manip.c:2074
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with r243108 on x86_64-linux-gnu, works with -O2.

$ cat RapMapMapper.ii
class a {
public:
  a(long);
  void operator<<=(long) {
long b;
for (unsigned long c; c; c--)
  d[c + b] = d[c];
  }
  a ();
  long d[28];
};
long e;
int f;
void j() {
  a h(e), i = h;
  i.g() <<= f;
}

$ g++ -std=c++11 -c -march=broadwell -g -O3 RapMapMapper.ii
RapMapMapper.ii: In function 'void j()':
RapMapMapper.ii:14:6: internal compiler error: in
create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
 void j() {
  ^
0xcdb7be create_intersect_range_checks_index
../../src/gcc/tree-vect-loop-manip.c:2073
0xcdb7be create_intersect_range_checks
../../src/gcc/tree-vect-loop-manip.c:2131
0xcdb7be vect_create_cond_for_alias_checks(_loop_vec_info*, tree_node**)
../../src/gcc/tree-vect-loop-manip.c:2219
0xcdbf7c vect_loop_versioning(_loop_vec_info*, unsigned int, bool)
../../src/gcc/tree-vect-loop-manip.c:2293
0xccc064 vect_transform_loop(_loop_vec_info*)
../../src/gcc/tree-vect-loop.c:6773
0xce8d62 vectorize_loops()
../../src/gcc/tree-vectorizer.c:621
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug tree-optimization/49599] FRE/DSE not performing well on aggregates

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
This was fixed a little over a year ago:
Author: alalaw01 
Date:   Fri Sep 18 10:55:11 2015 +

completely_scalarize arrays as well as records.

gcc/:

PR tree-optimization/67283
* tree-sra.c (type_consists_of_records_p): Rename to...
(scalarizable_type_p): ...this, add case for ARRAY_TYPE.
(completely_scalarize_record): Rename to...
(completely_scalarize): ...this, add ARRAY_TYPE case, move some code
to:
(scalarize_elem): New.
(analyze_all_variable_accesses): Follow renamings.

gcc/testsuite/:

* gcc.dg/tree-ssa/sra-15.c: New.
* gcc.dg/tree-ssa/sra-16.c: New.

[Bug fortran/78226] Fill out location information everywhere

[vehre at gcc dot gnu.org]

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

--- Comment #11 from vehre at gcc dot gnu.org ---
Please ignore my previous unqualified comment. I had applied you patch on a git
branch and based my own in that, but failed to merge yours into mine. Doing so
immediately gave the errors.

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
I cannot reproduce on native and valgrind doesn't complain.  Can you attach the
first RTL dump which contains the problematic insn?

(insn 196 94 197 (clobber (reg/i:SI 8 %o0 [24]))

[Bug target/78683] [ppc] __builtin_ctlz code gen can be improved for -mcpu=power8 and earlier

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Target||powerpc*-*-*
 CC||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug target/78683] New: [ppc] __builtin_ctlz code gen can be improved for -mcpu=power8 and earlier

[wschmidt at gcc dot gnu.org]

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

Bug ID: 78683
   Summary: [ppc] __builtin_ctlz code gen can be improved for
-mcpu=power8 and earlier
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

For this code:

unsigned r; r = (unsigned) __builtin_ctzl(v); return r;

GCC on POWER produces:

 neg 9,3
 and 3,9,3
 cntlzd 3,3
 subfic 3,3,63
 rldicl 3,3,0,32

Two other compilers produce the following sequences:

 addi 4, 3, -1
 andc 3, 4, 3
 popcntd 3, 3

or

 addi   r0,r3,-1
 andc   r0,r0,r3
 cntlzd r0,r0
 subfic r3,r0,64

We should probably be using the short and elegant popcntd solution.

[Bug fortran/78682] ICE calling (locally) a TBP of a remote CAF derived type

[stefano.zaghi at cnr dot it]

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

--- Comment #2 from Stefano Zaghi  ---
(In reply to Dominique d'Humieres from comment #1)
> This seems to have been fixed on trunk (7.0), likely r238007.

Dear Dominique, thank you for your fast replay. I can check this tomorrow after
a fresh download/build of the 7.0 trunk.

My best regards.

[Bug fortran/78682] ICE calling (locally) a TBP of a remote CAF derived type

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-05
 CC||afanfa at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
This seems to have been fixed on trunk (7.0), likely r238007.

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[nathan at gcc dot gnu.org]

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

--- Comment #5 from Nathan Sidwell  ---
r231665 lost the diagnostic

+2015-12-15  Martin Sebor  
+
+   c++/42121
+   * tree-chkp.c (chkp_find_bound_slots_1): Handle flexible array
+   members.
+   * tree.c (type_contains_placeholder_1): Avoid assuming type has
+   a non-null domain or an upper bound to handle flexible array
+   members.
+   * varasm.c (output_constructor_regular_field):  Same.
+   (output_constructor): Set min_index to integer_zero_node rather
+   than null when a type has no domain to avoid crashing later.
+

[Bug fortran/78682] New: ICE calling (locally) a TBP of a remote CAF derived type

[stefano.zaghi at cnr dot it]

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

Bug ID: 78682
   Summary: ICE calling (locally) a TBP of a remote CAF derived
type
   Product: gcc
   Version: 6.2.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 40252
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40252=edit
the MCVE reproducing the ICE

Dear all,

I get an ICE when I try to call (locally) a type-bound-procedure of
derived-type coarray on a remote image, see the attached MCVE. 

I know that very very probably my code is invalid with respect the current
standard, but because with GNU gfortran 6.2.1 I obtain the following Internal
Compiler Error, I would like to let you know.

Compilation/Error results

gfortran -fcoarray=lib gfortran_ice_caf.f90
gfortran_ice_caf.f90:31:0:

   if (this_image()==2) call core_caf[1]%core_value_print

internal compiler error: in gfc_get_tree_for_caf_expr, at
fortran/trans-expr.c:1818
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Architecture details

Linux 4.8.8-2-ARCH #1 SMP PREEMPT Thu Nov 17 14:51:03 CET 2016 x86_64 GNU/Linux

Intel(R) Xeon(R) CPU X5650@2.67GHz

GNU Fortran (GCC) 6.2.1 20160830 

My best regards.

P.S. thank you very very much for your work, you are my superheroes!

[Bug fortran/78676] [5/6/7 Regression] Optimizer bug with -ftree-vrp exposed by program with many bit operations

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #8)
> (In reply to janus from comment #4)
> > This seems to be a regression that started with version 4.9. In 4.7 and 4.8
> > I see the same results with all optimization levels.
> 
> It is not a regression.  It is invalid code, so the compiler can generate
> whatever results it wants.  Fortran does not have an unsigned integer
> type, which KISS requires.
> 
>   13.7.1 General
> 
>   Detailed specifications of the standard generic intrinsic
>   procedures are provided in 13.7 in alphabetical order.
> 
>   The types and type parameters of standard intrinsic procedure
>   arguments and function results are determined by these specifications.
>   The "Argument(s)" paragraphs specify requirements on the actual
>   arguments of the procedures.  The result characteristics are sometimes
>   specified in terms of the characteristics of dummy arguments.
>   A program is prohibited from invoking an intrinsic procedure under
>   circumstances where a value to be returned in a subroutine argument or
>   function result is outside the range of values representable by objects
>   of the specified type and type parameters, unless ... (stuff about IEEE). 
> 
>   13.3 Bit model
> 
>   13.3.1 General
> 
>   ... (stuff about nonnegative integers) ...
> 
>   The interpretation of a negative integer as a sequence of bits is
>   processor dependent.
> 
>   13.7.78 IEOR (I, J)
>   
>   ... (stuff about IEOR) ...
> 
>   The model for the interpretation of an integer value as a sequence of
>   bits is in 13.3.
> 
>   13.7.84 ISHFT (I, SHIFT)
> 
>   ... (stuff about ISHFT) ...
> 
>   The model for the interpretation of an integer value as a sequence of
>   bits is in 13.3.
> 
> OP has three options.  1) Change his/her code to use INTEGER(8) for 
> intermediate computations.  Results can then be converted to 
> INTEGER(4) by "mod(result, HUGE(I))".  2) Use ISO C binding to call
> a C implementation of KISS.  3) Use -fwrapv as indicated in comment #1.
> 
> BTW, until very recently, gfortran used 4 independent KISS generators
> for random_number. BUt, that implementation was done in C.

I forgot

  7.1.5.2.4 Evaluation of numeric intrinsic operations

  The execution of any numeric operation whose result is not defined
  by the arithmetic used by the processor is prohibited.

So, the programmer is prohibited from using the addition and
multiplication operators if/when the result of the operation
would overflow (or require wrap-around semantics).

[Bug tree-optimization/57361] Remove self memory assignment

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Fixed long ago...

[Bug fortran/78226] Fill out location information everywhere

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #10 from vehre at gcc dot gnu.org ---
Hi Thomas,

allow me a stupid question: I have applied your patch and added
--enable-checking=yes to configure when preping gfortran. Compiling and
regression testing shows no regressions. 

/configure --disable-multilib --enable-languages=c,fortran,c++
--enable-stage1-languages=fortran --enable-libgfortran --enable-checking=yes
--prefix=/home/vehre/Projekte/gfortran/ CFLAGS='-g -O0
-DENABLE_ASSERT_CHECKING' CXXFLAGS='-g -O0' 'STAGE1_CFLAGS=-g -O0
-DENABLE_ASSERT_CHECKING' 'STAGE1_CXXFLAGS=-g -O0'

What am I doing wrong? Or are there no more regressions when the patch is
applied?

- Andre

[Bug fortran/70244] [OOP] ICE in spec_dimen_size(): Bad dimension

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[OOP] ICE spec_dimen_size() |[OOP] ICE in
   |Bad dimension   |spec_dimen_size(): Bad
   ||dimension

--- Comment #2 from janus at gcc dot gnu.org ---
Slightly reduced test case:


module mymodule
implicit none
type :: deriv_t
contains
procedure :: fun
end type
type :: base_a
class(deriv_t), allocatable :: obj
end type
contains
function fun( self ) result( val )
class(deriv_t), intent(in) :: self
real, dimension(:,:), allocatable :: val
end function
end module

program bug
use mymodule
implicit none
type(base_a), dimension(1) :: e
real, dimension(:,:), allocatable :: m
allocate( deriv_t :: e(1)%obj )
m = e(1)%obj%fun()
end


Backtrace with current trunk:

f951: internal compiler error: spec_dimen_size(): Bad dimension
0x7de01e gfc_internal_error(char const*, ...)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/error.c:1328
0x7a3453 spec_dimen_size(gfc_array_spec*, int, __mpz_struct (*) [1])
/home/jweil/gcc/gcc7/trunk/gcc/fortran/array.c:2148
0x7a3ea8 gfc_array_dimen_size(gfc_expr*, int, __mpz_struct (*) [1])
/home/jweil/gcc/gcc7/trunk/gcc/fortran/array.c:2423
0x7e4a5d gfc_check_conformance(gfc_expr*, gfc_expr*, char const*, ...)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/expr.c:3103
0x7e4fe5 gfc_check_assign(gfc_expr*, gfc_expr*, int, bool)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/expr.c:3244
0x87dae6 resolve_ordinary_assign
/home/jweil/gcc/gcc7/trunk/gcc/fortran/resolve.c:10101
0x87f97b gfc_resolve_code(gfc_code*, gfc_namespace*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/resolve.c:10919
0x88ca24 resolve_codes
/home/jweil/gcc/gcc7/trunk/gcc/fortran/resolve.c:16028
0x88cb71 gfc_resolve(gfc_namespace*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/resolve.c:16063
0x85d493 resolve_all_program_units
/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:5977
0x85dcaf gfc_parse_file()
/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6224
0x8b6fea gfc_be_parse_file
/home/jweil/gcc/gcc7/trunk/gcc/fortran/f95-lang.c:202

[Bug libstdc++/66414] string::find ten times slower than strstr

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
This patch would implement the requested change:

--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -2291,9 +2291,28 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
*  it begins.  If not found, returns npos.
   */
   size_type
-  find(const _CharT* __s, size_type __pos = 0) const
+  find(const _CharT* __s, size_type __pos = 0) const _GLIBCXX_NOEXCEPT
   {
__glibcxx_requires_string(__s);
+   if (__are_same<_Traits, char_traits<_CharT>>::__value)
+ {
+   if (__are_same<_CharT, char>::__value)
+ {
+   const char* __data = (const char*)data();
+   const char* __p
+ = __builtin_strstr(__data + __pos, (const char*)__s);
+   return __p ? (__p - __data) : npos;
+ }
+#if _GLIBCXX_USE_WCHAR_T
+   else if (__are_same<_CharT, wchar_t>::__value)
+ {
+   const wchar_t* __data = (const wchar_t*)data();
+   const wchar_t* __p
+ = __builtin_wcsstr(__data + __pos, (const wchar_t*)__s);
+   return __p ? (__p - __data) : npos;
+ }
+#endif
+ }
return this->find(__s, __pos, traits_type::length(__s));
   }


But it causes a huge regression in this example, where currently it is hundreds
of times faster than strstr:

#include 
#include 
#include 
#include 
#include 

int main()
{
  std::string haystack(5000, 'a');
  std::string needle = haystack;
  needle.back() = 'b';
  std::size_t pos[1000];

  auto start = std::chrono::high_resolution_clock::now();
  for (auto& p : pos)
p = haystack.find(needle.c_str());
  auto stop = std::chrono::high_resolution_clock::now();
  std::cout << (stop - start).count() << std::endl;
  for (auto p : pos)
assert(p == std::string::npos);

  start = std::chrono::high_resolution_clock::now();
  for (auto& p : pos)
  {
auto ptr = std::strstr(haystack.c_str(), needle.c_str());
p = ptr ? ptr - haystack.c_str() : std::string::npos;
  }
  stop = std::chrono::high_resolution_clock::now();
  std::cout << (stop - start).count() << std::endl;
  for (auto p : pos)
assert(p == std::string::npos);
}

This is because the current code uses char_traits::length() (i.e. strlen)
first, so if the needle is longer than the haystack we don't bother looking for
it.

I don't think it's clear that using strstr is an improvement.

The C++17 library provides Boyer-Moore and Boyer-Moore-Horspool searchers, so
that already offers you more control than basic_string::find or strstr.

[Bug fortran/78676] [5/6/7 Regression] Optimizer bug with -ftree-vrp exposed by program with many bit operations

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to janus from comment #4)
> This seems to be a regression that started with version 4.9. In 4.7 and 4.8
> I see the same results with all optimization levels.

It is not a regression.  It is invalid code, so the compiler can generate
whatever results it wants.  Fortran does not have an unsigned integer
type, which KISS requires.

  13.7.1 General

  Detailed specifications of the standard generic intrinsic
  procedures are provided in 13.7 in alphabetical order.

  The types and type parameters of standard intrinsic procedure
  arguments and function results are determined by these specifications.
  The "Argument(s)" paragraphs specify requirements on the actual
  arguments of the procedures.  The result characteristics are sometimes
  specified in terms of the characteristics of dummy arguments.
  A program is prohibited from invoking an intrinsic procedure under
  circumstances where a value to be returned in a subroutine argument or
  function result is outside the range of values representable by objects
  of the specified type and type parameters, unless ... (stuff about IEEE). 

  13.3 Bit model

  13.3.1 General

  ... (stuff about nonnegative integers) ...

  The interpretation of a negative integer as a sequence of bits is
  processor dependent.

  13.7.78 IEOR (I, J)

  ... (stuff about IEOR) ...

  The model for the interpretation of an integer value as a sequence of
  bits is in 13.3.

  13.7.84 ISHFT (I, SHIFT)

  ... (stuff about ISHFT) ...

  The model for the interpretation of an integer value as a sequence of
  bits is in 13.3.

OP has three options.  1) Change his/her code to use INTEGER(8) for 
intermediate computations.  Results can then be converted to 
INTEGER(4) by "mod(result, HUGE(I))".  2) Use ISO C binding to call
a C implementation of KISS.  3) Use -fwrapv as indicated in comment #1.

BTW, until very recently, gfortran used 4 independent KISS generators
for random_number. BUt, that implementation was done in C.

[Bug tree-optimization/78681] [7 Regressions] ICE in determine_value_range, at tree-ssa-loop-niter.c:413

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
We shouldn't ICE on this, but otherwise, garbage in, garbage out.  The
prototype doesn't match the K definition.

Slightly cleaned up testcase:

struct S { char b; };
char d, e, f, l, m;
struct S n;
int bar (char, char);
static void foo (struct S *, int, int, int, int);

static void
foo (x, g, h, i, j)
  struct S *x;
  char g, h, i, j;
{
  char k;
  for (k = 0; k <= j; k++)
if (bar (g, k))
  for (; i; k++)
if (d)
  x->b = g;
}

void
baz (int q)
{
  foo (, m, l, f, 1);
  foo (, m, e, f, e - 1);
}

It is enough if just one argument disagrees (e.g. the int vs. char on just j,
not all the others).

[Bug tree-optimization/78681] [7 Regressions] ICE in determine_value_range, at tree-ssa-loop-niter.c:413

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-05
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

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

[Bug rtl-optimization/78652] [7 regression]LRA generates wrong code by inheriting changed register

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
I bisected and found it was caused by below change:

commit ab4ea053bf71c5571df344d5d5f5bd7ecc5ede8e
Author: vmakarov 
Date:   Tue Aug 2 16:07:36 2016 +

2016-08-02  Vladimir Makarov  

PR rtl-optimization/69847
* lra-int.h (struct lra-reg): Use restore_rtx instead of
restore_regno.
(lra_rtx_hash): New.
* lra.c (initialize_lra_reg_info_element): Use restore_rtx instead
of restore_regno.
(lra_rtx_hash): Rename and move lra-remat.c::rtx_hash.
* lra-remat.c (rtx_hash): Rename and Move to lra.c.
* lra-spills.c (lra_final_code_change): Don't delete insn when the
next insn is USE with the same reg as the current insn source.
* lra-constraints.c (curr_insn_transform): Use restore_rtx instead
of restore_regno.
(lra_constraints_init): Call initiate_invariants.
(lra_constraints_finish): Call finish_invariants.
(struct invariant, invariant_t, invariant_ptr_t): New.
(const_invariant_ptr_t, invariants, invariants_pool): New.
(invariant_table, invariant_hash, invariant_eq_p): New.
(insert_invariant, initiate_invariants, finish_invariants): New.
(clear_invariants, invalid_invariant_regs): New.
(inherit_reload_reg, split_reg, fix_bb_live_info): Use restore_rtx
instead of restore_regno.
(invariant_p, process_invariant_for_inheritance): New.
(inherit_in_ebb): Implement invariant inheritance.
(lra_inheritance): Initialize and finalize invalid_invariant_regs.
(remove_inheritance_pseudos): Implement undoing invariant
inheritance.
(undo_optional_reloads, lra_undo_inheritance): Use restore_rtx
instead of restore_regno.
* lra-assigns.c (regno_live_length): New.
(reload_pseudo_compare_func): Use regno_live_length.
(assign_by_spills): Use restore_rtx instead of restore_regno.
(lra_assign): Ditto.  Initiate regno_live_length.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@238991
138bc75d-0d04-0410-961f-82ee72b054a4

It is a big change.

[Bug c++/78635] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4989

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Note, lately lots of various PRs have been filed that started to ICE with the
r234636 change.  But it looks that usually we've just been generating silent
wrong-code or not accepts-invalid.