[Bug preprocessor/80716] Death by Documentation (SEGFAULT)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Of course, if you want to have \s at the end of line in comments, you just
should use /* ... */ style comments that can span multiple lines.

[Bug preprocessor/80716] Death by Documentation (SEGFAULT)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Can't reproduce with gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) nor
current trunk.  Perhaps the flags you've listed are incomplete?  There is no
-Wall nor -Wcomment nor -Wall -Werror nor -Werror=comment, so it certainly
doesn't warn with the flags you've mentioned.
It might be better if you attach the testcase, so that tabs vs. spaces are
preserved.

[Bug fortran/79440] internal compiler error: in fold_convert_loc, at fold-const.c:2373

[berke.durak at gmail dot com]

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

Berke Durak  changed:

   What|Removed |Added

 CC||berke.durak at gmail dot com

--- Comment #2 from Berke Durak  ---
I get a similar error with 7.0.1:

% cat crash.f90
module gogol
  implicit none

  type plop
  end type plop
contains
  function create() result(this)
class(plop), allocatable :: this
allocate(this)
  end function create
end module gogol

program foo
  use gogol
  implicit none
  type(plop), allocatable :: x
  x=create()
contains
end program foo

% gfortran crash.f90
crash.f90:17:0:

   x=create()

internal compiler error: in fold_convert_loc, at fold-const.c:2361
0x864863 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../src/gcc/fold-const.c:2361
0x6a5d7a gfc_allocate_using_malloc(stmtblock_t*, tree_node*, tree_node*, tre
e_node*)   
../../src/gcc/fortran/trans.c:662
0x6de110 trans_class_assignment
../../src/gcc/fortran/trans-expr.c:9693
0x6de110 gfc_trans_assignment_1
../../src/gcc/fortran/trans-expr.c:10031
0x6a38ff trans_code
../../src/gcc/fortran/trans.c:1817
0x6c8907 gfc_generate_function_code(gfc_namespace*)
../../src/gcc/fortran/trans-decl.c:6296
0x65dac6 translate_all_program_units
../../src/gcc/fortran/parse.c:6051
0x65dac6 gfc_parse_file()
../../src/gcc/fortran/parse.c:6251
0x6a043f gfc_be_parse_file
../../src/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/61543] static_cast(static_cast(enum_value)) doesn't get an error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-12
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.3, 4.9.3, 5.3.0, 6.2.0,
   ||7.1.0

--- Comment #4 from Martin Sebor  ---
Confirmed.  GCC seems to treat rvalues of integer types with zero value as the
literal 0.

$ cat t.C && gcc -S -Wall t.C

const int i = 0;

void *p0 = static_cast(i);
void *p1 = static_cast(static_cast(i));   // accepted

enum { e = 0 };

void *q = static_cast(static_cast(e));   // accepted

y.C:3:33: error: invalid static_cast from type ‘const int’ to type ‘void*’
 void *p0 = static_cast(i);
 ^

[Bug target/80718] New: GCC generates slow code for offsettable vec_duplicate

[meissner at gcc dot gnu.org]

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

Bug ID: 80718
   Summary: GCC generates slow code for offsettable vec_duplicate
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

In looking at bug 80697, I noticed on power8, there were loads to a GPR
register and move directs to vector registers.

I tracked this down to the load with splat instruction only taking indirect or
indexed loads, while the original address is an offsettable load.  So the
register allocator decides to load up a GPR and do the transfer over to the
vector register to do the vec_duplicate operation.

I.e.:
vector double foo (double *p) { return (vector double) { p[4], p[4] }; }

generates:
foo:
ld 9,32(3)
mtvsrd 34,9
xxpermdi 34,34,34,0
blr

I tested adding a combiner pattern to support offsettable loads, and it
generates:
foo:
li 9,32
lxvdsx 34,3,9
blr

[Bug fortran/80333] Namelist dtio write of array of class does not traverse the array

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #2 from Jerry DeLisle  ---
This is front end issue, and I will explore

[Bug lto/80717] New: LTO wrappers segfault if run with absolute path

[theivorytower at gmail dot com]

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

Bug ID: 80717
   Summary: LTO wrappers segfault if run with absolute path
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theivorytower at gmail dot com
  Target Milestone: ---

When I run any of the LTO wrappers (gcc-ar, gcc-nm, gcc-ranlib) with absolute
path (e.g. /usr/bin/gcc-ar), the program segfaults immediately. I tried to run
some debugging, and I found the culprit is in line 197-204 of gcc-ar.c.

Basically gcc-ar was trying to find ar, and "/usr/bin/" was removed from the
list of path to search for ar in line 203 of gcc-ar.c. As a result ar cannot be
found and the program segfaults.

I'm using Arch Linux and my gcc version info is as follows:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/hao/code/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++,lto --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 --disable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 7.1.1 20170508 (GCC)

[Bug target/80697] On PowerPC, the spec 2006 benchmark milc had a 5.6% regression under GCC 7.1 compared to GCC 6.3.

[meissner at gcc dot gnu.org]

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

--- Comment #8 from Michael Meissner  ---
I forgot to mention that I ran the MILC benchmark on a little endian power8
system, using -mcpu=power8 in addition to -O3 and -ffast-math.

[Bug middle-end/80707] [8 Regression] r247844 causes error: extra outgoing edge

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
David and HJ, the following patch fixes the ICE Markus reported, so can you try
the following patch to see if it fixes your bootstrap issues?

Index: tree-cfg.c
===
--- tree-cfg.c  (revision 247845)
+++ tree-cfg.c  (working copy)
@@ -1684,6 +1684,10 @@ group_case_labels_stmt (gswitch *stmt)
  || (EDGE_COUNT (base_bb->succs) == 0
  && gimple_seq_unreachable_p (bb_seq (base_bb
{
+ edge e;
+ if (base_bb != default_bb
+ && (e = find_edge (gimple_bb (stmt), base_bb)) != NULL)
+   remove_edge_and_dominated_blocks (e);
  gimple_switch_set_label (stmt, i, NULL_TREE);
  i++;
  new_size--;

[Bug target/80697] On PowerPC, the spec 2006 benchmark milc had a 5.6% regression under GCC 7.1 compared to GCC 6.3.

[meissner at gcc dot gnu.org]

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

--- Comment #7 from Michael Meissner  ---
Author: meissner
Date: Fri May 12 00:05:24 2017
New Revision: 247941

URL: https://gcc.gnu.org/viewcvs?rev=247941=gcc=rev
Log:
Attempt to fix pr 80697

Modified:
branches/ibm/meissner-work/gcc/ChangeLog.meissner

[Bug target/80697] On PowerPC, the spec 2006 benchmark milc had a 5.6% regression under GCC 7.1 compared to GCC 6.3.

[meissner at gcc dot gnu.org]

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

--- Comment #6 from Michael Meissner  ---
Author: meissner
Date: Fri May 12 00:00:50 2017
New Revision: 247940

URL: https://gcc.gnu.org/viewcvs?rev=247940=gcc=rev
Log:
Attempt to fix pr 80697

Modified:
branches/ibm/meissner-work/gcc/ChangeLog.meissner
branches/ibm/meissner-work/gcc/config/rs6000/rs6000.md

[Bug go/64238] ICE in get_partitioning_class, at symtab.c:1775

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #12 from Ian Lance Taylor  ---
Thanks, should be fixed now.

[Bug go/64238] ICE in get_partitioning_class, at symtab.c:1775

[ian at gcc dot gnu.org]

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

--- Comment #11 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu May 11 23:53:29 2017
New Revision: 247939

URL: https://gcc.gnu.org/viewcvs?rev=247939=gcc=rev
Log:
PR go/64238
* go-gcc.cc (Gcc_backend::implicit_variable_reference): Set
DECL_EXTERNAL, clear TREE_STATIC.

Modified:
branches/gcc-6-branch/gcc/go/ChangeLog
branches/gcc-6-branch/gcc/go/go-gcc.cc

[Bug go/64238] ICE in get_partitioning_class, at symtab.c:1775

[ian at gcc dot gnu.org]

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

--- Comment #10 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu May 11 23:53:13 2017
New Revision: 247938

URL: https://gcc.gnu.org/viewcvs?rev=247938=gcc=rev
Log:
PR go/64238
* go-gcc.cc (Gcc_backend::implicit_variable_reference): Set
DECL_EXTERNAL, clear TREE_STATIC.

Modified:
branches/gcc-7-branch/gcc/go/ChangeLog
branches/gcc-7-branch/gcc/go/go-gcc.cc

[Bug go/64238] ICE in get_partitioning_class, at symtab.c:1775

[ian at gcc dot gnu.org]

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

--- Comment #9 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu May 11 23:52:54 2017
New Revision: 247937

URL: https://gcc.gnu.org/viewcvs?rev=247937=gcc=rev
Log:
PR go/64238
* go-gcc.cc (Gcc_backend::implicit_variable_reference): Set
DECL_EXTERNAL, clear TREE_STATIC.

Modified:
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-gcc.cc

[Bug c/7654] warn if an enum is being assigned a non enum value

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78736

--- Comment #11 from Martin Sebor  ---
I'll confirm this ancient request.

Bug 78736 asks for something similar, and I'm working on enhancing the solution
there even further (to diagnose assigning constants that don't have a
corresponding enumerator in the destination type).  I'll add that on the
following slightly modified test case  Clang issues the warnings below: 

$ cat t.C && clang -S -Wall -Wextra -Weverything -xc t.C
void f (int i)
{
  enum e1 { e1a, e1b };
  enum e1 e1v;
  enum e2 { e2a, e2b };
  enum e2 e2v;

  e1v = 1;   // no warning
  e1v = 3;   // warning
  e1v = e1a; // ok
  e2v = e1v; // warning
  i = e1v;   // ok I guess
  e2v = i;   // warning
}
t.C:9:9: warning: integer constant not in range of enumerated type 'enum e1'
  [-Wassign-enum]
  e1v = 3;   // warning
^
t.C:11:9: warning: implicit conversion from enumeration type 'enum e1' to
  different enumeration type 'enum e2' [-Wenum-conversion]
  e2v = e1v; // warning
  ~ ^~~
t.C:13:9: warning: implicit conversion changes signedness: 'int' to 'enum e2'
  [-Wsign-conversion]
  e2v = i;   // warning
  ~ ^
t.C:1:6: warning: no previous prototype for function 'f' [-Wmissing-prototypes]
void f (int i)
 ^
4 warnings

[Bug c++/52763] Warning if compare between enum and non-enum type

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
Clang warns when an enum object is compared to a constant that's out of the
most restricted range of the enum's type.  The warning is in -Wall.  It doesn't
warn when the object is compared to a constant that doesn't correspond to any
of the type's enumerators.  I can see that being useful to some (carefully
written) projects but suspect it could be quite noisy for many others.

$ cat t.C && clang++ -S -Wall -Wextra t.C
enum E { NONE = 0, ONE = 1, TWO = 2 };

bool f (E e)
{
  return e == 3;   // no warning here
}

bool g (E e)
{
  return e == 4;
}


t.C:10:12: warning: comparison of constant 4 with expression of type 'E' is
  always false [-Wtautological-constant-out-of-range-compare]
  return e == 4;
 ~ ^  ~
1 warning generated.

[Bug bootstrap/80714] [8 Regression] profiledbootstrap failed with LTO

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #2 from Peter Bergner  ---
Closing as a dup.

[Bug middle-end/80707] [8 Regression] r247844 causes error: extra outgoing edge

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #3 from Peter Bergner  ---
*** Bug 80714 has been marked as a duplicate of this bug. ***

[Bug bootstrap/80714] [8 Regression] profiledbootstrap failed with LTO

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||bergner at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Peter Bergner  ---
This is a dup.

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

[Bug target/80697] On PowerPC, the spec 2006 benchmark milc had a 5.6% regression under GCC 7.1 compared to GCC 6.3.

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Created attachment 41344
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41344=edit
Assembler output from gcc 7.1.0

[Bug target/80697] On PowerPC, the spec 2006 benchmark milc had a 5.6% regression under GCC 7.1 compared to GCC 6.3.

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Created attachment 41343
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41343=edit
Assembler output from gcc 6.3.0

[Bug target/80697] On PowerPC, the spec 2006 benchmark milc had a 5.6% regression under GCC 7.1 compared to GCC 6.3.

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Created attachment 41342
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41342=edit
Preprocessed C source for the mult_adj_su3_mat_vec function

To reproduce, you need to use the -O3 -ffast-math options.

[Bug c++/80716] Death by Documentation (SEGFAULT)

[breakpoint at runbox dot com]

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

--- Comment #1 from Matt Heck  ---
Oh, I almost forgot the important part:

Substituting commas for those backslashes DOES resolve the problem, but ALL
THREE must be replaced.

Substituting \\ for \ DOES NOT resolve the problem.

Substituting \t for \ DOES resolve the problem.

Substituting "\ " for "\" DOES NOT resolve the problem.

[Bug target/80697] On PowerPC, the spec 2006 benchmark milc had a 5.6% regression under GCC 7.1 compared to GCC 6.3.

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #2 from Michael Meissner  ---
I did some comparisons to older benchmarks that were run on the same machine.

On April 21, 2016 I did a benchmark run with subversion id 235167, and milc's
speed was roughly the same as GCC 6.3.

On May 12, 2016, I did a benchmark run with subversion id 236136, and milc's
speed was roughly the same as GCC 7.1.

Here is the function that seems to be causing the performance issues:

Instructions   | gcc7 | gcc6 | diff | Class
   |  |  |  | =
fadd, xsaddd   |   12 |0 |  -12 | DF add
fmadd, xsmadd*dp   |   20 |   28 |8 | DF multiply and add
fmsub, xsmsub*dp   |4 |0 |   -4 | DF multiply and subtract
fmul, xsmuldp  |   24 |8 |  -16 | DF multiply
fnmsub, xsnmsub*dp |0 |   12 |   12 | DF negate, multiply and subtract
fsub, xssubdp  |4 |0 |   -4 | DF subtract
ld |5 |0 |   -5 | load doubleword offset
lfd|   48 |   53 |5 | load DF offset
mtvsrd |5 |0 |   -5 | move to vsr doubleword
xvadddp|3 |0 |   -3 | V2DF add
xvmadd*dp  |5 |7 |2 | V2DF multiply and add
xvmuldp|6 |2 |   -4 | V2DF multiply
xvnmsub*dp |1 |3 |2 | V2DF negate, multiply and subtract
xvsubdp|1 |0 |   -1 | V2DF subtract

If I had to guess there are two things going on that are based in PowerPC
changes in that period.  The first is a rather massive patch that I put in to
add ISA 3.0 d-form (register+offset) support.  It looks like it causes the
register allocator to load values in GPRs and do direct moves when it wants to
move a value to a scalar DFmode value in a traditional Altivec register (which
prior to ISA 3.0 did not have d-form support).  This accounts for the LD
instead of the LFD instructions and the MTVSRD.  While it is better than a
store and a load, a direct move on power8 systems is fairly slow.  I ran into a
similar thing with PR 68163, and fixing it involved tuning the constraints for
the moves (SFmode in the case of 68163, DFmode here).

The second thing is Aaron Sawdey's patch for tuning the reassociation width
went in in this period.  This likely affects when we can merge adds and
multiply into the PowerPC fma instructions.

2016-05-04  Aaron Sawdey  

* config/rs6000/rs6000.c (rs6000_reassociation_width): Add
function for TARGET_SCHED_REASSOCIATION_WIDTH to enable
parallel reassociation for power8 and forward.


2016-05-11  Michael Meissner  

* config/rs6000/predicates.md (quad_memory_operand): Move most of
the code into quad_address_p and call it to share code with
vsx_quad_dform_memory_operand.
(vsx_quad_dform_memory_operand): New predicate for ISA 3.0 vector
d-form support.
* config/rs6000/rs6000.opt (-mlra): Switch to being an option mask
bit instead of being a separate word.  Split -mpower9-dform into
two switches, -mpower9-dform-scalar and -mpower9-dform-vector.
* config/rs6000/rs6000.c (RELOAD_REG_QUAD_OFFSET): New addr_mask
for the register class supporting 128-bit quad word memory offsets.
(mode_supports_vsx_dform_quad): Helper function to return if the
register class uses quad word memory offsets.
(rs6000_debug_addr_mask): Add support for quad word memory offsets.
(rs6000_debug_reg_global): Always print if we are using LRA or not.
(rs6000_setup_reg_addr_masks): If ISA 3.0 vector d-form
instructions are enabled, set up the appropriate addr_masks for
128-bit types.
(rs6000_init_hard_regno_mode_ok): wb constraint is now based on
-mpower9-dform-scalar, instead of -mpower9-dform.
(rs6000_option_override_internal): Split -mpower9-dform into two
switches, -mpower9-dform-scalar and -mpower9-dform-vector.  The
-mpower9-dform switch sets or clears both.  If we are not using
the LRA register allocator, do not enable -mpower9-dform-vector by
default.  If we are using LRA, enable -mpower9-dform-vector and
-mvsx-timode if it is appropriate.  Issue a warning if either
-mpower9-dform-vector or -mvsx-timode are explicitly used without
enabling LRA.
(quad_address_offset_p): New helper function to return if the
offset is legal for quad word memory instructions.
(quad_address_p): New function to determin if GPR or vector
register quad word memory addresses are legal.
   

[Bug c++/80716] New: Death by Documentation (SEGFAULT)

[breakpoint at runbox dot com]

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

Bug ID: 80716
   Summary: Death by Documentation (SEGFAULT)
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: breakpoint at runbox dot com
  Target Milestone: ---

This bug is odd, in that it looks like it must be a preprocessor problem, but
it seems to be the compiler itself that is crashing.

Verbatim minimal code:


#define DEATH_BY_DOCUMENTATION

class dismissed {
public:
dismissed() {
// Construct the tree used for depth-first traversal testing.
//
// The tree has this structure:
//
//  1
// /|\
//2 7 8
//   /|   |\
//  3 6   9 12
// /| |\
//4 510 11
}
};



No lines have trailing whitespace.  Line 19 consists of a newline only and ends
the file.

Causes a segmentation fault in gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
(Fedora 25, 64-bit):

 internal compiler error: Segmentation fault
 #define DEATH_BY_DOCUMENTATION

Please submit a full bug report,
with preprocessed source if appropriate.


Flags: -O0 -g -ggdb3 -gdwarf-4 -fvar-tracking -fvar-tracking-assignments
-DGTEST_USE_OWN_TR1_TUPLE=0 -DGTEST_HAS_PTHREAD=1 -Dgtest_build_tests=ON
-DHAVE_EXPAT_CONFIG_H -std=gnu++03 -Wno-error=vla

Most extraneous material has been stripped.  The #define is required, but the
symbol seems to be irrelevant.  Adding newlines and/or semicolons before the
#define does not change the result.

Removing the #define avoids the segfault, and results in:

xxx.cpp:11:13: error: multi-line comment [-Werror=comment]
 // /|\
 ^
xxx.cpp:13:13: error: multi-line comment [-Werror=comment]
 //   /|   |\
 ^
xxx.cpp:15:13: error: multi-line comment [-Werror=comment]
 // /| |\


This is part of a larger build, but unfortunately, that is composed of
proprietary material.  So, this report may be mostly useful as additional data
for a similar bug, if anyone knows of one that exists, or may point out some
material that needs a code review.

If built as a standalone a.out with a token main(){}, all goes well.  However,
the code above is verbatim from our minimal crash case in the larger build;
note that it has no #includes.

It is possible, but unlikely, that this is somehow related to cotire; if I
figure that out, I'll add it in.

Does anyone know of any rough edges related to escape sequences in comments, or
possibly trigraphs or something that seem like they might be related to this?

Thanks.

[Bug fortran/80666] character length parameter fails if declaration order incorrect

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #3 from Harald Anlauf  ---
(In reply to Jos de Kloe from comment #2)
> (In reply to Dominique d'Humieres from comment #1)
> > Why do you think this a bug in gfortran?
> > 
> > The code compiles if you remove 'implicit none'. With it you have to define
> > 'keylen' before using it, as in you second test.
> 
> We had the impression our code was correct since it compiles without problem
> with pgf90 and ifort and older gfortran versions. I understand that extra
> checks are added when the compiler evolves, and that the democratic argument
> is maybe not applicable here, so if you think there is a rule in the fortran
> standard that forbids this way of coding, feel free to point it out and we
> can close the bug.

Compiling the code in comment #0 with ifort gives:

% ifort -c pr80666.f90 -stand
pr80666.f90(3): warning #7346: The CHARACTER* form of a CHARACTER declaration
is an obsolescent feature in Fortran 2003.
  character*(keylen), intent(in) :: key
-^
pr80666.f90(3): warning #8586: Implicit type is given to allow out-of-order
declaration. Non-standard extension.   [KEYLEN]
  character*(keylen), intent(in) :: key
-^


Or with Sun:

% sunf95 -c pr80666.f90 -ansi

  integer, intent(in):: keylen
^  
"pr80666.f90", Line = 4, Column = 37: ANSI: Implicit typing is confirmed for
object "KEYLEN".  The Fortran standard requires typing before reference with
IMPLICIT NONE.

f90comp: 5 SOURCE LINES
f90comp: 0 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 1 ANSI


Just try to write standard conforming code if possible.
And use the appropriate compiler checking option.

[Bug target/79634] ICE in expand_builtin_with_bounds, at builtins.c:7490

[aivchenk at gmail dot com]

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

--- Comment #5 from Alexander Ivchenko  ---
(In reply to Ilya Enkovich from comment #4)
> We hit function pointer propagation issues before and chkp_redirect_edge
> with corresponding code in redirect_call_stmt_to_callee appeared to handle
> them. Why doesn't it work in this case?

cgraph_edge::redirect_call_stmt_to_callee is not called at all here. I'll try
to figure out why tomorrow

[Bug middle-end/80715] New: NULL pointer dereferenced in find_costs_and_classes, at ira-costs.c

[zeccav at gmail dot com]

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

Bug ID: 80715
   Summary: NULL pointer dereferenced in find_costs_and_classes,
at ira-costs.c
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

This seems to be linked to 78650

/*NULL pointer dereferenced in find_costs_and_classes, at ira-costs.c:1748 */
/* must be compiled with options "-O2 -flive-range-shrinkage" */
/* double checked with ira_assert and ENABLE_IRA_CHECKING */
/*/home/vitti/f95/cc/gccerr55.c: In function ‘f’:
/home/vitti/f95/cc/gccerr55.c:27:1: internal compiler error: in
find_costs_and_classes, at ira-costs.c:1748
 }
 ^
0x863be3 find_costs_and_classes
../../gcc/gcc/ira-costs.c:1748
0x864959 ira_costs()
../../gcc/gcc/ira-costs.c:2261
0x85e356 ira_build()
../../gcc/gcc/ira-build.c:3420
0x855ccb ira
../../gcc/gcc/ira.c:5302
0x855ccb execute
../../gcc/gcc/ira.c:5613
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
*/
//ira-costs.c:1748 ira_assert(cost_classes_ptr);/*!vz pr60268.c -O2
-flive-range-shrinkage*/
//1749  enum reg_class *cost_classes = cost_classes_ptr->classes;
void f()
{
}

[Bug bootstrap/80714] New: [8 Regression] profiledbootstrap failed with LTO

[hjl.tools at gmail dot com]

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

Bug ID: 80714
   Summary: [8 Regression] profiledbootstrap failed with LTO
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: bergner at vnet dot ibm.com
  Target Milestone: ---

On Linux/x86-64, r247844 caused profiledbootstrap failure:

./../src-trunk/gcc/genrecog.c: In function ‘print_test’:
../../src-trunk/gcc/genrecog.c:4619:1: error: extra outgoing edge 29->30
 print_test (output_state *os, const rtx_test , bool is_param,
 ^
../../src-trunk/gcc/genrecog.c:4619:1: internal compiler error:
verify_flow_info failed
0x72f3c7 verify_flow_info()
../../src-trunk/gcc/cfghooks.c:260
0xfea51c checking_verify_flow_info
../../src-trunk/gcc/cfghooks.h:198
0xfea51c cleanup_tree_cfg_noloop
../../src-trunk/gcc/tree-cfgcleanup.c:837
0xfea51c cleanup_tree_cfg()
../../src-trunk/gcc/tree-cfgcleanup.c:883
0xd992fc execute_function_todo
../../src-trunk/gcc/passes.c:1921
0xd96414 do_per_function
../../src-trunk/gcc/passes.c:1652
0xd96717 execute_todo
../../src-trunk/gcc/passes.c:2022
0xd9ccec execute_one_ipa_transform_pass
../../src-trunk/gcc/passes.c:2219
0xd9ccec execute_all_ipa_transforms()
../../src-trunk/gcc/passes.c:2255
0x78d43e cgraph_node::expand()
../../src-trunk/gcc/cgraphunit.c:2035
0x790832 expand_all_functions
../../src-trunk/gcc/cgraphunit.c:2178
0x790832 symbol_table::compile()
../../src-trunk/gcc/cgraphunit.c:2535
0x656af4 lto_main()
../../src-trunk/gcc/lto/lto.c:3334
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[7]: *** [/tmp/ccH2Om7R.ltrans2.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Makefile:2794: recipe for target 'build/genrecog' failed
make[6]: *** [build/genrecog] Error 1

when gcc is configured with

--prefix=/export/gnu/import/git/gcc-regression-bootstrap/master/247851/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--enable-languages=c,c++ --enable-bootstrap --with-fpmath=sse
--with-build-config=bootstrap-lto --disable-werror --disable-multilib
--disable-libcc1 --disable-libcilkrts --disable-libsanitizer

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

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle  ---
Author: jvdelisle
Date: Thu May 11 20:40:49 2017
New Revision: 247930

URL: https://gcc.gnu.org/viewcvs?rev=247930=gcc=rev
Log:
2017-05-11  Jerry DeLisle  

PR fortran/78659
* io.c (dtio_procs_present): Add new function to check for DTIO
procedures relative to I/O statement READ or WRITE.
(gfc_resolve_dt): Add namelist checks using the new function.
* resolve.c (dtio_procs_present): Remove function and related
namelist checks. (resolve_fl_namelist): Add check specific to
Fortran 95 restriction on namelist objects.

* gfortran.dg/namelist_91.f90: New test.
* gfortran.dg/namelist_92.f90: New test.
* gfortran.dg/namelist_93.f90: New test.
* gfortran.dg/namelist_94.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/namelist_91.f90
trunk/gcc/testsuite/gfortran.dg/namelist_92.f90
trunk/gcc/testsuite/gfortran.dg/namelist_93.f90
trunk/gcc/testsuite/gfortran.dg/namelist_94.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug target/80713] recent crash in update_dep_bb

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from David Binderman  ---
Last person to change source code file tree-ssa-tail-merge.c
was Richard Biener in revision 247882.

Richard, would you be able to offer us some advice on your recent change ?

[Bug target/80713] recent crash in update_dep_bb

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Reduced code is this:

a, b, d, e, f;
*c;
g() {
  for (;;) {
if (*c) {
  int h;
  *c = 
} else
  b = 0;
if (f)
  *c = g;
else
  for (; a; a++)
for (;;) {
  if (d)
break;
  c = e;
}
  }
}

[Bug target/80695] gratuitous use of stxvx to store multiple pointers

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

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

[Bug target/80695] gratuitous use of stxvx to store multiple pointers

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Author: wschmidt
Date: Thu May 11 20:16:02 2017
New Revision: 247928

URL: https://gcc.gnu.org/viewcvs?rev=247928=gcc=rev
Log:
[gcc]

2017-05-11  Bill Schmidt  

PR target/80695
* config/rs6000/rs6000.c (rs6000_builtin_vectorization_cost):
Account for direct move costs for vec_construct of integer
vectors.

[gcc/testsuite]

2017-05-11  Bill Schmidt  

PR target/80695
* gcc.target/powerpc/pr80695-p8.c: New file.
* gcc.target/powerpc/pr80695-p9.c: New file.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr80695-p8.c
trunk/gcc/testsuite/gcc.target/powerpc/pr80695-p9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug c/80713] New: recent crash in update_dep_bb

[dcb314 at hotmail dot com]

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

Bug ID: 80713
   Summary: recent crash in update_dep_bb
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 41341
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41341=edit
C source code

Between revisions 247856 and 247911, the attached code went
wrong and crashed the compiler with flag -O2.

I'll have a go at reducing the code.

$ ../results.247856/bin/gcc -c -O2 -w bug352.c
$ ../results.247911/bin/gcc -c -O2 -w bug352.c
destDir/testFile.3785.c: In function ‘func_1’:
destDir/testFile.3785.c:239:24: internal compiler error: Segmentation fault
0xc3b34f crash_signal
../../trunk/gcc/toplev.c:337
0xe52101 update_dep_bb
../../trunk/gcc/tree-ssa-tail-merge.c:408
0xe52101 stmt_update_dep_bb
../../trunk/gcc/tree-ssa-tail-merge.c:430
0xe52101 same_succ_hash
../../trunk/gcc/tree-ssa-tail-merge.c:453

[Bug target/79634] ICE in expand_builtin_with_bounds, at builtins.c:7490

[ienkovich at gcc dot gnu.org]

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

--- Comment #4 from Ilya Enkovich  ---
We hit function pointer propagation issues before and chkp_redirect_edge with
corresponding code in redirect_call_stmt_to_callee appeared to handle them. Why
doesn't it work in this case?

[Bug ipa/79787] ICE in remove_unreachable_nodes, at ipa.c:469

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #3 from Ilya Enkovich  ---
This code in remove_unreachable_nodes is supposed to prevent removal of fn1.
Thusly we remove node which is not considered as unreachable by
remove_unreachable_nodes.

Did you try to find out how fn1 node is removed and prevent it?

[Bug target/80706] [7/8 Regression] peephole2 uses uninitialized stack variables on i686

[ubizjak at gmail dot com]

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

--- Comment #15 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #13)
> Created attachment 41340 [details]
> gcc8-pr80706.patch
> 
> I came up with this (in addition to #c7).  This removes one of the two
> useless stores in the original pr71245-1.c testcase and restores the above
> pr71245-1.c modification to what it used to look before (well, even better,
> as it reserves smaller stack).

The committed patch fixes unwanted matching by introducing specialized SSE
load/store patterns. I don't think it is worth complicating sync.md any
further, the stack slot is shared, and the patched compiler generates exactly
the same assembly as before.

[Bug target/80706] [7/8 Regression] peephole2 uses uninitialized stack variables on i686

[uros at gcc dot gnu.org]

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

--- Comment #14 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu May 11 18:12:25 2017
New Revision: 247921

URL: https://gcc.gnu.org/viewcvs?rev=247921=gcc=rev
Log:
PR target/80706
* config/i386/sync.md (UNSPEC_LDX_ATOMIC): New unspec.
(UNSPEC_STX_ATOMIC): Ditto.
(loaddi_via_sse): New insn.
(storedi_via_sse): Ditto.
(atomic_loaddi_fpu): Emit loaddi_via_sse and storedi_via_sse.
Update corresponding peephole2 patterns.
(atomic_storedi_fpu): Ditto.

testsuite/ChangeLog:

PR target/80706
* gcc.target/i386/pr80706.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr80706.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sync.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/80712] mention the name of the attribute being ignored

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=70125

--- Comment #1 from Martin Sebor  ---
See also bug 70125 for a similar request/problem report.

[Bug c++/80712] mention the name of the attribute being ignored

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-11
 Ever confirmed|0   |1

[Bug c++/70538] ICE on a deprecated access declaration in instantiate_template_1, at cp/pt.c:17310

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #6 from Paolo Carlini  ---
Done.

[Bug c++/70538] ICE on a deprecated access declaration in instantiate_template_1, at cp/pt.c:17310

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu May 11 17:13:42 2017
New Revision: 247917

URL: https://gcc.gnu.org/viewcvs?rev=247917=gcc=rev
Log:
2017-05-11  Paolo Carlini  

PR c++/70538
* g++.dg/cpp0x/pr70538.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr70538.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/80707] [8 Regression] r247844 causes error: extra outgoing edge

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
Also causes my local gcc bootstrap to fail. 

I think it's the -O3 -march=native causing it.
I'll try a bootstrap with the usual -O2 instead.

[Bug c++/70538] ICE on a deprecated access declaration in instantiate_template_1, at cp/pt.c:17310

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
This is fixed in 7.1.0: I'm adding a testcase and closing the bug.

[Bug c++/80712] New: mention the name of the attribute being ignored

[tromey at gcc dot gnu.org]

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

Bug ID: 80712
   Summary: mention the name of the attribute being ignored
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

I saw an error when building firefox with gcc 6.3.1 (fedora 25 system gcc):

/home/tromey/firefox-git/gecko/js/src/frontend/EitherParser.h:253:13: error:
ignoring attributes applied to ‘__va_list_tag’ after definition
[-Werror=attributes]

You can see more info here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1363116

I don't know what attribute might be applied here.  It would be handy if
gcc mentioned which attribute it was ignoring.  (FWIW I am not sure
but I suspect this error might be a gcc bug.)

[Bug target/57952] AVX/AVX2 no ymm registers used in a trivial reduction

[mmokrejs at gmail dot com]

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

--- Comment #3 from mmokrejs at gmail dot com ---
Weird, why g++ can do the task although probably less efficiently than icc?

$ g++ -O3 -march=core-avx-i -mtune=core-avx-i -mavx2 stream.c  ; objdump -d
a.out | grep ymm
stream.c:106:48: warning: deprecated conversion from string constant to 'char*'
[-Wwrite-strings]
 "Add:   ", "Triad: ", "Dot:   "};
^
stream.c:106:48: warning: deprecated conversion from string constant to 'char*'
[-Wwrite-strings]
stream.c:106:48: warning: deprecated conversion from string constant to 'char*'
[-Wwrite-strings]
stream.c:106:48: warning: deprecated conversion from string constant to 'char*'
[-Wwrite-strings]
stream.c:106:48: warning: deprecated conversion from string constant to 'char*'
[-Wwrite-strings]
  4006ac:   c5 fd 28 0d 2c 11 00vmovapd 0x112c(%rip),%ymm1#
4017e0 <_ZL5label+0xa0>
  4006b4:   c5 fd 28 05 44 11 00vmovapd 0x1144(%rip),%ymm0#
401800 <_ZL5label+0xc0>
  4006c0:   c5 fd 29 88 80 61 abvmovapd %ymm1,0x4cab6180(%rax)
  4006cc:   c5 fd 29 80 60 c1 85vmovapd %ymm0,0x2685c160(%rax)
  400738:   c5 fd 28 01 vmovapd (%rcx),%ymm0
  400740:   c5 fd 58 c0 vaddpd %ymm0,%ymm0,%ymm0
  400744:   c5 fd 29 41 e0  vmovapd %ymm0,-0x20(%rcx)
  400803:   c5 fd 28 15 15 10 00vmovapd 0x1015(%rip),%ymm2#
401820 <_ZL5label+0xe0>
  400817:   c5 fd 29 95 d0 fd ffvmovapd %ymm2,-0x230(%rbp)
  4008d0:   c5 fd 28 95 d0 fd ffvmovapd -0x230(%rbp),%ymm2
  400908:   c5 fd 29 10 vmovapd %ymm2,(%rax)
  40091c:   c5 fd 29 95 d0 fd ffvmovapd %ymm2,-0x230(%rbp)
  40098c:   c5 fd 28 95 d0 fd ffvmovapd -0x230(%rbp),%ymm2
  4009b8:   c5 fd 28 80 80 61 abvmovapd 0x4cab6180(%rax),%ymm0
  4009c4:   c5 fd 58 80 60 c1 85vaddpd 0x2685c160(%rax),%ymm0,%ymm0
  4009cc:   c5 fd 29 80 60 21 60vmovapd %ymm0,0x602160(%rax)
  4009e3:   c5 fd 29 95 d0 fd ffvmovapd %ymm2,-0x230(%rbp)
  400a56:   c5 fd 28 95 d0 fd ffvmovapd -0x230(%rbp),%ymm2
  400a80:   c5 ed 59 80 80 c1 85vmulpd 0x2685c180(%rax),%ymm2,%ymm0
  400a88:   c5 fd 58 80 80 61 abvaddpd 0x4cab6180(%rax),%ymm0,%ymm0
  400a94:   c5 fd 29 80 60 21 60vmovapd %ymm0,0x602160(%rax)
  400aab:   c5 fd 29 95 d0 fd ffvmovapd %ymm2,-0x230(%rbp)
  400b1e:   c5 fd 28 95 d0 fd ffvmovapd -0x230(%rbp),%ymm2
  400b77:   c5 fd 29 95 d0 fd ffvmovapd %ymm2,-0x230(%rbp)
  400bab:   c5 fd 28 95 d0 fd ffvmovapd -0x230(%rbp),%ymm2
  401006:   c4 e3 6d 18 95 28 ffvinsertf128
$0x1,-0xd8(%rbp),%ymm2,%ymm2
  401018:   c4 e3 7d 18 85 48 ffvinsertf128
$0x1,-0xb8(%rbp),%ymm0,%ymm0
  401022:   c5 ed 5c 95 10 ff ffvsubpd -0xf0(%rbp),%ymm2,%ymm2
  40102a:   c5 fd 5c 85 30 ff ffvsubpd -0xd0(%rbp),%ymm0,%ymm0
  401032:   c5 fd 28 25 66 07 00vmovapd 0x766(%rip),%ymm4#
4017a0 <_ZL5label+0x60>
  401044:   c5 ed 59 d4 vmulpd %ymm4,%ymm2,%ymm2
  401048:   c5 fd 59 c4 vmulpd %ymm4,%ymm0,%ymm0
  40104c:   c5 fd e6 d2 vcvttpd2dq %ymm2,%xmm2
  401058:   c5 fd e6 c0 vcvttpd2dq %ymm0,%xmm0
  40105c:   c4 e3 6d 38 d0 01   vinserti128 $0x1,%xmm0,%ymm2,%ymm2
  401062:   c4 e2 6d 3d d3  vpmaxsd %ymm3,%ymm2,%ymm2
  401067:   c4 e2 6d 39 15 50 07vpminsd 0x750(%rip),%ymm2,%ymm2   
# 4017c0 <_ZL5label+0x80>
  401096:   c4 e3 75 18 8d 68 ffvinsertf128
$0x1,-0x98(%rbp),%ymm1,%ymm1
  4010a4:   c5 f5 5c 8d 50 ff ffvsubpd -0xb0(%rbp),%ymm1,%ymm1
  4010b7:   c5 f5 59 cc vmulpd %ymm4,%ymm1,%ymm1
  4010bb:   c5 fd e6 c9 vcvttpd2dq %ymm1,%xmm1
  4010d3:   c4 e3 7d 18 45 88 01vinsertf128
$0x1,-0x78(%rbp),%ymm0,%ymm0
  4010da:   c5 fd 5c 85 70 ff ffvsubpd -0x90(%rbp),%ymm0,%ymm0
  4010e2:   c5 fd 59 c4 vmulpd %ymm4,%ymm0,%ymm0
  4010e6:   c5 fd e6 c0 vcvttpd2dq %ymm0,%xmm0
  4010ea:   c4 e3 75 38 c0 01   vinserti128 $0x1,%xmm0,%ymm1,%ymm0
  4010f5:   c4 e2 7d 3d c3  vpmaxsd %ymm3,%ymm0,%ymm0
  4010fa:   c4 e2 6d 39 c0  vpminsd %ymm0,%ymm2,%ymm0
  4010ff:   c4 e3 7d 46 c8 01   vperm2i128 $0x1,%ymm0,%ymm0,%ymm1
  401105:   c4 e2 7d 39 c1  vpminsd %ymm1,%ymm0,%ymm0
  40110f:   c5 f5 73 d8 08  vpsrldq $0x8,%ymm0,%ymm1
  401114:   c4 e2 7d 39 c9  vpminsd %ymm1,%ymm0,%ymm1
  401119:   c5 fd 73 d9 04  vpsrldq $0x4,%ymm1,%ymm0
  40111e:   c4 e2 75 39 c0  vpminsd %ymm0,%ymm1,%ymm0
  4011e0:   c4 e2 7d 19 c0  vbroadcastsd %xmm0,%ymm0
  4011f0:   c5 fd 29 00 vmovapd %ymm0,(%rax)
  401218:   c5 fd 28 80 80 61 abvmovapd 0x4cab6180(%rax),%ymm0
  401224:   c5 fd 58 80 60 c1 85vaddpd 

[Bug target/57952] AVX/AVX2 no ymm registers used in a trivial reduction

[mmokrejs at gmail dot com]

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

mmokrejs at gmail dot com changed:

   What|Removed |Added

 CC||mmokrejs at gmail dot com

--- Comment #2 from mmokrejs at gmail dot com ---
I see a similar problem with gcc-4.9.6 unable to use 256-bit YMM registers. It
only uses 128-bit XMM registers from SSE instructions.

Try https://people.eecs.berkeley.edu/~samw/research/code/stream/stream.c

$ gcc -march=native -o stream stream.c
$ objdump -d stream | grep ymm
$


icc does the job properly:

$ icc -qopenmp -O3 -xhost stream.c
$ objdump -d a.out | grep ymm
  401323:   c5 fd 10 00 vmovupd (%rax),%ymm0
  40132d:   c5 fd 10 48 20  vmovupd 0x20(%rax),%ymm1
  401332:   c5 7d 10 40 40  vmovupd 0x40(%rax),%ymm8
  401337:   c5 7d 10 48 60  vmovupd 0x60(%rax),%ymm9
  40133c:   c5 7d 10 1d 3c 65 00vmovupd 0x653c(%rip),%ymm11#
407880 <_IO_stdin_used+0x340>
  401344:   c5 fd 5c 50 f8  vsubpd -0x8(%rax),%ymm0,%ymm2
  401349:   c5 f5 5c 58 18  vsubpd 0x18(%rax),%ymm1,%ymm3
  40134e:   c5 3d 5c 50 38  vsubpd 0x38(%rax),%ymm8,%ymm10
  401353:   c5 35 5c 60 58  vsubpd 0x58(%rax),%ymm9,%ymm12
  401358:   c5 a5 59 e2 vmulpd %ymm2,%ymm11,%ymm4
  401361:   c5 a5 59 f3 vmulpd %ymm3,%ymm11,%ymm6
  401365:   c4 41 25 59 ea  vmulpd %ymm10,%ymm11,%ymm13
  40136a:   c4 41 25 59 fc  vmulpd %ymm12,%ymm11,%ymm15
  40136f:   c5 fd e6 ec vcvttpd2dq %ymm4,%xmm5
  401373:   c5 fd e6 fe vcvttpd2dq %ymm6,%xmm7
  401377:   c4 41 7d e6 f5  vcvttpd2dq %ymm13,%xmm14
  40137c:   c5 f5 ef c9 vpxor  %ymm1,%ymm1,%ymm1
  401380:   c4 41 7d e6 ef  vcvttpd2dq %ymm15,%xmm13
  401385:   c4 e2 7d 58 e2  vpbroadcastd %xmm2,%ymm4
  40139c:   c4 e3 55 38 c7 01   vinserti128 $0x1,%xmm7,%ymm5,%ymm0
  4013a2:   c4 e2 7d 3d d9  vpmaxsd %ymm1,%ymm0,%ymm3
  4013a7:   c4 e2 65 39 f4  vpminsd %ymm4,%ymm3,%ymm6
  4013ac:   c4 43 0d 38 fd 01   vinserti128 $0x1,%xmm13,%ymm14,%ymm15
  4013b2:   c4 e2 05 3d e9  vpmaxsd %ymm1,%ymm15,%ymm5
  4013b7:   c4 e2 55 39 fe  vpminsd %ymm6,%ymm5,%ymm7
  4013bc:   c4 c3 7d 39 f8 01   vextracti128 $0x1,%ymm7,%xmm8
  401caa:   c5 fd 57 c0 vxorpd %ymm0,%ymm0,%ymm0
  401cc8:   c5 fd 10 16 vmovupd (%rsi),%ymm2
  401cd0:   c5 fd 10 5e 20  vmovupd 0x20(%rsi),%ymm3
  401cd5:   c5 fd 10 66 40  vmovupd 0x40(%rsi),%ymm4
  401cda:   c5 fd 10 76 60  vmovupd 0x60(%rsi),%ymm6
  401ce7:   c4 e2 ed b8 0f  vfmadd231pd (%rdi),%ymm2,%ymm1
  401cec:   c4 e2 e5 b8 47 20   vfmadd231pd 0x20(%rdi),%ymm3,%ymm0
  401cf2:   c5 dd 59 6f 40  vmulpd 0x40(%rdi),%ymm4,%ymm5
  401cf7:   c5 cd 59 7f 60  vmulpd 0x60(%rdi),%ymm6,%ymm7
  401cfc:   c5 d5 58 c9 vaddpd %ymm1,%ymm5,%ymm1
  401d00:   c5 c5 58 c0 vaddpd %ymm0,%ymm7,%ymm0
  401d0d:   c5 f5 58 c0 vaddpd %ymm0,%ymm1,%ymm0
  401d11:   c4 e3 7d 19 c1 01   vextractf128 $0x1,%ymm0,%xmm1
  401d6a:   c5 fd 10 8c c3 c0 bevmovupd 0x60bec0(%rbx,%rax,8),%ymm1
  401d73:   c5 f5 59 94 c3 c0 60vmulpd
0x268660c0(%rbx,%rax,8),%ymm1,%ymm2
  401d7c:   c5 ed 58 c0 vaddpd %ymm0,%ymm2,%ymm0
  401d85:   c4 e3 7d 19 c1 01   vextractf128 $0x1,%ymm0,%xmm1
  401f9b:   c4 e2 7d 19 44 24 10vbroadcastsd 0x10(%rsp),%ymm0
  401fa2:   c5 fd 10 8c d1 c0 bevmovupd 0x60bec0(%rcx,%rdx,8),%ymm1
  401fab:   c4 e2 fd a8 8c d1 c0vfmadd213pd
0x268660c0(%rcx,%rdx,8),%ymm0,%ymm1
  401fb5:   c5 fd 2b 8c d1 c0 02vmovntpd %ymm1,0x4cac02c0(%rcx,%rdx,8)
  40213b:   c5 fd 10 84 d1 c0 60vmovupd 0x268660c0(%rcx,%rdx,8),%ymm0
  402144:   c5 fd 58 8c d1 c0 bevaddpd
0x60bec0(%rcx,%rdx,8),%ymm0,%ymm1
  40214d:   c5 fd 2b 8c d1 c0 02vmovntpd %ymm1,0x4cac02c0(%rcx,%rdx,8)
  4022dd:   c4 e2 7d 19 44 24 10vbroadcastsd 0x10(%rsp),%ymm0
  4022e4:   c5 fd 2b 84 d1 c0 02vmovntpd %ymm0,0x4cac02c0(%rcx,%rdx,8)
  4025c2:   c5 fd 10 05 76 52 00vmovupd 0x5276(%rip),%ymm0#
407840 <_IO_stdin_used+0x300>
  4025de:   c5 fd 59 0e vmulpd (%rsi),%ymm0,%ymm1
  4025e2:   c5 fd 11 0e vmovupd %ymm1,(%rsi)
  402759:   c5 fd 10 15 ff 50 00vmovupd 0x50ff(%rip),%ymm2#
407860 <_IO_stdin_used+0x320>
  402761:   c5 fd 10 0d d7 50 00vmovupd 0x50d7(%rip),%ymm1#
407840 <_IO_stdin_used+0x300>
  402769:   c5 fd 57 c0 vxorpd %ymm0,%ymm0,%ymm0
  40276d:   c5 fd 2b 94 f8 c0 60vmovntpd %ymm2,0x268660c0(%rax,%rdi,8)
  402776:   c5 fd 2b 8c f8 c0 

[Bug c++/80711] warn on non-const accessor member functions

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Good idea.

[Bug c++/80682] __is_trivially_constructible(void, int) returns true.

[ville.voutilainen at gmail dot com]

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

--- Comment #5 from Ville Voutilainen  ---
This patch doesn't fully provide the means for a library implementation to just
call the intrinsic from the library trait. I have
a patch that does, which I'm testing.

[Bug target/79634] ICE in expand_builtin_with_bounds, at builtins.c:7490

[aivchenk at gmail dot com]

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

--- Comment #3 from Alexander Ivchenko  ---
The problem here is that when CHKP is instrumenting call statement "i();" it
doesn't know that it's a builtin call. When optimizations come into play,
namely ccp pass, it becomes known that the call is to memmove and it is
actually is replaced as memmove. But we instrumented the call statement, so we
expand it like that:

if (CALL_WITH_BOUNDS_P (exp)) 
  return expand_builtin_with_bounds (exp, target, subtarget,  
 tmode, ignore); 

and then this assert fails:

gcc_assert (fcode > BEGIN_CHKP_BUILTINS   
&& fcode < END_CHKP_BUILTINS);


Here is untested fix to check whether we substitute builtin and, if the builtin
is of the instrumentable type, make the call to instrumented builtin:

diff --git a/gcc/tree-ssa-propagate.c b/gcc/tree-ssa-propagate.c
index 0693802..9e9c4a3 100644
--- a/gcc/tree-ssa-propagate.c
+++ b/gcc/tree-ssa-propagate.c
@@ -38,6 +38,8 @@
 #include "cfgloop.h"
 #include "tree-cfgcleanup.h"
 #include "cfganal.h"
+#include "cgraph.h"
+#include "ipa-chkp.h"

 /* This file implements a generic value propagation engine based on
the same propagation used by the SSA-CCP algorithm [1].
@@ -1072,6 +1074,13 @@ substitute_and_fold_dom_walker::before_dom_children
(basic_block bb)
  fold_stmt (, follow_single_use_edges);
  stmt = gsi_stmt (i);
  gimple_set_modified (stmt, true);
+ if (flag_check_pointer_bounds &&
+ gimple_code (stmt) == GIMPLE_CALL)
+   {
+ tree fndecl = gimple_call_fndecl (stmt);
+ fndecl = chkp_maybe_clone_builtin_fndecl (fndecl);
+ gimple_call_set_fndecl (stmt, fndecl);
+   }
}

   /* Some statements may be simplified using propagator

[Bug middle-end/80710] Stack smashing detected in correct code depending on optimization flag

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
So what happening here is you are not calling the function in ABI compatible
way at all.  So this code is way undefined.

[Bug c++/80711] New: warn on non-const accessor member functions

[msebor at gcc dot gnu.org]

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

Bug ID: 80711
   Summary: warn on non-const accessor member functions
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

C++ accessor (and similar) member functions that return a value computed from
one or more private data members without modifying the owning object can and
should be declared const.  Doing so not only improves the const-correctness of
code that relies on objects of the type, it also aids its analyzability.  It's
easy (and not uncommon) to forget to declare accessors const.  GCC could help
detect the missing const by issuing a warning on such accessors, similarly to
how it helps detect candidates for attribute const and pure.

This is an enhancement to request to add such a warning.  The test case below
illustrates where it would be issued and shows the similar -Wsuggest-attribute
warning that the new one could be modeled on.

$ cat t.C && gcc -O2 -S -Wall -Wextra -Wsuggest-attribute=pure t.C
class Int
{
public:
  int get () { return val; }   // suggested warning: function can be declared
const

private:
  int val;
};

int get_int (Int )
{
  return i.get ();
}
t.C: In function ‘int get_int(Int&)’:
t.C:10:5: warning: function might be candidate for attribute ‘pure’
[-Wsuggest-attribute=pure]
 int get_int (Int )
 ^~~

[Bug c++/80711] warn on non-const accessor member functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug middle-end/80710] Stack smashing detected in correct code depending on optimization flag

[dr.markus.hoffmann at gmx dot de]

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

--- Comment #1 from dr.markus.hoffmann at gmx dot de  ---
This example wants to show, that the optimizer destroys compatibility to the
ABI, either with optimizing something in the calling procedure (likely) or in
the called function. The same error happens, when test2 is in a .so library and
dynamically linked to the main program at runtime. Since the main program does
not know the function prototype at compile time it has to rely on calling it in
an ABI-compatible way.

[Bug rtl-optimization/80709] [8 Regression] ICE in setup_preferred_alternate_classes_for_new_pseudos, at ira.c:2772

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-05-11
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Can't reproduce it with a recent trunk. Can you provide the output of gcc -v
please?

[Bug libstdc++/80285] `std::make_shared` performs two separate allocations with `-fno-rtti`

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Fixed on trunk.

[Bug sanitizer/80386] UBSAN: false positive - constant folding and reassosiation before instrumentation

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Patch posted: .

[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old

[redi at gcc dot gnu.org]

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

--- Comment #23 from Jonathan Wakely  ---
No, because after discussion with the feature-test study group I don't want to
rely on GCC-specific magic. Instead I think it would be better for headers to
do:

#if __cplusplus >= 201402L
#define __cpp_lib_some_feature MM
...
#endif

That would mean including the header doesn't give an error, but you need to
test for both the header and a feature-test macro to know if the feature is
really available. i.e. existence of a header doesn't imply anything except that
the header can be included without error.

This needs a proposal to the study group and a change to SD-6 (currently
detection of many features only uses __has_include and there's no macro that
can be tested) and then changes to GCC to remove the #error directives (so we
allow inclusion, but define nothing when included with the wrong -std mode).

None of that has been decided on yet, so it's not possible to say if some
hypothetical idea would be backported to gcc-7-branch. There's nothing to
backport yet.

(N.B. C++14 added one new header, )

[Bug tree-optimization/80705] Incorrect code generated for profile counter updates due to SLP+LIM

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/80705] Incorrect code generated for profile counter updates due to SLP+LIM

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Thu May 11 14:08:07 2017
New Revision: 247906

URL: https://gcc.gnu.org/viewcvs?rev=247906=gcc=rev
Log:
2017-05-11  Richard Biener  

PR tree-optimization/80705
* tree-vect-data-refs.c (vect_analyze_data_refs): DECL_NONALIASED
bases are not vectorizable.

* gcc.dg/vect/bb-slp-pr80705.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-pr80705.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-data-refs.c

[Bug middle-end/71509] Bitfield causes load hit store with larger store than load

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Doing an 8 byte load of something that was stored as 4 byte immediately
before will cause flushes and stalls...  Yeah it could use a 4-byte load
here afaics.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[iains at gcc dot gnu.org]

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

--- Comment #25 from Iain Sandoe  ---
(In reply to Dominique d'Humieres from comment #24)
> > Le 11 mai 2017 à 09:06, gingold at adacore dot com 
> >  a écrit :


> 
> Note that
> 
> --with-stage1-ldflags=-static-libstdc++ 
> --with-boot-ldflags=-static-libstdc++
> 
> does not work if the install directory is empty:

That's actually a different problem, what you're seeing there is that
-static-libstdc++ is ignored on Darwin (dropped silently)...

... I.e.  -static-libstdc++ only works on Darwin with a patch which I got fed
up with pinging after 4 or so times.

NOTE: AFAIR clang doesn't support that option anyway, so it would not be
available at stage 1 where clang is the bootstrap compiler.

However, the existing compiler build process points explicitly to the
just-built libstdc++ convenience lib IIRC (the built tools are statically
linked with the lib). So that info ought to be available to the Ada build (I'm
pretty sure all the -B etc. is passed through).

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[dominiq at lps dot ens.fr]

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

--- Comment #24 from Dominique d'Humieres  ---
> Le 11 mai 2017 à 09:06, gingold at adacore dot com  
> a écrit :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
> 
> --- Comment #19 from Tristan Gingold  ---
> On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
> 
>> In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in
>> 
>> --- trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:44:28 
>> 247300
>> +++ trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:48:45 
>> 247301
>> @@ -99,6 +99,8 @@
>> ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN))
>> # Unresolved warnings in specific files.
>> ada/adaint.o-warn = -Wno-error
>> +# For unwind-pe.h
>> +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude
>> 
>> ada/%.o: ada/gcc-interface/%.c
>>$(COMPILE) $<
>> 
>> Isn't this wrong for darwin?
> 
> Why ?

I cannot distinguish -I (for include) and -l (for libs) on my browser, hence
the mistake.

Note that

--with-stage1-ldflags=-static-libstdc++ 
--with-boot-ldflags=-static-libstdc++

does not work if the install directory is empty:

dyld: Symbol not found: __ZdlPvm
  Referenced from: /opt/gcc/p_build/gcc/build/genmddeps (which was built for
Mac OS X 10.12)
  Expected in: /usr/lib/libstdc++.6.dylib
 in /opt/gcc/p_build/gcc/build/genmddeps

Dominique

> 
> The header unwind-pe.h is needed for the personality routine.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug libstdc++/79433] __has_include() is true but #include gives #error when -std=old

[marc.mutz at kdab dot com]

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

--- Comment #22 from Marc Mutz  ---
(In reply to Jonathan Wakely from comment #18)
> I've started a discussion about changing the SD-6 recommendations.
> 
> One idea that came out of the discussion so far would be to make a
> GCC-specific extension to __has_include. If the has-includes-expression
> finds a file then it could read the first line of the file to look for
> something like:
> 
> #pragma GCC has_include(constant-expression)
> 
> If found, the result of the has-include-expression would be 1 if the
> constant-expression is non-zero, and 0 otherwise.
> 
> Then we could decorate our C++17 headers with:
> 
> #pragma GCC has_include(__cplusplus > 201402L)
> 
> and __has_include would magically give the right answer.

Would that make its way into GCC 7, so we (Qt) could rely on it working at
least for the C++17 headers (C++14 didn't add many/any)?

[Bug libstdc++/80285] `std::make_shared` performs two separate allocations with `-fno-rtti`

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Thu May 11 13:21:07 2017
New Revision: 247905

URL: https://gcc.gnu.org/viewcvs?rev=247905=gcc=rev
Log:
PR libstdc++/80285 optimize std::make_shared for -fno-rtti

PR libstdc++/80285
* include/bits/shared_ptr_base.h (_Sp_make_shared_tag::_S_ti): Define
function to get unique fake std::type_info reference.
(_Sp_counted_ptr_inplace::_M_get_deleter) [!__cpp_rtti]: Compare to
_S_ti() fake reference.
(__shared_ptr(_Sp_make_shared_tag, const Alloc&, Args&&...)): Share
single implementation with or without RTTI enable.
[!__cpp_rtti]: Pass fake reference to _M_get_deleter.
* testsuite/20_util/shared_ptr/creation/alloc.cc: Change expected
allocation and deallocation counts.
* testsuite/20_util/shared_ptr/creation/single_allocation.cc: New.
* testsuite/20_util/shared_ptr/creation/single_allocation_no_rtti.cc:
New.

Added:
   
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/creation/single_allocation.cc
   
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/creation/single_allocation_no_rtti.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/shared_ptr_base.h
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/creation/alloc.cc

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
Yes, mt allocator has problems, that's why we stopped using it in 2005, but the
zerotier code isn't even using mt allocator. Their problem is probably
something different.

That's the problem with writing ghost stories instead of bug reports: ghosts
aren't real.

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|5.0 |unknown

--- Comment #15 from Jonathan Wakely  ---
(In reply to Bernd Paysan from comment #14)
> I therefore assigned that bug to libstdc++ version 5.0.

Um no, it was changed more than ten years ago.

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[bernd at net2o dot de]

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

Bernd Paysan  changed:

   What|Removed |Added

Version|unknown |5.0

--- Comment #14 from Bernd Paysan  ---
(In reply to Jonathan Wakely from comment #13)
> No libstdc++ bug here, nothing to see, move along.

Haha.

So I sum up: mt_allocator was made non-default after Version 5.x. Don't use
mt_allocator. We know it's not good enough, but won't fix it. Work on improving
glibc's malloc is on-going.

I therefore assigned that bug to libstdc++ version 5.0.

I'm sorry for the time wasted, but I think it is necessary to squish out that
sort of bug, whether real or ghost.  And the misleading documentation was also
fixed.

[Bug c/80710] New: Stack smashing detected in correct code depending on optimization flag

[dr.markus.hoffmann at gmx dot de]

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

Bug ID: 80710
   Summary: Stack smashing detected in correct code depending on
optimization flag
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dr.markus.hoffmann at gmx dot de
  Target Milestone: ---

Stack smashing detected if the code is compiled with -O1 or with
-fomit-frame-pointer. Everything fine, when compiled without optimization or
with -fno-omit-frame-pointer

Example code follows:
[code]

#include 
#include 
#include 
#include 
#include 

typedef struct {
  int a;
  int b;
  int c;
  int d;
} A;


A test2(int n) {
  A ret;
  printf("Hello n=%d\n",n);
  ret.a=1;
  ret.b=2;
  ret.c=3;
  return(ret);
}

#define GTT_SIZE 8

typedef struct  {long feld[GTT_SIZE];} GTT;
long (*adr)(GTT);


void dummy() {
  long ret;
  GTT gtt;
  A t;
  int i;

  printf("adr t: %p\n",);
  for(i=0;i>>The ERROR is triggered here !
}

int main() {
  printf("This is main.\n");
  dummy();
// <<< this will never be reached.
  printf("End of main.\n");
}

[/code]

Output: (normal case 
[code]
This is main.
adr t: 0xbfd76d7c
Hallo n=5
Function returned: 0xbfd76d7c
This is adress of t
Function ret: 1 2 3
original stack: 
0 : $bfd76d7c
1 : $5
2 : $2
3 : $3
4 : $4
5 : $5
6 : $6
7 : $7
End of main.

[/code]

Output if comiled with "gcc -fomit-frame-pointer a.c"
[code]
This is main.
adr t: 0xbfa1f30c
Hallo n=5
Function returned: 0xbfa1f30c
This is adress of t
Function ret: 2 3 0
original stack: 
0 : $5
1 : $2
2 : $3
3 : $4
4 : $5
5 : $6
6 : $7
7 : $9fc2c100
*** stack smashing detected ***: ./a.out terminated
Abort
[/code]

The latter should not happen and is considered as a bug in gcc.

[Bug target/80706] [7/8 Regression] peephole2 uses uninitialized stack variables on i686

[jakub at gcc dot gnu.org]

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

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

I came up with this (in addition to #c7).  This removes one of the two useless
stores in the original pr71245-1.c testcase and restores the above pr71245-1.c
modification to what it used to look before (well, even better, as it reserves
smaller stack).

[Bug testsuite/80580] GIMPLEFE ICE on invalid code (fuzz testing)

[miyuki at gcc dot gnu.org]

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

--- Comment #4 from Mikhail Maltsev  ---
Author: miyuki
Date: Thu May 11 12:27:37 2017
New Revision: 247903

URL: https://gcc.gnu.org/viewcvs?rev=247903=gcc=rev
Log:
GIMPLEFE: Handle invalid SSA names

gcc/testsuite/

PR testsuite/80580
* gcc.dg/gimplefe-error-6.c: New test.

gcc/c/

PR testsuite/80580
* gimple-parser.c (c_parser_parse_ssa_name): Validate SSA name base.

Added:
trunk/gcc/testsuite/gcc.dg/gimplefe-error-6.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/gimple-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/80708] [f08] ALLOCATE with MOLD error if source-expr is a derived type with null-init pointer component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-11
 CC||vehre at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed for 6.3.0, 7.1.0, and trunk (8.0). With 5.4.0 the error is

Error: Array specification required in ALLOCATE statement at (1)

The new error has been introduced at revision r234714.

[Bug target/80706] [7/8 Regression] peephole2 uses uninitialized stack variables on i686

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #12 from Uroš Bizjak  ---
Created attachment 41339
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41339=edit
Patch to prevent unwanted peephole2 matching

Instead of using generic SSE move patterns, attached patch implements and uses
loaddi_via_sse and storedi_via_sse specialized patterns.

This effectively prevents unwanted peephole2 matching.

[Bug middle-end/80707] [8 Regression] r247844 causes error: extra outgoing edge

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #1 from Peter Bergner  ---
Confirmed.  I'll have a look.

[Bug rtl-optimization/80709] New: ICE in setup_preferred_alternate_classes_for_new_pseudos, at ira.c:2772

[marxin at gcc dot gnu.org]

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

Bug ID: 80709
   Summary: ICE in
setup_preferred_alternate_classes_for_new_pseudos, at
ira.c:2772
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: arm-linux-gnueabihf

Using cross-compiler I see:

$ cat ~/Programming/testcases/arm.ii
typedef int a __attribute__ ((vector_size (16)));
constexpr a b[]{};
a c;
a d[]{};
void
abort ()
{
  int f = 0;
  for (;; ++f)
{
  a e = __builtin_shuffle (b[f], c, d[f]);
  if (__builtin_memcmp (, , sizeof (a)))
abort ();
}
}

$ ./xgcc -B. ~/Programming/testcases/arm.ii -O2
/home/marxin/Programming/testcases/arm.ii: In function ‘void abort()’:
/home/marxin/Programming/testcases/arm.ii:12:28: warning: ‘int
__builtin_memcmp_eq(const void*, const void*, unsigned int)’ reading 16 bytes
from a region of size 4 [-Wstringop-overflow=]
   if (__builtin_memcmp (, , sizeof (a)))
   ~^~~~
/home/marxin/Programming/testcases/arm.ii:15:1: internal compiler error: in
setup_preferred_alternate_classes_for_new_pseudos, at ira.c:2772
 }
 ^
0xee88e1 setup_preferred_alternate_classes_for_new_pseudos
../../gcc/ira.c:2772
0xee89d8 expand_reg_info
../../gcc/ira.c:2799
0xeef7a1 ira
../../gcc/ira.c:5333
0xeefed6 execute
../../gcc/ira.c:5613

[Bug go/64238] ICE in get_partitioning_class, at symtab.c:1775

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
There's link to docker image that illustrates that for 7.1:
https://hub.docker.com/r/marxin/docker-gcc-pr64238/builds/buqt3slnzjlvm858fg6j78t/

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

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #14)
> C++ FE's constexpr.c has bool lval argument to many recursive functions, so
> it can differentiate between cases where you don't want to fold "str"[0] to
> 's' and cases where you can do that.  It is among other cases set when
> processing ADDR_EXPR's operand.  But c_fully_fold_internal doesn't have
> anything like that, so that would need to be introduced there.

>From the related PR66618, it seems that if we had such an argument properly
propagated, we could as well use decl_constant_value_for_optimization during
c_fully_fold_internal (if not pedantic?) centrally for VAR_DECLs, rather then
just using it on selected operands where we basically know for sure we don't
need an lvalue.

Without such changes, a hack could be to add the ARRAY_REF of STRING_CST with
constant index folding into decl_constant_value_for_optimization.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
C++ FE's constexpr.c has bool lval argument to many recursive functions, so it
can differentiate between cases where you don't want to fold "str"[0] to 's'
and cases where you can do that.  It is among other cases set when processing
ADDR_EXPR's operand.  But c_fully_fold_internal doesn't have anything like
that, so that would need to be introduced there.

[Bug testsuite/80580] GIMPLEFE ICE on invalid code (fuzz testing)

[miyuki at gcc dot gnu.org]

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

--- Comment #3 from Mikhail Maltsev  ---
Author: miyuki
Date: Thu May 11 10:55:52 2017
New Revision: 247900

URL: https://gcc.gnu.org/viewcvs?rev=247900=gcc=rev
Log:
GIMPLEFE: handle invalid __MEM

gcc/c/

PR testsuite/80580
* gimple-parser.c (c_parser_gimple_postfix_expression): Handle
incorrect __MEM syntax.

gcc/testsuite/

PR testsuite/80580
* gcc.dg/gimplefe-error-5.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/gimplefe-error-5.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/gimple-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug go/64238] ICE in get_partitioning_class, at symtab.c:1775

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Ian Lance Taylor from comment #6)
> I'm sorry, I still can't recreate it.  I'm now at SVN revision 247848.
> 
> Note that I just committed a number of changes to the Go frontend, and I was
> using those changes when I tested before.  I don't see why they would affect
> this, but perhaps they do.  If that is the case, then you will no longer see
> a problem either.
> 
> I edited the gcc_checking_assert at symtab.c:1865 to be a plain gcc_assert,
> though I think that shouldn't matter.
> 
> This is what I see:
> 
> > gccgo -flto pr64238/bytes_decl.go pr64238/bytes.go
> /tmp/ccerLD54.ltrans0.ltrans.o::function go.bytes.Count: error:
> undefined reference to 'go.bytes.IndexByte'
> /tmp/ccerLD54.ltrans0.ltrans.o::function go.bytes.Count: error:
> undefined reference to 'go.bytes.Equal'
> /tmp/ccerLD54.ltrans0.ltrans.o::function go.bytes.Index: error:
> undefined reference to 'go.bytes.IndexByte'
> /tmp/ccerLD54.ltrans0.ltrans.o::function go.bytes.Index: error:
> undefined reference to 'go.bytes.IndexByte'
> /tmp/ccerLD54.ltrans0.ltrans.o::function go.bytes.Index: error:
> undefined reference to 'go.bytes.Equal'
> /tmp/ccerLD54.ltrans0.ltrans.o::function go.bytes.LastIndex:
> error: undefined reference to 'go.bytes.Equal'
> /tmp/ccerLD54.ltrans0.ltrans.o::function bytes.genSplit: error:
> undefined reference to 'go.bytes.Equal'
> collect2: error: ld returned 1 exit status
> 
> > gccgo -flto pr64238/bytes_decl.go pr64238/bytes.go -fgo-pkgpath=bytes
> > echo $?
> 0

I can confirm that current trunk works fine. However GCC 7.1 is affected.
Can you reproduce it for 7.1? Are you planning to backport some patches in
order to fix the release?

[Bug ipa/79787] ICE in remove_unreachable_nodes, at ipa.c:469

[aivchenk at gmail dot com]

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

Alexander Ivchenko  changed:

   What|Removed |Added

 CC||aivchenk at gmail dot com

--- Comment #2 from Alexander Ivchenko  ---
Reduced testcase:
inline __attribute__((__always_inline__)) __attribute__ ((target("bmi"))) int
fn1() {}

__attribute__((__always_inline__)) __attribute__ ((target("bmi"))) int fn2() {
fn1(); }

int fn3() { return fn1(); }


Initial call graph:
fn3 -(not inlinable because of attribute mismatch)-> fn1
fn2 -> fn1

Call graph before chkp_ecleanup
fn3 -> fn3.chkp -(not inlinable because of attribute mismatch)-> fn1.chkp 
fn2.chkp  -> fn1.chkp 
fn2 (fn1 is inlined here)


When compiler inlines fn1 to fn2 in expand_call_inline, it removes fn1 cnode,
as it is no longer needed.
There it execute this code (in cgraph_node::remove):

if (instrumented_version)
  {  
instrumented_version->instrumented_version = NULL;   
instrumented_version = NULL; 
  }
Hence, now fn1.chkp.instrumened_version==NULL and fn1 is removed.

And later on in chkp_cleanup in reachability analysis in
symbol_table::remove_unreachable_nodes 
we fail on this assert, where cnode==fn1.chkp


  /* For instrumentation clones we always need original 
 function node for proper LTO privatization.  */
  if (cnode->instrumentation_clone  
  && cnode->definition) 
{   
=>gcc_assert (cnode->instrumented_version || in_lto_p);

(since fn1 is removed, we don't consider it in chkp_produce_thunks
(early=false))

[Bug testsuite/80580] GIMPLEFE ICE on invalid code (fuzz testing)

[miyuki at gcc dot gnu.org]

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

--- Comment #2 from Mikhail Maltsev  ---
Author: miyuki
Date: Thu May 11 10:48:54 2017
New Revision: 247899

URL: https://gcc.gnu.org/viewcvs?rev=247899=gcc=rev
Log:
GIMPLEFE: Handle invalid unary "*" operand type

gcc/c/

PR testsuite/80580
* gimple-parser.c (c_parser_gimple_unary_expression): Check argument
type of unary '*'.

gcc/testsuite/

PR testsuite/80580
* gcc.dg/gimplefe-error-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/gimplefe-error-4.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/gimple-parser.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/80536] [6/7/8 Regression] UBSAN: compile time segfault

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
(In reply to Marek Polacek from comment #17)
> (In reply to Jakub Jelinek from comment #16)
> > (In reply to Marek Polacek from comment #15)
> > > In C I don't think so, because we mostly call c_save_expr and c_fully_fold
> > > therein would fold that expression to 0.  And when we call save_expr, it's
> > 
> > Yeah, I know that, and I think it is a serious bug.  With the c_fully_fold
> > in c_save_expr the C FE is not doing anything close to delayed folding, it
> > folds immediately whenever we might need a save_expr, the old trees gone.
> > So I think it would be nice to kill c_save_expr, just use save_expr, and let
> > c_fully_fold fold SAVE_EXPR operand (just once, not many times).
> 
> I agree.  I'll try (guess we'll need the fold cache).  That can be a
> separate project, though.

See above, if it is just about SAVE_EXPR, the C FE could just grab one of the
many spare bits on SAVE_EXPR for a flag whether the operand has been
c_fully_folded already.

[Bug sanitizer/80536] [6/7/8 Regression] UBSAN: compile time segfault

[mpolacek at gcc dot gnu.org]

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

--- Comment #17 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Marek Polacek from comment #15)
> > In C I don't think so, because we mostly call c_save_expr and c_fully_fold
> > therein would fold that expression to 0.  And when we call save_expr, it's
> 
> Yeah, I know that, and I think it is a serious bug.  With the c_fully_fold
> in c_save_expr the C FE is not doing anything close to delayed folding, it
> folds immediately whenever we might need a save_expr, the old trees gone.
> So I think it would be nice to kill c_save_expr, just use save_expr, and let
> c_fully_fold fold SAVE_EXPR operand (just once, not many times).

I agree.  I'll try (guess we'll need the fold cache).  That can be a separate
project, though.

[Bug sanitizer/80536] [6/7/8 Regression] UBSAN: compile time segfault

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
(In reply to Marek Polacek from comment #15)
> In C I don't think so, because we mostly call c_save_expr and c_fully_fold
> therein would fold that expression to 0.  And when we call save_expr, it's

Yeah, I know that, and I think it is a serious bug.  With the c_fully_fold in
c_save_expr the C FE is not doing anything close to delayed folding, it folds
immediately whenever we might need a save_expr, the old trees gone.
So I think it would be nice to kill c_save_expr, just use save_expr, and let
c_fully_fold fold SAVE_EXPR operand (just once, not many times).

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-05-11
 CC||aoliva at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r226901.

[Bug libstdc++/80658] Memory leak reported in libstdc++ (zerotier)

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
Like most ghost stories, this one is based on superstition and fantasy, not
facts or science:

https://www.reddit.com/r/programming/comments/69g8il/the_horror_in_the_standard_library/dhb2las/

No libstdc++ bug here, nothing to see, move along.

[Bug sanitizer/80536] [6/7/8 Regression] UBSAN: compile time segfault

[mpolacek at gcc dot gnu.org]

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

--- Comment #15 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Marek Polacek from comment #13)
> > This is true, but it happens very rarely.  It can happen e.g. when the
> > fold() call in save_expr() folds away the first operand of a COMPOUND_EXPR,
> > and the second operand is e.g.
> 
> Can't it happen say if you have save_expr called with (0 * i) + (0 * j) + (0
> * k) or whatever similar initially complex, but after folding very simple
> and obviously invariant?

In C I don't think so, because we mostly call c_save_expr and c_fully_fold
therein would fold that expression to 0.  And when we call save_expr, it's when
in_late_binary_op so the operands have already been folded.  There's one case,
though, where we call save_expr without previous folding, and that's when
constructing a VLA whose size is a sizeof of another VLA in grokdeclarator:

 6097 /* Arrange for the SAVE_EXPR on the inside of the
 6098MINUS_EXPR, which allows the -1 to get folded
 6099with the +1 that happens when building TYPE_SIZE. 
*/
 6100 if (size_varies)
 6101   size = save_expr (size);

void
f (int i)
{
  int (*a)[i];
  int x[sizeof (*a)];
}

I wouldn't worry much about that.

> > But even if I add this to fold or c_fully_fold, we don't have any guarantees
> > that any of these will be called before gimplification, right?  So most
> > likely we'd end up with the new SAVE_EXPR in the gimplifier, which, as you
> > point out, is not that bad.
> 
> I think cp_fold should handle SAVE_EXPR (by cp_folding the operand, and if
> it is invariant or invariant after skipping simple arith, returning that
> folded operand, otherwise making sure to add the SAVE_EXPR into the
> fold_cache giving 
> the SAVE_EXPR itself.  Right now cp_fold ignores SAVE_EXPR, but cp_fold_r
> handles it, but that one doesn't do much good, because it cp_folds the
> operands only after folding the containing trees.

I'm testing this.  Judging by running the C++ testsuite, it basically never
happens that we're able to cp_fold the content of a SAVE_EXPR to an invariant,
although it happens e.g. with this test:

int
foo (int i)
{
  return ((0 * i * (unsigned long long) (-0 + 1UL)) * 2) % 1;
}

so it probably makes sense to add the cp_fold bits.

Thanks.

[Bug target/80706] [7/8 Regression] peephole2 uses uninitialized stack variables on i686

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Jakub Jelinek from comment #10)
> Perhaps if we had such a pattern that we'd split into a normal DFmode load
> (perhaps with unspec before reload to guarantee it is atomic load), we
> wouldn't need the temporary at all?

--- gcc/config/i386/predicates.md.jj2017-01-01 12:45:42.0 +0100
+++ gcc/config/i386/predicates.md   2017-05-11 11:42:17.649136648 +0200
@@ -1657,3 +1657,14 @@ (define_predicate "register_or_constm1_o
   (ior (match_operand 0 "register_operand")
(and (match_code "const_int")
(match_test "op == constm1_rtx"
+
+;; Return true if OP is a memory_operand, including volatile MEM.
+(define_predicate "volatile_memory_operand"
+  (match_code "mem,subreg")
+{
+  int save_volatile_ok = volatile_ok;
+  volatile_ok = 1;
+  bool ret = memory_operand (op, mode);
+  volatile_ok = save_volatile_ok;
+  return ret;
+})
--- gcc/config/i386/sync.md.jj  2017-05-11 10:16:03.0 +0200
+++ gcc/config/i386/sync.md 2017-05-11 11:42:45.67179 +0200
@@ -210,6 +210,17 @@ (define_insn_and_split "atomic_loaddi_fp
   DONE;
 })

+(define_insn_and_split "*atomic_loaddf_fpu"
+  [(set (match_operand:DF 0 "nonimmediate_operand" "=x,f")
+   (subreg:DF (unspec:DI [(match_operand:DI 1 "volatile_memory_operand"
+  "m,m")]
+ UNSPEC_LDA) 0))]
+  "!TARGET_64BIT && (TARGET_80387 || TARGET_SSE)"
+  "#"
+  "&& 1"
+  [(set (match_dup 0) (match_dup 1))]
+  "operands[1] = gen_lowpart (DFmode, operands[1]);")
+
 (define_peephole2
   [(set (match_operand:DF 0 "fp_register_operand")
(unspec:DF [(match_operand:DI 1 "memory_operand")]

does that, unfortunately combine still fails, because the insn it wants to
match afterwards is:
(set (reg:DF 91)
(plus:DF (reg:DF 92)
(const_double:DF 1.0e+0 [0x0.8p+1])))
But the above patch at least helps a little bit on following testcase:
typedef union
{
  unsigned long long ll;
  double d;
} u_t;

u_t d = { .d = 5.0 };

void foo_d (double x)
{
  u_t tmp;

  tmp.ll = __atomic_load_n (, __ATOMIC_SEQ_CST);
  tmp.d += x;
  __atomic_store_n (, tmp.ll, __ATOMIC_SEQ_CST);
}
Before the #c7 patch, we get:
fldld
faddl   24(%esp)
fstpl   d
lock; orl   $0, (%esp)
with just the #c7 patch we get:
fldld
fstl(%esp)
faddl   24(%esp)
fstld
fstpl   (%esp)
lock; orl   $0, (%esp)
so 2 useless stores.  With #c7 and this patch we get:
fldld
faddl   24(%esp)
fstld
fstpl   (%esp)
lock; orl   $0, (%esp)
i.e. one useless store.  So, either we need combine or some other pre-reload
pass to figure out we have all uses of the atomic_loaddi_fpu pattern as
(subreg:DF (reg:DI ...)) and optimize that into the atomic_loaddf_fpu pattern
with uses changed into just the DFmode pseudo.  Allowing =f in
atomic_loaddi_fpu won't work, as DImode is not VALID_FP_MODE_P.

[Bug tree-optimization/53090] suboptimal ivopt

[amker at gcc dot gnu.org]

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

--- Comment #9 from amker at gcc dot gnu.org ---
Author: amker
Date: Thu May 11 09:50:15 2017
New Revision: 247893

URL: https://gcc.gnu.org/viewcvs?rev=247893=gcc=rev
Log:
PR tree-optimization/53090
* tree-ssa-loop-ivopts.c (enum comp_iv_rewrite): New enum value
COMP_IV_EXPR_2.
(extract_cond_operands): Detect condition with IV on both sides
and return COMP_IV_EXPR_2.
(find_interesting_uses_cond): Add iv_use for both IVs in condition.
(rewrite_use_compare): Simplify by removing call to function
extract_cond_operands.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug fortran/80708] New: [f08] ALLOCATE with MOLD error if source-expr is a derived type with null-init pointer component

[tamas.bela.feher at ipp dot mpg.de]

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

Bug ID: 80708
   Summary: [f08] ALLOCATE with MOLD error if source-expr is a
derived type with null-init pointer component
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tamas.bela.feher at ipp dot mpg.de
  Target Milestone: ---

Dear GFortran Team,

For the following program:

program mold_dtype_with_pointer_component
  implicit none
  type t
real, dimension(:), pointer :: p => null()
  end type
  type(t), dimension(3:4) :: array
  type(t), allocatable, dimension(:) :: h
  allocate(H, mold=array)
end program

GFortran (versions 6.3.0 and 8.0.0 20170427) gives the following error message:

gfortran mold_dtype_pointer.f90
mold_dtype_pointer.f90:8:11:

   allocate(H, mold=array)
   1
Error: Array specification or array-valued SOURCE= expression required in
ALLOCATE statement at (1)

The error disappears if the null-init for pointer p is removed, or if MOLD is
replaced with SOURCE. I would expect that the program compiles even in its
original form.

Best regards,
Tamas

[Bug tree-optimization/80705] Incorrect code generated for profile counter updates due to SLP+LIM

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Ok, SLP seems fine here, on x86_64 needs -fno-vect-cost-model to vectorize it. 
LIM also looks fine on x86 (does nothing) so it must be IVOPTs messing up the
refs on ppc64le.  Ah, on ppc64le:

  vect_cst__43 = {__gcov0.foo_I_lsm.13_187, __gcov0.foo_I_lsm.10_168};
  vect_cst__152 = {__gcov0.foo_I_lsm.11_105, __gcov0.foo_I_lsm.12_164};
  vect_cst__178 = {__gcov0.foo_I_lsm.14_204, PROF_edge_counter_193};
  MEM[(long int *)&__gcov0.foo + 32B] = vect_cst__178;
  _198 = &__gcov0.foo[4] + 16;
  MEM[(long int *)_198] = vect_cst__152;
  _39 = _198 + 16;
  MEM[(long int *)_39] = vect_cst__43;

actually similar on x86_64 without AVX:

  vect_cst__174 = {__gcov0.foo_I_lsm.10_109, __gcov0.foo_I_lsm.11_164};
  vect_cst__36 = {__gcov0.foo_I_lsm.12_147, PROF_edge_counter_167};
  MEM[(long int *)&__gcov0.foo + 24B] = vect_cst__36;
  _181 = &__gcov0.foo[3] + 16;
  MEM[(long int *)_181] = vect_cst__174;

the last ref is problematic as it aliases __gcov0.foo and that is not allowed.

I presume that vectorizing the counter update stores isn't really useful
anyway,
so the easiest thing may be to simply not allow vectorizing DECL_NONALIASED
refs.

Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c   (revision 247879)
+++ gcc/tree-vect-data-refs.c   (working copy)
@@ -3957,6 +4023,27 @@ again:
  datarefs[i] = dr;
}

+  if (TREE_CODE (DR_BASE_ADDRESS (dr)) == ADDR_EXPR
+ && DECL_P (TREE_OPERAND (DR_BASE_ADDRESS (dr), 0))
+ && DECL_NONALIASED (TREE_OPERAND (DR_BASE_ADDRESS (dr), 0)))
+   {
+  if (dump_enabled_p ())
+{
+  dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+   "not vectorized: base object not addressable "
+  "for stmt: ");
+  dump_gimple_stmt (MSG_MISSED_OPTIMIZATION, TDF_SLIM, stmt, 0);
+}
+  if (is_a  (vinfo))
+   {
+ /* In BB vectorization the ref can still participate
+in dependence analysis, we just can't vectorize it.  */
+ STMT_VINFO_VECTORIZABLE (stmt_info) = false;
+ continue;
+   }
+ return false;
+   }
+
   /* Set vectype for STMT.  */
   scalar_type = TREE_TYPE (DR_REF (dr));
   STMT_VINFO_VECTYPE (stmt_info)

[Bug target/80706] [7/8 Regression] peephole2 uses uninitialized stack variables on i686

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > The #c5 patch obviously doesn't help here, because the testcase triggers the
> > last of these 4 peephole2s.  But #c7 works.
> 
> Thanks! It looks like we'll have to live with extra stores then...

Can't we improve it in the combiner?
For PR71245 testcase obviously, we have:
(insn 5 2 6 2 (parallel [
(set (reg:DI 89 [ _4 ])
(unspec:DI [
(mem/v:DI (symbol_ref:SI ("d") [flags 0x2]  ) [-1  S8 A64])
] UNSPEC_LDA))
(clobber (mem/c:DI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0  S8 A64]))
(clobber (scratch:DF))
]) "/usr/include/c++/6.3.1/atomic":235 4970 {atomic_loaddi_fpu}
 (nil))
...
(insn 8 7 9 2 (set (reg:DF 91)
(plus:DF (subreg:DF (reg:DI 89 [ _4 ]) 0)
(reg:DF 92))) "pr71245.C":5 805 {*fop_df_comm}
 (expr_list:REG_DEAD (reg:DF 92)
(expr_list:REG_DEAD (reg:DI 89 [ _4 ])
(nil
and apparently the combiner attempts to match:
(set (reg:DF 92)
(subreg:DF (unspec:DI [
(mem/v:DI (symbol_ref:SI ("d") [flags 0x2]  ) [-1  S8 A64])
] UNSPEC_LDA) 0))
Perhaps if we had such a pattern that we'd split into a normal DFmode load
(perhaps with unspec before reload to guarantee it is atomic load), we wouldn't
need the temporary at all?

[Bug c++/46476] Missing Warning about unreachable code after return

[jg at jguk dot org]

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

--- Comment #11 from Jon Grant  ---
Perhaps some new static analysis tools could be added to GCC. I'd be happy to
contribute to costs.

[Bug target/80706] [7/8 Regression] peephole2 uses uninitialized stack variables on i686

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #8)
> The #c5 patch obviously doesn't help here, because the testcase triggers the
> last of these 4 peephole2s.  But #c7 works.

Thanks! It looks like we'll have to live with extra stores then...

[Bug c++/80683] Exceptions don't propagate through default member initializer

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #5 from Xi Ruoyao  ---
The issue is in cp/method.c:

  /* If that user-written default constructor would satisfy the
 requirements of a constexpr constructor (7.1.5), the
 implicitly-defined default constructor is constexpr.

 The implicitly-defined copy/move assignment operator is constexpr if
  - X is a literal type, and
  - the assignment operator selected to copy/move each direct base class
subobject is a constexpr function, and
  - for each non-static data member of X that is of class type (or array
thereof), the assignment operator selected to copy/move that
member is a constexpr function.  */
  if (constexpr_p)
*constexpr_p = ctor_p || (assign_p && cxx_dialect >= cxx14);

But if we have default member initializers, the implicitly-defined default
constructor can not be constexpr.  We have to check it.

[Bug tree-optimization/80705] Incorrect code generated for profile counter updates due to SLP+LIM

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Aww.  Probably fallout of the DECL_NONALIASED "hack".  We likely have to
restrict vectorizing / IVOPTing those.

Basically we want to be able to apply store motion to counter updates which
means we have to be able to disambiguate counter loads/stores against other
memory accesses.

I'll see what exactly happens here (just guessing above).

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

[gingold at adacore dot com]

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

--- Comment #23 from Tristan Gingold  ---
On 11/05/2017 10:11, iains at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
>
> --- Comment #22 from Iain Sandoe  ---
> (In reply to Tristan Gingold from comment #21)
>> On 11/05/2017 09:44, iains at gcc dot gnu.org wrote:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
>>>
>>> --- Comment #20 from Iain Sandoe  ---
>>> (In reply to Tristan Gingold from comment #19)
 On 10/05/2017 18:04, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

> In the commit r247301 I see in gcc/ada/gcc-interface/Make-lang.in
>
> --- trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:44:28 
> 247300
> +++ trunk/gcc/ada/gcc-interface/Make-lang.in2017/04/27 09:48:45 
> 247301
> @@ -99,6 +99,8 @@
>  ada-warn = $(ADA_CFLAGS) $(filter-out -pedantic, $(STRICT_WARN))
>  # Unresolved warnings in specific files.
>  ada/adaint.o-warn = -Wno-error
> +# For unwind-pe.h
> +CFLAGS-ada/raise-gcc.o += -I$(srcdir)/../libgcc -Iinclude
>
>  ada/%.o: ada/gcc-interface/%.c
> $(COMPILE) $<
>
> Isn't this wrong for darwin?

 Why ?

 The header unwind-pe.h is needed for the personality routine.
>>>
>>> What we need to do is to remove the (use of) libgcc_s and not use libgcc_eh
>>> (static-libgcc) for Darwin > 10, since the unwinder is now in
>>> usr/lib/system/libunwind.dylib.
>>>
>>> Needs two chunks (1) move the content for TLS emulation somewhere else, 
>>> since
>>> that's a reason to need libgcc_s (2) adjust the use of libgcc for Darwin > 
>>> 10
>>> to not include libgcc_eh for -static-libgcc.  I have some patches for gcc-5 
>>> and
>>> 6 that do this, will forward-port them.
>>
>> Great!
>
> .. but might not be 'this week' ;-)
>
>
>>> I'm a little surprised that we need explicit -static-libstdc++ for gnat, the
>>> rest of the compiler already handles this?
>>
>> We just need to remove -static-libgcc but keep -static-libstdc++
>
> OK. So looking at the breaking rev. (and to check I've understood correctly) -
> the change switches gnat from using setjmp/longjmp to using DWARF unwinding
> (and thus exposes the incompatibility)?

Yes.

> In the short-term, what ought to work is to ensure that -lSystem appears 
> before
> any -lgcc on the link line (so that the correct unwinder is used), and to
> remove -static-libgcc.

Might work too.

> TBH static-libgcc should actually work unless gnat is now pulling in any other
> system libraries which cause two unwinders to be present - I guess it might 
> be?

No, I think static-libgcc cannot work because it is not able to get the 
address of the unwind tables (on recent Darwin versions).

> (probably, as an aside, we ought to look at putting libstdc++ on top of
> libc++abi instead of libsupc++ - but that's on the TODO, no patches yet).

Hum, yes.