[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
OK, I think I just have gotten closer to what is wrong:

$ gfortran -g -O1 -ftree-parallelize-loops=2  do_concurrent_5.f90 
$ ./a.out
$ gfortran -g -O1 -ftree-parallelize-loops=2  -fopenmp do_concurrent_5.f90 
$ ./a.out
Speicherzugriffsfehler (Speicherabzug geschrieben)

Huh?

[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #5)
> > > The test should probably go to gcc/testsuite/gfortran.dg/gomp/.
> >
> > No, the testcase should go into libgomp/testsuite/libgomp.fortran/,
> > as it is a runtime test which needs the runtime library.
> 
> This works for me!-(

But not for me, see https://gcc.gnu.org/ml/fortran/2018-04/msg00054.html .

The only option I see at the moment is to remove the test case
and leave this PR open until the testuite is fixed, unless somebody
comes up with the magic incantation which makes this work.

I don't like this at all, but it is better than xfailing it.

[Bug c++/85356] [7/8 Regression] ICE with operator=

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c/85362] New: unnecessary checks with -fsanitize=object-size and non-int indices

[breiten at lexmark dot com]

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

Bug ID: 85362
   Summary: unnecessary checks with -fsanitize=object-size and
non-int indices
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: breiten at lexmark dot com
  Target Milestone: ---

Created attachment 43915
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43915=edit
example .c file - check for invalid index optimized out of foo() only

The following code, when compiled with gcc-6.4 or gcc-7.2 and
-fsanitize=object-size and -O2 or higher creates unnecessary code to ensure a
valid index.  I'm configured for aarch64, but also see this with armv7.

When indexing a 256-element array with either a uint8_t variable or an integer
variable shifted right by 24 or more, gcc inserts code to ensure a valid index.
 That code DOES get optimized out when using an integer variable with a smaller
or variable shift count and an explicit mask with 0xff.

With the index clearly being an unsigned 8-bit value, the check for > 256
should not be needed.  Even explicitly and'ing with 0xff does not cause the
check to get optimized out when using an 8-bit datatype.

lut[(*pi >> 23) & 0xff]);  // good
lut[(*pi >> 24) & 0xff]);  // extra check
lut[(*pi >> 25) & 0xff]);  // extra check
lut[(*pi >> 24) & 0x1]);   // extra check
lut[*pb]   // extra check
lut[*pb & 0xff];   // extra check
lut[*pb >> 7]; // extra check
lut[*pb >> 8]; // good - loads first element

/bonus/scratch/gcc64/poky/proj/tmp/work/aarch64-poky-linux/graph/*/recipe-sysroot-native/usr/bin/aarch64-poky-linux/aarch64-poky-linux-gcc
 -mcpu=cortex-a53  
--sysroot=/bonus/scratch/gcc64/poky/proj/tmp/work/aarch64-poky-linux/graph/*/recipe-sysroot
-S -O4  -fsanitize=object-size  -fno-sanitize-recover
-fsanitize-undefined-trap-on-error -Wall -Wextra   ~/sanitize.c

gcc-7.2 assembly output follows:
.arch armv8-a+crc
.file   "sanitize.c"
.text
.align  2
.p2align 4,,15
.global foo
.type   foo, %function
foo:
ldrbw1, [x0, 1]
adrpx0, lut
add x0, x0, :lo12:lut
ldr w0, [x0, x1, lsl 2]
ret
.size   foo, .-foo
.align  2
.p2align 4,,15
.global bar
.type   bar, %function
bar:
ldrbw2, [x0, 3]
adrpx1, lut
add x0, x1, :lo12:lut
add x3, x0, x2, lsl 2
sub x0, x3, x0
add x0, x0, 4
cmp x0, 1024
bhi .L6
.L4:
add x1, x1, :lo12:lut
ldr w0, [x1, x2, lsl 2]
ret
.L6:
add x0, x3, x0
cmp x3, x0
bhi .L4
brk #1000
.size   bar, .-bar
.align  2
.p2align 4,,15
.global baz
.type   baz, %function
baz:
ldrbw2, [x0]
adrpx1, lut
add x0, x1, :lo12:lut
add x3, x0, x2, uxtb 2
sub x0, x3, x0
add x0, x0, 4
cmp x0, 1024
bhi .L10
.L8:
add x1, x1, :lo12:lut
ldr w0, [x1, x2, lsl 2]
ret
.L10:
add x0, x3, x0
cmp x3, x0
bhi .L8
brk #1000
.size   baz, .-baz
.ident  "GCC: (GNU) 7.2.0"
.section.note.GNU-stack,"",@progbits

[Bug c/85361] New: Variable length array allowed in c89/90

[whh8b at virginia dot edu]

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

Bug ID: 85361
   Summary: Variable length array allowed in c89/90
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: whh8b at virginia dot edu
  Target Milestone: ---

Created attachment 43914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43914=edit
Code to trigger behavior.

In an attempt to fix bug 44209, I was investigating warning messages about
variable length arrays. 

The c89/90 standard appears to forbid VLAs but GCC treats their presence as
something only to warn the user about. Should this be an error instead of a
warning?

Depending on how you invoke GCC on the code attached to this report, it either
compiles with no complaints:

$ gcc -std=c89 /tmp/vla.c
$

or with a simple warning:
$  gcc -std=c89 -Wpedantic /tmp/vla.c 
/tmp/vla.c:1:13: warning: ISO C90 does not support ‘[*]’ array declarators
[-Wpedantic]
 void f(int a[*]);
$

Since gcc gives the user the option to specify which version of the c standard
to adhere to, shouldn't gcc be a little more strict when the user is explicit? 

I absolutely appeal to the wiser counsel of all the experts, but I thought I
would ask. 

Thank you!

[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc

[dclarke at blastwave dot org]

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

--- Comment #12 from Dennis Clarke  ---
Thanks .. I'll give that a try. The real objective here is to get a simple
native bootstrap going which includes libquadmath. My concern is that 
there is no support for that unless the ppc64 system has the POWER AVX
support and that certainly isn't the older PPC970 chips.

[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc

[doko at gcc dot gnu.org]

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

--- Comment #11 from Matthias Klose  ---
you might want --enable-objc-gc=auto or --disable-objc-gc. See install.texi for
the docs.

[Bug tree-optimization/85360] New: FAIL: gfortran.dg/deallocate_stat.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (ICE)

[danglin at gcc dot gnu.org]

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

Bug ID: 85360
   Summary: FAIL: gfortran.dg/deallocate_stat.f90   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer -finline-functions  (ICE)
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

In r259259,

spawn -ignore SIGHUP
/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfor
tran -B/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/home/dave/gnu/
gcc/objdir/hppa-linux-gnu/./libgfortran/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gf
ortran.dg/deallocate_stat.f90 -fno-diagnostics-show-caret
-fdiagnostics-color=ne
ver -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer
-finline-funct
ions -pedantic-errors
-B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.
libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs
-L/home/dave
/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs
-L/home/dave/gnu/gcc/objdir/h
ppa-linux-gnu/./libatomic/.libs -lm -o ./deallocate_stat.exe
during GIMPLE pass: cunrolli
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/deallocate_stat.f90:77:0:
inter
nal compiler error: Segmentation fault
0x73c7e7 crash_signal
../../gcc/gcc/toplev.c:325
0x7bc93c mark_block_for_update
../../gcc/gcc/tree-into-ssa.c:449
0x7c796b mark_use_interesting
../../gcc/gcc/tree-into-ssa.c:2546
0x7c796b prepare_use_sites_for
../../gcc/gcc/tree-into-ssa.c:2711
0x7c796b prepare_names_to_update
../../gcc/gcc/tree-into-ssa.c:2779
0x7c796b update_ssa(unsigned int)
../../gcc/gcc/tree-into-ssa.c:3345
0x86c1d3 tree_unroll_loops_completely
../../gcc/gcc/tree-ssa-loop-ivcanon.c:1469
0x86c377 execute
../../gcc/gcc/tree-ssa-loop-ivcanon.c:1668
Please submit a full bug report,

[Bug middle-end/85359] New: duplicate -Wstringop-overflow for a strcmp call with a nonstring pointer

[msebor at gcc dot gnu.org]

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

Bug ID: 85359
   Summary: duplicate -Wstringop-overflow for a strcmp call with a
nonstring pointer
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC issues two warnings for a single call to strcmp in the following test case.
 One warning is issued from expand_builtin_strcmp() in builtins.c and the other
from expand_call() in calls.c called directly from the former.

$ cat z.c && gcc -O2 -S -Wall z.c
int f (__attribute__ ((nonstring)) const char *d, const char *s)
{
  return __builtin_strcmp (d, s);
}
z.c: In function ‘f’:
z.c:3:10: warning: ‘__builtin_strcmp’ argument 1 declared attribute ‘nonstring’
[-Wstringop-overflow=]
   return __builtin_strcmp (d, s);
  ^~~
z.c:1:48: note: argument ‘d’ declared here
 int f (__attribute__ ((nonstring)) const char *d, const char *s)
^
z.c:3:10: warning: ‘__builtin_strcmp’ argument 1 declared attribute ‘nonstring’
[-Wstringop-overflow=]
   return __builtin_strcmp (d, s);
  ^~~
z.c:1:48: note: argument ‘d’ declared here
 int f (__attribute__ ((nonstring)) const char *d, const char *s)
^

[Bug target/85358] New: PowerPC: Using -mabi=ieeelongdouble -mcpu=power9 breaks __ibm128

[meissner at gcc dot gnu.org]

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

Bug ID: 85358
   Summary: PowerPC: Using -mabi=ieeelongdouble -mcpu=power9
breaks __ibm128
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

If you switch the default long double type to IEEE 128-bit
(-mabi=ieeelongdouble), the GCC compiler will crash.

Using this code:
__ibm128 add (__ibm128 a, __ibm128 b) { return a+b; }

This error is generated:
during RTL pass: expand
foo02.c: In function ‘add’:
foo02.c:1:49: internal compiler error: Segmentation fault
 __ibm128 add (__ibm128 a, __ibm128 b) { return a+b; }
~^~
0xb683ff crash_signal
/home/meissner/fsf-src/pr85075/gcc/toplev.c:325
0x86bd0f aggregate_value_p(tree_node const*, tree_node const*)
/home/meissner/fsf-src/pr85075/gcc/function.c:2040
0x6d76b4 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair*)
/home/meissner/fsf-src/pr85075/gcc/calls.c:4771
0xf2ae05 emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, rtx_def*, machine_mode)
/home/meissner/fsf-src/pr85075/gcc/rtl.h:4156
0xf01ed0 rs6000_expand_float128_convert(rtx_def*, rtx_def*, bool)
/home/meissner/fsf-src/pr85075/gcc/config/rs6000/rs6000.c:22489
0x10f318d gen_extenddfkf2(rtx_def*, rtx_def*)
/home/meissner/fsf-src/pr85075/gcc/config/rs6000/rs6000.md:7553
0xa608db maybe_emit_unop_insn(insn_code, rtx_def*, rtx_def*, rtx_code)
/home/meissner/fsf-src/pr85075/gcc/optabs.c:3547
0xa60988 emit_unop_insn(insn_code, rtx_def*, rtx_def*, rtx_code)
/home/meissner/fsf-src/pr85075/gcc/optabs.c:3570
0x80cc05 convert_mode_scalar
/home/meissner/fsf-src/pr85075/gcc/expr.c:601
0x80cc05 convert_move(rtx_def*, rtx_def*, int)
/home/meissner/fsf-src/pr85075/gcc/expr.c:268
0x80d891 convert_modes(machine_mode, machine_mode, rtx_def*, int)
/home/meissner/fsf-src/pr85075/gcc/expr.c:709
0xa6451f expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
/home/meissner/fsf-src/pr85075/gcc/optabs.c:1317
0x81b359 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/home/meissner/fsf-src/pr85075/gcc/expr.c:9715
0x808b53 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/meissner/fsf-src/pr85075/gcc/expr.c:9918
0x6e8abd expand_expr
/home/meissner/fsf-src/pr85075/gcc/expr.h:276
0x6e8abd expand_return
/home/meissner/fsf-src/pr85075/gcc/cfgexpand.c:3573
0x6e8abd expand_gimple_stmt_1
/home/meissner/fsf-src/pr85075/gcc/cfgexpand.c:3663
0x6e8abd expand_gimple_stmt
/home/meissner/fsf-src/pr85075/gcc/cfgexpand.c:3790
0x6ea667 expand_gimple_basic_block
/home/meissner/fsf-src/pr85075/gcc/cfgexpand.c:5819
0x6efdce execute
/home/meissner/fsf-src/pr85075/gcc/cfgexpand.c:6425
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Now what is happening is since there is hardware support for IEEE 128-bit
operations in power9, the GCC compiler decides it can do the calculation of IBM
double double in IEEE 128-bit and tries to do the conversion.

However, rather than converting to TFmode (long double), it converts to KFmode
(__float128/_Float128).  However, KFmode isn't properly registered (since
TFmode is used for float128), and emit_library_call_value_1 gets a NULL tree
type which aggregate_value_p crashes with a NULL pointer.

Ideally, for __ibm128 we should NOT try to use __float128 for the arithmetic,
since there are cases where the last bit is not accurate.

[Bug c++/85325] ICE on class template partial specialization for c++17

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Fixed by r258533.

[Bug fortran/68544] ICE trying to pass derived type constructor as a function

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #7 from Harald Anlauf  ---
(In reply to Gerhard Steinmetz from comment #3)
> Update :
> 
> 
> $ cat z1.f90
> program p
>type t
>end type
>call f(t)
> end

Adding "implicit none" triggers a misleading error message:

pr68544.f90:3:8:

   type t
1
Error: Symbol 't' at (1) has no IMPLICIT type


I think the code is invalid.  Intel writes:

pr68544.f90(5): error #6478: A type-name must not be used as a variable.   [T]
  call f(t)
-^
compilation aborted for pr68544.f90 (code 1)

[Bug c++/85356] [7/8 Regression] ICE with operator=

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||jakub at gcc dot gnu.org

[Bug fortran/85357] New: Regression: gfortran versions 7.2.0/8.0.1 reject F03 procedure overriding

[c...@mnet-mail.de]

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

Bug ID: 85357
   Summary: Regression: gfortran versions 7.2.0/8.0.1 reject F03
procedure overriding
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: c...@mnet-mail.de
  Target Milestone: ---

Created attachment 43913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43913=edit
gfortran 7.2.0/8.0.1 error messages for above procedure overriding code

The following valid Fortran 2003 (sample) code, that uses subroutine 
overriding, fails to compile with both gfortran 7.2.0 and 8.0.1 versions,
but did compile with gfortran 7.1. 

It also compiles fine with PGI/Nvidia's pgfortran (17.4) and (LLVM-)flang
(6.0).

module base

   implicit none

   type, abstract :: base_type
   contains
  procedure :: summation
   end type base_type

contains

   subroutine summation(self,i,j)
  class(base_type) :: self
  integer(4), intent(in) :: i
  integer(4), intent(out) :: j
  j = i + 1
   end subroutine summation

end module base

module extended

   use base

   implicit none

   type, extends(base_type) :: extended_type
   contains
  procedure :: summation
   end type extended_type

contains

   subroutine summation(self,i,j)
  class(extended_type) :: self
  integer(4), intent(in) :: i
  integer(4), intent(out) :: j
  j = i + 2
   end subroutine summation

end module extended

Compiler error messages (identical for both gfortran versions) are attached 
as a separate file below.

gfortran Version 7.2.0 used is:

Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.2.0-1ubuntu1~16.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-1ubuntu1~16.04) 


gfortran Version 8.0.1 used is:

Using built-in specs.
COLLECT_GCC=/home/kk/Gcc-8/bin/gfortran8
COLLECT_LTO_WRAPPER=/home/kk/Gcc-8/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-checking
--enable-languages=c,c++,fortran --disable-multilib --enable-multiarch
--enable-shared --enable-threads=posix --program-suffix=8
--with-gmp=/usr/local/lib --with-mpc=/usr/lib --with-mpfr=/usr/lib
--without-included-gettext --with-system-zlib --with-tune=generic
--prefix=/home/kk/GCC-8
Thread model: posix
gcc version 8.0.1 20180409 (experimental) (GCC)

[Bug target/85347] New testcase vec-ldl-1.c FAILs on powerpc64-linux

[kelvin at gcc dot gnu.org]

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

--- Comment #1 from kelvin at gcc dot gnu.org ---
FWIW, the test runs ok on bns -m32 as written.

Executing on host: /home/kelvin/gcc/build/gcc-trunk4fixvecldl.b4patch/gcc/xgcc
\
-B/home/kelvin/gcc/build/gcc-trunk4fixvecldl.b4patch/gcc/
/home/kelvin/gcc/gcc-\
trunk4fixvecldl.b4patch/gcc/testsuite/gcc.target/powerpc/vec-ldl-1.c  
-fno-dia\
gnostics-show-caret -fdiagnostics-color=never   -maltivec -O0 -Wall  -lm  
-m32\
  -o ./vec-ldl-1.exe(timeout = 300)
spawn /home/kelvin/gcc/build/gcc-trunk4fixvecldl.b4patch/gcc/xgcc
-B/home/kelvi\
n/gcc/build/gcc-trunk4fixvecldl.b4patch/gcc/
/home/kelvin/gcc/gcc-trunk4fixvecl\
dl.b4patch/gcc/testsuite/gcc.target/powerpc/vec-ldl-1.c
-fno-diagnostics-show-c\
aret -fdiagnostics-color=never -maltivec -O0 -Wall -lm -m32 -o
./vec-ldl-1.exe^\
M
PASS: gcc.target/powerpc/vec-ldl-1.c (test for excess errors)

Would be nice to know where this fails so I can confirm that my "fix" works.

[Bug c++/85353] deprecation warning issued on data member with initializer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed with the extended test case below and __attribute__ ((deprecated)). 
It doesn't appear to be a regression.

$ cat pr85353.C && gcc -S -Wall pr85353.C
struct A {
  __attribute__ ((deprecated)) int x = 0;
} a;

struct B {
  __attribute__ ((deprecated)) int y;
} b;

struct C {
  __attribute__ ((deprecated)) int x = 0;
  __attribute__ ((deprecated)) int y;
} c;
pr85353.C: In constructor ‘constexpr A::A()’:
pr85353.C:1:8: warning: ‘A::x’ is deprecated [-Wdeprecated-declarations]
 struct A {
^
pr85353.C:2:40: note: declared here
   __attribute__ ((deprecated)) int x = 0;
^
pr85353.C:1:8: warning: ‘A::x’ is deprecated [-Wdeprecated-declarations]
 struct A {
^
pr85353.C:2:40: note: declared here
   __attribute__ ((deprecated)) int x = 0;
^
pr85353.C: At global scope:
pr85353.C:3:3: note: synthesized method ‘constexpr A::A()’ first required here
 } a;
   ^
pr85353.C: In constructor ‘C::C()’:
pr85353.C:9:8: warning: ‘C::x’ is deprecated [-Wdeprecated-declarations]
 struct C {
^
pr85353.C:10:40: note: declared here
   __attribute__ ((deprecated)) int x = 0;
^
pr85353.C:9:8: warning: ‘C::x’ is deprecated [-Wdeprecated-declarations]
 struct C {
^
pr85353.C:10:40: note: declared here
   __attribute__ ((deprecated)) int x = 0;
^
pr85353.C:9:8: warning: ‘C::y’ is deprecated [-Wdeprecated-declarations]
 struct C {
^
pr85353.C:11:36: note: declared here
   __attribute__ ((deprecated)) int y;
^
pr85353.C:9:8: warning: ‘C::y’ is deprecated [-Wdeprecated-declarations]
 struct C {
^
pr85353.C:11:36: note: declared here
   __attribute__ ((deprecated)) int y;
^
pr85353.C: At global scope:
pr85353.C:12:3: note: synthesized method ‘C::C()’ first required here
 } c;
   ^

[Bug c++/85356] [7/8 Regression] ICE with operator=

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Target Milestone|--- |7.4
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r241944.

[Bug c++/85348] ostringstream with #pragma pack(1) causes stack smashing error

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
(In reply to Martin Sebor from comment #5)
...
> Another alternative would be to implicitly reset the #pragma pack on "entry"
> to every C++ standard header (or even every header), and restore it on
> "exit."

I meant on entry to every system header.

[Bug c++/85348] ostringstream with #pragma pack(1) causes stack smashing error

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
I think the -Wpacked-not-aligned warning would work well here.  There was a
request some time ago to issue a warning for things like:

  struct __attribute__ ((packed)) S {
std::mutex mtx;
...
  };

Decorating std::mutex (and other C++ standard library classes that need to be
aligned) with attribute warn_if_not_aligned would trigger the warning.

Alternatively, adding a new #pragma warn_if_not_aligned to effectively annotate
all type definitions in a header with the attribute would avoid having to
modify every class in the C++ standard library to add the attribute explicitly.

Another alternative would be to implicitly reset the #pragma pack on "entry" to
every C++ standard header (or even every header), and restore it on "exit."

[Bug target/85345] Missing ENDBR in IFUNC resolver

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

[Bug target/85345] Missing ENDBR in IFUNC resolver

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hubicka at ucw dot cz

--- Comment #1 from H.J. Lu  ---
/* Return true when function is only called directly or it has alias.
   i.e. it is not externally visible, address was not taken and
   it is not used in any other non-standard way.  */

inline bool 
cgraph_node::only_called_directly_or_aliased_p (void)
{
  gcc_assert (!global.inlined_to);
  return (!force_output && !address_taken
  && !used_from_other_partition
  && !DECL_VIRTUAL_P (decl)
  && !DECL_STATIC_CONSTRUCTOR (decl)
  && !DECL_STATIC_DESTRUCTOR (decl)
  && !used_from_object_file_p ()
  && !externally_visible);
}

should return false for IFUNC resolver, which is called indirectly.

[Bug c++/85356] New: [7/8 Regression] ICE with operator=

[reichelt at gcc dot gnu.org]

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

Bug ID: 85356
   Summary: [7/8 Regression] ICE with operator=
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following valid code snippet triggers an ICE since GCC 7.1.0
when compiled with "-std=c++1z":

==
struct A
{
  A& operator=(int);
};

void foo(A&(A::*)(int));

template void bar()
{
  foo(::operator=);
}
==

bug.cc: In function 'void bar()':
bug.cc:10:20: internal compiler error: in type_throw_all_p, at cp/except.c:1185
   foo(::operator=);
^
0x610678 type_throw_all_p(tree_node const*)
../../gcc/gcc/cp/except.c:1185
0x878e58 noexcept_conv_p
../../gcc/gcc/cp/cvt.c:2015
0x878e58 fnptr_conv_p(tree_node*, tree_node*)
../../gcc/gcc/cp/cvt.c:2041
0x8370d1 resolve_address_of_overloaded_function
../../gcc/gcc/cp/class.c:7713
0x81de96 standard_conversion
../../gcc/gcc/cp/call.c:1122
0x82989f implicit_conversion
../../gcc/gcc/cp/call.c:1843
0x82ad9a add_function_candidate
../../gcc/gcc/cp/call.c:2203
0x82c45b add_candidates
../../gcc/gcc/cp/call.c:5533
0x82c8d1 add_candidates
../../gcc/gcc/cp/call.c:4192
0x82c8d1 perform_overload_resolution
../../gcc/gcc/cp/call.c:4200
0x82e942 build_new_function_call(tree_node*, vec**, int)
../../gcc/gcc/cp/call.c:4273
0x9ace05 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2534
0x93813a cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:7235
0x938990 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8314
0x91880f cp_parser_cast_expression
../../gcc/gcc/cp/parser.c:9082
0x91901a cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:9183
0x91a854 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9478
0x91af58 cp_parser_expression
../../gcc/gcc/cp/parser.c:9647
0x91cc38 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:11123
0x92306d cp_parser_statement
../../gcc/gcc/cp/parser.c:10927
Please submit a full bug report, [etc.]

[Bug rtl-optimization/85354] [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #3 from Rainer Orth  ---
And on sparc-sun-solaris2.11 (both 32 and 64-bit) as well as
i386-pc-solaris2.11
(64-bit only).

[Bug fortran/82065] gfortran rejects redundant use of intrinsic module constant

[anlauf at gmx dot de]

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

--- Comment #5 from Harald Anlauf  ---
This looks pretty much like a namespace problem.

Adding in the example in comment #4

common /x/ integer_kinds

e.g. to subroutine sub1 makes the code illegal but compile.
It then prints:

   1   2   4   8
   0   0   0   0

I have looked at use_iso_fortran_env_module in module.c, but
frankly I do not understand how the code is supposed to work.

[Bug rtl-optimization/85354] [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
It fails on x86_64-linux as well.

[Bug rtl-optimization/85354] [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||abel at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |amonakov at gcc dot 
gnu.org

--- Comment #1 from Alexander Monakov  ---
Thanks. Judging from the backtrace, we shouldn't call cleanup_cfg after
dominators are computed: it will invalidate dominators without freeing or
fixing them. I wonder if that's "by design".

A simple way out is to run cleanup_cfg early enough. I'll bootstrap/regtest the
following on gcc112:

diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index 50a7daafba6..ee970522890 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -30,7 +30,6 @@ along with GCC; see the file COPYING3.  If not see
 #include "cfgrtl.h"
 #include "cfganal.h"
 #include "cfgbuild.h"
-#include "cfgcleanup.h"
 #include "insn-config.h"
 #include "insn-attr.h"
 #include "recog.h"
@@ -6122,9 +6121,6 @@ make_regions_from_loop_nest (struct loop *loop)
 void
 sel_init_pipelining (void)
 {
-  /* Remove empty blocks: their presence can break assumptions elsewhere,
- e.g. the logic to invoke update_liveness_on_insn in sel_region_init.  */
-  cleanup_cfg (0);
   /* Collect loop information to be used in outer loops pipelining.  */
   loop_optimizer_init (LOOPS_HAVE_PREHEADERS
| LOOPS_HAVE_FALLTHRU_PREHEADERS
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index cd29df35666..59762964c6e 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tm_p.h"
 #include "regs.h"
 #include "cfgbuild.h"
+#include "cfgcleanup.h"
 #include "insn-config.h"
 #include "insn-attr.h"
 #include "params.h"
@@ -7661,6 +7662,10 @@ sel_sched_region (int rgn)
 static void
 sel_global_init (void)
 {
+  /* Remove empty blocks: their presence can break assumptions elsewhere,
+ e.g. the logic to invoke update_liveness_on_insn in sel_region_init.  */
+  cleanup_cfg (0);
+
   calculate_dominance_info (CDI_DOMINATORS);
   alloc_sched_pools ();

[Bug c++/85355] new test case g++.dg/warn/Wzero-as-null-pointer-constant-7.C fails

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub   
Date: Wed Apr 11 15:55:15 2018  
New Revision: 259325

URL: https://gcc.gnu.org/viewcvs?rev=259325=gcc=rev   
Log:
PR c++/70808
* g++.dg/warn/Wzero-as-null-pointer-constant-7.C: Require c++11 
effective target.   

Modified:   
trunk/gcc/testsuite/ChangeLog   
trunk/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C

[Bug c++/85355] New: new test case g++.dg/warn/Wzero-as-null-pointer-constant-7.C fails

[seurer at gcc dot gnu.org]

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

Bug ID: 85355
   Summary: new test case
g++.dg/warn/Wzero-as-null-pointer-constant-7.C fails
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

It looks like it is compiling with -std=gnu++98 but using a feature only
supported in later standards.

spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -Wzero-as-null-pointer-constant -S -o
Wzero-as-null-pointer-constant-7.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C:4:17:
warning: extended initializer lists only available with -std=c++11 or
-std=gnu++11
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C:5:9:
error: expected constructor, destructor, or type conversion before '(' token
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C:4:17:
warning: extended initializer lists only available with -std=c++11 or
-std=gnu++11
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C:5:9:
error: expected constructor, destructor, or type conversion before '(' token

FAIL: g++.dg/warn/Wzero-as-null-pointer-constant-7.C  -std=gnu++98 (test for
excess errors)
Excess errors:
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C:4:17:
warning: extended initializer lists only available with -std=c++11 or
-std=gnu++11
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C:5:9:
error: expected constructor, destructor, or type conversion before '(' token

[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> > The test should probably go to gcc/testsuite/gfortran.dg/gomp/.
>
> No, the testcase should go into libgomp/testsuite/libgomp.fortran/,
> as it is a runtime test which needs the runtime library.

This works for me!-(

[Bug fortran/85352] Incorrect error diagnosed for dummy argument used in specification expression to subprogram with ENTRY

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (8.0).

[Bug rtl-optimization/85354] New: [8 regression] ICE with gcc.dg/graphite/pr84872.c starting with r259313

[seurer at gcc dot gnu.org]

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

Bug ID: 85354
   Summary: [8 regression] ICE with gcc.dg/graphite/pr84872.c
starting with r259313
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/graphite/pr84872.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O1
-floop-parallelize-all -freorder-blocks-and-partition -fschedule-insns2
-fselective-scheduling2 -fsel-sched-pipelining -fno-tree-dce -S -o pr84872.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/graphite/pr84872.c: In function
'foo':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/graphite/pr84872.c:19:1: error:
dominator of 3 status unknown
during RTL pass: sched2
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/graphite/pr84872.c:19:1:
internal compiler error: in verify_dominators, at dominance.c:1184
0x10493167 verify_dominators(cdi_direction)
/home/seurer/gcc/gcc-test2/gcc/dominance.c:1184
0x10493457 checking_verify_dominators
/home/seurer/gcc/gcc-test2/gcc/dominance.h:76
0x10493457 calculate_dominance_info(cdi_direction)
/home/seurer/gcc/gcc-test2/gcc/dominance.c:746
0x103fb3ff flow_loops_find(loops*)
/home/seurer/gcc/gcc-test2/gcc/cfgloop.c:431
0x107827f3 loop_optimizer_init(unsigned int)
/home/seurer/gcc/gcc-test2/gcc/loop-init.c:93
0x1093202f sel_init_pipelining()
/home/seurer/gcc/gcc-test2/gcc/sel-sched-ir.c:6132
0x1093c093 sel_find_rgns()
/home/seurer/gcc/gcc-test2/gcc/sel-sched-ir.c:6276
0x10923417 find_rgns
/home/seurer/gcc/gcc-test2/gcc/sched-rgn.c:1077
0x10923417 sched_rgn_init(bool)
/home/seurer/gcc/gcc-test2/gcc/sched-rgn.c:3250
0x10954d3b sel_global_init
/home/seurer/gcc/gcc-test2/gcc/sel-sched.c:7671
0x10954d3b run_selective_scheduling()
/home/seurer/gcc/gcc-test2/gcc/sel-sched.c:7725
0x109255a3 rest_of_handle_sched2
/home/seurer/gcc/gcc-test2/gcc/sched-rgn.c:3729
0x109255a3 execute
/home/seurer/gcc/gcc-test2/gcc/sched-rgn.c:3873


r259313 | amonakov | 2018-04-11 05:40:07 -0500 (Wed, 11 Apr 2018) | 9 lines

sel-sched: run cleanup_cfg just before loop_optimizer_init (PR 84659)

PR rtl-optimization/85659
* sel-sched-ir.c (sel_init_pipelining): Invoke cleanup_cfg.

testsuite/
* gcc.dg/pr84659.c: New test.

[Bug testsuite/85190] [8 Regression] gcc.dg/vect/pr81196.c FAILs

[amker at gcc dot gnu.org]

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

--- Comment #9 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Apr 11 16:50:16 2018
New Revision: 259326

URL: https://gcc.gnu.org/viewcvs?rev=259326=gcc=rev
Log:
gcc/testsuite
PR testsuite/85190
* gcc.dg/vect/pr81196.c: Remove function with undefined behavior.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/pr81196.c

[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Duplicate of pr34663?

[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
No, the testcase should go into libgomp/testsuite/libgomp.fortran/, as it is a
runtime test which needs the runtime library.  But see
http://gcc.gnu.org/ml/gcc-patches/2018-04/msg00549.html for other issues with
that test.

[Bug c++/85353] New: deprecation warning issued on data member with initializer

[haining.cpp at gmail dot com]

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

Bug ID: 85353
   Summary: deprecation warning issued on data member with
initializer
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haining.cpp at gmail dot com
  Target Milestone: ---

The following code issues deprecation warnings. "warning: 'Cls::x' is
deprecated "
struct Cls {
  [[deprecated]] int x = 0; // removing = 0 silences warning
};

int main() {
  Cls c;
}

The warning is only issued when the `= 0` is present. This code shouldn't be
warning at all. Live at wandbox: https://wandbox.org/permlink/sqR7DvAlMfllCES0

[Bug fortran/85352] Incorrect error diagnosed for dummy argument used in specification expression to subprogram with ENTRY

[mecej4 at outlook dot com]

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

--- Comment #1 from mecej4  ---
The bug goes away if some apparently unrelated changes are made. For example,
if "ENTRY rfinit" is commented out, the bug is not seen.

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
I asked Peter about that yesterday.  The access to *p in your example is still
meant to be undefined even under the proposed provenance rules.  Here's his
response: http://www.open-std.org/jtc1/sc22/wg14/15051  It's not yet entirely
clear to me how to derive this answer from the proposed wording but if it can't
be it's presumably just a bug that will be fixed.

I think the intent of the "happens to immediately follow the first array 
object in the address space" was to allow implementations to return true for
the ( + i == ) kind of equalities and the text just came out wrong (as a
requirement rather than a permission).  The text was added in C99 but I haven't
yet been able to find the paper that added it.

The implications of the "immediately follows the first array" sentence for
equality having to return true would be at odds with the "single provenance"
and so the result of the equality is only specified with -fno-provenance
(otherwise it's unspecified).

Regarding your suggestion for the equality being undefined, since it's
well-defined in C and  explicitly unspecified in C++, changing it to undefined
in C would introduce an incompatibility with C++.  That would go against WG14's
goal (part of C2X charter) to align more closely with C++.  To make it pass in
WG14, C++ would most likely have to agree to change first.  But I'll bring it
up during the meeting.

The rationale for the-f[no-]provenance option is discussed in N2119.  It sounds
like the authors think it disabling the provenance rules might make for more
intuitive behavior and help avoid bugs.  I'll also bring it at the meeting.

[Bug fortran/85352] New: Incorrect error diagnosed for dummy argument used in specification expression to subprogram with ENTRY

[mecej4 at outlook dot com]

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

Bug ID: 85352
   Summary: Incorrect error diagnosed for dummy argument used in
specification expression to subprogram with ENTRY
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mecej4 at outlook dot com
  Target Milestone: ---

Created attachment 43912
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43912=edit
fortran free form source code

There are some old codes (e.g., RMAT SWMOL3 - Molecule-Sweden code) in which
there are subroutines with ENTRY statements. A dummy argument to the ENTRY name
is allowed in specification expressions; F2003 12.5.2.4 says:

"If a dummy argument is used in a specification expression to specify an array
bound or character length of an object, the appearance of the object in a
statement that is executed during a procedure reference is permitted only if
the dummy argument appears in the dummy argument list of the procedure name
referenced and it is present (12.4.1.6)."

I constructed the example code to mimic the SWMOL3 code
http://www.tampa.phys.ucl.ac.uk/rmat/old/swmol3.f .

G95, Intel Fortran 18 and Lahey-Fujitsu 7.1 compile the example code with no
error messages. Gfortran 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC) says:

"sh-4.4$ gfortran -c bug.f90  
bug.f90:17:27:   

   CALL acomp(Sabb,nuca) 
   1 
Error: Variable 'nuc1', used in a specification expression, is referenced at
(1) before the ENTRY statement in which it is a parameter bug.f90:17:27: "

[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED
   Target Milestone|7.4 |---

--- Comment #20 from Peter Bergner  ---
Closing as WONTFIX.

[Bug target/77346] [7 Regression] ICE in push_reload, at reload.c:1350

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #19 from Peter Bergner  ---
Since this is a gcc7 only bug (-mno-lra has been removed in gcc8) and LRA is
the gcc7 default (and what people should be using), we've decided that we are
going to close this as WONTFIX.  Too much other work to be done than fixing old
reload bugs.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[rguenther at suse dot de]

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

--- Comment #22 from rguenther at suse dot de  ---
On April 11, 2018 4:21:06 PM GMT+02:00, "ebotcazou at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85238
>
>--- Comment #21 from Eric Botcazou  ---
>> Looks good to me, aka OK if it passes whatever testing you think is
>> sufficient.
>
>Thanks.  There is apparently another, preexisting issue visible in Ada:
>
>$ gcc -o t t.c -flto -g 
>lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not
>implemented: Invalid argument
>
>$ gnatmake nested_controlled_alloc -flto
>gcc -c -flto nested_controlled_alloc.adb
>gnatbind -x nested_controlled_alloc.ali
>gnatlink nested_controlled_alloc.ali -flto
>lto-wrapper.exe: fatal error: file too short: No error
>
>compilation terminated.
>c:/home/botcazou/anod-wave/x86_64-windows/gcc-gcc-head.0/install/bin/../libexec/gcc/x86_64-pc-mingw32/8.0.1/ld.exe:
>error: lto-wrapper failed
>
>but adding -g0 makes it disappear:
>
>$ gnatmake nested_controlled_alloc -flto -g0
>gcc -c -flto -g0 nested_controlled_alloc.adb
>gnatbind -x nested_controlled_alloc.ali
>gnatlink nested_controlled_alloc.ali -flto -g0
>
>Do you have any idea about what's going on here?

Huh, no. Never seen that. When debugging lto-wrapper issues I place a
raise(SIGSTOP) inside it and attach

[Bug c++/70808] Spurious -Wzero-as-null-pointer-constant for nullptr_t

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 11 15:55:15 2018
New Revision: 259325

URL: https://gcc.gnu.org/viewcvs?rev=259325=gcc=rev
Log:
PR c++/70808
* g++.dg/warn/Wzero-as-null-pointer-constant-7.C: Require c++11
effective target.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C

[Bug target/85321] Missing documentation and option misc for ppc64le

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||acsawdey at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from acsawdey at gcc dot gnu.org ---
All fixed in 259324.

[Bug c++/85348] ostringstream with #pragma pack(1) causes stack smashing error

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
What warning do you expect? The problem is not specific to ostringstream, so we
can't just add a warning when you try to use packing with that particular type.

It happens for any code which you link to and don't consistently use the same
packing. ostringstream just happens to be instantiated in libstdc++.dll
(without the packing pragmas) so you have objects that use a different ABI to
the library.

[Bug target/85321] Missing documentation and option misc for ppc64le

[acsawdey at gcc dot gnu.org]

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

--- Comment #5 from acsawdey at gcc dot gnu.org ---
Author: acsawdey
Date: Wed Apr 11 15:25:42 2018
New Revision: 259324

URL: https://gcc.gnu.org/viewcvs?rev=259324=gcc=rev
Log:
2018-04-11  Aaron Sawdey  

PR target/85321
* doc/invoke.texi (RS/6000 and PowerPC Options): Document options
-mcall- and -mtraceback=. Remove options -mabi=spe and -mabi=no-spe
from PowerPC section.
* config/rs6000/sysv4.opt (mcall-): Improve help text.
* config/rs6000/rs6000.opt (mblock-compare-inline-limit=): Trim
help text that is too long.
* config/rs6000/rs6000.opt (mblock-compare-inline-loop-limit=): Trim
help text that is too long.
* config/rs6000/rs6000.opt (mstring-compare-inline-limit=): Trim
help text that is too long.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.opt
trunk/gcc/config/rs6000/sysv4.opt
trunk/gcc/doc/invoke.texi

[Bug gcov-profile/85351] New: [GCOV] Wrong coverage with an executed exit() in if statement within a called function

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85351
   Summary: [GCOV] Wrong coverage with an executed exit() in if
statement within a called function
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

/** small.c */
$ cat small.c
#include 

void foo1(int x)
{
  if (x < 1)
exit(0);
}

int main()
{
  foo1(0);
  return 0;
}

$ gcc --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:71.43% of 7
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:
1:3:void foo1(int x)
-:4:{
1:5:  if (x < 1)
1:6:exit(0);
#:7:}
-:8:
1:9:int main()
-:   10:{
1:   11:  foo1(0);
#:   12:  return 0;
-:   13:}

*
Line #7 is wrongly marked as "#"
*

/** small2.c */
$ cat small2.c
#include 

void foo1(int x)
{
  // if (x < 1)
exit(0);
}

int main()
{
  foo1(0);
  return 0;
}

$ gcc --coverage small2.c; ./a.out; gcov-8 small2.c; cat small2.c.gcov
File 'small2.c'
Lines executed:80.00% of 5
Creating 'small2.c.gcov'

-:0:Source:small2.c
-:0:Graph:small2.gcno
-:0:Data:small2.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:
1:3:void foo1(int x)
-:4:{
-:5:  // if (x < 1)
1:6:exit(0);
-:7:}
-:8:
1:9:int main()
-:   10:{
1:   11:  foo1(0);
#:   12:  return 0;
-:   13:}



***
While comparing the coverage of small.c and small2.c, we can find that the
marks of Line #7 in these two files is inconsistant. This confirms that the
coverage of small.c is incorrect.

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to avieira from comment #5)
> I have been looking at this and the problem does indeed lie with the
> register not being a hard reg because aarch64_mem_pair_lanes_operand invokes
> aarch64_legitimate_address_p with 1 for the strict_p argument.
> 
> Changing that to a 0 yields the desired results for this testcase. Also good
> to note that this is not an ilp32 issue only, because of this we would also
> miss cases where the argument hard-register would not be successfully
> combined into the load/store. Say if for instance the argument in the test
> function were a pointer to the pointer we are addressing.
> 
> I will proceed to run tests now, if someone knows why that "strict_p" was
> being set to 1  please let me know, I am unfamiliar with this code and fear
> this might be too big a hammer.

I think requiring strict address checking in aarch64_mem_pair_lanes_operand is
overly conservative indeed. The store_pair_lanes pattern that uses it is
supposed to be created at combine-time at which point we want to allow any type
of register. Then during reg-alloc the Uml constraint enforces the strict
checking.

So I think relaxing aarch64_mem_pair_lanes_operand is the right way forward,
though of course testing will show.

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

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

--- Comment #5 from avieira at gcc dot gnu.org ---
I have been looking at this and the problem does indeed lie with the register
not being a hard reg because aarch64_mem_pair_lanes_operand invokes
aarch64_legitimate_address_p with 1 for the strict_p argument.

Changing that to a 0 yields the desired results for this testcase. Also good to
note that this is not an ilp32 issue only, because of this we would also miss
cases where the argument hard-register would not be successfully combined into
the load/store. Say if for instance the argument in the test function were a
pointer to the pointer we are addressing.

I will proceed to run tests now, if someone knows why that "strict_p" was being
set to 1  please let me know, I am unfamiliar with this code and fear this
might be too big a hammer.

[Bug rtl-optimization/84566] error: qsort comparator not anti-commutative: -1, -1 on aarch64 in sched1

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #5 from Alexander Monakov  ---
Fixed.

[Bug middle-end/82407] [meta-bug] qsort_chk fallout tracking

[amonakov at gcc dot gnu.org]

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

Bug 84566 Summary: error: qsort comparator not anti-commutative: -1, -1 on 
aarch64 in sched1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566

   What|Removed |Added

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

[Bug rtl-optimization/85099] [meta-bug] selective scheduling issues

[amonakov at gcc dot gnu.org]

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

Bug 84566 Summary: error: qsort comparator not anti-commutative: -1, -1 on 
aarch64 in sched1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84566

   What|Removed |Added

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

[Bug target/84301] [6/7 Regression] ICE in create_pre_exit, at mode-switching.c:451

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

  Known to work||8.0
   Assignee|unassigned at gcc dot gnu.org  |amonakov at gcc dot 
gnu.org
Summary|[6/7/8 Regression] ICE in   |[6/7 Regression] ICE in
   |create_pre_exit, at |create_pre_exit, at
   |mode-switching.c:451|mode-switching.c:451
  Known to fail|8.0 |

--- Comment #6 from Alexander Monakov  ---
Fixed on the trunk.

[Bug rtl-optimization/84566] error: qsort comparator not anti-commutative: -1, -1 on aarch64 in sched1

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
Author: amonakov
Date: Wed Apr 11 14:36:04 2018
New Revision: 259322

URL: https://gcc.gnu.org/viewcvs?rev=259322=gcc=rev
Log:
sched-deps: respect deps->readonly in macro-fusion (PR 84566)

PR rtl-optimization/84566
* sched-deps.c (sched_analyze_insn): Check deps->readonly when invoking
sched_macro_fuse_insns.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-deps.c

[Bug gcov-profile/85350] New: [GCOV] wrong coverage when using constant variable in struct declaration

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85350
   Summary: [GCOV] wrong coverage when using constant variable in
struct declaration
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)

$ cat small.c
#include 

int main (void)
{
  const int t = 2;
  struct s1 {
int x;
int g[t];
  };

  struct s2 {
int x;
int g[2];
  };

  printf("Sucess!\n");
  return 0;
}

$ gcc --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
Sucess!
File 'small.c'
Lines executed:100.00% of 6
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:
1:3:int main (void)
-:4:{
1:5:  const int t = 2;
2:6:  struct s1 {
-:7:int x;
1:8:int g[t];
-:9:  };
-:   10:
-:   11:  struct s2 {
-:   12:int x;
-:   13:int g[2];
-:   14:  };
-:   15:
1:   16:  printf("Sucess!\n");
1:   17:  return 0;
-:   18:}


Line #6 is wrongly marked as executed twice. 
The second struct declaration is not using constant variable t. By comparing
these two structs, we can know that constant variable should be the reason that
leads to the incorrect coverage.

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[avieira at gcc dot gnu.org]

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

avieira at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug target/83009] gcc.target/aarch64/store_v2vec_lanes.c fails with -mabi=ilp32

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug target/84301] [6/7/8 Regression] ICE in create_pre_exit, at mode-switching.c:451

[amonakov at gcc dot gnu.org]

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

--- Comment #5 from Alexander Monakov  ---
Author: amonakov
Date: Wed Apr 11 14:32:32 2018
New Revision: 259321

URL: https://gcc.gnu.org/viewcvs?rev=259321=gcc=rev
Log:
sched-rgn: run add_branch_dependencies for sel-sched (PR 84301)

PR target/84301
* sched-rgn.c (add_branch_dependences): Move sel_sched_p check here...
(compute_block_dependences): ... from here.

testsuite/
* gcc.target/i386/pr84301.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr84301.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-rgn.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/85342] [8 Regression] ICE: SIGSEGV in copyprop_hardreg_forward_1 (regcprop.c:995) with -O2 -mavx512vl

[jakub at gcc dot gnu.org]

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

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

Untested fix.  After failed apply_change_group, recog_data.insn is NULL and
rest of recog_data is garbage, so there is no need to update it.

[Bug target/85342] [8 Regression] ICE: SIGSEGV in copyprop_hardreg_forward_1 (regcprop.c:995) with -O2 -mavx512vl

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Latent before that, actually started with my r109013.

[Bug target/85238] [8 Regression] lto-wrapper: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument on Cygwin

[ebotcazou at gcc dot gnu.org]

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

--- Comment #21 from Eric Botcazou  ---
> Looks good to me, aka OK if it passes whatever testing you think is
> sufficient.

Thanks.  There is apparently another, preexisting issue visible in Ada:

$ gcc -o t t.c -flto -g 
lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not
implemented: Invalid argument

$ gnatmake nested_controlled_alloc -flto
gcc -c -flto nested_controlled_alloc.adb
gnatbind -x nested_controlled_alloc.ali
gnatlink nested_controlled_alloc.ali -flto
lto-wrapper.exe: fatal error: file too short: No error

compilation terminated.
c:/home/botcazou/anod-wave/x86_64-windows/gcc-gcc-head.0/install/bin/../libexec/gcc/x86_64-pc-mingw32/8.0.1/ld.exe:
error: lto-wrapper failed

but adding -g0 makes it disappear:

$ gnatmake nested_controlled_alloc -flto -g0
gcc -c -flto -g0 nested_controlled_alloc.adb
gnatbind -x nested_controlled_alloc.ali
gnatlink nested_controlled_alloc.ali -flto -g0

Do you have any idea about what's going on here?

[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The test should probably go to gcc/testsuite/gfortran.dg/gomp/.

[Bug c++/85348] ostringstream with #pragma pack(1) causes stack smashing error

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug gcov-profile/85349] [GCOV] struct varaible definition in while(1) will cause incorrect coverage

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-11
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug c++/85348] ostringstream with #pragma pack(1) causes stack smashing error

[crillion at tiscali dot it]

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

crillion at tiscali dot it changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #3 from crillion at tiscali dot it ---
the point is that this directive was in a deeply included header of a library I
use. It took me some amount of time (I spent some work hours) to isolate the
problem which emerges just in the ostringstream creation. I wasn't aware of
this behaviour of the generated code before; if the compiler had warned me, I
would have resolved more quickly.

[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
My patch doesn't fix g++.dg/eh/sighandle.C compiled with

-O2 -fcf-protection -mcet

[Bug target/85342] [8 Regression] ICE: SIGSEGV in copyprop_hardreg_forward_1 (regcprop.c:995) with -O2 -mavx512vl

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r255268.

[Bug gcov-profile/85349] New: [GCOV] struct varaible definition in while(1) will cause incorrect coverage

[yangyibiao at nju dot edu.cn]

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

Bug ID: 85349
   Summary: [GCOV] struct varaible definition in while(1) will
cause incorrect coverage
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu
8-20170923-1ubuntu2)

$ cat small.c
struct F {int x;};

int main()
{
  int x = 0;
  while (1) // first while
  {
struct F f1 = {x};
if (f1.x > 0)
  break;
x++;
  }

  x = 0;
  while (1) // second while
  {
if (x > 0)
  break;
x++;
  }

  x = 0;
  while (x < 10) // third while
  {
struct F f2 = {x};
if (f2.x > 0)
  break;
x++;
  }

  x = 0;
  while (x < 10)
  {
if (x > 0)
  break;
x++;
  }
  return 0;
}


$ gcc --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 23
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:struct F {int x;};
-:2:
1:3:int main()
-:4:{
1:5:  int x = 0;
-:6:  while (1) // first while
1:7:  {
2:8:struct F f1 = {x};
2:9:if (f1.x > 0)
1:   10:  break;
1:   11:x++;
-:   12:  }
-:   13:
1:   14:  x = 0;
-:   15:  while (1) // second while
-:   16:  {
2:   17:if (x > 0)
1:   18:  break;
1:   19:x++;
-:   20:  }
-:   21:
1:   22:  x = 0;
2:   23:  while (x < 10) // third while
-:   24:  {
2:   25:struct F f2 = {x};
2:   26:if (f2.x > 0)
1:   27:  break;
1:   28:x++;
-:   29:  }
-:   30:
1:   31:  x = 0;
2:   32:  while (x < 10)
-:   33:  {
2:   34:if (x > 0)
1:   35:  break;
1:   36:x++;
-:   37:  }
1:   38:  return 0;
-:   39:}


Line #7 is wrongly marked as "1". 

Line #16 and Line #33 are also the first braces of while statement. While they
are marked as "-". 

By comparing these three while-statements, I think the inconsistency is caused
by the struct variable definition inside the while(1) statement.

[Bug c/3885] Incorrect "invalid suffix on integer constant" error

[zackw at panix dot com]

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

Zack Weinberg  changed:

   What|Removed |Added

 CC||zackw at panix dot com

--- Comment #14 from Zack Weinberg  ---
I think we should reopen this bug and treat it as a request to improve the
diagnostics.

GCC is correct to reject tokens of the form "0x000E-0x0001", but the
accumulation of duplicate bug reports suggests that we could do a better job of
explaining what is wrong.  Proposal: whenever we are about to issue the
"invalid suffix on (integer/floating) constant" error, if the first character
of the "invalid suffix" is + or -, we say instead something like

error: invalid numeric constant ""
note: ('+'/'-') after ('e'/'p'/'E'/'P') continues a pp-number
note: to perform (addition/subtraction), put a space before the ('+'/'-')

Printing the entire pp-number token instead of just the "suffix", mentioning
the standardese term "pp-number", and calling the token an "invalid numeric
constant" instead of an "invalid integer/floating constant" should clue people
in to _why_ this apparently perverse tokenization is happening.

[Bug tree-optimization/85331] [8 Regression] during GIMPLE pass, internal compiler error: Segmentation fault (-O1 and above)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug other/84613] [meta-bug] SPEC compiler performance issues

[jakub at gcc dot gnu.org]

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

Bug 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance 
regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

   What|Removed |Added

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

[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
So hopefully fixed.

[Bug middle-end/84016] [8 Regression] Spec2000 regression around Jan 14 and Jan 19 2018

[jakub at gcc dot gnu.org]

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

Bug 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance 
regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

   What|Removed |Added

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

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[jakub at gcc dot gnu.org]

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

Bug 84149 Summary: [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance 
regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

   What|Removed |Added

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

[Bug tree-optimization/85331] [8 Regression] during GIMPLE pass, internal compiler error: Segmentation fault (-O1 and above)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 11 13:35:13 2018
New Revision: 259320

URL: https://gcc.gnu.org/viewcvs?rev=259320=gcc=rev
Log:
PR tree-optimization/85331
* vec-perm-indices.h (vec_perm_indices::clamp): Change input type
from int to HOST_WIDE_INT.

* gcc.c-torture/execute/pr85331.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr85331.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/vec-perm-indices.h

[Bug c++/85348] ostringstream with #pragma pack(1) causes stack smashing error

[pinskia at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I don't think you want to do this...   aka "doctor it hurts".

--- Comment #2 from Andrew Pinski  ---
#pragma pack(1)
causes an abi change so this is expected.

[Bug c++/85348] ostringstream with #pragma pack(1) causes stack smashing error

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I don't think you want to do this...   aka "doctor it hurts".

--- Comment #2 from Andrew Pinski  ---
#pragma pack(1)
causes an abi change so this is expected.

[Bug c++/85348] New: ostringstream with #pragma pack(1) causes stack smashing error

[crillion at tiscali dot it]

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

Bug ID: 85348
   Summary: ostringstream with #pragma pack(1) causes stack
smashing error
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crillion at tiscali dot it
  Target Milestone: ---

Hi.

  Using g++ version 7.2.0 on Windows 10 Enterprise N, installed with the
Mingw-w64 distribution, version x86_64-7.2.0-posix-seh-rt_v5-rev0, with the
following program

#pragma pack(1)

#include 

int main()
{
std::ostringstream{};
}

that I compile with the script (called from the normal windows console after
having added mingw-w64 bin path to the windows PATH variable)

g++ -pedantic -std=c++17 -Wall -Wextra -Werror=return-type -fdiagnostics-color
-s -Os program.cpp -o program_gpp.exe

the program compiles finely, but when I run it I get a crash without error
messages. The error occurs both if I don't use the -g option for debug or if I
use it.

On an older mingw-w64 version i686-510-win32-sjlj-rt_v4, used on a complex
cmake project in Debug Mode I get the crash too, with more detail in an
explicit console output as "   *** stack smashing detected ***:  terminated  ".
In release mode the error does not occur.

I understand that with #pragma pack(push,1) and #pragma pack(pop), and also by
including  BEFORE the #pragma pack(1) directive the crash does not
occur; 

But could you please issue a warning if someone uses simply #pragma pack(1)
with ostringstream ?

Thanks,

 Marco

[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  ---
Author: jamborm
Date: Wed Apr 11 13:30:53 2018
New Revision: 259319

URL: https://gcc.gnu.org/viewcvs?rev=259319=gcc=rev
Log:
Improve IPA-CP handling of self-recursive calls

2018-04-11  Martin Jambor  

PR ipa/84149
* ipa-cp.c (propagate_vals_across_pass_through): Expand comment.
(cgraph_edge_brings_value_p): New parameter dest_val, check if it is
not the same as the source val.
(cgraph_edge_brings_value_p): New parameter.
(gather_edges_for_value): Pass destination value to
cgraph_edge_brings_value_p.
(perhaps_add_new_callers): Likewise.
(get_info_about_necessary_edges): Likewise and exclude values brought
only by self-recursive edges.
(create_specialized_node): Redirect only clones of self-calling edges.
(+self_recursive_pass_through_p): New function.
(find_more_scalar_values_for_callers_subset): Use it.
(find_aggregate_values_for_callers_subset): Likewise.
(known_aggs_to_agg_replacement_list): Removed.
(decide_whether_version_node): Re-calculate known constants for all
remaining context clones.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c

[Bug ipa/85329] [8 Regression] ICE in add_to_same_comdat_group, at symtab.c:460

[doko at gcc dot gnu.org]

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

--- Comment #6 from Matthias Klose  ---
Created attachment 43910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43910=edit
preprocessed source

source package is https://launchpad.net/ubuntu/+source/i2pd

upstream is http://i2pd.website/

[Bug target/85347] New: New testcase vec-ldl-1.c FAILs on powerpc64-linux

[segher at gcc dot gnu.org]

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

Bug ID: 85347
   Summary: New testcase vec-ldl-1.c FAILs on powerpc64-linux
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

error: use of 'long long' in AltiVec types is invalid without '-mvsx'

This is without --with-cpu=, so defaulting to power4, so indeed no VSX.

[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres  ---
WORKDFORME with

% gfc -O3 -ftree-parallelize-loops=2
/opt/gcc/work/gcc/testsuite/gfortran.dg/do_concurrent_5.f90 -v
Driving: gfc -O3 -ftree-parallelize-loops=2
/opt/gcc/work/gcc/testsuite/gfortran.dg/do_concurrent_5.f90 -v
-mmacosx-version-min=10.13.0 -asm_macosx_version_min=10.13 -l gfortran
-shared-libgcc
Using built-in specs.
COLLECT_GCC=gfc
COLLECT_LTO_WRAPPER=/opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/8.0.1/lto-wrapper
Target: x86_64-apple-darwin17.5.0
Configured with: ../work/configure --prefix=/opt/gcc/gcc8w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,lto --with-gmp=/opt/mp-new
--with-system-zlib --with-isl=/opt/mp-new --enable-lto --enable-plugin
--with-arch=corei7 --with-cpu=corei7
Thread model: posix
gcc version 8.0.1 20180410 (experimental) [trunk revision 259304p8] (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-ftree-parallelize-loops=2' '-v'
'-mmacosx-version-min=10.13.0' '-asm_macosx_version_min=10.13' '-shared-libgcc'
'-mtune=corei7' '-march=corei7'
 /opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/8.0.1/f951
/opt/gcc/work/gcc/testsuite/gfortran.dg/do_concurrent_5.f90 -fPIC -quiet
-dumpbase do_concurrent_5.f90 -mmacosx-version-min=10.13.0 -mtune=corei7
-march=corei7 -auxbase do_concurrent_5 -O3 -version -ftree-parallelize-loops=2
-fintrinsic-modules-path
/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1/finclude -o
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cchHk7Ph.s
GNU Fortran (GCC) version 8.0.1 20180410 (experimental) [trunk revision
259304p8] (x86_64-apple-darwin17.5.0)
compiled by GNU C version 8.0.1 20180409 (experimental) [trunk revision
259249p9], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl
version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 8.0.1 20180410 (experimental) [trunk revision
259304p8] (x86_64-apple-darwin17.5.0)
compiled by GNU C version 8.0.1 20180409 (experimental) [trunk revision
259249p9], GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl
version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-O3' '-ftree-parallelize-loops=2' '-v'
'-mmacosx-version-min=10.13.0'  '-shared-libgcc' '-mtune=corei7'
'-march=corei7'
 as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=10.13 -o
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccv2JGs2.o
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cchHk7Ph.s
Apple LLVM version 9.1.0 (clang-902.0.39.1)
Target: x86_64-apple-darwin17.5.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
-cc1as -triple x86_64-apple-macosx10.13.0 -filetype obj -main-file-name
cchHk7Ph.s -target-cpu penryn -fdebug-compilation-dir
/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug -dwarf-debug-producer
Apple LLVM version 9.1.0 (clang-902.0.39.1) -dwarf-version=4 -mrelocation-model
pic -o /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccv2JGs2.o
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cchHk7Ph.s
Reading specs from
/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1/../../../libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-O3' '-ftree-parallelize-loops=2' '-v'
'-mmacosx-version-min=10.13.0'  '-shared-libgcc' '-mtune=corei7'
'-march=corei7'
COMPILER_PATH=/opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/8.0.1/:/opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/8.0.1/:/opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/:/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1/:/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/
LIBRARY_PATH=/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1/:/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1/../../../
COLLECT_GCC_OPTIONS='-O3' '-ftree-parallelize-loops=2' '-v'
'-mmacosx-version-min=10.13.0'  '-shared-libgcc' '-mtune=corei7'
'-march=corei7'
 /opt/gcc/gcc8w/libexec/gcc/x86_64-apple-darwin17.5.0/8.0.1/collect2 -dynamic
-arch x86_64 -macosx_version_min 10.13.0 -weak_reference_mismatches non-weak -o
a.out -L/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1
-L/opt/gcc/gcc8w/lib/gcc/x86_64-apple-darwin17.5.0/8.0.1/../../..
/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccv2JGs2.o -lgfortran -lgomp
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5
-lgcc -lSystem -v
collect2 version 8.0.1 20180410 (experimental) [trunk revision 259304p8]
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.13.0
-weak_reference_mismatches non-weak -o 

[Bug c++/85032] [8 regression] Wrong non-constant condition for static assertion

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug c++/85032] [8 regression] Wrong non-constant condition for static assertion

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Wed Apr 11 13:10:16 2018
New Revision: 259318

URL: https://gcc.gnu.org/viewcvs?rev=259318=gcc=rev
Log:
PR c++/85032
* constexpr.c (potential_constant_expression_1): Consider conversions
from classes to literal types potentially constant.

* g++.dg/cpp0x/pr51225.C: Adjust error message.
* g++.dg/cpp1z/constexpr-if21.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if21.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/pr51225.C

[Bug testsuite/85346] gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-11
  Component|fortran |testsuite
 Ever confirmed|0   |1

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

[Bug lto/85339] [8 Regression] With early LTO debug the early DWARF misses line-info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug lto/85339] [8 Regression] With early LTO debug the early DWARF misses line-info

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Wed Apr 11 13:05:35 2018
New Revision: 259317

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

PR lto/85339
* dwarf2out.c (dwarf2out_finish): Remove DW_AT_stmt_list attribute
from early DWARF output.
(dwarf2out_early_finish): Output line info unconditionally into
early DWARF and add reference to it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug fortran/85346] New: gfortran.dg/do_concurrent_5.f90 FAILs with --disable-libgomp

[segher at gcc dot gnu.org]

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

Bug ID: 85346
   Summary: gfortran.dg/do_concurrent_5.f90 FAILs with
--disable-libgomp
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

FAIL: gfortran.dg/do_concurrent_5.f90   -O  (test for excess errors)
Excess errors:
gfortran: error: libgomp.spec: No such file or directory

[Bug lto/85339] [8 Regression] With early LTO debug the early DWARF misses line-info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug target/85345] New: Missing ENDBR in IFUNC resolver

[hjl.tools at gmail dot com]

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

Bug ID: 85345
   Summary: Missing ENDBR in IFUNC resolver
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: igor.v.tsimbalist at intel dot com
Blocks: 81652
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

[hjl@gnu-cet-1 gcc]$ /export/build/gnu/gcc-cet/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-cet/build-x86_64-linux/gcc/
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr81128.c
-fcf-protection -mcet
-B/export/build/gnu/gcc-cet/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/
-B/export/build/gnu/gcc-cet/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxrt
-L/export/build/gnu/gcc-cet/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs
-B/export/build/gnu/gcc-cet/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/
-B/export/build/gnu/gcc-cet/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxwrap
-L/export/build/gnu/gcc-cet/build-x86_64-linux/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs
-fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -g
[hjl@gnu-cet-1 gcc]$ gdb a.out 
GNU gdb (GDB) Fedora 8.1-11.fc28
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...done.
(gdb) r
Starting program:
/export/build/gnu/gcc-cet/build-x86_64-linux/gcc/testsuite/gcc/a.out 
Missing separate debuginfos, use: dnf debuginfo-install
glibc-2.27-8.4.fc28.x86_64

Program received signal SIGSEGV, Segmentation fault.
resolve_do_it_right_at_runtime ()
at
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr81128.c:33
33srand (time (NULL));
(gdb) bt
#0  resolve_do_it_right_at_runtime ()
at
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr81128.c:33
#1  0x77ea01c8 in _dl_relocate_object ()
   from /lib64/ld-linux-x86-64.so.2
#2  0x77e9848f in dl_main () from /lib64/ld-linux-x86-64.so.2
#3  0x77eada2f in _dl_sysdep_start () from /lib64/ld-linux-x86-64.so.2
#4  0x77e961b8 in _dl_start () from /lib64/ld-linux-x86-64.so.2
#5  0x77e95108 in _start () from /lib64/ld-linux-x86-64.so.2
#6  0x0001 in ?? ()
#7  0x7fffda3c in ?? ()
#8  0x in ?? ()
(gdb) disass
Dump of assembler code for function resolve_do_it_right_at_runtime:
=> 0x00401220 <+0>: sub$0x8,%rsp   <<< Missing ENDBR
   0x00401224 <+4>: xor%edi,%edi
   0x00401226 <+6>: callq  0x4010a0 
   0x0040122b <+11>:mov%eax,%edi
   0x0040122d <+13>:callq  0x401090 
   0x00401232 <+18>:callq  0x4010b0 
   0x00401237 <+23>:addl   $0x1,0x2e1a(%rip)# 0x404058

   0x0040123e <+30>:mov$0x401260,%edx
   0x00401243 <+35>:test   $0x1,%al
   0x00401245 <+37>:mov$0x401210,%eax
   0x0040124a <+42>:cmove  %rdx,%rax
   0x0040124e <+46>:add$0x8,%rsp
   0x00401252 <+50>:retq   
End of assembler dump.
(gdb)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full -mcet bugs

[Bug libstdc++/85343] Overload __throw_ios_failure to allow passing errno

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug libstdc++/85343] Overload __throw_ios_failure to allow passing errno

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Created attachment 43909
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43909=edit
Patch to overload __throw_ios_failure

This patch is probably the best we can do. In theory we could capture errno as
soon as an error occurs and stash it somewhere in ios_base for later retrieval,
but that would be an ABI break.

With this patch this program:

#include 
int main()
{
  std::ifstream f(".");
  f.exceptions(std::ios::badbit);
  f.get();
}

Produces the more informative:
basic_filebuf::underflow error reading the file: Is a directory

instead of the generic:
basic_filebuf::underflow error reading the file: iostream error

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

[jason at gcc dot gnu.org]

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

--- Comment #19 from Jason Merrill  ---
(In reply to H.J. Lu from comment #18)
> (In reply to Jason Merrill from comment #16)
> > (In reply to Andreas Schwab from comment #15)
> > > Because the ABI says so.
> > 
> > Which ABI?  In https://www.uclibc.org/docs/psABI-i386.pdf I see
> > 
> > long long: sizeof 8, alignment 4.
> > 
> > That GCC chooses to give stronger alignment to long long variables isn't
> > part of the ABI, and shouldn't affect the value of alignof.
> 
> FYI, x86 psABIs are at
> 
> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

And those also say that double and long long have alignment 4.

[Bug target/85342] [8 Regression] ICE: SIGSEGV in copyprop_hardreg_forward_1 (regcprop.c:995) with -O2 -mavx512vl

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #4 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #3)
> More worrying is that this code compiles without error when it should error
> out:
> 
> void
> foo (void)
> {
>   __asm( "%0" :: "J" ((unsigned char) 0x80));
> }

In which case we end up with #-128 in the assembly which is not what the user
wrote. Thus adding wrong-code tag.

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
More worrying is that this code compiles without error when it should error
out:

void
foo (void)
{
  __asm( "%0" :: "J" ((unsigned char) 0x80));
}

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

[thopre01 at gcc dot gnu.org]

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

--- Comment #2 from Thomas Preud'homme  ---
I have a patch, starting testing.

[Bug middle-end/85344] Constant constraint check sign extends unsigned constant input operands

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-11
 Ever confirmed|0   |1
  Known to fail||6.4.1, 7.3.1, 8.0.1

--- Comment #1 from Thomas Preud'homme  ---
It believe that the problem is in expand_asm_stmt (). The code calls into
expand for the operand which will create a const_int of -128 with the
assumption that an outer RTX will tell how to interpret that constant (eg.
zero_extend:SI (const_int -128)). However the code uses that value directly
calling INTVAL on it. It should instead extend it according to the signedness
of the operand so that INTVAL returns the initial value.

[Bug middle-end/85344] New: Constant constraint check sign extends unsigned constant input operands

[thopre01 at gcc dot gnu.org]

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

Bug ID: 85344
   Summary: Constant constraint check sign extends unsigned
constant  input operands
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: thopre01 at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

Hi,

Compiling the following piece of code with -mthumb -mcpu=cortex-m0 generates an
"impossible constraint in 'asm' error"

void
foo (void)
{
  __asm( "%0" :: "I" ((unsigned char) 0x80));
}

It appears that although the operand is unsigned, it gets sign extended to
perform the constraint check.

[Bug libstdc++/85343] New: Overload __throw_ios_failure to allow passing errno

[redi at gcc dot gnu.org]

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

Bug ID: 85343
   Summary: Overload __throw_ios_failure to allow passing errno
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

The standard says "When throwing ios_base::failure exceptions, implementations
should provide values of ec that identify the specific reason for the failure."

We currently always use an error_code containing io_errc::stream.

We can probably only expect errno to be set for filebuf operations, and in
practice only for failed reads. Failed writes from basic_filebuf::overflow
return -1 which might cause a stream object to set failbit and then throw, but
at that point we're too far away from the write to know if errno can be relied
on or not.

[Bug target/85323] SSE/AVX/AVX512 shift by 0 not optimized away

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
If you mean adding if (__builtin_constant_p (__B) && __B == 0) return __A; and
similar to all the various intrinsics, then that is not the right thing to do,
it will make the headers much larger and even the IL much larger for the common
case where people aren't using 0 constant.
Doing this in in the fold target hooks is easier and more effective.

Note, Matthias has filed a bunch of other PRs for similar issues recently,
perhaps we want some tracker PR for those.
The general rule is that foldings which result in VECTOR_CST or other constants
should probably go into ix86_fold_builtin, and other foldings should go into
ix86_gimple_fold_builtin.