[Bug c/91664] Undefined reference linker errors when static linking archive with gcc target_clones function multi-versioning

[element at elementsofsound dot org]

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

--- Comment #6 from element at elementsofsound dot org  ---
I removed the internal_func() with the target_clones attribute, which caused
the last number digit of the symbols for fmv_test clones to match up between
object files, but errors still occur. I ran nm on the resulting archive and got
the below output, which may provide a clue. Note that the fmv_test target clone
functions have lower case 't' for local Text and don't end up in the archive
index. I removed the target_clones attribute and fmv_test ends up being a
global Text symbol (also pasted below), which builds fine:

nm -s fmv-test.a
Archive index:
main in main.o
fmv_test in main.o
fmv_test.resolver in main.o
fmv_normal_function in fmv-test.o
fmv_test.resolver in fmv-test.o
fmv_test in fmv-test.o

main.o:
 U __cpu_indicator_init
 U __cpu_model
 i fmv_test
 U fmv_test.avx.1
 U fmv_test.avx2.0
 U fmv_test.default.4
 W fmv_test.resolver
 U fmv_test.sse2.3
 U fmv_test.sse4_1.2
 U _GLOBAL_OFFSET_TABLE_
 T main
 U malloc
 U memset

fmv-test.o:
 U __cpu_indicator_init
 U __cpu_model
004d T fmv_normal_function
 i fmv_test
00a8 t fmv_test.avx.1
005b t fmv_test.avx2.0
 t fmv_test.default.4
 W fmv_test.resolver
0142 t fmv_test.sse2.3
00f5 t fmv_test.sse4_1.2
 U _GLOBAL_OFFSET_TABLE_




This is when fmv_test is defined without target_clones attribute:
Archive index:
main in main.o
fmv_test in fmv-test.o
fmv_normal_function in fmv-test.o

main.o:
 U fmv_test
 U _GLOBAL_OFFSET_TABLE_
 T main
 U malloc
 U memset

fmv-test.o:
004d T fmv_normal_function
 T fmv_test

[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts

[wilson at gcc dot gnu.org]

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

--- Comment #20 from Jim Wilson  ---
Created attachment 46830
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46830&action=edit
proposed patch to fix paradoxical reg in splitter problem

I get better code size with this alternative patch.  I added two more testcases
for the issues I found while evaluating this patch.  There is no change to the
rv32/newlib libc/libstdc++ library code sizes.  The rv64/linux libc.so is now
94 bytes smaller.  The libstdc++.so is 6 bytes larger but text is 10 bytes
smaller and rodata is 16 bytes larger.  I'm not sure what happened there, maybe
alignment padding, but I can live with it.  The text section looks like the
same code, but slightly better register allocation, which allows a few more
compressed instructions to be used.  This has passed rv32/newlib and rv64/linux
cross toolchain build and check.  The new testcase from Jakub still works,
along with my two new testcases.

I tried adding instrumentation to the patch to abort if I ended up with a
paradoxical reg in the splitters, and it never triggered, so it looks like
combine is doing the right thing when allocating a reg for the clobber.

[Bug c/91667] New: bogus -Wformat-overflow warning

[jbeulich at novell dot com]

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

Bug ID: 91667
   Summary: bogus -Wformat-overflow warning
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbeulich at novell dot com
  Target Milestone: ---

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

The attached example causes undue warnings - arrays of  chars without nul
terminator ought to not cause such a warning when the format specifier is
%.s.

Observations:
- requires -O1 or higher
- no warning (as expected) on the one printf() after the loop
- warning disappears with one array element removed (loop gets unrolled in this
case)
- warning disappears when un-commenting the commented out array element

For the full original file the issue was noticed with see
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/tests/cpu-policy/test-cpu-policy.c;h=ca3b8dd45fe18fd809804e8ec2e1a7c8d098c3da;hb=refs/heads/staging

[Bug tree-optimization/91656] [10 Regression] wrong code with -fgcse-after-reload

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
Created attachment 46828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46828&action=edit
testcase for x86_64-pc-linux-gnu

r275271 is OK
r275396 is BAD

$ x86_64-pc-linux-gnu-gcc -O3 testcase.c && ./a.out
Aborted

$ x86_64-pc-linux-gnu-gcc -O3 testcase.c -fno-gcse-after-reload && ./a.out
(finishes correctly)

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-275396-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-275396-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20190905 (experimental) (GCC)

[Bug target/91654] Regressions of SPEC2017 rate caused by r274994

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu  ---
Change cost from 2->6 
got
-
531.deepsjeng_r  9.64% 
548.exchange_r  10.24% 
557.xc_r        7.99%
508.namd_r      1.08%
527.cam4_r      6.91%
553.nab_r      3.06%


for 531,548,557,527, even better comparing to version before regression.
for 508,533, still little regressions comparing to version before regression.

[Bug c/91664] Undefined reference linker errors when static linking archive with gcc target_clones function multi-versioning

[element at elementsofsound dot org]

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

--- Comment #5 from element at elementsofsound dot org  ---
(In reply to Andrew Pinski from comment #3)
> Maybe it is not clear but target_clones is only supposed to be on the
> definition rather just declarations too.

I'm not sure if I understood you exactly. The target_clones attribute is
defined in the header file for the definition of the function (for use by other
.c files). If I add it to the actual function, GCC complains, so I only have it
on the definition. I think that is what you meant.

One thing I have noticed is that when the .c files are compiled as individual
object files, objdump shows that the number at the end of the symbols for the
target clones do not match. However, when linking these object files with gcc
they somehow are resolved. If instead they are placed in an archive, then they
don't resolve. Not sure if this is related. It seems like this has something to
do more with the linking than gcc compilation of the C code. So perhaps my lack
of knowledge led me to file the bug for the wrong component?

See below:
objdump -t fmv-test.o | grep fmv_test
 l F .text  0062 fmv_test.default.9
0239 l F .text  0062 fmv_test.avx2.4
029b l F .text  0062 fmv_test.avx.5
02fd l F .text  0062 fmv_test.sse4_1.6
035f l F .text  0062 fmv_test.sse2.7
 ld  .text.fmv_test.resolver
.text.fmv_test.resolver
03c1 g   i   .text  0080
internal_func._GLOBAL___fmv_test.ifunc
  wF .text.fmv_test.resolver0080
fmv_test.resolver
 g   i   .text.fmv_test.resolver0080 fmv_test

objdump -t main.o | grep fmv_test
 ld  .text.fmv_test.resolver
.text.fmv_test.resolver
 g   i   .text.fmv_test.resolver0080 fmv_test
  wF .text.fmv_test.resolver0080
fmv_test.resolver
 *UND*   fmv_test.avx2.0
 *UND*   fmv_test.avx.1
 *UND*   fmv_test.sse4_1.2
 *UND*   fmv_test.sse2.3
 *UND*   fmv_test.default.4

[Bug c/91664] Undefined reference linker errors when static linking archive with gcc target_clones function multi-versioning

[element at elementsofsound dot org]

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

--- Comment #4 from element at elementsofsound dot org  ---
(In reply to Andrew Pinski from comment #2)
> Try this:
> gcc -c fmv-test.c
> gcc -c main.c
> ar cr fmv-test.a  main.o fmv-test.o
> gcc -o fmv-test-borken fmv-test.a
> 
> It might be because the way linker processes archives and most likely not a
> bug.

I tried changing the order of the .o files in the ar command as shown, but same
errors occurred.

[Bug d/91666] New: _builtin function no work with GDC

[ray_linn at hotmail dot com]

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

Bug ID: 91666
   Summary: _builtin function no work with GDC
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ray_linn at hotmail dot com
  Target Milestone: ---

when compiling libphobos with MinGW-W64, I got the following errors on thread.d

/bin/sh ../libtool --tag=D   --mode=compile /home/alpha/gcc-build/./gcc/gdc
-B/home/alpha/gcc-build/./gcc/ -L/mingw64/x86_64-w64-mingw32/lib
-L/mingw64/mingw/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/mingw/include -B/mingw64/x86_64-w64-mingw32/bin/
-B/mingw64/x86_64-w64-mingw32/lib/ -isystem /mingw64/x86_64-w64-mingw32/include
-isystem /mingw64/x86_64-w64-mingw32/sys-include -O2 -g  -nostdinc -I
../../../../gcc-9.2.0/libphobos/libdruntime -I . -c -o core/thread.lo
../../../../gcc-9.2.0/libphobos/libdruntime/core/thread.d
libtool: compile:  /home/alpha/gcc-build/./gcc/gdc
-B/home/alpha/gcc-build/./gcc/ -L/mingw64/x86_64-w64-mingw32/lib
-L/mingw64/mingw/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/mingw/include -B/mingw64/x86_64-w64-mingw32/bin/
-B/mingw64/x86_64-w64-mingw32/lib/ -isystem /mingw64/x86_64-w64-mingw32/include
-isystem /mingw64/x86_64-w64-mingw32/sys-include -O2 -g -nostdinc -I
../../../../gcc-9.2.0/libphobos/libdruntime -I . -c
../../../../gcc-9.2.0/libphobos/libdruntime/core/thread.d -o core/thread.o
../../../../gcc-9.2.0/libphobos/libdruntime/core/thread.d:2430:13: error:
undefined identifier '__builtin_unwind_init'
 2430 | __builtin_unwind_init();
  | ^
../../../../gcc-9.2.0/libphobos/libdruntime/core/thread.d:3220:16: error:
undefined identifier '__builtin_frame_address'
 3220 | return __builtin_frame_address(0);
  |^
...

it looks' the built-in function does not work here.

[Bug tree-optimization/91665] New: [9/10 Regression] ICE in build_vector_from_val, at tree.c:1904

[asolokha at gmx dot com]

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

Bug ID: 91665
   Summary: [9/10 Regression] ICE in build_vector_from_val, at
tree.c:1904
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20190901 snapshot (r275284) ICEs when compiling the following
testcase w/ -Ofast:

short int u2;

void
nn (short int dv, short int cu)
{
  short int *sz = &u2;

  dv = 1;
  while (dv != 0)
dv += ++cu || (*sz = dv);
}

% gcc-10.0.0-alpha20190901 -Ofast -c xsledmfe.c
during GIMPLE pass: vect
xsledmfe.c: In function 'nn':
xsledmfe.c:4:1: internal compiler error: in build_vector_from_val, at
tree.c:1904
4 | nn (short int dv, short int cu)
  | ^~
0x71589c build_vector_from_val(tree_node*, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190901/work/gcc-10-20190901/gcc/tree.c:1904
0xfb1035 vect_create_epilog_for_reduction
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190901/work/gcc-10-20190901/gcc/tree-vect-loop.c:4666
0xfb8475 vectorizable_reduction(_stmt_vec_info*, gimple_stmt_iterator*,
_stmt_vec_info**, _slp_tree*, _slp_instance*, vec*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190901/work/gcc-10-20190901/gcc/tree-vect-loop.c:7408
0xfa29ee vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190901/work/gcc-10-20190901/gcc/tree-vect-stmts.c:10783
0xfa3bb9 vect_transform_loop_stmt
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190901/work/gcc-10-20190901/gcc/tree-vect-loop.c:8459
0xfa8bc9 vect_transform_loop(_loop_vec_info*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190901/work/gcc-10-20190901/gcc/tree-vect-loop.c:8684
0xfd5cac try_vectorize_loop_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190901/work/gcc-10-20190901/gcc/tree-vectorizer.c:980
0xfd671f vectorize_loops()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190901/work/gcc-10-20190901/gcc/tree-vectorizer.c:1112

gcc 9 fails differently:

% gcc-9.2.0 -Ofast -c xsledmfe.c -fchecking
xsledmfe.c: In function 'nn':
xsledmfe.c:4:1: error: mismatching comparison operand types
4 | nn (short int dv, short int cu)
  | ^~
short int
unsigned short
stmp_u2_lsm.20_78 = stmp_u2_lsm.20_77 == 0 ? u2_lsm.6_5 : stmp_u2_lsm.20_77;
xsledmfe.c:4: confused by earlier errors, bailing out

[Bug c/65403] -Wno-error= is an error

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #14 from Eric Gallager  ---
(In reply to Alex Henrie from comment #13)
> I filled out all the forms and was approved to contribute code to GCC, but
> the patches have still not been reviewed:
> https://gcc.gnu.org/ml/gcc-patches/2019-03/msg00971.html

Latest review comment I can find on a later iteration of that patch series is
here by Martin Sebor: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01892.html

[Bug c/91664] Undefined reference linker errors when static linking archive with gcc target_clones function multi-versioning

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Maybe it is not clear but target_clones is only supposed to be on the
definition rather just declarations too.

[Bug c/91664] Undefined reference linker errors when static linking archive with gcc target_clones function multi-versioning

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-05
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Try this:
gcc -c fmv-test.c
gcc -c main.c
ar cr fmv-test.a  main.o fmv-test.o
gcc -o fmv-test-borken fmv-test.a

It might be because the way linker processes archives and most likely not a
bug.

[Bug c/91664] Undefined reference linker errors when static linking archive with gcc target_clones function multi-versioning

[element at elementsofsound dot org]

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

--- Comment #1 from element at elementsofsound dot org  ---
Created attachment 46827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46827&action=edit
Preprocessed file for main.c

[Bug c/91664] New: Undefined reference linker errors when static linking archive with gcc target_clones function multi-versioning

[element at elementsofsound dot org]

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

Bug ID: 91664
   Summary: Undefined reference linker errors when static linking
archive with gcc target_clones function
multi-versioning
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: element at elementsofsound dot org
  Target Milestone: ---

Created attachment 46826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46826&action=edit
Preprocessed file for fmv-test.c

Target: x86_64-linux-gnu
gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1)

Creating a static library archive with publicly declared functions with
target_clones attribute, causes undefined reference errors to the function
clones when linking the archive into the final application.

I created a test build on github which illustrates this:
https://github.com/elementgreen/fmv-test

Also a stackoverflow question:
https://stackoverflow.com/questions/57798005/how-to-fix-undefined-reference-linker-errors-when-static-linking-archive-with-gc

This test build has 3 different make targets "works", "also_works", and
"borken". The first just builds the executable in one go with .c source files
and -o for the target executable. The second compiles each .c into .o object
files and then links them with gcc -o and the object files. The final make
target compiles each .c into .o files, then creates an archive with ar, and
then links the .a archive into the final executable with gcc -o. The first 2
targets work, the 3rd does not, with the errors:
gcc -c fmv-test.c
gcc -c main.c
ar cr fmv-test.a fmv-test.o main.o
gcc -o fmv-test-borken fmv-test.a
/usr/bin/ld: fmv-test.a(main.o): in function `fmv_test':
main.c:(.text.fmv_test.resolver[fmv_test.resolver]+0x1f): undefined reference
to `fmv_test.avx2.0'
/usr/bin/ld: main.c:(.text.fmv_test.resolver[fmv_test.resolver]+0x3b):
undefined reference to `fmv_test.avx.1'
/usr/bin/ld: main.c:(.text.fmv_test.resolver[fmv_test.resolver]+0x57):
undefined reference to `fmv_test.sse4_1.2'
/usr/bin/ld: main.c:(.text.fmv_test.resolver[fmv_test.resolver]+0x71):
undefined reference to `fmv_test.sse2.3'
/usr/bin/ld: main.c:(.text.fmv_test.resolver[fmv_test.resolver]+0x7a):
undefined reference to `fmv_test.default.4'
collect2: error: ld returned 1 exit status

[Bug fortran/32957] C/Fortran interoperability and -fdefault-integer-8

[egallager at gcc dot gnu.org]

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

--- Comment #9 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #8)
> > So is this fixed now?
> 
> I have spotted some new tests requiring c_int:
> 
> --- ../_clean/gcc/testsuite/gfortran.dg/bind_c_usage_24.f90   2018-02-18
> 00:40:36.0 +0100
> +++ ../p_work/gcc/testsuite/gfortran.dg/bind_c_usage_24.f90   2018-05-12
> 16:01:26.0 +0200
> @@ -30,9 +30,10 @@ contains
>  end module m
>  
>  program test
> +  use iso_c_binding
>use m
>implicit none
> -  integer :: val
> +  integer(c_int) :: val
>  
>val = 4
>call c_proc (.false._c_bool)
> --- ../_clean/gcc/testsuite/gfortran.dg/internal_dummy_4.f08  2018-02-18
> 00:40:40.0 +0100
> +++ ../p_work/gcc/testsuite/gfortran.dg/internal_dummy_4.f08  2018-05-12
> 16:01:29.0 +0200
> @@ -39,11 +39,11 @@ end module test_mod
>  program main
>use test_mod
>implicit none
> -  integer :: a
> +  integer(c_int) :: a
>a = 33
> -  call test_sub (one, a, 7*33)
> +  call test_sub (one, a, 7_c_int*33_c_int)
>a = 23
> -  call test_func(two, a, -123*23)
> +  call test_func(two, a, -123_c_int*23_c_int)
>  contains
>subroutine one(x) bind(c)
>   integer(c_int),intent(inout) :: x

Well, please send this part to the list for review anyways, even if it still
leaves some other parts un-fixed.

> 
> There is also a problem with gfortran.dg/bind_c_usage_10.f03 I have been
> unable to fix:
> 
> /opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:66:31:
> 
>integer(c_int) function func4()
>1
> Error: FUNCTION result func4 can't be of type INTEGER(4) in FUNCTION func4
> at (1)
> /opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:59:31:
> 
>integer(c_int) function func3() bind(c, name="myFunc3")
>1
> Error: FUNCTION result func3 can't be of type INTEGER(4) in FUNCTION func3
> at (1)
> /opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:52:31:
> 
>integer(c_int) function func2()
>1
> Error: FUNCTION result func2 can't be of type INTEGER(4) in FUNCTION func2
> at (1)
> /opt/gcc/_clean/gcc/testsuite/gfortran.dg/bind_c_usage_10.f03:45:31:
> 
>integer(c_int) function func1() bind(c, name="myFunc1")
>1
> Error: FUNCTION result func1 can't be of type INTEGER(4) in FUNCTION func1
> at (1)

[Bug tree-optimization/91663] split function can be re-inlined, leaving bad stack trace

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Thu Sep  5 04:12:30 2019
New Revision: 275396

URL: https://gcc.gnu.org/viewcvs?rev=275396&root=gcc&view=rev
Log:
PR tree-optimization/91663
* go-lang.c (go_langhook_post_options): Clear
flag_partial_inlining.

Modified:
trunk/gcc/go/ChangeLog
trunk/gcc/go/go-lang.c

[Bug tree-optimization/91663] New: split function can be re-inlined, leaving bad stack trace

[ian at airs dot com]

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

Bug ID: 91663
   Summary: split function can be re-inlined, leaving bad stack
trace
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian at airs dot com
  Target Milestone: ---

Test case (this is C code converted from a Go program):

extern void exit (int) __attribute ((__noreturn__));

struct s
{
  int f1;
  unsigned int f2;
};

void
i1 (void *p)
{
}

void quit (const char *) __attribute ((__noreturn__, __noinline__));

void
quit (const char *s)
{
  exit (1);
}

#define c0 1
#define c1 2
#define c2 4

#define c3 3

static void f3 (unsigned int *, int, int) __attribute__ ((__noinline__));

static void
f3 (unsigned int *p, int v, int v2)
{
  quit ("f3");
}

void
f2 (struct s *m, int v)
{
  if (((v + c0) & c0) == 0)
  quit ("fail1");
  if ((v & c2) == 0)
{
  int v2 = v;
lab:
{
  _Bool f = (v2 >> c3) == 0;
  if (! f)
f = (v2 & (c0 | c1 | c2)) != 0;
  if (f)
return;
  v = (v2 - (1 << c3)) | c1;
  if (__atomic_compare_exchange_n (&m->f1, &v2, v, 0,
   __ATOMIC_SEQ_CST,
   __ATOMIC_SEQ_CST) != 0)
{
  f3 (&m->f2, 0, 1);
  return;
}
  v2 = m->f1;
}
goto lab;
}
  else
f3 (&m->f2, 1, 1);
}

void f1 (struct s *) __attribute__ ((__noinline__));

void
f1 (struct s *m)
{
  int v;

  if (0)
i1 ((void*) m);
  v = __atomic_add_fetch (&m->f1, -c0, __ATOMIC_SEQ_CST);
  if (v != 0)
f2 (m, v);
}

int
main ()
{
  struct s m;
  m.f1 = c0 + (1 << c3);
  m.f2 = 0;
  f1 (&m);
}


> gcc -o foo -g -O2 -fno-optimize-sibling-calls foo.c
> gdb ./foo

(gdb) break f3
Breakpoint 1 at 0x4005b0: file /home/iant/foo.c, line 33.
(gdb) r
Starting program: /home/iant/gcc/gccgo4-objdir/foo 

Breakpoint 1, f3 (v2=1, v=0, p=) at /home/iant/foo.c:33
33quit ("f3");
(gdb) where
#0  f3 (v2=1, v=0, p=) at foo.c:33
#1  0x004005ea in f2 (v=, m=)
at foo.c:56
#2  f2 (m=, v=) at foo.c:37
#3  0x00400629 in f1 (m=m@entry=0x7fffe308) at foo.c:78
#4  0x00400497 in main () at foo.c:87


Note how in the stack backtrace f2 appears twice although it does not call
itself.  This appears to be happening because pass_split_functions splits f2
into two functions, f2 and f2.part.0.  Then the ipa-inline pass inlines the
split function back into its single caller.  We are left with a single function
that has debug info showing an inlined call of itself.  gdb prints the
resulting stack trace showing the inlined call, but this doesn't make sense
since there is only one function and one stack frame here.  There is no user
visible inlining.


This happens with GCC 10 (current trunk) but does not happen with GCC 9.

(This causes trouble with the original Go code, because Go expects to be able
to reliably unwind the stack.  In this case there appears to be no marker
letting us know that the inlined call is to a split function that should be
ignored, so Go sees f2 calling itself, leading to incorrect stack unwinding.)

[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts

[wilson at gcc dot gnu.org]

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

--- Comment #19 from Jim Wilson  ---
I did cross toolchain builds and checks for rv32i/newlib and rv64gc/glibc. 
There were no regressions.

Since the splitters exist to reduce code size, I looked at the libc and
libstdc++ sizes with and without the patch.

For the rv32i build, libstdc++ is the same size, and libc is 4 bytes smaller. 
I extracted a testcase.
int
isnanf (float x)
{
  union u { float f; int i; } u;
  u.f = x;
  int i = u.i;
  i &= 0x7fff;
  return i > 0x7f80;
}
Without the patch with -O2 -S we get
sllia0,a0,1
li  a5,2139095040
srlia0,a0,1
sgt a0,a0,a5
ret
with the patch we get
li  a5,-16777216
sllia0,a0,1
sgtua0,a0,a5
ret
The issue here is that the extra temporary used for the splitter that generates
the slli/srli gives combine a little more freedom, and it manages to find an
optimization that was missed before.

For the rv64gc build, libc is 38 bytes smaller and libstdc++ is 34 bytes
larger.  The libc issue appears to be the same as above.  The libstdc++ issue
is more interesting.  I extracted a testcase.
unsigned long
sub (long l)
{
  union u {
struct s { int a : 19; unsigned int b : 13; int x; } s;
long l;
  } u;
  u.l = l;
  return u.s.b;
}
Without the patch, with -O2 -S, we generate
srliw   a0,a0,19
ret
and with the patch we get
srlia0,a0,19
sllia0,a0,51
srlia0,a0,51
ret
The issue here is that there is no REG_DEAD note for the temporary that we
generated. So without the patch combine generates
Successfully matched this instruction:
(set (reg:DI 78)
(zero_extract:DI (reg:DI 82)
(const_int 13 [0xd])
(const_int 19 [0x13])))
and with the patch combine generates
Failed to match this instruction:
(parallel [
(set (reg:DI 78)
(zero_extract:DI (reg:DI 82)
(const_int 13 [0xd])
(const_int 19 [0x13])))
(set (reg:DI 83)
(and:DI (ashift:DI (reg:DI 82)
(const_int 32 [0x20]))
(const_int -2251799813685248 [0xfff8])))
])
where reg 83 is the temporary generated by the splitter which has no REG_DEAD
note.

Since the temporary appears to be generally useful, and lack of a REG_DEAD note
causes problems, I think it would be better to modify the two define_split
patterns to have a clobber instead of calling gen_reg_rtx.  I do get the
REG_DEAD note in this case, and the correct single instruction output for the
second testcase.  The three define_insn_and_split patterns can remain the same
as they aren't causing any trouble.

Though I suppose there is a question here of whether combine will ever
accidentally substitute in a paradoxical reg for a clobber.  I would hope that
it doesn't.  I can check for that.

Since I have a new patch, and new testcases, I need to redo the builds and
checks from scratch.

[Bug c++/91662] New: [concepts] unable to deduce placeholder type, should be accepted

[frederik.engels24 at gmail dot com]

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

Bug ID: 91662
   Summary: [concepts] unable to deduce placeholder type, should
be accepted
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederik.engels24 at gmail dot com
  Target Milestone: ---

The following should compile but doesn't on current gcc-trunk (20190902)
with options: "-std=c++2a -fconcepts"

godbolt: https://godbolt.org/z/3jvFqX

#include 
#include 

template
concept same_as = std::is_same_v && std::is_same_v;

template
concept assignable_from = 
requires(LHS lhs, RHS&& rhs) {
{ lhs = std::forward(rhs) } -> same_as;
};

template T>
void foo(T&& t) {}

int main()
{
int i = 0;
foo(i);
}

with output

: In function 'int main()':

:19:10: error: cannot call function 'void foo(T&&) [with T = int&]'

   19 | foo(i);

  |  ^

:14:6: note:   constraints not satisfied

   14 | void foo(T&& t) {}

  |  ^~~

:8:9: note: within 'template concept const bool
assignable_from [with LHS = int&; RHS = int]'

8 | concept assignable_from =

  | ^~~

:8:9: note: with 'int& lhs'

:8:9: note: with 'int&& rhs'

:8:9: note: unable to deduce placeholder type 'same_as' from 'lhs
=(forward)(rhs)'

ASM generation compiler returned: 1

: In function 'int main()':

:19:10: error: cannot call function 'void foo(T&&) [with T = int&]'

   19 | foo(i);

  |  ^

:14:6: note:   constraints not satisfied

   14 | void foo(T&& t) {}

  |  ^~~

:8:9: note: within 'template concept const bool
assignable_from [with LHS = int&; RHS = int]'

8 | concept assignable_from =

  | ^~~

:8:9: note: with 'int& lhs'

:8:9: note: with 'int&& rhs'

:8:9: note: unable to deduce placeholder type 'same_as' from 'lhs
=(forward)(rhs)'

Execution build compiler returned: 1

[Bug fortran/91660] [8/9/10 Regression] Missing error on invalid type declaration

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from kargl at gcc dot gnu.org ---
Looks like the -fdec junk may have broke this.

[Bug fortran/91660] [8/9/10 Regression] Missing error on invalid type declaration

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-04
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/91650] [10 Regression] ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:370

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed on trunk.

[Bug fortran/91650] [10 Regression] ICE in gfc_conv_constant_to_tree, at fortran/trans-const.c:370

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Sep  4 23:21:12 2019
New Revision: 275391

URL: https://gcc.gnu.org/viewcvs?rev=275391&root=gcc&view=rev
Log:
2019-09-04  Steven G. Kargl  

PR fortran/91650
* io.c (match_io_element):  An output IO list item cannot be a BOZ.

2019-09-04  Steven G. Kargl  

PR fortran/91650
* gfortran.dg/pr91650_1.f90: New test.
* gfortran.dg/pr91650_2.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/pr91650_1.f90
trunk/gcc/testsuite/gfortran.dg/pr91650_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog

[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)

[joseph at codesourcery dot com]

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

--- Comment #16 from joseph at codesourcery dot com  ---
Could you give the testcase you expect to be diagnosed with this option 
with C++ that isn't diagnosed by default?

[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
(In reply to Mikael Slevinsky from comment #10)
> I can confirm this is fixed, thank you!

Great, for which GCC versions is it fixed?

> P.S. the exact processor type is a Xeon(R) W-2191B CPU @ 2.30GHz.

thanks

[Bug libstdc++/41861] [DR 887][C++0x] does not use monotonic_clock

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #20 from Jonathan Wakely  ---
Fixed for GCC 10 by Mike's patches.

[Bug libstdc++/41861] [DR 887][C++0x] does not use monotonic_clock

[redi at gcc dot gnu.org]

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

--- Comment #19 from Jonathan Wakely  ---
Author: redi
Date: Wed Sep  4 22:43:29 2019
New Revision: 275390

URL: https://gcc.gnu.org/viewcvs?rev=275390&root=gcc&view=rev
Log:
PR libstdc++/41861 Add full steady_clock support to condition_variable

The pthread_cond_clockwait function is available in glibc since the 2.30
release. If this function is available in the C library it can be used
to fix PR libstdc++/41861 by supporting std::chrono::steady_clock
properly with std::condition_variable.

This means that code using std::condition_variable::wait_for or
std::condition_variable::wait_until with std::chrono::steady_clock is no
longer subject to timing out early or potentially waiting for much
longer if the system clock is warped at an inopportune moment.

If pthread_cond_clockwait is available then std::chrono::steady_clock is
deemed to be the "best" clock available which means that it is used for
the relative wait_for calls and absolute wait_until calls using
user-defined clocks. Calls explicitly using std::chrono::system_clock
continue to use CLOCK_REALTIME via __gthread_cond_timedwait.

If pthread_cond_clockwait is not available then
std::chrono::system_clock is deemed to be the "best" clock available
which means that the previous suboptimal behaviour remains.

2019-09-04  Mike Crowe  

PR libstdc++/41861
* acinclude.m4 (GLIBCXX_CHECK_PTHREAD_COND_CLOCKWAIT): Check for new
pthread_cond_clockwait function.
* configure.ac: Use GLIBCXX_CHECK_PTHREAD_COND_CLOCKWAIT.
* configure: Regenerate.
* config.h.in: Regenerate.
* include/std/condition_variable: (condition_variable): Rename
__steady_clock_t typedef and add system_clock. Change __clock_t to be
a typedef for the preferred clock to convert arbitrary other clocks to.
[_GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT] (wait_until): Add a steady_clock
overload.
(wait_until): Change __clock_t overload to use system_clock.
[_GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT] (__wait_until_impl): Add
steady_clock overload that calls pthread_cond_clockwait.
(__wait_until_impl): Change __clock_t overload to use system_clock.
(condition_variable_any) [_GLIBCXX_USE_PTHREAD_COND_CLOCKWAIT]: Use
steady_clock for __clock_t if pthread_cond_clockwait is available.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/config.h.in
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/configure.ac
trunk/libstdc++-v3/include/std/condition_variable

[Bug fortran/91661] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-04
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from kargl at gcc dot gnu.org ---
Well, this is rather disconcerting.

(gdb) s
is_constant_array_expr (e=0x202f10d20) at ../../gccx/gcc/fortran/simplify.c:222
(gdb) list
224
225   if (e->expr_type == EXPR_VARIABLE && e->rank > 0
226   && e->symtree->n.sym->attr.flavor == FL_PARAMETER)
227 gfc_simplify_expr (e, 1);
228
229   if (e->expr_type != EXPR_ARRAY || !gfc_is_constant_expr (e))
230 return false;
231
232   for (c = gfc_constructor_first (e->value.constructor);
233c; c = gfc_constructor_next (c))
(gdb) p *e
$3 = {expr_type = EXPR_CONSTANT, ts = {type = BT_INTEGER, kind = 4, u = {
  derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0, 
is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false, 
interop_kind = 0x0}, rank = 1, shape = 0x0, symtree = 0x0, ref = 0x0, 

So, gfc_simplify_expr (e, 1) has reduced b(a(1)) to an EXPR_CONSTANT
with rank = 1.  Whoops, that's not good.

[Bug middle-end/91631] buffer overflow into an array member of a declared object not detected

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00221.html

[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018

[mrslevinsky at hotmail dot com]

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

--- Comment #10 from Mikael Slevinsky  ---
I can confirm this is fixed, thank you!

P.S. the exact processor type is a Xeon(R) W-2191B CPU @ 2.30GHz.

scima-mh421-20:Desktop mikael$ sysctl -a |grep cpu
hw.ncpu: 36
hw.activecpu: 36
hw.physicalcpu: 18
hw.physicalcpu_max: 18
hw.logicalcpu: 36
hw.logicalcpu_max: 36
hw.cputype: 7
hw.cpusubtype: 8
hw.cpu64bit_capable: 1
hw.cpufamily: 939270559
hw.cpufrequency: 23
hw.cpufrequency_min: 23
hw.cpufrequency_max: 23
hw.cputhreadtype: 1
machdep.cpu.max_basic: 22
machdep.cpu.max_ext: 2147483656
machdep.cpu.vendor: GenuineIntel
machdep.cpu.brand_string: Intel(R) Xeon(R) W-2191B CPU @ 2.30GHz
machdep.cpu.family: 6
machdep.cpu.model: 85
machdep.cpu.extmodel: 5
machdep.cpu.extfamily: 0
machdep.cpu.stepping: 4
machdep.cpu.feature_bits: 9223086162756500479
machdep.cpu.leaf7_feature_bits: 3550478331
machdep.cpu.extfeature_bits: 1241984796928
machdep.cpu.signature: 329300
machdep.cpu.brand: 0
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA
CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ
DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC
MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C
machdep.cpu.leaf7_features: SMEP ERMS RDWRFSGS TSC_THREAD_OFFSET BMI1 HLE AVX2
BMI2 INVPCID RTM SMAP RDSEED ADX IPT AVX512F AVX512CD AVX512DQ AVX512BW
AVX512VL PQM FPU_CSDS MPX PQE CLFSOPT
machdep.cpu.extfeatures: SYSCALL XD 1GBPAGE EM64T LAHF LZCNT PREFETCHW RDTSCP
TSCI
machdep.cpu.logical_per_package: 64
machdep.cpu.cores_per_package: 32
machdep.cpu.microcode_version: 33554526
machdep.cpu.processor_flag: 1
machdep.cpu.mwait.linesize_min: 64
machdep.cpu.mwait.linesize_max: 64
machdep.cpu.mwait.extensions: 3
machdep.cpu.mwait.sub_Cstates: 8224
machdep.cpu.thermal.sensor: 1
machdep.cpu.thermal.dynamic_acceleration: 1
machdep.cpu.thermal.invariant_APIC_timer: 1
machdep.cpu.thermal.thresholds: 2
machdep.cpu.thermal.ACNT_MCNT: 1
machdep.cpu.thermal.core_power_limits: 1
machdep.cpu.thermal.fine_grain_clock_mod: 1
machdep.cpu.thermal.package_thermal_intr: 1
machdep.cpu.thermal.hardware_feedback: 0
machdep.cpu.thermal.energy_policy: 1
machdep.cpu.xsave.extended_state: 255 2688 2688 0
machdep.cpu.xsave.extended_state1: 15 2432 256 0
machdep.cpu.arch_perf.version: 4
machdep.cpu.arch_perf.number: 4
machdep.cpu.arch_perf.width: 48
machdep.cpu.arch_perf.events_number: 7
machdep.cpu.arch_perf.events: 0
machdep.cpu.arch_perf.fixed_number: 3
machdep.cpu.arch_perf.fixed_width: 48
machdep.cpu.cache.linesize: 64
machdep.cpu.cache.L2_associativity: 16
machdep.cpu.cache.size: 256
machdep.cpu.tlb.inst.large: 8
machdep.cpu.tlb.data.small: 64
machdep.cpu.tlb.data.small_level1: 64
machdep.cpu.address_bits.physical: 46
machdep.cpu.address_bits.virtual: 48
machdep.cpu.core_count: 18
machdep.cpu.thread_count: 36
machdep.cpu.tsc_ccc.numerator: 192
machdep.cpu.tsc_ccc.denominator: 2
machdep.xcpm.cpu_thermal_level: 0

[Bug c++/67774] [concepts] ICE when mismatching template arguments to concept

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Created attachment 46825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46825&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This was previously fixed in the concepts-cxx2a branch. Providing a patch that
adds a test for the PR.

[Bug c++/67727] [concepts] parameterized constraint not being checked for unused variables

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Created attachment 46824
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46824&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

Apparently, this has been previously fixed in the concepts-cxx2a branch.
Providing a patch that adds a test for the PR.

[Bug target/91635] wrong code at -O2 with __builtin_add_overflow() and shifts

[wilson at gcc dot gnu.org]

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

--- Comment #18 from Jim Wilson  ---
I was willing to write a patch, I just needed a day to catch up as I'm
hopelessly overloaded with work.  But since Jakub wrote one, it looks right to
me, and I think we should use that.  I'm not sure exactly what testing Kito
did, and he has now left on vacation, so I will just do my own testing.

I think the reason why RISC-V needs paradoxical_reg and other architectures
don't is that most architectures have sense enough to define zero and sign
extend instructions.  RISC-V will finally get that when the draft B (bit
manipulation) extension is formally approved.

[Bug c++/67719] [concepts] bug with concepts using logical or

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Created attachment 46823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46823&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to have been previously fixed in the concepts-cxx2a branch.
Providing a patch that adds a test.

[Bug c++/67704] [concepts] requirements not being applied to aliases

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Confirmed. 

Constraints on dependent types aren't checked, but alias templates are always
"transparent". In the requirements on f, the type requirement R is simply
replaced by its instantiation, and the associated constraints are discarded.

There's a smaller version of this bug in the test suite in
g++.dg/cpp2a/concepts-alias.C, which is currently marked as xfail.

[Bug fortran/81827] Large compile time with derived-type rrays

[robison at arlut dot utexas.edu]

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

--- Comment #21 from Luke Robison  ---
I was again trying to upgrade our gfortran version and ran into this issue
again in gfortran-9.2, but I think I found a workaround this time.

Re-reading Paul Thomas' comments and looking at the changes in the bisected
commit ( r254427 ) I had the idea to try two workarounds:

(1) Changing some or all of the "type(levelNN)" definitions to "class(levelNN)"
definitions
(2) Changing from "allocatable" to "pointer"

Both of these fixes worked in gfortran 9.2 to remove the recursion-bomb during
compilation.  I haven't checked to see if they fix the issue in other versions,
but I thought it might help you come up with a more general solution.

For my team, we'll probably switch a few of our nested type-definitions over to
being CLASS statements instead of TYPE statements.

Hope this helped,
Luke

[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)

[jg at jguk dot org]

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

--- Comment #15 from Jonny Grant  ---
Great this is added for C and ObjC
Could it also be added for C++?

[Bug fortran/91661] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804

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

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

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

With a scalar "a" instead :


$ cat z2.f90
program p
   integer, parameter :: a = 2
   integer, parameter :: b(a) = 3
   integer, parameter :: c = dot_product(b, b)
   print *, c
end


$ gfortran-10-20190901 z2.f90 && ./a.out
  18

[Bug fortran/91661] New: ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804

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

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

Bug ID: 91661
   Summary: ICE in gfc_conv_intrinsic_dot_product, at
fortran/trans-intrinsic.c:4804
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least gfortran-5.
Similar also for intrinsics sum, size, shape, product.


$ cat z1.f90
program p
   integer, parameter :: a(1) = 2
   integer, parameter :: b(a(1)) = 3
   integer, parameter :: c = dot_product(b, b)
   print *, c
end


$ gfortran-10-20190901 -c z1.f90
z1.f90:5:0:

5 |print *, c
  |
internal compiler error: in gfc_conv_intrinsic_dot_product, at
fortran/trans-intrinsic.c:4804
0x706e91 gfc_conv_intrinsic_dot_product
../../gcc/fortran/trans-intrinsic.c:4804
0x71d20e gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-intrinsic.c:10006
0x701414 gfc_conv_function_expr
../../gcc/fortran/trans-expr.c:7460
0x6f47ea gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:8587
0x6fb175 gfc_conv_expr_reference(gfc_se*, gfc_expr*, bool)
../../gcc/fortran/trans-expr.c:8732
0x723717 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2582
0x6c4cd7 trans_code
../../gcc/fortran/trans.c:2072
0x7211fe build_dt
../../gcc/fortran/trans-io.c:2026
0x6c4cb7 trans_code
../../gcc/fortran/trans.c:2044
0x6ed7a4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6779
0x6775be translate_all_program_units
../../gcc/fortran/parse.c:6253
0x6775be gfc_parse_file()
../../gcc/fortran/parse.c:6492
0x6c14bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug c++/67697] [concepts] ICE when using non-constexpr in requires expression

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Created attachment 46822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46822&action=edit
Patch against concepts-cxx2a (git format-patch format)

This was fixed in concepts-cxx2a. The attached patch adds a test for the PR and
emits the error at the right location in the source file.

[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe  ---
(In reply to Martin Sebor from comment #7)
> Thanks, the trailing 10 in x86_64-apple-darwin10 makes the difference!

hmm, something's odd then, 'x86_64-apple-darwin' works for me (I put a number
out of habit more than necessity, in the host-only case***)

$ ./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=./gcc/xgcc
Target: x86_64-apple-darwin
Configured with: ../src/configure --prefix=/home/iains/gcc-trunk/darwin
--target=x86_64-apple-darwin

*** having said that, I do recommend putting something between 10 and 18 there
if you are building any libs, since some of them make dumb assumptions absent a
darwin version.  However, I don't expect you're building any libs - since that
would require the SDK headers and Mach-O 'binutils' neither of which you
(probably) have.



Thanks for the explanation - I wonder what happens for Linux when you use -fpic
-mcmodel=medium?

[Bug fortran/91660] New: [8/9/10 Regression] Missing error on invalid type declaration

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

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

Bug ID: 91660
   Summary: [8/9/10 Regression] Missing error on invalid type
declaration
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to gfortran-5.
Missing a closing bracket :


$ cat z1.f90
program p
   type t
   end type
   type (t x
   x = t()
end


$ gfortran-5 -c z1.f90
z1.f90:4:3:

type (t x
   1
Error: Unclassifiable statement at (1)
z1.f90:5:7:

x = t()
   1
Error: Can't convert TYPE(t) to REAL(8) at (1)


$ gfortran-10-20190901 -c z1.f90
$

[Bug rtl-optimization/91659] [Regression 10] Revision 275365 is causing a Fortran testsuite failure at -O3

[kargl at gcc dot gnu.org]

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

--- Comment #1 from kargl at gcc dot gnu.org ---
This seems to be trigger by the combination of -fgcse-after-reload and
-fpeel-loops.

% gfcx -o z -O2 -fgcse-after-reload -fpeel-loops a.f && ./z
STOP 3

[Bug target/63810] gcc sets incorrect macro for OS X deployment targets

[iains at gcc dot gnu.org]

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

--- Comment #35 from Iain Sandoe  ---
Author: iains
Date: Wed Sep  4 19:17:41 2019
New Revision: 275382

URL: https://gcc.gnu.org/viewcvs?rev=275382&root=gcc&view=rev
Log:
[Darwin, Driver] Fix driver crashes with valid command line input.

Backport Improve processing of macosx-version-min=

For PR target/63810 some improvements were made in the parsing of
the version string at the point it's used to define the built-in
__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__. This is fine, but the
specs processing also uses the version, and specs version-compare
doesn't like leading zeros on components. This means that while we
succeed in processing -mmacosx-version-min=010.2.99 on compile
lines, it fails for any other line that uses the value as part of a spec
(in particular, link lines fail).

To fix this, we need to apply a bit of clean-up to the version that's
presented to the driver, and push that back into the command line opts.

The value can come from four places:
1. User-entered on the command line
2. User-entered as MACOSX_DEPLOYMENT_TARGET= environment var.
3. Absent those two
3a For self-hosting systems, look-up from the kernel
3b For cross-compilers, as a default supplied at configure time.

We apply the clean-up to all 4 (although it shouldn't really be needed
for the cases under 3).

We also supply a test-case that adapts to the target-version of the
system, so that the link requirements are met by the SDK in use (if you
try to link i686-darwin9 on an x86-64-darwin18 SDK, it will fail).

gcc/

2019-09-04  Iain Sandoe  

Backport from mainline
2019-06-19  Iain Sandoe  

* config/darwin-driver.c (darwin_driver_init): Fix off-by-one errors
in computing the number of options to be moved.

Backport from mainline
2019-06-13  Iain Sandoe  

* config/darwin-driver.c (validate_macosx_version_min): New.
(darwin_default_min_version): Cleanup and validate supplied version.
(darwin_driver_init): Likewise and push cleaned version into opts.

gcc/testsuite/

2019-09-04  Iain Sandoe  

Backport from mainline.
2019-06-13  Iain Sandoe  

* gcc.dg/darwin-minversion-link.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/darwin-minversion-link.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/darwin-driver.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/67692] [concepts] ICE when using requires in non-concept contexts

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Created attachment 46821
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46821&action=edit
Patch against concepts-cxx2a to add test.

The issue appears to have been previously resolved.

[Bug rtl-optimization/91659] [Regression 10] Revision 275365 is causing a Fortran testsuite failure at -O3

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rguenther at suse dot de
   Target Milestone|--- |10.0

[Bug target/83531] Build broken on macOS 10.13.2

[iains at gcc dot gnu.org]

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

--- Comment #17 from Iain Sandoe  ---
Author: iains
Date: Wed Sep  4 19:11:08 2019
New Revision: 275381

URL: https://gcc.gnu.org/viewcvs?rev=275381&root=gcc&view=rev
Log:
[Darwin, fixincludes] Backport fix for PR83531

There is no reasonable chance that the SDKs in question will be re-
issued, so the only viable solution is a fixincludes.

2019-09-04  Iain Sandoe  

Backport from mainline.
2019-08-18  C.G. Dogan  
Iain Sandoe  

PR target/83531
* inclhack.def (darwin_api_availability): New; strip leading
underscores from API_ defines.
* fixincl.x: Regenerate.
* tests/base/os/availability.h: New file.


Added:
branches/gcc-7-branch/fixincludes/tests/base/os/availability.h
Modified:
branches/gcc-7-branch/fixincludes/ChangeLog
branches/gcc-7-branch/fixincludes/fixincl.x
branches/gcc-7-branch/fixincludes/inclhack.def

[Bug rtl-optimization/91659] New: [Regression 10] Revision 275365 is causing a Fortran testsuite failure at -O3

[kargl at gcc dot gnu.org]

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

Bug ID: 91659
   Summary: [Regression 10] Revision 275365 is causing a Fortran
testsuite failure at -O3
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Revision 275365 is causing

%gmake check-fortran RUNTESTFLAGS="dg.exp=direct_io\*"

Running /safe/sgk/gcc/gccx/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/direct_io_10.f   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/direct_io_10.f   -O3 -g  execution test

=== gfortran Summary ===

# of expected passes142
# of unexpected failures2
/safe/sgk/gcc/objx/gcc/gfortran  version 10.0.0 20190904 (experimental) (GCC) 


The revision was identified by 

% svn merge -r275365:275364 .

in top of tree.

[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Richard Biener from comment #1)
> for y >= 0.0 the result is unspecified?

NaN >= 0.0 is false, but even if it was unspecified, the implication would
still be true.

(In reply to Nikita Lisitsa from comment #2)
> If by 'isless(y, 0.0)' you mean 'y < 0.f',

He is talking about the standard macro isless, defined in math.h.

[Bug c++/67427] [concepts] Subsumption dependence on template parameter ordering

[Casey at Carter dot net]

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

Casey Carter  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||Casey at Carter dot net
 Resolution|--- |INVALID

--- Comment #2 from Casey Carter  ---
(In reply to Andrew Sutton from comment #1)
> I believe that the ambiguity is correct under the revised semantics of
> concepts.

I agree. Happy fourth birthday, #67427 - we'll miss you.

[Bug c++/67491] [meta-bug] concepts issues

[Casey at Carter dot net]

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

Bug 67427 Summary: [concepts] Subsumption dependence on template parameter 
ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67427

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug target/32413] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
Correct fix committed.

[Bug target/32413] [4.3 Regression] internal compiler error: in reload_cse_simplify_operands, at postreload.c:396

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Sep  4 18:25:05 2019
New Revision: 275377

URL: https://gcc.gnu.org/viewcvs?rev=275377&root=gcc&view=rev
Log:
PR target/32413
* config/i386/i386.c (inline_secondary_memory_needed): Return true
for QI and HImode moves between SSE and general registers.


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

[Bug target/91615] [10 regression][armeb] ICEs since r274986

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-04
   Assignee|unassigned at gcc dot gnu.org  |edlinger at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #6 from Bernd Edlinger  ---
Created attachment 46820
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46820&action=edit
untested patch

[Bug c++/67685] ICE on invalid requires expression

[andrew.n.sutton at gmail dot com]

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

--- Comment #3 from Andrew Sutton  ---
Fixed in the concepts-cxx2a branch and added a test for the PR.

[Bug c++/67684] [concepts] friend access not working with constrained function

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Fixed in concepts-cxx2a branch and added a test for the PR.

[Bug c++/67658] [concepts] invalid code with constrained concepts compiles

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Created attachment 46819
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46819&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions

[tnfchris at gcc dot gnu.org]

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

--- Comment #19 from Tamar Christina  ---
> It *was* committed (r249005).  Then reverted (r249050).  
>  reported "a 
> large number of new failures on AIX, including compiler ICEs".  I noted it 
> caused ICEs building glibc for powerpc.  Rainer noted Solaris/SPARC was 
> affected .  
> Other issues were also reported in that thread.

No it was not. The patch you're linking to is a couple of months older than the
one I had linked to that was problem free.

Yes it was committed and reverted and fixed, but never committed again.

The patch you linked to was form June, the one I linked to is from November.
Two different patches.

[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions

[joseph at codesourcery dot com]

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

--- Comment #18 from joseph at codesourcery dot com  ---
On Wed, 4 Sep 2019, tnfchris at gcc dot gnu.org wrote:

> As far as I am aware, the final version of the patch had no regressions for 
> any
> target, including PowerPC which I used the GCC compile farm to verify
> (https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02567.html)
> 
> The patch ended up not getting committed because of questions around whether
> integer operations were fast enough on all targets and on the latest reviewer
> requesting a major change to the patch.

It *was* committed (r249005).  Then reverted (r249050).  
 reported "a 
large number of new failures on AIX, including compiler ICEs".  I noted it 
caused ICEs building glibc for powerpc.  Rainer noted Solaris/SPARC was 
affected .  
Other issues were also reported in that thread.

Clearly these problems need to be fixed before it can go back in.

That doesn't mean it needs to cover all cases.  But it needs to avoid 
introducing regressions (whether ICEs or wrong code), and existing cases 
that are expanded inline need to stay expanded inline (whether with the 
old or the new expansion), and the limited subset of cases where it's OK 
to take the address of some such built-in functions with the possibility 
of out-of-line expansion need to stay working in the cases where they 
currently work.

[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)

[prathamesh3492 at gcc dot gnu.org]

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

--- Comment #14 from prathamesh3492 at gcc dot gnu.org ---
Author: prathamesh3492
Date: Wed Sep  4 16:25:21 2019
New Revision: 275376

URL: https://gcc.gnu.org/viewcvs?rev=275376&root=gcc&view=rev
Log:
Add warning Wenum-conversion for C and ObjC.

The patch enables warning with Wextra due to PR91593 and warnings with
allmodconfig kernel build. Once these issues are resolved, we could
consider promoting it to Wall.

2019-09-04  Prathamesh Kulkarni  

PR c/78736
* doc/invoke.texi: Document -Wenum-conversion.

c-family
* c.opt (Wenum-conversion): New option.

c/
* c-typeck.c (convert_for_assignment): Handle Wenum-conversion.

testsuite/
* gcc.dg/Wenum-conversion.c: New test-case.

Added:
trunk/gcc/testsuite/gcc.dg/Wenum-conversion.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

[ivan.chow2 at aecom dot com]

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

--- Comment #4 from Ivan Chow  ---
24GB still crashed the compiler

I think the preprocessor cc1plus has a bug in handling some of the templates of
that file...   it shouldn't need that much memory 

I ran command 'top' and can see the memory usage ran out-of-control and then
the compiler crashed.


-Original Message-
From: Chow, Ivan (Aiken) 
Sent: Wednesday, September 4, 2019 11:44 AM
To: 'mpolacek at gcc dot gnu.org'
Subject: RE: [Bug c++/91658] g++: internal compiler error: Killed (program
cc1plus)


Sorry.  Actually, I can increase the VM memory.   Only the "recommended"
maximum memory is 16GB.

Let me increase the VM memory to 24 GB and see what happen.  But it does have a
maximum memory, which is 64GB.

Thanks.


-Original Message-
From: Chow, Ivan (Aiken) 
Sent: Wednesday, September 4, 2019 11:29 AM
To: 'mpolacek at gcc dot gnu.org'
Subject: RE: [Bug c++/91658] g++: internal compiler error: Killed (program
cc1plus)


Thanks for the info.

I ran this on Ubuntu 18.04 with 16GB RAM configured on a VMware VM and the
maximum memory allowed is 16GB for this VM 

What should I do? 

Thanks for any advices.


-Original Message-
From: mpolacek at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Wednesday, September 4, 2019 11:26 AM
To: Chow, Ivan (Aiken)
Subject: [Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_bugzilla_show-5Fbug.cgi-3Fid-3D91658&d=DwIFaQ&c=TQzoP61-bYDBLzNd0XmHrw&r=1l2NCl9J2IRlx158OleV8UxhxKZcl07nghTppK8NHRQ&m=xIOYHPfZ-u-WA1Rv1yzNRl-x4iApqZS8WZEXmCdzqMw&s=PvKjvYMWPeh1ZBcDG62Mz-AyKrdic9VIMIbDlRwT2gE&e=
 

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-04
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
fatal error: ./indexing_op.h: No such file or directory

But Killed (program cc1plus) means you ran out of memory and the OOM killer
killed the cc1plus process.  Unlikely to be a GCC error.

[Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

[ivan.chow2 at aecom dot com]

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

--- Comment #3 from Ivan Chow  ---
Sorry.  Actually, I can increase the VM memory.   Only the "recommended"
maximum memory is 16GB.

Let me increase the VM memory to 24 GB and see what happen.  But it does have a
maximum memory, which is 64GB.

Thanks.


-Original Message-
From: Chow, Ivan (Aiken) 
Sent: Wednesday, September 4, 2019 11:29 AM
To: 'mpolacek at gcc dot gnu.org'
Subject: RE: [Bug c++/91658] g++: internal compiler error: Killed (program
cc1plus)


Thanks for the info.

I ran this on Ubuntu 18.04 with 16GB RAM configured on a VMware VM and the
maximum memory allowed is 16GB for this VM 

What should I do? 

Thanks for any advices.


-Original Message-
From: mpolacek at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Wednesday, September 4, 2019 11:26 AM
To: Chow, Ivan (Aiken)
Subject: [Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_bugzilla_show-5Fbug.cgi-3Fid-3D91658&d=DwIFaQ&c=TQzoP61-bYDBLzNd0XmHrw&r=1l2NCl9J2IRlx158OleV8UxhxKZcl07nghTppK8NHRQ&m=xIOYHPfZ-u-WA1Rv1yzNRl-x4iApqZS8WZEXmCdzqMw&s=PvKjvYMWPeh1ZBcDG62Mz-AyKrdic9VIMIbDlRwT2gE&e=
 

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-04
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
fatal error: ./indexing_op.h: No such file or directory

But Killed (program cc1plus) means you ran out of memory and the OOM killer
killed the cc1plus process.  Unlikely to be a GCC error.

[Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

[ivan.chow2 at aecom dot com]

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

--- Comment #2 from Ivan Chow  ---
Thanks for the info.

I ran this on Ubuntu 18.04 with 16GB RAM configured on a VMware VM and the
maximum memory allowed is 16GB for this VM 

What should I do? 

Thanks for any advices.


-Original Message-
From: mpolacek at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] 
Sent: Wednesday, September 4, 2019 11:26 AM
To: Chow, Ivan (Aiken)
Subject: [Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_bugzilla_show-5Fbug.cgi-3Fid-3D91658&d=DwIFaQ&c=TQzoP61-bYDBLzNd0XmHrw&r=1l2NCl9J2IRlx158OleV8UxhxKZcl07nghTppK8NHRQ&m=xIOYHPfZ-u-WA1Rv1yzNRl-x4iApqZS8WZEXmCdzqMw&s=PvKjvYMWPeh1ZBcDG62Mz-AyKrdic9VIMIbDlRwT2gE&e=
 

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-04
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
fatal error: ./indexing_op.h: No such file or directory

But Killed (program cc1plus) means you ran out of memory and the OOM killer
killed the cc1plus process.  Unlikely to be a GCC error.

[Bug c++/91658] g++: internal compiler error: Killed (program cc1plus)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-04
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
fatal error: ./indexing_op.h: No such file or directory

But Killed (program cc1plus) means you ran out of memory and the OOM killer
killed the cc1plus process.  Unlikely to be a GCC error.

[Bug c++/91658] New: g++: internal compiler error: Killed (program cc1plus)

[ivan.chow2 at aecom dot com]

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

Bug ID: 91658
   Summary: g++: internal compiler error: Killed (program cc1plus)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ivan.chow2 at aecom dot com
  Target Milestone: ---

Created attachment 46818
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46818&action=edit
file which cause the compiler to fail with internal error

gcc version 7.4.0 on Ubuntu 18.04.1 fails when it complies a file from MXnet
distribution with the following messages:
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with prepossessed source if appropriate.

[Bug c++/67654] [concepts] ICE when using concepts in constexpr function

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
This seems to have been fixed at some point. Added a test for this PR in the
concepts-cxx2a branch.

[Bug c++/67427] [concepts] Subsumption dependence on template parameter ordering

[andrew.n.sutton at gmail dot com]

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

--- Comment #1 from Andrew Sutton  ---
I believe that the ambiguity is correct under the revised semantics of
concepts.

The targets of the parameter mapping in Sentinel differs for the two
declarations of distance because the order of template parameters changes. For
the first declaration, the parameter mapping of the normal form of the requires
expression maps the 2nd template parameter of the concept to the 2nd template
parameter of the function template. For the second declaration, the normal form
of the requires expression maps the 2nd template parameter of the concept to
the 1st template parameter of the function template. Template parameters with
different indexes are not equivalent.

[Bug c++/67319] Short-hand concepts for variadic member functions broken

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
This seems to have been fixed at some point. Add a test for this PR in
concepts-cxx2a.

[Bug tree-optimization/91647] [10 Regression] new FAILs for Warray-bounds-8 and Wstringop-overflow-3.C

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Thanks, the trailing 10 in x86_64-apple-darwin10 makes the difference!

Here's a small test case copied from the one around line 335 in
g++.dg/warn/Warray-bounds-8.C, and its output with the cross:

  void sink (void*);

  struct B0
  {
char n;
char a[0];// { dg-message "destination object declared
here" }

B0 () { a[0] = 0; }   // { dg-warning "\\\[-Wstringop-overflow" }
  };

  void gb0 (void)
  {
struct B0 b0;
sink (&b0);
  }

$ /build/x86_64-apple-darwin10/gcc-svn/gcc/xgcc -B
/build/x86_64-apple-darwin10/gcc-svn/gcc -O2 -S -Wall -Wextra t.C
In constructor 'B0::B0()',
inlined from 'void gb0()' at t.C:16:13:
t.C:10:16: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   10 |   B0 () { a[0] = 0; }   // { dg-warning
"\\\[-Wstringop-overflow" }
  |   ~^~~

and with a Linux native GCC:

$ /build/gcc-svn/gcc/xgcc -B /build/gcc-svn/gcc -O2 -S -Wall -Wextra t.C
t.C: In function ‘void gb0()’:
t.C:10:14: warning: array subscript 0 is above array bounds of ‘char [0]’
[-Warray-bounds]
   10 |   B0 () { a[0] = 0; }   // { dg-warning
"\\\[-Wstringop-overflow" }
  |   ~~~^
t.C:8:8: note: while referencing ‘B0::a’
8 |   char a[0];// { dg-message "destination object
declared here" }
  |^


The difference between the two is that with the cross the store is a MEM_REF
that the -Warray-bounds warning doesn't handle:

gb0 ()
{
  struct B0 b0;

   [local count: 1073741824]:
  MEM[(char *)&b0 + 1B] = 0;
  sink (&b0);
  b0 ={v} {CLOBBER};
  return;

}

while with the native GCC the store is an ARRAY_REF that -Warray-bounds does
handle:

gb0 ()
{
  struct B0 b0;

   [local count: 1073741824]:
  b0 ={v} {CLOBBER};
  b0.a[0] = 0;
  sink (&b0);
  b0 ={v} {CLOBBER};
  return;

}

The MEM_REF is introduced during the early sra pass which the native compiler
decides not to run because the B0 ctor doesn't pass the
ipa_sra_preliminary_function_checks: it thinks the function cannot be local. 
This is based on the result of cgraph_node_cannot_be_local_p_1, specifically
the value of node->same_comdat_group which is null with the native GCC and
non-null with darwin:

cgraph_node_cannot_be_local_p_1 (cgraph_node *node, void *)
{
  return !(!node->force_output
   && ((DECL_COMDAT (node->decl)
&& !node->forced_by_abi
&& !node->used_from_object_file_p ()
&& !node->same_comdat_group)
   || !node->externally_visible));
}

I can't say I know why that is but the difference seems gratuitous.

That aside, ideally, both warnings would handle both forms of accesses but as
they don't share code so they improve independently, leading to these kinds of
inconsistencies.  I will look into improving -Warray-bounds to handle the
MEM_REF case as well.

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Though, looking at libdruntime, it already handles that and has several *.S
files.

[Bug c++/67225] [concepts] Expression constraint with a constrained result turns off access checking

[andrew.n.sutton at gmail dot com]

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

--- Comment #7 from Andrew Sutton  ---
It looks like there was an earlier state where access was being turned
off by one construct or another. All of the examples here fail as they're
supposed to. Added tests to concepts-cxx2a.

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
(In reply to Florian Weimer from comment #10)
> (In reply to rdapp from comment #9)
> > I opted for inline assembly to make sure r12 is not changed directly before
> > the function call. Do you have an idea to guarantee this in another way?
> 
> Wouldn't an out-of-line function in an .S file work?  It's a bit annoying
> because makefile changes will be needed, but maybe that's not too bad.
> 
> Does D support top-level asm statements?  Then perhaps you could use that to
> define an out-of-line function.

.S has the disadvantage that you need to take care about .note.GNU-stack etc.
If D doesn't have toplevel asm, you could use toplevel asm in a C source
perhaps.

[Bug c++/67217] [concepts] Constraints are ignored when specializing union templates

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #1 from Andrew Sutton  ---
Fixed in concepts-cxx2a. Added a test for this PR.

[Bug c++/67210] [concepts] Error parsing ">>" after a template-id that names a concept

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
This seems to have been resolved at some point. Added a unit test to the
concepts-cxx2a branch.

[Bug c++/67178] [concepts] ICE on self-referencing concept

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #2 from Andrew Sutton  ---
Fixed in concepts-cxx2a branch. Added a test for this PR.

[Bug c++/67147] [concepts] ICE on checking concept with default template arguments

[andrew.n.sutton at gmail dot com]

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

--- Comment #6 from Andrew Sutton  ---
There's a test for this PR in the concepts-cxx2a branch.

[Bug c++/67148] [concepts] Failed concept check when indirecting through a constrained trait

[andrew.n.sutton at gmail dot com]

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

--- Comment #3 from Andrew Sutton  ---
This seems to have been fixed at some point. All examples compile in the
concepts-cxx2a branch, which also has a test for this PR.

[Bug c++/67147] [concepts] ICE on checking concept with default template arguments

[andrew.n.sutton at gmail dot com]

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

--- Comment #5 from Andrew Sutton  ---
This seems to have been fixed at some point. All examples compile in the
concepts-cxx2a branch.

[Bug c++/67070] [concepts] Concept with negation and disjunction not checked correctly

[andrew.n.sutton at gmail dot com]

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

--- Comment #11 from Andrew Sutton  ---
Most of the concerns in this issue have been resolved when concept satisfaction
was defined in terms of normalized constraints in all contexts (requirements or
otherwise). In particular. negation makes the constraint atomic, and we don't
recursively normalize atoms. Negation is not a logical operator for the purpose
of subsumption.

Note that the case of overloading with the constraints !(C && C) vs
(!C || !C) is ambiguous since the atomic constraint !(C && C)
doesn't match either  !C and !C (and vice versa).

The concepts-cxx2a branch implements the new semantics.

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[fw at gcc dot gnu.org]

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

--- Comment #10 from Florian Weimer  ---
(In reply to rdapp from comment #9)
> I opted for inline assembly to make sure r12 is not changed directly before
> the function call. Do you have an idea to guarantee this in another way?

Wouldn't an out-of-line function in an .S file work?  It's a bit annoying
because makefile changes will be needed, but maybe that's not too bad.

Does D support top-level asm statements?  Then perhaps you could use that to
define an out-of-line function.

[Bug c++/66844] [c++-concepts] Requires-expression parameter with void type

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #4 from Andrew Sutton  ---
The parameter list of a requires clause should have the same restrictions as
that of a function's, unless WG21 decides to relax this later. The
concepts-cxx2a branch disallows void parameters, making both examples
ill-formed.

A (void) parameter-list is still permitted and is equivalent to ().

[Bug rtl-optimization/91657] New: [10 regression] many failures after r275365

[seurer at gcc dot gnu.org]

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

Bug ID: 91657
   Summary: [10 regression] many failures after r275365
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

One example:

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

Backtrace for this error:
#0  0x3fffb7f80477 in ???
#1  0x10001100 in intrinsic_unpack
at
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_unpack.f90:15
#2  0x1b0b in main
at
/home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_unpack.f90:21
FAIL: gfortran.fortran-torture/execute/intrinsic_unpack.f90 execution,  -O3 -g 


FAIL: gcc.c-torture/execute/builtins/mempcpy-2.c execution,  -O3 -g 
FAIL: gcc.dg/tree-prof/20050826-2.c execution,-fprofile-use -D_PROFILE_USE
FAIL: gfortran.dg/boz_15.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/boz_15.f90   -O3 -g  execution test
FAIL: gfortran.dg/char_length_8.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/char_length_8.f90   -O3 -g  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/intrinsic_unpack_2.f90   -O3 -g  execution test
FAIL: gfortran.dg/intrinsic_unpack_3.f90   -O3 -g  execution test
FAIL: gfortran.dg/list_read_4.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/list_read_4.f90   -O3 -g  execution test
FAIL: gfortran.dg/lto/bind_c-4 f_lto_bind_c-4_0.o-f_lto_bind_c-4_1.o execute 
-O3 -flto 
FAIL: gfortran.dg/maxlocval_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/maxlocval_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/mvbits_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/mvbits_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/namelist_12.f   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/namelist_12.f   -O3 -g  execution test
FAIL: gfortran.dg/pointer_remapping_5.f08   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/pointer_remapping_5.f08   -O3 -g  execution test
FAIL: gfortran.dg/read_legacy_comma.f90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/read_legacy_comma.f90   -O3 -g  execution test
FAIL: gfortran.dg/record_marker_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/record_marker_3.f90   -O3 -g  execution test
FAIL: gfortran.dg/reshape-alloc.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/reshape-alloc.f90   -O3 -g  execution test
FAIL: gfortran.dg/shift-alloc.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/shift-alloc.f90   -O3 -g  execution test
FAIL: gfortran.dg/unpack_mask_1.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/unpack_mask_1.f90   -O3 -g  execution test
FAIL: gfortran.dg/zero_sized_3.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/zero_sized_3.f90   -O3 -g  execution test
FAIL: gfortran.fortran-torture/execute/intrinsic_unpack.f90 execution,  -O3 -g

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[rdapp at linux dot ibm.com]

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

--- Comment #9 from rdapp at linux dot ibm.com ---
(In reply to Florian Weimer from comment #8)
> Calling functions from inline assembly is always a bit iffy.  For example,
> your code lacks clobbers for the vector registers (if present) and the
> condition code register.  I don't know if s390/s390x has a red zone, or
> specific call frame setup requirements (the psABI is ambiguous regarding the
> latter for functions whose arguments all fit into registers, as it is the
> case here).
> 
> I would suggest not to use inline assembly for this purpose.

Right about the missing registers.  I was wary about building with an older GCC
but the support only started with GCC9 so this should not be a problem. 
Apparently we can also add vector clobbers with -mno-vx.

I opted for inline assembly to make sure r12 is not changed directly before the
function call. Do you have an idea to guarantee this in another way?

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[fw at gcc dot gnu.org]

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

--- Comment #8 from Florian Weimer  ---
(In reply to rdapp from comment #7)
> Created attachment 46817 [details]
> Proposed patch using __tls_get_offset
> 
> I drafted a patch that uses __tls_get_offset instead of the internal symbol
> following Florian's idea.
> 
> Test suite looks similar to before.  Is it OK?

Calling functions from inline assembly is always a bit iffy.  For example, your
code lacks clobbers for the vector registers (if present) and the condition
code register.  I don't know if s390/s390x has a red zone, or specific call
frame setup requirements (the psABI is ambiguous regarding the latter for
functions whose arguments all fit into registers, as it is the case here).

I would suggest not to use inline assembly for this purpose.

[Bug d/91628] libdruntime uses glibc internal symbol on s390

[rdapp at linux dot ibm.com]

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

rdapp at linux dot ibm.com changed:

   What|Removed |Added

 CC||rdapp at linux dot ibm.com

--- Comment #7 from rdapp at linux dot ibm.com ---
Created attachment 46817
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46817&action=edit
Proposed patch using __tls_get_offset

I drafted a patch that uses __tls_get_offset instead of the internal symbol
following Florian's idea.

Test suite looks similar to before.  Is it OK?


Apart from that patch, however, I noticed that we FAIL in

libphobos.allocations/tls_gc_integration.d
libphobos.thread/tlsgc_sections.d

but I'm not sure yet how serious that is.

[Bug middle-end/66462] GCC isinf/isnan/... builtins cause sNaN exceptions

[segher at gcc dot gnu.org]

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

--- Comment #17 from Segher Boessenkool  ---
(In reply to Tamar Christina from comment #16)
> > Do you have a link to those problems?  And no, please don't regress us for 
> > no
> > reason at all, it's really easy to *not* regress this on double-double.
> 
> As far as I am aware, the final version of the patch had no regressions for
> any target, including PowerPC which I used the GCC compile farm to verify
> (https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02567.html)

That sounds great!

> The patch ended up not getting committed because of questions around whether
> integer operations were fast enough on all targets

But floating point operations are *incorrect* (at least when SNaNs are
enabled).

> and on the latest
> reviewer requesting a major change to the patch.

Hrm.

> At this time the patch had gone through 3 completely different
> implementations (due to to every time having a different reviewer reviewing
> it) and so a 4th rewrite was deemed not productive use of time.

Could you please retry anyway?  Maybe split the patch into smaller chunks,
so it is easier to digest?  (This also helps if anything regresses, to help
pinpoint what caused that).

Thanks!

[Bug libstdc++/41861] [DR 887][C++0x] does not use monotonic_clock

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch
   Last reconfirmed|2010-02-05 12:53:09 |2019-9-4
   Target Milestone|--- |10.0

[Bug c++/91618] template-id required to friend a function template, even for a qualified-id

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
to remind me, bullet 3 that Barry references is:

'if the name of the friend is a qualified-id and a matching function template
is found in the specified class or namespace, the friend declaration refers to
the deduced specialization of that function template (13.9.2.6), otherwise,'

[Bug target/81800] On aarch64 ilp32 lrint should not be inlined as two instructions

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #22 from Wilco  ---
Fixed

[Bug target/81800] On aarch64 ilp32 lrint should not be inlined as two instructions

[wilco at gcc dot gnu.org]

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

--- Comment #21 from Wilco  ---
Backported to GCC8 and GCC9 too.

[Bug target/81800] [8/9 regression] on aarch64 ilp32 lrint should not be inlined as two instructions

[wilco at gcc dot gnu.org]

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

--- Comment #20 from Wilco  ---
Author: wilco
Date: Wed Sep  4 13:06:55 2019
New Revision: 275374

URL: https://gcc.gnu.org/viewcvs?rev=275374&root=gcc&view=rev
Log:
[AArch64] Fix PR81800

PR81800 is about the lrint inline giving spurious FE_INEXACT exceptions.
The previous change for PR81800 didn't fix this: when lrint is disabled
in the backend, the midend will simply use llrint.  This actually makes
things worse since llrint now also ignores FE_INVALID exceptions!
The fix is to disable lrint/llrint on double if the size of a long is
smaller (ie. ilp32).

gcc/
PR target/81800
* gcc/config/aarch64/aarch64.md (lrint): Disable lrint pattern if GPF
operand is larger than a long int.

testsuite/
PR target/81800
* gcc.target/aarch64/no-inline-lrint_3.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/no-inline-lrint_3.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/aarch64/aarch64.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/91652] -march=skylake-avx512 -mno-fma -O2 generates FMA instructions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
I don't believe this is a bug.
If you look up the Intel CPU manuals, the FMA CPUID Feature Flag guards the VEX
encoded VF{,N}M{ADD,SUB,ADDSUB}{132,213,231}{S,P}{S,D} instructions, but not
the EVEX encoded ones, those are guarded just by AVX512F or AVX512F and
AVX512VL CPUID Feature Flags.  Thus, -mno-fma shouldn't affect them,
-mno-avx512f should.
And you can use -ffp-contract= to decide if code that isn't already using
explicit fma should be converted to FMA or not if the instructions are
available.

[Bug preprocessor/91639] [10 Regression] FAIL: gcc.dg/plugin/location-overflow-test-pr83173.c -fplugin=./location_overflo w_plugin.so scan-file-not # (?!1 [^\r\n]+location-overflow-test-pr83173-1.h"

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-04
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/81800] [8/9 regression] on aarch64 ilp32 lrint should not be inlined as two instructions

[wilco at gcc dot gnu.org]

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

--- Comment #19 from Wilco  ---
Author: wilco
Date: Wed Sep  4 12:42:22 2019
New Revision: 275373

URL: https://gcc.gnu.org/viewcvs?rev=275373&root=gcc&view=rev
Log:
[AArch64] Fix PR81800

PR81800 is about the lrint inline giving spurious FE_INEXACT exceptions.
The previous change for PR81800 didn't fix this: when lrint is disabled
in the backend, the midend will simply use llrint.  This actually makes
things worse since llrint now also ignores FE_INVALID exceptions!
The fix is to disable lrint/llrint on double if the size of a long is
smaller (ie. ilp32).

gcc/
PR target/81800
* gcc/config/aarch64/aarch64.md (lrint): Disable lrint pattern if GPF
operand is larger than a long int.

testsuite/
PR target/81800
* gcc.target/aarch64/no-inline-lrint_3.c: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/aarch64/no-inline-lrint_3.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/aarch64/aarch64.md
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

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

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

--- Comment #7 from G. Steinmetz  ---
Created attachment 46816
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46816&action=edit
Input "3 3", result test_3_3.f90


Enclosed are generators to systematically test the facts.
Please find attached two result files, 
e.g. ready to compile test_3_3.f90


$ gfortran generator_module_hierarchy.f90 -o gmh
$
$ echo "3 3" > in
$ ./gmh < in > test_3_3.f90
$
$ time gfortran -c test_3_3.f90
...

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

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

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

--- Comment #6 from G. Steinmetz  ---
Created attachment 46815
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46815&action=edit
Input "2 2", result test_2_2.f90

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

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

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

--- Comment #5 from G. Steinmetz  ---
Created attachment 46814
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46814&action=edit
Addon generator_module_hierarchy_ptr.f90

[Bug fortran/91646] gfortran takes long time and consumes a lot of memory

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

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #4 from G. Steinmetz  ---
Created attachment 46813
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46813&action=edit
Addon generator_module_hierarchy.f90

[Bug tree-optimization/81740] [7 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Wed Sep  4 11:56:15 2019
New Revision: 275372

URL: https://gcc.gnu.org/viewcvs?rev=275372&root=gcc&view=rev
Log:
2019-09-04  Richard Biener  

Backport from mainline
2019-03-26  Bin Cheng  

PR tree-optimization/81740
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence):
In case of outer loop vectorization, check for backward dependence
at the inner loop if outer loop dependence is reversed.

* gcc.dg/vect/pr81740-1.c: New testcase.
* gcc.dg/vect/pr81740-2.c: Likewise.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr81740-1.c
branches/gcc-7-branch/gcc/testsuite/gcc.dg/vect/pr81740-2.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/tree-vect-data-refs.c

[Bug middle-end/91001] internal compiler error: in extract_insn, at recog.c:2310

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
*** Bug 91105 has been marked as a duplicate of this bug. ***