Re: [PATCH] c++: C++20 DR 2237, disallow simple-template-id in cdtor.

2020-04-05 Thread Jason Merrill via Gcc-patches 

On 4/4/20 7:30 PM, Marek Polacek wrote:

This patch implements DR 2237 which says that a simple-template-id is
no longer valid as the declarator-id of a constructor or destructor;
see .  It is not explicitly
stated but out-of-line destructors with a simple-template-id are also
meant to be ill-formed now.  (Out-of-line constructors like that are
invalid since DR1435 I think.)  This change only applies to C++20; it
is not a DR against C++17.

I'm not crazy about the diagnostic in constructors but ISTM that
cp_parser_constructor_declarator_p shouldn't print errors.

Does it seem reasonable to apply this now or should I defer to GCC 11?


A new error should wait for GCC 11.


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

2020-04-04  Marek Polacek  

DR 2237
* parser.c (cp_parser_unqualified_id): Reject simple-template-id as
the declarator-id of a destructor.
(cp_parser_constructor_declarator_p): Reject simple-template-id as
the declarator-id of a constructor.

* g++.dg/DRs/dr2237.C: New test.
* g++.dg/parse/constructor2.C: Add dg-error for C++20.
* g++.dg/parse/dtor12.C: Likewise.
* g++.dg/parse/dtor4.C: Likewise.
* g++.dg/template/dtor4.C: Adjust dg-error.
* g++.dg/template/error34.C: Likewise.
* g++.old-deja/g++.other/inline15.C: Only run for C++17 and lesses.
* g++.old-deja/g++.pt/ctor2.C: Add dg-error for C++20.
---
  gcc/cp/parser.c| 16 
  gcc/testsuite/g++.dg/DRs/dr2237.C  | 18 ++
  gcc/testsuite/g++.dg/parse/constructor2.C  |  4 ++--
  gcc/testsuite/g++.dg/parse/dtor12.C|  2 +-
  gcc/testsuite/g++.dg/parse/dtor4.C |  2 +-
  gcc/testsuite/g++.dg/template/dtor4.C  |  2 +-
  gcc/testsuite/g++.dg/template/error34.C| 10 +-
  .../g++.old-deja/g++.other/inline15.C  |  2 +-
  gcc/testsuite/g++.old-deja/g++.pt/ctor2.C  |  2 +-
  9 files changed, 46 insertions(+), 12 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/DRs/dr2237.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 7e5921e039f..810edfa87a9 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -6114,6 +6114,16 @@ cp_parser_unqualified_id (cp_parser* parser,
return build_min_nt_loc (loc, BIT_NOT_EXPR, make_auto ());
  }
  
+	/* DR 2237 (C++20 only): A simple-template-id is no longer valid as the

+  declarator-id of a constructor or destructor.  */
+   if (token->type == CPP_TEMPLATE_ID && cxx_dialect >= cxx2a)
+ {
+   if (!cp_parser_uncommitted_to_tentative_parse_p (parser))
+ error_at (tilde_loc, "template-id not allowed for destructor");
+   cp_parser_simulate_error (parser);


The usual pattern is

if (!cp_parser_simulate_error (parser))
  error...


+   return error_mark_node;
+ }
+
/* If there was an explicit qualification (S::~T), first look
   in the scope given by the qualification (i.e., S).
  
@@ -28675,6 +28685,12 @@ cp_parser_constructor_declarator_p (cp_parser *parser, cp_parser_flags flags,

if (!constructor_name_p (id, nested_name_specifier))
constructor_p = false;
  }
+  /* DR 2237 (C++20 only): A simple-template-id is no longer valid as the
+ declarator-id of a constructor or destructor.  */
+  else if (constructor_p
+  && cxx_dialect >= cxx2a
+  && cp_lexer_next_token_is (parser->lexer, CPP_TEMPLATE_ID))
+constructor_p = false;
/* If we still think that this might be a constructor-declarator,
   look for a class-name.  */
else if (constructor_p)


Do you also want to exclude CPP_TEMPLATE_ID from the test at the top of 
the function for C++20?



  if (next_token->type != CPP_NAME
  && next_token->type != CPP_SCOPE
  && next_token->type != CPP_NESTED_NAME_SPECIFIER
  && next_token->type != CPP_TEMPLATE_ID)
return false;


Jason

Re: [PATCH] Generalize -fuse-ld= to support absolute path or arbitrary ld.linker

2020-04-05 Thread Fangrui Song via Gcc-patches 

On 2020-03-11, Martin Liška wrote:

On 2/10/20 1:02 AM, Fangrui Song via gcc-patches wrote:

Hello.

Thank you for the patch. You haven't received a review because we are right now
in stage4 of the development cycle:
https://gcc.gnu.org/develop.html#stage4


Thanks for the review!
According to https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543028.html "GCC 
10.0 Status Report (2020-04-01)",
I guess GCC is not open for a new development cycle yet.
I will just answer a few questions instead of uploading a new patch.


Anyway, I'm going to provide a review (even though I'm not maintainer of that).

Can you please describe your test-case why you need such option? When using
a different ld, I typically export PATH=/path/to/binutils and then run configure
and make.


I would hope -fuse-ld=ld.bfd and -fuse-ld=ld.gold were used instead of
-fuse-ld=bfd and -fuse-ld=gold, then it would be more natural to have
-fuse-ld=/abs/path/to/ld . https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55470

-fuse-ld=bfd, -fuse-ld=gold and -fuse-ld=lld are hard-coded in numerous
places. It is too late to change that.

One idea is to make

-fuse-ld=bfd
-fuse-ld=gold
-fuse-ld=lld

special. For any other value, e.g. -fuse-ld=foo or -fuse-ld=/abs/path, just 
searches the
executable named "foo" (instead of "ld.foo") or /abs/path .

Does the scheme sound good? If it is agreed, I can make a similar change to 
clang.


I noticed not ideal error message:

$ gcc -fuse-ld=pes /tmp/foo.c
collect2: fatal error: cannot find ‘ld’
compilation terminated.

while clang prints:

$clang -fuse-ld=pes /tmp/foo.c
clang-9.0: error: invalid linker name in argument '-fuse-ld=pes'

The rest of the patch is comment inline...


Thanks for all the comments.


PR driver/93645
* common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
* opts.c (common_handle_option): Handle OPT_fuse_ld_.
* gcc.c (driver_handle_option): Likewise.
* collect2.c (main): Likewise.
---
 gcc/ChangeLog   |  8 ++
 gcc/collect2.c  | 67 -
 gcc/common.opt  | 14 ++
 gcc/doc/invoke.texi | 15 +++---
 gcc/gcc.c   | 14 --
 gcc/opts.c  |  4 +--
 6 files changed, 57 insertions(+), 65 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index feb2d066d0b..6bcec12d841 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-02-09  Fangrui Song  
+
+   PR driver/93645
+   * common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
+   * opts.c (common_handle_option): Handle OPT_fuse_ld_.
+   * gcc.c (driver_handle_option): Likewise.
+   * collect2.c (main): Likewise.
+
 2020-02-09  Uroš Bizjak  
* recog.c: Move pass_split_before_sched2 code in front of
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 502d629141c..a3ef525a93b 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -859,18 +859,12 @@ main (int argc, char **argv)
 {
   USE_DEFAULT_LD,
   USE_PLUGIN_LD,
-  USE_GOLD_LD,
-  USE_BFD_LD,
-  USE_LLD_LD,
-  USE_LD_MAX
+  USE_LD
 } selected_linker = USE_DEFAULT_LD;
-  static const char *const ld_suffixes[USE_LD_MAX] =
+  static const char *const ld_suffixes[USE_LD] =
 {
   "ld",
-  PLUGIN_LD_SUFFIX,
-  "ld.gold",
-  "ld.bfd",
-  "ld.lld"
+  PLUGIN_LD_SUFFIX
 };
   static const char *const real_ld_suffix = "real-ld";
   static const char *const collect_ld_suffix = "collect-ld";
@@ -882,7 +876,7 @@ main (int argc, char **argv)
   static const char *const strip_suffix = "strip";
   static const char *const gstrip_suffix = "gstrip";
-  const char *full_ld_suffixes[USE_LD_MAX];
+  const char *full_ld_suffixes[USE_LD];
 #ifdef CROSS_DIRECTORY_STRUCTURE
   /* If we look for a program in the compiler directories, we just use
  the short name, since these directories are already system-specific.
@@ -924,6 +918,7 @@ main (int argc, char **argv)
   const char **ld1;
   bool use_plugin = false;
   bool use_collect_ld = false;
+  const char *use_ld = NULL;
   /* The kinds of symbols we will have to consider when scanning the
  outcome of a first pass link.  This is ALL to start with, then might
@@ -948,7 +943,7 @@ main (int argc, char **argv)
 #endif
   int i;
-  for (i = 0; i < USE_LD_MAX; i++)
+  for (i = 0; i < USE_LD; i++)
 full_ld_suffixes[i]
 #ifdef CROSS_DIRECTORY_STRUCTURE
   = concat (target_machine, "-", ld_suffixes[i], NULL);
@@ -1041,12 +1036,11 @@ main (int argc, char **argv)
if (selected_linker == USE_DEFAULT_LD)
  selected_linker = USE_PLUGIN_LD;
  }
-   else if (strcmp (argv[i], "-fuse-ld=bfd") == 0)
- selected_linker = USE_BFD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=gold") == 0)
- selected_linker = USE_GOLD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
- selected_linker = USE_LLD_LD;
+   else if (!strncmp (argv[i],

[committed] libstdc++: Refer to Git documentation

2020-04-05 Thread Gerald Pfeifer 
Nice to see that our redirects work as intended.  Still, preferrable
to adjust URLs.

Pushed.

Gerald

---
 libstdc++-v3/ChangeLog  | 6 ++
 libstdc++-v3/doc/html/manual/appendix_contributing.html | 2 +-
 libstdc++-v3/doc/xml/manual/appendix_contributing.xml   | 2 +-
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index c358977dfbb..eb092792229 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,9 @@
+2020-04-05  Gerald Pfeifer  
+
+   * doc/xml/manual/appendix_contributing.xml: Refer to Git
+   documentation instead of Subversion.  Switch to https.
+   * doc/html/manual/appendix_contributing.html: Regenerate.
+
 2020-04-03  Jonathan Wakely  
 
PR libstdc++/93960
diff --git a/libstdc++-v3/doc/html/manual/appendix_contributing.html 
b/libstdc++-v3/doc/html/manual/appendix_contributing.html
index 28c46555d91..8be678eb919 100644
--- a/libstdc++-v3/doc/html/manual/appendix_contributing.html
+++ b/libstdc++-v3/doc/html/manual/appendix_contributing.html
@@ -68,7 +68,7 @@
   mailto:ass...@gnu.org;>ass...@gnu.org, please CC the 
libstdc++
   maintainers above so that progress can be monitored.
 Getting Sources
-  http://gcc.gnu.org/svnwrite.html; 
target="_top">Getting write access
+  https://gcc.gnu.org/gitwrite.html; 
target="_top">Getting write access
(look for "Write after approval")
 Submitting 
Patches
   Every patch must have several pieces of information before it can be
diff --git a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml 
b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
index 79fa0ed32b8..00991128525 100644
--- a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
+++ b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
@@ -126,7 +126,7 @@
   Getting Sources
 
 
-  http://www.w3.org/1999/xlink; 
xlink:href="http://gcc.gnu.org/svnwrite.html;>Getting write access
+  http://www.w3.org/1999/xlink; 
xlink:href="https://gcc.gnu.org/gitwrite.html;>Getting write access
(look for "Write after approval")
 
   
-- 
2.26.0

Re: [committed] wwwdocs: ada: Tweak link to GNAT: The GNU Ada Compiler.

2020-04-05 Thread Gerald Pfeifer 
On Wed, 1 Apr 2020, Arnaud Charlet wrote:
> We're investigating at Adacore whether the HTML version can be restored.

Thank you.

> In the mean time, pointing to 
> https://www.adacore.com/books/gnat-the-gnu-ada-compiler is indeed the way to 
> go.

Done thusly (= pushed).

Gerald


commit 69513e9ef655783d2ae68d771ad8bd4eb878839d
Author: Gerald Pfeifer 
Date:   Sun Apr 5 23:42:41 2020 +0200

Fix up URL for the GNAT book.

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 84fc0404..da37af6a 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -562,7 +562,7 @@ names.
  Other resources:
  
https://www.adacore.com/community;>AdaCore Community 
Site
-   https://www.adacore.com/gap-static/GNAT_Book/html/;>GNAT:
+   https://www.adacore.com/books/gnat-the-gnu-ada-compiler;>GNAT:
The GNU Ada Compiler
https://www.adaic.org/resources/add_content/docs/95style/html/cover.html;>Ada
Quality  Style Guide

Re: [RFA/RFC] [PR tree-optimization/80635] Optimize some V_C_Es with limited ranges into NOP_EXPRs

2020-04-05 Thread Eric Botcazou 
> Ada no longer uses VIEW_CONVERT_EXPR between scalar types

... between integral types (it does use it if you explicit request an 
unchecked version between integer and floating-point types for example).

-- 
Eric Botcazou

[committed] coroutines, testsuite: Renumber two tests (NFC).

2020-04-05 Thread Iain Sandoe 
Hi,
This fixes a nit in the numbering of tests that I spotted while working on open
PRs.

tested on x86_64-linux/darwin.

applied to master
thanks
Iain

Try to keep tests order by distinct number (and with a short descriptive name 
appended).
 
gcc/testsuite/

2020-04-05  Iain Sandoe  

* g++.dg/coroutines/torture/co-await-14-template-traits.C: Rename...
* g++.dg/coroutines/torture/co-await-16-template-traits.C: to this.
* g++.dg/coroutines/torture/co-await-15-capture-comp-ref.C: Rename..
* g++.dg/coroutines/torture/co-await-17-capture-comp-ref.C: to this.

diff --git 
a/gcc/testsuite/g++.dg/coroutines/torture/co-await-14-template-traits.C 
b/gcc/testsuite/g++.dg/coroutines/torture/co-await-16-template-traits.C
similarity index 100%
rename from 
gcc/testsuite/g++.dg/coroutines/torture/co-await-14-template-traits.C
rename to gcc/testsuite/g++.dg/coroutines/torture/co-await-16-template-traits.C
diff --git 
a/gcc/testsuite/g++.dg/coroutines/torture/co-await-15-capture-comp-ref.C 
b/gcc/testsuite/g++.dg/coroutines/torture/co-await-17-capture-comp-ref.C
similarity index 100%
rename from 
gcc/testsuite/g++.dg/coroutines/torture/co-await-15-capture-comp-ref.C
rename to gcc/testsuite/g++.dg/coroutines/torture/co-await-17-capture-comp-ref.C

Re: [RFA/RFC] [PR tree-optimization/80635] Optimize some V_C_Es with limited ranges into NOP_EXPRs

2020-04-05 Thread Eric Botcazou 
> ISTR Ada uses V_C_E to implement checks on value ranges to types. We need to
> make sure to not interfere with this.

Yes, Jeff privately asked some time ago whether this would be problematic and 
I answered that this wouldn't.  Ada no longer uses VIEW_CONVERT_EXPR between 
scalar types, including for checks, for about a decade and I actually said to 
Jeff that the optimizers ought to do the same.

-- 
Eric Botcazou

Re: Question?

2020-04-05 Thread Chamsi Pirson via Gcc-patches 
Hi just a quick question,
My name is Chamsi Pirson. I'm a freelance writer, with 5 years of experience, 
creating content for varied online portals. I have expertise in writing about 
technology related topics. You can check out some of my previous posts here and 
here!
I'm reaching out to see if you'd be interested in featuring a guest post on 
lemire.me which is 100% unique and qualitative post. I have an article ready to 
publish that I believe will be a good fit for your website.
Let me know if you’re interested and we can talk about the next steps. One way 
or another, thanks for your time, and keep up the awesome work on your site
Take care,
Chamsi PirsonDon't want emails from us anymore? Reply to this email with the 
word "UNSUBSCRIBE" in the subject line.
Techdrunk.com, Building A, 48 Bridge Street Building A, New York, New York, 
10001, United States

Re: Results for 10.0.1 20200404 (experimental) [master revision r10-7550-gaae5d08a8d4d] (GCC) testsuite on x86_64-apple-darwin19

2020-04-05 Thread Iain Sandoe via Gcc-patches 

Iain Sandoe via Gcc-patches  wrote:

LAST_UPDATED: Sat Apr  4 08:01:44 UTC 2020 (revision  
r10-7550-gaae5d08a8d4d)


damn .. beaten by autocompletion again..
sorry
Iain

Re: [PATCH] free() was missing from a part of the documentation

2020-04-05 Thread Jeff Law via Gcc-patches 
On Thu, 2020-04-02 at 12:29 -0600, Zackery Spytz via Gcc-patches wrote:
> Hello,
> 
> The free() function was missing from a part of the documentation!
THanks for the patch.  I've pushed it to the trunk.
jeff

Results for 10.0.1 20200404 (experimental) [master revision r10-7550-gaae5d08a8d4d] (GCC) testsuite on x86_64-apple-darwin19

2020-04-05 Thread Iain Sandoe via Gcc-patches 
LAST_UPDATED: Sat Apr  4 08:01:44 UTC 2020 (revision r10-7550-gaae5d08a8d4d)

Native configuration is x86_64-apple-darwin19

=== g++ tests ===


Running target unix
FAIL: c-c++-common/asan/alloca_big_alignment.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_detect_custom_size.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_partial.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_right.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_underflow_left.c   -Os  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O0  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O1  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O2  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O2 -flto  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O2 -flto -flto-partition=none  output 
pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -Os  output pattern test
FAIL: g++.dg/ipa/pr67056.C   scan-ipa-dump cp "Speculative outer type:struct 
CompositeClass"
FAIL: g++.dg/pr80481.C  -std=gnu++14  scan-assembler-not 
vmovaps[^\\n\\r]*zmm[0-9]+,[^\\n\\r]*zmm[0-9]+
FAIL: g++.dg/pr80481.C  -std=gnu++17  scan-assembler-not 
vmovaps[^\\n\\r]*zmm[0-9]+,[^\\n\\r]*zmm[0-9]+
FAIL: g++.dg/pr80481.C  -std=gnu++2a  scan-assembler-not 
vmovaps[^\\n\\r]*zmm[0-9]+,[^\\n\\r]*zmm[0-9]+
FAIL: g++.dg/pr80481.C  -std=gnu++98  scan-assembler-not 
vmovaps[^\\n\\r]*zmm[0-9]+,[^\\n\\r]*zmm[0-9]+
FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, -flto -O0 
-std=c++11
FAIL: g++.dg/lto/pr65549 cp_lto_pr65549_0.o-cp_lto_pr65549_0.o link,  
-std=gnu++14 -flto -g -O2 -fno-inline -flto-partition=max -Wno-return-type 
FAIL: g++.dg/lto/pr89335 cp_lto_pr89335_0.o assemble, -O2 -flto 
-Wsuggest-final-methods

=== g++ Summary ===

# of expected passes185716
# of unexpected failures20
# of expected failures  739
# of unsupported tests  8341
/scratch/10-15-cat/gcc-trunk-wip/gcc/xg++  version 10.0.1 20200404 
(experimental) [master revision r10-7550-gaae5d08a8d4d] (GCC) 

=== gcc tests ===


Running target unix
FAIL: c-c++-common/asan/alloca_big_alignment.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_detect_custom_size.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_partial.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_overflow_right.c   -Os  output pattern test
FAIL: c-c++-common/asan/alloca_underflow_left.c   -Os  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O0  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O1  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O2  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O2 -flto  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O2 -flto -flto-partition=none  output 
pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -Os  output pattern test
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O0  output pattern test
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O1  (test for excess errors)
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O1  output pattern test
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O2  (test for excess errors)
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O2  output pattern test
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O2 -flto  (test for excess 
errors)
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O2 -flto  output pattern test
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O2 -flto -flto-partition=none  
(test for excess errors)
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O2 -flto -flto-partition=none  
output pattern test
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O3 -g  (test for excess errors)
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -Os  (test for excess errors)
FAIL: c-c++-common/asan/strncpy-overflow-1.c   -Os  output pattern test
FAIL: gcc.dg/debug/dwarf2/inline4.c scan-assembler 
DW_TAG_inlined_subroutine[^(]*([^)]*)[^(]*(DIE 
(0x[0-9a-f]*) DW_TAG_formal_parameter[^(]*(DIE 
(0x[0-9a-f]*) DW_TAG_variable
FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not (DIE 
(0x([0-9a-f]*)) DW_TAG_lexical_block)[^#/!@;|]*[#/!@;|]+ 
+[^(].*DW_TAG_lexical_block)[^#/!@;|x]*x1[^#/!@;|]*[#/!@;|] 
+DW_AT_abstract_origin
FAIL: gcc.dg/darwin-version-1.c (test for excess errors)
FAIL: gcc.dg/pr68766.c (internal compiler error)
FAIL: gcc.dg/pr68766.c (test for excess errors)
FAIL: gcc.dg/stack-layout-dynamic-1.c (internal compiler error)
FAIL: gcc.dg/stack-layout-dynamic-1.c (test for excess errors)
UNRESOLVED: gcc.dg/stack-layout-dynamic-1.c scan-assembler-not 
cfi_def_cfa_register
FAIL:

Re: [RFA/RFC] [PR tree-optimization/80635] Optimize some V_C_Es with limited ranges into NOP_EXPRs

2020-04-05 Thread Jeff Law via Gcc-patches 
On Sun, 2020-04-05 at 20:48 +0200, Richard Biener wrote:
> On April 5, 2020 5:25:15 PM GMT+02:00, Jeff Law via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
> > So here's an approach to try and address PR80635.
> > 
> > In this BZ we're getting a false positive uninitialized warning using
> > std::optional.
> > 
> > As outlined in the BZ this stems from SRA using a VIEW_CONVERT_EXPR 
> > which isn't
> > handled terribly well by the various optimizers/analysis passes.
> > 
> > We have these key blocks:
> > 
> > ;;   basic block 5, loop depth 0
> > ;;pred:   3
> > ;;2
> >  # maybe_a$m_6 = PHI <_5(3), maybe_a$m_4(D)(2)>
> >  # maybe_a$4_7 = PHI <1(3), 0(2)>
> > :
> >  _8 = maybe_b.live;
> >  if (_8 != 0)
> >goto ; [0.00%]
> >  else
> >goto ; [0.00%]
> > ;;succ:   6
> > ;;7
> > 
> > ;;   basic block 6, loop depth 0
> > ;;pred:   5
> >  B::~B (_b.D.2512.m_item);
> > ;;succ:   7
> > 
> > ;;   basic block 7, loop depth 0
> > ;;pred:   5
> > ;;6
> >  maybe_b ={v} {CLOBBER};
> >  resx 3
> > ;;succ:   8
> > 
> > ;;   basic block 8, loop depth 0
> > ;;pred:   7
> > :
> >  _9 = VIEW_CONVERT_EXPR(maybe_a$4_7);
> >  if (_9 != 0)
> >goto ; [0.00%]
> >  else
> >goto ; [0.00%]
> > ;;succ:   9
> > ;;10
> > 
> > Where there is a use of maybe_a$m_6 in block #9.
> > 
> > Of course maybe_a$m_6 only takes the value of maybe_a$m_4(D) when we
> > traverse the
> > edge 2->5 but in that case maybe_a$4_7 will always have the value zero
> > and thus
> > we can not reach bb #9..  But the V_C_E gets in the way of the analysis
> > and we
> > issue the false positive warning.  Martin Jambor has indicated that he
> > doesn't
> > see a way to avoid the V_C_E from SRA without reintroducing PR52244.
> > 
> > This patch optimizes the V_C_E into a NOP_EXPR by verifying that the
> > V_C_E folds
> > to a constant value for the min & max values of the range of the input
> > operand
> > and the result of folding is equal to the original input.  We do some
> > additional
> > checking beyond just that original value and converted value are equal
> > according
> > to operand_equal_p.
> > 
> > Eventually the NOP_EXPR also gets removed as well and the conditional
> > in bb8
> > tests maybe_a$4_7 against 0 directly.
> > 
> > That in turn allows the uninit analysis to determine the use of
> > maybe_a$_m_6 in
> > block #9 is properly guarded and the false positive is avoided.
> > 
> > The optimization of a V_C_E into a NOP_EXPR via this patch occurs a
> > couple
> > hundred times during a bootstrap, so this isn't a horribly narrow
> > change just to
> > fix a false positive warning.
> > 
> > Bootstrapped and regression tested on x86_64.  I've also put it through
> > its paces
> > in the tester.  The tester's current failures (aarch64, mips, h8) are
> > unrelated
> > to this patch.
> > 
> > 
> > Thoughts?  OK for the trunk?  Alternately I wouldn't lose sleep moving
> > this to
> > gcc-11.
> 
> ISTR Ada uses V_C_E to implement checks on value ranges to types. We need to
> make sure to not interfere with this. 
Eric indicated they use it a lot less often than they used to, but yes we should
try to make sure we're not interfering.

I'll enable Ada for the native targets in the tester and see if that spits out
anything concerning.

Jeff

Re: [RFA/RFC] [PR tree-optimization/80635] Optimize some V_C_Es with limited ranges into NOP_EXPRs

2020-04-05 Thread Richard Biener via Gcc-patches 
On April 5, 2020 5:25:15 PM GMT+02:00, Jeff Law via Gcc-patches 
 wrote:
>
>So here's an approach to try and address PR80635.
>
>In this BZ we're getting a false positive uninitialized warning using
>std::optional.
>
>As outlined in the BZ this stems from SRA using a VIEW_CONVERT_EXPR 
>which isn't
>handled terribly well by the various optimizers/analysis passes.
>
>We have these key blocks:
>
>;;   basic block 5, loop depth 0
>;;pred:   3
>;;2
>  # maybe_a$m_6 = PHI <_5(3), maybe_a$m_4(D)(2)>
>  # maybe_a$4_7 = PHI <1(3), 0(2)>
>:
>  _8 = maybe_b.live;
>  if (_8 != 0)
>goto ; [0.00%]
>  else
>goto ; [0.00%]
>;;succ:   6
>;;7
>
>;;   basic block 6, loop depth 0
>;;pred:   5
>  B::~B (_b.D.2512.m_item);
>;;succ:   7
>
>;;   basic block 7, loop depth 0
>;;pred:   5
>;;6
>  maybe_b ={v} {CLOBBER};
>  resx 3
>;;succ:   8
>
>;;   basic block 8, loop depth 0
>;;pred:   7
>:
>  _9 = VIEW_CONVERT_EXPR(maybe_a$4_7);
>  if (_9 != 0)
>goto ; [0.00%]
>  else
>goto ; [0.00%]
>;;succ:   9
>;;10
>
>Where there is a use of maybe_a$m_6 in block #9.
>
>Of course maybe_a$m_6 only takes the value of maybe_a$m_4(D) when we
>traverse the
>edge 2->5 but in that case maybe_a$4_7 will always have the value zero
>and thus
>we can not reach bb #9..  But the V_C_E gets in the way of the analysis
>and we
>issue the false positive warning.  Martin Jambor has indicated that he
>doesn't
>see a way to avoid the V_C_E from SRA without reintroducing PR52244.
>
>This patch optimizes the V_C_E into a NOP_EXPR by verifying that the
>V_C_E folds
>to a constant value for the min & max values of the range of the input
>operand
>and the result of folding is equal to the original input.  We do some
>additional
>checking beyond just that original value and converted value are equal
>according
>to operand_equal_p.
>
>Eventually the NOP_EXPR also gets removed as well and the conditional
>in bb8
>tests maybe_a$4_7 against 0 directly.
>
>That in turn allows the uninit analysis to determine the use of
>maybe_a$_m_6 in
>block #9 is properly guarded and the false positive is avoided.
>
>The optimization of a V_C_E into a NOP_EXPR via this patch occurs a
>couple
>hundred times during a bootstrap, so this isn't a horribly narrow
>change just to
>fix a false positive warning.
>
>Bootstrapped and regression tested on x86_64.  I've also put it through
>its paces
>in the tester.  The tester's current failures (aarch64, mips, h8) are
>unrelated
>to this patch.
>
>
>Thoughts?  OK for the trunk?  Alternately I wouldn't lose sleep moving
>this to
>gcc-11.

ISTR Ada uses V_C_E to implement checks on value ranges to types. We need to 
make sure to not interfere with this. 

Richard. 

>
>jeff

RE: [PATCH]Microblaze: Modified trap instruction

2020-04-05 Thread Nagaraju Mekala 
> -Original Message-
> From: Jeff Law 
> Sent: Sunday, April 5, 2020 9:36 PM
> To: Michael Eager ; Nagaraju Mekala
> ; gcc-patches@gcc.gnu.org
> Cc: Sadanand Mutyala 
> Subject: Re: [PATCH]Microblaze: Modified trap instruction
> 
> On Sat, 2020-04-04 at 11:15 -0700, Michael Eager wrote:
> > OK to apply.
Thank you.
> >
> > On 4/4/20 1:59 AM, Nagaraju Mekala wrote:
> > > Hello All,
> > >
> > >  There is a bug in trap instruction generation.
> > >  Instead of "bri 0" instruction "brki r0, -1" was used, corrected it 
> > > now.
> > >
> > >  ChangeLog:
> > >  2020-04-04 Nagaraju Mekala 
> > >
> > >  * gcc/config/microblaze/microblaze.md
> > >  (trap): update in the pattern
> > >  * gcc/testsuite/gcc.target/microblaze/others/builtin-trap.c
> > >  (dg-final): update in the scan-assembler instruction
> I fixed up nits in the ChangeLog and committed the patch on Nagaraju's
> behalf.
Thank you.
- Nagaraju
>
> jeff
> > >

RE: [PATCH]Microblaze: Fixed missing save of r18 in fast_interrupt.

2020-04-05 Thread Nagaraju Mekala 
> -Original Message-
> From: Jeff Law 
> Sent: Sunday, April 5, 2020 9:45 PM
> To: Michael Eager ; Nagaraju Mekala
> ; gcc-patches@gcc.gnu.org
> Cc: Sadanand Mutyala ; klauspeter...@gmail.com
> Subject: Re: [PATCH]Microblaze: Fixed missing save of r18 in fast_interrupt.
> 
> On Sat, 2020-04-04 at 11:16 -0700, Michael Eager wrote:
> > OK to apply.
Thank you.

> > On 4/4/20 2:18 AM, Nagaraju Mekala wrote:
> > > Hello All,
> > >
> > > Fixed missing save of r18 in fast_interrupt.
> > > Register 18 is used as a clobber register, and must be stored when
> > > entering a fast_interrupt. Before this fix, register 18 was only
> > > saved if it was used directly in the interrupt function.
> > >
> > > However, if the fast_interrupt function called a function that used
> > > r18, the register would not be saved, and thus be mangled upon
> > > returning from the interrupt.
> > >
> > > Changelog
> > >  2020-04-04  Klaus Petersen 
> > >   * gcc/config/microblaze/microblaze.c: Check for fast_interrupt 
> > > in
> > >  microblaze_must_save_register.
> > >
> > >  Signed-off-by: Klaus Petersen 
> > >  Signed-off-by :Nagaraju Mekala 
> Fixed up the ChangeLog and trailing whitespace nits and pushed to the trunk.
Thank you. I will take care of it from next time.
- Nagaraju
> THanks,
> jeff
>

Re: [PATCH]Microblaze: Fixed missing save of r18 in fast_interrupt.

2020-04-05 Thread Jeff Law via Gcc-patches 
On Sat, 2020-04-04 at 11:16 -0700, Michael Eager wrote:
> OK to apply.
> 
> On 4/4/20 2:18 AM, Nagaraju Mekala wrote:
> > Hello All,
> > 
> > Fixed missing save of r18 in fast_interrupt.
> > Register 18 is used as a clobber register, and must be stored when entering 
> > a
> > fast_interrupt. Before this fix, register 18 was only saved if it was used
> > directly in the interrupt function.
> >  
> > However, if the fast_interrupt function called a function that used r18, the
> > register would not be saved, and thus be mangled upon returning from the
> > interrupt.
> >  
> > Changelog
> >  2020-04-04  Klaus Petersen 
> >   * gcc/config/microblaze/microblaze.c: Check for fast_interrupt in
> >  microblaze_must_save_register.
> > 
> >  Signed-off-by: Klaus Petersen 
> >  Signed-off-by :Nagaraju Mekala 
Fixed up the ChangeLog and trailing whitespace nits and pushed to the trunk.

THanks,
jeff

Re: [PATCH]Microblaze: Modified trap instruction

2020-04-05 Thread Jeff Law via Gcc-patches 
On Sat, 2020-04-04 at 11:15 -0700, Michael Eager wrote:
> OK to apply.
> 
> On 4/4/20 1:59 AM, Nagaraju Mekala wrote:
> > Hello All,
> > 
> >  There is a bug in trap instruction generation.
> >  Instead of "bri 0" instruction "brki r0, -1" was used, corrected it 
> > now.
> >  
> >  ChangeLog:
> >  2020-04-04 Nagaraju Mekala 
> >  
> >  * gcc/config/microblaze/microblaze.md
> >  (trap): update in the pattern
> >  * gcc/testsuite/gcc.target/microblaze/others/builtin-trap.c
> >  (dg-final): update in the scan-assembler instruction
I fixed up nits in the ChangeLog and committed the patch on Nagaraju's behalf.

jeff
> >

[RFA/RFC] [PR tree-optimization/80635] Optimize some V_C_Es with limited ranges into NOP_EXPRs

2020-04-05 Thread Jeff Law via Gcc-patches 

So here's an approach to try and address PR80635.

In this BZ we're getting a false positive uninitialized warning using
std::optional.

As outlined in the BZ this stems from SRA using a VIEW_CONVERT_EXPR  which isn't
handled terribly well by the various optimizers/analysis passes.

We have these key blocks:

;;   basic block 5, loop depth 0
;;pred:   3
;;2
  # maybe_a$m_6 = PHI <_5(3), maybe_a$m_4(D)(2)>
  # maybe_a$4_7 = PHI <1(3), 0(2)>
:
  _8 = maybe_b.live;
  if (_8 != 0)
goto ; [0.00%]
  else
goto ; [0.00%]
;;succ:   6
;;7

;;   basic block 6, loop depth 0
;;pred:   5
  B::~B (_b.D.2512.m_item);
;;succ:   7

;;   basic block 7, loop depth 0
;;pred:   5
;;6
  maybe_b ={v} {CLOBBER};
  resx 3
;;succ:   8

;;   basic block 8, loop depth 0
;;pred:   7
:
  _9 = VIEW_CONVERT_EXPR(maybe_a$4_7);
  if (_9 != 0)
goto ; [0.00%]
  else
goto ; [0.00%]
;;succ:   9
;;10

Where there is a use of maybe_a$m_6 in block #9.

Of course maybe_a$m_6 only takes the value of maybe_a$m_4(D) when we traverse 
the
edge 2->5 but in that case maybe_a$4_7 will always have the value zero and thus
we can not reach bb #9..  But the V_C_E gets in the way of the analysis and we
issue the false positive warning.  Martin Jambor has indicated that he doesn't
see a way to avoid the V_C_E from SRA without reintroducing PR52244.

This patch optimizes the V_C_E into a NOP_EXPR by verifying that the V_C_E folds
to a constant value for the min & max values of the range of the input operand
and the result of folding is equal to the original input.  We do some additional
checking beyond just that original value and converted value are equal according
to operand_equal_p.

Eventually the NOP_EXPR also gets removed as well and the conditional in bb8
tests maybe_a$4_7 against 0 directly.

That in turn allows the uninit analysis to determine the use of maybe_a$_m_6 in
block #9 is properly guarded and the false positive is avoided.

The optimization of a V_C_E into a NOP_EXPR via this patch occurs a couple
hundred times during a bootstrap, so this isn't a horribly narrow change just to
fix a false positive warning.

Bootstrapped and regression tested on x86_64.  I've also put it through its 
paces
in the tester.  The tester's current failures (aarch64, mips, h8) are unrelated
to this patch.


Thoughts?  OK for the trunk?  Alternately I wouldn't lose sleep moving this to
gcc-11.

jeff


PR tree-optimization/90635
* vr-values.c (simplify_stmt_using_ranges): Simplify V_C_E into
NOP_EXPR in some cases.

* g++.dg/warn/Wuninitialized-11.C: New test.


diff --git a/gcc/testsuite/g++.dg/warn/Wuninitialized-11.C 
b/gcc/testsuite/g++.dg/warn/Wuninitialized-11.C
new file mode 100644
index 000..8e3782264bb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wuninitialized-11.C
@@ -0,0 +1,46 @@
+// { dg-do compile { target c++11 } } 
+// { dg-options "-O2 -Wuninitialized" }
+
+using size_t = decltype(sizeof(1));
+inline void *operator new (size_t, void *p) { return p; }
+template
+struct optional
+{
+  optional () : m_dummy (), live (false) {}
+  void emplace () { new (_item) T (); live = true; }
+  ~optional () { if (live) m_item.~T (); }
+
+  union
+  {
+struct {} m_dummy;
+T m_item;
+  };
+  bool live;
+};
+
+
+extern int get ();
+extern void set (int);
+
+struct A
+{
+  A () : m (get ()) {}
+  ~A () { set (m); }
+
+  int m;
+};
+
+struct B
+{
+  B ();
+  ~B ();
+};
+
+void func ()
+{
+  optional maybe_a;
+  optional maybe_b;
+
+  maybe_a.emplace ();
+  maybe_b.emplace ();
+}
diff --git a/gcc/vr-values.c b/gcc/vr-values.c
index 2e3a0788710..bfd3f4f2cea 100644
--- a/gcc/vr-values.c
+++ b/gcc/vr-values.c
@@ -4308,6 +4308,54 @@ vr_values::simplify_stmt_using_ranges 
(gimple_stmt_iterator *gsi)
return simplify_bit_ops_using_ranges (gsi, stmt);
  break;
 
+
+   case VIEW_CONVERT_EXPR:
+ /* If we're converting an object with a range which is
+directly representable in the final type, then just
+turn the VIEW_CONVERT_EXPR into a NOP_EXPR.
+
+Various optimizers/analyzers handle the NOP_EXPR
+better than VIEW_CONVERT_EXPR.  */
+ if (TREE_CODE (TREE_OPERAND (rhs1, 0)) == SSA_NAME)
+   {
+ const value_range_equiv *vr
+   = get_value_range (TREE_OPERAND (rhs1, 0));
+ if (vr->kind () == VR_RANGE)
+   {
+ /* See if the min and max values convert to themselves.  */
+ tree min = vr->min ();
+ tree max = vr->min ();
+ tree min_converted = const_unop (VIEW_CONVERT_EXPR,
+  TREE_TYPE (lhs),
+  min);
+ tree max_converted = const_unop (VIEW_CONVERT_EXPR,
+

New Swedish PO file for 'gcc' (version 10.1-b20200322)

2020-04-05 Thread Translation Project Robot 
Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-10.1-b20200322.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[PATCH] lra: Stop eh_return data regs being incorrectly marked live [PR92989]

2020-04-05 Thread Richard Sandiford 
lra_assign has an assert to make sure that no pseudo is allocated
to a conflicting hard register.  It used to be restricted to
!flag_ipa_ra, but in g:a1e6ee38e708ef2bdef4 I'd enabled it for
flag_ipa_ra too.  It then tripped a few times while building
libstdc++ for mips-mti-linux.

Previous patches fixed one of the problems: registers clobbered
by the taking of an exception were being treated as live at the
beginning of the EH receiver, and this got propagated to predecessor
blocks.  But it turns out that there was a second problem: eh_return
data registers were also being marked live in the same way.

These registers are defined by the unwinder and so in reality they
really are live on entry to the EH receiver.  But definitions can
only happen in blocks, not on edges, so for liveness purposes
we use artificial definitions at the start of the EH receiver.
process_bb_lives should therefore model the effect of a definition,
not a plain use.

Tested this time by building a full mips-mti-linux-gnu toolchain
(including the prerequisite 26 glibc sysroots).  Also boostrapped
& regression tested on aarch64-linux-gnu and x86_64-linux-gnu.
OK to install?

Richard


2020-04-05  Richard Sandiford  

gcc/
PR rtl-optimization/92989
* lra-lives.c (process_bb_lives): Do not treat eh_return data
registers as being live at the beginning of the EH receiver.
---
 gcc/lra-lives.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/lra-lives.c b/gcc/lra-lives.c
index c8780779a11..917c617903f 100644
--- a/gcc/lra-lives.c
+++ b/gcc/lra-lives.c
@@ -1014,13 +1014,19 @@ process_bb_lives (basic_block bb, int _point, bool 
dead_insn_p)
 }
 
   if (bb_has_eh_pred (bb))
+/* Any pseudos that are currently live conflict with the eh_return
+   data registers.  For liveness purposes, these registers are set
+   by artificial definitions at the start of the BB, so are not
+   actually live on entry.  */
 for (j = 0; ; ++j)
   {
unsigned int regno = EH_RETURN_DATA_REGNO (j);
 
if (regno == INVALID_REGNUM)
  break;
+
make_hard_regno_live (regno);
+   make_hard_regno_dead (regno);
   }
 
   /* Pseudos can't go in stack regs at the start of a basic block that