Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project

[Prasad Ghangal]

On 23 August 2016 at 21:15, Prasad Ghangal  wrote:
> On 23 August 2016 at 02:56, David Malcolm  wrote:
>> On Tue, 2016-08-23 at 00:10 +0530, Prasad Ghangal wrote:
>>> On 22 August 2016 at 16:55, Trevor Saunders 
>>> wrote:
>>> > On Sun, Aug 21, 2016 at 10:35:17PM +0530, Prasad Ghangal wrote:
>>
>> [...]
>>
>>> > @@ -228,6 +228,12 @@ struct GTY(()) function {
>>> >/* GIMPLE body for this function.  */
>>> >gimple_seq gimple_body;
>>> >
>>> > +  /* GIMPLEFE pass to start with */
>>> > +  opt_pass *pass_startwith = NULL;
>> I'm guessing you've only compiled in C++11 mode? because I'm pretty
>>> > sure
>>> > you are using a C++11 feature here (the default member value you
>>> > assign).
>>>
>>
>> [...]
>>
>>> I am not getting what did you mean by C++11 mode (I am not explicitly
>>
>> Prasad: what compiler version are you using to build your patched gcc?
>>  My guess is that you're using gcc 6 to build.
>>
> I am using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.1)
>
>> In gcc 6 we changed the default C++ mode from -std=gnu++98
>> to -std=gnu++14. See:
>>   https://gcc.gnu.org/gcc-6/porting_to.html#gxx14
>>
>> I believe the syntax that Trevor spotted is only available in C++11
>> onwards:
>>
>>   $ cat test.cc
>>   struct foo
>>   {
>> int field = 42;
>>   };
>>
>> With the default for gcc 6:
>>
>>   $ gcc -c test.cc -std=c++14
>>
>> it has no problems, whereas with the default for gcc 5 and earlier:
>>
>>   $ gcc -c test.cc -std=gnu++98
>>   test.cc:3:15: warning: non-static data member initializers only
>> available with -std=c++11 or -std=gnu++11
>>int field = 42;
>>^~
>>
> and it does give me the warning. I will try compiling on < 5 version.
>
I have successfully bootstrapped using gcc 4.8 version. I think while
stage2+ builds it is putting -std=gnu++11 flag. Should I remove C++11
syntax ?


Thanks,
Prasad

>> So it's probably worth attempting to bootstrap with an older gcc as the
>> starting compiler.
>>
>> Hope this is helpful
>> Dave
>
> Re-attaching the patch as it has a typo
>
>
> Thanks,
> Prasad

[Patch, libstdc++/77356] Support escape in regex bracket expression

[Tim Shen]

I didn't realized that we can actually escape a dash inside bracket
expression: R"([\-])", in which case the dash should be treated
literally.

Tell me if you feel like we need more documentations. :P

Bootstrapped and tested on x86_64-linux-gnu.

Thanks!

-- 
Regards,
Tim Shen
commit 404a69b17f7fddc9856e9664e304f122601f212f
Author: Tim Shen 
Date:   Wed Aug 24 00:06:54 2016 -0700

2016-08-25  Tim Shen  

PR libstdc++/77356
* include/bits/regex_compiler.tcc(_M_insert_bracket_matcher,
_M_expression_term): Modify to support dash literal.
* include/bits/regex_scanner.h: Add dash as a token type to make
a different from the mandated dash literal by escaping.
* include/bits/regex_scanner.tcc(_M_scan_in_bracket): Emit dash
token in bracket expression parsing.
* testsuite/28_regex/regression.cc: Add new testcase.

diff --git a/libstdc++-v3/include/bits/regex_compiler.tcc 
b/libstdc++-v3/include/bits/regex_compiler.tcc
index ff69e16..3ffa170 100644
--- a/libstdc++-v3/include/bits/regex_compiler.tcc
+++ b/libstdc++-v3/include/bits/regex_compiler.tcc
@@ -426,13 +426,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   pair __last_char; // Optional<_CharT>
   __last_char.first = false;
   if (!(_M_flags & regex_constants::ECMAScript))
-   if (_M_try_char())
- {
-   __matcher._M_add_char(_M_value[0]);
-   __last_char.first = true;
-   __last_char.second = _M_value[0];
- }
+   {
+ if (_M_try_char())
+   {
+ __last_char.first = true;
+ __last_char.second = _M_value[0];
+   }
+ else if (_M_match_token(_ScannerT::_S_token_bracket_dash))
+   {
+ __last_char.first = true;
+ __last_char.second = '-';
+   }
+   }
   while (_M_expression_term(__last_char, __matcher));
+  if (__last_char.first)
+   __matcher._M_add_char(__last_char.second);
   __matcher._M_ready();
   _M_stack.push(_StateSeqT(
  *_M_nfa,
@@ -449,19 +457,35 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   if (_M_match_token(_ScannerT::_S_token_bracket_end))
return false;
 
+  const auto __push_char = [&](_CharT __ch)
+  {
+   if (__last_char.first)
+ __matcher._M_add_char(__last_char.second);
+   else
+ __last_char.first = true;
+   __last_char.second = __ch;
+  };
+
   if (_M_match_token(_ScannerT::_S_token_collsymbol))
{
  auto __symbol = __matcher._M_add_collate_element(_M_value);
  if (__symbol.size() == 1)
-   {
- __last_char.first = true;
- __last_char.second = __symbol[0];
-   }
+   __push_char(__symbol[0]);
+ else
+   __last_char.first = false;
}
   else if (_M_match_token(_ScannerT::_S_token_equiv_class_name))
-   __matcher._M_add_equivalence_class(_M_value);
+   {
+ __last_char.first = false;
+ __matcher._M_add_equivalence_class(_M_value);
+   }
   else if (_M_match_token(_ScannerT::_S_token_char_class_name))
-   __matcher._M_add_character_class(_M_value, false);
+   {
+ __last_char.first = false;
+ __matcher._M_add_character_class(_M_value, false);
+   }
+  else if (_M_try_char())
+   __push_char(_M_value[0]);
   // POSIX doesn't allow '-' as a start-range char (say [a-z--0]),
   // except when the '-' is the first or last character in the bracket
   // expression ([--0]). ECMAScript treats all '-' after a range as a
@@ -472,55 +496,55 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // Clang (3.5) always uses ECMAScript style even in its POSIX syntax.
   //
   // It turns out that no one reads BNFs ;)
-  else if (_M_try_char())
+  else if (_M_match_token(_ScannerT::_S_token_bracket_dash))
{
  if (!__last_char.first)
{
- __matcher._M_add_char(_M_value[0]);
- if (_M_value[0] == '-'
- && !(_M_flags & regex_constants::ECMAScript))
+ if (!(_M_flags & regex_constants::ECMAScript))
{
  if (_M_match_token(_ScannerT::_S_token_bracket_end))
-   return false;
+   {
+ __push_char('-');
+ return false;
+   }
  __throw_regex_error(
regex_constants::error_range,
"Unexpected dash in bracket expression. For POSIX syntax, "
"a dash is not treated literally only when it is at "
"beginning or end.");
}
- __last_char.first = true;
- __last_char.second = _M_value[0];
+ __push_char('-');
}
  else
{
- if (_M_value[0] == '-')
+ if (_M_try_char())
 

RE: [PATCH 3/4] Add support to run auto-vectorization tests for multiple effective targets

[Robert Suchanek]

> On 08/23/2016 04:15 PM, Trevor Saunders wrote:
> >
> > I've certainly been tempted to take a stab at at least replacing the
> > expect stuff with something else, it drives me kind of crazy to see how
> > much testsuite time is spent running expect.  Even if we can't do all of
> > it, the vast majority is just run the compiler and grep dump files or
> > the compiler's stdout / stderr.
> Yup.  When Rob was making noise about rewriting dejagnu I tried to steer
> him a bit towards instead replacing the expect layer, but his plans
> where more on the tcl/dejagnu side.  I don't think anything ever came
> out of that proposal.
> 
> Expect is severe overkill for what we need and yes, it burns an amazing
> about of CPU time for what get out of it.
> 
> Jeff

True.  I wasn't considering replacing the expect layer, just to overcome
the limitation of auto-vect tests.  This in itself is rather another hack
but didn't have a suggestion what to replace it with.

Regards,
Robert

RE: [PATCH 3/4] Add support to run auto-vectorization tests for multiple effective targets

[Robert Suchanek]

Hi Jeff,

> > The following patch reverts to the old behaviour. I also removed misleading
> > comments and related logic that checks for the cached result.  There might 
> > be
> > other procedures with similar inconsistency but here I only modified the
> offending ones.
> Thanks.  Given how much cut-n-paste we do with the tcl code there's a
> good chance this problem exists elsewhere.   I don't start ranting about
> tcl/dejagnu, I'll just put me in a terrible mood for the rest of the day.

Indeed.

> > Alternatively, it would be possible to switch to the new method and do the
> caching
> > but it is more intrusive change that requires careful analysis of the 
> > results
> > and the tests will not likely be directly comparable with old results
> (because of
> > flag mixing into the test names).  It's safer to restore the original
> behaviour
> > as the patch was not supposed to change any existing results.
> I'd go with the safer approach for now -- I keep holding out hope that
> there's a silver bullet out there that will allow us to replace dejagnu
> and all its tcl goop some day.

I noticed over time that tcl/dejagnu have a unique set of features.
Replacing them with something else at some point wouldn't be a bad thing.

> 
> >
> > Ok to apply?
> >
> > Regards,
> > Robert
> >
> > gcc/testsuite/
> > * lib/target-supports.exp
> > (check_effective_target_vect_aligned_arrays): Don't cache the result.
> > (check_effective_target_vect_natural_alignment): Ditto.
> > (check_effective_target_vector_alignment_reachable): Ditto.
> > (check_effective_target_vector_alignment_reachable_for_64bit): Ditto.
> OK.
> jeff
> >

Committed as r239730.

Regards,
Robert

Re: [PATCH 0/4] Applying fix-its on behalf of the user to their code

[Richard Biener]

On Wed, Aug 24, 2016 at 3:28 AM, David Malcolm  wrote:
> Currently our diagnostics subsystem can emit fix-it hints
> suggesting edits the user can make to their code to fix warnings/errors,
> but currently the user must make these edits manually [1].
>
> The following patch kit adds two command-line options with which
> we can make the changes on behalf of the user:
>
> (A) -fdiagnostics-generate-patch emits a diff to stderr, which
> could potentially be applied using "patch"; it also gives another
> way to visualize the fix-its.
>
> (B) -fdiagnostics-apply-fixits, which writes back the changes
> to the input files.

I don't like this very much - option (A) looks good with the user having
to manually apply a patch.  But (B) is just asking for trouble ;)

I'd rather have -fdiagnostics-apply-fixits apply the fixit hints for
the current compilation only (so you'll see if the compile is successful
after applying the suggestions).  That is, work more in a "error recovery"
mode.

Richard.

> Patches 1 and 2 are enabling work.
>
> Patch 3 is the heart of the kit: a new class edit_context,
> representing a set of changes to be applied to source file(s).
> The changes are atomic: all are applied or none [2], and locations are
> specified relative to the initial inputs (and there's some fiddly
> logic for fixing up locations so that the order in which edits are
> applied doesn't matter).
>
> Patch 4 uses the edit_context class to add the new options.
>
> The kit also unlocks the possibility of writing refactoring tools
> as gcc plugins, or could be used to build a parser for the output
> of -fdiagnostics-parseable-fixits.
>
> Successfully bootstrapped®rtested the combination of the patches
> on x86_64-pc-linux-gnu.
>
> I believe I can self-approve patch 3, and, potentially patch 4
> as part of my "diagnostics maintainer" role, though this is
> clearly a significant extension of the scope of diagnostics.
>
> OK for trunk? (assuming individual bootstraps®rtesting)
>
> [1] or use -fdiagnostics-parseable-fixits - but we don't have a
> way to parse that output format yet
> [2] the error-handling for write-back isn't great right now, so
> the claim of atomicity is a stretch; is there a good cross-platform
> way to guarantee atomicity of a set of filesystem operations?
> (maybe create the replacements as tempfiles, rename the originals,
> try to move all the replacements into place, and then unlink the
> backups, with a rollback involving moving the backups into place)
>
> David Malcolm (4):
>   selftest: split out named_temp_file from temp_source_file
>   Improvements to typed_splay_tree
>   Introduce class edit_context
>   Add -fdiagnostics-generate-patch and -fdiagnostics-apply-fixits
>
>  gcc/Makefile.in|2 +
>  gcc/common.opt |8 +
>  gcc/diagnostic-color.c |8 +-
>  gcc/diagnostic.c   |   11 +
>  gcc/diagnostic.h   |7 +
>  gcc/doc/invoke.texi|   28 +-
>  gcc/edit-context.c | 1341 
> 
>  gcc/edit-context.h |   66 +
>  gcc/selftest-run-tests.c   |2 +
>  gcc/selftest.c |   49 +-
>  gcc/selftest.h |   26 +-
>  .../diagnostic-test-show-locus-generate-patch.c|   77 ++
>  gcc/testsuite/gcc.dg/plugin/plugin.exp |3 +-
>  gcc/toplev.c   |   20 +
>  gcc/typed-splay-tree.c |   79 ++
>  gcc/typed-splay-tree.h |   67 +
>  16 files changed, 1770 insertions(+), 24 deletions(-)
>  create mode 100644 gcc/edit-context.c
>  create mode 100644 gcc/edit-context.h
>  create mode 100644 
> gcc/testsuite/gcc.dg/plugin/diagnostic-test-show-locus-generate-patch.c
>  create mode 100644 gcc/typed-splay-tree.c
>
> --
> 1.8.5.3
>

Re: [PATCH] Remove whitespace

[Jonathan Wakely]

On 22/08/16 23:38 +0100, Jonathan Wakely wrote:

On 22/08/16 15:30 -0700, Mike Stump wrote:

On Aug 22, 2016, at 2:45 PM, Aditya Kumar  wrote:


libstdc++-v3/ChangeLog  |   5 +
libstdc++-v3/include/bits/algorithmfwd.h| 206 ++--
libstdc++-v3/include/bits/shared_ptr_base.h |  26 ++--
3 files changed, 121 insertions(+), 116 deletions(-)



diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index 299bce6..88d908d 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,8 @@
+2016-08-22  Aditya Kumar 


blank line here.


And two spaces between name and email address.


+   * libstdc++-v3/include/bits/algorithmfwd.h: Remove WS
+   * libstdc++-v3/include/bits/shared_ptr_base.h: Remove WS



+
+


One less blank line here.

Also, all libstdc++ must also be copied to the libstdc++ list, otherwise, they 
won't even see it.


Yep, I can't comment on the actual patch, because I haven't seen it.


Patch committed to trunk now, thanks.

Re: [PATCH, ARM] Fix aprofile multilib mappings

[Ramana Radhakrishnan]

On 10/08/16 14:28, Thomas Preudhomme wrote:
> Hi,
> 
> Mappings (MULTILIB_MATCHES and MULTILIB_REUSE) in ARM aprofile multilib 
> suffer from a number of issues:
> 
> * missing mapping of -mcpu=cortex-a7 to -march=armv7-a

You mean -march=armv7ve...

> * typo on vfpv3-d16-fp16 (MULTILIB_MATCHES uses vfpv3-fp16-d16 instead)
> * missing mapping for neon-fp16, fpv5-d16 and fp-armv8 to neon, vfpv4 and 
> vfpv4 respectively
> * reuse directive with option not in MULTILIB_OPTION (-mfpu=vfpv4 and 
> -mfpu=fp-armv8)
> 
> The latter leads to unexpected results currently: GCC creates a reuse mapping 
> that match for any -mfpu not in MULTILIB_OPTIONS. This means for instance 
> that -march=armv7-a -mfpu=vfp -mfloat-abi=hard is mapped to -march=armv7-a 
> -mfpu=vfpv3-d16 -mfloat-abi=hard. With this patch, it is now mapped to the 
> default multilib (ie. -print-multi-directory gives .) which is a softfloat 
> multilib. Arguably an option not in MULTILIB_OPTIONS should give an error 
> when appearing in MULTILIB_REUSE rather the current behavior. This should be 
> the object of a future patch.
> 
> The patch in attachment fixes all the issues mentioned above.
> 
> ChangeLog entry is as follows:
> 
> 
> *** gcc/ChangeLog ***
> 
> 2016-08-01  Thomas Preud'homme  
> 
> * config/arm/t-aprofile (MULTILIB_MATCHES): Add mapping for
> -mcpu=cortex-a7, -mfpu=neon-fp16, -mfpu=fpv5-d16 and -mfpu=fp-armv8.
> Fix typo in -mfpu=vfpv3-d16-fp16 mapping.
> (MULTILIB_REUSE): Remove reuse rules for option set including
> -mfpu=fp-armv8 and -mfpu=vfpv4
> 


OK.

Ramana
> 
> The mappings added have been tested to work as expected and the option 
> combinations that the intended behavior of removed MULTILIB_REUSE directives 
> were checked as well. For details, see [1]. Regression testsuite for 
> arm-none-eabi with aprofile multilib shows no regression.
> 
> Is this ok for trunk?
> 
> Best regards,
> 
> Thomas
> 
> 
> [1] Format of the tests is as follows:
> 
> # expected mapping
> % command line for getting multilib we should be mapping to
> expected result
> % command line for the multilib that should be mapped to the one above
> [before] result without patch
> [ after] result with patch
> 
> Provided that the second set of options should indeed be mapped to the first 
> set, the result [ after] should be the same as the expected result.
> 
> 
> # cortex-a7 -> armv7-a
> % arm-none-eabi-gcc -march=armv7ve -print-multi-directory
> v7ve
> % arm-none-eabi-gcc -mcpu=cortex-a7 -print-multi-directory
> [before] .
> [ after] v7ve
> 
> # vfpv3-d16-fp16 -> vfpv3-d16
> % arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv3-d16 -mfloat-abi=hard 
> -print-multi-directory
> v7-a/fpv3/hard
> % arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv3-d16-fp16 -mfloat-abi=hard 
> -print-multi-directory
> [before] v7ve/fpv4/hard
> [ after] v7-a/fpv3/hard
> 
> # neon-fp16 -> neon
> arm-none-eabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard 
> -print-multi-directory
> v7-a/simdv1/hard
> % arm-none-eabi-gcc -march=armv7-a -mfpu=neon-fp16 -mfloat-abi=hard 
> -print-multi-directory
> [before] v7-a/fpv3/hard
> [ after] v7-a/simdv1/hard
> 
> # fpv5-d16 -> vfpv4-d16
> % arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv4-d16 -mfloat-abi=hard 
> -print-multi-directory
> v7ve/fpv4/hard
> % arm-none-eabi-gcc -march=armv7ve -mfpu=fpv5-d16 -mfloat-abi=hard 
> -print-multi-directory
> [before] v7ve/fpv4/hard
> [ after] v7ve/fpv4/hard
> 
> # fp-armv8 -> vfpv4-d16
> % arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv4-d16 -mfloat-abi=hard 
> -print-multi-directory
> v7ve/fpv4/hard
> % arm-none-eabi-gcc -march=armv7ve -mfpu=fp-armv8 -mfloat-abi=hard 
> -print-multi-directory
> [before] v7ve/fpv4/hard
> [ after] v7ve/fpv4/hard
> 
> # armv7-a vfpv4 softfp -> armv7-a vfpv3-d16 softfp
> % arm-none-eabi-gcc -march=armv7-a -mfpu=vfpv4-d16 -mfloat-abi=softfp 
> -print-multi-directory
> v7-a/fpv3/softfp
> % arm-none-eabi-gcc -march=armv7-a -mfpu=vfpv4 -mfloat-abi=softfp 
> -print-multi-directory
> [before] v7-a/fpv3/softfp
> [ after] v7-a/fpv3/softfp
> 
> # armv7-a vfpv4 hard -> armv7-a vfpv3-d16 hard
> % arm-none-eabi-gcc -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard 
> -print-multi-directory
> v7-a/fpv3/hard
> % arm-none-eabi-gcc -march=armv7-a -mfpu=vfpv4 -mfloat-abi=hard 
> -print-multi-directory
> [before] v7-a/fpv3/hard
> [ after] v7-a/fpv3/hard
> 
> # armv7ve fp-armv8 softfp -> armv7ve vfpv4-d16 softfp
> % arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv4-d16 -mfloat-abi=softfp 
> -print-multi-directory
> v7ve/fpv4/softfp
> % arm-none-eabi-gcc -march=armv7ve -mfpu=fp-armv8 -mfloat-abi=softfp 
> -print-multi-directory
> [before] v7ve/fpv4/softfp
> [ after] v7ve/fpv4/softfp
> 
> # armv7ve fp-armv8 hard -> armv7ve vfpv4-d16 hard
> % arm-none-eabi-gcc -march=armv7ve -mfpu=vfpv4-d16 -mfloat-abi=hard 
> -print-multi-directory
> v7ve/fpv4/hard
> % arm-none-eabi-gcc -march=armv7ve -mfpu=fp-armv8 -mfloat-abi=hard 
> -print-multi-directory
> [before] v7ve/fpv4/hard
> [ after

Re: [Patch, libstdc++/77356] Support escape in regex bracket expression

[Jonathan Wakely]

On 24/08/16 00:18 -0700, Tim Shen wrote:

I didn't realized that we can actually escape a dash inside bracket
expression: R"([\-])", in which case the dash should be treated
literally.


With this patch applied I no longer get a match for:

 regex_match("-", std::regex{"[a-]", std::regex_constants::basic})

"[-a]" still works correctly, but they should be equivalent for POSIX
BREs and EREs.




diff --git a/libstdc++-v3/include/bits/regex_scanner.h 
b/libstdc++-v3/include/bits/regex_scanner.h
index 37dea84..2a83d1c 100644
--- a/libstdc++-v3/include/bits/regex_scanner.h
+++ b/libstdc++-v3/include/bits/regex_scanner.h
@@ -73,6 +73,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  _S_token_comma,
  _S_token_dup_count,
  _S_token_eof,
+  _S_token_bracket_dash,
  _S_token_unknown
};


I wonder if we want to give _S_token_unknown an initializer with a
specific value, so it doesn't change whenever we add new tokens.

If we use -1 it would change the underlying type of
_ScannerBase::_TokenT from unsigned int to signed int, so we should
give it a fixed type too:

 struct _ScannerBase
 {
 public:
   /// Token types returned from the scanner.
   enum _TokenT : unsigned
   {
 ...
 _S_token_unknown = -1u

[Patch, testsuite] Fix more bogus test failures for avr

[Senthil Kumar Selvaraj]

Hi,

  This patch fixes a couple of testsuite failures for the avr target by
  requiring int32plus support for zero_sign_ext_test.c, and explicitly
  using __UINT32_TYPE__ instead of assuming 32 bit ints for pr71083.c

  Regtested with avr and x86_64-pc-linux. Committed to trunk.

Regards
Senthil

gcc/testsuite/ChangeLog

2016-08-24  Senthil Kumar Selvaraj  

* gcc.c-torture/execute/pr71083.c: Use UINT32_TYPE instead
of unsigned int.
* gcc.dg/zero_sign_ext_test.c: Require int32plus.


Index: gcc/testsuite/gcc.c-torture/execute/pr71083.c
===
--- gcc/testsuite/gcc.c-torture/execute/pr71083.c   (revision 239731)
+++ gcc/testsuite/gcc.c-torture/execute/pr71083.c   (working copy)
@@ -1,5 +1,7 @@
+__extension__ typedef __UINT32_TYPE__ uint32_t;
+
 struct lock_chain {
-  unsigned int irq_context: 2,
+  uint32_t irq_context: 2,
 depth: 6,
 base: 24;
 };
Index: gcc/testsuite/gcc.dg/zero_sign_ext_test.c
===
--- gcc/testsuite/gcc.dg/zero_sign_ext_test.c   (revision 239731)
+++ gcc/testsuite/gcc.dg/zero_sign_ext_test.c   (working copy)
@@ -2,6 +2,7 @@
 
 /* { dg-options "-O2" } */
 /* { dg-do run } */
+/* { dg-require-effective-target int32plus } */
 
 #define TYPE_MAX(type, sign)   \
   ((!sign) ? ((1 << (sizeof (type) * 8 - 1)) - 1) :\
  

Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project

[Richard Biener]

On Wed, Aug 24, 2016 at 9:02 AM, Prasad Ghangal
 wrote:
> On 23 August 2016 at 21:15, Prasad Ghangal  wrote:
>> On 23 August 2016 at 02:56, David Malcolm  wrote:
>>> On Tue, 2016-08-23 at 00:10 +0530, Prasad Ghangal wrote:
 On 22 August 2016 at 16:55, Trevor Saunders 
 wrote:
 > On Sun, Aug 21, 2016 at 10:35:17PM +0530, Prasad Ghangal wrote:
>>>
>>> [...]
>>>
 > @@ -228,6 +228,12 @@ struct GTY(()) function {
 >/* GIMPLE body for this function.  */
 >gimple_seq gimple_body;
 >
 > +  /* GIMPLEFE pass to start with */
 > +  opt_pass *pass_startwith = NULL;
>>> I'm guessing you've only compiled in C++11 mode? because I'm pretty
 > sure
 > you are using a C++11 feature here (the default member value you
 > assign).

>>>
>>> [...]
>>>
 I am not getting what did you mean by C++11 mode (I am not explicitly
>>>
>>> Prasad: what compiler version are you using to build your patched gcc?
>>>  My guess is that you're using gcc 6 to build.
>>>
>> I am using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.1)
>>
>>> In gcc 6 we changed the default C++ mode from -std=gnu++98
>>> to -std=gnu++14. See:
>>>   https://gcc.gnu.org/gcc-6/porting_to.html#gxx14
>>>
>>> I believe the syntax that Trevor spotted is only available in C++11
>>> onwards:
>>>
>>>   $ cat test.cc
>>>   struct foo
>>>   {
>>> int field = 42;
>>>   };
>>>
>>> With the default for gcc 6:
>>>
>>>   $ gcc -c test.cc -std=c++14
>>>
>>> it has no problems, whereas with the default for gcc 5 and earlier:
>>>
>>>   $ gcc -c test.cc -std=gnu++98
>>>   test.cc:3:15: warning: non-static data member initializers only
>>> available with -std=c++11 or -std=gnu++11
>>>int field = 42;
>>>^~
>>>
>> and it does give me the warning. I will try compiling on < 5 version.
>>
> I have successfully bootstrapped using gcc 4.8 version. I think while
> stage2+ builds it is putting -std=gnu++11 flag. Should I remove C++11
> syntax ?

Yes, we can't use C++ syntax generally.

Thanks,
Richard.

>
> Thanks,
> Prasad
>
>>> So it's probably worth attempting to bootstrap with an older gcc as the
>>> starting compiler.
>>>
>>> Hope this is helpful
>>> Dave
>>
>> Re-attaching the patch as it has a typo
>>
>>
>> Thanks,
>> Prasad

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'gcc' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/gcc-6.2.0.pot

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.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

https://ftp.gnu.org/gnu/gcc/gcc-6.1.0/gcc-6.2.0.tar.bz2

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

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

Re: [PATCH, ARM] Fix aprofile multilib mappings

[Thomas Preudhomme]

On 24/08/16 09:13, Ramana Radhakrishnan wrote:



On 10/08/16 14:28, Thomas Preudhomme wrote:

Hi,

Mappings (MULTILIB_MATCHES and MULTILIB_REUSE) in ARM aprofile multilib suffer 
from a number of issues:

* missing mapping of -mcpu=cortex-a7 to -march=armv7-a


You mean -march=armv7ve...


Yes indeed, as reflected by the new directory used for -mcpu=cortex-a7 after the 
patch (v7ve).





* typo on vfpv3-d16-fp16 (MULTILIB_MATCHES uses vfpv3-fp16-d16 instead)
* missing mapping for neon-fp16, fpv5-d16 and fp-armv8 to neon, vfpv4 and vfpv4 
respectively
* reuse directive with option not in MULTILIB_OPTION (-mfpu=vfpv4 and 
-mfpu=fp-armv8)

The latter leads to unexpected results currently: GCC creates a reuse mapping 
that match for any -mfpu not in MULTILIB_OPTIONS. This means for instance that 
-march=armv7-a -mfpu=vfp -mfloat-abi=hard is mapped to -march=armv7-a 
-mfpu=vfpv3-d16 -mfloat-abi=hard. With this patch, it is now mapped to the 
default multilib (ie. -print-multi-directory gives .) which is a softfloat 
multilib. Arguably an option not in MULTILIB_OPTIONS should give an error when 
appearing in MULTILIB_REUSE rather the current behavior. This should be the 
object of a future patch.

The patch in attachment fixes all the issues mentioned above.

ChangeLog entry is as follows:


*** gcc/ChangeLog ***

2016-08-01  Thomas Preud'homme  

* config/arm/t-aprofile (MULTILIB_MATCHES): Add mapping for
-mcpu=cortex-a7, -mfpu=neon-fp16, -mfpu=fpv5-d16 and -mfpu=fp-armv8.
Fix typo in -mfpu=vfpv3-d16-fp16 mapping.
(MULTILIB_REUSE): Remove reuse rules for option set including
-mfpu=fp-armv8 and -mfpu=vfpv4




OK.


Thanks, committed.

Best regards,

Thomas

Re: Fwd: [PATCH] genmultilib: improve error reporting for MULTILIB_REUSE

[Thomas Preudhomme]

On 18/08/16 17:39, Jeff Law wrote:

On 08/10/2016 09:51 AM, Thomas Preudhomme wrote:



*** gcc/ChangeLog ***

2016-08-01  Thomas Preud'homme  

* doc/fragments.texi (MULTILIB_REUSE): Mention that only options in
MULTILIB_OPTIONS should be used.  Small wording fixes.
* genmultilib: Memorize set of all option combinations in
combination_space.  Detect if RHS of MULTILIB_REUSE uses an
option not
found in MULTILIB_OPTIONS by checking if option set is listed in
combination_space.  Output new and existing error message to
stderr.

[ snip ]



+A reuse rule is comprised of two parts connected by equality sign.  The left
+part is the option set used to build multilib and the right part is the option
+set that will reuse this multilib.  Both part should only use options specified

"Both part" -> "Both parts" I think here.

OK with that change.


Committed with the change, thanks.

Best regards,

Thomas

Re: [patch] [gsoc] [gimplefe] GIMPLE FE Project

[Richard Biener]

On Mon, Aug 22, 2016 at 8:40 PM, Prasad Ghangal
 wrote:
> On 22 August 2016 at 16:55, Trevor Saunders  wrote:
>> On Sun, Aug 21, 2016 at 10:35:17PM +0530, Prasad Ghangal wrote:
>>> Hi all,
>>>
>>> As a part of my gsoc project. I have completed the following tasks:
>>>
>>> * Parsed gimple-expression
>>> * Parsed gimple-labels
>>> * Parsed local declaration
>>> * Parsed gimple-goto statement
>>> * Parsed gimple-if-else statement
>>> * Parsed gimple-switch statement
>>> * Parsed gimple-return statement
>>> * Parsed gimple-PHI function
>>> * Parsed gimple ssa-names along with default def
>>> * Parsed gimple-call
>>>
>>> * Hacked pass manager to add support for startwith (pass-name) to skip
>>> early opt passes
>>> * Modified gimple dump for making it parsable
>>>
>>> I am willing to continue work on the project, some TODOs for the projects 
>>> are:
>>>
>>> * Error handling
>>> * Parse more gimple syntax
>>> * Add startwith support for IPA passes
>>>
>>> The complete code of gimple fe project can be found at
>>> https://github.com/PrasadG193/gcc_gimple_fe
>>>
>>>
>>> PFA patch for complete project (rebased for latest trunk revision).
>>> I have successfully bootstrapped and tested on x86_64-pc-linux-gnu.
>>> Some testcases failed due to modified gimple dump as expected.
>>>
>>>
>>> Thanks,
>>> Prasad
>>
>> only some rather minor comments
>>
>>
>> +++ b/gcc/c/c-parser.c
>> @@ -59,6 +59,18 @@ along with GCC; see the file COPYING3.  If not see
>>  #include "gimple-expr.h"
>>  #include "context.h"
>>  #include "gcc-rich-location.h"
>> +#include "tree-vrp.h"
>>
>> given that you need these headers it might be better to put most of the
>> gimple parsing in its own file so only what actually needs to know about
>> this part of the compiler does now about it.
>>
>> +void
>> +c_parser_parse_gimple_body (c_parser *parser)
>> +{
>> +  bool return_p = false;
>> +  gimple_seq seq;
>> +  gimple_seq body;
>> +  tree stmt = push_stmt_list ();
>>
>> it would be nice to move the declarations down to their first use.
>>
>> +  gimple *ret;
>> +  ret = gimple_build_return (NULL);
>>
>> there's no reason for a separate declaration and assignment ;)
>>
>> +  tree block = NULL;
>> +  block = pop_scope ();
>>
>> same here, and a number of other places.
>>
>> +c_parser_gimple_compound_statement (c_parser *parser, gimple_seq *seq)
>> +{
>> +  bool return_p = false;
>> +
>> +  if (!c_parser_require (parser, CPP_OPEN_BRACE, "expected %<{%>"))
>> +  return return_p;
>>
>> return false would work fine.
>>
>> +
>> +  if (c_parser_next_token_is (parser, CPP_CLOSE_BRACE))
>> +{
>> +  c_parser_consume_token (parser);
>> +  goto out;
>>
>> I don't see the need for the gotos, there's no cleanup in this function.
>>
>> +  /* gimple PHI expression.  */
>> +  if (c_parser_next_token_is_keyword (parser, RID_PHI))
>> +{
>> +  c_parser_consume_token (parser);
>> +
>> +  if (!c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
>> +   {
>> + return;
>> +   }
>> +
>> +  gcall *call_stmt;
>> +  tree arg = NULL_TREE;
>> +  vec vargs = vNULL;
>>
>> I think you can use auto_vec here, as is I think this leaks the vectors
>> storage.
>>
>> +c_parser_gimple_binary_expression (c_parser *parser, enum tree_code 
>> *subcode)
>>
>> you can skip the explicit 'enum' keyword.
>>
>> +  struct {
>> +/* The expression at this stack level.  */
>> +struct c_expr expr;
>>
>> similar with struct here.
>>
>> +/* The precedence of the operator on its left, PREC_NONE at the
>> +   bottom of the stack.  */
>> +enum c_parser_prec prec;
>> +/* The operation on its left.  */
>> +enum tree_code op;
>> +/* The source location of this operation.  */
>> +location_t loc;
>> +  } stack[2];
>> +  int sp;
>> +  /* Location of the binary operator.  */
>> +  location_t binary_loc = UNKNOWN_LOCATION;  /* Quiet warning.  */
>> +#define POP 
>>  \
>>
>> it seems like it would be nicer to name the type, and then make this a
>> function.
>>
>> +   RO_UNARY_STAR);
>> +   ret.src_range.m_start = op_loc;
>> +   ret.src_range.m_finish = finish;
>> +   return ret;
>> +  }
>> +case CPP_PLUS:
>> +  if (!c_dialect_objc () && !in_system_header_at (input_location))
>> +   warning_at (op_loc,
>> +   OPT_Wtraditional,
>> +   "traditional C rejects the unary plus operator");
>>
>> does it really make sense to warn about C issues when compiling gimple?
>>
>> +c_parser_parse_ssa_names (c_parser *parser)
>> +{
>> +  tree id = NULL_TREE;
>> +  c_expr ret;
>> +  char *var_name, *var_version, *token;
>> +  ret.original_code = ERROR_MARK;
>> +  ret.original_type = NULL;
>> +
>> +  /* ssa token string.  */
>> +  const char *ssa_token = NULL;
>> +  ssa_token = IDENTIFIER_POINTER (c_parser_peek_token (parser)->value);
>> +  token = new char [strlen (ssa_to

C PATCH to suppress a bogus "defaulting to int" warning (PR c/77323)

[Marek Polacek]

When declaring something using an unsupported type specifier, such as __int128
on 32-bit systems, or _Float128x, the error for the unsupported type is
followed by a warning about the type defaulting to int.

But for unsupported types this warning isn't useful.  The problem was that for
these unsupported types typespec_word was set to cts_none, so in
finish_declspecs we'd set default_int_p and thus warn in grokdeclarator.

How to fix this became clear when I looked at how we handle fixed-point types
and decimal floating point types -- by setting typespec_word even when we've
given an error.  The finish_declspecs hunk is needed so that we don't pass
a null type to grokdeclarator.

Tested also with
make check-c RUNTESTFLAGS='dg.exp=pr77323.c --target_board=unix\{-m32,-m64\}'

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

2016-08-24  Marek Polacek  

PR c/77323
* c-decl.c (declspecs_add_type): Set typespec_word even when __intN
or _FloatN or _FloatNx is not supported.
(finish_declspecs): Set type to integer_type_node when _FloatN or
_FloatNx is not supported.

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

diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index 0fb2d20..0c52a64 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -10190,10 +10190,13 @@ declspecs_add_type (location_t loc, struct 
c_declspecs *specs,
  ("both %<__int%d%> and % in "
   "declaration specifiers"),
  int_n_data[specs->int_n_idx].bitsize);
- else if (! int_n_enabled_p [specs->int_n_idx])
-   error_at (loc,
- "%<__int%d%> is not supported on this target",
- int_n_data[specs->int_n_idx].bitsize);
+ else if (! int_n_enabled_p[specs->int_n_idx])
+   {
+ specs->typespec_word = cts_int_n;
+ error_at (loc,
+   "%<__int%d%> is not supported on this target",
+   int_n_data[specs->int_n_idx].bitsize);
+   }
  else
{
  specs->typespec_word = cts_int_n;
@@ -10400,12 +10403,15 @@ declspecs_add_type (location_t loc, struct 
c_declspecs *specs,
   ? "x"
   : ""));
  else if (FLOATN_NX_TYPE_NODE (specs->floatn_nx_idx) == NULL_TREE)
-   error_at (loc,
- "%<_Float%d%s%> is not supported on this target",
- floatn_nx_types[specs->floatn_nx_idx].n,
- (floatn_nx_types[specs->floatn_nx_idx].extended
-  ? "x"
-  : ""));
+   {
+ specs->typespec_word = cts_floatn_nx;
+ error_at (loc,
+   "%<_Float%d%s%> is not supported on this target",
+   floatn_nx_types[specs->floatn_nx_idx].n,
+   (floatn_nx_types[specs->floatn_nx_idx].extended
+? "x"
+: ""));
+   }
  else
{
  specs->typespec_word = cts_floatn_nx;
@@ -10892,9 +10898,12 @@ finish_declspecs (struct c_declspecs *specs)
 case cts_floatn_nx:
   gcc_assert (!specs->long_p && !specs->short_p
  && !specs->signed_p && !specs->unsigned_p);
-  specs->type = (specs->complex_p
-? COMPLEX_FLOATN_NX_TYPE_NODE (specs->floatn_nx_idx)
-: FLOATN_NX_TYPE_NODE (specs->floatn_nx_idx));
+  if (FLOATN_NX_TYPE_NODE (specs->floatn_nx_idx) == NULL_TREE)
+   specs->type = integer_type_node;
+  else if (specs->complex_p)
+   specs->type = COMPLEX_FLOATN_NX_TYPE_NODE (specs->floatn_nx_idx);
+  else
+   specs->type = FLOATN_NX_TYPE_NODE (specs->floatn_nx_idx);
   break;
 case cts_dfloat32:
 case cts_dfloat64:
diff --git gcc/testsuite/gcc.dg/pr77323.c gcc/testsuite/gcc.dg/pr77323.c
index e69de29..281c334 100644
--- gcc/testsuite/gcc.dg/pr77323.c
+++ gcc/testsuite/gcc.dg/pr77323.c
@@ -0,0 +1,6 @@
+/* PR c/77323 */
+/* { dg-do compile { target ia32 } } */
+/* { dg-options "" } */
+
+__int128 a; /* { dg-error "not supported" } */
+_Float128x b; /* { dg-error "not supported" } */

Marek

Re: C PATCH to suppress a bogus "defaulting to int" warning (PR c/77323)

[Marek Polacek]

On Wed, Aug 24, 2016 at 12:18:17PM +0200, Marek Polacek wrote:
> When declaring something using an unsupported type specifier, such as __int128
> on 32-bit systems, or _Float128x, the error for the unsupported type is
> followed by a warning about the type defaulting to int.
> 
> But for unsupported types this warning isn't useful.  The problem was that for
> these unsupported types typespec_word was set to cts_none, so in
> finish_declspecs we'd set default_int_p and thus warn in grokdeclarator.
> 
> How to fix this became clear when I looked at how we handle fixed-point types
> and decimal floating point types -- by setting typespec_word even when we've
> given an error.  The finish_declspecs hunk is needed so that we don't pass
> a null type to grokdeclarator.
> 
> Tested also with
> make check-c RUNTESTFLAGS='dg.exp=pr77323.c --target_board=unix\{-m32,-m64\}'
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?

And now tested on ppc64le-redhat-linux, too.

Marek

[PATCHv2 1/7, GCC, ARM, V8M] Add support for ARMv8-M's Secure Extensions flag and intrinsics

[Andre Vieira (lists)]

On 25/07/16 14:19, Andre Vieira (lists) wrote:
> This patch adds the support of the '-mcmse' option to enable ARMv8-M's
> Security Extensions and supports the following intrinsics:
> cmse_TT
> cmse_TT_fptr
> cmse_TTT
> cmse_TTT_fptr
> cmse_TTA
> cmse_TTA_fptr
> cmse_TTAT
> cmse_TTAT_fptr
> cmse_check_address_range
> cmse_check_pointed_object
> cmse_is_nsfptr
> cmse_nsfptr_create
> 
> It also defines the mandatory cmse_address_info struct and the
> __ARM_FEATURE_CMSE macro.
> See Chapter 4, Sections 5.2, 5.3 and 5.6 of ARM®v8-M Security
> Extensions: Requirements on Development Tools
> (http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).
> 
> *** gcc/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * config.gcc (extra_headers): Added arm_cmse.h.
> * config/arm/arm-arches.def (ARM_ARCH):
> (armv8-m): Add FL2_CMSE.
> (armv8-m.main): Likewise.
> (armv8-m.main+dsp): Likewise.
> * config/arm/arm-c.c
> (arm_cpu_builtins): Added __ARM_FEATURE_CMSE macro.
> * config/arm/arm-protos.h
> (arm_is_constant_pool_ref): Define FL2_CMSE.
> * config/arm.c (arm_arch_cmse): New.
> (arm_option_override): New error for unsupported cmse target.
> * config/arm/arm.h (arm_arch_cmse): New.
> * config/arm/arm.opt (mcmse): New.
> * doc/invoke.texi (ARM Options): Add -mcmse.
> * config/arm/arm_cmse.h: New file.
> 
> *** libgcc/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * config/arm/cmse.c: Likewise.
> * config/arm/t-arm (HAVE_CMSE): New.
> 
> *** gcc/testsuite/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * gcc.target/arm/cmse/cmse.exp: New.
> * gcc.target/arm/cmse/cmse-1.c: New.
> * gcc.target/arm/cmse/cmse-12.c: New.
> * lib/target-supports.exp
> (check_effective_target_arm_cmse_ok): New.
> 

Added more documentation as requested.

This patch adds the support of the '-mcmse' option to enable ARMv8-M's
Security Extensions and supports the following intrinsics:
cmse_TT
cmse_TT_fptr
cmse_TTT
cmse_TTT_fptr
cmse_TTA
cmse_TTA_fptr
cmse_TTAT
cmse_TTAT_fptr
cmse_check_address_range
cmse_check_pointed_object
cmse_is_nsfptr
cmse_nsfptr_create

It also defines the mandatory cmse_address_info struct and the
__ARM_FEATURE_CMSE macro.
See Chapter 4, Sections 5.2, 5.3 and 5.6 of ARM®v8-M Security
Extensions: Requirements on Development Tools
(http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).

*** gcc/ChangeLog ***
2016-07-xx  Andre Vieira
Thomas Preud'homme  

* config.gcc (extra_headers): Added arm_cmse.h.
* config/arm/arm-arches.def (ARM_ARCH):
(armv8-m): Add FL2_CMSE.
(armv8-m.main): Likewise.
(armv8-m.main+dsp): Likewise.
* config/arm/arm-c.c
(arm_cpu_builtins): Added __ARM_FEATURE_CMSE macro.
* config/arm/arm-protos.h
(arm_is_constant_pool_ref): Define FL2_CMSE.
* config/arm.c (arm_arch_cmse): New.
(arm_option_override): New error for unsupported cmse target.
* config/arm/arm.h (arm_arch_cmse): New.
* config/arm/arm.opt (mcmse): New.
* doc/invoke.texi (ARM Options): Add -mcmse.
* doc/extend.texi (ARM ARMv8-M Security Extensions): Add section.
* config/arm/arm_cmse.h: New file.

*** libgcc/ChangeLog ***
2016-07-xx  Andre Vieira
Thomas Preud'homme  
* config/arm/cmse.c: Likewise.
* config/arm/t-arm (HAVE_CMSE): New.


*** gcc/testsuite/ChangeLog ***
2016-07-xx  Andre Vieira
Thomas Preud'homme  

* gcc.target/arm/cmse/cmse.exp: New.
* gcc.target/arm/cmse/cmse-1.c: New.
* gcc.target/arm/cmse/cmse-12.c: New.
* lib/target-supports.exp
(check_effective_target_arm_cmse_ok): New.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 
1f75f17877334c2bb61cd16b69539ec7514db8ae..8555bbf19d81b517493c86b38aff31a633ac50eb
 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -320,7 +320,7 @@ arc*-*-*)
 arm*-*-*)
cpu_type=arm
extra_objs="arm-builtins.o aarch-common.o"
-   extra_headers="mmintrin.h arm_neon.h arm_acle.h"
+   extra_headers="mmintrin.h arm_neon.h arm_acle.h arm_cmse.h"
target_type_format_char='%'
c_target_objs="arm-c.o"
cxx_target_objs="arm-c.o"
diff --git a/gcc/config/arm/arm-arches.def b/gcc/config/arm/arm-arches.def
index 
be46521c9eaea54f9ad78a92874567589289dbdf..0e523959551cc3b1da31411ccdd1105b830db845
 100644
--- a/gcc/config/arm/arm-arches.def
+++ b/gcc/config/arm/arm-arches.def
@@ -63,11 +63,11 @@ ARM_ARCH("armv8.1-a+crc",cortexa53, 8A,
  ARM_FSET_MAKE (FL_CO_PROC | FL_CRC32 | FL_FOR_ARCH8A,
 FL2_FOR_ARCH8_1A))
 ARM_ARCH("armv8-m.base", cortexm0, 8M_BASE,
-ARM_FSET_MAKE_CPU1

[PATCHv2 2/7, GCC, ARM, V8M] Handling ARMv8-M Security Extension's cmse_nonsecure_entry attribute

[Andre Vieira (lists)]

On 25/07/16 14:21, Andre Vieira (lists) wrote:
> This patch adds support for the ARMv8-M Security Extensions
> 'cmse_nonsecure_entry' attribute. In this patch we implement the
> attribute handling and diagnosis around the attribute. See Section 5.4
> of ARM®v8-M Security Extensions
> (http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).
> 
> *** gcc/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * config/arm/arm.c (arm_handle_cmse_nonsecure_entry): New.
> (arm_attribute_table): Added cmse_nonsecure_entry
> (arm_compute_func_type): Handle cmse_nonsecure_entry.
> (cmse_func_args_or_return_in_stack): New.
> (arm_handle_cmse_nonsecure_entry): New.
> * config/arm/arm.h (ARM_FT_CMSE_ENTRY): New macro define.
> (IS_CMSE_ENTRY): Likewise.
> 
> *** gcc/testsuite/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * gcc.target/arm/cmse/cmse-3.c: New.
>

Added more documentation as requested.



This patch adds support for the ARMv8-M Security Extensions
'cmse_nonsecure_entry' attribute. In this patch we implement the
attribute handling and diagnosis around the attribute. See Section 5.4
of ARM®v8-M Security Extensions
(http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).

*** gcc/ChangeLog ***
2016-07-xx  Andre Vieira
Thomas Preud'homme  

* config/arm/arm.c (arm_handle_cmse_nonsecure_entry): New.
(arm_attribute_table): Added cmse_nonsecure_entry
(arm_compute_func_type): Handle cmse_nonsecure_entry.
(cmse_func_args_or_return_in_stack): New.
(arm_handle_cmse_nonsecure_entry): New.
* config/arm/arm.h (ARM_FT_CMSE_ENTRY): New macro define.
(IS_CMSE_ENTRY): Likewise.
* doc/extend.texi (ARM ARMv8-M Security Extensions): New attribute.

*** gcc/testsuite/ChangeLog ***
2016-07-xx  Andre Vieira
Thomas Preud'homme  

* gcc.target/arm/cmse/cmse-3.c: New.
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 
e3697bbcb425999db31ac2b4f47e14bb3f2ffa89..5307ec8f904230db5ea44150ef471d928926ab6d
 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -1373,6 +1373,7 @@ enum reg_class
 #define ARM_FT_VOLATILE(1 << 4) /* Does not return.  */
 #define ARM_FT_NESTED  (1 << 5) /* Embedded inside another func.  */
 #define ARM_FT_STACKALIGN  (1 << 6) /* Called with misaligned stack.  */
+#define ARM_FT_CMSE_ENTRY  (1 << 7) /* ARMv8-M non-secure entry function.  
*/
 
 /* Some macros to test these flags.  */
 #define ARM_FUNC_TYPE(t)   (t & ARM_FT_TYPE_MASK)
@@ -1381,6 +1382,7 @@ enum reg_class
 #define IS_NAKED(t)(t & ARM_FT_NAKED)
 #define IS_NESTED(t)   (t & ARM_FT_NESTED)
 #define IS_STACKALIGN(t)   (t & ARM_FT_STACKALIGN)
+#define IS_CMSE_ENTRY(t)   (t & ARM_FT_CMSE_ENTRY)
 
 
 /* Structure used to hold the function stack frame layout.  Offsets are
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
9903d9cd8c5ff68a2318a643bdf31cf48016eba4..11417ab3c2f7101866ee5d6b100913480e5c336e
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -134,6 +134,7 @@ static tree arm_handle_isr_attribute (tree *, tree, tree, 
int, bool *);
 #if TARGET_DLLIMPORT_DECL_ATTRIBUTES
 static tree arm_handle_notshared_attribute (tree *, tree, tree, int, bool *);
 #endif
+static tree arm_handle_cmse_nonsecure_entry (tree *, tree, tree, int, bool *);
 static void arm_output_function_epilogue (FILE *, HOST_WIDE_INT);
 static void arm_output_function_prologue (FILE *, HOST_WIDE_INT);
 static int arm_comp_type_attributes (const_tree, const_tree);
@@ -343,6 +344,9 @@ static const struct attribute_spec arm_attribute_table[] =
   { "notshared",0, 0, false, true, false, arm_handle_notshared_attribute,
 false },
 #endif
+  /* ARMv8-M Security Extensions support.  */
+  { "cmse_nonsecure_entry", 0, 0, true, false, false,
+arm_handle_cmse_nonsecure_entry, false },
   { NULL,   0, 0, false, false, false, NULL, false }
 };
 
@@ -3633,6 +3637,9 @@ arm_compute_func_type (void)
   else
 type |= arm_isr_value (TREE_VALUE (a));
 
+  if (lookup_attribute ("cmse_nonsecure_entry", attr))
+type |= ARM_FT_CMSE_ENTRY;
+
   return type;
 }
 
@@ -6634,6 +6641,110 @@ arm_handle_notshared_attribute (tree *node,
 }
 #endif
 
+/* This function returns true if a function with declaration FNDECL, name
+   NAME and type FNTYPE uses the stack to pass arguments or return variables
+   and false otherwise.  This is used for functions with the attributes
+   'cmse_nonsecure_call' or 'cmse_nonsecure_entry' and this function will issue
+   diagnostic messages if the stack is used.  */
+
+static bool
+cmse_func_args_or_return_in_stack (tree fndecl, tree name, tree fntype)
+{
+  function_args_iterator args_iter;
+  CUMULATIVE_ARGS args_so_far_v;
+  cumulative_args_t a

[PATCHv2 4/7, GCC, ARM, V8M] ARMv8-M Security Extension's cmse_nonsecure_entry: clear registers

[Andre Vieira (lists)]

On 25/07/16 14:23, Andre Vieira (lists) wrote:
> This patch extends support for the ARMv8-M Security Extensions
> 'cmse_nonsecure_entry' attribute to safeguard against leak of
> information through unbanked registers.
> 
> When returning from a nonsecure entry function we clear all caller-saved
> registers that are not used to pass return values, by writing either the
> LR, in case of general purpose registers, or the value 0, in case of FP
> registers. We use the LR to write to APSR and FPSCR too. We currently do
> not support entry functions that pass arguments or return variables on
> the stack and we diagnose this. This patch relies on the existing code
> to make sure callee-saved registers used in cmse_nonsecure_entry
> functions are saved and restored thus retaining their nonsecure mode
> value, this should be happening already as it is required by AAPCS.
> 
> This patch also clears padding bits for cmse_nonsecure_entry functions
> with struct and union return types. For unions a bit is only considered
> a padding bit if it is an unused bit in every field of that union. The
> function that calculates these is used in a later patch to do the same
> for arguments of cmse_nonsecure_call's.
> 
> *** gcc/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * config/arm/arm.c (output_return_instruction): Clear
> registers.
> (thumb2_expand_return): Likewise.
> (thumb1_expand_epilogue): Likewise.
> (thumb_exit): Likewise.
> (arm_expand_epilogue): Likewise.
> (cmse_nonsecure_entry_clear_before_return): New.
> (comp_not_to_clear_mask_str_un): New.
> (compute_not_to_clear_mask): New.
> * config/arm/thumb1.md (*epilogue_insns): Change length attribute.
> * config/arm/thumb2.md (*thumb2_return): Likewise.
> 
> *** gcc/testsuite/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * gcc.target/arm/cmse/cmse.exp: Test different multilibs separate.
> * gcc.target/arm/cmse/struct-1.c: New.
> * gcc.target/arm/cmse/bitfield-1.c: New.
> * gcc.target/arm/cmse/bitfield-2.c: New.
> * gcc.target/arm/cmse/bitfield-3.c: New.
> * gcc.target/arm/cmse/baseline/cmse-2.c: Test that registers are
> cleared.
> * gcc.target/arm/cmse/mainline/soft/cmse-5.c: New.
> * gcc.target/arm/cmse/mainline/hard/cmse-5.c: New.
> * gcc.target/arm/cmse/mainline/hard-sp/cmse-5.c: New.
> * gcc.target/arm/cmse/mainline/softfp/cmse-5.c: New.
> * gcc.target/arm/cmse/mainline/softfp-sp/cmse-5.c: New.
> 

Updated this patch to correctly clear only the cumulative
exception-status (0-4,7) and the condition code bits (28-31) of the
FPSCR. I also adapted the code to be handle the bigger floating point
register files.



This patch extends support for the ARMv8-M Security Extensions
'cmse_nonsecure_entry' attribute to safeguard against leak of
information through unbanked registers.

When returning from a nonsecure entry function we clear all caller-saved
registers that are not used to pass return values, by writing either the
LR, in case of general purpose registers, or the value 0, in case of FP
registers. We use the LR to write to APSR. For FPSCR we clear only the
cumulative exception-status (0-4, 7) and the condition code bits
(28-31). We currently do not support entry functions that pass arguments
or return variables on the stack and we diagnose this. This patch relies
on the existing code to make sure callee-saved registers used in
cmse_nonsecure_entry functions are saved and restored thus retaining
their nonsecure mode value, this should be happening already as it is
required by AAPCS.

This patch also clears padding bits for cmse_nonsecure_entry functions
with struct and union return types. For unions a bit is only considered
a padding bit if it is an unused bit in every field of that union. The
function that calculates these is used in a later patch to do the same
for arguments of cmse_nonsecure_call's.

*** gcc/ChangeLog ***
2016-07-xx  Andre Vieira
Thomas Preud'homme  

* config/arm/arm.c (output_return_instruction): Clear
registers.
(thumb2_expand_return): Likewise.
(thumb1_expand_epilogue): Likewise.
(thumb_exit): Likewise.
(arm_expand_epilogue): Likewise.
(cmse_nonsecure_entry_clear_before_return): New.
(comp_not_to_clear_mask_str_un): New.
(compute_not_to_clear_mask): New.
* config/arm/thumb1.md (*epilogue_insns): Change length attribute.
* config/arm/thumb2.md (*thumb2_return): Duplicate pattern for
cmse_nonsecure_entry functions.

*** gcc/testsuite/ChangeLog ***
2016-07-xx  Andre Vieira
Thomas Preud'homme  

* gcc.target/arm/cmse/cmse.exp: Test different multilibs separate.
* gcc.target/arm/cmse/struct-1.c: New.
* gcc.target/arm/cmse/bitfi

Re: [PATCH 7/7, GCC, ARM, V8M] Added support for ARMV8-M Security Extension cmse_nonsecure_caller intrinsic

[Andre Vieira (lists)]

On 25/07/16 14:28, Andre Vieira (lists) wrote:
> This patch adds support ARMv8-M's Security Extension's
> cmse_nonsecure_caller intrinsic. This intrinsic is used to check whether
> an entry function was called from a non-secure state.
> See Section 5.4.3 of ARM®v8-M Security Extensions: Requirements on
> Development Tools
> (http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html)
> for further details.
> 
> The FIXME in config/arm/arm_cmse.h is for a diagnostic message that is
> suggested in the ARMv8-M Security Extensions document mentioned above,
> to diagnose the use of the cmse_nonsecure_caller intrinsic outside of
> functions with the 'cmse_nonsecure_entry' attribute.  Checking whether
> the intrinsic is called from within such functions can easily be done
> inside 'arm_expand_builtin'. However, making the warning point to the
> right location is more complicated.  The ARMv8-M Security Extensions
> specification does mention that such a diagnostic might become
> mandatory, so I might have to pick this up later, otherwise it is left
> as a potential extra feature.
> 
> 
> *** gcc/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * config/arm/arm-builtins.c (arm_builtins): Define
> ARM_BUILTIN_CMSE_NONSECURE_CALLER.
> (bdesc_2arg): Add line for cmse_nonsecure_caller.
> (arm_expand_builtin): Handle cmse_nonsecure_caller.
> * config/arm/arm_cmse.h (cmse_nonsecure_caller): New.
> 
> *** gcc/testsuite/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * gcc.target/arm/cmse/cmse-1.c: Add test for
> cmse_nonsecure_caller.
> 
Added more documentation as requested.

---

This patch adds support ARMv8-M's Security Extension's
cmse_nonsecure_caller intrinsic. This intrinsic is used to check whether
an entry function was called from a non-secure state.
See Section 5.4.3 of ARM®v8-M Security Extensions: Requirements on
Development Tools
(http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html)
for further details.

The FIXME in config/arm/arm_cmse.h is for a diagnostic message that is
suggested in the ARMv8-M Security Extensions document mentioned above,
to diagnose the use of the cmse_nonsecure_caller intrinsic outside of
functions with the 'cmse_nonsecure_entry' attribute.  Checking whether
the intrinsic is called from within such functions can easily be done
inside 'arm_expand_builtin'. However, making the warning point to the
right location is more complicated.  The ARMv8-M Security Extensions
specification does mention that such a diagnostic might become
mandatory, so I might have to pick this up later, otherwise it is left
as a potential extra feature.


*** gcc/ChangeLog ***
2016-07-xx  Andre Vieira
Thomas Preud'homme  

* config/arm/arm-builtins.c (arm_builtins): Define
ARM_BUILTIN_CMSE_NONSECURE_CALLER.
(bdesc_2arg): Add line for cmse_nonsecure_caller.
(arm_expand_builtin): Handle cmse_nonsecure_caller.
* config/arm/arm_cmse.h (cmse_nonsecure_caller): New.
* doc/extend.texi (ARM ARMv8-M Security Extensions): New intrinsic.

*** gcc/testsuite/ChangeLog ***
2016-07-xx  Andre Vieira
Thomas Preud'homme  

* gcc.target/arm/cmse/cmse-1.c: Add test for
cmse_nonsecure_caller.
diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index 
68b2839879f78e8d819444fbc11d2a91f8d6279a..2589ec2d1233f3daff94a1d35ebf63c8a9b93ecf
 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -515,6 +515,8 @@ enum arm_builtins
   ARM_BUILTIN_GET_FPSCR,
   ARM_BUILTIN_SET_FPSCR,
 
+  ARM_BUILTIN_CMSE_NONSECURE_CALLER,
+
 #undef CRYPTO1
 #undef CRYPTO2
 #undef CRYPTO3
@@ -1789,6 +1791,17 @@ arm_init_builtins (void)
= add_builtin_function ("__builtin_arm_stfscr", ftype_set_fpscr,
ARM_BUILTIN_SET_FPSCR, BUILT_IN_MD, NULL, 
NULL_TREE);
 }
+
+  if (arm_arch_cmse)
+{
+  tree ftype_cmse_nonsecure_caller
+   = build_function_type_list (unsigned_type_node, NULL);
+  arm_builtin_decls[ARM_BUILTIN_CMSE_NONSECURE_CALLER]
+   = add_builtin_function ("__builtin_arm_cmse_nonsecure_caller",
+   ftype_cmse_nonsecure_caller,
+   ARM_BUILTIN_CMSE_NONSECURE_CALLER, BUILT_IN_MD,
+   NULL, NULL_TREE);
+}
 }
 
 /* Return the ARM builtin for CODE.  */
@@ -2368,6 +2381,12 @@ arm_expand_builtin (tree exp,
   emit_insn (pat);
   return target;
 
+case ARM_BUILTIN_CMSE_NONSECURE_CALLER:
+  target = gen_reg_rtx (SImode);
+  op0 = arm_return_addr (0, NULL_RTX);
+  emit_insn (gen_addsi3 (target, op0, const1_rtx));
+  return target;
+
 case ARM_BUILTIN_TEXTRMSB:
 case ARM_BUILTIN_TEXTRMUB:
 case ARM_BUILTIN_TEXTRMSH:
diff --git a/gcc/config/arm/arm_cmse.h b/gcc/config/

[PATCHv2 5/7, GCC, ARM, V8M] Handling ARMv8-M Security Extension's cmse_nonsecure_call attribute

[Andre Vieira (lists)]

On 25/07/16 14:25, Andre Vieira (lists) wrote:
> This patch adds support for the ARMv8-M Security Extensions
> 'cmse_nonsecure_call' attribute. This attribute may only be used for
> function types and when used in combination with the '-mcmse'
> compilation flag. See Section 5.5 of ARM®v8-M Security Extensions
> (http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).
> 
> We currently do not support cmse_nonsecure_call functions that pass
> arguments or return variables on the stack and we diagnose this.
> 
> *** gcc/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * config/arm/arm.c (gimplify.h): New include.
> (arm_handle_cmse_nonsecure_call): New.
> (arm_attribute_table): Added cmse_nonsecure_call.
> 
> *** gcc/testsuite/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * gcc.target/arm/cmse/cmse-3.c: Add tests.
> * gcc.target/arm/cmse/cmse-4.c: Add tests.
> 

Added more documentation as requested.

---

This patch adds support for the ARMv8-M Security Extensions
'cmse_nonsecure_call' attribute. This attribute may only be used for
function types and when used in combination with the '-mcmse'
compilation flag. See Section 5.5 of ARM®v8-M Security Extensions
(http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).

We currently do not support cmse_nonsecure_call functions that pass
arguments or return variables on the stack and we diagnose this.

*** gcc/ChangeLog ***
2016-07-xx  Andre Vieira
Thomas Preud'homme  

* config/arm/arm.c (gimplify.h): New include.
(arm_handle_cmse_nonsecure_call): New.
(arm_attribute_table): Added cmse_nonsecure_call.
* doc/extend.texi (ARM ARMv8-M Security Extensions): New attribute.

*** gcc/testsuite/ChangeLog ***
2016-07-xx  Andre Vieira
Thomas Preud'homme  

* gcc.target/arm/cmse/cmse-3.c: Add tests.
* gcc.target/arm/cmse/cmse-4.c: Add tests.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
680b648a218d166d49e89be78ee30397dac7e87f..647e41677834573db1b921d3e8445145767779c4
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -61,6 +61,7 @@
 #include "builtins.h"
 #include "tm-constrs.h"
 #include "rtl-iter.h"
+#include "gimplify.h"
 
 /* This file should be included last.  */
 #include "target-def.h"
@@ -135,6 +136,7 @@ static tree arm_handle_isr_attribute (tree *, tree, tree, 
int, bool *);
 static tree arm_handle_notshared_attribute (tree *, tree, tree, int, bool *);
 #endif
 static tree arm_handle_cmse_nonsecure_entry (tree *, tree, tree, int, bool *);
+static tree arm_handle_cmse_nonsecure_call (tree *, tree, tree, int, bool *);
 static void arm_output_function_epilogue (FILE *, HOST_WIDE_INT);
 static void arm_output_function_prologue (FILE *, HOST_WIDE_INT);
 static int arm_comp_type_attributes (const_tree, const_tree);
@@ -347,6 +349,8 @@ static const struct attribute_spec arm_attribute_table[] =
   /* ARMv8-M Security Extensions support.  */
   { "cmse_nonsecure_entry", 0, 0, true, false, false,
 arm_handle_cmse_nonsecure_entry, false },
+  { "cmse_nonsecure_call", 0, 0, true, false, false,
+arm_handle_cmse_nonsecure_call, false },
   { NULL,   0, 0, false, false, false, NULL, false }
 };
 
@@ -6750,6 +6754,78 @@ arm_handle_cmse_nonsecure_entry (tree *node, tree name,
   return NULL_TREE;
 }
 
+
+/* Called upon detection of the use of the cmse_nonsecure_call attribute, this
+   function will check whether the attribute is allowed here and will add the
+   attribute to the function type tree or otherwise issue a diagnostic.  The
+   reason we check this at declaration time is to only allow the use of the
+   attribute with declarations of function pointers and not function
+   declarations.  This function checks NODE is of the expected type and issues
+   diagnostics otherwise using NAME.  If it is not of the expected type
+   *NO_ADD_ATTRS will be set to true.  */
+
+static tree
+arm_handle_cmse_nonsecure_call (tree *node, tree name,
+tree /* args */,
+int /* flags */,
+bool *no_add_attrs)
+{
+  tree decl = NULL_TREE;
+  tree type, fntype, main_variant;
+
+  if (!use_cmse)
+{
+  *no_add_attrs = true;
+  return NULL_TREE;
+}
+
+  if (TREE_CODE (*node) == VAR_DECL || TREE_CODE (*node) == TYPE_DECL)
+{
+  decl = *node;
+  type = TREE_TYPE (decl);
+}
+
+  if (!decl
+  || (!(TREE_CODE (type) == POINTER_TYPE
+   && TREE_CODE (TREE_TYPE (type)) == FUNCTION_TYPE)
+ && TREE_CODE (type) != FUNCTION_TYPE))
+{
+   warning (OPT_Wattributes, "%qE attribute only applies to base type of a 
"
+"function pointer", name);
+   *no_add_attrs = true;
+   return NULL_TREE;
+}
+
+  /* type is either a function pointer, when the

[PATCHv2 6/7, GCC, ARM, V8M] ARMv8-M Security Extension's cmse_nonsecure_call: use __gnu_cmse_nonsecure_call

[Andre Vieira (lists)]

On 25/07/16 14:26, Andre Vieira (lists) wrote:
> This patch extends support for the ARMv8-M Security Extensions
> 'cmse_nonsecure_call' to use a new library function
> '__gnu_cmse_nonsecure_call'. This library function is responsible for
> (without using r0-r3 or d0-d7):
> 1) saving and clearing all callee-saved registers using the secure stack
> 2) clearing the LSB of the address passed in r4 and using blxns to
> 'jump' to it
> 3) clearing ASPR, including the 'ge bits' if DSP is enabled
> 4) clearing FPSCR if using non-soft float-abi
> 5) restoring callee-saved registers.
> 
> The decisions whether to include DSP 'ge bits' clearing and floating
> point registers (single/double precision) all depends on the multilib used.
> 
> See Section 5.5 of ARM®v8-M Security Extensions
> (http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).
> 
> *** gcc/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * config/arm/arm.c (detect_cmse_nonsecure_call): New.
> (cmse_nonsecure_call_clear_caller_saved): New.
> (arm_reorg): Use cmse_nonsecure_call_clear_caller_saved.
> * config/arm/arm-protos.h (detect_cmse_nonsecure_call): New.
> * config/arm/arm.md (call): Handle cmse_nonsecure_entry.
> (call_value): Likewise.
> (nonsecure_call_internal): New.
> (nonsecure_call_value_internal): New.
> * config/arm/thumb1.md (*nonsecure_call_reg_thumb1_v5): New.
> (*nonsecure_call_value_reg_thumb1_v5): New.
> * config/arm/thumb2.md (*nonsecure_call_reg_thumb2): New.
> (*nonsecure_call_value_reg_thumb2): New.
> * config/arm/unspecs.md (UNSPEC_NONSECURE_MEM): New.
> 
> *** libgcc/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * config/arm/cmse_nonsecure_call.S: New.
>   * config/arm/t-arm: Compile cmse_nonsecure_call.S
> 
> 
> *** gcc/testsuite/ChangeLog ***
> 2016-07-25  Andre Vieira
> Thomas Preud'homme  
> 
> * gcc.target/arm/cmse/cmse.exp: Run tests in mainline dir.
> * gcc.target/arm/cmse/cmse-9.c: Added some extra tests.
> * gcc.target/arm/cmse/baseline/bitfield-4.c: New.
> * gcc.target/arm/cmse/baseline/bitfield-5.c: New.
> * gcc.target/arm/cmse/baseline/bitfield-6.c: New.
> * gcc.target/arm/cmse/baseline/bitfield-7.c: New.
> * gcc.target/arm/cmse/baseline/bitfield-8.c: New.
> * gcc.target/arm/cmse/baseline/bitfield-9.c: New.
> * gcc.target/arm/cmse/baseline/bitfield-and-union-1.c: New.
> * gcc.target/arm/cmse/baseline/cmse-11.c: New.
>   * gcc.target/arm/cmse/baseline/cmse-13.c: New.
>   * gcc.target/arm/cmse/baseline/cmse-6.c: New.
> * gcc/testsuite/gcc.target/arm/cmse/baseline/union-1.c: New.
> * gcc/testsuite/gcc.target/arm/cmse/baseline/union-2.c: New.
>   * gcc.target/arm/cmse/mainline/hard-sp/cmse-13.c: New.
>   * gcc.target/arm/cmse/mainline/hard-sp/cmse-7.c: New.
>   * gcc.target/arm/cmse/mainline/hard-sp/cmse-8.c: New.
>   * gcc.target/arm/cmse/mainline/hard/cmse-13.c: New.
>   * gcc.target/arm/cmse/mainline/hard/cmse-7.c: New.
>   * gcc.target/arm/cmse/mainline/hard/cmse-8.c: New.
>   * gcc.target/arm/cmse/mainline/soft/cmse-13.c: New.
>   * gcc.target/arm/cmse/mainline/soft/cmse-7.c: New.
>   * gcc.target/arm/cmse/mainline/soft/cmse-8.c: New.
>   * gcc.target/arm/cmse/mainline/softfp-sp/cmse-7.c: New.
>   * gcc.target/arm/cmse/mainline/softfp-sp/cmse-8.c: New.
>   * gcc.target/arm/cmse/mainline/softfp/cmse-13.c: New.
>   * gcc.target/arm/cmse/mainline/softfp/cmse-7.c: New.
>   * gcc.target/arm/cmse/mainline/softfp/cmse-8.c: New.
> 

Updated this patch to correctly clear only the cumulative
exception-status (0-4,7) and the condition code bits (28-31) of the FPSCR.



This patch extends support for the ARMv8-M Security Extensions
'cmse_nonsecure_call' to use a new library function
'__gnu_cmse_nonsecure_call'. This library function is responsible for
(without using r0-r3 or d0-d7):
1) saving and clearing all callee-saved registers using the secure stack
2) clearing the LSB of the address passed in r4 and using blxns to
'jump' to it
3) clearing ASPR, including the 'ge bits' if DSP is enabled
4) clearing the cumulative exception-status (0-4, 7) and the condition
bits (28-31) of the FPSCR if using non-soft float-abi
5) restoring callee-saved registers.

The decisions whether to include DSP 'ge bits' clearing and floating
point registers (single/double precision) all depends on the multilib used.

See Section 5.5 of ARM®v8-M Security Extensions
(http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).

*** gcc/ChangeLog ***
2016-07-xx  Andre Vieira
Thomas Preud'homme  

* config/arm/arm.c (detect_cmse_nonsecure_call): New.
(cmse_nonsecure_call_clear_caller_saved): New.
(arm_reo

Re: [PATCH 0/7, GCC, V8M] ARMv8-M Security Extensions

[Andre Vieira (lists)]

On 10/08/16 09:08, Andre Vieira (lists) wrote:
> On 09/08/16 17:47, Sandra Loosemore wrote:
>> On 08/09/2016 06:01 AM, Andre Vieira (lists) wrote:
>>> [snip]
>>>
>>> The documentation is in the ARMV8-M Security Extensions in: ARM®v8-M
>>> Security Extensions: Requirements on Development Tools document I linked
>>> in the email above and subsequent emails
>>> (http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/index.html).
>>>
>>> Also per patch I refer to the relevant sections. So for instance in
>>> PATCH 3/7 refers to Section 5.4, which describes Entry functions and
>>> mentions the cmse_nonsecure_entry attribute. Whereas PATCH 7/7 refers to
>>> Section 5.4.3 of the same document which describes the
>>> cmse_nonsecure_caller intrinsic which that patch implements.
>>>
>>> Is there a specific intrinsic/attribute you are missing?
>>
>> You need to at least add entries to the relevant sections in extend.texi
>> for the new target-specific intrinsic and attributes.  The documentation
>> there doesn't need to be terribly detailed (one sentence and a link to
>> the external document is probably all you need), but it's important that
>> these things be listed in GCC's supported extensions so that users know
>> they can use them and so that people who see them in code written by
>> other people can find out what they mean.
>>
>> -Sandra
>>
> 
> 
> I see, I did add a new entry to extend.texi for ARMv8-M Security
> Extensions. I will also mention all intrinsics and attributes there.
> 
> Thank you.
> 
> Andre
> 

I updated the patch series with more documentation in extend.texi and I
also fixed an issue with the clearing of FPSCR.

Cheers,
Andre

Re: Weird behaviour with --target_board="unix{var1,var2}"

[Jonathan Wakely]

On 23/08/16 12:05 +0100, Pedro Alves wrote:

On 08/23/2016 10:54 AM, Jonathan Wakely wrote:


That's being set by prettyprinters.exp and xmethods.exp (so it's GDB's
fault! ;-)


:-)


This seems to work. I'll do some more testing and commit later today.


LGTM.

Though IME, save/restoring globals in a constant source of trouble,
for occasionally someone adds an early return that inadvertently
skips the restore.  Of course in gdb every test must be written
using custom .exp code, so we're more prone to being bitten.  Still...

The way we solve that on gdb systematically is with convenience
wrappers that handle the save/restore.  E.g. see:

$ grep "proc with_" *
gdb.exp:proc with_test_prefix { prefix body } {
gdb.exp:proc with_gdb_prompt { prompt body } {
gdb.exp:proc with_target_charset { target_charset body } {
gdb.exp:proc with_spawn_id { spawn_id body } {
gdb.exp:proc with_timeout_factor { factor body } {

In this particular case, I'd add a wrapper method to
libstdc++-v3/testsuite/lib/gdb-test.exp, such as:

# Like dg-runtest but keep the .exe around.  dg-test has an option for
# this but there is no way to pass it through dg-runtest.

proc gdb-dg-runtest {args} {
 global dg-interpreter-batch-mode
 set saved-dg-interpreter-batch-mode ${dg-interpreter-batch-mode}
 set dg-interpreter-batch-mode 1

 eval dg-runtest $args

 set dg-interpreter-batch-mode ${saved-dg-interpreter-batch-mode}
}

And then use gdb-dg-runtest instead of dg-runtest in
prettyprinters.exp and xmethods.exp.


That works nicely.


(Maybe put even move more of the duplicate code around the
current dg-runtest calls to the wrapper, and then give the
wrapper named arguments.)


That didn't seem to make things simpler.

This is what I plan to commit.


commit a487dae3a870d0c238bef06937d63d0136a13465
Author: Jonathan Wakely 
Date:   Tue Aug 23 09:09:18 2016 +0100

Restore dg-interpreter-batch-mode for libstdc++ tests

2016-08-24  Jonathan Wakely  
	Pedro Alves  

	* testsuite/lib/gdb-test.exp (gdb-dg-runtest): Define wrapper to save
	and restore dg-interpreter-batch-mode.
	* testsuite/libstdc++-prettyprinters/prettyprinters.exp: Use
	gdb-dg-runtest instead of dg-runtest.
	* testsuite/libstdc++-xmethods/xmethods.exp: Likewise.

diff --git a/libstdc++-v3/testsuite/lib/gdb-test.exp b/libstdc++-v3/testsuite/lib/gdb-test.exp
index 5570009..a029883 100644
--- a/libstdc++-v3/testsuite/lib/gdb-test.exp
+++ b/libstdc++-v3/testsuite/lib/gdb-test.exp
@@ -277,3 +277,15 @@ proc gdb_version_check_xmethods {} {
 	  "python import gdb.xmethod; print(gdb.xmethod.XMethod)" \
 	  ""]
 }
+
+# Like dg-runtest but keep the .exe around.  dg-test has an option for
+# this but there is no way to pass it through dg-runtest.
+proc gdb-dg-runtest {args} {
+  global dg-interpreter-batch-mode
+  set saved-dg-interpreter-batch-mode ${dg-interpreter-batch-mode}
+  set dg-interpreter-batch-mode 1
+
+  eval dg-runtest $args
+
+  set dg-interpreter-batch-mode ${saved-dg-interpreter-batch-mode}
+}
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp b/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
index 0c62b5e..cc003cd 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
@@ -41,14 +41,9 @@ if {! [gdb_version_check]} {
 return
 }
 
-# This can be used to keep the .exe around.  dg-test has an option for
-# this but there is no way to pass it through dg-runtest.
-global dg-interpreter-batch-mode
-set dg-interpreter-batch-mode 1
-
 global DEFAULT_CXXFLAGS
 global PCH_CXXFLAGS
-dg-runtest [lsort [glob $srcdir/$subdir/*.cc]] \
+gdb-dg-runtest [lsort [glob $srcdir/$subdir/*.cc]] \
   "" "$DEFAULT_CXXFLAGS $PCH_CXXFLAGS"
 
 if [info exists guality_gdb_name] {
diff --git a/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp b/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp
index ee9b31a..e580d73 100644
--- a/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp
+++ b/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp
@@ -42,14 +42,9 @@ if {! [gdb_version_check_xmethods]} {
 return
 }
 
-# This can be used to keep the .exe around.  dg-test has an option for
-# this but there is no way to pass it through dg-runtest.
-global dg-interpreter-batch-mode
-set dg-interpreter-batch-mode 1
-
 global DEFAULT_CXXFLAGS
 global PCH_CXXFLAGS
-dg-runtest [lsort [glob $srcdir/$subdir/*.cc]] \
+gdb-dg-runtest [lsort [glob $srcdir/$subdir/*.cc]] \
   "" "$DEFAULT_CXXFLAGS $PCH_CXXFLAGS"
 
 if [info exists guality_gdb_name] {

Re: [PR49366] emit loc exprs for C++ non-virtual pmf template value parms

[Richard Biener]

On Sat, Jul 23, 2016 at 4:30 PM, Alexandre Oliva  wrote:
> We used to emit, in debug information, the values bound to pointer to
> member function template parameters only when they were NULL or
> virtual member functions, because those can be represented with
> DW_AT_const_value.
>
> In order to represent the symbolic pointer to member function
> constants for non-virtual member functions, we'd need to be able to
> emit relocations for part of DW_AT_const_value, which we don't.  The
> more viable alternative is to use DW_AT_location to represent such
> values, as slated for inclusion in DWARFv5, according to
> http://www.dwarfstd.org/ShowIssue.php?issue=130412.1>.
>
> With this patch, when we can't emit a DW_AT_const_value, we emit each
> "member" of the pointer to member function "record" as a
> DW_OP_stack_value DW_OP_piece, as long as the referenced member
> function is output in the same translation unit, otherwise we'd get
> relocations to external symbols, something to avoid in debug sections.
>
> Regstrapped on x86_64-linux-gnu and i686-pc-linux-gnu, and manually
> cross-tested with both endiannesses (just to be sure ;-) with a
> mips64-elf target.  Ok to install?
>
> for  gcc/ChangeLog
>
> PR debug/49366
> * dwarf2out.c (loc_list_from_tree_1): Expand some CONSTRUCTORs
> in DW_OP_pieces, just enough to handle pointers to member
> functions.
> (gen_remaining_tmpl_value_param_die_attribute): Use a location
> expression on DWARFv5 if a constant value doesn't work.

This change broke early LTO debug by emitting locations during early finish.

A simplistic fix is to do

@@ -24410,7 +24794,8 @@ gen_remaining_tmpl_value_param_die_attri
  if (!tree_add_const_value_attribute (e->die, e->arg))
{
  dw_loc_descr_ref loc = NULL;
- if (dwarf_version >= 5 || !dwarf_strict)
+ if (! early_dwarf
+ && (dwarf_version >= 5 || !dwarf_strict))
loc = loc_descriptor_from_tree (e->arg, 2, NULL);
  if (loc)
add_AT_loc (e->die, DW_AT_location, loc);

but in reality the issue is (again) that we can't refer to a DIE here.  Thus
it doesn't seem to be possible in dwarf to have debug info for

void func ();

  do  ();

with func being optimized out.

The issue with LTO / early debug is that we can't prune DIEs that refer
to optimized out entities from early debug output thus we have to create
those DIEs late only (in the above case, as tmpl_value_param_die_table
is not streamed, not at all for LTO).  Without LTO the issue is avoided
by resolve_addr pruning such references to optimized out entities from
location lists.

It would be nice to enhance dwarf to allow debug info for do 
so that printing the template parameter value is still possible even
if 'func' itself is optimized out.

Richard.

> for  gcc/testsuite/ChangeLog
>
> PR debug/49366
> * g++.dg/debug/dwarf2/template-params-12.H: New.
> * g++.dg/debug/dwarf2/template-params-12f.C: New.
> * g++.dg/debug/dwarf2/template-params-12g.C: New.
> * g++.dg/debug/dwarf2/template-params-12n.C: New.
> * g++.dg/debug/dwarf2/template-params-12s.C: New.
> * g++.dg/debug/dwarf2/template-params-12u.C: New.
> * g++.dg/debug/dwarf2/template-params-12v.C: New.
> * g++.dg/debug/dwarf2/template-params-12w.C: New.
> ---
>  gcc/dwarf2out.c| 93 
> +-
>  .../g++.dg/debug/dwarf2/template-params-12.H   | 17 
>  .../g++.dg/debug/dwarf2/template-params-12f.C  |  7 ++
>  .../g++.dg/debug/dwarf2/template-params-12g.C  |  7 ++
>  .../g++.dg/debug/dwarf2/template-params-12n.C  | 10 +++
>  .../g++.dg/debug/dwarf2/template-params-12s.C  |  8 ++
>  .../g++.dg/debug/dwarf2/template-params-12u.C  |  7 ++
>  .../g++.dg/debug/dwarf2/template-params-12v.C  |  6 ++
>  .../g++.dg/debug/dwarf2/template-params-12w.C  |  6 ++
>  9 files changed, 160 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/template-params-12.H
>  create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/template-params-12f.C
>  create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/template-params-12g.C
>  create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/template-params-12n.C
>  create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/template-params-12s.C
>  create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/template-params-12u.C
>  create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/template-params-12v.C
>  create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/template-params-12w.C
>
> diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
> index e3cb586..c658220 100644
> --- a/gcc/dwarf2out.c
> +++ b/gcc/dwarf2out.c
> @@ -16142,6 +16142,89 @@ loc_list_from_tree_1 (tree loc, int want_address,
>  case COMPLEX_CST:
>if ((ret = cst_pool_loc_descr (loc)))
> have_address = 1;
> +

Re: [PATCH 2/2][v4] Drop excess size used for run time allocated stack variables.

[Andreas Krebbel]

On 08/24/2016 04:02 AM, David Edelsohn wrote:
> This patch broke bootstrap on AIX.  Stage1 GCC is miscompiled.
> 
> Please revert this patch.

Done.  Sorry for the breakage.

-Andreas-

Re: [PATCH] Add a TARGET_GEN_MEMSET_VALUE hook

[Richard Biener]

On Mon, Aug 22, 2016 at 5:28 PM, H.J. Lu  wrote:
> On Mon, Aug 22, 2016 at 4:31 AM, Richard Biener
>  wrote:
>> On Fri, Aug 19, 2016 at 4:45 PM, H.J. Lu  wrote:
>>> On Fri, Aug 19, 2016 at 2:21 AM, Richard Biener
>>>  wrote:
 On Thu, Aug 18, 2016 at 5:16 PM, H.J. Lu  wrote:
> On Thu, Aug 18, 2016 at 1:18 AM, Richard Biener
>  wrote:
>> On Wed, Aug 17, 2016 at 10:11 PM, H.J. Lu  wrote:
>>> builtin_memset_gen_str returns a register used for memset, which only
>>> supports integer registers.  But a target may use vector registers in
>>> memmset.  This patch adds a TARGET_GEN_MEMSET_VALUE hook to duplicate
>>> QImode value to mode derived from STORE_MAX_PIECES, which can be used
>>> with vector instructions.  The default hook is the same as the original
>>> builtin_memset_gen_str.  A target can override it to support vector
>>> instructions for STORE_MAX_PIECES.
>>>
>>> Tested on x86-64 and i686.  Any comments?
>>>
>>> H.J.
>>> ---
>>> gcc/
>>>
>>> * builtins.c (builtin_memset_gen_str): Call 
>>> targetm.gen_memset_value.
>>> (default_gen_memset_value): New function.
>>> * target.def (gen_memset_value): New hook.
>>> * targhooks.c: Inclue "expmed.h" and "builtins.h".
>>> (default_gen_memset_value): New function.
>>
>> I see default_gen_memset_value in builtins.c but it belongs here.
>>
>>> * targhooks.h (default_gen_memset_value): New prototype.
>>> * config/i386/i386.c (ix86_gen_memset_value): New function.
>>> (TARGET_GEN_MEMSET_VALUE): New.
>>> * config/i386/i386.h (STORE_MAX_PIECES): Likewise.
>>> * doc/tm.texi.in: Add TARGET_GEN_MEMSET_VALUE hook.
>>> * doc/tm.texi: Updated.
>>>
>
> Like this?

 Aww, ok - I see builtins.c is a better place - sorry for the extra work.

 Richard.
>>>
>>> Here is the original patch with the updated ChangeLog.  OK for trunk?
>>
>> So now actually looking at what you are doing.  Why do we need a new
>> hook?  Is it that even if we make builtin_memset_gen_str handle vector-mode
>> MODE properly you don't get the desired optimized code?  Your patch doesn't
>
> It is hard to say what codes builtin_memset_gen_str will generate
> if vector mode is supported.  I suspect since broadcast instructions are
> target specific, a target hook may still be needed to broadcast a QImode
> input to a full vector register.

Well, we mainly seem to miss an optab that matches vec_duplicate (we have
vec_init only which might be sufficient as well).

>> seem to change the mode to vector but only STORE_MAX_PIECES and
>> op_by_pieces_d::run will only consider integer modes.
>
> My patch doesn't change mode of STORE_MAX_PIECES.  It changes
> how TImode register from STORE_MAX_PIECES is generated:
>
> (insn 8 7 9 (set (reg:SI 90)
> (zero_extend:SI (reg:QI 89))) c1.i:4 -1
>  (nil))
>
> (insn 9 8 10 (parallel [
> (set (reg:SI 91)
> (mult:SI (reg:SI 90)
> (const_int 16843009 [0x1010101])))
> (clobber (reg:CC 17 flags))
> ]) c1.i:4 -1
>  (nil))
>
> (insn 10 9 11 (set (reg:V4SI 92)
> (vec_duplicate:V4SI (reg:SI 91))) c1.i:4 4197 {*vec_dupv4si}
>  (nil))
>
> (insn 11 10 12 (set (subreg:V4SI (reg:TI 93) 0)
> (reg:V4SI 92)) c1.i:4 -1
>  (nil))
>
> (insn 12 11 13 (set (mem:TI (reg/v/f:DI 87 [ dst ]) [0 MEM[(void
> *)dst_2(D)]+0 S16
> A8])
> (reg:TI 93)) c1.i:4 -1
>  (nil))

Yes, but if you change STORE_MAX_PIECES to also include OI/XImode
then this exposes OI/XImode scalars by doing OI/XImode stores.  Thus
I am suggesting to instead allow to use vector integer modes as well
for the by_pieces stuff (and maybe guard that fact with a target hook).

Richard.

> vs.
>
> (insn 8 7 9 (set (reg:DI 91)
> (zero_extend:DI (reg:QI 89))) c1.i:4 -1
>  (nil))
>
> (insn 9 8 10 (set (subreg:DI (reg:TI 90) 0)
> (reg:DI 91)) c1.i:4 -1
>  (nil))
>
> (insn 10 9 11 (set (subreg:DI (reg:TI 90) 8)
> (const_int 0 [0])) c1.i:4 -1
>  (nil))
>
> (insn 11 10 12 (set (reg:DI 93)
> (const_int 72340172838076673 [0x101010101010101])) c1.i:4 -1
>  (nil))
>
> (insn 12 11 13 (parallel [
> (set (reg:DI 92)
> (mult:DI (subreg:DI (reg:TI 90) 8)
> (reg:DI 93)))
> (clobber (reg:CC 17 flags))
> ]) c1.i:4 -1
>  (nil))
>
> (insn 13 12 14 (set (reg:DI 95)
> (const_int 72340172838076673 [0x101010101010101])) c1.i:4 -1
>  (nil))
>
> (insn 14 13 15 (parallel [
> (set (reg:DI 94)
> (mult:DI (subreg:DI (reg:TI 90) 0)
> (reg:DI 95)))
> (clobber (reg:CC 17 flags))
> ]) c1.i:4 -1
>  (nil))
>
> (insn 15 14 16 (parallel [
> (set (reg:DI 96)
> (plus:DI (reg:DI 92)
> 

Re: [RFC] ipa bitwise constant propagation

[Prathamesh Kulkarni]

On 22 August 2016 at 19:24, Prathamesh Kulkarni
 wrote:
> On 22 August 2016 at 19:03, Martin Jambor  wrote:
>> Hi,
>>
>> On Tue, Aug 16, 2016 at 06:34:48PM +0530, Prathamesh Kulkarni wrote:
>>> Thanks, I updated the patch to address these issues (attached).
>>> However the patch caused ICE during testing
>>> objc.dg/torture/forward-1.m (and few others but with same ICE):
>>>
>>> Command line options:
>>> /home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/bootstrap-build/gcc/xgcc
>>> -B/home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/bootstrap-build/gcc/
>>> /home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/gcc/gcc/testsuite/objc.dg/torture/forward-1.m
>>> -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto
>>> -fuse-linker-plugin -fno-fat-lto-objects -fgnu-runtime
>>> -I/home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/gcc/gcc/testsuite/../../libobjc
>>> -B/home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/bootstrap-build/x86_64-pc-linux-gnu/./libobjc/.libs
>>> -L/home/prathamesh.kulkarni/gnu-toolchain/gcc/bits-prop-5/bootstrap-build/x86_64-pc-linux-gnu/./libobjc/.libs
>>> -lobjc -lm -o ./forward-1.exe
>>>
>>> Backtrace:
>>> 0x8c0ed2 ipa_get_param_decl_index_1
>>> ../../gcc/gcc/ipa-prop.c:106
>>> 0x8b7dbb will_be_nonconstant_predicate
>>> ../../gcc/gcc/ipa-inline-analysis.c:2110
>>> 0x8b7dbb estimate_function_body_sizes
>>> ../../gcc/gcc/ipa-inline-analysis.c:2739
>>> 0x8bae26 compute_inline_parameters(cgraph_node*, bool)
>>> ../../gcc/gcc/ipa-inline-analysis.c:3030
>>> 0x8bb309 inline_analyze_function(cgraph_node*)
>>> ../../gcc/gcc/ipa-inline-analysis.c:4157
>>> 0x11dc402 ipa_icf::sem_function::merge(ipa_icf::sem_item*)
>>> ../../gcc/gcc/ipa-icf.c:1345
>>> 0x11d6334 ipa_icf::sem_item_optimizer::merge_classes(unsigned int)
>>> ../../gcc/gcc/ipa-icf.c:3461
>>> 0x11e12c6 ipa_icf::sem_item_optimizer::execute()
>>> ../../gcc/gcc/ipa-icf.c:2636
>>> 0x11e34d6 ipa_icf_driver
>>> ../../gcc/gcc/ipa-icf.c:3538
>>> 0x11e34d6 ipa_icf::pass_ipa_icf::execute(function*)
>>> ../../gcc/gcc/ipa-icf.c:3585
>>>
>>> This appears due to following assert in ipa_get_param_decl_index_1():
>>> gcc_checking_assert (!flag_wpa);
>>> which was added by Martin's patch introducing ipa_get_type().
>>> Removing the assert works, however I am not sure if that's the correct 
>>> thing.
>>> I would be grateful for suggestions on how to handle this case.
>>>
>>
>> I wrote that the patch was not really tested, I did not think about
>> ICF loading bodies and re-running body-analyses at WPO time.
>> Nevertheless, after some consideration, I think that just removing the
>> assert is fine.  After all, the caller must have passed a PARM_DECL if
>> it is doing anything sensible at all and that means we have access to
>> the function body.
> Thanks for the pointers. I will validate the patch after removing assert,
> and get back.
Hi,
The attached version passes bootstrap+test on
x86_64-unknown-linux-gnu, ppc64le-linux-gnu,
and with c,c++,fortran on armv8l-linux-gnueabihf.
Cross-tested on arm*-*-* and aarch64*-*-*.
Verified the patch survives lto-bootstrap on x86_64-unknown-linux-gnu.
Ok to commit ?

Thanks,
Prathamesh
>
> Thanks,
> Prathamesh
>>
>> Thanks,
>>
>> Martin
Patch for performing interprocedural bitwise constant propagation.

2016-08-23  Prathamesh Kulkarni  
Martin Jambhor  

* common.opt: New option -fipa-cp-bit.
* doc/invoke.texi: Document -fipa-cp-bit.
* opts.c (default_options_table): Add entry for -fipa-cp-bit.
(enable_fdo_optimizations): Check for flag_ipa_cp_bit.
* tree-ssa-ccp.h: New header file.
* tree-ssa-ccp.c: Include tree-ssa-ccp.h
(bit_value_binop_1): Change to bit_value_binop_1 and export it.
Replace all occurences of tree parameter by two new params: signop, int.
(bit_value_unop_1): Change to bit_value_unop and export it.
Replace all occurences of tree parameter by two new params: signop,
int.
(bit_value_binop): Change call from bit_value_binop_1 to
bit_value_binop.
(bit_value_assume_aligned): Likewise.
(bit_value_unop): Change call from bit_value_unop_1 to bit_value_unop.
(do_ssa_ccp): Pass nonzero_p || flag_ipa_cp_bit instead of nonzero_p
to ccp_finalize.
(ccp_finalize): Skip processing if val->mask == 0.
* ipa-cp.c: Include tree-ssa-ccp.h
(ipcp_bits_lattice): New class.
(ipcp_param_lattice (bits_lattice): New member.
(print_all_lattices): Call ipcp_bits_lattice::print.
(set_all_contains_variable): Call ipcp_bits_lattice::set_to_bottom. 
(initialize_node_lattices): Likewise.
(propagate_bits_accross_jump_function): New function.
(propagate_constants_accross_call): Call
propagate_bits_accross_jump_function.
(ipcp_propagate_stage): Store parameter types when in_lto_p is true.
(ipcp_store_bits_results): New function.
(ipcp_driver): Call i

[Patch, fortran] pr77358 - [F08] deferred-length character function returns zero-length string

[Paul Richard Thomas]

Dear All,

The attached fixes this problem, bootstraps and regtests on FC21/x86_64.

OK for 6-branch and trunk?

Paul

2016-08-24  Paul Thomas  

PR fortran/77358

* resolve.c (resolve_fl_procedure): Use the correct gfc_charlen
for deferred character length module procedures.

2016-08-24  Paul Thomas  

PR fortran/77358
* gfortran.dg/submodule_17.f08: New test.
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 238840)
--- gcc/fortran/resolve.c   (working copy)
*** resolve_fl_procedure (gfc_symbol *sym, i
*** 11961,11966 
--- 11961,11973 
iface = sym->ts.interface;
sym->ts.interface = NULL;
  
+   /* Make sure that the result uses the correct charlen for deferred
+length results.  */
+   if (iface && sym->result
+ && iface->ts.type == BT_CHARACTER
+ && iface->ts.deferred)
+   sym->result->ts.u.cl = iface->ts.u.cl;
+ 
if (iface == NULL)
goto check_formal;
  
Index: gcc/testsuite/gfortran.dg/submodule_17.f08
===
*** gcc/testsuite/gfortran.dg/submodule_17.f08  (revision 0)
--- gcc/testsuite/gfortran.dg/submodule_17.f08  (working copy)
***
*** 0 
--- 1,27 
+ ! { dg-do run }
+ !
+ ! Tests the fix for PR77358, in which the wrong gfc_charlen was
+ ! being used for the result of 'get'.
+ !
+ ! Contributed by Damian Rouson  
+ !
+ module hello_interface
+   character(len=13) :: string="Hello, world!"
+   interface
+ module function get() result(result_string)
+   character(:), allocatable :: result_string
+ end function
+   end interface
+ end module
+ 
+ submodule(hello_interface) hello_implementation
+ contains
+   module function get() result(result_string)
+ character(:), allocatable :: result_string
+ result_string = string
+   end function
+ end submodule
+ 
+   use hello_interface
+   if (get() .ne. string) call abort
+ end

Re: [Patch, fortran] pr77358 - [F08] deferred-length character function returns zero-length string

[Tobias Burnus]

Dear Paul,

Paul Richard Thomas wrote:
> The attached fixes this problem, bootstraps and regtests on FC21/x86_64.
> OK for 6-branch and trunk?

Looks good to me. Thanks for the patch.

Tobias

> 2016-08-24  Paul Thomas  
> 
> PR fortran/77358
> 
> * resolve.c (resolve_fl_procedure): Use the correct gfc_charlen

There shouldn't be a space between the PR line and the rest.
> 
> PR fortran/77358
> * gfortran.dg/submodule_17.f08: New test.

Re: [PATCH 2/2][v4] Drop excess size used for run time allocated stack variables.

[David Edelsohn]

On Wed, Aug 24, 2016 at 7:42 AM, Andreas Krebbel
 wrote:
> On 08/24/2016 04:02 AM, David Edelsohn wrote:
>> This patch broke bootstrap on AIX.  Stage1 GCC is miscompiled.
>>
>> Please revert this patch.
>
> Done.  Sorry for the breakage.

Is the alignment assumption safe irrespective of ABI?

Thanks, David

Re: [PATCH 0/4] Applying fix-its on behalf of the user to their code

[David Malcolm]

On Tue, 2016-08-23 at 21:57 -0400, Eric Gallager wrote:
> On 8/23/16, David Malcolm  wrote:
> > Currently our diagnostics subsystem can emit fix-it hints
> > suggesting edits the user can make to their code to fix
> > warnings/errors,
> > but currently the user must make these edits manually [1].
> > 
> > The following patch kit adds two command-line options with which
> > we can make the changes on behalf of the user:
> > 
> > (A) -fdiagnostics-generate-patch emits a diff to stderr, which
> > could potentially be applied using "patch"; it also gives another
> > way to visualize the fix-its.
> > 
> > (B) -fdiagnostics-apply-fixits, which writes back the changes
> > to the input files.
> > 
> > Patches 1 and 2 are enabling work.
> > 
> > Patch 3 is the heart of the kit: a new class edit_context,
> > representing a set of changes to be applied to source file(s).
> > The changes are atomic: all are applied or none [2], and locations
> > are
> > specified relative to the initial inputs (and there's some fiddly
> > logic for fixing up locations so that the order in which edits are
> > applied doesn't matter).
> > 
> > Patch 4 uses the edit_context class to add the new options.
> > 
> > The kit also unlocks the possibility of writing refactoring tools
> > as gcc plugins, or could be used to build a parser for the output
> > of -fdiagnostics-parseable-fixits.
> > 
> > Successfully bootstrapped®rtested the combination of the patches
> > on x86_64-pc-linux-gnu.
> > 
> > I believe I can self-approve patch 3, and, potentially patch 4
> > as part of my "diagnostics maintainer" role, though this is
> > clearly a significant extension of the scope of diagnostics.
> > 
> > OK for trunk? (assuming individual bootstraps®rtesting)
> > 
> > [1] or use -fdiagnostics-parseable-fixits - but we don't have a
> > way to parse that output format yet
> > [2] the error-handling for write-back isn't great right now, so
> > the claim of atomicity is a stretch; is there a good cross-platform
> > way to guarantee atomicity of a set of filesystem operations?
> > (maybe create the replacements as tempfiles, rename the originals,
> > try to move all the replacements into place, and then unlink the
> > backups, with a rollback involving moving the backups into place)
> > 
> > David Malcolm (4):
> >   selftest: split out named_temp_file from temp_source_file
> >   Improvements to typed_splay_tree
> >   Introduce class edit_context
> >   Add -fdiagnostics-generate-patch and -fdiagnostics-apply-fixits
> > 
> >  gcc/Makefile.in|2 +
> >  gcc/common.opt |8 +
> >  gcc/diagnostic-color.c |8 +-
> >  gcc/diagnostic.c   |   11 +
> >  gcc/diagnostic.h   |7 +
> >  gcc/doc/invoke.texi|   28 +-
> >  gcc/edit-context.c | 1341
> > 
> >  gcc/edit-context.h |   66 +
> >  gcc/selftest-run-tests.c   |2 +
> >  gcc/selftest.c |   49 +-
> >  gcc/selftest.h |   26 +-
> >  .../diagnostic-test-show-locus-generate-patch.c|   77 ++
> >  gcc/testsuite/gcc.dg/plugin/plugin.exp |3 +-
> >  gcc/toplev.c   |   20 +
> >  gcc/typed-splay-tree.c |   79 ++
> >  gcc/typed-splay-tree.h |   67 +
> >  16 files changed, 1770 insertions(+), 24 deletions(-)
> >  create mode 100644 gcc/edit-context.c
> >  create mode 100644 gcc/edit-context.h
> >  create mode 100644
> > gcc/testsuite/gcc.dg/plugin/diagnostic-test-show-locus-generate
> > -patch.c
> >  create mode 100644 gcc/typed-splay-tree.c
> > 
> > --
> > 1.8.5.3
> > 
> > 
> 
> 
> So, if -fdiagnostics-apply-fixits writes the fixits back into the
> file
> as actual code, I'm wondering, could there also be a separate option
> to write them in as comments? Say if I want to be reminded to fix
> something, but am not quite sure if the fixit is right or not, and
> don't want to have a separate patch file lying around... e.g.,
> instead
> of changing
> return ptr.x;
> to
> return ptr->x;
> it could change it to
> return ptr.x; // ->
> or maybe put it below like:
> return ptr.x;
>/* -> */
> Just an idea I thought might be useful as a user... I dunno...

Thanks - interesting idea.  I'm keen on making life easier for gcc
users, and I think there's "low hanging fruit" around fix-its (hence my
patches), so please keep suggesting ideas like this.

That said, I think that implementing this particular one robustly could
be non-trivial.  Consider the case of a gcc plugin that tidies up code
to fix a particular coding style: it might emit this fix-it:

test.c:1:20: missing trailing '.' at end of comment
  /* Open the pod b

Re: [PATCH 0/4] Applying fix-its on behalf of the user to their code

[Trevor Saunders]

On Wed, Aug 24, 2016 at 09:59:18AM +0200, Richard Biener wrote:
> On Wed, Aug 24, 2016 at 3:28 AM, David Malcolm  wrote:
> > Currently our diagnostics subsystem can emit fix-it hints
> > suggesting edits the user can make to their code to fix warnings/errors,
> > but currently the user must make these edits manually [1].
> >
> > The following patch kit adds two command-line options with which
> > we can make the changes on behalf of the user:
> >
> > (A) -fdiagnostics-generate-patch emits a diff to stderr, which
> > could potentially be applied using "patch"; it also gives another
> > way to visualize the fix-its.
> >
> > (B) -fdiagnostics-apply-fixits, which writes back the changes
> > to the input files.
> 
> I don't like this very much - option (A) looks good with the user having
> to manually apply a patch.  But (B) is just asking for trouble ;)

 Obviously your work flow needs to deal with things other than your
 editor changing files for this to be useful, but it can only cause
 trouble for you if you ask for it.  I don't think it should be the
 default, and I'm not sure if all fix it hints are good candidates.
 However it does make my life better if I don't need to do busy work
 like insert |typename| to make the compiler happy with my template
 usage.

 I think the even better use of this is for plugins that want to rewrite
 the source code for a project to change some API's consumers in a
 mechanical way.  Currently you usually get to do that by manually
 applying the same fix whever the compiler tells you there is an error,
 and in some cases that really should be automatable.  I believe
 Libreoffice has used clang plugins to this to good effect, but I don't
 know any details.

> I'd rather have -fdiagnostics-apply-fixits apply the fixit hints for
> the current compilation only (so you'll see if the compile is successful
> after applying the suggestions).  That is, work more in a "error recovery"
> mode.

That might be useful too.

Trev

Re: [PATCH 0/4] Applying fix-its on behalf of the user to their code

[David Malcolm]

On Wed, 2016-08-24 at 09:59 +0200, Richard Biener wrote:
> On Wed, Aug 24, 2016 at 3:28 AM, David Malcolm 
> wrote:
> > Currently our diagnostics subsystem can emit fix-it hints
> > suggesting edits the user can make to their code to fix
> > warnings/errors,
> > but currently the user must make these edits manually [1].
> > 
> > The following patch kit adds two command-line options with which
> > we can make the changes on behalf of the user:
> > 
> > (A) -fdiagnostics-generate-patch emits a diff to stderr, which
> > could potentially be applied using "patch"; it also gives another
> > way to visualize the fix-its.
> > 
> > (B) -fdiagnostics-apply-fixits, which writes back the changes
> > to the input files.
> 
> I don't like this very much - option (A) looks good with the user
> having
> to manually apply a patch.  But (B) is just asking for trouble ;)

Yeah, the current implementation of (B) has issues with atomicity; I
wonder what would happen in a parallel build if a fix-it happened
affecting a header file...

Would you be open to a less ambitious version of the patch kit which
just implemented (A)?

> I'd rather have -fdiagnostics-apply-fixits apply the fixit hints for
> the current compilation only (so you'll see if the compile is
> successful
> after applying the suggestions).  That is, work more in a "error
> recovery"
> mode.
> Richard.

One approach here would be to provide a small binary that knows how to
parse the output of -fdiagnostics-parseable-fixits, and applies them,
something like ${bindir}/gcc-apply-fixits
It would read a stream of text on stdin (taken from stderr of cc1 and
friends), parse any lines emitted by -fdiagnostics-parseable-fixits
(ignoring the rest), put them all into an edit_context, and then apply
them (or generate a patch).

If nothing else, this might be useful for people integrating fix-its
into an IDE.

I was thinking that the driver could then have an option to attempt the
compile, and have it send stderr through the binary, and somehow run
the compiler twice.  But presumably we'd want to have the 2nd
invocation of the compiler be run on temporarily-modified sources; what
happens if we need to issue a diagnostic on such sources?  In
particular what filename does the user see?  It seems that we'd need
some way of mapping filenames, so that the compiler and the user are
effectively seeing an "as-if" view of the filesystem (as if the changes
were applied).

Alternatively, maybe this is too implementation-focused: we should
start by thinking of the interaction model - what do we want the user's
experience to be?

I wonder if there's a way for a fix-it to actually change the token
stream seen by the compiler (doing it all in one invocation of the
compiler).

Dave

> > Patches 1 and 2 are enabling work.
> > 
> > Patch 3 is the heart of the kit: a new class edit_context,
> > representing a set of changes to be applied to source file(s).
> > The changes are atomic: all are applied or none [2], and locations
> > are
> > specified relative to the initial inputs (and there's some fiddly
> > logic for fixing up locations so that the order in which edits are
> > applied doesn't matter).
> > 
> > Patch 4 uses the edit_context class to add the new options.
> > 
> > The kit also unlocks the possibility of writing refactoring tools
> > as gcc plugins, or could be used to build a parser for the output
> > of -fdiagnostics-parseable-fixits.
> > 
> > Successfully bootstrapped®rtested the combination of the patches
> > on x86_64-pc-linux-gnu.
> > 
> > I believe I can self-approve patch 3, and, potentially patch 4
> > as part of my "diagnostics maintainer" role, though this is
> > clearly a significant extension of the scope of diagnostics.
> > 
> > OK for trunk? (assuming individual bootstraps®rtesting)
> > 
> > [1] or use -fdiagnostics-parseable-fixits - but we don't have a
> > way to parse that output format yet
> > [2] the error-handling for write-back isn't great right now, so
> > the claim of atomicity is a stretch; is there a good cross-platform
> > way to guarantee atomicity of a set of filesystem operations?
> > (maybe create the replacements as tempfiles, rename the originals,
> > try to move all the replacements into place, and then unlink the
> > backups, with a rollback involving moving the backups into place)
> > 
> > David Malcolm (4):
> >   selftest: split out named_temp_file from temp_source_file
> >   Improvements to typed_splay_tree
> >   Introduce class edit_context
> >   Add -fdiagnostics-generate-patch and -fdiagnostics-apply-fixits
> > 
> >  gcc/Makefile.in|2 +
> >  gcc/common.opt |8 +
> >  gcc/diagnostic-color.c |8 +-
> >  gcc/diagnostic.c   |   11 +
> >  gcc/diagnostic.h   |7 +
> >  gcc/doc/invoke.texi|   28 +-
> >  gcc/edit-context.c   

Re: [PATCH 0/4] Various GCOV/PGO improvements

[David Edelsohn]

Martin and Jan,

This set of patches introduces a huge number of testsuite regressions
on AIX.  AIX defaults to 32 bit. Although it supports a 64 bit "long
long" type, it does not have 64 bit atomic operations on "long long"
in 32 bit mode.  All of the testcases fails with

ld: 0711-317 ERROR: Undefined symbol: .__atomic_fetch_add_8
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status

Testing LONG_LONG_TYPE_SIZE > 32 does not seem like a robust
mechanism, especially later removing GCOV_TYPE_SIZE.

I didn't think that __atomic_fetch_add_8 was required in 32 bit mode.

Thanks, David

Re: [PATCH 0/4] Applying fix-its on behalf of the user to their code

[Bernd Schmidt]

On 08/24/2016 03:28 AM, David Malcolm wrote:


(B) -fdiagnostics-apply-fixits, which writes back the changes
to the input files.


That sounds really scary, there's no way I'd personally ever enable 
something like this. Do we have any data about what percentage of fixits 
actually correctly identify the problem?


We also better make really sure there's no way we'll get bug reports 
along the lines of "gcc ate my program and now it's gone".



Bernd

Re: Implement -Wimplicit-fallthrough (version 5)

[Marek Polacek]

On Mon, Aug 22, 2016 at 10:31:16AM -0600, Martin Sebor wrote:
> Just a few minor nits based on a quick reading of the patch:

Thanks for looking into this.
 
> > @@ -24114,6 +24164,16 @@ cp_parser_std_attribute (cp_parser *parser)
> >  " use %");
> >   TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
> > }
> > +  /* C++17 fallthrough attribute is equivalent to GNU's.  */
> > +  else if (cxx_dialect >= cxx11
> > +  && is_attribute_p ("fallthrough", attr_id))
> > +   {
> > + if (cxx_dialect < cxx1z)
> > +   pedwarn (token->location, OPT_Wpedantic,
> > +"% is a C++17 feature;"
> 
> The text of the message above is missing the word "attribute" that's
> normally used in all other diagnostics about attributes.
 
Here I copied over the C++14 deprecated attribute handling above and
that doesn't have the word "attribute".  I guess we can fix both later.

> But I wonder about issuing a pedantic warning for this C++ 17 attribute
> when it isn't issued for others such as nodiscard.  I would expect them
> to be diagnosed consistently (i.e., __attribute__((fallthrough)) to be
> accepted in all modes, and [[fallthrough]] diagnosed in C++ 14 mode,
> and all [[...]] attributes diagnosed in C++ 98 as they are now).  It
> looks to me like your patch is close to what I expect but different
> from other C++ 17 attributes.
 
So currently __attribute__((fallthrough)) is accepted in all modes,
[[fallthrough]] diagnosed in C++14 mode and all [[...]] attributes diagnosed in
C++98 mode -- no disagreement on that.  But I think the pedwarn for the
fallthrough attribute it appropriate, and we should also diagnose nodiscard.
And maybe_unused too.  Perhaps we'll need to discuss this with Jason, though
it probably isn't the most important thing.
 
> > +" use %");
> > + TREE_PURPOSE (TREE_PURPOSE (attribute)) = get_identifier ("gnu");
> > +   }
> > /* Transactional Memory TS optimize_for_synchronized attribute is
> >  equivalent to GNU transaction_callable.  */
> > else if (is_attribute_p ("optimize_for_synchronized", attr_id))
> > @@ -24178,6 +24238,10 @@ cp_parser_check_std_attribute (tree attributes, 
> > tree attribute)
> >&& lookup_attribute ("deprecated", attributes))
> > error ("attribute deprecated can appear at most once "
> >"in an attribute-list")
> > +  else if (is_attribute_p ("fallthrough", name)
> > +  && lookup_attribute ("fallthrough", attributes))
> > +   error ("attribute fallthrough can appear at most once "
> > +  "in an attribute-list");
> 
> Here "fallthrough" isn't quoted when it is everywhere else as far
> as I noticed (looks like the same applies to "deprecated" above).
 
I fixed all of them byt adding %<...%>.

> > +C++17 provides a standard way to suppress the 
> > @option{-Wimplicit-fallthrough}
> > +warning using @code{[[fallthrough]];} instead of the GNU attribute.  In 
> > C++11
> > +or C++14 users can use @code{[[gnu::fallthrough]];}, which is a GNU 
> > extension.
> > +Instead of the these attributes, it is also possible to add a "falls 
> > through"
> > +comment to silence the warning.  GCC accepts wide range of such comments, 
> > so
> > +e.g. all of "Falls through.", "fallthru", "FALLS-THROUGH" work.
> 
> The last sentence is missing an article:
> 
>   GCC accepts _a_ wide range of such comments...
 
Fixed.

> (Personally, I also find using "e.g." in the middle of a sentence
> a bit too informal and would like it better spelled out, but that
> could just be me.)
 
Changed to "for example", if that's any better.

> > +/* Find LABEL in vector of label entries VEC.  */
> > +
> > +static struct label_entry *
> > +find_label_entry (const auto_vec *vec, tree label)
> > +{
> > +  unsigned int i;
> > +  struct label_entry *l;
> > +
> > +  FOR_EACH_VEC_ELT (*vec, i, l)
> > +if (l->label == label)
> > +  return l;
> > +  return NULL;
> > +}
> > +
> > +/* Return true if LABEL, a LABEL_DECL, represents a case label
> > +   in a vector of labels CASES.  */
> > +
> > +static bool
> > +case_label_p (const vec &cases, tree label)
> 
> I'm curious why this function takes the first argument by const
> reference when the function above by const pointer.  Is there
> a subtle difference between the functions that I'm not seeing?
> For that matter, is there a convention in GCC?  (FWIW, my own
> rule of thumb is to have a function take a large argument by
> const reference when it must be non-null and by pointer
> otherwise.)
 
I admit I don't know what's better, I'd say the reference, but elsewhere in the
codebase I see const *.  I changed case_label_p's vec argument to const * to be
consistent, but I'm all ears if anyone wants to educate me.

> > +/* Collect interesting labels to LABELS and return the statement preceding
> > +   another case label, or a user-defined label.  */
> 
> Suggest either "Collect interesting labels in LABELS" or "Append
> in

Re: [PATCH 0/4] Applying fix-its on behalf of the user to their code

[Richard Biener]

On Wed, Aug 24, 2016 at 3:45 PM, Bernd Schmidt  wrote:
> On 08/24/2016 03:28 AM, David Malcolm wrote:
>
>> (B) -fdiagnostics-apply-fixits, which writes back the changes
>> to the input files.
>
>
> That sounds really scary, there's no way I'd personally ever enable
> something like this. Do we have any data about what percentage of fixits
> actually correctly identify the problem?
>
> We also better make really sure there's no way we'll get bug reports along
> the lines of "gcc ate my program and now it's gone".

You never typoed

gcc t.c -o t.c

?  ;)  (I did ... :/)

But yes, exactly my feelings towards (B).

IMHO (B) is something for tight IDE - compiler integration, sth GCC is not very
good at at the moment.  [hint: provide the patches in a form so emacs
can eat them]

Richard.

>
> Bernd

[gomp4] Frame propagation for routines

[Nathan Sidwell]

I've committed this to the gomp4 branch.  It addresses an issue I was puzzled 
we'd not met, but then I realized I'd been turning the optimizer on and thus 
inlining things, which hid the problem.


If we pass a reference (i.e. addressof) a frame object to an openecc routine 
that itself contains partitioned execution, the partitioned instances will 
interpret the address as referring to their own .local stack frame -- even 
though the address has been 'globalized'.


The openacc std doesn't say whether the other threads should refer to the 
original unique instance, or clone that object.  However, for non-references, 
the object is cloned, and I have taken that approach as it's the simplest.


nathan
2016-08-24  Nathan Sidwell  

	gcc/
	* config/nvptx/nvptx.c (nvptx_emit_forking, nvptx_emit_joining):
	Emit insns for calls too.
	(nvptx_find_par): Always look for worker-level predecessor insn.
	(nvptx_propagate): Add is_call parm, return bool.  Copy frame for
	calls.
	(nvptx_vpropagate, nvptx_wpropagate): Adjust.
	(nvptx_process_pars): Propagate frames for calls.

	libgomp/
	* testsuite/libgomp.oacc-c++/ref-1.C: New.

Index: gcc/config/nvptx/nvptx.c
===
--- gcc/config/nvptx/nvptx.c	(revision 239735)
+++ gcc/config/nvptx/nvptx.c	(working copy)
@@ -335,8 +335,7 @@ nvptx_emit_forking (unsigned mask, bool
 	 it creates a block with a single successor before entering a
 	 partitooned region.  That is a good candidate for the end of
 	 an SESE region.  */
-  if (!is_call)
-	emit_insn (gen_nvptx_fork (op));
+  emit_insn (gen_nvptx_fork (op));
   emit_insn (gen_nvptx_forked (op));
 }
 }
@@ -355,8 +354,7 @@ nvptx_emit_joining (unsigned mask, bool
   /* Emit joining for all non-call pars to ensure there's a single
 	 predecessor for the block the join insn ends up in.  This is
 	 needed for skipping entire loops.  */
-  if (!is_call)
-	emit_insn (gen_nvptx_joining (op));
+  emit_insn (gen_nvptx_joining (op));
   emit_insn (gen_nvptx_join (op));
 }
 }
@@ -2489,8 +2487,7 @@ nvptx_find_par (bb_insn_map_t *map, para
 	par = new parallel (par, mask);
 	par->forked_block = block;
 	par->forked_insn = end;
-	if (!(mask & GOMP_DIM_MASK (GOMP_DIM_MAX))
-		&& (mask & GOMP_DIM_MASK (GOMP_DIM_WORKER)))
+	if (mask & GOMP_DIM_MASK (GOMP_DIM_WORKER))
 	  par->fork_insn
 		= nvptx_discover_pre (block, CODE_FOR_nvptx_fork);
 	  }
@@ -2505,8 +2502,7 @@ nvptx_find_par (bb_insn_map_t *map, para
 	gcc_assert (par->mask == mask);
 	par->join_block = block;
 	par->join_insn = end;
-	if (!(mask & GOMP_DIM_MASK (GOMP_DIM_MAX))
-		&& (mask & GOMP_DIM_MASK (GOMP_DIM_WORKER)))
+	if (mask & GOMP_DIM_MASK (GOMP_DIM_WORKER))
 	  par->joining_insn
 		= nvptx_discover_pre (block, CODE_FOR_nvptx_joining);
 	par = par->parent;
@@ -3191,29 +3187,34 @@ nvptx_find_sese (auto_vec &
 #undef BB_SET_SESE
 #undef BB_GET_SESE
 
-/* Propagate live state at the start of a partitioned region.  BLOCK
-   provides the live register information, and might not contain
-   INSN. Propagation is inserted just after INSN. RW indicates whether
-   we are reading and/or writing state.  This
+/* Propagate live state at the start of a partitioned region.  IS_CALL
+   indicates whether the propagation is for a (partitioned) call
+   instruction.  BLOCK provides the live register information, and
+   might not contain INSN. Propagation is inserted just after INSN. RW
+   indicates whether we are reading and/or writing state.  This
separation is needed for worker-level proppagation where we
essentially do a spill & fill.  FN is the underlying worker
function to generate the propagation instructions for single
register.  DATA is user data.
 
-   We propagate the live register set and the entire frame.  We could
-   do better by (a) propagating just the live set that is used within
-   the partitioned regions and (b) only propagating stack entries that
-   are used.  The latter might be quite hard to determine.  */
+   Returns true if we didn't emit any instructions.
+
+   We propagate the live register set for non-calls and the entire
+   frame for calls and non-calls.  We could do better by (a)
+   propagating just the live set that is used within the partitioned
+   regions and (b) only propagating stack entries that are used.  The
+   latter might be quite hard to determine.  */
 
 typedef rtx (*propagator_fn) (rtx, propagate_mask, unsigned, void *);
 
-static void
-nvptx_propagate (basic_block block, rtx_insn *insn, propagate_mask rw,
-		 propagator_fn fn, void *data)
+static bool
+nvptx_propagate (bool is_call, basic_block block, rtx_insn *insn,
+		 propagate_mask rw, propagator_fn fn, void *data)
 {
   bitmap live = DF_LIVE_IN (block);
   bitmap_iterator iterator;
   unsigned ix;
+  bool empty = true;
 
   /* Copy the frame array.  */
   HOST_WIDE_INT fs = get_frame_size ();
@@ -3225,6 +3226,7 @@ nvptx_propa

[PATCH, testsuite]: Improve and clean-up tree-ssa/prefetch-?.c testcases

[Uros Bizjak]

Hello!

Attached patch improves and cleans up tree-ssa/prefetch-? testcases in
several ways:
a) Enables testcases on 64bit x86 targets by selecting amdfam10
architecture instead of 32bit-only athlon architecture
b) Removes unnecessary -msse2 -mfpmath=sse compile flags
c) Removes unnecessary SSE2 effective target requirement for compile tests (all)
d) Removes assembly scanning directives. The final prefetch asm insns
are heavily target dependent, we already scanned tree dumps for
correct codes, and we have tests for asm insns in gcc.misc-tests.

2016-08-24  Uros Bizjak  

PR target/77270
* gcc.dg/tree-ssa/loop-28.c: Also compile on 32bit x86 targets.
(dg-options): Use -march=amdfam10 instead of -march=athlon.
* gcc.dg/tree-ssa/update-unroll-1.c: Ditto.
* gcc.dg/tree-ssa/prefetch-3.c: Ditto.
* gcc.dg/tree-ssa/prefetch-4.c: Ditto.
* gcc.dg/tree-ssa/prefetch-5.c: Ditto.
* gcc.dg/tree-ssa/prefetch-6.c: Ditto.  Do not require sse2
effective target.  Remove scan-assembler-times directives.
* gcc.dg/tree-ssa/prefetch-7.c: Ditto.
* gcc.dg/tree-ssa/prefetch-8.c: Ditto.
* gcc.dg/tree-ssa/prefetch-9.c: Ditto.

Tested on x86_64-linux-gnu {,-m32}, where it "fixes" a couple of
scan-asm testsuite errors.

Committed to mainline SVN.

Uros.
Index: gcc.dg/tree-ssa/loop-28.c
===
--- gcc.dg/tree-ssa/loop-28.c   (revision 239735)
+++ gcc.dg/tree-ssa/loop-28.c   (working copy)
@@ -1,5 +1,5 @@
-/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } } */
-/* { dg-options "-O2 -fprefetch-loop-arrays -march=athlon 
-fdump-tree-optimized -fdump-tree-aprefetch --param max-unrolled-insns=1000" } 
*/
+/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-options "-O2 -fprefetch-loop-arrays -march=amdfam10 
-fdump-tree-optimized -fdump-tree-aprefetch --param max-unrolled-insns=1000" } 
*/
 
 char x[10];
 
Index: gcc.dg/tree-ssa/prefetch-3.c
===
--- gcc.dg/tree-ssa/prefetch-3.c(revision 239735)
+++ gcc.dg/tree-ssa/prefetch-3.c(working copy)
@@ -1,7 +1,7 @@
 /* Prefetching used to prefer nonsensical unroll factor of 5 in this testcase. 
 */
 
-/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } } */
-/* { dg-options "-O2 -fprefetch-loop-arrays -march=athlon -msse2 -mfpmath=sse 
-fdump-tree-aprefetch-details" } */
+/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-options "-O2 -fprefetch-loop-arrays -march=amdfam10 
-fdump-tree-aprefetch-details" } */
 
 #define N 100
 
Index: gcc.dg/tree-ssa/prefetch-4.c
===
--- gcc.dg/tree-ssa/prefetch-4.c(revision 239735)
+++ gcc.dg/tree-ssa/prefetch-4.c(working copy)
@@ -1,7 +1,7 @@
 /* The loop rolls too little, hence the prefetching would not be useful.  */
 
-/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } } */
-/* { dg-options "-O2 -fprefetch-loop-arrays -march=athlon 
-fdump-tree-optimized" } */
+/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-options "-O2 -fprefetch-loop-arrays -march=amdfam10 
-fdump-tree-optimized" } */
 
 int xxx[20];
 
Index: gcc.dg/tree-ssa/prefetch-5.c
===
--- gcc.dg/tree-ssa/prefetch-5.c(revision 239735)
+++ gcc.dg/tree-ssa/prefetch-5.c(working copy)
@@ -1,5 +1,5 @@
-/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } } */
-/* { dg-options "-O2 --param min-insn-to-prefetch-ratio=5 
-fprefetch-loop-arrays -march=athlon -fdump-tree-aprefetch-details" } */
+/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-options "-O2 -fprefetch-loop-arrays -march=amdfam10 --param 
min-insn-to-prefetch-ratio=5 -fdump-tree-aprefetch-details" } */
 
 /* These are common idioms for writing variable-length arrays at the end
of structures.  We should not deduce anything about the number of iterations
Index: gcc.dg/tree-ssa/prefetch-6.c
===
--- gcc.dg/tree-ssa/prefetch-6.c(revision 239735)
+++ gcc.dg/tree-ssa/prefetch-6.c(working copy)
@@ -1,6 +1,5 @@
-/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } } */
-/* { dg-require-effective-target sse2 } */
-/* { dg-options "-O2 -fprefetch-loop-arrays -march=athlon -msse2 -mfpmath=sse 
--param simultaneous-prefetches=100 --param min-insn-to-prefetch-ratio=6 
-fdump-tree-aprefetch-details" } */
+/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-options "-O2 -fprefetch-loop-arrays -march=amdfam10 --param 
simultaneous-prefetches=100 --param min-insn-to-prefetch-ratio=6 
-fdump-tree-aprefetch-details" } */
 
 #define N 1000
 #define K 900
@@ -47,7 +46,3 @@
 
 /* { dg-final { scan-tree-dump-times "Issued prefetch" 5 "aprefetch" } } */
 /* { dg-final { scan-tree-dump-

Re: [Patch, fortran] PR48298 - [F03] User-Defined Derived-Type IO (DTIO)

[Jerry DeLisle]

Here is an additional test case demonstrating recursive calls.

Regards,

Jerry
! { dg-do run }
!
! Functional test of User Defined Derived Type IO.
!
! This tests recursive calls where a derived type has a member that is
! itself.
!
MODULE p
  USE ISO_FORTRAN_ENV
  TYPE :: person
CHARACTER (LEN=20) :: name
INTEGER(4) :: age
type(person), pointer :: next => NULL()
CONTAINS
  procedure :: pwf
  procedure :: prf
  GENERIC :: WRITE(FORMATTED) => pwf
  GENERIC :: READ(FORMATTED) => prf
  END TYPE person
CONTAINS
  RECURSIVE SUBROUTINE pwf (dtv,unit,iotype,vlist,iostat,iomsg)
CLASS(person), INTENT(IN) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER (LEN=*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: vlist(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER (LEN=*), INTENT(INOUT) :: iomsg
CHARACTER (LEN=30) :: udfmt
INTEGER :: myios

udfmt='(*(g0))'
iomsg = "SUCCESS"
iostat=0
if (iotype.eq."DT") then
  if (size(vlist).ne.0) print *, 36
  if (associated(dtv%next)) then
WRITE(unit, FMT = '(a20,i2, DT)', IOSTAT=iostat, advance='no') dtv%name, dtv%age, dtv%next
  else
WRITE(unit, FMT = '(a20,i2)', IOSTAT=iostat, advance='no') dtv%name, dtv%age
  endif
  if (iostat.ne.0) iomsg = "Fail PWF DT"
endif
if (iotype.eq."DTzeroth") then
  if (size(vlist).ne.0) print *, 40
  WRITE(unit, FMT = '(g0,g0)', advance='no') dtv%name, dtv%age
  if (iostat.ne.0) iomsg = "Fail PWF DTzeroth"
endif
if (iotype.eq."DTtwo") then
  if (size(vlist).ne.2) call abort
  WRITE(udfmt,'(A,A,I1,A,I1,A)') '(', 'A', vlist(1),',I', vlist(2), ')'
  WRITE(unit, FMT='(A8,I2)') dtv%name, dtv%age
  if (iostat.ne.0) iomsg = "Fail PWF DTtwo"
endif
if (iotype.eq."DTthree") then
  WRITE(udfmt,'(2A,I2,A,I1,A,I2,A)',iostat=myios) '(', 'A', vlist(1),',I', vlist(2), ',F', vlist(3), '.2)'
  WRITE(unit, FMT=udfmt, IOSTAT=iostat, advance='no') trim(dtv%name), dtv%age, 3.14
  if (iostat.ne.0) iomsg = "Fail PWF DTthree"
endif
if (iotype.eq."LISTDIRECTED") then
  if (size(vlist).ne.0) print *, 55
  if (associated(dtv%next)) then
WRITE(unit, FMT = *) dtv%name, dtv%age, dtv%next
  else
WRITE(unit, FMT = *) dtv%name, dtv%age
  endif
  if (iostat.ne.0) iomsg = "Fail PWF LISTDIRECTED"
endif
if (iotype.eq."NAMELIST") then
  if (size(vlist).ne.0) print *, 59
  iostat=6000
endif
if (associated (dtv%next) .and. (iotype.eq."LISTDIRECTED")) write(unit, fmt = *) dtv%next
  END SUBROUTINE pwf

  RECURSIVE SUBROUTINE prf (dtv,unit,iotype,vlist,iostat,iomsg)
CLASS(person), INTENT(INOUT) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER (LEN=*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: vlist(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER (LEN=*), INTENT(INOUT) :: iomsg
CHARACTER (LEN=30) :: udfmt
INTEGER :: myios
real :: areal
udfmt='(*(g0))'
iomsg = "SUCCESS"
iostat=0
if (iotype.eq."DT") then
  if (size(vlist).ne.0) print *, 36
  if (associated(dtv%next)) then
READ(unit, FMT = '(a20,i2, DT)', IOSTAT=iostat, advance='no') dtv%name, dtv%age, dtv%next
  else
READ(unit, FMT = '(a20,i2)', IOSTAT=iostat, advance='no') dtv%name, dtv%age
  endif
  if (iostat.ne.0) iomsg = "Fail PWF DT"
endif
if (iotype.eq."DTzeroth") then
  if (size(vlist).ne.0) print *, 40
  READ(unit, FMT = '(a,I2)', advance='no') dtv%name, dtv%age
  if (iostat.ne.0) iomsg = "Fail PWF DTzeroth"
endif
if (iotype.eq."DTtwo") then
  if (size(vlist).ne.2) call abort
  WRITE(udfmt,'(A,A,I1,A,I1,A)') '(', 'A', vlist(1),',I', vlist(2), ')'
  READ(unit, FMT='(A8,I2)') dtv%name, dtv%age
  if (iostat.ne.0) iomsg = "Fail PWF DTtwo"
endif
if (iotype.eq."DTthree") then
  WRITE(udfmt,'(2A,I2,A,I1,A,I2,A)',iostat=myios) '(', 'A', vlist(1),',I', vlist(2), ',F', vlist(3), '.2)'
  READ(unit, FMT=udfmt, IOSTAT=iostat, advance='no') dtv%name, dtv%age, areal
  if (iostat.ne.0) iomsg = "Fail PWF DTthree"
endif
if (iotype.eq."LISTDIRECTED") then
  if (size(vlist).ne.0) print *, 55
  READ(unit, FMT = *) dtv%name, dtv%age
  if (iostat.ne.0) iomsg = "Fail PWF LISTDIRECTED"
endif
if (iotype.eq."NAMELIST") then
  if (size(vlist).ne.0) print *, 59
  iostat=6000
endif
!READ (UNIT = UNIT, FMT = *) dtv%name, dtv%age
  END SUBROUTINE prf

END MODULE p

PROGRAM test
  USE p
  TYPE (person) :: chairman
  TYPE (person), target :: member
  character(80) :: astring
  integer :: thelength

  chairman%name="Charlie"
  chairman%age=62
  member%name="George"
  member%age=42
  astring = "FAILURE"
  ! At this point, next is NULL as defined up in the type block.
  open(10, status = "scratch")
  write (10, *, iostat=myiostat, iomsg=astring) member, chairman
  write(10,*)
  rewind(10)
  chairman%name="bogus1"
  chairman%age=99
  member%name="bogus2

[PATCH][ARM] Refactor MOVW/MOVT fusion logic to allow extension

[Kyrill Tkachov]

Hi all,

If we want to add more macro fusion cases in the arm backend we need to rework 
the aarch_macro_fusion_pair_p a bit
to not return early during the MOVW/MOVT fusion checks.  This simple patch does 
that by adding a helper function
that can be called with the two sets to check if they satisfy the fusion logic. 
 There is no change in codegen.

Bootstrapped and tested on arm-none-linux-gnueabihf.

Ok for trunk?
Thanks,
Kyrill

2016-08-23  Kyrylo Tkachov  

* config/arm/arm.c (arm_sets_movw_movt_fusible_p): New function.
(aarch_macro_fusion_pair_p): Use above to avoid early return.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 2deb62b2f724ef9c17f585046480e47abcd341b0..bb6ada9e0f62efae95fdeb11dfcee14dba3299b0 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -29903,11 +29903,57 @@ arm_macro_fusion_p (void)
   return current_tune->fusible_ops != tune_params::FUSE_NOTHING;
 }
 
+/* Return true if the two back-to-back sets PREV_SET, CURR_SET are suitable
+   for MOVW / MOVT macro fusion.  */
+
+static bool
+arm_sets_movw_movt_fusible_p (rtx prev_set, rtx curr_set)
+{
+  /* We are trying to fuse
+ movw imm / movt imm
+instructions as a group that gets scheduled together.  */
+
+  rtx set_dest = SET_DEST (curr_set);
+
+  if (GET_MODE (set_dest) != SImode)
+return false;
+
+  /* We are trying to match:
+ prev (movw)  == (set (reg r0) (const_int imm16))
+ curr (movt) == (set (zero_extract (reg r0)
+	(const_int 16)
+	(const_int 16))
+			  (const_int imm16_1))
+ or
+ prev (movw) == (set (reg r1)
+			  (high (symbol_ref ("SYM"
+curr (movt) == (set (reg r0)
+			(lo_sum (reg r1)
+(symbol_ref ("SYM"  */
+
+if (GET_CODE (set_dest) == ZERO_EXTRACT)
+  {
+	if (CONST_INT_P (SET_SRC (curr_set))
+	&& CONST_INT_P (SET_SRC (prev_set))
+	&& REG_P (XEXP (set_dest, 0))
+	&& REG_P (SET_DEST (prev_set))
+	&& REGNO (XEXP (set_dest, 0)) == REGNO (SET_DEST (prev_set)))
+	  return true;
+
+  }
+else if (GET_CODE (SET_SRC (curr_set)) == LO_SUM
+	 && REG_P (SET_DEST (curr_set))
+	 && REG_P (SET_DEST (prev_set))
+	 && GET_CODE (SET_SRC (prev_set)) == HIGH
+	 && REGNO (SET_DEST (curr_set)) == REGNO (SET_DEST (prev_set)))
+  return true;
+
+  return false;
+}
 
 static bool
 aarch_macro_fusion_pair_p (rtx_insn* prev, rtx_insn* curr)
 {
-  rtx set_dest;
   rtx prev_set = single_set (prev);
   rtx curr_set = single_set (curr);
 
@@ -29925,45 +29971,10 @@ aarch_macro_fusion_pair_p (rtx_insn* prev, rtx_insn* curr)
   && aarch_crypto_can_dual_issue (prev, curr))
 return true;
 
-  if (current_tune->fusible_ops & tune_params::FUSE_MOVW_MOVT)
-{
-  /* We are trying to fuse
-	 movw imm / movt imm
-	 instructions as a group that gets scheduled together.  */
-
-  set_dest = SET_DEST (curr_set);
-
-  if (GET_MODE (set_dest) != SImode)
-	return false;
+  if (current_tune->fusible_ops & tune_params::FUSE_MOVW_MOVT
+  && arm_sets_movw_movt_fusible_p (prev_set, curr_set))
+return true;
 
-  /* We are trying to match:
-	 prev (movw)  == (set (reg r0) (const_int imm16))
-	 curr (movt) == (set (zero_extract (reg r0)
-	  (const_int 16)
-	   (const_int 16))
-			 (const_int imm16_1))
-	 or
-	 prev (movw) == (set (reg r1)
-			  (high (symbol_ref ("SYM"
-	 curr (movt) == (set (reg r0)
-			 (lo_sum (reg r1)
- (symbol_ref ("SYM"  */
-  if (GET_CODE (set_dest) == ZERO_EXTRACT)
-	{
-	  if (CONST_INT_P (SET_SRC (curr_set))
-	  && CONST_INT_P (SET_SRC (prev_set))
-	  && REG_P (XEXP (set_dest, 0))
-	  && REG_P (SET_DEST (prev_set))
-	  && REGNO (XEXP (set_dest, 0)) == REGNO (SET_DEST (prev_set)))
-	return true;
-	}
-  else if (GET_CODE (SET_SRC (curr_set)) == LO_SUM
-	   && REG_P (SET_DEST (curr_set))
-	   && REG_P (SET_DEST (prev_set))
-	   && GET_CODE (SET_SRC (prev_set)) == HIGH
-	   && REGNO (SET_DEST (curr_set)) == REGNO (SET_DEST (prev_set)))
-	 return true;
-}
   return false;
 }
 

Re: Implement -Wimplicit-fallthrough (version 5)

[Martin Sebor]

I'm curious why this function takes the first argument by const
reference when the function above by const pointer.  Is there
a subtle difference between the functions that I'm not seeing?
For that matter, is there a convention in GCC?  (FWIW, my own
rule of thumb is to have a function take a large argument by
const reference when it must be non-null and by pointer
otherwise.)


I admit I don't know what's better, I'd say the reference, but elsewhere in the
codebase I see const *.  I changed case_label_p's vec argument to const * to be
consistent, but I'm all ears if anyone wants to educate me.


There's been lots of debate about this in various C++ communities.
This may be a discussion better had outside of a patch review but
since you asked I'll answer here.

I don't think there is one right answer, but having a convention
in place would be helpful especially to those of us who are not
intimately familiar with the details of every API in the compiler.

One coding style recommends using const references and non-const
pointers (and not the other way around).  The rationale is to
make it possible to tell just by looking at a call to a function
whether it can change an argument.  For example, in:

  SomeType x = /* ... */;
  OtherType y = /* ... */;

  foo (x, &y);

the convention makes it clear that x will be unchanged by the call
to foo but y will most likely not.  This is true whether foo takes
x by value or by const reference.  The downside of this approach
is that the callee has to (or should) either assert the that the
pointer is non-null or handle the null, otherwise it can raises
the question whether it's intended to accept null pointers.

This style is what the Google Coding Style recommends:
https://google.github.io/styleguide/cppguide.html#Reference_Arguments

Marshall Cline's C++ FAQ LITE considers this style old school and
recommends to use references whenever possible:
https://www.cs.rit.edu/~mjh/docs/c++-faq/references.html#faq-8.6

This is also what the C++ Core Guidelines recommend, i.e., to
declare "in arguments" by const reference and "in-out" arguments
by non-const reference:

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-inout


The warnings above use "attribute %" yet the notes here
use "__attribute__ ((fallthrough));"  It seems that using consistent
spelling in all messages would be better (and avoid emphasizing one
spelling of the attribute over others, especially the C++ 17
[[fallthrough]]).


Here I think I'd rather not change things.  I think what I currently have is
fine, because the fixit hints are meants to be verbatim code, the warnings
talk about the attribute more generally.


Understood.  But suggesting __attribute__((fallthrough)) in C++ 17
code guides users toward writing non-portable code.  I think GCC
should recommend a standard solution first, and only suggest
extensions where there is no standard alternative.  One way to do
it would be to issue different hints based on the target standard.
To avoid complicating the code with conditionals the issue can be
circumvented to by using "attribute %" here as well.

FWIW, this seems like another broader topic to have consensus
on and document: GCC messages should be consistent not only in
appearance (quoting, etc.) but also (and I'd say even more
important) in the spelling of alternate language constructs
they suggest.

Martin

[wwwdocs] [PATCH] Add my changes to gcc-7/changes.html

[David Malcolm]

This covers my changes so far for gcc 7,  based on
 git log --author=dmalcolm \
 002c3f2881626f4dea765f89e4a11be1f4bac240..c3e800b980fb13f42468ceeaf723
a39f4cee0f3e

Validates as XHTML 1.0 Transitional.

OK to commit?

(I don't have a working copy of mhc, so I can't easily test the CSS
markup)
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.5
diff -u -p -r1.5 changes.html
--- htdocs/gcc-7/changes.html	23 Aug 2016 22:43:55 -	1.5
+++ htdocs/gcc-7/changes.html	24 Aug 2016 15:25:55 -
@@ -45,11 +45,69 @@ For more information, see the
 
 
 C family
-
 
 C
 
 
 C++
-
 
 Runtime Library (libstdc++)
 
 
 
-
+libgccjit
+The libgccjit API gained support for marking calls as requiring
+tail-call optimization via a new entrypoint:
+https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html#gcc_jit_rvalue_set_bool_require_tail_call";>gcc_jit_rvalue_set_bool_require_tail_call.
+
+libgccjit performs numerous checks at the API boundary, but
+if these succeed, it previously ignored errors and other diagnostics emitted
+within the core of gcc, and treated the compile of a gcc_jit_context
+as having succeeded.  As of gcc 7 it now ensures that if any diagnostics are
+emitted, they are visible from the libgccjit API, and that the the context is
+flagged as having failed.
 
 
 New Targets and Target Specific Improvements
@@ -152,11 +225,84 @@ For more information, see the
 
 
 Other significant improvements
-
 
 

Re: wwwdocs: gcc-7/changes.html

[Kyrill Tkachov]

On 23/08/16 21:54, Gerald Pfeifer wrote:

On Tue, 23 Aug 2016, Segher Boessenkool wrote:

I'm committing the following to wwwdocs as obvious.

Thank you, Segher!  That would have been my late evening program for
today, otherwise. ;-)


Thanks for doing this.
Can we also add a link to this from the main page?
(next to GCC 7.0 before "release criteria").
I'll get around doing it myself in the near future if needed.

Kyrill


Gerald

PS. I did commit a simple patch that de-indents lists, see  below.

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.2
diff -u -r1.2 changes.html
--- changes.html23 Aug 2016 19:27:37 -  1.2
+++ changes.html23 Aug 2016 20:51:25 -
@@ -21,62 +21,62 @@
  
  Caveats
  
  
  

  General Optimizer Improvements
  
  
  

  New Languages and Language specific improvements
  
  
  
  
  C family

  
  
  C

  
  
  C++

  
  
  Runtime Library (libstdc++)

  
  
  Fortran

  
  
  

@@ -142,9 +142,9 @@
  
  Other significant improvements
  
  
  

Re: [PATCH v2 0/9] Separate shrink-wrapping

[Segher Boessenkool]

Ping x2.

On Wed, Aug 03, 2016 at 07:05:34PM -0500, Segher Boessenkool wrote:
> Ping.
> 
> 
> Segher
> 
> 
> On Mon, Aug 01, 2016 at 01:42:37AM +, Segher Boessenkool wrote:
> > This is the second version.  Concern was renamed to component, and all
> > other comments were addressed (I hope).  It still uses only two bitmaps
> > for the component placement, but now they are called needs_components
> > and has_components, which hopefully is easier to follow.  The "can this
> > prologue be moved earlier for no cost" test is generalised a bit, and
> > the cost estimate explicitly excludes backedges, which makes it easier
> > to see that prologues will not be placed inside a loop if there is no
> > benefit to that (I didn't see any different generated code because of
> > this change).  And new and updated comments all over, of course.
> > 
> > Is this okay for trunk?
> > 
> > 
> > Segher
> > 
> > 
> >  gcc/cfgcleanup.c   |   5 +
> >  gcc/common.opt |   4 +
> >  gcc/config/rs6000/rs6000.c | 257 -
> >  gcc/dce.c  |   9 +
> >  gcc/doc/invoke.texi|  11 +-
> >  gcc/doc/tm.texi|  54 
> >  gcc/doc/tm.texi.in |  29 ++
> >  gcc/emit-rtl.h |   4 +
> >  gcc/function.c |  15 +-
> >  gcc/regcprop.c |   4 +
> >  gcc/regrename.c|  13 +-
> >  gcc/sel-sched-ir.c |   1 +
> >  gcc/shrink-wrap.c  | 705 
> > +
> >  gcc/shrink-wrap.h  |   1 +
> >  gcc/target.def |  57 
> >  15 files changed, 1150 insertions(+), 19 deletions(-)
> > 
> > -- 
> > 1.9.3

New Ukrainian PO file for 'gcc' (version 6.2.0)

[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 Ukrainian team of translators.  The file is available at:

http://translationproject.org/latest/gcc/uk.po

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

All other PO files for your package are available in:

http://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:

http://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.

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Martin Sebor]

On 08/23/2016 05:00 PM, Joseph Myers wrote:

Some observations:

* Does -fprintf-return-value allow for the possibility of snprintf failing
because of a memory allocation failure and so returning -1 when GCC
computed bounds on what it could return if successful?


No.  I recall having seen Glibc fail with ENOMEM years ago when
formatting a floating point number to a very large precision but
I haven't seen any implementation fail.  I haven't yet looked to
see if the Glibc failure can still happen.  My reading of C and
POSIX is that snprintf is only allowed to fail due to an encoding
error, not because it runs out of memory, so such a failure would
seem like a bug.

At the same time, the cause of the failure doesn't really matter.
If the function could fail, unless GCC could determine the failure
at compile time and avoid the optimization, the transformation
wouldn't be guaranteed to be safe.  It might be something to
consider and possibly accommodate in the implementation.  It's
one of the reasons why I want to expose the optimization to
more code before enabling it.

I also haven't yet thought about how to deal with it but if it
is a possibility we want to allow for then maybe a target hook
for libc implementers to set to indicate whether sprintf can fail
and when would work.  Libc implementations that can fail under
any conditions (whether allowed by the standard or not) would
need to disable (or not enable, depending on the default) the
optimization.  I'm certainly open to other ideas.


* It looks like you convert to (signed/unsigned) char for %hh formats,
etc.  Now, there is the possibility that the value passed was actually of
type int, and out of range for those types.  And there is the possibility
that the implementation might not itself convert those values to char /
short (glibc didn't until 2006) - passing a value outside the range of the
relevant type seems likely undefined behavior, so implementations may not
actually need to convert, and there's an open question about whether the
value actually needs to have been promoted from char/short in the caller
(see my ).  I don't
know if you wish to allow at all for this issue.


It sounds like the concern is that for the following call (when
UCHAR_MAX is 255):

  sprintf (d, "%hhu", 1000)

some implementation (an old version of Glibc?) may have actually
produced four digits and returned 4 on the basis of C saying that
the %hhu argument must be an unsigned char (promoted to int) and
thus the behavior of the call being undefined.

I wouldn't think this to be the intended interpretation (C11 says
the argument "value shall be converted to signed char or unsigned
char before printing") but if it really was meant to be undefined
then having GCC treat the undefined call differently than libc
shouldn't be a problem.  That said, I've tried not to allow the
optimization for calls with undefined behavior so if there was
a serious concern about this causing trouble I could see about
detecting this case and disabling it.

Martin

Re: [PATCH] disable ifunc on *-musl by default

[Szabolcs Nagy]

On 20/07/16 14:37, Szabolcs Nagy wrote:
> Musl libc does not support gnu ifunc, so disable it by default.
> (not disabled on s390-* since that has no musl support yet.)
> 
> gcc/
> 2016-07-20  Szabolcs Nagy  
> 
>   * config.gcc (*-*-*musl*): Disable gnu-indirect-function.
> 

ping

Re: [PATCH] report supported function classes correctly on *-musl

[Szabolcs Nagy]

On 20/07/16 14:39, Szabolcs Nagy wrote:
> All function classes listed in gcc/coretypes.h are supported by musl.
> 
> Most of the optimizations based on these function classes are not
> relevant for standard conform c code, but this is required to get
> rid of some test system noise.
> 
> gcc/
> 2016-07-20  Szabolcs Nagy  
> 
>   * config/linux.c (linux_libc_has_function): Return true on musl.
> 

ping

Re: [PATCH] check -nopie in configure

[Szabolcs Nagy]

On 20/07/16 14:58, Szabolcs Nagy wrote:
> since gcc can be built with --enable-default-pie, there
> is a -no-pie flag to turn off PIE.
> 
> gcc cannot be built as PIE (pr 71934), so the gcc build
> system has to detect the -no-pie flag to disable PIE.
> 
> historically default pie toolchains used the -nopie flag
> (e.g. gentoo hardened), those toolchains cannot build
> gcc anymore, so detect -nopie too.
> 
> gcc/
> 2016-07-20  Szabolcs Nagy  
> 
>   * configure.ac: Detect -nopie flag just like -no-pie.
>   * configure: Regenerate.
> 

ping

Fix bogus warning with -Wlogical-not-parentheses (PR c/77292)

[Marek Polacek]

The -Wlogical-not-parentheses deliberately doesn't warn when the RHS has
boolean type.  But since in C the type of a comparison is int, we need
to check for tcc_comparison, too.

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

2016-08-24  Marek Polacek  

PR c/77292
* c-common.c (warn_logical_not_parentheses): Don't warn if RHS is
a comparison.

* c-c++-common/Wlogical-not-parentheses-1.c: New test.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 3feb910..47255c3 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -1481,7 +1481,7 @@ warn_tautological_cmp (location_t loc, enum tree_code 
code, tree lhs, tree rhs)
 
 /* Warn about logical not used on the left hand side operand of a comparison.
This function assumes that the LHS is inside of TRUTH_NOT_EXPR.
-   Do not warn if RHS is of a boolean type.  */
+   Do not warn if RHS is of a boolean type, or a comparison.  */
 
 void
 warn_logical_not_parentheses (location_t location, enum tree_code code,
@@ -1489,7 +1489,8 @@ warn_logical_not_parentheses (location_t location, enum 
tree_code code,
 {
   if (TREE_CODE_CLASS (code) != tcc_comparison
   || TREE_TYPE (rhs) == NULL_TREE
-  || TREE_CODE (TREE_TYPE (rhs)) == BOOLEAN_TYPE)
+  || TREE_CODE (TREE_TYPE (rhs)) == BOOLEAN_TYPE
+  || TREE_CODE_CLASS (TREE_CODE (rhs)) == tcc_comparison)
 return;
 
   /* Don't warn for !x == 0 or !y != 0, those are equivalent to
diff --git gcc/testsuite/c-c++-common/Wlogical-not-parentheses-1.c 
gcc/testsuite/c-c++-common/Wlogical-not-parentheses-1.c
index e69de29..4ae9ec2 100644
--- gcc/testsuite/c-c++-common/Wlogical-not-parentheses-1.c
+++ gcc/testsuite/c-c++-common/Wlogical-not-parentheses-1.c
@@ -0,0 +1,18 @@
+/* PR c/77292 */
+/* { dg-do compile } */
+/* { dg-options "-Wlogical-not-parentheses" } */
+
+ /* Test that we don't warn if rhs is a comparison.  */
+
+int
+foo (int a, int b)
+{
+  int r = 0;
+  r += !a == (a < b);
+  r += !a == (a > b);
+  r += !a == (a >= b);
+  r += !a == (a <= b);
+  r += !a == (a != b);
+  r += !a == (a == b);
+  return r;
+}

Marek

Add fixit hint for -Wlogical-not-parentheses

[Marek Polacek]

This patch adds a fixit hint to -Wlogical-not-parentheses.  When the LHS
has a location, it prints:

z.c: In function ‘int foo(int, int)’:
z.c:12:11: warning: logical not is only applied to the left hand side of 
comparison [-Wlogical-not-parentheses]
   r += !a == b;
   ^~
z.c:12:8: note: add parentheses around left hand side expression to silence 
this warning
   r += !a == b;
^~
( )

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

2016-08-24  Marek Polacek  

* c-common.c (warn_logical_not_parentheses): Print fixit hints.
* c-common.h (warn_logical_not_parentheses): Update declaration.

* c-typeck.c (parser_build_binary_op): Pass LHS to
warn_logical_not_parentheses.

* parser.c (cp_parser_binary_expression): Pass LHS to
warn_logical_not_parentheses.

* c-c++-common/Wlogical-not-parentheses-2.c: New test.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 3feb910..a445df1 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -1485,7 +1485,7 @@ warn_tautological_cmp (location_t loc, enum tree_code 
code, tree lhs, tree rhs)
 
 void
 warn_logical_not_parentheses (location_t location, enum tree_code code,
- tree rhs)
+ tree lhs, tree rhs)
 {
   if (TREE_CODE_CLASS (code) != tcc_comparison
   || TREE_TYPE (rhs) == NULL_TREE
@@ -1498,9 +1498,16 @@ warn_logical_not_parentheses (location_t location, enum 
tree_code code,
   && integer_zerop (rhs))
 return;
 
-  warning_at (location, OPT_Wlogical_not_parentheses,
- "logical not is only applied to the left hand side of "
- "comparison");
+  if (warning_at (location, OPT_Wlogical_not_parentheses,
+ "logical not is only applied to the left hand side of "
+ "comparison")
+  && EXPR_HAS_LOCATION (lhs))
+{
+  rich_location richloc (line_table, EXPR_LOCATION (lhs));
+  richloc.add_fixit_insert (EXPR_LOCATION (lhs), "( )");
+  inform_at_rich_loc (&richloc, "add parentheses around left hand side "
+ "expression to silence this warning");
+}
 }
 
 /* Warn if EXP contains any computations whose results are not used.
diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index bc22baa..42ce969 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -847,7 +847,8 @@ extern void overflow_warning (location_t, tree);
 extern bool warn_if_unused_value (const_tree, location_t);
 extern void warn_logical_operator (location_t, enum tree_code, tree,
   enum tree_code, tree, enum tree_code, tree);
-extern void warn_logical_not_parentheses (location_t, enum tree_code, tree);
+extern void warn_logical_not_parentheses (location_t, enum tree_code, tree,
+ tree);
 extern void warn_tautological_cmp (location_t, enum tree_code, tree, tree);
 extern void check_main_parameter_types (tree decl);
 extern bool c_determine_visibility (tree);
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index bc8728a..2f8d611 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -3696,7 +3696,7 @@ parser_build_binary_op (location_t location, enum 
tree_code code,
  while (1);
}
   if (TREE_CODE (TREE_TYPE (t)) != BOOLEAN_TYPE)
-   warn_logical_not_parentheses (location, code, arg2.value);
+   warn_logical_not_parentheses (location, code, arg1.value, arg2.value);
 }
 
   /* Warn about comparisons against string literals, with the exception
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 690e928..d54cf8a 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -8922,7 +8922,7 @@ cp_parser_binary_expression (cp_parser* parser, bool 
cast_p,
  || TREE_TYPE (current.lhs) == NULL_TREE
  || TREE_CODE (TREE_TYPE (current.lhs)) != BOOLEAN_TYPE))
warn_logical_not_parentheses (current.loc, current.tree_type,
- maybe_constant_value (rhs));
+ current.lhs, maybe_constant_value (rhs));
 
   overload = NULL;
 
diff --git gcc/testsuite/c-c++-common/Wlogical-not-parentheses-2.c 
gcc/testsuite/c-c++-common/Wlogical-not-parentheses-2.c
index e69de29..c5c2aac 100644
--- gcc/testsuite/c-c++-common/Wlogical-not-parentheses-2.c
+++ gcc/testsuite/c-c++-common/Wlogical-not-parentheses-2.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-Wlogical-not-parentheses -fdiagnostics-show-caret" } */
+
+ /* Test fixit hints.  */
+
+int
+foo (int a, int b)
+{
+  int r = 0;
+  r += (!a) == b;
+  r += !a == b; /* { dg-warning "logical not is only applied" } */
+/* { dg-begin-multiline-output "" }
+   r += !a == b;
+   ^~
+   r += !a == b;
+^~
+( )
+   { dg-end-multiline-output "" } */
+  return r;
+}

Marek

Re: [RS6000] ABI_V4 ifunc

[Alexander Monakov]

On Wed, 24 Aug 2016, Alan Modra wrote:
> Given a hidden visibility function declaration, the toolchain can say
> that the function is local to the module.  This generally means that a
> call to the function can be direct, ie. doesn't need to go via the PLT
> even in a shared library.  However, ifunc breaks this promise.  GNU
> indirect functions may resolve non-locally, and are implemented by
> always using a PLT call.
> 
> This causes trouble for targets like ppc32 where the -msecure-plt PIC
> PLT call stub needs a valid GOT pointer.  Any call that potentially
> might be to an ifunc therefore requires a GOT pointer, and can't be a
> sibling call (because the GOT pointer on ppc32 is a caller saved reg).

The same issue exists on 32-bit x86: PLT calls require that %ebx holds the
address of GOT (and the sibcall issue arises as well).  I've just confirmed
using a simple testcase that the scenario you describe leads to a runtime error
on i386, and even LD_BIND_NOW=1 doesn't help, as it doesn't trigger early
resolution of ifuncs.

> So unless we require that all ifuncs are declared as ifunc,

(note, that would be impossible with today's GCC because the ifunc attribute
requires designating the resolver, and the resolver cannot be extern -- so
ultimately you cannot declare an extern-ifunc symbol)

> it seems that ppc32 can't assume extern or weak functions are local.

It doesn't seem nice to penalize all normal calls due to this issue. I think a
solution without this cost is possible: have ld synthesize a forwarder function
when it sees a non-plt call to an ifunc symbol. The forwarder can push the GOT
register, load the GOT address, call the ifunc symbol, pop the GOT register and
return. Does this sound right?

HTH.
Alexander

Re: Add fixit hint for -Wlogical-not-parentheses

[David Malcolm]

On Wed, 2016-08-24 at 19:43 +0200, Marek Polacek wrote:
> This patch adds a fixit hint to -Wlogical-not-parentheses.  When the
> LHS
> has a location, it prints:
> 
> z.c: In function ‘int foo(int, int)’:
> z.c:12:11: warning: logical not is only applied to the left hand side
> of comparison [-Wlogical-not-parentheses]
>r += !a == b;
>^~
> z.c:12:8: note: add parentheses around left hand side expression to
> silence this warning
>r += !a == b;
> ^~
> ( )
> 
> Bootstrapped/regtested on x86_64-linux and ppc64le-redhat-linux, ok
> for trunk?

Thanks for writing new fix-it hints.

Can you split this up into two fix-its, one for each parenthesis, at
the appropriate locations?  A single rich_location (and thus
diagnostic)  can contain up to 3 fix-it hints at the moment.  My hope
is that an IDE could, in theory, apply them; right now, the fixit is
effectively saying to make this change:

-   r += !a == b;
+   r += ( )!a == b;

whereas presumably it should be making this change:

-   r += !a == b;
+   r += (!a) == b;

You should be able to access the source end-point of the expression
via:
  get_range_from_loc (line_table, loc).m_finish

Also, when writing testcases that involve -fdiagnostics-show-caret,
please use identifier names that are longer than one character: this
makes it easier to verify that we're using the correct ranges.


> 2016-08-24  Marek Polacek  
> 
>   * c-common.c (warn_logical_not_parentheses): Print fixit hints.
>   * c-common.h (warn_logical_not_parentheses): Update
> declaration.
> 
>   * c-typeck.c (parser_build_binary_op): Pass LHS to
>   warn_logical_not_parentheses.
> 
>   * parser.c (cp_parser_binary_expression): Pass LHS to
>   warn_logical_not_parentheses.
> 
>   * c-c++-common/Wlogical-not-parentheses-2.c: New test.
> 
> diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
> index 3feb910..a445df1 100644
> --- gcc/c-family/c-common.c
> +++ gcc/c-family/c-common.c
> @@ -1485,7 +1485,7 @@ warn_tautological_cmp (location_t loc, enum
> tree_code code, tree lhs, tree rhs)
>  
>  void
>  warn_logical_not_parentheses (location_t location, enum tree_code
> code,
> -   tree rhs)
> +   tree lhs, tree rhs)
>  {
>if (TREE_CODE_CLASS (code) != tcc_comparison
>|| TREE_TYPE (rhs) == NULL_TREE
> @@ -1498,9 +1498,16 @@ warn_logical_not_parentheses (location_t
> location, enum tree_code code,
>&& integer_zerop (rhs))
>  return;
>  
> -  warning_at (location, OPT_Wlogical_not_parentheses,
> -   "logical not is only applied to the left hand side of
> "
> -   "comparison");
> +  if (warning_at (location, OPT_Wlogical_not_parentheses,
> +   "logical not is only applied to the left hand side
> of "
> +   "comparison")
> +  && EXPR_HAS_LOCATION (lhs))
> +{
> +  rich_location richloc (line_table, EXPR_LOCATION (lhs));
> +  richloc.add_fixit_insert (EXPR_LOCATION (lhs), "( )");
> +  inform_at_rich_loc (&richloc, "add parentheses around left
> hand side "
> +   "expression to silence this warning");
> +}
>  }
>  
>  /* Warn if EXP contains any computations whose results are not used.
> diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
> index bc22baa..42ce969 100644
> --- gcc/c-family/c-common.h
> +++ gcc/c-family/c-common.h
> @@ -847,7 +847,8 @@ extern void overflow_warning (location_t, tree);
>  extern bool warn_if_unused_value (const_tree, location_t);
>  extern void warn_logical_operator (location_t, enum tree_code, tree,
>  enum tree_code, tree, enum
> tree_code, tree);
> -extern void warn_logical_not_parentheses (location_t, enum
> tree_code, tree);
> +extern void warn_logical_not_parentheses (location_t, enum
> tree_code, tree,
> +   tree);
>  extern void warn_tautological_cmp (location_t, enum tree_code, tree,
> tree);
>  extern void check_main_parameter_types (tree decl);
>  extern bool c_determine_visibility (tree);
> diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
> index bc8728a..2f8d611 100644
> --- gcc/c/c-typeck.c
> +++ gcc/c/c-typeck.c
> @@ -3696,7 +3696,7 @@ parser_build_binary_op (location_t location,
> enum tree_code code,
> while (1);
>   }
>if (TREE_CODE (TREE_TYPE (t)) != BOOLEAN_TYPE)
> - warn_logical_not_parentheses (location, code, arg2.value);
> + warn_logical_not_parentheses (location, code, arg1.value,
> arg2.value);
>  }
>  
>/* Warn about comparisons against string literals, with the
> exception
> diff --git gcc/cp/parser.c gcc/cp/parser.c
> index 690e928..d54cf8a 100644
> --- gcc/cp/parser.c
> +++ gcc/cp/parser.c
> @@ -8922,7 +8922,7 @@ cp_parser_binary_expression (cp_parser* parser,
> bool cast_p,
> || TREE_TYPE (current.lhs) == NULL_TREE
> || TREE_CODE (TREE_TYPE (current.lhs)) !=
> BOOLEAN_TYPE))
>   warn_logical_not_

Re: Add fixit hint for -Wlogical-not-parentheses

[Marek Polacek]

On Wed, Aug 24, 2016 at 01:57:15PM -0400, David Malcolm wrote:
> On Wed, 2016-08-24 at 19:43 +0200, Marek Polacek wrote:
> > This patch adds a fixit hint to -Wlogical-not-parentheses.  When the
> > LHS
> > has a location, it prints:
> > 
> > z.c: In function ‘int foo(int, int)’:
> > z.c:12:11: warning: logical not is only applied to the left hand side
> > of comparison [-Wlogical-not-parentheses]
> >r += !a == b;
> >^~
> > z.c:12:8: note: add parentheses around left hand side expression to
> > silence this warning
> >r += !a == b;
> > ^~
> > ( )
> > 
> > Bootstrapped/regtested on x86_64-linux and ppc64le-redhat-linux, ok
> > for trunk?
> 
> Thanks for writing new fix-it hints.
> 
> Can you split this up into two fix-its, one for each parenthesis, at
> the appropriate locations?  A single rich_location (and thus
> diagnostic)  can contain up to 3 fix-it hints at the moment.  My hope
> is that an IDE could, in theory, apply them; right now, the fixit is
> effectively saying to make this change:
> 
> -   r += !a == b;
> +   r += ( )!a == b;
> 
> whereas presumably it should be making this change:
> 
> -   r += !a == b;
> +   r += (!a) == b;
 
True.

> You should be able to access the source end-point of the expression
> via:
>   get_range_from_loc (line_table, loc).m_finish
 
I see, thanks.  So like in the below?

> Also, when writing testcases that involve -fdiagnostics-show-caret,
> please use identifier names that are longer than one character: this
> makes it easier to verify that we're using the correct ranges.
 
Done.

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

2016-08-24  Marek Polacek  

* c-common.c (warn_logical_not_parentheses): Print fixit hints.
* c-common.h (warn_logical_not_parentheses): Update declaration.

* c-typeck.c (parser_build_binary_op): Pass LHS to
warn_logical_not_parentheses.

* parser.c (cp_parser_binary_expression): Pass LHS to
warn_logical_not_parentheses.

* c-c++-common/Wlogical-not-parentheses-2.c: New test.

diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 3feb910..1059466 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -1485,7 +1485,7 @@ warn_tautological_cmp (location_t loc, enum tree_code 
code, tree lhs, tree rhs)
 
 void
 warn_logical_not_parentheses (location_t location, enum tree_code code,
- tree rhs)
+ tree lhs, tree rhs)
 {
   if (TREE_CODE_CLASS (code) != tcc_comparison
   || TREE_TYPE (rhs) == NULL_TREE
@@ -1498,9 +1498,18 @@ warn_logical_not_parentheses (location_t location, enum 
tree_code code,
   && integer_zerop (rhs))
 return;
 
-  warning_at (location, OPT_Wlogical_not_parentheses,
- "logical not is only applied to the left hand side of "
- "comparison");
+  if (warning_at (location, OPT_Wlogical_not_parentheses,
+ "logical not is only applied to the left hand side of "
+ "comparison")
+  && EXPR_HAS_LOCATION (lhs))
+{
+  location_t lhs_loc = EXPR_LOCATION (lhs);
+  rich_location richloc (line_table, lhs_loc);
+  richloc.add_fixit_insert (lhs_loc, "(");
+  richloc.add_fixit_insert (get_finish (lhs_loc), ")");
+  inform_at_rich_loc (&richloc, "add parentheses around left hand side "
+ "expression to silence this warning");
+}
 }
 
 /* Warn if EXP contains any computations whose results are not used.
diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index bc22baa..42ce969 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -847,7 +847,8 @@ extern void overflow_warning (location_t, tree);
 extern bool warn_if_unused_value (const_tree, location_t);
 extern void warn_logical_operator (location_t, enum tree_code, tree,
   enum tree_code, tree, enum tree_code, tree);
-extern void warn_logical_not_parentheses (location_t, enum tree_code, tree);
+extern void warn_logical_not_parentheses (location_t, enum tree_code, tree,
+ tree);
 extern void warn_tautological_cmp (location_t, enum tree_code, tree, tree);
 extern void check_main_parameter_types (tree decl);
 extern bool c_determine_visibility (tree);
diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index bc8728a..2f8d611 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -3696,7 +3696,7 @@ parser_build_binary_op (location_t location, enum 
tree_code code,
  while (1);
}
   if (TREE_CODE (TREE_TYPE (t)) != BOOLEAN_TYPE)
-   warn_logical_not_parentheses (location, code, arg2.value);
+   warn_logical_not_parentheses (location, code, arg1.value, arg2.value);
 }
 
   /* Warn about comparisons against string literals, with the exception
diff --git gcc/cp/parser.c gcc/cp/parser.c
index 690e928..d54cf8a 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -8922,7 +8922,7 @@ cp_parser_binary_ex

[PATCH, PR70955] Tag {ms,sysv}_va_list_type_node with {ms,sysv}_abi attribute

[Tom de Vries]

Hi,

in PR70955, ix86_canonical_va_list_type fails to recognize a 
__builtin_ms_va_list that was declared in a TU, because its type doesn't 
have the same main variant as the ms_va_list_type_node initialized in lto1.


This patch fixes the PR by tagging ms_va_list_type_node and 
sysv_va_list_type_node with ms_abi/sysv_abi attributes.


sysv_va_list_type_node is of type array of length one with elemtype 
record, and I ran into trouble with both adding the attribute to the 
array type and the record type, so I ended up adding it to the first 
field type.


Bootstrapped and reg-tested on x86_64.

OK for trunk, 6 branch?

Thanks,
- Tom
Tag {ms,sysv}_va_list_type_node with {ms,sysv}_abi attribute

2016-08-24  Tom de Vries  

	PR lto/70955
	* config/i386/i386.c (ix86_build_builtin_va_list_64): Tag type with
	sysv_abi attribute.
	(ix86_build_builtin_va_list): Tag type with ms_abi attribute.
	(ix86_canonical_va_list_type): Handle sysv_abi and ms_abi attributes.

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

---
 gcc/config/i386/i386.c | 89 +-
 gcc/testsuite/gcc.dg/pr70955.c | 33 
 2 files changed, 61 insertions(+), 61 deletions(-)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 2639c8c..b5a5bd1 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -10518,9 +10518,13 @@ ix86_build_builtin_va_list_64 (void)
   type_decl = build_decl (BUILTINS_LOCATION,
 			  TYPE_DECL, get_identifier ("__va_list_tag"), record);
 
+  tree attr = tree_cons (get_identifier ("sysv_abi"), NULL_TREE, NULL_TREE);
+  tree sysv_unsigned_type_node
+= build_type_attribute_variant (unsigned_type_node, attr);
+
   f_gpr = build_decl (BUILTINS_LOCATION,
 		  FIELD_DECL, get_identifier ("gp_offset"),
-		  unsigned_type_node);
+		  sysv_unsigned_type_node);
   f_fpr = build_decl (BUILTINS_LOCATION,
 		  FIELD_DECL, get_identifier ("fp_offset"),
 		  unsigned_type_node);
@@ -10561,16 +10565,16 @@ ix86_build_builtin_va_list (void)
   if (TARGET_64BIT)
 {
   /* Initialize ABI specific va_list builtin types.  */
-  tree sysv_va_list, ms_va_list;
-
-  sysv_va_list = ix86_build_builtin_va_list_64 ();
-  sysv_va_list_type_node = build_variant_type_copy (sysv_va_list);
+  sysv_va_list_type_node = ix86_build_builtin_va_list_64 ();
 	
   /* For MS_ABI we use plain pointer to argument area.  */
-  ms_va_list = build_pointer_type (char_type_node);
-  ms_va_list_type_node = build_variant_type_copy (ms_va_list);
+  tree char_ptr_type = build_pointer_type (char_type_node);
+  tree attr = tree_cons (get_identifier ("ms_abi"), NULL_TREE, NULL_TREE);
+  ms_va_list_type_node = build_type_attribute_variant (char_ptr_type, attr);
 
-  return (ix86_abi == MS_ABI) ? ms_va_list : sysv_va_list;
+  return ((ix86_abi == MS_ABI)
+	  ? ms_va_list_type_node
+	  : sysv_va_list_type_node);
 }
   else
 {
@@ -48563,8 +48567,6 @@ ix86_fn_abi_va_list (tree fndecl)
 static tree
 ix86_canonical_va_list_type (tree type)
 {
-  tree wtype, htype;
-
   /* Resolve references and pointers to va_list type.  */
   if (TREE_CODE (type) == MEM_REF)
 type = TREE_TYPE (type);
@@ -48573,64 +48575,29 @@ ix86_canonical_va_list_type (tree type)
   else if (POINTER_TYPE_P (type) && TREE_CODE (TREE_TYPE (type)) == ARRAY_TYPE)
 type = TREE_TYPE (type);
 
-  if (TARGET_64BIT && va_list_type_node != NULL_TREE)
+  if (TARGET_64BIT)
 {
-  wtype = va_list_type_node;
-	  gcc_assert (wtype != NULL_TREE);
-  htype = type;
-  if (TREE_CODE (wtype) == ARRAY_TYPE)
-	{
-	  /* If va_list is an array type, the argument may have decayed
-	 to a pointer type, e.g. by being passed to another function.
-	 In that case, unwrap both types so that we can compare the
-	 underlying records.  */
-	  if (TREE_CODE (htype) == ARRAY_TYPE
-	  || POINTER_TYPE_P (htype))
-	{
-	  wtype = TREE_TYPE (wtype);
-	  htype = TREE_TYPE (htype);
-	}
-	}
-  if (TYPE_MAIN_VARIANT (wtype) == TYPE_MAIN_VARIANT (htype))
-	return va_list_type_node;
-  wtype = sysv_va_list_type_node;
-	  gcc_assert (wtype != NULL_TREE);
-  htype = type;
-  if (TREE_CODE (wtype) == ARRAY_TYPE)
-	{
-	  /* If va_list is an array type, the argument may have decayed
-	 to a pointer type, e.g. by being passed to another function.
-	 In that case, unwrap both types so that we can compare the
-	 underlying records.  */
-	  if (TREE_CODE (htype) == ARRAY_TYPE
-	  || POINTER_TYPE_P (htype))
-	{
-	  wtype = TREE_TYPE (wtype);
-	  htype = TREE_TYPE (htype);
-	}
-	}
-  if (TYPE_MAIN_VARIANT (wtype) == TYPE_MAIN_VARIANT (htype))
-	return sysv_va_list_type_node;
-  wtype = ms_va_list_type_node;
-	  gcc_assert (wtype != NULL_TREE);
-  htype = type;
-  if (TREE_CODE (wtype) == ARRAY_TYPE)
+  if (lookup_attribute ("ms_abi", TYPE_ATTRIBUTES (type)))
+	return ms_va_list_type_node;
+
+   

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Florian Weimer]

On 08/24/2016 06:40 PM, Martin Sebor wrote:

On 08/23/2016 05:00 PM, Joseph Myers wrote:

Some observations:

* Does -fprintf-return-value allow for the possibility of snprintf
failing
because of a memory allocation failure and so returning -1 when GCC
computed bounds on what it could return if successful?


No.  I recall having seen Glibc fail with ENOMEM years ago when
formatting a floating point number to a very large precision but
I haven't seen any implementation fail.  I haven't yet looked to
see if the Glibc failure can still happen.  My reading of C and
POSIX is that snprintf is only allowed to fail due to an encoding
error, not because it runs out of memory, so such a failure would
seem like a bug.


It can still happen, and not just for floating point.

#include 

int
main()
{
  printf("%099d\n", 5);
}

valgrind reports:

   total heap usage: 1 allocs, 1 frees, 1,000,031 bytes allocated

We are certainly not proud of this state of affairs, but it is unlikely 
to change anytime soon.


Florian

Re: Add fixit hint for -Wlogical-not-parentheses

[David Malcolm]

On Wed, 2016-08-24 at 20:15 +0200, Marek Polacek wrote:
> On Wed, Aug 24, 2016 at 01:57:15PM -0400, David Malcolm wrote:
> > On Wed, 2016-08-24 at 19:43 +0200, Marek Polacek wrote:
> > > This patch adds a fixit hint to -Wlogical-not-parentheses.  When
> > > the
> > > LHS
> > > has a location, it prints:
> > > 
> > > z.c: In function ‘int foo(int, int)’:
> > > z.c:12:11: warning: logical not is only applied to the left hand
> > > side
> > > of comparison [-Wlogical-not-parentheses]
> > >r += !a == b;
> > >^~
> > > z.c:12:8: note: add parentheses around left hand side expression
> > > to
> > > silence this warning
> > >r += !a == b;
> > > ^~
> > > ( )
> > > 
> > > Bootstrapped/regtested on x86_64-linux and ppc64le-redhat-linux,
> > > ok
> > > for trunk?
> > 
> > Thanks for writing new fix-it hints.
> > 
> > Can you split this up into two fix-its, one for each parenthesis,
> > at
> > the appropriate locations?  A single rich_location (and thus
> > diagnostic)  can contain up to 3 fix-it hints at the moment.  My
> > hope
> > is that an IDE could, in theory, apply them; right now, the fixit
> > is
> > effectively saying to make this change:
> > 
> > -   r += !a == b;
> > +   r += ( )!a == b;
> > 
> > whereas presumably it should be making this change:
> > 
> > -   r += !a == b;
> > +   r += (!a) == b;
>  
> True.
> 
> > You should be able to access the source end-point of the expression
> > via:
> >   get_range_from_loc (line_table, loc).m_finish
>  
> I see, thanks.  So like in the below?

Thanks.  I didn't fully think through my suggestion, sorry.  I think
there's an off-by-one error in the positioning of the closing
parenthesis, though up till now we haven't defined the semantics of
fixits very strongly.

My interpretation is that an insertion fixit happens immediately
*before* the current content of its column.

So given these column numbers:
011
1234567890123456789
  r += !aaa == bbb;

we want to:
(i) insert a '(' immediately before the '! i.e. at column 8 (correct in
the patch), and
(ii) insert a ')' after the "aaa" i.e. immediately before the ' ' after
the "aaa" i.e. at column 12

I tried your patch with my "-fdiagnostics-generate-patch" patch, and
the patch it generated for these fixits was:
--- ../../src/gcc/testsuite/c-c++-common/Wlogical-not-parentheses-2.c
+++ ../../src/gcc/testsuite/c-c++-common/Wlogical-not-parentheses-2.c
@@ -8,7 +8,7 @@
 {
   int r = 0;
   r += (!aaa) == bbb;
-  r += !aaa == bbb; /* { dg-warning "logical not is only applied" } */
+  r += (!aa)a == bbb; /* { dg-warning "logical not is only applied" } */
 /* { dg-begin-multiline-output "" }
r += !aaa == bbb;
  ^~

Note the incorrect:
  (!aa)a
rather than:
  (!aaa)

which is consistent with the interpretation above.

So I think you need to offset that final column by 1, which isn't as
simple as simply adding 1 to the location_t (given packed ranges).

I believe you need something like:

next_loc = linemap_position_for_loc_and_offset (line_table, finish, 1)

I've attached a patch to your patch that does this; with that, the
fixits and
generated patch look like this:


../../src/gcc/testsuite/c-c++-common/Wlogical-not-parentheses-2.c:11:8: note:
add parentheses around left hand side expression to silence this warning
   r += !aaa == bbb; /* { dg-warning "logical not is only applied" } */
^~~~
(   )
--- ../../src/gcc/testsuite/c-c++-common/Wlogical-not-parentheses-2.c
+++ ../../src/gcc/testsuite/c-c++-common/Wlogical-not-parentheses-2.c
@@ -8,7 +8,7 @@
 {
   int r = 0;
   r += (!aaa) == bbb;
-  r += !aaa == bbb; /* { dg-warning "logical not is only applied" } */
+  r += (!aaa) == bbb; /* { dg-warning "logical not is only applied" }
*/
 /* { dg-begin-multiline-output "" }
r += !aaa == bbb;
  ^~

which looks correct to me.


> > Also, when writing testcases that involve -fdiagnostics-show-caret,
> > please use identifier names that are longer than one character:
> > this
> > makes it easier to verify that we're using the correct ranges.
>  
> Done.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2016-08-24  Marek Polacek  
> 
>   * c-common.c (warn_logical_not_parentheses): Print fixit hints.
>   * c-common.h (warn_logical_not_parentheses): Update
> declaration.
> 
>   * c-typeck.c (parser_build_binary_op): Pass LHS to
>   warn_logical_not_parentheses.
> 
>   * parser.c (cp_parser_binary_expression): Pass LHS to
>   warn_logical_not_parentheses.
> 
>   * c-c++-common/Wlogical-not-parentheses-2.c: New test.
> 
> diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
> index 3feb910..1059466 100644
> --- gcc/c-family/c-common.c
> +++ gcc/c-family/c-common.c
> @@ -1485,7 +1485,7 @@ warn_tautological_cmp (location_t loc, enum
> tree_code code, tree lhs, tree rhs)
>  
>  void
>  warn_logical_not_parentheses (location_t location, enum tree_code
> code,
> -   tree rhs)
> +  

[PATCH 0/4][PR 71931] Fix target lib tests --with-build-sysroot

[Szabolcs Nagy]

The dejagnu find_gcc function cannot handle if CC needs extra flags
like --sysroot. So for testing target libraries use the same CC that
was used for building the target libs.

New patch works even if runtest is not invoked from make as discussed
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01320.html

Szabolcs Nagy (4):
  [PR 71931] Fix libatomic tests
  [PR 71931] Fix libgomp tests
  [PR 71931] Fix libitm tests
  [RFC][PR 71931] Fix libvtv tests

 libatomic/configure   |5 +++-
 libatomic/configure.ac|1 +
 libatomic/testsuite/Makefile.am   |2 ++
 libatomic/testsuite/Makefile.in   |   33 -
 libatomic/testsuite/lib/libatomic.exp |5 
 libatomic/testsuite/libatomic-test-support.exp.in |1 +
 libgomp/testsuite/lib/libgomp.exp |3 ++
 libgomp/testsuite/libgomp-test-support.exp.in |2 ++
 libitm/configure  |7 +++--
 libitm/configure.ac   |1 +
 libitm/testsuite/Makefile.am  |2 ++
 libitm/testsuite/Makefile.in  |   33 -
 libitm/testsuite/lib/libitm.exp   |5 
 libitm/testsuite/libitm-test-support.exp.in   |1 +
 libvtv/Makefile.am|4 +--
 libvtv/Makefile.in|4 +--
 libvtv/configure  |3 ++
 libvtv/configure.ac   |1 +
 libvtv/testsuite/Makefile.am  |2 ++
 libvtv/testsuite/Makefile.in  |   33 -
 libvtv/testsuite/lib/libvtv.exp   |5 
 libvtv/testsuite/libvtv-test-support.exp.in   |1 +
 22 files changed, 105 insertions(+), 49 deletions(-)
 create mode 100644 libatomic/testsuite/libatomic-test-support.exp.in
 create mode 100644 libitm/testsuite/libitm-test-support.exp.in
 create mode 100644 libvtv/testsuite/libvtv-test-support.exp.in

-- 
1.7.9.5

[PATCH 1/4][PR 71931] Fix libatomic tests

[Szabolcs Nagy]

Pass build time CC make var down to dejagnu so the sysroot
is set correctly when gcc is built with --with-build-sysroot.

libatomic/
2016-08-24  Szabolcs Nagy  

PR testsuite/71931
* configure.ac: Add AC_CONFIG_FILES.
* configure: Regenerated.
* testuite/Makefile.am: Add rule for libatomic-test-support.exp.
* testuite/Makefile.in: Regenerated.
* testuite/libatomic-test-support.exp.in: New.
* testuite/lib/libatomic.exp (libatomic_init): Use BUILD_CC.

diff --git a/libatomic/configure b/libatomic/configure
index 8526abf..d185e9d 100755
--- a/libatomic/configure
+++ b/libatomic/configure
@@ -9083,7 +9083,7 @@ _LT_EOF
 	if $NM -V 2>&1 | $GREP 'GNU' > /dev/null; then
 	  export_symbols_cmds='$NM -Bpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "W")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
 	else
-	  export_symbols_cmds='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
+	  export_symbols_cmds='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "L")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
 	fi
 	aix_use_runtimelinking=no
 
@@ -15264,6 +15264,8 @@ fi
 
 ac_config_files="$ac_config_files Makefile testsuite/Makefile"
 
+ac_config_files="$ac_config_files testsuite/libatomic-test-support.exp"
+
 cat >confcache <<\_ACEOF
 # This file is a shell script that caches the results of configure
 # tests run on this system so they can be shared between configure
@@ -16312,6 +16314,7 @@ do
 "gstdint.h") CONFIG_COMMANDS="$CONFIG_COMMANDS gstdint.h" ;;
 "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
+"testsuite/libatomic-test-support.exp") CONFIG_FILES="$CONFIG_FILES testsuite/libatomic-test-support.exp" ;;
 
   *) as_fn_error "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
   esac
diff --git a/libatomic/configure.ac b/libatomic/configure.ac
index cf40ea1..7ed2bcc 100644
--- a/libatomic/configure.ac
+++ b/libatomic/configure.ac
@@ -261,4 +261,5 @@ else
 fi
 
 AC_CONFIG_FILES(Makefile testsuite/Makefile)
+AC_CONFIG_FILES(testsuite/libatomic-test-support.exp)
 AC_OUTPUT
diff --git a/libatomic/testsuite/Makefile.am b/libatomic/testsuite/Makefile.am
index 561b7e2..6c5e5fc 100644
--- a/libatomic/testsuite/Makefile.am
+++ b/libatomic/testsuite/Makefile.am
@@ -11,3 +11,5 @@ EXPECT = $(shell if test -f $(top_builddir)/../expect/expect; then \
 _RUNTEST = $(shell if test -f $(top_srcdir)/../dejagnu/runtest; then \
 	 echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 RUNTEST = "$(_RUNTEST) $(AM_RUNTESTFLAGS)"
+
+all-local: libatomic-test-support.exp
diff --git a/libatomic/testsuite/Makefile.in b/libatomic/testsuite/Makefile.in
index 34f83e0..16f28fa 100644
--- a/libatomic/testsuite/Makefile.in
+++ b/libatomic/testsuite/Makefile.in
@@ -52,7 +52,8 @@ build_triplet = @build@
 host_triplet = @host@
 target_triplet = @target@
 subdir = testsuite
-DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/Makefile.am
+DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/Makefile.am \
+	$(srcdir)/libatomic-test-support.exp.in
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
 am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \
 	$(top_srcdir)/../config/depstand.m4 \
@@ -69,7 +70,7 @@ am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
 	$(ACLOCAL_M4)
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/auto-config.h
-CONFIG_CLEAN_FILES =
+CONFIG_CLEAN_FILES = libatomic-test-support.exp
 CONFIG_CLEAN_VPATH_FILES =
 SOURCES =
 am__can_run_installinfo = \
@@ -255,6 +256,8 @@ $(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
 $(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
 	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
 $(am__aclocal_m4_deps):
+libatomic-test-support.exp: $(top_builddir)/config.status $(srcdir)/libatomic-test-support.exp.in
+	cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
 
 mostlyclean-libtool:
 	-rm -f *.lo
@@ -315,7 +318,7 @@ distclean-DEJAGNU:
 check-am: all-am
 	$(MAKE) $(AM_MAKEFLAGS) check-DEJAGNU
 check: check-am
-all-am: Makefile
+all-am: Makefile all-local
 installdirs:
 install: install-am
 install-exec: install-exec-am
@@ -415,19 +418,21 @@ uninstall-am:
 
 .MAKE: check-am install-am install-strip
 
-.PHONY: all all-am check check-DEJAGNU check-am clean clean-generic \
-	clean-libtool distclean distclean-DEJAGNU distclean-generic \
-	distclean-libtool dvi dvi-am html html-am info info-am install \
-	install-am install-data install-data-am install-dvi \
-	install-dvi-am install-exec install-exec-am install-html \
-	install-html-am install-info ins

[PATCH 2/4][PR 71931] Fix libgomp tests

[Szabolcs Nagy]

Pass build time CC make var down to dejagnu so the sysroot
is set correctly when gcc is built with --with-build-sysroot.

Existing libgomp-test-support.exp.in machinery is used.

libgomp/
2016-08-23  Szabolcs Nagy  

PR testsuite/71931
* testuite/libgomp-test-support.exp.in: Add BUILD_CC.
* testuite/lib/libgomp.exp (libgomp_init): Use BUILD_CC.

diff --git a/libgomp/testsuite/lib/libgomp.exp b/libgomp/testsuite/lib/libgomp.exp
index 1cb4991..398ba1f 100644
--- a/libgomp/testsuite/lib/libgomp.exp
+++ b/libgomp/testsuite/lib/libgomp.exp
@@ -85,6 +85,7 @@ proc libgomp_init { args } {
 global ALWAYS_CFLAGS
 global CFLAGS
 global TOOL_EXECUTABLE TOOL_OPTIONS
+global BUILD_CC
 global GCC_UNDER_TEST
 global TESTING_IN_BUILD_TREE
 global target_triplet
@@ -107,6 +108,8 @@ proc libgomp_init { args } {
 if ![info exists GCC_UNDER_TEST] then {
 	if [info exists TOOL_EXECUTABLE] {
 	set GCC_UNDER_TEST $TOOL_EXECUTABLE
+	} elseif [info exists BUILD_CC] {
+	set GCC_UNDER_TEST $BUILD_CC
 	} else {
 	set GCC_UNDER_TEST "[find_gcc]"
 	}
diff --git a/libgomp/testsuite/libgomp-test-support.exp.in b/libgomp/testsuite/libgomp-test-support.exp.in
index 5a724fb..b3cb4c7 100644
--- a/libgomp/testsuite/libgomp-test-support.exp.in
+++ b/libgomp/testsuite/libgomp-test-support.exp.in
@@ -1,3 +1,5 @@
+set BUILD_CC "@CC@"
+
 set cuda_driver_include "@CUDA_DRIVER_INCLUDE@"
 set cuda_driver_lib "@CUDA_DRIVER_LIB@"
 set hsa_runtime_lib "@HSA_RUNTIME_LIB@"

[PATCH 3/4][PR 71931] Fix libitm tests

[Szabolcs Nagy]

Pass build time CC make var down to dejagnu so the sysroot
is set correctly when gcc is built with --with-build-sysroot.

libitm/
2016-08-24  Szabolcs Nagy  

PR testsuite/71931
* configure.ac: Add AC_CONFIG_FILES.
* configure: Regenerated.
* testuite/Makefile.am: Add rule for libitm-test-support.exp.
* testuite/Makefile.in: Regenerated.
* testuite/libitm-test-support.exp.in: New.
* testuite/lib/libitm.exp (libitm_init): Use BUILD_CC.

diff --git a/libitm/configure b/libitm/configure
index 55332bb..09fd041 100644
--- a/libitm/configure
+++ b/libitm/configure
@@ -9762,7 +9762,7 @@ _LT_EOF
 	if $NM -V 2>&1 | $GREP 'GNU' > /dev/null; then
 	  export_symbols_cmds='$NM -Bpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "W")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
 	else
-	  export_symbols_cmds='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
+	  export_symbols_cmds='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "L")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
 	fi
 	aix_use_runtimelinking=no
 
@@ -14248,7 +14248,7 @@ $as_echo_n "checking whether the $compiler linker ($LD) supports shared librarie
 if $NM -V 2>&1 | $GREP 'GNU' > /dev/null; then
   export_symbols_cmds_CXX='$NM -Bpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "W")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
 else
-  export_symbols_cmds_CXX='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
+  export_symbols_cmds_CXX='$NM -BCpg $libobjs $convenience | awk '\''{ if (((\$ 2 == "T") || (\$ 2 == "D") || (\$ 2 == "B") || (\$ 2 == "L")) && (substr(\$ 3,1,1) != ".")) { print \$ 3 } }'\'' | sort -u > $export_symbols'
 fi
 ;;
   pw32*)
@@ -17638,6 +17638,8 @@ fi
 
 ac_config_files="$ac_config_files Makefile testsuite/Makefile libitm.spec"
 
+ac_config_files="$ac_config_files testsuite/libitm-test-support.exp"
+
 cat >confcache <<\_ACEOF
 # This file is a shell script that caches the results of configure
 # tests run on this system so they can be shared between configure
@@ -18799,6 +18801,7 @@ do
 "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
 "libitm.spec") CONFIG_FILES="$CONFIG_FILES libitm.spec" ;;
+"testsuite/libitm-test-support.exp") CONFIG_FILES="$CONFIG_FILES testsuite/libitm-test-support.exp" ;;
 
   *) as_fn_error "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
   esac
diff --git a/libitm/configure.ac b/libitm/configure.ac
index 3875aa0..70ce8dc 100644
--- a/libitm/configure.ac
+++ b/libitm/configure.ac
@@ -287,4 +287,5 @@ AM_CONDITIONAL([ARCH_X86_AVX], [test "$libitm_cv_as_avx" = yes])
 AM_CONDITIONAL([ARCH_FUTEX], [test $enable_linux_futex = yes])
 
 AC_CONFIG_FILES(Makefile testsuite/Makefile libitm.spec)
+AC_CONFIG_FILES(testsuite/libitm-test-support.exp)
 AC_OUTPUT
diff --git a/libitm/testsuite/Makefile.am b/libitm/testsuite/Makefile.am
index 561b7e2..688d48f 100644
--- a/libitm/testsuite/Makefile.am
+++ b/libitm/testsuite/Makefile.am
@@ -11,3 +11,5 @@ EXPECT = $(shell if test -f $(top_builddir)/../expect/expect; then \
 _RUNTEST = $(shell if test -f $(top_srcdir)/../dejagnu/runtest; then \
 	 echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 RUNTEST = "$(_RUNTEST) $(AM_RUNTESTFLAGS)"
+
+all-local: libitm-test-support.exp
diff --git a/libitm/testsuite/Makefile.in b/libitm/testsuite/Makefile.in
index 4d79781..8b7bc8e 100644
--- a/libitm/testsuite/Makefile.in
+++ b/libitm/testsuite/Makefile.in
@@ -52,7 +52,8 @@ build_triplet = @build@
 host_triplet = @host@
 target_triplet = @target@
 subdir = testsuite
-DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/Makefile.am
+DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/Makefile.am \
+	$(srcdir)/libitm-test-support.exp.in
 ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
 am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \
 	$(top_srcdir)/../config/asmcfi.m4 \
@@ -74,7 +75,7 @@ am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
 	$(ACLOCAL_M4)
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/config.h
-CONFIG_CLEAN_FILES =
+CONFIG_CLEAN_FILES = libitm-test-support.exp
 CONFIG_CLEAN_VPATH_FILES =
 SOURCES =
 am__can_run_installinfo = \
@@ -265,6 +266,8 @@ $(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
 $(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
 	cd $(top_builddir) && $(MAKE) $(AM_M

[PATCH][mips] Fix linux header use in libgcc

[Szabolcs Nagy]

gcc should use libc headers, not kernel headers.

libgcc/
2016-08-24  Szabolcs Nagy  

* config/mips/linux-unwind.h: Use sys/syscall.h.
diff --git a/libgcc/config/mips/linux-unwind.h b/libgcc/config/mips/linux-unwind.h
index bf12de5..4035c121 100644
--- a/libgcc/config/mips/linux-unwind.h
+++ b/libgcc/config/mips/linux-unwind.h
@@ -27,7 +27,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
state data appropriately.  See unwind-dw2.c for the structs.  */
 
 #include 
-#include 
+#include 
 
 /* The third parameter to the signal handler points to something with
  * this structure defined in asm/ucontext.h, but the name clashes with

[PATCH][mips] Add support for mips*r6-*-musl

[Szabolcs Nagy]

Add the musl dynamic linker names for mips r6.

It seems DRIVER_SELF_SPECS sets the default mips isa
(MIPS_DEFAULT_ISA_LEVEL_SPEC) on *-mti-linux* or *-mti-elf,
but not on gnu linux targets (see config/mips/mti-linux.h vs
config/mips/gnu-user.h).

Is that ok? It seems broken, but i didn't try to fix that.
If the toolchain is configured with mipsisa32r6-linux-musl
the dynlinker name is wrong unless one explicitly passes
-mips32r6 to gcc (same for the assembler and linker: they
don't get -mips32r6 by default).

gcc/
2016-08-24  Szabolcs Nagy  

* config/mips/linux.h (MUSL_DYNAMIC_LINKER32): Update.
(MUSL_DYNAMIC_LINKER64, MUSL_DYNAMIC_LINKERN32): Update.

diff --git a/gcc/config/mips/linux.h b/gcc/config/mips/linux.h
index fa253b6..2d79715 100644
--- a/gcc/config/mips/linux.h
+++ b/gcc/config/mips/linux.h
@@ -38,10 +38,13 @@ along with GCC; see the file COPYING3.  If not see
   "%{mnan=2008:/lib32/ld-uClibc-mipsn8.so.0;:/lib32/ld-uClibc.so.0}"
 
 #undef MUSL_DYNAMIC_LINKER32
-#define MUSL_DYNAMIC_LINKER32 "/lib/ld-musl-mips%{EL:el}%{msoft-float:-sf}.so.1"
+#define MUSL_DYNAMIC_LINKER32 \
+  "/lib/ld-musl-mips%{mips32r6:r6}%{EL:el}%{msoft-float:-sf}.so.1"
 #undef MUSL_DYNAMIC_LINKER64
-#define MUSL_DYNAMIC_LINKER64 "/lib/ld-musl-mips64%{EL:el}%{msoft-float:-sf}.so.1"
-#define MUSL_DYNAMIC_LINKERN32 "/lib/ld-musl-mipsn32%{EL:el}%{msoft-float:-sf}.so.1"
+#define MUSL_DYNAMIC_LINKER64 \
+  "/lib/ld-musl-mips64%{mips64r6:r6}%{EL:el}%{msoft-float:-sf}.so.1"
+#define MUSL_DYNAMIC_LINKERN32 \
+  "/lib/ld-musl-mipsn32%{mips64r6:r6}%{EL:el}%{msoft-float:-sf}.so.1"
 
 #define BIONIC_DYNAMIC_LINKERN32 "/system/bin/linker32"
 #define GNU_USER_DYNAMIC_LINKERN32 \

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Martin Sebor]

On 08/24/2016 12:54 PM, Florian Weimer wrote:

On 08/24/2016 06:40 PM, Martin Sebor wrote:

On 08/23/2016 05:00 PM, Joseph Myers wrote:

Some observations:

* Does -fprintf-return-value allow for the possibility of snprintf
failing
because of a memory allocation failure and so returning -1 when GCC
computed bounds on what it could return if successful?


No.  I recall having seen Glibc fail with ENOMEM years ago when
formatting a floating point number to a very large precision but
I haven't seen any implementation fail.  I haven't yet looked to
see if the Glibc failure can still happen.  My reading of C and
POSIX is that snprintf is only allowed to fail due to an encoding
error, not because it runs out of memory, so such a failure would
seem like a bug.


It can still happen, and not just for floating point.

#include 

int
main()
{
   printf("%099d\n", 5);
}

valgrind reports:

total heap usage: 1 allocs, 1 frees, 1,000,031 bytes allocated


Thanks for the information (even though that's not the news I was
hoping for).  Is there a way to determine from the format string
whether the allocation will happen?  Does it just happen with
output beyond some length, for example?

Martin

Re: [Patch, fortran] pr77358 - [F08] deferred-length character function returns zero-length string

[Paul Richard Thomas]

Dear Tobias,

Committed to trunk as revision 239740. 6-branch to follow.

Thanks for the review.

Best regards

Paul

Re: [Patch, fortran] pr77358 - [F08] deferred-length character function returns zero-length string

[Paul Richard Thomas]

...and to 6-branch as revision 239741.

Cheers

Paul

On 24 August 2016 at 21:41, Paul Richard Thomas
 wrote:
> Dear Tobias,
>
> Committed to trunk as revision 239740. 6-branch to follow.
>
> Thanks for the review.
>
> Best regards
>
> Paul



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

Re: [Patch, libstdc++/77356] Support escape in regex bracket expression

[Tim Shen]

On Wed, Aug 24, 2016 at 1:41 AM, Jonathan Wakely  wrote:
> On 24/08/16 00:18 -0700, Tim Shen wrote:
>>
>> I didn't realized that we can actually escape a dash inside bracket
>> expression: R"([\-])", in which case the dash should be treated
>> literally.
>
>
> With this patch applied I no longer get a match for:
>
>  regex_match("-", std::regex{"[a-]", std::regex_constants::basic})

Nice catch. I'm surprised that there is no test for it. Added one.

> I wonder if we want to give _S_token_unknown an initializer with a
> specific value, so it doesn't change whenever we add new tokens.
>
> If we use -1 it would change the underlying type of
> _ScannerBase::_TokenT from unsigned int to signed int, so we should
> give it a fixed type too:
>
>  struct _ScannerBase
>  {
>  public:
>/// Token types returned from the scanner.
>enum _TokenT : unsigned
>{
>  ...
>  _S_token_unknown = -1u

Done.


-- 
Regards,
Tim Shen
commit 4d35cb02470ae73560df67fd7d1c2d901304cbf3
Author: Tim Shen 
Date:   Wed Aug 24 12:43:22 2016 -0700

2016-08-24  Tim Shen  

PR libstdc++/77356
* include/bits/regex_compiler.tcc(_M_insert_bracket_matcher,
_M_expression_term): Modify to support dash literal.
* include/bits/regex_scanner.h: Add dash as a token type to make
a different from the mandated dash literal by escaping.
* include/bits/regex_scanner.tcc(_M_scan_in_bracket): Emit dash
token in bracket expression parsing.
* testsuite/28_regex/regression.cc: Add new testcases.

diff --git a/libstdc++-v3/include/bits/regex_compiler.tcc 
b/libstdc++-v3/include/bits/regex_compiler.tcc
index ff69e16..ef6ebdd 100644
--- a/libstdc++-v3/include/bits/regex_compiler.tcc
+++ b/libstdc++-v3/include/bits/regex_compiler.tcc
@@ -426,13 +426,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   pair __last_char; // Optional<_CharT>
   __last_char.first = false;
   if (!(_M_flags & regex_constants::ECMAScript))
-   if (_M_try_char())
- {
-   __matcher._M_add_char(_M_value[0]);
-   __last_char.first = true;
-   __last_char.second = _M_value[0];
- }
+   {
+ if (_M_try_char())
+   {
+ __last_char.first = true;
+ __last_char.second = _M_value[0];
+   }
+ else if (_M_match_token(_ScannerT::_S_token_bracket_dash))
+   {
+ __last_char.first = true;
+ __last_char.second = '-';
+   }
+   }
   while (_M_expression_term(__last_char, __matcher));
+  if (__last_char.first)
+   __matcher._M_add_char(__last_char.second);
   __matcher._M_ready();
   _M_stack.push(_StateSeqT(
  *_M_nfa,
@@ -449,19 +457,43 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   if (_M_match_token(_ScannerT::_S_token_bracket_end))
return false;
 
+  const auto __push_char = [&](_CharT __ch)
+  {
+   if (__last_char.first)
+ __matcher._M_add_char(__last_char.second);
+   else
+ __last_char.first = true;
+   __last_char.second = __ch;
+  };
+  const auto __flush = [&]
+  {
+   if (__last_char.first)
+ {
+   __matcher._M_add_char(__last_char.second);
+   __last_char.first = false;
+ }
+  };
+
   if (_M_match_token(_ScannerT::_S_token_collsymbol))
{
  auto __symbol = __matcher._M_add_collate_element(_M_value);
  if (__symbol.size() == 1)
-   {
- __last_char.first = true;
- __last_char.second = __symbol[0];
-   }
+   __push_char(__symbol[0]);
+ else
+   __flush();
}
   else if (_M_match_token(_ScannerT::_S_token_equiv_class_name))
-   __matcher._M_add_equivalence_class(_M_value);
+   {
+ __flush();
+ __matcher._M_add_equivalence_class(_M_value);
+   }
   else if (_M_match_token(_ScannerT::_S_token_char_class_name))
-   __matcher._M_add_character_class(_M_value, false);
+   {
+ __flush();
+ __matcher._M_add_character_class(_M_value, false);
+   }
+  else if (_M_try_char())
+   __push_char(_M_value[0]);
   // POSIX doesn't allow '-' as a start-range char (say [a-z--0]),
   // except when the '-' is the first or last character in the bracket
   // expression ([--0]). ECMAScript treats all '-' after a range as a
@@ -472,55 +504,55 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // Clang (3.5) always uses ECMAScript style even in its POSIX syntax.
   //
   // It turns out that no one reads BNFs ;)
-  else if (_M_try_char())
+  else if (_M_match_token(_ScannerT::_S_token_bracket_dash))
{
  if (!__last_char.first)
{
- __matcher._M_add_char(_M_value[0]);
- if (_M_value[0] == '-'
- && !(_M_flags & regex_constants::ECMAScript))
+ if (!(_M_flags & regex_constants::ECMAScript))
  

Re: Add fixit hint for -Wlogical-not-parentheses

[Marek Polacek]

On Wed, Aug 24, 2016 at 02:59:43PM -0400, David Malcolm wrote:
> On Wed, 2016-08-24 at 20:15 +0200, Marek Polacek wrote:
> > On Wed, Aug 24, 2016 at 01:57:15PM -0400, David Malcolm wrote:
> > > On Wed, 2016-08-24 at 19:43 +0200, Marek Polacek wrote:
> > > > This patch adds a fixit hint to -Wlogical-not-parentheses.  When
> > > > the
> > > > LHS
> > > > has a location, it prints:
> > > > 
> > > > z.c: In function ‘int foo(int, int)’:
> > > > z.c:12:11: warning: logical not is only applied to the left hand
> > > > side
> > > > of comparison [-Wlogical-not-parentheses]
> > > >r += !a == b;
> > > >^~
> > > > z.c:12:8: note: add parentheses around left hand side expression
> > > > to
> > > > silence this warning
> > > >r += !a == b;
> > > > ^~
> > > > ( )
> > > > 
> > > > Bootstrapped/regtested on x86_64-linux and ppc64le-redhat-linux,
> > > > ok
> > > > for trunk?
> > > 
> > > Thanks for writing new fix-it hints.
> > > 
> > > Can you split this up into two fix-its, one for each parenthesis,
> > > at
> > > the appropriate locations?  A single rich_location (and thus
> > > diagnostic)  can contain up to 3 fix-it hints at the moment.  My
> > > hope
> > > is that an IDE could, in theory, apply them; right now, the fixit
> > > is
> > > effectively saying to make this change:
> > > 
> > > -   r += !a == b;
> > > +   r += ( )!a == b;
> > > 
> > > whereas presumably it should be making this change:
> > > 
> > > -   r += !a == b;
> > > +   r += (!a) == b;
> >  
> > True.
> > 
> > > You should be able to access the source end-point of the expression
> > > via:
> > >   get_range_from_loc (line_table, loc).m_finish
> >  
> > I see, thanks.  So like in the below?
> 
> Thanks.  I didn't fully think through my suggestion, sorry.  I think
> there's an off-by-one error in the positioning of the closing
> parenthesis, though up till now we haven't defined the semantics of
> fixits very strongly.
> 
> My interpretation is that an insertion fixit happens immediately
> *before* the current content of its column.
> 
> So given these column numbers:
> 011
> 1234567890123456789
>   r += !aaa == bbb;
> 
> we want to:
> (i) insert a '(' immediately before the '! i.e. at column 8 (correct in
> the patch), and
> (ii) insert a ')' after the "aaa" i.e. immediately before the ' ' after
> the "aaa" i.e. at column 12
> 
> I tried your patch with my "-fdiagnostics-generate-patch" patch, and
> the patch it generated for these fixits was:
> --- ../../src/gcc/testsuite/c-c++-common/Wlogical-not-parentheses-2.c
> +++ ../../src/gcc/testsuite/c-c++-common/Wlogical-not-parentheses-2.c
> @@ -8,7 +8,7 @@
>  {
>int r = 0;
>r += (!aaa) == bbb;
> -  r += !aaa == bbb; /* { dg-warning "logical not is only applied" } */
> +  r += (!aa)a == bbb; /* { dg-warning "logical not is only applied" } */
>  /* { dg-begin-multiline-output "" }
> r += !aaa == bbb;
>   ^~
> 
> Note the incorrect:
>   (!aa)a
> rather than:
>   (!aaa)
> 
> which is consistent with the interpretation above.
> 
> So I think you need to offset that final column by 1, which isn't as
> simple as simply adding 1 to the location_t (given packed ranges).
> 
> I believe you need something like:
> 
> next_loc = linemap_position_for_loc_and_offset (line_table, finish, 1)
> 
> I've attached a patch to your patch that does this; with that, the
> fixits and
> generated patch look like this:

Makes sense, thanks.  Before I post another patch, should I introduce
a helper for this, something like get_one_past_finish or somesuch?

Marek

Re: Add fixit hint for -Wlogical-not-parentheses

[David Malcolm]

On Wed, 2016-08-24 at 21:50 +0200, Marek Polacek wrote:
> On Wed, Aug 24, 2016 at 02:59:43PM -0400, David Malcolm wrote:
> > On Wed, 2016-08-24 at 20:15 +0200, Marek Polacek wrote:
> > > On Wed, Aug 24, 2016 at 01:57:15PM -0400, David Malcolm wrote:
> > > > On Wed, 2016-08-24 at 19:43 +0200, Marek Polacek wrote:
> > > > > This patch adds a fixit hint to -Wlogical-not-parentheses. 
> > > > >  When
> > > > > the
> > > > > LHS
> > > > > has a location, it prints:
> > > > > 
> > > > > z.c: In function ‘int foo(int, int)’:
> > > > > z.c:12:11: warning: logical not is only applied to the left
> > > > > hand
> > > > > side
> > > > > of comparison [-Wlogical-not-parentheses]
> > > > >r += !a == b;
> > > > >^~
> > > > > z.c:12:8: note: add parentheses around left hand side
> > > > > expression
> > > > > to
> > > > > silence this warning
> > > > >r += !a == b;
> > > > > ^~
> > > > > ( )
> > > > > 
> > > > > Bootstrapped/regtested on x86_64-linux and ppc64le-redhat
> > > > > -linux,
> > > > > ok
> > > > > for trunk?
> > > > 
> > > > Thanks for writing new fix-it hints.
> > > > 
> > > > Can you split this up into two fix-its, one for each
> > > > parenthesis,
> > > > at
> > > > the appropriate locations?  A single rich_location (and thus
> > > > diagnostic)  can contain up to 3 fix-it hints at the moment. 
> > > >  My
> > > > hope
> > > > is that an IDE could, in theory, apply them; right now, the
> > > > fixit
> > > > is
> > > > effectively saying to make this change:
> > > > 
> > > > -   r += !a == b;
> > > > +   r += ( )!a == b;
> > > > 
> > > > whereas presumably it should be making this change:
> > > > 
> > > > -   r += !a == b;
> > > > +   r += (!a) == b;
> > >  
> > > True.
> > > 
> > > > You should be able to access the source end-point of the
> > > > expression
> > > > via:
> > > >   get_range_from_loc (line_table, loc).m_finish
> > >  
> > > I see, thanks.  So like in the below?
> > 
> > Thanks.  I didn't fully think through my suggestion, sorry.  I
> > think
> > there's an off-by-one error in the positioning of the closing
> > parenthesis, though up till now we haven't defined the semantics of
> > fixits very strongly.
> > 
> > My interpretation is that an insertion fixit happens immediately
> > *before* the current content of its column.
> > 
> > So given these column numbers:
> > 011
> > 1234567890123456789
> >   r += !aaa == bbb;
> > 
> > we want to:
> > (i) insert a '(' immediately before the '! i.e. at column 8
> > (correct in
> > the patch), and
> > (ii) insert a ')' after the "aaa" i.e. immediately before the ' '
> > after
> > the "aaa" i.e. at column 12
> > 
> > I tried your patch with my "-fdiagnostics-generate-patch" patch,
> > and
> > the patch it generated for these fixits was:
> > --- ../../src/gcc/testsuite/c-c++-common/Wlogical-not-parentheses
> > -2.c
> > +++ ../../src/gcc/testsuite/c-c++-common/Wlogical-not-parentheses
> > -2.c
> > @@ -8,7 +8,7 @@
> >  {
> >int r = 0;
> >r += (!aaa) == bbb;
> > -  r += !aaa == bbb; /* { dg-warning "logical not is only applied"
> > } */
> > +  r += (!aa)a == bbb; /* { dg-warning "logical not is only
> > applied" } */
> >  /* { dg-begin-multiline-output "" }
> > r += !aaa == bbb;
> >   ^~
> > 
> > Note the incorrect:
> >   (!aa)a
> > rather than:
> >   (!aaa)
> > 
> > which is consistent with the interpretation above.
> > 
> > So I think you need to offset that final column by 1, which isn't
> > as
> > simple as simply adding 1 to the location_t (given packed ranges).
> > 
> > I believe you need something like:
> > 
> > next_loc = linemap_position_for_loc_and_offset (line_table, finish,
> > 1)
> > 
> > I've attached a patch to your patch that does this; with that, the
> > fixits and
> > generated patch look like this:
> 
> Makes sense, thanks.  Before I post another patch, should I introduce
> a helper for this, something like get_one_past_finish or somesuch?

I was thinking about maybe:
  rich_location::add_fixit_insert_after_caret (source_location loc)
which would add it immediately after the *caret* location of loc - as
opposed to after the *finish* location of loc, or maybe just:
  rich_location::add_fixit_insert_after (source_location loc)
which
would take into account the finish location of loc.

Having a helper in rich_location for this would be good, for protecting against 
cases where some of the tokens are in a macro expansion, and others aren't (I 
think fix-its within a rich_location ought to be atomic: if some can't be 
applied, none should be).  I'd rather have the rich_location machinery care 
about these awkward issues in one place, rather than force every diagnostic to 
do it.

I already have the beginnings of some fixit validation code written (but not 
posted), so maybe you should go ahead and post the patch as-is, and we can move 
the relevant parts into a helper as a followup?

Dave

Re: [PATCH] check -nopie in configure

[Magnus Granberg]

onsdag 24 augusti 2016 kl. 18:21:07 CEST skrev  Szabolcs Nagy:
> On 20/07/16 14:58, Szabolcs Nagy wrote:
> > since gcc can be built with --enable-default-pie, there
> > is a -no-pie flag to turn off PIE.
> > 
> > gcc cannot be built as PIE (pr 71934), so the gcc build
> > system has to detect the -no-pie flag to disable PIE.
> > 
> > historically default pie toolchains used the -nopie flag
> > (e.g. gentoo hardened), those toolchains cannot build
> > gcc anymore, so detect -nopie too.
> > 
> > gcc/
> > 2016-07-20  Szabolcs Nagy  
> > 
> > * configure.ac: Detect -nopie flag just like -no-pie.
> > * configure: Regenerate.
> 
> ping

On Gentoo Hardened we are moving to use -no-pie to disable the linking part 
for both gcc and ld/gold support it. -nopie was not supported by upstream.
To disable PIE when compile -fno-PIE should be just.
The compile and link part is disable when building gcc, look in the Makefile.

/Magnus G.

[PATCH, Fortran] Fix compare logic for anonymous structure types

[Fritz Reese]

With a few recent notes by others, I have identified that the
comparison logic I used in interface.c (compare_components,
gfc_compare_derived_types) was faulty in a few ways. I apologize in
advance for the length of this message, but I believe it will help
others (and myself) understand (recall) more thoroughly my internal
implementation of structures, unions, and maps which may have not be
obvious just by staring at hundreds of lines of code. Feel free to
skip to the end where you'll find the small patch which reorganizes
this section of code for clarity and correctness.



The goal of the aforementioned sections of code is to allow
gfc_compare_derived_types (and gfc_compare_union_types) to determine
when two type definitions are equal. For STRUCTUREs, as with derived
types with the SEQUENCE attribute, the type definitions can be
considered the same if their declarations are identical. With derived
types, this is easy enough. For STRUCTUREs however, we have several
constructs which induce the creation of both structure type
definitions and components with no user-defined names. I refer to
these as anonymous structures and anonymous components.

One of the checks originally performed by gfc_compare_derived_types is
to compare the names of both type definitions and components. Clearly,
this is insufficient for anonymous elements. Consider the following
definition of a structure containing a union and an anonymous
("ad-hoc") structure definition:

STRUCTURE /s/
  integer x
  UNION
MAP
  integer y
END MAP
  END UNION
  STRUCTURE sub
real r
  END STUCTURE
END STRUCTURE

Internally, this has to create four separate type definitions. One for
the containing structure ("s"), one for the union, one for the map
within the union, and one for the anonymous sub-structure (in the
sub-structure, the type itself has no name - "sub" is the name of the
component which has the anonymous type). The outer structure, the map,
and the anonymous inner structure all get FL_STRUCT gfc_symbols and
the union gets an FL_UNION gfc_symbol. Furthermore several
gfc_components are created: s contains one for x, one for the union,
and one for sub; the type definition of sub contains one for r; the
union contains one for the map; and the map contains one for y. Since
there is no way for the user to name some of these elements, some
components and thier type definitions are "anonymous", and must be
given unambiguous internal names.

In the case of anonymous structure components, I have chosen to store
the second letter of the type definition symbol as uppercase. As with
regular derived type definitions, the first letter is also uppercase.
In the case of the anonymous union and map components, the component
names themselves start with a lowercase letter and the second letter
is uppercase. These names are unambiguous because Fortran is
case-insensitive and all names from user source are stored as
lowercase.

As a result, even when the above structure definition appears in
multiple places identically in source code, the compiler will generate
unique internal names for each union, map, and anonymous structure
definition because it cannot know immediately upon parsing whether
they match. In the case of derived types, components with different
names are clearly distinct. But in the case of structures, to properly
consider unions and maps we must go deeper and compare all the
sub-components. The same structure above declared in multiple places
should be considered equal, as with derived types with the SEQUENCE
attribute. This is the reason we need to bypass the name check in
gfc_compare_derived_types and compare_components.

One issue fixed by this patch is PR 77327, where I greedily started
checking properties of the components' derived type symbol, even
before I knew it was a derived type. In the following code you can see
the unprotected access to cmp1->ts.u.derived before confirming
cmp1->ts.type:

> compare_components (gfc_component *cmp1, gfc_component *cmp2,
(snip)
>   d1 = cmp1->ts.u.derived;
>   d2 = cmp2->ts.u.derived;
>   if (   (d1 && (d1->attr.flavor == FL_STRUCT || d1->attr.flavor == FL_UNION)
(snip)

The other issue fixed is in the anonymous name checking logic at the
top of gfc_compare_derived_types. The bug is exhibited by the attached
testcase wherein extra errors/warnings are erroneously generated for
identical structure definitions. As I described above, the first and
second characters of anonymous structure types are uppercase, and only
if the symbol is FL_UNION or FL_STRUCT. Unfortunately, for whatever
reason, the current code checks the third character via
derived2->name[2]:

> gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol *derived2)
(snip)
>   anonymous = (derived1->name[0] == derived2->name[0]
>   && derived1->name[1] && derived2->name[1] && derived2->name[2]
>   && derived1->name[1] == (char) TOUPPER (derived1->name[0])
>   && derived2->name[2] == (char) TOUPPER (derived2->name[0]))

Re: [PATCH, Fortran] Fix compare logic for anonymous structure types

[Fritz Reese]

https://gcc.gnu.org/ml/fortran/2016-08/msg00144.html

On Wed, Aug 24, 2016 at 5:14 PM, Fritz Reese  wrote:
> With a few recent notes by others, I have identified that the
> comparison logic I used in interface.c (compare_components,
> gfc_compare_derived_types) was faulty in a few ways.
(snip)
> tl;dr: The attached patch fixes PR 77327 and another bug which is
> demonstrated in the included testcase.


Minor correction to a typo in the patch above - should be checking
cmp1 and cmp2 not cmp1 and cmp1:


diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index ffc36f5..f082464 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -425,7 +425,7 @@ compare_components (gfc_component *cmp1, gfc_component *cmp2
 gfc_symbol *derived1, gfc_symbol *derived2)
 {
   /* Compare names, but not for anonymous components such as UNION or MAP.  */
-  if (!is_anonymous_component (cmp1) && !is_anonymous_component (cmp1)
+  if (!is_anonymous_component (cmp1) && !is_anonymous_component (cmp2)
   && strcmp (cmp1->name, cmp2->name) != 0)
 return 0;

---
Fritz Reese

2016-08-24  Fritz Reese  

PR fortran/77327
gcc/fortran/
* interface.c (is_anonymous_component, is_anonymous_dt): New functions.
* interface.c (compare_components, gfc_compare_derived_types): Use new
functions.

gcc/testsuite/gfortran.dg/
* dec_structure_13.f90: New testcase.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 17500c9..f082464 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -387,26 +387,46 @@ gfc_match_end_interface (void)
 }
 
 
+/* Return whether the component was defined anonymously.  */
+
+static bool
+is_anonymous_component (gfc_component *cmp)
+{
+  /* Only UNION and MAP components are anonymous.  In the case of a MAP,
+ the derived type symbol is FL_STRUCT and the component name looks like mM*.
+ This is the only case in which the second character of a component name is
+ uppercase.  */
+  return cmp->ts.type == BT_UNION
+|| (cmp->ts.type == BT_DERIVED
+&& cmp->ts.u.derived->attr.flavor == FL_STRUCT
+&& cmp->name[0] && cmp->name[1] && ISUPPER (cmp->name[1]));
+}
+
+
+/* Return whether the derived type was defined anonymously.  */
+
+static bool
+is_anonymous_dt (gfc_symbol *derived)
+{
+  /* UNION and MAP types are always anonymous. Otherwise, only nested STRUCTURE
+ types can be anonymous.  For anonymous MAP/STRUCTURE, we have FL_STRUCT
+ and the type name looks like XX*.  This is the only case in which the
+ second character of a type name is uppercase.  */
+  return derived->attr.flavor == FL_UNION
+|| (derived->attr.flavor == FL_STRUCT
+&& derived->name[0] && derived->name[1] && ISUPPER (derived->name[1]));
+}
+
+
 /* Compare components according to 4.4.2 of the Fortran standard.  */
 
 static int
 compare_components (gfc_component *cmp1, gfc_component *cmp2,
 gfc_symbol *derived1, gfc_symbol *derived2)
 {
-  gfc_symbol *d1, *d2;
-  bool anonymous = false;
-
-  /* Unions, maps, and anonymous structures all have names like "[xX]X$\d+"
- which should not be compared.  */
-  d1 = cmp1->ts.u.derived;
-  d2 = cmp2->ts.u.derived;
-  if (   (d1 && (d1->attr.flavor == FL_STRUCT || d1->attr.flavor == FL_UNION)
-  && ISUPPER (cmp1->name[1]))
-  || (d2 && (d2->attr.flavor == FL_STRUCT || d2->attr.flavor == FL_UNION)
-  && ISUPPER (cmp2->name[1])))
-anonymous = true;
-
-  if (!anonymous && strcmp (cmp1->name, cmp2->name) != 0)
+  /* Compare names, but not for anonymous components such as UNION or MAP.  */
+  if (!is_anonymous_component (cmp1) && !is_anonymous_component (cmp2)
+  && strcmp (cmp1->name, cmp2->name) != 0)
 return 0;
 
   if (cmp1->attr.access != cmp2->attr.access)
@@ -512,22 +532,12 @@ int
 gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol *derived2)
 {
   gfc_component *cmp1, *cmp2;
-  bool anonymous = false;
 
   if (derived1 == derived2)
 return 1;
 
   gcc_assert (derived1 && derived2);
 
-  /* MAP and anonymous STRUCTURE types have internal names of the form
- mM* and sS* (we can get away this this because source names are converted
- to lowerase). Compare anonymous type names specially because each
- gets a unique name when it is declared. */
-  anonymous = (derived1->name[0] == derived2->name[0]
-  && derived1->name[1] && derived2->name[1] && derived2->name[2]
-  && derived1->name[1] == (char) TOUPPER (derived1->name[0])
-  && derived2->name[2] == (char) TOUPPER (derived2->name[0]));
-
   /* Special case for comparing derived types across namespaces.  If the
  true names and module names are the same and the module name is
  nonnull, then they are equal.  */
@@ -541,7 +551,9 @@ gfc_compare_derived_types (gfc_symbol *derived1, gfc_symbol *derived2)
  because they can be anonymous; therefore two structures with different
  names may be equal.  */
 
-  if

Re: C PATCH to suppress a bogus "defaulting to int" warning (PR c/77323)

[Joseph Myers]

On Wed, 24 Aug 2016, Marek Polacek wrote:

> 2016-08-24  Marek Polacek  
> 
>   PR c/77323
>   * c-decl.c (declspecs_add_type): Set typespec_word even when __intN
>   or _FloatN or _FloatNx is not supported.
>   (finish_declspecs): Set type to integer_type_node when _FloatN or
>   _FloatNx is not supported.
> 
>   * gcc.dg/pr77323.c: New test.

OK.

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

Re: [PATCH 0/4] Applying fix-its on behalf of the user to their code

[Manuel López-Ibáñez]

On 24/08/16 14:56, Richard Biener wrote:

You never typoed

gcc t.c -o t.c

?  ;)  (I did ... :/)


With GCC >=5

$ gcc t.c -o t.c
gcc: fatal error: input file ‘t.c’ is the same as output file
compilation terminated.

You are welcome ;-)

Manuel.

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Joseph Myers]

On Wed, 24 Aug 2016, Martin Sebor wrote:

> No.  I recall having seen Glibc fail with ENOMEM years ago when
> formatting a floating point number to a very large precision but
> I haven't seen any implementation fail.  I haven't yet looked to
> see if the Glibc failure can still happen.  My reading of C and
> POSIX is that snprintf is only allowed to fail due to an encoding
> error, not because it runs out of memory, so such a failure would
> seem like a bug.

It's a general ISO C principle that there may be implementation limits, 
including in areas where no specific minimum limit is given in the 
standard, and even where there is a mimimum, that doesn't mean that every 
possible program that does not exceed that minimum does not exceed the 
limit in that area.  In this case, a specific minimum limit is given, 
7.21.6.1#15 "The number of characters that can be produced by any single 
conversion shall be at least 4095.".  That is, libc can't reject all cases 
of larger results, but it's possible that if memory is short then some 
cases with shorter results could still fail.

It's also a general POSIX principle that functions may have additional 
error conditions beyond those given in the standard, when it's possible 
for them to return errors at all.

(Since people may wish to use snprintf / dprintf in signal handlers, 
avoiding malloc where possible in those functions is still a good idea.)

> > * It looks like you convert to (signed/unsigned) char for %hh formats,
> > etc.  Now, there is the possibility that the value passed was actually of
> > type int, and out of range for those types.  And there is the possibility
> > that the implementation might not itself convert those values to char /
> > short (glibc didn't until 2006) - passing a value outside the range of the
> > relevant type seems likely undefined behavior, so implementations may not
> > actually need to convert, and there's an open question about whether the
> > value actually needs to have been promoted from char/short in the caller
> > (see my ).  I don't
> > know if you wish to allow at all for this issue.
> 
> It sounds like the concern is that for the following call (when
> UCHAR_MAX is 255):
> 
>   sprintf (d, "%hhu", 1000)
> 
> some implementation (an old version of Glibc?) may have actually
> produced four digits and returned 4 on the basis of C saying that
> the %hhu argument must be an unsigned char (promoted to int) and
> thus the behavior of the call being undefined.

Yes.

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

Re: [PATCH 1/4][PR 71931] Fix libatomic tests

[Joseph Myers]

On Wed, 24 Aug 2016, Szabolcs Nagy wrote:

> diff --git a/libatomic/testsuite/lib/libatomic.exp 
> b/libatomic/testsuite/lib/libatomic.exp
> index cafab54..e374c64 100644
> --- a/libatomic/testsuite/lib/libatomic.exp
> +++ b/libatomic/testsuite/lib/libatomic.exp
> @@ -47,6 +47,8 @@ load_gcc_lib timeout.exp
>  load_gcc_lib timeout-dg.exp
>  load_gcc_lib fortran-modules.exp
>  
> +load_file libatomic-test-support.exp

This approach looks like it would break installed testing.  Such 
information from the build tree should only be loaded when 
TESTING_IN_BUILD_TREE is defined.

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

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Martin Sebor]

On 08/24/2016 04:03 PM, Joseph Myers wrote:

On Wed, 24 Aug 2016, Martin Sebor wrote:


No.  I recall having seen Glibc fail with ENOMEM years ago when
formatting a floating point number to a very large precision but
I haven't seen any implementation fail.  I haven't yet looked to
see if the Glibc failure can still happen.  My reading of C and
POSIX is that snprintf is only allowed to fail due to an encoding
error, not because it runs out of memory, so such a failure would
seem like a bug.


It's a general ISO C principle that there may be implementation limits,
including in areas where no specific minimum limit is given in the
standard, and even where there is a mimimum, that doesn't mean that every
possible program that does not exceed that minimum does not exceed the
limit in that area.  In this case, a specific minimum limit is given,
7.21.6.1#15 "The number of characters that can be produced by any single
conversion shall be at least 4095.".  That is, libc can't reject all cases
of larger results, but it's possible that if memory is short then some
cases with shorter results could still fail.


It sounds like using the 4095 limit should be safe even with Glibc.
I'll use it then, thanks.


It sounds like the concern is that for the following call (when
UCHAR_MAX is 255):

   sprintf (d, "%hhu", 1000)

some implementation (an old version of Glibc?) may have actually
produced four digits and returned 4 on the basis of C saying that
the %hhu argument must be an unsigned char (promoted to int) and
thus the behavior of the call being undefined.


Yes.


Since it's presumably a Glibc bug (bug 2509?) is this something
you believe the optimization needs to worry about?  If so, can
you confirm that only Glibc versions 2.4 and prior are affected
and 2.5 is not?

Martin

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Manuel López-Ibáñez]

>> --Wno-format-contains-nul -Wno-format-extra-args -Wformat-nonliteral @gol
>> +-Wno-format-contains-nul -Wno-format-extra-args -Wformat-length=1 @gol
>>
>> Most options that take levels are documented as:
>>
>> -Wshift-overflow -Wshift-overflow=@var{n}
>> -Wstrict-overflow -Wstrict-overflow=@var{n}
>
>
> I haven't found any uses of the @var{} tag for numeric arguments
> to options (e.g., -Wformat=2), only for symbolic arguments (e.g.,
> -Warray-bounds=@var{n}), so I'm leaving this as is.

My suggestion was to document -Wformat-length=@var{n}. There is no
difference between -Wformat-length's levels and -Wstrict-overfllow,
-Wshift-overflow, -Wstrict-aliasing levels.
-Wformat=2 is actually the odd one. Note that its description does use:
@item -Wformat
@itemx -Wformat=@var{n}

Even if you want to be explicit and follow -Wformat, then it should be

+-Wno-format-contains-nul -Wno-format-extra-args -Wformat-length
-Wformat-length=2 @gol


> I agree.  The challenge is that not all the bits this depends on
> (the g_string_concat_db and parse_in globals defined in the front
> end) are available in the middle end.  I've been talking to David
> Malcolm about how best to factor things out of c-format.c and make
> it available in both parts of the compiler under a convenient API.

Perhaps diagnostics_context could have pointers to those, forward
defined in the .h file and include the relevant libcpp headers in
diagnostics.c (or input.c). FEs that make use of those features could
initialize them (via some API) to some existing object. Otherwise,
they will work like in your patch (but within diagnostic.c). Similar
to how we initialize the FE-specific pretty-printers.

We already depend on libcpp for line-map.c, so internally depending on
other libcpp features is not so bad. The important thing is to hide
this from the clients, so that the clients do not need to be aware of
what diagnostics.c requires. That is, the middle-end and Ada should
not include headers that include libcpp headers, but diagnostics.c can
include whatever it needs.

Otherwise, the future will be again a mess and we get further away
from ever separating the FEs from the ME.

BTW, it would be nice to explain in comments why each header needs to
be included, besides obvious ones such as tree.h and gimple.h (it
would be great if we had guidelines on how to order included headers,
why not group together all gimple*, tree*, backend-stuff, diagnostics
stuff?). On the other hand, it is unfair to nitpick your patch
regarding this when other commits do the same.

+#include "backend.h"
+#include "tree.h"
+#include "gimple.h"
+#include "tree-pass.h"
+#include "ssa.h"
+#include "gimple-fold.h"
+#include "gimple-pretty-print.h"
+#include "diagnostic-core.h"

Already included in diagnostic.h

+#include "fold-const.h"
+#include "gimple-iterator.h"
+#include "tree-ssa.h"
+#include "tree-object-size.h"
+#include "params.h"
+#include "tree-cfg.h"
+#include "calls.h"
+#include "cfgloop.h"
+#include "intl.h"
+
+#include "builtins.h"
+#include "stor-layout.h"
+
+#include "realmpfr.h"
+#include "target.h"
+#include "targhooks.h"
+
+#include "cpplib.h"

Not in the ME!

+#include "input.h"

already included in coretypes.h

+#include "toplev.h"

Very few files actually need to include toplev.h. Most of them just
include it because of copy-pasting headers lists. And even for bogus
reasons (final.c:#include "toplev.h" /* exact_log2, floor_log2 */)

+#include "substring-locations.h"
+#include "diagnostic.h"

Cheers,

Manuel.

[PATCH 1/4] selftest: split out named_temp_file from temp_source_file

[David Malcolm]

Split out a new base class for temp_source_file, named_temp_file,
moving the deletion to the base class dtor, so that we can write
out temporary files in other ways in selftests.

gcc/ChangeLog:
* selftest.c (selftest::named_temp_file::named_temp_file): New
ctor.
(selftest::temp_source_file::~temp_source_file): Move to...
(selftest::named_temp_file::~named_temp_file): ...here.
(selftest::test_named_temp_file): New function.
(selftest::selftest_c_tests): Call test_named_temp_file.
* selftest.h (class named_temp_file): New class.
(class temp_source_file): Convert to a subclass of named_temp_file.
---
 gcc/selftest.c | 49 +++--
 gcc/selftest.h | 24 +---
 2 files changed, 52 insertions(+), 21 deletions(-)

diff --git a/gcc/selftest.c b/gcc/selftest.c
index 629db98..e6c9510 100644
--- a/gcc/selftest.c
+++ b/gcc/selftest.c
@@ -120,34 +120,40 @@ selftest::assert_str_contains (const location &loc,
 desc_haystack, desc_needle, val_haystack, val_needle);
 }
 
-/* Constructor.  Create a tempfile using SUFFIX, and write CONTENT to
-   it.  Abort if anything goes wrong, using LOC as the effective
-   location in the problem report.  */
+/* Constructor.  Generate a name for the file.  */
 
-selftest::temp_source_file::temp_source_file (const location &loc,
- const char *suffix,
- const char *content)
+selftest::named_temp_file::named_temp_file (const char *suffix)
 {
   m_filename = make_temp_file (suffix);
   ASSERT_NE (m_filename, NULL);
-
-  FILE *out = fopen (m_filename, "w");
-  if (!out)
-::selftest::fail_formatted (loc, "unable to open tempfile: %s",
-   m_filename);
-  fprintf (out, "%s", content);
-  fclose (out);
 }
 
 /* Destructor.  Delete the tempfile.  */
 
-selftest::temp_source_file::~temp_source_file ()
+selftest::named_temp_file::~named_temp_file ()
 {
   unlink (m_filename);
   diagnostics_file_cache_forcibly_evict_file (m_filename);
   free (m_filename);
 }
 
+/* Constructor.  Create a tempfile using SUFFIX, and write CONTENT to
+   it.  Abort if anything goes wrong, using LOC as the effective
+   location in the problem report.  */
+
+selftest::temp_source_file::temp_source_file (const location &loc,
+ const char *suffix,
+ const char *content)
+: named_temp_file (suffix)
+{
+  FILE *out = fopen (get_filename (), "w");
+  if (!out)
+::selftest::fail_formatted (loc, "unable to open tempfile: %s",
+   get_filename ());
+  fprintf (out, "%s", content);
+  fclose (out);
+}
+
 /* Selftests for the selftest system itself.  */
 
 namespace selftest {
@@ -167,12 +173,27 @@ test_assertions ()
   ASSERT_STR_CONTAINS ("foo bar baz", "bar");
 }
 
+/* Verify named_temp_file.  */
+
+static void
+test_named_temp_file ()
+{
+  named_temp_file t (".txt");
+  FILE *f = fopen (t.get_filename (), "w");
+  if (!f)
+selftest::fail_formatted (SELFTEST_LOCATION,
+ "unable to open %s for writing",
+ t.get_filename ());
+  fclose (f);
+}
+
 /* Run all of the selftests within this file.  */
 
 void
 selftest_c_tests ()
 {
   test_assertions ();
+  test_named_temp_file ();
 }
 
 } // namespace selftest
diff --git a/gcc/selftest.h b/gcc/selftest.h
index b073ed6..fd3c6b0 100644
--- a/gcc/selftest.h
+++ b/gcc/selftest.h
@@ -77,22 +77,32 @@ extern void assert_str_contains (const location &loc,
 const char *val_haystack,
 const char *val_needle);
 
-/* A class for writing out a temporary sourcefile for use in selftests
-   of input handling.  */
+/* A named temporary file for use in selftests.
+   Usable for writing out files, and as the base class for
+   temp_source_file.
+   The file is unlinked in the destructor.  */
 
-class temp_source_file
+class named_temp_file
 {
  public:
-  temp_source_file (const location &loc, const char *suffix,
-   const char *content);
-  ~temp_source_file ();
-
+  named_temp_file (const char *suffix);
+  ~named_temp_file ();
   const char *get_filename () const { return m_filename; }
 
  private:
   char *m_filename;
 };
 
+/* A class for writing out a temporary sourcefile for use in selftests
+   of input handling.  */
+
+class temp_source_file : public named_temp_file
+{
+ public:
+  temp_source_file (const location &loc, const char *suffix,
+   const char *content);
+};
+
 /* Various selftests involving location-handling require constructing a
line table and one or more line maps within it.
 
-- 
1.8.5.3

[PATCH 2/4] Improvements to typed_splay_tree

[David Malcolm]

This patch adds foreach, max and min methods to
class typed_splay_tree, along with the start of a selftest
suite.

gcc/ChangeLog:
* Makefile.in (OBJS): Add typed-splay-tree.o.
* selftest-run-tests.c (selftest::run_tests): Call
typed_splay_tree_c_tests.
* selftest.h (typed_splay_tree_c_tests): New decl.
* typed-splay-tree.c: New file.
* typed-splay-tree.h (typed_splay_tree::foreach_fn): New typedef.
(typed_splay_tree::max): New method.
(typed_splay_tree::min): New method.
(typed_splay_tree::foreach): New method.
(struct closure): New struct.
(inner_foreach_fn): New function.
---
 gcc/Makefile.in  |  1 +
 gcc/selftest-run-tests.c |  1 +
 gcc/selftest.h   |  1 +
 gcc/typed-splay-tree.c   | 79 
 gcc/typed-splay-tree.h   | 67 
 5 files changed, 149 insertions(+)
 create mode 100644 gcc/typed-splay-tree.c

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 8d7cc51..f5f3339 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1542,6 +1542,7 @@ OBJS = \
tree-vectorizer.o \
tree-vrp.o \
tree.o \
+   typed-splay-tree.o \
valtrack.o \
value-prof.o \
var-tracking.o \
diff --git a/gcc/selftest-run-tests.c b/gcc/selftest-run-tests.c
index 6453e31..e20bbd0 100644
--- a/gcc/selftest-run-tests.c
+++ b/gcc/selftest-run-tests.c
@@ -56,6 +56,7 @@ selftest::run_tests ()
   ggc_tests_c_tests ();
   sreal_c_tests ();
   fibonacci_heap_c_tests ();
+  typed_splay_tree_c_tests ();
 
   /* Mid-level data structures.  */
   input_c_tests ();
diff --git a/gcc/selftest.h b/gcc/selftest.h
index fd3c6b0..8e6c47a 100644
--- a/gcc/selftest.h
+++ b/gcc/selftest.h
@@ -165,6 +165,7 @@ extern void selftest_c_tests ();
 extern void spellcheck_c_tests ();
 extern void spellcheck_tree_c_tests ();
 extern void sreal_c_tests ();
+extern void typed_splay_tree_c_tests ();
 extern void tree_c_tests ();
 extern void tree_cfg_c_tests ();
 extern void vec_c_tests ();
diff --git a/gcc/typed-splay-tree.c b/gcc/typed-splay-tree.c
new file mode 100644
index 000..33992c1
--- /dev/null
+++ b/gcc/typed-splay-tree.c
@@ -0,0 +1,79 @@
+/* Selftests for typed-splay-tree.h.
+   Copyright (C) 2016 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "typed-splay-tree.h"
+#include "selftest.h"
+
+#if CHECKING_P
+
+namespace selftest {
+
+/* Callback for use by test_str_to_int.  */
+
+static int
+append_cb (const char *, int value, void *user_data)
+{
+  auto_vec  *vec = (auto_vec  *)user_data;
+  vec->safe_push (value);
+  return 0;
+}
+
+/* Test of typed_splay_tree .  */
+
+static void
+test_str_to_int ()
+{
+  typed_splay_tree  t (strcmp, NULL, NULL);
+
+  t.insert ("a", 1);
+  t.insert ("b", 2);
+  t.insert ("c", 3);
+
+  ASSERT_EQ (1, t.lookup ("a"));
+  ASSERT_EQ (2, t.lookup ("b"));
+  ASSERT_EQ (3, t.lookup ("c"));
+
+  ASSERT_EQ (2, t.predecessor ("c"));
+  ASSERT_EQ (3, t.successor ("b"));
+  ASSERT_EQ (1, t.min ());
+  ASSERT_EQ (3, t.max ());
+
+  /* Test foreach by appending to a vec, and verifying the vec.  */
+  auto_vec  v;
+  t.foreach (append_cb, &v);
+  ASSERT_EQ (3, v.length ());
+  ASSERT_EQ (1, v[0]);
+  ASSERT_EQ (2, v[1]);
+  ASSERT_EQ (3, v[2]);
+}
+
+/* Run all of the selftests within this file.  */
+
+void
+typed_splay_tree_c_tests ()
+{
+  test_str_to_int ();
+}
+
+} // namespace selftest
+
+#endif /* #if CHECKING_P */
diff --git a/gcc/typed-splay-tree.h b/gcc/typed-splay-tree.h
index 9dd96d6..b52fc20 100644
--- a/gcc/typed-splay-tree.h
+++ b/gcc/typed-splay-tree.h
@@ -33,6 +33,7 @@ class typed_splay_tree
   typedef int (*compare_fn) (key_type, key_type);
   typedef void (*delete_key_fn) (key_type);
   typedef void (*delete_value_fn) (value_type);
+  typedef int (*foreach_fn) (key_type, value_type, void *);
 
   typed_splay_tree (compare_fn,
delete_key_fn,
@@ -43,6 +44,9 @@ class typed_splay_tree
   value_type predecessor (key_type k);
   value_type successor (key_type k);
   void insert (key_type k, value_type v);
+  value_type max ();
+  value_type min ();
+  int foreach (foreach_fn, void *);
 
  private:
   static value_type node_to_value (splay_tree_node node);
@@ -120,6 +124,69 @@ typed_

[PATCH 3/4] (v2) Introduce class edit_context

[David Malcolm]

This version removes edit_context::apply_changes and related
functionality, retaining the ability to generate diffs.

It also improves error-handling (adding a selftest for this).

gcc/ChangeLog:
* Makefile.in (OBJS-libcommon): Add edit-context.o.
* diagnostic-color.c (color_dict): Add "diff-filename",
"diff-hunk", "diff-delete", and "diff-insert".
(parse_gcc_colors): Update default value of GCC_COLORS in comment
to reflect above changes.
* edit-context.c: New file.
* edit-context.h: New file.
* selftest-run-tests.c (selftest::run_tests): Call
edit_context_c_tests.
* selftest.h (edit_context_c_tests): New decl.
---
 gcc/Makefile.in  |1 +
 gcc/diagnostic-color.c   |8 +-
 gcc/edit-context.c   | 1347 ++
 gcc/edit-context.h   |   65 +++
 gcc/selftest-run-tests.c |1 +
 gcc/selftest.h   |1 +
 6 files changed, 1422 insertions(+), 1 deletion(-)
 create mode 100644 gcc/edit-context.c
 create mode 100644 gcc/edit-context.h

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index f5f3339..506f0d4 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1561,6 +1561,7 @@ OBJS = \
 # Objects in libcommon.a, potentially used by all host binaries and with
 # no target dependencies.
 OBJS-libcommon = diagnostic.o diagnostic-color.o diagnostic-show-locus.o \
+   edit-context.o \
pretty-print.o intl.o \
vec.o input.o version.o hash-table.o ggc-none.o memory-block.o \
selftest.o
diff --git a/gcc/diagnostic-color.c b/gcc/diagnostic-color.c
index f76c87b..decbe84 100644
--- a/gcc/diagnostic-color.c
+++ b/gcc/diagnostic-color.c
@@ -168,6 +168,10 @@ static struct color_cap color_dict[] =
   { "range2", SGR_SEQ (COLOR_FG_BLUE), 6, false },
   { "locus", SGR_SEQ (COLOR_BOLD), 5, false },
   { "quote", SGR_SEQ (COLOR_BOLD), 5, false },
+  { "diff-filename", SGR_SEQ (COLOR_BOLD), 13, false },
+  { "diff-hunk", SGR_SEQ (COLOR_FG_CYAN), 9, false },
+  { "diff-delete", SGR_SEQ (COLOR_FG_RED), 11, false },
+  { "diff-insert", SGR_SEQ (COLOR_FG_GREEN), 11, false },
   { NULL, NULL, 0, false }
 };
 
@@ -196,7 +200,9 @@ colorize_stop (bool show_color)
 }
 
 /* Parse GCC_COLORS.  The default would look like:
-   
GCC_COLORS='error=01;31:warning=01;35:note=01;36:range1=32:range2=34;locus=01:quote=01'
+   GCC_COLORS='error=01;31:warning=01;35:note=01;36:\
+   range1=32:range2=34:locus=01:quote=01:\
+   diff-filename=01:diff-hunk=32:diff-delete=31:diff-insert=32'
No character escaping is needed or supported.  */
 static bool
 parse_gcc_colors (void)
diff --git a/gcc/edit-context.c b/gcc/edit-context.c
new file mode 100644
index 000..6b79b45
--- /dev/null
+++ b/gcc/edit-context.c
@@ -0,0 +1,1347 @@
+/* Determining the results of applying fix-its.
+   Copyright (C) 2016 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "line-map.h"
+#include "edit-context.h"
+#include "pretty-print.h"
+#include "diagnostic-color.h"
+#include "selftest.h"
+
+/* This file implements a way to track the effect of fix-its,
+   via a class edit_context; the other classes are support classes for
+   edit_context.
+
+   A complication here is that fix-its are expressed relative to coordinates
+   in the file when it was parsed, before any changes have been made, and
+   so if there's more that one fix-it to be applied, we have to adjust
+   later fix-its to allow for the changes made by earlier ones.  This
+   is done by the various "get_effective_column" methods.
+
+   The "filename" params are required to outlive the edit_context (no
+   copy of the underlying str is taken, just the ptr).  */
+
+/* Forward decls.  class edit_context is declared within edit-context.h.
+   The other types are declared here.  */
+class edit_context;
+class edited_file;
+class line_state;
+class line_event;
+  class insert_event;
+  class replace_event;
+
+/* A struct to hold the params of a print_diff call.  */
+
+struct diff
+{
+  diff (pretty_printer *pp, bool show_filenames)
+  : m_pp (pp), m_show_filenames (show_filenames) {}
+
+  pretty_printer *m_pp;
+  bool m_show_filenames;
+};
+
+/* The state of one named file within an edit_context: the filename,
+   the current content of the file after applying all 

[PATCH 0/4] (v2) Generating patches from fix-it hints

[David Malcolm]

Here's a much less ambitious version of the patch kit, which
eliminates any attempt to write to the user's source
code (getting rid of edit_context::apply_changes and
 -fdiagnostics-apply-fixits).

It implements -fdiagnostics-generate-patch.  In so doing, it
tightens up the exact semantics of fix-its; see [1] for an
example of where that's useful.

I need review of at least patches 1 and 2 (which are unchanged
from v1 of the kit).  I believe I can self-approve patches 3
and 4 as part of my "diagnostics maintainer" role; are they
acceptable to those who objected to the earlier kit? (now
that there's no attempt to write to source files).

Successfully bootstrapped®rtested the combination of the patches
on x86_64-pc-linux-gnu.

OK for trunk? (assuming individual bootstraps®rtesting)

[1] https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01751.html

David Malcolm (4):
  selftest: split out named_temp_file from temp_source_file
  Improvements to typed_splay_tree
  Introduce class edit_context (v2)
  Add -fdiagnostics-generate-patch (v2)

 gcc/Makefile.in|2 +
 gcc/common.opt |4 +
 gcc/diagnostic-color.c |8 +-
 gcc/diagnostic.c   |   11 +
 gcc/diagnostic.h   |6 +
 gcc/doc/invoke.texi|   23 +-
 gcc/edit-context.c | 1306 
 gcc/edit-context.h |   65 +
 gcc/selftest-run-tests.c   |2 +
 gcc/selftest.c |   49 +-
 gcc/selftest.h |   26 +-
 .../diagnostic-test-show-locus-generate-patch.c|   77 ++
 gcc/testsuite/gcc.dg/plugin/plugin.exp |3 +-
 gcc/toplev.c   |   14 +
 gcc/typed-splay-tree.c |   79 ++
 gcc/typed-splay-tree.h |   67 +
 16 files changed, 1718 insertions(+), 24 deletions(-)
 create mode 100644 gcc/edit-context.c
 create mode 100644 gcc/edit-context.h
 create mode 100644 
gcc/testsuite/gcc.dg/plugin/diagnostic-test-show-locus-generate-patch.c
 create mode 100644 gcc/typed-splay-tree.c

-- 
1.8.5.3

[PATCH 4/4] (v2) Add -fdiagnostics-generate-patch

[David Malcolm]

Changed in v2: I dropped -fdiagnostics-apply-fixits

This patch uses the edit_context machinery to provide a new
-fdiagnostics-generate-patch option.

If set an edit_context is created for global_dc, and any
fix-it hints emitted by diagnostics are added to the edit_context.

-fdiagnostics-generate-patch writes out a patch to stderr in unified
diff format.  This is potentially color-coded, following the same rules
as for diagnostics (and affected by -fdiagnostics-color).  The color
scheme mimics that of git-diff.

gcc/ChangeLog:
* common.opt (fdiagnostics-generate-patch): New option.
* diagnostic.c: Include "edit-context.h".
(diagnostic_initialize): Initialize context->edit_context_ptr.
(diagnostic_finish): Delete context->edit_context_ptr.
(diagnostic_report_diagnostic): Add fix-it hints from the
diagnostic to context->edit_context_ptr, if any.
* diagnostic.h (class edit_context): Add forward decl.
(struct diagnostic_context): Add field "edit_context_ptr".
* doc/invoke.texi (Diagnostic Message Formatting Options): Add
-fdiagnostics-generate-patch.
(-fdiagnostics-generate-patch): New item.
* toplev.c: Include "edit-context.h".
(process_options): Set global_dc->edit_context_ptr to a new
edit_context if the options need one.
(toplev::main): Handle -fdiagnostics-generate-patch by using
global_dc->edit_context_ptr.

gcc/testsuite/ChangeLog:
* gcc.dg/plugin/diagnostic-test-show-locus-generate-patch.c: New
test case.
* gcc.dg/plugin/plugin.exp (plugin_test_list): Add
diagnostic-test-show-locus-generate-patch.c to the sources
for diagnostic_plugin_test_show_locus.c.
---
 gcc/common.opt |  4 ++
 gcc/diagnostic.c   | 11 
 gcc/diagnostic.h   |  6 ++
 gcc/doc/invoke.texi| 23 ++-
 .../diagnostic-test-show-locus-generate-patch.c| 77 ++
 gcc/testsuite/gcc.dg/plugin/plugin.exp |  3 +-
 gcc/toplev.c   | 14 
 7 files changed, 136 insertions(+), 2 deletions(-)
 create mode 100644 
gcc/testsuite/gcc.dg/plugin/diagnostic-test-show-locus-generate-patch.c

diff --git a/gcc/common.opt b/gcc/common.opt
index 65a9762..0c40d0a 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1196,6 +1196,10 @@ fdiagnostics-parseable-fixits
 Common Var(flag_diagnostics_parseable_fixits)
 Print fixit hints in machine-readable form.
 
+fdiagnostics-generate-patch
+Common Var(flag_diagnostics_generate_patch)
+Print fix-it hints to stderr in unified diff format.
+
 fdiagnostics-show-option
 Common Var(flag_diagnostics_show_option) Init(1)
 Amend appropriate diagnostic messages with the command line option that 
controls them.
diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index b47da38..5a2c565 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -31,6 +31,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "backtrace.h"
 #include "diagnostic.h"
 #include "diagnostic-color.h"
+#include "edit-context.h"
 #include "selftest.h"
 
 #ifdef HAVE_TERMIOS_H
@@ -174,6 +175,7 @@ diagnostic_initialize (diagnostic_context *context, int 
n_opts)
   context->colorize_source_p = false;
   context->show_ruler_p = false;
   context->parseable_fixits_p = false;
+  context->edit_context_ptr = NULL;
 }
 
 /* Maybe initialize the color support. We require clients to do this
@@ -235,6 +237,12 @@ diagnostic_finish (diagnostic_context *context)
   context->printer->~pretty_printer ();
   XDELETE (context->printer);
   context->printer = NULL;
+
+  if (context->edit_context_ptr)
+{
+  delete context->edit_context_ptr;
+  context->edit_context_ptr = NULL;
+}
 }
 
 /* Initialize DIAGNOSTIC, where the message MSG has already been
@@ -943,6 +951,9 @@ diagnostic_report_diagnostic (diagnostic_context *context,
   diagnostic->message.format_spec = saved_format_spec;
   diagnostic->x_data = NULL;
 
+  if (context->edit_context_ptr)
+context->edit_context_ptr->add_fixits (diagnostic->richloc);
+
   context->lock--;
 
   return true;
diff --git a/gcc/diagnostic.h b/gcc/diagnostic.h
index 104e39c..27e6007 100644
--- a/gcc/diagnostic.h
+++ b/gcc/diagnostic.h
@@ -62,6 +62,8 @@ typedef void (*diagnostic_start_span_fn) (diagnostic_context 
*,
 
 typedef diagnostic_starter_fn diagnostic_finalizer_fn;
 
+class edit_context;
+
 /* This data structure bundles altogether any information relevant to
the context of a diagnostic message.  */
 struct diagnostic_context
@@ -209,6 +211,10 @@ struct diagnostic_context
   /* If true, print fixits in machine-parseable form after the
  rest of the diagnostic.  */
   bool parseable_fixits_p;
+
+  /* If non-NULL, an edit_context to which fix-it hints should be
+ applied, for generating patches.  */
+  edit_context *edit_context_p

[PATCH 1/3] haifa-sched.c: make ready_list an auto_vec

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-08-25  Trevor Saunders  

* haifa-sched.c (fix_recovery_deps): Make ready_list a vector.
---
 gcc/haifa-sched.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 84e42c0..c58b0ad 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -8600,9 +8600,8 @@ static void
 fix_recovery_deps (basic_block rec)
 {
   rtx_insn *note, *insn, *jump;
-  rtx_insn_list *ready_list = 0;
+  auto_vec ready_list;
   bitmap_head in_ready;
-  rtx_insn_list *link;
 
   bitmap_initialize (&in_ready, 0);
 
@@ -8628,7 +8627,7 @@ fix_recovery_deps (basic_block rec)
  sd_delete_dep (sd_it);
 
  if (bitmap_set_bit (&in_ready, INSN_LUID (consumer)))
-   ready_list = alloc_INSN_LIST (consumer, ready_list);
+   ready_list.safe_push (consumer);
}
  else
{
@@ -8645,9 +8644,10 @@ fix_recovery_deps (basic_block rec)
   bitmap_clear (&in_ready);
 
   /* Try to add instructions to the ready or queue list.  */
-  for (link = ready_list; link; link = link->next ())
-try_ready (link->insn ());
-  free_INSN_LIST_list (&ready_list);
+  unsigned int i;
+  rtx_insn *temp;
+  FOR_EACH_VEC_ELT_REVERSE (ready_list, i, temp)
+try_ready (temp);
 
   /* Fixing jump's dependences.  */
   insn = BB_HEAD (rec);
-- 
2.9.0

[PATCH 3/3] make stack_slot_list a vec

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-08-25  Trevor Saunders  

* emit-rtl.h (struct rtl_data): Make stack_slot_list a vector.
* emit-rtl.c (unshare_all_rtl_1): Adjust.
(unshare_all_rtl_again): Likewise.
* function.c (assign_stack_local_1): Likewise.
(assign_stack_temp_for_type): Likewise.
---
 gcc/emit-rtl.c | 11 ---
 gcc/emit-rtl.h |  2 +-
 gcc/function.c |  8 +++-
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 99f052d..c1051eb 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -2626,8 +2626,10 @@ unshare_all_rtl_1 (rtx_insn *insn)
  This special care is necessary when the stack slot MEM does not
  actually appear in the insn chain.  If it does appear, its address
  is unshared from all else at that point.  */
-  stack_slot_list = safe_as_a  (
- copy_rtx_if_shared (stack_slot_list));
+  unsigned int i;
+  rtx temp;
+  FOR_EACH_VEC_SAFE_ELT_REVERSE (stack_slot_list, i, temp)
+(*stack_slot_list)[i] = copy_rtx_if_shared (temp);
 }
 
 /* Go through all the RTL insn bodies and copy any invalid shared
@@ -2656,7 +2658,10 @@ unshare_all_rtl_again (rtx_insn *insn)
   for (decl = DECL_ARGUMENTS (cfun->decl); decl; decl = DECL_CHAIN (decl))
 set_used_flags (DECL_RTL (decl));
 
-  reset_used_flags (stack_slot_list);
+  rtx temp;
+  unsigned int i;
+  FOR_EACH_VEC_SAFE_ELT_REVERSE (stack_slot_list, i, temp)
+reset_used_flags (temp);
 
   unshare_all_rtl_1 (insn);
 }
diff --git a/gcc/emit-rtl.h b/gcc/emit-rtl.h
index 39dfce9..52c72b1 100644
--- a/gcc/emit-rtl.h
+++ b/gcc/emit-rtl.h
@@ -104,7 +104,7 @@ struct GTY(()) rtl_data {
 
   /* List (chain of EXPR_LISTs) of all stack slots in this function.
  Made for the sake of unshare_all_rtl.  */
-  rtx_expr_list *x_stack_slot_list;
+  vec *x_stack_slot_list;
 
   /* List of empty areas in the stack frame.  */
   struct frame_space *frame_space_list;
diff --git a/gcc/function.c b/gcc/function.c
index bba0705..53bad87 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -499,8 +499,7 @@ assign_stack_local_1 (machine_mode mode, HOST_WIDE_INT size,
   set_mem_align (x, alignment_in_bits);
   MEM_NOTRAP_P (x) = 1;
 
-  stack_slot_list
-= gen_rtx_EXPR_LIST (VOIDmode, x, stack_slot_list);
+  vec_safe_push (stack_slot_list, x);
 
   if (frame_offset_overflow (frame_offset, current_function_decl))
 frame_offset = 0;
@@ -829,8 +828,7 @@ assign_stack_temp_for_type (machine_mode mode, 
HOST_WIDE_INT size,
  p->type = best_p->type;
  insert_slot_to_list (p, &avail_temp_slots);
 
- stack_slot_list = gen_rtx_EXPR_LIST (VOIDmode, p->slot,
-  stack_slot_list);
+ vec_safe_push (stack_slot_list, p->slot);
 
  best_p->size = rounded_size;
  best_p->full_size = rounded_size;
@@ -902,7 +900,7 @@ assign_stack_temp_for_type (machine_mode mode, 
HOST_WIDE_INT size,
 
   /* Create a new MEM rtx to avoid clobbering MEM flags of old slots.  */
   slot = gen_rtx_MEM (mode, XEXP (p->slot, 0));
-  stack_slot_list = gen_rtx_EXPR_LIST (VOIDmode, slot, stack_slot_list);
+  vec_safe_push (stack_slot_list, slot);
 
   /* If we know the alias set for the memory that will be used, use
  it.  If there's no TYPE, then we don't know anything about the
-- 
2.9.0

[PATCH 2/3] make forced labels a vec

[tbsaunde+gcc]

From: Trevor Saunders 

gcc/ChangeLog:

2016-08-25  Trevor Saunders  

* cfgbuild.c (make_edges): Adjust.
* cfgrtl.c (can_delete_label_p): Likewise.
* dwarf2cfi.c (create_trace_edges): Likewise.
* except.c (sjlj_emit_dispatch_table): Likewise.
* function.h (struct expr_status): make x_forced_labels a vector.
* jump.c (rebuild_jump_labels_1): Adjust.
* reload1.c (set_initial_label_offsets): Likewise.
* stmt.c (force_label_rtx): Likewise.
(expand_label): Likewise.
---
 gcc/cfgbuild.c  |  9 ++---
 gcc/cfgrtl.c|  3 ++-
 gcc/dwarf2cfi.c |  6 --
 gcc/except.c|  3 +--
 gcc/function.h  |  2 +-
 gcc/jump.c  | 12 +++-
 gcc/reload1.c   |  7 ---
 gcc/stmt.c  |  4 ++--
 8 files changed, 27 insertions(+), 19 deletions(-)

diff --git a/gcc/cfgbuild.c b/gcc/cfgbuild.c
index c1ec46a..20fc270 100644
--- a/gcc/cfgbuild.c
+++ b/gcc/cfgbuild.c
@@ -204,7 +204,8 @@ make_edges (basic_block min, basic_block max, int update_p)
   /* Heavy use of computed goto in machine-generated code can lead to
  nearly fully-connected CFGs.  In that case we spend a significant
  amount of time searching the edge lists for duplicates.  */
-  if (forced_labels || cfun->cfg->max_jumptable_ents > 100)
+  if (!vec_safe_is_empty (forced_labels)
+  || cfun->cfg->max_jumptable_ents > 100)
 edge_cache = sbitmap_alloc (last_basic_block_for_fn (cfun));
 
   /* By nature of the way these get numbered, ENTRY_BLOCK_PTR->next_bb block
@@ -280,8 +281,10 @@ make_edges (basic_block min, basic_block max, int update_p)
 everything on the forced_labels list.  */
  else if (computed_jump_p (insn))
{
- for (rtx_insn_list *x = forced_labels; x; x = x->next ())
-   make_label_edge (edge_cache, bb, x->insn (), EDGE_ABNORMAL);
+ rtx_insn *insn;
+ unsigned int i;
+ FOR_EACH_VEC_SAFE_ELT_REVERSE (forced_labels, i, insn)
+   make_label_edge (edge_cache, bb, insn, EDGE_ABNORMAL);
}
 
  /* Returns create an exit out.  */
diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index 0d335fc..de07fcd 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -115,7 +115,8 @@ can_delete_label_p (const rtx_code_label *label)
   return (!LABEL_PRESERVE_P (label)
  /* User declared labels must be preserved.  */
  && LABEL_NAME (label) == 0
- && !in_insn_list_p (forced_labels, label));
+ && !vec_safe_contains (forced_labels,
+const_cast 
(label)));
 }
 
 /* Delete INSN by patching it out.  */
diff --git a/gcc/dwarf2cfi.c b/gcc/dwarf2cfi.c
index bcf79f5..3ded2ce 100644
--- a/gcc/dwarf2cfi.c
+++ b/gcc/dwarf2cfi.c
@@ -2354,8 +2354,10 @@ create_trace_edges (rtx_insn *insn)
}
   else if (computed_jump_p (insn))
{
- for (rtx_insn_list *lab = forced_labels; lab; lab = lab->next ())
-   maybe_record_trace_start (lab->insn (), insn);
+ rtx_insn *temp;
+ unsigned int i;
+ FOR_EACH_VEC_SAFE_ELT_REVERSE (forced_labels, i, temp)
+   maybe_record_trace_start (temp, insn);
}
   else if (returnjump_p (insn))
;
diff --git a/gcc/except.c b/gcc/except.c
index 8aeb4e8..bc6f30c 100644
--- a/gcc/except.c
+++ b/gcc/except.c
@@ -1278,8 +1278,7 @@ sjlj_emit_dispatch_table (rtx_code_label *dispatch_label, 
int num_dispatch)
  label on the nonlocal_goto_label list.  Since we're modeling these
  CFG edges more exactly, we can use the forced_labels list instead.  */
   LABEL_PRESERVE_P (dispatch_label) = 1;
-  forced_labels
-= gen_rtx_INSN_LIST (VOIDmode, dispatch_label, forced_labels);
+  vec_safe_push (forced_labels, dispatch_label);
 #endif
 
   /* Load up exc_ptr and filter values from the function context.  */
diff --git a/gcc/function.h b/gcc/function.h
index 501ef68..590a490 100644
--- a/gcc/function.h
+++ b/gcc/function.h
@@ -126,7 +126,7 @@ struct GTY(()) expr_status {
   rtx x_apply_args_value;
 
   /* List of labels that must never be deleted.  */
-  rtx_insn_list *x_forced_labels;
+  vec *x_forced_labels;
 };
 
 typedef struct call_site_record_d *call_site_record;
diff --git a/gcc/jump.c b/gcc/jump.c
index 5b433af..b166926 100644
--- a/gcc/jump.c
+++ b/gcc/jump.c
@@ -68,8 +68,6 @@ static int invert_exp_1 (rtx, rtx);
 static void
 rebuild_jump_labels_1 (rtx_insn *f, bool count_forced)
 {
-  rtx_insn_list *insn;
-
   timevar_push (TV_REBUILD_JUMP);
   init_label_info (f);
   mark_all_labels (f);
@@ -79,9 +77,13 @@ rebuild_jump_labels_1 (rtx_insn *f, bool count_forced)
  count doesn't drop to zero.  */
 
   if (count_forced)
-for (insn = forced_labels; insn; insn = insn->next ())
-  if (LABEL_P (insn->insn ()))
-   LABEL_NUSES (insn->insn ())++;
+{
+  rtx_insn *insn;
+  unsigned int i;
+  FOR_EACH_VEC_SAFE_ELT_REVERSE (forced_labels, i, insn)
+   if (LABEL_P (insn))
+ L

[PATCH 0/3] more rtl list work

[tbsaunde+gcc]

From: Trevor Saunders 

Hi,

continueing on with getting rid of uses of rtx_insn_list and rtx_expr_list.

bootstrapped + regtested patches individually on x86_64-linux-gnu, ok?

Thanks!

Trev


Trevor Saunders (3):
  haifa-sched.c: make ready_list an auto_vec
  make forced labels a vec
  make stack_slot_list a vec

 gcc/cfgbuild.c|  9 ++---
 gcc/cfgrtl.c  |  3 ++-
 gcc/dwarf2cfi.c   |  6 --
 gcc/emit-rtl.c| 11 ---
 gcc/emit-rtl.h|  2 +-
 gcc/except.c  |  3 +--
 gcc/function.c|  8 +++-
 gcc/function.h|  2 +-
 gcc/haifa-sched.c | 12 ++--
 gcc/jump.c| 12 +++-
 gcc/reload1.c |  7 ---
 gcc/stmt.c|  4 ++--
 12 files changed, 45 insertions(+), 34 deletions(-)

-- 
2.9.0