[Bug target/84547] New: Suboptimal code for masked shifts (ARM64)

[nruslan_devel at yahoo dot com]

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

Bug ID: 84547
   Summary: Suboptimal code for masked shifts (ARM64)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nruslan_devel at yahoo dot com
  Target Milestone: ---

Partially related to the Bug 84431 (see description of the problem there) but
observed on ARM64 instead of x86/x86-64. (Not sure about ARM32.)

Test example:

__uint128_t func(__uint128_t a, unsigned shift)
{
   return a << (shift & 63);
}

aarch64-linux-gnu-gcc-7 -Wall -O2 -S test.c

GCC generates:
func:
and w2, w2, 63
mov w4, 63
sub w5, w4, w2
lsr x4, x0, 1
sub w3, w2, #64
lsl x1, x1, x2
cmp w3, 0
lsr x4, x4, x5
orr x1, x4, x1
lsl x4, x0, x3
lsl x0, x0, x2
cselx1, x4, x1, ge
cselx0, x0, xzr, lt
ret


While clang/llvm generates better code:

func:   // @func
// BB#0:
and w8, w2, #0x3f
lsr x9, x0, #1
eor x11, x8, #0x3f
lsl x10, x1, x8
lsr x9, x9, x11
orr x1, x10, x9
lsl x0, x0, x8
ret


Another interesting case when __builtin_unreachable() is used:

__uint128_t func(__uint128_t a, unsigned shift)
{
if (shift > 63)
__builtin_unreachable();
return a << shift;
}

But in this case, neither clang/llvm, nor gcc seem to be able to optimize code
well.

[Bug c/84531] 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

--- Comment #2 from Siddhesh Poyarekar  ---
There's also a PyCFunctionWithoutArgs that takes just one parameter so it'll
have to be one arg onwards but I don't know the impact on it's API. I'm going
to test that when I get back home tonight and propose a fix in Python. I kinda
understand the rationale behind not diluting the warning, but I'd like to keep
this open pending conclusion of the discussion on the ML.

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

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #43494|0   |1
is obsolete||

--- Comment #2 from H.J. Lu  ---
Comment on attachment 43494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43494
A patch

The patch is posted at

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

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Sun, Feb 25, 2018 at 12:13:09AM +, dominiq at lps dot ens.fr wrote:
> > Patched to mailing list.
> 
> Patch at https://gcc.gnu.org/ml/fortran/2018-01/msg00192.html which seems to
> have never been applied. What is the problem?
> 

Haven't gotten around to committing it.  Need to separate out
out diffs.

[Bug fortran/69420] ICE: tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:5618

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres  ---
The ICE is fixed by Kargl's patch for pr83633.

[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> Patched to mailing list.

Patch at https://gcc.gnu.org/ml/fortran/2018-01/msg00192.html which seems to
have never been applied. What is the problem?

[Bug fortran/84546] New: [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

[neil.n.carlson at gmail dot com]

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

Bug ID: 84546
   Summary: [7/8 Regression] Bad sourced allocation of CLASS(*)
with source with CLASS(*) component
   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: ---

The following example produces the expected result with 6.4.1, but not with the
latest 7 and 8 trunk.  The correct output is "foobar", but 7/8 produce "foob"

module any_vector_type

  type :: any_vector
class(*), allocatable :: vec(:)
  end type

  interface any_vector
procedure any_vector1
  end interface

contains

  function any_vector1(vec) result(this)
class(*), intent(in) :: vec(:)
type(any_vector) :: this
allocate(this%vec, source=vec)
  end function

end module

program main

  use any_vector_type
  implicit none

  class(*), allocatable :: x
  character(*), parameter :: vec(*) = ['foo','bar']

  allocate(x, source=any_vector(vec))

  select type (x)
  type is (any_vector)
select type (xvec => x%vec)
type is (character(*))
  print *, xvec ! EXPECT "foobar"
  if (any(xvec /= vec)) stop 1
end select
  end select

end program

[Bug debug/84545] New: FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)

[danglin at gcc dot gnu.org]

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

Bug ID: 84545
   Summary: FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for
excess errors)
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/h
ome/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../
/home/dave/gnu/gcc/gcc/gcc/test
suite/g++.dg/debug/pr44182.C -fno-diagnostics-show-caret
-fdiagnostics-color=nev
er -nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/h
ppa-linux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include
-I
/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/gcc/gcc/libstdc++
-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util
-fmess
age-length=0 -gdwarf-2 -O2 -fcompare-debug -S -o pr44182.s
xg++: error: /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/debug/pr44182.C:
-fcomp
are-debug failure (length)
compiler exited with status 1
FAIL: g++.dg/debug/pr44182.C -gdwarf-2 -O2 (test for excess errors)

First seen r257868.

There are a slew of similar fails.

[Bug c++/84540] [6/7/8 Regression] ICE with alignas in variadic template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-24
 CC||msebor at gcc dot gnu.org
  Known to work||5.4.0
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.3.0, 8.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r232701:

r232701 | jason | 2016-01-21 15:26:02 -0500 (Thu, 21 Jan 2016) | 5 lines

PR c++/43407
* decl.c (start_enum): Add attributes parameter.
* parser.c (cp_parser_enum_specifier): Pass it.
* pt.c (lookup_template_class_1): Pass it.
* cp-tree.h: Adjust.

[Bug c++/84544] New: Missing warning when returning a reference to internal variable inside a lambda

[jpakkane at gmail dot com]

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

Bug ID: 84544
   Summary: Missing warning when returning a reference to internal
variable inside a lambda
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jpakkane at gmail dot com
  Target Milestone: ---

Suppose you have a C++14 method like this:

auto f1() {
int x = 3;
auto l = [&]() -> int& { return x; };
return l;
}

Here the returned lambda contains a reference to the stack allocated integer
that goes out of scope. Gcc does not give a warning for this. If you call
function f1 like this:

int& f2() {
auto l = f1();
return l();
}

Then Gcc does print the following warning (but only with -O2 or higher):

: In function 'int& f2()':
:9:14: warning: function returns address of local variable
[-Wreturn-local-addr]
 return l();
  ^
:2:9: note: declared here
 int x = 3;
 ^
Compiler returned: 0

It would be useful if gcc generated a warning for f1 already.

[Bug fortran/33056] [Meta-bug] Data - statement related bugs

[kargl at gcc dot gnu.org]

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

Bug 30792 Summary: DATA implied-do substring allowed with -std=f95/f2003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30792

   What|Removed |Added

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

[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

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

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

[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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Feb 24 20:24:27 2018
New Revision: 257964

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

PR fortran/30792
* decl.c (gfc_match_data): Check for invalid substring in
data-implied-do

2018-02-24  Steven G. Kargl 

PR fortran/30792
* gfortran.dg/data_substring.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/data_substring.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/84431] Suboptimal code for masked shifts (x86/x86-64)

[nruslan_devel at yahoo dot com]

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

--- Comment #6 from Ruslan Nikolaev  ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Ruslan Nikolaev from comment #4)
> > Thanks! I was wondering if the patch also fixes the same thing for x86-64
> > (i.e., -m64); in which case we would have something like this:
> > 
> > __uint128_t func(__uint128_t a, unsigned shift)
> > {
> >return a << (shift & 63);
> > }
> 
> Yes, the patch also handles __int128.

Great! Also, another interesting case (with the same idea for -m64 and
__uint128_t) would be this:


gcc -m32 -Wall -O2 -S test.c

unsigned func(unsigned long long a, unsigned shift)
{
return (unsigned) (a >> (shift & 31));
}

In this case, clang generates just a single 'shrd' instruction.

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

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> Confirmed, present since at least r245582.

Forgot to say that the ICE requires a compiler configured with
--enable-checking=yes.

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-24
 Ever confirmed|0   |1

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-24
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed, present since at least r245582.

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Thanks, I can reproduce it with that test case.  Checking for the basic block
being null fixes the SEGV for me.  Let me retest this and post an update for
review.

Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c   (revision 257963)
+++ gcc/tree-ssa-strlen.c   (working copy)
@@ -1856,8 +1856,20 @@ maybe_diag_stxncpy_trunc (gimple_stmt_iterator gsi
  avoid the truncation warning.  */
   gsi_next_nondebug ();
   gimple *next_stmt = gsi_stmt (gsi);
+  if (!next_stmt)
+{
+  /* When there is no statement in the same basic block check
+the immediate successor block.  */
+  if (basic_block bb = gimple_bb (stmt))
+   {
+ basic_block nextbb
+   = EDGE_COUNT (bb->succs) ? EDGE_SUCC (bb, 0)->dest : NULL;
+ gimple_stmt_iterator it = gsi_start_bb (nextbb);
+ next_stmt = gsi_stmt (it);
+   }
+}

-  if (!gsi_end_p (gsi) && is_gimple_assign (next_stmt))
+  if (next_stmt && is_gimple_assign (next_stmt))
 {
   tree lhs = gimple_assign_lhs (next_stmt);
   tree_code code = TREE_CODE (lhs);

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

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
The if statement is generating the code:

struct array01_t_spot D.3815;

if ((real(kind=4)[0:] * restrict) ((struct t_spot *)
(rc->spots.data + (sizetype) ((rc->spots.offset + SAVE_EXPR <(integer(kind=8))
k> * rc->spots.dim[0].stride) * D.3815.span)))->vm.data != 0B)

You will see that D.3815's span is being used but is never set.

This temporary is being generated at trans-array.c:3664. It should produce an
assignment of the array descriptor to the temporary, as well as the
declaration.

Somewhere, the se->pre is not being retained so that the assignment disappears.

I am onto it.

Paul

PS
Index: gcc/fortran/trans.c
===
*** gcc/fortran/trans.c (revision 257937)
--- gcc/fortran/trans.c (working copy)
*** get_array_span (tree type, tree decl)
*** 358,364 
{
  if (TREE_CODE (decl) == PARM_DECL)
decl = build_fold_indirect_ref_loc (input_location, decl);
! span = gfc_conv_descriptor_span_get (decl);
}
else
span = NULL_TREE;
--- 358,365 
{
  if (TREE_CODE (decl) == PARM_DECL)
decl = build_fold_indirect_ref_loc (input_location, decl);
! span = TYPE_SIZE_UNIT (gfc_get_element_type (TREE_TYPE (decl)));
! span = fold_convert (gfc_array_index_type, span);
}
else
span = NULL_TREE;

fixes this bug but produces a number of regressions.

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

[neil.n.carlson at gmail dot com]

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

--- Comment #6 from Neil Carlson  ---
... and this would also be invalid

   type t(a)
  integer, len :: a = 3
  character(len=a) :: c = 'foo'
   end type

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

[neil.n.carlson at gmail dot com]

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

--- Comment #5 from Neil Carlson  ---
No, both of those are valid. The constraint is on component initialization, and
type parameters are *not* components.  So something like this would be invalid
by F08:C458

   type t(a)
  integer, len :: a
  character(len=a) :: c = 'foo'
   end type

[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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Feb 24 17:51:09 2018
New Revision: 257963

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

PR fortran/30792
* decl.c (gfc_match_data): Check for invalid substring in
data-implied-do

2018-02-24  Steven G. Kargl 

PR fortran/30792
* gfortran.dg/data_substring.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/data_substring.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
Just to clarify.  Are you saying that this: invalid

   type t(a)
  integer, len :: a
  character(len=a) :: c
   end type

should be: valid

   type t(a)
  integer, len :: a = 2
  character(len=a) :: c
   end type

a is a parameter and c is a component.

?

Some of the I/O touches on pr84143.

[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd

[noloader at gmail dot com]

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

--- Comment #8 from Jeffrey Walton  ---
(In reply to Jeffrey Walton from comment #0)
> According to Intel
> (https://software.intel.com/sites/landingpage/IntrinsicsGuide), there are no
> alignment requirements for _mm_load_sd, _mm_store_sd and _mm_loaddup_pd. For
> example, from _mm_load_sd:
> 
>   Description
> 
> Load a double-precision (64-bit) floating-point element from
> memory into the lower of dst, and zero the upper element.
> mem_addr does not need to be aligned on any particular boundary.

The opening sentence was incorrect. The *_sd functions do not have alignment
requirements. Searching through the Intrinsic Guide reveals the following
functions do not have the alignment requirements:

  * _mm_load_sd
  * _mm_store_sd
  * _mm_load_ss
  * _mm_loadh_pi
  * _mm_loadl_pd
  * _mm_loadl_pi
  * _mm_loadu_pd
  * _mm_loadu_ps
  * _mm_loadu_si128

  * _mm_store_sd
  * _mm_store_ss
  * _mm_storeu_pd
  * _mm_storeu_ps
  * _mm_storeu_si128

All the functions listed above specifically state "mem_addr does not need to be
aligned on any particular boundary."

The remaining functions have natural alignment or 16-byte alignment
requirements.

[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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Feb 24 17:22:10 2018
New Revision: 257962

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

PR fortran/30792
* decl.c (gfc_match_data): Check for invalid substring in
data-implied-do

2018-02-24  Steven G. Kargl 

PR fortran/30792
* gfortran.dg/data_substring.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/data_substring.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-24
 Ever confirmed|0   |1

[Bug fortran/84543] undefined reference to __copy_INTEGER_4_.3788

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-24
 Ever confirmed|0   |1
  Known to fail||7.3.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed for 7.3.0 and trunk (8.0). Compiling the first test in comment 0 with
6.4.0 or earlier gives

Error: Assignment to an allocatable polymorphic variable at (1) is not yet
supported

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[romain.geissler at amadeus dot com]

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

--- Comment #9 from Romain Geissler  ---
Ok I was able to strip down the ICE to this very simple reproducer:

<

static char keyword[4];

static void f (void) { strncpy(keyword, "if  ", 4); }
EOF

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #10 from Dominique d'Humieres  ---
Note that compiling with trunk

type keyword
  character(60), allocatable :: c(:)   ! works but should it?
end type keyword
...
allocate(character(80) :: kw(1)%c(10))

gives the error

 allocate(character(80) :: kw(1)%c(10))
  1
Error: Allocating kw at (1) with type-spec requires the same character-length
parameter as in the declaration


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

Agreed, closing.

[Bug fortran/78238] [7/8 Regression] [OOP] ICE: verify_gimple failed, with -fdefault-integer-8

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #12 from Thomas Koenig  ---
_hash is an integer(4) in all cases:

$ gfortran -fdefault-integer-8 -fdump-fortran-original a.f90 2>/dev/null  |
grep hash
(_hash (INTEGER 4) () PRIVATE) 
(_hash (INTEGER 4) () PRIVATE) 
$ gfortran -fdump-fortran-original a.f90 2>/dev/null  | grep hash
(_hash (INTEGER 4) () PRIVATE) 
(_hash (INTEGER 4) () PRIVATE)

Probably the constant has the wrong type.

[Bug fortran/78238] [7/8 Regression] [OOP] ICE: verify_gimple failed, with -fdefault-integer-8

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #11 from Thomas Koenig  ---
At the place where the ICE happens:

 gcc_checking_assert (precision == x.get_precision ());

(gdb) p precision
$1 = 64
(gdb) p x
$2 = (const generic_wide_int &) @0x7fffca10:
{ = {val = {-1, 140737340585456, 140737340585456}, len = 1, 
precision = 32}, static is_sign_extended = }

Looking up the call chain, the following can be found:

gimple_simplify_174 (res_code=0x7fffcbcc, res_ops=0x7fffcbd0,
type=0x77168b28, captures=0x7fffcad0, cmp=EQ_EXPR, 
valueize=0xad6320 , seq=0x7fffcd18) at
gimple-match.c:7605

so it can be assumed that the type of a comparison goes wrong.

Hmm... there is no difference visible in the tree dumps. However,
there is the line

  if (x->_vptr->_hash == 64409183)

in the dump. Maybe the types on the left and right hand sides do
not agree?

[Bug fortran/84543] New: undefined reference to __copy_INTEGER_4_.3788

[neil.n.carlson at gmail dot com]

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

Bug ID: 84543
   Summary: undefined reference to __copy_INTEGER_4_.3788
   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: ---

I stumbled across this problem while reducing an actual error to a minimal test
case (PR84539).  I wasn't going to bother reporting it (it seems a bit too
silly) but reconsidered. Maybe this means something significant to a developer;
I'll let you decide.

$ cat bug.f90
class(*), allocatable :: x
x = 42
end

$ gfortran bug.f90
/tmp/cclHGRhz.o:(.rodata+0x60): undefined reference to `__copy_INTEGER_4_.3788'
collect2: error: ld returned 1 exit status

And similar with a real or character value, and presumably with any of the
kinds that gfortran supports. The link error goes away if you add a TYPE IS
clause for the type of the value; e.g.

class(*), allocatable :: x
x = 42
select type (x)
type is (integer)
end select
end

[Bug fortran/84538] [8 Regression] Array of derived type elements incorrectly accessed in function

[abensonca at gmail dot com]

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

--- Comment #3 from Andrew Benson  ---
Hi Paul,

Thanks for the select type workaround suggestion - I'll do that for now.

[Bug c++/84542] missing -Wdeprecated-declarations on a redeclared function template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Martin Sebor  ---
This never worked correctly in GCC so it's not a regression.  It works as
expected in Clang and ICC, and with [[deprecated]] also in MSVC.

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[romain.geissler at amadeus dot com]

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

--- Comment #8 from Romain Geissler  ---
I am currently testing a little variant of your patch (check that "nextbb" if
not NULL before trying to use it):

Index: gcc/tree-ssa-strlen.c
===
--- gcc/tree-ssa-strlen.c   (revision 257796)
+++ gcc/tree-ssa-strlen.c   (working copy)
@@ -1851,8 +1851,21 @@ maybe_diag_stxncpy_trunc (gimple_stmt_iterator gsi
  avoid the truncation warning.  */
   gsi_next_nondebug ();
   gimple *next_stmt = gsi_stmt (gsi);
+  if (!next_stmt)
+{
+  /* When there is no statement in the same basic block check
+the immediate successor block.  */
+  basic_block bb = gimple_bb (stmt);
+  basic_block nextbb
+   = EDGE_COUNT (bb->succs) ? EDGE_SUCC (bb, 0)->dest : NULL;
+  if (nextbb)
+{
+  gimple_stmt_iterator it = gsi_start_bb (nextbb);
+  next_stmt = gsi_stmt (it);
+}
+}

-  if (!gsi_end_p (gsi) && is_gimple_assign (next_stmt))
+  if (next_stmt && is_gimple_assign (next_stmt))
 {
   tree lhs = gimple_assign_lhs (next_stmt);
   tree_code code = TREE_CODE (lhs);


If it doesn't work, I will provide you with the translation unit.

[Bug c++/84542] New: missing -Wdeprecated-declarations on a redeclared function template

[msebor at gcc dot gnu.org]

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

Bug ID: 84542
   Summary: missing -Wdeprecated-declarations on a redeclared
function template
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Redeclaring an ordinary function with the deprecated attribute makes the
attribute effective on subsequent uses of the function.

However, redeclaring a function template with the same attribute has no effect
(regardless of whether the template has been defined).

$ cat a.C && gcc -S -Wall a.C
void f ();

void __attribute__ ((deprecated)) f ();

void ff ()
{
  f ();   // -Wdeprecated-declarations (good)
}

template 
void g ();

template 
void __attribute__ ((deprecated)) g ();

void gg ()
{
  g();   // missing warning
}

template 
void __attribute__ ((deprecated)) g () { }

void ggg ()
{
  g();   // missing warning
}

a.C: In function ‘void ff()’:
a.C:7:6: warning: ‘void f()’ is deprecated [-Wdeprecated-declarations]
   f ();   // -Wdeprecated-declarations (good)
  ^
a.C:3:35: note: declared here
 void __attribute__ ((deprecated)) f ();
   ^

[Bug tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Thanks for the early heads up!  Can you please attach the translation unit for
the kernel file that GCC faults on?

[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 #6 from Jerry DeLisle  ---
The patch fixes the first part of the problem so the write will ignore the kind
and len parameters.

The component n is simply not being initialized at all. I am searching code for
where this ought to happen. I was thinking possibly in build_struct in decl.c,
but I am not sure yet.

[Bug c++/84541] New: [8 Regression] ICE with auto in function parameter

[reichelt at gcc dot gnu.org]

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

Bug ID: 84541
   Summary: [8 Regression] ICE with auto in function parameter
   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 invalid code snippet (compiled with "-fconcepts") triggers
an ICE since GCC 6.1.0:

===
template struct A
{
  static const bool b = true;
};

static_assert(A::b, "");
===

bug.cc:6:36: internal compiler error: Segmentation fault
 static_assert(A::b, "");
^
0xeb1cef crash_signal
../../gcc/gcc/toplev.c:325
0x99e667 add_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:390
0x9129e1 cp_parser_static_assert
../../gcc/gcc/cp/parser.c:13936
0x93d35e cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:12866
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 tree-optimization/84468] [8 Regression] bogus -Wstringop-truncation despite assignment after conditional strncpy

[romain.geissler at amadeus dot com]

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

--- Comment #6 from Romain Geissler  ---
Hi,

Tried to apply this patch on top of current trunk. During my build process, I
bootstrap a complete Linux/binutils/glibc/gcc toolchain following the Linux
From Scratch guidelines.

Without the patch, the bootstrap works fine. With the patch, the bootstrap
fails when using a newly built gcc 8, I try to build the Linux headers. Here
are the logs I have:

+ cd /workdir/src/linux-2.6.32.23
+ make mrproper
+ make INSTALL_HDR_PATH=dest headers_install
  CHK include/linux/version.h
  UPD include/linux/version.h
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/basic/hash
  HOSTCC  scripts/unifdef
In file included from
/home/jenkins/workspace/OTF_Toolchain_release_4.0-YQJ6EBM33XTPWHNNQSFSZFEGBOIWUEOX32S2OZLINN43UBSUZTJA/output/build/temporary-system/install/include/string.h:630,
 from scripts/unifdef.c:72:
scripts/unifdef.c: In function 'Mpass':
scripts/unifdef.c:377:28: internal compiler error: Segmentation fault
 static void Mpass (void) { strncpy(keyword, "if  ", 4); Pelif(); }

^~~

scripts/unifdef.c:377:28: internal compiler error: Aborted
gcc: internal compiler error: Aborted signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
scripts/Makefile.host:118: recipe for target 'scripts/unifdef' failed
make[1]: *** [scripts/unifdef] Error 4
Makefile:1089: recipe for target '__headers' failed
make: *** [__headers] Error 2


I expect that you would be able to reproduce the same error by downloading the
Linux headers
(https://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.23.tar.gz) and then:

make mrproper
make INSTALL_HDR_PATH=dest headers_install


This file is actually pretty simple. See
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/scripts/unifdef.c?h=v2.6.32.23#n377

...
static void Pelif (void) { print(); ignoreoff(); state(IS_PASS_MIDDLE); }
...
static void Mpass (void) { strncpy(keyword, "if  ", 4); Pelif(); }
...

Maybe the fact that the instruction that follows strncpy is a function call
makes gcc seg faults ?

Cheers,
Romain

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

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
Created attachment 43494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43494=edit
A patch

I am testing this patch.

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

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-24
Version|unknown |8.0.1
 Blocks||84072
   Target Milestone|--- |8.0
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84072
[Bug 84072] [meta-bug] -mindirect-branch=thunk issues

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
I think just 

--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -5541,6 +5541,10 @@ bool
 suggest_alternative_in_explicit_scope (location_t location, tree name,
   tree scope)
 {
+  /* Something went very wrong; don't suggest anything.  */
+  if (name == error_mark_node)
+return false;
+
   /* Resolve any namespace aliases.  */
   scope = ORIGINAL_NAMESPACE (scope);


should do.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Started with r255336.

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

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Comparing the outputs of -fDump-tree-original for r257064 and r257065 shows:

--- pr84523.f90.003t.original_652018-02-24 14:45:17.0 +0100
+++ pr84523.f90.003t.original_642018-02-24 14:44:32.0 +0100
...
@@ -116,32 +116,32 @@ construct (struct t_rowcol & restrict rc
 *rc = t_rowcol.6;
   }
   {
-integer(kind=8) D.3821;
-integer(kind=4) D.3822;
-integer(kind=8) D.3823;
-integer(kind=8) D.3824;
-integer(kind=4) D.3825;
+integer(kind=8) D.3815;
+integer(kind=4) D.3816;
+integer(kind=8) D.3817;
+integer(kind=8) D.3818;
+integer(kind=4) D.3819;
 unsigned long size.2;
-logical(kind=4) D.3827;
+logical(kind=4) D.3821;
 integer(kind=4) overflow.3;

 rc->nh = *nh;
-rc->spots.dtype = {.elem_len=112, .rank=1, .type=5};
-D.3821 = (integer(kind=8)) MAX_EXPR <*nh, 0>;
-D.3822 = NON_LVALUE_EXPR ;
-D.3823 = NON_LVALUE_EXPR ;
-D.3824 = D.3823;
-D.3825 = ((unsigned long) D.3823 > 164703072086692425 ? 1 : 0) + D.3822;
^
-D.3827 = *nh <= 0;
-if (D.3827)
+rc->spots.dtype = 6697;
+D.3815 = (integer(kind=8)) MAX_EXPR <*nh, 0>;
+D.3816 = NON_LVALUE_EXPR ;
+D.3817 = NON_LVALUE_EXPR ;
+D.3818 = D.3817;
+D.3819 = ((unsigned long) D.3817 > 177372539170284150 ? 1 : 0) + D.3816;
^
+D.3821 = *nh <= 0;
+if (D.3821)
   {
 size.2 = 0;
   }
 else
   {
-size.2 = (unsigned long) D.3823 * 112;
+size.2 = (unsigned long) D.3817 * 104;
   }
-overflow.3 = D.3825;
+overflow.3 = D.3819;
 if (overflow.3 != 0)
   {
 _gfortran_runtime_error (&"Integer overflow when calculating the
amount of memory to allocate"[1]{lb: 1 sz: 1});
@@ -158,57 +158,57 @@ construct (struct t_rowcol & restrict rc
 rc->spots.dim[0].ubound = (integer(kind=8)) *nh;
 rc->spots.dim[0].stride = 1;
 rc->spots.offset = -1;
-rc->spots.span = 112;
  ^
+rc->spots.span = 104;
  ^
 {
...

[Bug fortran/84538] [8 Regression] Array of derived type elements incorrectly accessed in function

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Hi Andrew,

The testcase gives the same result if 'n' in the main program is a pointer.
However, if the dummy is given the allocatable/pointer attribute, as
appropriate, then the correct result is obtained.

Otherwise, using select type works correctly too.

Please use either of these as a temporary workaround.

I am hunting for where the dummy attribute has been missed in testing for the
need for pointer arithmetic in accessing the array elements.

Thanks for reporting this.

Paul

[Bug c++/83692] Rejects valid constexpr with unrelated code fixing problem

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed for GCC 8.

[Bug c++/83692] Rejects valid constexpr with unrelated code fixing problem

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Sat Feb 24 13:10:44 2018
New Revision: 257961

URL: https://gcc.gnu.org/viewcvs?rev=257961=gcc=rev
Log:
PR c++/83692
* constexpr.c (maybe_constant_init_1): New function.
(maybe_constant_init): Make it a wrapper around maybe_constant_init_1.
(cxx_constant_init): New function.
* cp-tree.h (cxx_constant_init): Declare.
* typeck2.c (store_init_value): Call cxx_constant_init instead of
cxx_constant_value.  Move the maybe_constant_init call under an 'else'.

* g++.dg/cpp1z/constexpr-83692.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-83692.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres  ---
Caused by revision r257065.

[Bug c++/84540] New: [6/7/8 Regression] ICE with alignas in variadic template

[reichelt at gcc dot gnu.org]

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

Bug ID: 84540
   Summary: [6/7/8 Regression] ICE with alignas in variadic
template
   Product: gcc
   Version: unknown
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 valid code snippet triggers an ICE since GCC 6.1.0,
while it was accepted in GCC 5.2.0 - 5.4.0:

=
template struct alignas(alignof(T)...) A {};

A<> a;
=

bug.cc: In instantiation of 'struct A<>':
bug.cc:3:5:   required from here
bug.cc:1:55: internal compiler error: Segmentation fault
 template struct alignas(alignof(T)...) A {};
   ^
0xeb1cef crash_signal
../../gcc/gcc/toplev.c:325
0x97866d contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3245
0x97866d apply_late_template_attributes
../../gcc/gcc/cp/pt.c:10318
0x989727 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:10550
0x989727 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:10930
0x9ce93d complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:136
0x87f5b7 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:5201
0x8a52ff start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:5164
0x934a89 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:19578
0x93c1c8 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13044
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.]

Btw, clang 6.0.0rc2 accepts the code.

[Bug fortran/84538] [8 Regression] Array of derived type elements incorrectly accessed in function

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-24
 CC||tkoenig at gcc dot gnu.org
   Target Milestone|--- |8.0
Summary|Array of derived type   |[8 Regression] Array of
   |elements incorrectly|derived type elements
   |accessed in function|incorrectly accessed in
   ||function
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
7.3.1 works, trunk fails.

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

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #1 from Bernd Edlinger  ---
The suggested wild-card function type for functions taking 2 or more parameters
would be something like this:

PyObject * (*) (PyObject *, PyObject *, ...);

It is still necessary to cast it back to the correct type before calling.