Re: [C++ Patch/RFC] PR 84348 ("[7/8 Regression] ICE with invalid friend declaration")

[Jason Merrill]

OK.

On Fri, Feb 16, 2018 at 5:30 PM, Paolo Carlini  wrote:
> Hi,
>
> here we ICE during error recovery when, after emitting a correct error from
> grokdeclarator, we go on, we only clear friendp, and grokfield proceeds to
> call cp_finish_decl where 'gcc_assert (CLASS_PLACEHOLDER_TEMPLATE
> (auto_node));' triggers. We could imagine solving the problem in various
> ways... If we want to do something as early as possible, in grokdeclarator,
> over the years in turn we handled different cases in different ways related
> to the error recovery effects, mostly. A straightforward solution, which I'm
> finishing testing, would be just bailing-out after the error, alternately we
> could also imagine something relatively sophisticated like going on, but
> also setting type = error_mark_node conditional to type_uses_auto (auto)
> thus mimicking the error recovery strategy we use above for a non-friend
> ill-formed variant. Just unconditionally setting type = error_mark_node
> doesn't seem morally correct to me - even if probably it would also pass the
> testsuite - because what we are actually diagnosing to the user, in fact the
> first problem in such snippet in parsing order, doesn't have to do with the
> type per se, but with friend - the diagnostic for 'friend int foo' is the
> same. As usual I'm on x86_64-linux.
>
> Thanks, Paolo.
>
> 
>

Re: [PATCH] replace ICE with error for failed template deduction (PR 84355)

[Jason Merrill]

On Fri, Feb 16, 2018 at 4:33 PM, Martin Sebor  wrote:
> On 02/16/2018 07:04 AM, Jason Merrill wrote:
>>
>> On Thu, Feb 15, 2018 at 6:36 PM, Martin Sebor  wrote:
>>>
>>> A failed template deduction in template member of a template
>>> triggers an ICE with -std=c++17 due to what seems like
>>> a missing handling of invalid input.  Replacing
>>> the gcc_unreachable() call that causes the ICE with a return
>>> statement indicating the deduction failure eliminates the ICE
>>> and restores sane diagnostics.
>>
>>
>> Hmm, we really shouldn't have gotten there; that assert is checking
>> that when we see a TEMPLATE_*_PARM node in the template signature, it
>> corresponds to one of the actual parms of the template.  Sounds like
>> something is going wrong in build_deduction_guide.
>
>
> Are you suggesting that build_deduction_guide should fail somehow
> (it's not expected to fail right now) or that the guide it creates
> is wrong?

The latter.  Maybe we're handling T wrong somehow?  We shouldn't be
trying to deduce it.  In fact, we probably shouldn't be trying to
deduce arguments for 'b' until we instantiate A.

Jason

Re: [PATCH] gold: Use autotools pthread macro

[Joshua Watt]

On Sat, Feb 17, 2018 at 4:42 PM, Cary Coutant  wrote:
>> The autotools library macro (AX_PTHREAD) is now used to detect if
>> pthreads is present and multi-threaded linking in gold is automatically
>> enabled if it is found. This enables multi-threaded gold on platforms
>> where pthreads is enabled via other methods than just -lpthread (e.g.
>> MinGW)
>>
>> Signed-off-by: Joshua Watt 
>> ---
>>  config/ax_pthread.m4   | 485 
>>  gold/Makefile.am   |  11 +-
>>  gold/Makefile.in   |  22 +-
>>  gold/aclocal.m4|   1 +
>>  gold/configure | 767 
>> +++--
>>  gold/configure.ac  |  23 +-
>>  gold/testsuite/Makefile.in |   8 +-
>>  7 files changed, 1254 insertions(+), 63 deletions(-)
>
> Thanks for the patch! I have a few preliminary questions and comments...
>
> First, do you or your company have a copyright assignment on file with FSF?

I do not. What is the process for that? I don't need a company
assignment, an individual contributor for me will be fine.

If I sign that for this project, would it also cover GCC, or do I need
one for each?

>
> I could be wrong, but I believe adding to config/ will require
> approval from a GCC config/ maintainer. The normal process, as I
> understand it, would be to add the file to the GCC tree, then sync it
> into the binutils tree. I'm not in a position to approve that, nor can
> I judge on the acceptability of the copyright notice in that file.

Ok. I didn't realize the config/ directory came from GCC. I'll look
into getting it submitted there How does that get "synced" to
binutils? Would I make a patch to add it here after it is added there?

FWIW, it is the same license as the ax_check_define macro (also from
the autotools macro archive) that is already in config/

>
> I'd like to retain the ability to use --disable-threads as a configure option.
>

I will add that back in.

> If this is just to get MinGW on board, is there a lighter-weight way
> of doing that? Could we just add a configure option that switches
> between -lpthread and -pthread (or whatever option is needed)? I like
> the idea of fully automating it, but that's a pretty big m4 file!

It is pretty large I pulled it straight from the autoconf macro
archive. IMHO, its much better quality than anything I would be able
to come up with otherwise, and pretty brain-dead easy for the end
user. It should "just work" without any special switches (although the
user *can* configure it with some env-vars I think).

>
> Anyway, I'd like to hear what the GCC folks think of adding
> ax_pthread.m4 to the config/ directory.
>
> (BTW, In the future, please omit diffs from generated files from your patch.)

Will do. I couldn't find a lot of examples of config changes in
binutils, but I thought the one that I did updated the generated files
also. I must have been mistaken.

>
> -cary

Thanks,
Joshua Watt

Re: [Patch, fortran] PR83344 - Use of uninitialized memory with ASSOCIATE and strings

[Paul Richard Thomas]

Hi Janne and Thomas,

1) The patch is attached now - sorry!

2) The commented out part of associate_22.f90 is not yet fixed. I am
working on it.

3) I will take a look at PR83975 tomorrow night.

Paul


On 18 February 2018 at 16:08, Janne Blomqvist  wrote:
> On Sun, Feb 18, 2018 at 5:48 PM, Paul Richard Thomas
>  wrote:
>> Bootstraps and regtests on FC27/x86_64 - OK for trunk?
>
> Hi,
>
> thanks for looking into this!
>
> 1. The patch itself is missing...
>
> 2. Could you uncomment the commented out part of associate_22.f90 and
> check that the tree-original dump is sensible.
>
> 3. Same for the testcases posted to PR 83975. I suspect (err, hope)
> that this patch would fix those as well. If so, please add that PR to
> the ChangeLog entries as well.
>
>>
>> Paul
>>
>> 2018-02-18  Paul Thomas  
>>
>> PR fortran/83344
>> * resolve.c (resolve_assoc_var): Character associate names that
>> have no length expression that have variable targets and are
>> not deferred length have assumed length.
>> * trans-decl.c (gfc_get_symbol_decl): Set 'length' to
>> gfc_index_zero_node for character associate names, whose string
>> length is a PARM_DECL.
>>
>> 2018-02-18  Paul Thomas  
>>
>> PR fortran/83344
>> * gfortran.dg/associate_36.f90: New test.
>
>
>
> --
> Janne Blomqvist



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 257787)
--- gcc/fortran/resolve.c   (working copy)
*** resolve_assoc_var (gfc_symbol* sym, bool
*** 8656,8662 
sym->ts.u.cl->length =
  gfc_get_int_expr (gfc_charlen_int_kind, NULL,
target->value.character.length);
! else
gfc_error ("Not Implemented: Associate target with type character"
   " and non-constant length at %L", >where);
}
--- 8656,8663 
sym->ts.u.cl->length =
  gfc_get_int_expr (gfc_charlen_int_kind, NULL,
target->value.character.length);
! /* If the target is a variable, it is an assumed length dummy.  */
! else if (target->expr_type != EXPR_VARIABLE)
gfc_error ("Not Implemented: Associate target with type character"
   " and non-constant length at %L", >where);
}
Index: gcc/fortran/trans-decl.c
===
*** gcc/fortran/trans-decl.c(revision 257787)
--- gcc/fortran/trans-decl.c(working copy)
*** gfc_get_symbol_decl (gfc_symbol * sym)
*** 1712,1718 
  
if (sym->attr.associate_var
  && sym->ts.u.cl->backend_decl
! && VAR_P (sym->ts.u.cl->backend_decl))
length = gfc_index_zero_node;
else
length = gfc_create_string_length (sym);
--- 1712,1719 
  
if (sym->attr.associate_var
  && sym->ts.u.cl->backend_decl
! && (VAR_P (sym->ts.u.cl->backend_decl)
! || TREE_CODE (sym->ts.u.cl->backend_decl) == PARM_DECL))
length = gfc_index_zero_node;
else
length = gfc_create_string_length (sym);
Index: gcc/testsuite/gfortran.dg/associate_36.f90
===
*** gcc/testsuite/gfortran.dg/associate_36.f90  (nonexistent)
--- gcc/testsuite/gfortran.dg/associate_36.f90  (working copy)
***
*** 0 
--- 1,28 
+ ! { dg-do run }
+ !
+ ! Test the fix for PR83344.
+ !
+ ! Contributed by 
+ !
+ program foo
+implicit none
+character(len=1) a
+character(len=2) b
+character(len=3) c
+a = 'a'
+call bah(a, len (a))
+b = 'bb'
+call bah(b, len (b))
+c = 'ccc'
+call bah(c, len (c))
+contains
+   subroutine bah(x, clen)
+  implicit none
+  integer :: clen
+  character(len=*), intent(in) :: x
+  associate(y => x)
+ if (len(y) .ne. clen) stop 1
+ if (y .ne. x) stop 2
+  end associate
+   end subroutine bah
+ end program foo

New Spanish PO file for 'gcc' (version 8.1-b20180128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators.  The file is available at:

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

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

All other PO files for your package are available in:

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

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Re: [PATCH] Respect TMPDIR value in contrib scripts

[Jeff Law]

On 02/18/2018 11:25 AM, Yury Gribov wrote:
> Hi all,
> 
> This uses ${TMPDIR:-/tmp} instead of /tmp in scripts in contrib folder.
> 
> Ok for trunk?
> 
> -Y
> 
OK.
jeff

Re: [PATCHv2][PR 81376] Remove unnecessary float casts in comparisons

[Jeff Law]

On 02/18/2018 11:52 AM, Yuri Gribov wrote:
> Hi all,
> 
> This is a second iteration of patch which gets rid of float casts in
> comparisons when all values of casted integral type are exactly
> representable by the float type
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81376). The new version
> addresses Richard's review
> (https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00481.html).
> 
> Bootstrapped and regtested on x64_64. Ok to commit?
This should defer into the next stage1 IMHO.
jeff

[patch, committed] PR84389

[Jerry DeLisle]

Committed the following as obvious and simple to trunk with new test case.

Author: jvdelisle
Date: Sun Feb 18 19:19:47 2018
New Revision: 257795

URL: https://gcc.gnu.org/viewcvs?rev=257795=gcc=rev
Log:
2018-02-18  Jerry DeLisle  

PR fortran/84389
* io.c (check_format): Allow FMT_COLON.

* gfortran.dg/dtio_33.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_33.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog

The patch:


diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index 9b7c2de16f4..d9f0fb1d4ac 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -985,6 +985,9 @@ data_desc:
case FMT_COMMA:
  goto format_item;

+   case FMT_COLON:
+ goto format_item_1;
+
case FMT_LPAREN:

   dtio_vlist:

[PATCHv2][PR 81376] Remove unnecessary float casts in comparisons

[Yuri Gribov]

Hi all,

This is a second iteration of patch which gets rid of float casts in
comparisons when all values of casted integral type are exactly
representable by the float type
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81376). The new version
addresses Richard's review
(https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00481.html).

Bootstrapped and regtested on x64_64. Ok to commit?

-Y


pr81376-2.patch
Description: Binary data

[PATCH] Respect TMPDIR value in contrib scripts

[Yury Gribov]

Hi all,

This uses ${TMPDIR:-/tmp} instead of /tmp in scripts in contrib folder.

Ok for trunk?

-Y


Respect-TMPDIR-1.patch
Description: Binary data

Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier

[Andre Vehreschild]

Well, after discussing on IRC whether RM should be bothered, I was asked to
simplify release managers lives and propose, that if no one objects within one
day, I will merge the patch. So any objections?

- Andre

On Sun, 18 Feb 2018 18:07:28 +0100
Andre Vehreschild  wrote:

> Dear release managers,
> 
> this patch (for reference
> https://gcc.gnu.org/ml/fortran/2018-02/msg00124.html) fixes a regression in
> the coarray api by extending three relatively new functions with one or two
> arguments, respectively. The patch has been approved by gfortran devs. Asking
> your approval to merge it: Ok to merge to trunk?
> 
> Regards,
>   Andre
> 
> On Sun, 18 Feb 2018 08:53:41 -0800
> Jerry DeLisle  wrote:
> 
> > On 02/18/2018 07:39 AM, Andre Vehreschild wrote:  
> > > Hi all,
> > > 
> > > attached patch fixes an issue with the coarray API. When a component of a
> > > derived type coarray was referenced using a caf_*_by_ref () function and
> > > that component was not an array with a descriptor, then the type of the
> > > component was not known. Which additionally meant, that type conversion
> > > was not applied as required. This patch fixes that issue by adding type
> > > specifiers to the three caf_*_by_ref-calls and implements the
> > > functionality for libcaf_single. This is harmless because other coarray
> > > libraries that do not expect this argument just ignore it.
> > > Additionally does this patch also provide the first working version of
> > > caf_sendget_by_ref in libcaf_single, which previously only lead to a stack
> > > corruption and was not usable since the array descriptor rework (nice job,
> > > btw).
> > > 
> > > I would like to have this patch in trunk knowing that I am somewhat late,
> > > but it would be quite necessary, because as it is now, the coarray feature
> > > for derived types is hardly usable. Furthermore do some people name this a
> > > regression, because the caf_*_by_ref are also used when the lhs of a
> > > caf_get_by_ref() is allocatable which now does not work as expected
> > > anymore but before gcc-6 using caf_get() (w/o reallocation) did.
> > > 
> > > Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk?
> > > 
> > > - Andre
> > > 
> > 
> > This is OK from the Fortranners perspective. Should touch base with 
> > release manager.  It looks harmless though it changes coarray API, which 
> > is hidden behind -fcoarray=
> > 
> > Regards,
> > 
> > Jerry  
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier

[Andre Vehreschild]

Dear release managers,

this patch (for reference https://gcc.gnu.org/ml/fortran/2018-02/msg00124.html)
fixes a regression in the coarray api by extending three relatively new
functions with one or two arguments, respectively. The patch has been approved
by gfortran devs. Asking your approval to merge it: Ok to merge to trunk?

Regards,
Andre

On Sun, 18 Feb 2018 08:53:41 -0800
Jerry DeLisle  wrote:

> On 02/18/2018 07:39 AM, Andre Vehreschild wrote:
> > Hi all,
> > 
> > attached patch fixes an issue with the coarray API. When a component of a
> > derived type coarray was referenced using a caf_*_by_ref () function and
> > that component was not an array with a descriptor, then the type of the
> > component was not known. Which additionally meant, that type conversion was
> > not applied as required. This patch fixes that issue by adding type
> > specifiers to the three caf_*_by_ref-calls and implements the functionality
> > for libcaf_single. This is harmless because other coarray libraries that do
> > not expect this argument just ignore it.
> > Additionally does this patch also provide the first working version of
> > caf_sendget_by_ref in libcaf_single, which previously only lead to a stack
> > corruption and was not usable since the array descriptor rework (nice job,
> > btw).
> > 
> > I would like to have this patch in trunk knowing that I am somewhat late,
> > but it would be quite necessary, because as it is now, the coarray feature
> > for derived types is hardly usable. Furthermore do some people name this a
> > regression, because the caf_*_by_ref are also used when the lhs of a
> > caf_get_by_ref() is allocatable which now does not work as expected anymore
> > but before gcc-6 using caf_get() (w/o reallocation) did.
> > 
> > Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk?
> > 
> > - Andre
> >   
> 
> This is OK from the Fortranners perspective. Should touch base with 
> release manager.  It looks harmless though it changes coarray API, which 
> is hidden behind -fcoarray=
> 
> Regards,
> 
> Jerry


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Re: [Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier

[Jerry DeLisle]

On 02/18/2018 07:39 AM, Andre Vehreschild wrote:

Hi all,

attached patch fixes an issue with the coarray API. When a component of a
derived type coarray was referenced using a caf_*_by_ref () function and that
component was not an array with a descriptor, then the type of the component was
not known. Which additionally meant, that type conversion was not applied as
required. This patch fixes that issue by adding type specifiers to the three
caf_*_by_ref-calls and implements the functionality for libcaf_single. This is
harmless because other coarray libraries that do not expect this argument just
ignore it.
Additionally does this patch also provide the first working version of
caf_sendget_by_ref in libcaf_single, which previously only lead to a stack
corruption and was not usable since the array descriptor rework (nice job, btw).

I would like to have this patch in trunk knowing that I am somewhat late, but
it would be quite necessary, because as it is now, the coarray feature for
derived types is hardly usable. Furthermore do some people name this a
regression, because the caf_*_by_ref are also used when the lhs of a
caf_get_by_ref() is allocatable which now does not work as expected anymore but
before gcc-6 using caf_get() (w/o reallocation) did.

Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk?

- Andre



This is OK from the Fortranners perspective. Should touch base with 
release manager.  It looks harmless though it changes coarray API, which 
is hidden behind -fcoarray=


Regards,

Jerry

[patch, fortran] Remove workaround introduced because of PR80945

[Thomas Koenig]

Hello world,

after Paul's fix for PR80945, the code in frontend-passes.c meant
to circumvent this bug is no longer needed. The attached patch
removes it, adding a test case which shows that the optimization
is working.

After this, I think we can finally lay PR 35339 to rest.

Regression-tested. OK for trunk?

Regards

Thomas

2018-02-18  Thomas Koenig  

PR fortran/35339
* frontend-passes.c (traverse_io_block): Remove workaround for
PR 80945.

2018-02-18  Thomas Koenig  

PR fortran/35339
* gfortran.dg/implied_do_io_4.f90: New test.
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 257788)
+++ frontend-passes.c	(Arbeitskopie)
@@ -1162,14 +1162,7 @@ traverse_io_block (gfc_code *code, bool *has_reach
 
   gcc_assert (curr->op == EXEC_TRANSFER);
 
-  /* FIXME: Workaround for PR 80945 - array slices with deferred character
- lenghts do not work.  Remove this section when the PR is fixed.  */
   e = curr->expr1;
-  if (e->expr_type == EXPR_VARIABLE && e->ts.type == BT_CHARACTER
-  && e->ts.deferred)
-return false;
-  /* End of section to be removed.  */
-
   ref = e->ref;
   if (!ref || ref->type != REF_ARRAY || ref->u.ar.codimen != 0 || ref->next)
 return false;
! { dg-do  run }
! { dg-additional-options "-ffrontend-optimize -fdump-tree-original" }
! PR fortran/35339  - make sure that I/O of an implied DO loop
! of allocatable character arrays a) works and b) is converted
! to a transfer_array
program main
implicit none
integer:: i
integer, parameter:: N = 10
character(len=:), dimension(:),allocatable:: ca
allocate(character(len=N):: ca(3))
open(unit=10,status="scratch")
ca(1) = "foo"
ca(2) = "bar"
ca(3) = "xyzzy"
write (10, '(3A10)') (ca(i),i=1,3)
rewind (10)
ca(:) = ''
read (10, '(3A10)') (ca(i),i=1,3)
if (ca(1) /= 'foo' .or. ca(2) /= 'bar' .or. ca(3) /= 'xyzzy') call abort
end program
! { dg-final { scan-tree-dump-times "_gfortran_transfer_array" 2 "original" } }

Re: [Patch, fortran] PR83344 - Use of uninitialized memory with ASSOCIATE and strings

[Janne Blomqvist]

On Sun, Feb 18, 2018 at 5:48 PM, Paul Richard Thomas
 wrote:
> Bootstraps and regtests on FC27/x86_64 - OK for trunk?

Hi,

thanks for looking into this!

1. The patch itself is missing...

2. Could you uncomment the commented out part of associate_22.f90 and
check that the tree-original dump is sensible.

3. Same for the testcases posted to PR 83975. I suspect (err, hope)
that this patch would fix those as well. If so, please add that PR to
the ChangeLog entries as well.

>
> Paul
>
> 2018-02-18  Paul Thomas  
>
> PR fortran/83344
> * resolve.c (resolve_assoc_var): Character associate names that
> have no length expression that have variable targets and are
> not deferred length have assumed length.
> * trans-decl.c (gfc_get_symbol_decl): Set 'length' to
> gfc_index_zero_node for character associate names, whose string
> length is a PARM_DECL.
>
> 2018-02-18  Paul Thomas  
>
> PR fortran/83344
> * gfortran.dg/associate_36.f90: New test.



-- 
Janne Blomqvist

[Patch, fortran] PR83344 - Use of uninitialized memory with ASSOCIATE and strings

[Paul Richard Thomas]

Bootstraps and regtests on FC27/x86_64 - OK for trunk?

Paul

2018-02-18  Paul Thomas  

PR fortran/83344
* resolve.c (resolve_assoc_var): Character associate names that
have no length expression that have variable targets and are
not deferred length have assumed length.
* trans-decl.c (gfc_get_symbol_decl): Set 'length' to
gfc_index_zero_node for character associate names, whose string
length is a PARM_DECL.

2018-02-18  Paul Thomas  

PR fortran/83344
* gfortran.dg/associate_36.f90: New test.

[Fortran, PATCH, coarray, v1] Extend caf_*_by_ref () API by a type specifier

[Andre Vehreschild]

Hi all,

attached patch fixes an issue with the coarray API. When a component of a
derived type coarray was referenced using a caf_*_by_ref () function and that
component was not an array with a descriptor, then the type of the component was
not known. Which additionally meant, that type conversion was not applied as
required. This patch fixes that issue by adding type specifiers to the three
caf_*_by_ref-calls and implements the functionality for libcaf_single. This is
harmless because other coarray libraries that do not expect this argument just
ignore it.
Additionally does this patch also provide the first working version of
caf_sendget_by_ref in libcaf_single, which previously only lead to a stack
corruption and was not usable since the array descriptor rework (nice job, btw).

I would like to have this patch in trunk knowing that I am somewhat late, but
it would be quite necessary, because as it is now, the coarray feature for
derived types is hardly usable. Furthermore do some people name this a
regression, because the caf_*_by_ref are also used when the lhs of a
caf_get_by_ref() is allocatable which now does not work as expected anymore but
before gcc-6 using caf_get() (w/o reallocation) did.

Bootstrapped and regtested ok on x86_64-linux/f27. Ok for trunk?

- Andre
-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
gcc/fortran/ChangeLog:

2018-02-18  Andre Vehreschild  

* gfortran.texi: Document additional src/dst_type.  Fix some typos.
* trans-decl.c (gfc_build_builtin_function_decls): Declare the new
argument of _caf_*_by_ref () with * e { get, send, sendget }.
* trans-intrinsic.c (gfc_conv_intrinsic_caf_get): Add the type of the
data referenced when generating a call to caf_get_by_ref ().
(conv_caf_send): Same but for caf_send_by_ref () and
caf_sendget_by_ref ().

gcc/testsuite/ChangeLog:

2018-02-18  Andre Vehreschild  

* gfortran.dg/coarray_alloc_comp_6.f08: New test.
* gfortran.dg/coarray_alloc_comp_7.f08: New test.
* gfortran.dg/coarray_alloc_comp_8.f08: New test.

libgfortran/ChangeLog:

2018-02-18  Andre Vehreschild  

* caf/libcaf.h: Add type parameters to the caf_*_by_ref prototypes.
* caf/single.c (get_for_ref): Simplifications and now respecting
the type argument.
(_gfortran_caf_get_by_ref): Added source type handing to get_for_ref().
(send_by_ref): Simplifications and respecting the dst_type now.
(_gfortran_caf_send_by_ref): Added destination type hand over to
send_by_ref().
(_gfortran_caf_sendget_by_ref): Added general support and fixed stack
corruption.  The function is now really usable.

diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 9ffe6ade661..db48a713661 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -4750,7 +4750,7 @@ remote image identified by the @var{image_index}.
 @item @emph{Syntax}:
 @code{void _gfortran_caf_send_by_ref (caf_token_t token, int image_index,
 gfc_descriptor_t *src, caf_reference_t *refs, int dst_kind, int src_kind,
-bool may_require_tmp, bool dst_reallocatable, int *stat)}
+bool may_require_tmp, bool dst_reallocatable, int *stat, int dst_type)}
 
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
@@ -4774,6 +4774,9 @@ is a full array or component ref.
 @item @var{stat} @tab intent(out) When non-@code{NULL} give the result of the
 operation, i.e., zero on success and non-zero on error.  When @code{NULL} and
 an error occurs, then an error message is printed and the program is terminated.
+@item @var{dst_type} @tab intent(in)  Give the type of the destination.  When
+the destination is not an array, than the precise type, e.g. of a component in
+a derived type, is not known, but provided here.
 @end multitable
 
 @item @emph{NOTES}
@@ -4808,7 +4811,7 @@ identified by the @var{image_index}.
 @item @emph{Syntax}:
 @code{void _gfortran_caf_get_by_ref (caf_token_t token, int image_index,
 caf_reference_t *refs, gfc_descriptor_t *dst, int dst_kind, int src_kind,
-bool may_require_tmp, bool dst_reallocatable, int *stat)}
+bool may_require_tmp, bool dst_reallocatable, int *stat, int src_type)}
 
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
@@ -4833,6 +4836,9 @@ array or a component is referenced.
 @item @var{stat} @tab intent(out) When non-@code{NULL} give the result of the
 operation, i.e., zero on success and non-zero on error.  When @code{NULL} and an
 error occurs, then an error message is printed and the program is terminated.
+@item @var{src_type} @tab intent(in)  Give the type of the source.  When the
+source is not an array, than the precise type, e.g. of a component in a
+derived type, is not known, but provided here.
 @end multitable
 
 @item @emph{NOTES}
@@ -4868,7 +4874,8 @@ identified by the @var{src_image_index} to a remote image identified by the
 @code{void 

Re: [ patch, testsuite, fortran] Replace "call abort" by "stop n"

[Janus Weil]

2018-02-18 1:38 GMT+01:00 Thomas Koenig :
> Hi Janus,
>
>> Regarding "-fall-intrinsics": Your commit has greatly reduced its
>> usage, but I still see a few cases that you left in, although the flag
>> does not really seem to be required.
>>
>> Is there a reason why did not treat these?
>
> I was specifically chaning those cases which contained STOP [1-9]
> after my patch; I didn't look at any other use of -fall-intrinsics.
>
>> Would you mind if I applied
>> the patch in attachment?
>
>
> Not at all - if the test cases pass without the option, just go ahead
> and commit the patch.

Alrighty, committed as r257789 (after making sure there are no failures).

Cheers,
Janus

New Swedish PO file for 'gcc' (version 8.1-b20180128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

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

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

All other PO files for your package are available in:

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

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

[Patch, fortran] PR80945 - Invalid code with allocatable character array in READ/WRITE statement

[Paul Richard Thomas]

Committed as 'obvious' - revision 257788.

This patch works fine on 7-branch. I will commit it there in a day or
two unless there is any objection.

Cheers

Paul

2018-02-18  Paul Thomas  

PR fortran/80945
* trans-array.c (gfc_conv_expr_descriptor): Set parmtype from
the typenode in the case of deferred length characters.

2018-02-18  Paul Thomas  

PR fortran/80945
* gfortran.dg/associate_35.f90: Remove error, add stop n's and
change to run.