[Bug tree-optimization/83523] New: [8 Regression] ICE: verify_gimple failed (error: statement marked for throw, but doesn't)

[asolokha at gmx dot com]

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

Bug ID: 83523
   Summary: [8 Regression] ICE: verify_gimple failed (error:
statement marked for throw, but doesn't)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu, powerpcspe-*-linux-gnu

gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O2 (-Os, -O3, -Ofast) -fexceptions -fnon-call-exceptions -ftrapv
for 32-bit BE powerpc targets:

void
d4 (long long int fs, int rp)
{
  int *h0;
{
  int **yf = 
  int ***wo = 

  fs = 2;
  fs *= rp;
  *h0 = 0;
}
}

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20171217 -O2 -fhandle-exceptions
-fnon-call-exceptions -ftrapv -c xvzxasob.c
xvzxasob.c: In function 'd4':
xvzxasob.c:2:1: error: statement marked for throw, but doesn't
 d4 (long long int fs, int rp)
 ^~
_6 = rp_5(D) w* 2;
during GIMPLE pass: widening_mul
xvzxasob.c:2:1: internal compiler error: verify_gimple failed
0xc8ce84 verify_gimple_in_cfg(function*, bool)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/tree-cfg.c:5537
0xb280b1 execute_function_todo
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/passes.c:1994
0xb28efc execute_todo
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/passes.c:2048

[Bug fortran/83522] New: gfortran is sometimes confused between what is an element range and what is a character range

[urbanjost at comcast dot net]

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

Bug ID: 83522
   Summary: gfortran is sometimes confused between what is an
element range and what is a character range
   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: ---

In the attachment:

 If I try to print any range of elements of the array other than all of them
 and do not specify the extent of the character range I get errors. It is
 somewhat like it is confused as to whether I am specifying the range of 
 elements or the range of characters.

 Lines commented with double-exclamations cause different kinds of errors,
 usually ICE; sometimes print the wrong strings or get segmentation faults
 depending on the LEN value.

 So if you take the attachment as-is it will run with some lines a lot like
 the commented lines. Try to uncomment the commented lines and you get ICE
 when you compile, or various run-time errors; either the wrong output or 
 run-time segfaults. There is a pattern as to what works and what does not,
 but could not quite figure it out so I left all the cases that failed in
 the example because I did not want to over-simplify what I was seeing, but ...

 I think it is all the same problem, but I cannot even compile this program:

  program testit
  character(len=:),allocatable :: strings(:)
  strings=[character(len=2) :: 'AA','BB']
  write(*,*)strings(:)(:)  !  COMPILES WITHOUT THE WRITE(3f)
  end program testit

internal compiler error: Segmentation fault
gfortran: internal compiler error: Segmentation fault (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/82666] [7/8 regression]: sum += (x>128 ? x : 0) puts the cmov on the critical path (at -O2)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80520

--- Comment #2 from Jeffrey A. Law  ---
This is another case where PRE does the right thing on a local basis, but the
result isn't well handled later in the pipeline.

Prior to PRE the key blocks look like:

 
 [ ... ]
 if (_4 > 127)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 531502203]:

   [local count: 1063004407]:
  # _17 = PHI <_4(4), 0(3)>
  iftmp.0_8 = (long long int) _17;
  sum_13 = iftmp.0_8 + sum_19;

Not surprisingly PRE realizes it can reduce the total expressions evaluated on
the path 3->5 by moving the arithmetic into bb4:

 
 [ ... ]
 if (_4 > 127)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 531502203]:
  _22 = (long long int) _4;
  _24 = sum_19 + _22;

   [local count: 1063004407]:
  # _17 = PHI <_4(4), 0(3)>
  # prephitmp_25 = PHI <_24(4), sum_19(3)>

We keep that form through the rest of the gimple optimizers and into RTL where
it turns into the problematic cmov during the first if-conversion pass.

Compiling with -fno-tree-pre gives code that I believe is equivalent to
gcc-6.x.

[Bug c++/82764] [7/8 Regression] ICE in output_constructor_regular_field, at varasm.c:5030

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  ---
Not sure about Martin's c#2.  It just reproduced on the trunk for me.  r255837

[Bug tree-optimization/79224] [7/8 Regression] Large C-Ray slowdown

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org

--- Comment #17 from Jeffrey A. Law  ---
Aldy, this might be a good one to look at as well -- mostly to see if Jan's
changes in combination with those from Yuri fixed the regression.

[Bug rtl-optimization/79405] [8 Regression] Infinite loop in fwprop

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||dmalcolm at gcc dot gnu.org

--- Comment #10 from Jeffrey A. Law  ---
Aldy, David, either of you want to take a shot at this one?

So right now we have this loop in fwprop.c:

 /* Go through all the uses.  df_uses_create will create new ones at the
 end, and we'll go through them as well.

 Do not forward propagate addresses into loops until after unrolling.
 CSE did so because it was able to fix its own mess, but we are not.  */

  for (i = 0; i < DF_USES_TABLE_SIZE (); i++)
{
  if (!propagations_left)
break;

  df_ref use = DF_USES_GET (i);
  if (use)
if (DF_REF_TYPE (use) == DF_REF_REG_USE
|| DF_REF_BB (use)->loop_father == NULL
/* The outer most loop is not really a loop.  */
|| loop_outer (DF_REF_BB (use)->loop_father) == NULL)
  forward_propagate_into (use);
}


The general consensus is that instead of walking the use table do a walk like
Richi suggests in c#9.

I think the hack we did for gcc-7 is still in the tree.  You may need to revert
that and/or roll back to a gcc-7 snapshot to get the infinite loop for testing
purposes.

[Bug tree-optimization/83521] New: [8 Regression] ICE: verify_gimple failed (error: invalid operand in unary operation)

[asolokha at gmx dot com]

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

Bug ID: 83521
   Summary: [8 Regression] ICE: verify_gimple failed (error:
invalid operand in unary operation)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O1 -fno-tree-forwprop:

int
tq (unsigned int ls, int gj)
{
  int *iz = (int *)

  return (gj == 0) ? gj : *iz;
}

% gcc-8.0.0-alpha20171217 -O1 -fno-tree-forwprop -c wslnmfya.c
wslnmfya.c: In function 'tq':
wslnmfya.c:2:1: error: invalid operand in unary operation
 tq (unsigned int ls, int gj)
 ^~
iftmp.0_1 = (int) (int) _6;
during GIMPLE pass: phiopt
wslnmfya.c:2:1: internal compiler error: verify_gimple failed
0xd71686 verify_gimple_in_cfg(function*, bool)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/tree-cfg.c:5537
0xc6625f execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/passes.c:1994
0xc66cae execute_todo
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/passes.c:2048

[Bug rtl-optimization/83398] [8 Regression] ICE: in try_ready, at haifa-sched.c:7524 with -O2 -fsched2-use-superblocks -g

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org

--- Comment #6 from Alexandre Oliva  ---
Mine.  Fixed, IIUC.  Please reopen otherwise.

[Bug other/83520] New: format string bug in libvtv

[charo.ctf at gmail dot com]

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

Bug ID: 83520
   Summary: format string bug in libvtv
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: charo.ctf at gmail dot com
  Target Milestone: ---

Description:
  On startup of a program compiled with "-fvtable-verify=std" or
  "-fvtable-verify=preinit", argv[0] is directly passed as the
  third argument of snprintf.
  This would cause memory corruption if argv[0] contains format
  specifiers like %n.

Affected version:
  gcc>=4.9 configured with --enable-vtable-verify

Technical description:
  The code below is taken from gcc-5-20171003/libvtv/vtv_rts.cc

  ==vtv_rts.cc (line 832-856)==
  static int
  dl_iterate_phdr_callback (struct dl_phdr_info *info, size_t, void *data)
  {
int * mprotect_flags = (int *) data;
off_t map_sect_offset = 0;
ElfW (Word) map_sect_len = 0;
char buffer[1024];
char program_name[1024];
const char *map_sect_name = VTV_PROTECTED_VARS_SECTION;

/* Check to see if this is the record for the Linux Virtual Dynamic
   Shared Object (linux-vdso.so.1), which exists only in memory (and
   therefore cannot be read from disk).  */

if (strcmp (info->dlpi_name, "linux-vdso.so.1") == 0)
  return 0;

if (strlen (info->dlpi_name) == 0
&& info->dlpi_addr != 0)
  return 0;

/* Get the name of the main executable.  This may or may not include
   arguments passed to the program.  Find the first space, assume it
   is the start of the argument list, and change it to a '\0'. */
snprintf (program_name, sizeof (program_name), program_invocation_name);
  =

  As we can see, there is a format string bug at the last line of
  the code above.

  According to the manpage of program_invocation_name,
  program_invocation_name is the same as the value of argv[0] of
  main(), which means that this value is user supplied.

  There is another format string bug with the same situation as
  above in read_section_offset_and_length function (line 576).

===PoC===
$ g++-vtv -v
Using built-in specs.
COLLECT_GCC=g++-vtv
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-linux-gnu/5.4.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-5-20171003/configure -v --enable-languages=c,c++
--program-suffix=-vtv --disable-multilib --enable-libstdcxx-threads
--enable-vtable-verify --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.1 20171003 (GCC)
$ cat victim.cpp
#include 
int main(){
puts("Hello world");
}
$ g++-vtv -o victim -fvtable-verify=std victim.cpp
$ ./victim
Hello world
$ ln -s ./victim ./%n
$ ./%n
Segmentation fault (core dumped)
=

[Bug debug/83419] [8 Regression] -fcompare-debug failure (length)

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #6 from Alexandre Oliva  ---
Mine.  Patch posted at https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01393.html

[Bug c/65673] Compound literal with initializer for zero-sized array drops other initializers

[stilor at att dot net]

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

--- Comment #4 from Alexey Neyman  ---
Any chance of this patch getting applied?

[Bug driver/80271] Support environment variable CLICOLOR_FORCE to enable -fdiagnostics-color

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-21
 Ever confirmed|0   |1

--- Comment #5 from Eric Gallager  ---
OK, since other people seem to want this, too, I'll confirm it.

[Bug bootstrap/83284] bootstrap comparison failure in libiberty/stack-limit.o

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Eric Gallager  ---
I can no longer reproduce this bug after updating my svn checkout to r255894. I
guess it was just a fluke...

[Bug tree-optimization/83501] [8 Regression] strlen(a) not folded after strcpy(a, "...")

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
See also bug 81703 for a similar case.

[Bug tree-optimization/81385] missing optimization involving strlen of arrays of known size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
This was implemented in r255790 (and it's a duplicate of pr78450).

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

[Bug tree-optimization/78450] strlen(s) return value can be assumed to be less than the size of s

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
*** Bug 81385 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/83519] New: missing -Wrestrict on an overlapping strcpy to a non-member array

[msebor at gcc dot gnu.org]

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

Bug ID: 83519
   Summary: missing -Wrestrict on an overlapping strcpy to a
non-member array
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Most likely due to bug 83501, while the newly enhanced -Wrestrict warning
detects the overlapping copy in function f() below, it fails to detect the same
problem in g() and h().  The strlen pass isn't prepared to handle the MEM_REF.

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout a.c
extern char* stpcpy (char*, const char*);   // work around bug 82429

struct S { char a[17]; };

void f (struct S *p, const char *s)
{
  __builtin_strcpy (p->a, "0123456789abcdef");

  __builtin_strcpy (p->a, p->a + 4);   // warning (good)
}

char a[17];

void g (const char *s)
{
  __builtin_strcpy (a, "0123456789abcdef");

  __builtin_strcpy (a, a + 4);   // missing warning (bug)
}

void h (const char *s)
{
   char a[17];

  __builtin_strcpy (a, "0123456789abcdef");

  __builtin_strcpy (a, a + 4);   // missing warning (bug)

  extern void sink (void*);
  sink (a);
}


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

a.c: In function ‘f’:
a.c:9:3: warning: ‘__builtin_strcpy’ accessing 13 bytes at offsets 0 and 4
overlaps 9 bytes at offset 4 [-Wrestrict]
   __builtin_strcpy (p->a, p->a + 4);   // warning (good)
   ^
f (struct S * p, const char * s)
{
  char[17] * _1;
  const char * _2;

   [local count: 1073741825]:
  _1 = _3(D)->a;
  __builtin_memcpy (_1, "0123456789abcdef", 17);
  _2 = [(void *)p_3(D) + 4B];
  __builtin_strcpy (_1, _2);
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1902, cgraph_uid=1, symbol_order=2)

g (const char * s)
{
   [local count: 1073741825]:
  MEM[(char * {ref-all})] = MEM[(char * {ref-all})"0123456789abcdef"];
  __builtin_strcpy (, [(void *) + 4B]);
  return;

}



;; Function h (h, funcdef_no=2, decl_uid=1905, cgraph_uid=2, symbol_order=3)

h (const char * s)
{
  char a[17];

   [local count: 1073741825]:
  MEM[(char * {ref-all})] = MEM[(char * {ref-all})"0123456789abcdef"];
  __builtin_strcpy (, [(void *) + 4B]);
  sink ();
  a ={v} {CLOBBER};
  return;

}

[Bug middle-end/83463] [8 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in builtin_memr ef, at gimple-ssa-warn

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Sebor  ---
The ICE has been fixed in r255781 so this bug can be resolved.

A patch addressing the other issues (unrelated to the ICE) discussed in comment
#4 and comment #9 has been submitted:
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01394.html

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

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
One thought would be to realize that the copy/extend sequence seen in this case
is special.  It's going to be used when the input for the extension can't be
used in an extension (ie %esi in this case).  ie, we had to emit an input
reload for the extension insn.

So when the source of the copy is the destination of the extension and the
destination of the copy is the source of the extension and the appropriate
input operands die at the copy & extension, then we could just ignore the copy
entirely and treat the extension like a (set (src) (extend
(src_in_narrow_mode))

Again, not sure how ugly that would be to model in REE, but it's one way to
think about the problem.

[Bug tree-optimization/83491] [8 Regression] ICE in execute_cse_reciprocals_1 at gcc/tree-ssa-math-opts.c:585

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/83491] [8 Regression] ICE in execute_cse_reciprocals_1 at gcc/tree-ssa-math-opts.c:585

[law at gcc dot gnu.org]

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

--- Comment #7 from Jeffrey A. Law  ---
Author: law
Date: Wed Dec 20 23:55:42 2017
New Revision: 255906

URL: https://gcc.gnu.org/viewcvs?rev=255906=gcc=rev
Log:
PR tree-optimization/83491
* tree-ssa-math-opts.c (execute_cse_reciprocals_1): Check for SSA_NAME
before walking uses.  Improve coding style and comments.

PR tree-optimization/83491
* gcc.dg/pr83491.c: Add new test.

Added:
trunk/gcc/testsuite/gcc.dg/pr83491.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-math-opts.c

[Bug ipa/83506] [8 Regression] ICE: Segmentation fault in force_nonfallthru_and_redirect

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #8 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug target/83514] ABRT in arm_declare_function_name passing a null pointer to std::string

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
> will *always* construct a -march string for the driver
  ^^
for the compiler proper

[Bug target/83514] ABRT in arm_declare_function_name passing a null pointer to std::string

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Richard Earnshaw  ---
Following the option processing rework the driver (gcc) on ARM will *always*
construct a -march string for the driver, either from the options passed by the
user or from the compiler's built-in defaults.  If you run the debugger
directly on cc1 you either need to fabricate a suitable -march string directly,
or paste one that the driver would have inserted for you.

[Bug middle-end/83463] [8 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in builtin_memr ef, at gimple-ssa-warn

[msebor at gcc dot gnu.org]

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

--- Comment #13 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #12)
> How can it have a directive for the system sprintf?

GCC should make it possible to format wide ints.  There should also be an easy
way to use the GCC pretty printer to format into a string wide int objects and
objects of other GCC data types so this kind of code wouldn't be necessary. 
Something like gcc_sprintf().

[Bug tree-optimization/83517] Missed optimization in math expression: (x+x)/x == 2

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
  (div (mult @0 @1) @1)

Maybe we are missing a :c here.

[Bug c++/59800] Compilation with g++ fails when -Ofast -flto is used to compile code using some distribution

[aes368 at cornell dot edu]

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

aes368 at cornell dot edu changed:

   What|Removed |Added

 CC||aes368 at cornell dot edu

--- Comment #5 from aes368 at cornell dot edu ---
Created attachment 42937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42937=edit
Code that causes incorrect compiler warning

This is also an issue for me. The attached code raises a warning. Changing the
loop end point from 2 to 1 makes the warning go away.

The command line used to compile is:

g++ t.cc -Wall -Ofast  -std=c++11

and the warning raised is:

t.cc: In function ‘int main()’:
t.cc:9:10: warning: ‘dist.std::normal_distribution::_M_saved’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
 v[0] = dist(generator);

This is an issue both with GCC 5.3.1 and GCC 7.2.1.

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.2.1 20171128 (GCC)

and

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.3.1-14ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2)

[Bug libstdc++/82522] std::map::insert(value_type &&) not selected

[fdumont at gcc dot gnu.org]

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

--- Comment #8 from François Dumont  ---
Author: fdumont
Date: Wed Dec 20 21:53:25 2017
New Revision: 255904

URL: https://gcc.gnu.org/viewcvs?rev=255904=gcc=rev
Log:
2017-12-20  François Dumont  

PR libstdc++/82522
* include/debug/map.h (map::insert(value_type&&))
(map::insert(const_iterator, value_type&&)): Add overload for rvalues.
* include/debug/multimap.h (multimap::insert(value_type&&))
(multimap::insert(const_iterator, value_type&&)): Likewise.
* include/debug/unordered_map (unordered_map::insert(value_type&&))
(unordered_map::insert(const_iterator, value_type&&))
(unordered_multimap::insert(value_type&&))
(unordered_multimap::insert(const_iterator, value_type&&)): Likewise.
* testsuite/23_containers/map/modifiers/insert/dr2354.cc (test02): New.
* testsuite/23_containers/multimap/modifiers/insert/dr2354.cc (test02):
New.
* testsuite/23_containers/unordered_map/insert/dr2354.cc (test02): New.
* testsuite/23_containers/unordered_multimap/insert/dr2354.cc (test02):
New.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/debug/map.h
trunk/libstdc++-v3/include/debug/multimap.h
trunk/libstdc++-v3/include/debug/unordered_map
trunk/libstdc++-v3/testsuite/23_containers/map/modifiers/insert/dr2354.cc
   
trunk/libstdc++-v3/testsuite/23_containers/multimap/modifiers/insert/dr2354.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/insert/dr2354.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/dr2354.cc

[Bug tree-optimization/83518] New: Missing optimization: useless instructions should be dropped

[zamazan4ik at tut dot by]

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

Bug ID: 83518
   Summary: Missing optimization: useless instructions should be
dropped
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zamazan4ik at tut dot by
  Target Milestone: ---

gcc (trunk) with '-O3 -std=c++17' for this code:

unsigned test()
{
int arr[] = {5,4,3,2,1};
int sum = 0;

for(int i = 0;i < 5;++i)
{
for(int j = 0; j < 5; ++j)
{
int t = arr[i];
arr[i] = arr[j];
arr[j] = t;
}
}

for(int i = 0; i < 5; ++i)
{
sum += arr[i];
}

return sum;
}


generates it:

test():
  movdqa xmm0, XMMWORD PTR .LC0[rip]
  movaps XMMWORD PTR [rsp-40], xmm0
  mov rax, QWORD PTR [rsp-32]
  mov DWORD PTR [rsp-32], 1
  mov QWORD PTR [rsp-40], rax
  mov DWORD PTR [rsp-28], 5
  movdqa xmm0, XMMWORD PTR [rsp-40]
  movdqa xmm1, xmm0
  psrldq xmm1, 8
  paddd xmm0, xmm1
  movdqa xmm1, xmm0
  psrldq xmm1, 4
  paddd xmm0, xmm1
  movd eax, xmm0
  add eax, 4
  ret
.LC0:
  .long 5
  .long 4
  .long 3
  .long 2


clang (trunk) with '-O3 -std=c++17':

test(): # @test()
  mov eax, 15
  ret

[Bug sanitizer/83356] [7 Regression] excessive stack usage compiling with -O2 -fsanitize=bounds -fsanitize=object-size

[arnd at linaro dot org]

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

--- Comment #10 from Arnd Bergmann  ---
I sent a (rather crude) workaround to the kernel mailing list now, mainly to
get the crypto maintainers involved in this as well. I also did further testing
and found that in the entire kernel, this is the only place that caused this
particular problem:

- comparing gcc-7.1.1 and gcc-7.2.1, many of the 72326 functions with >64 byte
stack usage use less stack in gcc-7.2, only the AES code uses much more

- In 30 architectures I tested, the stack frames are more than twice as big as
the second-largest function, around 2KB for 32-bit architectures and 4KB for
64-bit architectures. The only exception is aarch64, which uses only 500 bytes
here.

- There are a handful of other functions that show a very substantial stack
size increase with UBSAN (enic_rq_service() 2240 bytes,
fnic_rq_cmpl_handler_cont() 2240 bytes, dsp3780I_EnableDSP() 1016 bytes), but
all of them are the same way in older compilers as well, those are not
regressions. 

- From looking at the assembler output for the AES cipher, it appears that
gcc-7.1 and gcc-8 are both worse than gcc-6, with or without UBSAN, but only
gcc-7.2 with UBSAN is drastically worse. As mentioned in my patch description,
this needs to be tested better. There is a test module in the kernel to measure
the throughput of the AES code, but I have not tried it myself.

https://patchwork.kernel.org/patch/10126567/

[Bug tree-optimization/83517] New: Missed optimization in math expression: (x+x)/x == 2

[zamazan4ik at tut dot by]

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

Bug ID: 83517
   Summary: Missed optimization in math expression: (x+x)/x == 2
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zamazan4ik at tut dot by
  Target Milestone: ---

gcc (trunk) with '-O3 -std=c++17 -ffast-math -funsafe-math-optimizations' for
this code:

int test(int x)
{
return (x+x)/x;
}


generates:

test(int):
  lea eax, [rdi+rdi]
  cdq
  idiv edi
  ret


Why? In this case we can return simply 2. Because there are only two corner
cases: when x is 0 and we have division by zero (it's UB), and when x+x is
integer overflow (it's also UB).

So we can simply optimize it. There are a lot of similar cases.

[Bug fortran/83416] [8 Regression] Invalid rejection of association of contiguous pointer to a target

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
The lack of IS_CONTIGUOUS is PR45424

[Bug fortran/83436] Internal file cannot be accessed by UNFORMATTED data transfer when reading from /dev/urandom

[tkoenig at gcc dot gnu.org]

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

--- Comment #13 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Dec 20 20:36:22 2017
New Revision: 255902

URL: https://gcc.gnu.org/viewcvs?rev=255902=gcc=rev
Log:
2017-12-20  Thomas Koenig  

PR fortran/83436
* gfortran.dg/internal_readwrite_4.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/internal_readwrite_4.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/83516] %G interferes with format_warning_at_substring

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Created attachment 42936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42936=edit
Patch to add %G directives to gimple-ssa-sprintf.c

The attached patch for bug 83429 adds the %G directive to gimple-ssa-sprintf.c
to print the inlining context.

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

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
Of course we can't propagate because %esi doesn't have a QImode equivalent.

So to back up a little bit.  The costing changes twiddled the register
assignments.  In particular reg93 gets allocated into %esi rather than %ebx.

That in turn means we have to emit a reload to handle this insn:

(insn 19 18 20 4 (set (reg:SI 109 [ xr ])
(zero_extend:SI (reg/v:QI 93 [ xr ]))) "j.c":15 140 {*zero_extendqisi2}
 (expr_list:REG_DEAD (reg/v:QI 93 [ xr ])
(nil)))

Because we can't use %esi in QImode.  So we get:



 (insn 36 18 19 4 (set (reg/v:QI 3 bx [orig:93 xr ] [93])
(reg/v:QI 4 si [orig:93 xr ] [93])) "j.c":15 88 {*movqi_internal}
 (nil))
(insn 19 36 20 4 (set (reg:SI 4 si [orig:109 xr ] [109])
(zero_extend:SI (reg/v:QI 3 bx [orig:93 xr ] [93]))) "j.c":15 140
{*zero_extendqisi2}
 (nil))


The only reaching def for the source of the zero extend in insn 19 is insn 36,
so REE will try to turn insn 36 into:

(insn 36 18 19 4 (set (reg:SI 4 si)
(zero_extend:SI (reg/v:QI 4 si [orig:93 xr ] [93]))) "j.c":15 -1
 (nil))

Which, of course fails.  Even if it succeeded, it's not really an improvement. 
We really need to chase things back up to:

(insn 15 14 16 4 (set (reg/v:QI 4 si [orig:93 xr ] [93])
(mem:QI (reg/v/f:SI 1 dx [orig:104 in ] [104]) [0 MEM[base: in_26,
offset: 0B]+0 S1 A8])) "j.c":13 88 {*movqi_internal}
 (nil))


I don't offhand know if we can really model that in REE or not.  Though there'd
almost certainly be a general benefit to x86 in doing so.

[Bug middle-end/83516] New: %G interferes with format_warning_at_substring

[msebor at gcc dot gnu.org]

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

Bug ID: 83516
   Summary: %G interferes with format_warning_at_substring
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Bug 83429 points out a few flaws with the location information in
-Wstringop-truncation warnings (the same problems affect -Wstringop-overflow). 
A solution is to have the warning print the inlining context (i.e., make use of
the %G directive).  With that, the output for the first test case in the PR
becomes:

u.c: In function ‘void test(S*)’:
u.c:12:13: warning: ‘%s’ directive output may be truncated writing up to 9
bytes into a region of size between 5 and 14 [-Wformat-truncation=]
 snprintf(s->out, sizeof(s->out), "%s.%s", s->str1, s->str2); // line 12
 ^~~
u.c:12:13: note: ‘snprintf’ output between 2 and 20 bytes into a destination of
size 15

I.e., the warning underlines the offending snprintf call rather than the
function it appears in.

Unfortunately, the %G directive messes up underlining.  Without it, when
compiled using the C compiler (but not C++) the following test case

char a[1];

void f (void)
{
  __builtin_sprintf (a, "%i", 123);
}

prints this (notice how the %i in the format string is underlined:

u.c: In function ‘f’:
u.c:5:26: warning: ‘%i’ directive writing 3 bytes into a region of size 1
[-Wformat-overflow=]
   __builtin_sprintf (a, "%i", 123);
  ^~
u.c:5:3: note: ‘__builtin_sprintf’ output 4 bytes into a destination of size 1
   __builtin_sprintf (a, "%i", 123);
   ^~~~

While with the directive in place GCC prints this (notice that the whole call
is underlined):

u.c: In function ‘f’:
u.c:5:3: warning: ‘%i’ directive writing 3 bytes into a region of size 1
[-Wformat-overflow=]
   __builtin_sprintf (a, "%i", 123);
   ^~~~
u.c:5:3: note: ‘__builtin_sprintf’ output 4 bytes into a destination of size 1


I.e., by using %G we lose the ability to point to the format directive that
caused the overflow (or truncation).

[Bug fortran/83436] Internal file cannot be accessed by UNFORMATTED data transfer when reading from /dev/urandom

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
This also does not occur with 20171219.

So, my guess would be that this was a side-effect of one of
the recent patches, and was fixed in the meantime.

I will commit a test case and then close this as FIXED.

[Bug debug/83157] [8 regression] gcc.dg/guality/pr41616-1.c fail

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez  ---
Looks like it actually started with r247597, which AFAICT is also a change in
how we determine cloning/inlining, so perhaps a latent bug?

[Bug ipa/83506] [8 Regression] ICE: Segmentation fault in force_nonfallthru_and_redirect

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Wed Dec 20 19:41:38 2017
New Revision: 255901

URL: https://gcc.gnu.org/viewcvs?rev=255901=gcc=rev
Log:
PR ipa/83506
* ipa-fnsummary.c (pass_data_ipa_free_fn_summary): Use 0 for
todo_flags_finish.
(pass_ipa_free_fn_summary): Add small_p private data member,
initialize to false in the ctor.
(pass_ipa_free_fn_summary::clone,
pass_ipa_free_fn_summary::set_pass_param,
pass_ipa_free_fn_summary::gate): New methods.
(pass_ipa_free_fn_summary::execute): Return TODO_remove_functions
| TODO_dump_symtab if small_p.
* passes.def: Add true parm for the existing pass_ipa_free_fn_summary
entry and add another instance of the pass with false parm after
ipa-pure-const.
* ipa-pure-const.c (pass_ipa_pure_const): Don't call
ipa_free_fn_summary here.

* gcc.dg/pr83506.c: New test.
* gcc.dg/ipa/ctor-empty-1.c: Use -fdump-ipa-free-fnsummary1 instead
of -fdump-ipa-free-fnsummary and scan in free-fnsummary1 instead of
free-fnsummary dump.

Added:
trunk/gcc/testsuite/gcc.dg/pr83506.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-fnsummary.c
trunk/gcc/ipa-pure-const.c
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ipa/ctor-empty-1.c

[Bug fortran/83515] New: ICE: Invalid expression in gfc_element_size

[liakhdi at ornl dot gov]

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

Bug ID: 83515
   Summary: ICE: Invalid expression in gfc_element_size
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liakhdi at ornl dot gov
  Target Milestone: ---

Code: https://github.com/DmitryLyakh/GFC.git
To reproduce: Open Makefile, make line 138 look exactly like line 140:
NO_GNU := -DNO_GNU
Type "make"
If you need a debuggable version (-g), please change OPT to DEV in line 9.
If you need any help from me to debug the issue (we did this in the past with
Paul Thomas, but not for ICE), please let me know.

ICE description: source file gfc_vector.F90 is causing this:
gfortran -I. -I. -c -fopenmp -O3 -DNO_GPU -DNO_AMD -DNO_PHI -DLINUX -DNO_GNU
-DNO_PGI -fPIC gfc_vector.F90 -o ./OBJ/gfc_vector.o
f951: internal compiler error: Invalid expression in gfc_element_size.
0x891e7f gfc_internal_error(char const*, ...)
/home/dima/src/gcc/gcc/fortran/error.c:1358
0x922e6b gfc_element_size(gfc_expr*)
/home/dima/src/gcc/gcc/fortran/target-memory.c:126
0x8768f9 find_intrinsic_vtab
/home/dima/src/gcc/gcc/fortran/class.c:2703
0x8768f9 gfc_find_vtab(gfc_typespec*)
/home/dima/src/gcc/gcc/fortran/class.c:2846
0x8a039c compare_actual_formal
/home/dima/src/gcc/gcc/fortran/interface.c:2934
0x8a14d4 gfc_arglist_matches_symbol(gfc_actual_arglist**, gfc_symbol*)
/home/dima/src/gcc/gcc/fortran/interface.c:3797
0x905bc2 resolve_typebound_generic_call
/home/dima/src/gcc/gcc/fortran/resolve.c:6125
0x905f5e resolve_typebound_call
/home/dima/src/gcc/gcc/fortran/resolve.c:6183
0x8fa4c9 resolve_typebound_subroutine
/home/dima/src/gcc/gcc/fortran/resolve.c:6494
0x8fa4c9 gfc_resolve_code(gfc_code*, gfc_namespace*)
/home/dima/src/gcc/gcc/fortran/resolve.c:11270
0x908aab gfc_resolve_blocks(gfc_code*, gfc_namespace*)
/home/dima/src/gcc/gcc/fortran/resolve.c:10108
0x8f8fd9 gfc_resolve_code(gfc_code*, gfc_namespace*)
/home/dima/src/gcc/gcc/fortran/resolve.c:11052
0x908aab gfc_resolve_blocks(gfc_code*, gfc_namespace*)
/home/dima/src/gcc/gcc/fortran/resolve.c:10108
0x8f8fd9 gfc_resolve_code(gfc_code*, gfc_namespace*)
/home/dima/src/gcc/gcc/fortran/resolve.c:11052
0x908aab gfc_resolve_blocks(gfc_code*, gfc_namespace*)
/home/dima/src/gcc/gcc/fortran/resolve.c:10108
0x8f8fd9 gfc_resolve_code(gfc_code*, gfc_namespace*)
/home/dima/src/gcc/gcc/fortran/resolve.c:11052
0x908aab gfc_resolve_blocks(gfc_code*, gfc_namespace*)
/home/dima/src/gcc/gcc/fortran/resolve.c:10108
0x8f8fd9 gfc_resolve_code(gfc_code*, gfc_namespace*)
/home/dima/src/gcc/gcc/fortran/resolve.c:11052
0x8fbf2f resolve_codes
/home/dima/src/gcc/gcc/fortran/resolve.c:16433
0x8fbe6e resolve_codes
/home/dima/src/gcc/gcc/fortran/resolve.c:16417

[Bug target/83514] New: ABRT in arm_declare_function_name passing a null pointer to std::string

[msebor at gcc dot gnu.org]

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

Bug ID: 83514
   Summary: ABRT in arm_declare_function_name passing a null
pointer to std::string
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

I stumbled into this while debugging the ARM cross-compiler.  Looks like
back-end assumes targ_options->x_arm_arch_string is non-null, even though when
invoked with just the options below it can be null.

(gdb) r -O2 -Wall -isystem /ssd/build/arm-linux-gnueabi/gcc-git/gcc/include
-quiet /build/tmp/a.c
Starting program: /ssd/build/arm-linux-gnueabi/gcc-git/gcc/cc1 -O2 -Wall
-isystem /ssd/build/arm-linux-gnueabi/gcc-git/gcc/include -quiet /build/tmp/a.c

Program received signal SIGABRT, Aborted.
0x7688c91f in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x7688c91f in raise () from /lib64/libc.so.6
#1  0x7688e51a in abort () from /lib64/libc.so.6
#2  0x771ce52d in __gnu_cxx::__verbose_terminate_handler() () from
/lib64/libstdc++.so.6
#3  0x771cc2d6 in ?? () from /lib64/libstdc++.so.6
#4  0x771cc321 in std::terminate() () from /lib64/libstdc++.so.6
#5  0x771cc539 in __cxa_throw () from /lib64/libstdc++.so.6
#6  0x771f5f0f in std::__throw_logic_error(char const*) () from
/lib64/libstdc++.so.6
#7  0x77263614 in void std::__cxx11::basic_string::_M_construct(char
const*, char const*, std::forward_iterator_tag) () from /lib64/libstdc++.so.6
#8  0x772637cc in std::__cxx11::basic_string::basic_string(char const*,
std::allocator const&) () from /lib64/libstdc++.so.6
#9  0x0157c8ab in arm_declare_function_name (stream=0x2a28140,
name=0x7fffefac5f68 "f", decl=0x7fffef94dd00) at
/ssd/src/gcc/git/gcc/config/arm/arm.c:30984
...
(gdb) frame 9
#9  0x0157c8ab in arm_declare_function_name (stream=0x2a28140,
name=0x7fffefac5f68 "f", decl=0x7fffef94dd00) at
/ssd/src/gcc/git/gcc/config/arm/arm.c:30984
30984 std::string arch_to_print = targ_options->x_arm_arch_string;
(gdb) p targ_options->x_arm_arch_string
$5 = 0x0

[Bug other/83508] [8 regression][arm] c-c++-common/Wrestrict.c fails since r255836

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-12-20
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed with an arm-linux-gnueabi cross-compiler and the test case below.

Most (all?) back-ends transform the strcpy call into memcpy first (in the
handle_builtin_strcpy function in tree-ssa-strlen.c), just after warning for
the out-of-bounds offset.  After transforming the call handle_builtin_strcpy
also sets the no-warning bit on the new statement to prevent warning on it
again.

Most back-ends (or at least some, including x86_64) also transform the memcpy
call into MEM_REF.  The arm compiler, however, doesn't and leaves the invalid
memcpy call alone.  The invalid memcpy call is ultimately noticed by the
-Wstringop-overflow checker which hasn't been updated to check the no-warning
bit.  That results in the duplicate warning.

I think this points out not just (minor) issue with the warning but a more
serious weakness in the buffer overflow detection and prevention
(_FORTIFY_SOURCE) which lets this bug slip through.  This is one of the
downsides of allowing even invalid calls to be folded.

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout a.c
char* strcpy (char*, const char*);

void sink (void*);

void f (__PTRDIFF_TYPE__ i)
{
  char a[8] = "012";

  if (i < __PTRDIFF_MAX__ - 2 || __PTRDIFF_MAX__ - 1 < i)
i = __PTRDIFF_MAX__ - 2;

  strcpy (a + i, a);

  sink (a);
}
a.c: In function ‘f’:
a.c:12:3: warning: ‘strcpy’ offset [2147483645, 2147483646] is out of the
bounds [0, 8] of object ‘a’ with type ‘char[8]’ [-Warray-bounds]
   strcpy (a + i, a);
   ^
a.c:7:8: note: ‘a’ declared here
   char a[8] = "012";
^

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

f (int i)
{
  char a[8];
  unsigned int i.0_1;
  unsigned int _2;
  char * _4;
  sizetype prephitmp_12;

   [local count: 1073741825]:
  a = "012";
  i.0_1 = (unsigned int) i_8(D);
  _2 = i.0_1 + 2147483651;
  if (_2 > 1)
goto ; [64.00%]
  else
goto ; [36.00%]

   [local count: 687194769]:

   [local count: 1073741825]:
  # prephitmp_12 = PHI 
  _4 =  + prephitmp_12;
  __builtin_memcpy (_4, , 4);
  sink ();
  a ={v} {CLOBBER};
  return;

}


a.c:12:3: warning: ‘__builtin_memcpy’ writing 4 bytes into a region of size 0
overflows the destination [-Wstringop-overflow=]
   strcpy (a + i, a);
   ^

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Can't reproduce with current trunk (admittedly cross from x86_64-linux):
./cc1 -quiet -nostdinc -march=armv7-a -mcpu=cortex-a8 -mfpu=neon -O2 pr82989.c
ldrdr2, [r0]
mov r1, #0
addsr2, r3, r2
adc r3, r1, r3
strdr2, [r0]
bx  lr

[Bug tree-optimization/83081] [8 regression][arm] gcc.dg/pr80218.c fails since r254888

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #3 from Aldy Hernandez  ---
(In reply to Christophe Lyon from comment #2)
> It's still failing at r255848.
> My configure flags contain:
> --target=arm-none-linux-gnueabi --enable-checking 
> --enable-languages=c,c++,fortran --with-float=soft --enable-build-with-cxx
> --with-mode=arm --with-cpu=cortex-a9

Is this on a cross?  I still can't reproduce on an x86_64 x
arm-non-linux-gnueabi as specified above.

[Bug tree-optimization/83510] Recent changes for -Warray-bounds trigger false positive

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-20
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Looks like this has started very recently (sometime in the last
week).  But a VRP dump from GCC 7 shows the same range:

  _9 = i.0_1 + 4294967286;
  _10 = arr[_9];
  ...
Found new range for _9: [4294967286, +INF]
  ...
_9: [4294967286, +INF]

[Bug rtl-optimization/82973] [8 regression] ICE in output_constant_pool_2, at varasm.c:3896 on aarch64

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 42935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42935=edit
gcc8-pr82973.patch

Untested fix.  This regressed with r254388 btw, but was just latent everywhere
before that.

[Bug rtl-optimization/83513] New: [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 3) in fill_vec_av_set in selective scheduler

[asolokha at gmx dot com]

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

Bug ID: 83513
   Summary: [8 Regression] ICE: qsort checking failed (error:
qsort comparator non-negative on sorted output: 3) in
fill_vec_av_set in selective scheduler
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O1 (-O2, -Os) -fschedule-insns -fselective-scheduling
-fno-guess-branch-probability:

void
oh (long int qc, short int de)
{
  {
long int uf = 0;
int *xu, *gx = 

 p6:
*gx = (qc == 0) ? -1 : (qc - uf);
if (de == *gx)
  {
++*xu;
de = *xu;
  }
else
  de = qc;
  }

  goto p6;
}

% gcc-8.0.0-alpha20171217 -O1 -fschedule-insns -fselective-scheduling
-fno-guess-branch-probability -c -w vugfco5g.c  
vugfco5g.c: In function 'oh':
vugfco5g.c:20:1: error: qsort comparator non-negative on sorted output: 3
 }
 ^
during RTL pass: sched1
vugfco5g.c:20:1: internal compiler error: qsort checking failed
0x829340 qsort_chk_error
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/vec.c:222
0x8293c7 qsort_chk(void*, unsigned long, unsigned long, int (*)(void const*,
void const*))
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/vec.c:274
0xd069c4 vec<_expr*, va_heap, vl_embed>::qsort(int (*)(void const*, void
const*))
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/vec.h:1050
0xd069c4 vec<_expr*, va_heap, vl_ptr>::qsort(int (*)(void const*, void const*))
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/vec.h:1812
0xd069c4 fill_vec_av_set
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/sel-sched.c:3725
0xd089ea fill_ready_list
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/sel-sched.c:4022
0xd089ea find_best_expr
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/sel-sched.c:4382
0xd089ea fill_insns
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/sel-sched.c:5539
0xd0ae50 schedule_on_fences
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/sel-sched.c:7356
0xd0ae50 sel_sched_region_2
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/sel-sched.c:7494
0xd0c588 sel_sched_region_1
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/sel-sched.c:7536
0xd0c588 sel_sched_region(int)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/sel-sched.c:7637
0xd0d5e1 run_selective_scheduling()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/sel-sched.c:7713
0xcedadd rest_of_handle_sched
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/sched-rgn.c:3715
0xcedadd execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/sched-rgn.c:3825

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

[amker at gcc dot gnu.org]

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

--- Comment #10 from amker at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #9)
> Either r160 should be SImode, or we should copy it to a SImode pseudo
> and use that instead throughout?  Do we want to use it as DImode anywhere?

Not sure how ppc backend/expanding works.  If m is passed in different type to
int, the conversion is better to be done at assignment of i = m.  The
extendsion instruction is kind of unnecessary?  If it is, this could fix the
after-change in-efficient code generation of ivopts.  Of course, this maybe not
related to SMS so far.

[Bug rtl-optimization/81611] [8 Regression] gcc un-learned loop / post-increment optimization

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #2 from Jeffrey A. Law  ---
So we get good code just prior to this:

Author: rguenth 
Date:   Tue Apr 21 12:52:43 2015 +

2015-04-21  Richard Biener  

PR tree-optimization/65650
* tree-ssa-ccp.c (valid_lattice_transition): Allow lattice
transitions involving copies.
(set_lattice_value): Adjust for copy lattice state.
[ ... ]

That change results in propagation of a copy (no surprise there).  This results
in IVopts making some different choices.Prior to the change the loop looks
like this in the .optimized dump:

 # x_1 = PHI 
  # ivtmp.7_16 = PHI 
  str_2 = (char *) ivtmp.7_16;
  _9 = x_1 & 1;
  _10 = _9 + 48;
  _11 = (char) _10;
  MEM[base: str_2, offset: 0B] = _11;
  ivtmp.7_15 = ivtmp.7_16 + 1;
  x_13 = x_1 >> 1;
  if (x_13 != 0)
goto ;
  else
goto ;

Intuitively we can see the relationship between STR and IVTMP and the likely
post-inc opportunity at the memory reference and subsequent increment of IVTMP.

If we look at the loop after the referenced change we have:

  # x_1 = PHI 
  # str_2 = PHI 
  str_8 = str_2 + 1;
  _9 = x_1 & 1;
  _10 = _9 + 48;
  _11 = (char) _10;
  _16 = str_8 + 65535;
  MEM[base: _16, offset: 0B] = _11;
  x_13 = x_1 >> 1;
  if (x_13 != 0)
goto ;
  else
goto ;

So we no longer have the IV, just STR and it's a lot harder to recover the
auto-inc opportunity at the memory reference.  Anyway, that's the point where
it looks to me like things start to go off the rails.


If we walk forward to the trunk today and look at the .expand dump we have:

  # x_5 = PHI 
  # str_6 = PHI 
  _1 = x_5 & 1;
  _2 = _1 + 48;
  str_11 = str_6 + 1;
  _4 = (char) _2;
  _16 = str_6;
  MEM[base: _16, offset: 0B] = _4;
  x_13 = x_5 >> 1;
  x_15 = x_13;
  str_17 = str_11;
  if (x_5 > 1)
goto ; [85.00%]
  else
goto ; [15.00%]

;;   basic block 4, loop depth 0
;;pred:   3
  MEM[(char *)str_6 + 1B] = 0;
  return;


I think part of the problem is that we need str_6 and str_11 -- they have
different values and conflict.  The two MEMs could potentially be rewritten  
in terms of str_11.  With the obvious copy-props we'd have something like this:

  # x_5 = PHI 
  # str_6 = PHI 
  _1 = x_5 & 1;
  _2 = _1 + 48;
  str_11 = str_6 + 1;
  _4 = (char) _2;
  MEM[base: str_11, offset: -1B] = _4;
  x_13 = x_5 >> 1;
  if (x_5 > 1)
goto ; [85.00%]
  else
goto ; [15.00%]

;;   basic block 4, loop depth 0
;;pred:   3
  MEM[(char *)str_11, offset: 0B] = 0;
  return;


That ought to allow str_6 and str_11 to coalesce.  The question then becomes
can we recover the auto-inc -- I'm not sure the auto-inc code is good enough to
see it in that form.

Most importantly, while this BZ is filed against the AVR target, it seems to me
to be clearly a generic issue.

[Bug rtl-optimization/82973] [8 regression] ICE in output_constant_pool_2, at varasm.c:3896 on aarch64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
I have a patch.

[Bug rtl-optimization/80791] [8 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #9 from Segher Boessenkool  ---
Either r160 should be SImode, or we should copy it to a SImode pseudo
and use that instead throughout?  Do we want to use it as DImode anywhere?

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

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #5 from Jeffrey A. Law  ---
Or alternately cprop away the si->bx copy?  Why is that left in the IL (I'm
currently digging at two other regressions at the moment, so no real bandwidth
to dig into this right now).

[Bug testsuite/83483] [8 Regression] gcc.dg/memcpy-6.c FAILs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Committed in r255899.

[Bug testsuite/83483] [8 Regression] gcc.dg/memcpy-6.c FAILs

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Wed Dec 20 17:01:24 2017
New Revision: 255899

URL: https://gcc.gnu.org/viewcvs?rev=255899=gcc=rev
Log:
PR testsuite/83483 - [8 Regression] gcc.dg/memcpy-6.c FAILs

gcc/testsuite/ChangeLog:

PR testsuite/83483
* gcc.dg/memcpy-6.c: Skip for targets other than x86.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/memcpy-6.c

[Bug middle-end/78918] missing -Wrestrict on memcpy copying over self

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Sebor  ---
The memcpy-6.c failures are tracked in bug 83483.

[Bug testsuite/83131] c-c++/common/attr-nonstring-3 failure for strcmp tests on PowerPC

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Fixed in r255898.

[Bug testsuite/83131] c-c++/common/attr-nonstring-3 failure for strcmp tests on PowerPC

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Wed Dec 20 16:56:20 2017
New Revision: 255898

URL: https://gcc.gnu.org/viewcvs?rev=255898=gcc=rev
Log:
PR testsuite/83131 - c-c++/common/attr-nonstring-3 failure for strcmp tests on
PowerPC

gcc/ChangeLog:

PR testsuite/83131
* builtins.c (expand_builtin_strlen): Use get_callee_fndecl.
(expand_builtin_strcmp): Call maybe_warn_nonstring_arg. 
(expand_builtin_strncmp): Same.

gcc/testsuite/ChangeLog:

PR testsuite/83131
* c-c++-common/attr-nonstring-4.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/attr-nonstring-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/83367] static global constructors stack memory corruption

[weilercdale at gmail dot com]

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

--- Comment #5 from Dale Weiler  ---
Except they are referenced via their this pointer (which should alias the
static storage in that translation unit). I don't see how this is any different
than having a static variable in a translation unit and returning it in a
function that references it in that same translation unit. The constructor in
this case is compiled in the tests translation unit and references it. I think
the problem has to do with move construction, since if you provide a move
constructor for the cTest itself gcc seems to do the right thing.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
So, right before REE we have:
(insn 15 14 16 4 (set (reg/v:QI 4 si [orig:93 xr ] [93])
(mem:QI (reg/v/f:SI 1 dx [orig:104 in ] [104]) [0 MEM[base: in_26,
offset: 0B]+0 S1 A8])) "pr50038.c":13 88 {*movqi_internal}
 (nil))
... // neither si nor bx referenced
(insn 36 18 19 4 (set (reg/v:QI 3 bx [orig:93 xr ] [93])
(reg/v:QI 4 si [orig:93 xr ] [93])) "pr50038.c":15 88 {*movqi_internal}
 (nil))
(insn 19 36 20 4 (set (reg:SI 4 si [orig:109 xr ] [109])
(zero_extend:SI (reg/v:QI 3 bx [orig:93 xr ] [93]))) "pr50038.c":15 140
{*zero_extendqisi2}
 (nil))

REE has framework to optimize
 (set (reg1) (expression))
 ...
 (set (reg2) (any_extend (reg1)))
to
 (set (reg2) (any_extend (expression)))
 (set (reg1) (reg2))
but that is not the case here, we'd need to extend that to handle also
 (set (reg1) (expression))
 ...
 (set (reg2) (reg1))
 ...
 (set (reg1) (any_extend (reg2)))
to
 (set (reg1) (any_extend (expression)))
 (set (reg2) (reg1))
and possibly:
 (set (reg1) (expression))
 ...
 (set (reg2) (reg1))
 ...
 (set (reg3) (any_extend (reg2)))
to
 (set (reg3) (any_extend (expression)))
 (set (reg1) (reg3))
 (set (reg2) (reg3))
Jeff, thoughts on this?

[Bug rtl-optimization/83500] gcc.dg/tree-prof/switch-case-1.c fails on aarch64

[sje at gcc dot gnu.org]

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

--- Comment #3 from Steve Ellcey  ---
The test now passes for me.

[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
Is this due to linking libstdc++.a with LTO in it, or due to mixing
-std=c++1[14] and -std=c++17 compiled code in one LTO compilation where
std::string/std::wstring are then different?

[Bug tree-optimization/81082] [8 Regression] Failure to vectorise after reassociating index computation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So is there anything we can do here?
Isn't the bigger problem that we no longer notice the multiplications can't
overflow?  With the int multiplications gone, we need to assume [1, INT_MAX]
ranges on b1, b2 and b3 in the loop (otherwise it wouldn't loop at all), and
[0, INT_MAX - 1] ranges for i1, i2 and i3.  But, from the i1 * b2 * b3 + i2 *
b3 + (i3 - 1) we could have determined that b1 * b2 * b3 is [0, INT_MAX].

We do vectorize:
int
f (int *x, int b1, int b2, int b3)
{
  int foo = 0;
  for (int i1 = 0; i1 < b1; ++i1)
for (int i2 = 0; i2 < b2; ++i2)
  for (int i3 = 0; i3 < b3; ++i3)
foo += x[(i1 * b2 + i2) * b3 + (i3 - 1)];
  return foo;
}
without gather loads, while the #c0 only with them (if available).

Regarding the PR66313 optimization, first of all, what happened to the move of
it to match.pd?
As we vectorize:
int
f (int *x, int b1, int b2, int b3)
{
  int foo = 0;
  for (int i1 = 0; i1 < b1; ++i1)
for (int i2 = 0; i2 < b2; ++i2)
  for (int i3 = 0; i3 < b3; ++i3)
{
  int t1 = i1 * b2 * b3;
  int t2 = i2 * b3;
  int t3 = i3 - 1;
  foo += x[t1 + t2 + t3];
}
  return foo;
}

it seems that hasn't been done.

Second thing, in fold_plusminus_mult_expr I don't understand the:
  /* We are neither factoring zero nor minus one.  */
  || TREE_CODE (same) == INTEGER_CST)
part, shouldn't that be || (TREE_CODE (same) == INTEGER_CST && !integer_zerop
(same) && !integer_minus_onep (same)) ?

Another thing is, for signed a, b, c we can't optimize a * b + a * c as
a * (b + c) if a can be -1 or 0, exhaustive proof for signed char:
int
main ()
{
  int a, b, c;
  for (a = -128; a < 128; a++)
for (b = -128; b < 128; b++)
  for (c = -128; c < 128; c++)
{
  int ab = a * b;
  int ac = a * c;
  int ab_ac = ab + ac;
  if (ab < -128 || ab >= 128 || ac < -128 || ac >= 128 || ab_ac < -128
|| ab_ac >= 128)
continue;
  /* Ok, in this case a * b + a * c is without UB.  */
  int b_c = b + c;
#ifdef NEW
  b_c = (signed char) b_c;
#endif
  int r = a * b_c;
  if (b_c < -128 || b_c >= 128 || r != ab_ac)
__builtin_printf ("%d * %d + %d * %d = %d wrong opt (%d)\n", a, b,
a, c, ab_ac, r);
}
  return 0;
}

But, if we know for sure that a is not -1, we could optimize it as
  a * (signed)((unsigned) b + c)
(which doesn't work for a == -1, but works for others) instead of
  (signed)(a * ((unsigned) b + c))
(which works for all, but is a too big hammer).

Perhaps if this optimization is moved over to match.pd and we'd defer it if a
isn't constant until at least vrp1 and tune based on range info?
The range for b3 at least during vrp pass itself is [1, INT_MAX], so neither -1
nor 0 are possible and we could safely reassociate it as a * (b + c) rather
than the variants with unsigned.

Or do we want to somehow mark the MULT_EXPR we've created, propagate it through
the IL and if we in vrp notice this way marked MULT_EXPR (or IFN) we fold it as
integer multiplication?  That would be ugly.

[Bug target/83105] [8 regression] arm-*-*eabihf: error: -mfloat-abi=hard: selected processor lacks an FPU

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #6 from Jeffrey A. Law  ---
Per c#5.

[Bug c++/83504] incorrect attribute const interpretation on function overloads

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #2 from Martin Sebor  ---
The two functions differ in their argument lists (one takes an int and other
nothing) so they are distinct overloads.

[Bug middle-end/83487] [8 Regression] ICE in expand_call, at calls.c:4098

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Well, this seems to fix it.

--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -1882,6 +1882,12 @@ finalize_type_size (tree type)

   /* Handle empty records as per the x86-64 psABI.  */
   TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type);
+  if (TYPE_EMPTY_P (type))
+{
+  /* Ignore alignment on empty types.  */
+  TYPE_USER_ALIGN (type) = false;
+  SET_TYPE_ALIGN (type, 1);
+}
 }

 /* Return a new underlying object for a bitfield started with FIELD.  */

[Bug preprocessor/83492] [7 Regression] Optimized search_line_fast breaks preprocessor on aarch64_be

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] Optimized  |[7 Regression] Optimized
   |search_line_fast breaks |search_line_fast breaks
   |preprocessor on aarch64_be  |preprocessor on aarch64_be

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug preprocessor/83492] [7/8 Regression] Optimized search_line_fast breaks preprocessor on aarch64_be

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Wed Dec 20 15:07:01 2017
New Revision: 255896

URL: https://gcc.gnu.org/viewcvs?rev=255896=gcc=rev
Log:
[PATCH, PR83492] Fix selection of aarch64 big-endian shift parameters based on
__AARCH64EB__

2017-12-20  Michael Weiser  

PR preprocessor/83492
* lex.c (search_line_fast) [__ARM_NEON && __ARM_64BIT_STATE]:
Fix selection of big-endian shift parameters by using
__ARM_BIG_ENDIAN.


Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
So let's put also a deadline, if the port isn't cleaned by end of January, it
is dropped.  Delaying changes further would mean it won't get the testing it
would deserve.

[Bug bootstrap/83396] [8 Regression] Bootstrap failures with Statement Frontiers

[aoliva at gcc dot gnu.org]

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

--- Comment #84 from Alexandre Oliva  ---
Author: aoliva
Date: Wed Dec 20 14:48:34 2017
New Revision: 255895

URL: https://gcc.gnu.org/viewcvs?rev=255895=gcc=rev
Log:
[SFN] debug markers before labels no more

Make sure that gimple and RTL IRs don't have debug markers before
labels.  When we build the CFG, we move labels before any markers
appearing before them.  Then, make sure we don't mistakenly
reintroduce them.

This reverts some of the complexity that had been brought about by the
initial SFN patches.

for  gcc/ChangeLog

PR bootstrap/83396
* cfgexpand.c (label_rtx_for_bb): Revert SFN changes that
allowed debug stmts before labels.
(expand_gimple_basic_block): Likewise.
* gimple-iterator.c (gimple_find_edge_insert_loc): Likewise.
* gimple-iterator.h (gsi_after_labels): Likewise.
* tree-cfgcleanup (remove_forwarder_block): Likewise, but
rename reused variable, and simplify using gsi_move_before.
* tree-ssa-tail-merge.c (find_duplicate): Likewise.
* tree-cfg.c (make_edges, cleanup_dead_labels): Likewise.
(gimple_can_merge_blocks_p, verify_gimple_in_cfg): Likewise.
(gimple_verify_flow_info, gimple_block_label): Likewise.
(make_blocks): Move debug markers after adjacent labels.
* cfgrtl.c (skip_insns_after_block): Revert SFN changes that
allowed debug insns outside blocks.
* df-scan.c (df_insn_delete): Likewise.
* lra-constraints.c (update_ebb_live_info): Likewise.
* var-tracking.c (get_first_insn, vt_emit_notes): Likewise.
(vt_initialize, delete_vta_debug_insns): Likewise.
(reemit_marker_as_note): Drop BB parm.  Adjust callers.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/cfgrtl.c
trunk/gcc/df-scan.c
trunk/gcc/gimple-iterator.c
trunk/gcc/gimple-iterator.h
trunk/gcc/lra-constraints.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-cfgcleanup.c
trunk/gcc/tree-ssa-tail-merge.c
trunk/gcc/var-tracking.c

[Bug target/83488] [8 Regression] ICE on a CET test-case

[igor.v.tsimbalist at intel dot com]

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

--- Comment #15 from igor.v.tsimbalist at intel dot com ---
(In reply to Jakub Jelinek from comment #13)
> And, if we run out of easy move ideas, we could make a copy of the ISA_64BIT
> so that we'd have it in both flag sets (and keep it synced) and move all
> AVX512 related stuff to isa_flags2 and everything else to isa_flags.

Good idea!

[Bug target/83488] [8 Regression] ICE on a CET test-case

[igor.v.tsimbalist at intel dot com]

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

--- Comment #14 from igor.v.tsimbalist at intel dot com ---
ok, maybe I was wrong. But my point is OPTION_MASK_ISA_AVX512VL may be used
with new/future instructions likely. This bit is in isa_flags set, which is
full now, so it will require reordering isa_flags and isa_flags2 each time when
such combinations might appear in future.

[Bug target/83488] [8 Regression] ICE on a CET test-case

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
And, if we run out of easy move ideas, we could make a copy of the ISA_64BIT so
that we'd have it in both flag sets (and keep it synced) and move all AVX512
related stuff to isa_flags2 and everything else to isa_flags.

[Bug gcov-profile/83509] [8 Regression] gcov-dump-8 unable to dump any gcda files

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Patch sent: https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01361.html

[Bug target/83488] [8 Regression] ICE on a CET test-case

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
If it is due to a bug in i386-builtins.def, with my patch there are just 60
bits in isa_flags and thus a couple of further isa bits could be moved there if
really needed.  And as I said earlier, I think it is possible to move some
others in the other direction.

[Bug target/83488] [8 Regression] ICE on a CET test-case

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
$ grep 'OPTION_MASK_ISA_AVX512VNNI.*|' i386-builtins.def
$ grep '|.*OPTION_MASK_ISA_AVX512VNNI' i386-builtins.def
So, at least I can't find that.

[Bug c++/83490] [8 Regression] ICE in find_call_stack_args, at dce.c:392

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/83488] [8 Regression] ICE on a CET test-case

[igor.v.tsimbalist at intel dot com]

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

--- Comment #10 from igor.v.tsimbalist at intel dot com ---
The bit OPTION_MASK_ISA_AVX512VNNI may have OPTION_MASK_ISA_AVX512VL bit set
also. But these bits are from different isa flags.

[Bug target/83488] [8 Regression] ICE on a CET test-case

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||kyukhin at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Perhaps it would help if we did:
--- gcc/config/i386/i386.opt.jj 2017-12-20 13:01:04.0 +0100
+++ gcc/config/i386/i386.opt2017-12-20 15:18:59.351758063 +0100
@@ -726,15 +726,15 @@ Target Report Mask(ISA_AVX512VBMI) Var(i
 Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2 and AVX512F and
AVX512VBMI built-in functions and code generation.

 mavx5124fmaps
-Target Report Mask(ISA_AVX5124FMAPS) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_AVX5124FMAPS) Var(ix86_isa_flags2) Save
 Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, AVX512F and
AVX5124FMAPS built-in functions and code generation.

 mavx5124vnniw
-Target Report Mask(ISA_AVX5124VNNIW) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_AVX5124VNNIW) Var(ix86_isa_flags2) Save
 Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, AVX512F and
AVX5124VNNIW built-in functions and code generation.

 mavx512vpopcntdq
-Target Report Mask(ISA_AVX512VPOPCNTDQ) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_AVX512VPOPCNTDQ) Var(ix86_isa_flags2) Save
 Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, AVX512F and
AVX512VPOPCNTDQ built-in functions and code generation.

 mavx512vbmi2
@@ -742,7 +742,7 @@ Target Report Mask(ISA_AVX512VBMI2) Var(
 Support MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AVX2, AVX512F and
AVX512VBMI2 built-in functions and code generation.

 mavx512vnni
-Target Report Mask(ISA_AVX512VNNI) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_AVX512VNNI) Var(ix86_isa_flags2) Save
 Support AVX512VNNI built-in functions and code generation.

 mfma
@@ -774,11 +774,11 @@ Target Report Mask(ISA_POPCNT) Var(ix86_
 Support code generation of popcnt instruction.

 msgx
-Target Report Mask(ISA_SGX) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_SGX) Var(ix86_isa_flags2) Save
 Support SGX built-in functions and code generation.

 mrdpid
-Target Report Mask(ISA_RDPID) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_RDPID) Var(ix86_isa_flags2) Save
 Support RDPID built-in functions and code generation.

 mgfni
@@ -786,7 +786,7 @@ Target Report Mask(ISA_GFNI) Var(ix86_is
 Support GFNI built-in functions and code generation.

 mvaes
-Target Report Mask(ISA_VAES) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_VAES) Var(ix86_isa_flags2) Save
 Support VAES built-in functions and code generation.

 mvpclmulqdq
@@ -806,7 +806,7 @@ Target Report Mask(ISA_LZCNT) Var(ix86_i
 Support LZCNT built-in function and code generation.

 mhle
-Target Report Mask(ISA_HLE) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_HLE) Var(ix86_isa_flags2) Save
 Support Hardware Lock Elision prefixes.

 mrdseed
@@ -858,7 +858,7 @@ Target Report Mask(ISA_TBM) Var(ix86_isa
 Support TBM built-in functions and code generation.

 mcx16
-Target Report Mask(ISA_CX16) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_CX16) Var(ix86_isa_flags2) Save
 Support code generation of cmpxchg16b instruction.

 msahf
@@ -866,7 +866,7 @@ Target Report Mask(ISA_SAHF) Var(ix86_is
 Support code generation of sahf instruction in 64bit x86-64 code.

 mmovbe
-Target Report Mask(ISA_MOVBE) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_MOVBE) Var(ix86_isa_flags2) Save
 Support code generation of movbe instruction.

 mcrc32
@@ -939,15 +939,15 @@ Target Report Mask(ISA_RTM) Var(ix86_isa
 Support RTM built-in functions and code generation.

 mmpx
-Target Report Mask(ISA_MPX) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_MPX) Var(ix86_isa_flags2) Save
 Support MPX code generation.

 mmwaitx
-Target Report Mask(ISA_MWAITX) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_MWAITX) Var(ix86_isa_flags2) Save
 Support MWAITX and MONITORX built-in functions and code generation.

 mclzero
-Target Report Mask(ISA_CLZERO) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_CLZERO) Var(ix86_isa_flags2) Save
 Support CLZERO built-in functions and code generation.

 mpku
@@ -1000,7 +1000,7 @@ Support Control-flow  Enforcment Technol
 and code generation.

 mibt
-Target Report Mask(ISA_IBT) Var(ix86_isa_flags2) Save
+Target Report Mask(ISA2_IBT) Var(ix86_isa_flags2) Save
 Specifically enables an indirect branch tracking feature from Control-flow
 Enforcment Technology (CET).

and adjusted all uses, then it would be from the OPTION_MASK_* name clear which
bitmask we are talking about, we could more easily verify we don't mix the
non-compatible ones etc.  Uros/Kyrill, what do you think?  I'll certainly
bootstrap/regtest the above patch with the added testcase without this, this is
something that can be done incrementally.

[Bug gcov-profile/83509] [8 Regression] gcov-dump-8 unable to dump any gcda files

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
  Known to work||7.2.0
Summary|gcov-dump-8 unable to dump  |[8 Regression] gcov-dump-8
   |any gcda files  |unable to dump any gcda
   ||files
  Known to fail||8.0

--- Comment #5 from Martin Liška  ---
Nwo I can confirm that. Thanks for the test-case.

[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes

[matt at godbolt dot org]

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

Matt Godbolt  changed:

   What|Removed |Added

 CC||matt at godbolt dot org

--- Comment #7 from Matt Godbolt  ---
The pedigree of the GCC 7.1 is as Peter says. The compiler isn't bootstrapped,
and uses an in-tree binutils, should that be important.

Other pertinent info from gcc -v

Configured with: ../gcc-7.1.0/configure --prefix /root/staging
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--disable-multilib --disable-bootstrap --disable-multiarch --with-arch-32=i586
--enable-clocale=gnu --enable-languages=c,c++,go,fortran --enable-ld=yes
--enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 7.1.0 (GCC-Explorer-Build) 
GNU C++11 (GCC-Explorer-Build) version 7.1.0 (x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072


The binaries used on CE are here:
https://s3.amazonaws.com/compiler-explorer/opt/gcc-7.1.0.tar.xz

[Bug gcov-profile/83509] gcov-dump-8 unable to dump any gcda files

[tulipawn at gmail dot com]

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

--- Comment #4 from PeteVine  ---
Created attachment 42934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42934=edit
corresponding C/gcda/gcno files

[Bug gcov-profile/83509] gcov-dump-8 unable to dump any gcda files

[tulipawn at gmail dot com]

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

--- Comment #3 from PeteVine  ---
OK, the following command was used to obtain the gcno/gcda files:

$ gcc-8 -O3 -fprofile-generate -ftest-coverage sudoku.c && ./a.out

Unlike the gcda file, gcno is dumpable with gcov-dump-8.

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

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
I've finally cloned PR82881 as I apparently don't have permissions to reopen
that PR. I'm also adding another similar testcase for the case:

int u3;

int
w7 (int *a9)
{
  for (;;)
{
  for (*a9 = 0; *a9 < 1; *a9++)
{
}

  ++u3;
}
}

% gcc-8.0.0-alpha20171217 -O2 -freorder-blocks-algorithm=simple -c mvsp6303.c 
during RTL pass: bbro
mvsp6303.c: In function 'w7':
mvsp6303.c:14:1: internal compiler error: in df_compact_blocks, at
df-core.c:1729
 }
 ^
0x5d7389 df_compact_blocks()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/df-core.c:1729
0x13acd65 compact_blocks()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfg.c:160
0x13a3f08 reorder_basic_blocks
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/bb-reorder.c:2480
0x13a3f08 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/bb-reorder.c:2570

(as of r255766)

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

[asolokha at gmx dot com]

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

Bug ID: 83512
   Summary: [8 Regression] ICE: in df_compact_blocks, at
df-core.c:1729 with -freorder-blocks-algorithm=simple
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: asolokha at gmx dot com, hubicka at gcc dot gnu.org,
jakub at gcc dot gnu.org, unassigned at gcc dot gnu.org,
zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

+++ This bug was initially created as a clone of Bug #82881 +++

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O2 -freorder-blocks-algorithm=simple testcase.c 
during RTL pass: bbro
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: in df_compact_blocks, at
df-core.c:1729
 }
 ^
0x8a6b3f df_compact_blocks()
/repo/gcc-trunk/gcc/df-core.c:1729
0x1543a45 compact_blocks()
/repo/gcc-trunk/gcc/cfg.c:160
0x153c150 reorder_basic_blocks
/repo/gcc-trunk/gcc/bb-reorder.c:2502
0x153c150 execute
/repo/gcc-trunk/gcc/bb-reorder.c:2592
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-254487-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-254487-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 8.0.0 20171107 (experimental) (GCC)

[Bug middle-end/58598] ICE: SIGSEGV (write after free) with -O -flto -fno-fat-lto-objects -fvtable-verify=std

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Gallager  ---
(In reply to Zdenek Sojka from comment #2)
> No longer crashing in 6.4.0+

So... that's FIXED then, since the "Known to fail" branches are both closed

[Bug tree-optimization/83491] [8 Regression] ICE in execute_cse_reciprocals_1 at gcc/tree-ssa-math-opts.c:585

[wilco at gcc dot gnu.org]

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

--- Comment #6 from Wilco  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01357.html

[Bug libstdc++/83511] New: Missing default argument for basic_string_view::substr

[kaballo86 at hotmail dot com]

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

Bug ID: 83511
   Summary: Missing default argument for basic_string_view::substr
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kaballo86 at hotmail dot com
  Target Milestone: ---

The following snippet results in a compilation error:

std::string_view sv;
sv = sv.substr();

> error: no matching function for call to 
> 'std::basic_string_view::substr()'
>  note: candidate 'substr(size_type __pos, size_type __n = npos) const 
> noexcept(false)'

The declaration is missing a default argument of `0` for the first parameter.

[Bug c++/81055] [6/7/8 Regression] ICE with invalid initializer for array new

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c++/81055] [6/7/8 Regression] ICE with invalid initializer for array new

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
On it.

[Bug target/83488] [8 Regression] ICE on a CET test-case

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to igor.v.tsimbalist from comment #6)
> I haven't look into all the cases but I think there are similar cases with
> OPTION_MASK_ISA_AVX512F and OPTION_MASK_ISA_AVX512VL.

Which ones do you mean?

With my patch, the isa_flags OPTION_MASK_ISA_* values are:
OPTION_MASK_ISA_3DNOW
OPTION_MASK_ISA_3DNOW_A
OPTION_MASK_ISA_64BIT
OPTION_MASK_ISA_ABM
OPTION_MASK_ISA_ADX
OPTION_MASK_ISA_AES
OPTION_MASK_ISA_AVX
OPTION_MASK_ISA_AVX2
OPTION_MASK_ISA_AVX512BW
OPTION_MASK_ISA_AVX512CD
OPTION_MASK_ISA_AVX512DQ
OPTION_MASK_ISA_AVX512ER
OPTION_MASK_ISA_AVX512F
OPTION_MASK_ISA_AVX512IFMA
OPTION_MASK_ISA_AVX512PF
OPTION_MASK_ISA_AVX512VBMI
OPTION_MASK_ISA_AVX512VBMI2
OPTION_MASK_ISA_AVX512VL
OPTION_MASK_ISA_BMI
OPTION_MASK_ISA_BMI2
OPTION_MASK_ISA_CLFLUSHOPT
OPTION_MASK_ISA_CLWB
OPTION_MASK_ISA_CRC32
OPTION_MASK_ISA_F16C
OPTION_MASK_ISA_FMA
OPTION_MASK_ISA_FMA4
OPTION_MASK_ISA_FSGSBASE
OPTION_MASK_ISA_FXSR
OPTION_MASK_ISA_GFNI
OPTION_MASK_ISA_LWP
OPTION_MASK_ISA_LZCNT
OPTION_MASK_ISA_MMX
OPTION_MASK_ISA_PCLMUL
OPTION_MASK_ISA_PKU
OPTION_MASK_ISA_POPCNT
OPTION_MASK_ISA_PREFETCHWT1
OPTION_MASK_ISA_PRFCHW
OPTION_MASK_ISA_RDRND
OPTION_MASK_ISA_RDSEED
OPTION_MASK_ISA_RTM
OPTION_MASK_ISA_SAHF
OPTION_MASK_ISA_SHA
OPTION_MASK_ISA_SHSTK
OPTION_MASK_ISA_SSE
OPTION_MASK_ISA_SSE2
OPTION_MASK_ISA_SSE3
OPTION_MASK_ISA_SSE4_1
OPTION_MASK_ISA_SSE4_2
OPTION_MASK_ISA_SSE4A
OPTION_MASK_ISA_SSSE3
OPTION_MASK_ISA_TBM
OPTION_MASK_ISA_VPCLMULQDQ
OPTION_MASK_ISA_XOP
OPTION_MASK_ISA_XSAVE
OPTION_MASK_ISA_XSAVEC
OPTION_MASK_ISA_XSAVEOPT
OPTION_MASK_ISA_XSAVES

and isa_flags2 values are:

OPTION_MASK_ISA_AVX5124FMAPS
OPTION_MASK_ISA_AVX5124VNNIW
OPTION_MASK_ISA_AVX512VNNI
OPTION_MASK_ISA_AVX512VPOPCNTDQ
OPTION_MASK_ISA_CLZERO
OPTION_MASK_ISA_CX16
OPTION_MASK_ISA_HLE
OPTION_MASK_ISA_IBT
OPTION_MASK_ISA_MOVBE
OPTION_MASK_ISA_MPX
OPTION_MASK_ISA_MWAITX
OPTION_MASK_ISA_RDPID
OPTION_MASK_ISA_SGX
OPTION_MASK_ISA_VAES

If the first list above is in /tmp/J1 and second list in /tmp/J2, then:

$ for i in `cat /tmp/J2`; do grep 'isa_flags[^2].*'${i}'_SET' i386-common.c; \
done
$ for i in `cat /tmp/J2`; do grep 'isa_flags[^2].*'${i}'_UNSET' i386-common.c;
\
done
$ for i in `cat /tmp/J1`; do grep 'isa_flags2.*'${i}'_SET' i386-common.c; done
  opts->x_ix86_isa_flags2 |= OPTION_MASK_ISA_AVX512F_SET;
  opts->x_ix86_isa_flags2_explicit |= OPTION_MASK_ISA_AVX512F_SET;
$ for i in `cat /tmp/J1`; do grep 'isa_flags2.*'${i}'_UNSET' i386-common.c;
done

so it shows the single case you've found.

[Bug c/83510] New: Recent changes for -Warray-bounds trigger false positive

[sirl at gcc dot gnu.org]

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

Bug ID: 83510
   Summary: Recent changes for -Warray-bounds trigger false
positive
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42933=edit
testcase

The attached testcase started to produce a warning with trunk somewhere between
r255501 and r255678, with -O2 -Warray-bounds:

test-Warray-bounds.c: In function 'g':
test-Warray-bounds.c:18:13: warning: array subscript 4294967286 is above array
bounds of 'unsigned int[10]' [-Warray-bounds=]
   return arr[number - 0xa];
  ~~~^~

I believe it is a false positive.


unsigned int arr[10];

struct xyz {
unsigned int a0;
};

extern void wfm(struct xyz *, int, unsigned int);

static unsigned int f(struct xyz * ctx, unsigned int number)
{
switch (number) {
case 0x9:
return ctx->a0;
case 0xA: case 0xB:
case 0xC: case 0xD: case 0xE: case 0xF:
case 0x10: case 0x11: case 0x12: case 0x13:
return arr[number - 0xa];
}
return 0;
}

int g(struct xyz * ctx) {
int i;

for (i = 0; i < 10; i++) {
wfm(ctx, i, f(ctx, i));
}

return 0;
}

[Bug ipa/83065] [8 Regression] SPEC CPU2017 523/623 compfail (ICE)

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Even using the affected revision, I'm unable to reproduce that with:

   OPTIMIZE= -Ofast -funroll-loops -g -march=haswell -fpermissive
-fgnu89-inline 

Can you please provide whole command line that invokes the problematic source
file? And please add also --verbose output.

[Bug target/83488] [8 Regression] ICE on a CET test-case

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Testcase for the other ICE fixed by this patch:

/* { dg-do compile } */
/* { dg-options "-mavx512vbmi2 -mno-avx512f" } */

typedef long long __v8di __attribute__((vector_size (64)));
void
foo (__v8di *a, __v8di *b, __v8di *c, __v8di *d)
{
  *d = __builtin_ia32_vpshldv_v8di (*a, *b, *c); /* { dg-warning "implicit" }
*/
} /* { dg-error "incompatible types when assigning to type" } */

[Bug middle-end/83487] [8 Regression] ICE in expand_call, at calls.c:4098

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug rtl-optimization/82982] [8 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 5) in ready_sort_real in haifa scheduler

[amonakov at gcc dot gnu.org]

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

--- Comment #3 from Alexander Monakov  ---
> Can it be a duplicate of PR83459?

No, this is a separate issue (the root cause here is different from the issue
in sched-pressure ordering heuristic found by Jakub in the other bug).

[Bug middle-end/83487] [8 Regression] ICE in expand_call, at calls.c:4098

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Yeah, that sounds like a reasonable thing to do to me.

[Bug middle-end/83487] [8 Regression] ICE in expand_call, at calls.c:4098

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
I think we should ignore alignment on TYPE_EMPTY_P arguments which we aren't
passing at all.  Though, we should double check what other compilers are doing
in that case.

[Bug c++/83331] Compile time evaluation of cbrt does not match library evaluation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
That can happen.  Is the std::cbrt (123.456) precise (error <= .5ulp)?  If so
and the library implementation is not, you should expect some differences.
std::cbrt is constexpr, so if you use it on a constant argument, the compiler
can (and in constant initializers/constexpr contexts must) fold it into a
constant.

[Bug ipa/83065] [8 Regression] SPEC CPU2017 523/623 compfail (ICE)

[andrey.y.guskov at intel dot com]

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

--- Comment #2 from Andrey Guskov  ---
Standard base6 options: -Ofast -funroll-loops

[Bug target/83488] [8 Regression] ICE on a CET test-case

[igor.v.tsimbalist at intel dot com]

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

--- Comment #6 from igor.v.tsimbalist at intel dot com ---
I haven't look into all the cases but I think there are similar cases with
OPTION_MASK_ISA_AVX512F and OPTION_MASK_ISA_AVX512VL.