[Bug tree-optimization/84057] [8 Regression] ICE: Segmentation fault (in can_remove_branch_p)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-26
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with Richi's r253149.

[Bug middle-end/84048] [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-26
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Eric Botcazou  ---
Did you upgrade binutils?  We had the same failures on SPARC, see PR ld/22727.

[Bug libstdc++/84056] map insertes a pair when check a value

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Where is the bug? Did you read the documentation for operator[]?

[Bug tree-optimization/84057] New: [8 Regression] ICE: Segmentation fault (in can_remove_branch_p)

[asolokha at gmx dot com]

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

Bug ID: 84057
   Summary: [8 Regression] ICE: Segmentation fault (in
can_remove_branch_p)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20180121 snapshot (r256935) ICEs when compiling the following
snippet w/ -O2 -fgraphite -funroll-loops -fno-tree-ccp -fno-tree-dce:

int ue;

void
fr (int ct)
{
  int au = 0;
  int *ra = 

  while (au < 1)
{
  au -= 0x7878788;
  if (au != ct && ue != 0)
{
  while (au < 1)
{
}

 fc:
  while (ct != 0)
{
}
}
}

  for (au = 0; au < 2; ++au)
if (ct != 0)
  goto fc;
}

% gcc-8.0.0-alpha20180121 -O2 -fgraphite -funroll-loops -fno-tree-ccp
-fno-tree-dce -c imaaek0k.c
during GIMPLE pass: cunroll
imaaek0k.c: In function 'fr':
imaaek0k.c:4:1: internal compiler error: Segmentation fault
 fr (int ct)
 ^~
0xc969ef crash_signal
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/toplev.c:325
0x8829e3 can_remove_branch_p(edge_def const*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/cfghooks.c:389
0x891683 remove_path(edge_def*, bool*, bitmap_head*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/cfgloopmanip.c:315
0xdd4b03 unloop_loops
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-ssa-loop-ivcanon.c:668
0xdd7f01 unloop_loops
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-ssa-loop-ivcanon.c:1450
0xdd7f01 tree_unroll_loops_completely
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-ssa-loop-ivcanon.c:1450
0xdd83b4 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/tree-ssa-loop-ivcanon.c:1599

[Bug c++/84056] map insertes a pair when check a value

[alper.ccc at yandex dot com]

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

--- Comment #1 from Alper Ce  ---
output:

a => 1
b => 2
Map after if condition(a new pair ['c':0] inserted in map!):
a => 1
b => 2
c => 0

[Bug c++/84056] New: map insertes a pair when check a value

[alper.ccc at yandex dot com]

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

Bug ID: 84056
   Summary: map insertes a pair when check a value
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alper.ccc at yandex dot com
  Target Milestone: ---

In this example there is a map with 2 pairs ( a:1 and b:2)
but after checking the unavailable vale in if statement (value of c) it inserts
new pair (c:0) to the map:


#include 
#include 
using namespace std;
int main ()
{
  map my_map;
  my_map['a'] = 1;
  my_map['b'] = 2;

  for (map::iterator it=my_map.begin(); it!=my_map.end(); ++it)
cout << it->first << " => " << it->second << endl;

  if(my_map['c'] == 100)
  cout<<"my_map['c'] = 100"<::iterator it=my_map.begin(); it!=my_map.end(); ++it)
cout << it->first << " => " << it->second << endl;

  return 0;
}

[Bug c/84052] Using Randomizing structure layout plugin in linux kernel compilation doesn't generate proper debuginfo

[caoj.fnst at cn dot fujitsu.com]

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

--- Comment #2 from pino  ---
(In reply to Andrew Pinski from comment #1)
> Plugins issues like this should reported to the plugin author and not to gcc.

I don't know gcc internals, from my very limited understanding about gcc & that
plugin, the plugin just does one optimization on the intermediate language:
redefine a structure with randomized order and set it back to its context. So
the backend would see a structure different from its original definition in
source file and could generate the proper debuginfo.   So I feels this issue
may be more close to gcc.

I was not sure where should I report this problem. I was hoping gcc guys could
take a look at that plugin, I feel it is not hard for you gcc expert to read,
even I can tell the basic logic inside.

[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

[kip at thevertigo dot com]

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

--- Comment #2 from Kip Warner  ---
Created attachment 43250
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43250=edit
Assembly listing of minimal.cpp

[Bug c++/84055] warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

[kip at thevertigo dot com]

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

--- Comment #1 from Kip Warner  ---
Created attachment 43249
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43249=edit
Pre-processed intermediate form of minimal.cpp

[Bug c++/84055] New: warning: ignoring attributes on template argument ‘cl_uint {aka unsigned int}’ [-Wignored-attributes]

[kip at thevertigo dot com]

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

Bug ID: 84055
   Summary: warning: ignoring attributes on template argument
‘cl_uint {aka unsigned int}’ [-Wignored-attributes]
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kip at thevertigo dot com
  Target Milestone: ---

Created attachment 43248
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43248=edit
Minimal example to reproduce the problem.

The following minimal requires an OpenCL C++ installation. Manually typedef'ing
cl_uint makes the problem go away, but for some reason using the OpenCL
header's version, I see the following error:

$ g++ minimal.cpp -o minimal `pkg-config --cflags --libs OpenCL`
minimal.cpp:13:28: warning: ignoring attributes on template argument ‘cl_uint
{aka unsigned int}’ [-Wignored-attributes]
 std::vector m_BreakMe;
^

$ g++ --version
g++ (Ubuntu 7.2.0-8ubuntu3) 7.2.0
Copyright (C) 2017 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.

[Bug c/84054] New: seems -fno-bounds-checking no longer supported

[sbansal at ciena dot com]

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

Bug ID: 84054
   Summary: seems -fno-bounds-checking no longer supported
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbansal at ciena dot com
  Target Milestone: ---

Hi,

We are migrating from 3.4.5 to 4.8.1 compiler and some of our code is using 
"-fno-bounds-checking" option to avoid doing bounds check on a special piece of
code.

This was working good in 3.4.5 but it seems not supported on 4.8.1 giving
compilation error.

Please suggest any possible resolution.

Regards,
Sumit

[Bug testsuite/83881] FAIL: c-c++-common/Wrestrict.c -std=gnu++98 (test for excess errors)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-26
  Component|c   |testsuite
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
With the top of the trunk the test passes for me with an hppa-unknown-linux-gnu
cross-compiler (both C and C++) with the following results:

Running /ssd/src/gcc/git/gcc/testsuite/g++.dg/dg.exp ...

=== g++ Summary ===

# of expected passes465
# of expected failures  18
/ssd/build/hppa-unknown-linux-gnu/gcc-git/gcc/xg++  version 8.0.1 20180125
(experimental) (GCC) 

Can you please try again and update the bug with your latest results?

[Bug c++/83911] [6/7/8 Regression] ICE with target attribute on constructor in gimplify_expr at gimplify.c:11321

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.4
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-01-26
 CC||msebor at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE with target attribute   |[6/7/8 Regression] ICE with
   |on constructor in   |target attribute on
   |gimplify_expr at|constructor in
   |gimplify.c:11321|gimplify_expr at
   ||gimplify.c:11321
  Known to fail||5.4.0, 6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed with GCC 5, 6, 7, and 8.  Bisection points to Richard's r210692
committed in gcc 4.10 (5.0).

GCC 8 abends with the following output:

gcc -O2 -S -Wall -Wextra pr83911.C
pr83911.C: In constructor ‘SimdFloat::SimdFloat(float)’:
pr83911.C:5:21: warning: unused parameter ‘x’ [-Wunused-parameter]
 SimdFloat(float x) {}
   ~~^
pr83911.C: In constructor ‘SimdFloat::SimdFloat(float)’:
pr83911.C:8:21: warning: unused parameter ‘x’ [-Wunused-parameter]
 SimdFloat(float x) {}
   ~~^
pr83911.C: In function ‘SimdFloat foo()’:
pr83911.C:13:12: internal compiler error: in
ix86_get_function_versions_dispatcher, at config/i386/i386.c:32432
 return 1;
^
0x13f2168 ix86_get_function_versions_dispatcher
/ssd/src/gcc/svn/gcc/config/i386/i386.c:32432
0x7e5a3c get_function_version_dispatcher(tree_node*)
/ssd/src/gcc/svn/gcc/cp/call.c:7479
0x7e7b1c build_over_call
/ssd/src/gcc/svn/gcc/cp/call.c:8191
0x7e3af0 convert_like_real
/ssd/src/gcc/svn/gcc/cp/call.c:6783
0x7e42c6 convert_like_real
/ssd/src/gcc/svn/gcc/cp/call.c:6909
0x7ee318 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
/ssd/src/gcc/svn/gcc/cp/call.c:10574
0x9b6b5c convert_for_initialization(tree_node*, tree_node*, tree_node*, int,
impl_conv_rhs, tree_node*, int, int)
/ssd/src/gcc/svn/gcc/cp/typeck.c:8982
0x9b7bd4 check_return_expr(tree_node*, bool*)
/ssd/src/gcc/svn/gcc/cp/typeck.c:9372
0x97004f finish_return_stmt(tree_node*)
/ssd/src/gcc/svn/gcc/cp/semantics.c:890
0x8def99 cp_parser_jump_statement
/ssd/src/gcc/svn/gcc/cp/parser.c:12368
0x8dbf5c cp_parser_statement
/ssd/src/gcc/svn/gcc/cp/parser.c:10773
0x8dcbe1 cp_parser_statement_seq_opt
/ssd/src/gcc/svn/gcc/cp/parser.c:11218
0x8dcad7 cp_parser_compound_statement
/ssd/src/gcc/svn/gcc/cp/parser.c:11172
0x8ee1dd cp_parser_function_body
/ssd/src/gcc/svn/gcc/cp/parser.c:21712
0x8ee2e8 cp_parser_ctor_initializer_opt_and_function_body
/ssd/src/gcc/svn/gcc/cp/parser.c:21747
0x8f6245 cp_parser_function_definition_after_declarator
/ssd/src/gcc/svn/gcc/cp/parser.c:26648
0x8f606b cp_parser_function_definition_from_specifiers_and_declarator
/ssd/src/gcc/svn/gcc/cp/parser.c:26565
0x8ea718 cp_parser_init_declarator
/ssd/src/gcc/svn/gcc/cp/parser.c:19436
0x8e02b3 cp_parser_simple_declaration
/ssd/src/gcc/svn/gcc/cp/parser.c:13009
0x8dfe48 cp_parser_block_declaration
/ssd/src/gcc/svn/gcc/cp/parser.c:12827
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
tmp$

[Bug c/84052] Using Randomizing structure layout plugin in linux kernel compilation doesn't generate proper debuginfo

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Plugins issues like this should reported to the plugin author and not to gcc.

[Bug tree-optimization/84053] [5//6/7 Regression] missing -Warray-bounds accessing a struct array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
  Known to work||4.6.3
Summary|missing -Warray-bounds  |[5//6/7 Regression] missing
   |accessing a struct array|-Warray-bounds accessing a
   |member  |struct array member
  Known to fail||4.7.4, 4.8.4, 4.9.4, 5.5.0,
   ||6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Bisection points to r178312 committed in GCC 4.7 as the change that introduced
this regression:

r178312 | rguenth | 2011-08-30 10:06:00 -0400 (Tue, 30 Aug 2011) | 30 lines

2011-08-30  Richard Guenther  

PR middle-end/48571

[Bug tree-optimization/84053] New: missing -Warray-bounds accessing a struct array member

[msebor at gcc dot gnu.org]

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

Bug ID: 84053
   Summary: missing -Warray-bounds accessing a struct array member
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Prior to version 4.7, GCC would diagnose out-of-bounds accesses to local arrays
across inlined function boundaries.  The test case below shows that these
invalid accesses are no longer diagnosed.

int f (int i)
{
  int a[] = { 1, 2 };

  if (i < 3)
i = 3;

  return a[i];   // -Warray-bounds (good)
}

int g (const int *p, int i)
{
  return p[i];
}

int h (int i)
{
  int a[] = { 2, 3 };

  if (i < 3)
i = 3;

  return g (a, i);   // missing -Warray-bounds
}
t.c: In function ‘f’:
t.c:8:11: warning: array subscript 3 is above array bounds of ‘int[2]’
[-Warray-bounds]
   return a[i];   // -Warray-bounds (good)
  ~^~~

[Bug c/84052] New: Using Randomizing structure layout plugin in linux kernel compilation doesn't generate proper debuginfo

[caoj.fnst at cn dot fujitsu.com]

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

Bug ID: 84052
   Summary: Using Randomizing structure layout plugin in linux
kernel compilation doesn't generate proper debuginfo
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: caoj.fnst at cn dot fujitsu.com
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)

Recently, linux kernel introduced a security feature[*] to randomize the layout
of some crucial structures during compilation.

[*]https://lwn.net/Articles/722293/

FYI: the plugin related source files locate:

scripts/gcc-plugins/Makefile
scripts/gcc-plugins/gen-random-seed.sh
scripts/gcc-plugins/randomize_layout_plugin.c

of linux kernel source.

After enable/disable this feature, I use "gdb vmlinux" to examine the
debuginfo, and find that the output of "ptype struct xxx"(xxx is the randomized
structure like uts_namespace) in both condition are identical, which feels like
a bug to me. And this result would affect other utility like crash tool.

[Bug tree-optimization/84051] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds access via an array pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
  Known to work||4.5.4
Summary|missing -Warray-bounds on   |[6/7/8 Regression] missing
   |an out-of-bounds access via |-Warray-bounds on an
   |an array pointer|out-of-bounds access via an
   ||array pointer
  Known to fail||4.6.4, 4.7.4, 4.8.4, 4.9.4,
   ||5.5.0, 6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Bisection points to either r158060 or r158060, both committed into GCC 4.6. 
The latter seems like the more likely culprit:

2010-04-07  Richard Guenther  

PR tree-optimization/43270
* tree-vrp.c (check_array_ref): Fix flexible array member
detection.
* tree-ssa-sccvn.h (fully_constant_vn_reference_p): Declare.
* tree-ssa-pre.c (phi_translate_1): Adjust.
(fully_constant_expression): Split out vn_reference handling to ...
* tree-ssa-sccvn.c (fully_constant_vn_reference_p): ... here.
Fold reads from constant strings.
(vn_reference_lookup): Handle fully constant references.
(vn_reference_lookup_pieces): Likewise.
* Makefile.in (expmed.o-warn): Add -Wno-error.

[Bug tree-optimization/84051] New: missing -Warray-bounds on an out-of-bounds access via an array pointer

[msebor at gcc dot gnu.org]

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

Bug ID: 84051
   Summary: missing -Warray-bounds on an out-of-bounds access via
an array pointer
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC used to diagnose out-of-bounds accesses made by pointers to arrays of a
fixed bound.  The test case below shows it can no longer do that.   Clang and
ICC bot detect this bug.

typedef int A4[4];

int f (A4 *p)
{
  return (*p)[7];
}

[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450

[bergner at gcc dot gnu.org]

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

--- Comment #9 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #8)
>> This kernel AT_PLATFORM name should strip the '+' off:
>>   .platform = "power7+", -> "power7"
>
> We probably should have a -mcpu=power7+, we have power5+ as well etc.

Well, we have a -mcpu=power5+ because power5+ added a few new instructions over
and above what power5 has.  That is not the case with power7+.  It implements
the exact same instructions that power7 does, so power7+ doesn't really buy us
anything.


>> These kernel AT_PLATFORM names should strip their prefix and suffix off:
>>   .platform = "ppc440gp", -> "440"
>>   .platform = "ppc-cell-be", -> "cell"
>> 
>> These kernel AT_PLATFORM names should strip the 'ppc' prefix off, as
>> well as test the AT_HWCAP for PPC_FEATURE_HAS_FPU:
>>   .platform = "ppc405", -> "405" | "405fp"
>>   .platform = "ppc440", -> "440" | "440fp"
>> 
>> This kernel AT_PLATFORM name should strip the 'ppc' prefix off, change
>> 470 to 476 as well as test the AT_HWCAP for PPC_FEATURE_HAS_FPU:
>>   .platform = "ppc470", -> "476" | "476fp"
> 
> We could also decide not to support those for "native" (except cell?),
> they all have problems and no one will try to build on those anyway.
> I hope.

Well, it was easy enough to add support for them in case some did try in the
future.  Up to you though if you want to leave them out.


> e500mc64 is a different core AFAIK, one that was never shipped anyway.

Ok, so the current patch and the updated one I'm working on don't support it,
so I'll leave it that way.


> Could use 970 for pa6t, if we care.

Its up to you if you want me to map that to 970.  Let me know what you want me
to do.

[Bug tree-optimization/84050] [6/7/8 Regression] missing -Warray-bounds accessing a struct array member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
  Known to work||4.5.4
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83776
Summary|missing -Warray-bounds  |[6/7/8 Regression] missing
   |accessing a struct array|-Warray-bounds accessing a
   |member  |struct array member
  Known to fail||4.6.4, 4.7.4, 4.8.4, 4.9.4,
   ||5.5.0, 6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
Same as in bug 83776, bisection points to r164688 committed into GCC 4.6 as the
root cause of the regression:

r164688 | hubicka | 2010-09-28 12:28:39 -0400 (Tue, 28 Sep 2010) | 5 lines

* tree-ssa-ccp.c (fold_ctor_reference): New function.
(fold_const_aggregate_ref): Use it.
* fold-const.c (canonicalize_constructor_val): Check that we don't fold
into external static.

[Bug tree-optimization/84050] New: missing -Warray-bounds accessing a struct array member

[msebor at gcc dot gnu.org]

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

Bug ID: 84050
   Summary: missing -Warray-bounds accessing a struct array member
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC diagnoses tnhe out-of-bounds array index in function farray() below but
fails to diagnose the same bug in fstatic_array.

$ cat t.c && gcc -O2 -S -Wall t.c
struct A { int a[3]; };

int fstatic_array (void)
{
  static struct A a = { { 1, 2, 3 } };

  return a.a[7];   // missing -Warray-bounds
}

int farray (void)
{
  extern struct A f (void);

  struct A a = f ();

  return a.a[7];   // -Warray-bounds (good)
}

t.c: In function ‘farray’:
t.c:16:13: warning: array subscript 7 is above array bounds of ‘int[3]’
[-Warray-bounds]
   return a.a[7];   // -Warray-bounds (good)
  ~~~^~~

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[mike at fireburn dot co.uk]

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

--- Comment #39 from Mike Lothian  ---
I can confirm it fixes things for me too. 

Is that the final patch in Comment 36? If so I'll try and get the Gentoo devs
to include it in the GCC ebuilds

Will this be added to GCC 8.1 and 7.4?

Thanks again, this bug has been plaguing me for the last 8 months

[Bug tree-optimization/83776] [6/7/8 Regression] missing -Warray-bounds indexing past the end of a string literal

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02144.html

[Bug testsuite/84049] New: libgomp.c++/for-[56].C and libgomp.c/for-[56].c take a long time to run

[hjl.tools at gmail dot com]

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

Bug ID: 84049
   Summary: libgomp.c++/for-[56].C and libgomp.c/for-[56].c take a
long time to run
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On a machine with 100+ cores, libgomp.c++/for-[56].C and
libgomp.c/for-[56].c take a long time to run:

   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND
127330 hjl   20   0 56.831g  34568   2400 R  1169  0.1  48:22.56 for-5.exe  
273104 hjl   20   0 1158488  13084   2280 S  1067  0.0  13:28.57 for-5.exe 

Should these tests adjust number of threads and loop counts based on
number of cores?

[Bug middle-end/84048] [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
r256935 was okay.

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

[dtrebbien at gmail dot com]

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

--- Comment #13 from Daniel Trebbien  ---
(In reply to Jonathan Wakely from comment #9)
> Also, if boost::optional had a noexcept move constructor it would work fine.
> This is a boost bug.
> 
> The part of the patch addressing PR 83982 seems right.

I have split out the part of the patch addressing PR 83982 and have attached
the reduced patch there.

[Bug libstdc++/83982] Exception guarantee of C++14 vector::resize(size_type) is not met

[dtrebbien at gmail dot com]

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

--- Comment #2 from Daniel Trebbien  ---
Created attachment 43247
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43247=edit
Patch for PR 83982 alone

[Bug middle-end/84048] New: [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c -O0 -pie -fPIE execution test

[danglin at gcc dot gnu.org]

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

Bug ID: 84048
   Summary: [8 Regression] FAIL: gcc.dg/torture/tls/run-ld.c   -O0
 -pie -fPIE  execution test
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/obj
dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/tls/run-ld.c
-fno-d
iagnostics-show-caret -fdiagnostics-color=never -O0 -pie -fPIE -ansi
-pedantic-e
rrors -lm -o ./run-ld.exe
PASS: gcc.dg/torture/tls/run-ld.c   -O0  -pie -fPIE  (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/obj
dir/hppa-linux-gnu/./libatomic/.libs::/home/dave/gnu/gcc/objdir/gcc:/home/dave/g
nu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/hppa-li
nux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.
libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/o
bjdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/
gnu/gcc/objdir/./prev-gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/
src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/g
cc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/
libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev
-gcc
Execution timeout is: 300
spawn [open ...]
FAIL: gcc.dg/torture/tls/run-ld.c   -O0  -pie -fPIE  execution test

Similar fail:
FAIL: gcc.dg/torture/tls/run-ld.c   -O0  -pie -fpie  execution test

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

[dtrebbien at gmail dot com]

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

--- Comment #12 from Daniel Trebbien  ---
https://wg21.link/lwg2158 looks relevant, particularly this part:

"This requirement is not sufficient if an implementation is free to select copy
constructor when !is_nothrow_move_constructible::value &&
is_copy_constructible::value evaluates to true. Unfortunately,
is_copy_constructible cannot reliably determine whether T is really
copy-constructible. A class may contain public non-deleted copy constructor
whose definition does not exist or cannot be instantiated successfully (e.g.,
std::vector has copy constructor, but this type is not
copy-constructible)."

Even though is_copy_constructible for std::vector> is
true, resizing a vector of this element type works because the std::vector move
constructor is noexcept, so the move constructor is selected.

Jonathan, I personally think that your argument in Comment 10 is persuasive.

Further, I like the suggestion in LWG 2158 to add "if
!is_nothrow_move_constructible::value && is_copy_constructible::value
then T shall be CopyInsertable into *this;" to the requirements of
vector::resize(size_type). I think that this would be required because, based
on my reading of [temp.inst], it is a well-formed program to instantiate
boost::optional, as this does not require the
instantiation of the boost::optional copy
constructor.

[Bug c++/84045] ICE when is_nothrow_default_constructible is used before #include

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-25
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed on trunk and with gcc 7 (but not gcc 6).

I had a go at reducing it (to eliminate the use of the header); this headerless
code (sadly not quite valid anymore) reproduces the ICE:


template  struct is_nothrow_default_constructible { };

template  struct dummy {
  typedef is_nothrow_default_constructible dc;
  void fu() noexcept(dc::value) {}
};

template  struct _Rb_tree_key_compare {
  _Rb_tree_key_compare()
  noexcept(is_nothrow_default_constructible<_Key_compare>::value) {}
};

int main() { _Rb_tree_key_compare bar; }




$ ./xg++ -B. -c ../../src/pr84045.C 
../../src/pr84045.C: In instantiation of
‘_Rb_tree_key_compare<_Key_compare>::_Rb_tree_key_compare() [with _Key_compare
= int]’:
../../src/pr84045.C:13:40:   required from here

 int main() { _Rb_tree_key_compare bar; }
^~~
../../src/pr84045.C:9:3: internal compiler error: tree check: accessed elt 2 of
tree_vec with 1 elts in tsubst, at cp/pt.c:13717
   _Rb_tree_key_compare()
   ^~~~
0x772e64 tree_vec_elt_check_failed(int, int, char const*, int, char const*)
../../src/gcc/tree.c:9533
0x7cf5c5 tree_vec_elt_check(tree_node*, int, char const*, int, char const*)
../../src/gcc/tree.h:3353
0x9a85ce tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13717
0x9b67a7 tsubst_template_args
../../src/gcc/cp/pt.c:11801
0x9a7ca0 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13992
0x9a8d63 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:13596
0x9c9433 tsubst_qualified_id
../../src/gcc/cp/pt.c:14539
0x9af072 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:17345
0x9d6e43 maybe_instantiate_noexcept(tree_node*, int)
../../src/gcc/cp/pt.c:22898
0x88b9b2 mark_used(tree_node*, int)
../../src/gcc/cp/decl2.c:5211
0x7c1b23 build_over_call
../../src/gcc/cp/call.c:8199
0x7c749c build_new_method_call_1
../../src/gcc/cp/call.c:9295
0x7c7aa8 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../src/gcc/cp/call.c:9364
0x7c4a2b build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../src/gcc/cp/call.c:8877
0x8b713c expand_default_init
../../src/gcc/cp/init.c:1889
0x8b713c expand_aggr_init_1
../../src/gcc/cp/init.c:2004
0x8b7f23 build_aggr_init(tree_node*, tree_node*, int, int)
../../src/gcc/cp/init.c:1744
0x84958f build_aggr_init_full_exprs
../../src/gcc/cp/decl.c:6163
0x84958f check_initializer
../../src/gcc/cp/decl.c:6311
0x86c7ef cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../src/gcc/cp/decl.c:7011

[Bug target/84033] powerpc64le -moptimize-swaps bad code with vec_vbpermq

[amodra at gcc dot gnu.org]

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

--- Comment #3 from Alan Modra  ---
Author: amodra
Date: Thu Jan 25 23:57:18 2018
New Revision: 257070

URL: https://gcc.gnu.org/viewcvs?rev=257070=gcc=rev
Log:
PR84033, powerpc64le -moptimize-swaps bad code with vec_vbpermq

vbpermq produces its output in bits 48..63 of the target vector reg,
so the output cannot be lane swapped.

gcc/
PR target/84033
* config/rs6000/rs6000-p8swap.c (rtx_is_swappable_p): Exclude
UNSPEC_VBPERMQ.  Sort other unspecs.
gcc/testsuite/
PR target/84033
* gcc.target/powerpc/swaps-p8-46.c: New.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/swaps-p8-46.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-p8swap.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/84047] [6/7/8 Regression] missing -Warray-bounds on an out-of-bounds index into an array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] missing  |[6/7/8 Regression] missing
   |-Warray-bounds on a |-Warray-bounds on an
   |negative offset into a  |out-of-bounds index into an
   |string  |array

--- Comment #2 from Martin Sebor  ---
Another test case with the same root cause, but this one with an array and a
small positive index:

char a[8];

int f (void)
{
  const char *s = a + 4;
  int i = 8;
  return s[i];   // missing -Warray-bounds
}

[Bug target/56010] Powerpc, -mcpu=native and -mtune=native use the wrong name for target 7450

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #8 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #5)
> Going through the kernel cputable.c file and comparing it to
> rs6000-cpus.def, I think the name translation should like:
> 
> These kernel AT_PLATFORM names can be used as is:
>   .platform = "powerpc",
>   .platform = "power3",
>   .platform = "power4",
>   .platform = "power5",
>   .platform = "power5+",
>   .platform = "power6",
>   .platform = "power6x",
>   .platform = "power7",
>   .platform = "power8",
>   .platform = "power9",
> 
> This kernel AT_PLATFORM name should strip the '+' off:
>   .platform = "power7+", -> "power7"

We probably should have a -mcpu=power7+, we have power5+ as well etc.

> These kernel AT_PLATFORM names should strip the 'ppc' prefix off:
>   .platform = "ppc970", -> "970"
>   .platform = "ppc601", -> "601"
>   .platform = "ppc603", -> "603"
>   .platform = "ppc604", -> "604"
>   .platform = "ppc750", -> "750"
>   .platform = "ppc7400", -> "7400"
>   .platform = "ppc7450", -> "7450"
>   .platform = "ppc823", -> "823"
>   .platform = "ppc403", -> "403"
>   .platform = "ppc8540", -> "8540"
>   .platform = "ppc8548", -> "8548"
>   .platform = "ppce5500", -> "e5500"
>   .platform = "ppce6500", -> "e6500"

Yup.

> These kernel AT_PLATFORM names should strip their prefix and suffix off:
>   .platform = "ppc440gp", -> "440"
>   .platform = "ppc-cell-be", -> "cell"
> 
> These kernel AT_PLATFORM names should strip the 'ppc' prefix off, as
> well as test the AT_HWCAP for PPC_FEATURE_HAS_FPU:
>   .platform = "ppc405", -> "405" | "405fp"
>   .platform = "ppc440", -> "440" | "440fp"
> 
> This kernel AT_PLATFORM name should strip the 'ppc' prefix off, change
> 470 to 476 as well as test the AT_HWCAP for PPC_FEATURE_HAS_FPU:
>   .platform = "ppc470", -> "476" | "476fp"

We could also decide not to support those for "native" (except cell?),
they all have problems and no one will try to build on those anyway.
I hope.

> This kernel AT_PLATFORM name should strip the 'ppc' prefix off, as
> well as test the AT_HWCAP for PPC_FEATURE_64::
>   .platform = "ppce500mc", -> "e500mc" | "e500mc64"

e500mc64 is a different core AFAIK, one that was never shipped anyway.

> These kernel AT_PLATFORM names do not seem to have an equivalent
> rs6000-cpus.def entry, so we probably should just treat them as
> unknown/non-existent names:
>   .platform = "pa6t",
>   .platform = "ppc5554",


Could use 970 for pa6t, if we care.  5554 is SPE (e200z6)

> I do question though, whether we should test the AT_HWCAP bits or not.  Just
> because we're on, say a 476fp system, doesn't mean the toolchain and
> libraries are compiled with FP support.  Thoughts anyone?

Not sure.  Maybe just error out?

[Bug libstdc++/83662] std::aligned_alloc() not available

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Adding this is simple, but I'm worried it will cause issues on Windows, where
detection of that function doesn't seem to work properly (see PR 78565).

[Bug libstdc++/24537] Non-uglified names inside namespace __gnu_cxx

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
char_traits shouldn't need to be uglified, because it's a reserved name anyway,
due to std::char_traits. That means users can't define macros with that name.
If they get ambiguities due to "using namespace __gnu_cxx;" then they should
not do that.

Thee are other names that should be uglified though, see PR 64135.

[Bug tree-optimization/84047] [6/7/8 Regression] missing -Warray-bounds on a negative offset into a string

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
  Known to work||4.5.4
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83776
Summary|missing -Warray-bounds on a |[6/7/8 Regression] missing
   |negative offset into a  |-Warray-bounds on a
   |string  |negative offset into a
   ||string
  Known to fail||5.4.0, 6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Sebor  ---
The root cause of this regression is different from that of pr83776.  Bisection
leads to r161655 (committed in the GCC 4.6.0 cycle):

r161655 | rguenth | 2010-07-01 04:49:19 -0400 (Thu, 01 Jul 2010) | 341 lines

2010-07-01  Richard Guenther  

PR middle-end/42834
PR middle-end/44468

[Bug tree-optimization/84047] New: missing -Warray-bounds on a negative offset into a string

[msebor at gcc dot gnu.org]

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

Bug ID: 84047
   Summary: missing -Warray-bounds on a negative offset into a
string
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In the distant past GCC would diagnose the out-of-bounds array access in the
following test case but it no longer does:

int f (void)
{
  const char *s = "12345678";
  int i = 1U << 30;
  return s[i];   // missing -Warray-bounds
}

[Bug c/84046] New: global zero-sized objects may have same address

[uecker at eecs dot berkeley.edu]

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

Bug ID: 84046
   Summary: global zero-sized objects may have same address
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: uecker at eecs dot berkeley.edu
  Target Milestone: ---

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

With newer versions of gcc (tested: 6.3.0 and recent git) global zero-sized
objects may have the same address. The only real use of such objects at a
global level is to create unique addresses, but this newer behavior breaks this
use case. Older versions of gcc (tested: 4.8 and 4.9) seem to always assign
different addresses and the same is true for clang 3.8 and 3.9.

[Bug rtl-optimization/83985] [8 Regression] Compile time hog for 32-bit BE powerpc targets

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
Ah, #c6 made me think you wanted to do something else.  I didn't look close
enough, sorry.  That patch looks good.

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

[daniel.kruegler at googlemail dot com]

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

--- Comment #11 from Daniel Krügler  ---
(In reply to Jonathan Wakely from comment #10)
> Perhaps Daniel can comment, since he wrote the resolution of lwg 2033.
> 
> Daniel, if the intent was that vector::resize(size_type) must only move,
> even if that can throw, why is the exception-safety guarantee worded in
> terms of a non-CopyInsertable condition? Was the intention really to forbid
> implementations from giving the strong exception-safety guarantee (by
> copying) if possible?

I'm in the mid of something else, so forgive me if I'm still catching up. The
wording was slightly changed by LWG 2323 later on, does that clarify? [If not,
I can look deeper into it tomorrow evening, so please let me know] The basic
idea that the original wording tried to ensure is that strong exception-safety
holds for non-throwing move-only types or copyable types, because that was the
original intend suggested by Howard Hinnant.

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #8)
> I don't think your patch is correct. The whole point of the "move if
> noexcept" utilities is that they handle this correctly. If the type is
> nothrow movable, then move. Otherwise if it is copyable, then copy.
> Otherwise move (even though that might throw).

This is why the "Remarks:" paragraph talks about "a non-CopyInsertable T". If
copying  wasn't allowed here then whether it's CopyInsertable would make no
difference, and the exception safety guarantee could just say "If an exception
is thrown other than by the move constructor of T, there are no effects."

(This of course assumes that the constructor used by
allocator_traits::construct is the move constructor, but that's a separate
defect).

Perhaps Daniel can comment, since he wrote the resolution of lwg 2033.

Daniel, if the intent was that vector::resize(size_type) must only move, even
if that can throw, why is the exception-safety guarantee worded in terms of a
non-CopyInsertable condition? Was the intention really to forbid
implementations from giving the strong exception-safety guarantee (by copying)
if possible?

[Bug c/71501] missing warning on printf %s with a non-nul terminated string

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

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

[Bug lto/84044] Spurious -Wodr warning with -flto

[geoffrey at allott dot email]

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

--- Comment #2 from Geoffrey Allott  ---
Or even simply

A a;

[Bug middle-end/83959] Missing buffer overflow warning on printf %s

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
I agree that it would be valuable to detect this class of bugs, including all
other such invalid uses of character arrays that aren't nul-terminated (e.g.,
strlen(a)), and perhaps even those that aren't initialized.  I think the most
suitable pass to detect these bugs is tree-ssa-strlen.  For the printf-family
of functions, integrating the gimple-ssa-sprintf pass would be a good approach.
 (By integrating I don't necessarily mean at the source code level but rather
by having the strlen pass drive and call into the sprintf code).

This request is a duplicate of pr71501.

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

[Bug lto/84044] Spurious -Wodr warning with -flto

[geoffrey at allott dot email]

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

--- Comment #1 from Geoffrey Allott  ---
I discovered that in b.cpp a free function

A get() {
return A();
}

also triggers the error. Struct B is not necessary.

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Also, if boost::optional had a noexcept move constructor it would work fine.
This is a boost bug.

The part of the patch addressing PR 83982 seems right.

[Bug rtl-optimization/83985] [8 Regression] Compile time hog for 32-bit BE powerpc targets

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Yes, I do, see #c5.  Successfully bootstrapped/regtested (without go which
seems to be broken right now) on powerpc64le-linux and bootstrapped on
powerpc64-linux, will post once regtest (-m64/-m32) on the latter finishes.

[Bug c++/84045] New: ICE when is_nothrow_default_constructible is used before #include

[schlaffi at users dot sourceforge.net]

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

Bug ID: 84045
   Summary: ICE when is_nothrow_default_constructible is used
before #include
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schlaffi at users dot sourceforge.net
  Target Milestone: ---

The following valid code

#include 

template 
struct dummy{
 typedef std::is_nothrow_default_constructible dc;
 void fu()noexcept(dc::value){}
};

#include 

int main(){
 std::set bar;
 return 0;
}

causes the ICE:

In file included from /usr/include/c++/7/set:60:0,
 from ice.cc:9:
/usr/include/c++/7/bits/stl_tree.h: In instantiation of
‘std::_Rb_tree_key_compare<_Key_compare>::_Rb_tree_key_compare() [with
_Key_compare = std::less]’:
ice.cc:12:16:   required from here
/usr/include/c++/7/bits/stl_tree.h:146:7: internal compiler error: Segmentation
fault
   _Rb_tree_key_compare()

The following changes make the code compile without error:

- include  before struct dummy
- force dc::value to be bool (e.g. not not dc::value or bool(dc::value))
- expand the typedef in dc::value
- have only one template parameter

But, it took me quite a while to find what line causes the error.

My gcc is

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
I don't think your patch is correct. The whole point of the "move if noexcept"
utilities is that they handle this correctly. If the type is nothrow movable,
then move. Otherwise if it is copyable, then copy. Otherwise move (even though
that might throw).

The problem here is that boost::optional pretends to be copyable, but then
fails in its copy constructor because foo is not copyable.

[Bug lto/84044] New: Spurious -Wodr warning with -flto

[geoffrey at allott dot email]

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

Bug ID: 84044
   Summary: Spurious -Wodr warning with -flto
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geoffrey at allott dot email
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

a.cpp
=

struct A {
virtual ~A();
};

A::~A() {}


b.cpp
=

struct A {
virtual ~A();
};

struct B {
A a;
A get();
};

A B::get() {
return a;
}


Makefile


main: a.cpp b.cpp
$(CXX) a.cpp -c -fno-semantic-interposition -fpic -flto
$(CXX) b.cpp -c -flto -O1
$(CXX) a.o b.o


This results in:

b.cpp:1:8: warning: virtual table of type ‘struct A’ violates one definition
rule   [-Wodr]
 struct A {
^
a.cpp:1:8: note: the conflicting type defined in another translation unit
 struct A {
^
a.cpp:5:1: note: virtual method ‘__base_dtor ’
 A::~A() {}
 ^
a.cpp:5:1: note: ought to match virtual method ‘__base_dtor ’ but does not



Note that even something as simple as inlining the definition of the destructor
or the `get` function cause the warning to go away. All of the flags are
necessary to reproduce the error.

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[boger at us dot ibm.com]

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

--- Comment #25 from boger at us dot ibm.com ---
A few other variations that enable it to work even with a power8 configuration:

Compiling with -fdisable-ipa-cp prevents the ICE.

OR

Using the //go:nosplit directive before the function identified in the error
message prevents the ICE.

OR making various source changes to the function in some cases allows it to
work.
for example, in function:

func (tools gccgoToolchain) gc(b *Builder, a *Action, archive string, importcfg
[]byte, asmhdr bool, gofiles []string) (ofile string, output []byte, err error) 

Commenting out this loop prevents the error:

  for _, f := range gofiles {
  args = append(args, mkAbs(p.Dir, f))
  }

[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917

[clyon at gcc dot gnu.org]

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

--- Comment #6 from Christophe Lyon  ---
My bisect script cannot find the commit that introduced the problem with
-fno-vect-cost-model, because the build was broken for quite some time.
The regression seems to have been introduced between r197671 and r197815.

[Bug rtl-optimization/83985] [8 Regression] Compile time hog for 32-bit BE powerpc targets

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #8 from Segher Boessenkool  ---
Hi Jakub,

Do you have a patch?  Or should I take a look?

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[manuel.lauss at googlemail dot com]

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

--- Comment #38 from Manuel Lauss  ---
(In reply to Jakub Jelinek from comment #36)

Your patch does fix my llvm issue. Thank you!

[Bug sanitizer/84043] -fsanitize=alignment leads to massive compile time

[sduvan.gcc at gmail dot com]

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

--- Comment #2 from Johan Alfredsson  ---
bash> g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/7.2.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/products/gcc/7.2.0/lib/gcc/x86_64-suse-linux/7.2.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-7.2.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/7.2.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.26/bin/as --with-gnu-ld
--with-ld=/usr/local/products/gcc/binutils-2.26/bin/ld.bfd
--with-gmp=/usr/local/products/gcc/gmp-6.1.0
--with-mpfr=/usr/local/products/gcc/mpfr-3.1.4
--with-mpc=/usr/local/products/gcc/mpc-1.0.3 --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=pool
x86_64-suse-linux
Thread model: posix
gcc version 7.2.0 (GCC) 

to reproduce the problem
g++ -fsanitize=alignment bug.C -o bug

[Bug sanitizer/84043] -fsanitize=alignment leads to massive compile time

[sduvan.gcc at gmail dot com]

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

--- Comment #1 from Johan Alfredsson  ---
Created attachment 43245
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43245=edit
Preprocessed source

[Bug sanitizer/84043] New: -fsanitize=alignment leads to massive compile time

[sduvan.gcc at gmail dot com]

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

Bug ID: 84043
   Summary: -fsanitize=alignment leads to massive compile time
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sduvan.gcc at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

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

The tiny attached program, bug.C, leads to compile times that seem to be
exponential in the number of operator<<():s used.

I'm aware of bug 69656 but it was not clear to me that this was related to the
same underlying issue and also my testcase seems significantly smaller.

[Bug rtl-optimization/84038] [7/8 Regression] powerpc-linux-gcc gets stuck building linux kernel

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

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

--- Comment #3 from Arnd Bergmann  ---
(In reply to Arnd Bergmann from comment #2)
> bisected this one to r244207, and bisected pr83985 to something earlier.

attachment 43241 that jakub created for pr83985 addresses this one as well,
closing as duplicate.

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

[Bug rtl-optimization/83985] [8 Regression] Compile time hog for 32-bit BE powerpc targets

[arnd at linaro dot org]

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

--- Comment #7 from Arnd Bergmann  ---
*** Bug 84038 has been marked as a duplicate of this bug. ***

[Bug libstdc++/81122] [DR 2381] parsing f stopped after '0' when reading std::hexfloat >> f;

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED
Summary|parsing f stopped after '0' |[DR 2381] parsing f stopped
   |when reading std::hexfloat  |after '0' when reading
   |>> f;   |std::hexfloat >> f;

--- Comment #3 from Jonathan Wakely  ---
It's unclear whether the standard says this should work or not. LWG 2381 argues
that it is already implied by the use of strtod, but 'P' cannot be accumulated
into an input sequence for strtod, because it's not a valid atom.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[ubizjak at gmail dot com]

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

--- Comment #37 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #33)

> and it should work.  The last case would be right now:
>   SI:N+1 = SI:N &~ SI:N+2; SI:N+2 = SI:N+1 &~ SI:N+3;
> and is again wrong, but we could again swap:
>   SI:N+2 = SI:N+1 &~ SI:N+3; SI:N+1 = SI:N &~ SI:N+2;
> and all is fine.

Whoops, it looks that SI:N+2 is clobbered in the swapped case.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[jakub at gcc dot gnu.org]

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

--- Comment #36 from Jakub Jelinek  ---
Ah, bmi, not bmi2.  And the =r <- (r, r) alternative might be best first.
--- gcc/config/i386/i386.md.jj  2018-01-16 09:28:19.721432394 +0100
+++ gcc/config/i386/i386.md 2018-01-25 20:58:18.382378827 +0100
@@ -9250,14 +9250,14 @@ (define_split
 })

 (define_insn "*andndi3_doubleword"
-  [(set (match_operand:DI 0 "register_operand" "=r,")
+  [(set (match_operand:DI 0 "register_operand" "=r,r,")
(and:DI
- (not:DI (match_operand:DI 1 "register_operand" "r,0"))
- (match_operand:DI 2 "nonimmediate_operand" "rm,rm")))
+ (not:DI (match_operand:DI 1 "register_operand" "r,0,r"))
+ (match_operand:DI 2 "nonimmediate_operand" "r,rm,m")))
(clobber (reg:CC FLAGS_REG))]
   "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
   "#"
-  [(set_attr "isa" "bmi,*")])
+  [(set_attr "isa" "bmi,*,bmi")])

 (define_split
   [(set (match_operand:DI 0 "register_operand")
@@ -9273,7 +9273,22 @@ (define_split
(parallel [(set (match_dup 3)
   (and:SI (not:SI (match_dup 4)) (match_dup 5)))
  (clobber (reg:CC FLAGS_REG))])]
-  "split_double_mode (DImode, [0], 3, [0], [3]);")
+{
+  split_double_mode (DImode, [0], 3, [0], [3]);
+  /* For the =r <- (r, r) alternative of *andndi3_doubleword, there could
+ be overlap between the output and input registers.  If the output
+ is equal to one of the input operands, this is fine, if there is
+ partial overlap, we can resolve it by swapping the two instructions.  */
+  if (reg_overlap_mentioned_p (operands[0], operands[4])
+  || reg_overlap_mentioned_p (operands[0], operands[5]))
+{
+  std::swap (operands[0], operands[3]);
+  std::swap (operands[1], operands[4]);
+  std::swap (operands[2], operands[5]);
+  gcc_assert (!reg_overlap_mentioned_p (operands[0], operands[4])
+ && !reg_overlap_mentioned_p (operands[0], operands[5]));
+}
+})

 (define_split
   [(set (match_operand:DI 0 "register_operand")

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[jakub at gcc dot gnu.org]

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

--- Comment #35 from Jakub Jelinek  ---
So, what about following?
--- gcc/config/i386/i386.md.jj  2018-01-16 09:28:19.721432394 +0100
+++ gcc/config/i386/i386.md 2018-01-25 20:58:18.382378827 +0100
@@ -9250,14 +9250,14 @@ (define_split
 })

 (define_insn "*andndi3_doubleword"
-  [(set (match_operand:DI 0 "register_operand" "=r,")
+  [(set (match_operand:DI 0 "register_operand" "=r,r,")
(and:DI
- (not:DI (match_operand:DI 1 "register_operand" "r,0"))
- (match_operand:DI 2 "nonimmediate_operand" "rm,rm")))
+ (not:DI (match_operand:DI 1 "register_operand" "0,r,r"))
+ (match_operand:DI 2 "nonimmediate_operand" "rm,r,m")))
(clobber (reg:CC FLAGS_REG))]
   "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
   "#"
-  [(set_attr "isa" "bmi,*")])
+  [(set_attr "isa" "*,bmi2,bmi2")])

 (define_split
   [(set (match_operand:DI 0 "register_operand")
@@ -9273,7 +9273,22 @@ (define_split
(parallel [(set (match_dup 3)
   (and:SI (not:SI (match_dup 4)) (match_dup 5)))
  (clobber (reg:CC FLAGS_REG))])]
-  "split_double_mode (DImode, [0], 3, [0], [3]);")
+{
+  split_double_mode (DImode, [0], 3, [0], [3]);
+  /* For the =r <- (r, r) alternative of *andndi3_doubleword, there could
+ be overlap between the output and input registers.  If the output
+ is equal to one of the input operands, this is fine, if there is
+ partial overlap, we can resolve it by swapping the two instructions.  */
+  if (reg_overlap_mentioned_p (operands[0], operands[4])
+  || reg_overlap_mentioned_p (operands[0], operands[5]))
+{
+  std::swap (operands[0], operands[3]);
+  std::swap (operands[1], operands[4]);
+  std::swap (operands[2], operands[5]);
+  gcc_assert (!reg_overlap_mentioned_p (operands[0], operands[4])
+ && !reg_overlap_mentioned_p (operands[0], operands[5]));
+}
+})

 (define_split
   [(set (match_operand:DI 0 "register_operand")

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[ubizjak at gmail dot com]

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

--- Comment #34 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #33)

> At least with a smarter splitter we don't really need to avoid no overlap at
> all for the r <- (r, r) bmi case, we can choose which of the two 32-bit
> andn's we do first depending on the overlap, all we need to guarantee is
> that the splitter is not impossible and ideally doesn't need any
> instructions but the two.

This would work nicely. I have seen a couple of places with the attached source
(using only -mbmi -m32) where RA satisfied & or 0 constraint only with spills
and would benefit from relaxed constraints.

BTW: AFAICS, "andn" is the only double-word three-operand instruction that is
split after reload. So, andn r <- (r,r) post-reload splitter is a precedent in
x86 world.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[jakub at gcc dot gnu.org]

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

--- Comment #33 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #31)
> (In reply to Uroš Bizjak from comment #30)
> > So, I'll bootstrap:
> 
> Maybe we can also allow  <- (r,r) for BMI, to be safe (c.f. comment #23):
> 
> (define_insn "*andndi3_doubleword"
>   [(set (match_operand:DI 0 "register_operand" "=r,")
>   (and:DI
> (not:DI (match_operand:DI 1 "register_operand" "0,r"))
> (match_operand:DI 2 "nonimmediate_operand" "rm,rm")))
>(clobber (reg:CC FLAGS_REG))]
>   "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
>   "#"
>   [(set_attr "isa" "*,bmi")])
> 
> Manuel, can you please test this pattern?

At least with a smarter splitter we don't really need to avoid no overlap at
all for the r <- (r, r) bmi case, we can choose which of the two 32-bit andn's
we do first depending on the overlap, all we need to guarantee is that the
splitter is not impossible and ideally doesn't need any instructions but the
two.
Hard registers for DImode must be consecutive because we identify them by the
(lowest) register number and mode and for r <- (r, r) there can't be any
overlap between the two input operands.  So, even if DImode registers can start
at any GPR number other than the last, not just even ones, either there is no
overlap at all in between output and inputs, or the output is the same as the
first, or as the second input (all these cases are fine), or there is a partial
overlap with one or both of the operands.
For the partial operand I can think of DI:N = DI:N+1 &~ DI:unrelated, or
DI:N+1 = DI:N &~ DI:unrelated, or DI:N+1 = DI:N &~ DI:N+2 (or swapped
operands),
the last case is partial overlap with both inputs.  So, right now we'd split
those into:
  SI:N = SI:N+1 &~ SI:unrelated; SI:N+1 = SI:N+2 &~ SI:unrelated+1
which is fine, or
  SI:N+1 = SI:N &~ SI:unrelated; SI:N+2 = SI:N+1 &~ SI:unrelated+1
which is wrong but we can swap those:
  SI:N+2 = SI:N+1 &~ SI:unrelated+1; SI:N+1 = SI:N &~ SI:unrelated
and it should work.  The last case would be right now:
  SI:N+1 = SI:N &~ SI:N+2; SI:N+2 = SI:N+1 &~ SI:N+3;
and is again wrong, but we could again swap:
  SI:N+2 = SI:N+1 &~ SI:N+3; SI:N+1 = SI:N &~ SI:N+2;
and all is fine.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[manuel.lauss at googlemail dot com]

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

--- Comment #32 from Manuel Lauss  ---
(In reply to Uroš Bizjak from comment #31)
> (In reply to Uroš Bizjak from comment #30)
> > So, I'll bootstrap:
> 
> Maybe we can also allow  <- (r,r) for BMI, to be safe (c.f. comment #23):
> 
> (define_insn "*andndi3_doubleword"
>   [(set (match_operand:DI 0 "register_operand" "=r,")
>   (and:DI
> (not:DI (match_operand:DI 1 "register_operand" "0,r"))
> (match_operand:DI 2 "nonimmediate_operand" "rm,rm")))
>(clobber (reg:CC FLAGS_REG))]
>   "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
>   "#"
>   [(set_attr "isa" "*,bmi")])
> 
> Manuel, can you please test this pattern?

Seems to work as well:

[...]
  b1:   c4 e2 73 f7 d2  shrx   %ecx,%edx,%edx
  b6:   0f 45 c2cmovne %edx,%eax
  b9:   0f 45 d5cmovne %ebp,%edx
  bc:   c4 e2 68 f2 54 df 04andn   0x4(%edi,%ebx,8),%edx,%edx
  c3:   89 d1   mov%edx,%ecx
  c5:   c4 e2 78 f2 04 df   andn   (%edi,%ebx,8),%eax,%eax
  cb:   09 c1   or %eax,%ecx
[...]

[Bug jit/81672] trunk/gcc/jit/jit-recording.c:2852: possible missing initialiser

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #3 from David Malcolm  ---
Thanks.

Should be fixed by r257066; please reopen this if there are any similar
warnings in the jit code.

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

--- Comment #24 from Bill Seurer  ---
sawdey asked me to try this.  I built gcc with go enabled and the assertion
line that is causing the ICE commented out.  The build finished just fine.  I
ran make check on that and compared the results with the same revision built
without go and there are no significant differences;  a few go tests failed
that usually fail but no ICEs or anything like that.

[Bug jit/81672] trunk/gcc/jit/jit-recording.c:2852: possible missing initialiser

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
Author: dmalcolm
Date: Thu Jan 25 19:19:29 2018
New Revision: 257066

URL: https://gcc.gnu.org/viewcvs?rev=257066=gcc=rev
Log:
jit: remove some unused fields from recording::union_ (PR jit/81672)

gcc::jit::recording::union_ has some stray fields, which
are duplicates of those in the compound_type base class.

It looks like these have been present since the initial merger of the jit
branch to trunk (r217374), where it had three duplicate fields:

 location *m_loc;
 string *m_name;
 fields *m_fields;

I removed the duplicate field "m_fields" in r219564 but missed the other
two.

This patch removes them.

gcc/jit/ChangeLog:
PR jit/81672
* jit-recording.h (gcc::jit::recording::union_): Remove fields
"m_loc" and "m_name".


Modified:
trunk/gcc/jit/ChangeLog
trunk/gcc/jit/jit-recording.h

[Bug fortran/83999] [8 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10233

[paul.richard.thomas at gmail dot com]

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

--- Comment #5 from paul.richard.thomas at gmail dot com  ---
Hi Jakub,

Thanks for the OK and the help in getting the padding sorted out.

Committed as Committed revision 257065.

Paul

On 24 January 2018 at 20:26, Paul Richard Thomas
 wrote:
> Hi Jakub,
>
> I have made the changes to the types of the dtype elements that you
> suggested. It led to a cast being needed in
> trans-intrinsic.c(gfc_conv_intrinsic_rank) but, apart from that, the
> changes were straightforward. Please find the updated patch attached.
>
> OK for trunk?
>
> Once I have committed this patch, I promise that I will stick to
> regressions and bug fixes through to release :-)
>
> Paul
>
>
> On 24 January 2018 at 09:11, jakub at gcc dot gnu.org
>  wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83999
>>
>> Jakub Jelinek  changed:
>>
>>What|Removed |Added
>> 
>>Priority|P3  |P4
>>  Status|UNCONFIRMED |NEW
>>Last reconfirmed||2018-01-24
>>  CC||jakub at gcc dot gnu.org,
>>||pault at gcc dot gnu.org
>>  Ever confirmed|0   |1
>>
>> --- Comment #2 from Jakub Jelinek  ---
>> Started with r254936.
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for the bug.
>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough"
> - Albert Einstein

[Bug fortran/37577] [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Thu Jan 25 19:09:40 2018
New Revision: 257065

URL: https://gcc.gnu.org/viewcvs?rev=257065=gcc=rev
Log:
2018-25-01  Paul Thomas  

PR fortran/37577
* array.c (gfc_match_array_ref): If standard earlier than F2008
it is an error if the reference dimension is greater than 7.
libgfortran.h : Increase GFC_MAX_DIMENSIONS to 15. Change the
dtype masks and shifts accordingly.
* trans-array.c (gfc_conv_descriptor_dtype): Use the dtype
type node to check the field.
(gfc_conv_descriptor_dtype): Access the rank field of dtype.
(duplicate_allocatable_coarray): Access the rank field of the
dtype descriptor rather than the dtype itself.
* trans-expr.c (get_scalar_to_descriptor_type): Store the type
of 'scalar' on entry and use its TREE_TYPE if it is ARRAY_TYPE
(ie. a character).
(gfc_conv_procedure_call): Pass TREE_OPERAND (tmp,0) to
get_scalar_to_descriptor_type if the actual expression is a
constant.
(gfc_trans_structure_assign): Assign the rank directly to the
dtype rank field.
* trans-intrinsic.c (gfc_conv_intrinsic_rank): Cast the result
to default integer kind.
(gfc_conv_intrinsic_sizeof): Obtain the element size from the
'elem_len' field of the dtype.
* trans-io.c (gfc_build_io_library_fndecls): Replace
gfc_int4_type_node with dtype_type_node where necessary.
(transfer_namelist_element): Use gfc_get_dtype_rank_type for
scalars.
* trans-types.c : Provide 'get_dtype_type_node' to acces the
dtype_type_node and, if necessary, build it.
The maximum size of an array element is now determined by the
maximum value of size_t.
Update the description of the array descriptor, including the
type def for the dtype_type.
(gfc_get_dtype_rank_type): Build a constructor for the dtype.
Distinguish RECORD_TYPEs that are BT_DERIVED or BT_CLASS.
(gfc_get_array_descriptor_base): Change the type of the dtype
field to dtype_type_node.
(gfc_get_array_descr_info): Get the offset to the rank field of
the dtype.
* trans-types.h : Add a prototype for 'get_dtype_type_node ()'.
* trans.h : Define the indices of the dtype fields.

2018-25-01  Paul Thomas  

PR fortran/37577
* gfortran.dg/coarray_18.f90: Allow dimension 15 for F2008.
* gfortran.dg/coarray_lib_this_image_2.f90: Change 'array1' to
'array01' in the tree dump comparison.
* gfortran.dg/coarray_lib_token_4.f90: Likewise.
* gfortran.dg/inline_sum_1.f90: Similar - allow two digits.
* gfortran.dg/rank_1.f90: Allow dimension 15 for F2008.

2018-25-01  Paul Thomas  

PR fortran/37577
* caf/single.c (_gfortran_caf_failed_images): Access the 'type'
and 'elem_len' fields of the dtype instead of the shifts.
(_gfortran_caf_stopped_images): Likewise.
* intrinsics/associated.c (associated): Compare the 'type' and
'elem_len' fields instead of the dtype.
* caf/date_and_time.c : Access the dtype fields rather using
shifts and masks.
* io/transfer.c (transfer_array ): Comment on item count.
(set_nml_var,st_set_nml_var): Change dtype type and use fields.
(st_set_nml_dtio_var): Likewise.
* libgfortran.h : Change definition of GFC_ARRAY_DESCRIPTOR and
add a typedef for the dtype_type. Change the GFC_DTYPE_* macros
to access the dtype fields.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/libgfortran.h
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/fortran/trans-types.h
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray_18.f90
trunk/gcc/testsuite/gfortran.dg/coarray_lib_this_image_2.f90
trunk/gcc/testsuite/gfortran.dg/coarray_lib_token_4.f90
trunk/gcc/testsuite/gfortran.dg/inline_sum_1.f90
trunk/gcc/testsuite/gfortran.dg/rank_1.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/caf/single.c
trunk/libgfortran/intrinsics/associated.c
trunk/libgfortran/intrinsics/date_and_time.c
trunk/libgfortran/io/transfer.c
trunk/libgfortran/libgfortran.h

[Bug middle-end/84040] [8 regression] compilation time of gcc.c-torture/compile/limits-blockid.c is 50x slower

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-25
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from James Greenhalgh  ---
Confirmed on aarch64-none-linux-gnu. My bisect pointed to the same revision
r255569 . The 50x slow-down is surprising, and may be much larger than
expected? Otherwise we could workaround this with -gno-statement-frontiers for
this test.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #31 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #30)
> So, I'll bootstrap:

Maybe we can also allow  <- (r,r) for BMI, to be safe (c.f. comment #23):

(define_insn "*andndi3_doubleword"
  [(set (match_operand:DI 0 "register_operand" "=r,")
(and:DI
  (not:DI (match_operand:DI 1 "register_operand" "0,r"))
  (match_operand:DI 2 "nonimmediate_operand" "rm,rm")))
   (clobber (reg:CC FLAGS_REG))]
  "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
  "#"
  [(set_attr "isa" "*,bmi")])

Manuel, can you please test this pattern?

[Bug middle-end/84040] [8 regression] compilation time of gcc.c-torture/compile/limits-blockid.c is 50x slower

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #1 from nsz at gcc dot gnu.org ---
regression seems to be introduced by r255569

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[ubizjak at gmail dot com]

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

--- Comment #30 from Uroš Bizjak  ---
So, I'll bootstrap:

(define_insn "*andndi3_doubleword"
  [(set (match_operand:DI 0 "register_operand" "=r,")
(and:DI
  (not:DI (match_operand:DI 1 "register_operand" "0,r"))
  (match_operand:DI 2 "nonimmediate_operand" "rm,m")))
   (clobber (reg:CC FLAGS_REG))]
  "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
  "#"
  [(set_attr "isa" "*,bmi")])

[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations

[msebor at gcc dot gnu.org]

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

Bug 71304 Summary: missing strlen optimizations after string truncation by 
assigning NUL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71304

   What|Removed |Added

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

[Bug middle-end/71304] missing strlen optimizations after string truncation by assigning NUL

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED

--- Comment #5 from Martin Sebor  ---
Bisection points to r249880 as the commit that enabled this optimization.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[ubizjak at gmail dot com]

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

--- Comment #29 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #25)
> I believe for double-word pseudos the RA will not do that, CCing Vlad about
> it.

I start to worry about it due to allocated:

   0x080a96c3 <+1347>:  andn   (%eax,%ebx,8),%edx,%eax
=> 0x080a96c9 <+1353>:  andn   0x4(%eax,%ebx,8),%ecx,%edx

In addition to memory input operand, (dx,cx) regpair is used and (ax,dx) is the
output operand. These regpairs do in fact interleave!

> Anyway, by having all of r <- (r, r), r <- (0, rm) and  <- (r, m)
> alternatives I'd think the RA has more choices than when it just has the
> first 2.
> If it sees it as beneficial to have the middle operand in the destination,
> it can due to the second alternative even if third one is a memory, if it
> wants some other, it can, just needs to make sure the destination doesn't
> overlap with mem's address.

Taking all those facts into account, I think we can allow two alternatives:

r <- (0, rm)

and additionally

 <- (r, m) for BMI

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[ubizjak at gmail dot com]

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

--- Comment #28 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #23)
> (The earlyclobber of non-BMI case is needed due to separate not insn).

It is not needed. I have added earlyclobber in r243202 without much thought.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[manuel.lauss at googlemail dot com]

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

--- Comment #27 from Manuel Lauss  ---
(In reply to Uroš Bizjak from comment #21)
> Following patch should fix the problem:
> 
> --cut here--
> Index: i386.md
> ===
> --- i386.md (revision 256935)
> +++ i386.md (working copy)
> @@ -9250,10 +9250,10 @@
>  })
>  
>  (define_insn "*andndi3_doubleword"
> -  [(set (match_operand:DI 0 "register_operand" "=r,")
> +  [(set (match_operand:DI 0 "register_operand" "=r,r")
> (and:DI
>   (not:DI (match_operand:DI 1 "register_operand" "r,0"))
> - (match_operand:DI 2 "nonimmediate_operand" "rm,rm")))
> + (match_operand:DI 2 "nonimmediate_operand" "r,rm")))
> (clobber (reg:CC FLAGS_REG))]
>"!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
>"#"
> --cut here--
> 
> So, the pattern now reads:
> 
> (define_insn "*andndi3_doubleword"
>   [(set (match_operand:DI 0 "register_operand" "=r,r")
>   (and:DI
> (not:DI (match_operand:DI 1 "register_operand" "r,0"))
> (match_operand:DI 2 "nonimmediate_operand" "r,rm")))
>(clobber (reg:CC FLAGS_REG))]
>   "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
>   "#"
>   [(set_attr "isa" "bmi,*")])


I rebuilt gcc-7.3 with this applied, now the generated code looks much better:
  ab:   0f ad d0shrd   %cl,%edx,%eax
  ae:   f6 c1 20test   $0x20,%cl
  b1:   c4 e2 73 f7 d2  shrx   %ecx,%edx,%edx
  b6:   0f 45 c2cmovne %edx,%eax
  b9:   0f 45 d5cmovne %ebp,%edx
  bc:   c4 e2 68 f2 54 df 04andn   0x4(%edi,%ebx,8),%edx,%edx
  c3:   89 d1   mov%edx,%ecx
  c5:   c4 e2 78 f2 04 df   andn   (%edi,%ebx,8),%eax,%eax
  cb:   09 c1   or %eax,%ecx

And it seems to work as well, 32bit llvm now built successfully.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[mike at fireburn dot co.uk]

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

--- Comment #26 from Mike Lothian  ---
Is this the patch you want us to test then:

diff -ur a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
--- a/gcc/config/i386/i386.md   2018-01-16 11:17:49.509247000 +
+++ b/gcc/config/i386/i386.md   2018-01-25 18:21:25.562225621 +
@@ -8586,7 +8586,7 @@
 (define_insn "*andndi3_doubleword"
   [(set (match_operand:DI 0 "register_operand" "=r,")
(and:DI
- (not:DI (match_operand:DI 1 "register_operand" "r,0"))
+ (not:DI (match_operand:DI 1 "register_operand" "0,0"))
  (match_operand:DI 2 "nonimmediate_operand" "rm,rm")))
(clobber (reg:CC FLAGS_REG))]
   "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

[dtrebbien at gmail dot com]

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

--- Comment #7 from Daniel Trebbien  ---
So as not to break testsuite/23_containers/vector/capacity/resize/moveable2.cc
for C++11, I decided that it would be best to keep the use of
std::__uninitialized_move_if_noexcept_a() when compiling as C++11. Please see
my proposed patch.

[Bug libstdc++/83981] vector::resize(size_type) should not require T to be CopyInsertable when std=c++14

[dtrebbien at gmail dot com]

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

--- Comment #6 from Daniel Trebbien  ---
Created attachment 43243
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43243=edit
Patch for PR 83981 and PR 83982

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #25 from Jakub Jelinek  ---
I believe for double-word pseudos the RA will not do that, CCing Vlad about it.
Anyway, by having all of r <- (r, r), r <- (0, rm) and  <- (r, m)
alternatives I'd think the RA has more choices than when it just has the first
2.
If it sees it as beneficial to have the middle operand in the destination, it
can due to the second alternative even if third one is a memory, if it wants
some other, it can, just needs to make sure the destination doesn't overlap
with mem's address.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[ubizjak at gmail dot com]

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

--- Comment #24 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #22)
> Wonder though if it wouldn't give the RA more choices by also including
> another
>  <- (r, m) alternative with bmi2 isa attribute.

This would be worse than r <- (0, m) alternative on register starved x86_32
architecture. The above approach can use up to 6 registers, while r <- (0, m)
uses up to 4.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[ubizjak at gmail dot com]

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

--- Comment #23 from Uroš Bizjak  ---
The above patch builds on the promise, that with (=r,r,r) alternative, the
register allocator won't allocate (=r1,=r2) = ~(r0,r1) & (r2,r3). This would
again clobber the r1 too early:

r1 = ~r0 & r2
r2 = ~r1 & r3

The safest choice of the pattern would be:

(define_insn "*andndi3_doubleword"
  [(set (match_operand:DI 0 "register_operand" "=r,")
(and:DI
  (not:DI (match_operand:DI 1 "register_operand" "0,0"))
  (match_operand:DI 2 "nonimmediate_operand" "rm,rm")))
   (clobber (reg:CC FLAGS_REG))]
  "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
  "#"
  [(set_attr "isa" "bmi,*")])

(The earlyclobber of non-BMI case is needed due to separate not insn).

[Bug tree-optimization/83821] local aggregate initialization defeats strlen optimization

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
(In reply to Leslie Zhai from comment #3)

In the case of mips64 (and a number of other targets) the missing optimization
is due to pr83543.

[Bug tree-optimization/84042] New: IVOPTS doesn't optimize int indexes on some PowerPC code.

[meissner at gcc dot gnu.org]

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

Bug ID: 84042
   Summary: IVOPTS doesn't optimize int indexes on some PowerPC
code.
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

This is a follow-on to PR target/81550.

In that bug, the following code generated more code.  That in turn caused the
test to fail that was looking for a loop to be 8 instructions or less to test
the TARGET_ASM_LOOP_ALIGN_MAX_SKIP target hook:

void f(double *a, double *b, double *c, int n) {
  int i;
  for (i=0; i < n; i++)
a[i] = b[i] + c[i];
}

I rewrote the test to use unsigned long instead of int so that the # of
instructions is under 8, and it validates the target hook.

But we really should fix the regression.

As per PR target/81550, the original code on powerpc little endian was:

.file   "loop_align.c"
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl f
.type   f, @function
f:
cmpwi 7,6,0
blelr 7
addi 6,6,-1
li 9,0
rldicl 6,6,0,32
addi 10,6,1
mtctr 10
.p2align 5,,31
.L3:
lfdx 0,4,9
lfdx 12,5,9
fadd 0,0,12
stfdx 0,3,9
addi 9,9,8
bdnz .L3
blr
.file   "loop_align.c"
.abiversion 2
.section".text"
.align 2
.p2align 4,,15
.globl f
.type   f, @function
f:
cmpwi 7,6,0
blelr 7
addi 6,6,-1
addi 9,4,-8
rldic 6,6,3,29
addi 5,5,-8
add 4,4,6
addi 3,3,-8
.p2align 4,,15
.L3:
lfdu 0,8(9)
lfdu 12,8(5)
cmpld 7,9,4
fadd 0,0,12
stfdu 0,8(3)
beqlr 7
lfdu 0,8(9)
lfdu 12,8(5)
cmpld 7,9,4
fadd 0,0,12
stfdu 0,8(3)
bne 7,.L3
blr

The first observation is the count down loop is no longer done (i.e. no BDNZ). 
Because it no longer is a count down loop, reorder blocks decided to clone the
block and have an early exit.  This all makes the loop to be 12 instructions,
which causes the TARGET_ASM_LOOP_ALIGN_MAX_SKIP target hook to fail.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[jakub at gcc dot gnu.org]

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

--- Comment #22 from Jakub Jelinek  ---
Will do, for now I'm including it with my normal options bootstraps (testing
other patches and need the same baseline), then will try some
--with-arch/--with-tune).
Wonder though if it wouldn't give the RA more choices by also including another
 <- (r, m) alternative with bmi2 isa attribute.

[Bug middle-end/51677] don't suggest giving main() __attribute__((const))

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
It should be easy to white-list the main function in the -Wsuggest-attribute=
checker.  At the same time, I'm not sure it's necessary or that the problem is
unique to main.  The reasons noted in comment #0 apply to other functions as
well.  Defining empty functions is useful for a variety of reasons (e.g.,
default no-op handlers or, in C++, default no-op implementations of virtual
functions).  Similarly, without perfect data flow analysis across the whole
program it's impossible to tell whether an extern function is ever called.  Why
should main be treated differently from those?

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[ubizjak at gmail dot com]

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

--- Comment #21 from Uroš Bizjak  ---
Following patch should fix the problem:

--cut here--
Index: i386.md
===
--- i386.md (revision 256935)
+++ i386.md (working copy)
@@ -9250,10 +9250,10 @@
 })

 (define_insn "*andndi3_doubleword"
-  [(set (match_operand:DI 0 "register_operand" "=r,")
+  [(set (match_operand:DI 0 "register_operand" "=r,r")
(and:DI
  (not:DI (match_operand:DI 1 "register_operand" "r,0"))
- (match_operand:DI 2 "nonimmediate_operand" "rm,rm")))
+ (match_operand:DI 2 "nonimmediate_operand" "r,rm")))
(clobber (reg:CC FLAGS_REG))]
   "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
   "#"
--cut here--

So, the pattern now reads:

(define_insn "*andndi3_doubleword"
  [(set (match_operand:DI 0 "register_operand" "=r,r")
(and:DI
  (not:DI (match_operand:DI 1 "register_operand" "r,0"))
  (match_operand:DI 2 "nonimmediate_operand" "r,rm")))
   (clobber (reg:CC FLAGS_REG))]
  "!TARGET_64BIT && TARGET_STV && TARGET_SSE2"
  "#"
  [(set_attr "isa" "bmi,*")])

Instead of using earlyclobber on the output operand (which guarantees that no
input register will be clobbered), we can use a little trick and in case of
memory operand 2, match the output with a register operand 1. This will keep
output registers separate from registers in the memory operand (and is in fact
what we do in all other _doubleword patterns).

Jakub, I don't have Haswell target to test BMI instructions via native
bootstrap, can you perhaps bootstrap the compiler with the above patch?

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[manuel.lauss at googlemail dot com]

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

--- Comment #20 from Manuel Lauss  ---
Created attachment 43242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43242=edit
preprocessed source

preprocessed source of file that contains the function
"llvm::TypeInfer::EnforceSmallerThan", compressed due it being 2.5MB.

The Makefile builds it with these parameters: (stripped the includes)
g++ -m32 -O3 -ggdb -march=znver1 -mtune=broadwell -pipe -fPIC
-fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
-ffunction-sections -fdata-sections

[Bug target/83862] powerpc: ICE in signbit testcase

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #6 from Michael Meissner  ---
Fixed in trunk, back ported to GCC 6 and GCC 7 branches.

[Bug target/83862] powerpc: ICE in signbit testcase

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  ---
Author: meissner
Date: Thu Jan 25 17:36:47 2018
New Revision: 257060

URL: https://gcc.gnu.org/viewcvs?rev=257060=gcc=rev
Log:
[gcc]
2018-01-25  Michael Meissner  

Back port from trunk
2018-01-22  Michael Meissner  

PR target/83862
* config/rs6000/rs6000-protos.h (rs6000_split_signbit): Delete,
no longer used.
* config/rs6000/rs6000.c (rs6000_split_signbit): Likewise.
* config/rs6000/rs6000.md (signbit2): Change code for IEEE
128-bit to produce an UNSPEC move to get the double word with the
signbit and then a shift directly to do signbit.
(signbit2_dm): Replace old IEEE 128-bit signbit
implementation with a new version that just does either a direct
move or a regular move.  Move memory interface to separate insns.
Move insns so they are next to the expander.
(signbit2_dm_mem_be): New combiner insns to combine load
with signbit move.  Split big and little endian case.
(signbit2_dm_mem_le): Likewise.
(signbit2_dm_ext): Delete, no longer used.
(signbit2_dm2): Likewise.

[gcc/testsuite]
2018-01-25  Michael Meissner  

Back port from trunk
2018-01-22  Michael Meissner  

PR target/83862
* gcc.target/powerpc/pr83862.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr83862.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000-protos.h
branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
branches/gcc-7-branch/gcc/config/rs6000/rs6000.md
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Haven't managed to reproduce it e.g. with
long long
foo (long long *p, int q, unsigned r1, unsigned r2)
{
  int t, u;
  asm ("" : "+a" (p), "+b" (q), "+d" (r1), "+c" (r2), "=S" (t), "=D" (u));
  unsigned long long r = ((unsigned long long) r2 << 32) | r1;
  long long a = p[q] & ~r;
  asm volatile ("" : "+A" (a) : "S" (t), "D" (u));
  return a;
}

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

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  ---
Author: hubicka
Date: Thu Jan 25 17:24:06 2018
New Revision: 257059

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

PR middle-end/83055
* predict.c (drop_profile): Do not push/pop cfun; update also
node->count.
(handle_missing_profiles): Fix logic looking for zero profiles.

* gcc.dg/torture/pr83055.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr83055.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/predict.c
trunk/gcc/testsuite/ChangeLog

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #18 from Jakub Jelinek  ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Manuel Lauss from comment #16)
> >0x080a96c3 <+1347>:  andn   (%eax,%ebx,8),%edx,%eax
> > => 0x080a96c9 <+1353>:  andn   0x4(%eax,%ebx,8),%ecx,%edx
> 
> This looks like double-word andn is clobbering %eax too early.

Yeah.  In that case, can you please attach the preprocessed source of whatever
source contains that and g++ command line options used to compile that?
Thanks.

[Bug rtl-optimization/83985] [8 Regression] Compile time hog for 32-bit BE powerpc targets

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
In the end this was really caused by r241060.
Not deleting unmarked insn is a bad idea, because we might not have marked any
instructions it needs, so instead we need to mark such instructions as not
deletable and let the DCE pass do its magic.

[Bug rtl-optimization/83985] [8 Regression] Compile time hog for 32-bit BE powerpc targets

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.