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

[craig.topper at gmail dot com]

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

Bug ID: 85530
   Summary: [X86] _mm512_mullox_epi64 and _mm512_mask_mullox_epi64
not implemented
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: craig.topper at gmail dot com
  Target Milestone: ---

icc has these intrinsics which emulate a v8di multiply using multiple pmuludqs
when avx512f is enabled, but avx512dq is not enabled. If avx512dq is enabled it
uses vpmullq.

I just added support to clang in r330923. Would be good if gcc could implement
it too.

[Bug tree-optimization/85529] New: wrong code at -O2 and -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 85529
   Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

It appears to be a recent regression. 


$ gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20180426 (experimental) [trunk revision 259666] (GCC) 
$ 
$ gcctk -Os small.c; ./a.out
1
$ gcc-7.3.0 -O2 small.c; ./a.out
1
$ 
$ gcctk -O2 small.c
$ ./a.out
0
$ 


--


int printf (const char *, ...);

struct S
{
  int a;
};

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

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

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

[Bug rtl-optimization/85528] New: ICE in code_motion_process_successors, at sel-sched.c:6403

[asolokha at gmx dot com]

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

Bug ID: 85528
   Summary: ICE in code_motion_process_successors, at
sel-sched.c:6403
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*, powerpcspe-*-linux-gnu*

gcc-8.0.0-alpha20180422 snapshot (r259553) w/ r259563 applied still ICEs when
compiling the following snippet w/ -misel -O1 -frename-registers
-fschedule-insns2 -fselective-scheduling2 -ftree-pre -fvar-tracking-assignments
-fno-ssa-phiopt -fno-tree-ccp -fno-tree-dce -fno-tree-fre:

long long int id;
short int am;
int sf;

void
qj (void)
{
  if (id == 0)
return;

  for (;;)
{
  short int kq;

  id *= 2;
  kq = id;
  id = (kq < 3) ? sf : 0;
  if (id == 0)
{
  int bp;

  bp = !!id || !!sf;
  am += bp * (!!id || !!(kq *= 2));
}
  else
sf += id;
}
}

% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180422 -misel -O1
-frename-registers -fschedule-insns2 -fselective-scheduling2 -ftree-pre
-fvar-tracking-assignments -fno-ssa-phiopt -fno-tree-ccp -fno-tree-dce
-fno-tree-fre -w -c sx9cnxly.c 
during RTL pass: sched2
sx9cnxly.c: In function 'qj':
sx9cnxly.c:28:1: internal compiler error: in code_motion_process_successors, at
sel-sched.c:6403
 }
 ^
0xc1180b code_motion_process_successors
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:6400
0xc1180b code_motion_path_driver
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:6622
0xc11269 code_motion_process_successors
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:6356
0xc11269 code_motion_path_driver
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:6622
0xc11ab5 move_op
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:6714
0xc11ab5 move_exprs_to_boundary
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:5237
0xc11ab5 schedule_expr_on_boundary
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:5450
0xc15b28 fill_insns
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:5592
0xc1796e schedule_on_fences
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:7366
0xc1796e sel_sched_region_2
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:7504
0xc189e1 sel_sched_region_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:7546
0xc19fd5 sel_sched_region(int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:7647
0xc1a929 run_selective_scheduling()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:7733
0xbf142d rest_of_handle_sched2
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sched-rgn.c:3732
0xbf142d execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sched-rgn.c:3876

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Wed, Apr 25, 2018 at 11:33:34PM +, dominiq at lps dot ens.fr wrote:
> The code compiles with 6.4.0 and 7.3.0, but not with 6.4.1, 7.3.1,
> 8.0.1 and trunk (9.0).  This is likely r258347 for gcc8, r258367
> for gcc7, and r258368 for gcc6.

Bummer.

Don't know how to fix this one.

Workaround is to move checkFmt() to above its first use
in another function.

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||6.4.0, 7.3.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-04-25
 Ever confirmed|0   |1
Summary|[6.4 regression] calling a  |[6/7/8/9 regression] ICE
   |(pure) function from inside |when calling a (pure)
   |another  pure function may  |function from inside
   |cause segmentation fault|another pure function
   |during compilation  |
  Known to fail||6.4.1, 7.3.1, 8.0.1

--- Comment #2 from Dominique d'Humieres  ---
The code compiles with 6.4.0 and 7.3.0, but not with 6.4.1, 7.3.1, 8.0.1 and
trunk (9.0). This is likely r258347 for gcc8, r258367 for gcc7, and r258368 for
gcc6.

[Bug fortran/85526] [6.4 regression] calling a (pure) function from inside another pure function may cause segmentation fault during compilation

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Reduce test case.

module fox_m_fsys_format

   implicit none

   integer, parameter :: dp=8

   interface leng
  module procedure str_real_dp_fmt_len
   end interface

   contains

  pure function str_real_dp_fmt_len(x, fmt) result(n)
 real(dp), intent(in) :: x
 character(len=10), intent(in) :: fmt
 integer :: n
 if (.not.checkFmt(fmt)) then
n = 0
return
 end if
  end function str_real_dp_fmt_len

  function str_real_dp_fmt(x, fmt) result(s)
 real(dp), intent(in) :: x
 character(len=10), intent(in) :: fmt
 character(len=leng(x, fmt)) :: s
  end function str_real_dp_fmt

  function checkFmt(fmt) result(good)
 character(len=10), intent(in) :: fmt
 logical good
 good = .true.
  end function checkFmt

end module fox_m_fsys_format

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #8 from Jonathan Wakely  ---
Thanks for the details.

[Bug testsuite/85527] New: [openacc] atomic_capture-1.{c,f90} undefined behaviour

[vries at gcc dot gnu.org]

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

Bug ID: 85527
   Summary: [openacc] atomic_capture-1.{c,f90} undefined behaviour
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I.

Consider this test-case, minimized from atomic_capture-1.f90:
...
program main
  real fgot, fexp, ftmp
  integer, parameter :: N = 32

  fgot = 1234.0
  fexp = 1266.0

  !$acc parallel loop copy (fgot, ftmp) 
  do i = 1, N
 !$acc atomic capture   
 ftmp = fgot
 fgot = fgot + 1.0
 !$acc end atomic   
  end do
  !$acc end parallel loop   

  if (ftmp /= fexp - 1.0) call abort
end program main
...

We write different values to the scalar ftmp in a parallel loop.

So, roughtly equivalent to:
...
  !$acc parallel loop copy (fgot, ftmp) 
  do i = 1, N
 ftmp = i
  end do
  !$acc end parallel loop
...

This is undefined behaviour.

If we look in atomic_capture-1.c, the equivalent loop looks like this:
...
#pragma acc data copy (fgot, fdata[0:N])
  {
#pragma acc parallel loop
for (i = 0; i < N; i++)
  {
#pragma acc atomic capture
fdata[i] = fgot++;
  }
  }

  if (fexp != fgot)
abort ();
...

So, the solution here is to write to different entries in an array.


II.

atomic_capture-1.c contains only a single case of checking the contents of
fdata/ldata/idata:
...
  fgot = 1.0;
  fexp = 0.0;

#pragma acc data copy (fgot, fdata[0:N])
  {
#pragma acc parallel loop
for (i = 0; i < N; i++)
  {
float expr = 32.0;

#pragma acc atomic capture
fdata[i] = fgot = expr - fgot;
  }
  }

  for (i = 0; i < N; i++)
if (i % 2 == 0)
  {
if (fdata[i] != 31.0)
  abort ();
  }
else
  {
if (fdata[i] != 1.0)
  abort ();
  }
...

That was already observed to be causing problem here
(https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00173.html ), and was removed in
this patch:
...
commit 39be832ac8fb62836b54b98c118ce713a323bb2e
Author: nathan 
Date:   Fri Jan 22 22:01:33 2016 +

* testsuite/libgomp.oacc-c-c++-common/atomic_capture-1.c: Don't
assume atomic op ordering.
* testsuite/libgomp.oacc-fortran/atomic_capture-1.f90: Likewise.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@232749
138bc75d-0d04-0410-961f-82ee72b054a4
...
but that's still missing on trunk.

That patch also removes some of the ftmp/itmp/ltmp checks in
atomic_capture-1.f90, but not the one mentioned in I.


III.

It may still be a good idea to check the result of fdata/idata/ldata array, but
not in the order-dependent fashion that's used in the example listed at II.

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

[tom at ritter dot vg]

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

--- Comment #7 from Tom Ritter  ---
I'm compiling some AVX code with MinGW+gcc.  I'm afraid it's difficult to
create a test case, but I think there's an alignment issue here.

Registers at crash site:

rbp is 0x00 % 20

> 0:000> r
> rax=15ce306b rbx=00656930 rcx=1f1ba500
> rdx= rsi= rdi=00656440
> rip=072656fa rsp=00656bc0 rbp=00657060
> r8=1fc0f0a0  r9=0018 r10=1fc0f0a0
> r11=1f75bcff r12=00657c90 r13=000f
> r14= r15=
> iopl=0 nv up ei pl nz na po nc
> cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b efl=00010204
> xul!XRE_GetBootstrap+0x256380a:
> `072656fa c5fd7f45f0  vmovdqa ymmword ptr [rbp-10h],ymm0 
> ss:`00657050=17


Disassembly:

vmovdqa expects 0x20 alignment
but offset by 0x10:
`072356fa c5fd7f45f0  vmovdqa ymmword ptr [rbp-10h],ymm0

I've attached the disassembly.


The c++ code is attached and also at:
https://searchfox.org/mozilla-central/rev/36dec78aecc40539ecc8d78e91612e38810f963c/gfx/skia/skia/src/opts/SkOpts_hsw.cpp

There is a function; convolve_16_pixels that corresponds to
xul!XRE_GetBootstrap+0x6676510 in the attached disassembly



It was pointed out that

`07235595 48c1e805shr rax,5
`07235599 48c1e005shl rax,5
`0723559d 4889c3  mov rbx,rax

aligns rbx at the entry to the function, so it can safely do things like
vmovdqa ymmword ptr [rbx+3E0h],ymm0

However rbp does not get the same alignment treatment, and operations offset
from it may not be correctly aligned.

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

[tom at ritter dot vg]

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

--- Comment #6 from Tom Ritter  ---
Created attachment 44020
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44020=edit
Disassembly of affected function

[Bug fortran/85526] New: [6.4 regression] calling a (pure) function from inside another pure function may cause segmentation fault during compilation

[mail at pietrodelugas dot it]

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

Bug ID: 85526
   Summary: [6.4 regression] calling a (pure) function from inside
another  pure function may cause segmentation fault
during compilation
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mail at pietrodelugas dot it
  Target Milestone: ---

Created attachment 44019
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44019=edit
fortran source file to demonstrate the bug

A call to a pure function from inside a pure function crashes the compilation
with this message 

internal compiler error: Segmentation fault

the same code has been compiling regularly with gfortran up to 6.2 while it is
failing in 6.4 and 7.3 versions 

I attach a sample source file

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

[tom at ritter dot vg]

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

--- Comment #5 from Tom Ritter  ---
./x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=./x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/builds/worker/workspace/build/src/mingw32/bin/../libexec/gcc/x86_64-w64-mingw32/6.4.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../gcc-6.4.0/configure
--prefix=/tmp/tmp.G8UuS5o8Pw/tools/mingw32 --target=x86_64-w64-mingw32 --with-
gnu-ld --with-gnu-as --disable-multilib --enable-threads=posix
Thread model: posix
gcc version 6.4.0 (GCC) 



/builds/worker/workspace/build/src/mingw32/bin/x86_64-w64-mingw32-g++ -mwindows
-o SkOpts_hsw.o -c
-I/builds/worker/workspace/build/src/obj-firefox/dist/stl_wrappers -DDEBUG=1
-DSK_JUMPER_USE_ASSEMBLY=0 -DUNICODE -D_UNICODE -DSKIA_IMPLEMENTATION=1
-DSK_PDF_USE_SFNTLY=1 -DSK_CAN_USE_DLOPEN=0 -DSTATIC_EXPORTABLE_JS_API
-DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL
-I/builds/worker/workspace/build/src/gfx/skia
-I/builds/worker/workspace/build/src/obj-firefox/gfx/skia
-I/builds/worker/workspace/build/src/gfx/skia/skia/include/c
-I/builds/worker/workspace/build/src/gfx/skia/skia/include/config
-I/builds/worker/workspace/build/src/gfx/skia/skia/include/core
-I/builds/worker/workspace/build/src/gfx/skia/skia/include/effects
-I/builds/worker/workspace/build/src/gfx/skia/skia/include/gpu
-I/builds/worker/workspace/build/src/gfx/skia/skia/include/pathops
-I/builds/worker/workspace/build/src/gfx/skia/skia/include/ports
-I/builds/worker/workspace/build/src/gfx/skia/skia/include/private
-I/builds/worker/workspace/build/src/gfx/skia/skia/include/utils
-I/builds/worker/workspace/build/src/gfx/skia/skia/include/utils/mac
-I/builds/worker/workspace/build/src/gfx/skia/skia/include/views
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/core
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/gpu
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/effects
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/gl
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/glsl
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/image
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/lazy
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/opts
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/sfnt
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/sksl
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/utils
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/utils/mac
-I/builds/worker/workspace/build/src/gfx/skia/skia/src/utils/win
-I/builds/worker/workspace/build/src/gfx/sfntly/cpp/src
-I/builds/worker/workspace/build/src/obj-firefox/dist/include
-I/builds/worker/workspace/build/src/obj-firefox/dist/include/nspr
-I/builds/worker/workspace/build/src/obj-firefox/dist/include/nss
-DMOZILLA_CLIENT -include
/builds/worker/workspace/build/src/obj-firefox/mozilla-config.h -Wall
-Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith
-Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings
-Wno-invalid-offsetof -Wduplicated-cond -Wno-error=maybe-uninitialized
-Wno-error=deprecated-declarations -Wno-error=array-bounds
-Wno-error=free-nonheap-object -Wno-unknown-pragmas -Wno-unused-function
-Wno-conversion-null -Wno-switch -Wno-enum-compare -fno-sized-deallocation
-fno-exceptions -fno-strict-aliasing -mms-bitfields -fno-keep-inline-dllexport
-fno-rtti -ffunction-sections -fdata-sections -Wa,-mbig-obj -fno-exceptions
-fno-math-errno -pthread -pipe -g -fno-omit-frame-pointer
-Wno-deprecated-declarations -Wno-overloaded-virtual -Wno-shadow
-Wno-sign-compare -Wno-unreachable-code -Wno-unused-function -Wno-logical-op
-Wno-maybe-uninitialized  -MD -MP -MF .deps/SkOpts_hsw.o.pp  -mavx2
/builds/worker/workspace/build/src/gfx/skia/skia/src/opts/SkOpts_hsw.cpp

(There is no compiler output.)

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

[tom at ritter dot vg]

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

--- Comment #4 from Tom Ritter  ---
Created attachment 44018
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44018=edit
Preprocessed source file

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-04-25
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Please read https://gcc.gnu.org/bugs/ and provide the information requested
there, and put the details in this report instead of a link to a pastebin.

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

[tom at ritter dot vg]

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

--- Comment #2 from Tom Ritter  ---
(In reply to Andrew Pinski from comment #1)
> What exact target is this on?

Sorry, this is x64 if that's what you mean?

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
What exact target is this on?

[Bug c/85525] New: Alignment Issue in AVX compiler intrinsics

[tom at ritter dot vg]

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

Bug ID: 85525
   Summary: Alignment Issue in AVX compiler intrinsics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at ritter dot vg
CC: jacek at codeweavers dot com
  Target Milestone: ---

I am using gcc 6.4.0 and MinGW to compile some code that uses AVX intrinsics
for Windows.  Specifically, this code:
https://searchfox.org/mozilla-central/rev/36dec78aecc40539ecc8d78e91612e38810f963c/gfx/skia/skia/src/opts/SkOpts_hsw.cpp

The crashing instruction is:

vmovdqa ymmword ptr [rbp-10h],ymm0 

However at this location, rbp is 0 % 0x20 and vmovdqa expects 0x20 alignment
(and in the assembly offset by 0x10).

We think there is a missing alignment sequence at the beginning the function
(there is one for rbx, but not rbp).

The full disassembly and details are at https://pastebin.mozilla.org/9083932

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #48 from John Paul Adrian Glaubitz  ---
(In reply to Segher Boessenkool from comment #47)
> Believe it or not, but the rs6000 port maintainers *care* about older
> systems.

Then why is something that is still working and being used by people being
deprecated?

> I wanted to obsolete SPE support because it is a big burden, not in small
> part
> because no one maintains it.  This has been going on for years and years.

In what sense? Care to elaborate? I thought the codebase has already been
separated out so it doesn't bother the rest of the code base. As mentioned
above, it would be nice to be pointed to an actual problem the code is causing
right now as-is.

> Big pushback; people still want SPE, they just don't want to spend work on
> it.

So, does every gcc user also have to be a gcc developer? I think the number of
people using gcc is magnitudes larger than the people capable of working on the
gcc codebase. So I think this argument is a bit unfair.

> Well neither do we, it's been enough.  So I spent a week splitting off the
> port
> (also tested removing VSX etc.; removing unused code does not take that long;
> I just have no way to *test* it so that was not included).  It was agreed the
> powerpcspe port would be maintained or it would be removed.

Ignoring that there are people still using it.

> Now a year later GCC 8 is on the horizon, and the powerpcspe port is still
> not
> maintained.  And the RMs decided to give it *another* year: it is not removed
> but merely obsoleted.

Why not leave it in as long as it works and it's being used? Mark it as
unsupported, broken or wontfix, but please don't remove it.

[Bug libstdc++/85472] Regex match bug

[haberg-1 at telia dot com]

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

--- Comment #12 from Hans Åberg  ---
(In reply to Tim Shen from comment #11)
> > The problem is that #4 has an earlier capture, making it impossible to see
> > that it is left undefined later.
> 
> I wouldn't say it's impossible. libc++ implements it correctly at a cost.
>
> Specifically, see
> https://github.com/llvm-mirror/libcxx/blob/
> e54a22f809bc741760e39ac78444f57f06117652/include/regex#L5566. 

I meant the way I do it now.

> > So it would be better to capture it as an
> > empty string here:
> > 
> > In the example I gave, if the transitions are marked (ignoring #2)
> >   1: {a ↦ {1#3, 2#3, 3#3$4}};
> >   2: {b ↦ {2#4, 3#4}};
> >   3: {c ↦ {3#5, 2#5, 1#5, ∅#2}.
> > Then in the "ac" part, 'a' in state 1 goes to 3 and gets a #3 match 'a' plus
> > an empty which I have written $4. That is the idea, though.
> 
> I'm feeling that this is going to a quadratic space complexity here. Does
> "(((...((a_0)|(a_1)|(a_2)|...(a_n))...)))" if the regex expands to n
> surrounding parenthesis, and n characters in the middle? Would this regex
> match taking up to n^2 time, given a n-sized input string?

It is all linear, in one traverse, just pick down the action form the
transitions instead of the states. Both are computed when checking the forward
transition for a character: I just record them.

> If you think it's time and space efficiently doable, maybe you can develop a
> prototype first.

Yes. I will have to think about it, and report back here.

> > I have though not implemented the counted repetitions A{m, n}, which I think
> > usually are implemented as loops, so I do not know how that fits into the
> > picture.
> 
> It might also be helpful to think about back-references like "(a+)\1".

What's this?

[Bug libstdc++/85472] Regex match bug

[timshen at gcc dot gnu.org]

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

--- Comment #11 from Tim Shen  ---
> The problem is that #4 has an earlier capture, making it impossible to see
> that it is left undefined later.

I wouldn't say it's impossible. libc++ implements it correctly at a cost.

Specifically, see
https://github.com/llvm-mirror/libcxx/blob/e54a22f809bc741760e39ac78444f57f06117652/include/regex#L5566.

> So it would be better to capture it as an
> empty string here:
> 
> In the example I gave, if the transitions are marked (ignoring #2)
>   1: {a ↦ {1#3, 2#3, 3#3$4}};
>   2: {b ↦ {2#4, 3#4}};
>   3: {c ↦ {3#5, 2#5, 1#5, ∅#2}.
> Then in the "ac" part, 'a' in state 1 goes to 3 and gets a #3 match 'a' plus
> an empty which I have written $4. That is the idea, though.

I'm feeling that this is going to a quadratic space complexity here. Does
"(((...((a_0)|(a_1)|(a_2)|...(a_n))...)))" if the regex expands to n
surrounding parenthesis, and n characters in the middle? Would this regex match
taking up to n^2 time, given a n-sized input string?

If you think it's time and space efficiently doable, maybe you can develop a
prototype first.

> I have though not implemented the counted repetitions A{m, n}, which I think
> usually are implemented as loops, so I do not know how that fits into the
> picture.

It might also be helpful to think about back-references like "(a+)\1".

[Bug libstdc++/85472] Regex match bug

[haberg-1 at telia dot com]

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

--- Comment #10 from Hans Åberg  ---
(In reply to Tim Shen from comment #9)
> Ah with the example it's clear, thanks!

You are welcome.

> > The last line gives for #1 the sub-string "z" , and for #2 "aacbbbcac".
> 
> This is not what ECMAScript produces either. for capture #2, ECMAScriptn
> produces "ac", the last match of the loop.
> 
> Think about the difference between
> 
>   (z)((a+)?(b+)?(c))*
> 
> and
> 
>   (z)((?:(a+)?(b+)?(c))*)
> 
> Your #2 seems to capture the second case, which is different.

Yes, I thought about this difference in an earlier version that marked the
start and last states only, but switched to this, because I wanted to ignore
empty matches:

I think though that one might mark the transitions with action numbers and
capture it that way (see below).

> > For
> > #3 "a", and for #5 "c". But #4 is missing, indication there is no match. So
> > there might be problem here, as there are earlier matches:
> > 
> > Perhaps the intent is that it should be implemented as a loop, only
> > retaining the last #4, 
> 
> That's what the implementations (boost, libstdc++, python) actually do.
> That's not ECMAScript's intention. ECMAScript's intention is to leave #4
> undefined (*not* retaining the last non-empty #4), as in the last iteration
> of the loop, #4 (b+)? doesn't match any sub-string.

The problem is that #4 has an earlier capture, making it impossible to see that
it is left undefined later. So it would be better to capture it as an empty
string here:

In the example I gave, if the transitions are marked (ignoring #2)
  1: {a ↦ {1#3, 2#3, 3#3$4}};
  2: {b ↦ {2#4, 3#4}};
  3: {c ↦ {3#5, 2#5, 1#5, ∅#2}.
Then in the "ac" part, 'a' in state 1 goes to 3 and gets a #3 match 'a' plus an
empty which I have written $4. That is the idea, though.

> > but the problem is that that is not what the
> > underlying theory says.
> 
> I'm not sure if there is any theory around caputring groups. If we are about
> to create one, be aware that there are multiple plausible definitions.

I have though not implemented the counted repetitions A{m, n}, which I think
usually are implemented as loops, so I do not know how that fits into the
picture.

[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Note to self: this came out of this ML thread:
  https://gcc.gnu.org/ml/gcc/2018-04/msg00168.html

[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Note to self: test coverage should also verify += and so on.

[Bug middle-end/85524] Strange cbrt() result on linux in C

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |middle-end
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
This is 1ulp difference.  This is a standard issue with floating point; please
read "what every computer scientist should know about floating-point
arithmetic".  The first case is the result from libm (which in Linux case comes
from glibc project) and in the second case, GCC constants folds the cbrt and
gets an exact result.

[Bug c/85524] New: Strange cbrt() result on linux in C

[toto852 at courriel dot fr.nf]

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

Bug ID: 85524
   Summary: Strange cbrt() result on linux in C
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: toto852 at courriel dot fr.nf
  Target Milestone: ---

This behavior strange. It meets on different version of gcc linux.

#include 
#include 
#include 

int main() {
double nb = 56623104;
double v1 = cbrt(nb);
printf("v1 -> %.15f\n",v1);

double v2 = cbrt((double) 56623104);
printf("v2 -> %.15f\n",v2);
}


Compilation :

gcc test.c -o test -lm && ./test

Result :

v1 -> 384.057
v2 -> 384.000

[Bug target/85473] internal compiler error: in emit_move_insn, at expr.c:3722

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed for GCC 8.

[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-25
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
With that patch -fdiagnostics-generate-patch produces:

ret.cc: In member function 'X& X::operator=(const X&)':
ret.cc:2:28: warning: no return statement in function returning non-void
[-Wreturn-type]
   X& operator=(const X&) { } // show fix-it
^
ret.cc:2:28: note: assignment operators usually return *this
   X& operator=(const X&) { } // show fix-it
^
return *this;
ret.cc: In member function 'int Y::operator=(int)':
ret.cc:7:24: warning: no return statement in function returning non-void
[-Wreturn-type]
   int operator=(int) { } // no fix-it here, just a -Wreturn-type warning
^
ret.cc: In member function 'Z& Z::operator=(const Z&)':
ret.cc:13:3: warning: no return statement in function returning non-void
[-Wreturn-type]
   } // show fix-it
   ^
ret.cc:13:3: note: assignment operators usually return *this
   } // show fix-it
   ^
   return *this;
--- ret.cc
+++ ret.cc
@@ -1,5 +1,5 @@
 struct X {
-  X& operator=(const X&) { } // show fix-it
+  X& operator=(const X&) { return *this;} // show fix-it
 };

 struct Y {
@@ -10,7 +10,7 @@
 struct Z {
   Z& operator=(const Z& z) {
 i = z.i;
-  } // show fix-it
+  return *this;} // show fix-it

   int i;
 };


On IRC Dave said:

to do it right, should handle both single-line and multiline methods
and indent to match that of nearby code; see that
add_newline_fixit_with_indentation from
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00334.html
probably a trailing space for the single-line case

[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Created attachment 44017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44017=edit
Proof-of-concept patch to add fix-it

[Bug c++/85523] New: Add fix-it hint for missing return statement in assignment operators

[redi at gcc dot gnu.org]

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

Bug ID: 85523
   Summary: Add fix-it hint for missing return statement in
assignment operators
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

As discussed at https://gcc.gnu.org/ml/gcc/2018-04/msg00170.html we could offer
fix-it hints for cases like:

struct X {
  X& operator=(const X&) { } // show fix-it
};

struct Y {
  void operator=(const Y&) { }
  int operator=(int) { } // no fix-it here, just a -Wreturn-type warning
};

struct Z {
  Z& operator=(const Z& z) {
i = z.i;
  } // show fix-it

  int i;
};

[Bug libstdc++/85472] Regex match bug

[timshen at gcc dot gnu.org]

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

--- Comment #9 from Tim Shen  ---
Ah with the example it's clear, thanks!

> The last line gives for #1 the sub-string "z" , and for #2 "aacbbbcac".

This is not what ECMAScript produces either. for capture #2, ECMAScriptn
produces "ac", the last match of the loop.

Think about the difference between

  (z)((a+)?(b+)?(c))*

and

  (z)((?:(a+)?(b+)?(c))*)

Your #2 seems to capture the second case, which is different.

> For
> #3 "a", and for #5 "c". But #4 is missing, indication there is no match. So
> there might be problem here, as there are earlier matches:
> 
> Perhaps the intent is that it should be implemented as a loop, only
> retaining the last #4, 

That's what the implementations (boost, libstdc++, python) actually do. That's
not ECMAScript's intention. ECMAScript's intention is to leave #4 undefined
(*not* retaining the last non-empty #4), as in the last iteration of the loop,
#4 (b+)? doesn't match any sub-string.

> but the problem is that that is not what the
> underlying theory says.

I'm not sure if there is any theory around caputring groups. If we are about to
create one, be aware that there are multiple plausible definitions.

[Bug target/85473] internal compiler error: in emit_move_insn, at expr.c:3722

[hjl at gcc dot gnu.org]

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

--- Comment #5 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Wed Apr 25 17:31:20 2018
New Revision: 259654

URL: https://gcc.gnu.org/viewcvs?rev=259654=gcc=rev
Log:
x86: Correct movdir64b builtin function

gcc/ChangeLog:

Backport from mainline
2018-04-25  Sebastian Peryt  

PR target/85473
* config/i386/i386.c (ix86_expand_builtin): Change memory
operand to XI, extend p0 to Pmode.
* config/i386/i386.md: Change unspec volatile and operand
1 mode to XI, change operand 0 mode to P.

gcc/testsuite/ChangeLog:

Backport from mainline
2018-04-25  Sebastian Peryt  

PR target/85473
* gcc.target/i386/pr85473-1.c: New test.
* gcc.target/i386/pr85473-2.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr85473-1.c
branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr85473-2.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/i386/i386.c
branches/gcc-8-branch/gcc/config/i386/i386.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/85517] std::variant exception safety problems

[metaprogrammingtheworld at gmail dot com]

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

Matt Calabrese  changed:

   What|Removed |Added

 CC||metaprogrammingtheworld@gma
   ||il.com

--- Comment #2 from Matt Calabrese  
---
Example copy-assign non-compliance:

//

#include 

struct bar
{
  bar() noexcept = default; 
  bar(bar&&) { /*never throws, but not noexcept*/ }
  bar(bar const&)  // A copy constructor that throws.
  {
throw 0;
  }

  bar& operator=(bar&&) noexcept = default;
  bar& operator=(bar const&) noexcept = default;
};

int main()
{
  std::variant v1, v2 = bar();

  try
  {
v1 = v2;
  }
  catch( int )
  {
return 0;
  }

  return 1;
}

[Bug libstdc++/85517] std::variant exception safety problems

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-25
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
Mine.

[Bug target/85434] Address of stack protector guard spilled to stack on ARM

[thopre01 at gcc dot gnu.org]

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

--- Comment #9 from Thomas Preud'homme  ---
Managed to reach a state where nothing is spilled on the stack for Thumb-1
either. I want to do 3 more changes before I start full testing:
- put some compiler barrier between address computation and canari setting /
canari check to ensure no instruction is scheduled between the two
- clarify in documentation that it's the target's responsability to ensure
guard's address computation is not CSE (in particular for PIC access)
- tighten scan pattern for testcase a bit more

[Bug tree-optimization/85509] fails to promote local static to const

[aaron_sami_abassi at hotmail dot com]

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

--- Comment #5 from ASA  ---
> > I would expect this is likely true for any non-const static duration
> > function pointer, not just the case when the auto type specifier is used,
> > but I have not confirmed it.
> 
> But it is the case for any non-const static duration function pointer.
> This has nothing to do with 'auto', changing the testcase to
> 
> static inline bool
> RunTest( void ) {
> static bool (*PerformQuickly)(int &, const int &) = Perform< SumQuickly
> >;
> static bool (*PerformSafely)(int &, const int &) = Perform< SumSafely >;
> int i = 0;
> return PerformQuickly( i, 1 ) && !PerformSafely( i, INT_MAX );
> }
> 
> has no effect.

Which is exactly what I stated I would have expected.  Thank you for the
confirmation of that expectation, though very oddly worded.

[Bug target/85401] segfault building code for VAX

[martin at netbsd dot org]

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

--- Comment #4 from Martin Husemann  ---
The costs are missing for various modes:

(gdb) p (default_target_ira_int->x_ira_register_move_cost)
$6 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x7f7ff7b8c8b0, 0x7f7ff7b8c8b0, 0x0 }

(that is: only HImode and SImode costs are available)

[Bug target/85401] segfault building code for VAX

[martin at netbsd dot org]

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

--- Comment #3 from Martin Husemann  ---
Indeed. Digging a bit with gdb (but in our local 6.4 version) shows:

#0  0x009fa7be in allocno_copy_cost_saving (allocno=0x7f7ff679a178,
hard_regno=11)
at /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/ira-color.c:2763
2763  cost += cp->freq *
ira_register_move_cost[allocno_mode][rclass][rclass];
(gdb) p (default_target_ira_int->x_ira_register_move_cost)[allocno_mode]
$5 = (move_table *) 0x0


Where is that table supposed to be setup?

[Bug rtl-optimization/85522] ICE: in model_update_limit_points_in_group, at haifa-sched.c:1985 with -O2 -ftracer --param=max-sched-extend-regions-iters=5

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.

[Bug middle-end/51677] don't suggest giving main() __attribute__((const))

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Martin Sebor from comment #3)
> It should be easy to white-list the main function in the
> -Wsuggest-attribute= checker.  At the same time, I'm not sure it's necessary
> or that the problem is unique to main.  The reasons noted in comment #0
> apply to other functions as well.  Defining empty functions is useful for a
> variety of reasons (e.g., default no-op handlers or, in C++, default no-op
> implementations of virtual functions).  Similarly, without perfect data flow
> analysis across the whole program it's impossible to tell whether an extern
> function is ever called.  Why should main be treated differently from those?

Because it's an easy first step that doesn't require doing all of those extra
data flow analyses

[Bug other/63613] dejagnu.h needs to be fix included

[egallager at gcc dot gnu.org]

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

--- Comment #12 from Eric Gallager  ---
(In reply to David Malcolm from comment #11)
> Patch posted as https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00468.html

Does this still apply?

[Bug c/49702] Undefined static functions resolve to external definitions

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=19315

--- Comment #3 from Eric Gallager  ---
Possibly related: bug 19315? (both cases of statics becoming externs; that for
variables, this for functions)

[Bug middle-end/85414] [8 Regression] ICE: in ix86_expand_prologue, at config/i386/i386.c:13810 with -Og -fgcse

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 25 13:10:01 2018
New Revision: 259649

URL: https://gcc.gnu.org/viewcvs?rev=259649=gcc=rev
Log:
PR middle-end/85414
* simplify-rtx.c (simplify_unary_operation_1) : Pass SUBREG_REG (op) rather than op to
gen_lowpart_no_emit.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/simplify-rtx.c

[Bug target/85401] segfault building code for VAX

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|ASSIGNED|UNCONFIRMED
 CC||m...@3am-software.com
   Assignee|thopre01 at gcc dot gnu.org|unassigned at gcc dot 
gnu.org
 Ever confirmed|1   |0

--- Comment #2 from Thomas Preud'homme  ---
Actually given where the fault occurs this does not seem to be related to
bswap. Might be a missing pattern or cost in the vax backend.

[Bug c/36941] gcc does not reject invalid cast

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||accepts-invalid, diagnostic
 CC||joseph at codesourcery dot com

--- Comment #8 from Eric Gallager  ---
(In reply to Eric Gallager from comment #7)
> (In reply to Chris Lattner from comment #0)
> > GCC accepts:
> > extern struct S x;
> > void foo() { (void)x; }
> > 
> > But correctly rejects:
> > 
> > extern struct S x;
> > void foo() { x; }
> > 
> 
> Confirmed. Note that clang diagnoses the first one like this:
> 
> $ /sw/opt/llvm-3.1/bin/clang-3.1 -c 36941.c
> 36941.c:2:20: error: incomplete type 'struct S' where a complete type is
> required
> void foo() { (void)x; }
>^
> 36941.c:1:15: note: forward declaration of 'struct S'
> extern struct S x;
>   ^

Same thing with a newer version of clang (5.0). Assuming that since clang still
rejects this that this is an accepts-invalid for gcc.

[Bug libstdc++/85472] Regex match bug

[haberg-1 at telia dot com]

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

--- Comment #8 from Hans Åberg  ---
(In reply to Tim Shen from comment #5)
> I'm not following the meaning of "action number" and "the partial reverse
> NFA is recorded".
> 
> How many actions numbers are recorded? for regex_match(s, regex(re)), is it
> on the order of O(s.size()), or O(re.size())? The goal is to allocate
> O(re.size()) of memory exactly once.

Let's check the OP example, to see if it is useful, which will also explain the
action numbers. So for regex '(z)((a+)?(b+)?(c))*', I used '(z)(a*b*(c))*' with
action numbers same as in the C++ library numbering. Here they are written out
with # in the NFA:
  ex = ({0}, {0, 3},
{0: {z ↦ {1, ∅}}[#1];1: {a ↦ {1, 2, 3}}[#2#3];
 2: {b ↦ {2, 3}}[#2#4];  3: {c ↦ {3, 2, 1, ∅}}[#2#5]}, {})
with start set {0}, and set of last (pointing to a final state ∅) states {0,
3}. (The last {} is the not yet computed DFA.)

Then lexing:

> zaacbbbcac
Full string is a valid match!
Matches: {zaacbbbcac, [@0@3@7@9]; 
[#1]
[#1][#2#3][#2#3][#2#5]
[#1][#2#3][#2#3][#2#5][#2#4][#2#4][#2#4][#2#5]
[#1][#2#3][#2#3][#2#5][#2#4][#2#4][#2#4][#2#5][#2#3][#2#5]
}
Time: 0.000555 s.

Each line gives the action numbers for the string positions for the successive
strings z, zaac, zaacbbbc, zaacbbbcac with final string positions @0, @3, @7,
@9.

The last line gives for #1 the sub-string "z" , and for #2 "aacbbbcac". For #3
"a", and for #5 "c". But #4 is missing, indication there is no match. So there
might be problem here, as there are earlier matches:

Perhaps the intent is that it should be implemented as a loop, only retaining
the last #4, but the problem is that that is not what the underlying theory
says.

[Bug c/37200] duplicate warning message with braced initializer list

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> Confirmed that gcc still prints 2 warnings for the testcase. It's necessary
> to set the standard manually to c89 or gnu89 now that GCC defaults to
> -std=gnu11. Now that GCC has carets for its diagnostics, we can see that the
> 2 warnings actually point to different places:
> 
> $ /usr/local/bin/gcc -c -std=gnu89 -pedantic 37200.c
> 37200.c: In function ‘foo’:
> 37200.c:10:11: warning: initializer element is not computable at load time
> [-Wpedantic]
>{   (void**) >tst }
>^
> 37200.c:10:3: warning: initializer element is not computable at load time
> [-Wpedantic]
>{   (void**) >tst }
>^
> 
> So are they still actually duplicates?

WAITING on a response to this.

[Bug target/85473] internal compiler error: in emit_move_insn, at expr.c:3722

[speryt at gcc dot gnu.org]

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

--- Comment #4 from speryt at gcc dot gnu.org ---
Author: speryt
Date: Wed Apr 25 12:39:57 2018
New Revision: 259648

URL: https://gcc.gnu.org/viewcvs?rev=259648=gcc=rev
Log:
2018-04-25  Sebastian Peryt  

gcc/ChangeLog:

PR target/85473
* config/i386/i386.c (ix86_expand_builtin): Change memory
operand to XI, extend p0 to Pmode.
* config/i386/i386.md: Change unspec volatile and operand
1 mode to XI, change operand 0 mode to P.

gcc/testsuite/ChangeLog:

PR target/85473
* gcc.target/i386/pr85473-1.c: New test.
* gcc.target/i386/pr85473-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr85473-1.c
trunk/gcc/testsuite/gcc.target/i386/pr85473-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug target/85401] segfault building code for VAX

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-04-25
 Ever confirmed|0   |1

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

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||openacc, openmp, patch
   Severity|normal  |trivial

--- Comment #2 from Tom de Vries  ---
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01122.html

[Bug target/84923] [8/9 regression] gcc.dg/attr-weakref-1.c failed on aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So in spirit of the comment#2 patch I'd propose

Index: gcc/varasm.c
===
--- gcc/varasm.c(revision 259638)
+++ gcc/varasm.c(working copy)
@@ -5641,7 +5641,8 @@ weak_finish (void)
   tree alias_decl = TREE_PURPOSE (t);
   tree target = ultimate_transparent_alias_target (_VALUE (t));

-  if (! TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (alias_decl)))
+  if (! TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (alias_decl))
+ || TREE_SYMBOL_REFERENCED (target))
/* Remove alias_decl from the weak list, but leave entries for
   the target alone.  */
target = NULL_TREE;

given do_assemble_alias skips the weak_finish part if TREE_SYMBOL_REFERENCED
(target) and thus will not end up removing target from the alias list.
The above makes both paths match.

[Bug libstdc++/85472] Regex match bug

[haberg-1 at telia dot com]

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

--- Comment #7 from Hans Åberg  ---
(In reply to Tim Shen from comment #5)
> (In reply to Hans Åberg from comment #4)
> > I wrote an NFA/DFA that computes all matches, it seems, in an efficient
> > manner: Action numbers are marked on the states of the sub-NFAs one is
> > interested in. While lexing a string, the partial reverse NFA is recorded,
> > which is searched when a final state is encountered. The string position
> > action numbers, as marked on the corresponding states, are recorded, and for
> > each action number, the contiguous string sequences are the possible
> > submatches.
> 
> I'm not following the meaning of "action number"...

Arbitrary numbers used identify the sub-automatons; in the C++ library, the
number of left parentheses in the regex expression from which it derives. 

> ...and "the partial reverse
> NFA is recorded".

The lexing states are sets of NFA states, which are also the DFA states. If a
lexing character c in the state p = {p_0, ...} has transition p_i -> {q_0,
...}, the reverse state q_0 -> {r_0, ...} gets p_i added at this position in
the string. This is to record the states which c actually uses.

> How many actions numbers are recorded?

They are sets, both in the states and the string matches. Each final state
position in the string produces a separate match, containing information about
the submatches via the action numbers.

> for regex_match(s, regex(re)), is it
> on the order of O(s.size()), or O(re.size())? The goal is to allocate
> O(re.size()) of memory exactly once.

The action numbers are just stamped onto the NFA states when it is created, and
then carried along. So it is the same as the number of states in the NFA. When
a string is lexed, one just gets the action numbers for each position that
produced a character match.

[Bug libstdc++/85472] Regex match bug

[haberg-1 at telia dot com]

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

--- Comment #6 from Hans Åberg  ---
(In reply to Tim Shen from comment #5)
> (In reply to Hans Åberg from comment #4)
> > I wrote an NFA/DFA that computes all matches, it seems, in an efficient
> > manner: Action numbers are marked on the states of the sub-NFAs one is
> > interested in. While lexing a string, the partial reverse NFA is recorded,
> > which is searched when a final state is encountered. The string position
> > action numbers, as marked on the corresponding states, are recorded, and for
> > each action number, the contiguous string sequences are the possible
> > submatches.
> 
> I'm not following the meaning of "action number"...

Arbitrary numbers used identify the sub-automatons; in the C++ library, the
number of left parentheses in the regex expression from which it derives. 

> ...and "the partial reverse
> NFA is recorded".

The lexing states are sets of NFA states, which are also the DFA states. If a
lexing character c in the state p = {p_0, ...} has transition p_i -> {q_0,
...}, the reverse state q_0 -> {r_0, ...} gets p_i added at this position in
the string. This is to record the states which c actually uses.

> How many actions numbers are recorded?

They are sets, both in the states and the string matches. Each final state
position in the string produces a separate match, containing information about
the submatches via the action numbers.

> for regex_match(s, regex(re)), is it
> on the order of O(s.size()), or O(re.size())? The goal is to allocate
> O(re.size()) of memory exactly once.

The action numbers are just stamped onto the NFA states when it is created, and
then carried along. So it is the same as the number of states in the NFA. When
a string is lexed, one just gets the action numbers for each position that
produced a character match.

[Bug rtl-optimization/85522] New: ICE: in model_update_limit_points_in_group, at haifa-sched.c:1985 with -O2 -ftracer --param=max-sched-extend-regions-iters=5

[zsojka at seznam dot cz]

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

Bug ID: 85522
   Summary: ICE: in model_update_limit_points_in_group, at
haifa-sched.c:1985 with -O2 -ftracer
--param=max-sched-extend-regions-iters=5
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-unknown-linux-gnu

Created attachment 44016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44016=edit
reduced testcase

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O2 -ftracer
--param=max-sched-extend-regions-iters=5 testcase.c
during RTL pass: sched1
testcase.c: In function 'foo':
testcase.c:11:1: internal compiler error: in
model_update_limit_points_in_group, at haifa-sched.c:1985
 }
 ^
0x149b095 model_update_limit_points_in_group
/repo/gcc-trunk/gcc/haifa-sched.c:1985
0x149b095 model_update_limit_points
/repo/gcc-trunk/gcc/haifa-sched.c:1996
0x149b095 schedule_insn
/repo/gcc-trunk/gcc/haifa-sched.c:4080
0x149d64c schedule_block(basic_block_def**, void*)
/repo/gcc-trunk/gcc/haifa-sched.c:6871
0xc25e5a schedule_region
/repo/gcc-trunk/gcc/sched-rgn.c:3177
0xc25e5a schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.c:3516
0xc26283 schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.c:3501
0xc26283 rest_of_handle_sched
/repo/gcc-trunk/gcc/sched-rgn.c:3720
0xc26283 execute
/repo/gcc-trunk/gcc/sched-rgn.c:3828
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-259628-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/8.0.1/lto-wrapper
Target: aarch64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-259628-checking-yes-rtl-df-extra-aarch64
Thread model: posix
gcc version 8.0.1 20180425 (experimental) (GCC)

[Bug target/84923] [8/9 regression] gcc.dg/attr-weakref-1.c failed on aarch64

[ramana at gcc dot gnu.org]

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

--- Comment #4 from Ramana Radhakrishnan  ---
(In reply to Richard Biener from comment #3)
> For x86_64 if I append
> 
> const int *dat[] = { ,  };
> 
> the testcase links fine irrespective of where I place the
> 
> .weakrefWv12,wv12
> .weak   wv12
> 
> assembler declarations.
> 
> When I look at the assembler generated by a cross from x86_64 I do not
> see any .weak wv12 directive which is likely the issue.

Yep, the .weak wv12 directive is the one that disappears. Putting that back in
by hand fixes the issue.

[Bug target/84923] [8/9 regression] gcc.dg/attr-weakref-1.c failed on aarch64

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
For x86_64 if I append

const int *dat[] = { ,  };

the testcase links fine irrespective of where I place the

.weakrefWv12,wv12
.weak   wv12

assembler declarations.

When I look at the assembler generated by a cross from x86_64 I do not
see any .weak wv12 directive which is likely the issue.

[Bug sanitizer/84307] asan blocks dead-store elimination

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 25 10:02:24 2018
New Revision: 259641

URL: https://gcc.gnu.org/viewcvs?rev=259641=gcc=rev
Log:
PR sanitizer/84307
* c-decl.c (build_compound_literal): Call pushdecl (decl) even when
it is not TREE_STATIC.
* c-typeck.c (c_mark_addressable) : Mark
not just the COMPOUND_LITERAL_EXPR node itself addressable, but also
its COMPOUND_LITERAL_EXPR_DECL.

Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/c/c-typeck.c

[Bug ada/85007] -b flag to gnatlink not recognized

[ebotcazou at gcc dot gnu.org]

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

--- Comment #17 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Apr 25 10:01:55 2018
New Revision: 259640

URL: https://gcc.gnu.org/viewcvs?rev=259640=gcc=rev
Log:
PR ada/85007
* gnat_ugn.texi: Regenerate.

Modified:
branches/gcc-8-branch/gcc/ada/ChangeLog
branches/gcc-8-branch/gcc/ada/gnat_ugn.texi

[Bug ada/85007] -b flag to gnatlink not recognized

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Apr 25 10:01:13 2018
New Revision: 259639

URL: https://gcc.gnu.org/viewcvs?rev=259639=gcc=rev
Log:
PR ada/85007
* gnat_ugn.texi: Regenerate.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gnat_ugn.texi

[Bug target/84923] [8/9 regression] gcc.dg/attr-weakref-1.c failed on aarch64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |target
  Known to work||7.3.1
   Target Milestone|--- |8.0
Summary|[8 regression]  |[8/9 regression]
   |gcc.dg/attr-weakref-1.c |gcc.dg/attr-weakref-1.c
   |failed on aarch64   |failed on aarch64

[Bug target/68256] Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64.

[ramana at gcc dot gnu.org]

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

--- Comment #12 from Ramana Radhakrishnan  ---
(In reply to Steve Ellcey from comment #11)
> FYI: This caused a regression on aarch64.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84923


I have marked 84923 as an 8 regression as it wasn't done earlier and probably
slipped in the cracks. 

The regression was noticed and a patch was posted but it appears that this
wasn't reviewed.

Ramana

[Bug libstdc++/85472] Regex match bug

[timshen at gcc dot gnu.org]

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

--- Comment #5 from Tim Shen  ---
(In reply to Hans Åberg from comment #4)
> (In reply to Tim Shen from comment #1)
> > I know exactly how libc++ produces this result. It creates an empty
> > match_result during each repetition ("*" operator). It's less confusing but
> > much slower.
> 
> I wrote an NFA/DFA that computes all matches, it seems, in an efficient
> manner: Action numbers are marked on the states of the sub-NFAs one is
> interested in. While lexing a string, the partial reverse NFA is recorded,
> which is searched when a final state is encountered. The string position
> action numbers, as marked on the corresponding states, are recorded, and for
> each action number, the contiguous string sequences are the possible
> submatches.

I'm not following the meaning of "action number" and "the partial reverse NFA
is recorded".

How many actions numbers are recorded? for regex_match(s, regex(re)), is it on
the order of O(s.size()), or O(re.size())? The goal is to allocate O(re.size())
of memory exactly once.

[Bug libstdc++/85472] Regex match bug

[haberg-1 at telia dot com]

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

--- Comment #4 from Hans Åberg  ---
(In reply to Tim Shen from comment #1)
> I know exactly how libc++ produces this result. It creates an empty
> match_result during each repetition ("*" operator). It's less confusing but
> much slower.

I wrote an NFA/DFA that computes all matches, it seems, in an efficient manner:
Action numbers are marked on the states of the sub-NFAs one is interested in.
While lexing a string, the partial reverse NFA is recorded, which is searched
when a final state is encountered. The string position action numbers, as
marked on the corresponding states, are recorded, and for each action number,
the contiguous string sequences are the possible submatches.

[Bug libstdc++/85472] Regex match bug

[timshen at gcc dot gnu.org]

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

--- Comment #3 from Tim Shen  ---
Conclusively, yes it is a bug, but it is hard to fix without regressing normal
case performance.

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

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> All these solutions work until the next failure shows up. It would be nice
> to fix this more definitely in some way, but I'm not sure how.

We could try to figure out the frame size of the recursive function.

Using GOMP_DEBUG=1 we see the JIT compile/link log:
...
Link log warning : Stack size for entry function 'main$_omp_fn$0' cannot be
statically determined
info: 0 bytes gmem
info: Function properties for 'main$_omp_fn$0':
info: used 8 registers, 0 stack, 0 bytes smem, 328 bytes cmem[0], 0 bytes
lmem 
...
but the stack size is only shown for the offloading region, not for individual
functions.

Using GOMP_NVPTX_SAVE_TEMPS=1 we could get the cubin, and dump the resource
usage:
...
$ cuobjdump -res-usage gomp-nvptx.*.cubin  

Resource usage:
 Common:
  GLOBAL:0
 Function rec:
  REG:8 STACK:0 SHARED:0 LOCAL:0 TEXTURE:0 SURFACE:0 SAMPLER:0
 Function main$_omp_fn$0:
  REG:8 STACK:UNKNOWN SHARED:0 LOCAL:0 CONSTANT[0]:328 TEXTURE:0 SURFACE:0
SAMPLER:0
...
but the STACK entry for rec shows up as 0.

Finally, using nvdisasm (or GOMP_NVPTX_DISASM=1) we find the info:
...
$ nvdisasm gomp-nvptx.*.cubin
//- nvinfo : EIATTR_FRAME_SIZE
.align  4
/**/.byte   0x04, 0x11
/*0002*/.short  (.L_6 - .L_5)
.align  4
.L_5:
/*0004*/.word   index@(rec)
/*0008*/.word   0x0010 


//- nvinfo : EIATTR_FRAME_SIZE
.align  4
.L_6:
/*000c*/.byte   0x04, 0x11
/*000e*/.short  (.L_8 - .L_7)
.align  4
.L_7:
/*0010*/.word   index@(main$_omp_fn$0)
/*0014*/.word   0x


//- nvinfo : EIATTR_MIN_STACK_SIZE
.align  4
.L_8:
/*0018*/.byte   0x04, 0x12
/*001a*/.short  (.L_10 - .L_9)
.align  4
.L_9:
/*001c*/.word   index@(main$_omp_fn$0)
/*0020*/.word   0x
.L_10:
...


So, we could write some tcl function to get the frame size for a function, and
xfail or skip the test if the frame size is bigger that given constant x, but
AFAIK dejagnu is not setup for this. The best we could do is to add a dg-final
check and emit a:
...
PASS: rec.c dg-nvptx-frame-size-check main$_omp_fn$0 0
FAIL: rec.c dg-nvptx-frame-size-check rec 8
...


Or, going for a more precise check:
...
FAIL: rec.c dg-nvptx-stack-size-check main$_omp_fn$0,rec=65 (peak stack size
1048 is larger than stack size limit 1024)
...
where you then check that frame-size (main$_omp_fn$0) + 65 * frame-size (rec) <
udaThreadGetLimit(, cudaLimitStackSize)).

Presumably formulating the peak stack composition gets more involved with
openmp test cases which have a more complicated call stack.

[Bug libstdc++/85472] Regex match bug

[timshen at gcc dot gnu.org]

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

--- Comment #2 from Tim Shen  ---
My bad, I didn't realize that "(z)((a+)?(b+)?(c))*" is exactly an example
described in ECMAScript third edition 15.10.2.5. Therefore libstdc++ is not
conforming.

[Bug libstdc++/85472] Regex match bug

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 CC||timshen at gcc dot gnu.org

--- Comment #1 from Tim Shen  ---
As I cross checked, boost 1.66, libstdc++, and python3 have the same behavior,
only libc++ is different from the rest.

I haven't checked the ECMAScript spec, but I suspect that it describes the
boost/libstdc++/python behavior, only because it's more efficient, not less
confusing.

I know exactly how libc++ produces this result. It creates an empty
match_result during each repetition ("*" operator). It's less confusing but
much slower.

[Bug lto/85405] [6 Regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1581

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.4.1
 Resolution|--- |FIXED
  Known to fail|6.4.1   |

--- Comment #10 from Martin Liška  ---
Fixed.

[Bug lto/85405] [6 Regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1581

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Wed Apr 25 07:41:44 2018
New Revision: 259634

URL: https://gcc.gnu.org/viewcvs?rev=259634=gcc=rev
Log:
Backport r259431

2018-04-25  Martin Liska  

Backport from mainline
2018-04-17  Martin Liska  

PR lto/85405
* ipa-devirt.c (odr_types_equivalent_p): Remove trailing
in message, remote space in between '_G' and '('.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ipa-devirt.c

[Bug lto/85248] [6 Regression] Miscompilation when using error function that returns

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.4.1
 Resolution|--- |FIXED
  Known to fail|6.4.0   |

--- Comment #17 from Martin Liška  ---
Fixed.

[Bug lto/85405] [6 Regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1581

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Author: marxin
Date: Wed Apr 25 07:41:25 2018
New Revision: 259633

URL: https://gcc.gnu.org/viewcvs?rev=259633=gcc=rev
Log:
Backport r259429

2018-04-25  Martin Liska  

Backport from mainline
2018-04-17  Jan Hubicka  

PR lto/85405
* ipa-devirt.c (odr_types_equivalent_p): Handle bit fields.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/ipa-devirt.c

[Bug lto/85248] [6 Regression] Miscompilation when using error function that returns

[marxin at gcc dot gnu.org]

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

--- Comment #16 from Martin Liška  ---
Author: marxin
Date: Wed Apr 25 07:40:46 2018
New Revision: 259632

URL: https://gcc.gnu.org/viewcvs?rev=259632=gcc=rev
Log:
Backport r259274

2018-04-25  Martin Liska  

Backport from mainline
2018-04-10  Martin Liska  

PR lto/85248
* lto-symtab.c (lto_symtab_merge_p): Do not check for
TREE_VALUES of error attributes.

Modified:
branches/gcc-6-branch/gcc/lto/ChangeLog
branches/gcc-6-branch/gcc/lto/lto-symtab.c

[Bug lto/85248] [6 Regression] Miscompilation when using error function that returns

[marxin at gcc dot gnu.org]

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

--- Comment #15 from Martin Liška  ---
Author: marxin
Date: Wed Apr 25 07:40:27 2018
New Revision: 259631

URL: https://gcc.gnu.org/viewcvs?rev=259631=gcc=rev
Log:
Backport r259265

2018-04-25  Martin Liska  

Backport from mainline
2018-04-10  Richard Biener  
Martin Liska  

PR lto/85248
* lto-symtab.c (lto_symtab_merge_p): Handle noreturn attribute.
2018-04-25  Martin Liska  

Backport from mainline
2018-04-10  Jakub Jelinek  

PR lto/85248
* gcc.dg/lto/pr85248_0.c: New test.
* gcc.dg/lto/pr85248_1.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/lto/pr85248_0.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/lto/pr85248_1.c
Modified:
branches/gcc-6-branch/gcc/lto/ChangeLog
branches/gcc-6-branch/gcc/lto/lto-symtab.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu,
   ||ia64-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-25
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  This also hits Itanium when building SPEC CPU 2000 with -O3
-funroll-loops -fpeel-loops in 176.gcc, 191.fma3d and 177.mesa.

[Bug middle-end/85516] [missed-optimization] gcc does not convert multiple compares against constants to a shift+bitmask test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-04-25
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
I expected fold_truth_andor to eventually catch this via fold_range_test. 
Probably the "bad" association in the testcase prevents this.

Anyway, this is a job for reassoc / if-conversion.

[Bug tree-optimization/85509] fails to promote local static to const

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to ASA from comment #3)
> (In reply to Richard Biener from comment #2)
> > The issue is you fail to make PerformQuickly and PerformSafely const and GCC
> > doesn't have local analysis to promote it so and IPA analysis is too late
> > for that since it is also the last inlining point.
> > 
> > Slight complication is nested functions and OMP outlining which may refer to
> > these variables.  But even the initial cgraph build should be able to figure
> > out the const-ness, no?
> > 
> > Workaround: make the vars const.
> 
> 
> I stated that const solves the issue in the description.  If the auto
> variables have automatic duration (remove the keyword static), the compiler
> is able to inline the invocation without the const qualifier.  As stated,
> LLVM (clang++) does inline the invocation even if it has static duration.
> 
> I would expect this is likely true for any non-const static duration
> function pointer, not just the case when the auto type specifier is used,
> but I have not confirmed it.

But it is the case for any non-const static duration function pointer.
This has nothing to do with 'auto', changing the testcase to

static inline bool
RunTest( void ) {
static bool (*PerformQuickly)(int &, const int &) = Perform< SumQuickly >;
static bool (*PerformSafely)(int &, const int &) = Perform< SumSafely >;
int i = 0;
return PerformQuickly( i, 1 ) && !PerformSafely( i, INT_MAX );
}

has no effect.

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #15 from Jakub Jelinek  ---
Fixed for 8.1+.

[Bug c++/55004] [meta-bug] constexpr issues

[jakub at gcc dot gnu.org]

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

Bug 49171 Summary: [C++0x][constexpr] Constant expressions support 
reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171

   What|Removed |Added

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

[Bug c++/55004] [meta-bug] constexpr issues

[jakub at gcc dot gnu.org]

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

Bug 85437 Summary: [8 Regression] member pointer static upcast rejected in a 
constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85437

   What|Removed |Added

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

[Bug c++/85437] [8 Regression] member pointer static upcast rejected in a constexpr context

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 25 07:10:16 2018
New Revision: 259629

URL: https://gcc.gnu.org/viewcvs?rev=259629=gcc=rev
Log:
PR c++/85437
PR c++/49171
* cp-tree.h (REINTERPRET_CAST_P): New.
* constexpr.c (cxx_eval_constant_expression) :
Reject REINTERPET_CAST_P conversions.  Use cplus_expand_constant
for non-trivial PTRMEM_CST cases.
* typeck.c (build_nop_reinterpret): New.
(build_reinterpret_cast_1): Use it.  Set REINTERPRET_CAST_P on
NOP_EXPRs returned by cp_convert.

* g++.dg/cpp0x/addressof1.C: Make reinterpret cases runtime checks.
* g++.dg/cpp0x/constexpr-cast.C: Remove xfails
* g++.dg/cpp0x/constexpr-nullptr-2.C: Likewise.
* g++.dg/cpp0x/constexpr-pmf1.C: Check when optimized.
* g++.dg/cpp0x/pr85437-1.C: New.
* g++.dg/cpp0x/pr85437-2.C: New.
* g++.dg/cpp0x/pr85437-3.C: New.
* g++.dg/cpp0x/pr85437-4.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-1.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-3.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/addressof1.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-cast.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-pmf1.C

[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr 25 07:10:16 2018
New Revision: 259629

URL: https://gcc.gnu.org/viewcvs?rev=259629=gcc=rev
Log:
PR c++/85437
PR c++/49171
* cp-tree.h (REINTERPRET_CAST_P): New.
* constexpr.c (cxx_eval_constant_expression) :
Reject REINTERPET_CAST_P conversions.  Use cplus_expand_constant
for non-trivial PTRMEM_CST cases.
* typeck.c (build_nop_reinterpret): New.
(build_reinterpret_cast_1): Use it.  Set REINTERPRET_CAST_P on
NOP_EXPRs returned by cp_convert.

* g++.dg/cpp0x/addressof1.C: Make reinterpret cases runtime checks.
* g++.dg/cpp0x/constexpr-cast.C: Remove xfails
* g++.dg/cpp0x/constexpr-nullptr-2.C: Likewise.
* g++.dg/cpp0x/constexpr-pmf1.C: Check when optimized.
* g++.dg/cpp0x/pr85437-1.C: New.
* g++.dg/cpp0x/pr85437-2.C: New.
* g++.dg/cpp0x/pr85437-3.C: New.
* g++.dg/cpp0x/pr85437-4.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-1.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-3.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/addressof1.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-cast.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-pmf1.C

[Bug c++/85437] [8 Regression] member pointer static upcast rejected in a constexpr context

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed by Nathan.