A new vision of the universe evolution

[bensalem . kamel]

 Dear colleague, 
 I am a Tunisian University professor. I am interested in Data Analysis 
concerning different domains (Biology, Geology, Astronomy, Linguistics, 
Sciences of religions etc...). In this context, I have written a paper entitled 
"A new vision of the universe evolution", that has been presented at the 
Symposium "The Future of Life and the Future of Our Civilization" held at  the 
University of Frankfurt (Germany) then  published (in an extended version) in 
"The Pacific Journal of Science and Technology" and which is available on 
ResearchGate website: (please see : 
  
 
https://www.researchgate.net/publication/331963051_The_Evolution_of_the_Universe_A_New_Vision
  
 In this paper I describe a scenario of the solar system end, the initial 
structure of the universe, its formation chronology, its evolution etc... The 
results of our investigations are carefully compared with the most recent 
theories.  
  
 Since the topic would interest many readers, I send you a copy of the paper. 
You would be very kind by sending me your remarks and comments in order to : 
  
 - Get as much opinions as possible on a subject that interests the future of  
the solar system and of the universe in general.
 - Contact experts in both Astronomy and Universe sciences. 
 - Establish statistical results related with opinions of the contacted persons 
(experts and non experts) on the diverse points discussed in the paper.
  
 P.S. :
 -  The paper cited above is also available at these links :
  
 http://www.akamaiuniversity.us/PJST6_1_37.pdf  or
  
 http://www.ejst.tuiasi.ro/Files/11/11-35Salem.pdf 
  
 - In order to help reader's to have a quick idea on this paper, I attached a 
brief presentation of its contents.
  
 https://www.researchgate.net/publication/331962994_The_Future_of_Solar_System
  
  
 I wish you good reading.
  
 Sincerely yours
  
 Kamel Ben Salem
 Professor of Data analysis at the Department of Computer Science at the 
Faculty of Science, Tunis,  2092 El Manar II - Tunisia;
 E-mail : kamel.bensa...@fst.rnu.tn
  
 
***
 If you no longuer wish to receive my mails, please send a mail to 
k...@fst.rnu.tn with 'unsubscribe' in the subject line. 
 
***
  
  

Re: A bug in vrp_meet?

[Richard Biener]

On Sun, May 5, 2019 at 11:09 PM Eric Botcazou  wrote:
>
> > I have now applied this variant.
>
> You backported it onto the 8 branch on Friday:
>
> 2019-05-03  Richard Biener  
>
> Backport from mainline
> [...]
> 2019-03-07  Richard Biener  
>
> PR tree-optimization/89595
> * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take
> stmt iterator as reference, take boolean output parameter to
> indicate whether the stmt was removed and thus the iterator
> already advanced.
> (dom_opt_dom_walker::before_dom_children): Re-iterate over
> stmts created by folding.
>
> and this introduced a regression for the attached Ada testcase at -O:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0102173c in set_value_range (
> vr=0x17747a0  const*)::vr_const_varying>, t=VR_RANGE, min=0x76c3df78, max= out>, equiv=0x0)
> at /home/eric/svn/gcc-8-branch/gcc/tree-vrp.c:298
> 298   vr->type = t;
>
> on x86-64 at least.  Mainline and 9 branch are not affected.

It looks like backporting r269597 might fix it though reverting that on trunk
doesn't make the testcase fail there.

Richard.

> --
> Eric Botcazou

GCC 9 linker error, missing GOMP_loop_nonmonotonic_dynamic_next

[FX]

Hi gcc and gfortran developers,

While testing GCC 9.1.0 before shipping it as part of Homebrew for macOS, we’re 
seeing the following OpenMP-based failure when recompiling several software 
packages with GCC 9. It includes both C++ and Fortran codes, which were working 
fine with the exact same setup and GCC 8.3.0.

The missing symbols we’re seeing are always in this list:
_GOMP_loop_nonmonotonic_dynamic_next
_GOMP_loop_nonmonotonic_dynamic_start
_GOMP_loop_ull_nonmonotonic_guided_next
_GOMP_loop_ull_nonmonotonic_guided_start

The linker lines that generate these issues vary, but they are of the form:

g++-9   -fopenmp -std=c++14 -DNDEBUG *.o -o foo

or:

gfortran -fopenmp -ffast-math -funroll-loops -ftree-vectorize -ffree-form -O2 
*.o -o foo

which I think is valid, since passing -fopenmp to the driver should link the 
necessary libraries, in which it would find the symbols that the front-ends 
emitted. I have read the release notes and can’t find anything related.

Any advice?

Thanks,
FX

Please help!!!

[Алексей Хилаев via gcc]

Gcc riscv won`t emit my insns, binutils and spike(riscv sim) work correctly, 
but gcc don`t. I want to add min/max for integer, gcc compiling correct, sim 
executing correctly.

(define_insn "*min_"
[(set (match_operand:GPR 0 "register_operand" "=r")
(smin:GPR (match_operand:X 1 "register_operand" " r")
(match_operand:X 2 "register_operand" " r")))]
""
"min\t%0,%1,%2"
[(set_attr "type" "move")
(set_attr "mode" "")])

С уважением Алексей. телефон 8(904)169-90-96.

Re: GCC 9 linker error, missing GOMP_loop_nonmonotonic_dynamic_next

[Jakub Jelinek]

On Mon, May 06, 2019 at 02:41:41PM +0200, FX wrote:
> Hi gcc and gfortran developers,
> 
> While testing GCC 9.1.0 before shipping it as part of Homebrew for macOS, 
> we’re seeing the following OpenMP-based failure when recompiling several 
> software packages with GCC 9. It includes both C++ and Fortran codes, which 
> were working fine with the exact same setup and GCC 8.3.0.
> 
> The missing symbols we’re seeing are always in this list:
> _GOMP_loop_nonmonotonic_dynamic_next
> _GOMP_loop_nonmonotonic_dynamic_start
> _GOMP_loop_ull_nonmonotonic_guided_next
> _GOMP_loop_ull_nonmonotonic_guided_start

Those are certainly exported from my GCC 9 libgomp.so.1.0.0 (at least on
Linux but I don't see how it could not be elsewhere).
So, the most likely explanation would be you are compiling something with
GCC 9, but linking against GCC 8 or earlier version of libgomp.

Jakub

Re: GCC 9 linker error, missing GOMP_loop_nonmonotonic_dynamic_next

[Iain Sandoe]

> On 6 May 2019, at 09:02, Jakub Jelinek  wrote:
> 
> On Mon, May 06, 2019 at 02:41:41PM +0200, FX wrote:
>> Hi gcc and gfortran developers,
>> 
>> While testing GCC 9.1.0 before shipping it as part of Homebrew for macOS, 
>> we’re seeing the following OpenMP-based failure when recompiling several 
>> software packages with GCC 9. It includes both C++ and Fortran codes, which 
>> were working fine with the exact same setup and GCC 8.3.0.
>> 
>> The missing symbols we’re seeing are always in this list:
>> _GOMP_loop_nonmonotonic_dynamic_next
>> _GOMP_loop_nonmonotonic_dynamic_start
>> _GOMP_loop_ull_nonmonotonic_guided_next
>> _GOMP_loop_ull_nonmonotonic_guided_start
> 
> Those are certainly exported from my GCC 9 libgomp.so.1.0.0 (at least on
> Linux but I don't see how it could not be elsewhere).

I can’t, at present, see how it would be different Darwin.

> So, the most likely explanation would be you are compiling something with
> GCC 9, but linking against GCC 8 or earlier version of libgomp.

Could you file a PR with a reproducer - presumably even a trivial OpenMP 
program will fail?

thanks
Iain

Status for 9.1.0 (GCC) on x86_64-w64-mingw32

[Rainer Emrich]

Testsuite results here:
https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00743.html

Complete bootstrap and testsuite logs here:
https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W

At the moment there's an issue in the d frontend testsuite.

Linking of directory gdc.test "ln -s . gdc.test" in the gdc directory
doesn't work on msys2. This leads to a recursion and results in an error.

ERROR: tcl error sourcing
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/gdc-test.exp.
ERROR: couldn't open "gdc.test/compilable/99bottles.d": no such file or
directory
while executing
"open $file r"
(procedure "grep" line 19)
invoked from within
"grep $prog "{\[ \t\]\+dg-\[-a-z\]\+\[ \t\]\+.*\[ \t\]\+}" line"
(procedure "dg-get-options" line 4)
invoked from within
"dg-get-options $prog"
(procedure "saved-dg-test" line 75)
invoked from within
"saved-dg-test gdc.test/compilable/99bottles.d { }
-I/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/compilable"
("eval" body line 1)
invoked from within
"eval saved-dg-test $args "
(procedure "dg-test" line 4)
invoked from within
"dg-test $test "$flags $flags_t" ${default-extra-flags}"
(procedure "gdc-dg-runtest" line 23)
invoked from within
"gdc-dg-runtest $filename $flags $imports"
(procedure "gdc-do-test" line 86)
invoked from within
"gdc-do-test"
(file
"/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/gdc-test.exp"
line 468)
invoked from within
"source
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/gdc-test.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/gdc-test.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""



signature.asc
Description: OpenPGP digital signature

Re: Status for 9.1.0 (GCC) on x86_64-w64-mingw32

[Rainer Emrich]

Am 06.05.2019 um 16:36 schrieb Rainer Emrich:
> Testsuite results here:
> https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00743.html
> 
> Complete bootstrap and testsuite logs here:
> https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W
> 
> At the moment there's an issue in the d frontend testsuite.
> 
> Linking of directory gdc.test "ln -s . gdc.test" in the gdc directory
> doesn't work on msys2. This leads to a recursion and results in an error.
> 
> ERROR: tcl error sourcing
> /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/gdc-test.exp.
> ERROR: couldn't open "gdc.test/compilable/99bottles.d": no such file or
> directory
> while executing
> "open $file r"
> (procedure "grep" line 19)
> invoked from within
> "grep $prog "{\[ \t\]\+dg-\[-a-z\]\+\[ \t\]\+.*\[ \t\]\+}" line"
> (procedure "dg-get-options" line 4)
> invoked from within
> "dg-get-options $prog"
> (procedure "saved-dg-test" line 75)
> invoked from within
> "saved-dg-test gdc.test/compilable/99bottles.d { }
> -I/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/compilable"
> ("eval" body line 1)
> invoked from within
> "eval saved-dg-test $args "
> (procedure "dg-test" line 4)
> invoked from within
> "dg-test $test "$flags $flags_t" ${default-extra-flags}"
> (procedure "gdc-dg-runtest" line 23)
> invoked from within
> "gdc-dg-runtest $filename $flags $imports"
> (procedure "gdc-do-test" line 86)
> invoked from within
> "gdc-do-test"
> (file
> "/opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/gdc-test.exp"
> line 468)
> invoked from within
> "source
> /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/gdc-test.exp"
> ("uplevel" body line 1)
> invoked from within
> "uplevel #0 source
> /opt/devel/gnu/src/gcc-mingw-w64/gcc-9.1.0/gcc/testsuite/gdc.test/gdc-test.exp"
> invoked from within
> "catch "uplevel #0 source $test_file_name""
> 
opened Bug 90368.



signature.asc
Description: OpenPGP digital signature

Re: Please help!!!

[Segher Boessenkool]

On Mon, May 06, 2019 at 04:01:58PM +0300, Алек�1557147755�й Хилаев via gcc 
wrote:
> Gcc riscv won`t emit my insns, binutils and spike(riscv sim) work correctly, 
> but gcc don`t. I want to add min/max for integer, gcc compiling correct, sim 
> executing correctly.
> 
> (define_insn "*min_"
> [(set (match_operand:GPR 0 "register_operand" "=r")
> (smin:GPR (match_operand:X 1 "register_operand" " r")
> (match_operand:X 2 "register_operand" " r")))]
> ""
> "min\t%0,%1,%2"
> [(set_attr "type" "move")
> (set_attr "mode" "")])

You need to call the patterns "minsi3" and the like, if you want it to be
automatically generated.  Possibly combine can also make these patterns
for you; look at its dump file (-fdump-rtl-combine-all) to see what it
tried.


Segher

Re: Please help!!!

[Jim Wilson]

On Mon, May 6, 2019 at 6:02 AM Алексей Хилаев via gcc  wrote:
> Gcc riscv won`t emit my insns, binutils and spike(riscv sim) work correctly, 
> but gcc don`t. I want to add min/max for integer, gcc compiling correct, sim 
> executing correctly.
> (define_insn "*min_"
> [(set (match_operand:GPR 0 "register_operand" "=r")
> (smin:GPR (match_operand:X 1 "register_operand" " r")
> (match_operand:X 2 "register_operand" " r")))]
> ""
> "min\t%0,%1,%2"
> [(set_attr "type" "move")
> (set_attr "mode" "")])

You must have patterns named sminXi3 where X can be s and/or d.
Likewise for smaxXi3.  Once the named patterns exist, then gcc will
automatically call the named patterns to generate RTL when
appropriate.  Then later passes like combine can create new RTL from
the min/max pattern RTL.  See for instance how the existing FP min/max
patterns work.  The pattern name is important.  You might also
consider adding uminXi3 and umaxXi3 patterns.  You can find a list of
supported named patterns in the gcc docs.

Also note that the RTL that you generate must look sensible.  You have
a smin:GPR operation that is accepting Xmode operands which is not OK.
The modes must match.  You can use sign_extend/zero_extend to
sign/zero extend a smaller mode to a larger mode, and subreg to reduce
a larger mode to a smaller one.   These will have to be separate
patterns.  But once you have the basic smin/smax patterns, combine can
create the sign_extend/whatever versions for you.  See for instance
how the addsi3 and addsi3_extend* patterns work.

Jim

Re: GSOC

[Giuliano Belinassi]

Hi,

On 03/29, Richard Biener wrote:
> On Thu, 28 Mar 2019, Giuliano Belinassi wrote:
> 
> > Hi, Richard
> > 
> > On 03/28, Richard Biener wrote:
> > > On Wed, Mar 27, 2019 at 2:55 PM Giuliano Belinassi
> > >  wrote:
> > > >
> > > > Hi,
> > > >
> > > > On 03/26, Richard Biener wrote:
> > > > > On Tue, 26 Mar 2019, David Malcolm wrote:
> > > > >
> > > > > > On Mon, 2019-03-25 at 19:51 -0400, nick wrote:
> > > > > > > Greetings All,
> > > > > > >
> > > > > > > I would like to take up parallelize compilation using threads or 
> > > > > > > make
> > > > > > > c++/c
> > > > > > > memory issues not automatically promote. I did ask about this 
> > > > > > > before
> > > > > > > but
> > > > > > > not get a reply. When someone replies I'm just a little concerned 
> > > > > > > as
> > > > > > > my writing for proposals has never been great so if someone just
> > > > > > > reviews
> > > > > > > and doubt checks that's fine.
> > > > > > >
> > > > > > > As for the other things building gcc and running the testsuite is
> > > > > > > fine. Plus
> > > > > > > I already working on gcc so I've pretty aware of most things and 
> > > > > > > this
> > > > > > > would
> > > > > > > be a great steeping stone into more serious gcc development work.
> > > > > > >
> > > > > > > If sample code is required that's in mainline gcc I sent out a 
> > > > > > > trial
> > > > > > > patch
> > > > > > > for this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Nick
> > > > > >
> > > > > > It's good to see that you've gotten as far as attaching a patch to 
> > > > > > BZ
> > > > > > [1]
> > > > > >
> > > > > > I think someone was going to attempt the "parallelize compilation 
> > > > > > using
> > > > > > threads" idea last year, but then pulled out before the summer; you 
> > > > > > may
> > > > > > want to check the archives (or was that you?)
> > > > >
> > > > > There's also Giuliano Belinassi who is interested in the same project
> > > > > (CCed).
> > > >
> > > > Yes, I will apply for this project, and I will submit the final version
> > > > of my proposal by the end of the week.
> > > >
> > > > Currently, my target is the `expand_all_functions` routine, as most of
> > > > the time is spent on it according to the experiments that I performed as
> > > > part of my Master's research on compiler parallelization.
> > > > (-O2, --disable-checking)
> > > 
> > > Yes, more specifically I think the realistic target is the GIMPLE part
> > > of   execute_pass_list (cfun, g->get_passes ()->all_passes);  done in
> > > cgraph_node::expand.  If you look at passes.def you'll see all_passes
> > > also contains RTL expansion (pass_expand) and the RTL optimization
> > > queue (pass_rest_of_compilation).  The RTL part isn't a realistic target.
> > > Without changing the pass hierarchy the obvious part that can be
> > > handled would be the pass_all_optimizations pass sub-queue of
> > > all_passes since those are all passes that perform transforms on the
> > > GIMPLE IL where we have all functions in this state at the same time
> > > and where no interactions between the functions happen anymore
> > > and thus functions can be processed in parallel (as much as make
> > > processes individual translation units in parallel).
> > > 
> > 
> > Great. So if I understood correctly, I will need to split
> > cgraph_node::expand() into three parts: IPA, GIMPLE and RTL, and then
> > refactor `expand_all_functions` so that the loop
> > 
> >  for (i = new_order_pos - 1; i >= 0; i--)
> > 
> >  use these three functions, then partition
> > 
> >  g->get_passes()->all_passes
> > 
> > into get_passes()->gimple_passes and get_passes()->rtl_passes, so I
> > can run RTL after GIMPLE is finished, to finally start the
> > paralellization of per function GIMPLE passes.
> 
> Yes, it involves refactoring of the loop - you may notice that
> parts of the compilation pipeline are under control of the
> pass manager (passes.c) but some is still manually driven
> by symbol_table::compile.  Whether it's more convenient to
> get more control stuffed to the pass manager and perform the
> threading under its control (I'd say that would be the cleaner
> design) or to try do this in the current ad-hoc parts remains
> to be seen.  You can see symbol_table::compile hands over
> control to the pass manager multiple times, first ipa_passes ()
> then all_late_ipa_passes and finally the expand_all_functions code.
> 
> I guess it would simplify things if you'd split pass_all_passes
> in passes.def at pass_expand like so:
> 
> diff --git a/gcc/passes.def b/gcc/passes.def
> index 2fcd80e53a3..bb0453b36a7 100644
> --- a/gcc/passes.def
> +++ b/gcc/passes.def
> @@ -403,11 +403,10 @@ along with GCC; see the file COPYING3.  If not see
>NEXT_PASS (pass_spectrev1);
>NEXT_PASS (pass_warn_function_noreturn);
>NEXT_PASS (pass_gen_hsail);
> +  TERMINATE_PASS_LIST (all_passes)
>  
> -  NEXT_PASS (pass_expand);
> -
> -  NEXT_

C++ no except updates

[nick]

Jonathan,

I don't know what work is remaining in my ideas with inlining r value functions 
as you
seemed to have already taken up and probably finished my ideas from reading the 
list.
If you want help finishing it just send me a ToDO of since C++11 and C++20 
classes have
not been made noexcept for the move constructor and assignment operator.


Thanks if possible,

Nick