[Bug fortran/85547] Run-time error: character array constructor

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
workaround.  Create a temporary.

  character(len=:), allocatable :: s(:)
  path = 'xyz/'
  s = (/ character(16) :: &
  trim(path) // "one",  &
  trim(path) // "three",  &
  trim(path) // "five",  &
  trim(path) // "eight",  &
  trim(path) // "forty two" /)
  call print_strings (s)

[Bug fortran/85547] Run-time error: character array constructor

[w6ws at earthlink dot net]

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

--- Comment #2 from Walter Spector  ---
Third variant.  This one messes up NAG and PGI too:

wws@w6ws-4:/tmp$ cat testch3.f90
program testch
  implicit none

  character(:), allocatable :: path(:)
  path = 'xyz/'
  path = (/ character(16) :: &
  path // "one",  &
  path // "three",  &
  path // "five",  &
  path // "eight",  &
  path // "forty two" /)
  call print_strings (path)

contains

  subroutine print_strings (s)
character(*), intent(in) :: s(:)

integer :: i

print *, 'character string length:', len (s)
print *, 'array size =', size (s)

do, i=1, size(s)
  print *, i, '>', s(i), '<'
end do

  end subroutine
end program
wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran -g testch3.f90
wws@w6ws-4:/tmp$ a.out

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

Backtrace for this error:
#0  0x7fe073c854af in ???
#1  0x400ea3 in testch
at /tmp/testch3.f90:5
#2  0x401b66 in main
at /tmp/testch3.f90:12
Segmentation fault (core dumped)
wws@w6ws-4:/tmp$

[Bug fortran/85547] Run-time error: character array constructor

[w6ws at earthlink dot net]

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

--- Comment #1 from Walter Spector  ---
Slightly different test case - using allocatable string length instead of the
trims.  However the same problems are evident:

program testch
  implicit none

  character(:), allocatable :: path
  path = 'xyz/'
  call print_strings ((/ character(16) :: &
  path // "one",  &
  path // "three",  &
  path // "five",  &
  path // "eight",  &
  path // "forty two" /) )

contains

  subroutine print_strings (s)
character(*), intent(in) :: s(:)

integer :: i

do, i=1, size(s)
  print *, i, '>', s(i), '<'
end do

  end subroutine
end program
wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran -g testch.f90
wws@w6ws-4:/tmp$ a.out
   1 >xyz/one<
   2 >xyz/thr<
   3 >xyz/fiv<
   4 >xyz/eig<
   5 >xyz/for<
*** Error in `a.out': free(): invalid next size (fast): 0x0217b640 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fac7b49c7e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fac7b4a537a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fac7b4a953c]
a.out[0x401280]
a.out[0x4012c5]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fac7b445830]
a.out[0x400949]
=== Memory map: 
0040-00402000 r-xp  08:0a 40632824  
/tmp/a.out
00601000-00602000 rw-p 1000 08:0a 40632824  
/tmp/a.out
02178000-02199000 rw-p  00:00 0  [heap]
7fac7400-7fac74021000 rw-p  00:00 0 
7fac74021000-7fac7800 ---p  00:00 0 
7fac7b425000-7fac7b5e5000 r-xp  08:0a 20190243  
/lib/x86_64-linux-gnu/libc-2.23.so
7fac7b5e5000-7fac7b7e5000 ---p 001c 08:0a 20190243  
/lib/x86_64-linux-gnu/libc-2.23.so
7fac7b7e5000-7fac7b7e9000 r--p 001c 08:0a 20190243  
/lib/x86_64-linux-gnu/libc-2.23.so
7fac7b7e9000-7fac7b7eb000 rw-p 001c4000 08:0a 20190243  
/lib/x86_64-linux-gnu/libc-2.23.so
7fac7b7eb000-7fac7b7ef000 rw-p  00:00 0 
7fac7b7ef000-7fac7b82e000 r-xp  08:0a 48497154  
/usr/local/gcc-trunk/lib64/libquadmath.so.0.0.0
7fac7b82e000-7fac7ba2d000 ---p 0003f000 08:0a 48497154  
/usr/local/gcc-trunk/lib64/libquadmath.so.0.0.0
7fac7ba2d000-7fac7ba2e000 rw-p 0003e000 08:0a 48497154  
/usr/local/gcc-trunk/lib64/libquadmath.so.0.0.0
7fac7ba2e000-7fac7ba45000 r-xp  08:0a 48497146  
/usr/local/gcc-trunk/lib64/libgcc_s.so.1
7fac7ba45000-7fac7bc44000 ---p 00017000 08:0a 48497146  
/usr/local/gcc-trunk/lib64/libgcc_s.so.1
7fac7bc44000-7fac7bc45000 rw-p 00016000 08:0a 48497146  
/usr/local/gcc-trunk/lib64/libgcc_s.so.1
7fac7bc45000-7fac7bd4d000 r-xp  08:0a 20185261  
/lib/x86_64-linux-gnu/libm-2.23.so
7fac7bd4d000-7fac7bf4c000 ---p 00108000 08:0a 20185261  
/lib/x86_64-linux-gnu/libm-2.23.so
7fac7bf4c000-7fac7bf4d000 r--p 00107000 08:0a 20185261  
/lib/x86_64-linux-gnu/libm-2.23.so
7fac7bf4d000-7fac7bf4e000 rw-p 00108000 08:0a 20185261  
/lib/x86_64-linux-gnu/libm-2.23.so
7fac7bf4e000-7fac7c1b8000 r-xp  08:0a 48497159  
/usr/local/gcc-trunk/lib64/libgfortran.so.5.0.0
7fac7c1b8000-7fac7c3b8000 ---p 0026a000 08:0a 48497159  
/usr/local/gcc-trunk/lib64/libgfortran.so.5.0.0
7fac7c3b8000-7fac7c3ba000 rw-p 0026a000 08:0a 48497159  
/usr/local/gcc-trunk/lib64/libgfortran.so.5.0.0
7fac7c3ba000-7fac7c3bb000 rw-p  00:00 0 
7fac7c3bb000-7fac7c3e1000 r-xp  08:0a 20190239  
/lib/x86_64-linux-gnu/ld-2.23.so
7fac7c5b9000-7fac7c5bd000 rw-p  00:00 0 
7fac7c5de000-7fac7c5e rw-p  00:00 0 
7fac7c5e-7fac7c5e1000 r--p 00025000 08:0a 20190239  
/lib/x86_64-linux-gnu/ld-2.23.so
7fac7c5e1000-7fac7c5e2000 rw-p 00026000 08:0a 20190239  
/lib/x86_64-linux-gnu/ld-2.23.so
7fac7c5e2000-7fac7c5e3000 rw-p  00:00 0 
7ffd9dc1f000-7ffd9dc4 rw-p  00:00 0 
[stack]
7ffd9dd24000-7ffd9dd27000 r--p  00:00 0  [vvar]
7ffd9dd27000-7ffd9dd29000 r-xp  00:00 0  [vdso]
ff60-ff601000 r-xp  00:00 0 
[vsyscall]

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x7fac7b45a4af in ???
#1  0x7fac7b45a428 in ???
#2  0x7fac7b45c029 in ???
#3  0x7fac7b49c7e9 in ???
#4  0x7fac7b4a5379 in ???
#5  0x7fac7b4a953b in ???
#6  0x40127f in testch
at /tmp/testch.f90:11
#7  0x4012c4 in main
at /tmp/testch.f90:11
Aborted (core dumped)
wws@w6ws-4:/tmp$

[Bug fortran/85547] New: Run-time error: character array constructor

[w6ws at earthlink dot net]

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

Bug ID: 85547
   Summary: Run-time error: character array constructor
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: w6ws at earthlink dot net
  Target Milestone: ---

The following compiles with gfortran (v4.8.4, 5.4, and a snapshot of todays
9.0), but abends at run-time.  Note there are actually two problems shown here:
 First, the passed in string size is bad.  It should be '16', not the length of
the first element.  Second, the deallocations after the call fail - which cause
the abend.

This test case runs fine with NAG and PGI.  (I've not tried Intel yet, but I
can if needed.)

wws@w6ws-4:/tmp$ cat testch.f90
program testch
  implicit none

  character(10) :: path
  path = 'xyz/'
  call print_strings ((/ character(16) :: &
  trim(path) // "one",  &
  trim(path) // "three",  &
  trim(path) // "five",  &
  trim(path) // "eight",  &
  trim(path) // "forty two" /) )

contains

  subroutine print_strings (s)
character(*), intent(in) :: s(:)

integer :: i

do, i=1, size(s)
  print *, i, '>', s(i), '<'
end do

  end subroutine
end program
wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran --version
GNU Fortran (GCC) 9.0.0 20180426 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

wws@w6ws-4:/tmp$ /usr/local/gcc-trunk/bin/gfortran -g testch.f90

Running under gdb:

wws@w6ws-4:/tmp$ gdb a.out
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...done.
(gdb) run
Starting program: /tmp/a.out 
   1 >xyz/one<
   2 >xyz/thr<
   3 >xyz/fiv<
   4 >xyz/eig<
   5 >xyz/for<
*** Error in `/tmp/a.out': free(): invalid next size (fast): 0x00605640
***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x76eb87e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x76ec137a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x76ec553c]
/tmp/a.out[0x4012d9]
/tmp/a.out[0x40131e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x76e61830]
/tmp/a.out[0x4008b9]
=== Memory map: 
0040-00402000 r-xp  08:0a 40632824  
/tmp/a.out
00601000-00602000 rw-p 1000 08:0a 40632824  
/tmp/a.out
00602000-00623000 rw-p  00:00 0  [heap]
7000-70021000 rw-p  00:00 0 
70021000-7400 ---p  00:00 0 
76e41000-77001000 r-xp  08:0a 20190243  
/lib/x86_64-linux-gnu/libc-2.23.so
77001000-77201000 ---p 001c 08:0a 20190243  
/lib/x86_64-linux-gnu/libc-2.23.so
77201000-77205000 r--p 001c 08:0a 20190243  
/lib/x86_64-linux-gnu/libc-2.23.so
77205000-77207000 rw-p 001c4000 08:0a 20190243  
/lib/x86_64-linux-gnu/libc-2.23.so
77207000-7720b000 rw-p  00:00 0 
7720b000-7724a000 r-xp  08:0a 48497154  
/usr/local/gcc-trunk/lib64/libquadmath.so.0.0.0
7724a000-77449000 ---p 0003f000 08:0a 48497154  
/usr/local/gcc-trunk/lib64/libquadmath.so.0.0.0
77449000-7744a000 rw-p 0003e000 08:0a 48497154  
/usr/local/gcc-trunk/lib64/libquadmath.so.0.0.0
7744a000-77461000 r-xp  08:0a 48497146  
/usr/local/gcc-trunk/lib64/libgcc_s.so.1
77461000-7766 ---p 00017000 08:0a 48497146  
/usr/local/gcc-trunk/lib64/libgcc_s.so.1
7766-77661000 rw-p 00016000 08:0a 48497146  
/usr/local/gcc-trunk/lib64/libgcc_s.so.1
77661000-77769000 r-xp  08:0a 20185261  
/lib/x86_64-linux-gnu/libm-2.23.so
77769000-

[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Thu, Apr 26, 2018 at 12:54:05AM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526
> 
> --- Comment #3 from Steve Kargl  ---
> On Wed, Apr 25, 2018 at 11:33:34PM +, dominiq at lps dot ens.fr wrote:
> > The code compiles with 6.4.0 and 7.3.0, but not with 6.4.1, 7.3.1,
> > 8.0.1 and trunk (9.0).  This is likely r258347 for gcc8, r258367
> > for gcc7, and r258368 for gcc6.
> 
> Bummer.
> 
> Don't know how to fix this one.
> 
> Workaround is to move checkFmt() to above its first use
> in another function.
> 

Well, I understand the problem a bit now.  In decl.c (lines 3229
to 3248), we have 

  /* If gfortran ends up here, then the len may be reducible to a
 constant.  Try to do that here.  If it does not reduce, simply
 assign len to the charlen.  */
  if (len && len->expr_type != EXPR_CONSTANT)
{
  gfc_expr *e;
  e = gfc_copy_expr (len);
  gfc_reduce_init_expr (e);
  if (e->expr_type == EXPR_CONSTANT)
{
  gfc_replace_expr (len, e);
  if (mpz_cmp_si (len->value.integer, 0) < 0)
mpz_set_ui (len->value.integer, 0);
}
  else
{
  gfc_free_expr (e);
}
  cl->length = len;
}

'gfc_reduce_init_expr (e)' is causing the symbol checkFmt,
which has not previously been seen, to be committed to the
current namespace before the symbol has been resolved.  So,
checkFmt() doesn't have a proper type and gfortran cannot
set it when she finally parses the function.  During the
translation, checkFmt is implicitly typed, which can be
gleaned from 

0x6ce630 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc8/gcc/fortran/trans-expr.c:7918
0x6d0967 gfc_conv_expr_val(gfc_se*, gfc_expr*)<-- from stepping in gdb
../../gcc8/gcc/fortran/trans-expr.c:7975
0x6fed87 gfc_trans_if_1
../../gcc8/gcc/fortran/trans-stmt.c:1427
0x70715a gfc_trans_if(gfc_code*)

What needs to be done is that symbols in the gfc_current_ns
must be save before the call to 'gfc_reduce_init_expr (e)'.
If reduction fails, then the old symbols need to be
restored in the gfc_current_ns and any new symbols added
by 'gfc_reduce_init_expr (e)' need to be removed.  

Unfortunately, I don't know how to do this.

[Bug inline-asm/85546] GCC assumes volatile asm block returns same value in loop

[be11f157cd19c4a2ba1e9c70a38b1a74 at protonmail dot com]

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

--- Comment #1 from be11f157cd19c4a2ba1e9c70a38b1a74 at protonmail dot com ---
The code sample is compiled with

gcc -ffreestanding -nostdlib -nostartfiles main.c

[Bug c/85546] New: GCC assumes volatile asm block returns same value in loop

[be11f157cd19c4a2ba1e9c70a38b1a74 at protonmail dot com]

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

Bug ID: 85546
   Summary: GCC assumes volatile asm block returns same value in
loop
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: be11f157cd19c4a2ba1e9c70a38b1a74 at protonmail dot com
  Target Milestone: ---

Created attachment 44027
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44027=edit
Code that triggers the bug

This code works correctly when compiled with no optimizations. When
optimizations are enabled the while loop in the input() function becomes an
infinite loop. GCC seems to be assuming that the return value of io() cannot
change between iterations of the loop despite the asm block within io() being
declared "volatile".

The program is tested with this input file:

1
1

[Bug c++/69560] x86_64: alignof(uint64_t) produces incorrect results with -m32

[peter at cordes dot ca]

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

Peter Cordes  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #23 from Peter Cordes  ---
Just to recap the current situation (gcc/g++ 8.0.1 20180425):

I ported David Marillat's testcase to work as C or C++
https://godbolt.org/g/QdG2V6.  (And changed it to set global variables instead
of calling printf, so you can see the results from looking at the asm output
instead of running it).

C++11 alignof() now agrees with C11 alignof() (which didn't change) that
alignof(int64_t) is 4 when targeting the i386 System V ABI.

Previously G++'s alignof() reported 8, while gcc's C11 alignof (stdalign.h)
reported 4.  That was the only change: struct-member alignof results are
unchanged, and already matched between C11 and C++11.


4 is the minimum alignment that *any* int64_t, or pointer to int64_t, is
assumed to have when generating code for i386 SysV.  gcc / g++ are allowed to
generate code that breaks if passed a pointer to int64_t that wasn't 4-byte
aligned.  (Auto-vectorization is one case where that can happen on x86:
https://stackoverflow.com/q/47510783/224132).

They're *not* allowed to assume that it's 8-byte aligned unless they can see
the definition and know that a particular int64_t object is over-aligned, e.g.
to its natural alignment of 8, like gcc chooses to do whenever possible (i.e.
outside structs).

So in both C++ and C (and in g++/gcc after this patch), alignof(int64_t) is the
minimum that any allocator must give an int64_t for correctness (in this funky
32-bit ABI), not the recommended alignment that gcc and g++ both already used
whenever ABI struct-packing rules didn't constrain them.

It's also the guaranteed minimum that code can *assume*.  e.g. a
manually-vectorized library function might check alignof(T) == sizeof(T) before
assuming that using 16-byte aligned loads/stores can line up with element
boundaries.  (An array inside a struct { int foo; int64_t arr[10]; } would
violate this for i386 SysV).

Anyway, I think use-cases like these are why the standard is worded the way it
is, and why it makes sense for alignof() to report the guaranteed/required
minimum.  The recommended or actual alignment is useful, too, though, for other
cases, so it's nice that GNU __alignof() is also available to report that.



Semi-related: gcc depends on 8-byte alignment for C11 _Atomic int64_t but still
fails to provide it inside structs on the i386 SysV ABI (Bug 65146), using the
same alignment rules as regular int64_t.

C++11 std::atomic is fine, getting the required natural alignment even
on i386 SysV so SSE2 movq is atomic and lock add is efficient.

This change to what alignof() reports in C++ had no effect on C at all, or on
any alignment choices made by the compiler in either C or C++.  I only mention
it as another interesting case where i386 SysV's under-alignment of 64-bit
types requiring special care, but that one will require an ABI change of some
sort to fix.

[Bug target/85492] riscv64: endless loop when throwing an exception from a constructor

[palmer at gcc dot gnu.org]

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||palmer at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |palmer at gcc dot 
gnu.org

--- Comment #2 from palmer at gcc dot gnu.org ---
After talking with Jim, I have a suspicion this is a glibc bug -- we changed
some stuff in the symbol resolution path as part of the upstreaming process and
I bet we screwed something up.  I'm going to leave this bug open for now but
investigate.

[Bug c++/85545] [8/9 Regression] ICE with static_cast of pointer-to-member-function

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Apr 26 20:32:32 2018
New Revision: 259689

URL: https://gcc.gnu.org/viewcvs?rev=259689=gcc=rev
Log:
PR c++/85545 - ICE with noexcept PMF conversion.

* cvt.c (cp_fold_convert): Handle PMF CONSTRUCTORs directly.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/noexcept-type20.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c

[Bug c++/85545] [8/9 Regression] ICE with static_cast of pointer-to-member-function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/85542] [6/7/8/9 Regression] ICE in check_inquiry, at fortran/expr.c:2426

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Thu, Apr 26, 2018 at 06:47:34PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85542
> 
> --- Comment #2 from kargl at gcc dot gnu.org ---
> (In reply to G. Steinmetz from comment #0)
> > gfortran-8 changed between 20180304 and 20180311.
> > gfortran-7 changed between 20180215 and 20180308.
> > gfortran-6 changed between 20180307 and 20180314.
> > 
> > 
> > $ cat z1.f90
> > function f(x)
> >character(*), intent(in) :: x
> >character((len((x :: f
> >f = x
> > end
> > 
> 
> Workaround: remove superfluous parentheses.
> 

Pesky NULL pointers.

Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c  (revision 259653)
+++ gcc/fortran/expr.c  (working copy)
@@ -2422,7 +2422,7 @@ check_inquiry (gfc_expr *e, int not_restricted)

/* Assumed character length will not reduce to a constant expression
   with LEN, as required by the standard.  */
-   if (i == 5 && not_restricted
+   if (i == 5 && not_restricted && ap->expr->symtree
&& ap->expr->symtree->n.sym->ts.type == BT_CHARACTER
&& (ap->expr->symtree->n.sym->ts.u.cl->length == NULL
|| ap->expr->symtree->n.sym->ts.deferred))

[Bug fortran/85544] [6/7/8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||4.8.5
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-04-26
 CC||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ICE in  |[6/7/8/9 Regression] ICE in
   |gfc_conv_scalarized_array_r |gfc_conv_scalarized_array_r
   |ef, at  |ef, at
   |fortran/trans-array.c:3385  |fortran/trans-array.c:3385
   Target Milestone|--- |6.5
  Known to fail||6.4.0, 7.3.0, 8.0.1, 9.0

--- Comment #2 from Dominique d'Humieres  ---
The test in comment 0 compiles with -fno-frontend-optimize.

[Bug fortran/85543] ICE in update_current_proc_array_outer_dependency, at fortran/resolve.c:3060

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-26
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/85542] [6/7/8/9 Regression] ICE in check_inquiry, at fortran/expr.c:2426

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> gfortran-8 changed between 20180304 and 20180311.
> gfortran-7 changed between 20180215 and 20180308.
> gfortran-6 changed between 20180307 and 20180314.
> 
> 
> $ cat z1.f90
> function f(x)
>character(*), intent(in) :: x
>character((len((x :: f
>f = x
> end
> 

Workaround: remove superfluous parentheses.

[Bug fortran/85542] [6/7/8/9 Regression] ICE in check_inquiry, at fortran/expr.c:2426

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0, 7.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-04-26
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |6.5
  Known to fail||6.4.1, 7.3.1, 8.0.1, 9.0

--- Comment #1 from Dominique d'Humieres  ---
Likely r258347 for gcc8, r258367 for gcc7, and r258368 for gcc6.

[Bug c++/85545] [8/9 Regression] ICE with static_cast of pointer-to-member-function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

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

[Bug c++/85545] [8/9 Regression] ICE with static_cast of pointer-to-member-function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-26
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug c/55976] -Werror=return-type should error on returning a value from a void function

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Dave Pagan from comment #6)
> Helpful update, Jonathan - did you want to follow up on this bug then? Or
> should I go ahead based on your new information?

I missed this reply, sorry. I wasn't going to do anything further so thanks for
working on it.

[Bug c++/85545] New: [8/9 Regression] ICE with static_cast of pointer-to-member-function

[reichelt at gcc dot gnu.org]

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

Bug ID: 85545
   Summary: [8/9 Regression] ICE with static_cast of
pointer-to-member-function
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet (compiled with "-std=c++17 -Wformat"
or "-std=c++17 -Wall") triggers an ICE with the GCC 8 release candidate
and on trunk:

==
struct A
{
  void foo() noexcept;
};

template void bar(T);

void baz()
{
  bar(static_cast(::foo));
}
==

bug.cc: In function 'void baz()':
bug.cc:10:41: internal compiler error: in fold_convert_loc, at
fold-const.c:2524
   bar(static_cast(::foo));
 ^
0x6c4cf4 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:2524
0x87539c cp_fold_convert(tree_node*, tree_node*)
../../gcc/gcc/cp/cvt.c:612
0x859760 cxx_eval_constant_expression
../../gcc/gcc/cp/constexpr.c:4613
0x85d0b7 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/constexpr.c:4861
0x85fed6 maybe_constant_value(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.c:5079
0x821a5b build_over_call
../../gcc/gcc/cp/call.c:8078
0x82f1bf build_new_function_call(tree_node*, vec**, int)
../../gcc/gcc/cp/call.c:4319
0x9ade95 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2534
0x938e2a cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7235
0x939681 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8317
0x9194ef cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9085
0x919cfa cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9186
0x91b534 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9481
0x91bc38 cp_parser_expression
../../gcc/gcc/cp/parser.c:9650
0x91d918 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:11132
0x923d4d cp_parser_statement
../../gcc/gcc/cp/parser.c:10936
0x9252c0 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11275
0x925397 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11229
0x93bfa0 cp_parser_function_body
../../gcc/gcc/cp/parser.c:21802
0x93bfa0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:21839
Please submit a full bug report, [etc.]

This is a very recent regression, introduced between 2018-04-22
and the release candidate.

Jakub, I think this is related to your commit, r259629.
I also think that this might qualify as release blocker.

[Bug c/55976] -Werror=return-type should error on returning a value from a void function

[dave.pagan at oracle dot com]

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

Dave Pagan  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #9 from Dave Pagan  ---
Patch submitted for review:

https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01034.html

[Bug target/85525] Alignment Issue in AVX compiler intrinsics

[tom at ritter dot vg]

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

--- Comment #9 from Tom Ritter  ---
This may be related to:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53485
https://sourceforge.net/p/mingw-w64/bugs/304/

[Bug fortran/85544] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385

[gs...@t-online.de]

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

--- Comment #1 from G. Steinmetz  ---

Whereas this variant (plain b) works for all tested versions :


$ cat z4.f90
program p
   integer, parameter :: na = -3, ne = 10
   integer :: i, a(na:ne), b(na:ne), c(na:ne)
   a = [(i, i=na, ne)]
   b = 2**a
   c = [(2**i, i=na, ne)]
   print *, sum(abs(b-c))
end


$ gfortran-8-20180422 z4.f90 -O2 -static-libgfortran
$ a.out
   0
$

[Bug fortran/85544] New: ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385

[gs...@t-online.de]

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

Bug ID: 85544
   Summary: ICE in gfc_conv_scalarized_array_ref, at
fortran/trans-array.c:3385
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to 4.9 at -O[gs123], gfortran-4.8 works :


$ cat z1.f90
program p
   integer, parameter :: na = -3, ne = 10
   integer :: i, a(na:ne), b(na:ne)
   a = [(i, i=na, ne)]
   b = [2**a]
   print *, b
end


$ gfortran-4.8 z1.f90 -O2
$ a.out
   0   0   0   1   2   4   
   8  16  32  64 128 256 512   
1024
$
$ gfortran-8-20180422 z1.f90 -O0 -static-libgfortran
$ a.out
   0   0   0   1   2   4   
   8  16  32  64 128 256 512   
1024
$
$ gfortran-8-20180422 -c z1.f90 -O2
z1.f90:5:0:

b = [2**a]

internal compiler error: Segmentation fault
0xb9d82f crash_signal
../../gcc/toplev.c:325
0x752e3b gfc_conv_scalarized_array_ref
../../gcc/fortran/trans-array.c:3385
0x753b49 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
../../gcc/fortran/trans-array.c:3540
0x78194d gfc_conv_variable
../../gcc/fortran/trans-expr.c:2737
0x77e672 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7930
0x780be3 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7975
0x78b434 gfc_conv_intrinsic_function_args
../../gcc/fortran/trans-intrinsic.c:229
0x79e112 gfc_conv_intrinsic_ishft
../../gcc/fortran/trans-intrinsic.c:5760
0x79e112 gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:9265
0x77e0b5 gfc_conv_function_expr
../../gcc/fortran/trans-expr.c:6788
0x77e652 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7922
0x74fbb7 gfc_trans_array_ctor_element
../../gcc/fortran/trans-array.c:1524
0x75aea5 gfc_trans_array_constructor_value
../../gcc/fortran/trans-array.c:1783
0x75b7f3 trans_array_constructor
../../gcc/fortran/trans-array.c:2543
0x75b7f3 gfc_add_loop_ss_code
../../gcc/fortran/trans-array.c:2819
0x75c025 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:5110
0x7862fc gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10058
0x74ac87 trans_code
../../gcc/fortran/trans.c:1828
0x771f99 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x701120 translate_all_program_units
../../gcc/fortran/parse.c:6121

[Bug fortran/85543] New: ICE in update_current_proc_array_outer_dependency, at fortran/resolve.c:3060

[gs...@t-online.de]

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

Bug ID: 85543
   Summary: ICE in update_current_proc_array_outer_dependency, at
fortran/resolve.c:3060
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to gfortran-5 :


$ cat z1.f90
program p
   procedure(), pointer :: z
contains
   real(z()) function f()
   end
end


$ gfortran-4.9 -c z1.f90
z1.f90:4.8:

   real(z()) function f()
1
Error: Function 'z' in initialization expression at (1) must be an intrinsic
function


$ gfortran-8-20180422 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb9d82f crash_signal
../../gcc/toplev.c:325
0x717d97 update_current_proc_array_outer_dependency
../../gcc/fortran/resolve.c:3060
0x70dca0 resolve_function
../../gcc/fortran/resolve.c:3300
0x70e3da gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.c:6719
0x6aaf8f gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2773
0x6ada91 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.c:2821
0x692565 gfc_match_kind_spec(gfc_typespec*, bool)
../../gcc/fortran/decl.c:2872
0x698b92 gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/fortran/decl.c:4241
0x699b63 gfc_match_prefix(gfc_typespec*)
../../gcc/fortran/decl.c:5955
0x699d37 gfc_match_function_decl()
../../gcc/fortran/decl.c:6952
0x6f9b12 decode_statement
../../gcc/fortran/parse.c:343
0x6fbb34 next_free
../../gcc/fortran/parse.c:1230
0x6fbb34 next_statement
../../gcc/fortran/parse.c:1462
0x6ffc34 parse_contained
../../gcc/fortran/parse.c:5516
0x6ffb66 parse_progunit
../../gcc/fortran/parse.c:5739
0x700ef4 gfc_parse_file()
../../gcc/fortran/parse.c:6207
0x747e2f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85542] New: [6/7/8/9 Regression] ICE in check_inquiry, at fortran/expr.c:2426

[gs...@t-online.de]

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

Bug ID: 85542
   Summary: [6/7/8/9 Regression] ICE in check_inquiry, at
fortran/expr.c:2426
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

gfortran-8 changed between 20180304 and 20180311.
gfortran-7 changed between 20180215 and 20180308.
gfortran-6 changed between 20180307 and 20180314.


$ cat z1.f90
function f(x)
   character(*), intent(in) :: x
   character((len((x :: f
   f = x
end


$ gfortran-8-20180304 -c z1.f90
$
$ gfortran-8-20180422 -c z1.f90
f951: internal compiler error: Segmentation fault
0xb9d82f crash_signal
../../gcc/toplev.c:325
0x6aa2ac check_inquiry
../../gcc/fortran/expr.c:2426
0x6aaa31 check_inquiry
../../gcc/fortran/expr.c:2618
0x6aaa31 gfc_check_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2611
0x6a7420 check_intrinsic_op
../../gcc/fortran/expr.c:2190
0x6aa559 gfc_check_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2565
0x6aafa7 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.c:2775
0x6929e7 gfc_match_char_spec(gfc_typespec*)
../../gcc/fortran/decl.c:3236
0x698d09 gfc_match_decl_type_spec(gfc_typespec*, int)
../../gcc/fortran/decl.c:3874
0x69a25c gfc_match_data_decl()
../../gcc/fortran/decl.c:5793
0x6f6519 match_word_omp_simd
../../gcc/fortran/parse.c:93
0x6f9c0e match_word
../../gcc/fortran/parse.c:376
0x6f9c0e decode_statement
../../gcc/fortran/parse.c:376
0x6fbb34 next_free
../../gcc/fortran/parse.c:1230
0x6fbb34 next_statement
../../gcc/fortran/parse.c:1462
0x6fd42c parse_spec
../../gcc/fortran/parse.c:3854
0x6ff913 parse_progunit
../../gcc/fortran/parse.c:5667
0x7012a1 gfc_parse_file()
../../gcc/fortran/parse.c:6221
0x747e2f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85541] ICE with parameterized derived type (PDT) and allocate

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-26
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/85541] New: ICE with parameterized derived type (PDT) and allocate

[w6ws at earthlink dot net]

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

Bug ID: 85541
   Summary: ICE with parameterized derived type (PDT) and allocate
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: w6ws at earthlink dot net
  Target Milestone: ---

The following test case causes an ICE when the allocate statement is present. 
This was first noticed with an older development snapshot.  However I updated
my compiler to a snapshot of todays trunk and still shows the problem.

wws@w6ws-4:/rootsda5/home/wws/fortran/pdt$ cat charptr.f90
module char_kinds
  implicit none

  type charptr(clen)
integer, len :: clen
character(clen), pointer :: cptr(:) => null()
  end type

end module

program charptr_test
  use char_kinds
  implicit none

  type (charptr(clen=:)), allocatable :: mychars

  allocate (mychars)  ! ICEes with this, compiles without it

end program
wws@w6ws-4:/rootsda5/home/wws/fortran/pdt$ /usr/local/gcc-trunk/bin/gfortran
--version
GNU Fortran (GCC) 9.0.0 20180426 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

wws@w6ws-4:/rootsda5/home/wws/fortran/pdt$ /usr/local/gcc-trunk/bin/gfortran -c
charptr.f90
charptr.f90:17:0:

   allocate (mychars)

internal compiler error: Segmentation fault
0xce260f crash_signal
../../gcc-trunk/gcc/toplev.c:325
0x693b2c insert_parameter_exprs
../../gcc-trunk/gcc/fortran/decl.c:3337
0x6b1390 gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*,
gfc_symbol*, int*), int)
../../gcc-trunk/gcc/fortran/expr.c:4731
0x76e145 structure_alloc_comps
../../gcc-trunk/gcc/fortran/trans-array.c:9054
0x772850 gfc_allocate_pdt_comp(gfc_symbol*, tree_node*, int,
gfc_actual_arglist*)
../../gcc-trunk/gcc/fortran/trans-array.c:9391
0x7ea98a gfc_trans_allocate(gfc_code*)
../../gcc-trunk/gcc/fortran/trans-stmt.c:6604
0x7542b7 trans_code
../../gcc-trunk/gcc/fortran/trans.c:1996
0x788f45 gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:6507
0x7081d0 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:6121
0x7081d0 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6324
0x75107f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
wws@w6ws-4:/rootsda5/home/wws/fortran/pdt$

[Bug target/85538] kortest for 32 and 64 bit masks incorrectly uses k0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-26
 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Seems RA goes wild for some reason.  Doesn't reproduce with
-O2 -march=skylake-avx512 -mtune=generic, but does e.g. with
-O2 -march=skylake-avx512 -mtune=intel.

Only two insns are involved in the f8:
(insn 10 8 12 2 (set (reg:DI 95)
(unspec:DI [
(subreg:V64QI (reg/v:V8DI 93 [ x ]) 0)
(reg:V64QI 22 xmm1 [ y ])
(const_int 0 [0])
] UNSPEC_PCMP)) "include/avx512bwintrin.h":3058 1740
{avx512bw_cmpv64qi3}
 (expr_list:REG_DEAD (reg/v:V8DI 93 [ x ])
(expr_list:REG_DEAD (reg:V64QI 22 xmm1 [ y ])
(nil
(insn 12 10 13 2 (set (reg:CC 17 flags)
(unspec:CC [
(reg:DI 95)
(reg:DI 95)
] UNSPEC_KORTEST)) "include/avx512bwintrin.h":128 1398 {kortestdi}
 (expr_list:REG_DEAD (reg:DI 95)
(nil)))
and IRA seems to think MASK_EVEX_REGS is most beneficial for r95.
That is what actually is used for the first insn, which has Yk constraint and
thus requires k1-k7 regs, but the second insn has k constraint, allows k0-k7
regs and for some reason the k1 value is moved through stack into k0.

Vlad, could you please have a look?

[Bug fortran/85531] Implement some loop fusion in the Fortran front end

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On April 26, 2018 6:09:40 PM GMT+02:00, "tkoenig at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85531
>
>--- Comment #4 from Thomas Koenig  ---
>What is the best strategy on this?
>
>I assume the Fortran front end could do a dependency analysis,
>the existing code could be extended for this.
>
>We could then either do the scalarization in the front end, or
>annotate the generated loops in some way to indicate that it
>is OK to merge them.
>
>What would be preferred?

Well. I think we need sth in the middle end. In the end the question will be
whether that's good enough or whether the frontend can do better in some cases.
We _do_ have issues with the frontend lowering everything to 1-dimensional
accesses.

[Bug ada/85540] New: gcc/ada/init.c:1282: suspicious expression ?

[dcb314 at hotmail dot com]

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

Bug ID: 85540
   Summary: gcc/ada/init.c:1282: suspicious expression ?
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

gcc/ada/init.c:1282]: (style) Boolean result is used in bitwise operation.
Clarify expression with parentheses.

Source code is

  if (sigargs [1] & FAC_MASK == DECADA_M_FACILITY)

Maybe better code

  if ((sigargs [1] & FAC_MASK) == DECADA_M_FACILITY)

[Bug fortran/85531] Implement some loop fusion in the Fortran front end

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
What is the best strategy on this?

I assume the Fortran front end could do a dependency analysis,
the existing code could be extended for this.

We could then either do the scalarization in the front end, or
annotate the generated loops in some way to indicate that it
is OK to merge them.

What would be preferred?

[Bug target/85539] New: x86_64: loads are not always narrowed

[tilkax at gmail dot com]

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

Bug ID: 85539
   Summary: x86_64: loads are not always narrowed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tilkax at gmail dot com
  Target Milestone: ---

When casting a 64-bit memory value to 32 bits, it's possible to only load the
lower 32 bits (this also avoids the REX prefix). GCC doesn't always do this:
https://godbolt.org/g/EzqKNo


#include 

uint32_t foo(uint64_t *p)
{
return *p;
}


Actual:
mov rax, QWORD PTR [rdi]
ret

Expected:
mov eax, DWORD PTR [rdi]
ret

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[marxin at gcc dot gnu.org]

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

--- Comment #25 from Martin Liška  ---
(In reply to krzysio.kurek from comment #24)
> Created attachment 44025 [details]
> Performance logs from perf
> 
> Alright so I've generated 4 profiles with the following flags:
> "pure6": -O3 -DNDEBUG -flto
> "profiled6": -O3 -DNDEBUG -flto + profile run
> "pure7": -O3 -DNDEBUG -flto
> "profiled7": -O3 -DNDEBUG -flto + profile run
> 
> On GCC6 the profile run impacted performance of the application negatively
> compared to "pure6".

It would be best if you attach perf report and perf annotate. The perf.data
files are bad as one needs built binaries.

Can you please attach ftp which you have for these configurations?

[Bug tree-optimization/85529] [7/8/9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 44026
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44026=edit
gcc8-pr85529.patch

Untested fix.

[Bug lto/82229] GCC7's LTO underperforms compared to GCC6

[krzysio.kurek at wp dot pl]

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

krzysio.kurek at wp dot pl changed:

   What|Removed |Added

  Attachment #42199|0   |1
is obsolete||

--- Comment #24 from krzysio.kurek at wp dot pl ---
Created attachment 44025
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44025=edit
Performance logs from perf

Alright so I've generated 4 profiles with the following flags:
"pure6": -O3 -DNDEBUG -flto
"profiled6": -O3 -DNDEBUG -flto + profile run
"pure7": -O3 -DNDEBUG -flto
"profiled7": -O3 -DNDEBUG -flto + profile run

On GCC6 the profile run impacted performance of the application negatively
compared to "pure6".

[Bug fortran/85536] ICE on procedure pointer assignment for subroutine with procedure pointer argument

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-26
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from at least 4.8 up to trunk (9.0).

[Bug fortran/85537] [7/8/9 Regression] Invalid memory reference at runtime when calling subroutine through procedure pointer

[dev-zero at gentoo dot org]

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

--- Comment #3 from Tiziano Müller  ---
(In reply to Dominique d'Humieres from comment #2)
> The test works for me with 4.8.5. The change occurred between revisions
> r2370089 (2016-06-04, OK) and r237310 + one patch (2016-06-10, wrong code).

Ok, then openSuSE must have some patches on their 4.8.5 which introduce the
bug, since I get:

tiziano@tcpc18 ~/tmp $ gfortran --version
GNU Fortran (SUSE Linux) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

tiziano@tcpc18 ~/tmp $ gfortran -o segfault_minimal_rep
segfault_minimal_rep.f90 -ggdb
tiziano@tcpc18 ~/tmp $ ./segfault_minimal_rep 
 foo
 foo

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

Backtrace for this error:
#0  0x7f9bb46c7607 in ???
#1  0x7f9bb46c686d in ???
#2  0x7f9bb3be3fdf in ???
#3  0x4007bc in bar_impl
at /users/tiziano/tmp/segfault_minimal_rep.f90:21
#4  0x4007f1 in __m_MOD_foo
at /users/tiziano/tmp/segfault_minimal_rep.f90:16
#5  0x4007fc in MAIN__
at /users/tiziano/tmp/segfault_minimal_rep.f90:30
#6  0x400832 in main
at /users/tiziano/tmp/segfault_minimal_rep.f90:28
Segmentation fault (core dumped)

[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Thu, Apr 26, 2018 at 08:03:35AM +, mail at pietrodelugas dot it wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526
> 
> --- Comment #4 from Pietro Delugas  ---
> a quick and dirty workaround is to move all the routines in the "leng"
> interface at the bottom of the file. But some compilers do not accept
> this code as valid. 
> 
> A better solution is to move  the leng subroutines in a module by
> their own and import the interface.
> 

With your original code, move checkFMT() to right after the 
CONTAINS statement.  The code then compiles.  No other 
functions need to move.

[Bug fortran/85537] [7/8/9 Regression] Invalid memory reference at runtime when calling subroutine through procedure pointer

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P4
  Known to work||6.4.0
   Target Milestone|--- |7.4
Summary|Invalid memory reference at |[7/8/9 Regression] Invalid
   |runtime when calling|memory reference at runtime
   |subroutine through  |when calling subroutine
   |procedure pointer   |through procedure pointer

--- Comment #2 from Dominique d'Humieres  ---
The test works for me with 4.8.5. The change occurred between revisions
r2370089 (2016-06-04, OK) and r237310 + one patch (2016-06-10, wrong code).

[Bug target/83748] Local variables not aligned to word boundary

[sbansal at ciena dot com]

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

--- Comment #10 from Sumit  ---
(In reply to Segher Boessenkool from comment #9)
Thanks Segher for your comment.

I have gone through the changes and seems like they are relevant to "volatile
bitfield".
Just wanted to confirm (double check) if the changes are relevant to my problem
as well?
My original problem was that the structures in the stack were not allocated
even address causing the Alignment exception.

Also, what could cause the addresses to be allocated a odd address?

[Bug fortran/85534] allocation of array with source give shifted index

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-26
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 6.4 up to trunk (9.0). Reduced test case

module test
contains
 function w2at(word) result(asciitable)
  character(len=*), intent(in) :: word
  integer, dimension(:), allocatable :: asciitable
  integer :: i

  allocate(asciitable(len(word)))
  forall(i=1:len(word)) asciitable(i) = iachar(word(i:i))

 end function w2at
end module test

program tst

use test
implicit none
character(len=256) :: word1
integer, dimension(:), allocatable :: aword1, help

word1="*STEP"
allocate(help,source=w2at(word1))
print *, "lbound of help = ", lbound(help)
print *, "lbound of pack = ", lbound(pack(help,help/=32))
allocate(aword1,source=pack(help,help/=32))
print *, "lbound of aword1 = ", lbound(aword1)

end program

which gives

 lbound of help =1
 lbound of pack =1
 lbound of aword1 =0

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[glisse at gcc dot gnu.org]

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

Bug 78151 Summary: Fail to vectorize *min_element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78151

   What|Removed |Added

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

[Bug tree-optimization/78151] Fail to vectorize *min_element

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #2 from Marc Glisse  ---
This now gets vectorized.

[Bug target/84025] [nvptx] Don't generate branch-around-nothing

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Tom de Vries  ---
Marking resolved-fixed.

[Bug target/83748] Local variables not aligned to word boundary

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
[ Please remove irrelevant parts of the email when replying to bugzilla mail ].

https://gcc.gnu.org/r205896 tells you this commit resolved four PRs:

PR middle-end/23623
PR middle-end/48784
PR middle-end/56341
PR middle-end/56997

You can access those at https://gcc.gnu.org/PR23623 etc.

You'll have to dig a bit to see what GCC 4.8 version has this patch (if any).

[Bug target/84025] [nvptx] Don't generate branch-around-nothing

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

--- Comment #3 from Tom de Vries  ---
Patch committed.

[Bug libgomp/84020] [nvptx] Add GOMP_NVPTX_JIT=-O[0-4] in nvptx libgomp plugin

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Tom de Vries  ---
Patch committed (patch containing testcase was already committed).

Marking resolved-fixed.

[Bug target/85538] kortest for 32 and 64 bit masks incorrectly uses k0

[kretz at kde dot org]

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

--- Comment #1 from Matthias Kretz  ---
Sorry, I was trying to force GCC to use the k1 register and playing with
register asm (which didn't have any effect at all). f8 should actually be (cf.
https://godbolt.org/g/hSkoJV):

bool f8(__m512i x, __m512i y) {
__mmask64 k = _mm512_cmp_epi8_mask(x, y, _MM_CMPINT_EQ);
return _kortestc_mask64_u8(k, k);
}

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #13 from Tom de Vries  ---
Patch with test-case committed, marking resolved-fixed.

[Bug target/85519] [nvptx, openacc, openmp, testsuite] Recursive tests may fail due to thread stack limit

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
Committed to trunk.

Approved for 8.2. [ 8.1 release is targeted for Wednesday, May 2nd. ]

[Bug target/85538] New: kortest for 32 and 64 bit masks incorrectly uses k0

[kretz at kde dot org]

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

Bug ID: 85538
   Summary: kortest for 32 and 64 bit masks incorrectly uses k0
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

Test case (`-O2 -march=skylake-avx512`, cf. https://godbolt.org/g/ou3oAZ):
#include 

// bad:
bool f8(__m512i x, __m512i y) {
register __mmask64 k asm("%rbx") = _mm512_cmp_epi8_mask(x, y,
_MM_CMPINT_EQ);
return _kortestc_mask64_u8(k, k);
}
bool f16(__m512i x, __m512i y) {
auto k = _mm512_cmp_epi16_mask(x, y, _MM_CMPINT_EQ);
return _kortestc_mask32_u8(k, k);
}

// good:
bool f32(__m512i x, __m512i y) {
auto k = _mm512_cmp_epi32_mask(x, y, _MM_CMPINT_EQ);
return _kortestc_mask16_u8(k, k);
}
bool f64(__m512i x, __m512i y) {
auto k = _mm512_cmp_epi64_mask(x, y, _MM_CMPINT_EQ);
return _kortestc_mask8_u8(k, k);
}

The 32-bit and 64-bit masks are correctly assigned to k1 on vpcmp[bw], but
subsequently GCC does some heroics to get k1 assigned into k0 (which shouldn't
be possible, no?) and then calls `kortest[qd] %k0, %k0`. The f32 and f64
functions show the correct behavior.

[Bug libgomp/84020] [nvptx] Add GOMP_NVPTX_JIT=-O[0-4] in nvptx libgomp plugin

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Author: vries
Date: Thu Apr 26 13:27:04 2018
New Revision: 259678

URL: https://gcc.gnu.org/viewcvs?rev=259678=gcc=rev
Log:
[nvptx, libgomp] Add GOMP_NVPTX_JIT=-O[0-4] in nvptx libgomp plugin

2018-04-26  Tom de Vries  

PR libgomp/84020
* plugin/cuda/cuda.h (CUjit_option): Add CU_JIT_OPTIMIZATION_LEVEL.
* plugin/plugin-nvptx.c (_GNU_SOURCE): Define.
(process_GOMP_NVPTX_JIT): New function.
(link_ptx): Use process_GOMP_NVPTX_JIT.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/plugin/cuda/cuda.h
trunk/libgomp/plugin/plugin-nvptx.c

[Bug target/84952] [nvptx] bar.sync generated in divergent code

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries  ---
Author: vries
Date: Thu Apr 26 13:26:48 2018
New Revision: 259677

URL: https://gcc.gnu.org/viewcvs?rev=259677=gcc=rev
Log:
[nvptx] Verify bar.sync position

2018-04-26  Tom de Vries  

PR target/84952
* config/nvptx/nvptx.c (verify_neutering_jumps)
(verify_neutering_labels): New function
(nvptx_single): Use verify_neutering_jumps and verify_neutering_labels.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c

[Bug target/84025] [nvptx] Don't generate branch-around-nothing

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Author: vries
Date: Thu Apr 26 13:26:38 2018
New Revision: 259676

URL: https://gcc.gnu.org/viewcvs?rev=259676=gcc=rev
Log:
[nvptx] Fix branch-around-nothing

2018-04-26  Tom de Vries  

PR target/84025
* config/nvptx/nvptx.c (needs_neutering_p): New function.
(nvptx_single): Use needs_neutering_p to skip over insns that do not
need neutering.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c

[Bug lto/85422] [openacc] ICE at cfgloop.c:468: segfault in flow_loops_find

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries  ---
Author: vries
Date: Thu Apr 26 13:26:25 2018
New Revision: 259675

URL: https://gcc.gnu.org/viewcvs?rev=259675=gcc=rev
Log:
[lto] Fixup loops before lto write-out

2018-04-26  Richard Biener 
Tom de Vries  

PR lto/85422
* lto-streamer-out.c (output_function): Fixup loops if required to
match
discovery done in the reader.

* testsuite/libgomp.oacc-c-c++-common/pr85422.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85422.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-out.c
trunk/libgomp/ChangeLog

[Bug target/85519] [nvptx, openacc, openmp, testsuite] Recursive tests may fail due to thread stack limit

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Author: vries
Date: Thu Apr 26 13:26:09 2018
New Revision: 259674

URL: https://gcc.gnu.org/viewcvs?rev=259674=gcc=rev
Log:
[nvptx, libgomp, testsuite] Reduce recursion depth in declare_target-{1,2}.f90

2018-04-26  Tom de Vries  

PR target/85519
* testsuite/libgomp.fortran/examples-4/declare_target-1.f90: Reduce
recursion depth from 25 to 23.
* testsuite/libgomp.fortran/examples-4/declare_target-2.f90: Same.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-1.f90
trunk/libgomp/testsuite/libgomp.fortran/examples-4/declare_target-2.f90

[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/85450] ICE: invalid types in nop conversion during GIMPLE pass: ompexp

[clyon at gcc dot gnu.org]

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

--- Comment #9 from Christophe Lyon  ---
Created attachment 44024
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44024=edit
vfprintf.i

Your patch proposal fixes the ICE with sysopen.i, but I still have a crash with
vfprintf.i (with -mabi=ilp32)

[Bug tree-optimization/85529] [7/8/9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
And finally a testcase that is miscompiled on 7.x, starting with r240858:
/* PR tree-optimization/85529 */
/* { dg-do run } */
/* { dg-options "-O2 -fno-ssa-phiopt" } */

__attribute__((noinline, noclone)) int
foo (int x)
{
  x &= 31;
  x -= 25;
  x *= 2;
  if (x < 0)
return 1;
  int y = x >> 2;
  if (x >= y)
return 1;
  return 0;
}

int
main ()
{
  int i;
  for (i = 0; i < 63; i++)
if (foo (i) != 1)
  __builtin_abort ();
  return 0;
}

[Bug tree-optimization/85529] [7/8/9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Slightly tweaked testcase:
struct S { int a; };

int b, c = 1, d, e, f;
static int g;
volatile struct S s;

signed char
foo (signed char i, int j)
{
  return i < 0 ? i : i << j;
}

int
main ()
{
  signed char k = -83;
  if (!d)
goto L;
  k = e || f;
L:
  for (; b < 1; b++)
s.a != (k < foo (k, 2) && (c = k = g));
  if (c != 1)
__builtin_abort ();
  return 0;
}


Another testcase, that started being miscompiled with r255387 is:
__attribute__((noipa)) int
foo (int x)
{
  x &= 63;
  x -= 50;
  x |= 1;
  if (x < 0)
return 1;
  int y = x >> 2;
  if (x >= y)
return 1;
  return 0;
}

int
main ()
{
  int i;
  for (i = 0; i < 63; i++)
if (foo (i) != 1)
  __builtin_abort ();
  return 0;
}

[Bug libstdc++/85116] std::min_element does not optimize well with inlined predicate

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
So loop-header copying now DTRT but then PRE is faced with

   [local count: 955630223]:
  # __first_20 = PHI <_M_elems(2), __first_21(7)>
  # __first_21 = PHI <[(void *) + 8B](2), __first_7(7)>
  # __result_22 = PHI <_M_elems(2), __result_15(7)>
  _8 = MEM[(const double *)__first_20 + 8B];
  _10 = *__result_22;
  _11 = _8 - offset_2(D);
  _12 = ABS_EXPR <_11>;
  _13 = _10 - offset_2(D);
  _14 = ABS_EXPR <_13>;
  if (_12 < _14)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 477815111]:
  goto ; [100.00%]

   [local count: 477815112]:

   [local count: 955630224]:
  # __result_15 = PHI <__first_21(5), __result_22(8)>
  __first_7 = __first_21 + 8;
  if (__first_7 != [(void *) + 8000B])
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 850510900]:
  goto ;

where the situation is too confusing to be recognized.  As said, loop-header
copying doing a SSA update introduces the extra IV somehow.  That needs to be
investigated.

[Bug libstdc++/85116] std::min_element does not optimize well with inlined predicate

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 26 12:18:58 2018
New Revision: 259672

URL: https://gcc.gnu.org/viewcvs?rev=259672=gcc=rev
Log:
2018-04-26  Richard Biener  

PR tree-optimization/85116
* tree-ssa-loop-ch.c (do_while_loop_p): A do-while loop should
have a loop exit from the single latch predecessor.  Remove
case of header with just condition.
(ch_base::copy_headers): Exclude infinite loops from any
processing.
(pass_ch::execute): Record exits.

* gcc.dg/tree-ssa/copy-headers-2.c: New testcase.
* gcc.dg/tree-ssa/copy-headers-3.c: Likewise.
* gcc.dg/tree-ssa/copy-headers-4.c: Likewise.
* gcc.dg/tree-ssa/loadpre6.c: Adjust.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-2.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/copy-headers-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/loadpre6.c
trunk/gcc/tree-ssa-loop-ch.c

[Bug middle-end/85450] ICE: invalid types in nop conversion during GIMPLE pass: ompexp

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 26 Apr 2018, clyon at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85450
> 
> --- Comment #7 from Christophe Lyon  ---
> Created attachment 44023
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44023=edit
> Newlib's sysopen.i
> 
> I could reproduce the problem with aarch64-none-elf too, and this requires
> -mabi=ilp32.
> 
> Compiling the attached file with -c ./sysopen.i  -mabi=ilp32:
> 
> In file included from
> /home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/include/sys/fcntl.h:3,
>  from
> /home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/include/fcntl.h:1,
>  from
> /home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/syscalls/sysopen.c:4:
> /home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/include/sys/_default_fcntl.h:
> In function 'open':
> /home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/include/sys/_default_fcntl.h:182:12:
> error: invalid types in nop conversion
>  extern int open _PARAMS ((const char *, int, ...));
> ^~~~
> long long int
> void *
> _19 = (long long int) _18;
> /home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/include/sys/_default_fcntl.h:182:12:
> error: invalid types in nop conversion
> long long int
> void *
> _28 = (long long int) _18;
> during GIMPLE pass: lower_vaarg
> /home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/include/sys/_default_fcntl.h:182:12:
> internal compiler error: verify_gimple failed
> 0xc4cd2b verify_gimple_in_cfg(function*, bool)
> 
> /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk/gcc/tree-cfg.c:5585
> 0xb03a27 execute_function_todo
> /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk/gcc/passes.c:1994
> 0xb04399 execute_todo
> /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk/gcc/passes.c:2048

Caused by aarch64_gimplify_va_arg_expr:

  /* Advance ap.__stack  */
  t = fold_convert (intDI_type_node, arg);
  t = build2 (PLUS_EXPR, TREE_TYPE (t), t,
  build_int_cst (TREE_TYPE (t), size + 7));
  t = build2 (BIT_AND_EXPR, TREE_TYPE (t), t,
  build_int_cst (TREE_TYPE (t), -8));
  t = fold_convert (TREE_TYPE (arg), t);

I'm not sure why, for ILP32, this code converts to intDI_type_node.  
Probably missing ILP32 adjustments.

I suggest to simplify the code with

Index: gcc/config/aarch64/aarch64.c
===
--- gcc/config/aarch64/aarch64.c(revision 259669)
+++ gcc/config/aarch64/aarch64.c(working copy)
@@ -12278,12 +12278,9 @@ aarch64_gimplify_va_arg_expr (tree valis
   else
 roundup = NULL;
   /* Advance ap.__stack  */
-  t = fold_convert (intDI_type_node, arg);
-  t = build2 (PLUS_EXPR, TREE_TYPE (t), t,
- build_int_cst (TREE_TYPE (t), size + 7));
+  t = fold_build_pointer_plus_hwi (arg, size + 7);
   t = build2 (BIT_AND_EXPR, TREE_TYPE (t), t,
  build_int_cst (TREE_TYPE (t), -8));
-  t = fold_convert (TREE_TYPE (arg), t);
   t = build2 (MODIFY_EXPR, TREE_TYPE (stack), unshare_expr (stack), t);
   /* String up roundup and advance.  */
   if (roundup)

which fixes the issue for me.

[Bug c++/85535] bogus code in decl2.c:decl_needed_p

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-26
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed by inspection ;)

[Bug fortran/85537] Invalid memory reference at runtime when calling subroutine through procedure pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-26
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed with GCC 7.

[Bug middle-end/85450] ICE: invalid types in nop conversion during GIMPLE pass: ompexp

[clyon at gcc dot gnu.org]

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

--- Comment #7 from Christophe Lyon  ---
Created attachment 44023
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44023=edit
Newlib's sysopen.i

I could reproduce the problem with aarch64-none-elf too, and this requires
-mabi=ilp32.

Compiling the attached file with -c ./sysopen.i  -mabi=ilp32:

In file included from
/home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/include/sys/fcntl.h:3,
 from
/home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/include/fcntl.h:1,
 from
/home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/syscalls/sysopen.c:4:
/home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/include/sys/_default_fcntl.h:
In function 'open':
/home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/include/sys/_default_fcntl.h:182:12:
error: invalid types in nop conversion
 extern int open _PARAMS ((const char *, int, ...));
^~~~
long long int
void *
_19 = (long long int) _18;
/home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/include/sys/_default_fcntl.h:182:12:
error: invalid types in nop conversion
long long int
void *
_28 = (long long int) _18;
during GIMPLE pass: lower_vaarg
/home/christophe.lyon/src/GCC/sources/newlib/newlib/libc/include/sys/_default_fcntl.h:182:12:
internal compiler error: verify_gimple failed
0xc4cd2b verify_gimple_in_cfg(function*, bool)
/home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk/gcc/tree-cfg.c:5585
0xb03a27 execute_function_todo
/home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk/gcc/passes.c:1994
0xb04399 execute_todo
/home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk/gcc/passes.c:2048


My GCC is configured with:
--target=aarch64-none-elf --disable-nls --without-headers --with-newlib
--disable-shared --disable-threads --disable-libssp --disable-libgomp
--disable-libmudflap --disable-libatomic --disable-libcilkrts
--without-libquadmath --disable-libquadmath --enable-languages=c --with-newlib
--disable-tls

[Bug tree-optimization/85529] [7/8/9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|8.0 |7.4
Summary|[8/9 Regression] wrong code |[7/8/9 Regression] wrong
   |at -O2 and -O3 on   |code at -O2 and -O3 on
   |x86_64-linux-gnu|x86_64-linux-gnu

--- Comment #4 from Richard Biener  ---
The issue is latent on the GCC 7 branch.

[Bug tree-optimization/85275] copyheader peels off almost the entire iteration

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
So after my fix for the related PR85116 we'll still not identify the loop as
do-while-loop because its latch isn't empty (it contains the IV increment).

As-is the loop probably should be header-copied but we should stop at the
first exit.

Index: gcc/tree-ssa-loop-ch.c
===
--- gcc/tree-ssa-loop-ch.c  (revision 259669)
+++ gcc/tree-ssa-loop-ch.c  (working copy)
@@ -328,6 +340,11 @@ ch_base::copy_headers (function *fun)
  bbs[n_bbs++] = header;
  gcc_assert (bbs_size > n_bbs);
  header = exit->dest;
+ /* Make sure to stop copying after we copied the first exit test.
+Without further heuristics we do not want to rotate the loop
+any further.  */
+ if (loop_exits_from_bb_p (loop, exit->src))
+   break;
}

   if (!exit)

[Bug fortran/85537] New: Invalid memory reference at runtime when calling subroutine through procedure pointer

[dev-zero at gentoo dot org]

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

Bug ID: 85537
   Summary: Invalid memory reference at runtime when calling
subroutine through procedure pointer
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dev-zero at gentoo dot org
  Target Milestone: ---

Given the following code, the runtime generates a segfault on the same function
when called through the procedure pointer instead of a direct function call:

  module m
 implicit none
  contains
 subroutine foo()
integer :: a

abstract interface
   subroutine ibar()
   end subroutine
end interface

procedure(ibar), pointer :: bar_ptr => bar_impl

a = 0
call bar_impl()
call bar_ptr()

 contains
subroutine bar_impl()
   write (*,*) "foo"
   a = a + 1
end subroutine

 end subroutine
  end module

  program main
 use m

 call foo()
  end program

it will generate the following output:

$ ./segfault_minimal_rep 
 foo
 foo

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

Backtrace for this error:
#0  0x7f34795e7bbd in ???
#1  0x7f34795e6e03 in ???
#2  0x7f3478b02fdf in ???
#3  0x400788 in bar_impl
at /users/tiziano/tmp/segfault_minimal_rep.f90:21
#4  0x4007c6 in __m_MOD_foo
at /users/tiziano/tmp/segfault_minimal_rep.f90:16
#5  0x4007d1 in MAIN__
at /users/tiziano/tmp/segfault_minimal_rep.f90:30
#6  0x400808 in main
at /users/tiziano/tmp/segfault_minimal_rep.f90:28
Segmentation fault (core dumped)

[Bug middle-end/85450] ICE: invalid types in nop conversion during GIMPLE pass: ompexp

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Thu, 26 Apr 2018, clyon at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85450
> 
> Christophe Lyon  changed:
> 
>What|Removed |Added
> 
>  CC||clyon at gcc dot gnu.org
> 
> --- Comment #5 from Christophe Lyon  ---
> Hi Richard,
> 
> This patch (r259667) makes the newlib build fail on aarch64_be-none-elf.
> 
> I'm seeing this in my build log:
> aarch64_be-none-elf-gcc
> -B/tmp/7730760_9.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/newlib/aarch64_be-none-elf/ilp32/newlib/
> -isystem
> /tmp/7730760_9.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/newlib/aarch64_be-none-elf/ilp32/newlib/targ-include
> -isystem /tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/include
> -B/tmp/7730760_9.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/newlib/aarch64_be-none-elf/ilp32/libgloss/aarch64
> -L/tmp/7730760_9.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/newlib/aarch64_be-none-elf/ilp32/libgloss/libnosys
> -L/tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/libgloss/aarch64 
> -mabi=ilp32 -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
> -DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"newlib\ 2.0.0\"
> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
> -I/tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdio
> -fno-builtin  -g -O2  -mabi=ilp32 -fshort-enums -DINTEGER_ONLY -c
> /tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdio/vfprintf.c
> -o lib_a-vfiprintf.o
> In file included from
> /tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdio/vfwscanf.c:109:
> /tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdio/vfwscanf.c:
> In function '__svfwscanf_r':
> /tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdio/vfwscanf.c:140:25:
> error: invalid types in nop conversion
>  #  define __SVFWSCANF_R __svfwscanf_r
>  ^
> /tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdio/vfwscanf.c:371:8:
> note: in expansion of macro '__SVFWSCANF_R'
>  _DEFUN(__SVFWSCANF_R, (rptr, fp, fmt0, ap),
> ^
> long long int
> void *
> _360 = (long long int) _368;
> [...]
> 
> 
> 
> 
> 
> and also:
> 0xc40fa3 verify_gimple_in_cfg(function*, bool)
>
> /tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-cfg.c:5585
> 0xae70ec execute_function_todo
>
> /tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/passes.c:1994
> 0xae6e85 execute_todo
>
> /tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/passes.c:2048
> 
> I'd have to reproduce the problem manually in order to share a preprocessed
> file.

Can't investigate w/o that though.  Please also say how to configure
a cross to aarch64_be-none-elf (big-endian aarch64?  please not...)

[Bug middle-end/85450] ICE: invalid types in nop conversion during GIMPLE pass: ompexp

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #5 from Christophe Lyon  ---
Hi Richard,

This patch (r259667) makes the newlib build fail on aarch64_be-none-elf.

I'm seeing this in my build log:
aarch64_be-none-elf-gcc
-B/tmp/7730760_9.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/newlib/aarch64_be-none-elf/ilp32/newlib/
-isystem
/tmp/7730760_9.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/newlib/aarch64_be-none-elf/ilp32/newlib/targ-include
-isystem /tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/include
-B/tmp/7730760_9.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/newlib/aarch64_be-none-elf/ilp32/libgloss/aarch64
-L/tmp/7730760_9.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/newlib/aarch64_be-none-elf/ilp32/libgloss/libnosys
-L/tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/libgloss/aarch64 
-mabi=ilp32 -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"newlib\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I/tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdio
-fno-builtin  -g -O2  -mabi=ilp32 -fshort-enums -DINTEGER_ONLY -c
/tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdio/vfprintf.c
-o lib_a-vfiprintf.o
In file included from
/tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdio/vfwscanf.c:109:
/tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdio/vfwscanf.c:
In function '__svfwscanf_r':
/tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdio/vfwscanf.c:140:25:
error: invalid types in nop conversion
 #  define __SVFWSCANF_R __svfwscanf_r
 ^
/tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdio/vfwscanf.c:371:8:
note: in expansion of macro '__SVFWSCANF_R'
 _DEFUN(__SVFWSCANF_R, (rptr, fp, fmt0, ap),
^
long long int
void *
_360 = (long long int) _368;
[...]





and also:
0xc40fa3 verify_gimple_in_cfg(function*, bool)
   
/tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-cfg.c:5585
0xae70ec execute_function_todo
   
/tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/passes.c:1994
0xae6e85 execute_todo
   
/tmp/7730760_9.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/passes.c:2048

I'd have to reproduce the problem manually in order to share a preprocessed
file.

[Bug c++/84691] [6/7/8/9 Regression] internal compiler error: in poplevel_class, at cp/name-lookup.c:4430

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #3 from Paolo Carlini  ---
Mine.

[Bug fortran/85536] New: ICE on procedure pointer assignment for subroutine with procedure pointer argument

[dev-zero at gentoo dot org]

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

Bug ID: 85536
   Summary: ICE on procedure pointer assignment for subroutine
with procedure pointer argument
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dev-zero at gentoo dot org
  Target Milestone: ---

Given the following minimal code:

  module m
 implicit none
 abstract interface
subroutine parser(nextParser)
   procedure(parser), pointer :: nextParser
end subroutine
 end interface

  contains
 subroutine parseA(nextParser)
procedure(parser), pointer :: nextParser
 end subroutine
  end module

  program main
 use m

 procedure(parser), pointer :: parse => parseA
  end program

I get the following ICE, with GNU Fortran (Gentoo Hardened 7.3.0-r2 p1.2)
7.3.0:

$ gfortran-7.3.0 -o ice_minimal_rep ice_minimal_rep.f90 
gfortran: internal compiler error: Segmentation fault (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


respectively with GNU Fortran (SUSE Linux) 8.0.1 20180406 (experimental) [trunk
revision 259162]:

$ gfortran-8 -o ice_minimal_rep ice_minimal_rep.f90 
gfortran-8: internal compiler error: Segmentation fault signal terminated
program f951
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


or with GNU Fortran (SUSE Linux) 4.8.5:

$ gfortran -o ice_minimal_rep ice_minimal_rep.f90 
gfortran: internal compiler error: Segmentation fault (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug tree-optimization/85529] [8/9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Reassoc does

[local count: 530374774]:
-  # b.9_28 = PHI 
+  # b.9_28 = PHI 
   # RANGE [-83, 1] NONZERO 173
-  # k_32 = PHI 
-  # c_lsm.11_10 = PHI 
-  # c_lsm.12_24 = PHI <0(13), c_lsm.12_25(9)>
+  # k_32 = PHI 
+  # c_lsm.11_10 = PHI 
+  # c_lsm.12_24 = PHI <0(12), c_lsm.12_25(8)>
   _4 ={v} s.a;
   # RANGE [-2147483647, 2147483647]
   _42 = b.9_28 + 1;
-  if (k_32 >= 0)
-goto ; [26.46%]
-  else
-goto ; [73.54%]
-
-   [local count: 140323371]:
-  # RANGE [0, 1] NONZERO 1
   _5 = (int) k_32;
-  # RANGE [0, 4] NONZERO 4
   _20 = _5 << 2;
-  # RANGE [0, 4] NONZERO 4
   iftmp.0_44 = (char) _20;
-  if (k_32 < iftmp.0_44)
-goto ; [84.48%]
+  _14 = (unsigned char) k_32;
+  _8 = (unsigned char) iftmp.0_44;
+  if (_8 > _14)

likely the reset_flow_sensitive_info_in_bb call is too late for the
simplification bits it does.

[Bug target/85530] [X86] _mm512_mullox_epi64 and _mm512_mask_mullox_epi64 not implemented

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-26
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 44022
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44022=edit
gcc8-pr85530.patch

Untested fix.

[Bug c++/85535] New: bogus code in decl2.c:decl_needed_p

[ebotcazou at gcc dot gnu.org]

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

Bug ID: 85535
   Summary: bogus code in decl2.c:decl_needed_p
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
  Target Milestone: ---

These lines are bogus:

  /* When not optimizing, do not bother to produce definitions for extern
 symbols.  */
  if (DECL_REALLY_EXTERN (decl)
  && ((TREE_CODE (decl) != FUNCTION_DECL
   && !optimize)
  || (TREE_CODE (decl) == FUNCTION_DECL
  && !opt_for_fn (decl, optimize)))
  && !lookup_attribute ("always_inline", decl))
return false;

You cannot call lookup_attribute on a DECL, this will immediately fail a check:

internal compiler error: tree check: expected tree_list, have var_decl in
get_attribute_name, at attribs.c:835

I spotted this by visual inspection so no testcase.

[Bug tree-optimization/85529] [8/9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r257852.  I'll have a look.

[Bug c++/82658] Suboptimal codegen on AVR when right-shifting 8-bit unsigned integers.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||randy.brecker64 at gmail dot 
com

--- Comment #4 from Georg-Johann Lay  ---
*** Bug 85533 has been marked as a duplicate of this bug. ***

[Bug c++/85533] Missing optimization for right-shift of unsigned int (avr-g++)

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Georg-Johann Lay  ---
Likely a DUP of PR82658.

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

[Bug tree-optimization/85168] [7 Regression] ICE in tree-ssa-coalesce.c: SSA corruption: Unable to coalesce ssa_names which are marked as MUST COALESCE when -O2 is used

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.3.1
 Resolution|--- |FIXED

--- Comment #9 from Richard Biener  ---
Fixed.

[Bug tree-optimization/85284] [7 Regression] Loop miscompilation starting with r238367

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.3.1
 Resolution|--- |FIXED
  Known to fail||7.3.0

--- Comment #9 from Richard Biener  ---
Fixed.

[Bug tree-optimization/85284] [7 Regression] Loop miscompilation starting with r238367

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 26 10:00:24 2018
New Revision: 259670

URL: https://gcc.gnu.org/viewcvs?rev=259670=gcc=rev
Log:
2018-04-26  Richard Biener  

Backport from mainline
2018-04-09  Richard Biener  

PR tree-optimization/85284
* tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
Only use the niter constraining form of simple_iv when the exit
is always executed.

* gcc.dg/torture/pr85284.c: New testcase.

2018-04-06  Richard Biener  

PR middle-end/85244
* tree-dfa.c (get_ref_base_and_extent): Reset seen_variable_array_ref
after seeing a component reference with an adjacent field.  Treat
refs to arrays at struct end of external decls similar to
refs to unconstrained commons.

* gcc.dg/torture/pr85244-1.c: New testcase.
* gcc.dg/torture/pr85244-2.c: Likewise.

2018-04-04  Richard Biener  

PR tree-optimization/85168
* tree-ssa-sccvn.c (vn_reference_maybe_forwprop_address): Avoid
propagating abnormals.

* gcc.dg/torture/pr85168.c: New testcase.

2018-03-16  Richard Biener  

PR c/84873
* c-gimplify.c (c_gimplify_expr): Revert previous change.  Instead
unshare the possibly folded expression.

2018-03-15  Richard Biener  

PR c/84873
* c-gimplify.c (c_gimplify_expr): Do not fold expressions.

* c-c++-common/pr84873.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/c-c++-common/pr84873.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85168.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85244-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85244-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85284.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/c-family/ChangeLog
branches/gcc-7-branch/gcc/c-family/c-gimplify.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-dfa.c
branches/gcc-7-branch/gcc/tree-ssa-loop-niter.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

[Bug c/84873] [6/7 Regression] ICE: verify_ssa failed (error: definition in block 3 does not dominate use in block 4)

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 26 10:00:24 2018
New Revision: 259670

URL: https://gcc.gnu.org/viewcvs?rev=259670=gcc=rev
Log:
2018-04-26  Richard Biener  

Backport from mainline
2018-04-09  Richard Biener  

PR tree-optimization/85284
* tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
Only use the niter constraining form of simple_iv when the exit
is always executed.

* gcc.dg/torture/pr85284.c: New testcase.

2018-04-06  Richard Biener  

PR middle-end/85244
* tree-dfa.c (get_ref_base_and_extent): Reset seen_variable_array_ref
after seeing a component reference with an adjacent field.  Treat
refs to arrays at struct end of external decls similar to
refs to unconstrained commons.

* gcc.dg/torture/pr85244-1.c: New testcase.
* gcc.dg/torture/pr85244-2.c: Likewise.

2018-04-04  Richard Biener  

PR tree-optimization/85168
* tree-ssa-sccvn.c (vn_reference_maybe_forwprop_address): Avoid
propagating abnormals.

* gcc.dg/torture/pr85168.c: New testcase.

2018-03-16  Richard Biener  

PR c/84873
* c-gimplify.c (c_gimplify_expr): Revert previous change.  Instead
unshare the possibly folded expression.

2018-03-15  Richard Biener  

PR c/84873
* c-gimplify.c (c_gimplify_expr): Do not fold expressions.

* c-c++-common/pr84873.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/c-c++-common/pr84873.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85168.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85244-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85244-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85284.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/c-family/ChangeLog
branches/gcc-7-branch/gcc/c-family/c-gimplify.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-dfa.c
branches/gcc-7-branch/gcc/tree-ssa-loop-niter.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/85244] [6/7 Regression] Bad optimisation with flexible array member (may be related to -ftree-dominator-opts)

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 26 10:00:24 2018
New Revision: 259670

URL: https://gcc.gnu.org/viewcvs?rev=259670=gcc=rev
Log:
2018-04-26  Richard Biener  

Backport from mainline
2018-04-09  Richard Biener  

PR tree-optimization/85284
* tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
Only use the niter constraining form of simple_iv when the exit
is always executed.

* gcc.dg/torture/pr85284.c: New testcase.

2018-04-06  Richard Biener  

PR middle-end/85244
* tree-dfa.c (get_ref_base_and_extent): Reset seen_variable_array_ref
after seeing a component reference with an adjacent field.  Treat
refs to arrays at struct end of external decls similar to
refs to unconstrained commons.

* gcc.dg/torture/pr85244-1.c: New testcase.
* gcc.dg/torture/pr85244-2.c: Likewise.

2018-04-04  Richard Biener  

PR tree-optimization/85168
* tree-ssa-sccvn.c (vn_reference_maybe_forwprop_address): Avoid
propagating abnormals.

* gcc.dg/torture/pr85168.c: New testcase.

2018-03-16  Richard Biener  

PR c/84873
* c-gimplify.c (c_gimplify_expr): Revert previous change.  Instead
unshare the possibly folded expression.

2018-03-15  Richard Biener  

PR c/84873
* c-gimplify.c (c_gimplify_expr): Do not fold expressions.

* c-c++-common/pr84873.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/c-c++-common/pr84873.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85168.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85244-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85244-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85284.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/c-family/ChangeLog
branches/gcc-7-branch/gcc/c-family/c-gimplify.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-dfa.c
branches/gcc-7-branch/gcc/tree-ssa-loop-niter.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

[Bug tree-optimization/85168] [7 Regression] ICE in tree-ssa-coalesce.c: SSA corruption: Unable to coalesce ssa_names which are marked as MUST COALESCE when -O2 is used

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 26 10:00:24 2018
New Revision: 259670

URL: https://gcc.gnu.org/viewcvs?rev=259670=gcc=rev
Log:
2018-04-26  Richard Biener  

Backport from mainline
2018-04-09  Richard Biener  

PR tree-optimization/85284
* tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
Only use the niter constraining form of simple_iv when the exit
is always executed.

* gcc.dg/torture/pr85284.c: New testcase.

2018-04-06  Richard Biener  

PR middle-end/85244
* tree-dfa.c (get_ref_base_and_extent): Reset seen_variable_array_ref
after seeing a component reference with an adjacent field.  Treat
refs to arrays at struct end of external decls similar to
refs to unconstrained commons.

* gcc.dg/torture/pr85244-1.c: New testcase.
* gcc.dg/torture/pr85244-2.c: Likewise.

2018-04-04  Richard Biener  

PR tree-optimization/85168
* tree-ssa-sccvn.c (vn_reference_maybe_forwprop_address): Avoid
propagating abnormals.

* gcc.dg/torture/pr85168.c: New testcase.

2018-03-16  Richard Biener  

PR c/84873
* c-gimplify.c (c_gimplify_expr): Revert previous change.  Instead
unshare the possibly folded expression.

2018-03-15  Richard Biener  

PR c/84873
* c-gimplify.c (c_gimplify_expr): Do not fold expressions.

* c-c++-common/pr84873.c: New testcase.

Added:
branches/gcc-7-branch/gcc/testsuite/c-c++-common/pr84873.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85168.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85244-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85244-2.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/torture/pr85284.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/c-family/ChangeLog
branches/gcc-7-branch/gcc/c-family/c-gimplify.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-dfa.c
branches/gcc-7-branch/gcc/tree-ssa-loop-niter.c
branches/gcc-7-branch/gcc/tree-ssa-sccvn.c

[Bug c++/85533] Missing optimization for right-shift of unsigned int (avr-g++)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Jonathan Wakely  ---
I'm not sure if this is specific to the avr target, as we also get different
code for C and C++ on x86_64 targets.

[Bug fortran/85534] New: allocation of array with source give shifted index

[alban.leroyer at gmail dot com]

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

Bug ID: 85534
   Summary: allocation of array with source give shifted index
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alban.leroyer at gmail dot com
  Target Milestone: ---

Created attachment 44021
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44021=edit
Small example highlighing the problem

When allocating an array using the source command, the array is created
starting from index 0.

[Bug c++/85533] New: Missing optimization for right-shift of unsigned int (avr-g++)

[randy.brecker64 at gmail dot com]

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

Bug ID: 85533
   Summary: Missing optimization for right-shift of unsigned int
(avr-g++)
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: randy.brecker64 at gmail dot com
  Target Milestone: ---

If the following snippet is compiled as C++-Code

volatile unsigned char x;
volatile unsigned char y;

int main() {
x >>= 1;
y /= 2;
}

it gives the assembler code:

   lds r24,x;  x.0_1, x
ldi r25,0;  x.0_1
asr r25  ;  tmp50
ror r24  ;  tmp50
sts x,r24;  x, tmp50
lds r24,y;  y.1_5, y
lsr r24  ;  _6
sts y,r24;  y, _6

If it is compiled as C-Code it gives a better optimizatoion for the right
shift:

   lds r24,x;  x.0_1, x
lsr r24  ;  _2
sts x,r24;  x, _2
lds r24,y;  y.1_3, y
lsr r24  ;  _4
sts y,r24;  y, _4

[Bug tree-optimization/84956] [6/7/8 Regression] ICE in replace_block_by, at tree-ssa-tail-merge.c:1546

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug fortran/85531] Implement some loop fusion in the Fortran front end

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-26
 CC||rguenth at gcc dot gnu.org
Version|unknown |9.0
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Thanks.  So -floop-nest-optimize (graphite) doens't do anything here, it
detects the two loops just fine but simply doesn't do any transform.  Probably
similar to the interchange failure we miss to provide it with spatial
constraints to minimize or so.

The loop distribution pass is presented with a CFG and IL that should be indeed
trivially analyzable (if we solve the dependence analysis issue).

[Bug fortran/85531] Implement some loop fusion in the Fortran front end

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Can you provide a testcase that can be compiled?

--- Comment #2 from Thomas Koenig  ---
Here it is. The internal writes are there just to confuse the
optimizer.

module x
  implicit none
contains
  subroutine foo(a,b,c, n)
integer, intent(in) :: n
double precision, dimension(n), intent(in) :: a
double precision, dimension(n), intent(out) :: b,c
b = a
c = a
  end subroutine foo
  subroutine bar(a,b,c,n)
integer, intent(in) :: n
double precision, dimension(n), intent(in) :: a
double precision, dimension(n), intent(out) :: b,c
integer :: i
do concurrent (i=1:n)
   b(i) = a(i)
   c(i) = a(i)
end do
  end subroutine bar
end module x

program main
  use x
  implicit none
  double precision, dimension(:), allocatable :: a, b, c
  integer, parameter :: n = 10**7
  double precision :: t1, t2
  character(len=80) :: line, line2
  integer :: i
  allocate (a(n), b(n), c(n))
  call random_number(a)

  line = '20'
  call cpu_time(t1)
  call foo(a,b,c,n)
  call cpu_time(t2)
  print *,t2-t1
  read (unit=line,fmt=*) i
  write (unit=line2, fmt=*) b(i),c(i)
  line = '20'
  call cpu_time(t1)
  call bar(a,b,c,n)
  call cpu_time(t2)
  print *,t2-t1
  read (unit=line,fmt=*) i
  write (unit=line2, fmt=*) b(i),c(i)

end program main

[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function

[mail at pietrodelugas dot it]

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

--- Comment #4 from Pietro Delugas  ---
a quick and dirty workaround is to move all the routines in the "leng"
interface at the bottom of the file. But some compilers do not accept this code
as valid. 

A better solution is to move  the leng subroutines in a module by their own and
import the interface.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #23 from Martin Liška  ---
I can easily split insn-emit.c. Once we know which was a split should be done,
I can prepare patch for that.

[Bug middle-end/85450] ICE: invalid types in nop conversion during GIMPLE pass: ompexp

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Apr 26 07:21:42 2018
New Revision: 259667

URL: https://gcc.gnu.org/viewcvs?rev=259667=gcc=rev
Log:
2018-04-26  Richard Biener  

PR middle-end/85450
* tree-cfg.c (verify_gimple_assign_unary): Restore proper
checking of integer<->pointer conversions.
* omp-expand.c (expand_omp_for_static_nochunk): Avoid
sign-/zero-extending pointer types.
(expand_omp_for_static_chunk): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-expand.c
trunk/gcc/tree-cfg.c

[Bug middle-end/85450] ICE: invalid types in nop conversion during GIMPLE pass: ompexp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.5

[Bug tree-optimization/85529] [8/9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||7.3.1
Version|unknown |8.0.1
   Keywords||needs-bisection, wrong-code
   Last reconfirmed||2018-04-26
 Ever confirmed|0   |1
Summary|wrong code at -O2 and -O3   |[8/9 Regression] wrong code
   |on x86_64-linux-gnu |at -O2 and -O3 on
   ||x86_64-linux-gnu
   Target Milestone|--- |8.0

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug fortran/85531] New: Implement some loop fusion in the Fortran front end

[tkoenig at gcc dot gnu.org]

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

Bug ID: 85531
   Summary: Implement some loop fusion in the Fortran front end
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

See the discussion starting at https://gcc.gnu.org/ml/gcc/2018-04/msg00128.html
.

Basically, for code like

ZQICE(1:NPROMA,1:NFLEVG) = PGFL(1:NPROMA,1:NFLEVG,YI%MP)
ZQLI(1:NPROMA,1:NFLEVG) = PGFL(1:NPROMA,1:NFLEVG,YL%MP)
ZQRAIN(1:NPROMA,1:NFLEVG) = PGFL(1:NPROMA,1:NFLEVG,YR%MP)
ZQSNOW(1:NPROMA,1:NFLEVG) = PGFL(1:NPROMA,1:NFLEVG,YS%MP)

the front end could notice that the right-hand sides always agree
and translate this to


  DO J=1,NFLEVG
DO I=1,NPROMA
  ZQICE(I,J) = PGFL(I,J,YI%MP)
  ZQLI(I,J) = PGFL(I,J,YI%MP)
  ZQRAIN(I,J) = PGFL(I,J,YI%MP)
  ZQSNOW(I,J) = PGFL(I,J,YI%MP)
END DO
  END DO

This would require some data flow analysis (are we sure that PGFL
is not changed in the meantime?) and some basic block analysis.

[Bug target/83748] Local variables not aligned to word boundary

[sbansal at ciena dot com]

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

--- Comment #8 from Sumit  ---
Hi Segher,

I somehow missed the below update from your side. 
Can you help me understand if this was some known issue in GCC which got fixed
in r205896? If yes, can you let us know if got fixed in 4.8.1 version?

Thanks.

Regards,
Sumit

-Original Message-
From: segher at gcc dot gnu.org  
Sent: Wednesday, March 07, 2018 12:12 AM
To: Bansal, Sumit 
Subject: [**EXTERNAL**] [Bug target/83748] Local variables not aligned to word
boundary

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #7 from Segher Boessenkool  --- Closing
this now.

This was fixed in 2013, in r205896 -- so should be fixed in 4.9 already.

That commit added this to the documentation:

 In some cases, such as when the 'packed' attribute is applied to a
 structure field, it may not be possible to access the field with a
 single read or write that is correctly aligned for the target
 machine.  In this case GCC falls back to generating multiple
 accesses rather than code that will fault or truncate the result at
 run time.

(and also added the code to implement it; as you noticed, older compilers will
do misaligned loads if you're not careful).

--
You are receiving this mail because:
You reported the bug.