[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

Re: [PATCH, wwwdocs] Update GCC 8 release notes for NDS32 port

[Chung-Ju Wu]

Gerald Pfeifer on 2018/1/23 22:39 wrote:

On Tue, 23 Jan 2018, Chung-Ju Wu wrote:

+New command-line options -mext-perf -mext-perf2 -mext-string


Can you write this as

   "...-mext-perf, -mext-perf2, and
   -mext-string..."

please?

Approved with that change.



Thank you for the review. :)

I made the change and committed it as revision 1.33 of 
htdosc/gcc-8/changes.html.


Best regards,
jasonwucj



Gerald

[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$

Re: [PATCH] Fix various x86 avx512{bitalg, vpopcntdq, vbmi2} issues (PR target/83488)

[Kirill Yukhin]

Hello Julia,
On 24 Jan 14:00, Koval, Julia wrote:
> Hi,
> Fixed it. Ok for trunk?
> 
> gcc/
>   * config/i386/avx512bitalgintrin.h (_mm512_bitshuffle_epi64_mask,
>   _mm512_mask_bitshuffle_epi64_mask, _mm256_bitshuffle_epi64_mask,
>   _mm256_mask_bitshuffle_epi64_mask, _mm_bitshuffle_epi64_mask,
>   _mm_mask_bitshuffle_epi64_mask): Fix type.
>   * config/i386/i386-builtin-types.def (UHI_FTYPE_V2DI_V2DI_UHI,
>   USI_FTYPE_V4DI_V4DI_USI): Remove.
>   * config/i386/i386-builtin.def (__builtin_ia32_vpshufbitqmb512_mask,
>   __builtin_ia32_vpshufbitqmb256_mask,
>   __builtin_ia32_vpshufbitqmb128_mask): Fix types.
>   * config/i386/i386.c (ix86_expand_args_builtin): Remove old types.
>   * config/i386/sse.md (VI1_AVX512VLBW): Change types.
> 
> gcc/testsuite/
>   * gcc.target/i386/avx512bitalg-vpshufbitqmb-1.c: Add -mavx512f 
> -mavx512bw.
>   * gcc.target/i386/avx512bitalgvl-vpshufbitqmb-1.c: Add -mavx512bw.
>   * gcc.target/i386/i386.exp: Fix types.
Your patch is OK for trunk. I've checked it in.

--
Thanks, K
> 
> Thanks,
> Julia
> 
> > -Original Message-
> > From: Kirill Yukhin [mailto:kirill.yuk...@gmail.com]
> > Sent: Saturday, January 20, 2018 11:49 AM
> > To: Koval, Julia 
> > Cc: 'Jakub Jelinek' ; 'Uros Bizjak' ;
> > 'GCC Patches' 
> > Subject: Re: [PATCH] Fix various x86 avx512{bitalg, vpopcntdq, vbmi2} 
> > issues (PR
> > target/83488)
> > 
> > Hello Julia,
> > On 12 Jan 08:55, Koval, Julia wrote:
> > > Changelog
> > >
> > > gcc/
> > >   * config/i386/avx512bitalgintrin.h (_mm512_bitshuffle_epi64_mask,
> > >   _mm512_mask_bitshuffle_epi64_mask,
> > _mm256_bitshuffle_epi64_mask,
> > >   _mm256_mask_bitshuffle_epi64_mask, _mm_bitshuffle_epi64_mask,
> > >   _mm_mask_bitshuffle_epi64_mask): Fix type.
> > >   * config/i386/i386-builtin-types.def (UHI_FTYPE_V2DI_V2DI_UHI,
> > >   USI_FTYPE_V4DI_V4DI_USI): Remove.
> > >   * config/i386/i386-builtin.def (__builtin_ia32_vpshufbitqmb512_mask,
> > >   __builtin_ia32_vpshufbitqmb256_mask,
> > >   __builtin_ia32_vpshufbitqmb128_mask): Fix types.
> > >   * config/i386/i386.c (ix86_expand_args_builtin): Remove old types.
> > >   * config/i386/sse.md (VI48_AVX512VLBW): Change types.
> > >
> > > gcc/testsuite/
> > >   * gcc.target/i386/avx512bitalg-vpshufbitqmb-1.c: Add -mavx512f -
> > mavx512bw.
> > >   * gcc.target/i386/avx512bitalgvl-vpshufbitqmb-1.c: Add -mavx512bw.
> > >   * gcc.target/i386/i386.exp: Fix types.
> > 
> >  (define_mode_iterator VI48_AVX512VLBW
> > -  [(V8DI "TARGET_AVX512BW") (V4DI  "TARGET_AVX512VL")
> > -   (V2DI  "TARGET_AVX512VL")])
> > +  [(V64QI "TARGET_AVX512BW") (V32QI  "TARGET_AVX512VL")
> > +   (V16QI  "TARGET_AVX512VL")])
> > I'd call this iterator VI1_AVX512VLBW.
> > 
> > --
> > Thanks, K
> 

[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.

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Peter Bergner]

On 1/25/18 3:56 PM, Peter Bergner wrote:
> Ok, I'll move the table to driver-rs6000.c and I'll resubmit.

Ok, here is a separate translation table like you wanted.  I still use the
RS6000_CPU table to hold entire list of canonical cpu names, the new
translation table in driver-rs6000.c only contains cpus whose AT_PLATFORM
names do not match their GCC canonical names.  I also added the pa6t to
970 translation you mentioned in the bugzilla.  If you want me to drop
that, that's easy enough to do.

I realize I also failed to mention in the first submission, that I have
added caching of the elf_plaform() result, so we don't have to mount and
scan /proc/self/auxv multiple times.

Is this better?  I did the same unit testing by forcing unknown names
and names that need translation and I've verified it works.  Bootstrap
and regtesting is still running though.

Peter

PR target/56010
PR target/83743
* config/rs6000/driver-rs6000.c: #include "diagnostic.h".
(rs6000_supported_cpu_names): New static variable.
(linux_cpu_translation_table): Likewise.
(elf_platform) : Define new static variable and use it.
Translate kernel AT_PLATFORM name to canonical name if needed.
Error if platform name is unknown.

Index: gcc/config/rs6000/driver-rs6000.c
===
--- gcc/config/rs6000/driver-rs6000.c   (revision 256364)
+++ gcc/config/rs6000/driver-rs6000.c   (working copy)
@@ -23,6 +23,7 @@
 #include "system.h"
 #include "coretypes.h"
 #include "tm.h"
+#include "diagnostic.h"
 #include 
 
 #ifdef _AIX
@@ -38,6 +39,44 @@
 # include 
 #endif
 
+#ifdef __linux__
+/* Canonical GCC cpu name table.  */
+static const char *rs6000_supported_cpu_names[] =
+{
+#define RS6000_CPU(NAME, CPU, FLAGS) NAME,
+#include "rs6000-cpus.def"
+#undef RS6000_CPU
+};
+
+/* This table holds a list of cpus where their Linux AT_PLATFORM name differs
+   from their GCC canonical name.  The first column in a row contains the GCC
+   canonical cpu name and the other columns in that row contain AT_PLATFORM
+   names that should be mapped to the canonical name.  */
+
+static const char *linux_cpu_translation_table[][4] = {
+  { "403", "ppc403", NULL },
+  { "405", "ppc405", NULL },
+  { "440", "ppc440", "ppc440gp", NULL },
+  { "476", "ppc470", NULL },
+  { "601", "ppc601", NULL },
+  { "603", "ppc603", NULL },
+  { "604", "ppc604", NULL },
+  { "7400", "ppc7400", NULL },
+  { "7450", "ppc7450", NULL },
+  { "750", "ppc750", NULL },
+  { "823", "ppc823", NULL },
+  { "8540", "ppc8540", NULL },
+  { "8548", "ppc8548", NULL },
+  { "970", "ppc970", "pa6t", NULL },
+  { "cell", "ppc-cell-be", NULL },
+  { "e500mc", "ppce500mc", NULL },
+  { "e5500", "ppce5500", NULL },
+  { "e6500", "ppce6500", NULL },
+  { "power7", "power7+", NULL },
+  { NULL } /* End of table sentinel.  */
+};
+#endif
+
 const char *host_detect_local_cpu (int argc, const char **argv);
 
 #if GCC_VERSION >= 0
@@ -158,15 +197,19 @@
 
 #ifdef __linux__
 
-/* Returns AT_PLATFORM if present, otherwise generic PowerPC.  */
+/* Returns the canonical AT_PLATFORM if present, otherwise NULL.  */
 
 static const char *
 elf_platform (void)
 {
-  int fd;
+  static const char *cpu = NULL;
 
-  fd = open ("/proc/self/auxv", O_RDONLY);
+  /* Use the cached AT_PLATFORM cpu name if we've already determined it.  */
+  if (cpu != NULL)
+return cpu;
 
+  int fd = open ("/proc/self/auxv", O_RDONLY);
+
   if (fd != -1)
 {
   char buf[1024];
@@ -179,15 +222,60 @@
   if (n > 0)
{
  for (av = (ElfW(auxv_t) *) buf; av->a_type != AT_NULL; ++av)
-   switch (av->a_type)
+   if (av->a_type == AT_PLATFORM)
  {
- case AT_PLATFORM:
-   return (const char *) av->a_un.a_val;
-
- default:
+   cpu = (const char *) av->a_un.a_val;
break;
  }
}
+
+  /* Verify that CPU is either a valid -mcpu= option name, or is a
+valid alternative name.  If it is a valid alternative name, then use
+the canonical name.  */
+  if (cpu != NULL)
+   {
+ size_t i, j, len = 0;
+ char *s, *p;
+
+ /* Check if AT_PLATFORM is a GCC canonical cpu name.  */
+ for (i = 0; i < ARRAY_SIZE (rs6000_supported_cpu_names); i++)
+   {
+ if (!strcmp (cpu, rs6000_supported_cpu_names[i]))
+   return cpu;
+ len += strlen (rs6000_supported_cpu_names[i]) + 1;
+   }
+
+ /* Check if AT_PLATFORM can be translated to a canonical cpu name.  */
+ for (i = 0; linux_cpu_translation_table[i][0] != NULL; i++)
+   {
+ const char *canonical = linux_cpu_translation_table[i][0];
+ for (j = 1; linux_cpu_translation_table[i][j] != NULL; j++)
+   if (!strcmp (cpu, linux_cpu_translation_table[i][j]))
+ {
+   cpu = canonical;
+

[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

[PATCH] restore -Warray-bounds for string literals (PR 83776)

[Martin Sebor]

PR tree-optimization/83776 - [6/7/8 Regression] missing
-Warray-bounds indexing past the end of a string literal,
identified a not-so-recent improvement to constant propagation
as the reason for GCC no longer being able to detect out-of-
bounds accesses to string literals.  The root cause is that
the change caused accesses to strings to be transformed into
MEM_REFs that the -Warray-bounds checker isn't prepared to
handle.  A simple example is:

  int h (void)
  {
const char *p = "1234";
return p[16];   // missing -Warray-bounds
  }

To fix the regression the attached patch extends the array bounds
checker to handle the small subset of MEM_REF expressions that
refer to string literals but stops of short of doing more than
that.  There are outstanding gaps in the detection that the patch
intentionally doesn't handle.  They are either caused by other
regressions (PR 84047) or by other latent bugs/limitations, or
by limitations in the approach I took to try to keep the patch
simple.  I hope to address some of those in a follow-up patch
for GCC 9.

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

gcc/ChangeLog:

	PR tree-optimization/83776
	* tree-vrp.c (vrp_prop::check_mem_ref): New function.
	(check_array_bounds): Call it.

gcc/testsuite/ChangeLog:

	PR tree-optimization/83776
	* gcc.dg/Warray-bounds-27.c: New test.
	* gcc.dg/Warray-bounds-28.c: New test.
	* gcc.dg/Warray-bounds-29.c: New test.

diff --git a/gcc/testsuite/gcc.dg/Warray-bounds-27.c b/gcc/testsuite/gcc.dg/Warray-bounds-27.c
new file mode 100644
index 000..ccc88cd
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Warray-bounds-27.c
@@ -0,0 +1,223 @@
+/* PR tree-optimization/83776: missing -Warray-bounds indexing past the end
+   of a string literal
+   Test to exercise detection of out-of-bounds indices into narrow string
+   literals.
+   { dg-do compile }
+   { dg-options "-O2 -Warray-bounds -ftrack-macro-expansion=0" } */
+
+#include "range.h"
+
+#define MAX DIFF_MAX
+#define MIN DIFF_MIN
+
+#define S1 "1"
+#define S3 "123"
+#define S7 "1234567"
+#define S8 "12345678"
+#define S9 "123456789"
+
+void sink (int, ...);
+
+#define T(expr)   sink (0, expr)
+
+
+void narrow_direct_cst (void)
+{
+  T (S1[MIN]);/* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .char\\\[2]" "" { xfail *-*-* } } */
+  T (S1[-1]); /* { dg-warning "array subscript -1 is below array bounds of .char\\\[2]" } */
+  T (S1[0]);
+  T (S1[1]);
+  T (S1[2]);  /* { dg-warning "array subscript 2 is above array bounds of .char\\\[2]" } */
+  T (S1[MAX]);/* { dg-warning "array subscript \[0-9\]+ is above array bounds of .char\\\[2]" } */
+
+  T ([MIN]);   /* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .char\\\[2]" } */
+  T ([-1]);/* { dg-warning "array subscript -1 is below array bounds of .char\\\[2]" } */
+  T ([0]);
+  T ([2]);
+  T ([3]); /* { dg-warning "array subscript 3 is above array bounds of .char\\\[2]" } */
+  T ([MAX]);   /* { dg-warning "array subscript \[0-9\]+ is above array bounds of .char\\\[2]" } */
+
+  T (S9[MIN]);/* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .char\\\[10]" "" { xfail *-*-* } } */
+  T (S9[-1]); /* { dg-warning "array subscript -1 is below array bounds of .char\\\[10]" } */
+  T (S9[9]);
+  T (S9[10]); /* { dg-warning "array subscript 10 is above array bounds of .char\\\[10]" } */
+  T (S9[11]); /* { dg-warning "array subscript 11 is above array bounds of .char\\\[10]" } */
+  T (S9[MAX]);/* { dg-warning "array subscript \[0-9\]+ is above array bounds of .char\\\[10]" } */
+
+  T ([MIN]);   /* { dg-warning "array subscript -\[0-9\]+ is below array bounds of .char\\\[10]" } */
+  T ([-1]);/* { dg-warning "array subscript -1 is below array bounds of .char\\\[10]" } */
+  T ([9]);
+  T ([10]);
+  T ([11]); /* { dg-warning "array subscript 11 is above array bounds of .char\\\[10]" } */
+  T ([MAX]);   /* { dg-warning "array subscript \[0-9\]+ is above array bounds of .char\\\[10]" } */
+}
+
+void narrow_ptr_deref_cst (void)
+{
+  const char *p = S8 + 9;
+
+  T (*(p + MIN)); /* { dg-warning "array subscript -\[0-9\]+ is outside array bounds of .char\\\[9]." } */
+  T (*(p - 10));  /* { dg-warning "array subscript -1 is outside array bounds of .char\\\[9]." } */
+  T (*(p - 9));
+  T (*(p - 1));
+  T (*p); /* { dg-warning "array subscript 9 is outside array bounds of .char\\\[9]." } */
+  T (*(p + 1));   /* { dg-warning "array subscript 10 is outside array bounds of .char\\\[9]." } */
+  T (*(p + 2));   /* { dg-warning "array subscript 11 is outside array bounds of .char\\\[9]." } */
+}
+
+void 

[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?

Re: GCC 7.3 Released

[bojanowski]

Hi Richard
Please let me know if you have any knowledge about compiler used to this 
project

I had some info they use gnu compiler before the change name sincerley chris
http://www.samsung.com/global/business/telecommunication-systems/resource/opensource/ip-set-top-box.html
 SMT-6010E SMT-6010E_OpenSource.zip

info from inside procesor bsp-15 mapca mapca1000a equator 
/pixelworks/hitachi japan VLIW



###
### Equator Technologies, Inc.
###

###
### Module name  : $RCSfile: Makefile.ETI,v $ $Revision: 1.2 $
###
### Last update  : $Date: 2005/06/16 13:46:21 $ UTC
###

#
# Default Settings

ETI_INSTALL := $(HOME)/build/eti_tools/v6.0/install
ETI_TOOLKIT := $(HOME)/build/eti_tools/v6.0/install
ETI_REFERENCE_INSTALL := $(HOME)/build/eti_tools/v6.0/install

WORKSPACE := $(shell pwd)
export HOST_ARCH  := i686
export HOST_PLATFORM  := Linux

ARCH   := BSP
PLATFORM   := Linux

###
# Configurations
# (see arch/bsp/configs/README)

# Default Configuration
# e.g. Dolphin
#ETI_CONFIGURATION  := PCIMASTER_NORD
# e.g. Stingray
#ETI_CONFIGURATION  := NOPCIMASTER_NORD
# e.g. Dolphin/Tetra with tinykernel
#By Changlae Jo
# We will use Ramdisk
ETI_CONFIGURATION  := PCIMASTER_RD
# e.g. Starfish
#ETI_CONFIGURATION  := STARFISH_NORD

PCIMASTER_NORD_VMLINUX:= vmlinux.out vmlinux.l2sei vmlinux.flashsei
NOPCIMASTER_NORD_VMLINUX  := vmlinux.out vmlinux.l2sei
PCIMASTER_RD_VMLINUX  := vmlinux.l2sei vmlinux.flashsei
STARFISH_NORD_VMLINUX := vmlinux.out vmlinux.l2sei

DOT_CONFIG := $(ETI_CONFIGURATION)_.config
AUTOCONF_H := $(ETI_CONFIGURATION)_autoconf.h
VMLINUX:= $($(ETI_CONFIGURATION)_VMLINUX)


# Modules for rootfilesystem
# By Changlae Jo.
#TINYROOTFS_ETI_MODULES := \
# 
$(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/boardSupportDev.o 
\
# 
$(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/noncoregpDev.o 
\

# $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/flash.o

#TINYROOTFS_LINUX_MODULES := \
# $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/fat.o \
# $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/vfat.o \
# $(ETI_REFERENCE_INSTALL)/BSP_Linux/tinyrootfs/lib/modules/2.2.20/msdos.o


# Dependencies
.PHONY  : check tinyrootfs_prep configure build install 
install.headers clean


ifeq ($(ETI_CONFIGURATION),PCIMASTER_NORD)
all : check configure install.headers build.modules build 
install.modules install post.install

else
# Do not install headers for non-PCI master builds.
all : check configure build install
endif

# Prepare tinyrootfs. Copy necessary file to it
ifeq ($(ETI_CONFIGURATION),PCIMASTER_RD)
build: tinyrootfs_prep
tinyrootfs_prep  : $(TINYROOTFS_ETI_MODULES) $(TINYROOTFS_LINUX_MODULES)
$(TINYROOTFS_LINUX_MODULES) : build.modules
endif

ifdef ETIQADEPS
configure  : check
install.headers: configure
build.modules  : configure
build  : configure
install.modules: build.modules
install: build
endif



# Verbosity, debug etc.
ifeq ($(VERBOSEBUILD),)
   .SILENT :
endif

##
# Exports
BSP_Linux_CC := $(ETI_TOOLKIT)/$(HOST_ARCH)_$(HOST_PLATFORM)/bin/ecc

export CC :=  $($(ARCH)_$(PLATFORM)_CC) -D__KERNEL__
export LD :=  `$(CC) -print-prog-name=ld`
export NM :=  `$(CC) -print-prog-name=nm`
export AS :=  $(CC)
export CPP :=  $(CC) -E

# Root filesystem for tiny kernel gets picked up from here:
ETI_REFERENCE_INSTALL = /h/qa/build/eti_tools/latest

###
# Rules

##
configure:
ifdef ETIQABUILD
$(MAKE) -f Makefile xconfig  > /dev/null 2>&1 &
sleep 5
cp $(WORKSPACE)/arch/bsp/configs/$(DOT_CONFIG) $(WORKSPACE)/.config
cp $(WORKSPACE)/arch/bsp/configs/$(AUTOCONF_H) 
$(WORKSPACE)/include/linux/autoconf.h

else
# $(MAKE) -f Makefile xconfig
# by Changlae Jo
$(MAKE) -f Makefile menuconfig
endif
$(MAKE) -f Makefile dep

build.modules:
$(MAKE) -C $(WORKSPACE) -f Makefile modules

build:
$(MAKE) -C $(WORKSPACE) -f Makefile $(VMLINUX)

##
install.headers:
$(MAKE) -C $(WORKSPACE) -f Makefile 
$(WORKSPACE)/include/linux/modversions.h

echo "Copying Linux header files"
mkdir -p $(ETI_INSTALL)/BSP_Linux/include
cd $(WORKSPACE)/include; /bin/tar --exclude CVS -czf - linux asm asm-bsp | 
\

(cd $(ETI_INSTALL)/BSP_Linux/include; /bin/tar -xzf -)

install.modules:
mkdir -p $(ETI_INSTALL)/BSP_Linux/rootfs;   \
$(MAKE) -C $(WORKSPACE) -f Makefile  \
 INSTALL_MOD_PATH=$(ETI_INSTALL)/BSP_Linux/rootfs \
 modules_install;   \
rm -f $(ETI_INSTALL)/BSP_Linux/rootfs/lib/modules/2.2.20/build

install:
if [ ! -f $(WORKSPACE)/arch/bsp/boot/vmlinux.out ];then\
  ln -s $(WORKSPACE)/vmlinux.out $(WORKSPACE)/arch/bsp/boot/vmlinux.out; \
fi
mkdir -p $(ETI_INSTALL)/util/linux_kernel/$(ETI_CONFIGURATION)
install -D -m 444 $(WORKSPACE)/arch/bsp/configs/README 

[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.

Re: [PATCH] PR libgcc/59714 complex division is surprising on aarch64

[Joseph Myers]

On Thu, 25 Jan 2018, vladimir.mezent...@oracle.com wrote:

> From: Vladimir Mezentsev 
> 
> Tested on aarch64-linux-gnu, x86_64-pc-linux-gnu and 
> sparc64-unknown-linux-gnu.
> No regression. New tests now passed.
> There is a performance degradation for complex double type:

This is, of course, something to consider for GCC 9; it's not suitable for 
the current development stage.

Could you provide a more extended writeup of the issue (starting with the 
argument for it being a bug at all), the approach you took and the 
rationale for the approach, when you resubmit the patch for GCC 9 stage 1?

> * libgcc/config/sparc/sfp-machine.h: New

Are you introducing a requirement for all architectures to provide 
sfp-machine.h?  If so, did you determine that SPARC was the only one 
lacking it?  If not the only one lacking it, you need to make sure that 
you do not break any existing architecture in GCC.

What about architectures using non-IEEE formats?  soft-fp is not suitable 
for those, but you mustn't break them.  Remember that e.g. TFmode can be 
IBM long double, and other ?Fmode similarly need not be IEEE; the name 
only indicates how many bytes are in the format, nothing else about it.

What about powerpc __divkc3?

What was the rationale for using soft-fp rather than adding appropriate 
built-in functions as suggested in a comment?

These are the sorts of issues you need to cover in your patch write-up, to 
demonstrate that you have allowed for the range of targets supported in 
GCC, have taken care to avoid breaking them and have made deliberate 
choices that are appropriate in each case (but might not be the same for 
every target).

> +static inline int get_cde(int c, int d)

Lots of the new functions need comments on them to explain their 
semantics.  Also, the formatting needs fixing to follow the GNU Coding 
Standards ("static inline int" on its own line, space before '(').

> +  if (cde != 0) {

Similarly, bad formatting, "{" goes on the next line.

-- 
Joseph S. Myers
jos...@codesourcery.com

[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

Re: [PATCH] Fix RTL DCE with separate shrink wrapped epilogues (PR rtl-optimization/83985)

[Segher Boessenkool]

On Thu, Jan 25, 2018 at 11:20:33PM +0100, Jakub Jelinek wrote:
> Hi!
> 
> The r241060 change added the second hunk in this patch which the patch is
> reverting.  The problem is that not deleting some unmarked insns in
> delete_unmarked_insns is done in a wrong place, it causes indeed not to
> delete the instruction we don't want to DCE, but the instructions that
> are needed by the instructions (in this case a memory load whose result
> the REG_CFA_RESTORE instruction uses) are not marked either and those are
> deleted.
> 
> The following patch fixes it by making such instructions non-deletable,
> which means they are marked and the DCE algorithm then marks the
> instructions they need too.

Looks good to me!  Thanks.  And sorry for causing the bug in the first
place :-/


Segher

[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?

Go patch committed: Look through aliases when looking for methods

[Ian Lance Taylor]

This patch to the Go frontend fixes it to look through aliases when
looking for methods.  The code is simplified by adding Type::is_alias
to do this, replacing a few existing loops.  This fixes
https://golang.org/issue/23489.  The test case for this is
https://golang.org/cl/89935.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 257068)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-203cbe7d3820fa03c965a01f72461f71588fe952
+897ce971b06a39c217d02dce9e1361bc7a240188
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc  (revision 257033)
+++ gcc/go/gofrontend/types.cc  (working copy)
@@ -107,6 +107,34 @@ Type::forwarded() const
   return t;
 }
 
+// Skip alias definitions.
+
+Type*
+Type::unalias()
+{
+  Type* t = this->forwarded();
+  Named_type* nt = t->named_type();
+  while (nt != NULL && nt->is_alias())
+{
+  t = nt->real_type()->forwarded();
+  nt = t->named_type();
+}
+  return t;
+}
+
+const Type*
+Type::unalias() const
+{
+  const Type* t = this->forwarded();
+  const Named_type* nt = t->named_type();
+  while (nt != NULL && nt->is_alias())
+{
+  t = nt->real_type()->forwarded();
+  nt = t->named_type();
+}
+  return t;
+}
+
 // If this is a named type, return it.  Otherwise, return NULL.
 
 Named_type*
@@ -333,15 +361,9 @@ Type::are_identical_cmp_tags(const Type*
   return errors_are_identical ? true : t1 == t2;
 }
 
-  // Skip defined forward declarations.
-  t1 = t1->forwarded();
-  t2 = t2->forwarded();
-
-  // Ignore aliases for purposes of type identity.
-  while (t1->named_type() != NULL && t1->named_type()->is_alias())
-t1 = t1->named_type()->real_type()->forwarded();
-  while (t2->named_type() != NULL && t2->named_type()->is_alias())
-t2 = t2->named_type()->real_type()->forwarded();
+  // Skip defined forward declarations.  Ignore aliases.
+  t1 = t1->unalias();
+  t2 = t2->unalias();
 
   if (t1 == t2)
 return true;
@@ -1197,9 +1219,7 @@ Type::finish_backend(Gogo* gogo, Btype *
 Bexpression*
 Type::type_descriptor_pointer(Gogo* gogo, Location location)
 {
-  Type* t = this->forwarded();
-  while (t->named_type() != NULL && t->named_type()->is_alias())
-t = t->named_type()->real_type()->forwarded();
+  Type* t = this->unalias();
   if (t->type_descriptor_var_ == NULL)
 {
   t->make_type_descriptor_var(gogo);
@@ -1648,10 +1668,10 @@ Type::type_functions(Gogo* gogo, Named_t
 Function_type* equal_fntype, Named_object** hash_fn,
 Named_object** equal_fn)
 {
-  // If this loop leaves NAME as NULL, then the type does not have a
-  // name after all.
-  while (name != NULL && name->is_alias())
-name = name->real_type()->named_type();
+  // If the unaliased type is not a named type, then the type does not
+  // have a name after all.
+  if (name != NULL)
+name = name->unalias()->named_type();
 
   if (!this->is_comparable())
 {
@@ -2370,9 +2390,7 @@ static const int64_t max_ptrmask_bytes =
 Bexpression*
 Type::gc_symbol_pointer(Gogo* gogo)
 {
-  Type* t = this->forwarded();
-  while (t->named_type() != NULL && t->named_type()->is_alias())
-t = t->named_type()->real_type()->forwarded();
+  Type* t = this->unalias();
 
   if (!t->has_pointer())
 return gogo->backend()->nil_pointer_expression();
@@ -11494,9 +11512,9 @@ Type::find_field_or_method(const Type* t
   std::string* ambig2)
 {
   // Named types can have locally defined methods.
-  const Named_type* nt = type->named_type();
+  const Named_type* nt = type->unalias()->named_type();
   if (nt == NULL && type->points_to() != NULL)
-nt = type->points_to()->named_type();
+nt = type->points_to()->unalias()->named_type();
   if (nt != NULL)
 {
   Named_object* no = nt->find_local_method(name);
Index: gcc/go/gofrontend/types.h
===
--- gcc/go/gofrontend/types.h   (revision 256593)
+++ gcc/go/gofrontend/types.h   (working copy)
@@ -676,6 +676,15 @@ class Type
   const Type*
   forwarded() const;
 
+  // Return the type skipping any alias definitions and any defined
+  // forward declarations.  This is like forwarded, but also
+  // recursively expands alias definitions to the aliased type.
+  Type*
+  unalias();
+
+  const Type*
+  unalias() const;
+
   // Return true if this is a basic type: a type which is not composed
   // of other types, and is not void.
   bool

Re: Go patch committed: Rationalize external symbol names

[Ian Lance Taylor]

On Thu, Jan 25, 2018 at 12:50 PM, Rainer Orth
 wrote:
>
>> From the error messages I guess the problem is that the assembler
>> doesn't like symbols that start with ".1".  Do you know what names the
>> assembler permits?
>
> The x86 Assembly Language Reference Manual states:

Thanks.  Looking back, it was actually not my plan to have symbols
that start with '.'.  It was a bug, fixed by this patch.  Bootstrapped
and ran Go testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 257061)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-553e04735d1be372c596c720bcaea27e050b13a6
+203cbe7d3820fa03c965a01f72461f71588fe952
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/go-encode-id.cc
===
--- gcc/go/gofrontend/go-encode-id.cc   (revision 257033)
+++ gcc/go/gofrontend/go-encode-id.cc   (working copy)
@@ -104,6 +104,14 @@ go_encode_id(const std::string )
   std::string ret;
   const char* p = id.c_str();
   const char* pend = p + id.length();
+
+  // A leading ".0" is a space introduced before a mangled type name
+  // that starts with a 'u' or 'U', to avoid confusion with the
+  // mangling used here.  We don't need a leading ".0", and we don't
+  // want symbols that start with '.', so remove it.
+  if (p[0] == '.' && p[1] == '0')
+p += 2;
+
   while (p < pend)
 {
   unsigned int c;
@@ -115,16 +123,19 @@ go_encode_id(const std::string )
  go_assert(!char_needs_encoding(c));
  ret += c;
}
-  else if (c < 0x1)
-   {
- char buf[16];
- snprintf(buf, sizeof buf, "..u%04x", c);
- ret += buf;
-   }
   else
{
  char buf[16];
- snprintf(buf, sizeof buf, "..U%08x", c);
+ if (c < 0x1)
+   snprintf(buf, sizeof buf, "..u%04x", c);
+ else
+   snprintf(buf, sizeof buf, "..U%08x", c);
+
+ // We don't want a symbol to start with '.', so add a prefix
+ // if needed.
+ if (ret.empty())
+   ret += '_';
+
  ret += buf;
}
   p += len;
Index: gcc/go/gofrontend/names.cc
===
--- gcc/go/gofrontend/names.cc  (revision 257033)
+++ gcc/go/gofrontend/names.cc  (working copy)
@@ -213,7 +213,7 @@ Gogo::function_asm_name(const std::strin
 {
   std::string ret;
   if (rtype != NULL)
-ret = rtype->mangled_name(this);
+ret = rtype->deref()->mangled_name(this);
   else if (package == NULL)
 ret = this->pkgpath_symbol();
   else
@@ -892,14 +892,7 @@ Named_type::append_mangled_type_name(Gog
  const Typed_identifier* rcvr =
this->in_function_->func_value()->type()->receiver();
  if (rcvr != NULL)
-   {
- std::string m = rcvr->type()->mangled_name(gogo);
- // Turn a leading ".1" back into "*" since we are going
- // to type-mangle this name again.
- if (m.compare(0, 2, ".1") == 0)
-   m = "*" + m.substr(2);
- ret->append(m);
-   }
+   ret->append(rcvr->type()->deref()->mangled_name(gogo));
  else if (this->in_function_->package() == NULL)
ret->append(gogo->pkgpath_symbol());
  else
@@ -956,7 +949,7 @@ Gogo::type_descriptor_name(Type* type, N
  const Typed_identifier* rcvr =
in_function->func_value()->type()->receiver();
  if (rcvr != NULL)
-   ret.append(rcvr->type()->mangled_name(this));
+   ret.append(rcvr->type()->deref()->mangled_name(this));
  else if (in_function->package() == NULL)
ret.append(this->pkgpath_symbol());
  else
Index: libgo/testsuite/gotest
===
--- libgo/testsuite/gotest  (revision 256593)
+++ libgo/testsuite/gotest  (working copy)
@@ -518,7 +518,7 @@ localname() {
pattern='Test([^a-z].*)?'
# The -p option tells GNU nm not to sort.
# The -v option tells Solaris nm to sort by value.
-   tests=$($NM -p -v _gotest_.o $xofile | egrep " $text .*\."$pattern'$' | 
grep -v '\..*\..*\.' | fgrep -v '$' | fgrep -v ' __go_' | sed 's/.* //' | 
$symtogo)
+   tests=$($NM -p -v _gotest_.o $xofile | egrep " $text .*\."$pattern'$' | 
grep -v '\..*\.' | fgrep -v '$' | fgrep -v ' __go_' | sed 's/.* //' | $symtogo)
if [ "x$tests" = x ]; then
echo 'gotest: warning: no tests matching '$pattern in 
_gotest_.o $xofile 1>&2
exit 2
Index: libgo/go/runtime/pprof/pprof_test.go
===
--- libgo/go/runtime/pprof/pprof_test.go

[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

Re: [C++ PATCH] Fix constexpr handling of arrays with unknown bound (PR c++/83993)

[Jakub Jelinek]

On Thu, Jan 25, 2018 at 01:13:56PM -0700, Martin Sebor wrote:
> On 01/24/2018 04:19 PM, Jakub Jelinek wrote:
> > Hi!
> > 
> > In constexpr evaluation of array references for arrays with unknown bounds,
> > we need to diagnose out of bounds accesses, but really don't know the bounds
> > at compile time, right now GCC will see nelts as error_mark_node + 1 and
> > will not consider them a constant expression at all.
> > From the clang commit message it seems that CWG is leaning towards allowing
> > _with_unknown_bound[0] and array_with_unknown_bound, but disallowing
> > any other indexes (i.e. assume the array could have zero elements).
> > The following patch implements that.  Bootstrapped/regtested on x86_64-linux
> > and i686-linux, ok for trunk?
> 
> Unless your goal is to have GCC 8 reject just some subset of
> expressions in the reported test case (and fix the rest in
> the future) then there still are other potentially invalid
> expressions that GCC will continue to accept.  For example,
> the initialization of p in f() is rejected with the patch but
> the use of the same expression in g() is still accepted (Clang
> silently accepts both).  It could be due to the same problem
> as bug 82877.  Other similar issues are being tracked in bug
> 82876 and 82874.

The goal is to fix the PR and improve the handling of unknown
bound arrays while at it.
There is no time nor good timing for something much more substantial.
After all, with the patch we still don't reject e.g.
some cases if g++.dg/cpp0x/pr83993.C testcase uses the [a-z]2 pointers
instead of corresponding array in the array refs it tests.

>   extern const int a[];
> 
>   constexpr int f ()
>   {
> const int *p = [7], *q = [0];
> return p - q;
>   }
> 
>   constexpr int g ()
>   {
> return [7] - [0];
>   }
> 
>   constexpr const int i = f ();
>   constexpr const int j = g ();

I believe the fix for this is to save bodies of constexpr
functions/methods before the folding and do the constexpr evaluations on
those rather than on something we've folded already, but that is
certainly not suitable for GCC8.

> Regarding the patch, just a couple of minor nits:
> 
> The consensus we have reached some time back was not to quote
> integer constants so I would suggest to follow it in new code
> and take the opportunity to remove the quoting from surrounding
> code.
> 
>   https://gcc.gnu.org/wiki/DiagnosticsGuidelines#Quoting

In this case I was just extending existing warning and wanted
consistency with that.  Both can be changed in a GCC9 follow-up,
or if Jason/Nathan want it now, even for GCC8, sure.

> In addition, I would suggest to phrase the error as "array
> subscript value %E is used *with* array qD" as opposed to
> "on array."  If we wanted to make it clearer that it's

That looks reasonable.

> the fact that the index is non-zero is the problem mentioning
> it in the warning might help ("non-zero array subscript %E...")

Well, even zero subscript is wrong if lval is false, i.e. a[0] + 1
rather than e.g. [0].  So we'd need to have another wordings
for the case when the index is zero.

> Alternatively, since the bounds are unknown is evident from
> the type of the array (e.g., "int[]") just: "array subscript
> value %E may be outside the bounds of array %qD of type %qT"
> might be good enough.

Dunno, perhaps.

Jakub

[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.

gcc-7-20180125 is now available

[gccadmin]

Snapshot gcc-7-20180125 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180125/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch 
revision 257067

You'll find:

 gcc-7-20180125.tar.xzComplete GCC

  SHA256=f4cad0895aa6dd237cbcb6e81750e40c3fb3eba8a5bcdf25a21c4ee5520c344b
  SHA1=3b0c38bad58b57a69260916c4f10c40baf56a099

Diffs from 7-20180111 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [C++ PATCH] Speed up inplace_merge algorithm & fix inefficient logic(PR c++/83938)

[chang jc]

Hi:

1. The __len = (__len + 1) / 2; is as you suggested, need to modify as
__len = (__len == 1) ? 0 : ((__len + 1) / 2);

2. The coding gain has been shown  PR c++/83938; I re-post here




  21
  20
  19
  18
  17
  16


  0.471136
  0.625695
  0.767262
  0.907461
  1.04838
  1.19508


  0.340845
  0.48651
  0.639139
  0.770133
  0.898454
  1.04632

it means when Merge [0, 4325376, 16777216); A is a sorted integer with
4325376 & B with 12451840 elements, total with 16M integers

The proposed method has the speed up under given buffer size =, ex
2^16, 2^17, ... 2^21 in unit of sizeof(int), for example, 2^16 means
given sizof(int)*64K bytes.

3. As your suggestion, _TmpBuf __buf should be rewrite.

4. It represents a fact that the intuitive idea to split from larger
part is wrong.

For example, if you have an input sorted array A & B, A has 8 integers
& B has 24 integers. Given tmp buffer whose capacity = 4 integers.

Current it tries to split from B, right?

Then we have:

A1 | A2  B1 | B2

B1 & B2 has 12 integers each, right?

Current algorithm selects pivot as 13th integer from B, right?

If the corresponding upper bound of A is 6th integer.

Then it split in

A1 = 5 | A2 = 3 | B1 = 12 | B2 = 12

After rotate, we have two arrays to merge

[A1 = 5 | B1 = 12]  & [A2 = 3 | B2 = 12]

Great, [A2 = 3 | B2 = 12] can use tmp buffer to merge.

Sadly, [A1 = 5 | B1 = 12] CANNOT.

So we do rotate again, split & merge the two split arrays from [A1 = 5
| B1 = 12] again.


But wait, if we always split from the smaller one instead of larger one.

After rotate, it promises two split arrays both contain ceiling[small/2].

Since tmp buffer also allocate by starting from sizeof(small) &
recursively downgrade by ceiling[small/2^(# of fail allocate)].

It means the allocated tmp buffer promises to be sufficient at the
level of (# of fail allocate).

Instead, you can see if split from large at level (# of fail allocate)
several split array still CANNOT use  tmp buffer to do buffered merge.


As you know, buffered merge is far speed then (split, rotate, and
merge two sub-arrays) (PR c++/83938 gives the profiling figures),

the way should provide speedup.


Thanks.










On 24/01/2018 18:23, François Dumont wrote:

Hi


It sounds like a very sensitive change to make but nothing worth figures.
Do you have any bench showing the importance of the gain ?

At least the memory usage optimization is obvious.

On 19/01/2018 10:43, chang jc wrote:

Current std::inplace_merge() suffers from performance issue by inefficient

logic under limited memory,

It leads to performance downgrade.

Please help to review it.

Index: include/bits/stl_algo.h
===
--- include/bits/stl_algo.h(revision 256871)
+++ include/bits/stl_algo.h(working copy)
@@ -2437,7 +2437,7 @@
_BidirectionalIterator __second_cut = __middle;
_Distance __len11 = 0;
_Distance __len22 = 0;
-  if (__len1 > __len2)
+  if (__len1 < __len2)
  {
__len11 = __len1 / 2;
std::advance(__first_cut, __len11);
@@ -2539,9 +2539,15 @@
const _DistanceType __len1 = std::distance(__first, __middle);
const _DistanceType __len2 = std::distance(__middle, __last);

+

typedef _Temporary_buffer<_BidirectionalIterator, _ValueType>
_TmpBuf;

-  _TmpBuf __buf(__first, __last);
-
+  _BidirectionalIterator __start, __end;
+  if (__len1 < __len2) {
+__start = __first; __end = __middle;
+  } else {
+__start = __middle; __end = __last;
+  }
+  _TmpBuf __buf(__start, ___end);

Note another optimization, we could introduce a _Temporary_buffer<> constructor
in order to write:

_TmpBuf __buf(std::min(__len1, __len2), __first);

So that std::distance do not need to be called again.

if (__buf.begin() == 0)
  std::__merge_without_buffer
(__first, __middle, __last, __len1, __len2, __comp);
Index: include/bits/stl_tempbuf.h
===
--- include/bits/stl_tempbuf.h(revision 256871)
+++ include/bits/stl_tempbuf.h(working copy)
@@ -95,7 +95,7 @@
  std::nothrow));
if (__tmp != 0)
  return std::pair<_Tp*, ptrdiff_t>(__tmp, __len);
-  __len /= 2;
+  __len = (__len + 1) / 2;

This part is problematic, if __len is 1 and allocation fails it will loop
forever.

It doesn't seem really necessary for your patch.


2018-01-20 4:05 GMT+08:00 Jason Merrill :

> This is a libstdc++ bug and patch, not the C++ front end.  So I'm
> adding the libstdc++ list to CC.
>
> On Fri, Jan 19, 2018 at 3:02 AM, chang jc  wrote:
> > Current std::inplace_merge() suffers from performance issue by
> inefficient
> > logic under limited memory,
> >
> > It leads to performance downgrade.
> >
> > Please help to review it.
> >
> > Index: include/bits/stl_algo.h
> > 

[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 ***

[PATCH] Fix RTL DCE with separate shrink wrapped epilogues (PR rtl-optimization/83985)

[Jakub Jelinek]

Hi!

The r241060 change added the second hunk in this patch which the patch is
reverting.  The problem is that not deleting some unmarked insns in
delete_unmarked_insns is done in a wrong place, it causes indeed not to
delete the instruction we don't want to DCE, but the instructions that
are needed by the instructions (in this case a memory load whose result
the REG_CFA_RESTORE instruction uses) are not marked either and those are
deleted.

The following patch fixes it by making such instructions non-deletable,
which means they are marked and the DCE algorithm then marks the
instructions they need too.

Bootstrapped/regtested on {x86_64,i686,powerpc64{,le}}-linux, ok for trunk?

2018-01-25  Jakub Jelinek  

PR rtl-optimization/83985
* dce.c (deletable_insn_p): Return false for separate shrink wrapping
REG_CFA_RESTORE insns.
(delete_unmarked_insns): Don't ignore separate shrink wrapping
REG_CFA_RESTORE insns here.

* gcc.dg/pr83985.c: New test.

--- gcc/dce.c.jj2018-01-04 00:43:17.995703342 +0100
+++ gcc/dce.c   2018-01-25 17:55:49.750007894 +0100
@@ -131,6 +131,12 @@ deletable_insn_p (rtx_insn *insn, bool f
 && REGNO (pic_offset_table_rtx) >= FIRST_PSEUDO_REGISTER)
   return false;
 
+  /* Callee-save restores are needed.  */
+  if (RTX_FRAME_RELATED_P (insn)
+  && crtl->shrink_wrapped_separate
+  && find_reg_note (insn, REG_CFA_RESTORE, NULL))
+return false;
+
   body = PATTERN (insn);
   switch (GET_CODE (body))
 {
@@ -592,15 +598,6 @@ delete_unmarked_insns (void)
  if (!dbg_cnt (dce))
continue;
 
- if (crtl->shrink_wrapped_separate
- && find_reg_note (insn, REG_CFA_RESTORE, NULL))
-   {
- if (dump_file)
-   fprintf (dump_file, "DCE: NOT deleting insn %d, it's a "
-   "callee-save restore\n", INSN_UID (insn));
- continue;
-   }
-
  if (dump_file)
fprintf (dump_file, "DCE: Deleting insn %d\n", INSN_UID (insn));
 
--- gcc/testsuite/gcc.dg/pr83985.c.jj   2018-01-25 18:05:23.366121812 +0100
+++ gcc/testsuite/gcc.dg/pr83985.c  2018-01-25 18:05:03.513117871 +0100
@@ -0,0 +1,25 @@
+/* PR rtl-optimization/83985 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+/* { dg-additional-options "-mcpu=e300c3 -mtune=e300c3" { target { 
powerpc*-*-* && ilp32 } } } */
+
+long long int v;
+
+void
+foo (int x)
+{
+  if (x == 0)
+return;
+
+  while (v < 2)
+{
+  signed char *a;
+  v /= x;
+  a = v == 0 ? (signed char *)  : (signed char *) 
+  ++*a;
+  ++v;
+}
+
+  while (1)
+;
+}

Jakub

[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.

Re: C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692)

[Marek Polacek]

On Thu, Jan 25, 2018 at 10:16:39PM +0100, Marek Polacek wrote:
> This is a similar problem to 83116: we'd cached a constexpr call, but after a
> store the result had become invalid, yet we used the wrong result again when
> encountering the same call later.  This resulted in evaluating a THROW_EXPR
> which doesn't work.  Details in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692#c5
> 
> The fix for 83116 didn't work here, because when evaluating the body of the
> ctor via store_init_value -> cxx_constant_value we are in STRICT, so we do
> cache.
> 
> It seems that we may no longer rely on the constexpr call table when we
> do cxx_eval_store_expression, because that just rewrites *valp, i.e. the
> value of an object.  Might be too big a hammer again, but I couldn't think
> of how I could guard the caching of a constexpr call.
> 
> This doesn't manifest in C++14 because build_special_member_call in C++17 is
> more aggressive with copy elisions (as required by P0135 which changed how we
> view prvalues).  In C++14 build_special_member_call produces a CALL_EXPR, so
> expand_default_init calls maybe_constant_init, for which STRICT is false, so
> we avoid caching as per 83116.

...so the testcase should actually test c++17.  Consider that fixed.

Marek

[PATCH] Fix -Wrestrict SSA_NAME handling (PR c/83989)

[Jakub Jelinek]

Hi!

builtin_memref ctor for a SSA_NAME with non-NULL SSA_NAME_VAR returns
the underlying variable, rather than just the SSA_NAME.
Later on the code checks if the bases are equal and then compares
corresponding offsets.

The fact that two different SSA_NAMEs have the same underlying variable
says nothing at all whether they have the same value, as the testcase shows,
either the SSA_NAMEs can be completely unrelated, or related, but with
different offsets.  The code already has code to handle POINTER_PLUS_EXPR
with a constant offset, to look through that.  Perhaps in the future there
can be other cases we'd special case, but generally we should compare as
bases the SSA_NAMEs, if they have the same or different base says nothing
about them.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-01-25  Jakub Jelinek  

PR c/83989
* gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): Don't
use SSA_NAME_VAR as base for SSA_NAMEs with non-NULL SSA_NAME_VAR.

* c-c++-common/Wrestrict-3.c: New test.

--- gcc/gimple-ssa-warn-restrict.c.jj   2018-01-17 11:54:17.0 +0100
+++ gcc/gimple-ssa-warn-restrict.c  2018-01-25 14:10:26.182498552 +0100
@@ -373,9 +373,6 @@ builtin_memref::builtin_memref (tree exp
  offrange[1] += off;
}
}
-
-   if (TREE_CODE (base) == SSA_NAME && SSA_NAME_VAR (base))
- base = SSA_NAME_VAR (base);
   }
 
   if (size)
--- gcc/testsuite/c-c++-common/Wrestrict-3.c.jj 2018-01-25 14:16:01.574563425 
+0100
+++ gcc/testsuite/c-c++-common/Wrestrict-3.c2018-01-25 14:14:39.273547506 
+0100
@@ -0,0 +1,48 @@
+/* PR c/83989 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -Wrestrict" } */
+
+__attribute__((__malloc__)) extern void *my_malloc (__SIZE_TYPE__);
+void baz (void *);
+
+#define SIZE 32
+
+void
+foo (void)
+{
+  void *recmem = __builtin_malloc (SIZE);
+  baz (recmem);
+  while (1)
+{
+  void *oldrecmem = recmem;
+  recmem = __builtin_malloc (SIZE);
+  if (!recmem)
+   {
+ __builtin_free (oldrecmem);
+ return;
+   }
+  __builtin_memcpy (recmem, oldrecmem, SIZE);  /* { dg-bogus 
"accessing" } */
+  baz (recmem);
+  __builtin_free (oldrecmem);
+}
+}
+
+void
+bar (void)
+{
+  void *recmem = my_malloc (SIZE);
+  baz (recmem);
+  while (1)
+{
+  void *oldrecmem = recmem;
+  recmem = my_malloc (SIZE);
+  if (!recmem)
+   {
+ __builtin_free (oldrecmem);
+ return;
+   }
+  __builtin_memcpy (recmem, oldrecmem, SIZE);  /* { dg-bogus 
"accessing" } */
+  baz (recmem);
+  __builtin_free (oldrecmem);
+}
+}

Jakub

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Peter Bergner]

On 1/25/18 2:18 PM, Segher Boessenkool wrote:
> Don't add this to rs6000-cpus.def; it belongs to the Linux support only.

Well, the reason I liked adding it to rs6000-cpus.def is that it keeps
the names together, so only one place to hold all of the info.  If you
prefer a separate table, then I can move it to driver-rs6000.c and it
would only need to hold info for AT_PLATFORMs that don't match GCC's
idea of the cpu name (eg, ppc440 versus 440).


> You also need to translate multiple AT_PLATFORM names for a single -mcpu=,
> not necessarily only two, so you probably want a separate translation table
> to do just the translation (in driver-rs6000.c ?)

Ah, I forgot about ppc440gp, even though it is in my list mentioned in the
link below.  I do think that is the only case though, "440", "ppc440" and
"ppc440gp" all being mapped to "440", but yes, that's not handled.


> Did you check this against the kernel's arch/powerpc/kernel/cputable.c ?

I did.  I posted my finding in the bugzilla:

https://gcc.gnu.org/PR56010#c5

I'll note that I did not try and disambiguate 440 vs 440fp, etc. by looking
at the HWCAP for PPC_FEATURE_HAS_FPU, like I mentioned in the bugzilla entry
above.  That's due to just because the cpu supports HW FP, we cannot know
what ABI the distro that is running on the cpu is using.  I could very well
be using a soft-float ABI.  Thoughts on that?


Ok, I'll move the table to driver-rs6000.c and I'll resubmit.

Peter

[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.

Cortex-r52 FP double precision

[Alexander Fedotov]

Hi,
As I understand from this
https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html current master
branch doesn't have support of double-precision FPv5 floating-point
instructions for ARMv8-R (Cortex-r52).
If yes, are there any chances to see them in GCC 8 ?

Alex

C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692)

[Marek Polacek]

This is a similar problem to 83116: we'd cached a constexpr call, but after a
store the result had become invalid, yet we used the wrong result again when
encountering the same call later.  This resulted in evaluating a THROW_EXPR
which doesn't work.  Details in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692#c5

The fix for 83116 didn't work here, because when evaluating the body of the
ctor via store_init_value -> cxx_constant_value we are in STRICT, so we do
cache.

It seems that we may no longer rely on the constexpr call table when we
do cxx_eval_store_expression, because that just rewrites *valp, i.e. the
value of an object.  Might be too big a hammer again, but I couldn't think
of how I could guard the caching of a constexpr call.

This doesn't manifest in C++14 because build_special_member_call in C++17 is
more aggressive with copy elisions (as required by P0135 which changed how we
view prvalues).  In C++14 build_special_member_call produces a CALL_EXPR, so
expand_default_init calls maybe_constant_init, for which STRICT is false, so
we avoid caching as per 83116.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2018-01-25  Marek Polacek  

PR c++/83692
* constexpr.c (cxx_eval_store_expression): Clear constexpr_call_table.

* g++.dg/cpp1y/constexpr-83692.C: New test.

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 4d2ee4a28fc..0202d22f320 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -3663,6 +3663,10 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, 
tree t,
   else
 *valp = init;
 
+  /* We've rewritten a value of a temporary in this constexpr
+ context which might invalide a cached call.  */
+  constexpr_call_table = NULL;
+
   /* Update TREE_CONSTANT and TREE_SIDE_EFFECTS on enclosing
  CONSTRUCTORs, if any.  */
   tree elt;
diff --git gcc/testsuite/g++.dg/cpp1y/constexpr-83692.C 
gcc/testsuite/g++.dg/cpp1y/constexpr-83692.C
index e69de29bb2d..292ba7c22e9 100644
--- gcc/testsuite/g++.dg/cpp1y/constexpr-83692.C
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-83692.C
@@ -0,0 +1,21 @@
+// PR c++/83692
+// { dg-do compile { target c++14 } }
+
+struct integer {
+  constexpr int value() const { return m_value;}
+  int m_value;
+};
+
+struct outer {
+  integer m_x{0};
+  constexpr outer()
+{
+  if (m_x.value() != 0)
+   throw 0;
+  m_x.m_value = integer{1}.value();
+  if (m_x.value() != 1)
+   throw 0;
+}
+};
+
+constexpr outer o{};

Marek

[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))
  }

Silence false positive on LTO type merging waring

[Jan Hubicka]

Hi,
the testcase triggers invalid warning on type mismatch because array
of pointers to complete type has different alias set from array of pointers
to incomplete type.  This is valid, because incoplete pointer has alias set
of void_ptr which alias all pointers and arrays alias with their members.

I already silenced the wanring for pointers but I forgot about arrays.

Bootstrapped/regtested x86_64-linux, OK?

* gcc.dg/lto/pr83954.h: New testcase.
* gcc.dg/lto/pr83954_0.c: New testcase.
* gcc.dg/lto/pr83954_1.c: New testcase.
* lto-symtab.c (warn_type_compatibility_p): Silence false positive
for type match warning on arrays of pointers.

Index: testsuite/gcc.dg/lto/pr83954.h
===
--- testsuite/gcc.dg/lto/pr83954.h  (revision 0)
+++ testsuite/gcc.dg/lto/pr83954.h  (working copy)
@@ -0,0 +1,3 @@
+struct foo;
+extern struct foo *FOO_PTR_ARR[1];
+
Index: testsuite/gcc.dg/lto/pr83954_0.c
===
--- testsuite/gcc.dg/lto/pr83954_0.c(revision 0)
+++ testsuite/gcc.dg/lto/pr83954_0.c(working copy)
@@ -0,0 +1,8 @@
+/* { dg-lto-do link } */
+#include "pr83954.h"
+
+int main() { 
+  // just to prevent symbol removal
+  FOO_PTR_ARR[1] = 0;
+  return 0;
+}
Index: testsuite/gcc.dg/lto/pr83954_1.c
===
--- testsuite/gcc.dg/lto/pr83954_1.c(revision 0)
+++ testsuite/gcc.dg/lto/pr83954_1.c(working copy)
@@ -0,0 +1,7 @@
+#include "pr83954.h"
+
+struct foo {
+ int x;
+};
+struct foo *FOO_PTR_ARR[1] = { 0 };
+
Index: lto/lto-symtab.c
===
--- lto/lto-symtab.c(revision 257009)
+++ lto/lto-symtab.c(working copy)
@@ -284,11 +284,22 @@ warn_type_compatibility_p (tree prevaili
   alias_set_type set1 = get_alias_set (type);
   alias_set_type set2 = get_alias_set (prevailing_type);
 
-  if (set1 && set2 && set1 != set2 
-  && (!POINTER_TYPE_P (type) || !POINTER_TYPE_P (prevailing_type)
+  if (set1 && set2 && set1 != set2)
+   {
+  tree t1 = type, t2 = prevailing_type;
+
+ /* Alias sets of arrays are the same as alias sets of the inner
+types.  */
+ while (TREE_CODE (t1) == ARRAY_TYPE && TREE_CODE (t2) == ARRAY_TYPE)
+   {
+ t1 = TREE_TYPE (t1);
+ t2 = TREE_TYPE (t2);
+   }
+  if ((!POINTER_TYPE_P (t1) || !POINTER_TYPE_P (t2))
  || (set1 != TYPE_ALIAS_SET (ptr_type_node)
- && set2 != TYPE_ALIAS_SET (ptr_type_node
-lev |= 5;
+ && set2 != TYPE_ALIAS_SET (ptr_type_node)))
+ lev |= 5;
+   }
 }
 
   return lev;

[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.

[C++ Patch] Add DECL_UNNAMED_BIT_FIELD and use it

[Paolo Carlini]

Hi,

this is the complete patch, tested x86_64-linux.

Thanks, Paolo.



/c-family
2018-01-25  Paolo Carlini  

* c-common.h (DECL_UNNAMED_BIT_FIELD): New.

/c
2018-01-25  Paolo Carlini  

* c-typeck.c (really_start_incremental_init, push_init_level,
set_nonincremental_init, output_init_element, process_init_element):
Use DECL_UNNAMED_BIT_FIELD.

/cp
2018-01-25  Paolo Carlini  

* class.c (is_really_empty_class): Use DECL_UNNAMED_BIT_FIELD.
* constexpr.c (cx_check_missing_mem_inits): Likewise.
* decl.c (next_initializable_field, find_decomp_class_base,
cp_finish_decomp): Likewise.
* typeck2.c (process_init_constructor_record): Likewise.
Index: c/c-typeck.c
===
--- c/c-typeck.c(revision 257063)
+++ c/c-typeck.c(working copy)
@@ -7955,8 +7955,7 @@ really_start_incremental_init (tree type)
   constructor_fields = TYPE_FIELDS (constructor_type);
   /* Skip any nameless bit fields at the beginning.  */
   while (constructor_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_fields)
-&& DECL_NAME (constructor_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_fields))
constructor_fields = DECL_CHAIN (constructor_fields);
 
   constructor_unfilled_fields = constructor_fields;
@@ -8161,8 +8160,7 @@ push_init_level (location_t loc, int implicit,
   constructor_fields = TYPE_FIELDS (constructor_type);
   /* Skip any nameless bit fields at the beginning.  */
   while (constructor_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_fields)
-&& DECL_NAME (constructor_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_fields))
constructor_fields = DECL_CHAIN (constructor_fields);
 
   constructor_unfilled_fields = constructor_fields;
@@ -8930,8 +8928,7 @@ set_nonincremental_init (struct obstack * braced_i
   constructor_unfilled_fields = TYPE_FIELDS (constructor_type);
   /* Skip any nameless bit fields at the beginning.  */
   while (constructor_unfilled_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_unfilled_fields)
-&& DECL_NAME (constructor_unfilled_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_unfilled_fields))
constructor_unfilled_fields = TREE_CHAIN (constructor_unfilled_fields);
 
 }
@@ -9300,8 +9297,7 @@ output_init_element (location_t loc, tree value, t
 
   /* Skip any nameless bit fields.  */
   while (constructor_unfilled_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_unfilled_fields)
-&& DECL_NAME (constructor_unfilled_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_unfilled_fields))
constructor_unfilled_fields =
  DECL_CHAIN (constructor_unfilled_fields);
 }
@@ -9665,8 +9661,8 @@ process_init_element (location_t loc, struct c_exp
  constructor_unfilled_fields = DECL_CHAIN (constructor_fields);
  /* Skip any nameless bit fields.  */
  while (constructor_unfilled_fields != 0
-&& DECL_C_BIT_FIELD (constructor_unfilled_fields)
-&& DECL_NAME (constructor_unfilled_fields) == 0)
+&& (DECL_UNNAMED_BIT_FIELD
+(constructor_unfilled_fields)))
constructor_unfilled_fields =
  DECL_CHAIN (constructor_unfilled_fields);
}
@@ -9675,8 +9671,7 @@ process_init_element (location_t loc, struct c_exp
  constructor_fields = DECL_CHAIN (constructor_fields);
  /* Skip any nameless bit fields at the beginning.  */
  while (constructor_fields != NULL_TREE
-&& DECL_C_BIT_FIELD (constructor_fields)
-&& DECL_NAME (constructor_fields) == NULL_TREE)
+&& DECL_UNNAMED_BIT_FIELD (constructor_fields))
constructor_fields = DECL_CHAIN (constructor_fields);
}
   else if (TREE_CODE (constructor_type) == UNION_TYPE)
Index: c-family/c-common.h
===
--- c-family/c-common.h (revision 257063)
+++ c-family/c-common.h (working copy)
@@ -939,6 +939,10 @@ extern void c_parse_final_cleanups (void);
 #define CLEAR_DECL_C_BIT_FIELD(NODE) \
   (DECL_LANG_FLAG_4 (FIELD_DECL_CHECK (NODE)) = 0)
 
+/* True if the decl was an unnamed bitfield.  */
+#define DECL_UNNAMED_BIT_FIELD(NODE) \
+  (DECL_C_BIT_FIELD (NODE) && !DECL_NAME (NODE))
+
 extern tree do_case (location_t, tree, tree);
 extern tree build_stmt (location_t, enum tree_code, ...);
 extern tree build_real_imag_expr (location_t, enum tree_code, tree);
Index: cp/class.c

[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!

Re: Go patch committed: Rationalize external symbol names

[Rainer Orth]

Hi Ian,

> From the error messages I guess the problem is that the assembler
> doesn't like symbols that start with ".1".  Do you know what names the
> assembler permits?

The x86 Assembly Language Reference Manual states:

2.1.2.1 Identifiers

An identifier is an arbitrarily-long sequence of letters and digits. The
first character must be a letter; the underscore (_) (ASCII 0x5F) and
the period (.) (ASCII 0x2E) are considered to be letters. Case is
significant: uppercase and lowercase letters are different.

Contrary to that, /bin/as won't assemble

.globl .1

The SPARC Assembly Language Reference Manual states this instead:

1.3.6 Symbol Names

The syntax for a symbol name is:

{ letter | _ | $ | . }   { letter | _ | $ | . | digit }* 

In the above syntax:

* Uppercase and lowercase letters are distinct; the underscore ( _ ),
  dollar sign ($), and dot ( . ) are treated as alphabetic characters.

* Symbol names that begin with a dot ( . ) are assumed to be local
  symbols. To simplify debugging, avoid using this type of symbol name
  in hand-coded assembly language routines.

* The symbol dot ( . ) is predefined and always refers to the address of
  the beginning of the current assembly language statement.

* External variable names beginning with the underscore character are
  reserved by the ANSI C Standard. Do not begin these names with the
  underscore; otherwise, the program will not conform to ANSI C and
  unpredictable behavior may result.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Go patch committed: Rationalize external symbol names

[Jakub Jelinek]

On Thu, Jan 25, 2018 at 12:40:13PM -0800, Ian Lance Taylor wrote:
> >> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> >> to mainline.
> >
> > this patch almost certainly (i.e. I didn't reghunt, but it's the only
> > plausible candidate between r257023 and r257057) Solaris/x86 bootstrap
> > with /bin/as:
> >
> > Assembler: doc.go
> > "/var/tmp//ccbyjwCc.s", line 1043 : Syntax error
> > Near line: ".globl  .1fmt.fmt.clearflags"
> > "/var/tmp//ccbyjwCc.s", line 1044 : Syntax error
> > Near line: ".type   .1fmt.fmt.clearflags, @function"
> > "/var/tmp//ccbyjwCc.s", line 1045 : Illegal mnemonic
> > Near line: ".1fmt.fmt.clearflags:"
> > "/var/tmp//ccbyjwCc.s", line 1045 : Syntax error
> > Near line: ".1fmt.fmt.clearflags:"
> > "/var/tmp//ccbyjwCc.s", line 1045 : Syntax error
> > Near line: ".1fmt.fmt.clearflags:"
> > "/var/tmp//ccbyjwCc.s", line 1058 : Syntax error
> > Near line: ".size   .1fmt.fmt.clearflags, 
> > .-.1fmt.fmt.clearflags"
> > "/var/tmp//ccbyjwCc.s", line 1060 : Syntax error
> > Near line: ".globl  .1fmt.pp.Width"
> > "/var/tmp//ccbyjwCc.s", line 1061 : Syntax error
> > Near line: ".type   .1fmt.pp.Width, @function"
> > "/var/tmp//ccbyjwCc.s", line 1062 : Illegal mnemonic
> > Near line: ".1fmt.pp.Width:"
> > "/var/tmp//ccbyjwCc.s", line 1062 : Syntax error
> > Near line: ".1fmt.pp.Width:"
> > "/var/tmp//ccbyjwCc.s", line 1062 : Syntax error
> > Near line: ".1fmt.pp.Width:"
> > "/var/tmp//ccbyjwCc.s", line 1082 : Syntax error
> > Near line: ".size   .1fmt.pp.Width, .-.1fmt.pp.Width"
> > "/var/tmp//ccbyjwCc.s", line 1084 : Syntax error
> > Near line: ".globl  .1fmt.pp.Precision"
> > "/var/tmp//ccbyjwCc.s", line 1085 : Syntax error
> > Near line: ".type   .1fmt.pp.Precision, @function"
> > "/var/tmp//ccbyjwCc.s", line 1086 : Illegal mnemonic
> > Near line: ".1fmt.pp.Precision:"
> > "/var/tmp//ccbyjwCc.s", line 1086 : Syntax error
> > Near line: ".1fmt.pp.Precision:"
> > "/var/tmp//ccbyjwCc.s", line 1086 : Syntax error
> > Near line: ".1fmt.pp.Precision:"
> > "/var/tmp//ccbyjwCc.s", line 1106 : Syntax error
> > Near line: ".size   .1fmt.pp.Precision, .-.1fmt.pp.Precision"
> > "/var/tmp//ccbyjwCc.s", line 1108 : Syntax error
> > Near line: ".globl  .1fmt.ss.Width"
> > "/var/tmp//ccbyjwCc.s", line 1109 : Syntax error
> > Near line: ".type   .1fmt.ss.Width, @function"
> > "/var/tmp//ccbyjwCc.s", line 1110 : Illegal mnemonic
> > Near line: ".1fmt.ss.Width:"
> > "/var/tmp//ccbyjwCc.s", line 1110 : Syntax error
> > Near line: ".1fmt.ss.Width:"
> > "/var/tmp//ccbyjwCc.s", line 1110 : Syntax error
> > Near line: ".1fmt.ss.Width:"
> > "/var/tmp//ccbyjwCc.s", line 1149 : Syntax error
> > Near line: ".size   .1fmt.ss.Width, .-.1fmt.ss.Width"
> > "/var/tmp//ccbyjwCc.s", line 1151 : Syntax error
> > Near line: ".globl  .1fmt.ss.UnreadRune"
> > "/var/tmp//ccbyjwCc.s", line 1152 : Syntax error
> > Near line: ".type   .1fmt.ss.UnreadRune, @function"
> > "/var/tmp//ccbyjwCc.s", line 1153 : Illegal mnemonic
> > Near line: ".1fmt.ss.UnreadRune:"
> > "/var/tmp//ccbyjwCc.s", line 1153 : Syntax error
> > Near line: ".1fmt.ss.UnreadRune:"
> > "/var/tmp//ccbyjwCc.s", line 1153 : Syntax error
> > Near line: ".1fmt.ss.UnreadRune:"
> > "/var/tmp//ccbyjwCc.s", line 1209 : Syntax error
> > Near line: ".size   .1fmt.ss.UnreadRune, .-.1fmt.ss.UnreadRune"
> > "/var/tmp//ccbyjwCc.s", line 1908 : Syntax error
> > Near line: ".globl  .1fmt.fmt.init"
> > Too many errors - Goodbye
> > make[4]: *** [Makefile:3322: fmt.lo] Error 1
> >
> > Solaris/SPARC with /bin/as is fine, but that's not too astonishing since
> > both assemblers are mostly different code bases.
> 
> >From the error messages I guess the problem is that the assembler
> doesn't like symbols that start with ".1".  Do you know what names the
> assembler permits?

It isn't just Solaris/SPARC, I saw bootstrap failure with go on
powerpc64-linux and powerpc64le-linux too, similar errors.
/tmp/cc9hDRO7.s: Assembler messages:
/tmp/cc9hDRO7.s:128: Error: symbol `.1errors.errorString.Error' is already 
defined
/tmp/cc9hDRO7.s: Error: .size expression for .1errors.errorString.Error does 
not evaluate to a constant

/home/jakub/gcc/obj22/gotools/../../gotools/../libgo/go/cmd/vet/unsafeptr.go:60:
 undefined reference to `.1go_types.Package.Path'
/home/jakub/gcc/obj22/gotools/../../gotools/../libgo/go/cmd/vet/unsafeptr.go:61:
 undefined reference to `.1go_types.Named.Obj'

Re: Go patch committed: Rationalize external symbol names

[Ian Lance Taylor]

On Thu, Jan 25, 2018 at 12:28 PM, Rainer Orth
 wrote:
>
>> This patch to the Go frontend rationalizes the external symbol names
>> that appear in assembler code.  It changes from the ad hoc mechanisms
>> used to date to produce a set of names that are at least somewhat more
>> coherent.  They are also more readable, after applying a simple
>> demangling algorithms outlined in the long comment in names.cc.  The
>> new names use only ASCII alphanumeric characters, underscore, and dot
>> (which fixes AIX by avoiding the use of dollar sign).  If we really
>> had to we could replace dot with underscore at the cost of forbidding
>> some uses of underscore in Go identifier names.
>>
>> A minor cleanup discovered during this was that we were treating
>> function types as different if one had a NULL parameters_ field and
>> another has a non-NULL parameters_ field that has no parameters.  This
>> worked because we mangled them slightly differently.  We now mangle
>> them the same, so we treat them as equal, as we should anyhow.
>>
>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
>> to mainline.
>
> this patch almost certainly (i.e. I didn't reghunt, but it's the only
> plausible candidate between r257023 and r257057) Solaris/x86 bootstrap
> with /bin/as:
>
> Assembler: doc.go
> "/var/tmp//ccbyjwCc.s", line 1043 : Syntax error
> Near line: ".globl  .1fmt.fmt.clearflags"
> "/var/tmp//ccbyjwCc.s", line 1044 : Syntax error
> Near line: ".type   .1fmt.fmt.clearflags, @function"
> "/var/tmp//ccbyjwCc.s", line 1045 : Illegal mnemonic
> Near line: ".1fmt.fmt.clearflags:"
> "/var/tmp//ccbyjwCc.s", line 1045 : Syntax error
> Near line: ".1fmt.fmt.clearflags:"
> "/var/tmp//ccbyjwCc.s", line 1045 : Syntax error
> Near line: ".1fmt.fmt.clearflags:"
> "/var/tmp//ccbyjwCc.s", line 1058 : Syntax error
> Near line: ".size   .1fmt.fmt.clearflags, .-.1fmt.fmt.clearflags"
> "/var/tmp//ccbyjwCc.s", line 1060 : Syntax error
> Near line: ".globl  .1fmt.pp.Width"
> "/var/tmp//ccbyjwCc.s", line 1061 : Syntax error
> Near line: ".type   .1fmt.pp.Width, @function"
> "/var/tmp//ccbyjwCc.s", line 1062 : Illegal mnemonic
> Near line: ".1fmt.pp.Width:"
> "/var/tmp//ccbyjwCc.s", line 1062 : Syntax error
> Near line: ".1fmt.pp.Width:"
> "/var/tmp//ccbyjwCc.s", line 1062 : Syntax error
> Near line: ".1fmt.pp.Width:"
> "/var/tmp//ccbyjwCc.s", line 1082 : Syntax error
> Near line: ".size   .1fmt.pp.Width, .-.1fmt.pp.Width"
> "/var/tmp//ccbyjwCc.s", line 1084 : Syntax error
> Near line: ".globl  .1fmt.pp.Precision"
> "/var/tmp//ccbyjwCc.s", line 1085 : Syntax error
> Near line: ".type   .1fmt.pp.Precision, @function"
> "/var/tmp//ccbyjwCc.s", line 1086 : Illegal mnemonic
> Near line: ".1fmt.pp.Precision:"
> "/var/tmp//ccbyjwCc.s", line 1086 : Syntax error
> Near line: ".1fmt.pp.Precision:"
> "/var/tmp//ccbyjwCc.s", line 1086 : Syntax error
> Near line: ".1fmt.pp.Precision:"
> "/var/tmp//ccbyjwCc.s", line 1106 : Syntax error
> Near line: ".size   .1fmt.pp.Precision, .-.1fmt.pp.Precision"
> "/var/tmp//ccbyjwCc.s", line 1108 : Syntax error
> Near line: ".globl  .1fmt.ss.Width"
> "/var/tmp//ccbyjwCc.s", line 1109 : Syntax error
> Near line: ".type   .1fmt.ss.Width, @function"
> "/var/tmp//ccbyjwCc.s", line 1110 : Illegal mnemonic
> Near line: ".1fmt.ss.Width:"
> "/var/tmp//ccbyjwCc.s", line 1110 : Syntax error
> Near line: ".1fmt.ss.Width:"
> "/var/tmp//ccbyjwCc.s", line 1110 : Syntax error
> Near line: ".1fmt.ss.Width:"
> "/var/tmp//ccbyjwCc.s", line 1149 : Syntax error
> Near line: ".size   .1fmt.ss.Width, .-.1fmt.ss.Width"
> "/var/tmp//ccbyjwCc.s", line 1151 : Syntax error
> Near line: ".globl  .1fmt.ss.UnreadRune"
> "/var/tmp//ccbyjwCc.s", line 1152 : Syntax error
> Near line: ".type   .1fmt.ss.UnreadRune, @function"
> "/var/tmp//ccbyjwCc.s", line 1153 : Illegal mnemonic
> Near line: ".1fmt.ss.UnreadRune:"
> "/var/tmp//ccbyjwCc.s", line 1153 : Syntax error
> Near line: ".1fmt.ss.UnreadRune:"
> "/var/tmp//ccbyjwCc.s", line 1153 : Syntax error
> Near line: ".1fmt.ss.UnreadRune:"
> "/var/tmp//ccbyjwCc.s", line 1209 : Syntax error
> Near line: ".size   .1fmt.ss.UnreadRune, .-.1fmt.ss.UnreadRune"
> "/var/tmp//ccbyjwCc.s", line 1908 : Syntax error
> Near line: ".globl  .1fmt.fmt.init"
> Too many errors - Goodbye
> make[4]: *** [Makefile:3322: fmt.lo] Error 1
>
> Solaris/SPARC with /bin/as is fine, but that's not too astonishing since
> both assemblers 

Re: [PATCH][Middle-end][version 2]2nd patch of PR78809 and PR83026

[Qing Zhao]

> 
> We're now in stage4 so please queue this patch and ping it during
> next stage1.
> 

I will update my patch based on Jeff and your comments, and send it during next 
stage 1.

thanks.

Qing

[PATCH] PR libgcc/59714 complex division is surprising on aarch64

[vladimir . mezentsev]

From: Vladimir Mezentsev 

Tested on aarch64-linux-gnu, x86_64-pc-linux-gnu and sparc64-unknown-linux-gnu.
No regression. New tests now passed.
There is a performance degradation for complex double type:

  failed cases  |time
   old   new|   old  new
complex-32  150 |  3.51  3.56
complex-64  190 |  1.88  2.34
complex-128 340 |  3.71  2.88

ChangeLog:
2018-01-25  Vladimir Mezentsev  

PR libgcc/59714
* libgcc/libgcc2.c: New complex division implementation
* libgcc/config/sparc/sfp-machine.h: New
* gcc/testsuite/gcc.c-torture/execute/pr59714_128.c: New test
* gcc/testsuite/gcc.c-torture/execute/pr59714_32.c: New test
* gcc/testsuite/gcc.c-torture/execute/pr59714_64.c: New test
---
 gcc/testsuite/gcc.c-torture/execute/pr59714_128.c | 506 ++
 gcc/testsuite/gcc.c-torture/execute/pr59714_32.c  | 506 ++
 gcc/testsuite/gcc.c-torture/execute/pr59714_64.c  | 506 ++
 libgcc/config/sparc/sfp-machine.h |  13 +
 libgcc/libgcc2.c  | 175 +++-
 5 files changed, 1700 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr59714_128.c
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr59714_32.c
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/pr59714_64.c
 create mode 100644 libgcc/config/sparc/sfp-machine.h

diff --git a/gcc/testsuite/gcc.c-torture/execute/pr59714_128.c 
b/gcc/testsuite/gcc.c-torture/execute/pr59714_128.c
new file mode 100644
index 000..e26f40a
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/pr59714_128.c
@@ -0,0 +1,506 @@
+#include 
+#include 
+
+extern void abort (void);
+#define FABS(x) ((x) >= 0 ? (x) : -(x))
+#define FTYPE   long double
+#define FMT "%-39.28La"
+
+/*
+   Tables of numbers for complex division testing
+   All values in hex format
+   z[i] == correctly rounded value of x[i]/y[i];
+ */
+
+#define NUMCNT 100
+
+__complex FTYPE x[NUMCNT] =
+  {
+0x1.0p0L + 0x1.0p0Li,  /* #1 */
+0x1.0p0L + 0x1.0p0Li,  /* #2 */
+0x1.0p1023L + 0x1.0p-1023Li,   /* #3 */
+0x1.0p1023L + 0x1.0p1023Li,/* #4 */
+0x1.0p1020L + 0x1.0p-844Li,/* #5 */
+0x1.0p-71L + 0x1.0p1021Li, /* #6 */
+0x1.0p-347L + 0x1.0p-54Li, /* #7 */
+0x1.0p-1074L + 0x1.0p-1074Li,  /* #8 */
+0x1.0p1015L + 0x1.0p-989Li,/* #9 */
+0x1.0p-622L + 0x1.0p-1071Li,   /* #10 */
+0x1.0p0L + 0x3.0p0Li,  /* #11 */
+-0x1.0p0L + 0x3.0p0Li, /* #12 */
+0x1.0p0L - 0x3.0p0Li,  /* #13 */
+0x3.0p0L + 0x1.0p0Li,  /* #14 */
+0x3.0p0L + 0x4.0p0Li,  /* #15 */
+0x1.0p0L - 0x3.1p-20Li,/* #16 */
+0x1.0p0L + 0x3.001p-20Li,  /* #17 */
+0x1.0p0L + 0x1.80002p1Li,  /* #18 */
+0x1.0p0L + 0x1.80004p1Li,  /* #19 */
+0x1.0p0L + 0x1.80008p1Li,  /* #20 */
+0x1.0p0L + 0x1.80010p1Li,  /* #21 */
+0x1.0p0L + 0x1.80020p1Li,  /* #22 */
+0x1.0p0L + 0x1.80040p1Li,  /* #23 */
+0x1.0p0L + 0x1.80080p1Li,  /* #24 */
+0x1.0p0L + 0x1.7ff8p1Li,   /* #25 */
+0x1.0p0L + 0x1.7ff0p1Li,   /* #26 */
+0x1.0p0L + 0x1.7f80p1Li,   /* #27 */
+0x1.0p0L + 0x1.7f00p1Li,   /* #28 */
+0x5.0p0L + 0x5.0p0Li,  /* #29 */
+0x4.0p0L + 0x3.0p0Li,  /* #30 */
+-0x4.0p0L + 0x3.1p0Li, /* #31 */
+0x3.001p-20L + 0x1.0p0Li,  /* #32 */
+0x1.001p-80L + 0x1.0p0Li,  /* #33 */
+0x1.001p-8000L + 0x1.0p0Li,/* #34 */
+0x1.0p0L + 0x1.001p-8000Li,/* #35 */
+-0x1.0p0L + 0x1.001p-8000Li,/* #36 */
+-0x1.0p0L + 0x1.001p-8000Li,/* #37 */
+-0x1.0p0L + 0x1.001p-8000Li,/* #38 */
+0x1.0p0L - 0x1.001p-8000Li,/* #39 */
+0x1.0p1000L - 0x1.001p-8000Li, /* #40 */
+0x1.97530p1000L - 0x1.001p-8000Li, /* #41 */
+0x1.97530p3000L - 0x1.001p-8000Li, /* #42 */
+0x1.97530p3770L - 0x1.001p-8000Li, /* #43 */
+0x1.97530p4770L - 0x1.001p-7000Li, /* #44 */
+0x1.97530p0L - 0x1.001p-12000Li,   /* #45 */
+0x1.97530p1000L - 0x1.001p-11000Li,/* #46 */
+0x1.97530p2000L - 0x1.001p-9000Li, /* #47 */
+0x1.97530p3000L - 0x1.001p-8000Li, /* #48 */
+0x1.97530p4000L - 0x1.001p-7000Li, /* #49 */
+0x1.97530p5000L - 0x1.001p-6000Li, /* #50 */
+0x1.97530p6000L - 0x1.001p-5000Li, /* #51 */
+0x1.97530p7000L - 0x1.001p-4000Li, /* #52 */
+0x1.97530p8000L - 0x1.001p-1000Li, /* #53 */
+0x1.97530p9000L - 0x1.001p-0Li,/* #54 */
+0x1.97530p1L + 

Re: [PATCH][Middle-end][version 2]2nd patch of PR78809 and PR83026

[Qing Zhao]

Hi, Jeff,

Really sorry for my  delay. 

Your email on 1/12/2018 and Richard’s email on 1/15/2018,   were completely 
lost in my mailboxes until yesterday my colleague, Paolo Carlini, forwarded it 
to me. 

I really apologize for the late reply.

Please see my reply below:

> On Jan 12, 2018, at 4:47 PM, Jeff Law  > wrote:
>> 
>> 
>>  1. replace the candidate calls with __builtin_str(n)cmp_eq instead of 
>> __builtin_memcmp_eq;
>>in builtins.c,  when expanding the new __builtin_str(n)cmp_eq 
>> call, expand them first as
>>__builtin_memcmp_eq, if Not succeed,  change the call back to 
>> __builtin_str(n)cmp.
>>  2. change the call to “get_range_strlen” with “compute_objsize”.
> Please read the big comment before compute_objsize.  If you are going to
> use it to influence code generation or optimization, then you're most
> likely doing something wrong.
> 
> compute_objsize can return an estimate in some circumstances.

> On Jan 15, 2018, at 2:48 AM, Richard Biener  > wrote:
> 
> Yes, compute_objsize cannot be used for optimizations.
Yes, I just checked the compute_objsize again, you are right, it might return 
an estimated code size.


> On Jan 12, 2018, at 4:47 PM, Jeff Law  > wrote:

> What I don't like here is the introduction of STRCMP_EQ and STRNCMP_EQ.
> ISTM that if you're going to introduce those new builtins, then you have
> to audit all the code that runs between their introduction into the IL
> and when you expand them to ensure they're handled properly.
> 
> All you're really doing is carrying along a status bit about what
> tree-ssa-strlen did.  So you could possibly store that status bit somewhere.
> 
> The concern with both is that something later invalidates the analysis
> you've done.  I'm having a hard time coming up with a case where this
> could happen, but I'm definitely concerned about this possibility.
> Though I feel it's more likely to happen if we store a status bit vs
> using STRCMP_EQ STRNCMP_EQ.
> 
> [ For example, we have two calls with the same arguments, but one feeds
> an equality test, the other does not.  If we store a status bit that one
> could be transformed, but then we end up CSE-ing the two calls, the
> status bit would be incorrect because one of the calls did not feed an
> equality test.  Hmmm. ]

See below.

>> +static HOST_WIDE_INT 
>> +compute_string_length (int idx)
>> +{
>> +  HOST_WIDE_INT string_leni = -1; 
>> +  gcc_assert (idx != 0);
>> +
>> +  if (idx < 0)
>> +string_leni = ~idx;
> So it seems to me you should just
>  return ~idx;
> 
> Then appropriately simplify the rest of the code.

Okay, I will update my code per your suggestion. 
> 
>> +
>> +/* Handle a call to strcmp or strncmp. When the result is ONLY used to do 
>> +   equality test against zero:
>> +
>> +   A. When both arguments are constant strings and it's a strcmp:
>> +  * if the length of the strings are NOT equal, we can safely fold the 
>> call
>> +to a non-zero value.
>> +  * otherwise, do nothing now.
> I'm guessing your comment needs a bit of work.  If both arguments are
> constant strings, then we can just use the host str[n]cmp to fold the
> str[n]cmp to a constant.  Presumably this is handled earlier :-)
> 
> So what I'm guessing is you're really referring to the case where the
> lengths are known constants, even if the contents of the strings
> themselves are not.  In that case if its an equality comparison, then
> you can fold to a constant.  Otherwise we do nothing.  So I think the
> comment needs updating here.

your understanding is correct, I will update the comments to make it more 
accurate.

>> +  
>> +   B. When one of the arguments is constant string, try to replace the call 
>> with
>> +   a __builtin_str(n)cmp_eq call where possible, i.e:
>> +
>> +   strncmp (s, STR, C) (!)= 0 in which, s is a pointer to a string, STR is 
>> a 
>> +   constant string, C is a constant.
>> + if (C <= strlen(STR) && sizeof_array(s) > C)
>> +   {
>> + replace this call with
>> + strncmp_eq (s, STR, C) (!)= 0
>> +   }
>> + if (C > strlen(STR)
>> +   {
>> + it can be safely treated as a call to strcmp (s, STR) (!)= 0
>> + can handled by the following strcmp.
>> +   }
>> +
>> +   strcmp (s, STR) (!)= 0 in which, s is a pointer to a string, STR is a 
>> +   constant string.
>> + if  (sizeof_array(s) > strlen(STR))
>> +   {
>> + replace this call with
>> + strcmp_eq (s, STR, strlen(STR)+1) (!)= 0
> So I'd hazard a guess that this comment has the same problem.  It's
> mixing up the concept of a constant string and the concept of a
> nonconstant string, but which has a known constant length.
> 
> First, if one of the arguments is a string constant, then it should be
> easy to get the constant at expansion time with minimal effort.  It's

Re: PR84033, powerpc64le -moptimize-swaps bad code with vec_vbpermq

[Segher Boessenkool]

On Thu, Jan 25, 2018 at 08:39:21PM +1030, Alan Modra wrote:
> vbpermq produces its output in bits 48..63 of the target vector reg,
> so the output cannot be lane swapped.  Bootstrapped and regression
> tested powerpc64le-linux.  OK to apply mainline, and backport to the
> branches?
> 
> 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.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/swaps-p8-46.c
> @@ -0,0 +1,34 @@
> +/* { dg-do run { target { powerpc64le-*-* } } } */

/* { dg-do run { target { lp64 } } } */

would be better, since you only care whether you are running 64-bit
(and the target triple does not tell you; although standard configs
for powerpc64le pretty much enforce it, of course).

Okay for trunk with or without that change; okay for the branches after
looking for fallout.  Thanks!


Segher

Re: Go patch committed: Rationalize external symbol names

[Rainer Orth]

Hi Ian,

> This patch to the Go frontend rationalizes the external symbol names
> that appear in assembler code.  It changes from the ad hoc mechanisms
> used to date to produce a set of names that are at least somewhat more
> coherent.  They are also more readable, after applying a simple
> demangling algorithms outlined in the long comment in names.cc.  The
> new names use only ASCII alphanumeric characters, underscore, and dot
> (which fixes AIX by avoiding the use of dollar sign).  If we really
> had to we could replace dot with underscore at the cost of forbidding
> some uses of underscore in Go identifier names.
>
> A minor cleanup discovered during this was that we were treating
> function types as different if one had a NULL parameters_ field and
> another has a non-NULL parameters_ field that has no parameters.  This
> worked because we mangled them slightly differently.  We now mangle
> them the same, so we treat them as equal, as we should anyhow.
>
> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> to mainline.

this patch almost certainly (i.e. I didn't reghunt, but it's the only
plausible candidate between r257023 and r257057) Solaris/x86 bootstrap
with /bin/as:

Assembler: doc.go
"/var/tmp//ccbyjwCc.s", line 1043 : Syntax error
Near line: ".globl  .1fmt.fmt.clearflags"
"/var/tmp//ccbyjwCc.s", line 1044 : Syntax error
Near line: ".type   .1fmt.fmt.clearflags, @function"
"/var/tmp//ccbyjwCc.s", line 1045 : Illegal mnemonic
Near line: ".1fmt.fmt.clearflags:"
"/var/tmp//ccbyjwCc.s", line 1045 : Syntax error
Near line: ".1fmt.fmt.clearflags:"
"/var/tmp//ccbyjwCc.s", line 1045 : Syntax error
Near line: ".1fmt.fmt.clearflags:"
"/var/tmp//ccbyjwCc.s", line 1058 : Syntax error
Near line: ".size   .1fmt.fmt.clearflags, .-.1fmt.fmt.clearflags"
"/var/tmp//ccbyjwCc.s", line 1060 : Syntax error
Near line: ".globl  .1fmt.pp.Width"
"/var/tmp//ccbyjwCc.s", line 1061 : Syntax error
Near line: ".type   .1fmt.pp.Width, @function"
"/var/tmp//ccbyjwCc.s", line 1062 : Illegal mnemonic
Near line: ".1fmt.pp.Width:"
"/var/tmp//ccbyjwCc.s", line 1062 : Syntax error
Near line: ".1fmt.pp.Width:"
"/var/tmp//ccbyjwCc.s", line 1062 : Syntax error
Near line: ".1fmt.pp.Width:"
"/var/tmp//ccbyjwCc.s", line 1082 : Syntax error
Near line: ".size   .1fmt.pp.Width, .-.1fmt.pp.Width"
"/var/tmp//ccbyjwCc.s", line 1084 : Syntax error
Near line: ".globl  .1fmt.pp.Precision"
"/var/tmp//ccbyjwCc.s", line 1085 : Syntax error
Near line: ".type   .1fmt.pp.Precision, @function"
"/var/tmp//ccbyjwCc.s", line 1086 : Illegal mnemonic
Near line: ".1fmt.pp.Precision:"
"/var/tmp//ccbyjwCc.s", line 1086 : Syntax error
Near line: ".1fmt.pp.Precision:"
"/var/tmp//ccbyjwCc.s", line 1086 : Syntax error
Near line: ".1fmt.pp.Precision:"
"/var/tmp//ccbyjwCc.s", line 1106 : Syntax error
Near line: ".size   .1fmt.pp.Precision, .-.1fmt.pp.Precision"
"/var/tmp//ccbyjwCc.s", line 1108 : Syntax error
Near line: ".globl  .1fmt.ss.Width"
"/var/tmp//ccbyjwCc.s", line 1109 : Syntax error
Near line: ".type   .1fmt.ss.Width, @function"
"/var/tmp//ccbyjwCc.s", line 1110 : Illegal mnemonic
Near line: ".1fmt.ss.Width:"
"/var/tmp//ccbyjwCc.s", line 1110 : Syntax error
Near line: ".1fmt.ss.Width:"
"/var/tmp//ccbyjwCc.s", line 1110 : Syntax error
Near line: ".1fmt.ss.Width:"
"/var/tmp//ccbyjwCc.s", line 1149 : Syntax error
Near line: ".size   .1fmt.ss.Width, .-.1fmt.ss.Width"
"/var/tmp//ccbyjwCc.s", line 1151 : Syntax error
Near line: ".globl  .1fmt.ss.UnreadRune"
"/var/tmp//ccbyjwCc.s", line 1152 : Syntax error
Near line: ".type   .1fmt.ss.UnreadRune, @function"
"/var/tmp//ccbyjwCc.s", line 1153 : Illegal mnemonic
Near line: ".1fmt.ss.UnreadRune:"
"/var/tmp//ccbyjwCc.s", line 1153 : Syntax error
Near line: ".1fmt.ss.UnreadRune:"
"/var/tmp//ccbyjwCc.s", line 1153 : Syntax error
Near line: ".1fmt.ss.UnreadRune:"
"/var/tmp//ccbyjwCc.s", line 1209 : Syntax error
Near line: ".size   .1fmt.ss.UnreadRune, .-.1fmt.ss.UnreadRune"
"/var/tmp//ccbyjwCc.s", line 1908 : Syntax error
Near line: ".globl  .1fmt.fmt.init"
Too many errors - Goodbye
make[4]: *** [Makefile:3322: fmt.lo] Error 1

Solaris/SPARC with /bin/as is fine, but that's not too astonishing since
both assemblers are mostly different code bases.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[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.

Re: [PR81611] improve auto-inc

[Alexandre Oliva]

On Jan 24, 2018, Richard Biener  wrote:

> given gimple_assign_ssa_name_copy checks it is an assign

*nod*

> the lhs != preinc check is always false given you got to phi via
> SSA_NAME_DEF_STMT of preinc.

*nod*

> The simple_iv_increment_p change is ok with that change.

Thanks, I'll retest with the simplified test (just in case; for I can't
recall why I ended up with all those redundant conditions), repost and
install.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Segher Boessenkool]

Hi!

On Wed, Jan 24, 2018 at 03:49:26PM -0600, Peter Bergner wrote:
> The following patch fixes both PR56010 and PR83743.  PR56010 is fixed by
> adding an extra altname field to the RS6000_CPU table which matches the
> cases where the Linux kernel's AT_PLATFORM name differs from the name GCC
> expects.  If we match on the altname, then we return the canonical name.

Don't add this to rs6000-cpus.def; it belongs to the Linux support only.

You also need to translate multiple AT_PLATFORM names for a single -mcpu=,
not necessarily only two, so you probably want a separate translation table
to do just the translation (in driver-rs6000.c ?)

Did you check this against the kernel's arch/powerpc/kernel/cputable.c ?


Segher

[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.

Re: [C++ PATCH] Fix constexpr handling of arrays with unknown bound (PR c++/83993)

[Martin Sebor]

On 01/24/2018 04:19 PM, Jakub Jelinek wrote:

Hi!

In constexpr evaluation of array references for arrays with unknown bounds,
we need to diagnose out of bounds accesses, but really don't know the bounds
at compile time, right now GCC will see nelts as error_mark_node + 1 and
will not consider them a constant expression at all.
From the clang commit message it seems that CWG is leaning towards allowing
_with_unknown_bound[0] and array_with_unknown_bound, but disallowing
any other indexes (i.e. assume the array could have zero elements).
The following patch implements that.  Bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?


Unless your goal is to have GCC 8 reject just some subset of
expressions in the reported test case (and fix the rest in
the future) then there still are other potentially invalid
expressions that GCC will continue to accept.  For example,
the initialization of p in f() is rejected with the patch but
the use of the same expression in g() is still accepted (Clang
silently accepts both).  It could be due to the same problem
as bug 82877.  Other similar issues are being tracked in bug
82876 and 82874.

  extern const int a[];

  constexpr int f ()
  {
const int *p = [7], *q = [0];
return p - q;
  }

  constexpr int g ()
  {
return [7] - [0];
  }

  constexpr const int i = f ();
  constexpr const int j = g ();

Regarding the patch, just a couple of minor nits:

The consensus we have reached some time back was not to quote
integer constants so I would suggest to follow it in new code
and take the opportunity to remove the quoting from surrounding
code.

  https://gcc.gnu.org/wiki/DiagnosticsGuidelines#Quoting

In addition, I would suggest to phrase the error as "array
subscript value %E is used *with* array qD" as opposed to
"on array."  If we wanted to make it clearer that it's
the fact that the index is non-zero is the problem mentioning
it in the warning might help ("non-zero array subscript %E...")

Alternatively, since the bounds are unknown is evident from
the type of the array (e.g., "int[]") just: "array subscript
value %E may be outside the bounds of array %qD of type %qT"
might be good enough.

Martin



2018-01-24  Jakub Jelinek  

PR c++/83993
* constexpr.c (diag_array_subscript): Emit different diagnostics
if TYPE_DOMAIN (arraytype) is NULL.
(cxx_eval_array_reference, cxx_eval_store_expression): For arrays
with NULL TYPE_DOMAIN use size_zero_node as nelts.

* g++.dg/init/pr83993-1.C: New test.
* g++.dg/cpp0x/pr83993.C: New test.

--- gcc/cp/constexpr.c.jj   2018-01-19 23:34:04.897278768 +0100
+++ gcc/cp/constexpr.c  2018-01-24 13:38:40.572913190 +0100
@@ -2270,13 +2270,20 @@ diag_array_subscript (const constexpr_ct
   tree sidx = fold_convert (ssizetype, index);
   if (DECL_P (array))
{
- error ("array subscript value %qE is outside the bounds "
-"of array %qD of type %qT", sidx, array, arraytype);
+ if (TYPE_DOMAIN (arraytype))
+   error ("array subscript value %qE is outside the bounds "
+  "of array %qD of type %qT", sidx, array, arraytype);
+ else
+   error ("array subscript value %qE used on array %qD of "
+  "type %qT with unknown bounds", sidx, array, arraytype);
  inform (DECL_SOURCE_LOCATION (array), "declared here");
}
-  else
+  else if (TYPE_DOMAIN (arraytype))
error ("array subscript value %qE is outside the bounds "
   "of array type %qT", sidx, arraytype);
+  else
+   error ("array subscript value %qE used on array of type %qT "
+  "with unknown bounds", sidx, arraytype);
 }
 }

@@ -2361,7 +2368,12 @@ cxx_eval_array_reference (const constexp

   tree nelts;
   if (TREE_CODE (TREE_TYPE (ary)) == ARRAY_TYPE)
-nelts = array_type_nelts_top (TREE_TYPE (ary));
+{
+  if (TYPE_DOMAIN (TREE_TYPE (ary)))
+   nelts = array_type_nelts_top (TREE_TYPE (ary));
+  else
+   nelts = size_zero_node;
+}
   else if (VECTOR_TYPE_P (TREE_TYPE (ary)))
 nelts = size_int (TYPE_VECTOR_SUBPARTS (TREE_TYPE (ary)));
   else
@@ -3439,7 +3451,12 @@ cxx_eval_store_expression (const constex
  tree nelts, ary;
  ary = TREE_OPERAND (probe, 0);
  if (TREE_CODE (TREE_TYPE (ary)) == ARRAY_TYPE)
-   nelts = array_type_nelts_top (TREE_TYPE (ary));
+   {
+ if (TYPE_DOMAIN (TREE_TYPE (ary)))
+   nelts = array_type_nelts_top (TREE_TYPE (ary));
+ else
+   nelts = size_zero_node;
+   }
  else if (VECTOR_TYPE_P (TREE_TYPE (ary)))
nelts = size_int (TYPE_VECTOR_SUBPARTS (TREE_TYPE (ary)));
  else
--- gcc/testsuite/g++.dg/init/pr83993-1.C.jj2018-01-24 13:45:43.430864528 
+0100
+++ gcc/testsuite/g++.dg/init/pr83993-1.C   2018-01-24 13:44:59.352869530 
+0100
@@ -0,0 +1,11 @@

[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.

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

[Alexandre Oliva]

On Jan 24, 2018, Jakub Jelinek  wrote:

> I think this asks for
>   if (flag_checking)
> gcc_assert (block_within_block_p (block,
> DECL_INITIAL (current_function_decl),
> true));

'k, changed.

> Otherwise the patch looks reasonable to me, but I think it depends on the
> 7/9.

Thanks, yeah, it very much does.  It *might* be possible to split out
the dependency, but...  it would just take most of the LVU patch with it
;-)

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

Re: [SFN+LVU+IEPM v4 7/9] [LVU] Introduce location views

[Alexandre Oliva]

On Jan 24, 2018, Jakub Jelinek  wrote:

> On Tue, Dec 12, 2017 at 12:52:18AM -0200, Alexandre Oliva wrote:
>> --- a/include/dwarf2.h
>> +++ b/include/dwarf2.h
>> @@ -298,6 +298,14 @@ enum dwarf_location_list_entry_type
>> DW_LLE_start_end = 0x07,
>> DW_LLE_start_length = 0x08,
>> 
>> + /*
>> 
>> +   has the proposal for now; only available to list members.
>> +
>> +   A (possibly updated) copy of the proposal is available at
>> +   .  */
>> +DW_LLE_GNU_view_pair = 0x09,
>> +#define DW_LLE_view_pair DW_LLE_GNU_view_pair
>> +

> This looks wrong.  The proposal has not been accepted yet, so you
> really can't know if DW_LLE_view_pair will be like that or whether it
> will have value of 9.  Unfortunately, the DWARF standard doesn't specify a
> vendor range for DW_LLE_* values.  I'd use 0xf0 or so, and don't pretend
> there is DW_LLE_view_pair at all, just use DW_LLE_GNU_view_pair everywhere.
> Jason, what do you think?

My reasoning was that, since we'd only emit this as an
explicitly-requested backward-incompatible extension to DWARF-5 (by
specifying -gdwarf-6 in this patch, but the option spelling could be
changed), any LLE number whatsoever would do.  The point of the #define
was to write the code in GCC so that, once DW_LLE_view_pair was
standardized (if it ever was), we'd just set up an enum for it and we'd
be done, but that would only happen at DWARF6+ anyway, so we'd be able
to tell, since we'd then have actual DWARF6, rather than DWARF5 with an
incompatible extensions (which is what we emit with the current
-gdwarf-6 option; see below).


>> --- a/gcc/dwarf2asm.c
>> +++ b/gcc/dwarf2asm.c
>> @@ -767,6 +767,33 @@ dw2_asm_output_data_sleb128 (HOST_WIDE_INT value,
>> va_end (ap);
>> }
>> 
>> +/* output symbol LAB1 as an unsigned LEB128 quantity.  */

> Capital O in Output please.

Thanks, fixed.

>> +static inline bool
>> +dwarf2out_locviews_in_attribute ()
>> +{
>> +  return debug_variable_location_views
>> +&& dwarf_version <= 5;

> Formatting, should be
>   return debug_variable_location_views && dwarf_version <= 5;
> or
>   return (debug_variable_location_views
> && dwarf_version <= 5);
> if it wouldn't fit (but it does).

Hmm...  Where does that mandate come from?, if you don't mind my asking.
I have just revised both GNU Coding Standards, and GCC-specific
conventions, to make sure I hadn't missed a change or some long-ago
established convention, and I couldn't find anything that supports that
"should".

I don't mind adjusting code to match your preferences (if that's what it
is), especially in modules you maintain, but I'd like to make sure I
haven't missed some requirement in the coding standards.  Or maybe, if
it's more than a personal preference and rather a group preference, we
should add that at least to the GCC coding conventions, if most of us
agree with it.

Personally, I don't see that line breaks before operators are only
permitted when the operand that follows wouldn't fit; the standards are
more permissive than that.  And I don't see that the parentheses are
mandatory either; GNU recommends them so that one doesn't have to indent
the subsequent lines by hand (or risk automatically reintendation to
undo that manual work), but it doesn't seem to mandate the indentation
or the paretheses, and the indentation one gets in their absence is IIUC
permitted and occasionally even desirable.  Am I missing something?

Anyway, consider the requested changes done.

> Do we really need to introduce -gdwarf-6 at this point?
> -gdwarf-5 -gvariable-location-views should be sufficient, isn't it?

No, that means something else, namely emit location view lists in a
separate attribute, matching corresponding ranges.

Maybe we shouldn't even have an option to emit that at this point, or
make it a very different spelling.  But I'd argue there's no point in
discarding the code that implements the format that was proposed for
standardization; at the very least it serves as a reference.  That's
also an argument for retaining the ability to emit it somehow, even if
with an option that we document as to-be-dropped if/when there's a
standard representation.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

[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.

Re: [PATCH] Fix PR84003

[Richard Sandiford]

Richard Sandiford  writes:
> Richard Biener  writes:
>> The following patch fixes PR84003 where RTL DSE removes a redundant
>> store (a store storing the same value as an earlier store) but in
>> doing this changing program semantics because the later store changes
>> the effective type of the memory location.  This in turn allows
>> sched2 to do an originally invalid transform.
>>
>> The fix is to harden DSE so that while removing the later store
>> the earlier stores alias-sets are changed to reflect both dynamic
>> types - which means using alias-set zero.
>>
>> On GIMPLE we simply avoid removing such type-changing stores because
>> we cannot easily get hold on the earlier store.
>>
>> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>>
>> Disclaimer: this is a "local" fix, I didn't try to understand much
>> of the DSE data structures but only learned from +-10 lines around
>> the affected transform which I found by searching for the dumped
>> messages ...  Richard, you contributed the pass so please review.
>
> So the file says.  In reality I only wrote an early version, and what
> was committed contains very little of that.  So TBH this pass is almost
> a complete unknown to me.  That said...
>
> Might it be worth keeping the store instead?

...that is, like gimple. :-)  Sorry, I spent so long thinking about this
that I forgot you'd said that gimple already does the same thing.

Richard

> Giving things alias set
> zero seems like a pretty big hammer and would turn the remaining store
> into something close to a scheduling barrier.
>
> IOW, how about checking alias_set_subset_of in:
>
> /* Even if PTR won't be eliminated as unneeded, if both
>PTR and this insn store the same constant value, we might
>eliminate this insn instead.  */
> if (s_info->const_rhs
> && const_rhs
> && known_subrange_p (offset, width,
>  s_info->offset, s_info->width)
> && all_positions_needed_p (s_info, offset - s_info->offset,
>width))
>
> instead?
>
> Failing that:
>
>> 2018-01-25  Richard Biener  
>>
>>  PR rtl-optimization/84003
>>  * dse.c (dse_step1): When removing redundant stores make sure
>>  to adjust the earlier stores alias-set to match semantics of
>>  the removed one and its own.
>>  (dse_step6): Likewise.
>>
>>  * g++.dg/torture/pr77745.C: Mark foo noinline to trigger
>>  latent bug in DSE.
>>
>> Index: gcc/dse.c
>> ===
>> --- gcc/dse.c(revision 257043)
>> +++ gcc/dse.c(working copy)
>> @@ -2725,6 +2725,19 @@ dse_step1 (void)
>>  "eliminated\n",
>>   INSN_UID (ptr->insn),
>>   INSN_UID (s_info->redundant_reason->insn));
>> +  /* If the later store we delete could have changed the
>> + dynamic type of the memory make sure the one we
>> + preserve serves as a store for all loads that could
>> + validly have accessed the one we delete.  */
>> +  store_info *r_info = s_info->redundant_reason->store_rec;
>> +  while (r_info)
>> +{
>> +  if (r_info->is_set
>> +  && (MEM_ALIAS_SET (s_info->mem)
>> +  != MEM_ALIAS_SET (r_info->mem)))
>> +set_mem_alias_set (r_info->mem, 0);
>> +  r_info = r_info->next;
>> +}
>>delete_dead_store_insn (ptr);
>>  }
>>free_store_info (ptr);
>> @@ -3512,6 +3525,19 @@ dse_step6 (void)
>>  "eliminated\n",
>>  INSN_UID (insn_info->insn),
>>  INSN_UID (rinsn));
>> +  /* If the later store we delete could have changed the
>> + dynamic type of the memory make sure the one we
>> + preserve serves as a store for all loads that could
>> + validly have accessed the one we delete.  */
>> +  store_info *r_info = s_info->redundant_reason->store_rec;
>> +  while (r_info)
>> +{
>> +  if (r_info->is_set
>> +  && (MEM_ALIAS_SET (s_info->mem)
>> +  != MEM_ALIAS_SET (r_info->mem)))
>> +set_mem_alias_set (r_info->mem, 0);
>> +  r_info = r_info->next;
>> +}
>
> I think this is subtle enough to be worth factoring out.  How about
> checking alias_set_subset_of, rather than checking for equality?
>
> Thanks,
> Richard
>
>>delete_dead_store_insn 

Re: [PATCH] Fix PR84003

[Richard Sandiford]

Richard Biener  writes:
> The following patch fixes PR84003 where RTL DSE removes a redundant
> store (a store storing the same value as an earlier store) but in
> doing this changing program semantics because the later store changes
> the effective type of the memory location.  This in turn allows
> sched2 to do an originally invalid transform.
>
> The fix is to harden DSE so that while removing the later store
> the earlier stores alias-sets are changed to reflect both dynamic
> types - which means using alias-set zero.
>
> On GIMPLE we simply avoid removing such type-changing stores because
> we cannot easily get hold on the earlier store.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> Disclaimer: this is a "local" fix, I didn't try to understand much
> of the DSE data structures but only learned from +-10 lines around
> the affected transform which I found by searching for the dumped
> messages ...  Richard, you contributed the pass so please review.

So the file says.  In reality I only wrote an early version, and what
was committed contains very little of that.  So TBH this pass is almost
a complete unknown to me.  That said...

Might it be worth keeping the store instead?  Giving things alias set
zero seems like a pretty big hammer and would turn the remaining store
into something close to a scheduling barrier.

IOW, how about checking alias_set_subset_of in:

  /* Even if PTR won't be eliminated as unneeded, if both
 PTR and this insn store the same constant value, we might
 eliminate this insn instead.  */
  if (s_info->const_rhs
  && const_rhs
  && known_subrange_p (offset, width,
   s_info->offset, s_info->width)
  && all_positions_needed_p (s_info, offset - s_info->offset,
 width))

instead?

Failing that:

> 2018-01-25  Richard Biener  
>
>   PR rtl-optimization/84003
>   * dse.c (dse_step1): When removing redundant stores make sure
>   to adjust the earlier stores alias-set to match semantics of
>   the removed one and its own.
>   (dse_step6): Likewise.
>
>   * g++.dg/torture/pr77745.C: Mark foo noinline to trigger
>   latent bug in DSE.
>
> Index: gcc/dse.c
> ===
> --- gcc/dse.c (revision 257043)
> +++ gcc/dse.c (working copy)
> @@ -2725,6 +2725,19 @@ dse_step1 (void)
>   "eliminated\n",
>INSN_UID (ptr->insn),
>INSN_UID (s_info->redundant_reason->insn));
> +   /* If the later store we delete could have changed the
> +  dynamic type of the memory make sure the one we
> +  preserve serves as a store for all loads that could
> +  validly have accessed the one we delete.  */
> +   store_info *r_info = s_info->redundant_reason->store_rec;
> +   while (r_info)
> + {
> +   if (r_info->is_set
> +   && (MEM_ALIAS_SET (s_info->mem)
> +   != MEM_ALIAS_SET (r_info->mem)))
> + set_mem_alias_set (r_info->mem, 0);
> +   r_info = r_info->next;
> + }
> delete_dead_store_insn (ptr);
>   }
> free_store_info (ptr);
> @@ -3512,6 +3525,19 @@ dse_step6 (void)
>   "eliminated\n",
>   INSN_UID (insn_info->insn),
>   INSN_UID (rinsn));
> +   /* If the later store we delete could have changed the
> +  dynamic type of the memory make sure the one we
> +  preserve serves as a store for all loads that could
> +  validly have accessed the one we delete.  */
> +   store_info *r_info = s_info->redundant_reason->store_rec;
> +   while (r_info)
> + {
> +   if (r_info->is_set
> +   && (MEM_ALIAS_SET (s_info->mem)
> +   != MEM_ALIAS_SET (r_info->mem)))
> + set_mem_alias_set (r_info->mem, 0);
> +   r_info = r_info->next;
> + }

I think this is subtle enough to be worth factoring out.  How about
checking alias_set_subset_of, rather than checking for equality?

Thanks,
Richard

> delete_dead_store_insn (insn_info);
>   }
>   }
> Index: gcc/testsuite/g++.dg/torture/pr77745.C
> ===
> --- gcc/testsuite/g++.dg/torture/pr77745.C(revision 257043)
> +++ gcc/testsuite/g++.dg/torture/pr77745.C(working copy)
> @@