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

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118

--- Comment #4 from Neil Carlson  ---
Note that if the sourced allocation in the comment 0 test case

  allocate(x%v,source=['foo','bar'])

is replaced by the equivalent (I think) assignment

  x%v = ['foo','bar']

Then the code produces a run time segfault instead:

$ gfortran --version
GNU Fortran (GCC) 8.0.1 20180224 (experimental)

$ gfortran -g -fbacktrace bug.f90
$ ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f3c46fda94f in ???
#1  0x0 in ???
Segmentation fault (core dumped)

I think the problems here may be related to the simpler test cases in PR84539
which I just reported.

[Bug fortran/84539] ICE and segfault with assignment to CLASS(*) array

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84539

--- Comment #1 from Neil Carlson  ---
And same example but using character data. This compiles but gives a segfault
when run at the assignment statement.

class(*), allocatable :: x(:)
x = ['foo','bar']
select type (x)
type is (character(*))
  if (any(x /= ['foo','bar'])) stop 1
end select
end


$ gfortran -g gfortran-20180223b.f90 
$ ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f40a5b0894f in ???
#1  0x400853 in MAIN__
at gfortran-20180223b.f90:2
#2  0x4009fd in main
at gfortran-20180223b.f90:7
Segmentation fault (core dumped)

[Bug fortran/84539] New: ICE and segfault with assignment to CLASS(*) array

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84539

Bug ID: 84539
   Summary: ICE and segfault with assignment to CLASS(*) array
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

Here are some issues with array assignment to an allocatable CLASS(*) array
using the current 8.0 trunk.

class(*), allocatable :: x(:)
x = [4,2]
select type (x)
type is (integer)
  if (any(x /= [4,2])) stop 1
end select
end

$ gfortran -g -fbacktrace gfortran-20180223a.f90 
gfortran-20180223a.f90:1:0:

 class(*), allocatable :: x(:)

Error: conversion of register to a different size
VIEW_CONVERT_EXPR(_1);

_12 = VIEW_CONVERT_EXPR(_1);
gfortran-20180223a.f90:1:0: internal compiler error: verify_gimple failed
0xd2b9bd verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5247
0xaa7495 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12710
0xaa7684 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12800
0x925d17 cgraph_node::analyze()
../../gcc/cgraphunit.c:670
0x9286b3 analyze_functions
../../gcc/cgraphunit.c:1131
0x9294a2 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2691
Please submit a full bug report,

[Bug c++/52036] C++11 allows template parameters to have internal linkage

[xaxxon at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52036

zac  changed:

   What|Removed |Added

 CC||xaxxon at gmail dot com

--- Comment #12 from zac  ---
Any update?  

https://godbolt.org/g/7qE4iW


template
void func() {
}
void g();
int main() {

constexpr auto lambda_function_pointer = +[](){};
func();

}


:9:35: error: 'main()::::_FUN' is not a valid template
argument for type 'void (*)()' because 'static constexpr void
main()::::_FUN()' has no linkage

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213

Neil Carlson  changed:

   What|Removed |Added

Version|4.7.0   |8.0.1

--- Comment #26 from Neil Carlson  ---
Still present in 8.0

[Bug fortran/69563] Generic TBP incorrectly resolves to elemental

[neil.n.carlson at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69563

Neil Carlson  changed:

   What|Removed |Added

Version|6.0 |8.0.1

--- Comment #2 from Neil Carlson  ---
And still present in 8.0.

[Bug fortran/51652] Allocate with type-spec and source-expr: check whether length type-parameter is the same is lacking

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51652

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #8)
> AFAICT this PR is mostly fixed since gcc-5. However I see a remaining glitch
> with the following variant of the original test
> 
> module settings
> 
> type keyword
> !  character(60), allocatable :: c(:)   ! works but should it?
> !  character(80), allocatable :: c(:)   ! works
>character(:), allocatable :: c(:)
> end type keyword
> 
> type(keyword) :: kw(10)
> 
> contains
> 
> subroutine save_kw
> 
> !allocate(kw(1)%c(10))
> allocate(character(80) :: kw(1)%c(10))
> 
> kw(1)%c(1) = 'abcd'
> 
> print *, "'", kw(1)%c(1), "'"
> if (trim(kw(1)%c(1)).eq.'abcd') then  ! problem here
>print *, 'yes'
> else
>print *, 'no'
> endif
> 
> end subroutine save_kw
> 
> end module settings
> 
> !*
> 
> program ice
> use settings
> 
> call save_kw
> 
> end program ice
> 
> which prints
> 
>  'abcd  
> '
>  yes
> 
> at run time, i.e., the second quote is missing.

I think that the is now fixed and can be closed.

[Bug c++/70468] [6/7/8 Regression] ICE on invalid code on x86_64-linux-gnu in emit_mem_initializers, at cp/init.c:1109

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70468

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|6.5 |8.0

--- Comment #9 from Jason Merrill  ---
Fixed for GCC 8, not backporting since testcase is ill-formed.

[Bug fortran/30792] DATA implied-do substring allowed with -std=f95/f2003

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30792

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug fortran/84538] New: Array of derived type elements incorrectly accessed in function

[abensonca at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84538

Bug ID: 84538
   Summary: Array of derived type elements incorrectly accessed in
function
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following code results in incorrect behavior with gfortran 8.0.1 (r257956):

module bugMod
  public
  type :: t
 integer :: i
  end type t
  type, extends(t) :: te
 integer :: j
  end type te
contains
  subroutine check(n)
implicit none
class(t), intent(inout), dimension(:) :: n
write (0,*) "FROM MODULE  ",n%i
return
  end subroutine check
end module bugMod

program bug
  use bugMod
  class(t), allocatable, dimension(:) :: n
  allocate(te :: n(2))
  n(1:2)%i=[8,3]
  write (0,*) "FROM PROGRAM ",n%i
  call check(n)
end program bug

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/nfs/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/nfs/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 8.0.1 20180223 (experimental) (GCC) 

$ gfortran bug.F90
$ a.out 
 FROM PROGRAM8   3
 FROM MODULE 8   0

I would expect the output to be the same from the module subroutine as from the
main program.

[Bug fortran/84523] [8 Regression] Runtime crash deallocating allocatable array within derived type

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84523

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug c++/84537] [8 Regression] ICE in get_string, at spellcheck-tree.h

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84537

--- Comment #1 from Volker Reichelt  ---
With a slightly modified testcase (namespace std instead of N) I get
a different stack-trace:

===
namespace std
{
  template struct A {};
}

std::template A<> a;
===

bug.cc:6:17: error: wrong number of template arguments (0, should be 1)
 std::template A<> a;
 ^
bug.cc:3:24: note: provided for 'template > struct std::A'
   template struct A {};
^
bug.cc:6:15: error: '' in namespace 'std' does not name a
type
 std::template A<> a;
   ^~~
bug.cc:6:15: internal compiler error: in maybe_suggest_missing_header, at
cp/name-lookup.c:5519
0x620703 maybe_suggest_missing_header
../../gcc/gcc/cp/name-lookup.c:5519
0x620703 suggest_alternative_in_explicit_scope(unsigned int, tree_node*,
tree_node*)
../../gcc/gcc/cp/name-lookup.c:5547
0x90cf87 cp_parser_diagnose_invalid_type_name
../../gcc/gcc/cp/parser.c:3370
0x9353ed cp_parser_parse_and_diagnose_invalid_type_name
../../gcc/gcc/cp/parser.c:3468
0x93c76f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12946
0x93cfd8 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12869
0x940f32 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12767
0x941341 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12643
0x941634 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4559
0x941634 c_parse_file()
../../gcc/gcc/cp/parser.c:38866
0xa3f966 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]

[Bug c++/84537] New: [8 Regression] ICE in get_string, at spellcheck-tree.h

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84537

Bug ID: 84537
   Summary: [8 Regression] ICE in get_string, at spellcheck-tree.h
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE on trunk:

=
namespace N
{
  template struct A {};
}

N::template A<> a;
=

bug.cc:6:15: error: wrong number of template arguments (0, should be 1)
 N::template A<> a;
   ^
bug.cc:3:24: note: provided for 'template > struct N::A'
   template struct A {};
^
bug.cc:6:13: error: '' in namespace 'N' does not name a type
 N::template A<> a;
 ^~~
bug.cc:6:13: internal compiler error: in get_string, at spellcheck-tree.h:46
0x620770 edit_distance_traits::get_string(tree_node*)
../../gcc/gcc/spellcheck-tree.h:46
0x620770 best_match::best_match(tree_node*, unsigned
int)
../../gcc/gcc/spellcheck.h:92
0x620770 suggest_alternative_in_explicit_scope(unsigned int, tree_node*,
tree_node*)
../../gcc/gcc/cp/name-lookup.c:5552
0x90cf87 cp_parser_diagnose_invalid_type_name
../../gcc/gcc/cp/parser.c:3370
0x9353ed cp_parser_parse_and_diagnose_invalid_type_name
../../gcc/gcc/cp/parser.c:3468
0x93c76f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12946
0x93cfd8 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12869
0x940f32 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12767
0x941341 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12643
0x941634 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4559
0x941634 c_parse_file()
../../gcc/gcc/cp/parser.c:38866
0xa3f966 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]

The regression was introduced between 2017-11-26 and 2017-12-18.

[Bug libstdc++/84532] [7/8 Regression] std::thread::__make_invoker prematurely unwraps reference_wrappers

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84532

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Feb 23 23:23:43 2018
New Revision: 257956

URL: https://gcc.gnu.org/viewcvs?rev=257956=gcc=rev
Log:
PR libstdc++/84532 prevent unwrapping of reference_wrapper arguments

PR libstdc++/84532
* include/std/thread (thread::__make_invoker): Construct tuple
directly instead of using make_tuple.
* testsuite/30_threads/async/84532.cc: New.
* testsuite/30_threads/thread/84532.cc: New.

Added:
trunk/libstdc++-v3/testsuite/30_threads/async/84532.cc
trunk/libstdc++-v3/testsuite/30_threads/thread/84532.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/thread

[Bug fortran/68226] [6/7/8 Regression] [OOP] ICE on assignment of pointer-valued function to allocatable

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68226

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
  Known to work||8.0.1

--- Comment #6 from Dominique d'Humieres  ---
> The code in comment#0 compiles with current trunk.  The ICE is gone. ...

The change occurred between revisions r254869 (2017-11-17, ICE) and r254940
(2017-11-19, OK), likely r254936 (pr78990).

Note the warnings

pr68226_db.f90:6:7:

a = f()
   1
Warning: POINTER-valued function appears on right-hand side of assignment at
(1) [-Wsurprising]
pr68226_db.f90:6:0:

a = f()

Warning: 'a.offset' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr68226_db.f90:6:0: Warning: 'a.dim[0].lbound' may be used uninitialized in
this function [-Wmaybe-uninitialized]
pr68226_db.f90:6:0: Warning: 'a.dim[0].ubound' may be used uninitialized in
this function [-Wmaybe-uninitialized]
pr68226_db.f90:6:0:

a = f()

Warning: 'a.dim[0].lbound' may be used uninitialized in this function
[-Wmaybe-uninitialized]
pr68226_db.f90:6:0: Warning: 'a.dim[0].ubound' may be used uninitialized in
this function [-Wmaybe-uninitialized]
pr68226_db.f90:6:0: Warning: 'a.dim[0].ubound' may be used uninitialized in
this function [-Wmaybe-uninitialized]
pr68226_db.f90:6:0: Warning: 'a.dim[0].lbound' may be used uninitialized in
this function [-Wmaybe-uninitialized]

[Bug libstdc++/84535] std::thread constructor missing constraint on first argument

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84535

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-23
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I have a patch ready for stage 1.

[Bug fortran/68226] [6/7/8 Regression] [OOP] ICE on assignment of pointer-valued function to allocatable

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68226

--- Comment #5 from Harald Anlauf  ---
The code in comment#0 compiles with current trunk.  The ICE is gone.

Not sure if the code is valid, but NAG accepts it
without complaining.

Adding a line

  print *, a

prints

   1   2

which I think is correct.

[Bug c++/84536] New: [7/8 Regression] ICE with non-type template parameter

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84536

Bug ID: 84536
   Summary: [7/8 Regression] ICE with non-type template parameter
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE since GCC 7.1.0:


template auto foo(N...) -> void {}

void bar()
{
  foo<>();
}


bug.cc:1:34: error: expected ';' before '->' token
 template auto foo(N...) -> void {}
  ^~~
  ;
bug.cc: In instantiation of 'auto foo<>':
bug.cc:5:3:   required from here
bug.cc:1:25: internal compiler error: in cp_finish_decl, at cp/decl.c:6812
 template auto foo(N...) -> void {}
 ^~~
0x600957 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6812
0x965bf9 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23367
0x8aefcb maybe_instantiate_decl
../../gcc/gcc/cp/decl2.c:5186
0x8b0dd8 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5281
0x9ace9b finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
../../gcc/gcc/cp/semantics.c:3681
0x91e2dc cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5607
0x9306fc cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7026
0x9312d0 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8318
0x91165f cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9086
0x911e6a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9187
0x9136a4 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9482
0x913db8 cp_parser_expression
../../gcc/gcc/cp/parser.c:9651
0x915a78 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:8
0x91bded cp_parser_statement
../../gcc/gcc/cp/parser.c:10922
0x91d300 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11261
0x91d3d7 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11215
0x933b50 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21756
0x933b50 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21793
0x934400 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:26694
0x935134 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:26610
Please submit a full bug report, [etc.]

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|6.4 |6.5

--- Comment #64 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #63)
> Workaround in place for 6.4, 7.4 and 8.1

Oops, 6.5 not 6.4

[Bug libstdc++/84535] New: std::thread constructor missing constraint on first argument

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84535

Bug ID: 84535
   Summary: std::thread constructor missing constraint on first
argument
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

int main()
{
static_assert(!std::is_constructible::value,
"");
}

This assertion fails. The standard requires the constructor to not participate
in overload resolution when the first argument is a std::thread.

[Bug target/84534] New: [8 regression] several powerpc test cases fail starting with r257915

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84534

Bug ID: 84534
   Summary: [8 regression] several powerpc test cases fail
starting with r257915
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I only saw this on LE.  The two LE tests may just need to be adjusted.

FAIL: gcc.target/powerpc/vec-setup-be-long.c execution test
FAIL: gcc.target/powerpc/vsx-vector-6-le.c scan-assembler-times xxlor 30 (found
26 times)
FAIL: gcc.target/powerpc/vsx-vector-6-le.p9.c scan-assembler-times xxlor 20
(found 16 times)


For vec-setup-be-long.c:

(gdb) where
#0  0x3fffb7ccedb0 in __GI_raise (sig=) at
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x3fffb7cd1270 in __GI_abort () at abort.c:89
#2  0x1af8 in vector_check (v=..., expect_hi=,
expect_lo=)
at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/vec-setup.h:120
#3  0x1688 in main () at
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/vec-setup.h:310

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143

--- Comment #5 from Jerry DeLisle  ---
Looking at the tree dump we have:

_gfortran_st_write (_parm.0);
{
  struct Pdtfoo_1 * D.3772;

  D.3772 = 
  _gfortran_transfer_integer_write (_parm.0, >k1, 4);
  _gfortran_transfer_integer_write (_parm.0, >l1, 4);
  _gfortran_transfer_integer_write (_parm.0, >n, 4);
}
_gfortran_st_write_done (_parm.0);

And so in trans-io.c I am going to try:

diff --git a/gcc/fortran/trans-io.c b/gcc/fortran/trans-io.c
index 36adb034475..d492ed8cc4e 100644
--- a/gcc/fortran/trans-io.c
+++ b/gcc/fortran/trans-io.c
@@ -2483,7 +2483,8 @@ transfer_expr (gfc_se * se, gfc_typespec * ts, tree
addr_expr,
  se->string_length = strlen;
}

- transfer_expr (se, >ts, tmp, code, NULL_TREE);
+ if (c->attr.pdt_kind == 0 && c->attr.pdt_len == 0)
+   transfer_expr (se, >ts, tmp, code, NULL_TREE);

  /* Reset so that the pdt string length does not propagate
 through to other strings.  */

Its not clear to me yet why printing x%n is coming out zero however. I will
explore some more.

[Bug fortran/84523] [8 Regression] Runtime crash deallocating allocatable array within derived type

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84523

--- Comment #2 from Harald Anlauf  ---
(In reply to Thomas Koenig from comment #1)
> Doesn't crash for me, but I get a valgrind error:

Trying -fsanitize=undefined, I get:

 ### destruct: size(rc% spots)=  80
 ### destruct: allocated (vm) = F
gfcbug148.f90:33: runtime error: member access within misaligned address
0x08053a1b for type 'struct t_spot', which requires 4 byte alignment
0x08053a1b: note: pointer points here
 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00
  ^ 
At line 33 of file gfcbug148.f90
Fortran runtime error: Attempt to DEALLOCATE unallocated 'rc'

Error termination. Backtrace:
#0  0x804947b in destruct
at /home/anlauf/gcc-bugs/gfcbug148.f90:33
#1  0x8049975 in gfcbug148
at /home/anlauf/gcc-bugs/gfcbug148.f90:12
#2  0x804a6d4 in main
at /home/anlauf/gcc-bugs/gfcbug148.f90:13


Modifying line 33 to

if (allocated (rc% spots(k)% vm)) print *, "hello"

it appears that it is the test that fails for me (on a 32-bit system).

I tried to compare the dump-tree-original of 8-trunk to 7.2, but
failed to understand the differences, which are probably due to the
changes in array descriptors.

[Bug tree-optimization/84526] [8 Regression] ICE in generic_overlap at gcc/gimple-ssa-warn-restrict.c:927 since r257860

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84526

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #9 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01349.html

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #16 from Jerry DeLisle  ---
Fixed and closing.

[Bug c++/84533] New: [7/8 Regression] ICE with duplicate enum value

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84533

Bug ID: 84533
   Summary: [7/8 Regression] ICE with duplicate enum value
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following really short invalid code snippet (compiled with "-std=c++1z")
triggers an ICE since GCC 7.1.0:

==
enum E { e, e };
==

bug.cc:1:13: internal compiler error: tree check: expected var_decl or
function_decl, have const_decl in redeclaration_error_message, at
cp/decl.c:2923
 enum E { e, e };
 ^
0x78a6fc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9335
0x890e85 tree_check2(tree_node*, char const*, int, char const*, tree_code,
tree_code)
../../gcc/gcc/tree.h:3151
0x890e85 redeclaration_error_message
../../gcc/gcc/cp/decl.c:2923
0x890e85 duplicate_decls(tree_node*, tree_node*, bool)
../../gcc/gcc/cp/decl.c:1767
0x9007ea do_pushdecl
../../gcc/gcc/cp/name-lookup.c:3035
0x9007ea pushdecl(tree_node*, bool)
../../gcc/gcc/cp/name-lookup.c:3170
0x8935d9 build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
../../gcc/gcc/cp/decl.c:14644
0x929db7 cp_parser_enumerator_definition
../../gcc/gcc/cp/parser.c:18410
0x929db7 cp_parser_enumerator_list
../../gcc/gcc/cp/parser.c:18339
0x929db7 cp_parser_enum_specifier
../../gcc/gcc/cp/parser.c:18266
0x929db7 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16726
0x936966 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13612
0x93c030 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12922
0x93cfd8 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12869
0x940f32 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12767
0x941341 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12643
0x941634 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4559
0x941634 c_parse_file()
../../gcc/gcc/cp/parser.c:38866
0xa3f966 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506

--- Comment #15 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Feb 23 19:53:04 2018
New Revision: 257951

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

Backport from trunk
PR fortran/84506
* trans-io.c (set_parameter_value_inquire): Adjust range check of
negative unit values for kind=8 units to the kind=4 negative limit.

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

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/inquire_19.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-io.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/83496] [7/8 regression] wrong code generates under "-Os -mbranch-cost=1"

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496

Eric Botcazou  changed:

   What|Removed |Added

 Target|mipsbe  |mips-*-*
   Target Milestone|--- |7.4
Summary|MIPS BE: wrong code |[7/8 regression] wrong code
   |generates under "-Os|generates under "-Os
   |-mbranch-cost=1"|-mbranch-cost=1"

[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
 CC||ebotcazou at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org

--- Comment #22 from Eric Botcazou  ---
Investigating.

[Bug fortran/84346] Statement functions should not accept keywords

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84346

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.5

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.

[Bug fortran/84511] [6/7/8 Regression] Internal compiler error from directly printing return of C_LOC

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84511

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on 6-branch, 7-branch, and trunk.
Thanks for the bug report.

[Bug libstdc++/84532] [7/8 Regression] std::thread::__make_invoker prematurely unwraps reference_wrappers

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84532

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-23
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Drat, thanks for catching this.

[Bug fortran/84511] [6/7/8 Regression] Internal compiler error from directly printing return of C_LOC

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84511

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Feb 23 19:42:43 2018
New Revision: 257950

URL: https://gcc.gnu.org/viewcvs?rev=257950=gcc=rev
Log:
2018-02-23  Steven G. Kargl  

PR fortran/84511
* trans-io.c (transfer_expr): Deal with C_LOC in transfer statement.

Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-io.c

[Bug fortran/84346] Statement functions should not accept keywords

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84346

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Feb 23 19:41:27 2018
New Revision: 257949

URL: https://gcc.gnu.org/viewcvs?rev=257949=gcc=rev
Log:
2018-02-23  Steven G. Kargl  

PR fortran/84346
* interface.c (compare_actual_formal): Issue error if keyword is
used in a statement function.

2018-02-23  Steven G. Kargl  

PR fortran/84346
* gfortran.dg/statement_function_1.f90: Update test.


Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/interface.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/statement_function_1.f90

[Bug fortran/84511] [6/7/8 Regression] Internal compiler error from directly printing return of C_LOC

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84511

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Feb 23 19:37:57 2018
New Revision: 257948

URL: https://gcc.gnu.org/viewcvs?rev=257948=gcc=rev
Log:
2018-02-23  Steven G. Kargl  

PR fortran/84511
* trans-io.c (transfer_expr): Deal with C_LOC in transfer statement.

Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-io.c

[Bug fortran/84346] Statement functions should not accept keywords

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84346

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Feb 23 19:35:51 2018
New Revision: 257946

URL: https://gcc.gnu.org/viewcvs?rev=257946=gcc=rev
Log:
2018-02-23  Steven G. Kargl  

PR fortran/84346
* interface.c (compare_actual_formal): Issue error if keyword is
used in a statement function.

2018-02-23  Steven G. Kargl  

PR fortran/84346
* gfortran.dg/statement_function_1.f90: Update test.

Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/interface.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/statement_function_1.f90

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506

--- Comment #14 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Feb 23 19:16:00 2018
New Revision: 257945

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

Backport from trunk
PR fortran/84506
* trans-io.c (set_parameter_value_inquire): Adjust range check of
negative unit values for kind=8 units to the kind=4 negative limit.

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

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/inquire_19.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-io.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug middle-end/84019] [7/8 regression] ICE in fold-const of std::complex division

[linux at carewolf dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019

--- Comment #8 from Allan Jensen  ---
Yes, I will take a look again and produce the intermediate results

[Bug rtl-optimization/83327] Spilling into hard regs not taken into account in lra liveness analysis

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83327

--- Comment #10 from Vladimir Makarov  ---
Any news about the patch testing on MIPS.  It would be nice to move forward
with the PR.

[Bug fortran/84511] [6/7/8 Regression] Internal compiler error from directly printing return of C_LOC

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84511

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Feb 23 18:59:38 2018
New Revision: 257943

URL: https://gcc.gnu.org/viewcvs?rev=257943=gcc=rev
Log:
2018-02-23  Steven G. Kargl  

PR fortran/84511
* trans-io.c (transfer_expr): Deal with C_LOC in transfer statement.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-io.c

[Bug fortran/84346] Statement functions should not accept keywords

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84346

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Feb 23 18:57:41 2018
New Revision: 257942

URL: https://gcc.gnu.org/viewcvs?rev=257942=gcc=rev
Log:
2018-02-23  Steven G. Kargl  

PR fortran/84346
* interface.c (compare_actual_formal): Issue error if keyword is
used in a statement function.

2018-02-23  Steven G. Kargl  

PR fortran/84346
* gfortran.dg/statement_function_1.f90: Update test.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/statement_function_1.f90

[Bug bootstrap/84450] bootstrap-lto ICE in g-dyntab.adb

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84450

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Eric Botcazou  ---
The search button is your friend. :-)

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

[Bug debug/83765] LTO bootstrap with Ada fails

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83765

Eric Botcazou  changed:

   What|Removed |Added

 CC||steven at uplinklabs dot net

--- Comment #7 from Eric Botcazou  ---
*** Bug 84450 has been marked as a duplicate of this bug. ***

[Bug fortran/84523] [8 Regression] Runtime crash deallocating allocatable array within derived type

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84523

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-23
 CC||tkoenig at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Doesn't crash for me, but I get a valgrind error:

 ### destruct: size(rc% spots)=  80
 ### destruct: allocated (vm) = F
 OK
ig25@linux-d6cw:~/Krempel/Alloca> valgrind ./a.out
==5413== Memcheck, a memory error detector
==5413== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==5413== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==5413== Command: ./a.out
==5413== 
==5413== Conditional jump or move depends on uninitialised value(s)
==5413==at 0x50594BB: write_decimal.constprop.10 (write.c:808)
==5413==by 0x5059873: write_integer (write.c:1351)
==5413==by 0x505A71D: list_formatted_write_scalar (write.c:1865)
==5413==by 0x505B3F4: _gfortrani_list_formatted_write (write.c:1943)
==5413==by 0x400A7B: destruct.3792 (in /home/ig25/Krempel/Alloca/a.out)
==5413==by 0x400DF2: MAIN__ (in /home/ig25/Krempel/Alloca/a.out)
==5413==by 0x40139E: main (in /home/ig25/Krempel/Alloca/a.out)
==5413== 
 ### destruct: size(rc% spots)=  80
==5413== Use of uninitialised value of size 8
==5413==at 0x400B40: destruct.3792 (in /home/ig25/Krempel/Alloca/a.out)
==5413==by 0x400DF2: MAIN__ (in /home/ig25/Krempel/Alloca/a.out)
==5413==by 0x40139E: main (in /home/ig25/Krempel/Alloca/a.out)
==5413== 
 ### destruct: allocated (vm) = F
==5413== Use of uninitialised value of size 8
==5413==at 0x400BF8: destruct.3792 (in /home/ig25/Krempel/Alloca/a.out)
==5413==by 0x400DF2: MAIN__ (in /home/ig25/Krempel/Alloca/a.out)
==5413==by 0x40139E: main (in /home/ig25/Krempel/Alloca/a.out)
==5413== 
 OK

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506

--- Comment #13 from Jerry DeLisle  ---
Fixed on trunk.

Jakub, thanks for the report. This will be backported to 6 and 7 shortly.

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506

--- Comment #12 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Feb 23 18:40:14 2018
New Revision: 257941

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

PR fortran/84506
* trans-io.c (set_parameter_value_inquire): Adjust range check of
negative unit values for kind=8 units to the kind=4 negative limit.

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

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

[Bug fortran/83149] [6- and 7-branches] Missing test for sym->ns->proc_name: crash_signal in toplev.c:325

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
Summary|[8 Regression] ICE on   |[6- and 7-branches] Missing
   |SELECT CASE: crash_signal   |test for
   |in toplev.c:325 |sym->ns->proc_name:
   ||crash_signal in
   ||toplev.c:325

--- Comment #12 from Paul Thomas  ---
The original regression is now fixed. The testcases of comments 2 and 7 have
been fixed on trunk but remain on 6- and 7-branches. I will await advice from
the list as to whether to backport or not and so will keep the PR open.

Neil, you were right about the common origin. Thanks for the report.

Paul

[Bug libstdc++/84532] New: [7/8 Regression] std::thread::__make_invoker prematurely unwraps reference_wrappers

[rs2740 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84532

Bug ID: 84532
   Summary: [7/8 Regression] std::thread::__make_invoker
prematurely unwraps reference_wrappers
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

std::thread::__make_invoker uses make_tuple, which unwraps reference_wrappers,
so instead of passing a DECAY_COPY'd reference_wrapper rvalue to __invoke,
it (incorrectly) passes a T lvalue instead.

This means that we accept invalid code like

int i = 0;
std::thread t([](auto&){}, std::ref(i));

It's not too hard to come up with code that changes meaning and valid code that
gets rejected either.

This is a 7/8 regression: previously the now-removed __bind_simple was used,
which correctly just does a simple decay.

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149

--- Comment #11 from Paul Thomas  ---
Author: pault
Date: Fri Feb 23 17:55:13 2018
New Revision: 257938

URL: https://gcc.gnu.org/viewcvs?rev=257938=gcc=rev
Log:
2018-02-23  Paul Thomas  

PR fortran/83149
* trans-types.c (gfc_sym_type): Test sym->ns->proc_name before
accessing its components.

2018-02-23  Paul Thomas  

PR fortran/83149
* gfortran.dg/pr83149_b.f90: New test.
* gfortran.dg/pr83149_a.f90: Additional source for previous.


Added:
trunk/gcc/testsuite/gfortran.dg/pr83149_a.f90
trunk/gcc/testsuite/gfortran.dg/pr83149_b.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84422] ICE on various builtin test functions when compiled with -mcpu=power7

[carll at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84422

--- Comment #2 from Carl Love  ---
Moved Power 8 vec_float2, vec_signed2 and vec_unsigned2 builtin tests to new
file builtins-3-runnable-p8.c.  Fixed ICE for vec_signed2 and vec_unsigned2
which were found in builtins-3-runnable.c once the vec_float2 test was moved to
a P8 test file.  Commit 257937.

[Bug tree-optimization/84526] [8 Regression] ICE in generic_overlap at gcc/gimple-ssa-warn-restrict.c:927 since r257860

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84526

--- Comment #8 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #7)
> (In reply to Jakub Jelinek from comment #5)
> > 
> > What is the TREE_OPERAND (expr, 0) in:
> >   base = get_inner_reference (expr, , , _off,
> >   , , , );
> >  
> >   poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
> >   
> >   HOST_WIDE_INT const_off;
> >   if (!base || !bytepos.is_constant (_off))
> > {
> >   base = get_base_address (TREE_OPERAND (expr, 0));
> >   return;
> > }
> > doing?  It doesn't seem you've checked what expr actually is before using
> > TREE_OPERAND (expr, 0) on it.  The cases that fall through into this code 
> > are
> > either that expr is an operand of ADDR_EXPR, or SSA_NAME, or in theory some
> > constant.  I don't think get_inner_reference ever returns NULL though.
> 
> This bit was left over from the previous version that used
> get_addr_base_and_unit_offset() where the function can return null.  If
> get_inner_reference() cannot return null and if the byte offset is

get_inner_reference can't return NULL, just see what it does.  bytepos in
theory could be non-constant on aarch64 with SVE, still, what do you know about
expr that you think you can safely use the operand of it (it couldn't have
one).
Why don't you treat non-constant bytepos as var_off?  Why do you think var_off
must be non-negative?  Perhaps if base is a DECL in correct programs it should
be, but if base is a MEM_REF it can be anything.
And again for if (TREE_CODE (base) == MEM_REF) you set base = TREE_OPERAND
(base, 0);, so what used to be at that point the base of the reference becomes
its address; though if base is instead say a DECL_P or something even
different, you don't do that.

[Bug tree-optimization/84526] [8 Regression] ICE in generic_overlap at gcc/gimple-ssa-warn-restrict.c:927 since r257860

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84526

--- Comment #7 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #5)
> 
> What is the TREE_OPERAND (expr, 0) in:
>   base = get_inner_reference (expr, , , _off,
>   , , , );
>  
>   poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);
>   
>   HOST_WIDE_INT const_off;
>   if (!base || !bytepos.is_constant (_off))
> {
>   base = get_base_address (TREE_OPERAND (expr, 0));
>   return;
> }
> doing?  It doesn't seem you've checked what expr actually is before using
> TREE_OPERAND (expr, 0) on it.  The cases that fall through into this code are
> either that expr is an operand of ADDR_EXPR, or SSA_NAME, or in theory some
> constant.  I don't think get_inner_reference ever returns NULL though.

This bit was left over from the previous version that used
get_addr_base_and_unit_offset() where the function can return null.  If
get_inner_reference() cannot return null and if the byte offset is guaranteed
to be constant the code can be removed.  (I made the change based on your
suggestion in bug 84095 and asked you to review it multiple times before I
committed it.)

[Bug tree-optimization/84526] [8 Regression] ICE in generic_overlap at gcc/gimple-ssa-warn-restrict.c:927 since r257860

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84526

--- Comment #6 from Martin Sebor  ---
The affected bit of code assumes dstref->base is an array and doesn't check to
see if it's something else.  In both of these cases it's a VAR_DECL so
TREE_TYPE (TREE_TYPE (dstref->base)) returns null.

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149

--- Comment #10 from Paul Thomas  ---
Author: pault
Date: Fri Feb 23 16:22:28 2018
New Revision: 257934

URL: https://gcc.gnu.org/viewcvs?rev=257934=gcc=rev
Log:
2018-02-23  Paul Thomas  

PR fortran/83149
* trans-decl.c (gfc_finish_var_decl): Test sym->ns->proc_name
before accessing its components.

2018-02-23  Paul Thomas  

PR fortran/83149
* gfortran.dg/pr83149_1.f90: New test.
* gfortran.dg/pr83149.f90: Additional source for previous.


Added:
trunk/gcc/testsuite/gfortran.dg/pr83149.f90
trunk/gcc/testsuite/gfortran.dg/pr83149_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/84527] missed optimization for special ternary operation

[ktietz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84527

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #6 from Kai Tietz  ---
ah, right. sorry for the noise. thanks for pointing out

[Bug rtl-optimization/84527] missed optimization for special ternary operation

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84527

--- Comment #5 from Jakub Jelinek  ---
No, signed comparison is very different from unsigned comparison, and only
unsigned comparison < is usable for this.  Borrow flag reflects unsigned signed
comparison result rather than signed.

[Bug rtl-optimization/84527] missed optimization for special ternary operation

[ktietz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84527

--- Comment #4 from Kai Tietz  ---
(In reply to Jakub Jelinek from comment #3)
> ..., but that just means it is not the right code for f1 and f3.

Right, that produced code depends on the sign of the condition arguments seems
to be pretty wrong

[Bug c/84531] New: c/c++: bogus warning for functions with different argument lengths but compatible arguments

[siddhesh at gotplt dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84531

Bug ID: 84531
   Summary: c/c++: bogus warning for functions with different
argument lengths but compatible arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: siddhesh at gotplt dot org
  Target Milestone: ---

gcc trunk throws a bogus warning about incompatible function cast when the cast
target and the function have different argument lengths but the same arguments
for the common subset.  An example of this is the PyCFunction <->
PyCFunctionWithKeywords cast in python.

Patch posted along with test case:

https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01315.html

[Bug tree-optimization/84526] [8 Regression] ICE in generic_overlap at gcc/gimple-ssa-warn-restrict.c:927 since r257860

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84526

Martin Sebor  changed:

   What|Removed |Added

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

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #19 from Segher Boessenkool  ---
.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

Segher Boessenkool  changed:

   What|Removed |Added

Version|7.0 |8.0
 Depends on||79455

--- Comment #18 from Segher Boessenkool  ---
It fails on 7 (and always has).  The fix for PR79455 needs to be applied before
this one can be.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79455
[Bug 79455] c-c++-common/tsan/race_on_mutex.c fails on powerpcle starting with
r244854 (where it was activated)

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||8.0
 Resolution|--- |FIXED

--- Comment #17 from Martin Liška  ---
Let's close it, if somebody sees problem on GCC 7, then we should reopen it.

[Bug fortran/84412] [7/8 Regression] Erroneous "Inquire statement identifies an internal file" error

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84412

Thomas Koenig  changed:

   What|Removed |Added

 CC||albandil at atlas dot cz

--- Comment #6 from Thomas Koenig  ---
*** Bug 84529 has been marked as a duplicate of this bug. ***

[Bug libfortran/84529] INQUIRE fails on "recycled" internal units

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84529

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||tkoenig at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Thomas Koenig  ---
Dup of 84412, which is going to be fixed, patch can be found at

https://gcc.gnu.org/ml/fortran/2018-02/msg00121.html

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

[Bug c++/84447] [8 Regression] ICE with inherited deleted constructor and default argument

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84447

--- Comment #2 from Jakub Jelinek  ---
My understanding is that this is because cand->fn in this case (the B ctor) is
not DECL_DELETED_FN, but strip_inheriting_ctors (cand->fn) is, we somehow
haven't tried to instantiate it (bailed early) and when we get into
convert_default_arg, we try it with the non-instantiated A(T, T = 0) rather
than
with A(T, T = 0) [with T = int].  Returning error_mark_node from
convert_default_arg in that case doesn't work though, because the bug is not
diagnosed at all.

[Bug target/84530] New: -mfunction-return=thunk does not work for simple_return_pop_internal insn

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84530

Bug ID: 84530
   Summary: -mfunction-return=thunk does not work for
simple_return_pop_internal insn
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hjl at gcc dot gnu.org, hubicka at ucw dot cz
  Target Milestone: ---
Target: i586

i386.md contains:

 13100  (define_insn "simple_return_pop_internal"
 13101[(simple_return)
 13102 (use (match_operand:SI 0 "const_int_operand"))]
 13103"reload_completed"
 13104"%!ret\t%0"
 13105[(set_attr "length" "3")
 13106 (set_attr "atom_unit" "jeu")
 13107 (set_attr "length_immediate" "2")
 13108 (set_attr "modrm" "0")
 13109 (set_attr "maybe_prefix_bnd" "1")])

Thus:

$ cat stdarg.c 
struct s { _Complex unsigned short x; };
struct s gs = { 100 + 200i };
struct s __attribute__((noinline)) foo (void) { return gs; }

$ gcc stdarg.c -S -O2 -m32 -o/dev/stdout  -mfunction-return=thunk
.file   "stdarg.c"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movl4(%esp), %eax
movlgs, %edx
movl%edx, (%eax)
ret $4
.cfi_endproc
.LFE0:
.size   foo, .-foo
.globl  gs
.data
    .align 4
.type   gs, @object
.size   gs, 4
gs:
.value  100
.value  200
.ident  "GCC: (GNU) 8.0.1 20180223 (experimental)"
.section.note.GNU-stack,"",@progbits

While x86-64 works:
gcc stdarg.c -S -O2  -o/dev/stdout  -mfunction-return=thunk
.file   "stdarg.c"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movzwl  gs+2(%rip), %eax
sall$16, %eax
movl%eax, %edx
movzwl  gs(%rip), %eax
orl %edx, %eax
jmp __x86_return_thunk
.cfi_endproc
.LFE0:
.size   foo, .-foo
.globl  gs
.data
.align 2
.type   gs, @object
.size   gs, 4
gs:
.value  100
.value  200
.section   
.text.__x86_indirect_thunk,"axG",@progbits,__x86_indirect_thunk,comdat
.globl  __x86_indirect_thunk
.hidden __x86_indirect_thunk
.type   __x86_indirect_thunk, @function
__x86_indirect_thunk:
.set__x86_return_thunk,__x86_indirect_thunk
.globl  __x86_return_thunk
.hidden __x86_return_thunk
.LFB1:
.cfi_startproc
    call    .LIND1
.LIND0:
pause
lfence
jmp .LIND0
.LIND1:
lea 8(%rsp), %rsp
ret
.cfi_endproc
.LFE1:
.ident  "GCC: (GNU) 8.0.1 20180223 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #16 from Segher Boessenkool  ---
Fixed on trunk.  Does this actually fail on GCC 7?  The regexp there should
work AFAICS.

[Bug target/84528] [8 Regression] gcc.c-torture/execute/960419-2.c -O3 fails with -fno-omit-frame-pointer

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84528

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Bah, this'll be https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02061.html .  I
hadn't realised that the -fomit-frame-pointer handling was the reason it was no
longer a problem.

[Bug target/84528] [8 Regression] gcc.c-torture/execute/960419-2.c -O3 fails with -fno-omit-frame-pointer

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84528

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Started with r256532.

[Bug libfortran/84529] New: INQUIRE fails on "recycled" internal units

[albandil at atlas dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84529

Bug ID: 84529
   Summary: INQUIRE fails on "recycled" internal units
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: albandil at atlas dot cz
  Target Milestone: ---

The following program fails with the error "Inquire statement identifies an
internal file" at the call to INQUIRE.

  program TestRecycleInternalUnit

implicit none

integer :: iunit, ipos
character(len=10) :: sstream

write(sstream,'(I0)') 12345
print *, 'sstream = ', sstream

open(newunit=iunit, file='output.bin', access="stream", form="unformatted")
inquire(iunit,pos=ipos)
print *, 'n = ', ipos
close(iunit)

  end program TestRecycleInternalUnit

I looked into the code of libgfortran/io/open.c (and around) and it seems that
OPEN reuses the cached internal unit (-10 in this case) used for writing to
string. However, the member "internal_unit_kind" of the unit structure is not
reset to 0 in the "st_open" function. This makes the subsequent INQUIRE think
that its argument is an internal unit.

[Bug c++/84286] [8 Regression] Segmentation fault of a chromium binary

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84286

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Martin Liška  ---
Can't reproduce even before the revision, I must have the setup somehow broken.
But the package now builds, so it's fixed.

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #15 from Segher Boessenkool  ---
Author: segher
Date: Fri Feb 23 14:17:35 2018
New Revision: 257932

URL: https://gcc.gnu.org/viewcvs?rev=257932=gcc=rev
Log:
Fix tsan race_on_mutex.c testcase (PR80551)

The testcase did not match the glibc internal names while it should.
This fixes it.


gcc/testsuite/
PR testsuite/80551
* c-c++-common/tsan/race_on_mutex.c: Change regexp to allow
__GI___pthread_mutex_init as well.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/tsan/race_on_mutex.c

[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"

[laurent at guerby dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496

--- Comment #21 from Laurent GUERBY  ---
I'm not familiar with mips ABIs but on gcc mips machine there's 32 bit code.

root@erpro8-fsf1:~# file /bin/ls
/bin/ls: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.26,
BuildID[sha1]=0x2b2fe81ce221a20ae62f4d516d1553fab61f9087, with unknown
capability 0x4100 = 0xf676e75, with unknown capability 0x1 = 0x70401,
stripped

root@erpro8-fsf1:~# gcc -dumpspecs
...
mabi=n32/mabi=32/mabi=64

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #14 from Jakub Jelinek  ---
Changing that (__)? to ((__GI_)?__)? is preapproved if it works.
Those are just glibc internal aliases which are in the symbol table too though,
so if you have full debug info for libpthread.so rather than just what .dynsym
contains it is possible you get it instead.

[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #20 from Martin Liška  ---
But the machine is mips64:
Linux erpro8-fsf2 4.1.4 #1 SMP PREEMPT Mon Aug 3 14:22:54 PDT 2015 mips64
GNU/Linux

Is it a target where I can reproduce the issue? Which --target option do you
use for a cross-compiler?

[Bug testsuite/80551] c-c++-common/tsan/race_on_mutex.c fails on powerpc

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80551

--- Comment #13 from Segher Boessenkool  ---
It is trying to match

#[01] (__)?pthread_mutex_init

but instead it gets

#1 __GI___pthread_mutex_init

[Bug c++/84286] [8 Regression] Segmentation fault of a chromium binary

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84286

--- Comment #9 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #8)
> Isn't this dup of PR84502 and thus fixed with r257892?

Very probably, let me test it.

[Bug fortran/77746] [6/7/8 Regression] [F03] Wrong subroutine called, clash of specific procedure name and binding-name

[dev-zero at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77746

Tiziano Müller  changed:

   What|Removed |Added

 CC||dev-zero at gentoo dot org

--- Comment #4 from Tiziano Müller  ---
There is an even simpler reproducer and slightly different twist, but I suspect
it's the same bug:

test.c:
  void bar();
  int main(int argc, char* argv[]) {
  bar();
  return 0;
  }

works as expected with any version with gcc and the following Fortran file:

foo_c_standalone.f90:

  module foo_c
  use iso_c_binding
  contains
  subroutine bar()
  write(*,*) "bar"
  end
  subroutine c_bar() bind(C, name="bar")
  write(*,*) "c_bar"
  call bar()
  end
  end module

while it terminates with a segfault due to the recursive call with gcc-5.3.1,
gcc-7.3.0 (and probably also gcc-4.9+) but works with gcc-4.8.5 with the
following code instead:

foo_c.f90:
  module foo_c
  use iso_c_binding
  use foo
  contains
  subroutine c_bar() bind(C, name="bar")
  write(*,*) "c_bar"
  call bar()
  end
  end module

foo.f90:
  module foo
  contains
  subroutine bar()
  write(*,*) "bar"
  end
  end

[Bug c++/70468] [6/7/8 Regression] ICE on invalid code on x86_64-linux-gnu in emit_mem_initializers, at cp/init.c:1109

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70468

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Fri Feb 23 13:32:41 2018
New Revision: 257931

URL: https://gcc.gnu.org/viewcvs?rev=257931=gcc=rev
Log:
PR c++/70468 - ICE with constructor delegation via typedef.

* pt.c (tsubst_initializer_list): Check for other mem-initializers
with constructor delegation.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/dc9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug debug/83917] [8 Regression] with -mcall-ms2sysv-xlogues, stepping into x86 tail-call restore stub gives bad backtrace

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83917

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2018-02/msg01294.htm
   ||l
   Last reconfirmed||2018-02-23
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Jakub Jelinek  ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2018-02/msg01294.html

[Bug middle-end/84019] [7/8 regression] ICE in fold-const of std::complex division

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84019

--- Comment #7 from Jakub Jelinek  ---
Can you please provide the requested reproducer, even if large?  Otherwise
there is nothing we can do about it and it will be closed as
RESOLVED/WORKSFORME.

[Bug c++/84286] [8 Regression] Segmentation fault of a chromium binary

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84286

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Isn't this dup of PR84502 and thus fixed with r257892?

[Bug c++/84518] [8 Regression] ICE with lambda capturing broken variable

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84518

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P4

--- Comment #3 from Jakub Jelinek  ---
Actually P4, error-recovery...

[Bug c++/84520] [6/7/8 Regression] ICE with lambda and static member function

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84520

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |6.5

--- Comment #1 from Jakub Jelinek  ---
Started with r210292, before it has been accepted.

[Bug c++/84518] [8 Regression] ICE with lambda capturing broken variable

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84518

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug rtl-optimization/84527] missed optimization for special ternary operation

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84527

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Indeed:
int f1 (int a, int b) { return a < b ? -1 : 1; }
int f2 (unsigned a, unsigned b) { return a < b ? -1 : 1; }
unsigned f3 (int a, int b) { return a < b ? -1 : 1; }
unsigned f4 (unsigned a, unsigned b) { return a < b ? -1 : 1; }
shows that we emit the code you want to see for f2 and f4, but that just means
it is not the right code for f1 and f3.

[Bug fortran/32630] [meta-bug] ISO C binding

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630
Bug 32630 depends on bug 83148, which changed state.

Bug 83148 Summary: [8 regression] ICE: crash_signal from toplev.c:325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83148

   What|Removed |Added

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

[Bug fortran/83148] [8 regression] ICE: crash_signal from toplev.c:325

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83148

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #8 from Paul Thomas  ---
Fixed. Thanks for the report.

Paul

[Bug fortran/83148] [8 regression] ICE: crash_signal from toplev.c:325

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83148

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Fri Feb 23 12:35:30 2018
New Revision: 257930

URL: https://gcc.gnu.org/viewcvs?rev=257930=gcc=rev
Log:
2018-02-23  Paul Thomas  

PR fortran/83148
* trans-const.c : Clean up some whitespace issues.
* trans-expr.c (gfc_conv_initializer): If an iso_c_binding
derived type has a kind value of zero, set it to the default
integer kind.

2018-02-23  Paul Thomas  

PR fortran/83148
* gfortran.dg/class_68.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/class_68.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-const.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/60212] missing warning for unused variable

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60212

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=55203
Summary|no warning for unused   |missing warning for unused
   |variables   |variable

--- Comment #2 from Eric Gallager  ---
(In reply to Ali Baharev from comment #0)
> 
> In my opinion, it is NOT a duplicate of:
> 
> No unused warning for variables of non-trivial types
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203
> 

Might still be related though; adding it under "See Also"

[Bug c++/80598] [7/8 regression] -Wunused triggers for functions used in uninstantiated templates

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80598

Eric Gallager  changed:

   What|Removed |Added

  Known to work||4.2.1, 4.5.4, 4.7.4, 4.8.5,
   ||5.5.0, 6.4.0
Summary|-Wunused triggers for   |[7/8 regression] -Wunused
   |functions used in   |triggers for functions used
   |uninstantiated templates|in uninstantiated templates
  Known to fail||7.3.0, 8.0.1

--- Comment #3 from Eric Gallager  ---
Tested with other versions; changing title to reflect that it's a regression

[Bug rtl-optimization/84527] missed optimization for special ternary operation

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84527

--- Comment #2 from Uroš Bizjak  ---
Try with the unsigned arguments.

[Bug fortran/83975] [8 Regression] ICE in set_parm_default_def_partition, at tree-ssa-coalesce.c:1919

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83975

Janne Blomqvist  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Janne Blomqvist  ---
AFAICT Paul Thomas nailed this in r257827, closing as fixed.

[Bug fortran/83344] Use of uninitialized memory with ASSOCIATE and strings

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83344

Janne Blomqvist  changed:

   What|Removed |Added

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

--- Comment #13 from Janne Blomqvist  ---
AFAICT Paul Thomas nailed this in r257827, closing as fixed.

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534
Bug 78534 depends on bug 83344, which changed state.

Bug 83344 Summary: Use of uninitialized memory with ASSOCIATE and strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83344

   What|Removed |Added

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

[Bug fortran/84509] STOP and ERROR STOP statements with -fdefault-integer-8 and large stop code

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84509

Janne Blomqvist  changed:

   What|Removed |Added

Summary|STOP and PAUSE statements   |STOP and ERROR STOP
   |with -fdefault-integer-8|statements with
   |and large stop code |-fdefault-integer-8 and
   ||large stop code

--- Comment #3 from Janne Blomqvist  ---
r257903 fixed the PAUSE statement, changing title to make clear STOP and ERROR
STOP are unfixed.

[Bug fortran/84519] STOP and ERROR STOP statements with QUIET specifier

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84519

Janne Blomqvist  changed:

   What|Removed |Added

   Assignee|jb at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #3 from Janne Blomqvist  ---
Unassigning myself in case someone else wants to tackle the parsing part for
GCC 9.

[Bug tree-optimization/84526] [8 Regression] ICE in generic_overlap at gcc/gimple-ssa-warn-restrict.c:927 since r257860

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84526

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Slightly cleaned up testcase:

struct S { int a; char b[10]; } d;
__SIZE_TYPE__ s;

void
foo (void)
{
  __builtin_strncpy (d.b, (char *) , s);
}

This code is a ticking bomb.
What is the base set builtin_memref::set_base_and_offset ?
Seems it is called with expr that is a pointer to something (i.e. arguments of
some strncpy-like function), but sometimes it sets base to the passed expr
(i.e. pointer to that memory), at other times to what it points to, at other
times to the get_inner_reference of what it points to.  Without a clear
agreement of what it is obviously spots like the new:
tree basetype = TREE_TYPE (TREE_TYPE (dstref->base));
are wrong, because it doesn't know if base is the pointer pointing to something
(the TREE_TYPE (TREE_TYPE (dstref->base)) assumes that and assumes it is a
POINTER_TYPE_P), or not.
If you sometimes need the pointer and sometimes what it points to, then either
you should have a flag that determines what base is, or better use different
members for pointer and base of what it points to.

What is the TREE_OPERAND (expr, 0) in:
  base = get_inner_reference (expr, , , _off,
  , , , );

  poly_int64 bytepos = exact_div (bitpos, BITS_PER_UNIT);

  HOST_WIDE_INT const_off;
  if (!base || !bytepos.is_constant (_off))
{
  base = get_base_address (TREE_OPERAND (expr, 0));
  return;
}
doing?  It doesn't seem you've checked what expr actually is before using
TREE_OPERAND (expr, 0) on it.  The cases that fall through into this code are
either that expr is an operand of ADDR_EXPR, or SSA_NAME, or in theory some
constant.  I don't think get_inner_reference ever returns NULL though.

[Bug target/84528] [8 Regression] gcc.c-torture/execute/960419-2.c -O3 fails with -fno-omit-frame-pointer

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84528

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Priority|P1  |P3
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-23
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
We are about to turn fno-omit-frame-pointer back on for gcc-8 so this is
probably important.

Usually the RM's need to set this to P1 - so keeping this at P3 for an RM to
confirm this goes up to P1 or P2.

[Bug target/83496] MIPS BE: wrong code generates under "-Os -mbranch-cost=1"

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83496

--- Comment #19 from Martin Liška  ---
(In reply to Laurent GUERBY from comment #18)
> Marxin, you have a cfarm account and access to gcc22 / 23 / 24 which are
> mips64 machines. If you need to change ssh keys see here:
> https://cfarm.tetaneutral.net/login/

Works for me, thank you.