[Bug bootstrap/83062] [8 regression] Bootstrap failure: libsanitizer/tsan/tsan_rtl.h:713:44: error: inlining failed in call to always_inline ‘void __tsan::MemoryRead(__tsan::ThreadState*, __sanitizer:

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-20
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
trippels@gcc2-power8 tsan % cat tsan_external.ii
void __attribute__((always_inline)) fn1(int *, long, long, int) {}
typedef void AccessFunc(int *, long, long, int);
void fn2(AccessFunc p1) {
  bool a();
  p1(0, 0, 0, 0);
  fn2(fn1);
}

trippels@gcc2-power8 tsan % g++ -O3 -c tsan_external.ii
tsan_external.ii:1:37: warning: always_inline function might not be inlinable
[-Wattributes]
 void __attribute__((always_inline)) fn1(int *, long, long, int) {}
 ^~~
tsan_external.ii: In function ‘void fn2(void (*)(int*, long int, long int,
int))’:
tsan_external.ii:1:37: error: inlining failed in call to always_inline ‘void
fn1(int*, long int, long int, int)’: caller is not optimized
tsan_external.ii:5:5: note: called from here
   p1(0, 0, 0, 0);
   ~~^~~~

[Bug bootstrap/83062] New: [8 regression] Bootstrap failure: libsanitizer/tsan/tsan_rtl.h:713:44: error: inlining failed in call to always_inline ‘void __tsan::MemoryRead(__tsan::ThreadState*, __sanit

[trippels at gcc dot gnu.org]

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

Bug ID: 83062
   Summary: [8 regression] Bootstrap failure:
libsanitizer/tsan/tsan_rtl.h:713:44: error: inlining
failed in call to always_inline ‘void
__tsan::MemoryRead(__tsan::ThreadState*,
__sanitizer::uptr, __sanitizer: :uptr, int)’: caller
is not optimized
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: hubicka at ucw dot cz
  Target Milestone: ---

trippels@gcc2-power8 tsan %  /home/trippels/gcc_build_dir_/./gcc/xgcc
-shared-libgcc -B/home/trippels/gcc_build_dir_/./gcc -nostdinc++
-L/home/trippels/gcc_build_dir_/powerpc64le-
unknown-linux-gnu/libstdc++-v3/src
-L/home/trippels/gcc_build_dir_/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/trippels/gcc_build_dir_/powerpc64le-unknown-linux-g
nu/libstdc++-v3/libsupc++/.libs -B/usr/local/powerpc64le-unknown-linux-gnu/bin/
-B/usr/local/powerpc64le-unknown-linux-gnu/lib/ -isystem
/usr/local/powerpc64le-unknown-linux-gnu/i
nclude -isystem /usr/local/powerpc64le-unknown-linux-gnu/sys-include
-D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -DCAN_SANITIZE_UB
=0 -I. -I../../../../gcc/libsanitizer/tsan -I.. -I ../../../../gcc/libsanitizer
-I ../../../../gcc/libsanitizer/include -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -W
no-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer
-funwind-tables -fvisibility=hidden -Wno-variadic-macros
-I../../libstdc++-v3/include -I../../libstd
c++-v3/include/powerpc64le-unknown-linux-gnu
-I../../../../gcc/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11
-mcpu=power8 -O3 -pipe -MT tsan_external.lo -MD -MP -MF .deps/ts
an_external.Tpo -c ../../../../gcc/libsanitizer/tsan/tsan_external.cc  -fPIC
-DPIC -o .libs/tsan_external.o
In file included from ../../../../gcc/libsanitizer/tsan/tsan_external.cc:11:
../../../../gcc/libsanitizer/tsan/tsan_rtl.h: In function ‘void
__tsan::ExternalAccess(void*, void*, void*, __tsan::AccessFunc)’:
../../../../gcc/libsanitizer/tsan/tsan_rtl.h:713:20: error: inlining failed in
call to always_inline ‘void __tsan::MemoryRead(__tsan::ThreadState*,
__sanitizer::uptr, __sanitizer:
:uptr, int)’: caller is not optimized
 void ALWAYS_INLINE MemoryRead(ThreadState *thr, uptr pc,
^~
../../../../gcc/libsanitizer/tsan/tsan_external.cc:66:11: note: called from
here
 access(thr, CALLERPC, (uptr)addr, kSizeLog1);
 ~~^~
In file included from ../../../../gcc/libsanitizer/tsan/tsan_external.cc:11:
../../../../gcc/libsanitizer/tsan/tsan_rtl.h: In function ‘void
__tsan::ExternalAccess(void*, void*, void*, __tsan::AccessFunc)’:
../../../../gcc/libsanitizer/tsan/tsan_rtl.h:718:20: error: inlining failed in
call to always_inline ‘void __tsan::MemoryWrite(__tsan::ThreadState*,
__sanitizer::uptr, __sanitizer
::uptr, int)’: caller is not optimized
 void ALWAYS_INLINE MemoryWrite(ThreadState *thr, uptr pc,
^~~
../../../../gcc/libsanitizer/tsan/tsan_external.cc:66:11: note: called from
here
 access(thr, CALLERPC, (uptr)addr, kSizeLog1);
 ~~^~

Reducing...

[Bug lto/83061] New: -Wmaybe-uninitialized warnings in gcc/lto/lto-object.c

[trippels at gcc dot gnu.org]

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

Bug ID: 83061
   Summary: -Wmaybe-uninitialized warnings in gcc/lto/lto-object.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

LTO/PGO bootstrap shows:

../../gcc/gcc/lto/lto-object.c: In function ‘lto_obj_append_data’:
../../gcc/gcc/lto/lto-object.c:361:7: warning: ‘err’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
   if (err == 0)
   ^
../../gcc/gcc/lto/lto-object.c:352:7: note: ‘err’ was declared here
   int err;
   ^
../../gcc/gcc/lto/lto-object.c: In function ‘lto_obj_begin_section’:
../../gcc/gcc/lto/lto-object.c:337:7: warning: ‘err’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
   if (err == 0)
   ^
../../gcc/gcc/lto/lto-object.c:324:7: note: ‘err’ was declared here
   int err;
   ^
../../gcc/gcc/lto/lto-object.c:338:14: warning: ‘errmsg’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
  fatal_error (input_location, "%s", errmsg);
  ^
../../gcc/gcc/lto/lto-object.c:323:15: note: ‘errmsg’ was declared here
   const char *errmsg;
   ^

All of the warnings are correct.

include/simple-object.h:
159 /* Add a section to SIMPLE_OBJECT.  NAME is the name of the new 
160section.  ALIGN is the required alignment expressed as the number
161of required low-order 0 bits (e.g., 2 for alignment to a 32-bit  
162boundary).  The section is created as containing data, readable, 
163not writable, not executable, not loaded at runtime.  On error this  
164returns NULL, sets *ERRMSG to an error message, and sets *ERR to an  
165errno value or 0 if there isn't one.  */ 
166 
167 extern simple_object_write_section *
168 simple_object_write_create_section (simple_object_write *simple_object, 
169 const char *name, unsigned int align,   
170 const char **errmsg, int *err);

But libiberty/simple-object.c has:
411 simple_object_write_section *   
412 simple_object_write_create_section (simple_object_write *sobj, const char
*name,  
413 unsigned int align, 
414 const char **errmsg ATTRIBUTE_UNUSED,   
415 int *err ATTRIBUTE_UNUSED)

[Bug c++/83060] New: ICE on valid C++ code: in ignore_overflows, at cp/cvt.c:583

[su at cs dot ucdavis.edu]

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

Bug ID: 83060
   Summary: ICE on valid C++ code: in ignore_overflows, at
cp/cvt.c:583
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It affects at least all versions as early as 4.8.x.

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171119 (experimental) [trunk revision 254940] (GCC)
$
$ clang++ -c tmp.cpp
$ icc -c tmp.cpp
$
$ g++tk -c tmp.cpp
tmp.cpp:7:37: internal compiler error: in ignore_overflows, at cp/cvt.c:583
 int b = __builtin_offsetof (A, s[-1]);
 ^
0x72ac8d ignore_overflows
../../gcc-source-trunk/gcc/cp/cvt.c:583
0x72d428 ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc-source-trunk/gcc/cp/cvt.c:817
0x80ef06 cp_parser_builtin_offsetof
../../gcc-source-trunk/gcc/cp/parser.c:9930
0x80ef06 cp_parser_primary_expression
../../gcc-source-trunk/gcc/cp/parser.c:5335
0x8103dd cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:7022
0x82b97c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8363
0x7fafcc cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:9131
0x7fb733 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:9232
0x7fc020 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9519
0x7fd0f3 cp_parser_constant_expression
../../gcc-source-trunk/gcc/cp/parser.c:9803
0x7fd9c7 cp_parser_initializer_clause
../../gcc-source-trunk/gcc/cp/parser.c:21978
0x8007d3 cp_parser_initializer
../../gcc-source-trunk/gcc/cp/parser.c:21918
0x8268a6 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19716
0x82949f cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:13125
0x82a338 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12943
0x832674 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12840
0x831016 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12716
0x83133e cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4502
0x83133e c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:39022
0x977ee5 c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1127
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$

--

struct A
{ 
  int i;
  int s[8];
};

int b = __builtin_offsetof (A, s[-1]);

[Bug fortran/83057] OPEN(3f) without a filename and without STATUS='SCRATCH' does not produce a warning as being an extension on unassigned files

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
What is the '3f' in the post?

[Bug c++/83059] New: ICE on invalid C++ code: in tree_to_uhwi, at tree.c:6633

[su at cs dot ucdavis.edu]

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

Bug ID: 83059
   Summary: ICE on invalid C++ code: in tree_to_uhwi, at
tree.c:6633
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It seems to affect at least all versions as early as 4.8.x. 

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171119 (experimental) [trunk revision 254940] (GCC)
$
$ g++-4.8 -c tmp.cpp
tmp.cpp: In member function ‘void A::f()’:
tmp.cpp:11:54: internal compiler error: in tree_low_cst, at tree.h:4851
   __atomic_compare_exchange (, , , false, 0, -1);
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccbLk5Tw.out file, please attach this to
your bugreport.
ERROR: Cannot create report: [Errno 17] File exists:
'/var/crash/_usr_lib_gcc_x86_64-linux-gnu_4.8_cc1plus.1001.crash'
$
$ g++tk -c tmp.cpp
tmp.cpp: In member function ‘void A::f()’:
tmp.cpp:11:54: internal compiler error: in tree_to_uhwi, at tree.c:6633
   __atomic_compare_exchange (, , , false, 0, -1);
  ^
0x11376e2 tree_to_uhwi(tree_node const*)
../../gcc-source-trunk/gcc/tree.c:6633
0x92692d get_atomic_generic_size
../../gcc-source-trunk/gcc/c-family/c-common.c:6674
0x95a55a resolve_overloaded_atomic_compare_exchange
../../gcc-source-trunk/gcc/c-family/c-common.c:6834
0x95a55a resolve_overloaded_builtin(unsigned int, tree_node*, vec<tree_node*,
va_gc, vl_embed>*)
../../gcc-source-trunk/gcc/c-family/c-common.c:7075
0x8ba6ef finish_call_expr(tree_node*, vec<tree_node*, va_gc, vl_embed>**, bool,
bool, int)
../../gcc-source-trunk/gcc/cp/semantics.c:2450
0x81060c cp_parser_postfix_expression
../../gcc-source-trunk/gcc/cp/parser.c:7239
0x82b97c cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8363
0x7fafcc cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:9131
0x7fb733 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:9232
0x7fc020 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9519
0x7fc8ca cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9688
0x8001a9 cp_parser_expression_statement
../../gcc-source-trunk/gcc/cp/parser.c:11205
0x80b895 cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:11021
0x80cb9f cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:11348
0x80ccaf cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:11302
0x825490 cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:21840
0x825490 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:21875
0x825edc cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:26766
0x826ccd cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-source-trunk/gcc/cp/parser.c:26683
0x826ccd cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:19541
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$


-


class A
{ 
  void f ();
  int i;
} a;

int b;

void A::f ()
{ 
  __atomic_compare_exchange (, , , false, 0, -1);
}

[Bug c++/83058] New: ICE on C++ code with negative array index: in warn_placement_new_too_small, at cp/init.c:2666

[su at cs dot ucdavis.edu]

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

Bug ID: 83058
   Summary: ICE on C++ code with negative array index: in
warn_placement_new_too_small, at cp/init.c:2666
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This appears to be a recent regression. 

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171119 (experimental) [trunk revision 254940] (GCC)
$
$ g++-7.2.0 -c -w tmp.cpp
$ clang++ -c -w tmp.cpp
$ icc -c -w tmp.cpp
$
$ g++tk -c -w tmp.cpp
tmp.cpp: In member function ‘void B::f()’:
tmp.cpp:7:31: internal compiler error: in warn_placement_new_too_small, at
cp/init.c:2666
   void f () { new ([-1]) A (); }
   ^
0x79f563 warn_placement_new_too_small
../../gcc-source-trunk/gcc/cp/init.c:2666
0x7a858e build_new_1
../../gcc-source-trunk/gcc/cp/init.c:3209
0x7a99b8 build_new(vec<tree_node*, va_gc, vl_embed>**, tree_node*, tree_node*,
vec<tree_node*, va_gc, vl_embed>**, int, int)
../../gcc-source-trunk/gcc/cp/init.c:3678
0x81f7c6 cp_parser_new_expression
../../gcc-source-trunk/gcc/cp/parser.c:8517
0x82ba67 cp_parser_unary_expression
../../gcc-source-trunk/gcc/cp/parser.c:8223
0x7fafcc cp_parser_cast_expression
../../gcc-source-trunk/gcc/cp/parser.c:9131
0x7fb733 cp_parser_binary_expression
../../gcc-source-trunk/gcc/cp/parser.c:9232
0x7fc020 cp_parser_assignment_expression
../../gcc-source-trunk/gcc/cp/parser.c:9519
0x7fc8ca cp_parser_expression
../../gcc-source-trunk/gcc/cp/parser.c:9688
0x8001a9 cp_parser_expression_statement
../../gcc-source-trunk/gcc/cp/parser.c:11205
0x80b895 cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:11021
0x80cb9f cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:11348
0x80ccaf cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:11302
0x825490 cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:21840
0x825490 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:21875
0x825edc cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:26766
0x82b1cc cp_parser_late_parsing_for_member
../../gcc-source-trunk/gcc/cp/parser.c:27647
0x805c5e cp_parser_class_specifier_1
../../gcc-source-trunk/gcc/cp/parser.c:22729
0x807549 cp_parser_class_specifier
../../gcc-source-trunk/gcc/cp/parser.c:22755
0x807549 cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:16819
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$



void *operator new (long unsigned int, void *p) { return p; }

struct A {};

struct B
{ 
  void f () { new ([-1]) A (); }
  int d[2];
};

[Bug fortran/83057] New: OPEN(3f) without a filename and without STATUS='SCRATCH' does not produce a warning as being an extension on unassigned files

[urbanjost at comcast dot net]

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

Bug ID: 83057
   Summary: OPEN(3f) without a filename and without
STATUS='SCRATCH' does not produce a warning as being
an extension on unassigned files
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

The standard states if a unconnected file is opened with a unit but
   not with a  filename that STATUS='SCRATCH' must be supplied. If so,
   the two OPEN(3f) statements below are not standard, but no warning
   is produced. Instead, files fort.20 and fort.-10 are created. The
   program creates the files if they do not exist, and produces no errors
   if they do exist.

   I know many compilers (at least in the past) that create files with
   a default name when a unit without a FILE= specifier is used such as
   below, but it appears that is non-standard.

   So should the OPEN(3f) statements below at least produce a warning
   about being non-standard? I am using GNU Fortran (GCC) 6.4.0:

  gfortran -std=f2008 -Wall xxx.F90   

   Perhaps something like

  'Warning: GNU Fortran extension: OPEN(3f) of an unconnected file without
a filename requires STATUS='SCRATCH' be specified'

! If the NEWUNIT= specifier appears in an OPEN statement, either the
! FILE= specifier shall appear, or the STATUS= specifier shall appear
! with a value of SCRATCH. The unit identified by a NEWUNIT value shall
! not be preconnected.
!
! If the filename is omitted and the unit is not connected to a file,
! the STATUS= specifier shall be specified with a value of SCRATCH;
! in this case, the connection is made to a processor-dependent file.

open(20)
open(newunit=lun)
end

[Bug middle-end/65041] Improve -Wclobbered

[eggert at gnu dot org]

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

Paul Eggert  changed:

   What|Removed |Added

 CC||eggert at gnu dot org

--- Comment #3 from Paul Eggert  ---
The bug for a2 seems related to Bug 21161, for which we have several
near-replicas (Bug 48968, Bug 54561, Bug 61118).

[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[eggert at gnu dot org]

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

Paul Eggert  changed:

   What|Removed |Added

 CC||eggert at gnu dot org

--- Comment #12 from Paul Eggert  ---
(In reply to Yuri Gribov from comment #11)
> (In reply to Tavian Barnes from comment #10)
> > > I think it is - __cancel_arg is assigned inside a while loop
> > 
> > Specifically a do { } while(0); loop, which obviously has only one 
> > iteration.
> 
> Actually I was talking about surrounding while
> ((double)future->progress/future->total < progress)...

The variables in question do not survive from one iteration to the next of the
surrounding while loop, so they cannot contribute to a setjmp/longjmp problem.
The code looks like this:

  while ((double)future->progress/future->total < progress) {
...
void (*__cancel_routine) (void *) = (cleanup_fn);
void *__cancel_arg = (>mutex);
if (__sigsetjmp (((struct __jmp_buf_tag *) (void *)
  __cancel_buf.__cancel_jmp_buf),
 0)) {
  __cancel_routine (__cancel_arg);
  ...
}
...
  }

As the addresses of the locals do not escape and they are never assigned to
after initialization and they do not survive until the next call to
__sigsetjmp, the warnings are false alarms.

Possibly GCC is hoisting the locals out of the loop, incorrectly transforming
the above code into this:

  void (*__cancel_routine) (void *);
  void *__cancel_arg;
  while ((double)future->progress/future->total < progress) {
...
__cancel_routine = (cleanup_fn);
__cancel_arg = (>mutex);
if (__sigsetjmp (((struct __jmp_buf_tag *) (void *)
  __cancel_buf.__cancel_jmp_buf),
 0)) {
  __cancel_routine (__cancel_arg);
  ...
}
...
  }

where the warning would be valid.

Also see Bug 48968 which has similar symptoms.

[Bug c/83056] New: GCC suggests the use of previously reported undeclared identifiers when reporting new undeclared identifiers

[jamrial at gmail dot com]

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

Bug ID: 83056
   Summary: GCC suggests the use of previously reported undeclared
identifiers when reporting new undeclared identifiers
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamrial at gmail dot com
  Target Milestone: ---

$ cat suggest.c
enum {
TYPE_A,
}

int fn(void)
{
int b = TYPE_B;
int c = TYPE_C;
int d = TYPE_D;
return 0;
}

$ gcc -O3 -Wall -c suggest.c
suggest.c: In function 'fn':
suggest.c:7:13: error: 'TYPE_B' undeclared (first use in this function); did
you mean 'TYPE_A'?
 int b = TYPE_B;
 ^~
 TYPE_A
suggest.c:7:13: note: each undeclared identifier is reported only once for each
function it appears in
suggest.c:8:13: error: 'TYPE_C' undeclared (first use in this function); did
you mean 'TYPE_B'?
 int c = TYPE_C;
 ^~
 TYPE_B
suggest.c:9:13: error: 'TYPE_D' undeclared (first use in this function); did
you mean 'TYPE_C'?
 int d = TYPE_D;
 ^~
 TYPE_C

For some reason, for every new undeclared identifier gcc suggest to use a
previously reported (but apparently similar) undeclared identifier.
Shouldn't it always suggest TYPE_A, the only defined identifier?

[Bug ada/83027] Hang when attaching a SIGINT handler

[porton at narod dot ru]

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

--- Comment #16 from Victor Porton  ---
I've discovered that Ahven source uses tasking.

So it is most likely some tasking problem with Ahven.

[Bug tree-optimization/83053] [8 Regression] ICE in vrp_prop::check_array_ref at cc/tree-vrp.c:4811

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
I can't reproduce the ICE with the current top of trunk.  My output is below. 
Running GCC through Valgrind also doesn't show any unexpected errors.  I do see
a ton of test suite failures with this build, though.

$ /opt/notnfs/msebor/build/gcc-git/gcc/gfortran -B
/opt/notnfs/msebor/build/gcc-git/gcc -O1 -S -Wall -Warray-bounds=1
/opt/notnfs/msebor/src/gcc/git/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90
/opt/notnfs/msebor/src/gcc/git/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90:65:16:

 integer :: k
1
Warning: Unused variable ‘k’ declared at (1) [-Wunused-variable]
/opt/notnfs/msebor/src/gcc/git/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90:129:0:

 end function lower_sortable

Warning: ‘__result_lower_sortable’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
/opt/notnfs/msebor/src/gcc/git/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90:121:0:

 logical function lower_sortable( op1, op2 )

note: ‘__result_lower_sortable’ was declared here

[Bug ipa/83001] [8 Regression] ICE in edge_badness, at ipa-inline.c:1025

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
Fixed.

[Bug target/81362] [8 regression] FAIL: gcc.dg/vect/no-vfa-vect-57.c execution test

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #8 from Segher Boessenkool  ---
Is this fixed now?

[Bug ada/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Sun Nov 19 22:36:25 2017
New Revision: 254940

URL: https://gcc.gnu.org/viewcvs?rev=254940=gcc=rev
Log:
PR ada/83016
* gnatlink.adb (Process_Args): Accept multiple switches for --LINK.
(Usage): Adjust.
* gcc-interface/Makefile.in (GCC_LINK): Remove $(ADA_INCLUDES).
(common-tools): Pass $(CC) as --GCC= and $(GCC_LINK) as --LINK= in
the invocations of $(GNATLINK).
(../../gnatdll$(exeext)): Likewise.
(../../vxaddr2line$(exeext)): Likewise.
(gnatmake-re): Likewise.
(gnatlink-re): Likewise.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in
trunk/gcc/ada/gnatlink.adb

[Bug ada/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #7 from Eric Botcazou  ---
.

[Bug tree-optimization/83055] New: [8 Regression] ICE in operator>, at profile-count.h:834

[marxin at gcc dot gnu.org]

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

Bug ID: 83055
   Summary: [8 Regression] ICE in operator>, at
profile-count.h:834
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---

Starting from r254888 we ICE on:

$ ~/Programming/gcc/objdir/gcc/xg++ -B ~/Programming/gcc/objdir/gcc/
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr68672-1.C -O1 
-fbranch-probabilities
during IPA pass: profile
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr68672-1.C:20:1:
internal compiler error: in operator>, at profile-count.h:834
 }
 ^
0xdbf76b profile_count::operator>(long) const
../../gcc/profile-count.h:834
0xdbf76b handle_missing_profiles()
../../gcc/predict.c:3289
0xf40fbf tree_profiling
../../gcc/tree-profile.c:750
0xf40fbf execute
../../gcc/tree-profile.c:780

[Bug ipa/83054] New: [8 Regression] ICE in operator>, at profile-count.h:823

[marxin at gcc dot gnu.org]

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

Bug ID: 83054
   Summary: [8 Regression] ICE in operator>, at
profile-count.h:823
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from r254832 we ICE on:

$ ~/Programming/gcc/objdir/gcc/xg++ -B ~/Programming/gcc/objdir/gcc/
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/gomp/pr31769.C  -O3
-Wsuggest-final-types
during IPA pass: devirt
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/gomp/pr31769.C:61:1: internal
compiler error: in operator>, at profile-count.h:834
 }
 ^
0xc9aa6b profile_count::operator>(long) const
../../gcc/profile-count.h:834
0xc9aa6b ipa_devirt
../../gcc/ipa-devirt.c:3750
0xc9aa6b execute
../../gcc/ipa-devirt.c:3892

[Bug tree-optimization/83053] New: [8 Regression] ICE in vrp_prop::check_array_ref at cc/tree-vrp.c:4811

[marxin at gcc dot gnu.org]

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

Bug ID: 83053
   Summary: [8 Regression] ICE in vrp_prop::check_array_ref at
cc/tree-vrp.c:4811
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
  Target Milestone: ---

Starting from Martin's commit r254830 we ICE on:

$ gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90
-Ofast -Warray-bounds=1 -c
during GIMPLE pass: vrp
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/actual_array_offset_1.f90:59:0:

 recursive subroutine quicksort( array )

internal compiler error: Segmentation fault
0xc1478f crash_signal
.././../gcc/toplev.c:325
0x92bed4 contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
.././../gcc/tree.h:3459
0x92bed4 wi::to_wide(tree_node const*)
.././../gcc/tree.h:5247
0xebb658 vrp_prop::check_array_ref(unsigned int, tree_node*, bool)
.././../gcc/tree-vrp.c:4811
0xecc434 vrp_prop::check_array_ref(unsigned int, tree_node*, bool)
.././../gcc/tree-vrp.c:4780
0xecc434 vrp_prop::search_for_addr_array(tree_node*, unsigned int)
.././../gcc/tree-vrp.c:4901
0xecca79 check_array_bounds
.././../gcc/tree-vrp.c:4988
0xef7003 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
.././../gcc/tree.c:11122
0x97a083 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
.././../gcc/gimple-walk.c:202
0xebca12 vrp_prop::check_all_array_refs()
.././../gcc/tree-vrp.c:5028
0xebe6bf vrp_prop::vrp_finalize(bool)
.././../gcc/tree-vrp.c:6791
0xecd3a8 execute_vrp
.././../gcc/tree-vrp.c:6864

[Bug target/83052] New: ICE in extract_insn, at recog.c:2305 starting from r254560

[marxin at gcc dot gnu.org]

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

Bug ID: 83052
   Summary: ICE in extract_insn, at recog.c:2305 starting from
r254560
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: andi-gcc at firstfloor dot org
  Target Milestone: ---

After Andi's patch we ICE on:

$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/tls/run-ld.c
-mforce-indirect-call
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/tls/run-ld.c: In
function ‘get_ld’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/tls/run-ld.c:13:1:
error: unrecognizable insn:
 }
 ^
(call_insn/u 5 2 6 2 (parallel [
(set (reg:DI 0 ax)
(call:DI (mem:QI (symbol_ref:DI ("__tls_get_addr")) [0  S1 A8])
(const_int 0 [0])))
(unspec:DI [
(symbol_ref:DI ("tls_ld") [flags 0x12] )
(reg/f:DI 7 sp)
] UNSPEC_TLS_GD)
])
"/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/tls/run-ld.c":12 -1
 (expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(nil))
during RTL pass: vregs
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/torture/tls/run-ld.c:13:1:
internal compiler error: in extract_insn, at recog.c:2305
0x5be174 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0x5be193 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:116
0xb2d9af extract_insn(rtx_insn*)
../../gcc/recog.c:2305
0x8dae81 instantiate_virtual_regs_in_insn
../../gcc/function.c:1639
0x8dae81 instantiate_virtual_regs
../../gcc/function.c:1959
0x8dae81 execute
../../gcc/function.c:2008

[Bug middle-end/83023] branch probabilities pessimize malloc

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC|mliska at suse dot cz  |marxin at gcc dot 
gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #3 from Martin Liška  ---
Thanks for report. That can be definitely improved.

[Bug ada/83027] Hang when attaching a SIGINT handler

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  ---
> It is a GCC bug rather than an Ahven bug, because the bug is triggered by
> `with Ada.Text_IO;` (and disappears if we remove this line from
> spawn-signals.adb) which should not influence semantics of the program,
> because the imported package is not used.

Maybe, but can you extract a self-contained reproducer in order to give a
definitive answer to the question?  I know nothing about this Ahven library.

[Bug target/82281] Bulldozer/Zen tuning: uses XMM for single 64-bit integer AND, even with a simple mask

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Author: hubicka
Date: Sun Nov 19 20:30:26 2017
New Revision: 254939

URL: https://gcc.gnu.org/viewcvs?rev=254939=gcc=rev
Log:
PR target/82281
* gcc.target/i386/pr82281.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr82281.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/37262] Two branches of the same condition being emitted

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #9 from Segher Boessenkool  ---
So not exactly surprising the second testcase was fixed by r251690.
This should probably not be backported.  The first testcase is fixed
everywhere.  Closing the bug now.

[Bug ipa/81360] [8 Regression] ice in estimate_edge_growth, at ipa-inline.h:86

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
Author: hubicka
Date: Sun Nov 19 19:58:12 2017
New Revision: 254937

URL: https://gcc.gnu.org/viewcvs?rev=254937=gcc=rev
Log:
PR ipa/81360
* ipa-inline.c (can_inline_edge_p): Also check that caller is optimized
* gcc.c-torture/compile/pr81360.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr81360.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78990] [6/7/8 Regression] ICE when assigning polymorphic array function result

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Sun Nov 19 19:50:50 2017
New Revision: 254936

URL: https://gcc.gnu.org/viewcvs?rev=254936=gcc=rev
Log:
2017-11-19  Paul Thomas  

PR fortran/78990
* expr.c (gfc_is_class_array_function): Renamed from
'gfc_is_alloc_class_array_function' and modified to return true
for pointers as well as allocatable results.
* gfortran.h : Change of name for prototype of above function.
* trans-array.c (gfc_add_loop_ss_code): Force finalization of
class array results.
(build_class_array_ref): Change assertion into a condition.
(build_class_array_ref): Set the se class_vptr for class array
function results.
(gfc_walk_function_expr): Reference gfc_is_class_array_function
as above.
* trans-decl.c (get_proc_result): Move it up before
gfc_trans_deferred_vars.
(gfc_trans_deferred_vars): Nullify explicit return class arrays
on entry.
* trans-expr.c (gfc_conv_class_to_class): Allow conversion of
class array functions that have an se class_vptr and use it
for the result vptr.
(gfc_conv_subref_array_arg): Rename reference to the above
function.
(gfc_conv_procedure_call): Ditto. Add the se pre block to the
loop pre block before the function is evaluated. Do not
finalize class pointer results.
(arrayfunc_assign_needs_temporary, gfc_trans_assignment_1) More
renamed references.
* trans-intrinsic.c (gfc_conv_intrinsic_size): Ditto.

2017-11-19  Paul Thomas  

PR fortran/78990
* gfortran.dg/class_67.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/class_67.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/82923] Automatic allocation of deferred length character using function result

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> Confirmed, however I see an ICE when compiling the "type" variant of pr65381.

I have forgotten to say that the ICE is similar to the one in comment 1

pr65381_red.f90:15:0:

 pure function fixedStringTable(this) result(fixed)

Error: Local declaration from a different function
D.3828
pr65381_red.f90:15:0:

 pure function fixedStringTable(this) result(fixed)

note: in statement
D.3828 = MAX_EXPR <_8, 0>;
pr65381_red.f90:15:0:

 pure function fixedStringTable(this) result(fixed)

Error: Local declaration from a different function
D.3828
pr65381_red.f90:15:0:

 pure function fixedStringTable(this) result(fixed)

note: in statement
_11 = (sizetype) D.3828;
pr65381_red.f90:15:0:

 pure function fixedStringTable(this) result(fixed)

Error: Local declaration from a different function
D.3828
pr65381_red.f90:15:0:

 pure function fixedStringTable(this) result(fixed)

note: in statement
D.3894 = (sizetype) D.3828;
pr65381_red.f90:15:0:

 pure function fixedStringTable(this) result(fixed)

Error: Local declaration from a different function
D.3828
pr65381_red.f90:26:0:

 fixed(k) = this(i)%list(j)%chars

note: in statement
D.3883 = D.3828;
during GIMPLE pass: cfg
pr65381_red.f90:15:0:

 pure function fixedStringTable(this) result(fixed)

internal compiler error: verify_gimple failed

[Bug ipa/83001] [8 Regression] ICE in edge_badness, at ipa-inline.c:1025

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
Author: hubicka
Date: Sun Nov 19 18:56:58 2017
New Revision: 254935

URL: https://gcc.gnu.org/viewcvs?rev=254935=gcc=rev
Log:

PR ipa/83001
* profile-count.c (profile_count::to_sreal_scale): Fix return value
for uninitialied counts.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/profile-count.c

[Bug ipa/60243] IPA is slow on large cgraph tree

[hubicka at gcc dot gnu.org]

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

--- Comment #19 from Jan Hubicka  ---
Author: hubicka
Date: Sun Nov 19 18:55:30 2017
New Revision: 254934

URL: https://gcc.gnu.org/viewcvs?rev=254934=gcc=rev
Log:
PR ipa/60243
* tree-inline.c (estimate_num_insns): Set to 1 at least.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-inline.c

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
Author: hubicka
Date: Sun Nov 19 18:52:54 2017
New Revision: 254933

URL: https://gcc.gnu.org/viewcvs?rev=254933=gcc=rev
Log:

PR target/82713
* i386.c (ix86_builtin_vectorization_cost): Be ready for insane
types.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr82713.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c/83011] -Wformat-truncation wrongly computes length (depends on the position of numbers in the addition)

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
(In reply to Julien ÉLIE from comment #2)

Thanks.  I can reproduce the warning with -Wstringop-truncation=2 and a small
test case:

$ cat d.c && gcc -g -O2 -S -Wall -Wformat-truncation=2
-fdump-tree-printf-return-value=/dev/stdout d.c
char* f (const char *s)
{
  __SIZE_TYPE__ n = __builtin_strlen (s) + 2;

  char *d = __builtin_malloc (n);

  __builtin_snprintf (d, n, "%s ", s);

  return d;
}

;; Function f (f, funcdef_no=0, decl_uid=1891, cgraph_uid=0, symbol_order=0)

d.c:7: __builtin_snprintf: objsize = 2, fmtstr = "%s "
  Directive 1 at offset 0: "%s"
Result: 0, 1, -1, 9223372036854775807 (0, 1, -1, -1)
  Directive 2 at offset 2: " ", length = 1
Result: 1, 1, 1, 1 (1, 2, -1, -1)
  Directive 3 at offset 3: "", length = 1
d.c: In function ‘f’:
d.c:7:29: warning: ‘__builtin_snprintf’ output may be truncated before the last
format character [-Wformat-truncation=]
   __builtin_snprintf (d, n, "%s ", s);
 ^
d.c:7:3: note: ‘__builtin_snprintf’ output 2 or more bytes (assuming 3) into a
destination of size 2
   __builtin_snprintf (d, n, "%s ", s);
   ^~~


The line "d.c:7: __builtin_snprintf: objsize = 2, fmtstr = "%s "" shows that
for the small test case, the checker assumes the size of the destination
(objsize) is 2.  In your case it assumes it's just 1.  This is actually a
feature (although admittedly not a terribly intuitive one).  At level 2, the
warning is designed to be more strict than at level 1, and avoiding it involves
essentially proving to the checker that truncation cannot happen.  Under simple
circumstances when the size of the destination buffer is constant that's
usually fairly straightforward, but in more involved ones like in the test case
where the size of the buffer is a function of a number of variables, including
the length of a string argument to a %s directive, it can be less obvious.  The
checker actually determines that the size is in some range between 1 and some
large number.  At level 1, it takes the upper bound of the range to be the
size, but at level 2, it takes the lower bound, but the output of "%s " needs
at least two bytes.  So to avoid the warning, you need to tell the checker the
buffer is bigger than 2 bytes (in your case, preferably bigger than 28 bytes,
because any less would imply the len computation wrapped around zero).  The
simplest way to do it is by adding an assertion, e.g., like so:

   len = 52 * timer_count + 27 + (prefix == NULL ? 0 : strlen(prefix)) + 1;

if (len < 28)
  __builtin_unreachable ();   // or abort()

   buf = xmalloc(len);


If you compile your test case with this change the warning disappears and you
will see the following line in the output of the
-fdump-tree-printf-return-value option:

timer.c:395: snprintf: objsize = 28, fmtstr = "%s "

indicating the checker uses 28 and the minimum size of the buffer.

Let me know if this doesn't resolve the problem for you.

[Bug ipa/83051] New: ICE on valid code at -O3: in edge_badness, at ipa-inline.c:1024

[su at cs dot ucdavis.edu]

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

Bug ID: 83051
   Summary: ICE on valid code at -O3: in edge_badness, at
ipa-inline.c:1024
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20171119 (experimental) [trunk revision 254924] (GCC)
$
$ gcctk -O2 small.c
$ gcc-7.2.0 -O3 small.c
$
$ gcctk -O3 small.c
during IPA pass: inline
small.c:30:1: internal compiler error: in edge_badness, at ipa-inline.c:1024
 }
 ^
0x1471968 edge_badness
../../gcc-source-trunk/gcc/ipa-inline.c:1023
0x1471e69 update_edge_key
../../gcc-source-trunk/gcc/ipa-inline.c:1223
0x147236e update_caller_keys
../../gcc-source-trunk/gcc/ipa-inline.c:1345
0x1474709 inline_small_functions
../../gcc-source-trunk/gcc/ipa-inline.c:2051
0x1474709 ipa_inline
../../gcc-source-trunk/gcc/ipa-inline.c:2442
0x1474709 execute
../../gcc-source-trunk/gcc/ipa-inline.c:2849
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$


--


int a[1], b, c, d, e, f, g, h;

void fn1 (int p)
{ 
  b = b >> 8 ^ a[b ^ (c & 5)] >> 8 ^ a[(b ^ c) & 5];
  b = b >> 8 ^ a[(b ^ c) & 5];
}

static void fn2 ()
{ 
  int k;
  while (1)
while (e)
  { 
while (g)
  while (h)
for (k = 0; k < 6; k++)
  while (f)
fn1 (0);
fn1 (0);
fn1 (0);
fn1 (0);
  }
}

int main ()
{ 
  fn2 ();
  return 0;
}

[Bug libfortran/82962] valgrind reports "Conditional jump or move depends on uninitialised value" in EXECUTE_COMMAND_LINE

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> Since it seems that execute_command_line always sets a return value for the
> exitstat argument, one probably does not need to check against an initial
> value at all:

Sorry, I'm afraid that's actually not true. exitstat is not being set in all
situations (e.g. for asynchronous execution, i.e. with WAIT=.false.).

Therefore the patch in comment #2 is wrong and we're back to the question from
comment #1:

> What's a suitable value for estat_initial?

[Bug c/69960] "initializer element is not constant"

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Sun Nov 19 17:17:01 2017
New Revision: 254930

URL: https://gcc.gnu.org/viewcvs?rev=254930=gcc=rev
Log:
PR c/66618
PR c/69960
c-family/
* c-common.h (c_fully_fold): Add LVAL argument defaulted to false.
c/
* c-parser.c (c_parser_omp_atomic): Pass true as LVAL to c_fully_fold
where needed.
* c-typeck.c (build_unary_op, build_modify_expr, build_asm_expr,
handle_omp_array_sections): Likewise.
(digest_init): Don't call decl_constant_value_for_optimization.
* c-tree.h (decl_constant_value_for_optimization): Removed.
* c-fold.c (c_fold_array_ref): New function.
(c_fully_fold_internal): Add LVAL argument, propagate it through
recursive calls.  For VAR_P call decl_constant_value and
unshare if not LVAL and either optimizing or IN_INIT.  Remove
decl_constant_value_for_optimization calls.  If IN_INIT and not LVAL,
fold ARRAY_REF with STRING_CST and INTEGER_CST operands.
(c_fully_fold): Add LVAL argument, pass it through to
c_fully_fold_internal.
(decl_constant_value_for_optimization): Removed.
cp/
* cp-gimplify.c (c_fully_fold): Add LVAL argument, call
cp_fold_maybe_rvalue instead of cp_fold_rvalue and pass it !LVAL.
testsuite/
* gcc.dg/pr69960.c: New test.
* gcc.dg/pr66618.c: New test.
* gcc.dg/pr66618-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr66618-2.c
trunk/gcc/testsuite/gcc.dg/pr66618.c
trunk/gcc/testsuite/gcc.dg/pr69960.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-fold.c
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-tree.h
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug c/66618] Failure to diagnose non-constant initializer for static object with -O1

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Sun Nov 19 17:17:01 2017
New Revision: 254930

URL: https://gcc.gnu.org/viewcvs?rev=254930=gcc=rev
Log:
PR c/66618
PR c/69960
c-family/
* c-common.h (c_fully_fold): Add LVAL argument defaulted to false.
c/
* c-parser.c (c_parser_omp_atomic): Pass true as LVAL to c_fully_fold
where needed.
* c-typeck.c (build_unary_op, build_modify_expr, build_asm_expr,
handle_omp_array_sections): Likewise.
(digest_init): Don't call decl_constant_value_for_optimization.
* c-tree.h (decl_constant_value_for_optimization): Removed.
* c-fold.c (c_fold_array_ref): New function.
(c_fully_fold_internal): Add LVAL argument, propagate it through
recursive calls.  For VAR_P call decl_constant_value and
unshare if not LVAL and either optimizing or IN_INIT.  Remove
decl_constant_value_for_optimization calls.  If IN_INIT and not LVAL,
fold ARRAY_REF with STRING_CST and INTEGER_CST operands.
(c_fully_fold): Add LVAL argument, pass it through to
c_fully_fold_internal.
(decl_constant_value_for_optimization): Removed.
cp/
* cp-gimplify.c (c_fully_fold): Add LVAL argument, call
cp_fold_maybe_rvalue instead of cp_fold_rvalue and pass it !LVAL.
testsuite/
* gcc.dg/pr69960.c: New test.
* gcc.dg/pr66618.c: New test.
* gcc.dg/pr66618-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr66618-2.c
trunk/gcc/testsuite/gcc.dg/pr66618.c
trunk/gcc/testsuite/gcc.dg/pr69960.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.h
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-fold.c
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-tree.h
trunk/gcc/c/c-typeck.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #28 from Dominique d'Humieres  ---
Bootstrap is fixed, but the fix did not please to Iain Sandoe.

Dominique

> Le 19 nov. 2017 à 17:40, hubicka at gcc dot gnu.org 
>  a écrit :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033
> 
> --- Comment #27 from Jan Hubicka  ---
> Is this fixed now?
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug target/80313] -march=znver1 produce worse code than -march=haswell

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #5 from Jan Hubicka  ---
Fixed on trunk.

[Bug bootstrap/81033] [8 Regression] Revision r249019 breaks bootstrap on darwin

[hubicka at gcc dot gnu.org]

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

--- Comment #27 from Jan Hubicka  ---
Is this fixed now?

[Bug ipa/81133] [8 Regression] PGO/LTO bootstrap: ICE: in inline_small_functions, at ipa-inline.c:1891

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #9 from Jan Hubicka  ---
I have disabled the sanity check because it is too bothered by roundoff errors,
so this is "fixed".

[Bug ipa/81360] [8 Regression] ice in estimate_edge_growth, at ipa-inline.h:86

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #6 from Jan Hubicka  ---
Will take a look

[Bug c++/81668] LTO ODR warnings are not helpful

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-19
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #11 from Jan Hubicka  ---
I will try to recover that patch.

[Bug c++/81668] LTO ODR warnings are not helpful

[hubicka at gcc dot gnu.org]

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

--- Comment #10 from Jan Hubicka  ---
Problem is that we do not have location info that would say us the origin.
I have sent patch to add location info into TRANSLATION_UNIT_DECL some time ago
(at least a year) but I do not think it was approved.

[Bug rtl-optimization/81791] [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4422

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #2 from Jan Hubicka  ---
Testcase works again but the unerlying problem of loop optimizer not preserving
partitioning is not solved.

[Bug rtl-optimization/81791] [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4422

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
*** Bug 82671 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/82671] [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4412

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
Dup.

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

[Bug middle-end/81812] [7/8 Regression] Empty virtual function fails to compile

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
I think we should just mark such thunks as not inlinable in compute_fn_summary.
PPatch is OK with that change.

Thanks!
Honza

[Bug target/82281] Bulldozer/Zen tuning: uses XMM for single 64-bit integer AND, even with a simple mask

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
Fixed by the tuning update.  I will add testcase.

[Bug rtl-optimization/82290] [8 Regression] ICE at -O2 on x86_64-linux-gnu: verify_flow_info failed

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
Works for  me now.

[Bug target/82682] [8 Regression] FAIL: gcc.target/i386/pr50038.c scan-assembler-times movzbl 2 (found 3 times) since r253958

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
We now generate:
 .L3:
movzbl  (%edx), %esi
addl$2, %edx
addl$1, %ecx
movzbl  -1(%edx), %eax
movl%esi, %ebx
imull   $38470, %eax, %eax
movzbl  %bl, %esi
imull   $19595, %esi, %esi
addl%esi, %eax
sarl$16, %eax
movb%al, -1(%ecx)
cmpl%edi, %edx
jne .L3

while from older gcc I get
.L3:
movzbl  (%ecx,%edx,2), %eax
movzbl  1(%ecx,%edx,2), %edi
imull   $19595, %eax, %eax
imull   $38470, %edi, %edi
addl%edi, %eax
sarl$16, %eax
movb%al, (%esi,%edx)
addl$1, %edx
cmpl%edx, %ebx
jne .L3
.L1:

There is clearly missed optimization on movzbl $bl, esi because it is already
extended. 

I wonder how this can be triggered by the move cost changes, perhaps regalloc
difference?
Jakub, it is easy for you to get .s files from  r253958 and just before?

[Bug rtl-optimization/82671] [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4412

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Jan Hubicka  ---
The testcase works for me now, but I think we need to update loop optimizer
init to preserve partitioning info?

[Bug target/82615] [8 Regression] SPEC CPU2006 453.povray ~10% performance deviation with r248863

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed|2017-10-19 00:00:00 |2017-11-19
 Ever confirmed|0   |1

--- Comment #3 from Jan Hubicka  ---
Not really no-op, just trying to reduce its scope.  Is the regression still
visible after all the profiling fixes?

[Bug target/82862] [8 Regression] SPEC CPU2006 465.tonto performance regression with r253975 (up to 40% drop for particular loop)

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-19
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jan Hubicka  ---
I am aware of this regression. Will take a look into it now.

[Bug c++/83050] Please provide shortcircuit attribute for || and && operators

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I thought we had a warning about that.  Also the semantics become different
with your attribute which I think is going to be even more problematic too.

[Bug rtl-optimization/82881] [8 Regression] ICE: in df_compact_blocks, at df-core.c:1729 with -freorder-blocks-algorithm=simple

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
The testcase works for me. I honestly hope it was fixed by one of many fixes in
the area and not just papered around.

[Bug ipa/82908] [8 regression] gcc.dg/tree-prof/cmpsf-1.c and gcc.dg/tree-prof/20050826-2.c fail starting with r254452

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #1 from Jan Hubicka  ---
https://gcc.gnu.org/ml/gcc-testresults/2017-11/msg01671.html seems clean now
and I believe those are fixed.

[Bug other/82925] [8 regression] gcc.dg/tree-ssa/vrp101.c fails starting with r254379

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
I get
;; Function main (main, funcdef_no=0, decl_uid=1892, cgraph_uid=0,
symbol_order=1) (executed once)

main ()
{
   [local count: 1073741825]:
  return 0;

}

which seems fine and vrp101 passes for me, so I am closing.

[Bug ipa/82957] [8 Regression] ICE: in to_cgraph_frequency, at profile-count.c:251

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
Fixed yesterday.

[Bug rtl-optimization/37262] Two branches of the same condition being emitted

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
This is fixed on trunk.  I'll bisect it to see if it is worth backporting.

[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #3 from Jan Hubicka  ---
I now get fir first loop:


a.c:6:5: note: Cost model analysis: 
  Vector inside of loop cost: 1120  
  Vector prologue cost: 0   
  Vector epilogue cost: 0   
  Scalar iteration cost: 328
  Scalar outside cost: 0
  Vector outside cost: 0
  prologue iterations: 0
  epilogue iterations: 0
  Calculated minimum iters for profitability: 0 
a.c:6:5: note:   Runtime profitability threshold = 4
a.c:6:5: note:   Static estimate profitability threshold = 4

For second lop I get:

a.c:20:5: note: type of def: internal   
a.c:20:5: note: mark relevant 1, live 0: sum.0_60 = (unsigned int) sum_102; 
a.c:20:5: note: worklist: examine stmt: sum.0_60 = (unsigned int) sum_102;  
a.c:20:5: note: vect_is_simple_use: operand sum_102 
a.c:20:5: note: def_stmt: sum_102 = PHI <0(6), sum_75(7)>   
a.c:20:5: note: type of def: unknown
a.c:20:5: note: Unsupported pattern.
a.c:20:5: note: not vectorized: unsupported use in stmt.
a.c:20:5: note: unexpected pattern.   

Is it really that hard to sum values in vector?  

The code does not use AVX512 regs at all.

[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Jan Hubicka  ---
I was able to reproduce it on terbium but it bootstraps fine now.  Is the
problem fixed for you?
If not, would it be possible to have -fdump-tree-all-details-blocks
-fdump-ipa-all-details for mismatching object file?

[Bug ipa/60243] IPA is slow on large cgraph tree

[hubicka at gcc dot gnu.org]

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

--- Comment #18 from Jan Hubicka  ---
Returning MIN(1, count) indeed seems like very good idea to me.  We need to
keep those in control :)

I am testing patch for that.

[Bug middle-end/83023] branch probabilities pessimize malloc

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-19
 CC||mliska at suse dot cz
 Ever confirmed|0   |1

--- Comment #2 from Jan Hubicka  ---
We get:

Predictions for bb 2
  DS theory heuristics: 53.5%   
  combined heuristics: 53.5%
  pointer (on trees) heuristics of edge 2->3: 70.0% 
  call heuristics of edge 2->3: 33.0%   

We do not know that malloc is likely returning non-NULL, but we predict with
70% that pointer is non-NULL but in the testcase this prediction is overwritten
with call heuristics.

builtin_expect code can be easily extended to handle builtins that likely
return given value. I am adding Martin to CC as this may be part of predictor
retuning this time.

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #6 from Jan Hubicka  ---
Mine.

[Bug target/82713] [8 Regression] ICE in ix86_builtin_vectorization_cost, at config/i386/i386.c:44475

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #5 from Jan Hubicka  ---
Created attachment 42655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42655=edit
Patch I am testing.

[Bug tree-optimization/83047] [8 regression] glibc/crypt/crypt_util.c gets miscompiled

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
I suspect that Jakub's store-merging changes are responsible.
-fno-store-merging fixes the problem.

[Bug target/82851] [8 regression] g++.dg/vect/slp-pr56812.cc, i386/avx2-vpaddq-3.c, i386/avx2-vpsubq-3.c fails

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #1 from Jan Hubicka  ---
These also pass for me on the top of tree. Is the problem gone now?

[Bug target/82852] [8 regression] i386/vect-unpack-1.c, i386/avx512f-gather-2.c, i386/avx256-unaligned-store-2.c fails

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #1 from Jan Hubicka  ---
I get
$ grep "vect-unpack-1" `find . -name "*.sum"`
./testsuite/gcc/gcc.sum:PASS: gcc.target/i386/vect-unpack-1.c (test for excess
errors)
./testsuite/gcc/gcc.sum:PASS: gcc.target/i386/vect-unpack-1.c execution test
./testsuite/gcc/gcc.sum:PASS: gcc.target/i386/vect-unpack-1.c
scan-assembler-times vpmovzxbw[ \\t]+[^\n]*%zmm 2

So is the problem gone now?

[Bug rtl-optimization/82849] [8 Regression] ICE on valid code since r254379

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Patch posted.
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01668.html

[Bug c++/83049] Allow overloading of ?: conditional operator

[bugzi...@poradnik-webmastera.com]

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

--- Comment #1 from Daniel Fruzynski  ---
If you decide to implement this, please also attempt to add this as an feature
to some future version of C++ standard. By doing so users of other compilers
would benefit from this too.

[Bug c++/83050] New: Please provide shortcircuit attribute for || and && operators

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 83050
   Summary: Please provide shortcircuit attribute for || and &&
operators
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

Built-int || and && operators are shortcircuiting, i.e. they may skip
evaluation of 2nd argument in some cases. However overloaded || and &&
operators do not work in this way, they always evaluate both arguments.
Sometimes it would be handy if they also could support shortcircuiting. I
propose to add new shortcircuit attribute, which could be attached to
overloaded operator:

__attribute__((shortcircuit)) T1 operator||(T2 a, T3 b);
__attribute__((shortcircuit)) T1 operator&&(T2 a, T3 b);

With such attribute gcc would generate a bit different code, e.g. something
like this:

|| operator:
if ((bool)a)
(T1)a;
else
operator||(a, b);

&& operator:
if ((bool)a)
operator&&(a, b);
else
(T1)a;

This new attribute potentially could also be attached to other overloaded
operators (+, -, ...), but I have doubts if gcc should accept this - probably
it would be better to prohibit this.

[Bug c++/83049] New: Allow overloading of ?: conditional operator

[bugzi...@poradnik-webmastera.com]

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

Bug ID: 83049
   Summary: Allow overloading of ?: conditional operator
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzi...@poradnik-webmastera.com
  Target Milestone: ---

C++ standard states than conditional operator ?: cannot be overloaded. However
things changed since this rule was created, and now there are reasons to do
this - in fact gcc provided overloaded version of this operator for vector
extensions. Ability to overload it may be useful in user code too.

One example: in the past I crested small library which was wrapping various
SIMD instructions (SSE, AVX, NEON, and scalars as a pseudo-vector with 1
element). It provided types and defines like this:

template 
class SIMDVector;

struct SSEDoubleTraits;

#ifdef __SSE2__
typedef SIMDVector DoubleVector;
#define HAS_DOUBLE_VECTOR_2 1
#define DOUBLE_VECTOR_SIZE 2
#endif

With code like above, I was able to abstract out all SIMD stuff and use
DoubleVector in code which performed actual calculations. Ability to overload
?: operator in SIMDVector<> would be helpful and make code more natural.

[Bug ipa/82903] [8 regression] gcc.dg/tree-prof/20050826-2.c fail

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #4 from Jan Hubicka  ---
I believe I fixed this bug already and reports from Andreas' tester seems
clean.

[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Jan Hubicka  ---
I am mostly done with my tuning overhaul for core+ and znver and
I plan to work on generic now in early stage3.  My rough plan is
 - drop flags that are there for benefit of anything earlier than core2 and
buldozer
 - base costs of instructions on Haswell (and later)+ZNver1 latencies, keep in
mind buldozers.
 - revisit code alignment strategies. It seems to me that by default we align
way too much for both core and Zen. Maybe code alignment does not pay back at
all for -O2 and should be done at -Ofast only or so.
 - switch instruction scheduling to more modern chip (currently we schedule for
K8).  Here I need to figure out how much core based chips care about particular
scheduler model, but I suspect both core and Zen are quite neutral here and
mostly benefit from basic scheduling for latencies.
 - figure out best vectorization model - here AVX may be a fun, because core
and znver preffers different kind of codegen. 

Ideas are welcome.

[Bug other/83048] wrap multi-statement macros in do {} while (0)

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Already done:

7fbc9a6 [riscv] Wrap ASM_OUTPUT_LABELREF in do {} while (0)
df82c70 [mips] Wrap ASM_OUTPUT_LABELREF in do {} while (0)

[Bug other/83048] New: wrap multi-statement macros in do {} while (0)

[vries at gcc dot gnu.org]

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

Bug ID: 83048
   Summary: wrap multi-statement macros in do {} while (0)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

This command:
...
$ rm -f OUTPUT; for f in $(find . -type f | egrep -v '\.git|/testsuite/'); do
echo $f; ( perl -p -e 's/\\\n//' $f| egrep "^#define.*;.*;$"| egrep -v
'case|break'); done | grep -B1 'define' > OUTPUT
...

finds some candidates for fixing, f.i. in libobjc/class.c:
...
#define CLASS_TABLE_HASH(INDEX, HASH, CLASS_NAME)  \
  HASH = 0;  \
  for (INDEX = 0; CLASS_NAME[INDEX] != '\0'; INDEX++)\
{\
  HASH = (HASH << 4) ^ (HASH >> 28) ^ CLASS_NAME[INDEX]; \
}\
 \
  HASH = (HASH ^ (HASH >> 10) ^ (HASH >> 20)) & CLASS_TABLE_MASK;
...

[Bug other/82784] Remove semicolon after "do {} while (0)" macros

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #16 from Tom de Vries  ---
Total cleanup:
...
fadadb9 [arc] Remove semicolon after do while (0) in FUNCTION_PROFILER
70b53a9 [phoenix] Remove semicolon after do {} while (0) in
TARGET_OS_CPP_BUILTINS
ab81ab7 [visium] Remove semicolon after ASM_OUTPUT_CASE_END
762da9e [ft32, spu] Remove semicolon after do {} while (0) in
REGISTER_TARGET_PRAGMAS
0fc1fb0 [mcore] Remove semicolon after do {} while (0) in MCORE_EXPORT_NAME
45fe1f4 Remove semicolon after ASM_OUTPUT_ASCII
6665982 [cr16, powerpcspe, rs6000] Remove semicolon after ASM_OUTPUT_LABELREF
macro body
4a190f0 [mips] Remove semicolon after do {} while (0) in ASM_OUTPUT_CASE_END
3a999d8 [powerpcspe] Remove semicolon after do {} while (0) in
SUBTARGET_OVERRIDE_OPTIONS
cf10ab9 [rs6000] Remove semicolon after do {} while (0) in
SUBTARGET_OVERRIDE_OPTIONS
bdcb436 [libgcc, rs6000] Remove semicolon after do {} while (0) in
REGISTER_CFA_OFFSET_FOR
47d88ce [arm] Remove semicolon after while {} do (0) in
HANDLE_NARROW_SHIFT_ARITH
1ad21ae [libgcc] Remove semicolon after do {} while (0) in FP_HANDLE_EXCEPTIONS
2467912 Remove semicolon after do {} while (0) in DEF_SANITIZER_BUILTIN
0882c4f [libcpp] Remove semicolon after do {} while (0) in BUF_APPEND
6394b15 Remove semicolon after ASM_OUTPUT_BEFORE_CASE_LABEL macro body
0944531 [fortran] Remove semicolon after do {} while (0) in match macros
fa57650 [graphite] Remove semicolon after do {} while (0) in DEBUG_PRINT
06555bd [libquadmath] Remove semicolon after do {} while (0) in
MPN_MUL_N_RECURSE
1672bf6 [libsanitizer] Remove semicolon after do {} while (0) in macro body
cace945 Remove semicolon after do {} while (false) in HSA_LOG
...

[Bug tree-optimization/83047] [8 regression] glibc/crypt/crypt_util.c gets miscompiled

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
markus@x4 crypt % gcc --save-temps crypt_util.c -c -std=gnu11 -O2 -Wall -Wundef
-Wwrite-strings -fmerge-all-constants -fno-stack-protector -frounding-math -g
-pipe -Wstrict-prototypes -Wold-style-definition -fPIC -I../include
-I/var/tmp/glibc-build/crypt -I/var/tmp/glibc-build
-I../sysdeps/unix/sysv/linux/x86_64/64 -I../sysdeps/unix/sysv/linux/x86_64
-I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/x86/nptl
-I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/x86_64/nptl
-I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux
-I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet
-I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../sysdeps/unix
-I../sysdeps/posix -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu
-I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu -I../sysdeps/x86_64
-I../sysdeps/x86 -I../sysdeps/ieee754/float128
-I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96
-I../sysdeps/ieee754/dbl-64/wordsize-64 -I../sysdeps/ieee754/dbl-64
-I../sysdeps/ieee754/flt-32 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754
-I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem
/usr/lib/gcc/x86_64-pc-linux-gnu/8.0.0/include -isystem
/usr/lib/gcc/x86_64-pc-linux-gnu/8.0.0/include-fixed -isystem /usr/include
-D_LIBC_REENTRANT -include /var/tmp/glibc-build/libc-modules.h
-DMODULE_NAME=libcrypt -include ../include/libc-symbols.h -DPIC -DSHARED
-DTOP_NAMESPACE=glibc -o /var/tmp/glibc-build/crypt/crypt_util.os -MD -MP -MF
/var/tmp/glibc-build/crypt/crypt_util.os.dt -MT
/var/tmp/glibc-build/crypt/crypt_util.os

[Bug tree-optimization/83047] [8 regression] glibc/crypt/crypt_util.c gets miscompiled

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 42654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42654=edit
unreduced testcase

[Bug tree-optimization/83047] New: [8 regression] glibc/crypt/crypt_util.c gets miscompiled

[trippels at gcc dot gnu.org]

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

Bug ID: 83047
   Summary: [8 regression] glibc/crypt/crypt_util.c gets
miscompiled
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jsm28 at gcc dot gnu.org
  Target Milestone: ---

Glibc's crypt/crypt_util.c gets miscopmiled with gcc-8:

markus@x4 ~ % LD_PRELOAD=/var/tmp/glibc-build/crypt/libcrypt.so gdb
/var/tmp/glibc-build/crypt/badsalttest
Reading symbols from /var/tmp/glibc-build/crypt/badsalttest...done. 
(gdb) run   
Starting program: /home/markus/tmp/glibc-build/crypt/badsalttest
[New process 1418]  

Thread 2.1 "badsalttest" received signal SIGSEGV, Segmentation fault.   
[Switching to process 1418] 
0x77b9ecd9 in _ufc_setup_salt_r (s=s@entry=0x77ff3fff "*",
__data=__data@entry=0x77db2160 <_ufc_foobar>) at crypt_util.c:612   
612   s0 = s[0];
(gdb) bt
#0  0x77b9ecd9 in _ufc_setup_salt_r (s=s@entry=0x77ff3fff "*",
__data=__data@entry=0x77db2160 <_ufc_foobar>) at crypt_util.c:612   
#1  0x77b9bf2f in __crypt_r (key=0x401e32 "end of page",
salt=0x77ff3fff "*", data=0x77db2160 <_ufc_foobar>) at
crypt-entry.c:109  
#2  0x004012b2 in do_test () at badsalttest.c:66
#3  0x00401c1f in run_test_function (config=0x7fffe240,
config=0x7fffe240, argv=0x7fffe378, argc=) at
support_test_main.c:158   
#4  support_test_main (argc=, argv=0x7fffe378,
config=config@entry=0x7fffe240) at support_test_main.c:349  
#5  0x004010d9 in main (argc=, argv=) at
../support/test-driver.c:164

[Bug other/82784] Remove semicolon after "do {} while (0)" macros

[vries at gcc dot gnu.org]

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

--- Comment #15 from Tom de Vries  ---
Created attachment 42653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42653=edit
conformance scan results

Output from command:

$ rm -f OUTPUT; for f in $(find . | egrep -v '\.git|/testsuite/'); do echo $f;
( perl -p -e 's/\\\n//' $f| egrep "#.*define.*while \((false|0)\);"); done |
grep -B1 'while (' > OUTPUT

The gcc/read-rtl-function.c, gcc/print-rtl-function.c and
./gcc/config/arc/arc.c are short-lived macros in combination with .def files.
We could replace "do { ... } while (0)" with "{ ... }" but I'm not sure yet
what the right approach is here.

I've submitted the libgcc/config/alpha/vms-unwind.h one (
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01661.html ) .

I've just fixed the gcc/config/arc/arc.h one (
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01663.html ).

[Bug c++/83046] ICE in nvptx offloading, C++ compilation of libgomp.oacc-c-c++-common/gang-static-2.c

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
Also, for "-foffload=disable -x c++" we now run into:

/tmp/ccAXdy3B.o:(.gnu.offload_funcs+0x0): undefined reference to
`main._omp_fn.7'
/tmp/ccAXdy3B.o:(.gnu.offload_funcs+0x8): undefined reference to
`main._omp_fn.6'
/tmp/ccAXdy3B.o:(.gnu.offload_funcs+0x10): undefined reference to
`main._omp_fn.5'
/tmp/ccAXdy3B.o:(.gnu.offload_funcs+0x18): undefined reference to
`main._omp_fn.4'
/tmp/ccAXdy3B.o:(.gnu.offload_funcs+0x20): undefined reference to
`main._omp_fn.3'
/tmp/ccAXdy3B.o:(.gnu.offload_funcs+0x28): undefined reference to
`main._omp_fn.2'
/tmp/ccAXdy3B.o:(.gnu.offload_funcs+0x30): undefined reference to
`main._omp_fn.1'
collect2: error: ld returned 1 exit status

..., which also suggests some C++ front end/middle end offloading
inconsistency.

[Bug c++/83046] ICE in nvptx offloading, C++ compilation of libgomp.oacc-c-c++-common/gang-static-2.c

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Schwinge  ---
I suggest we first analyze PR83045.

[Bug c++/83046] New: ICE in nvptx offloading, C++ compilation of libgomp.oacc-c-c++-common/gang-static-2.c

[tschwinge at gcc dot gnu.org]

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

Bug ID: 83046
   Summary: ICE in nvptx offloading, C++ compilation of
libgomp.oacc-c-c++-common/gang-static-2.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

... starting with r254437 "Instrument function exit with __builtin_unreachable
in C++".

Program received signal SIGSEGV, Segmentation fault.
input_offload_tables (do_force_output=true) at
[...]/source-gcc/gcc/lto-cgraph.c:1942
1942varpool_node::get (var_decl)->force_output = 1;
(gdb) bt
#0  input_offload_tables (do_force_output=true) at
[...]/source-gcc/gcc/lto-cgraph.c:1942
#1  0x005a0927 in read_cgraph_and_symbols (fnames=,
nfiles=) at [...]/source-gcc/gcc/lto/lto.c:2863
#2  lto_main () at [...]/source-gcc/gcc/lto/lto.c:3314
#3  0x00a7f63f in compile_file () at
[...]/source-gcc/gcc/toplev.c:455
#4  0x0056ef20 in do_compile () at
[...]/source-gcc/gcc/toplev.c:2059
#5  toplev::main (this=this@entry=0x7fffcfb0, argc=argc@entry=15,
argv=0x17908e0, argv@entry=0x7fffd0b8) at
[...]/source-gcc/gcc/toplev.c:2194
#6  0x00571457 in main (argc=15, argv=0x7fffd0b8) at
[...]/source-gcc/gcc/main.c:39

Obviously, that test case has a "-Wreturn-type mismatch" (which is not
diagnosed for C++; see reduced PR83045), and fixing that cures this nvptx
offloading ICE.

[Bug c++/83045] New: -Wreturn-type regression in C++

[tschwinge at gcc dot gnu.org]

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

Bug ID: 83045
   Summary: -Wreturn-type regression in C++
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42652
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42652=edit
rt.c

... starting with r254437 "Instrument function exit with __builtin_unreachable
in C++" (assuming that I bisected that correctly).

For "-Wreturn-type -x c" compilation of the attached rt.c, we see:

[...]/rt.c: In function 'test1':
[...]/rt.c:6:1: warning: control reaches end of non-void function
[-Wreturn-type]
 }
 ^
[...]/rt.c: In function 'test2':
[...]/rt.c:13:1: warning: control reaches end of non-void function
[-Wreturn-type]
 }
 ^

... whereas for "-Wreturn-type -x c++" compilation, we now only see:

[...]/rt.c: In function 'int test1(int)':
[...]/rt.c:6:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^

..., but used to see (and with r254437 reverted again see):

[...]/rt.c: In function 'int test1(int)':
[...]/rt.c:6:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^
[...]/rt.c: In function 'int test2(int)':
[...]/rt.c:13:1: warning: control reaches end of non-void function
[-Wreturn-type]
 }
 ^

[Bug other/81334] -Wmisleading-indentation prints notes about being disabled even when already intentionally ignored

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #2)
> It should be a matter of checking for warn_misleading_indentation at
> c-family/c-indentation.c:get_visual_column()

Oh, I guess if we already know where the fix needs to go, that's a confirmation
of the bug

[Bug other/81712] gcc does not compile when using glib 2.26 (everything works fine with 2.25)

[mikpelinux at gmail dot com]

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

--- Comment #8 from Mikael Pettersson  ---
The fix was backported to gcc-6-branch in r249957 and to gcc-5-branch in
r249958.  So it's included in gcc-5.5.0 and will be included in gcc-6.5.0.

[Bug target/82961] [6/7 Regression] ICE in dwarf2out.c: deferred_asm_name != NULL

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries  ---
Created attachment 42651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42651=edit
backport to 6 branch

The patch committed to trunk applies cleanly to gcc-7-branch, but not the
gcc-6-branch. This version of the patch applies to the gcc-6-branch.

Given the lack of build and test, I'm not committing these backports, but I'm
waiting for a go ahead from the vms maintainers (ideally with a confirmation of
build & test) or branch maintainers.

[Bug fortran/82923] Automatic allocation of deferred length character using function result

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Created attachment 42637 [details]
> Fix for the bug
>
> This one does the job and it regtests OK.

Confirmed, however I see an ICE when compiling the "type" variant of pr65381.

[Bug fortran/65381] [6/7/8 Regression] ICE during array result, assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|RESOLVED|REOPENED
   Last reconfirmed||2017-11-19
  Known to work||5.5.0
 Resolution|DUPLICATE   |---
Summary|ICE during array result,|[6/7/8 Regression] ICE
   |assignment  |during array result,
   ||assignment
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.2.0, 8.0

--- Comment #2 from Dominique d'Humieres  ---
> Duplicate of pr54070.

Compiling the original test with gfortran 6 up to trunk gives the ICE

pr65381.f90:38:0:

 strings(:) = fixedStringTable(this)

internal compiler error: Segmentation fault: 11

My instrumented gfortran gives in addition

../../work/gcc/tree.h:3125:7: runtime error: member access within null pointer
of type 'union tree_node'

The code compiles if I replace

class(StringTable), intent(IN) :: this(:)

with

type(StringTable), intent(IN) :: this(:)

[Bug fortran/83021] [7/8 Regression] gfortran segfault in polymorphic assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||juergen.reuter at desy dot de

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

[Bug fortran/83042] [7/8 regression] ICE on valid code

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #6 from Dominique d'Humieres  ---
> Could be a duplicate of pr83021: the ICE is gone if I merge the files
> in one and the ICE appears in the same range.

The ICE appears at r254428 on the 7 branch. Marked as duplicate.

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

[Bug fortran/83021] [7/8 Regression] gfortran segfault in polymorphic assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to fail||8.0

[Bug fortran/83042] [7/8 regression] ICE on valid code

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-19
 CC||pault at gcc dot gnu.org
Summary|[8.0 regression] ICE on |[7/8 regression] ICE on
   |valid code  |valid code
 Ever confirmed|0   |1

--- Comment #5 from Dominique d'Humieres  ---
Could be a duplicate of pr83021: the ICE is gone if I merge the files in one
and the ICE appears in the same range.

[Bug c/83044] New: ice in contains_struct_check

[dcb314 at hotmail dot com]

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

Bug ID: 83044
   Summary: ice in contains_struct_check
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For the following C code, compiled by recent gcc trunk and flags
-std=gnu89 -Wall -O2 -c

struct a {
  int aeadctx[0]
};
struct b {
  struct a c[0]
} d() {
  struct b a;
  e(a.c->aeadctx);
}

I get

during GIMPLE pass: vrp
bug397-min.c:6:3: internal compiler error: Segmentation fault
 } d() {
   ^
0xd3c34f crash_signal
../../trunk/gcc/toplev.c:325
0x730c44 contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
../../trunk/gcc/tree.h:3459
0x730c44 wi::to_wide(tree_node const*)
../../trunk/gcc/tree.h:5247
0xf7c67d vrp_prop::check_array_ref(unsigned int, tree_node*, bool)
../../trunk/gcc/tree-vrp.c:4811

The bug seems to occur between revisions 254826 and 254877

[Bug tree-optimization/83043] FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite "2 loops carried no dependency" 1 (found 0 times)

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz

--- Comment #4 from Tom de Vries  ---
Regressing commit: r254888.

...
commit 7ae0128a031e2fd2f324f3853560f10e604c1812
Author: hubicka 
Date:   Fri Nov 17 17:47:36 2017 +

* predict.c (determine_unlikely_bbs): Set cgraph node count to 0
when entry block was promoted unlikely.
(estimate_bb_frequencies): Increase frequency scale.
* profile-count.h (profile_count): Export precision info.
* gcc.dg/tree-ssa/dump-2.c: Fixup template for profile precision
changes.
* gcc.dg/tree-ssa/pr77445-2.c: Fixup template for profile precision
changes.


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

[Bug fortran/83021] [7/8 Regression] gfortran segfault in polymorphic assignment

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

Summary|[7/8 Regression] gfortran   |[7/8 Regression] gfortran
   |segfault|segfault in polymorphic
   ||assignment

--- Comment #7 from Dominique d'Humieres  ---
Reduced test case

module global_field_module
  use local_field_module, only : local_field
  implicit none
  private
  public :: global_field

  type global_field
private
real, allocatable :: values(:)[:]
  contains
procedure, private :: assign_local_field
generic :: assignment(=) => assign_local_field
  end type

  real :: dx
  integer, allocatable :: num_local_points
  integer, parameter:: num_end_points=2
  real :: boundary_vals(num_end_points)

contains

  subroutine assign_local_field(lhs,rhs)
class(global_field), intent(inout) :: lhs
class(local_field), intent(in) :: rhs
lhs%values(:) = rhs%state()
call synchronize()
  end subroutine

end module

[Bug tree-optimization/83043] FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite "2 loops carried no dependency" 1 (found 0 times)

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Created attachment 42649
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42649=edit
force-parallel-1.c.154t.parloops2

[Bug tree-optimization/83043] FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite "2 loops carried no dependency" 1 (found 0 times)

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Created attachment 42650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42650=edit
force-parallel-1.c.228t.optimized

[Bug tree-optimization/83043] FAIL: libgomp.graphite/force-parallel-1.c scan-tree-dump-times graphite "2 loops carried no dependency" 1 (found 0 times)

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Created attachment 42648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42648=edit
force-parallel-1.c.150t.graphite

instead of "2 loops carried no dependency" 1 we have:
...
$ grep loops force-parallel-1.c.150t.graphite 
0 loops carried no dependency.
0 loops carried no dependency.
0 loops carried no dependency.
...