[Bug tree-optimization/92819] [10 Regression] Worse code generated on avx2 due to simplify_vector_constructor

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Fri Dec  6 07:53:15 2019
New Revision: 279033

URL: https://gcc.gnu.org/viewcvs?rev=279033&root=gcc&view=rev
Log:
2019-12-06  Richard Biener  

PR tree-optimization/92819
* match.pd (VEC_PERM_EXPR -> BIT_INSERT_EXPR): Handle inserts
into the last lane.  For two-element vectors try inserting
into the last lane when inserting into the first fails.

* gcc.target/i386/pr92819-1.c: New testcase.
* gcc.target/i386/pr92803.c: Adjust.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr92819-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr92803.c

[Bug go/92810] Compiling GCC go for aarch64_be-marvell-linux-gnu fails

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Dec  6 05:32:49 2019
New Revision: 279032

URL: https://gcc.gnu.org/viewcvs?rev=279032&root=gcc&view=rev
Log:
PR go/92810
libgo: recognize aarch64_be as arm64be

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/210038

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/configure
trunk/libgo/configure.ac

[Bug libfortran/92836] segfault with inquire()

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
Removing close statement:

$ ./a.out 
   0   8   4
   2   8   4
 -10
   5   8   4
   4   8   4
   3   8   4
At line 16 of file bug1.f90
Fortran runtime error: End of record
   6   8   4
At line 14 of file bug1.f90
Internal Error: Unit number changed
At line 14 of file bug1.f90

What I speculate is happening is that newunit is getting invoked in the middle
of trying to close the unit on a different thread and we do end up with
duplicate unit numbers assigned by newunit.  I need to look at that code yet.

Exploring further here.

[Bug libfortran/92836] segfault with inquire()

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
With the the following example I see varying results:

program inq
  use OMP_Lib
  implicit none
  logical :: s
  character(len=27) :: c
  integer :: i, j

  i=64
  !$omp parallel private(c,j,s)
  print *, OMP_Get_Thread_Num(), omp_get_num_threads(), omp_get_num_threads()/2
  do while (.true.)
 if (OMP_Get_Thread_Num() < omp_get_num_threads()/2) then
open(newUnit=j,file='test.txt',form='formatted',status='unknown')
write (c,'(e17.10, ">>>",i5, i5, "<<<")') 1.23456d0, j,
OMP_Get_Thread_Num()
write (j,*) trim(c)
close(j)
 else
inquire(file='test.txt',exist=s)
 end if
  end do
  !$omp end parallel
end program

I get randomly:

$ ./a.out 
   0   8   4
   3   8   4
   6   8   4
   5   8   4
   4   8   4
   1   8   4
   2   8   4
At line 14 of file bug1.f90
At line 14 of file bug1.f90
   7   8   4
Fortran runtime error: Fortran runtime error: End of recordEnd of record

$ ./a.out 
   2   8   4
   5   8   4
   6   8   4
   1   8   4
   7   8   4
   0   8   4
   4   8   4
   3   8   4
At line 14 of file bug1.f90
At line 14 of file bug1.f90
At line 14 of file bug1.f90
At line 14 of file bug1.f90
Fortran runtime error: Fortran runtime error: Fortran runtime error: End of
recordFortran runtime error: End of recordEnd of record
End of record


[jerry@amdr threadbug]$ ./a.out 
   0   8   4
   2   8   4
   6   8   4
   1   8   4
   5   8   4
   7   8   4
At line 14 of file bug1.f90
Fortran runtime error: End of record
   3   8   4

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

Backtrace for this error:
$ ./a.out 
   2   8   4
   6   8   4
   1   8   4
   0   8   4
   5   8   4
   7   8   4
   3   8   4
   4   8   4
At line 14 of file bug1.f90
At line 14 of file bug1.f90
Fortran runtime error: At line 14 of file bug1.f90
At line 14 of file bug1.f90
End of recordFortran runtime error: Fortran runtime error: Fortran runtime
error: 
End of recordEnd of recordEnd of record


$ ./a.out 
   7   8   4
   6   8   4
   1   8   4
   0   8   4
   5   8   4
   2   8   4
   3   8   4
At line 14 of file bug1.f90
Fortran runtime error:4   8   4
End of record
At line 14 of file bug1.f90
Fortran runtime error: End of file

[Bug c++/92837] New: ICE on syntax error in requires clause, in cp_parser_constraint_primary_expression

[arthur.j.odwyer at gmail dot com]

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

Bug ID: 92837
   Summary: ICE on syntax error in requires clause, in
cp_parser_constraint_primary_expression
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

Bug 92439 may be related.

cat >test.cc < concept A = true;
template requires (A int
EOF
g++ -std=c++2a test.cc

test.cc:2:29: internal compiler error: in
cp_parser_constraint_primary_expression, at cp/parser.c:27319
3 | template requires (A int
  | ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libfortran/92836] segfault with inquire()

[abensonca at gmail dot com]

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

--- Comment #2 from Andrew Benson  ---
Answers to questions raised by Jerry at:

https://gcc.gnu.org/ml/fortran/2019-12/msg00059.html

> 1) Are you opening a unique file (by file name) in each thread?

No. The code is operating on many files, but in the specific case that causes
the problem it's a file which is shared by all threads. Specifically, it's a
file which is generated by the code if the file does not already exist (it
stores solutions to a time-consuming calculation), or is read by the code if it
does exist. All threads write/read the same file.

> 2) Are you trying to synchronize these threads using the inquire?

No. The inquire() is used only to see if the file exists already. If it does,
the code branches to read the file, if it does not, the code branches to
generate the data for the file and then write it.

Synchronization of the file accesses are being handled using file locks, i.e. I
use ISO_C_Binding to allow me to call fcntl(). Since the Linux kernel on the
machine I'm using is too old to support OFD locks I'm using POSIX locks plus
OpenMP locks (since POSIX locks are per processes so I have to separately
synchronize the OpenMP threads).

> 3) or, trying to ensure a unique filename for each file or avoid the same
> file in two or more threads?

No. The problem always seems to occur when a thread inquires() on one
particular file, and the file name is the same across all threads.

There are other places in my code where inquire() is being used on other file
names. But in all cases the filename is the same for all threads.

[Bug libfortran/92836] segfault with inquire()

[abensonca at gmail dot com]

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

--- Comment #1 from Andrew Benson  ---
Running with -fsanitize=thread (suggested by Tobias) gives:

==
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=9982)
  Cycle in lock order graph: M26 (0x7f02bb31c340) => M84 (0x7b58002efee0) => 
M26

  Mutex M84 acquired here while holding mutex M26 in thread T63:
#0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/sanitizer_common/
sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x5095a)
#1 __gthread_mutex_lock ../libgcc/gthr-default.h:749 (libgfortran.so.
5+0x1e25c9)
#2 insert_unit ../../../gcc-trunk/libgfortran/io/unit.c:244 
(libgfortran.so.5+0x1e25c9)
#3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so.
1+0x198a5)

  Mutex M26 previously acquired by the same thread here:
#0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/sanitizer_common/
sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x5095a)
#1 __gthread_mutex_lock ../libgcc/gthr-default.h:749 (libgfortran.so.
5+0x1e265c)
#2 get_gfc_unit ../../../gcc-trunk/libgfortran/io/unit.c:332 
(libgfortran.so.5+0x1e265c)
#3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so.
1+0x198a5)

  Mutex M26 acquired here while holding mutex M84 in thread T63:
#0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/sanitizer_common/
sanitizer_common_interceptors.inc:4148 (libtsan.so.0+0x5095a)
#1 __gthread_mutex_lock ../libgcc/gthr-default.h:749 (libgfortran.so.
5+0x1e336b)
#2 close_unit_1 ../../../gcc-trunk/libgfortran/io/unit.c:735 
(libgfortran.so.5+0x1e336b)
#3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so.
1+0x198a5)

  Mutex M84 previously acquired by the same thread here:
#0 pthread_mutex_trylock ../../../../gcc-trunk/libsanitizer/tsan/
tsan_interceptors_posix.cpp:1246 (libtsan.so.0+0x4340a)
#1 __gthread_mutex_trylock ../libgcc/gthr-default.h:758 (libgfortran.so.
5+0x1e26f1)
#2 get_gfc_unit ../../../gcc-trunk/libgfortran/io/unit.c:380 
(libgfortran.so.5+0x1e26f1)
#3 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:123 (libgomp.so.
1+0x198a5)

  Thread T63 (tid=10047, running) created by main thread at:
#0 pthread_create ../../../../gcc-trunk/libsanitizer/tsan/
tsan_interceptors_posix.cpp:962 (libtsan.so.0+0x5bb22)
#1 gomp_team_start ../../../gcc-trunk/libgomp/team.c:839 (libgomp.so.
1+0x19eba)
#2 main  (a.out+0x400ef9)

SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) ../libgcc/
gthr-default.h:749 in __gthread_mutex_lock
==

[Bug libfortran/92836] New: segfault with inquire()

[abensonca at gmail dot com]

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

Bug ID: 92836
   Summary: segfault with inquire()
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

I'm attempting to track down a segfault that seems to be associated with the 
inquire() statement. Unfortunately it only happens when running a massively 
parallel code, using both MPI and OpenMP parallelism, and I have as yet been 
unable to make a simple test case that reproduces the bug. I also haven't 
convinced myself 100% that the problem is really in the libgfortran code for 
inquire() and not in my own code, but since it seems that inquire() should be 
thread safe it seems that the problem at least could be in libgfortran.

So, I'm hoping that someone on the mailing list has suggestions for how to 
track this down as I've exhausted everything I can think of!

The segfault is triggered by:

inquire(file=fileName,exist=exists)

This works as expected most of the time, but occasionally (typically after 
thousands of calls in a code running with 128 MPI processes and 4 OpenMP 
threads each) it will segfault. The gdb trace for the failed thread is:

(gdb) where
#0  galacticus_error::galacticus_signal_handler_sigsegv () at ./work/buildMPI/
galacticus.error.p.F90:328
#1  
#2  find_file0 (u=, st=st@entry=0x7ffed9b88ad0) at ../../../gcc-
trunk/libgfortran/io/unix.c:1725
#3  0x7f33ac1b7460 in find_file0 (u=, 
st=st@entry=0x7ffed9b88ad0) at ../../../gcc-trunk/libgfortran/io/unix.c:1741
#4  0x7f33ac1b7460 in find_file0 (u=, 
st=st@entry=0x7ffed9b88ad0) at ../../../gcc-trunk/libgfortran/io/unix.c:1741
#5  0x7f33ac1b7460 in find_file0 (u=, 
st=st@entry=0x7ffed9b88ad0) at ../../../gcc-trunk/libgfortran/io/unix.c:1741
#6  0x7f33ac1b7460 in find_file0 (u=, 
st=st@entry=0x7ffed9b88ad0) at ../../../gcc-trunk/libgfortran/io/unix.c:1741
#7  0x7f33ac1b7460 in find_file0 (u=, 
st=st@entry=0x7ffed9b88ad0) at ../../../gcc-trunk/libgfortran/io/unix.c:1741
#8  0x7f33ac1b8bbb in _gfortrani_find_file (file=, 
file_len=) at ../../../gcc-trunk/libgfortran/io/unix.c:1779
#9  0x7f33ac1a601d in _gfortran_st_inquire (iqp=0x7ffed9b88bf0) at 
../../../gcc-trunk/libgfortran/io/inquire.c:803

and the relevant line in unix.c is:

1725  if (st[0].st_dev == s->st_dev && st[0].st_ino == s->st_ino)

If I examine the variables used in this line I find:

(gdb) print st[0]
$2 = {st_dev = 24, st_ino = 12194159, st_nlink = 1, st_mode = 33188, st_uid = 
509, st_gid = 100, __pad0 = 0, st_rdev = 0, st_size = 104168, st_blksize = 
1048576, st_blocks = 208, 
  st_atim = {tv_sec = 1575236480, tv_nsec = 343597308}, st_mtim = {tv_sec = 
1575236486, tv_nsec = 774663718}, st_ctim = {tv_sec = 1575236486, tv_nsec = 
774663718}, __unused = {0, 0, 
0}}
(gdb) print *s
Cannot access memory at address 0x7f33818d7eb0

which suggests that "s" is somehow corrupted. I don't see how this can happen 
though as the "unit_lock" lock is used by find_file() which should prevent any 
modification to the tree of units. 

One other OpenMP thread was waiting for unit_lock:

#0  __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/
lowlevellock.S:136
#1  0x7f33ab4a354f in _L_lock_1028 () from /home/abenson/Galacticus/Tools/
lib/libpthread.so.0
#2  0x7f33ab4a336b in __pthread_mutex_lock (mutex=0x7f33ac40b340 
<_gfortrani_unit_lock>) at pthread_mutex_lock.c:61
#3  0x7f33ac1b6f3c in __gthread_mutex_lock (__mutex=0x7f33ac40b340 
<_gfortrani_unit_lock>) at ../libgcc/gthr-default.h:749
#4  _gfortrani_newunit_alloc () at ../../../gcc-trunk/libgfortran/io/unit.c:
906
#5  0x7f33ac1b706b in _gfortrani_get_unit (dtp=dtp@entry=0x7f33a1785800, 
do_create=do_create@entry=1) at ../../../gcc-trunk/libgfortran/io/unit.c:555
#6  0x7f33ac1b4ebd in data_transfer_init (dtp=dtp@entry=0x7f33a1785800, 
read_flag=read_flag@entry=0) at ../../../gcc-trunk/libgfortran/io/transfer.c:
2851
#7  0x7f33ac1b5924 in _gfortran_st_write (dtp=dtp@entry=0x7f33a1785800) at 
../../../gcc-trunk/libgfortran/io/transfer.c:4392

and was doing other writes to an internal file unit just prior to this.

[Bug c/92826] Impossible to silence warning: non-standard suffix on floating constant [-Wpedantic]

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #1)
> I think this is a duplicate of an existing bug.

bug 87274 perhaps?

[Bug testsuite/92829] [10 regression] several test case failures starting with r278983

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Fri Dec  6 01:04:42 2019
New Revision: 279031

URL: https://gcc.gnu.org/viewcvs?rev=279031&root=gcc&view=rev
Log:
PR testsuite/92829 - several test case failures starting with r278983

gcc/testsuite/ChangeLog:

* gcc.dg/Warray-bounds-56.c: Rearrange code to avoid powerpc64*
failures.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/Warray-bounds-56.c

[Bug testsuite/92829] [10 regression] several test case failures starting with r278983

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
The failures in Warray-bounds-56.c boil down to this test case where the
powerpc64 cross-compiler diagnoses only three out of the four buffer overflows,
 missing the one first one in f().  The native x86_64 compiler detects all of
them.  I'll adjust the test to avoid the failure but I'll probably raise a
separate bug to look into why it happens because it affects other tests as
well.

$ cat t.c && /build/powerpc64le-linux/gcc-svn/gcc/xgcc -B
/build/powerpc64le-linux/gcc-svn/gcc -O2 -S -Wall -Wno-stringop-overflow
-ftrack-macro-expansion=0 t.c
typedef __SIZE_TYPE__ size_t;

extern void* malloc (size_t);
extern char* strcpy (char*, const char*);

void sink (void*);

size_t value (void);

size_t range (size_t min, size_t max)
{
  size_t val = value ();
  return val < min || max < val ? min : val;
}

#undef T
#define T(T, src, n) do {   \
char *s = src;  \
typedef struct { T n, ax[]; } Flex; \
Flex *p = (Flex*)malloc (sizeof *p + n);\
char *d = (char*)p->ax; \
strcpy (d, s);  \
sink (p);   \
  } while (0)

void f (void)
{
  size_t r_1_2 = range (1, 2);
  size_t r_2_3 = range (2, 3);

  T (char, "12", r_1_2);   // { dg-warning "\\\[-Warray-bounds" }
  T (char, "123456789", r_2_3);// { dg-warning "\\\[-Warray-bounds" }
}

void g (void)
{
  size_t r_1_2 = range (1, 2);
  T (char, "12", r_1_2);   // { dg-warning "\\\[-Warray-bounds" }

  size_t r_2_3 = range (2, 3);
  T (char, "123456789", r_2_3);// { dg-warning "\\\[-Warray-bounds" }
}

t.c: In function 'f':
t.c:32:3: warning: '__builtin_memcpy' forming offset [4, 10] is out of the
bounds [0, 4] [-Warray-bounds]
   32 |   T (char, "123456789", r_2_3);// { dg-warning "\\\[-Warray-bounds"
}
  |   ^
t.c: In function 'g':
t.c:38:3: warning: '__builtin_memcpy' forming offset 3 is out of the bounds [0,
3] [-Warray-bounds]
   38 |   T (char, "12", r_1_2);   // { dg-warning "\\\[-Warray-bounds"
}
  |   ^
t.c:41:3: warning: '__builtin_memcpy' forming offset [4, 10] is out of the
bounds [0, 4] [-Warray-bounds]
   41 |   T (char, "123456789", r_2_3);// { dg-warning "\\\[-Warray-bounds"
}
  |   ^

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

[doko at debian dot org]

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #9 from Matthias Klose  ---
not fixed on arm-linux-gnuaebi-hf

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

[doko at ubuntu dot com]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at ubuntu dot com

--- Comment #8 from Matthias Klose  ---
an arm-linux-gnuebaihf build now fails with:

./../../src/libgo/runtime/go-context.S: Assembler messages:
../../../src/libgo/runtime/go-context.S:74: Error: junk at end of line, first
unrecognized character is `,'
make[6]: *** [Makefile:1441: runtime/go-context.lo] Error 1

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org]

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

Bug 92622 Summary: FAIL: gcc.dg/Warray-bounds-22.c on ILP32: missing warnings 
for VLA on lines 67 and 69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92622

   What|Removed |Added

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

[Bug middle-end/92622] FAIL: gcc.dg/Warray-bounds-22.c on ILP32: missing warnings for VLA on lines 67 and 69

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|ASSIGNED|RESOLVED
  Component|testsuite   |middle-end
 Resolution|--- |FIXED

--- Comment #6 from Martin Sebor  ---
Patch (https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00386.html) committed in
r279029.

[Bug testsuite/92622] FAIL: gcc.dg/Warray-bounds-22.c on ILP32: missing warnings for VLA on lines 67 and 69

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Fri Dec  6 00:18:32 2019
New Revision: 279029

URL: https://gcc.gnu.org/viewcvs?rev=279029&root=gcc&view=rev
Log:
PR middle-end/92622 - FAIL: gcc.dg/Warray-bounds-22.c on ILP32: missing
warnings for VLA on lines 67 and 69

gcc/ChangeLog:

PR middle-end/92622
* tree-vrp.c (vrp_prop::check_array_ref): Avoid using a variable
left uninitialized by get_addr_base_and_unit_offset ofn failure.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vrp.c

[Bug middle-end/92824] Wrong optimization: representation of long doubles not copied even with memcpy

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

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

--- Comment #2 from Andreas Schwab  ---
On m68k the padding is internal, and actually part of the representation.

[Bug middle-end/92824] Wrong optimization: representation of long doubles not copied even with memcpy

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu, m68k

--- Comment #1 from Andrew Pinski  ---
y = x;

I thought that would only copy the representational bits.  so padding for the
scalar value is ignored.

NOTE this is only an issue with x86 (and maybe m68k too)'s 80bit but with 16bit
(or 48bit) worth of padding.  Those are the only scalar types with padding.  No
other targets have this padding issue.

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Thu Dec  5 23:53:09 2019
New Revision: 279024

URL: https://gcc.gnu.org/viewcvs?rev=279024&root=gcc&view=rev
Log:
PR tree-optimization/92768
* gcc.dg/pr92768.c: Add -w -Wno-psabi to dg-options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/pr92768.c

[Bug target/67733] illumos needs a new target triple

[ikozhukhov at gmail dot com]

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

--- Comment #7 from Igor Kozhukhov  ---
i'd like to have DilOS triplets like:
Intel:
x86_64-dilos/i386-dilos
(or for 64bit amd64-dilos)

SPARC:
sparc64-dilos/sparc-dilos (or sparc32-dilos)
(or 64bit: sparcv9-dilos, 32bit: sparcv7-dilos)

it one day DilOS can be independent platform and do not depend on illumos.

right now we have DilOS as separate platform for ZFS:
https://docs.google.com/spreadsheets/d/1CFapSYxA5QRFYy5k6ge3FutU7zbAWbaeGN2nKVXgxCI/edit?pli=1#gid=0

because ZFS features are different.
also, with DilOS we are try to port and use Debian userland in main place - it
is not what illumos does + additional platform specific updates.

i'm DilOS owner.
question is: if i need new triplets, what is procedure for add it to GCC
mainline?
what are triplets can be used/useful for our platform?

A Poster Maker For Your School

[Poster Studio]

Can't see this email?. View in browser 
  

  

  

  


  
   

  
   

  
   

  
   
  

  

  

  


  
  
   

  
   

  
   

  
  Make Giant School PostersWith One Button! 
  

  

  

  


  
   

  
   


  
   

  
   
  
  
   

  
   
  

  
  
   
  

  



  
   

  
   

  
   
  

  
  
  True, Full Color Letter-To-Poster! 
  
  
   
  
  
  With the Poster Studio Express, you can quickly and 
easily create giant posters by scanning letter sized originals and pressing one 
button! 
  
  
   

  
   
  

  

  


  

  


  
   

  
   

  
   

  
   
  
  
  Poster Makers Available In 13", 24", 36" 44" and 60" 
Sizes!  
  

  

  
  
   


  
   

  
   
  

  



  
   

  
  With the Poster Studio Express, any teacher or staff 
member can create wildly elaborate and engaging posters by simply pressing one 
button!No more expensive trips to your local printing store! 
  

  


  
  
   

  
   

  
  With Our Poster Templates, 
  
  
  Creativity Is Included. 
  
  
  The Poster Studio Express includes 100's of templates, 
1,000's of fonts, and 100's of thousands of images! All making up the easiest 
and most complete way to quickly and easily produce economical, engaging and 
captivating classroom visuals that last! 
  
  
  Read More 
  

  

  
  
   


  
   

  
   
  

   
  



  
   

  
   
  

   
  



  
   

  
   

[Bug libgomp/92835] New: [OpenACC] Run time error with enter./exit data

[caplanr at predsci dot com]

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

Bug ID: 92835
   Summary: [OpenACC]  Run time error with enter./exit data
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: caplanr at predsci dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

I am trying to compile and run my OpenACC code with GNU 9.1.0 branch.

I am getting the following error:

libgomp:  GOACC_enter_exit_data UNHANDLED kind 0x01

What does this mean?  My code works fine with PGI.

[Bug demangler/92453] write buffer overflow in cplus_demangle()

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2019-11/msg02682.ht
   ||ml
 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to Tim Ruehsen from comment #3)
> (In reply to Christian Biesinger from comment #2)
> > Could you send your patch to gcc-patches per
> > https://gcc.gnu.org/contribute.html#patches ? Thanks!
> 
> I did that some days ago:
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02682.html

adding "patch" keyword then

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=28036

--- Comment #7 from Eric Gallager  ---
related: bug 28036

[Bug c++/84255] accepts redefinition of template variable

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
This should probably be caught in redeclaration_error_message but isn't because

 2991   if (TREE_CODE (DECL_TEMPLATE_RESULT (newdecl)) != FUNCTION_DECL
 2992   || (DECL_TEMPLATE_RESULT (newdecl)
 2993   == DECL_TEMPLATE_RESULT (olddecl)))
 2994 return NULL;

and here DECL_TEMPLATE_RESULT is a VAR_DECL.

[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
*** Bug 92441 has been marked as a duplicate of this bug. ***

[Bug c++/92441] [10 regression] ICE: in strip_typedefs, at cp/tree.c:1681

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #4 from Marek Polacek  ---
This has been fixed, assuming it's a dup of 92206.

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

[Bug c++/92576] Definition of variable template without initializer is treated as declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
I think accepting the invalid first definition is PR 68012.

Accepting the second definition is PR 84255.

[Bug c++/84255] accepts redefinition of template variable

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2018-02-06 00:00:00 |2019-12-5

--- Comment #1 from Jonathan Wakely  ---
Still present on trunk. Slightly reduced:

template bool var = false;
template bool var = true;

[Bug testsuite/92622] FAIL: gcc.dg/Warray-bounds-22.c on ILP32: missing warnings for VLA on lines 67 and 69

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #4 from Martin Sebor  ---
I think I see the problem.  It's due to the use of an uninitialized variable.
The patch below fixes it:

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 279008)
+++ gcc/tree-vrp.c  (working copy)
@@ -3544,7 +3544,7 @@ vrp_prop::check_array_ref (location_t location, tr
  decl = base;
}

- if (known_gt (off, 0))
+ if (base && known_gt (off, 0))
maxbound = wide_int_to_tree (sizetype,
 wi::sub (wi::to_wide (maxbound),
  off));

[Bug c/92833] ice for broken C code

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman  ---
Something similar for this list of tokens:

 extern
 ==
 ==
 ==

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

[mpolacek at gcc dot gnu.org]

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

Bug 91353 Summary: Implement P1331R2: Permitting trivial default initialization 
in constexpr contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91353

   What|Removed |Added

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

[Bug c++/88323] implement C++20 language features.

[mpolacek at gcc dot gnu.org]

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

Bug 91353 Summary: Implement P1331R2: Permitting trivial default initialization 
in constexpr contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91353

   What|Removed |Added

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

[Bug c++/91353] Implement P1331R2: Permitting trivial default initialization in constexpr contexts

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Implemented for GCC 10.

[Bug tree-optimization/92825] Unnecesary stack protection in Firefox's LightPixel.

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

Summary|Unnecesary stack protection |Unnecesary stack protection
   |and missed SLP  |in Firefox's LightPixel.
   |vectorization in Firefox's  |
   |LightPixel. |

--- Comment #2 from Jan Hubicka  ---
I have filled separate bug for the SLP issue so we do not mix multiple things
in one PR. 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92834

[Bug tree-optimization/92834] New: misssed SLP vectorization in LightPixel

[hubicka at gcc dot gnu.org]

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

Bug ID: 92834
   Summary: misssed SLP vectorization in LightPixel
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47431
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47431&action=edit
simplified testcase

Clang is able to vectorize LightPixel which leads to about 10% improvements in
rasterflood-svg Firefox benchmark.

[Bug c++/91353] Implement P1331R2: Permitting trivial default initialization in constexpr contexts

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Thu Dec  5 20:13:03 2019
New Revision: 279019

URL: https://gcc.gnu.org/viewcvs?rev=279019&root=gcc&view=rev
Log:
PR c++/91353 - P1331R2: Allow trivial default init in constexpr
contexts.

This patch implements C++20 P1331, allowing trivial default initialization in
constexpr contexts.

* c-cppbuiltin.c (c_cpp_builtins): Adjust the value of __cpp_constexpr.

* class.c (trivial_default_constructor_is_constexpr): Return true in
C++20.
* constexpr.c (cx_check_missing_mem_inits): Allow missing field
initializers in C++20.
(cxx_eval_call_expression): Don't clear CONSTRUCTOR_NO_CLEARING for
constexpr constructors in C++20.
(reduced_constant_expression_p): Don't set FIELD for union and array
types.  Skip empty class fields without initializers.
* decl.c (check_for_uninitialized_const_var): Permit trivial default
initialization in constexpr.
(next_initializable_field): Don't skip vptr fields.
* method.c (walk_field_subobs): Still consider a constructor that
doesn't initialize all the members constexpr.

* g++.dg/cpp0x/constexpr-array6.C: Adjust dg-error.
* g++.dg/cpp0x/constexpr-ctor.C: Likewise.
* g++.dg/cpp0x/constexpr-diag3.C: Likewise.
* g++.dg/cpp0x/constexpr-diag4.C: Likewise.
* g++.dg/cpp0x/constexpr-ex3.C: Likewise.
* g++.dg/cpp0x/constexpr-template2.C: Likewise.
* g++.dg/cpp0x/constexpr-union2.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-mangle.C: Rip out a piece of code ...
* g++.dg/cpp0x/lambda/lambda-mangle6.C: ... and put it here.
* g++.dg/cpp0x/pr79118.C: Adjust dg-error.
* g++.dg/cpp1y/constexpr-83921-3.C: Likewise.
* g++.dg/cpp1y/constexpr-neg1.C: Likewise.
* g++.dg/cpp1z/constexpr-lambda12.C: Likewise.
* g++.dg/cpp1z/feat-cxx1z.C: Use -std=c++17.
* g++.dg/cpp2a/constexpr-init1.C: New test.
* g++.dg/cpp2a/constexpr-init2.C: New test.
* g++.dg/cpp2a/constexpr-init3.C: New test.
* g++.dg/cpp2a/constexpr-init4.C: New test.
* g++.dg/cpp2a/constexpr-init5.C: New test.
* g++.dg/cpp2a/constexpr-init6.C: New test.
* g++.dg/cpp2a/constexpr-init7.C: New test.
* g++.dg/cpp2a/constexpr-init8.C: New test.
* g++.dg/cpp2a/constexpr-init9.C: New test.
* g++.dg/cpp2a/constexpr-init10.C: New test.
* g++.dg/cpp2a/constexpr-init11.C: New test.
* g++.dg/cpp2a/constexpr-init12.C: New test.
* g++.dg/cpp2a/constexpr-init13.C: New test.
* g++.dg/cpp2a/constexpr-init14.C: New test.
* g++.dg/cpp2a/constexpr-init15.C: New test.
* g++.dg/cpp2a/constexpr-try5.C: Adjust dg-error.
* g++.dg/cpp2a/feat-cxx2a.C: Test __cpp_constexpr.
* g++.dg/cpp2a/lambda-mangle.C: New test.
* g++.dg/debug/dwarf2/pr44641.C: Skip for c++2a.
* g++.dg/ext/stmtexpr21.C: Adjust dg-error.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle6.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init1.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init10.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init11.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init12.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init13.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init14.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init15.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init2.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init3.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init4.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init5.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init6.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init7.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init8.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-init9.C
trunk/gcc/testsuite/g++.dg/cpp2a/lambda-mangle.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-cppbuiltin.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/decl.c
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array6.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-diag3.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-diag4.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ex3.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template2.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-union2.C
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-mangle.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr79118.C
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-83921-3.C
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-neg1.C
trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-lambda12.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-

[Bug c++/92831] CWG1299 extend_ref_init_temps_1 punts on COND_EXPRs

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Even better testcase that has nested COND_EXPRs:
template using id = T;
struct S { S () { s++; } ~S () { s--; } S (int) { s++; } static int s; };
int S::s = 0;

void
bar (bool cond, bool cond2)
{
  if (S::s != (cond ? cond2 ? 7 : 5 : cond2 ? 8 : 9))
__builtin_abort ();
}

void
foo (bool cond, bool cond2)
{
  int i = 1;
  // temporary array has same lifetime as a
  S&& a = id{1, 2, 3}[i];
  // temporary S has same lifetime as b
  const S& b = static_cast(0);
  // exactly one of the four temporaries is lifetime-extended
  S&& c = cond ? cond2 ? id{1, 2, 3}[i] : static_cast(0)
   : cond2 ? id{1, 2, 3, 4}[i] : id{1, 2, 3, 4, 5}[i];
  bar (cond, cond2);
}

int
main ()
{
  foo (true, true);
  foo (true, false);
  foo (false, true);
  foo (false, false);
}

--- gcc/cp/call.c.jj2019-12-05 10:03:04.110181312 +0100
+++ gcc/cp/call.c   2019-12-05 20:35:08.386092965 +0100
@@ -12153,12 +12153,19 @@ extend_ref_init_temps_1 (tree decl, tree
 = extend_ref_init_temps_1 (decl, TREE_OPERAND (sub, 1), cleanups);
   return init;
 }
+  if (TREE_CODE (sub) == COND_EXPR)
+{
+  TREE_OPERAND (sub, 1)
+   = extend_ref_init_temps_1 (decl, TREE_OPERAND (sub, 1), cleanups);
+  TREE_OPERAND (sub, 2)
+   = extend_ref_init_temps_1 (decl, TREE_OPERAND (sub, 2), cleanups);
+  return init;
+}
   if (TREE_CODE (sub) != ADDR_EXPR)
 return init;
   /* Deal with binding to a subobject.  */
   for (p = &TREE_OPERAND (sub, 0);
-   (TREE_CODE (*p) == COMPONENT_REF
-   || TREE_CODE (*p) == ARRAY_REF); )
+   TREE_CODE (*p) == COMPONENT_REF || TREE_CODE (*p) == ARRAY_REF; )
 p = &TREE_OPERAND (*p, 0);
   if (TREE_CODE (*p) == TARGET_EXPR)
 {
isn't sufficient, because if there are any cleanups added by either of the
recursive calls, we need to conditionalize those cleanups on whether the
particular COND_EXPR's first operand evaluated to true or false.  I think
cp_save_expr won't do it for the nested cases though, because the SAVE_EXPR
might end up not being initialized.  So we need to arrange for a bool temporary
that will be initialized to say false early, before the first COND_EXPR is
encountered, set it to true at the start of corresponding init code and wrap
cleanups with that guard.
Any better ideas?

[Bug c++/92271] for consistency, __is_same_as should be named __is_same

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Thu Dec  5 20:06:46 2019
New Revision: 279018

URL: https://gcc.gnu.org/viewcvs?rev=279018&root=gcc&view=rev
Log:
PR c++/92271 - make __is_same alias for __is_same_as.

Richard Smith proposed adding a synonym for __is_same_as, to accomodate the
convention of exposing std::SOME_TRAIT::value as __SOME_TRAIT(A, B).

So add that alias, and also adjust the C++ printer.  I didn't bother changing
the RID_ identifier.

* c-common.c: Add __is_same, an alias for __is_same_as.

* cxx-pretty-print.c (pp_cxx_trait_expression) :
Print "__is_same".

* g++.dg/ext/is_same.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/is_same.C
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cxx-pretty-print.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/92271] for consistency, __is_same_as should be named __is_same

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Done.

[Bug ipa/92800] IPA escape analysis for structs

[christoph.muell...@theobroma-systems.com]

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

--- Comment #2 from Christoph Müllner 
 ---
Thanks for mentioning that.
We have an upcoming conf call with Marvell where we will discuss this.

[Bug testsuite/92622] FAIL: gcc.dg/Warray-bounds-22.c on ILP32: missing warnings for VLA on lines 67 and 69

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The reduced test case below reproduces the spurious nature of the failure
outside the test harness:

$ (set -x; cat t.c && for i in 1 2 3; do gcc -O2 -S -Warray-bounds
-ftrack-macro-expansion=0 -m32 t.c ; done)
+ cat t.c
#define DIFF_MAX __PTRDIFF_MAX__
#define DIFF_MIN (-DIFF_MAX - 1)

void f (int);

void g (unsigned m, unsigned n)
{
  char a[m][n];

  f (a[0][DIFF_MAX]); 
}

+ for i in 1 2 3
+ gcc -O2 -S -Warray-bounds -ftrack-macro-expansion=0 -m32 t.c
t.c: In function ‘g’:
t.c:10:10: warning: array subscript 2147483647 is above array bounds of
‘char[ + 1]’ [-Warray-bounds]
   10 |   f (a[0][DIFF_MAX]);
  |  ^~
+ for i in 1 2 3
+ gcc -O2 -S -Warray-bounds -ftrack-macro-expansion=0 -m32 t.c
+ for i in 1 2 3
+ gcc -O2 -S -Warray-bounds -ftrack-macro-expansion=0 -m32 t.c
$

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-05
 Ever confirmed|0   |1

--- Comment #5 from Peter Bergner  ---
Actually, I got it to ICE.  I had to add -fstack-protector-strong to my
options, which your compile was adding automatically due to your configure
options.  I'll have a look.

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

[doko at debian dot org]

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

--- Comment #4 from Matthias Klose  ---
the revision always is the one from the LAST_UPDATED file.

This was a build on Ubuntu, which has more hardening flags enabled by default. 
I'll recheck with a build on Debian unstable.

[Bug c/92833] ice for broken C code

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-05
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #3 from Segher Boessenkool  ---
Hi!

I cannot reproduce it, and neither can Peter.  What are we missing?

That revision cannot be correct, btw, it doesn't touch any file involved
in this build.

[Bug c/87488] hyperlink filenames in diagnostics

[egmont at gmail dot com]

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

--- Comment #16 from Egmont Koblinger  ---
(In reply to Tobias Burnus from comment #13)

> but using KDE Konsole, the warnings now have:
> 
>warning: control reaches end of non-void function [\-Wreturn-type\]
> 
> That is: There are spurious \ in the output.

This has recently been fixed and is going to be released in konsole 19.12. See
https://bugs.kde.org/show_bug.cgi?id=231405 for details.

I don't know when gcc 10 planned to be released, but if later than that then
very few users will hit this bug (and as far as I understand, they can still
disable this formatting in gcc, correct?).

> The quoted reference [...] but not stating what ST exactly is.

Please read that reference again carefully, it _does_ state what ST is. ECMA-48
also states what it is, and states it as the only terminator for an OSC
(section 8.3.89).

Contrary, BEL is a nonstandard extension.

That's why the OSC 8 spec also uses ST.

> Assuming there is no (known) downside

There is no practical downside I'm aware of, except that you would switch from
the official standard solution to an unofficial nonstandard one.

Should you do it in order to workaround a terminal emulator which failed to fix
this bug for 9.5 years after it was reported? Or should you comply with the
standards and blame them for this mistake? Your call.

[Bug c/92833] New: ice for broken C code

[dcb314 at hotmail dot com]

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

Bug ID: 92833
   Summary: ice for broken C code
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this list of C tokens:

 char
 <<
 <<
 <<

recent gcc trunk deals with it in a less than tidy fashion:

destDir/crash0.c:2:2: error: expected identifier or ‘(’ before ‘<<’ token
2 |  <<
  |  ^~
destDir/crash0.c:4:2: internal compiler error: Segmentation fault
4 |  <<
  |  ^~
0xeaa5a7 crash_signal
../../trunk/gcc/toplev.c:328
0x1994284 _cpp_lex_direct
../../trunk/libcpp/lex.c:2725
0x1995cc0 _cpp_lex_token
../../trunk/libcpp/lex.c:2608
0x199fc47 cpp_get_token_1
../../trunk/libcpp/macro.c:2707

[Bug c++/92831] CWG1299 extend_ref_init_temps_1 punts on COND_EXPRs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-05
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c/87488] hyperlink filenames in diagnostics

[dmalcolm at gcc dot gnu.org]

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

--- Comment #15 from David Malcolm  ---
I guess the other thing to test it on is on older gnome terminals that predate
the support - but I don't have one handy.

[Bug c/87488] hyperlink filenames in diagnostics

[dmalcolm at gcc dot gnu.org]

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

--- Comment #14 from David Malcolm  ---
Thanks.

systemd also uses '\a':
  https://github.com/systemd/systemd/blob/master/src/shared/pretty-print.c#L53
n = strjoin("\x1B]8;;", url, "\a", text, "\x1B]8;;\a");

I didn't see your update to this BZ after our discussion on IRC, and
independently came up with the same patch as your one in comment #13, so I
think that's the right approach.

Shall I go ahead and bootstrap/test/commit the patch, or do you want to?

[Bug bootstrap/92832] New: valgrind error in incorporate_penalties

[dcb314 at hotmail dot com]

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

Bug ID: 92832
   Summary: valgrind error in incorporate_penalties
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just tried a valgrind build of gcc revision 279000 and got this:

==2020328== Conditional jump or move depends on uninitialised value(s)
==2020328==at 0x1488041: incorporate_penalties (ipa-cp.c:3174)
==2020328==by 0x1488041: good_cloning_opportunity_p(cgraph_node*, int, int,
profile_count, int) (ipa-cp.c:3230)
==2020328==by 0x14929CA: bool decide_about_value(cgraph_node*,
int, long, ipcp_value*, vec,
vec) (ipa-cp.c:5327)
==2020328==by 0x1494494: decide_whether_version_node (ipa-cp.c:5397)

svn blame says

278893   fxue   if (info->node_within_scc && !info->node_is_self_scc)

Configure script is

../trunk/configure --prefix=/home/dcb/gcc/results.279000.valgrind \
--disable-bootstrap \
--disable-multilib \
--disable-werror \
--enable-checking=valgrind \
--enable-languages=c,c++,fortran

sed 's/-O2/-O3/' < Makefile > Makefile.tmp
mv Makefile.tmp Makefile

[Bug c++/92831] CWG1299 extend_ref_init_temps_1 punts on COND_EXPRs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
Summary|extend_ref_init_temps_1 |CWG1299
   |punts on COND_EXPRs |extend_ref_init_temps_1
   ||punts on COND_EXPRs

--- Comment #1 from Jakub Jelinek  ---
Seems this is http://wg21.link/p0727 aka CWG 1299.

[Bug c++/92831] New: extend_ref_init_temps_1 punts on COND_EXPRs

[jakub at gcc dot gnu.org]

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

Bug ID: 92831
   Summary: extend_ref_init_temps_1 punts on COND_EXPRs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

http://eel.is/c++draft/class.temporary#6.7
says that even ?: second and third operands need to be handled, but short
testcase modified from the standard one:
template using id = T;

int i = 1;
int&& a = id{1, 2, 3}[i];   // temporary array has same
lifetime as a
const int& b = static_cast(0);  // temporary int has same lifetime
as b
int&& c = cond ? id{1, 2, 3}[i] : static_cast(0);
// exactly one of the two
temporaries is lifetime-extended
like:
template using id = T;
struct S { S () { s++; } ~S () { s--; } S (int) { s++; } static int s; };
int S::s = 0;

void
bar (bool cond)
{
  if (S::s != (cond ? 7 : 5))
__builtin_abort ();
}

void
foo (bool cond)
{
  int i = 1;
  // temporary array has same lifetime as a
  S&& a = id{1, 2, 3}[i];
  // temporary S has same lifetime as b
  const S& b = static_cast(0);
  // exactly one of the two temporaries is lifetime-extended
  S&& c = cond ? id{1, 2, 3}[i] : static_cast(0);
  bar (cond);
}

int
main ()
{
  foo (true);
  foo (false);
}

fails with g++ and succeeds with clang++.

[Bug middle-end/92830] New: -fdiagnostics-url shows the wrong URL for warnings which are not in 'gcc' but e.g. in 'gfortran'

[burnus at gcc dot gnu.org]

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

Bug ID: 92830
   Summary: -fdiagnostics-url shows the wrong URL for warnings
which are not in 'gcc' but e.g. in 'gfortran'
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Cf. also PR 87488

Create a file 'test.f90' with:
!---
print *, "Hello &
   world"
end
!---

And run it:  gfortran -Wall test.f90

This will show:

Warning: Missing ‘&’ in continued character constant at (1) [-Wampersand]

With the link:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wampersand

However, that's the wrong file. The correct link is:
https://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html#index-Wampersand

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #6 from Ian Lance Taylor  ---
Hopefully fixed.  Let me know if not.

[Bug c/87488] hyperlink filenames in diagnostics

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #13 from Tobias Burnus  ---
While this works with xterm (ignored) and gnome-terminal (shows hyperlink), 
but using KDE Konsole, the warnings now have:

   warning: control reaches end of non-void function [\-Wreturn-type\]

That is: There are spurious \ in the output. Looking at the output of
Coreutil's 'ls --hyperlink', they use  \a  instead of  \033\

I don't know whether there is a downside, but it seems to work fine.

The quoted reference (second link below or comment above pp_begin_url) states:
   >  OSC 8 ; params ; URI ST
at the beginning and
   > OSC 8 ; ; ST
but not stating what ST exactly is.

Cross references:

* Coreutils: https://bugzilla.gnome.org/show_bug.cgi?id=779734 – they use '\a'
from the beginning w/o discussion
* https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda - this web
page suggests \033\
* KDE Konsole - no intention to implement it, cf.
  https://bugs.kde.org/show_bug.cgi?id=379294


Assuming there is no (known) downside, I suggest to apply the patch:

diff --git a/gcc/pretty-print.c b/gcc/pretty-print.c
index c57a3dbd887..032baad0146 100644
--- a/gcc/pretty-print.c
+++ b/gcc/pretty-print.c
@@ -2052,7 +2052,7 @@ void
 pp_begin_url (pretty_printer *pp, const char *url)
 {
   if (pp->show_urls)
-pp_printf (pp, "\33]8;;%s\33\\", url);
+pp_printf (pp, "\33]8;;%s\a", url);
 }

 /* If URL-printing is enabled, write a "close URL" escape sequence to PP.  */
@@ -2061,7 +2061,7 @@ void
 pp_end_url (pretty_printer *pp)
 {
   if (pp->show_urls)
-pp_string (pp, "\33]8;;\33\\");
+pp_string (pp, "\33]8;;\a");
 }

 #if CHECKING_P
@@ -2369,7 +2369,7 @@ test_urls ()
 pp_begin_url (&pp, "http://example.com";);
 pp_string (&pp, "This is a link");
 pp_end_url (&pp);
-ASSERT_STREQ ("\33]8;;http://example.com\33\\This is a link\33]8;;\33\\",
+ASSERT_STREQ ("\33]8;;http://example.com\aThis is a link\33]8;;\a",
  pp_formatted_text (&pp));
   }
 }

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

[ian at gcc dot gnu.org]

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

--- Comment #5 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Dec  5 17:51:10 2019
New Revision: 279010

URL: https://gcc.gnu.org/viewcvs?rev=279010&root=gcc&view=rev
Log:
PR go/92820
runtime: always mark assembly file as non-executable stack

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/210037

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/libgo/runtime/go-context.S

[Bug c/92826] Impossible to silence warning: non-standard suffix on floating constant [-Wpedantic]

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
TS 18661-3 has been accepted in principle for C2x, but no-one has done the 
editing work needed to get it into the (LaTeX) form needed to add as an 
Annex to the C standard.  Once that's in, I'll update GCC so that uses of 
_Float128 and the "f128" constant suffix will no longer be rejected with 
-std=c2x (or -std=gnu2x) -Wpedantic (but the "q" suffix will continue to 
be diagnosed).

[Bug testsuite/92829] [10 regression] several test case failures starting with r278983

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-05
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c/92826] Impossible to silence warning: non-standard suffix on floating constant [-Wpedantic]

[kim.walisch at gmail dot com]

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

--- Comment #3 from kim.walisch at gmail dot com ---
> I thought the name "pedantic" made it clear that it is going to warn about 
> things that are just fine, and you shouldn't use it...

A large number of projects (including mine) run automated tests using "-Wall
-Wextra -Wpedantic -Werror" and treat warnings as errors. This is why I
currently don't enable __float128 by default in my projects.

Before C++11 "long long" used to be a non standard type and GCC would print
warnings when using "long long". However GCC had an option (-Wno-long-long) to
turn these warnings off . For me the current __float128 warnings are similar to
the -Wlong-long warnings and so there should also be an option to turn these
warnings off.

And by the way, here is the disgusting hack the boost math library uses to get
rid of this warning. (And I am not even sure it works because there are people
complaining about this warning from the boost mast library on stack-overflow.)

#if defined(__GNUC__) && defined(BOOST_MATH_USE_FLOAT128)
//
// This is the only way we can avoid
// warning: non-standard suffix on floating constant [-Wpedantic]
// when building with -Wall -pedantic.  Neither __extension__
// nor #pragma dianostic ignored work :(
//
#pragma GCC system_header
#endif

https://www.boost.org/doc/libs/develop/boost/math/special_functions/lambert_w.hpp

[Bug testsuite/92829] [10 regression] several test case failures starting with r278983

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Target||powerpc64*
   Host||powerpc64*
  Build||powerpc64*

--- Comment #1 from Martin Sebor  ---
Confirmed on powerpc64le-unknown-linux-gnu:
https://gcc.gnu.org/ml/gcc-testresults/2019-12/msg00249.html
and powerpc64-unknown-linux-gnu
https://gcc.gnu.org/ml/gcc-testresults/2019-12/msg00248.html
but not on other targets.

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

[doko at debian dot org]

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

--- Comment #2 from Matthias Klose  ---
r278994

[Bug rtl-optimization/92796] [10 Regression] ICE in lra_assign, at lra-assigns.c:1646 on powerpc64le-linux-gnu

[doko at debian dot org]

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

--- Comment #1 from Matthias Klose  ---
$ cat acosq.i
typedef int a;
__ieee128 b();
typedef union {
  __ieee128 c;
  struct {
int d;
  } e;
} f;
__ieee128 acosq(__ieee128 g) {
  __ieee128 h, i, j, k, l, m, n, o;
  a ix, p;
  f q;
  q.c = g;
  ix = q.e.d & 5;
  q.e.d = ix;
  if (ix)
return g - g;
  { 
k = h = k * n;
i = i;
if (p)
  i = l;
m = b();
o = m;
j = q.c * o;
return j;
  }
}

$ /home/ubuntu/gcc/gcc-10-10-20191205/build/./gcc/xgcc
-B/home/ubuntu/gcc/gcc-10-10-20191205/build/gcc/
-B/usr/powerpc64le-linux-gnu/bin/ -B/usr/powerpc64le-linux-gnu/lib/ -Wall
-fchecking=1 -g -O2 -c acosq.i -fPIC acosq.i
during RTL pass: reload
acosq.i: In function 'acosq':
acosq.i:28:1: internal compiler error: in lra_assign, at lra-assigns.c:1646
   28 | }
  | ^
0x1066683b lra_assign(bool&)
../../src/gcc/lra-assigns.c:1646
0x1065f893 lra(_IO_FILE*)
../../src/gcc/lra.c:2487
0x1060499b do_reload
../../src/gcc/ira.c:5518
0x1060499b execute
../../src/gcc/ira.c:5704
Please submit a full bug report,
with preprocessed source if appropriate.

GCC configured with 
 --enable-languages=c,c++,go,d,fortran,objc,obj-c++
 --prefix=/usr
 --with-gcc-major-version-only
 --program-suffix=-10
 --program-prefix=powerpc64le-linux-gnu-
 --enable-shared
 --enable-linker-build-id
 --libexecdir=/usr/lib
 --without-included-gettext
 --enable-threads=posix
 --libdir=/usr/lib
 --enable-nls
 --enable-clocale=gnu
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=new
 --enable-gnu-unique-object
 --enable-plugin
 --enable-default-pie
 --with-system-zlib
 --disable-libphobos
 --enable-objc-gc=auto
 --enable-secureplt
 --with-cpu=power8
 --enable-targets=powerpcle-linux
 --disable-multilib
 --enable-multiarch
 --disable-werror
 --with-long-double-128
 --enable-offload-targets=nvptx-none
 --without-cuda-driver
 --enable-checking=release
 --build=powerpc64le-linux-gnu
 --host=powerpc64le-linux-gnu
 --target=powerpc64le-linux-gnu

[Bug bootstrap/92828] array out of bounds access in libcpp/mkdeps.c

[krebbel at gcc dot gnu.org]

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

--- Comment #4 from Andreas Krebbel  ---
(In reply to Andrew Pinski from comment #3)
> Are you saying the warning shows up which causes the bootstrap to fail?
> Because at runtime there should be no out of bounds access.

Yes. It is just the warning.

With an unknown value of d->vpath[i].len GCC cannot determine what the outcome
of the / check will be:

const char *p = t + d->vpath[i].len;
if (!IS_DIR_SEPARATOR (*p))
   goto not_this_one;

[Bug bootstrap/92828] array out of bounds access in libcpp/mkdeps.c

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Are you saying the warning shows up which causes the bootstrap to fail?
Because at runtime there should be no out of bounds access.

[Bug c/92826] Impossible to silence warning: non-standard suffix on floating constant [-Wpedantic]

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
I thought the name "pedantic" made it clear that it is going to warn about
things that are just fine, and you shouldn't use it...
You can disable the warning by inserting __extension__ in your code. It might
be a good idea for quadmath.h to use __extension__ in its macro definitions. Or
the warning could check if the code actually lies in a system header, as so
many other warnings do.

[Bug c/92826] Impossible to silence warning: non-standard suffix on floating constant [-Wpedantic]

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I think this is a duplicate of an existing bug.

[Bug bootstrap/92828] array out of bounds access in libcpp/mkdeps.c

[krebbel at gcc dot gnu.org]

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

--- Comment #2 from Andreas Krebbel  ---
Created attachment 47430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47430&action=edit
reduced testcase

on x86_64:
cc1plus -quiet  -O2 t.cc -Wall --param max-inline-insns-auto=80

t.cc: In function 'void deps_add_default_target(mkdeps*, const char*)':
t.cc:47:24: warning: array subscript 2 is outside array bounds of 'const char
[2]' [-Warray-bounds]
   47 |  if (p[1] == '.' && p[2] == '.' && (((p[3]) == '/') || (((p[3]) ==
'\\') && (0goto not_this_one;
  | ~~~^
t.cc:47:42: warning: array subscript 3 is outside array bounds of 'const char
[2]' [-Warray-bounds]
   47 |  if (p[1] == '.' && p[2] == '.' && (((p[3]) == '/') || (((p[3]) ==
'\\') && (0goto not_this_one;
  |  ^~

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

[doko at debian dot org]

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

--- Comment #4 from Matthias Klose  ---
these are the architectures I see this:
i686-linux-gnu, s390x-linux-gnu, arm-linux-gnueabihf, arm-linux-gnueabi,
alpha-linux-gnu, powerpc-linux-gnu, sparc64-linux-gnu, sh4-linux-gnu

[Bug c++/92746] [10 Regression] ICE in check_noexcept_r, at cp/except.c:1114

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Started with r278775.

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor  ---
What architectures do you see it on?  Do we just need to move the
.section.note.GNU-stack,"",@progbits
in runtime/go-context.S out of the #ifdef?

[Bug bootstrap/92828] array out of bounds access in libcpp/mkdeps.c

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build

--- Comment #1 from Andrew Pinski  ---
I don't see how this will produce an out of bounds.
So we start out with:
checking if t[d->vpath[i].len] == '/'
then we check for t[d->vpath[i].len+1] == '.' and then t[d->vpath[i].len+2] ==
'.' and then t[d->vpath[i].len+3] == '/' .

None of that could cause an out of bounds for a string of "-" in the first
place.
mainly because of this:
filename_ncmp (d->vpath[i].str, t, d->vpath[i].len) //just strncmp

So some check of out of bounds (unconditional one at that) is going incorrectly
wrong.

[Bug testsuite/92829] New: [10 regression] several test case failures starting with r278983

[seurer at gcc dot gnu.org]

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

Bug ID: 92829
   Summary: [10 regression] several test case failures starting
with r278983
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Some of the new test cases in the revision do not test cleanly and one old test
also now fails:

FAIL: g++.dg/warn/Wstringop-overflow-4.C  -std=gnu++14  (test for warnings,
line 117)
FAIL: g++.dg/warn/Wstringop-overflow-4.C  -std=gnu++17  (test for warnings,
line 117)
FAIL: g++.dg/warn/Wstringop-overflow-4.C  -std=gnu++2a  (test for warnings,
line 117)
FAIL: g++.dg/warn/Wstringop-overflow-4.C  -std=gnu++98  (test for warnings,
line 117)
FAIL: gcc.dg/Warray-bounds-56.c  (test for warnings, line 82)
FAIL: gcc.dg/Wstringop-overflow-25.c  (test for warnings, line 317)
FAIL: gcc.dg/Wstringop-overflow-25.c  (test for warnings, line 318)
FAIL: gcc.dg/Wstringop-overflow-25.c  (test for warnings, line 319)

Details on one of the new failures:

Executing on host:
/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++8/../../xg++
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++8/../../
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -nostdinc++
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=gnu++98 -O2 -Wall -Wno-array-bounds -ftrack-macro-expansion=0  -S -o
Wstringop-overflow-4.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++8/../../xg++
-B/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++8/../../
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -O2 -Wall -Wno-array-bounds -ftrack-macro-expansion=0 -S -o
Wstringop-overflow-4.s
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C: In
function 'void test_strcpy_new_char(size_t)':
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:32:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 2 bytes into a region of size 1 overflows the destination
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:36:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 3 bytes into a region of size 2 overflows the destination
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:40:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 4 bytes into a region of size 3 overflows the destination
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:41:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 10 bytes into a region of size 3 overflows the destination
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C: In
function 'void test_strcpy_new_char_array(size_t)':
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:86:3:
warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:91:3:
warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:89:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 3 bytes into a region of size 2 overflows the destination
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:95:3:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
writing 5 bytes into a region of size 4 overflows the destination
[-Wstringop-overflow=]
/home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/warn/Wstringop-overflow-4.C:81:3:
warning: 'void* __builtin_mem

[Bug bootstrap/92828] New: array out of bounds access in libcpp/mkdeps.c

[krebbel at gcc dot gnu.org]

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

Bug ID: 92828
   Summary: array out of bounds access in libcpp/mkdeps.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

/* If T begins with any of the partial pathnames listed in d->vpathv,
   then advance T to point beyond that pathname.  */
static const char *
apply_vpath (class mkdeps *d, const char *t)
{
  if (unsigned len = d->vpath.size ())
for (unsigned i = len; i--;)
  {
if (!filename_ncmp (d->vpath[i].str, t, d->vpath[i].len))
  {
const char *p = t + d->vpath[i].len;
if (!IS_DIR_SEPARATOR (*p))
  goto not_this_one;

/* Do not simplify $(vpath)/../whatever.  ??? Might not
   be necessary. */
if (p[1] == '.' && p[2] == '.' && IS_DIR_SEPARATOR (p[3]))
  goto not_this_one;
...

The last check causes

error: array subscript 2 is outside array bounds of ‘const char [2]’

if apply_vpath gets inlined into deps_add_target and deps_add_target gets
inlined into:

void
deps_add_default_target (class mkdeps *d, const char *tgt)
{
  /* Only if we have no targets.  */
  if (d->targets.size ())
return;

  if (tgt[0] == '\0')
{
  __builtin_trap ();
  deps_add_target (d, "-", 1);
}
...


This unfortunately triggers a bootstrap fail on IBM Z when using
--with-arch=z13 at configure time. For z13 we bump the inlining threshold so
that the inlining described above actually happens.

The right fix appears to be passing the length of the buffer along with the
buffer itself. Alternatively it might also be ok to just remove the check as
the comment above it suggests.

[Bug target/92821] Miscompilation when passing 8-bit enum to extern function

[emilio at crisal dot io]

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

Emilio Cobos Álvarez (:emilio)  changed:

   What|Removed |Added

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

--- Comment #10 from Emilio Cobos Álvarez (:emilio)  
---
(In reply to Jakub Jelinek from comment #9)
> What really matters is what does the psABI say, and as you can see above
> clarified from one of the ABI authors, there is intentionally no zero or
> sign extension of shorter arguments.
> So LLVM has a bug and that bug should be fixed in there, not worked around
> in other compilers.

Well, we do make changes in Gecko to improve interop with other browser engines
even when the spec doesn't explicitly specify a given behavior... But yeah, I
totally get that, and I hate when we have to do that too. It was worth a shot
though :)

At this point I guess this should be closed as invalid, unless someone or
further evidence shows there's something to fix in GCC.

Thanks for all your work in GCC :)

[Bug target/92821] Miscompilation when passing 8-bit enum to extern function

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)
> Another point that someone made in the Mozilla bug tracker is that the ABI,
> in the "Scalar Types" table, specifies that enums are represented as a
> `signed fourbyte`.

It doesn't apply to typed enums nor normal enums that don't fit into the 4
bytes, such as enum E { -9223372036854775807LL, 9223372036854775807LL }; etc.
typed enums have a fixed underlying type and that is what they use, in your
case uint8_t.

> I'm not sure that applies to typed enums. But just in case, if it does, the
> ABI may require sign/zero-extending these too?
> 
> Looking at https://bugs.llvm.org/show_bug.cgi?id=12207, which might be a
> dupe of the LLVM bug I just filed, doesn't make me very hopeful of LLVM
> changing their behavior here.

What really matters is what does the psABI say, and as you can see above
clarified from one of the ABI authors, there is intentionally no zero or sign
extension of shorter arguments.
So LLVM has a bug and that bug should be fixed in there, not worked around in
other compilers.

[Bug libgomp/92827] New: Missing data/state sharing/propagation between host and offloading devices

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92827
   Summary: Missing data/state sharing/propagation between host
and offloading devices
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

An issue known for a long time, now finally put into a PR.

We're currently missing data/state sharing/propagation between host and
offloading devices, which can lead to inconsistencies in behavior, and other
surprises.  In particular, this concerns the state kept by all involved runtime
libraries, such as libgomp itself, libgfortran, libc/libm.

At process creation time, no constructors etc. are executed for offload devices
to initialize the respective runtime libraries' state, so these run with
uninitialized state, and we're lucky that this is doing reasonable things most
of the time.

---

For example,
:

On 2018-12-12T14:00:18+0100, Thomas Schwinge  wrote:
> On Wed, 12 Dec 2018 10:36:17 +0100, Jakub Jelinek  wrote:
>> Eventually we need to find a way how to transfer some ICVs and other data
>> from the host to the offloading library, either process shared that aren't
>> changing, which can include the hostname, getpid, or some others that would
>> need to be passed for every target region.
>
> That would probably also include any state that the respective language
> runtime libraries maintain?  For example, C's global rounding mode as set
> my "fesetround".  ..., and I now wonder how to propagate that from the
> host libc to the target libcs, for example host: glibc vs. nvptx
> offloading: newlib -- have to do a host-side "fegetround" before each
> offloaded code region, or at least when there's been an intermediate
> host-side "fesetround" call (so have to track these?), and likewise for
> any other such state-changing functions?  Also, the "options" array and
> call of "_gfortran_set_options" that the Fortran front end synthesizes
> into each "main" function?

Or,
:

On 2019-12-05T09:44:26+0100, Tobias Burnus  wrote:
> +! In gfortran's main program, libfortran's set_options is called - which sets
> +! compiler_options.backtrace = 1 by default.  For an offload libgfortran, 
> this
> +! is never called and, hence, "Error termination." is never printed.  Thus:
> +! { dg-output "Error termination.*" { target { ! { 
> openacc_nvidia_accel_selected || openacc_amdgcn_accel_selected } } } }

---

Probably the first task is to run any such constructors/setup on the offload
devices at all, and another task then is to keep state synchronized between
host and offload devices.

[Bug target/92821] Miscompilation when passing 8-bit enum to extern function

[emilio at crisal dot io]

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

--- Comment #8 from Emilio Cobos Álvarez (:emilio)  ---
(In reply to Jakub Jelinek from comment #6)
> Note that for most types one ends up with zero or sign extension already due
> to C/C++ promotion rules, though in the ABI still can't use that as
> guarantee, but C++ typed enums aren't promoted.

I see.

Another point that someone made in the Mozilla bug tracker is that the ABI, in
the "Scalar Types" table, specifies that enums are represented as a `signed
fourbyte`.

I'm not sure that applies to typed enums. But just in case, if it does, the ABI
may require sign/zero-extending these too?

Looking at https://bugs.llvm.org/show_bug.cgi?id=12207, which might be a dupe
of the LLVM bug I just filed, doesn't make me very hopeful of LLVM changing
their behavior here.

Would it make sense to make gcc always zero/sign-extend on the caller, even if
not required by the ABI or the language? This makes a bunch of calls from gcc
to llvm-compiled binaries potentially unsafe.

[Bug c/92826] New: Impossible to silence warning: non-standard suffix on floating constant [-Wpedantic]

[kim.walisch at gmail dot com]

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

Bug ID: 92826
   Summary: Impossible to silence warning: non-standard suffix on
floating constant [-Wpedantic]
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kim.walisch at gmail dot com
  Target Milestone: ---

Created attachment 47429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47429&action=edit
Causes warning when compiled using -Wpedantic

Hi,

GCC warns when using the Q suffix for __float128 constants and compiling using
-Wpedantic:

int main()
{
if (1.0Q > 0)
return 0;
else
return 1;
}

$ gcc -Wpedantic test.c -o test
test.c: In function ‘main’:
test.c:3:2: warning: non-standard suffix on floating constant [-Wpedantic]
  if (1.0Q > 0)
  ^~

GCC even warns when using constants defined as macros from the 
system header.

#include 

int main()
{
if (1.0 > FLT128_MIN)
return 0;
else
return 1;
}

$ gcc -Wpedantic test.c -o test
test.c: In function ‘main’:
test.c:5:5: warning: non-standard suffix on floating constant [-Wpedantic]
 if (1.0 > FLT128_MIN)

GCC should definitely not warn when using constants from . GCC
should also provide an option to disable these warnings (e.g.
-Wno-non-standard-suffix). People are currently using disgusting hacks to avoid
these warnings so please add an option for that.

[Bug target/92821] Miscompilation when passing 8-bit enum to extern function

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Related links:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46942
https://groups.google.com/forum/?hl=en#!topic/x86-64-abi/E8O33onbnGQ

[Bug target/92821] Miscompilation when passing 8-bit enum to extern function

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Note that for most types one ends up with zero or sign extension already due to
C/C++ promotion rules, though in the ABI still can't use that as guarantee, but
C++ typed enums aren't promoted.

[Bug tree-optimization/92825] Unnecesary stack protection and missed SLP vectorization in Firefox's LightPixel.

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-05
 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
The stack protection in there is because the expansion sees the color variable
(not optimized away) in there and that variable's type contains arrays.
I guess this boils down to:
int
foo (int r, int g, int b)
{
  union U { int rgba; char p[4]; } u;
  u.p[0] = r;
  u.p[1] = g;
  u.p[2] = b;
  u.p[3] = -1;
  return u.rgba;
}

While stack_vars_num is 0 here, we don't force u into memory, it gets assigned
a pseudo instead, stack protection is still forced because of
stack_protect_decl_p function.
Now, why it is done this way rather than only do such checks on the vars we
force into memory, like moving the stack_protect_decl_p call from where it is
currently to around:
  /* If stack protection is enabled, we don't share space between
 vulnerable data and non-vulnerable data.  */
  if (flag_stack_protect != 0
  && (flag_stack_protect != SPCT_FLAG_EXPLICIT
  || (flag_stack_protect == SPCT_FLAG_EXPLICIT
  && lookup_attribute ("stack_protect",
   DECL_ATTRIBUTES
(current_function_decl)
add_stack_protection_conflicts ();
and iterate on stack_vars[0].decl ... stack_vars[stack_vars_num - 1].decl
instead of
  FOR_EACH_LOCAL_DECL (cfun, i, var)
if (!is_global_var (var))
I have no idea.
We'd instrument fewer functions, sure, but vars that don't really live in
memory shouldn't result in stack overflows.
CCing Jeff as reviewer of the -fstack-protector-strong patches.

Completely untested patch that fixes the short testcase mentioned above:
--- gcc/cfgexpand.c.jj  2019-12-03 20:21:30.542464581 +0100
+++ gcc/cfgexpand.c 2019-12-05 15:19:08.578613685 +0100
@@ -2021,19 +2021,18 @@ static bool
 stack_protect_decl_p ()
 {
   unsigned i;
-  tree var;

-  FOR_EACH_LOCAL_DECL (cfun, i, var)
-if (!is_global_var (var))
-  {
-   tree var_type = TREE_TYPE (var);
-   if (VAR_P (var)
-   && (TREE_CODE (var_type) == ARRAY_TYPE
-   || TREE_ADDRESSABLE (var)
-   || (RECORD_OR_UNION_TYPE_P (var_type)
-   && record_or_union_type_has_array_p (var_type
- return true;
-  }
+  for (i = 0; i < stack_vars_num; i++)
+{
+  tree var = stack_vars[i].decl;
+  tree var_type = TREE_TYPE (var);
+  if (VAR_P (var)
+ && (TREE_CODE (var_type) == ARRAY_TYPE
+ || TREE_ADDRESSABLE (var)
+ || (RECORD_OR_UNION_TYPE_P (var_type)
+ && record_or_union_type_has_array_p (var_type
+   return true;
+}
   return false;
 }

@@ -2103,8 +2102,7 @@ expand_used_vars (void)
 }

   if (flag_stack_protect == SPCT_FLAG_STRONG)
-  gen_stack_protect_signal
-   = stack_protect_decl_p () || stack_protect_return_slot_p ();
+gen_stack_protect_signal = stack_protect_return_slot_p ();

   /* At this point all variables on the local_decls with TREE_USED
  set are not associated with any block scope.  Lay them out.  */
@@ -2180,6 +2178,9 @@ expand_used_vars (void)

   if (stack_vars_num > 0)
 {
+  if (flag_stack_protect == SPCT_FLAG_STRONG)
+   gen_stack_protect_signal |= stack_protect_decl_p ();
+
   add_scope_conflicts ();

   /* If stack protection is enabled, we don't share space between
Of course, pedantically it changes the meaning of -fstack-protector-strong from
variables with arrays to variables with arrays emitted into memory.  Though, we
already don't count variables that are optimized away anyway.
Another question is if we need this stack_protect_decl_p function at all, I
mean, stack_protect_classify_type should already flag those variables as
needing protection and if it doesn't flag any, what is the point when no vars
would be emitted in the area of stack protected variables?

[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants

[rsandifo at gcc dot gnu.org]

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

--- Comment #16 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Thu Dec  5 14:20:38 2019
New Revision: 279002

URL: https://gcc.gnu.org/viewcvs?rev=279002&root=gcc&view=rev
Log:
Check for bitwise identity when encoding VECTOR_CSTs (PR 92768)

This PR shows that we weren't checking for bitwise-identical values
when trying to encode a VECTOR_CST, so -0.0 was treated the same as
0.0 for -fno-signed-zeros.  The patch adds a new OEP flag to select
that behaviour.

2019-12-05  Richard Sandiford  

gcc/
PR middle-end/92768
* tree-core.h (OEP_BITWISE): New flag.
* fold-const.c (operand_compare::operand_equal_p): Handle it.
* tree-vector-builder.h (tree_vector_builder::equal_p): Pass it.

gcc/testsuite/
PR middle-end/92768
* gcc.dg/pr92768.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr92768.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-core.h
trunk/gcc/tree-vector-builder.h

[Bug target/92821] Miscompilation when passing 8-bit enum to extern function

[matz at gcc dot gnu.org]

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

--- Comment #5 from Michael Matz  ---
Yes, we (intentionally) haven't required any extensions to happen for arguments
or return values smaller than 64bit (e.g. we haven't even specified that
arguments <= 32bit would be zero-extended in the high bits, as would have been
natural with the instruction set).  If LLVM relies on that it would be a bug.

[Bug gcov-profile/92817] the prototype of the built-in __gcov_exit function is wrong

[pageexec at gmail dot com]

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

--- Comment #5 from PaX Team  ---
(In reply to Martin Liška from comment #2)
> You are right, it's wrong. Can you please explain to me what control-flow
> integrity check do you use?

it's my own called RAP (Reuse Attack Protector, see
https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf). a public
version for linux (the kernel) is available in PaX and grsecurity though i
think that older version won't find this problem as it didn't handle internal
types like this at the time.

[Bug target/92821] Miscompilation when passing 8-bit enum to extern function

[emilio at crisal dot io]

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

Emilio Cobos Álvarez (:emilio)  changed:

   What|Removed |Added

   See Also||https://bugs.llvm.org/show_
   ||bug.cgi?id=44228

--- Comment #4 from Emilio Cobos Álvarez (:emilio)  ---
I filed https://bugs.llvm.org/show_bug.cgi?id=44228 to get some input from LLVM
folks.

[Bug tree-optimization/92825] New: Unnecesary stack protection and missed SLP vectorization in Firefox's LightPixel.

[hubicka at gcc dot gnu.org]

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

Bug ID: 92825
   Summary: Unnecesary stack protection and missed SLP
vectorization in Firefox's LightPixel.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47428
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47428&action=edit
full testcase

uint32_t DiffuseLightingSoftware::LightPixel(const Point3D& aNormal,
 const Point3D& aVectorToLight,
 uint32_t aColor) {
  Float dotNL = std::max(0.0f, aNormal.DotProduct(aVectorToLight));
  Float diffuseNL = mDiffuseConstant * dotNL;

  union {
uint32_t bgra;
uint8_t components[4];
  } color = {aColor};
  color.components[B8G8R8A8_COMPONENT_BYTEOFFSET_B] = umin(
  uint32_t(diffuseNL * color.components[B8G8R8A8_COMPONENT_BYTEOFFSET_B]),
  255U);
  color.components[B8G8R8A8_COMPONENT_BYTEOFFSET_G] = umin(
  uint32_t(diffuseNL * color.components[B8G8R8A8_COMPONENT_BYTEOFFSET_G]),
  255U);
  color.components[B8G8R8A8_COMPONENT_BYTEOFFSET_R] = umin(
  uint32_t(diffuseNL * color.components[B8G8R8A8_COMPONENT_BYTEOFFSET_R]),
  255U);
  color.components[B8G8R8A8_COMPONENT_BYTEOFFSET_A] = 255;
  return color.bgra;
}

(full testcase attached)
Built with -O3 -fstack-protection-strong results in slower code with gcc10 than
with gcc9 or clang.

GCC produces:
   │ 04390e20  const&,
   │
_ZN7mozilla3gfx12_GLOBAL__N_124SpecularLightingSoftware10LightPixelERKNS0_12Point3DTypedINS0_12UnknownUnitsEfEES7_j():
  0.19 │   push  %rbp
  0.60 │   pxor  %xmm5,%xmm5
  0.05 │   mov   %rsp,%rbp
  0.12 │   push  %rbx
  0.65 │   sub   $0x18,%rsp
  0.33 │   movss 0x4(%rdx),%xmm0
  0.10 │   movss (%rdx),%xmm1
  0.58 │   mov   %fs:0x28,%rax
  0.03 │   mov   %rax,-0x18(%rbp)
  0.22 │   xor   %eax,%eax
  0.07 │   movss pw_32+0x1588,%xmm3
  1.58 │   addss 0x8(%rdx),%xmm3
  0.67 │   addss %xmm5,%xmm0
  0.23 │   addss %xmm5,%xmm1
   │   movaps%xmm0,%xmm2
  0.41 │   movaps%xmm1,%xmm4
  0.87 │   mulss %xmm0,%xmm2
  0.28 │   mulss %xmm1,%xmm4
  3.71 │   addss %xmm2,%xmm4
  0.14 │   movaps%xmm3,%xmm2
  0.04 │   mulss %xmm3,%xmm2
  1.99 │   addss %xmm2,%xmm4
  0.15 │   movss 0x4(%rsi),%xmm2
  9.39 │   sqrtss%xmm4,%xmm4
  8.90 │   divss %xmm4,%xmm0
  2.10 │   divss %xmm4,%xmm3
  1.08 │   mulss %xmm0,%xmm2
  0.01 │   movss 0x8(%rsi),%xmm0

while clang
Percent│
_ZN7mozilla3gfx12_GLOBAL__N_124SpecularLightingSoftware10LightPixelERKNS0_12Point3DTypedINS0_12UnknownUnitsEfEES7_j():
  0.11 │   xorps %xmm0,%xmm0
  0.83 │   movss 0x4(%rdx),%xmm1
  3.29 │   addss %xmm0,%xmm1
  0.03 │   movss (%rdx),%xmm2
  0.08 │   movss 0x8(%rdx),%xmm3
  0.04 │   unpcklps  %xmm2,%xmm3
  0.59 │   movss
mozilla::gfx::ConvertComponentTransferFunctionToFilter(mozilla::gfx::ComponentTransferAttributes
const&, int, int, mozilla::gfx::DrawTarget*, RefPtr

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

[doko at debian dot org]

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

--- Comment #2 from Matthias Klose  ---
I don't see it here on x86_64-linux-gnu, aarch64-linux-gnu,
powerpc64le-linux-gnu.

[Bug target/92821] Miscompilation when passing 8-bit enum to extern function

[emilio at crisal dot io]

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

--- Comment #3 from Emilio Cobos Álvarez (:emilio)  ---
If my reading of https://godbolt.org/z/BNHxEY is correct (sorry, still a bit of
a noob with disassembly), it looks like GCC does correctly load only the low
byte in the equivalent implementation of the Rust function, but clang does
assume zero-extension to 32 bit... :/

[Bug c/92824] New: Wrong optimization: representation of long doubles not copied even with memcpy

[ch3root at openwall dot com]

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

Bug ID: 92824
   Summary: Wrong optimization: representation of long doubles not
copied even with memcpy
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Source code:

--
#include 
#include 

int main()
{
long double x, y;

unsigned char *px = (unsigned char *)&x;
unsigned char *py = (unsigned char *)&y;

// make x pseudo-denormal
x = 0;
px[7] = 0x80;

// set padding
px[10] = 0x80;
px[11] = 0x80;
px[12] = 0x80;
px[13] = 0x80;
px[14] = 0x80;
px[15] = 0x80;

// uncomment if you don't like pseudo-denormals
//memset(&x, 0x80, sizeof x);

y = x;
memcpy(&y, &x, sizeof y);

for (int i = sizeof y; i-- > 0;)
printf("%02x ", py[i]);
printf("\n");
}

--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
80 80 80 80 80 80 00 00 80 00 00 00 00 00 00 00 
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
00 00 00 00 00 00 00 01 80 00 00 00 00 00 00 00 
--

gcc x86-64 version: gcc (GCC) 10.0.0 20191205 (experimental)


Another variation of pr92486 and pr71475. This time on trunk and without
structs. Feel free to close as dup.

There are two issues here:
- padding is not copied;
- if pseudo-denormals are not considered trap representions in gcc, their
non-padding bytes are not preserved too (the exponent is changed from 0 to 1).
(OTOH it seems sNaN in double on x86-32 is not converted to qNaN in such a
situation.)

[Bug tree-optimization/92818] Typo in vec_perm -> bit_insert pattern

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/92823] New: Is that possible to optimize C++ exception??????????? I always HATE 2 phases of exception unwind

[euloanty at live dot com]

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

Bug ID: 92823
   Summary: Is that possible to optimize C++ exception???
I always HATE 2 phases of exception unwind
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: EH
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

This paper shows the possibility of optimizing the current exception model.
Just optimize lippincott function will yield huge benefits.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1676r0.pdf

Here is the proposal of Bjarne Stroustrup:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1947r0.pdf

Same with clang. It also does 2 phase unwinding.

Stroustrup C++ exceptions and alternatives P1947

I think that the current implementations of C++ exception handling are
sub-optimal from a performance
standpoint and could be improved:
• GCC always (even in optimized modes) walks the stack twice to provide better
debug support.
• Implementations use complete RTTI implementations to do type matching
(ostensibly to
simplify use of dynamic linking).
• Cross-function optimizations of exception handling are still rare.
• Special-purpose stack-unwinding and type-matching algorithms are not used for
systems with
special requirements (e.g., with no dynamic linking or tight memories).
• Some exception handling mechanisms cater for generalizations and alternatives
not mandated
by the standard.
• There seem to be no optimization of the original case of passing and catching
simple exceptions
by value. Given final, we can know that a given exception type isn’t the root
of a hierarchy.
• Use of the general free store for all exception objects, rather than
pre-allocated memory for
common and important exceptions as anticipated in the original design.
One reason for the relative poverty of optimizations seems to be that since
exceptions were considered
slow there seemed no reason to optimize them. Thus, exception handling is now
relatively slower than it
was in the 1990s. Other kinds of code have been significantly optimized since
then.
As an example of a missed opportunity, I can mention the Chinese-remainder fast
constant-time type
matching algorithm that I published in 2005 [Gibbs]. For closed systems and
relatively small class
hierarchies (as are increasingly common in embedded systems), this eliminates
almost all of the type
matching cost.
It may also be the case that the table-based implementation approach is
sub-optimal for tiny memories
compared to error-code/stack-marking implementation approaches. The possibility
of special-purpose
implementations of exception handling for special-purpose systems ought to be
explored. The
Edinburgh experiments [Renwick] are encouraging for this direction of
exploration.

[Bug tree-optimization/92818] Typo in vec_perm -> bit_insert pattern

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Thu Dec  5 13:02:57 2019
New Revision: 278998

URL: https://gcc.gnu.org/viewcvs?rev=278998&root=gcc&view=rev
Log:
2019-12-05  Richard Biener  

PR middle-end/92818
* tree-ssa-forwprop.c (simplify_vector_constructor): Improve
heuristics on what don't care element to choose.
* match.pd (VEC_PERM_EXPR -> BIT_INSERT_EXPR): Fix typo.

* gcc.target/i386/pr92818.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr92818.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c

[Bug tree-optimization/92822] New: regressions on aarch64 after r278938

[clyon at gcc dot gnu.org]

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

Bug ID: 92822
   Summary: regressions on aarch64 after r278938
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

After commit r278938, I've noticed regressions on aarch64:

FAIL: gcc.target/aarch64/fmla_intrinsic_1.c scan-assembler-times
fmla\\tv[0-9]+.2s, v[0-9]+.2s, v[0-9]+.2s\\[[0-9]+\\] 2
FAIL: gcc.target/aarch64/fmls_intrinsic_1.c scan-assembler-times
fmls\\tv[0-9]+.2s, v[0-9]+.2s, v[0-9]+.2s\\[[0-9]+\\] 2
FAIL: gcc.target/aarch64/fmul_intrinsic_1.c scan-assembler-times
fmul\\td[0-9]+, d[0-9]+, d[0-9]+ 1
FAIL: gcc.target/aarch64/fmul_intrinsic_1.c scan-assembler-times
fmul\\tv[0-9]+.2d, v[0-9]+.2d, v[0-9]+.d\\[[0-9]+\\] 3
FAIL: gcc.target/aarch64/fmul_intrinsic_1.c scan-assembler-times
fmul\\tv[0-9]+.2s, v[0-9]+.2s, v[0-9]+.s\\[[0-9]+\\] 2
FAIL: gcc.target/aarch64/simd/vmulx_laneq_f32_1.c scan-assembler-times fmulx[
\t]+[vV][0-9]+.2[sS], ?[vV][0-9]+.2[sS], ?[vV][0-9]+.[sS]\\[0\\]\n 1
FAIL: gcc.target/aarch64/simd/vmulx_laneq_f32_1.c scan-assembler-times fmulx[
\t]+[vV][0-9]+.2[sS], ?[vV][0-9]+.2[sS], ?[vV][0-9]+.[sS]\\[1\\]\n 1
FAIL: gcc.target/aarch64/simd/vmulx_laneq_f32_1.c scan-assembler-times fmulx[
\t]+[vV][0-9]+.2[sS], ?[vV][0-9]+.2[sS], ?[vV][0-9]+.[sS]\\[2\\]\n 1
FAIL: gcc.target/aarch64/simd/vmulx_laneq_f32_1.c scan-assembler-times fmulx[
\t]+[vV][0-9]+.2[sS], ?[vV][0-9]+.2[sS], ?[vV][0-9]+.[sS]\\[3\\]\n 1
FAIL: gcc.target/aarch64/simd/vmulx_laneq_f64_1.c scan-assembler-times fmulx[
\t]+[dD][0-9]+, ?[dD][0-9]+, ?[vV][0-9]+.[dD]\\[0\\]\n 1
FAIL: gcc.target/aarch64/simd/vmulx_laneq_f64_1.c scan-assembler-times fmulx[
\t]+[dD][0-9]+, ?[dD][0-9]+, ?[vV][0-9]+.[dD]\\[1\\]\n 1
FAIL: gcc.target/aarch64/singleton_intrinsics_1.c scan-assembler-times
aarch64_get_lanev2di 2

[Bug go/92820] [10 Regression] libgo.so.15 has executable stack

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

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

--- Comment #1 from Andreas Schwab  ---
Don't see that on aarch64 or riscv64.

[Bug target/92821] Miscompilation when passing 8-bit enum to extern function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com,
   ||hubicka at gcc dot gnu.org,
   ||matz at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I believe it is a LLVM bug.
At least, reading
https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-1.0.pdf, I can't find
in the Parameter Passing section anything that would say that arguments smaller
than 64-bit are passed sign or zero extended to 64-bit like some other psABIs
require.  The only related thing is
"When a value of type _Bool is returned or passed in a register or on the
stack,
bit 0 contains the truth value and bits 1 to 7 shall be zero."
with a footnote:
"Other bits are left unspecified, hence the consumer side of those values can
rely on it being 0 or 1 when truncated to 8 bit."
which says that _Bool has only significant low 8 bits and the rest is
unspecified.

[Bug gcov-profile/92817] the prototype of the built-in __gcov_exit function is wrong

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed on trunk, not planning to backport that.

[Bug gcov-profile/92817] the prototype of the built-in __gcov_exit function is wrong

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Thu Dec  5 12:35:26 2019
New Revision: 278995

URL: https://gcc.gnu.org/viewcvs?rev=278995&root=gcc&view=rev
Log:
Fix __gcov_exit fn prototype.

2019-12-05  Martin Liska  

PR gcov-profile/92817
* coverage.c (build_gcov_exit_decl): Remove superfluous
void_type_node.

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

[Bug gcov-profile/92817] the prototype of the built-in __gcov_exit function is wrong

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
> 
> as it is, the builtin-in prototype does not match what one would define in
> source code and this trips up type based control-flow integrity checks.

You are right, it's wrong. Can you please explain to me what control-flow
integrity check do you use?