Re: Sched1 stability issue

2018-07-04 Thread Eric Botcazou 
> We noticed a difference in the code generated for aarch64 gcc 7.2
> hosted in Linux vs mingw. AFIK, we are supposed to produce the same
> output.

Try maybe to compare the automata generated on the hosts, are they identical?

-- 
Eric Botcazou

Re: Sched1 stability issue

2018-07-04 Thread Alexander Monakov 
On Wed, 4 Jul 2018, Kugan Vivekanandarajah wrote:
> We noticed a difference in the code generated for aarch64 gcc 7.2
> hosted in Linux vs mingw. AFIK, we are supposed to produce the same
> output.
> 
> For the testacse we have (quite large and I am trying to reduce), the
> difference comes from sched1 pass. If I disable sched1 the difference
> is going away.
> 
> Is this a known issue? Attached is the sched1 dump snippet where there
> is the difference.

The rank_for_schedule comparator used for qsort in the scheduler is known
to be invalid; some issues have been fixed in gcc-8, but some remain (you
can search the bugzilla for qsort_chk issues). Since the comparator is
invalid, different qsort implementations reorder the ready list differently.

In gcc-9 qsort calls use gcc_qsort instead and thus wouldn't diverge.

Alexander

Re: Understanding tree_swap_operands_p wrt SSA name versions

2018-07-04 Thread Richard Biener 
On Tue, Jul 3, 2018 at 9:09 PM Jeff Law  wrote:
>
> On 07/03/2018 11:55 AM, Michael Ploujnikov wrote:
> > On 2018-07-03 12:46 PM, Richard Biener wrote:
> >> On July 3, 2018 4:56:57 PM GMT+02:00, Michael Ploujnikov 
> >>  wrote:
> >>> On 2018-06-20 04:23 AM, Richard Biener wrote:
>  On Wed, Jun 20, 2018 at 7:31 AM Jeff Law  wrote:
> >
> > On 06/19/2018 12:30 PM, Michael Ploujnikov wrote:
> >> Hi everyone,
> >>
> >> (I hope this is the right place to ask, if not my apologies; please
> >> point me in the right direction)
> >>
> >> I'm trying to get a better understanding of the following part in
> >> tree_swap_operands_p():
> >>
> >>   /* It is preferable to swap two SSA_NAME to ensure a canonical
> >>> form
> >>  for commutative and comparison operators.  Ensuring a
> >>> canonical
> >>  form allows the optimizers to find additional redundancies
> >>> without
> >>  having to explicitly check for both orderings.  */
> >>   if (TREE_CODE (arg0) == SSA_NAME
> >>   && TREE_CODE (arg1) == SSA_NAME
> >>   && SSA_NAME_VERSION (arg0) > SSA_NAME_VERSION (arg1))
> >> return 1;
> >>
> >> My questions in no particular order: It looks like this was added
> >>> in
> >> 2004. I couldn't find any info other than what's in the
> >>> corresponding
> >> commit (cc0bdf913) so I'm wondering if the canonical form/order
> >>> still
> >> relevant/needed today? Does the ordering have to be done based on
> >>> the
> >> name versions specifically? Or can it be based on something more
> >> intrinsic to the input source code rather than a GCC internal
> >>> value, eg:
> >> would alphabetic sort order of the variable names be a reasonable
> >> replacement?
> > Canonicalization is still important and useful.
> 
>  Indeed.
> 
> > However, canonicalizing on SSA_NAMEs is problematical due to the way
> >>> we
> > recycle nodes and re-pack them.
> 
>  In the past we made sure to not disrupt order - hopefully that didn't
> >>> change
>  so the re-packing shoudln't invaidate previous canonicalization:
> 
>  static void
>  release_free_names_and_compact_live_names (function *fun)
>  {
>  ...
>    /* And compact the SSA number space.  We make sure to not change
> >>> the
>   relative order of SSA versions.  */
>    for (i = 1, j = 1; i < fun->gimple_df->ssa_names->length (); ++i)
>  {
> 
> 
> > I think defining additional rules for canonicalization prior to
> >>> using
> > SSA_NAME_VERSION as the fallback would be looked upon favorably.
> 
>  I don't see a good reason to do that, it will be harder to spot
> >>> canonicalization
>  issues and it will take extra compile-time.
> 
> > Note however, that many of the _DECL nodes referenced by SSA_NAMEs
> >>> are
> > temporaries generated by the compiler and do not correspond to any
> > declared/defined object in the original source.  So you'll still
> >>> need
> > the SSA_NAME_VERSION (or something as stable or better)
> >>> canonicalization
> > to handle those cases.
> 
>  And not all SSA_NAMEs have underlying _DECL nodes (or IDENTIFIER_NODE
> >>> names).
> 
>  Richard.
> 
> > Jeff
> >>>
> >>> After a bit more digging I found that insert_phi_nodes inserts PHIs in
> >>> the order of UIDs, which indirectly affects the order of vars in
> >>> old_ssa_names, which in turn affects the order in which
> >>> make_ssa_name_fn
> >>> is called to pick SSA versions from FREE_SSANAMES so in the end
> >>> ordering by SSA_NAME_VERSION's is more or less equivalent to ordering
> >>> by
> >>> UIDs. I'm trying to figure out if there's a way to avoid depending on
> >>> UIDs being ordered in a certain way. So if tree_swap_operands_p stays
> >>> the same I'm wondering if there's some other info available at the
> >>> point
> >>> of insert_phi_nodes that would be a good replacement for UID. From my
> >>> very limited experience with a very small source input, and if I
> >>> understand things correctly, all of the var_infos have a var which is
> >>> DECL_P and thus should have an IDENTIFIER_NODE. Is that true in the
> >>> general case? I don't fully understand what are all the things that
> >>> insert_phi_nodes iterates over.
> >>
> >> Why do you want to remove the dependence on UID ordering? It's pervasive 
> >> throughout the whole compilation...
> >>
> >> Richard.
> >>
> >>> - Michael
> >>
> >
> >
> > Well, I'm working on a reduction of the number of changes seen with
> > binary diffing (a la https://wiki.debian.org/ReproducibleBuilds) and
> > since current UID assignment is essentially tied to the order of things
> > in the input source code one function's changes can cascade to others
> > (even when they're unchanged). As you said UID dependence is quiet
> > pervasive, and although finding and improving individual cases (such as
> > tr

Re: LTO and other test failures on trunk

2018-07-04 Thread Martin Sebor 

On 06/19/2018 04:37 AM, Thomas Schwinge wrote:

Hi!

In case that you have not yet found it:

On Mon, 11 Jun 2018 12:19:23 -0600, Martin Sebor  wrote:

I've been noticing a number of failures in LTO (and some other)
tests in my x86_64-builds most of which don't appear in results
reported on gcc-testresults (all those on lines that start with
with the '!' below) and that I don't recall seeing before.

The LTO tests seem to fail with errors like the one below:

/usr/bin/ld: /tmp/ccIaufZk.lto.o: plugin needed to handle lto object
FAIL: g++.dg/lto/pr64043 cp_lto_pr64043_0.o-cp_lto_pr64043_0.o link,
-flto -std=c++11


That looks like .


Yes, that's it.  Thanks!  I've updated the bug to hopefull nudge
it closer to resolution since I continue to see these failures in
my builds on x86_64-linux running Fedora 25 (and they are making
it easier to miss other failures/regressions caused by my own
changes).

Honza, are there any other solutions besides those you mention
in comment 6 on the bug?  My builds run on a shared machine that
I'm not sure can be easily upgraded.  I could build my own Binutils
and use it instead but it seems that a more robust solution is for
the GCC test harness to detect and handle this gracefully (the same
way other missing dependencies are detected and prevented from
causing test failures).

Martin

gcc-6-20180704 is now available

2018-07-04 Thread gccadmin 
Snapshot gcc-6-20180704 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180704/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

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

You'll find:

 gcc-6-20180704.tar.xzComplete GCC

  SHA256=593f10b09f62b2d69fcf7c98bc3574bb3c39e821057062e9b40108a43721b561
  SHA1=10e77d389340552386b16c44cc970aabd574fcf8

Diffs from 6-20180627 are available in the diffs/ subdirectory.

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

About a error reported by gcc

2018-07-04 Thread snow_xmas 
Hello.
The source in the attachment can not be compiled, because there is a 
variable in the lambda-introducer does not have a copy-constructor, but have a 
move-constructor. When a function object constructed by a lambda-expression 
like this, the compiler will report this error. And I have try it under gcc 
version 5.4, 7,3 and 8.1, the same error will be reported by all these versions 
of gcc. However, the lambda-expression can be moved normally to std::async, 
std::packaged_task, except std::function. So I believe it's a bug of gcc

The classes which is prohibited to copy but allowed to move is necessary in 
some condition, like unique_ptr. Please give me a solution for this error.





---my source 
code--
#include 
#include 
#include 


class Test {
public:
Test( const char *in ): m_strMsg( in ) {}
Test( Test && ) = default;
Test( const Test & ) = delete;

private:
std::string m_strMsg;
};


int main() {
auto lambda_express = [ uptr = Test( "C++17" ) ]()->int { return 0; };
std::function func1 = std::move( lambda_express );

return 0;
}






error reported by gcc 
8.1
--Building project:[ training - Debug ]--
make[1]: Entering directory '/home/mayuchao/workspaces/cpptraining/training'
codelite-cc /home/mayuchao/.opt/gcc/bin/g++  -c  
"/home/mayuchao/workspaces/cpptraining/training/main.cpp" -std=c++17 -g -O0 
-Wall  -o ./Debug/main.cpp.o -I. -I.
In file included from /home/mayuchao/.opt/gcc/include/c++/8.1.0/functional:59,
 from /home/mayuchao/workspaces/cpptraining/training/main.cpp:1:
/home/mayuchao/.opt/gcc/include/c++/8.1.0/bits/std_function.h: In instantiation 
of 'static void 
std::_Function_base::_Base_manager<_Functor>::_M_clone(std::_Any_data&, const 
std::_Any_data&, std::false_type) [with _Functor = main()::; 
std::false_type = std::integral_constant]':
/home/mayuchao/.opt/gcc/include/c++/8.1.0/bits/std_function.h:208:16:   
required from 'static bool 
std::_Function_base::_Base_manager<_Functor>::_M_manager(std::_Any_data&, const 
std::_Any_data&, std::_Manager_operation) [with _Functor = main()::]'
/home/mayuchao/.opt/gcc/include/c++/8.1.0/bits/std_function.h:676:19:   
required from 'std::function<_Res(_ArgTypes ...)>::function(_Functor) [with 
_Functor = main()::;  = void; 
 = void; _Res = int; _ArgTypes = {}]'
/home/mayuchao/workspaces/cpptraining/training/main.cpp:17:60:   required from 
here
/home/mayuchao/.opt/gcc/include/c++/8.1.0/bits/std_function.h:173:6: error: use 
of deleted function 'main()(const main()::&)'
  new _Functor(*__source._M_access<_Functor*>());
  ^~
/home/mayuchao/workspaces/cpptraining/training/main.cpp:16:52: note: 
'main()(const main()::&)' is implicitly deleted 
because the default definition would be ill-formed:
 auto lambda_express = [ uptr = Test( "C++17" ) ]()->int { return 0; };
^
/home/mayuchao/workspaces/cpptraining/training/main.cpp:16:52: error: use of 
deleted function 'Test::Test(const Test&)'
/home/mayuchao/workspaces/cpptraining/training/main.cpp:9:5: note: declared here
 Test( const Test & ) = delete;
 ^~~~
training.mk:95: recipe for target 'Debug/main.cpp.o' failed
make[1]: *** [Debug/main.cpp.o] Error 1
make[1]: Leaving directory '/home/mayuchao/workspaces/cpptraining/training'
Makefile:4: recipe for target 'All' failed
make: *** [All] Error 2
3 errors, 5 warnings

Re: About a error reported by gcc

2018-07-04 Thread Liu Hao 

在 2018/7/5 9:14, snow_xmas 写道:

Hello.
 The source in the attachment can not be compiled, because there is a 
variable in the lambda-introducer does not have a copy-constructor, but have a 
move-constructor. When a function object constructed by a lambda-expression 
like this, the compiler will report this error. And I have try it under gcc 
version 5.4, 7,3 and 8.1, the same error will be reported by all these versions 
of gcc. However, the lambda-expression can be moved normally to std::async, 
std::packaged_task, except std::function. So I believe it's a bug of gcc

 The classes which is prohibited to copy but allowed to move is necessary 
in some condition, like unique_ptr. Please give me a solution for this error.





The constructor of `std::function` in question requires the argument 
object to be CopyConstructible:


  ISO/IEC WG21 N1750
  Working Draft, Standard for Programming Language C++

  23.14.13.2.1 function construct/copy/destroy [func.wrap.func.con]

template function(F f);

  7 Requires: F shall be CopyConstructible.

, which, recursively, requires everything in your lambda that is 
captured by value to be CopyConstructible.


As an alternative, using `uptr = std::make_shared("c++17")` in 
place of `uptr = Test("c++17")` will overcome this problem.


--
Best regards,
LH_Mouse

What is the difference between datatype "const_tree" and "tree" ?

2018-07-04 Thread 冠人 王 via gcc 
In the function emit_side_effect_warnings, I find its inputs are "location_t 
loc" and "tree expr".
And, there is a function warn_if_unused_value called by 
emit_side_effect_warnings:
emit_side_effect_warnings(location_t loc, tree expr){    ...
    else
    warn_if_unused_value(expr,loc)
}

To call warn_if_unused_value, we use location_t loc and tree expr as inputs
In the function warn_if_unused_value, I find its inputs are "location_t loc" 
and "const_tree expr"
warn_if_unused_value(const_tree exp, location_t locus){    ...
}
I am confused about the difference between "tree expr" and "const_tree expr" 
since
if I modify the"const_tree" to "tree", I make failed.
Besides this, I try to use debug_tree function to dump the imformation of the 
node.
I am successful when I use it in the function emit_side_effect_warnings but
not in the function warn_if_unused_value