[Bug middle-end/90514] Issue about enum type in gcc tree

2019-05-19 Thread JunMa at linux dot alibaba.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90514

--- Comment #4 from JunMa  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to JunMa from comment #2) 
> > I had got confused by the comments in vrp pass. the condition
> >   if ((kind != ENUM1) && (kind != ENUM2))
> > is not always false, and cannot be folded to if (0). 
> > Also the code deals with pr23046 is out of data, and should be removed.
> 
> That was C++ code rather than C code and C++ which has different rules than
> C (at least with -fstrict-enums).  The code is not out of date for gimple
> types.  Since the types in Gimple can have more well defined behaviors which
> are not exposed via C or C++ front-ends.  NOTE there could be an Ada code
> which hits the same failure (I don't know Ada that well but I do know the
> Ada front-end supports more features of the GCC middle-end than either of
> the C or C++ front-ends).

Since gimple folding has changed so much, we can easily support folding it in
match.pd rather than checking this in here.

[Bug fortran/90536] Use of -fno-range-check creates warnings or errors when assigning to a byte variable

2019-05-19 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536

Thomas Koenig  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|WONTFIX |---
   Severity|normal  |enhancement

--- Comment #7 from Thomas Koenig  ---
Hi Steve,

the same thing also happens if the variables are declared as integer(kind=1),
as I
found yesterday, also on assignment to a default kind integer constant.

I do not think it is intended that -Wconversion should warn for that.

[Bug middle-end/90514] Issue about enum type in gcc tree

2019-05-19 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90514

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Andrew Pinski  ---
(In reply to JunMa from comment #2) 
> I had got confused by the comments in vrp pass. the condition
>   if ((kind != ENUM1) && (kind != ENUM2))
> is not always false, and cannot be folded to if (0). 
> Also the code deals with pr23046 is out of data, and should be removed.

That was C++ code rather than C code and C++ which has different rules than C
(at least with -fstrict-enums).  The code is not out of date for gimple types. 
Since the types in Gimple can have more well defined behaviors which are not
exposed via C or C++ front-ends.  NOTE there could be an Ada code which hits
the same failure (I don't know Ada that well but I do know the Ada front-end
supports more features of the GCC middle-end than either of the C or C++
front-ends).

[Bug c++/90538] New: Redeclaration error when expanding parameter pack multiple times in a lambda

2019-05-19 Thread wtt6 at cornell dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90538

Bug ID: 90538
   Summary: Redeclaration error when expanding parameter pack
multiple times in a lambda
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wtt6 at cornell dot edu
  Target Milestone: ---

With gcc-9.1.0, compiling this code
---
template 
void a(const T&...) {}

template 
void b(const T&... t) {
  [&]() {
a(t...);
a(t...);
  };
}

void c() {
  b(1);
}
---
gives errors
---
test.cpp: In instantiation of ‘void b(const T& ...) [with T = {int}]’:
test.cpp:13:6:   required from here
test.cpp:8:7: error: redeclaration of ‘const int& t#0’
8 | a(t...);
  |   ^
test.cpp:7:7: note: ‘const int& t#0’ previously declared here
7 | a(t...);
  |   ^
test.cpp:6:3: error: member ‘b(const T& ...) [with T = {int}]’ is uninitialized reference
6 |   [&]() {
  |   ^~~
7 | a(t...);
  | 
8 | a(t...);
  | 
9 |   };
  |   ~
test.cpp:6:3: error: designator order for field ‘b(const T& ...) [with T =
{int}]’ does not match declaration order in ‘b(const
T& ...) [with T = {int}]::’
---

This was accepted by gcc 8.3.

[Bug fortran/90536] Use of -fno-range-check creates warnings or errors when assigning to a byte variable

2019-05-19 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #6 from kargl at gcc dot gnu.org ---
This code is so far from valid Fortran that it will not be fixed.

1) BYTE is not a standard type.
2) BYTE is not a replacement for DATA, so initialization
   in the BYTE statement is dubious.  gfortran is interpreting 
   a BOZ as-if it is in a data statement.  Fortran 95 requires
   a conversion of a BOZ to INTEGER(16) on your system.
3) The 'X' on '89'X is not standard conforming.
4) The postfix position of 'X' is not standard conforming.

I have plans to deprecate the 'X' extension, postfix position
of BOZ indicators, and the BYTE type in gfortran 10, and their
removal in 11.

[Bug c++/69316] Implement CWG 393

2019-05-19 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69316

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Marek Polacek  ---
This was fixed in GCC 8 by r250137.  In C++17, the code is accepted without
warnings even with -Wpedantic.

[Bug c++/86476] Members declared later in a class appear to be unavailable

2019-05-19 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86476

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Marek Polacek  ---
Patch available: .

[Bug c++/90537] Implement P1286R2, Contra CWG DR1778

2019-05-19 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90537

Marek Polacek  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-20
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Mine.

[Bug c++/90537] New: Implement P1286R2, Contra CWG DR1778

2019-05-19 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90537

Bug ID: 90537
   Summary: Implement P1286R2, Contra CWG DR1778
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

(NB: This assumes that my
 has gone in.)

Implement .  This should compile now:

struct X { X(); };

struct A {
  struct B {
B() noexcept(A::value) = default;
X x;
  };
  decltype(B()) b;
  static constexpr bool value = true;
};
A::B b;

static_assert(noexcept(A::B()), "");

but we print

p1286.C:11:6: error: use of deleted function ‘A::B::B()’
   11 | A::B b;
  |  ^
p1286.C:5:5: note: ‘A::B::B() noexcept’ is implicitly deleted because its
exception-specification does not match the implicit exception-specification ‘’
5 | B() noexcept(A::value) = default;
  | ^
p1286.C:13:29: error: use of deleted function ‘A::B::B()’
   13 | static_assert(noexcept(A::B()), "");
  | ^

Latest clang/EDG compile it fine.

[Bug fortran/90536] Use of -fno-range-check creates warnings or errors when assigning to a byte variable

2019-05-19 Thread j.ravens.nz at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536

--- Comment #5 from Jonathan Ravens  ---
(In reply to Dominique d'Humieres from comment #3)
> To make the story short: compile your code with -Wno-conversion as a work
> around.
> 
> This is needed starting with at least 4.6.0 revision r161462 (2010-06-27),
> but not needed with 4.5.4 or earlier.
> 
> Note that BYTE and '89'X are GNU extensions and not standard conforming.
> 
> IMO this PR is INVALID.

Hi Dominique, I agree that 'BYTE and '89'X' are not standard conforming, and
it's true that using -Wno-conversion does effect a workaround.  However BYTE
and '01'X (for example) should not raise a warning, so I think that part of my
report is valid.

Simpler code to illustrate this :

program test
byte b1 / '01'X /
b1 = 2
end

> gfortran -c -Wall -fno-range-check gfortran_bug_2.f
gfortran_bug_2.f:2.23:

byte b1 / '01'X /   
   1
Warning: Possible change of value in conversion from INTEGER(16) to INTEGER(1)
at (1)
gfortran_bug_2.f:3.13:

b1 = 2  
 1
Warning: Possible change of value in conversion from INTEGER(4) to INTEGER(1)
at (1)

[Bug fortran/90536] Use of -fno-range-check creates warnings or errors when assigning to a byte variable

2019-05-19 Thread j.ravens.nz at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536

--- Comment #4 from Jonathan Ravens  ---
(In reply to Thomas Koenig from comment #2)
> Hm, another question: Which gfortran version do you use?
> If your version is _really_ old, it might not yet have
> the -Wno-conversion flag.

"gfortran -v" gives "gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)" and
it does support -Wno-conversion, so that's a workaround for now, thankyou. 

I take Dominuque's point that initialising a byte to something greater than 127
is not OK, but the warnings for setting a  byte value to (eg) 6 are not right,
as you pointed out.  Thanks.

[Bug c++/85679] [DR2094] __is_trivially_copyable returns false with volatile scalar type

2019-05-19 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85679

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Marek Polacek  ---
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01173.html

[Bug target/90522] unrecognizable insn (V8SF)

2019-05-19 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90522

--- Comment #2 from Uroš Bizjak  ---
The testcase compiles without problems for me with:

gcc (GCC) 10.0.0 20190519 (experimental) [trunk revision 271384]

[Bug fortran/90536] Use of -fno-range-check creates warnings or errors when assigning to a byte variable

2019-05-19 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536

--- Comment #3 from Dominique d'Humieres  ---
To make the story short: compile your code with -Wno-conversion as a work
around.

This is needed starting with at least 4.6.0 revision r161462 (2010-06-27), but
not needed with 4.5.4 or earlier.

Note that BYTE and '89'X are GNU extensions and not standard conforming.

IMO this PR is INVALID.

[Bug fortran/90536] Use of -fno-range-check creates warnings or errors when assigning to a byte variable

2019-05-19 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536

--- Comment #2 from Thomas Koenig  ---
Hm, another question: Which gfortran version do you use?
If your version is _really_ old, it might not yet have
the -Wno-conversion flag.

[Bug target/90453] PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64

2019-05-19 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90453

--- Comment #7 from Segher Boessenkool  ---
Note that vec_pack works for unsigned as well.

For vec_unpack[hl] of unsigned you can do a vec_merge[hl] instead (with the
first arg a zero vector).

[Bug fortran/90536] Use of -fno-range-check creates warnings or errors when assigning to a byte variable

2019-05-19 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-19
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
With your test case, I get

$ gfortran a.f90
a.f90:32:24:

   32 | byte b2 /  '89'X/
  |1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option '-fno-range-check'
$ gfortran a.f90
a.f90:32:24:

   32 | byte b2 /  '89'X/
  |1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option '-fno-range-check'
$ gfortran -fno-range-check a.f90
$ gfortran -Wall -fno-range-check a.f90
a.f90:32:24:

   32 | byte b2 /  '89'X/
  |1
Warning: Conversion from 'INTEGER(16)' to 'INTEGER(1)' at (1) [-Wconversion]
a.f90:34:13:

   34 | b1 = 6
  | 1
Warning: Conversion from 'INTEGER(4)' to 'INTEGER(1)' at (1) [-Wconversion]
a.f90:35:13:

   35 | b2 = 7
  | 1
Warning: Conversion from 'INTEGER(4)' to 'INTEGER(1)' at (1) [-Wconversion]
$ gfortran -Wall -Wno-conversion -fno-range-check a.f90
$ 

so the compiler tells you which option causes the warning. Following
general gcc conventions, -Wno-conversion can turn this warning off.

Having said that, the fact that "b1 = 6" triggers a warning when
-fno-range-check is in effect is certainly unintentional.

Let's see.

[Bug tree-optimization/90447] Missed opportunities to use adc (worse when -1 is involved)

2019-05-19 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90447

--- Comment #2 from Marc Glisse  ---
Looking at f3, in combine, for -2, we manage to match

   (plus:SI (plus:SI (ltu:SI (reg:CCC 17 flags)
   (const_int 0 [0]))
   (reg:SI 91))
   (const_int -2 [0xfffe])))

while for -1 we fail to match

   (minus:SI (reg:SI 91)
   (geu:SI (reg:CCC 17 flags)
   (const_int 0 [0]

That is, simplify-rtx replaced x+(a<0)+-1 with x-(a>=0), and there is no such
transformation for values other than -1. This last form does not match the
usual pattern anymore. I guess the easiest would be to add a specific pattern
(yet another one) just for this case...

[Bug fortran/90536] New: Use of -fno-range-check creates warnings or errors when assigning to a byte variable

2019-05-19 Thread j.ravens.nz at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536

Bug ID: 90536
   Summary: Use of -fno-range-check creates warnings or errors
when assigning to a byte variable
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: j.ravens.nz at gmail dot com
  Target Milestone: ---

Created attachment 46382
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46382=edit
6-line fortran source giving warnings/errors when assining to a byte variable

Essentially any assignment to a byte variable gives a warning or an error.  The
errors are fatal, and the warnings are too numerous to ignore (I'm getting one
warning for each byte that is initialised in a DATA statement, so that can be
many thousands of warnings).  We have used code like this since 1982 without
any problems until the Ubuntu18.04 release.

When gfortran is used to compile a simple Fortran source with the
-fno-range-check option, any byte assignment in code or data statement will
give a warning, eg :

> gfortran -Wall -fno-range-check -c gfortran_bug_report.f
gfortran_bug_report.f:33.24:

byte b2 /  '89'X/
1
Warning: Possible change of value in conversion from INTEGER(16) to INTEGER(1)
at (1)

This only happens with 'gfortran -c -Wall -fno-range-check' (but when using
gfortran via mpif90, -Wall is turned on, so we can't suppress those warnings,
and there are thousands of them).

However, without  -fno-range-check, we get other, fatal, errors, so that's even
worse :

gfortran -Wall -c gfortran_bug_report.f
gfortran_bug_report.f:33.24:

byte b2 /  '89'X/
1
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This
check can be disabled with the option -fno-range-check

[Bug c/90535] Wrong branch selected if (--(s.ptr))

2019-05-19 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90535

--- Comment #2 from Andrew Pinski  ---
-fno-delete-null-pointer-checks is the correct option.

https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Optimize-Options.html#index-fdelete-null-pointer-checks

[Bug c/90535] Wrong branch selected if (--(s.ptr))

2019-05-19 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90535

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
You cant go from a normal pointer to a null pointer in well defined C code. 
Gcc has -fno-delete-null-checks (I might have typed it wrong as I am writing
this from my phone).

[Bug c++/90534] ICE in consteval in GCCs 8.3, 8.2, 8.1, 7.3, 7.2 and 7.1

2019-05-19 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90534

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-19
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
This was fixed by r266816 aka c++/85569.

[Bug c/90535] New: Wrong branch selected if (--(s.ptr))

2019-05-19 Thread vbraun.name at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90535

Bug ID: 90535
   Summary: Wrong branch selected if (--(s.ptr))
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vbraun.name at gmail dot com
  Target Milestone: ---

Decrementing a struct member pointer is not seen in a subsequent if() branch,
so tests like 

if (--(s.ptr)) 

jump to the wrong branch. This is with gcc 9.1.1 and -O1 or higher, -O0 works
correctly. The following is a simplified testcase that was extracted from a
real-world reference counting implementation:

===
#include "stdio.h"

struct MyStruct {
void *ptr;
};


int main() {
struct MyStruct s;
s.ptr = NULL + 1;

// The bug only happens if we have a pointer to s, even though we don't
really use it
struct MyStruct *struct_ptr =  
printf("MyStruct *struct_ptr = %p\n", struct_ptr);// need to use it
once

printf(" ptr = 0x1 \n");
printf("ptr is 0x1: %p\n", s.ptr);
if (s.ptr) {
printf("ptr is truthy (correct!) %p\n", s.ptr);
}

printf(" ptr = NULL \n");
(s.ptr)--; // We should be back to 0x0 now
// Uncomenting the following line makes the bug disappear
// printf("ptr is null: %p\n", s.ptr);
if (!(s.ptr)) {
printf("ptr is falsy (correct!) %p\n", s.ptr);
}
if (s.ptr) {
printf("ptr is truthy (wrong!) %p\n", s.ptr);
}
return 0;
}

===

$ gcc -O1 test_char_ptr.c  && ./a.out 
MyStruct *struct_ptr = 0x7ffd0b049758
 ptr = 0x1 
ptr is 0x1: 0x1
ptr is truthy (correct!) 0x1
 ptr = NULL 
ptr is truthy (wrong!) (nil)

$ gcc --version
gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug libfortran/90038] execute_command_line should not use fork()

2019-05-19 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038

Janne Blomqvist  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Janne Blomqvist  ---
Fixed on trunk, closing.

[Bug rtl-optimization/43147] SSE shuffle merge

2019-05-19 Thread linux at carewolf dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147

Allan Jensen  changed:

   What|Removed |Added

 CC||linux at carewolf dot com

--- Comment #9 from Allan Jensen  ---
(In reply to Marc Glisse from comment #6)
> Created attachment 45303 [details]
> example patch (untested)
> 
> Making the meaning of shuffles visible in GIMPLE could help a bit (although
> it wouldn't solve the problem completely because IIRC we don't dare combine
> shuffles, since it is hard to find an optimal expansion for a shuffle and we
> might pessimize some cases).

With some other cases there are checks to see if a combined new tree can be
generated as a single instruction and only combined in that case. And as soon
as the compiler have SSSE3 available, we can shuffle anything as single
instruction, so combining them is always safe and fast.

[Bug c++/90534] New: ICE in consteval in GCCs 8.3, 8.2, 8.1, 7.3, 7.2 and 7.1

2019-05-19 Thread s_gccbugzilla at nedprod dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90534

Bug ID: 90534
   Summary: ICE in consteval in GCCs 8.3, 8.2, 8.1, 7.3, 7.2 and
7.1
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s_gccbugzilla at nedprod dot com
  Target Milestone: ---

8.3: https://wandbox.org/permlink/2pmM3pg8Fygh5Gi5

8.2: https://wandbox.org/permlink/RIobfNd409w0uQRT

8.1: https://wandbox.org/permlink/jVz65UsIz0jLCKKQ

7.3: https://wandbox.org/permlink/GwlNwWCsKSWdWsGF

7.2: https://wandbox.org/permlink/attxpIAIXr7JO2Zl

7.1: https://wandbox.org/permlink/1I1dWqqhMHjRQOtc

GCCs 6.3, 9.1, and 10.0 trunk all work fine.

[Bug libfortran/90038] execute_command_line should not use fork()

2019-05-19 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90038

--- Comment #9 from Janne Blomqvist  ---
Author: jb
Date: Sun May 19 19:38:11 2019
New Revision: 271384

URL: https://gcc.gnu.org/viewcvs?rev=271384=gcc=rev
Log:
libfortran/90038 Reap dead children when wait=.false.

When using posix_spawn or fork to launch a child process, the parent
needs to wait for the child, otherwise the dead child is left as a
zombie process. For this purpose one can install a signal handler for
SIGCHLD.

2019-05-19  Janne Blomqvist  

PR libfortran/90038
* intrinsics/execute_command_line (sigchld_handler): New function.
(execute_command_line): Install handler for SIGCHLD.
* configure.ac: Check for presence of sigaction and waitpid.
* config.h.in: Regenerated.
* configure: Regenerated.

Regtested on x86_64-pc-linux-gnu.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/config.h.in
trunk/libgfortran/configure
trunk/libgfortran/configure.ac
trunk/libgfortran/intrinsics/execute_command_line.c

[Bug middle-end/90530] [9,10 Regression] Invalid SUBREG insn generated by reload

2019-05-19 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530

John David Anglin  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
Summary|[10 Regression] Invalid |[9,10 Regression] Invalid
   |SUBREG insn generated by|SUBREG insn generated by
   |reload  |reload

--- Comment #5 from John David Anglin  ---
Problematic change was back ported to gcc-9.

I'm testing a change to reject SUBREG operands in the mult patterns.
They require operands be loaded in floating-point registers.  However,
it seems to that this problem might occur in any pattern that requires
a float register in integer mode given we can't allow mode changes.
So, I'm thinking is this is just a work around.

[Bug fortran/90498] [8/9/10 Regression] ICE with select type/associate and derived type argument containing class(*)

2019-05-19 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90498

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Sun May 19 18:08:28 2019
New Revision: 271383

URL: https://gcc.gnu.org/viewcvs?rev=271383=gcc=rev
Log:
2019-05-19  Paul Thomas  

PR fortran/90498
* trans-stmt.c (trans_associate_var) Do not use the saved
descriptor if the expression is a COMPONENT_REF.

2019-05-19  Paul Thomas  

PR fortran/90498
* gfortran.dg/associate_48.f90 : New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/associate_48.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/trans-stmt.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/83118] [7/8/9/10 Regression] Bad intrinsic assignment of class(*) array component of derived type

2019-05-19 Thread paul.richard.thomas at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118

--- Comment #22 from paul.richard.thomas at gmail dot com  ---
I'll get lined up to fix this tomorrow night.

Thanks for all the testing.

Regards

Paul

On Sun, 19 May 2019 at 11:58, dominiq at lps dot ens.fr
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
>
> --- Comment #21 from Dominique d'Humieres  ---
> > Created attachment 46216 [details]
> > Patch for the remaining problems.
>
> I have the patch in my working tree without any problem.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug c++/85679] [DR2094] __is_trivially_copyable returns false with volatile scalar type

2019-05-19 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85679

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #3 from Marek Polacek  ---
trivially_copyable_p needs a small tweak.

[Bug middle-end/90530] [10 Regression] Invalid SUBREG insn generated by reload

2019-05-19 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530

--- Comment #4 from John David Anglin  ---
In ira pass, we had:

(insn 549 539 550 4 (set (reg:DI 286)
(mult:DI (zero_extend:DI (subreg:SI (reg/f:DI 522) 4))
(const_int 4294967295 [0x]))) 179 {*pa.md:5338}
 (expr_list:REG_EQUIV (mult:DI (zero_extend:DI (subreg:SI (symbol_ref:DI
("default_target_expmed") [flags 0x202]  ) 4))
(const_int 4294967295 [0x]))
(nil)))

[Bug middle-end/90530] [10 Regression] Invalid SUBREG insn generated by reload

2019-05-19 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530

--- Comment #3 from John David Anglin  ---
(insn 538 512 539 4 (set (reg:DI 1 %r1 [282])
(plus:DI (reg:DI 27 %r27)
(high:DI (symbol_ref:DI ("default_target_expmed") [flags 0x202] 
 90 {*pa.md:2634}
 (nil))
(note 539 538 3281 4 NOTE_INSN_DELETED)
(insn 3281 539 3282 4 (set (reg/f:DI 1 %r1)
(plus:DI (reg:DI 27 %r27)
(high:DI (symbol_ref/u:DI ("*L$C19") [flags 0x2] 90
{*pa.md:2634}
 (nil))
(insn 3282 3281 3284 4 (set (reg/f:DI 1 %r1)
(mem/u/c:DI (lo_sum:DI (reg/f:DI 1 %r1)
(unspec:DI [
(symbol_ref/u:DI ("*L$C19") [flags 0x2])
] UNSPEC_DLTIND14R)) [0  S8 A64])) 128 {*pa.md:4178}
 (expr_list:REG_EQUAL (symbol_ref/u:DI ("*L$C19") [flags 0x2])
(nil)))
(insn 3284 3282 3285 4 (set (reg:DI 50 %fr22)
(mem/u/c:DI (reg/f:DI 1 %r1) [0  S8 A64])) 128 {*pa.md:4178}
 (nil))
(insn 3285 3284 3286 4 (set (reg:SI 52 %fr24)
(subreg:SI (reg:DI 50 %fr22) 4)) -1
 (nil))
(insn 3286 3285 3287 4 (set (reg/f:DI 1 %r1)
(plus:DI (reg:DI 27 %r27)
(high:DI (symbol_ref/u:DI ("*L$C20") [flags 0x2] -1
 (nil))
(insn 3287 3286 3288 4 (set (reg/f:DI 1 %r1)
(mem/u/c:DI (lo_sum:DI (reg/f:DI 1 %r1)
(unspec:DI [
(symbol_ref/u:DI ("*L$C20") [flags 0x2])
] UNSPEC_DLTIND14R)) [0  S8 A64])) -1
 (expr_list:REG_EQUAL (symbol_ref/u:DI ("*L$C20") [flags 0x2])
(nil)))
(insn 3288 3287 3289 4 (set (reg/f:DI 1 %r1)
(reg/f:DI 1 %r1)) -1
 (expr_list:REG_EQUAL (symbol_ref/u:DI ("*L$C20") [flags 0x2])
(nil)))
(insn 3289 3288 549 4 (set (reg:DI 53 %fr25)
(mem/u/c:DI (reg/f:DI 1 %r1) [0  S8 A64])) -1
 (nil))
(insn 549 3289 3290 4 (set (reg:DI 51 %fr23 [286])
(mult:DI (zero_extend:DI (reg:SI 52 %fr24))
(reg:DI 53 %fr25))) 179 {*pa.md:5338}
 (expr_list:REG_EQUIV (mult:DI (zero_extend:DI (subreg:SI (symbol_ref:DI
("default_target_expmed") [flags 0x202]  ) 4))
(const_int 4294967295 [0x]))
(nil)))

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

2019-05-19 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

Iain Sandoe  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #63 from Iain Sandoe  ---
I'm reopening this because
(a) the fix applied was a work-around and it's time to fix the Darwin unwinder
hassles properly
(b) it regresses gcc.dg/torture/fp-int-convert-timode-3.c  to place libSystem()
in front of libgcc.

[Bug target/86215] Exceptions are broken on OSX when linking with -static-libgcc

2019-05-19 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86215

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Iain Sandoe  ---
fixed for 7.5.

[Bug target/80556] [8 Regression] bootstrap failure for Ada compiler

2019-05-19 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556

--- Comment #62 from Iain Sandoe  ---
Author: iains
Date: Sun May 19 16:03:17 2019
New Revision: 271381

URL: https://gcc.gnu.org/viewcvs?rev=271381=gcc=rev
Log:
darwin - fix PR86215 by backporting 80556.

The backport had been missed.

2019-01-03  Iain Sandoe  

PR target/86215
Backport from mainline
2017-09-25  Iain Sandoe  

PR target/80556
* config/i386/darwin.h (REAL_LIB_SPEC): New; put libSystem ahead
of libgcc_eh for m64.
* config/i386/darwin64.h: Likewise.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/darwin.h
branches/gcc-7-branch/gcc/config/i386/darwin64.h

[Bug target/86215] Exceptions are broken on OSX when linking with -static-libgcc

2019-05-19 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86215

--- Comment #7 from Iain Sandoe  ---
Author: iains
Date: Sun May 19 16:03:17 2019
New Revision: 271381

URL: https://gcc.gnu.org/viewcvs?rev=271381=gcc=rev
Log:
darwin - fix PR86215 by backporting 80556.

The backport had been missed.

2019-01-03  Iain Sandoe  

PR target/86215
Backport from mainline
2017-09-25  Iain Sandoe  

PR target/80556
* config/i386/darwin.h (REAL_LIB_SPEC): New; put libSystem ahead
of libgcc_eh for m64.
* config/i386/darwin64.h: Likewise.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/i386/darwin.h
branches/gcc-7-branch/gcc/config/i386/darwin64.h

[Bug fortran/54262] LOC shouldn't use copy-in/copy-out

2019-05-19 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54262

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Dominique d'Humieres  ---
> LOC is a GNU extension and it is a matter of choice to accept
> or reject it in gfortran.

No feedback, closing as INVALID.

[Bug c++/90533] New: [C++20] cannot redeclare telmplate function if it contains lambda expression in its declaration

2019-05-19 Thread kariya_mitsuru at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90533

Bug ID: 90533
   Summary: [C++20] cannot redeclare telmplate function if it
contains lambda expression in its declaration
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kariya_mitsuru at hotmail dot com
  Target Milestone: ---

The sample code below should be compiled successfully in c++20 mode but gcc
9.1.0 or above generate compilation error.

=sample code=
template  static void k(decltype([]{ return 0; }()));
template  static void k(decltype([]{ return 0; }()));
template  static void k(int) {}

int main()
{
k<0>(0);
}
===compiler output===
prog.cc: In function 'int main()':
prog.cc:7:11: error: call of overloaded 'k<0>(int)' is ambiguous
7 | k<0>(0);
  |   ^
prog.cc:1:30: note: candidate: 'void k(decltype (())) [with int N = 0;
decltype (()) = int]'
1 | template  static void k(decltype([]{ return 0; }()));
  |  ^
prog.cc:2:30: note: candidate: 'void k(decltype (())) [with int N = 0;
decltype (()) = int]'
2 | template  static void k(decltype([]{ return 0; }()));
  |  ^
prog.cc:3:30: note: candidate: 'void k(int) [with int N = 0]'
3 | template  static void k(int) {}
  |  ^
=
cf. https://wandbox.org/permlink/GRhyXXNttvOtlNxu

The 1st and 2nd declarations should not contain closure type in its signature
because an operand of the decltype contains no template parameter.
So these three declarations should be identical.

Note that the sample code above is from p0315r4 and the paper says that it is
equivalent to a following code that is compiled successfully by gcc 9.1.0 or
above.
=sample code=
struct lambda { auto operator()() const { return 0; } };
template  static void k(decltype(lambda{}()));
template  static void k(decltype(lambda{}()));
template  static void k(int) {}

int main()
{
k<0>(0);
}
===compiler output===
cf. https://wandbox.org/permlink/jUosb2rfxR58JBbx

I think the code above is bit inaccurate but a more precise version below is
also compiled successfully by gcc 9.1.0 or above.
=sample code=
struct lambda1 { auto operator()() const { return 0; } };
struct lambda2 { auto operator()() const { return 0; } };
template  static void k(decltype(lambda1{}()));
template  static void k(decltype(lambda2{}()));
template  static void k(int) {}

int main()
{
k<0>(0);
}
===compiler output===
cf. https://wandbox.org/permlink/kl8K4AHTPL5dL4rq


[links]
Wording for lambdas in unevaluated contexts
  http://wg21.link/p0315r4
C++2a Support in GCC
  https://gcc.gnu.org/projects/cxx-status.html#cxx2a

[Bug fortran/90519] ICE (segfault) on derived type which has a recursive allocatable component of the same type, and a static component of another type which has a "final" attribute

2019-05-19 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90519

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from GCC7 up to trunk (10.0). With GCC 5 or 6, I get an error

pr90519.f90:28:51:

type(t), allocatable :: content_alloc(:) ! (2)
   1
Error: Component at (1) must have the POINTER attribute

[Bug fortran/90421] Invalid memory write in allocate on assignment to a class(*) variable

2019-05-19 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90421

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-19
 Blocks||89891
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from GCC7 up to trunk (10.0). Assignment to an allocatable
polymorphic variable is not supported in earlier versions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891
[Bug 89891] [meta-bug] Accessing memory in rejected statements or expressions

[Bug fortran/90499] ICE during polymorphic assignment

2019-05-19 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90499

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from GCC7 up to trunk (10.0). Assignment to an allocatable
polymorphic variable is not supported in earlier versions.

[Bug fortran/90504] Improved NORM2 algorithm

2019-05-19 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90504

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-19
 Ever confirmed|0   |1

[Bug middle-end/90530] [10 Regression] Invalid SUBREG insn generated by reload

2019-05-19 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90530

--- Comment #2 from John David Anglin  ---
Breakpoint 1, emit_insn (x=0x83fffd0474c0) at ../../gcc/gcc/emit-rtl.c:5074
5074  rtx_insn *last = get_last_insn ();
(gdb) p debug_rtx(x)
(insn 3285 0 0 (set (reg:SI 52 %fr24)
(subreg:SI (symbol_ref:DI ("default_target_expmed") [flags 0x202]
) 4)) -1
 (nil))
$39 = void
(gdb) bt
#0  emit_insn (x=0x83fffd0474c0) at ../../gcc/gcc/emit-rtl.c:5074
#1  0x417c6e48 in emit_input_reload_insns (chain=0x83fffd0474c0,
rl=0x83fffd001de0, old=0x83fffd001d80, j=-2147482625)
at ../../gcc/gcc/reload1.c:7594
#2  0x417c84f4 in do_input_reload (chain=0x83fffd0474c0,
rl=0x83fffd001de0, j=-2147482625) at ../../gcc/gcc/reload1.c:7933
#3  0x417c952c in emit_reload_insns (chain=0x83fffd0474c0)
at ../../gcc/gcc/reload1.c:8121
#4  0x417ba170 in reload_as_needed (live_known=-2147482625)
at ../../gcc/gcc/reload1.c:4658
#5  0x417aa3d4 in reload (first=0x83fffd0474c0, global=-2147482625)
at ../../gcc/gcc/reload1.c:1050
#6  0x414d11fc in do_reload () at ../../gcc/gcc/ira.c:5528
#7  0x414d1c04 in (anonymous namespace)::pass_reload::execute (
this=0x90cd5) at ../../gcc/gcc/ira.c:5700
#8  0x416f3cac in execute_one_pass (pass=0x83fffd0474c0)
at ../../gcc/gcc/passes.c:2473
#9  0x416f4348 in execute_pass_list_1 (pass=0x83fffd0474c0)
at ../../gcc/gcc/passes.c:2559
#10 0x416f4398 in execute_pass_list_1 (pass=0x8001007a7918)
at ../../gcc/gcc/passes.c:2560
#11 0x416f4460 in execute_pass_list (fn=0x83fffb30b9a0,
pass=0x8001007a3798) at ../../gcc/gcc/passes.c:2570
---Type  to continue, or q  to quit---
#12 0x41012e14 in cgraph_node::expand (this=0x83fffb368168)
at ../../gcc/gcc/cgraphunit.c:2198
#13 0x4101392c in expand_all_functions ()
at ../../gcc/gcc/cgraphunit.c:2336
#14 0x41014fe4 in symbol_table::compile (this=0x83fffb368168)
at ../../gcc/gcc/cgraphunit.c:2687
#15 0x41015a40 in symbol_table::finalize_compilation_unit (
this=0x83fffb368168) at ../../gcc/gcc/cgraphunit.c:2865
#16 0x418d2174 in compile_file () at ../../gcc/gcc/toplev.c:481
#17 0x418d8480 in do_compile () at ../../gcc/gcc/toplev.c:2205
#18 0x418d8bec in toplev::main (this=0x83fffb368168, argc=0,
argv=0x4063c278) at ../../gcc/gcc/toplev.c:2340
#19 0x427b2754 in main (argc=-2147482625, argv=0x8)
at ../../gcc/gcc/main.c:39

[Bug target/86215] Exceptions are broken on OSX when linking with -static-libgcc

2019-05-19 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86215

Iain Sandoe  changed:

   What|Removed |Added

  Component|libgcc  |target

--- Comment #6 from Iain Sandoe  ---
As suspected in comment #2, this is a missing backport of the fix for PR80556,
which I will take care of later - altering the component to 'target'.

[Bug fortran/90498] [8/9/10 Regression] ICE with select type/associate and derived type argument containing class(*)

2019-05-19 Thread pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90498

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Sun May 19 12:32:55 2019
New Revision: 271380

URL: https://gcc.gnu.org/viewcvs?rev=271380=gcc=rev
Log:
2019-05-19  Paul Thomas  

PR fortran/90498
* trans-stmt.c (trans_associate_var) Do not use the saved
descriptor if the expression is a COMPONENT_REF.

2019-05-19  Paul Thomas  

PR fortran/90498
* gfortran.dg/associate_48.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/associate_48.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78290] Gfortran incorrectly creates a copy of an array passed to an array pointer dummy argument

2019-05-19 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78290

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #5)
> > Any need for a new test on top of those included in the revision?
> 
> PING!

I committed Harald's variant with VOLATILE (which did not seem
to be covered by the existing test cases).

So, fixed.

[Bug fortran/78290] Gfortran incorrectly creates a copy of an array passed to an array pointer dummy argument

2019-05-19 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78290

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Sun May 19 11:26:20 2019
New Revision: 271379

URL: https://gcc.gnu.org/viewcvs?rev=271379=gcc=rev
Log:
2019-05-19  Thomas Koenig  

PR fortran/78290
* gfortran.dg/pr78290.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pr78290.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/88821] Inline packing of non-contiguous arguments

2019-05-19 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821

--- Comment #8 from Thomas Koenig  ---
Author: tkoenig
Date: Sun May 19 11:24:17 2019
New Revision: 271378

URL: https://gcc.gnu.org/viewcvs?rev=271378=gcc=rev
Log:
2019-05-19  Thomas Koenig  

PR fortran/88821
* ChangeLog: Add forgotten entry.


Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/83118] [7/8/9/10 Regression] Bad intrinsic assignment of class(*) array component of derived type

2019-05-19 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118

--- Comment #21 from Dominique d'Humieres  ---
> Created attachment 46216 [details]
> Patch for the remaining problems.

I have the patch in my working tree without any problem.

[Bug c++/85679] [DR2094] __is_trivially_copyable returns false with volatile scalar type

2019-05-19 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85679

Jonathan Wakely  changed:

   What|Removed |Added

 CC||alisdairm at me dot com

--- Comment #2 from Jonathan Wakely  ---
*** Bug 90531 has been marked as a duplicate of this bug. ***

[Bug c++/90531] is_trivailly_copyable_v should be 'true'

2019-05-19 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90531

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
.

*** This bug has been marked as a duplicate of bug 85679 ***

[Bug fortran/90294] Compare with NaN failing

2019-05-19 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294

Thomas Koenig  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug fortran/90294] Compare with NaN failing

2019-05-19 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #9 from Thomas Koenig  ---
(In reply to Fred Krogh from comment #8)
> My apologies for posting this.  In my original code the program just quit at
> the point of the test.  I thought I had more or less reproduced this in a
> small program.  Clearly that is not the case.  My code has changed to get
> around the bug, such change was needed regardless.  I have not idea how to
> get this reproduced in a small program.

OK, so I will resolve this (for now).

If you come up with something that shows an error, please do not
hesitate to resubmit.

[Bug fortran/88821] Inline packing of non-contiguous arguments

2019-05-19 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Thomas Koenig  ---
Fixed on trunk, closing.

[Bug fortran/88821] Inline packing of non-contiguous arguments

2019-05-19 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88821

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Sun May 19 10:21:06 2019
New Revision: 271377

URL: https://gcc.gnu.org/viewcvs?rev=271377=gcc=rev
Log:
2019-05-19  Thomas Koenig  

PR fortran/88821
* expr.c (gfc_is_simply_contiguous): Return true for
an EXPR_ARRAY.
* trans-array.c (is_pointer): New function.
(gfc_conv_array_parameter): Call gfc_conv_subref_array_arg
when not optimizing and not optimizing for size if the formal
arg is passed by reference.
* trans-expr.c (gfc_conv_subref_array_arg): Add arguments
fsym, proc_name and sym.  Add run-time warning for temporary
array creation.  Wrap argument if passing on an optional
argument to an optional argument.
* trans.h (gfc_conv_subref_array_arg): Add optional arguments
fsym, proc_name and sym to prototype.

2019-05-19  Thomas Koenig  

PR fortran/88821
* gfortran.dg/alloc_comp_auto_array_3.f90: Add -O0 to dg-options
to make sure the test for internal_pack is retained.
* gfortran.dg/assumed_type_2.f90: Split compile and run time
tests into this and
* gfortran.dg/assumed_type_2a.f90: New file.
* gfortran.dg/c_loc_test_22.f90: Likewise.
* gfortran.dg/contiguous_3.f90: Likewise.
* gfortran.dg/internal_pack_11.f90: Likewise.
* gfortran.dg/internal_pack_12.f90: Likewise.
* gfortran.dg/internal_pack_16.f90: Likewise.
* gfortran.dg/internal_pack_17.f90: Likewise.
* gfortran.dg/internal_pack_18.f90: Likewise.
* gfortran.dg/internal_pack_4.f90: Likewise.
* gfortran.dg/internal_pack_5.f90: Add -O0 to dg-options
to make sure the test for internal_pack is retained.
* gfortran.dg/internal_pack_6.f90: Split compile and run time
tests into this and
* gfortran.dg/internal_pack_6a.f90: New file.
* gfortran.dg/internal_pack_8.f90: Likewise.
* gfortran.dg/missing_optional_dummy_6: Split compile and run time
tests into this and
* gfortran.dg/missing_optional_dummy_6a.f90: New file.
* gfortran.dg/no_arg_check_2.f90: Split compile and run time tests
into this and
* gfortran.dg/no_arg_check_2a.f90: New file.
* gfortran.dg/typebound_assignment_5.f90: Split compile and run time
tests into this and
* gfortran.dg/typebound_assignment_5a.f90: New file.
* gfortran.dg/typebound_assignment_6.f90: Split compile and run time
tests into this and
* gfortran.dg/typebound_assignment_6a.f90: New file.
* gfortran.dg/internal_pack_19.f90: New file.
* gfortran.dg/internal_pack_20.f90: New file.
* gfortran.dg/internal_pack_21.f90: New file.


Added:
trunk/gcc/testsuite/gfortran.dg/assumed_type_2a.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_19.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_20.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_21.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_6a.f90
trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6a.f90
trunk/gcc/testsuite/gfortran.dg/no_arg_check_2a.f90
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_5a.f03
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_6a.f03
Modified:
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_3.f90
trunk/gcc/testsuite/gfortran.dg/assumed_type_2.f90
trunk/gcc/testsuite/gfortran.dg/c_loc_test_22.f90
trunk/gcc/testsuite/gfortran.dg/contiguous_3.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_11.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_12.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_16.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_17.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_18.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_4.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_5.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_6.f90
trunk/gcc/testsuite/gfortran.dg/internal_pack_9.f90
trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90
trunk/gcc/testsuite/gfortran.dg/no_arg_check_2.f90
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_5.f03
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_6.f03

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

2019-05-19 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329

--- Comment #36 from Thomas Koenig  ---
Author: tkoenig
Date: Sun May 19 08:22:41 2019
New Revision: 271376

URL: https://gcc.gnu.org/viewcvs?rev=271376=gcc=rev
Log:
2019-05-19  Thomas Koenig  

PR fortran/90329
* invoke.texi: Document -fbroken-callers.
* lang.opt: Add -fbroken-callers.
* trans-decl.c (create_function_arglist): Only set
DECL_HIDDEN_STRING_LENGTH if flag_broken_callers is set.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/trans-decl.c

[Bug c++/90531] is_trivailly_copyable_v should be 'true'

2019-05-19 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90531

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-19
  Component|libstdc++   |c++
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Yes this is a compiler issue. We might already have a bug about it. I haven't
bothered pushing for the intrinsic to change, because the standard will
probably change the rule again as soon as we catch up. A take of woe indeed.