Re: [C/C++ PATCH] Don't emit invalid VEC_COND_EXPR for vector comparisons (PR c/68062)

[Marek Polacek]

Ping.

On Wed, Jan 20, 2016 at 12:31:51PM +0100, Marek Polacek wrote:
> On Wed, Jan 13, 2016 at 11:11:52PM +, Joseph Myers wrote:
> > The C front-end changes are OK.
> 
> Jason, is the C++ part of this patch here
> 
> (which is identical to the change in the C FE) ok?
> 
> Also, not sure about backporting this, maybe just to 5?

Marek

Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation

[Jeff Law]

On 01/18/2016 11:27 AM, Ajit Kumar Agarwal wrote:



Ajit, can you confirm which of adpcm_code or adpcm_decode where
path splitting is showing a gain?  I suspect it's the former but
would like to make sure so that I can adjust the heuristics
properly.

I'd still like to have this answered when you can Ajit, just to
be 100% that it's the path splitting in adpcm_code that's
responsible for the improvements you're seeing in adpcm.


The adpcm_coder get optimized with path splitting whereas the
adpcm_decoder is not optimized further with path splitting. In
adpcm_decoder the join node is duplicated into its predecessors and
with the duplication of join node the code is not optimized further.
Right.  Just wanted to make sure my analysis corresponded with what you 
were seeing in your benchmarking -- and it does.


I suspect that if we looked at this problem from the angle of isolating 
paths based on how constant PHI arguments feed into and allow 
simplifications in later blocks that we might get better long term 
results -- including improving adpcm_decoder which has the same idiom as 
adpcm_coder -- it's just in the wrong spot in the CFG.


But that's obviously gcc-7 material.

Jeff

Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation

[Jeff Law]

On 01/18/2016 02:13 AM, Ajit Kumar Agarwal wrote:



-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Saturday, January 16, 2016 12:03 PM
To: Ajit Kumar Agarwal; Richard Biener
Cc: GCC Patches; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; 
Nagaraju Mekala
Subject: Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa 
representation

On 01/04/2016 07:32 AM, Ajit Kumar Agarwal wrote:



-Original Message- From: Jeff Law [mailto:l...@redhat.com]
Sent: Wednesday, December 23, 2015 12:06 PM To: Ajit Kumar Agarwal;
Richard Biener Cc: GCC Patches; Vinod Kathail; Shail Aditya Gupta;
Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re:
[Patch,tree-optimization]: Add new path Splitting pass on tree ssa
representation

On 12/11/2015 02:11 AM, Ajit Kumar Agarwal wrote:


Mibench/EEMBC benchmarks (Target Microblaze)

Automotive_qsort1(4.03%), Office_ispell(4.29%),
Office_stringsearch1(3.5%). Telecom_adpcm_d( 1.37%),
ospfv2_lite(1.35%).

I'm having a real tough time reproducing any of these results.
In fact, I'm having a tough time seeing cases where path splitting
even applies to the Mibench/EEMBC benchmarks

mentioned above.



In the very few cases where split-paths might apply, the net
resulting assembly code I get is the same with and without
split-paths.



How consistent are these results?


I am consistently getting the gains for office_ispell and
office_stringsearch1, telcom_adpcm_d. I ran it again today and we see
gains in the same bench mark tests with the split path changes.


What functions are being affected that in turn impact performance?


For office_ispell: The function are Function "linit (linit,
funcdef_no=0, decl_uid=2535, cgraph_uid=0, symbol_order=2) for
lookup.c file". "Function checkfile (checkfile, funcdef_no=1,
decl_uid=2478, cgraph_uid=1, symbol_order=4)" " Function correct
(correct, funcdef_no=2, decl_uid=2503, cgraph_uid=2, symbol_order=5)"
" Function askmode (askmode, funcdef_no=24, decl_uid=2464,
cgraph_uid=24, symbol_order=27)" for correct.c file.

For office_stringsearch1: The function is Function "bmhi_search
(bmhi_search, funcdef_no=1, decl_uid=2178, cgraph_uid=1,
symbol_order=5)" for bmhisrch.c file.

Can you send me the pre-processed lookup.c, correct.c and bmhi_search.c?



I generated mine using x86 and that may be affecting my ability to reproduce your 
results on the microblaze target.  Looking specifically at bmhi_search.c and 
correct.c, I see they are >>going to be sensitive to the target headers.  If 
(for exmaple) they use FORTIFY_SOURCE or macros for toupper.



In the bmhi_search I'm looking at, I don't see any opportunities for the path 
splitter to do anything.  The CFG just doesn't have the right shape.  Again, that may 
be an artifact of how >>toupper is implemented in the system header files -- 
hence my request for the cpp output on each of the important files.


Would you like me  to send the above files and function pre-processed with -E 
option flag.
That would be perfect.  I'm on the road the latter half of the week into 
early next week -- the long flights might be a good time for me to stare 
at the dumps and tweak the heuristic a bit.


jeff

Re: [PATCH 4/5] Don't mark targets of unconditional jumps with side effects as FALLTHRU.

[Jeff Law]

On 01/22/2016 12:44 AM, Andreas Krebbel wrote:

On 01/22/2016 12:10 AM, Jeff Law wrote:

On 01/21/2016 03:05 AM, Andreas Krebbel wrote:

On 01/02/2016 08:16 PM, Marcin Kościelnicki wrote:

When an unconditional jump with side effects targets an immediately
following label, rtl_tidy_fallthru_edge is called.  Since it has side
effects, it doesn't remove the jump, but the label is still marked
as fallthru.  This later causes a verification error.  Do nothing in this
case instead.

gcc/ChangeLog:

* cfgrtl.c (rtl_tidy_fallthru_edge): Bail for unconditional jumps
with side effects.


The change looks ok to me (although I'm not able to approve it). Could you 
please run regressions
tests on x86_64 with that change?

Perhaps a short comment in the code would be good.

I think the patch is technically fine, the question is does it fix a
visible bug?  I read the series as new feature enablement so I put this
patch into my gcc7 queue.


We need the patch for the S/390 split-stack implementation which we would like 
to see in GCC 6.  I'm
aware that this isn't stage 3 material but people seem to have reasons to 
really want split stack on
S/390 asap and we would have to backport this feature anyway. Therefore I would 
prefer to have it in
the official release already. That's the only common code change we would need 
for that.

I've started a bootstrap and regression test for the patch also on Power.

Do you see a chance we can get this into GCC 6?
So I think it'd largely depend on what you do with the s390 specific 
bits -- if you decide to drop those in (ISTM that's your call), then I 
think adding the cfgrtl patch is probably the wise thing to do.  So 
consider it approved for gcc-6 if/when you decide to go forward with the 
s390 specific bits.


FWIW, the PA might run afoul of the code you're fixing as well. It's got 
add[i]b,tr and mov[i]b,tr which are unconditional jumps with other side 
effects.  We never really used them all that much and once the PA8000 
series came out, they were actually a performance lose, so they were 
disabled on the "modern" PA machines.


Jeff

Re: Suspicious code in fold-const.c

[Jeff Law]

On 01/22/2016 10:21 AM, Bernd Schmidt wrote:

On 01/22/2016 02:37 PM, Andrew MacLeod wrote:


 /* If the initializer is non-void, then it's a normal expression
that will be assigned to the slot.  */
(*)  if (!VOID_TYPE_P (t))
  (*) return RECURSE (t);




I suspect this should also be
if (!VOID_TYPE_P(TREE_TYPE(t))


The terminology in the documentation is somewhat unfortunate:

/* For TARGET_EXPR, operand 0 is the target of an initialization,
operand 1 is the initializer for the target, which may be void
  if simply expanding it initializes the target.
operand 2 is the cleanup for this node, if any.
operand 3 is the saved initializer after this node has been
expanded once; this is so we can re-expand the tree later.  */
DEFTREECODE (TARGET_EXPR, "target_expr", tcc_expression, 4)

I suspect that should read "which may have void type". Code in cp/tree.c
also looks at the type of the initializer to see if it is void, so I
think you are right with your suspicion.

So, I think your proposed change is OK (modulo formatting), but it may
cause problems since it'll enable code that was never tested. Maybe best
to do it for gcc-7. Ideally you'd also make a change cleaning up the
wording in tree.def.

Agreed.

jeff

Re: Suspicious code in fold-const.c

[Jeff Law]

On 01/22/2016 04:03 AM, Richard Biener wrote:


My guess is this is probably suppose to be
&& ! VOID_TYPE_P (TREE_TYPE (TREE_OPERAND (tem, 1)))
  && ! VOID_TYPE_P (TREE_TYPE (TREE_OPERAND (tem, 2)))

but I'm not sure.   Any guesses whats intended here?


Not sure, it might be to detect some of the x ? : throw () constructs
but not sure how those would survive the previous == code check.
Maybe a ? (void) ... : (void) ... is supposed to be detected.

The type check below would catch that as well
(huh?  a flag_syntax_only check in fold-const.c!?)

I'd say change to ! VOID_TYPE_P (TREE_TYPE (TREE_OPERAND (tem, 1))
to match what the VOID_TYPE_P check does above this block.
It's definitely to catch cases where one or both branches of a COND_EXPR 
have a void type due to throwing an exception and other non-returning 
things.


See:
https://gcc.gnu.org/ml/gcc-patches/2002-10/msg00873.html

Andrew if you wanted to be particularly sure, you could check out
c2ad71a27166be748562a41f50bc9bd2f252e85d

And build it (ha!, good luck with that) and see what the code does with 
the old g77.dg/execute/7388.f test :_)


Or maybe you might get lucky and the 7388.f test will still get into 
that path and you can poke around more directly.


Jeff

Re: [PATCH] Fix PR69336

[Dominik Vogt]

On Tue, Jan 19, 2016 at 10:08:17AM +0100, Richard Biener wrote:
> 
> The following patch enhances the recent change to DOMs memory reference
> value-numbering to cover PR69336 (all handled components instead of
> just ones with outermost ARRAY_REF).
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu.

The new test case fails on s390x:

-- snip --
  void * D.35681;
  size_t n;
  const struct static_map cmap;
  const char * _4;
  int _5;
  int _11;
  void * _15;
  int _25;

  :
  cmap = *.LC3;
  _5 = cmap._values[0].second.first;
  if (_5 == 8)
goto ;
  else
goto ;

  :
  _25 = cmap._values[1].second.first;
  if (_25 == 8)
goto ;
  else
goto ;

  :
  _11 = cmap._values[2].second.first;
  if (_11 == 8)
goto ;
  else
goto ;

  :
  # n_8 = PHI <2(4), 0(2), 1(3)>
  _4 = MEM[(const char * const &)&cmap]._values[n_8].second.second;
  if (_4 == 0B)
goto ;
  else
goto ;

  :
  _15 = __cxa_allocate_exception (16);
  std::out_of_range::out_of_range (_15, "Key not found");

  :
  __cxa_throw (_15, &_ZTISt12out_of_range, __comp_dtor );

:
  __cxa_free_exception (_15);
  _3 = __builtin_eh_pointer (5);
  __builtin_unwind_resume (_3);

  :
  abort ();

  :
  cmap ={v} {CLOBBER};
  return 0;
-- snip --

> 2016-01-19  Richard Biener  
> 
>   PR tree-optimization/69336
>   * tree-ssa-scopedtables.c (avail_expr_hash): Handle all
>   handled components with get_ref_base_and_extent.
>   (equal_mem_array_ref_p): Adjust.
> 
>   * g++.dg/tree-ssa/pr69336.C: New testcase.
> 
> Index: gcc/tree-ssa-scopedtables.c
> ===
> *** gcc/tree-ssa-scopedtables.c   (revision 232508)
> --- gcc/tree-ssa-scopedtables.c   (working copy)
> *** avail_expr_hash (class expr_hash_elt *p)
> *** 214,220 
>   {
> /* T could potentially be a switch index or a goto dest.  */
> tree t = expr->ops.single.rhs;
> !   if (TREE_CODE (t) == MEM_REF || TREE_CODE (t) == ARRAY_REF)
>   {
> /* Make equivalent statements of both these kinds hash together.
>Dealing with both MEM_REF and ARRAY_REF allows us not to care
> --- 214,220 
>   {
> /* T could potentially be a switch index or a goto dest.  */
> tree t = expr->ops.single.rhs;
> !   if (TREE_CODE (t) == MEM_REF || handled_component_p (t))
>   {
> /* Make equivalent statements of both these kinds hash together.
>Dealing with both MEM_REF and ARRAY_REF allows us not to care
> *** avail_expr_hash (class expr_hash_elt *p)
> *** 251,259 
>   static bool
>   equal_mem_array_ref_p (tree t0, tree t1)
>   {
> !   if (TREE_CODE (t0) != MEM_REF && TREE_CODE (t0) != ARRAY_REF)
>   return false;
> !   if (TREE_CODE (t1) != MEM_REF && TREE_CODE (t1) != ARRAY_REF)
>   return false;
>   
> if (!types_compatible_p (TREE_TYPE (t0), TREE_TYPE (t1)))
> --- 251,259 
>   static bool
>   equal_mem_array_ref_p (tree t0, tree t1)
>   {
> !   if (TREE_CODE (t0) != MEM_REF && ! handled_component_p (t0))
>   return false;
> !   if (TREE_CODE (t1) != MEM_REF && ! handled_component_p (t1))
>   return false;
>   
> if (!types_compatible_p (TREE_TYPE (t0), TREE_TYPE (t1)))
> Index: gcc/testsuite/g++.dg/tree-ssa/pr69336.C
> ===
> *** gcc/testsuite/g++.dg/tree-ssa/pr69336.C   (revision 0)
> --- gcc/testsuite/g++.dg/tree-ssa/pr69336.C   (working copy)
> ***
> *** 0 
> --- 1,86 
> + // { dg-do compile }
> + // { dg-options "-O3 -fdump-tree-optimized -std=c++14" }
> + 
> + #include 
> + #include 
> + 
> + 
> + template struct static_map
> + {
> +   using key_type = Key;
> +   using mapped_type = T;
> +   using value_type = std::pair;
> + private:
> +   using _value_type = std::pair;
> +   _value_type _values[N];
> +   static constexpr _value_type _new_value_type(const std::pair &v)
> +   {
> + return std::make_pair(0, std::make_pair(v.first, v.second));
> +   }
> + public:
> +   template constexpr static_map(U &&...il) : _values{ 
> _new_value_type(il)... } { }
> +   constexpr mapped_type &operator[](const key_type &k) { return at(k); }
> +   constexpr const mapped_type &operator[](const key_type &k) const { return 
> at(k); }
> +   constexpr mapped_type &at(const key_type &k)
> +   {
> + for (size_t n = 0; n < N; n++)
> +   if (_values[n].second.first == k)
> + return _values[n].second.second;
> + throw std::out_of_range("Key not found");
> +   }
> +   constexpr const mapped_type &at(const key_type &k) const
> +   {
> + for (size_t n = 0; n < N; n++)
> +   if (_values[n].second.first == k)
> + return _values[n].second.second;
> + throw std::out_of_range("Key not found");
> +   }
> + };
> + namespace detail
> + {
> +   template constexpr 
> static_map static_map_from_array(const std::pair(&il)[N], 
> std::index_sequence)
> +   {
> + retur

Re: [PATCH] fix #69317 - [6 regression] wrong ABI version in -Wabi warnings

[Jeff Law]

On 01/25/2016 09:56 AM, Martin Sebor wrote:

Ping: I'm looking a review/approval of the almost trivial patch
below:

https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01206.html

On 01/16/2016 05:42 PM, Martin Sebor wrote:

While adding an ABI warning in the patch for bug 69277 I noticed
that the ABI version printed by GCC 6.0 in some -Wabi diagnostics
is incorrect:  while 5.1.0 prints the versions of the ABI given
by the -Wabi=X and -fabi-version=Y options (i.e., it mentions
both X and Y), 6.0 prints the same version twice (just Y).

The attached patch fixes this and adds tests to verify that the
referenced versions are as expected (it uses ABIs 2 and 3 but
tests exercising the other ABI changes should be added as well).

OK.

Jeff

Re: [wwwdocs][PATCH] Add notes on -Wmisleading-indentation to GCC 6 porting guide

[Jeff Law]

On 01/26/2016 01:41 PM, David Malcolm wrote:

htdocs/gcc-6/porting_to.html is looking rather empty right now.  The
attached patch starts fleshing it out by adding some notes on
-Wmisleading-indentation.

[see the notes at https://gcc.gnu.org/ml/gcc/2016-01/msg00224.html on
what -Wmisleading-indentation ran into on a mass-rebuild of Debian]

I put it apart from the existing headings as it relates to both C and to
C++.

Validates.

OK to commit?

OK.
jeff

Re: RFA: Fix for cygwin/mingw PR 66655

[Jeff Law]

On 01/26/2016 07:34 AM, Nick Clifton wrote:

Hi Guys,

   The patch below is offered as a fix for PR 66655.  In testing it
   appears that the patch does work, and does not break building
   libstdc++-v3 for cygwin or mingw.  (Unlike the earlier version...)

   Due to my brain being so small, I have already checked the patch in,
   without receiving proper authorisation.  I apologise for this.  If the
   patch does prove suitable and is approved today, then I will leave it
   in.  Otherwise I will revert the change and wait for proper approval.

   The patch itself is also slightly dubious in that I am not sure if I
   have all the correct terms in the if-statement.  I was going for
   minimal impact on the current code, so I went for a set of selectors
   that matched the testcase for PR 66655, but nothing else.  In
   particular I did not check to see if a similar problem exists for
   methods or virtual functions.

   My theory was that if does turn out that these kinds of functions can
   also trigger this kind of bug, then the patch could be extended
   later.  Plus a new bug report is likely to include a new testcase that
   can be added to the testsuite.

   So ... OK to apply ?

Cheers
   Nick

gcc/ChangeLog
2016-01-26  Nick Clifton  

PR target/66655
* config/i386/winnt.c (i386_pe_binds_local_p): If a function has
been marked as DECL_ONE_ONLY but we do not the means to make it
so, then do not allow it to bind locally.

This is OK.

Note that in general we're trying to get away from this kind of 
#if[n]def checking and instead use if (whatever).  The motivation is to 
avoid conditionally compiled code as much as possible.  That avoids lots 
of silly problems that we have to deal with far too often (like 
variables/arguments that are only used inside conditionally compiled 
code and similar stuff.


MAKE_DECL_ONE_ONLY is used elsewhere to create conditionally compiled 
code and we're in stage4, so I'm not going to insist on converting it 
right now.


And FWIW, with Kai leaving, we don't really have a cygwin/mingw 
maintainer.  So I really appreciate the effort you and others have put 
forth to addressing these issues -- if you didn't put forth that effort 
I suspect the windows based toolchains would probably be fairly broken 
for gcc-6.


jeff

Re: NetBSD has SSP in libc

[Thomas Klausner]

On Tue, Jan 26, 2016 at 11:35:15PM -0700, Jeff Law wrote:
> On 01/23/2016 02:52 PM, Thomas Klausner wrote:
> >NetBSD has SSP included in libc:
> >
> >http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/ssp/?only_with_tag=MAIN
> >
> >gcc/configure does not know about this. The attached patch (against
> >SVN checkout from today) fixes this.
> >
> >I've previously reported this as
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68380 but was told that
> >patches should be sent here.
> Thanks.
> 
> If I understand the history SSP first appeared in NetBSD 4.0, so this code
> really ought to be conditional on NetBSD 4.0 or newer to be strictly
> correct.
> 
> Unfortunately we don't have much interaction with NetBSD anymore -- so we
> have no clue if supporting building on anything before NetBSD 4.0 is even
> reasonable or feasible anymore.

The only supported release branches are NetBSD-6.x and NetBSD-7.x.

NetBSD-4.x was desupported when NetBSD 6.x came out, in 2012:
https://blog.netbsd.org/tnf/entry/end_of_life_for_4

 Thomas

Re: [PATCH, testsuite] Fix g++.dg/pr67989.C test failure when running with -march or -mcpu

[Thomas Preud'homme]

Ping?

On Monday, January 18, 2016 11:33:47 AM Thomas Preud'homme wrote:
> On Wednesday, January 13, 2016 06:39:20 PM Bernd Schmidt wrote:
> > On 01/12/2016 08:55 AM, Thomas Preud'homme wrote:
> > > On Monday, January 11, 2016 04:57:18 PM Bernd Schmidt wrote:
> > >> On 01/08/2016 10:33 AM, Thomas Preud'homme wrote:
> > >>> 2016-01-08  Thomas Preud'homme  
> > >>> 
> > >>>   * g++.dg/pr67989.C: Remove ARM-specific option.
> > >>>   * gcc.target/arm/pr67989.C: New file.
> > >> 
> > >> I checked some other arm tests and they have things like
> > >> 
> > >> /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } {
> > >> "-march=*" } { "-march=armv4t" } } */
> > >> /* { dg-skip-if "avoid conflicting multilib options" { *-*-* } {
> > >> "-mthumb" } { "" } } */
> > >> 
> > >> Do you need the same in your testcase?
> > > 
> > > That was the first approach I took but Kyrill suggested me to use
> > > arm_arch_v4t and arm_arch_v4t_ok machinery instead. It should take care
> > > about whether the architecture can be selected.
> > 
> > Hmm, the ones I looked at did use dg-add-options, but not the
> > corresponding _ok requirement. So I think this is OK.
> 
> Just to make sure: ok as in OK to commit as is?
> 
> Best regards,
> 
> Thomas

Re: NetBSD has SSP in libc

[Jeff Law]

On 01/23/2016 02:52 PM, Thomas Klausner wrote:

NetBSD has SSP included in libc:

http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/ssp/?only_with_tag=MAIN

gcc/configure does not know about this. The attached patch (against
SVN checkout from today) fixes this.

I've previously reported this as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68380 but was told that
patches should be sent here.

Thanks.

If I understand the history SSP first appeared in NetBSD 4.0, so this 
code really ought to be conditional on NetBSD 4.0 or newer to be 
strictly correct.


Unfortunately we don't have much interaction with NetBSD anymore -- so 
we have no clue if supporting building on anything before NetBSD 4.0 is 
even reasonable or feasible anymore.


Jeff

Re: new port: vn8

[Nguyễn Sinh Ngọc]

Hello Mike Stump,

Thanks for your comment.
I'll remove all of redundant code for this target.

I wonder that what paper is?
Is it an introduction about new feature in our target?

On Wed, Jan 27, 2016 at 5:53 AM, Mike Stump  wrote:
> I don’t see the point of libgcc/config/vn8/test.patch.  I suspect either you 
> need to apply it to your diffs before you send them out, or remove the file a 
> junk from the diff set.
>
> I saw:
>
>   inflating: libgcc/config/vn8/lib1funcs-fixed.S
>   inflating: libgcc/config/vn8/lib1funcs-fixed.S.old
>   inflating: libgcc/config/vn8/lib1funcs.S
>   inflating: libgcc/config/vn8/lib1funcs.S.old
>
> and suspect the .old files are old, and aren’t used by the build.  If so, 
> they can be removed.
>
> I saw:
>
>   inflating: gcc/config/vn8/vn8.md.bak
>   inflating: gcc/config/vn8/vn8.md.bk
>   inflating: gcc/config/vn8/t-vn8.bak
>
> and suspect these aren’t needed (or are badly named) and should be removed.
>
> I glanced at the non-port files, and all that code looks fine.
>
>> I used gcc-4.9.0 version for new port.
>
> So, you will want to check out a copy of the compiler from git or svn.  You 
> will want to do this checkout from the trunk.  You then want to apply your 
> patch set to it, and build and test it, fixing any issues that arise, and 
> then contribute that.  The patch set you sent would be a back port to a 
> release branch, if any, and would come after the port is accepted into trunk.
>
>> //  output_addr_const (stderr, addr);
>> //  fprintf(stderr,"\n”);
>> //  rtx temp_rtx = XEXP(XEXP(x,0),0);
>
> It is now time to figure out what to do with this code.  If you like it and 
> want to keep it, instead do:
>
> #define PORTDEBUGGING 0
>
>   if (PORTDEBUGGING)
> {
> }
>
> and turn it into normal code.
>
>> #if 0
>> ADJUST_BYTESIZE (QI, 1);
>> ADJUST_BYTESIZE (HI, 1);
>> ADJUST_BYTESIZE (SI, 2);
>> ADJUST_BYTESIZE (PSI, 3);
>> ADJUST_BYTESIZE (DI, 4);
>> ADJUST_BYTESIZE (TI, 8);
>> #endif // 1
>
> You should just remove the whole block.
>
>
> I’d recommend fixing all the above and reposting.  Someone else will do a 
> more in depth port review and comment further.
>
> If you don’t have your paper work done, you will want to start up that 
> process now.  The port can’t go into the compiler without it.
>
>
>
> One last comment, while you wait for the review of the port code, you should 
> consider your FIXMEs and decide if there is any progress you can make on them.
>
> ./gcc/config/vn8/vn8.c:  /* FIXME: For setjmp and in 
> vn8_builtin_setjmp_frame_value we don't know
> ./gcc/config/vn8/vn8.c:  /* FIXME:  Non-generic addresses are not 
> mode-dependent in themselves.
> ./gcc/config/vn8/vn8.c:  /* FIXME: We ship info on failing tail-call in 
> struct machine_function.
> ./gcc/config/vn8/vn8.c:  /* FIXME: For OS_task and OS_main, this might be 
> over-conservative.  */
> ./gcc/config/vn8/vn8.c:  /* FIXME: Ideally, the following test is not needed.
> ./gcc/config/vn8/vn8.c:  /* FIXME: This hook gets called with MODE:REGNO 
> combinations that don't
> ./gcc/config/vn8/vn8.c: FIXME: Filter out cases where the target object 
> is known to
> ./gcc/config/vn8/vn8.c:  /* FIXME: Register allocator might come up with 
> spill fails if it is left
> ./gcc/config/vn8/vn8.c:  /* FIXME: Register allocator does a bad job and 
> might spill address



-- 
Thanks & Best regards
Nguyễn Sinh Ngọc
Software Department
IC Design & Research Education Center
Email: ngoc.nguyens...@icdrec.edu.vn
Cell Phone: +84 (0)974117946

Re: C++ PATCH for c++/69496 (ICE on VLA in constexpr function)

[Martin Sebor]

On 01/26/2016 04:02 PM, Marek Polacek wrote:

The (invalid) testcase was causing an ICE because we were passing the result
of array_type_nelts_top immediately into tree_int_cst_lt, but for VLAs, the
result doesn't have to be a constant.  Fixed by evaluating the bound of the
array so that we're able to give a proper out-of-bounds diagnostics.  And the
VERIFY_CONSTANT should ensure that if the array bound couldn't be reduced to
a constant, we bail out rather than evoke an ICE.


Wow, you are quick! :)

I wonder if it might be better to instead reject VLAs in constexpr
functions altogether.  Not because they're not in C++, but because
C (or gcc) doesn't allow them to be initialized (and so accepting
an initialized VLA is a g++ extension of an extension), and
because in constexpr functions they are rejected without
initialization just like other uninitialized variables.

FWIW, it seems to me the fewer extensions we support the less risk
of something going wrong because of unforeseen interactions with
other features.

Martin

Re: [PATCH 1/3] [D] libiberty: Correctly decode function pointer types.

[Iain Buclaw]

On 27 January 2016 at 01:49, Ian Lance Taylor  wrote:
> On Tue, Jan 26, 2016 at 4:30 PM, Iain Buclaw  wrote:
>>
>> This patch series ultimately supports recent support for
>> extern(Objective-C) functions.  However this simple addition exposed
>> two nasty bugs in the process.
>>
>> This addresses demangling function types.  In real symbols, function
>> types are only ever seen following the pointer type symbol 'P'.  So
>> this is reflected in both code and tests.
>
> This is OK.
>
> Thanks.
>
> Ian

That was a very prompt response!  Committing to trunk now...

Regards
Iain.

Re: [PATCH 1/3] [D] libiberty: Correctly decode function pointer types.

[Ian Lance Taylor]

On Tue, Jan 26, 2016 at 4:30 PM, Iain Buclaw  wrote:
>
> This patch series ultimately supports recent support for
> extern(Objective-C) functions.  However this simple addition exposed
> two nasty bugs in the process.
>
> This addresses demangling function types.  In real symbols, function
> types are only ever seen following the pointer type symbol 'P'.  So
> this is reflected in both code and tests.

This is OK.

Thanks.

Ian

Re: [PATCH 3/3] [D] libiberty: Handle the new extern(Objective-C) calling convention

[Ian Lance Taylor]

On Tue, Jan 26, 2016 at 4:41 PM, Iain Buclaw  wrote:
> Finally, recognizing the extern(Objective-C) symbol 'Y'.

This is OK.

Thanks.

Ian

[PATCH 3/3] [D] libiberty: Handle the new extern(Objective-C) calling convention

[Iain Buclaw]

Finally, recognizing the extern(Objective-C) symbol 'Y'.

Iain.
---
libiberty/

 2016-01-26  Iain Buclaw  
 
	* d-demangle.c (dlang_call_convention): Handle extern Objective-C
	function calling convention.
	(dlang_call_convention_p): Likewise.
	(dlang_type): Likewise.
	* testsuite/d-demangle-expected: Add coverage tests.

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index 9e5a8043..4ad90a6 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -223,6 +223,10 @@ dlang_call_convention (string *decl, const char *mangled)
   mangled++;
   string_append (decl, "extern(C++) ");
   break;
+case 'Y': /* (Objective-C) */
+  mangled++;
+  string_append (decl, "extern(Objective-C) ");
+  break;
 default:
   return NULL;
 }
@@ -539,7 +543,7 @@ dlang_type (string *decl, const char *mangled)
   switch (*mangled)
 	{
 	case 'F': case 'U': case 'W':
-	case 'V': case 'R':
+	case 'V': case 'R': case 'Y':
 	  mangled = dlang_function_type (decl, mangled);
 	  string_append (decl, "function");
 	  return mangled;
@@ -1338,7 +1342,7 @@ dlang_call_convention_p (const char *mangled)
   switch (*mangled)
 {
 case 'F': case 'U': case 'V':
-case 'W': case 'R':
+case 'W': case 'R': case 'Y':
   return 1;
 
 default:
diff --git a/libiberty/testsuite/d-demangle-expected b/libiberty/testsuite/d-demangle-expected
index 8f0b167..04d39f4 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -394,6 +394,10 @@ _D8demangle4testFDRZaZv
 demangle.test(extern(C++) char() delegate)
 #
 --format=dlang
+_D8demangle4testFDYZaZv
+demangle.test(extern(Objective-C) char() delegate)
+#
+--format=dlang
 _D8demangle4testFPFZaZv
 demangle.test(char() function)
 #
@@ -414,6 +418,10 @@ _D8demangle4testFPRZaZv
 demangle.test(extern(C++) char() function)
 #
 --format=dlang
+_D8demangle4testFPYZaZv
+demangle.test(extern(Objective-C) char() function)
+#
+--format=dlang
 _D8demangle4testFDFNaZaZv
 demangle.test(char() pure delegate)
 #

Re: [PATCH 2/3] [D] libiberty: Fix demangling of D-style variadic functions

[Ian Lance Taylor]

On Tue, Jan 26, 2016 at 4:36 PM, Iain Buclaw  wrote:
> This one fixes support for D-style variadic functions, specifically
> where non-variadic parameters can be omitted entirely.

This is OK.

Thanks.

Ian

[PATCH 2/3] [D] libiberty: Fix demangling of D-style variadic functions

[Iain Buclaw]

This one fixes support for D-style variadic functions, specifically
where non-variadic parameters can be omitted entirely.

Iain
---
libiberty/

 2016-01-26  Iain Buclaw  
 
	* d-demangle.c (dlang_function_args): Append ',' for variadic functions
	only if parameters were seen before the elipsis symbol.
	* testsuite/d-demangle-expected: Add coverage test for parameter-less
	variadic functions.

diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index 9c4d459..9e5a8043 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -399,7 +399,9 @@ dlang_function_args (string *decl, const char *mangled)
 	  return mangled;
 	case 'Y': /* (variadic T t, ...) style.  */
 	  mangled++;
-	  string_append (decl, ", ...");
+	  if (n != 0)
+	string_append (decl, ", ");
+	  string_append (decl, "...");
 	  return mangled;
 	case 'Z': /* Normal function.  */
 	  mangled++;
diff --git a/libiberty/testsuite/d-demangle-expected b/libiberty/testsuite/d-demangle-expected
index 11785f2..8f0b167 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -342,6 +342,10 @@ _D8demangle4testFaaYv
 demangle.test(char, char, ...)
 #
 --format=dlang
+_D8demangle4testFYv
+demangle.test(...)
+#
+--format=dlang
 _D8demangle4testFaaZv
 demangle.test(char, char)
 #

[PATCH 1/3] [D] libiberty: Correctly decode function pointer types.

[Iain Buclaw]

Hi,

This patch series ultimately supports recent support for
extern(Objective-C) functions.  However this simple addition exposed
two nasty bugs in the process.

This addresses demangling function types.  In real symbols, function
types are only ever seen following the pointer type symbol 'P'.  So
this is reflected in both code and tests.

Iain.
---
libiberty/

	* d-demangle.c (dlang_type): Handle function types only in the context
	of seeing a pointer type symbol.
	* testsuite/d-demangle-expected: Update function pointer tests.
 
difVf --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index 3d7ccf6..9c4d459 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -1,5 +1,5 @@
 /* Demangler for the D programming language
-   Copyright 2014, 2015 Free Software Foundation, Inc.
+   Copyright 2014, 2015, 2016 Free Software Foundation, Inc.
Written by Iain Buclaw (ibuc...@gdcproject.org)
 
 This file is part of the libiberty library.
@@ -533,6 +533,15 @@ dlang_type (string *decl, const char *mangled)
 }
 case 'P': /* pointer (T*) */
   mangled++;
+  /* Function pointer types don't include the trailing asterisk.  */
+  switch (*mangled)
+	{
+	case 'F': case 'U': case 'W':
+	case 'V': case 'R':
+	  mangled = dlang_function_type (decl, mangled);
+	  string_append (decl, "function");
+	  return mangled;
+	}
   mangled = dlang_type (decl, mangled);
   string_append (decl, "*");
   return mangled;
@@ -564,13 +573,6 @@ dlang_type (string *decl, const char *mangled)
   mangled++;
   return dlang_parse_tuple (decl, mangled);
 
-/* Function types */
-case 'F': case 'U': case 'W':
-case 'V': case 'R':
-  mangled = dlang_function_type (decl, mangled);
-  string_append (decl, "function");
-  return mangled;
-
 /* Basic types */
 case 'n':
   mangled++;
diff --git a/libiberty/testsuite/d-demangle-expected b/libiberty/testsuite/d-demangle-expected
index 2b1cc4f..11785f2 100644
--- a/libiberty/testsuite/d-demangle-expected
+++ b/libiberty/testsuite/d-demangle-expected
@@ -390,23 +390,23 @@ _D8demangle4testFDRZaZv
 demangle.test(extern(C++) char() delegate)
 #
 --format=dlang
-_D8demangle4testFFZaZv
+_D8demangle4testFPFZaZv
 demangle.test(char() function)
 #
 --format=dlang
-_D8demangle4testFUZaZv
+_D8demangle4testFPUZaZv
 demangle.test(extern(C) char() function)
 #
 --format=dlang
-_D8demangle4testFWZaZv
+_D8demangle4testFPWZaZv
 demangle.test(extern(Windows) char() function)
 #
 --format=dlang
-_D8demangle4testFVZaZv
+_D8demangle4testFPVZaZv
 demangle.test(extern(Pascal) char() function)
 #
 --format=dlang
-_D8demangle4testFRZaZv
+_D8demangle4testFPRZaZv
 demangle.test(extern(C++) char() function)
 #
 --format=dlang
@@ -466,59 +466,59 @@ _D8demangle4testFNjNkDFNjZaZv
 demangle.test(return char() return delegate)
 #
 --format=dlang
-_D8demangle4testFFNaZaZv
+_D8demangle4testFPFNaZaZv
 demangle.test(char() pure function)
 #
 --format=dlang
-_D8demangle4testFFNbZaZv
+_D8demangle4testFPFNbZaZv
 demangle.test(char() nothrow function)
 #
 --format=dlang
-_D8demangle4testFFNcZaZv
+_D8demangle4testFPFNcZaZv
 demangle.test(char() ref function)
 #
 --format=dlang
-_D8demangle4testFFNdZaZv
+_D8demangle4testFPFNdZaZv
 demangle.test(char() @property function)
 #
 --format=dlang
-_D8demangle4testFFNeZaZv
+_D8demangle4testFPFNeZaZv
 demangle.test(char() @trusted function)
 #
 --format=dlang
-_D8demangle4testFFNfZaZv
+_D8demangle4testFPFNfZaZv
 demangle.test(char() @safe function)
 #
 --format=dlang
-_D8demangle4testFFNiZaZv
+_D8demangle4testFPFNiZaZv
 demangle.test(char() @nogc function)
 #
 --format=dlang
-_D8demangle4testFFNaNbZaZv
+_D8demangle4testFPFNaNbZaZv
 demangle.test(char() pure nothrow function)
 #
 --format=dlang
-_D8demangle4testFFNbNaZaZv
+_D8demangle4testFPFNbNaZaZv
 demangle.test(char() nothrow pure function)
 #
 --format=dlang
-_D8demangle4testFFNdNfNaZaZv
+_D8demangle4testFPFNdNfNaZaZv
 demangle.test(char() @property @safe pure function)
 #
 --format=dlang
-_D8demangle4testFNjFZaZv
+_D8demangle4testFNjPFZaZv
 demangle.test(char() function)
 #
 --format=dlang
-_D8demangle4testFNkFZaZv
+_D8demangle4testFNkPFZaZv
 demangle.test(return char() function)
 #
 --format=dlang
-_D8demangle4testFFNjZaZv
+_D8demangle4testFPFNjZaZv
 demangle.test(char() return function)
 #
 --format=dlang
-_D8demangle4testFNjNkFNjZaZv
+_D8demangle4testFNjNkPFNjZaZv
 demangle.test(return char() return function)
 #
 --format=dlang
@@ -989,7 +989,7 @@ object.TypeInfo_Array.argTypes(out TypeInfo, out TypeInfo)
 #
 --format=dlang
 _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv
-rt.dmain2._d_run_main(int, char**, extern(C) int(char[][]) function*).tryExec(scope void() delegate)
+rt.dmain2._d_run_main(int, char**, extern(C) int(char[][]) function).tryExec(scope void() delegate)
 #
 --format=dlang
 _D6object9Exception6__ctorMFNaNbNfAyaAyamC6object9ThrowableZC9Exception

Go patch committed: Don't crash on erroneous array return types

[Ian Lance Taylor]

This patch by Chris Manghane avoids a Go frontend crash on an
erroneous array return type.  This fixes
https://golang.org/issue/12939.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 232857)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-721c778adb8f99d8a6b7795dbad86013ccc9ba91
+9e68d67d65fd72b9b4f163f2f26e15cd0d3e2cd2
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/parse.cc
===
--- gcc/go/gofrontend/parse.cc  (revision 232239)
+++ gcc/go/gofrontend/parse.cc  (working copy)
@@ -419,6 +419,8 @@ Parse::array_type(bool may_use_ellipsis)
 }
 
   Type* element_type = this->type();
+  if (element_type->is_error_type())
+return Type::make_error_type();
 
   return Type::make_array_type(element_type, length);
 }

Re: [PATCH] Fix up wi::lrshift (PR c++/69399)

[Jakub Jelinek]

On Tue, Jan 26, 2016 at 01:55:41PM -0800, Mike Stump wrote:
> On Jan 26, 2016, at 1:26 PM, Jakub Jelinek  wrote:
> > will do cc1plus size comparison afterwards.
> 
> We know the dynamic check is larger.  You can’t tell the advantage of
> speed from size.  Better would be to time compiling any random large
> translation unit.
> 
> Nice to see that only 14 calls remain, that’s way better than the 34 I
> thought.

So, it seems probably the PR65656 changes made things actually significantly
worse, while I see a (small) difference in the generated code between the two
patches if I compile say tree-ssa-ccp.c with g++ 5.x, in the bootstrapped
compiler there is no difference at all, the compilers with either patch
have identical objdump -dr cc1plus.  Already at *.gimple time all the
relevant __builtin_constant_p are resolved and it seems all to 0.

So please agree on one of the two patches (don't care which), and I'll try
to distill a testcase to look at for PR65656.

Jakub

Re: Wonly-top-basic-asm

[David Wohlferd]

On 1/26/2016 8:11 AM, Segher Boessenkool wrote:

On Tue, Jan 26, 2016 at 01:11:36PM +0100, Bernd Schmidt wrote:

On 01/26/2016 01:29 AM, Segher Boessenkool wrote:


In my opinion we should not warn for any asm that means the same both
as basic and as extended asm.  The problem then becomes, what *is* the
meaning of a basic asm, what does it clobber.

I think this may be too hard to figure out in general without parsing
the asm string, which we don't really want to do.

That depends on the semantics of basic asm.  With the currently implemented
semantics, it is trivial.


Oh?

asm("cmp al, '#' # if (c == '#') {");

There's a '{', so it might look like it needs to be escaped, but it 
doesn't.  The '{' is just part of a comment.  And how do you know it's a 
comment?  Because of the comment marker (#).  And how do you know that 
it's a comment marker and not a literal?  Only by doing more assembler 
parsing that I'm prepared to write.


But more importantly, consider this MIPS statement:

   asm ("sync");

That is the same for both basic and extended.  But I absolutely want the 
warning to flag this statement.  This is exactly the kind of "broken" 
statement that people need to be able to find/fix right now.


And when Jeff makes the changes to basic asm for v7, people may want to 
be able to find the statements that are affected by that in order to 
*stop* clobbering so many registers.


I'm not clear what people would use this warning for if we made the 
change you are suggesting.


dw

gccgo patch committed: Don't crash on invalid array type declarations

[Ian Lance Taylor]

This patch by Chris Manghane fixes the Go frontend to not crash on an
invalid array type declaration that is not otherwise used.  This fixes
https://golang.org/issue/12937.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 232855)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-731941c155214d6158fa800e52ab3225c0b55f73
+721c778adb8f99d8a6b7795dbad86013ccc9ba91
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/gogo.cc
===
--- gcc/go/gofrontend/gogo.cc   (revision 232239)
+++ gcc/go/gofrontend/gogo.cc   (working copy)
@@ -2699,6 +2699,15 @@ Gogo::lower_parse_tree()
 {
   Lower_parse_tree lower_parse_tree(this, NULL);
   this->traverse(&lower_parse_tree);
+
+  // There might be type definitions that involve expressions such as the
+  // array length.  Make sure to lower these expressions as well.  Otherwise,
+  // errors hidden within a type can introduce unexpected errors into later
+  // passes.
+  for (std::vector::iterator p = this->verify_types_.begin();
+   p != this->verify_types_.end();
+   ++p)
+Type::traverse(*p, &lower_parse_tree);
 }
 
 // Lower a block.

C++ PATCH for c++/69496 (ICE on VLA in constexpr function)

[Marek Polacek]

The (invalid) testcase was causing an ICE because we were passing the result
of array_type_nelts_top immediately into tree_int_cst_lt, but for VLAs, the
result doesn't have to be a constant.  Fixed by evaluating the bound of the
array so that we're able to give a proper out-of-bounds diagnostics.  And the
VERIFY_CONSTANT should ensure that if the array bound couldn't be reduced to
a constant, we bail out rather than evoke an ICE.

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

2016-01-26  Marek Polacek  

PR c++/69496
* constexpr.c (cxx_eval_array_reference): Evaluate the number of
elements of the array.

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

diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
index 6b0e5a8..6324e45 100644
--- gcc/cp/constexpr.c
+++ gcc/cp/constexpr.c
@@ -1855,7 +1855,12 @@ cxx_eval_array_reference (const constexpr_ctx *ctx, tree 
t,
 
   if (!found)
 {
-  if (tree_int_cst_lt (index, array_type_nelts_top (TREE_TYPE (ary
+  tree nelts = array_type_nelts_top (TREE_TYPE (ary));
+  /* For VLAs, the number of elements won't be an integer constant.  */
+  nelts = cxx_eval_constant_expression (ctx, nelts, false, non_constant_p,
+   overflow_p);
+  VERIFY_CONSTANT (nelts);
+  if (tree_int_cst_lt (index, nelts))
{
  if (TREE_CODE (ary) == CONSTRUCTOR
  && CONSTRUCTOR_NO_IMPLICIT_ZERO (ary))
diff --git gcc/testsuite/g++.dg/cpp1y/constexpr-vla1.C 
gcc/testsuite/g++.dg/cpp1y/constexpr-vla1.C
index e69de29..a5615bb 100644
--- gcc/testsuite/g++.dg/cpp1y/constexpr-vla1.C
+++ gcc/testsuite/g++.dg/cpp1y/constexpr-vla1.C
@@ -0,0 +1,30 @@
+// PR c++/69496
+// { dg-do compile { target c++14 } }
+
+constexpr int
+fn_ok (int n)
+{
+__extension__ int a[n] = { };
+int z = 0;
+
+for (unsigned i = 0; i < sizeof (a) / sizeof (int); ++i)
+  z += a[i];
+
+return z;
+}
+
+
+constexpr int
+fn_not_ok (int n)
+{
+__extension__ int a[n] = { };
+int z = 0;
+
+for (unsigned i = 0; i < sizeof (a); ++i)
+  z += a[i];
+
+return z;
+}
+
+constexpr int n1 = fn_ok (3);
+constexpr int n2 = fn_not_ok (3); // { dg-error "array subscript out of bound" 
}

Marek

new port: vn8

[Mike Stump]

I don’t see the point of libgcc/config/vn8/test.patch.  I suspect either you 
need to apply it to your diffs before you send them out, or remove the file a 
junk from the diff set.

I saw:

  inflating: libgcc/config/vn8/lib1funcs-fixed.S  
  inflating: libgcc/config/vn8/lib1funcs-fixed.S.old  
  inflating: libgcc/config/vn8/lib1funcs.S  
  inflating: libgcc/config/vn8/lib1funcs.S.old  

and suspect the .old files are old, and aren’t used by the build.  If so, they 
can be removed.

I saw:

  inflating: gcc/config/vn8/vn8.md.bak  
  inflating: gcc/config/vn8/vn8.md.bk 
  inflating: gcc/config/vn8/t-vn8.bak  

and suspect these aren’t needed (or are badly named) and should be removed.

I glanced at the non-port files, and all that code looks fine.

> I used gcc-4.9.0 version for new port.

So, you will want to check out a copy of the compiler from git or svn.  You 
will want to do this checkout from the trunk.  You then want to apply your 
patch set to it, and build and test it, fixing any issues that arise, and then 
contribute that.  The patch set you sent would be a back port to a release 
branch, if any, and would come after the port is accepted into trunk.

> //  output_addr_const (stderr, addr); 
> //  fprintf(stderr,"\n”);
> //  rtx temp_rtx = XEXP(XEXP(x,0),0);

It is now time to figure out what to do with this code.  If you like it and 
want to keep it, instead do:

#define PORTDEBUGGING 0

  if (PORTDEBUGGING)
{
}

and turn it into normal code.

> #if 0
> ADJUST_BYTESIZE (QI, 1);
> ADJUST_BYTESIZE (HI, 1);
> ADJUST_BYTESIZE (SI, 2);
> ADJUST_BYTESIZE (PSI, 3);
> ADJUST_BYTESIZE (DI, 4);
> ADJUST_BYTESIZE (TI, 8);
> #endif // 1

You should just remove the whole block.


I’d recommend fixing all the above and reposting.  Someone else will do a more 
in depth port review and comment further.

If you don’t have your paper work done, you will want to start up that process 
now.  The port can’t go into the compiler without it.



One last comment, while you wait for the review of the port code, you should 
consider your FIXMEs and decide if there is any progress you can make on them.

./gcc/config/vn8/vn8.c:  /* FIXME: For setjmp and in 
vn8_builtin_setjmp_frame_value we don't know
./gcc/config/vn8/vn8.c:  /* FIXME:  Non-generic addresses are not 
mode-dependent in themselves.
./gcc/config/vn8/vn8.c:  /* FIXME: We ship info on failing tail-call in 
struct machine_function.
./gcc/config/vn8/vn8.c:  /* FIXME: For OS_task and OS_main, this might be 
over-conservative.  */
./gcc/config/vn8/vn8.c:  /* FIXME: Ideally, the following test is not needed.
./gcc/config/vn8/vn8.c:  /* FIXME: This hook gets called with MODE:REGNO 
combinations that don't
./gcc/config/vn8/vn8.c: FIXME: Filter out cases where the target object is 
known to
./gcc/config/vn8/vn8.c:  /* FIXME: Register allocator might come up with spill 
fails if it is left
./gcc/config/vn8/vn8.c:  /* FIXME: Register allocator does a bad job and might 
spill address

[testsuite] XFAIL gcc.c-torture/execute/stkalign.c on SPARC 64-bit

[Eric Botcazou]

This test is very convoluted, doesn't contain a single line of comment and 
apparently makes an invalid assumption (see PR testsuite/68886).

Tested on x86-64/Linux and SPARC64/Solaris, applied on the mainline.


2016-01-26  Eric Botcazou  

* gcc.c-torture/execute/stkalign.c: XFAIL run on SPARC 64-bit.

-- 
Eric BotcazouIndex: gcc.c-torture/execute/stkalign.c
===
--- gcc.c-torture/execute/stkalign.c	(revision 232773)
+++ gcc.c-torture/execute/stkalign.c	(working copy)
@@ -1,3 +1,4 @@
+/* { dg-xfail-run-if "invalid assumption" { sparc*-*-* && lp64 } "*" "" } */
 /* { dg-options "-fno-inline" } */
 
 #include 

Re: [PATCH, 4.9, rs6000, testsuite] Fix PR69479

[David Edelsohn]

On Tue, Jan 26, 2016 at 4:46 PM, Bill Schmidt
 wrote:
> Hi,
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69479 notes that
> gcc.dg/and-1.c fails a scan-assembler-not test for nand, but the test
> does pass in subsequent releases.  The test author indicates in comment
> #1 that we can just remove this test for powerpc*-*-*, which this patch
> does.  Verified for 4.9 on powerpc64le-unknown-linux-gnu.  Ok to commit
> to that branch?
>
> Thanks,
> Bill
>
>
> 2016-01-26  Bill Schmidt  
>
> * gcc.dg/and-1.c: Remove nand test for powerpc*-*-*.

Please use an XFAIL, not removing the target from the test.

Thanks, David

gccgo patch committed: avoid knock-on errors with impossibly large types

[Ian Lance Taylor]

This patch by Chris Manghane patches the Go frontend to avoid knock-on
errors when working with impossibly large types.  This fixes
https://golang.org/issue/12938.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 232239)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-c375f3bf470f94220149b486c947bb3eb57cde7d
+731941c155214d6158fa800e52ab3225c0b55f73
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc  (revision 232239)
+++ gcc/go/gofrontend/types.cc  (working copy)
@@ -2550,6 +2550,8 @@ Type::backend_type_size(Gogo* gogo, int6
 {
   if (!this->is_backend_type_size_known(gogo))
 return false;
+  if (this->is_error_type())
+return false;
   Btype* bt = this->get_backend_placeholder(gogo);
   *psize = gogo->backend()->type_size(bt);
   if (*psize == -1)
@@ -6453,7 +6455,7 @@ Array_type::slice_gc_symbol(Gogo* gogo,
   (*vals)->push_back(Expression::make_integer_ul(opval, uintptr_type, bloc));
   (*vals)->push_back(*offset);
 
-  if (element_size != 0)
+  if (element_size != 0 && ok)
 (*vals)->push_back(Expression::make_gc_symbol(element_type));
   this->advance_gc_offset(offset);
 }
@@ -6488,7 +6490,7 @@ Array_type::array_gc_symbol(Gogo* gogo,
   Type* element_type = this->element_type();
   if (bound < 1 || !element_type->has_pointer())
 this->advance_gc_offset(offset);
-  else if (bound == 1 || iwidth <= 4 * pwidth)
+  else if (ok && (bound == 1 || iwidth <= 4 * pwidth))
 {
   for (unsigned int i = 0; i < bound; ++i)
Type::gc_symbol(gogo, element_type, vals, offset, stack_size);

Re: [gomp4] Un-parallelized OpenACC kernels constructs with nvptx offloading: "avoid offloading"

[Martin Jambor]

On Fri, Jan 22, 2016 at 02:18:38PM +0100, Bernd Schmidt wrote:
> On 01/22/2016 09:36 AM, Jakub Jelinek wrote:
> >
> >I think it is a bad idea to go against what the user wrote.  Warning that
> >some code might not be efficient?  Perhaps (if properly guarded with some
> >warning option one can turn off, either on a per-source file or using
> >pragmas even more fine grained).  But by default not offloading?  That is
> >just wrong.
> 
> I'm leaning more towards Thomas' side of the argument. The kernels construct
> is a hint, a "do your best" request to the compiler. If the compiler sees
> that it can't parallelize a loop inside a kernels region, it's probably best
> not to offload it.
> 

Shouldn't such optimization feedback be output in MSG_NOTE dumps?
Vectorizer uses it to inform the user what it is doing, supposedly
with the intention to help the programmer find out why specific loops
are not vectorized (and run slowly).  I have also decided to use it to
inform the user whether a combination of OpenMP constructs is
gridified or not.

Unfortunately, notes seem to appear only in "detailed" dumps, which
often are not the best place for users to look into because of too
much information on gcc internals.  So the user interface aspect of
notes could perhaps be re-thought a bit.

In any event, I think that at least in the near term, good compiler
feedback could ease the efficient use of accelerators quite a lot,
like (they say) it did with early auto-vectorizing compilers.

Martin

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[H.J. Lu]

On Tue, Jan 26, 2016 at 1:40 PM, Jakub Jelinek  wrote:
> On Tue, Jan 26, 2016 at 01:21:52PM -0800, H.J. Lu wrote:
>> Like this:
>>
>> /* Returns true if TYPE is POD for the purpose of layout and an empty
>>class or an class with empty classes.  */
>>
>> static bool
>> is_empty_record (tree type)
>> {
>>   if (type == error_mark_node)
>> return false;
>>
>>   if (!CLASS_TYPE_P (type))
>> return false;
>>
>>   if (CLASSTYPE_NON_LAYOUT_POD_P (type))
>> return false;
>>
>>   gcc_assert (COMPLETE_TYPE_P (type));
>>
>>   if (CLASSTYPE_EMPTY_P (type))
>> return true;
>>
>>   tree field;
>>
>>   for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
>> if (TREE_CODE (field) == FIELD_DECL
>> && !DECL_ARTIFICIAL (field)
>> && !is_empty_record (TREE_TYPE (field)))
>>   return false;
>>
>>   return true;
>> }
>
> So you say that K1 in e.g.:
>
> struct A1 {}; struct A2 {};
> struct B1 { A1 a; A2 b; }; struct B2 { A1 a; A2 b; };
> struct C1 { B1 a; B2 b; }; struct C2 { B1 a; B2 b; };
> struct D1 { C1 a; C2 b; }; struct D2 { C1 a; C2 b; };
> struct E1 { D1 a; D2 b; }; struct E2 { D1 a; D2 b; };
> struct F1 { E1 a; E2 b; }; struct F2 { E1 a; E2 b; };
> struct G1 { F1 a; F2 b; }; struct G2 { F1 a; F2 b; };
> struct H1 { G1 a; G2 b; }; struct H2 { G1 a; G2 b; };
> struct I1 { H1 a; H2 b; }; struct I2 { H1 a; H2 b; };
> struct J1 { I1 a; I2 b; }; struct J2 { I1 a; I2 b; };
> struct K1 { J1 a; J2 b; };
> int v;
> __attribute__((noinline, noclone))
> K1 foo (int a, K1 x, int b)
> {
>   v = a + b;
>   return x;
> }
> K1 k, m;
> void
> bar (void)
> {
>   m = foo (1, k, 2);
> }
>
> is empty class?  What does clang do with this?
>
> Jakub

Revised:

/* Returns true if TYPE is POD of one-byte or less in size for the purpose
   of layout and an empty class or an class with empty classes.  */

static bool
is_empty_record (tree type)
{
  if (type == error_mark_node)
return false;

  if (!CLASS_TYPE_P (type))
return false;

  if (CLASSTYPE_NON_LAYOUT_POD_P (type))
return false;

  gcc_assert (COMPLETE_TYPE_P (type));

  if (CLASSTYPE_EMPTY_P (type))
return true;

  if (int_size_in_bytes (type) > 1)
return false;

  tree field;

  for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
if (TREE_CODE (field) == FIELD_DECL
&& !DECL_ARTIFICIAL (field)
&& !is_empty_record (TREE_TYPE (field)))
  return false;

  return true;
}


-- 
H.J.

Re: [Patch, fortran] PR69385 - [6 regression] ICE on valid with -fcheck=mem

[Paul Richard Thomas]

Dear Janus,

Thanks - committed as revision 232850.

I hope that this signals your return - we need your help!

Paul

On 25 January 2016 at 22:13, Janus Weil  wrote:
> Hi Paul,
>
> seems we were pretty well-synchronized in posting this (in the PR it
> sounded as if you wanted me to submit it ...)
>
> In any case, the patch is ok for my taste.
>
> Thanks!
>
> Cheers,
> Janus
>
>
>
> 2016-01-25 22:02 GMT+01:00 Paul Richard Thomas 
> :
>> Dear All,
>>
>> The initial report concerns initialization assignments that should be
>> excluded from the check for assignment of scalars to unallocated
>> arrays. This part is so trivial that it does not require a test. On
>> the other hand, the block that implemented the check was plain and
>> simple wrong and the rest of the patch corrects this. It is commented
>> such as to be fully comprehensible.
>>
>> Bootstrapped and regtested on FC21/x86_64 - OK for trunk and for
>> 5-branch when all the wrinkles (PR69422 and 69423) are sorted out?
>>
>> Cheers
>>
>> Paul
>>
>> 2016-01-25  Paul Thomas  
>>
>> PR fortran/69385
>> * trans-expr.c (gfc_trans_assignment_1): Exclude initialization
>> assignments from check on assignment of scalars to unassigned
>> arrays and correct wrong code within the corresponding block.
>>
>> 2015-01-25  Paul Thomas  
>>
>> PR fortran/69385
>> * gfortran.dg/allocate_error_6.f90: New test.



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

Albert Einstein

Re: [PATCH] Fix up wi::lrshift (PR c++/69399)

[Mike Stump]

On Jan 26, 2016, at 1:26 PM, Jakub Jelinek  wrote:
> will do cc1plus size comparison afterwards.

We know the dynamic check is larger.  You can’t tell the advantage of speed 
from size.  Better would be to time compiling any random large translation unit.

Nice to see that only 14 calls remain, that’s way better than the 34 I thought.

Re: [PATCH] Fix up wi::lrshift (PR c++/69399)

[Mike Stump]

On Jan 26, 2016, at 12:45 PM, Richard Biener  wrote:
> The original reasoning was to inline only the fast path if it is known at 
> compile time and otherwise have a call. Exactly to avoid bloating callers 
> with inlined conditionals.

That’s part of it.  And generally, yes, we do that.  One other part is, from 
the comment:

 For variable-precision integers like wide_int, handle HWI  
 
 and sub-HWI integers inline.  */

Before, we just did the shift directly.  This _was_ the fast path.  We bulk the 
fast path case by a shift check, because we want to ensure it is small enough 
to be well defined.  The code previously was the fast path, because almost all 
shifts ever run will be HWI or smaller and will be 63 bits or less shifted.  If 
we make the check static only, then we boost the existing fast path out into 
the subroutine call.  Since the condition is most always true and since the 
predicate is in a register for the subroutine call anyway, the extra check 
should be fairly light (one instruction slot, zero execution time, zero 
dependencies, one BHT slot pollution).  With 34 call sites, that should be 
around an additional 136 bytes to the executable.  I think that space is paid 
for by the speed different of the fast path and how often it hits.  But, would 
be nice to have a person that loves benchmarking compile times and just tell us 
which one is faster.  :-)  Anyone skilled at knowing which one is faster is 
free to change to the other form.  My confidence that I know which one is 
faster is small; I’m happy to defer to someone that is more confident than I.

[PATCH, 4.9, rs6000, testsuite] Fix PR69479

[Bill Schmidt]

Hi,

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69479 notes that
gcc.dg/and-1.c fails a scan-assembler-not test for nand, but the test
does pass in subsequent releases.  The test author indicates in comment
#1 that we can just remove this test for powerpc*-*-*, which this patch
does.  Verified for 4.9 on powerpc64le-unknown-linux-gnu.  Ok to commit
to that branch?

Thanks,
Bill


2016-01-26  Bill Schmidt  

* gcc.dg/and-1.c: Remove nand test for powerpc*-*-*.

Index: gcc/testsuite/gcc.dg/and-1.c
===
--- gcc/testsuite/gcc.dg/and-1.c(revision 232844)
+++ gcc/testsuite/gcc.dg/and-1.c(working copy)
@@ -1,8 +1,8 @@
 /* { dg-do compile } */
 /* { dg-options "-O2" } */
 /* { dg-final { scan-assembler "and" { target powerpc*-*-* spu-*-* } } } */
-/* There should be no nand for this testcase (for either PPC or SPU). */
-/* { dg-final { scan-assembler-not "nand" { target powerpc*-*-* spu-*-* } } } 
*/
+/* There should be no nand for this testcase for SPU. */
+/* { dg-final { scan-assembler-not "nand" { target spu-*-* } } } */
 
 int f(int y)
 {

GCC 5 libgo patch committed: Update mksysinfo on GCC 5 branch

[Ian Lance Taylor]

I've committed this patch to the GCC 5 branch to update
libgo/mksysinfo.sh to bring in recent changes on mainline.  This
brings in https://golang.org/cl/17893, https://golang.org/cl/16588,
https://golang.org/cl/16580, https://golang.org/cl/16534,
https://golang.org/cl/14858.  The patch was put together by Lynn
Boger.  Bootstrapped and ran Go tests on x86_64-pc-linux-gnu.
Committed to GCC 5 branch.

Ian
Index: libgo/mksysinfo.sh
===
--- libgo/mksysinfo.sh  (revision 232844)
+++ libgo/mksysinfo.sh  (working copy)
@@ -183,6 +183,12 @@ enum {
 #ifdef TIOCSCTTY
   TIOCSCTTY_val = TIOCSCTTY,
 #endif
+#ifdef TIOCGPGRP
+  TIOCGPGRP_val = TIOCGPGRP,
+#endif
+#ifdef TIOCSPGRP
+  TIOCSPGRP_val = TIOCSPGRP,
+#endif
 #ifdef TIOCGPTN
   TIOCGPTN_val = TIOCGPTN,
 #endif
@@ -534,7 +540,7 @@ upcase_fields () {
 # GNU/Linux specific; it should do no harm if there is no
 # _user_regs_struct.
 regs=`grep '^type _user_regs_struct struct' gen-sysinfo.go || true`
-if test "$regs" == ""; then
+if test "$regs" = ""; then
   # s390
   regs=`grep '^type __user_regs_struct struct' gen-sysinfo.go || true`
   if test "$regs" != ""; then
@@ -878,11 +884,13 @@ grep '^type _addrinfo ' gen-sysinfo.go |
   -e 's/ ai_/ Ai_/g' \
 >> ${OUT}
 
-# The addrinfo flags and errors.
+# The addrinfo and nameinfo flags and errors.
 grep '^const _AI_' gen-sysinfo.go | \
   sed -e 's/^\(const \)_\(AI_[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
 grep '^const _EAI_' gen-sysinfo.go | \
   sed -e 's/^\(const \)_\(EAI_[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
+grep '^const _NI_' gen-sysinfo.go | \
+  sed -e 's/^\(const \)_\(NI_[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
 
 # The passwd struct.
 grep '^type _passwd ' gen-sysinfo.go | \
@@ -918,6 +926,16 @@ if ! grep '^const TIOCSCTTY' ${OUT} >/de
 echo 'const TIOCSCTTY = _TIOCSCTTY_val' >> ${OUT}
   fi
 fi
+if ! grep '^const TIOCGPGRP' ${OUT} >/dev/null 2>&1; then
+  if grep '^const _TIOCGPGRP_val' ${OUT} >/dev/null 2>&1; then
+echo 'const TIOCGPGRP = _TIOCGPGRP_val' >> ${OUT}
+  fi
+fi
+if ! grep '^const TIOCSPGRP' ${OUT} >/dev/null 2>&1; then
+  if grep '^const _TIOCSPGRP_val' ${OUT} >/dev/null 2>&1; then
+echo 'const TIOCSPGRP = _TIOCSPGRP_val' >> ${OUT}
+  fi
+fi
 if ! grep '^const TIOCGPTN' ${OUT} >/dev/null 2>&1; then
   if grep '^const _TIOCGPTN_val' ${OUT} >/dev/null 2>&1; then
 echo 'const TIOCGPTN = _TIOCGPTN_val' >> ${OUT}
@@ -1433,6 +1451,11 @@ grep '^type _inotify_event ' gen-sysinfo
 # The GNU/Linux CLONE flags.
 grep '^const _CLONE_' gen-sysinfo.go | \
   sed -e 's/^\(const \)_\(CLONE_[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
+# We need some CLONE constants that are not defined in older versions
+# of glibc.
+if ! grep '^const CLONE_NEWUSER ' ${OUT} > /dev/null 2>&1; then
+  echo "const CLONE_NEWUSER = 0x1000" >> ${OUT}
+fi
 
 # Struct sizes.
 set cmsghdr Cmsghdr ip_mreq IPMreq ip_mreqn IPMreqn ipv6_mreq IPv6Mreq \

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[Jakub Jelinek]

On Tue, Jan 26, 2016 at 01:21:52PM -0800, H.J. Lu wrote:
> Like this:
> 
> /* Returns true if TYPE is POD for the purpose of layout and an empty
>class or an class with empty classes.  */
> 
> static bool
> is_empty_record (tree type)
> {
>   if (type == error_mark_node)
> return false;
> 
>   if (!CLASS_TYPE_P (type))
> return false;
> 
>   if (CLASSTYPE_NON_LAYOUT_POD_P (type))
> return false;
> 
>   gcc_assert (COMPLETE_TYPE_P (type));
> 
>   if (CLASSTYPE_EMPTY_P (type))
> return true;
> 
>   tree field;
> 
>   for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
> if (TREE_CODE (field) == FIELD_DECL
> && !DECL_ARTIFICIAL (field)
> && !is_empty_record (TREE_TYPE (field)))
>   return false;
> 
>   return true;
> }

So you say that K1 in e.g.:

struct A1 {}; struct A2 {};
struct B1 { A1 a; A2 b; }; struct B2 { A1 a; A2 b; };
struct C1 { B1 a; B2 b; }; struct C2 { B1 a; B2 b; };
struct D1 { C1 a; C2 b; }; struct D2 { C1 a; C2 b; };
struct E1 { D1 a; D2 b; }; struct E2 { D1 a; D2 b; };
struct F1 { E1 a; E2 b; }; struct F2 { E1 a; E2 b; };
struct G1 { F1 a; F2 b; }; struct G2 { F1 a; F2 b; };
struct H1 { G1 a; G2 b; }; struct H2 { G1 a; G2 b; };
struct I1 { H1 a; H2 b; }; struct I2 { H1 a; H2 b; };
struct J1 { I1 a; I2 b; }; struct J2 { I1 a; I2 b; };
struct K1 { J1 a; J2 b; };
int v;
__attribute__((noinline, noclone))
K1 foo (int a, K1 x, int b)
{
  v = a + b;
  return x;
}
K1 k, m;
void
bar (void)
{
  m = foo (1, k, 2);
}

is empty class?  What does clang do with this?

Jakub

Re: [PATCH] Fix up wi::lrshift (PR c++/69399)

[Jakub Jelinek]

On Tue, Jan 26, 2016 at 09:45:19PM +0100, Richard Biener wrote:
> On January 26, 2016 8:00:52 PM GMT+01:00, Mike Stump  
> wrote:
> >On Jan 26, 2016, at 10:21 AM, Jakub Jelinek  wrote
> >> The question is, shall we do what wi::lshift does and have the fast
> >path
> >> only for the constant shifts, as the untested patch below does, or
> >shall we
> >> check shift dynamically (thus use
> >> shift < HOST_BITS_PER_WIDE_INT
> >> instead of
> >> STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT)
> >> in the patch),
> >
> >Hum…  I think I prefer the dynamic check.  The reasoning is that when
> >we fast path, we can tolerate the conditional branch to retain the fast
> >path, as most of the time, that condition will usually be true.  If the
> >compiler had troubles with knowing the usual truth value of the
> >expression, seems like we can hint that it will be true and influence
> >the static prediction of the branch.  This permits us to fast path
> >almost all the time in the non-constant, but small enough case.  For
> >known shifts, there is no code gen difference, so it doesn’t matter.
> 
> The original reasoning was to inline only the fast path if it is known at 
> compile time and otherwise have a call. Exactly to avoid bloating callers 
> with inlined conditionals.

I'm now also bootstrapping/regtesting following patch, the previous one
passed bootstrap/regtest, and will do cc1plus size comparison afterwards.
That said, I have done a quick check, where I believe that unless xi and
shift are both compile time constants, for the
STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
case there should be some comparison and the lrshift_large call with
the non-STATIC_CONSTANT_P variant, but in the bootstrapped (non-LTO)
cc1plus I only see 14 calls to lrshift_large, thus I bet it will likely affect
only <= 14 places right now:

00776990 
<_ZL11build_new_1PP3vecIP9tree_node5va_gc8vl_embedES1_S1_S6_bi>:
  777ca4:   e8 17 28 91 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
--
008b8bc0 <_ZL31adjust_offset_for_component_refP9tree_nodePbPl.part.91>:
  8b8cc2:   e8 f9 17 7d 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
--
00a7b550 
<_ZN2wi7rrotateIPK9tree_node16generic_wide_intI16wide_int_storageEEENS_12unary_traitsIT_E11result_typeERKS8_RKT0_j>:
  a7baea:   e8 d1 e9 60 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
00a7bd90 
<_ZN2wi7lrotateIPK9tree_node16generic_wide_intI16wide_int_storageEEENS_12unary_traitsIT_E11result_typeERKS8_RKT0_j>:
  a7c457:   e8 64 e0 60 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
--
00a7c710 
<_ZN2wi7lrshiftIP9tree_nodelEENS_12unary_traitsIT_E11result_typeERKS4_RKT0_>:
  a7c851:   e8 6a dc 60 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
--
00a7d280 
<_ZN2wi7lrshiftIPK9tree_node16generic_wide_intI16wide_int_storageEEENS_12unary_traitsIT_E11result_typeERKS8_RKT0_>:
  a7d3b9:   e8 02 d1 60 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
--
00cc1370 <_Z15real_to_integerPK10real_valuePbi>:
  cc1752:   e8 69 8d 3c 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
--
00cc27f0 
<_Z17real_from_integerP10real_value13format_helperRK16generic_wide_intI20wide_int_ref_storageILb0EEE6signop>:
  cc2f05:   e8 b6 75 3c 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
--
00d6c420 
<_Z31simplify_const_binary_operation8rtx_code12machine_modeP7rtx_defS2_>:
  d6f5a5:   e8 16 af 31 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
--
00d7ca40 
<_ZN2wi7lrotateISt4pairIP7rtx_def12machine_modeES5_EENS_12unary_traitsIT_E11result_typeERKS7_RKT0_j>:
  d7d17a:   e8 41 d3 30 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
00d7d310 
<_ZN2wi7rrotateISt4pairIP7rtx_def12machine_modeES5_EENS_12unary_traitsIT_E11result_typeERKS7_RKT0_j>:
  d7d99d:   e8 1e cb 30 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
--
00ea3c40 
<_ZN2wi7lrshiftI16generic_wide_intI22fixed_wide_int_storageILi192EEES4_EENS_12unary_traitsIT_E11result_typeERKS6_RKT0_>:
  ea3ca7:   e8 14 68 1e 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
--
00f435a0 
<_ZL27copy_reference_ops_from_refP9tree_nodeP3vecI22vn_reference_op_struct7va_heap6vl_ptrE>:
  f444b2:   e8 09 60 14 00  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>
--
0161c840 
<_ZL21restructure_referencePP9tree_nodeS1_P16generic_wide_intI22fixed_wide_int_storageILi192EEES1_.constprop.133>:
 161cb51:   e8 6a d9 a6 ff  callq  108a4c0 
<_ZN2wi13lrshift_largeEPlPKl>

2016-01-26  Jakub Jelinek  

PR tree-optimization/69399
* wide-int.h (wi::lrshift): For larger precisions, only
use fast path if shift is known to be < HOST_BITS_PER_WIDE_INT.

* gcc.dg/torture/pr69399.c: New test.

--- gcc/wide-int.h.jj   2016-01-04 14:5

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[H.J. Lu]

On Tue, Jan 26, 2016 at 12:44 PM, Marc Glisse  wrote:
> On Tue, 26 Jan 2016, H.J. Lu wrote:
>
>> On Tue, Jan 26, 2016 at 12:23 PM, Marc Glisse 
>> wrote:
>>>
>>> On Tue, 26 Jan 2016, H.J. Lu wrote:
>>>
 On Tue, Jan 26, 2016 at 11:27 AM, Jason Merrill 
 wrote:
>
>
> On 12/14/2015 05:08 PM, H.J. Lu wrote:
>>
>>
>>
>> +  if (abi_version_at_least (10))
>> +TYPE_EMPTY_RECORD (t) = is_really_empty_class (t);
>
>
>
>
> This should use is_empty_class or CLASSTYPE_EMPTY_P.  We don't want to
> change how classes with just a vptr are passed.
>
> Otherwise, it looks OK to me.



 Is true_type an empty class here?  is_empty_class returns false
 on this:
>>>
>>>
>>>
>>> It isn't empty in the usual C++ sense (we can't apply the empty base
>>> optimization to something that derives from it, for instance), or the one
>>> described in the itanium ABI (the relevant one here I guess). On the
>>> other
>>> hand, it is rather useless to pass it by value, so a different notion of
>>
>>
>> llvm/clang treats it as empty class and I think it should be treated
>> as "empty" class.
>
>
> Is it still empty if there are several empty members? Is there a clear
> definition somewhere of what empty means? I guess it makes sense to
> recursively allow "empty" members for this purpose.

Like this:

/* Returns true if TYPE is POD for the purpose of layout and an empty
   class or an class with empty classes.  */

static bool
is_empty_record (tree type)
{
  if (type == error_mark_node)
return false;

  if (!CLASS_TYPE_P (type))
return false;

  if (CLASSTYPE_NON_LAYOUT_POD_P (type))
return false;

  gcc_assert (COMPLETE_TYPE_P (type));

  if (CLASSTYPE_EMPTY_P (type))
return true;

  tree field;

  for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
if (TREE_CODE (field) == FIELD_DECL
&& !DECL_ARTIFICIAL (field)
&& !is_empty_record (TREE_TYPE (field)))
  return false;

  return true;
}

-- 
H.J.

Is it OK for rtx_addr_can_trap_p_1 to attempt to compute the frame layout? (was Re: [PATCH] Skip re-computing the mips frame info after reload completed)

[Richard Sandiford]

[cc-ing Eric as RTL maintainer]

Matthew Fortune  writes:
> Bernd Edlinger  writes:
>> Matthew Fortune  writes:
>> > Has the patch been tested beyond just building GCC? I can do a
>> > test run for you if you don't have things set up to do one yourself.
>> 
>> I built a cross-gcc with all languages and a cross-glibc, but I have
>> not set up an emulation environment, so if you could give it a test
>> that would be highly welcome.
>
> mipsel-linux-gnu test results are the same before and after this patch.
>
> Please go ahead and commit.

I still object to this.  And it feels like the patch was posted
as though it was a new one in order to avoid answering the objections
that were raised when it was last posted:

  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02218.html

IMO the problem is that rtx_addr_can_trap_p_1 duplicates a large
bit of LRA/reload logic:


/* Compute an approximation for the offset between the register
   FROM and TO for the current function, as it was at the start
   of the routine.  */

static HOST_WIDE_INT
get_initial_register_offset (int from, int to)
{
#ifdef ELIMINABLE_REGS
  static const struct elim_table_t
  {
const int from;
const int to;
  } table[] = ELIMINABLE_REGS;
  HOST_WIDE_INT offset1, offset2;
  unsigned int i, j;

  if (to == from)
return 0;

  /* It is not safe to call INITIAL_ELIMINATION_OFFSET
 before the reload pass.  We need to give at least
 an estimation for the resulting frame size.  */
  if (! reload_completed)
{
  offset1 = crtl->outgoing_args_size + get_frame_size ();
#if !STACK_GROWS_DOWNWARD
  offset1 = - offset1;
#endif
  if (to == STACK_POINTER_REGNUM)
return offset1;
  else if (from == STACK_POINTER_REGNUM)
return - offset1;
  else
return 0;
 }

  for (i = 0; i < ARRAY_SIZE (table); i++)
  if (table[i].from == from)
{
  if (table[i].to == to)
{
  INITIAL_ELIMINATION_OFFSET (table[i].from, table[i].to,
  offset1);
  return offset1;
}
  for (j = 0; j < ARRAY_SIZE (table); j++)
{
  if (table[j].to == to
  && table[j].from == table[i].to)
{
  INITIAL_ELIMINATION_OFFSET (table[i].from, table[i].to,
  offset1);
  INITIAL_ELIMINATION_OFFSET (table[j].from, table[j].to,
  offset2);
  return offset1 + offset2;
}
  if (table[j].from == to
  && table[j].to == table[i].to)
{
  INITIAL_ELIMINATION_OFFSET (table[i].from, table[i].to,
  offset1);
  INITIAL_ELIMINATION_OFFSET (table[j].from, table[j].to,
  offset2);
  return offset1 - offset2;
}
}
}
  else if (table[i].to == from)
{
  if (table[i].from == to)
{
  INITIAL_ELIMINATION_OFFSET (table[i].from, table[i].to,
  offset1);
  return - offset1;
}
  for (j = 0; j < ARRAY_SIZE (table); j++)
{
  if (table[j].to == to
  && table[j].from == table[i].from)
{
  INITIAL_ELIMINATION_OFFSET (table[i].from, table[i].to,
  offset1);
  INITIAL_ELIMINATION_OFFSET (table[j].from, table[j].to,
  offset2);
  return - offset1 + offset2;
}
  if (table[j].from == to
  && table[j].to == table[i].from)
{
  INITIAL_ELIMINATION_OFFSET (table[i].from, table[i].to,
  offset1);
  INITIAL_ELIMINATION_OFFSET (table[j].from, table[j].to,
  offset2);
  return - offset1 - offset2;
}
}
}

  /* If the requested register combination was not found,
 try a different more simple combination.  */
  if (from == ARG_POINTER_REGNUM)
return get_initial_register_offset (HARD_FRAME_POINTER_REGNUM, to);
  else if (to == ARG_POINTER_REGNUM)
return get_initial_register_offset (from, HARD_FRAME_POINTER_REGNUM);
  else if (from == HARD_FRAME_POINTER_REGNUM)
return get_initial_register_offset (FRAME_POINTER_REGNUM, to);
  else if (to == HARD_FRAME_POINTER_REGNUM)
return get_initial_register_offset (from, FRAME_POINTER_REGNUM);
  else
return 0;

#else
  HOST_WIDE_INT offset;

  if (to == from)
return 0;

  if (reload_completed)
{
  

Re: [PATCH] Handle -fsanitize=* in lto-wrapper (PR lto/69254)

[Jakub Jelinek]

On Tue, Jan 26, 2016 at 04:44:39PM +0100, Jakub Jelinek wrote:
> 2016-01-26  Jakub Jelinek  
> 
>   PR lto/69254
>   * lto-opts.c (lto_write_options): Write also -f{,no-}sanitize=
>   options.
>   * lto-wrapper.c (struct lto_decoded_options): New type.
>   (append_option, merge_and_complain, append_compiler_options,
>   append_linker_options, append_offload_options,
>   compile_offload_image, compile_images_for_offload_targets,
>   find_and_merge_options): Pass around options
>   in struct lto_decoded_options instead of struct cl_decoded_option
>   pointer and count pair.
>   (get_options_from_collect_gcc_options): Likewise.  Parse -fsanitize=
>   options and if in the end any ub sanitizers are enabled, set
>   decoded_opts->sanitize_undefined to true.
>   (run_gcc): Adjust callers of these functions.  If
>   fdecoded_options.sanitize_undefined is true, append
>   -fsanitize=shift after the linker options.

Now successfully bootstrapped/regtested on x86_64-linux and i686-linux.

Jakub

[PATCH] [graphite] handle isl_ast_op_select

[Sebastian Pop]

2016-01-26  Abderrazek Zaafrani  
Sebastian Pop  

* graphite-isl-ast-to-gimple.c (ternary_op_to_tree): Handle
isl_ast_op_cond and isl_ast_op_select.
(gcc_expression_from_isl_expr_op): Same.

* gcc.dg/graphite/isl-ast-op-select.c: New.
---
 gcc/graphite-isl-ast-to-gimple.c  | 18 +++---
 gcc/testsuite/gcc.dg/graphite/isl-ast-op-select.c | 29 +++
 2 files changed, 37 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/graphite/isl-ast-op-select.c

diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 0f58503..81ed304 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-isl-ast-to-gimple.c
@@ -689,22 +689,20 @@ tree
 translate_isl_ast_to_gimple::
 ternary_op_to_tree (tree type, __isl_take isl_ast_expr *expr, ivs_params &ip)
 {
-  gcc_assert (isl_ast_expr_get_op_type (expr) == isl_ast_op_minus);
+  enum isl_ast_op_type t = isl_ast_expr_get_op_type (expr);
+  gcc_assert (t == isl_ast_op_cond || t == isl_ast_op_select);
   isl_ast_expr *arg_expr = isl_ast_expr_get_op_arg (expr, 0);
-  tree tree_first_expr
-= gcc_expression_from_isl_expression (type, arg_expr, ip);
+  tree a = gcc_expression_from_isl_expression (type, arg_expr, ip);
   arg_expr = isl_ast_expr_get_op_arg (expr, 1);
-  tree tree_second_expr
-= gcc_expression_from_isl_expression (type, arg_expr, ip);
+  tree b = gcc_expression_from_isl_expression (type, arg_expr, ip);
   arg_expr = isl_ast_expr_get_op_arg (expr, 2);
-  tree tree_third_expr
-= gcc_expression_from_isl_expression (type, arg_expr, ip);
+  tree c = gcc_expression_from_isl_expression (type, arg_expr, ip);
   isl_ast_expr_free (expr);
 
   if (codegen_error)
 return NULL_TREE;
-  return fold_build3 (COND_EXPR, type, tree_first_expr,
- tree_second_expr, tree_third_expr);
+
+  return fold_build3 (COND_EXPR, type, a, b, c);
 }
 
 /* Converts a unary isl_ast_expr_op expression E to a GCC expression tree of
@@ -791,7 +789,6 @@ gcc_expression_from_isl_expr_op (tree type, __isl_take 
isl_ast_expr *expr,
 case isl_ast_op_call:
 case isl_ast_op_and_then:
 case isl_ast_op_or_else:
-case isl_ast_op_select:
   gcc_unreachable ();
 
 case isl_ast_op_max:
@@ -822,6 +819,7 @@ gcc_expression_from_isl_expr_op (tree type, __isl_take 
isl_ast_expr *expr,
   return unary_op_to_tree (type, expr, ip);
 
 case isl_ast_op_cond:
+case isl_ast_op_select:
   return ternary_op_to_tree (type, expr, ip);
 
 default:
diff --git a/gcc/testsuite/gcc.dg/graphite/isl-ast-op-select.c 
b/gcc/testsuite/gcc.dg/graphite/isl-ast-op-select.c
new file mode 100644
index 000..688176e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/graphite/isl-ast-op-select.c
@@ -0,0 +1,29 @@
+/* { dg-options "-O2 -floop-nest-optimize" } */
+
+static void kernel_gemm(int ni, int nj, int nk, double alpha, double beta, 
double C[1024][1024], double A[1024][1024], double B[1024][1024])
+{
+ int i, j, k;
+ for (i = 0; i < ni; i++)
+   for (j = 0; j < nj; j++)
+ {
+   C[i][j] *= beta;
+   for (k = 0; k < nk; ++k)
+ C[i][j] += alpha * A[i][k] * B[k][j];
+ }
+}
+
+void *polybench_alloc_data (int, int);
+
+int main(int argc, char** argv) {
+  int ni = 1024;
+  int nj = 1024;
+  int nk = 1024;
+  double alpha;
+  double beta;
+  double (*C)[1024][1024];
+  C = (double(*)[1024][1024])polybench_alloc_data ((1024) * (1024), 
sizeof(double));
+  double (*A)[1024][1024];
+  A = (double(*)[1024][1024])polybench_alloc_data ((1024) * (1024), 
sizeof(double));
+  double (*B)[1024][1024];
+  kernel_gemm (ni, nj, nk, alpha, beta, *C, *A, *B);
+}
-- 
2.5.0

Re: RFA (tree.c): PATCH for c++/68782 (wrong TREE_CONSTANT flag on C++ CONSTRUCTOR)

[Jakub Jelinek]

On Tue, Jan 26, 2016 at 03:46:50PM -0500, Jason Merrill wrote:
> On 01/26/2016 03:32 PM, Jakub Jelinek wrote:
> >>>+if (CHECKING_P)
> >>>+  verify_constructor_flags (t);
> >>>+else
> >>>+  recompute_constructor_flags (t);
> 
> >But I don't understand this.  Either the flags are supposed to be already
> >correct here, then I'd expect to see
> >   if (CHECKING_P)
> > verify_constructor_flags (t);
> >only, or they are not guaranteed to be correct, and then I'd expect
> >unconditional
> >   recompute_constructor_flags (t).
> >
> 
> They are supposed to be correct, so when --enable-checking, we check for
> that.  The recompute is for better fault-tolerance in release compilers in
> case the patch doesn't catch everything.

Ah, ok.  But please make sure to remove it after GCC 6 branches. 

Jakub

Re: RFA (tree.c): PATCH for c++/68782 (wrong TREE_CONSTANT flag on C++ CONSTRUCTOR)

[Jason Merrill]

On 01/26/2016 03:32 PM, Jakub Jelinek wrote:

>+ if (CHECKING_P)
>+   verify_constructor_flags (t);
>+ else
>+   recompute_constructor_flags (t);



But I don't understand this.  Either the flags are supposed to be already
correct here, then I'd expect to see
   if (CHECKING_P)
 verify_constructor_flags (t);
only, or they are not guaranteed to be correct, and then I'd expect
unconditional
   recompute_constructor_flags (t).



They are supposed to be correct, so when --enable-checking, we check for 
that.  The recompute is for better fault-tolerance in release compilers 
in case the patch doesn't catch everything.


Jason

Re: [PATCH] Fix up wi::lrshift (PR c++/69399)

[Richard Biener]

On January 26, 2016 8:00:52 PM GMT+01:00, Mike Stump  
wrote:
>On Jan 26, 2016, at 10:21 AM, Jakub Jelinek  wrote
>> The question is, shall we do what wi::lshift does and have the fast
>path
>> only for the constant shifts, as the untested patch below does, or
>shall we
>> check shift dynamically (thus use
>> shift < HOST_BITS_PER_WIDE_INT
>> instead of
>> STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT)
>> in the patch),
>
>Hum…  I think I prefer the dynamic check.  The reasoning is that when
>we fast path, we can tolerate the conditional branch to retain the fast
>path, as most of the time, that condition will usually be true.  If the
>compiler had troubles with knowing the usual truth value of the
>expression, seems like we can hint that it will be true and influence
>the static prediction of the branch.  This permits us to fast path
>almost all the time in the non-constant, but small enough case.  For
>known shifts, there is no code gen difference, so it doesn’t matter.

The original reasoning was to inline only the fast path if it is known at 
compile time and otherwise have a call. Exactly to avoid bloating callers with 
inlined conditionals.

Richard.

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[Marc Glisse]

On Tue, 26 Jan 2016, H.J. Lu wrote:


On Tue, Jan 26, 2016 at 12:23 PM, Marc Glisse  wrote:

On Tue, 26 Jan 2016, H.J. Lu wrote:


On Tue, Jan 26, 2016 at 11:27 AM, Jason Merrill  wrote:


On 12/14/2015 05:08 PM, H.J. Lu wrote:



+  if (abi_version_at_least (10))
+TYPE_EMPTY_RECORD (t) = is_really_empty_class (t);




This should use is_empty_class or CLASSTYPE_EMPTY_P.  We don't want to
change how classes with just a vptr are passed.

Otherwise, it looks OK to me.



Is true_type an empty class here?  is_empty_class returns false
on this:



It isn't empty in the usual C++ sense (we can't apply the empty base
optimization to something that derives from it, for instance), or the one
described in the itanium ABI (the relevant one here I guess). On the other
hand, it is rather useless to pass it by value, so a different notion of


llvm/clang treats it as empty class and I think it should be treated
as "empty" class.


Is it still empty if there are several empty members? Is there a clear 
definition somewhere of what empty means? I guess it makes sense to 
recursively allow "empty" members for this purpose.



empty might have been useful when the ABI was defined...


I proposed to update x86-64 psABI:

https://groups.google.com/forum/#!topic/x86-64-abi/VTE-LJ9VnDk


Does the full document have a definition of empty anywhere?


[hjl@gnu-skl-1 gcc]$ cat x.cc
struct dummy { };
struct true_type { struct dummy i; };

extern true_type y;
extern void xxx (true_type c);

void
yyy (void)
{
 xxx (y);
}
[hjl@gnu-skl-1 gcc]$



--
Marc Glisse


--
Marc Glisse

[Patch, MIPS] Patch for PR 68400, a mips16 bug

[Steve Ellcey]

Here is a patch for PR6400.  The problem is that and_operands_ok was checking
one operand to see if it was a memory_operand but MIPS16 addressing is more
restrictive than what the general memory_operand allows.  The fix was to
call mips_classify_address if TARGET_MIPS16 is set because it will do a
more complete mips16 addressing check and reject operands that do not meet
the more restrictive requirements.

I ran the GCC testsuite with no regressions and have included a test case as
part of this patch.

OK to checkin?

Steve Ellcey
sell...@imgtec.com


2016-01-26  Steve Ellcey  

PR target/68400
* config/mips/mips.c (and_operands_ok): Add MIPS16 check.



diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index dd54d6a..adeafa3 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -8006,9 +8006,18 @@ mask_low_and_shift_p (machine_mode mode, rtx mask, rtx 
shift, int maxlen)
 bool
 and_operands_ok (machine_mode mode, rtx op1, rtx op2)
 {
-  return (memory_operand (op1, mode)
- ? and_load_operand (op2, mode)
- : and_reg_operand (op2, mode));
+
+  if (memory_operand (op1, mode))
+{
+  if (TARGET_MIPS16) {
+   struct mips_address_info addr;
+   if (!mips_classify_address (&addr, op1, mode, false))
+ return false;
+  }
+  return and_load_operand (op2, mode);
+}
+  else
+return and_reg_operand (op2, mode);
 }
 
 /* The canonical form of a mask-low-and-shift-left operation is




2016-01-26  Steve Ellcey  

PR target/68400
* gcc.target/mips/mips.exp (mips_option_groups): Add stack-protector.
* gcc.target/mips/pr68400.c: New test.


diff --git a/gcc/testsuite/gcc.target/mips/mips.exp 
b/gcc/testsuite/gcc.target/mips/mips.exp
index f191331..ff9c99a 100644
--- a/gcc/testsuite/gcc.target/mips/mips.exp
+++ b/gcc/testsuite/gcc.target/mips/mips.exp
@@ -257,6 +257,7 @@ set mips_option_groups {
 lsa "(|!)HAS_LSA"
 section_start "-Wl,--section-start=.*"
 frame-header "-mframe-header-opt|-mno-frame-header-opt"
+stack-protector "-fstack-protector"
 }
 
 for { set option 0 } { $option < 32 } { incr option } {
diff --git a/gcc/testsuite/gcc.target/mips/pr68400.c 
b/gcc/testsuite/gcc.target/mips/pr68400.c
index e69de29..1099568 100644
--- a/gcc/testsuite/gcc.target/mips/pr68400.c
+++ b/gcc/testsuite/gcc.target/mips/pr68400.c
@@ -0,0 +1,28 @@
+/* PR target/pr68400
+   This was triggering an ICE in change_address_1 when compiled with -Os.  */
+
+/* { dg-do compile } */
+/* { dg-options "-fstack-protector -mips16" } */
+
+typedef struct s {
+ unsigned long long d;
+ long long t;
+} p;
+
+int sh(int x, unsigned char *buf)
+{
+ p *uhdr = (p *)buf;
+ unsigned int i = 0;
+ uhdr->d = ((uhdr->d & 0xff00LL) >> 56)
+| ((uhdr->d & 0xff00LL) >> 24)
+| ((uhdr->d & 0xff00LL) << 8)
+| ((uhdr->d & 0x00ffLL) << 56);
+ uhdr->t = ((uhdr->t & 0xff00LL) >> 56)
+| ((uhdr->t & 0xff00LL) >> 24)
+| ((uhdr->t & 0x00ffLL) >> 8)
+| ((uhdr->t & 0xff00LL) << 8)
+| ((uhdr->t & 0xff00LL) << 40)
+| ((uhdr->t & 0x00ffLL) << 56);
+ i += 4;
+ if (x < i) return 0; else return 1;
+}

[wwwdocs][PATCH] Add notes on -Wmisleading-indentation to GCC 6 porting guide

[David Malcolm]

htdocs/gcc-6/porting_to.html is looking rather empty right now.  The
attached patch starts fleshing it out by adding some notes on
-Wmisleading-indentation.

[see the notes at https://gcc.gnu.org/ml/gcc/2016-01/msg00224.html on
what -Wmisleading-indentation ran into on a mass-rebuild of Debian]

I put it apart from the existing headings as it relates to both C and to
C++.

Validates.

OK to commit?
Dave
Index: htdocs/gcc-6/porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.1
diff -u -p -r1.1 porting_to.html
--- htdocs/gcc-6/porting_to.html	20 Jan 2016 11:53:52 -	1.1
+++ htdocs/gcc-6/porting_to.html	26 Jan 2016 20:35:05 -
@@ -33,6 +33,69 @@ manner. Additions and suggestions for im
 
 C++ language issues
 
+-Wmisleading-indentation
+
+A new warning -Wmisleading-indentation was added
+to -Wall, warning about places where the indentation of
+the code might mislead a human reader about the control flow:
+
+
+
+sslKeyExchange.c: In function 'SSLVerifySignedServerKeyExchange':
+sslKeyExchange.c:631:8: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
+goto fail;
+^~~~
+sslKeyExchange.c:629:4: note: ...this 'if' clause, but it is not
+if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
+^~
+
+
+
+This has highlighted genuine bugs, often due to missing braces, but it
+sometimes reports warnings for poorly-indented files, or on projects
+with unusual indentation.  This may cause build errors if you
+have -Wall -Werror in your project.
+
+
+
+The best fix is usually to fix the indentation of the code to match
+the block structure, or to fix the block structure by adding missing
+braces.  If changing the source is not practical or desirable (e.g. for
+autogenerated code, or to avoid churn in the source history), the
+warning can be disabled by adding -Wno-misleading-indentation
+to the build flags.  Alternatively, you can disable it for just one part of
+a source file or function using pragmas:
+
+
+
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wmisleading-indentation"
+
+/* (code for which the warning is to be disabled)  */
+
+#pragma GCC diagnostic pop
+
+
+
+Source files with mixed tabs and spaces that don't use 8-space tabs
+may lead to warnings.  A real-world example was for such a source file, which
+contained an Emacs directive to view tabs to be 4 spaces wide:
+
+
+
+  /* -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
+
+
+
+The mixture of tabs and spaces did correctly reflect the block
+structure when viewed in Emacs, but not in other editors, or in an
+HTML view of the source repository.
+By default, -Wmisleading-indentation assumes tabs to
+be 8 spaces wide.  It would have been possible to avoid this warning
+by adding -ftabstop=4 to the build flags for this file,
+but given that the code was confusing when viewed in other editors,
+the indentation of the source was fixed instead.
+
 
 Links
 

Re: RFA (tree.c): PATCH for c++/68782 (wrong TREE_CONSTANT flag on C++ CONSTRUCTOR)

[Jakub Jelinek]

On Tue, Jan 26, 2016 at 03:20:04PM -0500, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu. Are the tree.c changes OK for trunk?

The tree.c changes are ok.  But I have nits and one bigger issue in
constexpr.c:

> --- a/gcc/cp/constexpr.c
> +++ b/gcc/cp/constexpr.c
> @@ -2214,6 +2214,9 @@ cxx_eval_bare_aggregate (const constexpr_ctx *ctx, tree 
> t,
>vec **p = &CONSTRUCTOR_ELTS (ctx->ctor);
>vec_alloc (*p, vec_safe_length (v));
>  
> +  bool constant_p = true;
> +  bool side_effects_p = false;
> +
>unsigned i; tree index, value;

I think vars of different types shouldn't be declared on the same line.
And perhaps the empty line in between two sets of declarations isn't needed.

>FOR_EACH_CONSTRUCTOR_ELT (v, i, index, value)
>  {
> @@ -2826,6 +2836,8 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, 
> tree t,
>  }
>type = TREE_TYPE (object);
>bool no_zero_init = true;
> +
> +  vec *ctors = make_tree_vector();

Missing space before (.

>while (!refs->is_empty())
>  {
>if (*valp == NULL_TREE)
> @@ -2837,6 +2849,8 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, 
> tree t,
>subobjects will also be zero-initialized.  */
>no_zero_init = CONSTRUCTOR_NO_IMPLICIT_ZERO (*valp);
>  
> +  vec_safe_push (ctors, *valp);
> +
>enum tree_code code = TREE_CODE (type);
>type = refs->pop();
>tree index = refs->pop();
> @@ -2889,14 +2903,35 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, 
> tree t,
>/* The hash table might have moved since the get earlier.  */
>valp = ctx->values->get (object);
>if (TREE_CODE (init) == CONSTRUCTOR)
> - /* An outer ctx->ctor might be pointing to *valp, so just replace
> -its contents.  */
> - CONSTRUCTOR_ELTS (*valp) = CONSTRUCTOR_ELTS (init);
> + {
> +   /* An outer ctx->ctor might be pointing to *valp, so replace
> +  its contents.  */
> +   CONSTRUCTOR_ELTS (*valp) = CONSTRUCTOR_ELTS (init);
> +   TREE_CONSTANT (*valp) = TREE_CONSTANT (init);
> +   TREE_SIDE_EFFECTS (*valp) = TREE_SIDE_EFFECTS (init);
> + }
>else
>   *valp = init;
>  }
>else
> -*valp = init;
> +{
> +  *valp = init;
> +
> +  /* Update TREE_CONSTANT and TREE_SIDE_EFFECTS on enclosing
> +  CONSTRUCTORs.  */
> +  unsigned i; tree elt;
> +  bool c = TREE_CONSTANT (init);
> +  bool s = TREE_SIDE_EFFECTS (init);
> +  if (!c || s)
> + FOR_EACH_VEC_SAFE_ELT (ctors, i, elt)
> +   {
> + if (!c)
> +   TREE_CONSTANT (elt) = false;
> + if (s)
> +   TREE_SIDE_EFFECTS (elt) = true;
> +   }
> +}
> +  release_tree_vector (ctors);
>  
>if (*non_constant_p)
>  return t;
> @@ -3579,9 +3614,16 @@ cxx_eval_constant_expression (const constexpr_ctx 
> *ctx, tree t,
>  
>  case CONSTRUCTOR:
>if (TREE_CONSTANT (t))
> - /* Don't re-process a constant CONSTRUCTOR, but do fold it to
> -VECTOR_CST if applicable.  */
> - return fold (t);
> + {
> +   /* Don't re-process a constant CONSTRUCTOR, but do fold it to
> +  VECTOR_CST if applicable.  */
> +   if (CHECKING_P)
> + verify_constructor_flags (t);
> +   else
> + recompute_constructor_flags (t);

But I don't understand this.  Either the flags are supposed to be already
correct here, then I'd expect to see
  if (CHECKING_P)
verify_constructor_flags (t);
only, or they are not guaranteed to be correct, and then I'd expect
unconditional
  recompute_constructor_flags (t).

> +   if (TREE_CONSTANT (t))
> + return fold (t);
> + }
>r = cxx_eval_bare_aggregate (ctx, t, lval,
>  non_constant_p, overflow_p);
>break;

Jakub

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[H.J. Lu]

On Tue, Jan 26, 2016 at 12:23 PM, Marc Glisse  wrote:
> On Tue, 26 Jan 2016, H.J. Lu wrote:
>
>> On Tue, Jan 26, 2016 at 11:27 AM, Jason Merrill  wrote:
>>>
>>> On 12/14/2015 05:08 PM, H.J. Lu wrote:


 +  if (abi_version_at_least (10))
 +TYPE_EMPTY_RECORD (t) = is_really_empty_class (t);
>>>
>>>
>>>
>>> This should use is_empty_class or CLASSTYPE_EMPTY_P.  We don't want to
>>> change how classes with just a vptr are passed.
>>>
>>> Otherwise, it looks OK to me.
>>
>>
>> Is true_type an empty class here?  is_empty_class returns false
>> on this:
>
>
> It isn't empty in the usual C++ sense (we can't apply the empty base
> optimization to something that derives from it, for instance), or the one
> described in the itanium ABI (the relevant one here I guess). On the other
> hand, it is rather useless to pass it by value, so a different notion of

llvm/clang treats it as empty class and I think it should be treated
as "empty" class.

> empty might have been useful when the ABI was defined...

I proposed to update x86-64 psABI:

https://groups.google.com/forum/#!topic/x86-64-abi/VTE-LJ9VnDk

>
>> [hjl@gnu-skl-1 gcc]$ cat x.cc
>> struct dummy { };
>> struct true_type { struct dummy i; };
>>
>> extern true_type y;
>> extern void xxx (true_type c);
>>
>> void
>> yyy (void)
>> {
>>  xxx (y);
>> }
>> [hjl@gnu-skl-1 gcc]$
>
>
> --
> Marc Glisse



-- 
H.J.

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[Marc Glisse]

On Tue, 26 Jan 2016, H.J. Lu wrote:


On Tue, Jan 26, 2016 at 11:27 AM, Jason Merrill  wrote:

On 12/14/2015 05:08 PM, H.J. Lu wrote:


+  if (abi_version_at_least (10))
+TYPE_EMPTY_RECORD (t) = is_really_empty_class (t);



This should use is_empty_class or CLASSTYPE_EMPTY_P.  We don't want to
change how classes with just a vptr are passed.

Otherwise, it looks OK to me.


Is true_type an empty class here?  is_empty_class returns false
on this:


It isn't empty in the usual C++ sense (we can't apply the empty base 
optimization to something that derives from it, for instance), or the one 
described in the itanium ABI (the relevant one here I guess). On the other 
hand, it is rather useless to pass it by value, so a different notion of 
empty might have been useful when the ABI was defined...



[hjl@gnu-skl-1 gcc]$ cat x.cc
struct dummy { };
struct true_type { struct dummy i; };

extern true_type y;
extern void xxx (true_type c);

void
yyy (void)
{
 xxx (y);
}
[hjl@gnu-skl-1 gcc]$


--
Marc Glisse

Re: [PATCH] Fix up wi::lrshift (PR c++/69399)

[Richard Sandiford]

Jakub Jelinek  writes:
> On Tue, Jan 26, 2016 at 11:00:52AM -0800, Mike Stump wrote:
>> On Jan 26, 2016, at 10:21 AM, Jakub Jelinek  wrote
>> > The question is, shall we do what wi::lshift does and have the fast path
>> > only for the constant shifts, as the untested patch below does, or shall we
>> > check shift dynamically (thus use
>> > shift < HOST_BITS_PER_WIDE_INT
>> > instead of
>> > STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT)
>> > in the patch),
>> 
>> Hum…  I think I prefer the dynamic check.  The reasoning is that when we
>> fast path, we can tolerate the conditional branch to retain the fast path,
>> as most of the time, that condition will usually be true.  If the compiler
>> had troubles with knowing the usual truth value of the expression, seems
>> like we can hint that it will be true and influence the static prediction
>> of the branch.  This permits us to fast path almost all the time in the
>> non-constant, but small enough case.  For known shifts, there is no code
>> gen difference, so it doesn’t matter.
>
> Ok, I've cancelled my pending bootstrap/regtest and am testing this instead:
>
> 2016-01-26  Jakub Jelinek  
>
>   PR tree-optimization/69399
>   * wide-int.h (wi::lrshift): For larger precisions, only
>   use fast path if shift is known to be < HOST_BITS_PER_WIDE_INT.
>
> --- gcc/wide-int.h.jj 2016-01-04 18:50:34.656471663 +0100
> +++ gcc/wide-int.h2016-01-26 20:07:03.147054988 +0100
> @@ -2909,7 +2909,9 @@ wi::lrshift (const T1 &x, const T2 &y)
>For variable-precision integers like wide_int, handle HWI
>and sub-HWI integers inline.  */
>if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
> -   ? xi.len == 1 && xi.val[0] >= 0
> +   ? (shift < HOST_BITS_PER_WIDE_INT
> +  && xi.len == 1
> +  && xi.val[0] >= 0)
> : xi.precision <= HOST_BITS_PER_WIDE_INT)
>   {
> val[0] = xi.to_uhwi () >> shift;

LGTM, thanks.

Richard

RFA (tree.c): PATCH for c++/68782 (wrong TREE_CONSTANT flag on C++ CONSTRUCTOR)

[Jason Merrill]

The problem in this bug was that the constexpr code builds a lot of 
CONSTRUCTORs and then fills in the elements later without ever going 
back and updating TREE_CONSTANT and TREE_SIDE_EFFECTS.


This patch adds middle end functions recompute_constructor_flags and 
verify_constructor_flags, and fixes the constexpr code to be more 
careful about updating the flags.


Tested x86_64-pc-linux-gnu. Are the tree.c changes OK for trunk?
commit 2ffc171465931c8de27a8f5afd2963df63d8d6e5
Author: Jason Merrill 
Date:   Tue Jan 26 15:12:27 2016 -0500

	PR c++/68782

gcc/
	* tree.c (recompute_constructor_flags): Split out from
	build_constructor.
	(verify_constructor_flags): New.
	* tree.h: Declare them.
gcc/cp/
	* constexpr.c (cxx_eval_bare_aggregate): Update TREE_CONSTANT
	and TREE_SIDE_EFFECTS.
	(cxx_eval_constant_expression) [CONSTRUCTOR]: Call
	verify_constructor_flags.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 6b0e5a8..263ef38 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2214,6 +2214,9 @@ cxx_eval_bare_aggregate (const constexpr_ctx *ctx, tree t,
   vec **p = &CONSTRUCTOR_ELTS (ctx->ctor);
   vec_alloc (*p, vec_safe_length (v));
 
+  bool constant_p = true;
+  bool side_effects_p = false;
+
   unsigned i; tree index, value;
   FOR_EACH_CONSTRUCTOR_ELT (v, i, index, value)
 {
@@ -2231,6 +2234,11 @@ cxx_eval_bare_aggregate (const constexpr_ctx *ctx, tree t,
 	break;
   if (elt != value)
 	changed = true;
+
+  if (!TREE_CONSTANT (elt))
+	constant_p = false;
+  if (TREE_SIDE_EFFECTS (elt))
+	side_effects_p = true;
   if (index && TREE_CODE (index) == COMPONENT_REF)
 	{
 	  /* This is an initialization of a vfield inside a base
@@ -2264,6 +2272,8 @@ cxx_eval_bare_aggregate (const constexpr_ctx *ctx, tree t,
   /* We're done building this CONSTRUCTOR, so now we can interpret an
  element without an explicit initializer as value-initialized.  */
   CONSTRUCTOR_NO_IMPLICIT_ZERO (t) = false;
+  TREE_CONSTANT (t) = constant_p;
+  TREE_SIDE_EFFECTS (t) = side_effects_p;
   if (VECTOR_TYPE_P (TREE_TYPE (t)))
 t = fold (t);
   return t;
@@ -2826,6 +2836,8 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, tree t,
 }
   type = TREE_TYPE (object);
   bool no_zero_init = true;
+
+  vec *ctors = make_tree_vector();
   while (!refs->is_empty())
 {
   if (*valp == NULL_TREE)
@@ -2837,6 +2849,8 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, tree t,
 	 subobjects will also be zero-initialized.  */
   no_zero_init = CONSTRUCTOR_NO_IMPLICIT_ZERO (*valp);
 
+  vec_safe_push (ctors, *valp);
+
   enum tree_code code = TREE_CODE (type);
   type = refs->pop();
   tree index = refs->pop();
@@ -2889,14 +2903,35 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, tree t,
   /* The hash table might have moved since the get earlier.  */
   valp = ctx->values->get (object);
   if (TREE_CODE (init) == CONSTRUCTOR)
-	/* An outer ctx->ctor might be pointing to *valp, so just replace
-	   its contents.  */
-	CONSTRUCTOR_ELTS (*valp) = CONSTRUCTOR_ELTS (init);
+	{
+	  /* An outer ctx->ctor might be pointing to *valp, so replace
+	 its contents.  */
+	  CONSTRUCTOR_ELTS (*valp) = CONSTRUCTOR_ELTS (init);
+	  TREE_CONSTANT (*valp) = TREE_CONSTANT (init);
+	  TREE_SIDE_EFFECTS (*valp) = TREE_SIDE_EFFECTS (init);
+	}
   else
 	*valp = init;
 }
   else
-*valp = init;
+{
+  *valp = init;
+
+  /* Update TREE_CONSTANT and TREE_SIDE_EFFECTS on enclosing
+	 CONSTRUCTORs.  */
+  unsigned i; tree elt;
+  bool c = TREE_CONSTANT (init);
+  bool s = TREE_SIDE_EFFECTS (init);
+  if (!c || s)
+	FOR_EACH_VEC_SAFE_ELT (ctors, i, elt)
+	  {
+	if (!c)
+	  TREE_CONSTANT (elt) = false;
+	if (s)
+	  TREE_SIDE_EFFECTS (elt) = true;
+	  }
+}
+  release_tree_vector (ctors);
 
   if (*non_constant_p)
 return t;
@@ -3579,9 +3614,16 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, tree t,
 
 case CONSTRUCTOR:
   if (TREE_CONSTANT (t))
-	/* Don't re-process a constant CONSTRUCTOR, but do fold it to
-	   VECTOR_CST if applicable.  */
-	return fold (t);
+	{
+	  /* Don't re-process a constant CONSTRUCTOR, but do fold it to
+	 VECTOR_CST if applicable.  */
+	  if (CHECKING_P)
+	verify_constructor_flags (t);
+	  else
+	recompute_constructor_flags (t);
+	  if (TREE_CONSTANT (t))
+	return fold (t);
+	}
   r = cxx_eval_bare_aggregate (ctx, t, lval,
    non_constant_p, overflow_p);
   break;
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-aggr2.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-aggr2.C
new file mode 100644
index 000..805d026
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-aggr2.C
@@ -0,0 +1,27 @@
+// PR c++/68782
+// { dg-do compile { target c++11 } }
+
+#define assert(X) do { if (!(X)) __builtin_abort(); } while (0)
+
+struct holder { int& value; };
+
+constexpr holder from_value(int& val

Re: [PATCH] Fix up wi::lrshift (PR c++/69399)

[H.J. Lu]

On Tue, Jan 26, 2016 at 11:17 AM, Jakub Jelinek  wrote:
> On Tue, Jan 26, 2016 at 11:00:52AM -0800, Mike Stump wrote:
>> On Jan 26, 2016, at 10:21 AM, Jakub Jelinek  wrote
>> > The question is, shall we do what wi::lshift does and have the fast path
>> > only for the constant shifts, as the untested patch below does, or shall we
>> > check shift dynamically (thus use
>> > shift < HOST_BITS_PER_WIDE_INT
>> > instead of
>> > STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT)
>> > in the patch),
>>
>> Hum…  I think I prefer the dynamic check.  The reasoning is that when we
>> fast path, we can tolerate the conditional branch to retain the fast path,
>> as most of the time, that condition will usually be true.  If the compiler
>> had troubles with knowing the usual truth value of the expression, seems
>> like we can hint that it will be true and influence the static prediction
>> of the branch.  This permits us to fast path almost all the time in the
>> non-constant, but small enough case.  For known shifts, there is no code
>> gen difference, so it doesn’t matter.
>
> Ok, I've cancelled my pending bootstrap/regtest and am testing this instead:
>
> 2016-01-26  Jakub Jelinek  
>
> PR tree-optimization/69399
> * wide-int.h (wi::lrshift): For larger precisions, only
> use fast path if shift is known to be < HOST_BITS_PER_WIDE_INT.
>
> --- gcc/wide-int.h.jj   2016-01-04 18:50:34.656471663 +0100
> +++ gcc/wide-int.h  2016-01-26 20:07:03.147054988 +0100
> @@ -2909,7 +2909,9 @@ wi::lrshift (const T1 &x, const T2 &y)
>  For variable-precision integers like wide_int, handle HWI
>  and sub-HWI integers inline.  */
>if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
> - ? xi.len == 1 && xi.val[0] >= 0
> + ? (shift < HOST_BITS_PER_WIDE_INT
> +&& xi.len == 1
> +&& xi.val[0] >= 0)
>   : xi.precision <= HOST_BITS_PER_WIDE_INT)
> {
>   val[0] = xi.to_uhwi () >> shift;
>
>
> Jakub

Can you add the testcase in PR 69399 to gcc.dg/torture?

Thanks.


-- 
H.J.

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[H.J. Lu]

On Tue, Jan 26, 2016 at 11:27 AM, Jason Merrill  wrote:
> On 12/14/2015 05:08 PM, H.J. Lu wrote:
>>
>> +  if (abi_version_at_least (10))
>> +TYPE_EMPTY_RECORD (t) = is_really_empty_class (t);
>
>
> This should use is_empty_class or CLASSTYPE_EMPTY_P.  We don't want to
> change how classes with just a vptr are passed.
>
> Otherwise, it looks OK to me.

Is true_type an empty class here?  is_empty_class returns false
on this:

[hjl@gnu-skl-1 gcc]$ cat x.cc
struct dummy { };
struct true_type { struct dummy i; };

extern true_type y;
extern void xxx (true_type c);

void
yyy (void)
{
  xxx (y);
}
[hjl@gnu-skl-1 gcc]$


-- 
H.J.

[patch] libstdc++/69478 Fix assertions for move assignment of trivial types

[Jonathan Wakely]

The PR shows that we are incorrectly asserting that types are
copy-assignable when we are going to move-assign them.

Tested powerpc64-linux, committed to trunk. Branch commits to follow
shortly.

commit d11631c7c7f6630e83fdbe7f8e16f55eea2dd773
Author: Jonathan Wakely 
Date:   Tue Jan 26 13:38:33 2016 +

Fix assertions for move assignment of trivial types

	PR libstdc++/69478
	* include/bits/stl_algobase.h (__copy_move<_IsMove, true,
	random_access_iterator_tag>): Check is_move_assignable when moving.
	(__copy_move_backwards<_IsMove, true, random_access_iterator_tag>):
	Likewise.
	* testsuite/25_algorithms/copy/move_iterators/69478.cc: New.
	* testsuite/25_algorithms/copy_backward/move_iterators/69478.cc: New.
	* testsuite/25_algorithms/move/69478.cc: New.
	* testsuite/25_algorithms/move_backward/69478.cc: new.

diff --git a/libstdc++-v3/include/bits/stl_algobase.h b/libstdc++-v3/include/bits/stl_algobase.h
index 4a618be..d95ea51 100644
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -357,9 +357,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 __copy_m(const _Tp* __first, const _Tp* __last, _Tp* __result)
 {
 #if __cplusplus >= 201103L
+	  using __assignable = conditional<_IsMove,
+	   is_move_assignable<_Tp>,
+	   is_copy_assignable<_Tp>>;
 	  // trivial types can have deleted assignment
-	  static_assert( is_copy_assignable<_Tp>::value,
-	 "type is not assignable" );
+	  static_assert( __assignable::type::value, "type is not assignable" );
 #endif
 	  const ptrdiff_t _Num = __last - __first;
 	  if (_Num)
@@ -557,9 +559,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 __copy_move_b(const _Tp* __first, const _Tp* __last, _Tp* __result)
 {
 #if __cplusplus >= 201103L
+	  using __assignable = conditional<_IsMove,
+	   is_move_assignable<_Tp>,
+	   is_copy_assignable<_Tp>>;
 	  // trivial types can have deleted assignment
-	  static_assert( is_copy_assignable<_Tp>::value,
-	 "type is not assignable" );
+	  static_assert( __assignable::type::value, "type is not assignable" );
 #endif
 	  const ptrdiff_t _Num = __last - __first;
 	  if (_Num)
diff --git a/libstdc++-v3/testsuite/25_algorithms/copy/move_iterators/69478.cc b/libstdc++-v3/testsuite/25_algorithms/copy/move_iterators/69478.cc
new file mode 100644
index 000..707b273
--- /dev/null
+++ b/libstdc++-v3/testsuite/25_algorithms/copy/move_iterators/69478.cc
@@ -0,0 +1,40 @@
+// { dg-options "-std=gnu++11" }
+// { dg-do compile }
+
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library 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.
+
+// This library 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 this library; see the file COPYING3.  If not see
+// .
+
+// PR libstdc++/69478
+
+#include 
+#include 
+
+void
+test01()
+{
+  // A move-only type that is also a trivial class.
+  struct trivial_rvalstruct
+  {
+trivial_rvalstruct() = default;
+trivial_rvalstruct(trivial_rvalstruct&&) = default;
+trivial_rvalstruct& operator=(trivial_rvalstruct&&) = default;
+  };
+  static_assert(std::is_trivial::value, "");
+
+  trivial_rvalstruct a[1], b[1];
+  copy(std::make_move_iterator(a), std::make_move_iterator(a + 1), b);
+}
diff --git a/libstdc++-v3/testsuite/25_algorithms/copy_backward/move_iterators/69478.cc b/libstdc++-v3/testsuite/25_algorithms/copy_backward/move_iterators/69478.cc
new file mode 100644
index 000..e00d146
--- /dev/null
+++ b/libstdc++-v3/testsuite/25_algorithms/copy_backward/move_iterators/69478.cc
@@ -0,0 +1,40 @@
+// { dg-options "-std=gnu++11" }
+// { dg-do compile }
+
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library 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.
+
+// This library 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 this library; see the file COPYING3.  If not see
+// .
+
+

Re: [C++ PATCH] Handle error_mark_node in cp_fold (PR c++/68357)

[Jason Merrill]

On 01/26/2016 08:56 AM, Jakub Jelinek wrote:

PR c++/68357
* cp-gimplify.c (cp_fold): If some operand folds to error_mark_node,
return error_mark_node instead of building trees with error_mark_node
operands.


OK.

Jason

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[Jason Merrill]

On 12/14/2015 05:08 PM, H.J. Lu wrote:

+  if (abi_version_at_least (10))
+TYPE_EMPTY_RECORD (t) = is_really_empty_class (t);


This should use is_empty_class or CLASSTYPE_EMPTY_P.  We don't want to 
change how classes with just a vptr are passed.


Otherwise, it looks OK to me.

Jason

Re: [PATCH] Partial fix for PR target/68662

[David Edelsohn]

On Tue, Jan 26, 2016 at 2:15 PM, Jakub Jelinek  wrote:
> Hi!
>
> As Alan mentioned in the PR, there is some other issue still around, but
> by the time I've noticed that, I already had this patch being
> bootstrapped/regtested on powerpc64{,le}-linux (which just passed).
> Ok for trunk and deal with the rest incrementally?
>
> 2016-01-26  Jakub Jelinek  
>
> PR target/68662
> * config/rs6000/rs6000.c (rs6000_option_override_internal): Initialize
> toc_label_name unconditionally.
> (rs6000_emit_load_toc_table): Call ggc_strdup on toc_label_name for
> SYMBOL_REF string.  Use toc_label_name instead of constructing
> LCTOC1.
> (rs6000_elf_declare_function_name): Use toc_label_name instead of
> constructing LCTOC1.

This is okay as an incremental fix.

Thanks, David

Re: [PATCH] Fix up wi::lrshift (PR c++/69399)

[Jakub Jelinek]

On Tue, Jan 26, 2016 at 11:00:52AM -0800, Mike Stump wrote:
> On Jan 26, 2016, at 10:21 AM, Jakub Jelinek  wrote
> > The question is, shall we do what wi::lshift does and have the fast path
> > only for the constant shifts, as the untested patch below does, or shall we
> > check shift dynamically (thus use
> > shift < HOST_BITS_PER_WIDE_INT
> > instead of
> > STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT)
> > in the patch),
> 
> Hum…  I think I prefer the dynamic check.  The reasoning is that when we
> fast path, we can tolerate the conditional branch to retain the fast path,
> as most of the time, that condition will usually be true.  If the compiler
> had troubles with knowing the usual truth value of the expression, seems
> like we can hint that it will be true and influence the static prediction
> of the branch.  This permits us to fast path almost all the time in the
> non-constant, but small enough case.  For known shifts, there is no code
> gen difference, so it doesn’t matter.

Ok, I've cancelled my pending bootstrap/regtest and am testing this instead:

2016-01-26  Jakub Jelinek  

PR tree-optimization/69399
* wide-int.h (wi::lrshift): For larger precisions, only
use fast path if shift is known to be < HOST_BITS_PER_WIDE_INT.

--- gcc/wide-int.h.jj   2016-01-04 18:50:34.656471663 +0100
+++ gcc/wide-int.h  2016-01-26 20:07:03.147054988 +0100
@@ -2909,7 +2909,9 @@ wi::lrshift (const T1 &x, const T2 &y)
 For variable-precision integers like wide_int, handle HWI
 and sub-HWI integers inline.  */
   if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
- ? xi.len == 1 && xi.val[0] >= 0
+ ? (shift < HOST_BITS_PER_WIDE_INT
+&& xi.len == 1
+&& xi.val[0] >= 0)
  : xi.precision <= HOST_BITS_PER_WIDE_INT)
{
  val[0] = xi.to_uhwi () >> shift;


Jakub

[PATCH] Partial fix for PR target/68662

[Jakub Jelinek]

Hi!

As Alan mentioned in the PR, there is some other issue still around, but
by the time I've noticed that, I already had this patch being
bootstrapped/regtested on powerpc64{,le}-linux (which just passed).
Ok for trunk and deal with the rest incrementally?

2016-01-26  Jakub Jelinek  

PR target/68662
* config/rs6000/rs6000.c (rs6000_option_override_internal): Initialize
toc_label_name unconditionally.
(rs6000_emit_load_toc_table): Call ggc_strdup on toc_label_name for
SYMBOL_REF string.  Use toc_label_name instead of constructing
LCTOC1.
(rs6000_elf_declare_function_name): Use toc_label_name instead of
constructing LCTOC1.

--- gcc/config/rs6000/rs6000.c.jj   2016-01-25 22:33:17.0 +0100
+++ gcc/config/rs6000/rs6000.c  2016-01-26 13:05:18.600072073 +0100
@@ -4560,8 +4560,7 @@ rs6000_option_override_internal (bool gl
   if (TARGET_LONG_DOUBLE_128 && !TARGET_IEEEQUAD)
REAL_MODE_FORMAT (TFmode) = &ibm_extended_format;
 
-  if (TARGET_TOC)
-   ASM_GENERATE_INTERNAL_LABEL (toc_label_name, "LCTOC", 1);
+  ASM_GENERATE_INTERNAL_LABEL (toc_label_name, "LCTOC", 1);
 
   /* We can only guarantee the availability of DI pseudo-ops when
 assembling for 64-bit targets.  */
@@ -23983,7 +23982,7 @@ rs6000_emit_load_toc_table (int fromprol
   ASM_GENERATE_INTERNAL_LABEL (buf, "L", CODE_LABEL_NUMBER (lab));
   lab = gen_rtx_SYMBOL_REF (Pmode, ggc_strdup (buf));
   if (flag_pic == 2)
-   got = gen_rtx_SYMBOL_REF (Pmode, toc_label_name);
+   got = gen_rtx_SYMBOL_REF (Pmode, ggc_strdup (toc_label_name));
   else
got = rs6000_got_sym ();
   tmp1 = tmp2 = dest;
@@ -24027,7 +24026,7 @@ rs6000_emit_load_toc_table (int fromprol
{
  rtx tocsym, lab;
 
- tocsym = gen_rtx_SYMBOL_REF (Pmode, toc_label_name);
+ tocsym = gen_rtx_SYMBOL_REF (Pmode, ggc_strdup (toc_label_name));
  lab = gen_label_rtx ();
  emit_insn (gen_load_toc_v4_PIC_1b (tocsym, lab));
  emit_move_insn (dest, gen_rtx_REG (Pmode, LR_REGNO));
@@ -24040,10 +24039,7 @@ rs6000_emit_load_toc_table (int fromprol
   else if (TARGET_ELF && !TARGET_AIX && flag_pic == 0 && TARGET_MINIMAL_TOC)
 {
   /* This is for AIX code running in non-PIC ELF32.  */
-  char buf[30];
-  rtx realsym;
-  ASM_GENERATE_INTERNAL_LABEL (buf, "LCTOC", 1);
-  realsym = gen_rtx_SYMBOL_REF (Pmode, ggc_strdup (buf));
+  rtx realsym = gen_rtx_SYMBOL_REF (Pmode, ggc_strdup (toc_label_name));
 
   emit_insn (gen_elf_high (dest, realsym));
   emit_insn (gen_elf_low (dest, dest, realsym));
@@ -31726,9 +31722,8 @@ rs6000_elf_declare_function_name (FILE *
 
   (*targetm.asm_out.internal_label) (file, "LCL", rs6000_pic_labelno);
 
-  ASM_GENERATE_INTERNAL_LABEL (buf, "LCTOC", 1);
   fprintf (file, "\t.long ");
-  assemble_name (file, buf);
+  assemble_name (file, toc_label_name);
   putc ('-', file);
   ASM_GENERATE_INTERNAL_LABEL (buf, "LCF", rs6000_pic_labelno);
   assemble_name (file, buf);

Jakub

Re: [C++ PATCH] Handle error_mark_node in cp_fold (alt; PR c++/68357)

[Mike Stump]

On Jan 26, 2016, at 8:39 AM, Jakub Jelinek  wrote:
> On Tue, Jan 26, 2016 at 02:56:24PM +0100, Jakub Jelinek wrote:
>> Another alternative would be to make sure tree folders don't introduce
>> error_mark_node (if it wasn't there already), but instead fold the call say
>> to build_int_cst (returntype, 0).  The known cases that would need to change
>> are at least darwin_build_constant_cfstring and darwin_fold_builtin, but
>> maybe others.
> 
> Here is the alternative (but it is unclear if other targets don't have
> similar issues in their folders).

So, Jason needs to make the decision on which patch he prefers.

If he prefers that error mark node not be generated this late, then the below 
patch is Ok.

Re: [PATCH] Fix up wi::lrshift (PR c++/69399)

[Mike Stump]

On Jan 26, 2016, at 10:21 AM, Jakub Jelinek  wrote
> The question is, shall we do what wi::lshift does and have the fast path
> only for the constant shifts, as the untested patch below does, or shall we
> check shift dynamically (thus use
> shift < HOST_BITS_PER_WIDE_INT
> instead of
> STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT)
> in the patch),

Hum…  I think I prefer the dynamic check.  The reasoning is that when we fast 
path, we can tolerate the conditional branch to retain the fast path, as most 
of the time, that condition will usually be true.  If the compiler had troubles 
with knowing the usual truth value of the expression, seems like we can hint 
that it will be true and influence the static prediction of the branch.  This 
permits us to fast path almost all the time in the non-constant, but small 
enough case.  For known shifts, there is no code gen difference, so it doesn’t 
matter.

[PATCH] Fix up wi::lrshift (PR c++/69399)

[Jakub Jelinek]

Hi!

On Tue, Jan 26, 2016 at 04:54:43PM +0100, Richard Biener wrote:
> > Somehow PR 65656 miscompiled:
> >
> >   if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
> >   ? xi.len == 1 && xi.val[0] >= 0
> >   : xi.precision <= HOST_BITS_PER_WIDE_INT)
> >
> > which turned the expression into true and hit
> >
> >   val[0] = xi.to_uhwi () >> shift;
> >   result.set_len (1);
> 
> I think we need a better analysis as we use __builtin_constant_p
> elsewhere as well.

So, I had a look at this bug and it seems clearly a bug on the wide-int.h
side.  wi::lrshift right now doesn't do what the comment says (which says
that for the larger precision fixed types it only cares about constant
shift).
Compared to wi::lshift, for the
STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
case lrshift doesn't bother to check the value of shift.
While for xi.precision <= HOST_BITS_PER_WIDE_INT, at least conforming code
should not perform out of bounds shifts and thus there is no need to check
the value of shift, for xi.precision > HOST_BITS_PER_WIDE_INT it is
completely valid to have large shift (in between HOST_BITS_PER_WIDE_INT
inclusive and xi.precision exclusive), and then we just trigger undefined
behavior for that case.

The question is, shall we do what wi::lshift does and have the fast path
only for the constant shifts, as the untested patch below does, or shall we
check shift dynamically (thus use
shift < HOST_BITS_PER_WIDE_INT
instead of
STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT)
in the patch), or shall we have another case for such shifts and set
val[0] = 0; then?

The __builtin_constant_p change affects whether we trigger this bug
only for fixed large precision instantiations (with trunk
__builtin_constant_p) or also by mistake for variable large precision
instantiations (with gcc 5 __builtin_constant_p), but the fixed large
precision instantiations are broken in any case.

2016-01-26  Jakub Jelinek  

PR tree-optimization/69399
* wide-int.h (wi::lrshift): For larger precisions, only
use fast path if shift is known to be < HOST_BITS_PER_WIDE_INT.

--- gcc/wide-int.h.jj   2016-01-04 14:55:50.0 +0100
+++ gcc/wide-int.h  2016-01-26 19:05:20.715269366 +0100
@@ -2909,7 +2909,9 @@ wi::lrshift (const T1 &x, const T2 &y)
 For variable-precision integers like wide_int, handle HWI
 and sub-HWI integers inline.  */
   if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
- ? xi.len == 1 && xi.val[0] >= 0
+ ? (STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT)
+&& xi.len == 1
+&& xi.val[0] >= 0)
  : xi.precision <= HOST_BITS_PER_WIDE_INT)
{
  val[0] = xi.to_uhwi () >> shift;


Jakub

Re: [PATCH][ARM] Enable fusion of AES instructions

[Wilco Dijkstra]

ping

> -Original Message-
> From: Wilco Dijkstra [mailto:wilco.dijks...@arm.com]
> Sent: 19 November 2015 18:12
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH][ARM] Enable fusion of AES instructions
>
> Enable instruction fusion of AES instructions on ARM for Cortex-A53 and 
> Cortex-A57.
>
> OK for commit?
>
> ChangeLog:
> 2015-11-20  Wilco Dijkstra  
>
>   * gcc/config/arm/arm.c (arm_cortex_a53_tune): Add AES fusion.
>   (arm_cortex_a57_tune): Likewise.
>   (aarch_macro_fusion_pair_p): Add support for AES fusion.
>   * gcc/config/arm/arm-protos.h (fuse_ops): Add FUSE_AES_AESMC.
>
> ---
>  gcc/config/arm/arm-protos.h | 5 +++--
>  gcc/config/arm/arm.c| 9 +++--
>  2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
> index f9b1276..4801bb8 100644
> --- a/gcc/config/arm/arm-protos.h
> +++ b/gcc/config/arm/arm-protos.h
> @@ -302,8 +302,9 @@ struct tune_params
>enum fuse_ops
>{
>  FUSE_NOTHING   = 0,
> -FUSE_MOVW_MOVT = 1 << 0
> -  } fusible_ops: 1;
> +FUSE_MOVW_MOVT = 1 << 0,
> +FUSE_AES_AESMC = 1 << 1
> +  } fusible_ops: 2;
>/* Depth of scheduling queue to check for L2 autoprefetcher.  */
>enum {SCHED_AUTOPREF_OFF, SCHED_AUTOPREF_RANK, SCHED_AUTOPREF_FULL}
>  sched_autopref: 2;
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 02f5dc3..7077199 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -1969,7 +1969,7 @@ const struct tune_params arm_cortex_a53_tune =
>tune_params::DISPARAGE_FLAGS_NEITHER,
>tune_params::PREF_NEON_64_FALSE,
>tune_params::PREF_NEON_STRINGOPS_TRUE,
> -  FUSE_OPS (tune_params::FUSE_MOVW_MOVT),
> +  FUSE_OPS (tune_params::FUSE_MOVW_MOVT | tune_params::FUSE_AES_AESMC),
>tune_params::SCHED_AUTOPREF_OFF
>  };
>
> @@ -1992,7 +1992,7 @@ const struct tune_params arm_cortex_a57_tune =
>tune_params::DISPARAGE_FLAGS_ALL,
>tune_params::PREF_NEON_64_FALSE,
>tune_params::PREF_NEON_STRINGOPS_TRUE,
> -  FUSE_OPS (tune_params::FUSE_MOVW_MOVT),
> +  FUSE_OPS (tune_params::FUSE_MOVW_MOVT | tune_params::FUSE_AES_AESMC),
>tune_params::SCHED_AUTOPREF_FULL
>  };
>
> @@ -29668,6 +29668,11 @@ aarch_macro_fusion_pair_p (rtx_insn* prev, rtx_insn* 
> curr)
>  && REGNO (SET_DEST (curr_set)) == REGNO (SET_DEST (prev_set)))
>return true;
>  }
> +
> +  if (current_tune->fusible_ops & tune_params::FUSE_AES_AESMC
> +  && aarch_crypto_can_dual_issue (prev, curr))
> +return true;
> +
>return false;
>  }
>
> --
> 1.9.1

Re: [PATCH][AArch64] Add TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS

[Wilco Dijkstra]

ping (note the regressions discussed below are addressed by 
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01761.html)


From: Wilco Dijkstra
Sent: 17 December 2015 13:37
To: James Greenhalgh
Cc: gcc-patches@gcc.gnu.org; nd
Subject: RE: [PATCH][AArch64] Add TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS

James Greenhalgh wrote:
> On Wed, Dec 16, 2015 at 01:05:21PM +, Wilco Dijkstra wrote:
> > James Greenhalgh wrote:
> > > On Tue, Dec 15, 2015 at 10:54:49AM +, Wilco Dijkstra wrote:
> > > > ping
> > > >
> > > > > -Original Message-
> > > > > From: Wilco Dijkstra [mailto:wilco.dijks...@arm.com]
> > > > > Sent: 06 November 2015 20:06
> > > > > To: 'gcc-patches@gcc.gnu.org'
> > > > > Subject: [PATCH][AArch64] Add TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS
> > > > >
> > > > > This patch adds support for the TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS
> > > > > hook. When the cost of GENERAL_REGS and FP_REGS is identical, the 
> > > > > register
> > > > > allocator always uses ALL_REGS even when it has a much higher cost. 
> > > > > The
> > > > > hook changes the class to either FP_REGS or GENERAL_REGS depending on 
> > > > > the
> > > > > mode of the register. This results in better register allocation 
> > > > > overall,
> > > > > fewer spills and reduced codesize - particularly in SPEC2006 gamess.
> > > > >
> > > > > GCC regression passes with several minor fixes.
> > > > >
> > > > > OK for commit?
> > > > >
> > > > > ChangeLog:
> > > > > 2015-11-06  Wilco Dijkstra  
> > > > >
> > > > >   * gcc/config/aarch64/aarch64.c
> > > > >   (TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS): New define.
> > > > >   (aarch64_ira_change_pseudo_allocno_class): New function.
> > > > >   * gcc/testsuite/gcc.target/aarch64/cvtf_1.c: Build with -O2.
> > > > >   * gcc/testsuite/gcc.target/aarch64/scalar_shift_1.c
> > > > >   (test_corners_sisd_di): Improve force to SIMD register.
> > > > >   (test_corners_sisd_si): Likewise.
> > > > >   * gcc/testsuite/gcc.target/aarch64/vdup_lane_2.c: Build with 
> > > > > -O2.
> > > > >   * gcc/testsuite/gcc.target/aarch64/vect-ld1r-compile-fp.c:
> > > > >   Remove scan-assembler check for ldr.
> > >
> > > Drop the gcc/ from the ChangeLog.
> > >
> > > > > --
> > > > >  gcc/config/aarch64/aarch64.c   | 22 
> > > > > ++
> > > > >  gcc/testsuite/gcc.target/aarch64/cvtf_1.c  |  2 +-
> > > > >  gcc/testsuite/gcc.target/aarch64/scalar_shift_1.c  |  4 ++--
> > > > >  gcc/testsuite/gcc.target/aarch64/vdup_lane_2.c |  2 +-
> > > > >  .../gcc.target/aarch64/vect-ld1r-compile-fp.c  |  1 -
> > >
> > > These testsuite changes concern me a bit, and you don't mention them 
> > > beyond
> > > saying they are minor fixes...
> >
> > Well any changes to register allocator preferencing would cause fallout in
> > tests that are assuming which register is allocated, especially if they use
> > nasty inline assembler hacks to do so...
>
> Sure, but the testcases here each operate on data that should live in
> FP_REGS given the initial conditions that the nasty hacks try to mimic -
> that's what makes the regressions notable.
>
> >
> > > > >  #define FCVTDEF(ftype,itype) \
> > > > >  void \
> > > > > diff --git a/gcc/testsuite/gcc.target/aarch64/scalar_shift_1.c 
> > > > > b/gcc/testsuite/gcc.target/aarch64/scalar_shift_1.c
> > > > > index 363f554..8465c89 100644
> > > > > --- a/gcc/testsuite/gcc.target/aarch64/scalar_shift_1.c
> > > > > +++ b/gcc/testsuite/gcc.target/aarch64/scalar_shift_1.c
> > > > > @@ -186,9 +186,9 @@ test_corners_sisd_di (Int64x1 b)
> > > > >  {
> > > > >force_simd_di (b);
> > > > >b = b >> 63;
> > > > > +  force_simd_di (b);
> > > > >b = b >> 0;
> > > > >b += b >> 65; /* { dg-warning "right shift count >= width of type" 
> > > > > } */
> > > > > -  force_simd_di (b);
> > >
> > > This one I don't understand, but seems to say that we've decided to move
> > > b out of FP_REGS after getting it in there for b = b << 63; ? So this is
> > > another register allocator regression?
> >
> > No, basically the register allocator is now making better decisions as to
> > where to allocate integer variables. It will only allocate them to FP
> > registers if they are primarily used by other FP operations. The
> > force_simd_di inline assembler tries to mimic FP uses, and if there are
> > enough of them at the right places then everything works as expected.  If
> > however you do 3 consecutive integer operations then the allocator will now
> > correctly prefer to allocate them to the integer registers (while previously
> > it wouldn't, which is inefficient).
>
> I'm not sure I understand this argument in the abstract (though I believe
> it for some of the supported cores for the AArch64 target). At an abstract
> level, given a set of operations which can execute in either FP_REGS or
> GENERAL_REGS and initial and post conditions that allocate all input and
> output register

Re: [Fortran, gcc-5, patch, pr69268, v1] [5 Regression] Sourced allocation calls function twice

[Paul Richard Thomas]

Dear Andre,

The patch looks fine to me. OK for 5-branch.

Thanks for the patch.

Paul

On 26 January 2016 at 13:28, Andre Vehreschild  wrote:
> Hi all,
>
> please find attached a patch to solve the issue of evaluating a source=
> expression of an allocate() twice in gcc-5. The patch is a combination
> and partial back port of several prs of the mainline (namely, but not
> the complete list: pr44672, pr65548).
>
> The patch needed the counts of builtin_mallocs/frees in
> allocatable_scalar_13 to be adapted. There are now fewer calls to the
> memory management routines. Valgrind does not report any memory issues
> in the modified code, but that does not mean there aren't any. I am
> happy to hear about any issue, this patch causes (still having issues
> getting the sanitizer to work).
>
> Bootstrapped and regtested on x86_64-linux-gnu/F23.
>
> Ok, for gcc-5-branch?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de



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

Albert Einstein

[trans-mem, committed] Fix 60908

[Richard Henderson]

Just a silly think-o in building the tm region tree,
which resulted in the one region being found twice.


r~
PR middle-end/60908
* trans-mem.c (tm_region_init): Mark entry block as visited.

testsuite/
* gcc.dg/tm/pr60908.c: New test.



diff --git a/gcc/testsuite/gcc.dg/tm/pr60908.c 
b/gcc/testsuite/gcc.dg/tm/pr60908.c
new file mode 100644
index 000..773438d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tm/pr60908.c
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-fgnu-tm" } */
+
+int t, v;
+
+int
+foo (void)
+{
+  while (1)
+{
+  __transaction_atomic { v++; }
+  if (t)
+return 0;
+}
+}
diff --git a/gcc/trans-mem.c b/gcc/trans-mem.c
index b204760..500071f 100644
--- a/gcc/trans-mem.c
+++ b/gcc/trans-mem.c
@@ -2039,16 +2039,17 @@ tm_region_init (struct tm_region *region)
   struct tm_region *old_region;
   auto_vec bb_regions;
 
-  all_tm_regions = region;
-  bb = single_succ (ENTRY_BLOCK_PTR_FOR_FN (cfun));
-
   /* We could store this information in bb->aux, but we may get called
  through get_all_tm_blocks() from another pass that may be already
  using bb->aux.  */
   bb_regions.safe_grow_cleared (last_basic_block_for_fn (cfun));
 
+  all_tm_regions = region;
+  bb = single_succ (ENTRY_BLOCK_PTR_FOR_FN (cfun));
   queue.safe_push (bb);
+  bitmap_set_bit (visited_blocks, bb->index);
   bb_regions[bb->index] = region;
+
   do
 {
   bb = queue.pop ();

Re: Patch RFA: Add option -fcollectible-pointers, use it in ivopts

[Ian Lance Taylor]

On Tue, Jan 26, 2016 at 8:03 AM, David Malcolm  wrote:
>
> Is the patch missing some logic to make the option be enabled by default
> for gc-using languages?  (presumably go, and maybe java?)

I am intentionally leaving that to a separate patch, yes.  I think
this option is useful by itself for C/C++ programs that intend to use
something like the Boehm collector.  If the option is not useful by
itself, then a different approach may be appropriate.

Ian

[PR 69355] Correct hole detection when total_scalarization fails

[Martin Jambor]

Hi,

PR 69355 has revealed that when SRA attempts total scalarization of an
aggregate but this fails because the user type-casts a scalar field
and stores into a it a smaller aggregate (and the scalar field is not
written to, whether directly or as a part of an aggregate store), the
pass can loose track of unscalarized data there.

I think that this can happen only when violating strict aliasing rules
but with -fno-strict-aliasing it should work.

Fixed thusly with the patch below (the condition is there to avoid
detecting padding after aggregate-fields in totally-scalarized
aggregates as unscalarized data).  Bootstrapped and tested on
x86_64-linux.  OK for trunk?  And the gcc-5 branch?

Thanks,

Martin


2016-01-26  Martin Jambor  

PR tree-optimization/69355
* tree-sra.c (analyze_access_subtree): Correct hole detection when
total_scalarization fails.

testsuite/
* gcc.dg/tree-ssa/pr69355.c: New test.

---
 gcc/testsuite/gcc.dg/tree-ssa/pr69355.c | 44 +
 gcc/tree-sra.c  |  2 +-
 2 files changed, 45 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr69355.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr69355.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr69355.c
new file mode 100644
index 000..f515c21
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr69355.c
@@ -0,0 +1,44 @@
+/* { dg-do run } */
+/* { dg-options "-O -fno-strict-aliasing" } */
+
+struct S
+{
+  void *a;
+  long double b;
+};
+
+struct Z
+{
+  long long l;
+  short s;
+} __attribute__((packed));
+
+struct S __attribute__((noclone, noinline))
+foo (void *v, struct Z *z)
+{
+  struct S t;
+  t.a = v;
+  *(struct Z *) &t.b = *z;
+  return t;
+}
+
+struct Z gz;
+
+int
+main (int argc, char **argv)
+{
+  struct S s;
+
+  if (sizeof (long double) < sizeof (struct Z))
+return 0;
+
+  gz.l = 0xbeef;
+  gz.s = 0xab;
+
+  s = foo ((void *) 0, &gz);
+
+  if struct Z *) &s.b)->l != gz.l)
+  || (((struct Z *) &s.b)->s != gz.s))
+__builtin_abort ();
+  return 0;
+}
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 740542f..b0e737a 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2421,7 +2421,7 @@ analyze_access_subtree (struct access *root, struct 
access *parent,
 
   if (covered_to < limit)
hole = true;
-  if (scalar)
+  if (scalar || !allow_replacements)
root->grp_total_scalarization = 0;
 }
 
-- 
2.7.0

Re: [PATCH, 69217]: [6 Regression] ICE at var-tracking.c:5038 Segmentation fault

[Alexandre Oliva]

On Jan 23, 2016, Iain Buclaw  wrote:

>   PR rtl-optimization/69217
>   * var-tracking.c (tracked_record_parameter_p): Don't segfault if there
>   are no TYPE_FIELDS set for the record type.

This looks good to me, thanks.

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

[PR69315] enable finish_function to recurse for constexpr functions

[Alexandre Oliva]

We don't want finish_function to be called recursively from mark_used.
However, it's desirable and necessary to call itself recursively when
performing delayed folding, because that may have to instantiate and
evaluate constexpr template functions.

So, arrange for finish_function to accept being called recursively
during delayed folding, save and restore the controlling variables,
and process the deferred mark_used calls only when the outermost call
completes.

Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok to install?

for  gcc/cp/ChangeLog

PR c++/69315
* decl.c (is_folding_function): New variable.
(finish_function): Test, save and set it.

for  gcc/testsuite/ChangeLog

PR c++/69315
* g++.dg/pr69315.C: New.
---
 gcc/cp/decl.c  |   31 +--
 gcc/testsuite/g++.dg/pr69315.C |   34 ++
 2 files changed, 59 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr69315.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index f4604b6..65eff2f 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -227,10 +227,14 @@ struct GTY((for_user)) named_label_entry {
function, two inside the body of a function in a local class, etc.)  */
 int function_depth;
 
-/* To avoid unwanted recursion, finish_function defers all mark_used calls
-   encountered during its execution until it finishes.  */
+/* To avoid unwanted recursion, finish_function defers all mark_used
+   calls encountered during its execution until it finishes.
+   finish_function refuses to be called recursively, unless the
+   recursion occurs during folding, which often requires instantiating
+   and evaluating template functions.  */
 bool defer_mark_used_calls;
 vec *deferred_mark_used_calls;
+static bool is_folding_function;
 
 /* States indicating how grokdeclarator() should handle declspecs marked
with __attribute__((deprecated)).  An object declared as
@@ -14528,8 +14532,11 @@ finish_function (int flags)
   if (c_dialect_objc ())
 objc_finish_function ();
 
-  gcc_assert (!defer_mark_used_calls);
+  gcc_assert (!defer_mark_used_calls
+ || (is_folding_function && DECL_DECLARED_CONSTEXPR_P (fndecl)));
   defer_mark_used_calls = true;
+  bool save_folding_function = is_folding_function;
+  is_folding_function = false;
 
   record_key_method_defined (fndecl);
 
@@ -14636,7 +14643,14 @@ finish_function (int flags)
 
   /* Perform delayed folding before NRV transformation.  */
   if (!processing_template_decl)
-cp_fold_function (fndecl);
+{
+  is_folding_function = true;
+  cp_fold_function (fndecl);
+  /* Check that our controlling variables were restored to the
+expect state.  */
+  gcc_assert (is_folding_function && defer_mark_used_calls);
+  is_folding_function = false;
+}
 
   /* Set up the named return value optimization, if we can.  Candidate
  variables are selected in check_return_expr.  */
@@ -14780,8 +14794,13 @@ finish_function (int flags)
   /* Clean up.  */
   current_function_decl = NULL_TREE;
 
-  defer_mark_used_calls = false;
-  if (deferred_mark_used_calls)
+  is_folding_function = save_folding_function;
+  /* Iff we were called recursively for a constexpr function,
+ is_folding_function was just restored to TRUE.  If we weren't
+ called recursively, it was restored to FALSE.  That's just how
+ defer_mark_used_call ought to be set.  */
+  defer_mark_used_calls = is_folding_function;
+  if (!defer_mark_used_calls && deferred_mark_used_calls)
 {
   unsigned int i;
   tree decl;
diff --git a/gcc/testsuite/g++.dg/pr69315.C b/gcc/testsuite/g++.dg/pr69315.C
new file mode 100644
index 000..28975b6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr69315.C
@@ -0,0 +1,34 @@
+// { dg-do compile }
+// { dg-options "-std=c++11" }
+
+// Template instantiation and evaluation for folding within
+// finish_function may call finish_function recursively.
+// Make sure we don't reject or delay that sort of recursion.
+
+template  struct Iter;
+
+struct Arg {
+  Iter begin();
+  Iter end();
+};
+
+template  struct Iter {
+  int operator*();
+  Iter operator++();
+  template  friend constexpr bool operator==(Iter, 
Iter);
+  template  friend constexpr bool operator!=(Iter, 
Iter);
+};
+
+void func(Arg a) {
+  for (auto ch : a) {
+a.begin() == a.end();
+  }
+}
+
+template  constexpr bool operator==(Iter, Iter) {
+  return true;
+}
+
+template  constexpr bool operator!=(Iter a, Iter b) {
+  return a == b;
+}

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

Re: [PATCH][ARM] Fix PR target/69245 Rewrite arm_set_current_function

[Kyrill Tkachov]

On 26/01/16 16:56, Christian Bruel wrote:



On 01/26/2016 04:58 PM, Kyrill Tkachov wrote:

Hi Christian,

On 26/01/16 15:29, Christian Bruel wrote:


On 01/25/2016 05:37 PM, Kyrill Tkachov wrote:


So this is ok for trunk with the testcase changed as discussed above and using 
-O2
optimisation level and with a couple comment fixes below.

Hi Kyrill,

I realized afterwards that my implementation had a flaw with the handling of 
#pragma GCC reset. What happened is that when both old and new 
TREE_TARGET_OPTION are NULL, we didn't save_restore the globals flags, to save 
compute time. The
problem is that with #pragma GCC reset, we also fall into this situation, and 
exit without calling target_reeinit :-(

Handling this situation doesn't complicate the code much, because I factorized 
the calls to target_reeinit + restore_target_globals into a new function 
(save_restore_target_globals). This function is called from the pragma context 
when
resetting the state arm_reset_previous_fndecl to the default, and from 
arm_set_current_function when setting to a new target. This is only done when 
there is a change of the target flags, so no extra computing cost.

Same testing as with previous patch:
 arm-qemu/
 arm-qemu//-mfpu=neon-fp-armv8
 arm-qemu//-mfpu=neon

Still OK ?


+/* Restore the TREE_TARGET_GLOBALS from previous state, or save it.  */
+static void
+save_restore_target_globals (tree new_tree)
+{
+  /* If we have a previous state, use it.  */
+  if (TREE_TARGET_GLOBALS (new_tree))
+restore_target_globals (TREE_TARGET_GLOBALS (new_tree));
+  else if (new_tree == target_option_default_node)
+restore_target_globals (&default_target_globals);
+  else
+{
+  /* Call target_reinit and save the state for TARGET_GLOBALS.  */
+  TREE_TARGET_GLOBALS (new_tree) = save_target_globals_default_opts ();
+}
+
+  arm_option_params_internal ();
+}

Space before the function comment and signature.
what do you mean ?  a new line between the comment and the function signature ? I usually mimic what's done in the other arm.c declarations, which sometimes have a new line, sometime not. It's not clear to me what's mandatory here, even 
in the other parts of the compiler.




Yes, I meant new line, sorry. A new line is the rule, though there are some
functions that don't follow it. I guess we can fix those as we encounter them.


  Also, you need to document what is the NEW_TREE
parameter.

   /* Invalidate arm_previous_fndecl.  */
   void
-arm_reset_previous_fndecl (void)
+arm_reset_previous_fndecl (tree new_tree)
   {
+  if (new_tree)
+save_restore_target_globals (new_tree);
+
 arm_previous_fndecl = NULL_TREE;
   }

I'm a bit wary of complicating this function. Suddenly it doesn't just reset 
the previous fndecl
but also restores globals and can save stuff into its argument. It's suddenly 
not clear what it's
purpose is.
I think it would be clearer if you just added save_restore_target_globals to 
arm_protos.h and called
it explicitly from arm_pragma_target_parse when appropriate.


sure, like this one attached (sanity checked) ?




This is ok if it passes a proper testing round.

Thanks,
Kyrill




+
+  /* If nothing to do return. #pragma GCC reset or #pragma GCC pop to
+ the default have been handled by save_restore_target_globals from
+ arm_pragma_target_parse.  */

Two spaces between fullstop and "#pragma GCC".


thanks,

Christian

Re: [PATCH, PR69110] Don't return NULL access_fns in dr_analyze_indices

[Sebastian Pop]

Tom de Vries wrote:
> diff --git a/gcc/tree-data-ref.c b/gcc/tree-data-ref.c
> index a40f40d..4c29fc2 100644
> --- a/gcc/tree-data-ref.c
> +++ b/gcc/tree-data-ref.c
> @@ -1510,8 +1510,9 @@ initialize_data_dependence_relation (struct 
> data_reference *a,
>if (operand_equal_p (DR_REF (a), DR_REF (b), 0))
>  {
>   if (loop_nest.exists ()
> -&& !object_address_invariant_in_loop_p (loop_nest[0],
> - DR_BASE_OBJECT (a)))
> +  && (!object_address_invariant_in_loop_p (loop_nest[0],
> +   DR_BASE_OBJECT (a))
> +  || DR_NUM_DIMENSIONS (a) == 0))

Also please fix the indentation of all this if stmt.

>{
>  DDR_ARE_DEPENDENT (res) = chrec_dont_know;
>  return res;
> @@ -1548,8 +1549,9 @@ initialize_data_dependence_relation (struct 
> data_reference *a,
>   analyze it.  TODO -- in fact, it would suffice to record that there may
>   be arbitrary dependences in the loops where the base object varies.  */
>if (loop_nest.exists ()
> -  && !object_address_invariant_in_loop_p (loop_nest[0],
> -   DR_BASE_OBJECT (a)))
> +  && (!object_address_invariant_in_loop_p (loop_nest[0],
> +DR_BASE_OBJECT (a))
> +   || DR_NUM_DIMENSIONS (a) == 0))
>  {
>DDR_ARE_DEPENDENT (res) = chrec_dont_know;
>return res;

Let's check for DR_NUM_DIMENSIONS (a) == 0 independently of loop_nest.exists ().
We check for the loop_nest because we need to access the outer loop loop_nest[0]
to analyze the base object of a.

Otherwise the change looks good to me.

Thanks,
Sebastian

Re: Speedup configure and build with system.h

[Michael Matz]

Hi,

On Tue, 26 Jan 2016, Uros Bizjak wrote:

> > Meh.  Can you try the attached patch with a configure test (it 
> > includes the generated files)?  It works for me with 4.3.4, and should 
> > make your build include  always.
> 
> Yes, this patch works for me and allows bootstrap with gcc-4.1.2 to 
> finish.

Thanks for checking.  r232836 now.


Ciao,
Michael.

[C++ PATCH] Handle error_mark_node in cp_fold (alt; PR c++/68357)

[Jakub Jelinek]

On Tue, Jan 26, 2016 at 02:56:24PM +0100, Jakub Jelinek wrote:
> Another alternative would be to make sure tree folders don't introduce
> error_mark_node (if it wasn't there already), but instead fold the call say
> to build_int_cst (returntype, 0).  The known cases that would need to change
> are at least darwin_build_constant_cfstring and darwin_fold_builtin, but
> maybe others.

Here is the alternative (but it is unclear if other targets don't have
similar issues in their folders).

I have no access to Darwin, so all I've done was test it on the preprocessed
source from the PR.

2016-01-26  Jakub Jelinek  

PR c++/68357
* config/darwin.c (darwin_fold_builtin): For errorneous use
of the __builtin___CFStringMakeConstantString builtin return
constant 0 in the right type rather than error_mark_node.

--- gcc/config/darwin.c.jj  2016-01-04 14:55:54.0 +0100
+++ gcc/config/darwin.c 2016-01-26 17:28:12.489018588 +0100
@@ -3345,19 +3345,17 @@ darwin_fold_builtin (tree fndecl, int n_
   if (fcode == darwin_builtin_cfstring)
 {
   if (!darwin_constant_cfstrings)
+   error ("built-in function %qD requires the" 
+  " %<-mconstant-cfstrings%> flag", fndecl);
+  else if (n_args != 1)
+   error ("built-in function %qD takes one argument only", fndecl);
+  else
{
- error ("built-in function %qD requires the" 
-" %<-mconstant-cfstrings%> flag", fndecl);
- return error_mark_node;
+ tree ret = darwin_build_constant_cfstring (*argp);
+ if (ret != error_mark_node)
+   return ret;
}
-
-  if (n_args != 1)
-   {
- error ("built-in function %qD takes one argument only", fndecl);
- return error_mark_node;
-   }
-
-  return darwin_build_constant_cfstring (*argp);
+  return build_int_cst (TREE_TYPE (TREE_TYPE (fndecl)), 0);
 }
 
   return NULL_TREE;


Jakub

[PATCH] Fix PR c++/69139 (deduction failure with trailing return type)

[Patrick Palka]

This patch makes the parser more robust in determining whether an 'auto'
specifier that appears in a parameter declaration corresponds to a
placeholder for a late return type, or corresponds to an implicit
template parameter as for an abbreviated function template.

Bootstrap + regtest in progress on x86_64-pc-linux-gnu, will also test
this change against Boost.  OK to commit if testing succeeds?  What
about for GCC 4.9/5?

gcc/cp/ChangeLog:

PR c++/69139
* parser.c (cp_parser_simple_type_specifier): Make the check
for disambiguating between an 'auto' placeholder and an implicit
template parameter more robust.

gcc/testsuite/ChangeLog:

PR c++/69139
* g++.dg/cpp0x/auto47.C: New test.
---
 gcc/cp/parser.c | 33 +++--
 gcc/testsuite/g++.dg/cpp0x/auto47.C | 20 
 2 files changed, 43 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/auto47.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d03b0c9..56c834f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -16032,20 +16032,33 @@ cp_parser_simple_type_specifier (cp_parser* parser,
  /* The 'auto' might be the placeholder return type for a function decl
 with trailing return type.  */
  bool have_trailing_return_fn_decl = false;
- if (cp_lexer_peek_nth_token (parser->lexer, 2)->type
- == CPP_OPEN_PAREN)
+
+ cp_parser_parse_tentatively (parser);
+ cp_lexer_consume_token (parser->lexer);
+ while (cp_lexer_next_token_is_not (parser->lexer, CPP_EQ)
+&& cp_lexer_next_token_is_not (parser->lexer, CPP_COMMA)
+&& cp_lexer_next_token_is_not (parser->lexer, CPP_CLOSE_PAREN)
+&& cp_lexer_next_token_is_not (parser->lexer, CPP_EOF))
{
- cp_parser_parse_tentatively (parser);
- cp_lexer_consume_token (parser->lexer);
- cp_lexer_consume_token (parser->lexer);
- if (cp_parser_skip_to_closing_parenthesis (parser,
+ if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_PAREN))
+   {
+ cp_lexer_consume_token (parser->lexer);
+ cp_parser_skip_to_closing_parenthesis (parser,
 /*recovering*/false,
 /*or_comma*/false,
-/*consume_paren*/true))
-   have_trailing_return_fn_decl
- = cp_lexer_next_token_is (parser->lexer, CPP_DEREF);
- cp_parser_abort_tentative_parse (parser);
+/*consume_paren*/true);
+ continue;
+   }
+
+ if (cp_lexer_next_token_is (parser->lexer, CPP_DEREF))
+   {
+ have_trailing_return_fn_decl = true;
+ break;
+   }
+
+ cp_lexer_consume_token (parser->lexer);
}
+ cp_parser_abort_tentative_parse (parser);
 
  if (have_trailing_return_fn_decl)
{
diff --git a/gcc/testsuite/g++.dg/cpp0x/auto47.C 
b/gcc/testsuite/g++.dg/cpp0x/auto47.C
new file mode 100644
index 000..08adf31
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/auto47.C
@@ -0,0 +1,20 @@
+// PR c++/69139
+// { dg-do compile { target c++11 } }
+
+auto get(int) -> int { return {}; }
+template  int f(auto (*)(int) -> R) { return {}; }
+int i = f(get);
+
+int foo1 (auto (int) -> char);
+
+int foo2 (auto f(int) -> char);
+
+int foo2 (auto (f)(int) -> char);
+
+int foo3 (auto (*f)(int) -> char);
+
+int foo4 (auto (*const **&f)(int) -> char);
+
+int foo5 (auto (*const **&f)(int, int *) -> char);
+
+int foo6 (auto (int) const -> char); // { dg-error "const" }
-- 
2.7.0.134.gf5046bd.dirty

Re: [C PATCH] Fix -Wunused-function (PR debug/66869)

[Jakub Jelinek]

On Tue, Jan 26, 2016 at 04:21:08PM +0100, Richard Biener wrote:
> > --- gcc/c/c-decl.c.jj   2016-01-21 00:41:47.0 +0100
> > +++ gcc/c/c-decl.c  2016-01-25 16:36:31.973504082 +0100
> > @@ -10741,11 +10741,19 @@ c_write_global_declarations_1 (tree glob
> >if (TREE_CODE (decl) == FUNCTION_DECL
> >   && DECL_INITIAL (decl) == 0
> >   && DECL_EXTERNAL (decl)
> > - && !TREE_PUBLIC (decl)
> > - && C_DECL_USED (decl))
> > + && !TREE_PUBLIC (decl))
> > {
> > - pedwarn (input_location, 0, "%q+F used but never defined", decl);
> > - TREE_NO_WARNING (decl) = 1;
> > + if (C_DECL_USED (decl))
> > +   {
> > + pedwarn (input_location, 0, "%q+F used but never defined", 
> > decl);
> > + TREE_NO_WARNING (decl) = 1;
> > +   }
> > + /* For -Wunused-function push the unused statics into cgraph,
> > +so that check_global_declaration emits the warning.  */
> > + else if (warn_unused_function
> > +  && ! DECL_ARTIFICIAL (decl)
> > +  && ! TREE_NO_WARNING (decl))
> > +   cgraph_node::get_create (decl);
> 
> Err, so why not warn here directly?

You mean check if it has a cgraph node (i.e. get instead of get_create) and
if it doesn't, warn?  What I'm worried in that case is that it might have a
cgraph node created later on for whatever reason and that we'll get double
warning (from here and from cgraphunit.c (check_global_declaration)).
I can try it though.

Jakub

Re: [PATCH] PR c++/69399: Add HAVE_WORKING_CXX_BUILTIN_CONSTANT_P

[Jakub Jelinek]

On Tue, Jan 26, 2016 at 04:54:43PM +0100, Richard Biener wrote:
> > Somehow PR 65656 miscompiled:
> >
> >   if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
> >   ? xi.len == 1 && xi.val[0] >= 0
> >   : xi.precision <= HOST_BITS_PER_WIDE_INT)
> >
> > which turned the expression into true and hit
> >
> >   val[0] = xi.to_uhwi () >> shift;
> >   result.set_len (1);
> 
> I think we need a better analysis as we use __builtin_constant_p
> elsewhere as well.

Yeah, it would be nice to understand the somehow and what exactly is gong
on.
So, what is xi.precision, is it variable or constant, what value does it
have, has __builtin_constant_p returned 1 when it was supposed to return 0?
But then there would be still the precision check.
What is xi.len and xi.val[0]?

Jakub

Re: Wonly-top-basic-asm

[Segher Boessenkool]

On Tue, Jan 26, 2016 at 01:11:36PM +0100, Bernd Schmidt wrote:
> On 01/26/2016 01:29 AM, Segher Boessenkool wrote:
> 
> >In my opinion we should not warn for any asm that means the same both
> >as basic and as extended asm.  The problem then becomes, what *is* the
> >meaning of a basic asm, what does it clobber.
> 
> I think this may be too hard to figure out in general without parsing 
> the asm string, which we don't really want to do.

That depends on the semantics of basic asm.  With the currently implemented
semantics, it is trivial.


Segher

[Patch AArch64] Restrict 16-bit sqrdml{sa}h instructions to FP_LO_REGS

[James Greenhalgh]

Hi,

In their forms using 16-bit lanes, the sqrdmlah and sqrdmlsh instruction
available when compiling with -march=armv8.1-a are only usable with
a register number in the range 0 to 15 for operand 3, as gas will point
out:

  Error: register number out of range 0 to 15 at
operand 3 -- `sqrdmlsh v2.4h,v4.4h,v23.h[5]'

This patch teaches GCC to avoid registers outside of this range when
appropriate, in the same fashion as we do for other instructions with
this limitation.

Tested on an internal testsuite targeting Neon intrinsics.

OK?

Thanks,
James

---
2016-01-25  James Greenhalgh  

* config/aarch64/aarch64.md
(arch64_sqrdmlh_lane): Fix register
constraints for operand 3.
(aarch64_sqrdmlh_laneq): Likewise.

diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index e1f5682..0b46e78 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -3240,7 +3240,7 @@
 	  [(match_operand:VDQHS 1 "register_operand" "0")
 	   (match_operand:VDQHS 2 "register_operand" "w")
 	   (vec_select:
-	 (match_operand: 3 "register_operand" "w")
+	 (match_operand: 3 "register_operand" "")
 	 (parallel [(match_operand:SI 4 "immediate_operand" "i")]))]
 	  SQRDMLH_AS))]
"TARGET_SIMD_RDMA"
@@ -3258,7 +3258,7 @@
 	  [(match_operand:SD_HSI 1 "register_operand" "0")
 	   (match_operand:SD_HSI 2 "register_operand" "w")
 	   (vec_select:
-	 (match_operand: 3 "register_operand" "w")
+	 (match_operand: 3 "register_operand" "")
 	 (parallel [(match_operand:SI 4 "immediate_operand" "i")]))]
 	  SQRDMLH_AS))]
"TARGET_SIMD_RDMA"
@@ -3278,7 +3278,7 @@
 	  [(match_operand:VDQHS 1 "register_operand" "0")
 	   (match_operand:VDQHS 2 "register_operand" "w")
 	   (vec_select:
-	 (match_operand: 3 "register_operand" "w")
+	 (match_operand: 3 "register_operand" "")
 	 (parallel [(match_operand:SI 4 "immediate_operand" "i")]))]
 	  SQRDMLH_AS))]
"TARGET_SIMD_RDMA"
@@ -3296,7 +3296,7 @@
 	  [(match_operand:SD_HSI 1 "register_operand" "0")
 	   (match_operand:SD_HSI 2 "register_operand" "w")
 	   (vec_select:
-	 (match_operand: 3 "register_operand" "w")
+	 (match_operand: 3 "register_operand" "")
 	 (parallel [(match_operand:SI 4 "immediate_operand" "i")]))]
 	  SQRDMLH_AS))]
"TARGET_SIMD_RDMA"

Re: Patch RFA: Add option -fcollectible-pointers, use it in ivopts

[David Malcolm]

On Tue, 2016-01-26 at 05:35 -0800, Ian Lance Taylor wrote:
[...]

> Index: common.opt
> ===
> --- common.opt  (revision 232580)
> +++ common.opt  (working copy)
> @@ -1380,6 +1380,10 @@
>  Enable hoisting adjacent loads to encourage generating conditional move
>  instructions.
>  
> +fkeep-gc-roots-live
> +Common Report Var(flag_keep_gc_roots_live) Optimization
> +Always keep a pointer to a live memory block
> +
>  floop-parallelize-all
>  Common Report Var(flag_loop_parallelize_all) Optimization
>  Mark all loops as parallel.
> Index: doc/invoke.texi
> ===
> --- doc/invoke.texi (revision 232580)
> +++ doc/invoke.texi (working copy)
> @@ -359,7 +359,7 @@
>  -fno-ira-share-spill-slots @gol
>  -fisolate-erroneous-paths-dereference -fisolate-erroneous-paths-attribute 
> @gol
>  -fivopts -fkeep-inline-functions -fkeep-static-functions @gol
> --fkeep-static-consts -flive-range-shrinkage @gol
> +-fkeep-static-consts -fkeep-gc-roots-live -flive-range-shrinkage @gol
>  -floop-block -floop-interchange -floop-strip-mine @gol
>  -floop-unroll-and-jam -floop-nest-optimize @gol
>  -floop-parallelize-all -flra-remat -flto -flto-compression-level @gol
> @@ -6621,6 +6621,17 @@
>  If you use @option{-Wunsafe-loop-optimizations}, the compiler warns you
>  if it finds this kind of loop.
>  
> +@item -fkeep-gc-roots-live
> +@opindex fkeep-gc-roots-live
> +This option tells the compiler that a garbage collector will be used,
> +and that therefore the compiled code must retain a live pointer into
> +all memory blocks.  The compiler is permitted to construct a pointer
> +that is outside the bounds of a memory block, but it must ensure that
> +given a pointer into memory, some pointer into that memory remains
> +live in the compiled code whenever it is live in the source code.
> +This option is disabled by default for most languages, enabled by
> +default for languages that use garbage collection.

Is the patch missing some logic to make the option be enabled by default
for gc-using languages?  (presumably go, and maybe java?)

[...snip...]

Re: [PATCH][ARM] Fix PR target/69245 Rewrite arm_set_current_function

[Kyrill Tkachov]

Hi Christian,

On 26/01/16 15:29, Christian Bruel wrote:



On 01/25/2016 05:37 PM, Kyrill Tkachov wrote:


So this is ok for trunk with the testcase changed as discussed above and using 
-O2
optimisation level and with a couple comment fixes below.

Hi Kyrill,

I realized afterwards that my implementation had a flaw with the handling of #pragma GCC reset. What happened is that when both old and new TREE_TARGET_OPTION are NULL, we didn't save_restore the globals flags, to save compute time. The 
problem is that with #pragma GCC reset, we also fall into this situation, and exit without calling target_reeinit :-(


Handling this situation doesn't complicate the code much, because I factorized the calls to target_reeinit + restore_target_globals into a new function (save_restore_target_globals). This function is called from the pragma context when 
resetting the state arm_reset_previous_fndecl to the default, and from arm_set_current_function when setting to a new target. This is only done when there is a change of the target flags, so no extra computing cost.


Same testing as with previous patch:
arm-qemu/
arm-qemu//-mfpu=neon-fp-armv8
arm-qemu//-mfpu=neon

Still OK ?



+/* Restore the TREE_TARGET_GLOBALS from previous state, or save it.  */
+static void
+save_restore_target_globals (tree new_tree)
+{
+  /* If we have a previous state, use it.  */
+  if (TREE_TARGET_GLOBALS (new_tree))
+restore_target_globals (TREE_TARGET_GLOBALS (new_tree));
+  else if (new_tree == target_option_default_node)
+restore_target_globals (&default_target_globals);
+  else
+{
+  /* Call target_reinit and save the state for TARGET_GLOBALS.  */
+  TREE_TARGET_GLOBALS (new_tree) = save_target_globals_default_opts ();
+}
+
+  arm_option_params_internal ();
+}

Space before the function comment and signature. Also, you need to document 
what is the NEW_TREE
parameter.

 /* Invalidate arm_previous_fndecl.  */
 void
-arm_reset_previous_fndecl (void)
+arm_reset_previous_fndecl (tree new_tree)
 {
+  if (new_tree)
+save_restore_target_globals (new_tree);
+
   arm_previous_fndecl = NULL_TREE;
 }

I'm a bit wary of complicating this function. Suddenly it doesn't just reset 
the previous fndecl
but also restores globals and can save stuff into its argument. It's suddenly 
not clear what it's
purpose is.
I think it would be clearer if you just added save_restore_target_globals to 
arm_protos.h and called
it explicitly from arm_pragma_target_parse when appropriate.

+
+  /* If nothing to do return. #pragma GCC reset or #pragma GCC pop to
+ the default have been handled by save_restore_target_globals from
+ arm_pragma_target_parse.  */

Two spaces between fullstop and "#pragma GCC".

Thanks,
Kyrill

Re: [PATCH] PR c++/69399: Add HAVE_WORKING_CXX_BUILTIN_CONSTANT_P

[Richard Biener]

On Mon, Jan 25, 2016 at 5:25 PM, H.J. Lu  wrote:
> On Mon, Jan 25, 2016 at 4:40 AM, Richard Biener
>  wrote:
>> On Fri, Jan 22, 2016 at 7:55 PM, H.J. Lu  wrote:
>>> Without the fix for PR 65656, g++ miscompiles __builtin_constant_p in
>>> wi::lrshift in wide-int.h.  Add a check with PR 65656 testcase to verify
>>> that C++ __builtin_constant_p works properly.
>>>
>>> Tested on x86-64 with working GCC:
>>>
>>> gcc/auto-host.h:/* #undef HAVE_WORKING_CXX_BUILTIN_CONSTANT_P */
>>> prev-gcc/auto-host.h:/* #undef HAVE_WORKING_CXX_BUILTIN_CONSTANT_P */
>>> stage1-gcc/auto-host.h:#define HAVE_WORKING_CXX_BUILTIN_CONSTANT_P 1
>>>
>>> and broken GCC:
>>>
>>> gcc/auto-host.h:/* #undef HAVE_WORKING_CXX_BUILTIN_CONSTANT_P */
>>> prev-gcc/auto-host.h:/* #undef HAVE_WORKING_CXX_BUILTIN_CONSTANT_P */
>>> stage1-gcc/auto-host.h:/* #undef HAVE_WORKING_CXX_BUILTIN_CONSTANT_P */
>>>
>>> Ok for trunk?
>>
>> I have a hard time seeing how we are "miscompiling"
>>
>>   if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
>>   ? xi.len == 1 && xi.val[0] >= 0
>>   : xi.precision <= HOST_BITS_PER_WIDE_INT)
>>
>> anything that relies on __builtin_constant_p () for sematics is fishy so why
>> is this not simply an lrshfit implementation bug?
>>
>
>
> We hit this via:
>
> Breakpoint 1, wi::lrshift
>>, generic_wide_int > > (x=..., y=...)
> at /export/gnu/import/git/sources/gcc-release/gcc/wide-int.h:2898
> 2898  val[0] = xi.to_uhwi () >> shift;
> (gdb) bt
> #0  wi::lrshift >,
> generic_wide_int > > (x=..., y=...)
> at /export/gnu/import/git/sources/gcc-release/gcc/wide-int.h:2898
> #1  0x009e7bbe in
> wi::rshift >,
> generic_wide_int > > (sgn=,
> y=..., x=...)
> at /export/gnu/import/git/sources/gcc-release/gcc/wide-int.h:2947
> #2  bit_value_binop_1 (code=code@entry=RSHIFT_EXPR,
> type=type@entry=0x7fffefe82dc8, val=val@entry=0x7fffd7c0,
> mask=mask@entry=0x7fffd790, r1type=0x7fffefe82dc8, r1val=...,
> r1mask=..., r2type=0x7fffefd6b690, r2val=..., r2mask=...)
> at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:1348
> #3  0x009e9e7b in bit_value_binop (code=code@entry=RSHIFT_EXPR,
> type=0x7fffefe82dc8, rhs1=rhs1@entry=0x7fffefd71708, rhs2=)
> at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:1549
> #4  0x009eb520 in evaluate_stmt (stmt=stmt@entry=0x7fffefe9a160)
> at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:1785
> #5  0x009ec8d2 in visit_assignment (stmt=stmt@entry=0x7fffefe9a160,
> output_p=output_p@entry=0x7fffdba0)
> at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:2258
> #6  0x009ec9c2 in ccp_visit_stmt (stmt=0x7fffefe9a160,
> taken_edge_p=0x7fffdba8, output_p=0x7fffdba0)
> at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:2336
> ---Type  to continue, or q  to quit---
> #7  0x00a4efcf in simulate_stmt (stmt=stmt@entry=0x7fffefe9a160)
> at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-propagate.c:348
> #8  0x00a50f79 in simulate_block (block=)
> at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-propagate.c:471
> #9  ssa_propagate (
> visit_stmt=visit_stmt@entry=0x9ec937  edge*, tree*)>, visit_phi=visit_phi@entry=0x9e6aa5
> )
> at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-propagate.c:888
> #10 0x009e6295 in do_ssa_ccp ()
> at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:2382
> #11 (anonymous namespace)::pass_ccp::execute (this=)
> at /export/gnu/import/git/sources/gcc-release/gcc/tree-ssa-ccp.c:2415
> #12 0x0089ca0c in execute_one_pass (pass=pass@entry=0x19b4bf0)
> at /export/gnu/import/git/sources/gcc-release/gcc/passes.c:2330
> #13 0x0089cd62 in execute_pass_list_1 (pass=0x19b4bf0)
> at /export/gnu/import/git/sources/gcc-release/gcc/passes.c:2382
> #14 0x0089cd7f in execute_pass_list_1 (pass=0x19b4a70,
> pass@entry=0x19b48f0)
> at /export/gnu/import/git/sources/gcc-release/gcc/passes.c:2383
> #15 0x0089cd9c in execute_pass_list (fn=0x7fffefe98000, 
> pass=0x19b48f0)
> at /export/gnu/import/git/sources/gcc-release/gcc/passes.c:2393
> #16 0x0089ba57 in do_per_function_toporder (
> callback=callback@entry=0x89cd83  opt_pass*)>, ---Type  to continue, or q  to quit---
> data=0x19b48f0) at 
> /export/gnu/import/git/sources/gcc-release/gcc/passes.c:1728
> #17 0x0089d3e3 in execute_ipa_pass_list (pass=0x19b4890)
> at /export/gnu/import/git/sources/gcc-release/gcc/passes.c:2736
> #18 0x0066f3ac in ipa_passes ()
> at /export/gnu/import/git/sources/gcc-release/gcc/cgraphunit.c:2172
> #19 symbol_table::compile (this=this@entry=0x7fffefd6b000)
> at /export/gnu/import/git/sources/gcc-release/gcc/cgraphunit.c:2313
> #20 0x00670be5 in symbol_table::finalize_compilation_unit (
> this=0x7fffefd6b000)
> at /export/gnu/imp

Re: [PATCH] Handle -fsanitize=* in lto-wrapper (PR lto/69254)

[Jakub Jelinek]

On Tue, Jan 26, 2016 at 03:06:43PM +0100, Richard Biener wrote:
> I'm somewhat confused about that you drop -fsanitize options from
> the LTO options section writing in lto-opts.c but then add code to
> parse it from there in lto-wrapper.c.  The code there also looks

Sorry, as I said to Bernd, that has been just thinko in the comment change,
the code was doing what I meant to.

> somewhat duplicated - why not just canonicalize any -fsanitize=
> option coming in to the first in merge_and_complain
> and special-case it in append_compiler_options again by say
> 
>   case OPT_fsanitize_:
>  obstack_ptr_grow (argv_obstack, "-fsanitize=shift");

It is certainly much easier to just propagate around a bool flag
whether we need to add -fsanitize=shift after the linker options.
The reason I haven't done that because I didn't want to pass around
yet another argument, furthermore so specific to a particular option.

But looking around, it seems we are already passing around pairs,
the pointer to array of struct cl_decoded_option and pointer to the count of
elements in that array.  By sticking the two into a structure and adding
the sanitize_undefined flag for now, if in the future we need to handle
some other option similarly, we can just handle it in 3-4 spots and not
everywhere among so many different functions.

So, what do you think about the untested patch below (the test with
-c -flto -fsanitize=undefined
-flto -fno-sanitize=undefined
passes)?  The patch is large, because it changed many places from
a pair of pointer and unsigned int (or a pair of pointer to pointer and
pointer to unsigned int) to pointer to this new struct.

2016-01-26  Jakub Jelinek  

PR lto/69254
* lto-opts.c (lto_write_options): Write also -f{,no-}sanitize=
options.
* lto-wrapper.c (struct lto_decoded_options): New type.
(append_option, merge_and_complain, append_compiler_options,
append_linker_options, append_offload_options,
compile_offload_image, compile_images_for_offload_targets,
find_and_merge_options): Pass around options
in struct lto_decoded_options instead of struct cl_decoded_option
pointer and count pair.
(get_options_from_collect_gcc_options): Likewise.  Parse -fsanitize=
options and if in the end any ub sanitizers are enabled, set
decoded_opts->sanitize_undefined to true.
(run_gcc): Adjust callers of these functions.  If
fdecoded_options.sanitize_undefined is true, append
-fsanitize=shift after the linker options.

--- gcc/lto-opts.c.jj   2016-01-25 22:33:11.477029666 +0100
+++ gcc/lto-opts.c  2016-01-26 15:41:02.937040062 +0100
@@ -198,10 +198,13 @@ lto_write_options (void)
 
   /* Also drop all options that are handled by the driver as well,
 which includes things like -o and -v or -fhelp for example.
-We do not need those.  The only exception is -foffload option, if we
-write it in offload_lto section.  Also drop all diagnostic options.  */
+We do not need those.  The only exceptions are:
+1) -foffload option, if we write it in offload_lto section
+2) -f{,no-}sanitize=
+Also drop all diagnostic options.  */
   if ((cl_options[option->opt_index].flags & (CL_DRIVER|CL_WARNING))
- && (!lto_stream_offload_p || option->opt_index != OPT_foffload_))
+ && (!lto_stream_offload_p || option->opt_index != OPT_foffload_)
+ && option->opt_index != OPT_fsanitize_)
continue;
 
   for (j = 0; j < option->canonical_option_num_elements; ++j)
--- gcc/lto-wrapper.c.jj2016-01-26 15:24:10.457845617 +0100
+++ gcc/lto-wrapper.c   2016-01-26 16:38:16.784303735 +0100
@@ -118,6 +118,16 @@ maybe_unlink (const char *file)
 /* Template of LTRANS dumpbase suffix.  */
 #define DUMPBASE_SUFFIX ".ltrans18446744073709551615"
 
+/* Structure containing decoded options, number of them and auxiliary
+   state from the options handling.  */
+
+struct lto_decoded_options
+{
+  struct cl_decoded_option *opt;
+  unsigned int count;
+  bool sanitize_undefined;
+};
+
 /* Create decoded options from the COLLECT_GCC and COLLECT_GCC_OPTIONS
environment according to LANG_MASK.  */
 
@@ -125,13 +135,14 @@ static void
 get_options_from_collect_gcc_options (const char *collect_gcc,
  const char *collect_gcc_options,
  unsigned int lang_mask,
- struct cl_decoded_option 
**decoded_options,
- unsigned int *decoded_options_count)
+ struct lto_decoded_options *decoded_opts)
 {
   struct obstack argv_obstack;
   char *argv_storage;
   const char **argv;
   int j, k, argc;
+  unsigned int i;
+  int sanitize = 0;
 
   argv_storage = xstrdup (collect_gcc_options);
   obstack_init (&argv_obstack);
@@ -166,9 +177,30 @@ get_options_from_collect_gcc_options (co
   ar

Re: [PATCH] PR other/69006: fix extra newlines after diagnostics (v2)

[David Malcolm]

On Tue, 2016-01-26 at 12:18 +0100, Bernd Schmidt wrote:
> On 01/25/2016 09:13 PM, David Malcolm wrote:
> > Here's an updated version of the patch.
> 
> Thanks!
> 
> > Instead of testing one particular kind of output via a plugin,
> > this version of the patch adds code to gcc-dg-prune to issue a
> > FAIL for any testcase containing blank lines, with a new
> >dg-allow-blank-lines-in-output
> > directive for those test cases that legimitately emit blank lines.
> > Examples of the latter include a test using -ftime-report, another
> > using -fdump-tree-cunrolli-details=stderr, and a Fortran test
> > using -fdump-fortran-original.
> 
> Is the =stderr test really necessary, or does it somehow predate the 
> ability to scan dumps?

It was deliberate.

Specifically:  this was in gcc/testsuite/gcc.dg/unroll-2.c

Looking backwards through history, it was renamed from
  gcc/testsuite/gcc.dg/unroll_1.c
in r219675 (2015-01-15)

It was changed to:
  -fdump-tree-cunrolli-details=stderr
from:
  -fdump-rtl-loop2_unroll=stderr
in r216238 (2014-10-14)

It was changed to:
  -fdump-rtl-loop2_unroll=stderr
from:
  -fdump-rtl-loop2_unroll
in r202260:

2013-09-04  Teresa Johnson  

* dumpfile.c (dump_finish): Don't close stderr/stdout.

* testsuite/gcc.dg/unroll_1.c: Test dumping to stderr.

which seems to have been this discussion:
  https://gcc.gnu.org/ml/gcc-patches/2013-09/msg00151.html
which was part of this thread:
  https://gcc.gnu.org/ml/gcc-patches/2013-08/msg00247.html
  "[PATCH] Convert more passes to new dump framework"

Hence it appears to be deliberate: to give us test coverage for dumping
to stderr, during a rewrite of dumping.


> > OK for trunk in stage 4?  I regard PR 69006 as a regression, and it
> > affects all diagnostics we output (unless caret-printing is
> > disabled).
> 
> Yes, I think so. Ok.

Thanks.

> > +  for (int row = layout.get_first_line ();
> > +   row <= last_line;
> > +   row++)
> 
> While you're fixing the layout here, see if that doesn't all fit on one 
> line.

It does.  Re-running bootstrap®rtest now with that tweak; I'll commit
it if it passes.

Dave

Re: [PATCH] Fix up ICE with initializer containing address of invalid var (PR tree-optimization/69483)

[Richard Biener]

On Tue, Jan 26, 2016 at 3:17 PM, Jakub Jelinek  wrote:
> Hi!
>
> If as in the testcase below a VAR_DECL has error_mark_node type
> (and that unfortunately happens (and has to) quite late, at the end of
> parsing the TU), canonicalize_constructor_val can ICE on that, because it
> will try to fold convert something to error_mark_node type.
>
> Fixed by giving up in that case.
> The patch also cleans up the change that introduced the error_mark_node in
> there, to use FOR_EACH_VEC_ELT.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Thanks,
Richard.

> 2016-01-26  Jakub Jelinek  
>
> PR tree-optimization/69483
> * gimple-fold.c (canonicalize_constructor_val): Return NULL
> if base has error_mark_node type.
>
> * c-parser.c (c_parser_translation_unit): Use FOR_EACH_VEC_ELT.
>
> * gcc.dg/pr69483.c: New test.
> * g++.dg/opt/pr69483.C: New test.
>
> --- gcc/gimple-fold.c.jj2016-01-08 21:48:36.0 +0100
> +++ gcc/gimple-fold.c   2016-01-26 10:54:12.142355308 +0100
> @@ -195,6 +195,8 @@ canonicalize_constructor_val (tree cval,
>|| TREE_CODE (base) == FUNCTION_DECL)
>   && !can_refer_decl_in_current_unit_p (base, from_decl))
> return NULL_TREE;
> +  if (TREE_TYPE (base) == error_mark_node)
> +   return NULL_TREE;
>if (TREE_CODE (base) == VAR_DECL)
> TREE_ADDRESSABLE (base) = 1;
>else if (TREE_CODE (base) == FUNCTION_DECL)
> --- gcc/c/c-parser.c.jj 2016-01-21 00:41:47.0 +0100
> +++ gcc/c/c-parser.c2016-01-26 10:59:30.104941374 +0100
> @@ -1431,15 +1431,14 @@ c_parser_translation_unit (c_parser *par
>while (c_parser_next_token_is_not (parser, CPP_EOF));
>  }
>
> -  for (unsigned i = 0; i < incomplete_record_decls.length (); ++i)
> -{
> -  tree decl = incomplete_record_decls[i];
> -  if (DECL_SIZE (decl) == NULL_TREE && TREE_TYPE (decl) != 
> error_mark_node)
> -   {
> - error ("storage size of %q+D isn%'t known", decl);
> - TREE_TYPE (decl) = error_mark_node;
> -   }
> -}
> +  unsigned int i;
> +  tree decl;
> +  FOR_EACH_VEC_ELT (incomplete_record_decls, i, decl)
> +if (DECL_SIZE (decl) == NULL_TREE && TREE_TYPE (decl) != error_mark_node)
> +  {
> +   error ("storage size of %q+D isn%'t known", decl);
> +   TREE_TYPE (decl) = error_mark_node;
> +  }
>  }
>
>  /* Parse an external declaration (C90 6.7, C99 6.9).
> --- gcc/testsuite/gcc.dg/pr69483.c.jj   2016-01-26 11:02:41.152289108 +0100
> +++ gcc/testsuite/gcc.dg/pr69483.c  2016-01-26 11:02:20.0 +0100
> @@ -0,0 +1,6 @@
> +/* PR tree-optimization/69483 */
> +/* { dg-do compile } */
> +
> +struct T { struct S *a; };
> +struct S b; /* { dg-error "storage size of 'b' isn't known" } */
> +struct T c = { &b };
> --- gcc/testsuite/g++.dg/opt/pr69483.C.jj   2016-01-26 11:06:03.375481313 
> +0100
> +++ gcc/testsuite/g++.dg/opt/pr69483.C  2016-01-26 11:03:20.0 +0100
> @@ -0,0 +1,6 @@
> +// PR tree-optimization/69483
> +// { dg-do compile }
> +
> +struct T { struct S *a; };
> +struct S b; // { dg-error "aggregate 'S b' has incomplete type and cannot be 
> defined" }
> +struct T c = { &b };
>
> Jakub

Re: [C PATCH] Fix -Wunused-function (PR debug/66869)

[Richard Biener]

On Mon, Jan 25, 2016 at 9:38 PM, Jakub Jelinek  wrote:
> Hi!
>
> The early-debug changes moved warnings about unused functions into cgraph.
> The problem is that if we have just unused declarations, they aren't
> sometimes even registered with cgraph and therefore we no longer warn.
>
> Here is an attempt to register those with cgraph anyway to get the warning,
> for C FE only (no idea where to do that in C++ FE).  Or anyone has better
> suggestions what to do?
>
> Bootstrapped/regtested on x86_64-linux and i686-linux.
>
> 2016-01-25  Jakub Jelinek  
>
> PR debug/66869
> * c-decl.c (c_write_global_declarations_1): For warn_unused_function,
> ensure creation of cgraph node even if there is no definition.
>
> * gcc.dg/pr66869.c: New test.
>
> --- gcc/c/c-decl.c.jj   2016-01-21 00:41:47.0 +0100
> +++ gcc/c/c-decl.c  2016-01-25 16:36:31.973504082 +0100
> @@ -10741,11 +10741,19 @@ c_write_global_declarations_1 (tree glob
>if (TREE_CODE (decl) == FUNCTION_DECL
>   && DECL_INITIAL (decl) == 0
>   && DECL_EXTERNAL (decl)
> - && !TREE_PUBLIC (decl)
> - && C_DECL_USED (decl))
> + && !TREE_PUBLIC (decl))
> {
> - pedwarn (input_location, 0, "%q+F used but never defined", decl);
> - TREE_NO_WARNING (decl) = 1;
> + if (C_DECL_USED (decl))
> +   {
> + pedwarn (input_location, 0, "%q+F used but never defined", 
> decl);
> + TREE_NO_WARNING (decl) = 1;
> +   }
> + /* For -Wunused-function push the unused statics into cgraph,
> +so that check_global_declaration emits the warning.  */
> + else if (warn_unused_function
> +  && ! DECL_ARTIFICIAL (decl)
> +  && ! TREE_NO_WARNING (decl))
> +   cgraph_node::get_create (decl);

Err, so why not warn here directly?

Richard.

> }
>
>wrapup_global_declaration_1 (decl);
> --- gcc/testsuite/gcc.dg/pr66869.c.jj   2016-01-25 16:38:39.037758657 +0100
> +++ gcc/testsuite/gcc.dg/pr66869.c  2016-01-25 16:39:42.346888954 +0100
> @@ -0,0 +1,6 @@
> +/* PR debug/66869 */
> +/* { dg-do compile } */
> +/* { dg-options "-Wunused-function" } */
> +
> +static void test (void); /* { dg-warning "'test' declared 'static' but never 
> defined" } */
> +int i;
>
> Jakub

Re: [PATCH] ARM PR68620 (ICE with FP16 on armeb)

[Christophe Lyon]

On 26 January 2016 at 14:20, Kyrill Tkachov  wrote:
> Hi Christophe,
>
> On 20/01/16 21:10, Christophe Lyon wrote:
>>
>> On 19 January 2016 at 15:51, Alan Lawrence 
>> wrote:
>>>
>>> On 19/01/16 11:15, Christophe Lyon wrote:
>>>
>> For neon_vdupn, I chose to implement neon_vdup_nv4hf and
>> neon_vdup_nv8hf instead of updating the VX iterator because I thought
>> it was not desirable to impact neon_vrev32.
>
>
> Well, the same instruction will suffice for vrev32'ing vectors of HF
> just
> as
> well as vectors of HI, so I think I'd argue that's harmless enough. To
> gain the
> benefit, we'd need to update arm_evpc_neon_vrev with a few new cases,
> though.
>
 Since this is more intrusive, I'd rather leave that part for later. OK?
>>>
>>>
>>> Sure.
>>>
>> +#ifdef __ARM_BIG_ENDIAN
>> +  /* Here, 3 is (4-1) where 4 is the number of lanes. This is also
>> the
>> + right value for vectors with 8 lanes.  */
>> +#define __arm_lane(__vec, __idx) (__idx ^ 3)
>> +#else
>> +#define __arm_lane(__vec, __idx) __idx
>> +#endif
>> +
>
>
> Looks right, but sounds... my concern here is that I'm hoping at some
> point we
> will move the *other* vget/set_lane intrinsics to use GCC vector
> extensions
> too. At which time (unlike __aarch64_lane which can be used everywhere)
> this
> will be the wrong formula. Can we name (and/or comment) it to avoid
> misleading
> anyone? The key characteristic seems to be that it is for vectors of
> 16-bit
> elements only.
>
 I'm not to follow, here. Looking at the patterns for
 neon_vget_lane_*internal in neon.md,
 I can see 2 flavours: one for VD, one for VQ2. The latter uses
 "halfelts".

 Do you prefer that I create 2 macros (say __arm_lane and __arm_laneq),
 that would be similar to the aarch64 ones (by computing the number of
 lanes of the input vector), but the "q" one would use half the total
 number of lanes instead?
>>>
>>>
>>> That works for me! Sthg like:
>>>
>>> #define __arm_lane(__vec, __idx) NUM_LANES(__vec) - __idx
>>> #define __arm_laneq(__vec, __idx) (__idx & (NUM_LANES(__vec)/2)) +
>>> (NUM_LANES(__vec)/2 - __idx)
>>> //or similarly
>>> #define __arm_laneq(__vec, __idx) (__idx ^ (NUM_LANES(__vec)/2 - 1))
>>>
>>> Alternatively I'd been thinking
>>>
>>> #define __arm_lane_32xN(__idx) __idx ^ 1
>>> #define __arm_lane_16xN(__idx) __idx ^ 3
>>> #define __arm_lane_8xN(__idx) __idx ^ 7
>>>
>>> Bear in mind PR64893 that we had on AArch64 :-(
>>>
>> Here is a new version, based on the comments above.
>> I've also removed the addition of arm_fp_ok effective target since I
>> added that in my other testsuite patch.
>>
>> OK now?
>>
>> Thanks,
>>
>> Christophe
>>
>
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 3588b83..b1f408c 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -12370,6 +12370,10 @@ neon_valid_immediate (rtx op, machine_mode mode,
> int inverse,
>if (!vfp3_const_double_rtx (el0) && el0 != CONST0_RTX (GET_MODE
> (el0)))
>  return -1;
>  +  /* FP16 vectors cannot be represented.  */
> +  if (innersize == 2)
> +   return -1;
> +
>r0 = CONST_DOUBLE_REAL_VALUE (el0);
>
>
> I think it'd be clearer to write "if (GET_MODE_INNER (mode) == HFmode)"
>
> +(define_expand "movv4hf"
> +  [(set (match_operand:V4HF 0 "s_register_operand")
> +   (match_operand:V4HF 1 "s_register_operand"))]
> +  "TARGET_NEON && TARGET_FP16"
> +{
> +  if (can_create_pseudo_p ())
> +{
> +  if (!REG_P (operands[0]))
> +   operands[1] = force_reg (V4HFmode, operands[1]);
> +}
> +})
>
> Can you please add a comment saying why you need the force_reg here?
> IIRC it's because of CANNOT_CHANGE_MODE_CLASS on big-endian that causes an
> ICE during expand with subregs.
>
> I've tried this patch out and it does indeed fix the ICE on armeb.
> So ok for trunk with the changes above.
> Thanks,
> Kyrill
>
>

OK thanks, here is what I have committed (r232832).


Christophe.
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 232831)
+++ gcc/config/arm/arm.c(working copy)
@@ -12381,6 +12381,10 @@
   if (!vfp3_const_double_rtx (el0) && el0 != CONST0_RTX (GET_MODE (el0)))
 return -1;
 
+  /* FP16 vectors cannot be represented.  */
+  if (GET_MODE_INNER (mode) == HFmode)
+   return -1;
+
   r0 = CONST_DOUBLE_REAL_VALUE (el0);
 
   for (i = 1; i < n_elts; i++)
Index: gcc/config/arm/arm_neon.h
===
--- gcc/config/arm/arm_neon.h   (revision 232831)
+++ gcc/config/arm/arm_neon.h   (working copy)
@@ -5302,16 +5302,28 @@
were marked always-inline so there were no call sites, the declaration
would nonetheless raise an error.  Hence, we must use a macro instead. 

Re: [PATCH], PowerPC IEEE 128-bit fp, #12 (default -mfloat128 on PowerPC-Linux)

[David Edelsohn]

On Thu, Jan 21, 2016 at 4:25 PM, Michael Meissner
 wrote:
> This is the final patch (at least so far) that turns on -mfloat128 by default
> for PowerPC Linux systems where the VSX instruction set is enabled.  As I
> mentioned in the last email, because we don't build the __float128 emulator on
> other systems, I didn't think it would be useful to make it the default.
>
> I did a boostrap build/check with no regressions on a little endian power8
> system.  Are the patches ok to check in?
>
> [gcc]
> 2016-01-21   Michael Meissner  
>
> * config/rs6000/rs6000.c (rs6000_option_override_internal): Enable
> -mfloat128 by default on PowerPC Linux systems with the VSX
> instruction enabled.
>
> [gcc/testsuite]
> 2016-01-21   Michael Meissner  
>
> * gcc.target/powerpc/float128-1.c: New test for IEEE 128-bit
> floating point support.
> * gcc.target/powerpc/float128-2.c: Likewise.

No.  This is too risky a change during Stage 4.

- David

Re: [PATCH][AArch64] Add vector permute cost

[James Greenhalgh]

On Tue, Dec 15, 2015 at 11:35:45AM +, Wilco Dijkstra wrote:
> 
> Add support for vector permute cost since various permutes can expand into a 
> complex
> sequence of instructions.  This fixes major performance regressions due to 
> recent changes
> in the SLP vectorizer (which now vectorizes more aggressively and emits many 
> complex 
> permutes).
> 
> Set the cost to > 1 for all microarchitectures so that the number of permutes 
> is usually zero
> and regressions disappear.  An example of the kind of code that might be 
> emitted for
> VEC_PERM_EXPR {0, 3} where registers happen to be in the wrong order:
> 
> adrpx4, .LC16
> ldr q5, [x4, #:lo12:.LC16
> eor v1.16b, v1.16b, v0.16b
> eor v0.16b, v1.16b, v0.16b
> eor v1.16b, v1.16b, v0.16b
> tbl v0.16b, {v0.16b - v1.16b}, v5.16b
> 
> Regress passes. This fixes regressions that were introduced recently, so OK 
> for commit?

OK.

Thanks,
James

> ChangeLog:
> 2015-12-15  Wilco Dijkstra  
> 
>   * gcc/config/aarch64/aarch64.c (generic_vector_cost):
>   Set vec_permute_cost.
>   (cortexa57_vector_cost): Likewise.
>   (exynosm1_vector_cost): Likewise.
>   (xgene1_vector_cost): Likewise.
>   (aarch64_builtin_vectorization_cost): Use vec_permute_cost.
>   * gcc/config/aarch64/aarch64-protos.h (cpu_vector_cost):
>   Add vec_permute_cost entry.
 

Re: [AArch64] Disable pcrelative_literal_loads with fix-cortex-a53-843419

[Kyrill Tkachov]

On 26/01/16 14:42, Christophe Lyon wrote:

Hi,

This is a followup to PR63304.

As discussed in bugzilla, this patch disables pcrelative_literal_loads
when -mfix-cortex-a53-843419 (or its default configure option) is
used.

I copied the behavior of -mfix-cortex-a53-835769 (e.g. in
aarch64_can_inline_p), and I have tested by building the Linux kernel
using -mfix-cortex-a53-843419 and checked that
R_AARCH64_ADR_PREL_PG_HI21 relocations are not emitted anymore (under
CONFIG_ARM64_ERRATUM_843419).

For reference, this is motivated by:
https://bugs.linaro.org/show_bug.cgi?id=1994
and further details on Launchpad:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533009

OK for trunk?

Thanks,

Christophe.



ENOPATCH.

Thanks,
Kyrill

Re: [AArch64] Disable pcrelative_literal_loads with fix-cortex-a53-843419

[Christophe Lyon]

With the attachment


On 26 January 2016 at 15:42, Christophe Lyon  wrote:
> Hi,
>
> This is a followup to PR63304.
>
> As discussed in bugzilla, this patch disables pcrelative_literal_loads
> when -mfix-cortex-a53-843419 (or its default configure option) is
> used.
>
> I copied the behavior of -mfix-cortex-a53-835769 (e.g. in
> aarch64_can_inline_p), and I have tested by building the Linux kernel
> using -mfix-cortex-a53-843419 and checked that
> R_AARCH64_ADR_PREL_PG_HI21 relocations are not emitted anymore (under
> CONFIG_ARM64_ERRATUM_843419).
>
> For reference, this is motivated by:
> https://bugs.linaro.org/show_bug.cgi?id=1994
> and further details on Launchpad:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533009
>
> OK for trunk?
>
> Thanks,
>
> Christophe.
2016-01-26  Christophe Lyon  

* config/aarch64/aarch64.h (TARGET_FIX_ERR_A53_843419_DEFAULT):
Always define to 0 or 1.
(TARGET_FIX_ERR_A53_843419): New macro.
* config/aarch64/aarch64-elf-raw.h
(TARGET_FIX_ERR_A53_843419_DEFAULT): Update for above changes.
* config/aarch64/aarch64-linux.h: Likewise.
* config/aarch64/aarch64.c
(aarch64_override_options_after_change_1): Do not default
aarch64_nopcrelative_literal_loads to true if Cortex-A53 erratum
843419 is on.
(aarch64_attributes): Handle fix-cortex-a53-843419.
(aarch64_can_inline_p): Likewise.
* config/aarch64/aarch64.opt (aarch64_fix_a53_err843419): Save.
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 8b463c9..ec96ce3 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -179,6 +179,20 @@ extern unsigned aarch64_architecture_version;
   ((aarch64_fix_a53_err835769 == 2)\
   ? TARGET_FIX_ERR_A53_835769_DEFAULT : aarch64_fix_a53_err835769)
 
+/* Make sure this is always defined so we don't have to check for ifdefs
+   but rather use normal ifs.  */
+#ifndef TARGET_FIX_ERR_A53_843419_DEFAULT
+#define TARGET_FIX_ERR_A53_843419_DEFAULT 0
+#else
+#undef TARGET_FIX_ERR_A53_843419_DEFAULT
+#define TARGET_FIX_ERR_A53_843419_DEFAULT 1
+#endif
+
+/* Apply the workaround for Cortex-A53 erratum 843419.  */
+#define TARGET_FIX_ERR_A53_843419  \
+  ((aarch64_fix_a53_err843419 == 2)\
+  ? TARGET_FIX_ERR_A53_843419_DEFAULT : aarch64_fix_a53_err843419)
+
 /* ARMv8.1 Adv.SIMD support.  */
 #define TARGET_SIMD_RDMA (TARGET_SIMD && AARCH64_ISA_RDMA)
 
diff --git a/gcc/config/aarch64/aarch64-elf-raw.h 
b/gcc/config/aarch64/aarch64-elf-raw.h
index 2dcb6d4..9097017 100644
--- a/gcc/config/aarch64/aarch64-elf-raw.h
+++ b/gcc/config/aarch64/aarch64-elf-raw.h
@@ -35,7 +35,7 @@
   " %{mfix-cortex-a53-835769:--fix-cortex-a53-835769}"
 #endif
 
-#ifdef TARGET_FIX_ERR_A53_843419_DEFAULT
+#if TARGET_FIX_ERR_A53_843419_DEFAULT
 #define CA53_ERR_843419_SPEC \
   " %{!mno-fix-cortex-a53-843419:--fix-cortex-a53-843419}"
 #else
diff --git a/gcc/config/aarch64/aarch64-linux.h 
b/gcc/config/aarch64/aarch64-linux.h
index 6064b26..5fcaa59 100644
--- a/gcc/config/aarch64/aarch64-linux.h
+++ b/gcc/config/aarch64/aarch64-linux.h
@@ -53,7 +53,7 @@
   " %{mfix-cortex-a53-835769:--fix-cortex-a53-835769}"
 #endif
 
-#ifdef TARGET_FIX_ERR_A53_843419_DEFAULT
+#if TARGET_FIX_ERR_A53_843419_DEFAULT
 #define CA53_ERR_843419_SPEC \
   " %{!mno-fix-cortex-a53-843419:--fix-cortex-a53-843419}"
 #else
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 03bc1b9..3bea61e 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -8062,9 +8062,11 @@ aarch64_override_options_after_change_1 (struct 
gcc_options *opts)
   if (opts->x_nopcrelative_literal_loads == 1)
 aarch64_nopcrelative_literal_loads = false;
 
-  /* If it is not set on the command line, we default to no
- pc relative literal loads.  */
-  if (opts->x_nopcrelative_literal_loads == 2)
+  /* If it is not set on the command line, we default to no pc
+ relative literal loads, unless the workaround for Cortex-A53
+ erratum 843419 is in effect.  */
+  if (opts->x_nopcrelative_literal_loads == 2
+  && !TARGET_FIX_ERR_A53_843419)
 aarch64_nopcrelative_literal_loads = true;
 
   /* In the tiny memory model it makes no sense
@@ -8748,6 +8750,8 @@ static const struct aarch64_attribute_info 
aarch64_attributes[] =
  OPT_mgeneral_regs_only },
   { "fix-cortex-a53-835769", aarch64_attr_bool, true, NULL,
  OPT_mfix_cortex_a53_835769 },
+  { "fix-cortex-a53-843419", aarch64_attr_bool, true, NULL,
+ OPT_mfix_cortex_a53_843419 },
   { "cmodel", aarch64_attr_enum, false, NULL, OPT_mcmodel_ },
   { "strict-align", aarch64_attr_mask, false, NULL, OPT_mstrict_align },
   { "omit-leaf-frame-pointer", aarch64_attr_bool, true, NULL,
@@ -9162,6 +9166,12 @@ aarch64_can_inline_p (tree caller, tree callee)
  2, TARGET_FIX_ERR_A53_835769_DEFAULT))
 return false;
 
+  if (!aarch64_tribools_ok_for_inlining_p (
+ caller_opts->x_aarc

[AArch64] Disable pcrelative_literal_loads with fix-cortex-a53-843419

[Christophe Lyon]

Hi,

This is a followup to PR63304.

As discussed in bugzilla, this patch disables pcrelative_literal_loads
when -mfix-cortex-a53-843419 (or its default configure option) is
used.

I copied the behavior of -mfix-cortex-a53-835769 (e.g. in
aarch64_can_inline_p), and I have tested by building the Linux kernel
using -mfix-cortex-a53-843419 and checked that
R_AARCH64_ADR_PREL_PG_HI21 relocations are not emitted anymore (under
CONFIG_ARM64_ERRATUM_843419).

For reference, this is motivated by:
https://bugs.linaro.org/show_bug.cgi?id=1994
and further details on Launchpad:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533009

OK for trunk?

Thanks,

Christophe.

Re: [PATCH][AArch64] Add vector permute cost

[Wilco Dijkstra]

ping


From: Wilco Dijkstra
Sent: 16 December 2015 11:37
To: Richard Biener; James Greenhalgh
Cc: GCC Patches; nd
Subject: RE: [PATCH][AArch64] Add vector permute cost

Richard Biener wrote:
> On Wed, Dec 16, 2015 at 10:32 AM, James Greenhalgh
>  wrote:
> > On Tue, Dec 15, 2015 at 11:35:45AM +, Wilco Dijkstra wrote:
> >>
> >> Add support for vector permute cost since various permutes can expand into 
> >> a complex
> >> sequence of instructions.  This fixes major performance regressions due to 
> >> recent changes
> >> in the SLP vectorizer (which now vectorizes more aggressively and emits 
> >> many complex
> >> permutes).
> >>
> >> Set the cost to > 1 for all microarchitectures so that the number of 
> >> permutes is usually zero
> >> and regressions disappear.  An example of the kind of code that might be 
> >> emitted for
> >> VEC_PERM_EXPR {0, 3} where registers happen to be in the wrong order:
> >>
> >> adrpx4, .LC16
> >> ldr q5, [x4, #:lo12:.LC16
> >> eor v1.16b, v1.16b, v0.16b
> >> eor v0.16b, v1.16b, v0.16b
> >> eor v1.16b, v1.16b, v0.16b
> >> tbl v0.16b, {v0.16b - v1.16b}, v5.16b
> >>
> >> Regress passes. This fixes regressions that were introduced recently, so 
> >> OK for commit?
> >>
> >>
> >> ChangeLog:
> >> 2015-12-15  Wilco Dijkstra  
> >>
> >>   * gcc/config/aarch64/aarch64.c (generic_vector_cost):
> >>   Set vec_permute_cost.
> >>   (cortexa57_vector_cost): Likewise.
> >>   (exynosm1_vector_cost): Likewise.
> >>   (xgene1_vector_cost): Likewise.
> >>   (aarch64_builtin_vectorization_cost): Use vec_permute_cost.
> >>   * gcc/config/aarch64/aarch64-protos.h (cpu_vector_cost):
> >>   Add vec_permute_cost entry.
> >>
> >>
> >> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> >> index 
> >> 10754c88c0973d8ef3c847195b727f02b193bbd8..2584f16d345b3d015d577dd28c08a73ee3e0b0fb
> >>  100644
> >> --- a/gcc/config/aarch64/aarch64.c
> >> +++ b/gcc/config/aarch64/aarch64.c
> >> @@ -314,6 +314,7 @@ static const struct cpu_vector_cost 
> >> generic_vector_cost =
> >>1, /* scalar_load_cost  */
> >>1, /* scalar_store_cost  */
> >>1, /* vec_stmt_cost  */
> >> +  2, /* vec_permute_cost  */
> >>1, /* vec_to_scalar_cost  */
> >>1, /* scalar_to_vec_cost  */
> >>1, /* vec_align_load_cost  */
> >
> > Is there any reasoning behind making this 2? Do we now miss vectorization
> > for some of the cheaper permutes? Across the cost models/pipeline
> > descriptions that have been contributed to GCC I think that this is a
> > sensible change to the generic costs, but I just want to check there
> > was some reasoning/experimentation behind the number you picked.

Yes, it blocks vectorization if they have a high percentage of permutes, even 
if trivial.
But that is exactly the goal - when we vectorize we want to minimize data 
shuffling
that just adds latency and does not contribute to actual work.

The value 2 was the minimal value that avoided the regressions I noticed due the
improved SLP vectorization. I tried other possibilities like increasing the 
statement cost,
but that affects other cases, so this is the simplest change.

Note that I'm not too convinced about any of the existing vector costs, they 
seem
fairly random numbers - the A57 vector costs for example block many simple
vectorization cases that are beneficial. The goal of this is simply to fix the 
regressions
rather than tuning vector costs (which is only possible if we have a better 
cost model).

> > As permutes can have such wildly different costs, this all seems like a good
> > candidate for some future much more involved hook from the vectorizer to the
> > back-end specifying the candidate permute operation and requesting a cost
> > (part of the bigger gimple costs framework?).
>
> Yes, the vectorizer side also needs to improve here.  Not sure if it is 
> possible
> to represent this kind of complex cost queries with a single gimple cost hook.
> After all we don't really want to generate the full gimple stmt just to query
> its cost ...
>
> To better represent permute cost in the short term we'd need another 
> vectorizer
> specific hook, not sth for stage3 unless we face some serious regressions
> on real-world code (thus not microbenchmarks only)

Yes we need a better cost model for the vectorizer. The sort of things that are 
important
is the vector mode (so we can differentiate between 2x, 4x, 8x, 16x 
vectorization etc),
the specific permute for permutes, the size and type of load/store (as some do 
permutes) etc.

Wilco

Re: [PATCH] Handle -fsanitize=* in lto-wrapper (PR lto/69254)

[Jakub Jelinek]

On Tue, Jan 26, 2016 at 03:06:43PM +0100, Richard Biener wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> Can you split out the non -fsanitize part?  It is ok.

Ok, I've committed following patch:

2016-01-26  Jakub Jelinek  

PR lto/69254
* lto-wrapper.c (merge_and_complain): Handle -fcilkplus.
(append_compiler_options): Handle -fcilkplus.
(append_linker_options): Ignore -fno-{openmp,openacc,cilkplus}.

--- gcc/lto-wrapper.c.jj2016-01-23 00:13:00.632019027 +0100
+++ gcc/lto-wrapper.c   2016-01-25 15:59:49.778877313 +0100
@@ -277,6 +293,7 @@ merge_and_complain (struct cl_decoded_op
case OPT_fwrapv:
case OPT_fopenmp:
case OPT_fopenacc:
+   case OPT_fcilkplus:
case OPT_fcheck_pointer_bounds:
  /* For selected options we can merge conservatively.  */
  for (j = 0; j < *decoded_options_count; ++j)
@@ -505,6 +546,7 @@ append_compiler_options (obstack *argv_o
case OPT_fwrapv:
case OPT_fopenmp:
case OPT_fopenacc:
+   case OPT_fcilkplus:
case OPT_ftrapv:
case OPT_fstrict_overflow:
case OPT_foffload_abi_:
@@ -558,6 +601,15 @@ append_linker_options (obstack *argv_obs
 ???  We fail to diagnose a possible mismatch here.  */
  continue;
 
+   case OPT_fopenmp:
+   case OPT_fopenacc:
+   case OPT_fcilkplus:
+ /* Ignore -fno-XXX form of these options, as otherwise
+corresponding builtins will not be enabled.  */
+ if (option->value == 0)
+   continue;
+ break;
+
default:
  break;
}


Jakub

RFA: Fix for cygwin/mingw PR 66655

[Nick Clifton]

Hi Guys,

  The patch below is offered as a fix for PR 66655.  In testing it
  appears that the patch does work, and does not break building
  libstdc++-v3 for cygwin or mingw.  (Unlike the earlier version...)

  Due to my brain being so small, I have already checked the patch in,
  without receiving proper authorisation.  I apologise for this.  If the
  patch does prove suitable and is approved today, then I will leave it
  in.  Otherwise I will revert the change and wait for proper approval.

  The patch itself is also slightly dubious in that I am not sure if I
  have all the correct terms in the if-statement.  I was going for
  minimal impact on the current code, so I went for a set of selectors
  that matched the testcase for PR 66655, but nothing else.  In
  particular I did not check to see if a similar problem exists for
  methods or virtual functions.

  My theory was that if does turn out that these kinds of functions can
  also trigger this kind of bug, then the patch could be extended
  later.  Plus a new bug report is likely to include a new testcase that
  can be added to the testsuite.

  So ... OK to apply ?

Cheers
  Nick

gcc/ChangeLog
2016-01-26  Nick Clifton  

PR target/66655
* config/i386/winnt.c (i386_pe_binds_local_p): If a function has
been marked as DECL_ONE_ONLY but we do not the means to make it
so, then do not allow it to bind locally.

Index: gcc/config/i386/winnt.c
===
--- gcc/config/i386/winnt.c (revision 232784)
+++ gcc/config/i386/winnt.c (working copy)
@@ -341,6 +341,20 @@
   && TREE_PUBLIC (exp)
   && DECL_EXTERNAL (exp))
 return true;
+
+#ifndef MAKE_DECL_ONE_ONLY
+  /* PR target/66655: If a function has been marked as DECL_ONE_ONLY
+ but we do not the means to make it so, then do not allow it to
+ bind locally.  */
+  if (DECL_P (exp)
+  && TREE_CODE (exp) == FUNCTION_DECL
+  && TREE_PUBLIC (exp)
+  && DECL_ONE_ONLY (exp)
+  && ! DECL_EXTERNAL (exp)
+  && DECL_DECLARED_INLINE_P (exp))
+return false;
+#endif
+  
   return default_binds_local_p_1 (exp, 0);
 }
 

[committed, PATCH] Remove -m32 from gcc.target/i386/pr68986-2.c

[H.J. Lu]

Index: ChangeLog
===
--- ChangeLog   (revision 232829)
+++ ChangeLog   (working copy)
@@ -1,5 +1,9 @@
 2016-01-26  H.J. Lu  
 
+   * gcc.target/i386/pr68986-2.c: Remove -m32.
+
+2016-01-26  H.J. Lu  
+
PR target/68986
* gcc.target/i386/pr68986-1.c: New test.
* gcc.target/i386/pr68986-2.c: Likewise.
Index: gcc.target/i386/pr68986-2.c
===
--- gcc.target/i386/pr68986-2.c (revision 232829)
+++ gcc.target/i386/pr68986-2.c (working copy)
@@ -1,7 +1,7 @@
 /* { dg-do compile { target ia32 } } */
 /* { dg-require-effective-target tls_native } */
 /* { dg-require-effective-target fpic } */
-/* { dg-options "-fPIC -mno-accumulate-outgoing-args 
-mpreferred-stack-boundary=2 -m32" } */
+/* { dg-options "-fPIC -mno-accumulate-outgoing-args 
-mpreferred-stack-boundary=2" } */
 
 extern __thread int msgdata;
 int