Re: Patching the GCC build system to build MPICH and OpenCoarrays

[Richard Biener]

On Wed, Apr 4, 2018 at 8:24 AM, Damian Rouson
 wrote:
> On April 3, 2018 at 1:36:37 AM, Richard Biener (richard.guent...@gmail.com)
> wrote:
>
>
> You probably only want a new target_module for the MPI library. Note
> it's name has to match that of the directory containing the sources
> which
> as far as I see is 'mpich', not 'libmpi'.
>
> Thanks!  I’ll ask Daniel to respond if he has further questions.
>
> May I ask again why mpi/opencoarrays should be built together with
> gfortran rather than separately? Does gfortran or any of its current
> target libraries
> link against them?
>
> Yes, gfortran links to OpenCoarrays via the -fcoarray=lib argument.

In that case user programs compiled with -fcoarray=lib are but gfortran
or libgfortran itself is not linked against OpenCoarrays?

> OpenCoarrays provides the only parallel implementations of gfortran’s
> Coarray ABI (http://bit.ly/Coarray-ABI). Any Fortran program that uses the
> large set of parallel features in Fortran 2008 and Fortran 2018 must have
> OpenCoarrays installed in order for the code to execute in parallel.

I see.  So if we consider OpenCoarrays part of the gfortran runtime then
it makes sense to build it in-tree...

> We have found MPICH to be the most robust option and it has the only
> released support for some of the more advanced requirements such as the
> Fortran 2018 fault-tolerance features.  However, there will be configure
> options for using MPI implementations other than MPICH.

... but building an mpi library in-tree might not?

I'm still lacking an idea of what it takes to enable coarrays with gfortran
since install.texi doesn't talk about this at all, neither in the prerequesites
section nor in a fortran/coarray specific section.

In fact the only thing I find is in invoke.texi which says

@item -fcoarray=@var{}
@opindex @code{fcoarray}
...
@item @samp{lib}
Library-based coarray parallelization; a suitable GNU Fortran coarray
library needs to be linked.
@end table

which suggests linking to the coarray library doesn't happen automatically
but the user is supposed to link a suitable library?

I'd love to "enable" coarray support for openSUSE but as said I have a hard
time assessing what I'd need to do here.

Thanks,
Richard.

>
> Damian

Re: where should C++ options be documented?

[Nathan Sidwell]

On 04/03/2018 07:05 PM, Martin Sebor wrote:
@@ -3914,6 +3916,7 @@ Options} and @ref{Objective-C and Objective-C++ Di
 -Wc++11-compat  -Wc++14-compat  @gol
 -Wcatch-value @r{(C++ and Objective-C++ only)}  @gol
 -Wchar-subscripts  @gol
+-Wclass-memaccess @r{(C++ and Objective-C++ only)}  @gol
 -Wcomment  @gol
 -Wduplicate-decl-specifier @r{(C and Objective-C only)} @gol
 -Wenum-compare @r{(in C/ObjC; this is on by default in C++)} @gol

The verbose '(C++ and Objective-C++ only)' and similar repeated 
annotations are annoying.  Even in the diff snippet there's no 
consistency -- Why is -Wc++11-compat not annotated, why does 
enum-compare contain what looks like documentation; 'on by default ...'.


Either don't note at this point, or use some contraction such as simply 
'(C)' or '(C++)' with the understanding that unless otherwise specified 
that includes the objective dialect.


Is it possible to use two different footnote markers such as 
{C,C++} and explain in the so-noted footnote?


nathan
--
Nathan Sidwell

Re: where should C++ options be documented?

[Jason Merrill]

On Tue, Apr 3, 2018 at 7:05 PM, Martin Sebor  wrote:
> On 04/03/2018 08:08 AM, Jason Merrill wrote:
>> On Mon, Apr 2, 2018 at 9:33 PM, Martin Sebor  wrote:
>>>
>>> Jason,
>>>
>>> The manual mentions some C++-only options in the language
>>> independent section 3.8 Options to Request or Suppress
>>> Warnings and others in 3.5 Options Controlling C++ Dialect.
>>>
>>> For example, -Wcatch-value, -Wconditionally-supported,
>>> and -Wzero-as-null-pointer-constant are mentioned only
>>> on the former page, while -Wabi-tag, -Wctor-dtor-privacy,
>>> -Wliteral-suffix, and -Wclass-memaccess are mentioned only
>>> on the latter.
>>>
>>> That makes C++ options harder to find than they should be.
>>> It also makes it difficult to tell which C++ options are
>>> included in -Wall or -Wextra.  I think we should converge
>>> on the same approach for all C++ options that doesn't have
>>> these problems.  What should it be?
>>>
>>> An approach that I think might work well is to continue
>>> to mention even C++-only options in 3.8 but move their
>>> descriptions to 3.5 (i.e., have the entry for each link
>>> to the full description of the option on the C++ page).
>>
>>
>> Sounds good.
>>
>>> Should I try to make this happen for GCC 8?
>>
>>
>> Sure.
>
>
> Attached is a prototype of what I have in mind.  It changes
> just one option for illustration: -Wclass-memaccess.  Once
> we're happy with the result I'll follow the same approach
> for the rest of the C++ warning options.
>
> To make it possible to jump directly to the detailed option
> I had to add an explicit anchor.  That's an extra step that
> would be nice to avoid.

It would indeed be nice if there were a way to xref to an index entry.

> The reference from -Wclass-memaccess
> in 3.8 to the detailed option description in 3.5 renders like
> this in HTML:
>
>   See -Wclass-memaccess in Controlling C++ Dialect.
>
> and like this in PDF:
>
>   See [Wclass-memaccess], page 52 in Section 3.5 [Controlling C++ Dialect],
> page 42.

Do we need both page numbers?

> +@item -Wno-class-memaccess @r{(C++ and Objective-C++ only)}
> +@opindex Wclass-memaccess
> +@opindex Wno-class-memaccess
> +See @ref{Wclass-memaccess,@option{-Wclass-memaccess}} in @ref{C++ Dialect 
> Options,,Controlling C++ Dialect}.

I don't think we want index entries for cross references.

Jason

Re: where should C++ options be documented?

[Martin Sebor]

Let me try gzipping the attachment to see if it gets past
SpamAssassin.

On 04/04/2018 11:08 AM, Martin Sebor wrote:

On 04/04/2018 05:49 AM, Nathan Sidwell wrote:

On 04/03/2018 07:05 PM, Martin Sebor wrote:
@@ -3914,6 +3916,7 @@ Options} and @ref{Objective-C and Objective-C++ Di
 -Wc++11-compat  -Wc++14-compat  @gol
 -Wcatch-value @r{(C++ and Objective-C++ only)}  @gol
 -Wchar-subscripts  @gol
+-Wclass-memaccess @r{(C++ and Objective-C++ only)}  @gol
 -Wcomment  @gol
 -Wduplicate-decl-specifier @r{(C and Objective-C only)} @gol
 -Wenum-compare @r{(in C/ObjC; this is on by default in C++)} @gol

The verbose '(C++ and Objective-C++ only)' and similar repeated
annotations are annoying.  Even in the diff snippet there's no
consistency -- Why is -Wc++11-compat not annotated, why does
enum-compare contain what looks like documentation; 'on by default ...'.

Either don't note at this point, or use some contraction such as simply
'(C)' or '(C++)' with the understanding that unless otherwise specified
that includes the objective dialect.


I agree.  How about using a @multitable:

  @option{-Wall} turns on the following warning flags:

  @multitable @columnfractions .3 .7
  @headitem Option @tab Notes
  @item @option{-Waddress}
  @item @option{-Warray-bounds=1}
  @tab Only with @option{-O2}.
  @item @option{-Wbool-compare}
  ...
  @end multitable

The PDF output of markup is attached.  The HTML looks similar
(the column headings are centered and don't line up with the
column text).

With this approach we could avoid having subsequent entries
for the C++ options in the section.  (Unfortunately, I don't
see a way to point directly at the detailed C++ description
of the option from the table.)



Is it possible to use two different footnote markers such as
{C,C++} and explain in the so-noted footnote?


I don't think that's possible with @footnote.  Texinfo seems
to like to number each seperately and I don't see a way to
change the numbering into something else.  It might be possible
to achieve a similar effect with cross-references if the table
idea doesn't fly.

Martin




gcc-page-64.pdf.gz
Description: application/gzip

Re: where should C++ options be documented?

[Martin Sebor]

On 04/04/2018 07:05 AM, Jason Merrill wrote:

On Tue, Apr 3, 2018 at 7:05 PM, Martin Sebor  wrote:

On 04/03/2018 08:08 AM, Jason Merrill wrote:

On Mon, Apr 2, 2018 at 9:33 PM, Martin Sebor  wrote:


Jason,

The manual mentions some C++-only options in the language
independent section 3.8 Options to Request or Suppress
Warnings and others in 3.5 Options Controlling C++ Dialect.

For example, -Wcatch-value, -Wconditionally-supported,
and -Wzero-as-null-pointer-constant are mentioned only
on the former page, while -Wabi-tag, -Wctor-dtor-privacy,
-Wliteral-suffix, and -Wclass-memaccess are mentioned only
on the latter.

That makes C++ options harder to find than they should be.
It also makes it difficult to tell which C++ options are
included in -Wall or -Wextra.  I think we should converge
on the same approach for all C++ options that doesn't have
these problems.  What should it be?

An approach that I think might work well is to continue
to mention even C++-only options in 3.8 but move their
descriptions to 3.5 (i.e., have the entry for each link
to the full description of the option on the C++ page).



Sounds good.


Should I try to make this happen for GCC 8?



Sure.



Attached is a prototype of what I have in mind.  It changes
just one option for illustration: -Wclass-memaccess.  Once
we're happy with the result I'll follow the same approach
for the rest of the C++ warning options.

To make it possible to jump directly to the detailed option
I had to add an explicit anchor.  That's an extra step that
would be nice to avoid.


It would indeed be nice if there were a way to xref to an index entry.


The reference from -Wclass-memaccess
in 3.8 to the detailed option description in 3.5 renders like
this in HTML:

  See -Wclass-memaccess in Controlling C++ Dialect.

and like this in PDF:

  See [Wclass-memaccess], page 52 in Section 3.5 [Controlling C++ Dialect],
page 42.


Do we need both page numbers?


I don't see a way to avoid them if we keep both references.
TexInfo inserts them automatically and I can't find a directive
to suppress them.  In the multitable format I posted earlier
I only used the latter reference because it makes it clear
when an option is C++ only.  The downside is that it doesn't
take us directly to the description of the C++ option.  I could
use the former reference instead to jump directly to the option
but then it would say "Section 3.5 [whatever we put in here],
page 45 which would look funny if it said [C++ and Objective-C++
only].  Ideally, I'd like to see just "C++ and Objective-C++ only"
next to each option in the table and either have the text point
to the option description or turn the option name into a link
pointing to it, but I don't think that's possible, so we'll
probably have to come up with some compromise.  What should
it be?




+@item -Wno-class-memaccess @r{(C++ and Objective-C++ only)}
+@opindex Wclass-memaccess
+@opindex Wno-class-memaccess
+See @ref{Wclass-memaccess,@option{-Wclass-memaccess}} in @ref{C++ Dialect 
Options,,Controlling C++ Dialect}.


I don't think we want index entries for cross references.


Sure, I can remove the @opindex directives here.

Martin

Re: where should C++ options be documented?

[Jason Merrill]

On Wed, Apr 4, 2018 at 2:18 PM, Martin Sebor  wrote:
> On 04/04/2018 07:05 AM, Jason Merrill wrote:
>>
>> On Tue, Apr 3, 2018 at 7:05 PM, Martin Sebor  wrote:
>>>
>>> On 04/03/2018 08:08 AM, Jason Merrill wrote:

 On Mon, Apr 2, 2018 at 9:33 PM, Martin Sebor  wrote:
>
>
> Jason,
>
> The manual mentions some C++-only options in the language
> independent section 3.8 Options to Request or Suppress
> Warnings and others in 3.5 Options Controlling C++ Dialect.
>
> For example, -Wcatch-value, -Wconditionally-supported,
> and -Wzero-as-null-pointer-constant are mentioned only
> on the former page, while -Wabi-tag, -Wctor-dtor-privacy,
> -Wliteral-suffix, and -Wclass-memaccess are mentioned only
> on the latter.
>
> That makes C++ options harder to find than they should be.
> It also makes it difficult to tell which C++ options are
> included in -Wall or -Wextra.  I think we should converge
> on the same approach for all C++ options that doesn't have
> these problems.  What should it be?
>
> An approach that I think might work well is to continue
> to mention even C++-only options in 3.8 but move their
> descriptions to 3.5 (i.e., have the entry for each link
> to the full description of the option on the C++ page).



 Sounds good.

> Should I try to make this happen for GCC 8?



 Sure.
>>>
>>>
>>>
>>> Attached is a prototype of what I have in mind.  It changes
>>> just one option for illustration: -Wclass-memaccess.  Once
>>> we're happy with the result I'll follow the same approach
>>> for the rest of the C++ warning options.
>>>
>>> To make it possible to jump directly to the detailed option
>>> I had to add an explicit anchor.  That's an extra step that
>>> would be nice to avoid.
>>
>>
>> It would indeed be nice if there were a way to xref to an index entry.
>>
>>> The reference from -Wclass-memaccess
>>> in 3.8 to the detailed option description in 3.5 renders like
>>> this in HTML:
>>>
>>>   See -Wclass-memaccess in Controlling C++ Dialect.
>>>
>>> and like this in PDF:
>>>
>>>   See [Wclass-memaccess], page 52 in Section 3.5 [Controlling C++
>>> Dialect],
>>> page 42.
>>
>>
>> Do we need both page numbers?
>
> I don't see a way to avoid them if we keep both references.

Maybe leave out the second reference and add "Controlling C++ Dialect"
to the text of the first reference instead?

Jason

gcc-6-20180404 is now available

[gccadmin]

Snapshot gcc-6-20180404 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180404/
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 259106

You'll find:

 gcc-6-20180404.tar.xzComplete GCC

  SHA256=4edcfb02859b8cde133619b28a3064a67b033ba35dbeda79a8dac23f3e2594f3
  SHA1=8e5f0afc91e4555bbbdfd9f55bf2e680cc518f08

Diffs from 6-20180328 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.

Re: how to generate - "procedure linkage table" for MIPS

[Maciej W. Rozycki]

Hi Vidya,

On Mon, 5 Mar 2018, V R wrote:

> Also on enabling gcc on MIPS with "–with-mips-plt " option the plt stub
> wasnt seen. Is there
> 
> anything missing that needs to be done or is there any limitation , please
> let me know.

 What problem are you trying to solve?  Can you run `readelf -S' on a MIPS 
executable you think you have a trouble with and post the result?

 NB MIPS shared libraries use the so called lazy binding stubs, where the 
call is always indirect, rather than a procedure linkage table to achieve 
a similar effect, so you won't ever see a PLT in a MIPS shared library.

  Maciej

Vincent Forbes's invitation is waiting for your response

[Vincent Forbes via Nextdoor]

  Vincent Forbes has invited you to join Nextdoor.


Nextdoor is a private social network that helps neighbors connect with each 
other to build stronger communities.

To accept your invitation, follow the link below:
https://nextdoor.com/invitation/?i=ggkkfghlzxggthdsqdsl&stage=1

---
This message is intended for gcc@gcc.gnu.org and promotes membership in a free 
neighborhood social network. To stop receiving email reminders about this 
invitation, use the following link:
https://nextdoor.com/email_prefs/?panel=n

Nextdoor, 875 Stevenson Street, Suite 700, San Francisco, CA 94103

Re: where should C++ options be documented?

[Eric Gallager]

On 4/2/18, Martin Sebor  wrote:
> Jason,
>
> The manual mentions some C++-only options in the language
> independent section 3.8 Options to Request or Suppress
> Warnings and others in 3.5 Options Controlling C++ Dialect.
>
> For example, -Wcatch-value, -Wconditionally-supported,
> and -Wzero-as-null-pointer-constant are mentioned only
> on the former page, while -Wabi-tag, -Wctor-dtor-privacy,
> -Wliteral-suffix, and -Wclass-memaccess are mentioned only
> on the latter.
>
> That makes C++ options harder to find than they should be.
> It also makes it difficult to tell which C++ options are
> included in -Wall or -Wextra.  I think we should converge
> on the same approach for all C++ options that doesn't have
> these problems.  What should it be?
>
> An approach that I think might work well is to continue
> to mention even C++-only options in 3.8 but move their
> descriptions to 3.5 (i.e., have the entry for each link
> to the full description of the option on the C++ page).
>
> Should I try to make this happen for GCC 8?
>
> Martin
>

This is bug 71283: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71283

Re: GSoC (Improvements to GCC on Windows)

[Ko Phyo]

I have been a little busy in recent days. I'll check it out in a day or
two. Thanks for your response.

On Mon, Apr 2, 2018, 12:56 PM Liu Hao  wrote:

> 在 2018/4/2 13:54, Ko Phyo 写道:
> > Thank for your valuable information. I couldn't made it for GSoC 2018 due
> > to delay of my proposal application because of my University 1st semester
> > examination. If you guys allow me to apply this kind of project in future
> > (Not as GSoC applicant), I would be happily take part in it. Thanks in
> > advanced.
> >
> > On Apr 1, 2018 9:39 PM, "JonY" <10wa...@gmail.com> wrote:
> >> Hi, I have been away for work this past month.
> >>
> >> There is a demand for a proper C++11 threading implementation for
> >> Windows using native Windows APIs (post Vista APIs), I have not looked
> >> too much into it, nor do I know if the scope is too big or too small for
> >> a summer project. Liu Hao has worked on it, and should be familiar with
> >> the scope, I have CC'ed him.
> >>
> >> Never having run any gsoc programs, are there any specific procedures to
> >> get it started?
> >>
> >>
>
> Well I thought I was almost forgotten.  XD
>
> You might want to have a look at my benchmarking result at
> . Prebuilt
> binaries are available at .
>
> I haven't heard of anyone using this new thread model in production
> environments. So it would be very kind of you for advertising for it.
>
> --
> Best regards,
> LH_Mouse
>
>