[Bug lto/85405] [6/7 Regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1581

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||8.0.1
  Known to fail|8.0.1   |

--- Comment #3 from Martin Liška  ---
Fixed on trunk.

[Bug ipa/85329] [8 Regression] ICE in add_to_same_comdat_group, at symtab.c:460

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Fixed on trunk.

[Bug lto/85405] [6/7 Regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1581

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue Apr 17 05:41:40 2018
New Revision: 259429

URL: https://gcc.gnu.org/viewcvs?rev=259429=gcc=rev
Log:
Support bitfields in Wodr machinery (PR lto/85405).

2018-04-17  Jan Hubicka  

PR lto/85405
* ipa-devirt.c (odr_types_equivalent_p): Handle bit fields.
2018-04-17  Martin Liska  

PR lto/85405
* g++.dg/lto/pr85405_0.C: New test.
* g++.dg/lto/pr85405_1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/lto/pr85405_0.C
trunk/gcc/testsuite/g++.dg/lto/pr85405_1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-devirt.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/85329] [8 Regression] ICE in add_to_same_comdat_group, at symtab.c:460

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Tue Apr 17 05:40:39 2018
New Revision: 259428

URL: https://gcc.gnu.org/viewcvs?rev=259428=gcc=rev
Log:
Make redirection only for target_clones: V3 (PR ipa/85329).

2018-04-17  Martin Liska  

PR ipa/85329
* multiple_target.c (create_dispatcher_calls): Set apostrophes
for target_clone error message.  Make default implementation
clone to be a local declaration.
(separate_attrs): Add new argument and check for an empty
string.
(expand_target_clones): Handle it.
(ipa_target_clone): Make redirection just for target_clones
functions.
2018-04-17  Martin Liska  

PR ipa/85329
* g++.dg/ext/pr85329-2.C: New test.
* g++.dg/ext/pr85329.C: New test.
* gcc.target/i386/mvc12.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/pr85329-2.C
trunk/gcc/testsuite/g++.dg/ext/pr85329.C
trunk/gcc/testsuite/gcc.target/i386/mvc12.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/multiple_target.c
trunk/gcc/testsuite/ChangeLog

[Bug c/85427] New: internal compiler error: in constant_lower_bound, at poly-int.h:1527

[shlei930 at gmail dot com]

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

Bug ID: 85427
   Summary: internal compiler error: in constant_lower_bound, at
poly-int.h:1527
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shlei930 at gmail dot com
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/suhua/compilers/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 8.0.1 20180416 (experimental) [trunk revision 259396] (GCC)

$ gcc-trunk abc.c
during RTL pass: expand
abc.c: In function ‘fn1’:
abc.c:3:13: internal compiler error: in constant_lower_bound, at
poly-int.h:1527
 int fn1() { fn1(a, b, c, d, e, f, g, h, i, j, k); }
 ^~~~
0x5ff4f0 long constant_lower_bound<1u, long>(poly_int_pod<1u, long> const&)
../../gcc/gcc/poly-int.h:1527
0x5ff4f0 expand_call(tree_node*, rtx_def*, int)
../../gcc/gcc/calls.c:3763
0x9b26ab expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:11007
0x8ad45e expand_expr
../../gcc/gcc/expr.h:280
0x8ad45e expand_call_stmt
../../gcc/gcc/cfgexpand.c:2690
0x8ad45e expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3624
0x8ad45e expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3790
0x8ae4df expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5819
0x8b30b7 execute
../../gcc/gcc/cfgexpand.c:6425
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ cat abc.c
typedef struct { char type[90]; } t;
t a, b, c, d, e, f, g, h, i, j, k;
int fn1() { fn1(a, b, c, d, e, f, g, h, i, j, k); }

[Bug bootstrap/85413] "./configure --with-build-config=bootstrap-lto " != "BOOT_CFLAGS +=-flto "

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
The difference between -flto and -flto=jobserver is minor (just speed of
linking).  I don't think this minor difference would cause the need to update
the documentation.

[Bug bootstrap/84856] Bootstrap failure on riscv: comparison of integer expressions of different signedness

[npickito at gmail dot com]

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

--- Comment #9 from Kito Cheng  ---
Hi Jim:

Yeah, you are right, so I guess just some missing in back-end now, thanks your
quick response :)

[Bug rtl-optimization/84842] [7/8 Regression] ICE in verify_target_availability, at sel-sched.c:1569

[asolokha at gmx dot com]

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

--- Comment #10 from Arseny Solokha  ---
Created attachment 43955
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43955=edit
gcc/auto-host.h

[Bug rtl-optimization/85426] New: ICE in patch_jump_insn, at cfgrtl.c:1271

[asolokha at gmx dot com]

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

Bug ID: 85426
   Summary: ICE in patch_jump_insn, at cfgrtl.c:1271
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*, powerpcspe-*-linux-gnu*

gcc-8.0.0-alpha20180415 snapshot (r259389) ICEs when compiling the following
snippet w/ -mcpu=8548 -O1 (-O2, -O3, -Ofast) -fmodulo-sched
-fprefetch-loop-arrays -freorder-blocks-and-partition
-ftree-parallelize-loops=2 -fno-ivopts:

long long unsigned int
c8 (int *zf, int v2)
{
  int ns;
  long long unsigned int sv = 0;

  for (ns = 0; ns < v2; ++ns)
sv += zf[ns] / ns;

  return sv;
}

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180415 -mcpu=8548 -O1
-fmodulo-sched -fprefetch-loop-arrays -freorder-blocks-and-partition
-ftree-parallelize-loops=2 -fno-ivopts -c t3kxgcui.c
during RTL pass: sms
t3kxgcui.c: In function 'c8._loopfn.0':
t3kxgcui.c:7:3: internal compiler error: in patch_jump_insn, at cfgrtl.c:1271
   for (ns = 0; ns < v2; ++ns)
   ^
0x74d7a2 patch_jump_insn
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/cfgrtl.c:1271
0x74dd52 redirect_branch_edge
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/cfgrtl.c:1297
0x74e02a cfg_layout_redirect_edge_and_branch
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/cfgrtl.c:4437
0x74e1d7 cfg_layout_redirect_edge_and_branch_force
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/cfgrtl.c:4451
0x7319f8 redirect_edge_and_branch_force(edge_def*, basic_block_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/cfghooks.c:486
0x7327ed make_forwarder_block(basic_block_def*, bool (*)(edge_def*), void
(*)(basic_block_def*))
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/cfghooks.c:893
0x73bbff merge_latch_edges
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/cfgloop.c:780
0x73bbff disambiguate_multiple_latches
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/cfgloop.c:831
0x73bbff disambiguate_loops_with_multiple_latches()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/cfgloop.c:844
0xa73474 apply_loop_flags
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/loop-init.c:54
0xa74105 loop_optimizer_init(unsigned int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/loop-init.c:123
0x14c78d5 sms_schedule
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/modulo-sched.c:1354
0x14ca3a2 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/modulo-sched.c:3345

[Bug c++/80290] [6/7/8 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |ASSIGNED

--- Comment #20 from Alexandre Oliva  ---
Patch posted
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00709.html

[Bug c++/85039] [6/7 Regression] internal compiler error: in nested_anon_class_index, at cp/mangle.c:1626

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|aoliva at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
Summary|[6/7/8 Regression] internal |[6/7 Regression] internal
   |compiler error: in  |compiler error: in
   |nested_anon_class_index, at |nested_anon_class_index, at
   |cp/mangle.c:1626|cp/mangle.c:1626

--- Comment #6 from Alexandre Oliva  ---
Fixed for 8

[Bug target/85400] R_SPARC_TLS_*: invalid relocations generated for optimized builds on sparc

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

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

[Bug target/85400] R_SPARC_TLS_*: invalid relocations generated for optimized builds on sparc

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Eric Botcazou  ---
Thanks, I can reproduce now, including with the GNU assembler.

[Bug ipa/85421] [8 regression] internal compiler error: in ipa_propagate_frequency, at ipa-profile.c:405

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||marxin at gcc dot gnu.org
  Component|c++ |ipa
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #3 from Martin Jambor  ---
Mine.  Fixed by the following:

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index b2627ffd05f..4e0e20af409 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -3863,6 +3863,7 @@ create_specialized_node (struct cgraph_node *node,
   new_node = node->create_virtual_clone (callers, replace_trees,
 args_to_skip, "constprop");

+  bool have_self_recursive_calls = !self_recursive_calls.is_empty ();
   for (unsigned j = 0; j < self_recursive_calls.length (); j++)
 {
   cgraph_edge *cs = next_edge_clone[self_recursive_calls[j]->uid];
@@ -3870,6 +3871,8 @@ create_specialized_node (struct cgraph_node *node,
   gcc_assert (cs->caller == new_node);
   cs->redirect_callee_duplicating_thunks (new_node);
 }
+  if (have_self_recursive_calls)
+new_node->expand_all_artificial_thunks ();

   ipa_set_node_agg_value_chain (new_node, aggvals);
   for (av = aggvals; av; av = av->next)

[Bug c++/85039] [6/7/8 Regression] internal compiler error: in nested_anon_class_index, at cp/mangle.c:1626

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  ---
Author: aoliva
Date: Mon Apr 16 21:35:34 2018
New Revision: 259423

URL: https://gcc.gnu.org/viewcvs?rev=259423=gcc=rev
Log:
[PR c++/85039] no type definitions in builtin offsetof

Types defined within a __builtin_offsetof argument don't always get
properly recorded as members of their context types, so if they're
anonymous, we may fail to assign them an anon type index for mangling
and ICE.

We shouldn't allow types to be introduced in __builtin_offsetof, I
think, and Jason says the std committee agrees, so I've arranged for
us to reject them.

Even then, we still parse the definitions and attempt to assign
mangled names to its member functions, so the ICE remains.  Since
we've already reported an error, we might as well complete the name
assignment with an arbitrary index, thus avoiding the ICE.

We used to have a test that expected to be able to define types in
__builtin_offsetof; this patch removes that specific test.


for  gcc/cp/ChangeLog

PR c++/85039
* parser.c (cp_parser_builtin_offset): Reject type definitions.
* mangle.c (nested_anon_class_index): Avoid crash returning -1
if we've seen errors.

for  gcc/testsuite/ChangeLog

PR c++/85039
* g++.dg/pr85039-1.C: New.
* g++.dg/pr85039-2.C: New.
* g++.dg/parse/semicolon3.C: Remove test_offsetof.

Added:
trunk/gcc/testsuite/g++.dg/pr85039-1.C
trunk/gcc/testsuite/g++.dg/pr85039-2.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/semicolon3.C

[Bug target/85417] -fcf-protection should provide CET protection on x86

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
Created attachment 43954
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43954=edit
A patch

I am testing this patch.

[Bug bootstrap/84856] Bootstrap failure on riscv: comparison of integer expressions of different signedness

[wilson at gcc dot gnu.org]

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

--- Comment #8 from Jim Wilson  ---
I copied the design of the patch from the i386 backend, so in theory it should
work.  The layout of the stack is completely at the control of the target
backend, so uses of STACK_BOUNDARY outside the backend should not be a problem.

I did some sanity checking when I made the check, but now that you point the
problem out I see that I missed two cases.  outgoing_args_size and
pretend_args_size are not longer rounded to the PREFERRED_STACK_BOUNDARY size,
they are rounded to the smaller STACK_BOUNDARY size instead.  We can fix this
in riscv_compute_frame_info by adding RISCV_STACK_ALIGN macro calls around the
uses of these two values.  This is a simple fix.  I'm testing a patch now.

[Bug target/85400] R_SPARC_TLS_*: invalid relocations generated for optimized builds on sparc

[phantall at gmail dot com]

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

--- Comment #2 from Brian Vandenberg  ---
Sorry, I was hand-typing from an air-gapped network.  I left the type name
out; line 5 should read:

>  thread_local int mything = 3;

-brian

On Mon, Apr 16, 2018 at 2:52 AM, ebotcazou at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85400
>
> Eric Botcazou  changed:
>
>What|Removed |Added
> 
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2018-04-16
>  CC||ebotcazou at gcc dot
> gnu.org
>  Ever confirmed|0   |1
>
> --- Comment #1 from Eric Botcazou  ---
> > In Solaris 10 & 11 using GCC versions 4.8, 4.9.2, 7.2.0 I get relocation
> > errors when thread_local variables are used in a struct/class.  Example
> code
> > that reproduces the problem:
> >
> > > struct Test {
> > >   int blah( int y ) {
> > > thread_local mything = 3;
> > > mything = y > 0 ? y : mything;
> > > return mything;
> > >   }
> > > };
> > > int stuff( Test& test, int y ) {
> > >   return test.blah(y);
> > > }
>
> This doesn't compile for me:
>
> pr85400.C: In member function 'int Test::blah(int)':
> pr85400.C:5:18: error: 'mything' does not name a type
>  thread_local mything = 3;
>   ^~~
> pr85400.C:6:5: error: 'mything' was not declared in this scope
>  mything = y > 0 ? y : mything;
>  ^~~
>
> > * The compilers I built and those produced by OpenCSW use the Solaris
> > assembler (/usr/ccs/bin/as) instead of gas.
>
> Do you have local patches?  My compiler is the stock GCC 8.x:
>
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/nfs/homes/homes/botcazou/gcc-head/
> install_sparc/bin/../libexec/gcc/sparc-sun-solaris2.10/8.0.1/lto-wrapper
> Target: sparc-sun-solaris2.10
> Configured with: /homes/botcazou/gcc-head/src/configure
> --build=sparc-sun-solaris2.10 --prefix=/homes/botcazou/gcc-
> head/install_sparc
> --with-as=/homes/botcazou/gcc-head/install_sparc/bin/as
> --with-gmp=/homes/botcazou/support/sparc
> --with-mpfr=/homes/botcazou/support/sparc
> --with-mpc=/homes/botcazou/support/sparc --enable-languages=all
> --disable-nls
> Thread model: posix
> gcc version 8.0.1 20180325 (experimental) (GCC)
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug c/85425] gcc 6.2.1 fails to catch error in function calling arguments

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-16
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Jonathan Wakely  ---
(In reply to Gerhard Heinzel from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> 
> Many thanks for your quick response. 
> I normally don't use -Wconversion because it floods me with
> uninteresting errors about size_t, floor(), and code from bison/flex etc. 

Yes, it's true that it produces a lot of warnings (which is why it isn't
enabled by -Wall).

It might be possible to add a new warning for cases where the arguments are
"obviously" transposed.

For example, in my reduced version:

void ghhrobust_search (double ay, int type) { }

void f(int i, double d) { ghhrobust_search(i, d); }

Although both conversions are allowed by the language, the fact that swapping
the arguments would require no conversions could be used to detect cases that
might be accidental.

Confirming as an enhancement request for a new warning.

[Bug c/85425] gcc 6.2.1 fails to catch error in function calling arguments

[gerhard.heinzel at aei dot mpg.de]

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

--- Comment #2 from Gerhard Heinzel  ---
(In reply to Jonathan Wakely from comment #1)

Many thanks for your quick response. 
I normally don't use -Wconversion because it floods me with
uninteresting errors about size_t, floor(), and code from bison/flex etc. 
But I'll try to use it more now.

Cheers,

Gerhard


> The example can be reduced to:
> 
> void ghhrobust_search (double ay, int type) { }
> 
> void f(int i, double d) { ghhrobust_search(i, d); }
> 
> This must not produce an error, because it is 100% valid according to the C
> standard. An int can be converted to a double and a double can be converted
> to an int, so the code is valid.
> 
> If you use -Wconversion you get a warning:
> 
> 
> a.c: In function ‘void f(int, double)’:
> a.c:3:48: warning: conversion to ‘int’ from ‘double’ may alter its value
> [-Wfloat-conversion]
>  void f(int i, double d) { ghhrobust_search(i, d); }
> ^
> 
> This seems to be what you're looking for. Indeed, compiling your attached
> code with -Wconversion gives a warning on the relevant line:
> 
> fail_contour.c: In function ‘contour_trace’:
> fail_contour.c:203:56: warning: conversion to ‘int’ from ‘double’ may alter
> its value [-Wfloat-conversion]

[Bug c++/59960] accepts ill-formed 'auto a1 = t1, a2 = t2;' where t1 and t2 have different template types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
As noted in comment 1 this is a dup of another bug with additional details, so
I'm closing this one despite it being reported first.

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

[Bug c++/79009] Missing 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||gcc at abeckmann dot de

--- Comment #4 from Jonathan Wakely  ---
*** Bug 59960 has been marked as a duplicate of this bug. ***

[Bug c++/79009] Missing 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-16
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Confirmed. Clang rejects the original with:

auto.cc:5:3: error: 'auto' deduced as 'long' in declaration of 'i' and deduced
as 'int' in declaration of 'j'
  auto i = t, j = 1;
  ^~  ~
auto.cc:25:3: note: in instantiation of function template specialization
'foo' requested here
  foo (0L);
  ^
auto.cc:12:3: error: 'auto' deduced as 'int' in declaration of 'i' and deduced
as 'long' in declaration of 'j'
  auto i = 1, j = t, k = 2;
  ^~  ~
auto.cc:26:3: note: in instantiation of function template specialization
'bar' requested here
  bar (0L);
  ^
auto.cc:19:3: error: 'auto' deduced as 'int' in declaration of 'i' and deduced
as 'long' in declaration of 'j'
  auto i = t, j = u;
  ^~  ~
auto.cc:27:3: note: in instantiation of function template specialization
'foo' requested here
  foo (1, 2L);
  ^
3 errors generated.


And similarly for comment 2:

auto.cc:7:9: error: 'auto' deduced as 'S' in declaration of 's' and
deduced as 'int' in declaration of 'i'
auto s = S(), i = 1;
^~~  ~
auto.cc:11:9: note: in instantiation of function template specialization
'f' requested here
f();
^
1 error generated.

[Bug c/85418] -Wformat-truncation on inlinned function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Martin Sebor  ---
The warning is intended (and designed to trigger across inlined function
calls).  The call to snprintf() truncates the string which may be unintended.

To avoid the warning either use the return value of the snprintf function to
take some action (i.e., handle the truncation) or use the len argument to
specify the precision of the %s directive like so:

snprintf (b, sizeof b, "%.*s", (int)len, s);

[Bug c/85425] gcc 6.2.1 fails to catch error in function calling arguments

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The example can be reduced to:

void ghhrobust_search (double ay, int type) { }

void f(int i, double d) { ghhrobust_search(i, d); }

This must not produce an error, because it is 100% valid according to the C
standard. An int can be converted to a double and a double can be converted to
an int, so the code is valid.

If you use -Wconversion you get a warning:


a.c: In function ‘void f(int, double)’:
a.c:3:48: warning: conversion to ‘int’ from ‘double’ may alter its value
[-Wfloat-conversion]
 void f(int i, double d) { ghhrobust_search(i, d); }
^

This seems to be what you're looking for. Indeed, compiling your attached code
with -Wconversion gives a warning on the relevant line:

fail_contour.c: In function ‘contour_trace’:
fail_contour.c:203:56: warning: conversion to ‘int’ from ‘double’ may alter its
value [-Wfloat-conversion]

[Bug c++/79009] Missing 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration

[sasha2048 at gmail dot com]

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

Sasha Unknown  changed:

   What|Removed |Added

 CC||sasha2048 at gmail dot com

--- Comment #2 from Sasha Unknown  ---
I confirm that this still happens on my g++-7 (Ubuntu 7.2.0-1ubuntu1~16.04)
7.2.0.

My test program (essentially the same as original):

template
struct S {};

template
void f() {
auto s = S(), i = 1;
}

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

[Bug c/85419] Incorrect determination of null pointer constant

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Martin Sebor  ---
Because they don't produce lvalues top-level qualifiers in casts are
meaningless.  As a result (void* restrict)0 is the same as (void*)0 and the
result is a null pointer constant.

[Bug target/84574] Function return thunks shouldn't be aliased to indirect branch thunks

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Apr 16 19:11:13 2018
New Revision: 259422

URL: https://gcc.gnu.org/viewcvs?rev=259422=gcc=rev
Log:
i386: Don't generate alias for function return thunk

Function return thunks shouldn't be aliased to indirect branch thunks
since indirect branch thunks are placed in COMDAT section and a COMDAT
section with indirect branch may not have function return thunk.  This
patch generates function return thunks directly.

gcc/

Backport from mainline
PR target/84574
* config/i386/i386.c (indirect_thunk_needed): Update comments.
(indirect_thunk_bnd_needed): Likewise.
(indirect_thunks_used): Likewise.
(indirect_thunks_bnd_used): Likewise.
(indirect_return_needed): New.
(indirect_return_bnd_needed): Likewise.
(output_indirect_thunk_function): Add a bool argument for
function return.
(output_indirect_thunk_function): Don't generate alias for
function return thunk.
(ix86_code_end): Call output_indirect_thunk_function to generate
function return thunks.
(ix86_output_function_return): Set indirect_return_bnd_needed
and indirect_return_needed instead of indirect_thunk_bnd_needed
and indirect_thunk_needed.

gcc/testsuite/

Backport from mainline
PR target/84574
* gcc.target/i386/ret-thunk-9.c: Expect __x86_return_thunk
label instead of __x86_indirect_thunk label.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/ret-thunk-9.c

[Bug target/84039] x86 retpolines and CFI

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Apr 16 19:08:14 2018
New Revision: 259421

URL: https://gcc.gnu.org/viewcvs?rev=259421=gcc=rev
Log:
i386: Add TARGET_INDIRECT_BRANCH_REGISTER

For

---
struct C {
  virtual ~C();
  virtual void f();
};

void
f (C *p)
{
  p->f();
  p->f();
}
---

-mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:

_Z1fP1C:
.LFB0:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq(%rdi), %rax
movq%rdi, %rbx
jmp .LIND1
.LIND0:
pushq   16(%rax)
jmp __x86_indirect_thunk
.LIND1:
call.LIND0
movq(%rbx), %rax
movq%rbx, %rdi
popq%rbx
.cfi_def_cfa_offset 8
movq16(%rax), %rax
jmp __x86_indirect_thunk_rax
.cfi_endproc

x86-64 is supposed to have asynchronous unwind tables by default, but
there is nothing that reflects the change in the (relative) frame
address after .LIND0.  That region really has to be moved outside of
the .cfi_startproc/.cfi_endproc bracket.

This patch adds TARGET_INDIRECT_BRANCH_REGISTER to force indirect
branch via register whenever -mindirect-branch= is used.  Now,
-mindirect-branch=thunk-extern -O2 on x86-64 GNU/Linux generates:

_Z1fP1C:
.LFB0:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq(%rdi), %rax
movq%rdi, %rbx
movq16(%rax), %rax
call__x86_indirect_thunk_rax
movq(%rbx), %rax
movq%rbx, %rdi
popq%rbx
.cfi_def_cfa_offset 8
movq16(%rax), %rax
jmp __x86_indirect_thunk_rax
.cfi_endproc

so that "-mindirect-branch=thunk-extern" is equivalent to
"-mindirect-branch=thunk-extern -mindirect-branch-register", which is
used by Linux kernel.

gcc/

Backport from mainline
2018-02-26  H.J. Lu  

PR target/84039
* config/i386/constraints.md (Bs): Replace
ix86_indirect_branch_register with
TARGET_INDIRECT_BRANCH_REGISTER.
(Bw): Likewise.
* config/i386/i386.md (indirect_jump): Likewise.
(tablejump): Likewise.
(*sibcall_memory): Likewise.
(*sibcall_value_memory): Likewise.
Peepholes of indirect call and jump via memory: Likewise.
(*sibcall_GOT_32): Disallowed for TARGET_INDIRECT_BRANCH_REGISTER.
(*sibcall_value_GOT_32): Likewise.
* config/i386/predicates.md (indirect_branch_operand): Likewise.
(GOT_memory_operand): Likewise.
(call_insn_operand): Likewise.
(sibcall_insn_operand): Likewise.
(GOT32_symbol_operand): Likewise.
* config/i386/i386.h (TARGET_INDIRECT_BRANCH_REGISTER): New.

gcc/testsuite/

Backport from mainline
2018-02-26  H.J. Lu  

PR target/84039
* gcc.target/i386/indirect-thunk-1.c: Updated.
* gcc.target/i386/indirect-thunk-2.c: Likewise.
* gcc.target/i386/indirect-thunk-3.c: Likewise.
* gcc.target/i386/indirect-thunk-4.c: Likewise.
* gcc.target/i386/indirect-thunk-5.c: Likewise.
* gcc.target/i386/indirect-thunk-6.c: Likewise.
* gcc.target/i386/indirect-thunk-7.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-1.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-2.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-3.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-4.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-5.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-6.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-7.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-1.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-2.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-3.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-4.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-1.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-2.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-3.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-4.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-5.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-6.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-7.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-1.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-2.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-3.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-4.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-5.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-6.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-7.c: Likewise.
* 

[Bug target/84530] -mfunction-return=thunk does not work for simple_return_pop_internal insn

[hjl at gcc dot gnu.org]

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

--- Comment #6 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Apr 16 19:06:32 2018
New Revision: 259420

URL: https://gcc.gnu.org/viewcvs?rev=259420=gcc=rev
Log:
i386: Update -mfunction-return= for return with pop

When -mfunction-return= is used, simple_return_pop_internal should pop
return address into ECX register, adjust stack by bytes to pop from stack
and jump to the return thunk via ECX register.

Revision 257992 removed the bool argument from ix86_output_indirect_jmp.
Update comments to reflect it.

Tested on i686 and x86-64.

gcc/

Backport from mainline
2018-02-26  H.J. Lu  

* config/i386/i386.c (ix86_output_indirect_jmp): Update comments.

2018-02-26  H.J. Lu  

PR target/84530
* config/i386/i386-protos.h (ix86_output_indirect_jmp): Remove
the bool argument.
(ix86_output_indirect_function_return): New prototype.
(ix86_split_simple_return_pop_internal): Likewise.
* config/i386/i386.c (indirect_return_via_cx): New.
(indirect_return_via_cx_bnd): Likewise.
(indirect_thunk_name): Handle return va CX_REG.
(output_indirect_thunk_function): Create alias for
__x86_return_thunk_[re]cx and __x86_return_thunk_[re]cx_bnd.
(ix86_output_indirect_jmp): Remove the bool argument.
(ix86_output_indirect_function_return): New function.
(ix86_split_simple_return_pop_internal): Likewise.
* config/i386/i386.md (*indirect_jump): Don't pass false
to ix86_output_indirect_jmp.
(*tablejump_1): Likewise.
(simple_return_pop_internal): Change it to define_insn_and_split.
Call ix86_split_simple_return_pop_internal to split it for
-mfunction-return=.
(simple_return_indirect_internal): Call
ix86_output_indirect_function_return instead of
ix86_output_indirect_jmp.

gcc/testsuite/

Backport from mainline
2018-02-26  H.J. Lu  

PR target/84530
* gcc.target/i386/ret-thunk-22.c: New test.
* gcc.target/i386/ret-thunk-23.c: Likewise.
* gcc.target/i386/ret-thunk-24.c: Likewise.
* gcc.target/i386/ret-thunk-25.c: Likewise.
* gcc.target/i386/ret-thunk-26.c: Likewise.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/ret-thunk-22.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/ret-thunk-23.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/ret-thunk-24.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/ret-thunk-25.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/ret-thunk-26.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386-protos.h
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/config/i386/i386.md
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c/85425] New: gcc 6.2.1 fails to catch error in function calling arguments

[gerhard.heinzel at aei dot mpg.de]

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

Bug ID: 85425
   Summary: gcc 6.2.1 fails to catch error in function calling
arguments
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.heinzel at aei dot mpg.de
  Target Milestone: ---

Created attachment 43953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43953=edit
preprocessed single C input file

Dear gcc maintainers,

First let me say that I am a very happy and grateful user of gcc since about 25
years.
I program in C under Linux and try to encourage my students to do the same.
Such C programs are the workhorse of my physics research group, although I have
to admit that the younger students now prefer C++ which I never really got used
to.

Anyway, here is the bug:

The attached program, which is already reduced to a single file that
contains about 5% of the code of the full thing, 
does _NOT_ trigger an error although in my opinion it should,
when compiled with

gcc-6 -Wall -Wextra -c fail_contour.i

A function is called with messed up order of parameters,
mixing int with double.

The function is declared and defined as

contour_point_t ghhrobust_search 
(contour_point_t * p, contour_point_t plast, double ax, double ay, int type)

but called as

p = ghhrobust_search (ptrials, plast, type, ax, ay);

where the integer variable "type" is at position 3 instead of at the end.

gcc (version info below) does not catch this error, which
I consider a bug.

Possibly I made a stupid mistake, in which case I'd be
grateful for a short notice.
I have tried to follow the bug reporting instructions.
If this is a real problem, I'd of course be willing to
submit more information or try to reduce the problem further
to a minimal case, although I suspect that you are much better
at that than I am.

With best greetings and thanks for your support,

Gerhard Heinzel.

-


Using built-in specs.
COLLECT_GCC=gcc-6
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,fortran,ada,go --enable-offload-targets=hsa
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/6
--enable-ssp --disable-libssp --disable-libvtv --disable-libcc1
--disable-plugin --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --with-default-libstdcxx-abi=gcc4-compatible
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --enable-gnu-indirect-function --program-suffix=-6
--without-system-libunwind --enable-multilib --with-arch-32=x86-64
--with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 6.2.1 20160826 [gcc-6-branch revision 239773] (SUSE Linux) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-mtune=generic'
'-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/6/cc1 -E -quiet -v fail_contour.c
-mtune=generic -march=x86-64 -Wall -Wextra -fpch-preprocess -o fail_contour.i
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib64/gcc/x86_64-suse-linux/6/include
 /usr/local/include
 /usr/lib64/gcc/x86_64-suse-linux/6/include-fixed
 /usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-mtune=generic'
'-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/6/cc1 -fpreprocessed fail_contour.i -quiet
-dumpbase fail_contour.c -mtune=generic -march=x86-64 -auxbase fail_contour
-Wall -Wextra -version -o fail_contour.s
GNU C11 (SUSE Linux) version 6.2.1 20160826 [gcc-6-branch revision 239773]
(x86_64-suse-linux)
compiled by GNU C version 6.2.1 20160826 [gcc-6-branch revision
239773], GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2, isl version
none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (SUSE Linux) version 6.2.1 20160826 [gcc-6-branch revision 239773]
(x86_64-suse-linux)
compiled by GNU C version 6.2.1 20160826 [gcc-6-branch revision
239773], GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2, isl version
none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9c15a1c4f36e0692cc50ecfa3c25d889
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-c' '-mtune=generic'
'-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/bin/as -v
--64 -o fail_contour.o fail_contour.s
GNU assembler version 2.29.1 (x86_64-suse-linux) using BFD version (GNU
Binutils; openSUSE Leap 42.3) 2.29.1

[Bug target/85424] The __builtin_packlongdouble function might have issues with the output overlapping the inputs

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-16
 CC||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/85424] New: The __builtin_packlongdouble function might have issues with the output overlapping the inputs

[meissner at gcc dot gnu.org]

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

Bug ID: 85424
   Summary: The __builtin_packlongdouble function might have
issues with the output overlapping the inputs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

When I was working on PR target/85075, I noticed the big endian version of the
compiler would not build the 32-bit library that used the function to create an
explicit IBM extended double value.

The problem is the pattern:

(define_insn_and_split "pack"
  [(set (match_operand:FMOVE128 0 "register_operand" "=d,")
(unspec:FMOVE128
 [(match_operand: 1 "register_operand" "0,d")
  (match_operand: 2 "register_operand" "d,d")]
 UNSPEC_PACK_128BIT))]
  "FLOAT128_2REG_P (mode)"
  "@
   fmr %L0,%2
   #"
  "&& reload_completed && REGNO (operands[0]) != REGNO (operands[1])"
  [(set (match_dup 3) (match_dup 1))
   (set (match_dup 4) (match_dup 2))]
{
  unsigned dest_hi = REGNO (operands[0]);
  unsigned dest_lo = dest_hi + 1;

  gcc_assert (!IN_RANGE (REGNO (operands[1]), dest_hi, dest_lo));
  gcc_assert (!IN_RANGE (REGNO (operands[2]), dest_hi, dest_lo));

  operands[3] = gen_rtx_REG (mode, dest_hi);
  operands[4] = gen_rtx_REG (mode, dest_lo);
}
  [(set_attr "type" "fpsimple,fp")
   (set_attr "length" "4,8")])

Generated an insn not found message, when one of the input operands overlapped
the output.  In the case I saw, operand1 was the same as the second output
register.  It is better to just delete the support for the register overlapping
(and hence trying to save a move), then to see this pop again in somewhat rare
circumstances.

[Bug bootstrap/83839] [8 Regression] bootstrap fails in gcc/config/i386/i386.c on darwin

[hjl at gcc dot gnu.org]

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

--- Comment #10 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Apr 16 18:55:04 2018
New Revision: 259414

URL: https://gcc.gnu.org/viewcvs?rev=259414=gcc=rev
Log:
x86: Add -mfunction-return=

Add -mfunction-return= option to convert function return to call and
return thunks.  The default is 'keep', which keeps function return
unmodified.  'thunk' converts function return to call and return thunk.
'thunk-inline' converts function return to inlined call and return thunk.
'thunk-extern' converts function return to external call and return
thunk provided in a separate object file.  You can control this behavior
for a specific function by using the function attribute function_return.

Function return thunk is the same as memory thunk for -mindirect-branch=
where the return address is at the top of the stack:

__x86_return_thunk:
call L2
L1:
pause
lfence
jmp L1
L2:
lea 8(%rsp), %rsp|lea 4(%esp), %esp
ret

and function return becomes

jmp __x86_return_thunk

-mindirect-branch= tests are updated with -mfunction-return=keep to
avoid false test failures when -mfunction-return=thunk is added to
RUNTESTFLAGS for "make check".

gcc/

Backport from mainline
2018-01-14  H.J. Lu  

* config/i386/i386-protos.h (ix86_output_function_return): New.
* config/i386/i386.c (ix86_set_indirect_branch_type): Also
set function_return_type.
(indirect_thunk_name): Add ret_p to indicate thunk for function
return.
(output_indirect_thunk_function): Pass false to
indirect_thunk_name.
(ix86_output_indirect_branch_via_reg): Likewise.
(ix86_output_indirect_branch_via_push): Likewise.
(output_indirect_thunk_function): Create alias for function
return thunk if regno < 0.
(ix86_output_function_return): New function.
(ix86_handle_fndecl_attribute): Handle function_return.
(ix86_attribute_table): Add function_return.
* config/i386/i386.h (machine_function): Add
function_return_type.
* config/i386/i386.md (simple_return_internal): Use
ix86_output_function_return.
(simple_return_internal_long): Likewise.
* config/i386/i386.opt (mfunction-return=): New option.
(indirect_branch): Mention -mfunction-return=.
* doc/extend.texi: Document function_return function attribute.
* doc/invoke.texi: Document -mfunction-return= option.

gcc/testsuite/

Backport from mainline
2018-01-14  H.J. Lu  

* gcc.target/i386/indirect-thunk-1.c (dg-options): Add
-mfunction-return=keep.
* gcc.target/i386/indirect-thunk-2.c: Likewise.
* gcc.target/i386/indirect-thunk-3.c: Likewise.
* gcc.target/i386/indirect-thunk-4.c: Likewise.
* gcc.target/i386/indirect-thunk-5.c: Likewise.
* gcc.target/i386/indirect-thunk-6.c: Likewise.
* gcc.target/i386/indirect-thunk-7.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-1.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-2.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-3.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-4.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-5.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-6.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-7.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-8.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-1.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-2.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-3.c: Likewise.
* gcc.target/i386/indirect-thunk-bnd-4.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-1.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-2.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-3.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-4.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-5.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-6.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-7.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-1.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-2.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-3.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-4.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-5.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-6.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-7.c: Likewise.
* gcc.target/i386/ret-thunk-1.c: New test.
* gcc.target/i386/ret-thunk-10.c: Likewise.
* gcc.target/i386/ret-thunk-11.c: Likewise.
* gcc.target/i386/ret-thunk-12.c: Likewise.
* gcc.target/i386/ret-thunk-13.c: Likewise.
* gcc.target/i386/ret-thunk-14.c: 

[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc

[dclarke at blastwave dot org]

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

--- Comment #14 from Dennis Clarke  ---
Since this bug was a "bootstrap" issue I think I should close it 
as simply an issue related to the garbage collector libs needed.

[Bug target/83905] ix86_expand_epilogue modifies the copy of cfun->machine->frame

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Apr 16 18:44:43 2018
New Revision: 259411

URL: https://gcc.gnu.org/viewcvs?rev=259411=gcc=rev
Log:
i386: Use const reference of struct ix86_frame to avoid copy

We can use const reference of struct ix86_frame to avoid making a local
copy of ix86_frame.  ix86_expand_epilogue makes a local copy of struct
ix86_frame and uses the reg_save_offset field as a local variable.  This
patch uses a separate local variable for reg_save_offset.

Tested on x86-64 with ada.

Backport from mainline
PR target/83905
* config/i386/i386.c (ix86_expand_prologue): Use cost reference
of struct ix86_frame.
(ix86_expand_epilogue): Likewise.  Add a local variable for
the reg_save_offset field in struct ix86_frame.

Modified:
branches/gcc-6-branch/gcc/ChangeLog

[Bug target/82499] x86: small stack initial adjustments could use push

[hjl at gcc dot gnu.org]

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

--- Comment #6 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Apr 16 18:42:57 2018
New Revision: 259408

URL: https://gcc.gnu.org/viewcvs?rev=259408=gcc=rev
Log:
i386: Move struct ix86_frame to machine_function

Make ix86_frame available to i386 code generation.  This is needed to
backport the patch set of -mindirect-branch= to mitigate variant #2 of
the speculative execution vulnerabilities on x86 processors identified
by CVE-2017-5715, aka Spectre.

Backport from mainline
2017-10-13  H.J. Lu  

PR target/82499
* config/i386/i386.h (ix86_red_zone_size): New.

2017-06-01  Bernd Edlinger  

* config/i386/i386.c (ix86_frame): Moved to ...
* config/i386/i386.h (ix86_frame): Here.
(machine_function): Add frame.
* config/i386/i386.c (ix86_compute_frame_layout): Repace the
frame argument with >machine->frame.
(ix86_can_use_return_insn_p): Don't pass  to
ix86_compute_frame_layout.  Copy frame from cfun->machine->frame.
(ix86_can_eliminate): Likewise.
(ix86_expand_prologue): Likewise.
(ix86_expand_epilogue): Likewise.
(ix86_expand_split_stack_prologue): Likewise.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/i386/i386.c
branches/gcc-6-branch/gcc/config/i386/i386.h

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  ---
> We looked into this with Martin todday. There are two bugs: one is the fact
> that lto.c forgets to register the type in case it was within strongly
> connected component after its outer type. The order depends on hash values
> and is not well determined. We do not want to test TYPE_CANONICAL being
> non-NULL. Martin is testing it.

OK, thanks for sorting this out.  It helps when specialists kick in. ;-)

[Bug target/85080] [8 regression] gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c fails starting with r248678

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

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

[Bug target/85080] [8 regression] gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c fails starting with r248678

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Author: wschmidt
Date: Mon Apr 16 18:18:42 2018
New Revision: 259407

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

2018-04-16  Bill Schmidt  

PR target/85080
* gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c: Skip dump checks
if the target supports efficient unaligned storage accesses.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c

[Bug middle-end/84955] [7/8 Regression] Incorrect OpenACC tile expansion

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries  ---
Author: vries
Date: Mon Apr 16 18:01:09 2018
New Revision: 259406

URL: https://gcc.gnu.org/viewcvs?rev=259406=gcc=rev
Log:
[openacc] Fix ICE when compiling tile loop containing infinite loop

2018-04-16  Cesar Philippidis  
Tom de Vries  

PR middle-end/84955
* omp-expand.c (expand_oacc_for): Add dummy false branch for
tiled basic blocks without omp continue statements.

* testsuite/libgomp.oacc-c-c++-common/pr84955.c: New test.
* testsuite/libgomp.oacc-fortran/pr84955.f90: New test.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr84955.c
trunk/libgomp/testsuite/libgomp.oacc-fortran/pr84955.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-expand.c
trunk/libgomp/ChangeLog

[Bug tree-optimization/85420] missing -Wrestrict with -fsanitize=undefined

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Whether that's a good or bad decision is a matter of opinion.  Most coding
guidelines advise against using strcpy even between distinct objects.  I happen
to think that's unnecessarily restrictive when the size of the destination is
known to be large enough for the source string, but I do feel it's unsafe to
use strcpy to copy substrings within the same array and that using memcpy is
preferable.  (The strengths and weaknesses of warnings and sanitizers are well
known and don't need to be debated here.)

[Bug rtl-optimization/85423] [8 Regression] ICE in code_motion_process_successors, at sel-sched.c:6403

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-16
 CC||abel at gcc dot gnu.org,
   ||amonakov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

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

[Bug c++/85421] [8 regression] internal compiler error: in ipa_propagate_frequency, at ipa-profile.c:405

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #2 from Martin Jambor  ---
 will have a look the first thing tomorrow.

[Bug tree-optimization/85420] missing -Wrestrict with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #5)
> The warning for attachment 43950 [details] is intended and the bug is
> actually in failing to issue it without -fsanitize=undefined.  Unlike for
> raw memory functions such as memcpy, for string functions like strcpy
> -Wrestrict triggers even for possible overlaps. 

That is a bad decision.  The overlap is something much better caught at
runtime, where it can be accurately, and not just throw mostly false positive
warnings at user when there is nothing wrong with the code and hardly anything
that can be done to avoid the false positive warnings.
-fsanitize=address can diagnose strcpy etc. overlap just fine.

[Bug tree-optimization/85420] missing -Wrestrict with -fsanitize=undefined

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-16
 CC||msebor at gcc dot gnu.org
  Component|middle-end  |tree-optimization
Summary|More -Wrestrict false   |missing -Wrestrict with
   |positives with  |-fsanitize=undefined
   |-fsanitize=undefined|
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
The warning for attachment 43950 is intended and the bug is actually in failing
to issue it without -fsanitize=undefined.  Unlike for raw memory functions such
as memcpy, for string functions like strcpy -Wrestrict triggers even for
possible overlaps.  I.e., copying a substring of the same array is designed to
warn whether or not the overlap is certain, as in:

  char a[32];

  void f (int i)
  {
__builtin_strcpy (a, a + i);   // -Wrestrict expected here
  }

This doesn't work completely consistently -- e.g., the above won't warn if a is
changed to a pointer -- but the basic idea is that strcpy is too
"unpredictable" to be safely used to copy substrings within the same array.  So
confirming for the missing warning.

The warning in attachment 43951 looks like a different bug in -Wrestrict: it
doesn't consider the sizes of the two array members and so it doesn't
distinguish between them.  Let me open a separate report for this.

[Bug rtl-optimization/85423] New: [8 Regression] ICE in code_motion_process_successors, at sel-sched.c:6403

[asolokha at gmx dot com]

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

Bug ID: 85423
   Summary: [8 Regression] ICE in code_motion_process_successors,
at sel-sched.c:6403
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-8.0.0-alpha20180415 snapshot (r259389) ICEs when compiling the following
snippet w/ -march=nano -O2 (-O3, -Ofast) -fselective-scheduling2
-fvar-tracking-assignments -fno-guess-branch-probability -fno-peephole2
-fno-ssa-phiopt -fno-tree-pre --param max-jump-thread-duplication-stmts=8:

int vn, xm;

void
i1 (int);

void
mb (int *ap, int ev)
{
  while (vn < 1)
{
  i1 (vn);

  ev += *ap && ++vn;

  while (xm < 1)
++xm;

  if (*ap == 0)
*ap = ev;

  ++vn;
}
}

% x86_64-unknown-linux-gnu-gcc-8.0.0-alpha20180415 -march=nano -O2
-fselective-scheduling2 -fvar-tracking-assignments
-fno-guess-branch-probability -fno-peephole2 -fno-ssa-phiopt -fno-tree-pre
--param max-jump-thread-duplication-stmts=8 -w -c l7diilgr.c
during RTL pass: sched2
l7diilgr.c: In function 'mb':
l7diilgr.c:23:1: internal compiler error: in code_motion_process_successors, at
sel-sched.c:6403
 }
 ^
0xc6c314 code_motion_process_successors
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:6400
0xc6c314 code_motion_path_driver
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:6622
0xc6be6e code_motion_process_successors
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:6356
0xc6be6e code_motion_path_driver
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:6622
0xc6be6e code_motion_process_successors
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:6356
0xc6be6e code_motion_path_driver
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:6622
0xc6c512 move_op
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:6714
0xc6c512 move_exprs_to_boundary
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:5237
0xc6c512 schedule_expr_on_boundary
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:5450
0xc705ac fill_insns
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:5592
0xc705ac schedule_on_fences
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7366
0xc705ac sel_sched_region_2
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7504
0xc71d28 sel_sched_region_1
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7546
0xc725ae sel_sched_region(int)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7647
0xc734c1 run_selective_scheduling()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7733
0xc52d45 rest_of_handle_sched2
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sched-rgn.c:3732
0xc52d45 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sched-rgn.c:3876

[Bug c++/85421] [8 regression] internal compiler error: in ipa_propagate_frequency, at ipa-profile.c:405

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-16
 CC||mjambor at suse dot cz
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It is caused by r259319.

[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc

[dclarke at blastwave dot org]

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

--- Comment #13 from Dennis Clarke  ---
Finally managed to get a decent looking three stage bootstrap to complete
without bizarre errors.  Thanks to Matthias Klose for the suggestion to
get away from that gc issue entirely.

Testsuite is running however I am not thrilled with what I see :

=== gcc Summary ===

# of expected passes112961
# of unexpected failures910
# of unexpected successes   22
# of expected failures  347
# of unresolved testcases   1
# of unsupported tests  2794
/usr/local/build/gcc-7.3.0_linux_4.15.0-2-powerpc64_ppc64.005/gcc/xgcc  version
7.3.0 (genunix Mon Apr 16 00:04:56 GMT 2018) 


I'll followup with the libquadmath issues that may yet exist. Not sure yet.

Dennis

[Bug target/85417] -fcf-protection should provide CET protection on x86

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|Extra test failures with|-fcf-protection should
   |-fcf-protection -mcet   |provide CET protection on
   ||x86

--- Comment #2 from H.J. Lu  ---
I am working to enable CET on Linux with a single binary. -fcf-protection
should provide CET protection on x86 by default.  We can add a command-line
option if we want a different implementation.

[Bug middle-end/85420] More -Wrestrict false positives with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Franz Sirl from comment #3)
> Hmm, this maybe creduce'd too much, the original source reads more like
> 
>strcpy(b, b + a + 10);
> 
> which would be only UB for sure if strlen(b + a + 10) >= 9, or?

If b was actually a larger array, then yes, otherwise even b + 10 would be UB.

[Bug middle-end/85420] More -Wrestrict false positives with -fsanitize=undefined

[sirl at gcc dot gnu.org]

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

--- Comment #3 from Franz Sirl  ---
Hmm, this maybe creduce'd too much, the original source reads more like

   strcpy(b, b + a + 10);

which would be only UB for sure if strlen(b + a + 10) >= 9, or?

[Bug target/83660] ICE with vec_extract inside expression statement

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from acsawdey at gcc dot gnu.org ---
Possibly need backports to both 7 and 6.

[Bug middle-end/84955] [7/8 Regression] Incorrect OpenACC tile expansion

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to cesar from comment #6)
> It should be noted that GCC also chokes with any empty OpenACC loop in
> general.

Filed as PR85422 - [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||openacc

--- Comment #1 from Tom de Vries  ---
Tentative patch was submitted here (
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00316.html ) and committed, but
reverted again.

[Bug lto/85422] New: [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[vries at gcc dot gnu.org]

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

Bug ID: 85422
   Summary: [openacc] ICE at cfgloop.c:468: segfault in
flow_loops_find
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

When compiling this program:
...
int
main (void)
{
#pragma acc parallel
#pragma acc loop
  for (int i = 1; i < 10; i++)
  for (;;)
;

  return 0;
}
...

we run into this ICE:
...
to1: internal compiler error: Segmentation fault
0xac51ff crash_signal
gcc/toplev.c:325
0x62cc08 flow_loops_find(loops*)
gcc/cfgloop.c:468
0x961b3b input_cfg
gcc/lto-streamer-in.c:841
0x961b3b input_function
gcc/lto-streamer-in.c:1069
0x961b3b lto_read_body_or_constructor
gcc/lto-streamer-in.c:1287
0x961b3b lto_input_variable_constructor(lto_file_decl_data*, varpool_node*,
char const*)
gcc/lto-streamer-in.c:1345
0x651d4e cgraph_node::get_untransformed_body()
gcc/cgraph.c:3667
0x6604d2 cgraph_node::expand()
gcc/cgraphunit.c:2109
0x661df2 output_in_order
gcc/cgraphunit.c:2381
0x661df2 symbol_table::compile()
gcc/cgraphunit.c:2623
0x5adccc lto_main()
gcc/lto/lto.c:3382
...

[Bug rtl-optimization/84842] [7/8 Regression] ICE in verify_target_availability, at sel-sched.c:1569

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |7.4
Summary|ICE in  |[7/8 Regression] ICE in
   |verify_target_availability, |verify_target_availability,
   |at sel-sched.c:1569 |at sel-sched.c:1569

--- Comment #9 from Jakub Jelinek  ---
Started with r241631 (at least the #c3 testcase).  You need -m32 which isn't
entirely obvious from it, and -mcpu=power8 is essential, so either you need gas
with that support around, or e.g. hand-edit auto-host.h to make sure
HAVE_AS_CMPB, HAVE_AS_DFP, HAVE_AS_FPRND, HAVE_AS_POPCNTD, HAVE_AS_POWER8
are defined to 1, then make -j16 cc1.

[Bug c++/85421] New: [8 regression] internal compiler error: in ipa_propagate_frequency, at ipa-profile.c:405

[skpgkp1 at gmail dot com]

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

Bug ID: 85421
   Summary: [8 regression] internal compiler error: in
ipa_propagate_frequency, at ipa-profile.c:405
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp1 at gmail dot com
  Target Milestone: ---

Created attachment 43952
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43952=edit
Preprocessed reproducer file.

This issue found while compiling HHVM sources. GCC 8 regressed with ICE between
04/10/2018 and 04/11/2018

ICE with 04/11/2018 compiler 

$g++ --version
g++ (GCC) 8.0.1 20180411 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$g++ -std=gnu++1y -O3   -o QCRAMCodec.cpp.o -c QCRAMCodec.cpp.i -w
during IPA pass: cp
QCRAMCodec.cpp.i:128:1: internal compiler error: in ipa_propagate_frequency, at
ipa-profile.c:405
 } // namespace bk
 ^
0x6ce400 ipa_propagate_frequency(cgraph_node*)
../../gcc-main.3V7F/gcc/ipa-profile.c:405
0xce6ca3 symbol_table::remove_unreachable_nodes(_IO_FILE*)
../../gcc-main.3V7F/gcc/ipa.c:701
0xdc7f09 execute_todo
../../gcc-main.3V7F/gcc/passes.c:2062
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Work fine with 04/10/2018 compiler.

$g++ --version
g++ (GCC) 8.0.1 20180410 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$g++ -std=gnu++1y -O3   -o QCRAMCodec.cpp.o -c QCRAMCodec.cpp.i -w
$ echo $?
0

[Bug middle-end/85420] More -Wrestrict false positives with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The #c0 testcase is always UB if the function is called, why doesn't it deserve
a warning?  Either a is initially 0, then already the first iteration invokes
UB (strcpy (b, b)) and -Wrestrict is right, or a is 1 and strcpy (b, b + 1)
invokes UB because it dereferences b[1] in the first iteration, or a is
different and and b + a invokes UB.

[Bug c++/84463] [6/7/8 Regression] Supposedly-incompliant "error: '* key0' is not a constant expression"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.5

[Bug middle-end/85420] More -Wrestrict false positives with -fsanitize=undefined

[sirl at gcc dot gnu.org]

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

--- Comment #1 from Franz Sirl  ---
Created attachment 43951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43951=edit
C++ testcase

[Bug middle-end/85420] New: More -Wrestrict false positives with -fsanitize=undefined

[sirl at gcc dot gnu.org]

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

Bug ID: 85420
   Summary: More -Wrestrict false positives with
-fsanitize=undefined
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

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

The attached testcases produce extra warnings of the "may overlap" kind with
-Wrestrict -fsanitize=undefined (PR85365 covers the "same destination" kind).

# gcc-8 -c -O2 -fsanitize=undefined -Wrestrict t5.c 
t5.c: In function 'c':
t5.c:6:5: warning: 'strcpy' accessing 1 byte at offsets 0 and [0, 1] may
overlap 1 byte at offset 0 [-Wrestrict]
 strcpy(b, b + a);
 ^~~~


g++-8 -c -O2 -fsanitize=undefined -Wrestrict t6.cpp 
t6.cpp: In member function 'int c::m_fn1()':
t6.cpp:13:9: warning: 'char* strcat(char*, const char*)' accessing 4096 or more
bytes at offsets 0 and 4095 may overlap 1 byte at offset 4095 [-Wrestrict]
   strcat(e, d.b);
   ~~^~~~

[Bug c/85419] New: Incorrect determination of null pointer constant

[terra at gnome dot org]

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

Bug ID: 85419
   Summary: Incorrect determination of null pointer constant
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

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

Priority: low


#include 

int
main (int argc,char **argv)
{
  printf ("%p\n", 0 ? (void *restrict)0 : (int *)0);
  return 0;
}



As I read C99's section 6.3.2.3, (void *restrict)0 is *not* a null pointer
constant.

I am reading section 6.5.15 as saying the ?: is valid with type
void *restrict.

%p is valid for such a pointer.

gcc disagrees:

# gcc -std=c99 -pedantic  -Wall t.c
t.c: In function ‘main’:
t.c:6:3: warning: format ‘%p’ expects argument of type ‘void *’, but argument 2
has type ‘int *’ [-Wformat=]
   printf ("%p\n", 0 ? (void *restrict)0 : (int *)0);
   ^
I.e., it thinks (void *restrict)0 is a null pointer constant.  Hence ?:
becomes an int* and %p isn't valid for that in a pedantic sense.

Removing the "restrict" clearly makes the program invalid in a pedantic
sense.  I.e., Section 6.7.3 #7 is wrong.


Details: stock OpenSuSE 42.3

[Bug c++/84463] [6/7/8 Regression] Supposedly-incompliant "error: '* key0' is not a constant expression"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c/85418] New: -Wformat-truncation on inlinned function

[Azim.Khan at arm dot com]

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

Bug ID: 85418
   Summary: -Wformat-truncation on inlinned function
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Azim.Khan at arm dot com
  Target Milestone: ---

See following code:

```
#include 

void f(const char s[5], size_t len)
{
char b[5];
snprintf(b, len, "%s", s); 
}

int main()
{
f("Hello World", 4); 
return 0;
}
```

On compiling it with -O2/3 f() gets inlinned and snprintf format checks apply
to it even though parameters to snprintf are parameters within f().

[Bug target/83660] ICE with vec_extract inside expression statement

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from acsawdey at gcc dot gnu.org ---
Fixed in 259403.

[Bug target/83660] ICE with vec_extract inside expression statement

[acsawdey at gcc dot gnu.org]

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

--- Comment #14 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Mon Apr 16 14:50:06 2018
New Revision: 259403

URL: https://gcc.gnu.org/viewcvs?rev=259403=gcc=rev
Log:
2018-04-16  Aaron Sawdey  

PR target/83660
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Mark
vec_extract expression as having side effects to make sure it gets
a cleanup point.

2018-04-16  Aaron Sawdey  

PR target/83660
* gcc.target/powerpc/pr83660.C: New test.



Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr83660.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-c.c
trunk/gcc/testsuite/ChangeLog

[Bug target/85417] Extra test failures with -fcf-protection -mcet

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-16
 CC||igor.v.tsimbalist at intel dot 
com
  Component|testsuite   |target
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Since CET is compatible with all processors with multi-byte NOPs, which
covers all 64-bit processors as well as 32-bit processors starting with
Pentium Pro, fcf-protection should be allowed on these processors.

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[hubicka at gcc dot gnu.org]

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

--- Comment #14 from Jan Hubicka  ---
Created attachment 43947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43947=edit
Proposed fix

We looked into this with Maritn todday. There are two bugs: one is the fact
that lto.c forgets to register the type in case it was within strongly
connected component after its outer type. The order depends on hash values and
is not well determined. We do not want to test TYPE_CANONICAL being non-NULL.
Martin is testing it.

Other is the fact that Eric's last change make odr types compatible when one of
them is incomplete. This is not necessarily the case. The patch should fix the
ordering issue by going the slow path in case type already in hashtable is
incomplete. In this case it won't take long to compare it with the other type
anyway.

[Bug rtl-optimization/84842] ICE in verify_target_availability, at sel-sched.c:1569

[amonakov at gcc dot gnu.org]

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

--- Comment #8 from Alexander Monakov  ---
Or as Jakub (thanks!) noted on IRC, gcc/auto-host.h from the build tree may be
also helpful and simpler for us to work with.

[Bug rtl-optimization/84842] ICE in verify_target_availability, at sel-sched.c:1569

[amonakov at gcc dot gnu.org]

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

--- Comment #7 from Alexander Monakov  ---
The testcase is not easily reproducible because the rs6000 backend has some
implicit dependencies on capabilities of configure-time binutils, and they are
not visible as 'gcc -v' flags.

So, to reproduce this we need to know the version and configure flags of cross
binutils that were found and checked by gcc's configure.

[Bug middle-end/85414] [8 Regression] ICE: in ix86_expand_prologue, at config/i386/i386.c:13810 with -Og -fgcse

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  We really should never generate subreg of subreg, period.

[Bug c++/84463] [6/7/8 Regression] Supposedly-incompliant "error: '* key0' is not a constant expression"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-16
  Known to work||5.5.0
Summary|Supposedly-incompliant  |[6/7/8 Regression]
   |"error: '* key0' is not a   |Supposedly-incompliant
   |constant expression"|"error: '* key0' is not a
   ||constant expression"
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.3.0, 8.0.1

--- Comment #2 from Jonathan Wakely  ---
Started to fail with r230365 ("Merge C++ delayed folding branch.")

[Bug tree-optimization/85416] Massive performance regression when switching on "-march=native"

[mar...@mpa-garching.mpg.de]

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

--- Comment #1 from Martin Reinecke  ---
Just re-tested on an Intel Core i5-4570; on this CPU, there is no performance
degradation.

[Bug demangler/85304] Segmentation fault

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #1 from Michael Matz  ---
Similar to https://sourceware.org/bugzilla/show_bug.cgi?id=23008,
the testcase contains a mangled name with roughly 29000 successive 'E'
characters.  Processing one 'E' character involves calling these three
routines:

5  0x004e8901 in demangle_expression (work=0x7fffd810,
mangled=0x7fffd710, 
s=0x7fffd540, tk=tk_integral) at ../../libiberty/cplus-dem.c:1895
1895  success = demangle_template_value_parm (work, mangled, s, tk);
(gdb) 
#4  0x004e98cb in demangle_template_value_parm (work=0x7fffd810,
mangled=0x7fffd710, 
s=0x7fffd540, tk=tk_integral) at ../../libiberty/cplus-dem.c:2069
2069success = demangle_integral_value (work, mangled, s);
(gdb) 
#3  0x004e8b82 in demangle_integral_value (work=0x7fffd810,
mangled=0x7fffd710, 
s=0x7fffd540) at ../../libiberty/cplus-dem.c:1916
1916success = demangle_expression (work, mangled, s, tk_integral);

That advances *mangled by one character and uses 496 bytes of stack while
doing that (when compiled by gcc-6 with address sanitizer).  The linux default
stack of 8 MB is good for 16893 of the E characters until stack overflow
occurs.
Without sanitizer we need less stack per recursion level, so that the testcase
doesn't cause a proplem (but just increasing the number of 'E' will make
it segfault there as well).

It seems all is working as designed, you request it to demangle a recursive
structure of > 2 levels deep and get what can be expected from that, a
stack
overflow.

[Bug testsuite/85417] New: Extra test failures with -fcf-protection -mcet

[hjl.tools at gmail dot com]

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

Bug ID: 85417
   Summary: Extra test failures with -fcf-protection -mcet
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---

When

RUNTESTFLAGS="--target_board='unix{-fcf-protection\ -mcet}'"

is used with "make check", there are extra test failures like:

FAIL: gcc.target/i386/mvc1.c (test for excess errors)

[hjl@gnu-4 gcc]$ /export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/mvc1.c 
-fcf-protection -mcet   -fno-diagnostics-show-caret -fdiagnostics-color=never  
 -ansi -pedantic-errors  -lm  -o ./mvc1.exe
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/mvc1.c: In
function \u2018foo.resolver\u2019:
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/mvc1.c:27:1:
error: \u2018-fcf-protection=full\u2019 requires Intel CET support. Use -mcet
or both of -mibt and -mshstk options to enable CET
[hjl@gnu-4 gcc]$ 

Since CET is applied to the whole program, we can't disable CET in
one function.

[Bug target/85414] [8 Regression] ICE: in ix86_expand_prologue, at config/i386/i386.c:13810 with -Og -fgcse

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
The problem is likely with the caching of ix86_compute_frame_layout results, at
least if I call this function at the beginning of ix86_expand_prologue, it
doesn't ICE anymore.

What changes in particular is ix86_nsaved_regs () on this testcase, during lra
-> lra_eliminate -> update_reg_eliminate it still returns 1, but during
pro_and_epilogue already 2.
The difference is in register 41.

What happens is:
1) fwprop1 adds a REG_EQUAL to the umulditi3_1 instruction:
(insn 13 12 111 3 (parallel [
(set (reg:TI 99)
(mult:TI (zero_extend:TI (subreg/s/v:DI (reg:TI 94) 0))
(zero_extend:TI (reg:DI 100
(clobber (reg:CC 17 flags))
]) "pr85414.c":5 366 {*umulditi3_1}
 (expr_list:REG_EQUAL (mult:TI (zero_extend:TI (subreg/s/v:DI (reg:TI 94)
0))
(const_int 59 [0x3b]))
(expr_list:REG_DEAD (reg:DI 100)
(expr_list:REG_DEAD (reg:TI 94)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
2) then probably based on the /s/v flags on the subreg that indicate
SUBREG_PROMOTED_VAR_P and SUBREG_PROMOTED_UNSIGNED_P, the cse_local pass
"optimizes" the REG_EQUAL note to (mult:TI (subreg:TI (subreg/s/v:DI (reg:TI
94) 0) 0) (const_int 59 [0x3b]))
That actually looks to me like invalid RTL, subreg of a subreg is not valid.
I guess it should have been just (mult:TI (reg:TI 94) (const_int 59 [0x3b])).
3) then the subreg2 pass just replaces uses of (reg:TI 94) subregs with (reg:DI
146)
4) during LRA we have (mult:TI (subreg:TI (reg:DI 40 r11 [146]) 0) (const_int
59 [0x3b])) and that refers to the r12 too, but nothing earlier recognized it
as used (nor it is actually used in the insn).

[Bug middle-end/85403] internal compiler error: ... config/i386/i386.c:32347

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed.

[Bug lto/85405] [6/7 Regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1581

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed|2018-04-15 00:00:00 |2018-04-16
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I've got patch for that.

[Bug tree-optimization/85416] New: Massive performance regression when switching on "-march=native"

[mar...@mpa-garching.mpg.de]

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

Bug ID: 85416
   Summary: Massive performance regression when switching on
"-march=native"
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 43945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43945=edit
Test case

When compiling the attached test case with

g++ -O3 -std=c++14 testcase.cc

and measuring the runtime via

time ./a.out

I get a CPU time of roughly 1.3 seconds

Recompiling with

g++ -O3 -std=c++14 -march=native testcase.cc

increases run time to over 8 seconds.

CPU: Intel Core i5-5300U

This was measured on trunk (gcc version 8.0.1 20180411), but I see similar
performance degradations already in gcc 5.4.

[Bug lto/85391] [8 Regression] ICE in add_type_duplicate, at ipa-devirt.c:1887

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug middle-end/85403] internal compiler error: ... config/i386/i386.c:32347

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Apr 16 11:31:22 2018
New Revision: 259400

URL: https://gcc.gnu.org/viewcvs?rev=259400=gcc=rev
Log:
i386: Check error_mark_node in multiversioning

Since CET is applied to the whole program, it is correct to disallow
-fcf-protection=full without -mcet.  But compiler shouldn't crash.

gcc/

PR target/85403
* config/i386/i386.c (get_builtin_code_for_version): Check
error_mark_node.

gcc/testsuite/

PR target/85403
* gcc.target/i386/pr85403.c: New test.
---
 gcc/config/i386/i386.c|  2 ++
 gcc/testsuite/g++.dg/ext/mv1.C|  2 +-
 gcc/testsuite/g++.dg/ext/mv14.C   |  2 +-
 gcc/testsuite/g++.dg/ext/mv15.C   |  2 +-
 gcc/testsuite/g++.dg/ext/mv16.C   |  2 +-
 gcc/testsuite/g++.dg/ext/mv17.C   |  2 +-
 gcc/testsuite/g++.dg/ext/mv18.C   |  2 +-
 gcc/testsuite/g++.dg/ext/mv19.C   |  2 +-
 gcc/testsuite/g++.dg/ext/mv20.C   |  2 +-
 gcc/testsuite/g++.dg/ext/mv21.C   |  2 +-
 gcc/testsuite/g++.dg/ext/mv22.C   |  2 +-
 gcc/testsuite/g++.dg/ext/mv23.C   |  2 +-
 gcc/testsuite/g++.dg/ext/mv26.C   |  1 +
 gcc/testsuite/g++.dg/ext/mv6.C|  2 +-
 gcc/testsuite/g++.dg/ext/mvc1.C   |  1 +
 gcc/testsuite/gcc.target/i386/cet-notrack-icf-1.c |  2 +-
 gcc/testsuite/gcc.target/i386/cet-notrack-icf-3.c |  2 +-
 gcc/testsuite/gcc.target/i386/cet-property-2.c|  2 +-
 gcc/testsuite/gcc.target/i386/mvc1.c  |  1 +
 gcc/testsuite/gcc.target/i386/mvc10.c |  1 +
 gcc/testsuite/gcc.target/i386/mvc11.c |  2 +-
 gcc/testsuite/gcc.target/i386/mvc6.c  |  2 +-
 gcc/testsuite/gcc.target/i386/mvc7.c  |  1 +
 gcc/testsuite/gcc.target/i386/mvc8.c  |  2 +-
 gcc/testsuite/gcc.target/i386/mvc9.c  |  2 +-
 gcc/testsuite/gcc.target/i386/pr81213.c   |  1 +
 gcc/testsuite/gcc.target/i386/pr81214.c   |  1 +
 gcc/testsuite/gcc.target/i386/pr85403.c   | 10 ++
 gcc/testsuite/gcc.target/i386/sse-26.c|  2 +-
 29 files changed, 39 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr85403.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6fa5b0add02..8a73fc0d316 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -32344,6 +32344,8 @@ get_builtin_code_for_version (tree decl, tree
*predicate_list)
  _options_set);

   gcc_assert (target_node);
+  if (target_node == error_mark_node)
+   return 0;
   new_target = TREE_TARGET_OPTION (target_node);
   gcc_assert (new_target);

diff --git a/gcc/testsuite/gcc.target/i386/pr85403.c
b/gcc/testsuite/gcc.target/i386/pr85403.c
new file mode 100644
index 000..f4fb12dd4e2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr85403.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-fcf-protection -mcet" } */
+/* { dg-require-ifunc "" } */
+
+__attribute__((target_clones("avx","arch=slm","arch=core-avx2","default")))
+int
+foo ()
+{
+  return -2;
+} /* { dg-error "requires Intel CET support" } */

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

[Bug c++/85415] New: internal compiler error: in finish_member_declaration, at cp/semantics.c:2984

[frederik.engels24 at gmail dot com]

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

Bug ID: 85415
   Summary: internal compiler error: in finish_member_declaration,
at cp/semantics.c:2984
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederik.engels24 at gmail dot com
  Target Milestone: ---

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

Not sure if this is similar to #82722.
Seems to happen when trying to use fold expressions, but the same thing
occurred when I used std::make_tuple to execute over all tuple members.
The same code compiles in clang 6.0.0 and MSVC

Here is the full output, with the testcase as an attachment

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.3.1 20180312 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-save-temps' '-std=c++1z' '-o'
'testcase' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/cc1plus -E -quiet -v -D_GNU_SOURCE
testcase.cpp -mtune=generic -march=x86-64 -std=c++1z -Wall -Wextra
-fpch-preprocess -o testcase.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1

/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-save-temps' '-std=c++1z' '-o'
'testcase' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/cc1plus -fpreprocessed testcase.ii
-quiet -dumpbase testcase.cpp -mtune=generic -march=x86-64 -auxbase testcase
-Wall -Wextra -std=c++1z -version -o testcase.s
GNU C++14 (GCC) version 7.3.1 20180312 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.3.1 20180312 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3fb60f63f2e4dccab1b015b716b8b627
testcase.cpp: In instantiation of
‘tuple_vector::clear_all():: [with auto:1 =
{std::vector, std::vector, std::vector}; Ts = {int, bool, double}]’:
/usr/include/c++/7.3.1/type_traits:2428:26:   required by substitution of
‘template static std::__result_of_success()((declval<_Args>)()...)), std::__invoke_other>
std::__result_of_other_impl::_S_test(int) [with _Fn =
tuple_vector::clear_all() [with Ts = {int, bool, double}]::; _Args = {std::vector&, std::vector&, std::vector&}]’
/usr/include/c++/7.3.1/type_traits:2439:55:   required from ‘struct
std::__result_of_impl, std::vector&, std::vector&,
std::vector&>’
/usr/include/c++/7.3.1/type_traits:2444:12:   required from ‘struct
std::__invoke_result, std::vector&,
std::vector&, std::vector&>’
/usr/include/c++/7.3.1/bits/invoke.h:89:5:   required by substitution of
‘template constexpr typename
std::__invoke_result<_Functor, _ArgTypes>::type 

[Bug ipa/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Liška  ---
I worked on that with Honza and we have proper fix. Let me test.

[Bug target/84331] Execution failures on Skylake server with -march=native

[jkoval at gcc dot gnu.org]

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

--- Comment #1 from Julia Koval  ---
Author: jkoval
Date: Mon Apr 16 11:23:55 2018
New Revision: 259399

URL: https://gcc.gnu.org/viewcvs?rev=259399=gcc=rev
Log:
Fixed g++.dg/ext/mv16.C with -march=native.

gcc/
PR target/84331
* gcc/config.gcc: Support "skylake".
* gcc/config/i386/i386-c.c (ix86_target_macros_internal): Handle
PROCESSOR_SKYLAKE.
* gcc/config/i386/i386.c (m_SKYLAKE): Define.
(processor_target_table): Add "skylake".
(ix86_option_override_internal): Add "skylake".
(get_builtin_code_for_version): Handle PROCESSOR_SKYLAKE,
PROCESSOR_CANNONLAKE.
(get_builtin_code_for_version): Fix priority for
PROCESSOR_ICELAKE_CLIENT, PROCESSOR_ICELAKE_SERVER,
PROCESSOR_SKYLAKE-AVX512.
* gcc/config/i386/i386.h (processor_costs): Define TARGET_SKYLAKE.
(processor_type): Add PROCESSOR_SKYLAKE.

gcc/testsuite/
PR target/84331
* gcc/testsuite/gcc.target/i386/funcspec-56.inc: Test arch=skylake.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc
trunk/gcc/config/i386/i386-c.c
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/funcspec-56.inc

[Bug target/84945] [8 Regression] UBSAN: gcc/config/i386/i386.c:33312:22: runtime error: shift exponent 32 is too large for 32-bit type 'int'

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Mon Apr 16 11:22:40 2018
New Revision: 259398

URL: https://gcc.gnu.org/viewcvs?rev=259398=gcc=rev
Log:
PR target/84945
* config/i386/cpuinfo.c (set_feature): Wrap into do while (0) to avoid
-Wdangling-else warnings.  Mask shift counts to avoid
-Wshift-count-negative and -Wshift-count-overflow false positives.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/i386/cpuinfo.c

[Bug target/85414] [8 Regression] ICE: in ix86_expand_prologue, at config/i386/i386.c:13810 with -Og -fgcse

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-16
 CC||edlinger at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

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

[Bug target/85414] New: [8 Regression] ICE: in ix86_expand_prologue, at config/i386/i386.c:13810 with -Og -fgcse

[zsojka at seznam dot cz]

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

Bug ID: 85414
   Summary: [8 Regression] ICE: in ix86_expand_prologue, at
config/i386/i386.c:13810 with -Og -fgcse
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Og -fgcse testcase.c
during RTL pass: pro_and_epilogue
testcase.c: In function 'foo':
testcase.c:6:1: internal compiler error: in ix86_expand_prologue, at
config/i386/i386.c:13810
 }
 ^
0x10fdb4b ix86_expand_prologue()
/repo/gcc-trunk/gcc/config/i386/i386.c:13810
0x13b584a gen_prologue()
/repo/gcc-trunk/gcc/config/i386/i386.md:13246
0x10d65d8 target_gen_prologue
/repo/gcc-trunk/gcc/config/i386/i386.md:19662
0xa0b127 make_prologue_seq
/repo/gcc-trunk/gcc/function.c:5926
0xa0b2c4 thread_prologue_and_epilogue_insns()
/repo/gcc-trunk/gcc/function.c:6043
0xa0be22 rest_of_handle_thread_prologue_and_epilogue
/repo/gcc-trunk/gcc/function.c:6534
0xa0be22 execute
/repo/gcc-trunk/gcc/function.c:6576
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


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

[Bug libgomp/85129] [openacc] Document GOMP_OPENACC_DIM

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> I. trunk
> 
> The GOMP_OPENACC_DIM environment variable is not documented (it should have
> an entry in libgomp.texi at 'OpenACC Environment Variables').

Atm, in trunk, fopenacc-dim does not yet support the '-' syntax, so the only
dimension that GOMP_OPENACC_DIM can influence is gang.

It probably doesn't make any sense to document GOMP_OPENACC_DIM until it's
fully functioning.

[Bug rtl-optimization/85412] [8 Regression] ICE in put_TImodes, at sel-sched.c:7191

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||abel at gcc dot gnu.org,
   ||amonakov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce in my bisect seed, so can't bisect.  Can reproduce with current
trunk though.
7188  clock = INSN_SCHED_CYCLE (insn);
7189  cost = (last_clock == -1) ? 1 : clock - last_clock;
7190
7191  gcc_assert (cost >= 0);

clock is 0, last_clock is 37, so cost is -37.
Though, s_i_d array has just length of 52 and insn here (created by
#1  0x00acef21 in emit_insn (x=0x7fffefdfef40) at
../../gcc/emit-rtl.c:5116
#2  0x00f56d77 in create_insn_rtx_from_pattern (pattern=0x7fffefdfef40,
label=0x0) at ../../gcc/sel-sched-ir.c:5753
#3  0x00f56f09 in create_copy_of_insn_rtx (insn_rtx=0x7fffefc58ec0) at
../../gcc/sel-sched-ir.c:5798
#4  0x00f686b1 in emit_bookkeeping_insn
(place_to_insert=0x7fffefe070c0, c_expr=0x7fffd8c0, new_seqno=100)
at ../../gcc/sel-sched.c:4768
#5  0x00f6881e in generate_bookkeeping_insn (c_expr=0x7fffd8c0,
e1= 4)>, e2= 4)>)
at ../../gcc/sel-sched.c:4805
#6  0x00f6b58b in move_op_at_first_insn (insn=0x7fffefdf88c0,
lparams=0x7fffd440, static_params=0x7fffd7e0)
at ../../gcc/sel-sched.c:6077
#7  0x00f6c2b2 in code_motion_path_driver (insn=0x7fffefdf88c0,
orig_ops=0x0, path=0x2d193d0, local_params_in=0x7fffd440, 
static_params=0x7fffd7e0) at ../../gcc/sel-sched.c:6669
#8  0x00f6bad6 in code_motion_process_successors (insn=0x7fffefdebe58,
orig_ops=0x2d19f88, path=0x2d193d0, static_params=0x7fffd7e0)
at ../../gcc/sel-sched.c:6356
#9  0x00f6c199 in code_motion_path_driver (insn=0x7fffefdebe58,
orig_ops=0x2d19f88, path=0x2d193d0, local_params_in=0x7fffd630, 
static_params=0x7fffd7e0) at ../../gcc/sel-sched.c:6622
#10 0x00f6bad6 in code_motion_process_successors (insn=0x7fffefdebea0,
orig_ops=0x2d1b4a0, path=0x2d1bb30, static_params=0x7fffd7e0)
at ../../gcc/sel-sched.c:6356
#11 0x00f6c199 in code_motion_path_driver (insn=0x7fffefdebea0,
orig_ops=0x2d1b4a0, path=0x2d1bb30, local_params_in=0x7fffd7b0, 
static_params=0x7fffd7e0) at ../../gcc/sel-sched.c:6622
#12 0x00f6c3af in move_op (insn=0x7fffefc58bc0, orig_ops=0x2d1b860,
expr_vliw=0x2d1bef8, dest=0x0, c_expr=0x7fffd8c0, 
should_move=0x7fffd89a) at ../../gcc/sel-sched.c:6714
#13 0x00f696eb in move_exprs_to_boundary (bnd=0x2d19360,
expr_vliw=0x2d1bef8, expr_seq=0x2d1b860, c_expr=0x7fffd8c0)
at ../../gcc/sel-sched.c:5237
#14 0x00f6a24b in schedule_expr_on_boundary (bnd=0x2d19360,
expr_vliw=0x2d1bef8, seqno=-13) at ../../gcc/sel-sched.c:5450
#15 0x00f6a6ec in fill_insns (fence=0x2d1b598, seqno=-13,
scheduled_insns_tailpp=0x7fffda90) at ../../gcc/sel-sched.c:5592
#16 0x00f6dbbd in schedule_on_fences (fences=0x2d1a2d0, max_seqno=32,
scheduled_insns_tailpp=0x7fffda90) at ../../gcc/sel-sched.c:7366
#17 0x00f6e0ae in sel_sched_region_2 (orig_max_seqno=34) at
../../gcc/sel-sched.c:7504
#18 0x00f6e22d in sel_sched_region_1 () at ../../gcc/sel-sched.c:7546
#19 0x00f6e683 in sel_sched_region (rgn=0) at
../../gcc/sel-sched.c:7647

has INSN_LUID 0.

[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  ---
Nope. Something deeper. The new testcase would be accepted but the declaration
of the int variable 'e' would not be usable, would be ignored.

[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  ---
In fact, if I slightly tweak the testcase to avoid the error by defining 'e' we
would ICE again, because binding->type is found null without a preceding
diagnostic. Thus I wonder if my patchlet in Comment 7 is actually correct or is
papering over a deeper issue?!?

struct c {
  ~c();
} b;

void f() {
  try {
d:
;
  } catch (int) {
  }

  decltype(b) a;
  int e;
  struct e { } f;
}

[Bug libgomp/85411] [openacc] Move GOMP_OPENACC_DIM parsing out of nvptx plugin

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00747.html

[Bug rtl-optimization/85408] ICE in patch_jump_insn, at cfgrtl.c:1271

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
This is a complete mess.
bb-reorder.c has fix_crossing_unconditional_branches for targets that don't
define HAS_LONG_UNCOND_BRANCHES to true.
One thing which isn't clear is if it is right that these branches have
JUMP_LABEL attached to them.  If not, then e.g.
--- gcc/bb-reorder.c.jj 2018-04-13 21:49:36.0 +0200
+++ gcc/bb-reorder.c2018-04-16 11:18:33.328681163 +0200
@@ -2178,7 +2178,7 @@ fix_crossing_unconditional_branches (voi

  label = JUMP_LABEL (last_insn);
  label_addr = gen_rtx_LABEL_REF (Pmode, label);
- LABEL_NUSES (label) += 1;
+ LABEL_NUSES (label)++;

  /* Get a register to use for the indirect jump.  */

@@ -2187,7 +2187,8 @@ fix_crossing_unconditional_branches (voi
  /* Generate indirect the jump sequence.  */

  start_sequence ();
- emit_move_insn (new_reg, label_addr);
+ rtx_insn *last = emit_move_insn (new_reg, label_addr);
+ add_reg_note (last, REG_LABEL_OPERAND, label);
  emit_indirect_jump (new_reg);
  indirect_jump_sequence = get_insns ();
  end_sequence ();
@@ -2210,9 +2211,6 @@ fix_crossing_unconditional_branches (voi
  emit_insn_before (indirect_jump_sequence, last_insn);
  delete_insn (last_insn);

- JUMP_LABEL (jump_insn) = label;
- LABEL_NUSES (label)++;
-
  /* Make BB_END for cur_bb be the jump instruction (NOT the
 barrier instruction at the end of the sequence...).  */

fixes this ICE.  Another thing is that these indirect jumps are shortly
afterwards "optimized" into direct jumps anyway, even without the above patch
with the same testcase e.g. without -fmodulo-sched option, with the patch even
with that option.  The thing is, with hot/cold partitioning we don't really
know how far from each other the hot and cold partitions will be.  On PowerPC
the direct branch is I think 26-bit (with bottom two bits assumed to be 0 and
reused for some flags) and thus considered insufficient.  x86_64 in the default
model has both conditional and unconditinal jumps with signed 32-bit immediates
and thus considered ok.

So, no matter whether we emit the JUMP_LABEL or not on the indirect jump, we
should also make sure we don't turn those indirect jumps into direct jumps if
they are crossing and !HAVE_LONG_UNCOND_BRANCH.

Lastly, HAVE_LONG_UNCOND_BRANCH true is probably not ok for x86_64
-mcmodel=large.

Honza, thoughts on this?

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

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

--- Comment #7 from avieira at gcc dot gnu.org ---
Bootstrap and regression testing looks good. Ill put the patch up on the ML
when we enter stage 1 again.

[Bug bootstrap/85413] New: "./configure --with-build-config=bootstrap-lto " != "BOOT_CFLAGS +=-flto "

[dilyan.palauzov at aegee dot org]

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

Bug ID: 85413
   Summary: "./configure --with-build-config=bootstrap-lto " !=
"BOOT_CFLAGS +=-flto "
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/doc/install.texi;h=64ad2445a335f270200e359812bc9d2213bd2405;hb=HEAD#l2457
says:

./configure --with-build-config=bootstrap-lto is the same as adding -flto to
BOOT_CFLAGS, but providing that config/bootstrap-lto.mk contains more code than
just adding -flto, this seems not to be correct.  Moreover the text in
gcc/doc/instal.texi concerning the equivalence originates from 2010, but
config/bootstrap-lto.ml was last modified in 2014.  In 2010 bootstrap-lto.m4
indeed only added -flto, not it appends also =jobserver.

[Bug rtl-optimization/85412] New: [8 Regression] ICE in put_TImodes, at sel-sched.c:7191

[asolokha at gmx dot com]

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

Bug ID: 85412
   Summary: [8 Regression] ICE in put_TImodes, at sel-sched.c:7191
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-8.0.0-alpha20180415 snapshot (r259389) ICEs when compiling the following
snippet w/ -march=haswell -O2 (-O3) -fselective-scheduling2
-fsel-sched-pipelining -fno-tree-ch -fno-tree-loop-im:

int n7;

int
rf (double as, long int u1, int sp, int fy)
{
  int ku = 0, us = 1, lo = sp;

  while (fy < 1)
{
  const long int pg = 5;
  const unsigned int g5 = 3;

  ku = as + us;

  if (fy == 0)
n7 /= u1;
  else
{
  const long long unsigned int w7 = 3;

  us = 0;
  as = u1 / w7 + u1;
}

  fy = sp % pg + n7 / g5;
}

  if (ku < 1)
lo = u1;

  return lo;
}

% x86_64-pc-linux-gnu-gcc-8.0.0-alpha20180415 -march=haswell -O2
-fselective-scheduling2 -fsel-sched-pipelining -fno-tree-ch -fno-tree-loop-im
-c t4byfoly.c
during RTL pass: sched2
t4byfoly.c: In function 'rf':
t4byfoly.c:32:1: internal compiler error: in put_TImodes, at sel-sched.c:7191
 }
 ^
0x64f37b put_TImodes
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7191
0x64f37b sel_region_target_finish
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7238
0x64f37b sel_region_finish
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7289
0x64f37b sel_sched_region(int)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7658
0xc6ef38 run_selective_scheduling()
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sel-sched.c:7733
0xc4e9a5 rest_of_handle_sched2
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sched-rgn.c:3732
0xc4e9a5 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180415/work/gcc-8-20180415/gcc/sched-rgn.c:3876

I've been hitting it for a while but am filing a PR only now, when many
selective scheduling fixes have actually started landing on the trunk.

[Bug libgomp/85129] [openacc] Document GOMP_OPENACC_DIM

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #3)
> (In reply to Tom de Vries from comment #2)
> > GOMP_OPENACC_DIM seems to be the odd one here, and we should document
> > the non-standard behaviour that it supports being set in main using setenv.
> 
> Amongst other things, in
>  I
> wondered whether "GOMP_OPENACC_DIM parsing conceptually belongs into generic
> libgomp code, instead of the nvptx plugin.  (But [...] currently, the nvptx
> plugin is the only one supporting/using it.)".
> 

Ack. Filed PR85411 - "[openacc] Move GOMP_OPENACC_DIM parsing out of nvptx
plugin"

[Bug libgomp/85411] New: [openacc] Move GOMP_OPENACC_DIM parsing out of nvptx plugin

[vries at gcc dot gnu.org]

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

Bug ID: 85411
   Summary: [openacc] Move GOMP_OPENACC_DIM parsing out of nvptx
plugin
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

As mentioned here ( https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01020.html ):
...
the GOMP_OPENACC_DIM parsing conceptually belongs into generic libgomp code,
instead of the nvptx plugin.  (But that aspect can be cleaned up later:
currently, the nvptx plugin is the only one supporting/using it.)
...

[ And re-iterated here: PR85129 comment 3 ]

[Bug c++/85112] [8 Regression] ICE with invalid constexpr

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Fixed.