[Bug rtl-optimization/87874] [8/9 Regression] ICE in simplify_subreg, at simplify-rtx.c:6396

[aoliva at gcc dot gnu.org]

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

--- Comment #3 from Alexandre Oliva  ---
Created attachment 44961
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44961=edit
candidate patch

[Bug bootstrap/87891] problems with building cross GCC for target powerpc64-darwin from powerpc-darwin

[dougmencken at gmail dot com]

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

--- Comment #8 from Douglas Mencken  ---
I found that I can add to configure line

AS_FOR_TARGET=as \
AR_FOR_TARGET=ar \
LD_FOR_TARGET=ld \
NM_FOR_TARGET=nm \
RANLIB_FOR_TARGET=ranlib \
LIPO_FOR_TARGET=lipo \
STRIP_FOR_TARGET=strip \
OBJDUMP_FOR_TARGET=objdump

[Bug target/87893] New: ICE in gimplify_expr, at gimplify.c:12557 on arm-linux-gnueabi

[marxin at gcc dot gnu.org]

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

Bug ID: 87893
   Summary: ICE in gimplify_expr, at gimplify.c:12557 on
arm-linux-gnueabi
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: arm-linux-gnueabihf

Following should be a recent regression:

$ arm-linux-gnueabi-gcc
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor5.C -c -O
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor5.C: In
function ‘void __static_initialization_and_destruction_0(int, int)’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor5.C:30:6:
internal compiler error: in gimplify_expr, at gimplify.c:12557
   30 | pair p;
  |  ^
0x5a80fb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:12557
0x938733 gimplify_modify_expr
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:5581
0x92fb9b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:11604
0x931ef6 gimplify_stmt(tree_node**, gimple**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:6614
0x93063a gimplify_cleanup_point_expr
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:6357
0x93063a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:11981
0x931ef6 gimplify_stmt(tree_node**, gimple**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:6614
0x92ff43 gimplify_statement_list
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:1763
0x92ff43 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:12033
0x931ef6 gimplify_stmt(tree_node**, gimple**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:6614
0x934457 gimplify_cond_expr
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:4084
0x92fb20 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:11561
0x931ef6 gimplify_stmt(tree_node**, gimple**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:6614
0x934457 gimplify_cond_expr
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:4084
0x92fb20 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:11561
0x931ef6 gimplify_stmt(tree_node**, gimple**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:6614
0x9331f4 gimplify_body(tree_node*, bool)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:12805
0x933475 gimplify_function_tree(tree_node*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/gimplify.c:12949
0x7ec49f cgraph_node::analyze()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cgraphunit.c:667
0x7eeac7 analyze_functions
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-arm/build/gcc/cgraphunit.c:1126

[Bug sanitizer/87892] New: [9 Regression]: libsanitizer fails to build on CentOS 5.11 (glibc 2.5)

[ubizjak at gmail dot com]

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

Bug ID: 87892
   Summary: [9 Regression]: libsanitizer fails to build on CentOS
5.11 (glibc 2.5)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Building libsanitizer with old glibc (2.5) fails with:

libtool: compile:  /home/uros/gcc-build/./gcc/xgcc -shared-libgcc
-B/home/uros/gcc-build/./gcc -nostdinc++
-L/home/uros/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/home/uros/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/uros/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/uros/local/x86_64-pc-linux-gnu/bin/
-B/home/uros/local/x86_64-pc-linux-gnu/lib/ -isystem
/home/uros/local/x86_64-pc-linux-gnu/include -isystem
/home/uros/local/x86_64-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=1 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../git/gcc/libsanitizer/sanitizer_common -I.. -I
../../../../git/gcc/libsanitizer/include -isystem
../../../../git/gcc/libsanitizer/include/system -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-pc-linux-gnu
-I../../../../git/gcc/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11
-DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I
../../../../git/gcc/libsanitizer/../libbacktrace -I ../libbacktrace -I
../../../../git/gcc/libsanitizer/../include -include
../../../../git/gcc/libsanitizer/libbacktrace/backtrace-rename.h -g -O2
-D_GNU_SOURCE -MT sanitizer_linux_libcdep.lo -MD -MP -MF
.deps/sanitizer_linux_libcdep.Tpo -c
../../../../git/gcc/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc 
-fPIC -DPIC -o .libs/sanitizer_linux_libcdep.o
../../../../git/gcc/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:
In function ‘__sanitizer::u32 __sanitizer::GetNumberOfCPUs()’:
../../../../git/gcc/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:699:10:
error: ‘CPU_COUNT’ was not declared in this scope
  699 |   return CPU_COUNT();
  |  ^
gmake[2]: *** [sanitizer_linux_libcdep.lo] Error 1
gmake[2]: Leaving directory
`/home/uros/gcc-build/x86_64-pc-linux-gnu/libsanitizer/sanitizer_common'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory
`/home/uros/gcc-build/x86_64-pc-linux-gnu/libsanitizer'
gmake: *** [all] Error 2

[Bug bootstrap/87891] problems with building cross GCC for target powerpc64-darwin from powerpc-darwin

[dougmencken at gmail dot com]

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

--- Comment #7 from Douglas Mencken  ---
So it’s not enough to just softlink ranlib, which is nothing more than alias to
libtool, and libtool sees it is invoked as ranlib, and fails to work as
"ranlib" when it’s powerpc64-unknown-darwin-ranlib

$ ls -l /usr/bin/ranlib
lrwxr-xr-x 1 root wheel 7 Jul  9  2014 /usr/bin/ranlib -> libtool

That’s what you need to use

sudo rm /usr/bin/powerpc64-unknown-darwin-ranlib
sudo cat << EOF > /usr/bin/powerpc64-unknown-darwin-ranlib
#!/bin/sh
exec ranlib \${1+"\$@"}
EOF
sudo chmod +x /usr/bin/powerpc64-unknown-darwin-ranlib

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #43 from Alexandre Oliva  ---
native --disable-bootstrap build on x86_64-linux-gnu now fails on trunk:
gnattools uses g++ -B../../ to link, which fails because g++ 8 does not
understand the %@ specs.  We really shouldn't be mixing up the preinstalled
compiler with the just-built one IMHO: it should be either g++, or ../../xg++
-B../../ (probably with additional flags to find libstdc++, if that's needed)

[Bug bootstrap/87891] problems with building cross GCC for target powerpc64-darwin from powerpc-darwin

[dougmencken at gmail dot com]

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

Douglas Mencken  changed:

   What|Removed |Added

  Component|c   |bootstrap

--- Comment #6 from Douglas Mencken  ---
After doing all of this

ln -s /usr/include/sys ./gcc/include/sys
ln -s /usr/include/machine ./gcc/include/machine
ln -s /usr/include/ppc ./gcc/include/ppc
ln -s /usr/include/unistd.h ./gcc/include/unistd.h
ln -s /usr/include/_types.h ./gcc/include/_types.h

ln -s /usr/include/stdlib.h ./gcc/include/stdlib.h
ln -s /usr/include/available.h ./gcc/include/available.h
ln -s /usr/include/alloca.h ./gcc/include/alloca.h

mkdir ./gcc/include/mach
ln -s /usr/include/mach/ppc ./gcc/include/mach/ppc

## /bin/sh: powerpc64-unknown-darwin-ar: command not found
sudo ln -s /usr/bin/ar /usr/bin/powerpc64-unknown-darwin-ar
# make[4]: powerpc64-unknown-darwin-ranlib: Command not found
sudo ln -s /usr/bin/ranlib /usr/bin/powerpc64-unknown-darwin-ranlib

ln -s /usr/include/pthread.h ./gcc/include/pthread.h
ln -s /usr/include/pthread_impl.h ./gcc/include/pthread_impl.h
ln -s /usr/include/sched.h ./gcc/include/sched.h
ln -s /usr/include/time.h ./gcc/include/time.h
ln -s /usr/include/_structs.h ./gcc/include/_structs.h

I got

powerpc64-unknown-darwin-ranlib libgcov.a
powerpc64-unknown-darwin-ranlib: no output file specified (specify with -o
output)
Usage: powerpc64-unknown-darwin-ranlib -static [-] file [...] [-filelist
listfile[,dirname]] [-arch_only arch] [-sacLT]
Usage: powerpc64-unknown-darwin-ranlib -dynamic [-] file [...] [-filelist
listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name]
[-compatibility_version #] [-current_version #] [-seg1addr 0x#]
[-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table
] [-seg_addr_table_filename ] [-all_load]
[-noall_load]
make[4]: *** [libgcov.a] Error 1
make[3]: *** [multi-do] Error 1
make[2]: *** [all-multi] Error 2
make[1]: *** [all-target-libgcc] Error 2

[Bug libstdc++/60497] unique_ptr tries to complete its type T even though it's not required to be a complete type

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #11 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #10)
> Author: redi
> Date: Tue May 13 17:22:08 2014
> New Revision: 210388
> 
> URL: http://gcc.gnu.org/viewcvs?rev=210388=gcc=rev
> Log:
>   PR libstdc++/60497
>   * include/debug/array (get): Qualify call to other get overload.
>   * include/profile/array (get): Likewise.
>   * include/std/array (get): Likewise.
>   * include/std/functional (_Mu, _Bind, _Bind_result): Qualify std::get.
>   * include/std/mutex (unique_lock, call_once): Use __addressof.
>   (__unlock_impl): Remove unused template.
>   (__try_to_lock): Declare inline.
>   (__try_lock_impl::__do_try_lock): Qualify function calls.
>   (lock): Avoid narrowing conversion.
>   * testsuite/20_util/bind/60497.cc: New.
>   * testsuite/23_containers/array/element_access/60497.cc: New.
>   * testsuite/30_threads/call_once/60497.cc: New.
>   * testsuite/30_threads/unique_lock/cons/60497.cc: New.
> 
> Added:
> trunk/libstdc++-v3/testsuite/20_util/bind/60497.cc
> trunk/libstdc++-v3/testsuite/23_containers/array/element_access/60497.cc
> trunk/libstdc++-v3/testsuite/30_threads/call_once/60497.cc
> trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/60497.cc
> Modified:
> trunk/libstdc++-v3/ChangeLog
> trunk/libstdc++-v3/include/debug/array
> trunk/libstdc++-v3/include/profile/array
> trunk/libstdc++-v3/include/std/array
> trunk/libstdc++-v3/include/std/functional
> trunk/libstdc++-v3/include/std/mutex

Did this fix it?

[Bug rtl-optimization/38711] ira should not be using df-lr except at -O1.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #9 from Eric Gallager  ---
(In reply to Steven Bosscher from comment #5)
> Much of GCC is still not ready for this.

What about now?

[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #22 from Eric Gallager  ---
(In reply to Rainer Orth from comment #8)
> Fixed for 4.8.0.

Rainer, do you want to remain the assignee for this? It was reopened for a
different platform than you originally opened it for... Although, then again:

(In reply to Jason Merrill from comment #18)
> Author: jason
> Date: Wed Mar  6 15:34:11 2013
> New Revision: 196493
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=196493
> Log:
>   PR debug/53363
>   * g++.dg/debug/dwarf2/thunk1.C: Skip on darwin.
> 
> Modified:
> trunk/gcc/testsuite/ChangeLog
> trunk/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C

...did this fix it? If so we can just close it and it won't matter who the
assignee is.

[Bug c/87891] _build/./gcc/as: line 106: exec: ppc64: not found

[dougmencken at gmail dot com]

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

--- Comment #5 from Douglas Mencken  ---
Then when I do

# header search path is -isystem ./include
ln -s /usr/include/sys ./gcc/include/sys
ln -s /usr/include/machine ./gcc/include/machine
ln -s /usr/include/ppc ./gcc/include/ppc
ln -s /usr/include/unistd.h ./gcc/include/unistd.h
ln -s /usr/include/_types.h ./gcc/include/_types.h

it succeeds to the next missing header

enable-execute-stack.c:27:10: fatal error: stdlib.h: No such file or directory
 #include 
  ^~

Why I need to do this by hand?

[Bug c/87891] _build/./gcc/as: line 106: exec: ppc64: not found

[dougmencken at gmail dot com]

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

--- Comment #4 from Douglas Mencken  ---
(In reply to Jonathan Wakely from comment #2)
> Do you have an assembler for the cross-target installed?

The same system’s `as` eats both of ppc and ppc64 assembly. It looks like that
build machinery of GCC just can’t locate it. Plus there’s another problem with

enable-execute-stack.c:25:10: fatal error: sys/mman.h: No such file or
directory

[Bug c/87891] _build/./gcc/as: line 106: exec: ppc64: not found

[dougmencken at gmail dot com]

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

--- Comment #3 from Douglas Mencken  ---
When I change

ORIGINAL_AS_FOR_TARGET=""

to

ORIGINAL_AS_FOR_TARGET="as"

inside gcc/as shell script, it succeeds, but not for long

/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/xgcc
-B/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/
-B/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/bin/
-B/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/lib/ -isystem
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/include -isystem
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/sys-include-g
-O2 -m32 -O2  -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -mmacosx-version-min=10.5 -pipe
-Wa,-force_cpusubtype_ALL -mmacosx-version-min=10.4 -fno-common
-mlong-double-128 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc  -mmacosx-version-min=10.5 -pipe -Wa,-force_cpusubtype_ALL
-mmacosx-version-min=10.4 -fno-common -mlong-double-128 -I. -I.
-I../../.././gcc -I../../../../gcc-8.2.0/libgcc
-I../../../../gcc-8.2.0/libgcc/. -I../../../../gcc-8.2.0/libgcc/../gcc
-I../../../../gcc-8.2.0/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o
enable-execute-stack.o -MT enable-execute-stack.o -MD -MP -MF
enable-execute-stack.dep  -c enable-execute-stack.c -fvisibility=hidden
-DHIDE_EXPORTS
exec as -arch ppc -I . -I . -I ../../.././gcc -I ../../../../gcc-8.2.0/libgcc
-I ../../../../gcc-8.2.0/libgcc/. -I ../../../../gcc-8.2.0/libgcc/../gcc -I
../../../../gcc-8.2.0/libgcc/../include -force_cpusubtype_ALL
-force_cpusubtype_ALL -o enable-execute-stack.o
enable-execute-stack.c:25:10: fatal error: sys/mman.h: No such file or
directory
 #include 
  ^~~~
compilation terminated.
make[4]: *** [enable-execute-stack.o] Error 1
make[3]: *** [multi-do] Error 1
make[2]: *** [all-multi] Error 2
make[1]: *** [all-target-libgcc] Error 2

[Bug c/87891] _build/./gcc/as: line 106: exec: ppc64: not found

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Do you have an assembler for the cross-target installed?

[Bug rtl-optimization/87874] [8/9 Regression] ICE in simplify_subreg, at simplify-rtx.c:6396

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #2 from Alexandre Oliva  ---
Mine

[Bug c/87891] _build/./gcc/as: line 106: exec: ppc64: not found

[dougmencken at gmail dot com]

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

--- Comment #1 from Douglas Mencken  ---
Created attachment 44960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44960=edit
assembly of conftest.c

It really can’t assemble main() { return 0; }

$ /Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/xgcc
-B/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/
-B/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/bin/
-B/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/lib/ -isystem
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/include -isystem
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/sys-include-c -g
-O2  conftest.c -save-temps

/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/as: line 106: exec:
ppc64: not found

[Bug c/87891] New: _build/./gcc/as: line 106: exec: ppc64: not found

[dougmencken at gmail dot com]

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

Bug ID: 87891
   Summary: _build/./gcc/as: line 106: exec: ppc64: not found
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dougmencken at gmail dot com
  Target Milestone: ---

When I try to cross-compile GCC from powerpc-darwin to powerpc64-darwin, it
fails at the beginning of libgcc

configure:3665: checking for suffix of object files
configure:3687: /Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/xgcc
-B/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/
-B/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/bin/
-B/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/lib/ -isystem
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/include -isystem
/Developer/GCC/8.2p/PowerPC/64bit/powerpc64-unknown-darwin/sys-include-c -g
-O2  conftest.c >&5
/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gcc/as: line 106: exec:
ppc64: not found
configure:3691: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/;
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3705: error: in
`/Volumes/hfsplushd/Development/gcc-toolchain/_build/powerpc64-unknown-darwin/libgcc':
configure:3708: error: cannot compute suffix of object files: cannot compile

Looks like it can’t parse “.machine ppc64” at the top of assembly file

How do I configure

../gcc-8.2.0/configure \
--build=powerpc-apple-darwin9 --host=powerpc-apple-darwin9
--target=powerpc64-unknown-darwin \
--prefix=/Developer/GCC/8.2p/PowerPC/64bit \
--enable-languages=c,c++,objc,obj-c++ \
--enable-shared --enable-static \
--enable-checking=release \
--enable-threads=posix --with-__thread --without-system-zlib \
--disable-nls --disable-werror

[Bug tree-optimization/80087] missing -Wtautological-compare with non-constant operands

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Most likely because Clang also implements the warning in the front-end and
without the benefit of flow analysis.

[Bug c/87879] -Wformat-nonliteral could see more things as literals

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Confirmed.  It could be done by integrating -Wformat with -Wformat-overflow. 
The latter runs without optimization as well as with it so the integration
shouldn't result in too many false negatives.

[Bug tree-optimization/80087] missing -Wtautological-compare with non-constant operands

[egallager at gcc dot gnu.org]

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

--- Comment #2 from Eric Gallager  ---
Although, for comparison, clang also only prints the same single
-Wtautological-compare warning that gcc does.

[Bug c++/79398] misleading error static constexpr member function called in a constant expression before its definition is complete

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> (In reply to Martin Sebor from comment #0)
> > The error below is a bit confusing: the definition of B::bar() is complete
> > when it's called.
> > 
> > I think I understand that the reason for the error below is actually that
> > the function is called before the definition of the class of which it's a
> > member is complete.  The error should make that clear, although it seems
> > that accepting it (e.g., as an extension) would make static constexpr member
> > functions quite a bit more useful.
> 
> Confirmed. If accepting it as an extension, sounds like material for
> -fpermissive.

C++ FE maintainers, is this something you'd want to do?

[Bug driver/87769] GCC build from source uses headers and libraries from directories host machine.

[mte.zych at gmail dot com]

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

--- Comment #4 from Mateusz Zych  ---
Right, the "--with-sysroot=" configuration parameter is the key.
The sysroot directory defines minimal filesystem of a target machine,
in particular it should contain standard C library and Linux kernel headers,
so it makes sense that I have to provide the sysroot directory
to build standalone GCC, which would be a cross compiler.

However, I don't understand why would
configuration parameters "--host=" and "--target=",
define whether I am building a cross compiler or not.
To me, what differentiates cross compiler form native compiler,
is the location of libraries and headers.

 - Native compilers use libraries and headers from host machine.
 - Cross compilers never touch host machine and always use sysroot.

Of course, all compilers targeting different architecture compared to
architecture of the host machine have be cross compilers.
But the opposite is not true - not all cross compilers have to target
architecture different from architecture of the host machine.
They can match, no problem!
And this is exactly what I'm trying to do - I want build GCC cross compiler
targeting the exact same architecture that my host machine is using.


OK, with that out of the way, I've updated my script:

# Linux
wget https://kernel.org/pub/linux/kernel/v4.x/linux-4.19.tar.gz
tar -xvf linux-4.19.tar.gz
mv linux-4.19 linux-source
cd linux-source
make ARCH=x86_64 INSTALL_HDR_PATH=$PWD/../gcc/sysroot/usr headers_install
cd ..

# GNU C Library (glibc)
wget https://ftp.gnu.org/gnu/glibc/glibc-2.28.tar.gz
tar -xvf glibc-2.28.tar.gz
mv glibc-2.28 glibc-source
mkdir glibc-build
cd glibc-build
../glibc-source/configure --build=x86_64-linux-gnu \
  --host=x86_64-linux-gnu \
  --target=x86_64-linux-gnu \
  --prefix=$PWD/../gcc/sysroot/usr \
  --with-headers=$PWD/../gcc/sysroot/usr/include \
  --disable-multilib \
  --disable-nls \
  --disable-timezone-tools
make all -j 4
make install
cd ..

# GNU Binutils
wget https://ftp.gnu.org/gnu/binutils/binutils-2.31.tar.gz
tar -xvf binutils-2.31.tar.gz
mv binutils-2.31 binutils-source
mkdir binutils-build
cd binutils-build
../binutils-source/configure --build=x86_64-linux-gnu \
 --host=x86_64-linux-gnu \
 --target=x86_64-linux-gnu \
 --prefix=$PWD/../gcc \
 --with-sysroot=$PWD/../gcc/sysroot \
 --disable-multilib \
 --disable-nls
make all -j 4
make install
cd ..

# GCC
wget https://ftp.gnu.org/gnu/gcc/gcc-8.2.0/gcc-8.2.0.tar.gz
tar -xvf gcc-8.2.0.tar.gz
mv gcc-8.2.0 gcc-source
cd gcc-source
./contrib/download_prerequisites
cd ..
mkdir gcc-build
cd gcc-build
../gcc-source/configure --build=x86_64-linux-gnu \
--host=x86_64-linux-gnu \
--target=x86_64-linux-gnu \
--prefix=$PWD/../gcc \
--with-sysroot=$PWD/../gcc/sysroot \
--enable-languages=c,c++ \
--disable-multilib \
--disable-nls
make all -j 4
make install
cd ..

Essentially I am puting:
 - GCC and Binutils into $ROOT/gcc and
 - glibc with Linux headers into ROOT/gcc/sysroot.


Unfortunately with updated script, GCC is not compiling anymore. :(
I've never managed to compile GCC configured with parameter "--with-sysroot=".

What is actually failing? Well, the libgcc_s.so fails to link with libc.so.6:

attempt to open
/home/mzych/standalone-gcc/gcc-build/../gcc/sysroot/home/mzych/standalone-gcc/glibc-build/../gcc/sysroot/usr/lib/libc.so.6
failed
attempt to open
/home/mzych/standalone-gcc/gcc-build/../gcc/sysroot/home/mzych/standalone-gcc/glibc-build/../gcc/sysroot/usr/lib/libc_nonshared.a
failed
attempt to open
/home/mzych/standalone-gcc/gcc-build/../gcc/sysroot/home/mzych/standalone-gcc/glibc-build/../gcc/sysroot/usr/lib/ld-linux-x86-64.so.2
failed

/usr/bin/ld: cannot find
/home/mzych/standalone-gcc/glibc-build/../gcc/sysroot/usr/lib/libc.so.6
   inside /home/mzych/standalone-gcc/gcc-build/../gcc/sysroot
/usr/bin/ld: cannot find
/home/mzych/standalone-gcc/glibc-build/../gcc/sysroot/usr/lib/libc_nonshared.a 
   inside /home/mzych/standalone-gcc/gcc-build/../gcc/sysroot
/usr/bin/ld: cannot find
/home/mzych/standalone-gcc/glibc-build/../gcc/sysroot/usr/lib/ld-linux-x86-64.so.2
inside /home/mzych/standalone-gcc/gcc-build/../gcc/sysroot

To me this failure looks like an issue with sysroot path,

[Bug tree-optimization/83657] detect invalid calls to built-ins declared without prototype

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
My patch for pr83656 implements this.

[Bug c/87890] New: inconsistency in handling floating built-ins declared without prototype

[msebor at gcc dot gnu.org]

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

Bug ID: 87890
   Summary: inconsistency in handling floating built-ins declared
without prototype
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing a patch for pr83656 I noticed another surprising inconsistency in
how built-ins declared without a prototype are handled.  In the test case
below, the fabs() declaration is accepted without a warning and the call to
fabs(-1.0) is folded to a constant.  But the declaration of fabsf() triggers a
warning and the equivalent call fabsf(-1.0f) is not folded.

The reason for this inconsistency is that the self_promoting_args_p() function
returns false for type float, and so the fabsf() function declaration without a
prototype is considered to be incompatible with fabsf(float).  GCC issues a
warning for it and treats it as an ordinary function.

$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
double fabs ();   // no warning

double f (void)
{
  return fabs (-1.0);   // folded to 1.0
}


float fabsf ();   // warning

float g (void)
{
  return fabsf (-1.0f);   // not folded
}

t.c:9:7: warning: conflicting types for built-in function ‘fabsf’
[-Wbuiltin-declaration-mismatch]
9 | float fabsf ();
  |   ^

;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)

f ()
{
   [local count: 1073741824]:
  return 1.0e+0;

}



;; Function g (g, funcdef_no=1, decl_uid=1911, cgraph_uid=2, symbol_order=1)

g ()
{
  float _3;

   [local count: 1073741824]:
  _3 = fabsf (-1.0e+0); [tail call]
  return _3;

}

[Bug c++/87882] -Wredundant-move false positive

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug tree-optimization/87889] New: [9 Regression] CPU2000 177.mesa failed to build

[hjl.tools at gmail dot com]

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

Bug ID: 87889
   Summary: [9 Regression] CPU2000 177.mesa failed to build
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
  Target Milestone: ---

On x86, r265812 caused:

gcc -c -o drawpix.o   -DSPEC_CPU2000_LP64 -O3 -funroll-loops
-ffast-math   drawpix.c
during GIMPLE pass: vect
drawpix.c: In function 'draw_depth_pixels':
drawpix.c:355:13: internal compiler error: Segmentation fault
  355 | static void draw_depth_pixels( GLcontext* ctx, GLsizei width, GLsizei
height,
  | ^
0xcd504f crash_signal
../../src-trunk/gcc/toplev.c:325
0xf1ab93 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../src-trunk/gcc/tree.h:3231
0xf1ab93 slpeel_duplicate_current_defs_from_edges
../../src-trunk/gcc/tree-vect-loop-manip.c:984
0xf1c966 slpeel_tree_duplicate_loop_to_edge_cfg(loop*, loop*, edge_def*)
../../src-trunk/gcc/tree-vect-loop-manip.c:1074
0xf20a44 vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**,
tree_node**, tree_node**, int, bool, bool)
../../src-trunk/gcc/tree-vect-loop-manip.c:2580
0xf0f914 vect_transform_loop(_loop_vec_info*)
../../src-trunk/gcc/tree-vect-loop.c:8243
0xf32bfd try_vectorize_loop_1
../../src-trunk/gcc/tree-vectorizer.c:965
0xf335f9 vectorize_loops()
../../src-trunk/gcc/tree-vectorizer.c:1097
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
specmake[3]: *** [drawpix.o] Error 1
specmake[3]: *** Waiting for unfinished jobs

[Bug libquadmath/68686] tgammaq(x) is always negative for noninteger x < 0

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #6 from Joseph S. Myers  ---
Fixed for GCC 9 by updating most of libquadmath/math/ from glibc and automating
that update.

[Bug libquadmath/68686] tgammaq(x) is always negative for noninteger x < 0

[jsm28 at gcc dot gnu.org]

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

--- Comment #5 from Joseph S. Myers  ---
Author: jsm28
Date: Mon Nov  5 23:03:55 2018
New Revision: 265822

URL: https://gcc.gnu.org/viewcvs?rev=265822=gcc=rev
Log:
Update most of libquadmath/math/ from glibc, automate update (PR
libquadmath/68686).

libquadmath sources are mostly based on glibc sources at present, but
derived from them by a manual editing / substitution process and with
subsequent manual merges.  The manual effort involved in merges means
they are sometimes incomplete and long-delayed.

Since libquadmath was first created, glibc's support for this format
has undergone significant changes so that it can also be used in glibc
to provide *f128 functions for the _Float128 type from TS 18661-3.
This makes it significantly easier to use it for libquadmath in a more
automated fashion, since glibc has a float128_private.h header that
redefines many identifiers as macros as needed for building *f128
functions.

Simply using float128_private.h directly in libquadmath, with
unmodified glibc sources except for changing function names in that
one header to be *q instead of *f128, would be tricky, given its
dependence on lots of other glibc-internal headers (whereas
libquadmath supports non-glibc systems), and also given how some libm
functions in glibc are built from type-generic templates using a
further set of macros rather than from separate function
implementations for each type.

So instead this patch adds a script update-quadmath.py to convert
glibc sources into libquadmath ones, and the script reads
float128_private.h to identify many of the substitutions it should
make.  quadmath-imp.h is updated with various new internal
definitions, taken from glibc as needed; this is the main place
expected to need updating manually when subsequent merges from glibc
are done using the script.  No attempt is made to make the script
output match the details of existing formatting, although the
differences are of a size that makes a rough comparison (ignoring
whitespace) possible.

Two new public interfaces are added to libquadmath, exp2q and
issignalingq, at a new QUADMATH_1.2 symbol version, since those
interfaces are used internally by some of the glibc sources being
merged into libquadmath; although there is a new symbol version, no
change however is made to the libtool version in the libtool-version
file.  Although there are various other interfaces now in glibc libm
but not in libquadmath, this patch does nothing to add such interfaces
(although adding many of them would in fact be easy to do, given the
script).

One internal file (not providing any public interfaces),
math/isinf_nsq.c, is removed, as no longer used by anything in
libquadmath after the merge.

Conditionals in individual source files on  availability or
features are moved into quadmath-imp.h (providing trivial macro
versions of the functions if real implementations aren't available),
to simplify the substitutions in individual source files.  Note
however that I haven't tested for any configurations lacking ,
so further changes could well be needed there.

Two files in libquadmath/math/ are based on glibc sources but not
updated in this patch: fmaq.c and rem_pio2q.c.  Both could be updated
after further changes to the script (and quadmath-imp.h as needed); in
the case of rem_pio2q.c, based on two separate glibc source files,
those separate files would naturally be split out into separate
libquadmath source files in the process (as done in this patch with
expq_table.h and tanq_kernel.c, where previously two glibc source
files had been merged into one libquadmath source file).  complex.c,
nanq.c and sqrtq.c are not based on glibc sources (though four of the
(trivial) functions in complex.c could readily be replaced by instead
using the four corresponding files from glibc, if desired).

libquadmath also has printf/ and strtod/ sources based on glibc, also
mostly not updated for a long time.  Again the script could no doubt
be made to generate those automatically, although that would be a
larger change (effectively some completely separate logic in the
script, not sharing much if anything with the existing code).

Bootstrapped with no regressions on x86_64-pc-linux-gnu.

PR libquadmath/68686
* Makefile.am: (libquadmath_la_SOURCES): Remove math/isinf_nsq.c.
Add math/exp2q.c math/issignalingq.c math/lgammaq_neg.c
math/lgammaq_product.c math/tanq_kernel.c math/tgammaq_product.c
math/casinhq_kernel.c.
* Makefile.in: Regenerate.
* libquadmath.texi (exp2q, issignalingq): Document.
* quadmath-imp.h: Include , ,  and
.
(HIGH_ORDER_BIT_IS_SET_FOR_SNAN, FIX_FLT128_LONG_CONVERT_OVERFLOW)
(FIX_FLT128_LLONG_CONVERT_OVERFLOW, __quadmath_kernel_tanq)
(__quadmath_gamma_productq, __quadmath_gammaq_r)
(__quadmath_lgamma_negq, __quadmath_lgamma_productq)
(__quadmath_lgammaq_r, 

[Bug fortran/87881] gfortran.dg/inquiry_type_ref_(1.f08|3.f90) fail on darwin

[pault at gcc dot gnu.org]

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

--- Comment #1 from Paul Thomas  ---
Hi Dominique,

When you have a moment, could you do a bit of diagnosis for me please? I
presume that the ICE is caused by the neglect of a pointer that is sometimes
null but which FC28 passes over. A debug session to find out what the problem
is would be much appreciated.

Thanks

Paul

[Bug middle-end/87886] ICE in format_helper, at real.h:227

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|7.4 |---
Summary|[7/8/9 Regression] ICE in   |ICE in format_helper, at
   |format_helper, at   |real.h:227
   |real.h:227  |

--- Comment #2 from Jakub Jelinek  ---
Actually, can't find a compiler that doesn't ICE, even r9 ICEs on this:
pr87886.c: In function ‘foo’:
pr87886.c:7: internal compiler error: output_operand: floating constant misused
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
The current ICE is that because apparently various spots in match.pd assume
that a builtin call will have compatible arguments with the builtin, but in
generic nothing actually checks that, and the FUNCTION_DECL doesn't even have a
type with TYPE_ARG_TYPES at all; this gets reverted during pop_scope of the
file scope, so what later gimple opts see is already proper function call.

[Bug ada/87688] [9 regression] ACATS cb1010a cb1010d failure

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Eric Botcazou  ---
Thanks for the note.

[Bug middle-end/87886] [7/8/9 Regression] ICE in format_helper, at real.h:227

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |7.4
Summary|ICE in format_helper, at|[7/8/9 Regression] ICE in
   |real.h:227  |format_helper, at
   ||real.h:227

[Bug middle-end/87886] ICE in format_helper, at real.h:227

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Same ICE, just no warning for:
extern double sqrt ();

int
foo (int x)
{
  return sqrt (x) < 1.0;
}

[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman  ---
Original problem still exists a couple of months later.

[Bug bootstrap/61164] GCC 4.9.0 fails to build libitm when fortification enabled

[romain.naour at gmail dot com]

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

Romain Naour  changed:

   What|Removed |Added

 CC||romain.naour at gmail dot com

--- Comment #6 from Romain Naour  ---
Hi,

This issue has been reported recently on gcc 5.5.0 [1]
Is it safe to backport the patch to gcc 4.9 and 5.5.0?

Best regards,
Romain

[1] https://bugs.busybox.net/show_bug.cgi?id=11476

[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
Author: segher
Date: Mon Nov  5 21:18:22 2018
New Revision: 265821

URL: https://gcc.gnu.org/viewcvs?rev=265821=gcc=rev
Log:
combine: Don't make an intermediate reg for assigning to sfp (PR87871)

The code with an intermediate register is perfectly fine, but LRA
apparently cannot handle the resulting code, or perhaps something else
is wrong.  In either case, making an extra temporary will not likely
help here, so let's just skip it.


PR rtl-optimization/87871
* combine.c (make_more_copies): Skip if dest is frame_pointer_rtx.

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

[Bug c/87888] New: Behaviour of __builtin_arc_sr differs from its description in the manual.

[nbowler at draconx dot ca]

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

Bug ID: 87888
   Summary: Behaviour of __builtin_arc_sr differs from its
description in the manual.
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nbowler at draconx dot ca
  Target Milestone: ---

I happened to notice what appears to be an error in the GCC manual,
§6.59.4 ARC Built-in Functions[1]:

Built-in Function: void __builtin_arc_sr (unsigned int auxr, unsigned int val)

The first argument, /auxv/, is the address of an auxiliary register,
the second argument, /val/, is a compile time constant to be written
to the register. Generates:

sr  auxr, [val]

This function indeed generates the sr instruction with the parameters
exactly as described, e.g., __builtin_arc_sr(0x123, 0x456) generates

   sr 0x123, [0x456]

However, the description of those parameters is incorrect: the first
operand of sr is the value to be written, and the second is the address,
so the previous example stores the value 0x123 to aux address 0x456.

Also I think the note about val being a compile-time constant is an
error as well... the sr instruction does not require constants, and
gcc happily accepts non-constant values as arguments to this builtin.

I suggest the documentation of this builtin should be changed to match
its actual behaviour, perhaps something like:

Built-in Function: void __builtin_arc_sr (unsigned int val, unsigned int auxr)

Stores /val/ to the auxiliary register with address /auxr/.  Generates:

sr  val, [auxr]

[1]
https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/ARC-Built-in-Functions.html#index-_005f_005fbuiltin_005farc_005fsr

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
If combine tries to split RTL into two instructions, it tries to do that
one way (and one way only).  It picked the AND here.  It did not work.

You can add some define_split to your target to help combine along.

[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists

[dmalcolm at gcc dot gnu.org]

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

--- Comment #9 from David Malcolm  ---
Candidate patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00304.html

[Bug c++/43486] Preserve variable-use locations

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #14 from David Malcolm  ---
Candidate followup patch:
  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00304.html

[Bug c++/87504] inconsistent diagnostic style between C and C++ for binary operators

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Candidate patch for C++ part of this:
  https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00303.html

[Bug target/87583] error: unrecognizable insn on ppc64le

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
It's the same problem as many other PRs.  You are using -mcpu=power8 (it is
the default for powerpc64le), but disabling some 2.04 insns (power5+).

[Bug c/87887] New: ICE in make_ssa_name_fn, at tree-ssanames.c:269

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

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

Bug ID: 87887
   Summary: ICE in make_ssa_name_fn, at tree-ssanames.c:269
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least gcc-5 :


$ cat z1.c
struct foo
{
  int n : 16;
};
#pragma omp declare simd
struct foo
f (int x)
{
}


$ gcc-9-20181104 -c z1.c -fopenmp -m64
$ gcc-9-20181104 -c z1.c -fopenmp -m32
during IPA pass: simdclone
z1.c: In function 'f.simdclone.1':
z1.c:9:1: internal compiler error: in make_ssa_name_fn, at tree-ssanames.c:269
9 | }
  | ^
0xc2cfa5 make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
../../gcc/tree-ssanames.c:266
0x11fc606 make_ssa_name
../../gcc/tree-ssanames.h:115
0x11fc606 simd_clone_adjust
../../gcc/omp-simd-clone.c:1230
0x11fde77 expand_simd_clones(cgraph_node*)
../../gcc/omp-simd-clone.c:1676
0x11fe337 ipa_omp_simd_clone
../../gcc/omp-simd-clone.c:1694
0x11fe337 execute
../../gcc/omp-simd-clone.c:1722



For both -m32|-m64 while configured with --enable-checking=yes :

$ gcc-9-20181104-chk -c z1.c -fopenmp -m64
during IPA pass: simdclone
z1.c: In function 'f.simdclone.0':
z1.c:9:1: internal compiler error: tree check: expected none of record_type or
union_type or qual_union_type or array_type, have record_type in layout_type,
at stor-layout.c:2363
9 | }
  | ^
0x5ca52e tree_not_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9527
0xbeedd7 tree_not_check4(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code, tree_code)
../../gcc/tree.h:3195
0xbeedd7 layout_type(tree_node*)
../../gcc/stor-layout.c:2363
0xee3ece make_vector_type
../../gcc/tree.c:9744
0x150cf5e simd_clone_adjust_return_type
../../gcc/omp-simd-clone.c:509
0x150fa63 simd_clone_adjust
../../gcc/omp-simd-clone.c:1103
0x15144a6 expand_simd_clones(cgraph_node*)
../../gcc/omp-simd-clone.c:1676
0x1514fe7 ipa_omp_simd_clone
../../gcc/omp-simd-clone.c:1694
0x1514fe7 execute
../../gcc/omp-simd-clone.c:1722

[Bug c/87886] New: ICE in format_helper, at real.h:227

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

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

Bug ID: 87886
   Summary: ICE in format_helper, at real.h:227
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

With option -Ofast or -ffast-math, down to at least gcc-5 :


$ cat z1.c
extern double sqrt (x);
int f (int x)
{
  return sqrt(x) < 1.0;
}


$ gcc-9-20181104 -c z1.c -Ofast
z1.c:1:1: warning: parameter names (without types) in function declaration
1 | extern double sqrt (x);
  | ^~
z1.c: In function 'f':
z1.c:4:3: internal compiler error: in format_helper, at real.h:227
4 |   return sqrt(x) < 1.0;
  |   ^~
0xe5fc01 format_helper::format_helper(machine_mode const&)
../../gcc/real.h:227
0xe5fc01 generic_simplify_47
/gcc/generic-match.c:2546
0xe6e5d6 generic_simplify_LT_EXPR
/gcc/generic-match.c:44235
0xeadead generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/gcc/generic-match.c:52146
0x7ebbce fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9364
0x7f203a fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12336
0x62f1f3 c_fully_fold_internal
../../gcc/c/c-fold.c:370
0x62fd09 c_fully_fold(tree_node*, bool, bool*, bool)
../../gcc/c/c-fold.c:125
0x5f728d c_finish_return(unsigned int, tree_node*, tree_node*)
../../gcc/c/c-typeck.c:10252
0x6255b3 c_parser_statement_after_labels
../../gcc/c/c-parser.c:5475
0x627060 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5100
0x6277d6 c_parser_compound_statement
../../gcc/c/c-parser.c:4934
0x628f3a c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2347
0x62d113 c_parser_external_declaration
../../gcc/c/c-parser.c:1648
0x62dbd9 c_parser_translation_unit
../../gcc/c/c-parser.c:1529
0x62dbd9 c_parse_file()
../../gcc/c/c-parser.c:18561
0x671e30 c_common_parse_file()
../../gcc/c-family/c-opts.c:1150

[Bug fortran/56496] [OOP] [F08] ICE with TYPE(*) coarray and SELECT TYPE

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

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

--- Comment #4 from G. Steinmetz  ---

Slightly modified :


$ cat z1.f90
program p
   class(*), allocatable :: a[:]
   allocate (integer :: a[*])
   select type (a)
   type is (integer)
  a = a(1)
   end select
end


$ gfortran-9-20181104 -c z1.f90 -fcoarray=single
z1.f90:6:0:

6 |   a = a(1)
  |
internal compiler error: in gfc_walk_array_ref, at fortran/trans-array.c:10574
0x6ce074 gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*)
../../gcc/fortran/trans-array.c:10574
0x6ce920 gfc_walk_expr(gfc_expr*)
../../gcc/fortran/trans-array.c:10886
0x6fc5f7 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10185
0x6bf54f trans_code
../../gcc/fortran/trans.c:1822
0x72d10f gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2066
0x6bf6f7 trans_code
../../gcc/fortran/trans.c:1918
0x72e269 gfc_trans_select_type_cases
../../gcc/fortran/trans-stmt.c:2674
0x72e269 gfc_trans_select_type(gfc_code*)
../../gcc/fortran/trans-stmt.c:3383
0x6bf787 trans_code
../../gcc/fortran/trans.c:1938
0x72d10f gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2066
0x6bf6f7 trans_code
../../gcc/fortran/trans.c:1918
0x6e6e14 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6509
0x6740a6 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x6740a6 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6bc03f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug c/87879] -Wformat-nonliteral could see more things as literals

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
You'd need dataflow information that's not available at that point in the 
front end to know that the initializer is indeed the value of fmt at that 
point in the code.

[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags

[thiago at kde dot org]

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

--- Comment #6 from Thiago Macieira  ---
Clang is not affected:

$ clang -dM -E -xc /dev/null -march=sandybridge -march=native | grep AVX
#define __AVX2__ 1
#define __AVX__ 1
$ clang -dM -E -xc /dev/null -march=native  -march=sandybridge | grep AVX
#define __AVX__ 1

Instead of enabling the CPU features your CPU has, Clang tries to guess which
CPU you have and will apply it. This has side-effects for non-arch-specific
items like AES.

ICC is similarly affected, despite claiming it isn't:

$ icc -dM -E -xc /dev/null -march=sandybridge  -march=native | grep AVX
icc: command line warning #10121: overriding '-march=sandybridge' with
'-march=native'
icc: command line warning #10121: overriding '-march=sandybridge' with
'-march=native'
#define __AVX_I__ 1
#define __AVX__ 1
#define __AVX2__ 1
$ icc -dM -E -xc /dev/null -march=native -march=sandybridge | grep AVX  
icc: command line warning #10121: overriding '-march=native' with
'-march=sandybridge'
#define __AVX_I__ 1
#define __AVX__ 1
#define __AVX2__ 1

It says it's overriding, but doesn't override.

[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags

[thiago at kde dot org]

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

Thiago Macieira  changed:

   What|Removed |Added

 CC||thiago at kde dot org

--- Comment #5 from Thiago Macieira  ---
Same thing here. User passes CFLAGS="-march=native" for their system, but
library needs to build one .cpp source with -march=haswell for additional
functionality (runtime-checked via CPUID). Unfortunately, -march=native
supersedes all other -march options, regardless of order, unlike all other
options.

Examples:
$ gcc -dM -E -xc /dev/null -march=sandybridge -march=haswell  | grep AVX 
#define __AVX__ 1
#define __AVX2__ 1
$ gcc -dM -E -xc /dev/null -march=haswell -march=sandybridge  | grep AVX
#define __AVX__ 1

$ gcc -dM -E -xc /dev/null -march=sandybridge -march=native | grep AVX
#define __AVX__ 1
#define __AVX2__ 1
$ gcc -dM -E -xc /dev/null -march=native  -march=sandybridge | grep AVX
#define __AVX__ 1
#define __AVX2__ 1

Qt is affected: https://bugreports.qt.io/browse/QTBUG-71564. The problem began
when we switched from appending -mavx2 to appending -march=haswell, so we'd get
FMA and BMI1/2 in the same file.

[Bug tree-optimization/87885] New: ICE in release_ssa_name_fn with -fprofile-report

[marxin at gcc dot gnu.org]

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

Bug ID: 87885
   Summary: ICE in release_ssa_name_fn with -fprofile-report
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Starting from r247882 I see:

$ ./xgcc -B. /tmp/ice.ii -c -fprofile-report -O  -c -Wall
during GIMPLE pass: fre
/tmp/ice.ii: In function ‘void ai()’:
/tmp/ice.ii:43:6: internal compiler error: Segmentation fault
   43 | void ai() {
  |  ^~
0x1466f7e crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:325
0x76bc310f ???
   
/usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x153c78f estimate_move_cost(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/tree-inline.c:3780
0x153d2b3 estimate_num_insns(gimple*, eni_weights*)
/home/marxin/Programming/gcc/gcc/tree-inline.c:4087
0x14dc9aa gimple_account_profile_record
/home/marxin/Programming/gcc/gcc/tree-cfg.c:8811
0xd63ddd account_profile_record(profile_record*, int)
/home/marxin/Programming/gcc/gcc/cfghooks.c:1475
0x12eccac check_profile_consistency
/home/marxin/Programming/gcc/gcc/passes.c:1757

$ cat ice.ii

template  class a {};
template  class b;
template  struct c;
template  struct c> {
  using d = a;
  using e = g;
  using f = long;
  static e aa(d, f);
};
struct h : c> {};
struct i {
  struct j {
int k;
j(j &&) { k = int(); }
  };
  struct l : a, j {};
  i(i &&) = default;
  ~i() {
long ab = m.k;
m.k ? h::aa(m, ab) : int();
  }
  l m;
};
class n : i {
public:
  n(long);
};
class q {
public:
  template  q(o, o, p);
  n ae() {
{
  n r(2);
  return r;
}
  }
};
template  void operator<<(b, s p2)
{
  p2.ae();
}
template  class b {};
double ah;
void ai() {
  q aj(ah, ah, ai);
  b ak;
  ak << aj;
}


The problem is that we call estimate_run_insns for a gimple statement that has
a SSA NAME in free list

[Bug c++/86574] ICE on std::prev with ranges::view::transform

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #5 from ensadc at mailnesia dot com ---
Duplicate of bug 86212 or bug 87814?

[Bug middle-end/87813] sprintf pass calling evrp at -O0 and setting global ranges which affect strnlen expansion

[aldyh at redhat dot com]

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

--- Comment #10 from Aldy Hernandez  ---
On 11/5/18 11:06 AM, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87813
> 
> --- Comment #9 from Martin Sebor  ---
> (In reply to Aldy Hernandez from comment #6)
> 
> I agree, but it's just a small subset of such cases.  There are many 
> optimizing
> transformations that GCC does at -O0 that affect the IL later on: calls to
> library built-ins are folded into other library calls (strcpy to memcpy), or 
> to
> MEM_REFs (memcpy), or even to constants (strlen).  For example:
> 
>int f (void)
>{
>  return __builtin_strlen ("123");
>}
> 

Yes, but in this -Og evrp case, the IL gets changed for *every* SSA name 
with a range.  That's rather significant IMO.

But alas, Jeff is working on this :).

[Bug c++/87814] [9 Regression] ICE in in tsubst_copy, at cp/pt.c:15962 with range-v3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-05
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
commit 9261bbbee3c2aa7be2cb37d358fa7c53dd4b3271
Author: jason 
Date:   Fri Jun 1 20:49:27 2018 +

* pt.c (instantiate_decl): Any defaulted function is defined.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@261084
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/87469] [9 Regression] ice in record_estimate, at tree-ssa-loop-niter.c:3271

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Assuming fixed.

[Bug tree-optimization/86572] unsafe strlen folding of const arguments with non-const offset

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

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

--- Comment #5 from Andreas Schwab  ---
This breaks aarch64 -mabi=ilp32.

/opt/gcc/gcc-20181105/gcc/testsuite/gcc.dg/warn-strlen-no-nul.c:56:1: error:
type mismatch in binary expression
int

int

sizetype

_1 = i1 + 1;
/opt/gcc/gcc-20181105/gcc/testsuite/gcc.dg/warn-strlen-no-nul.c:56:1: internal
compiler error: verify_gimple failed
0xbf4f43 verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5082
0x91dd7b gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:12859
0x91e04b gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:12949
0x769ecb cgraph_node::analyze()
../../gcc/cgraphunit.c:667
0x76cf13 analyze_functions
../../gcc/cgraphunit.c:1126
0x76e033 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2833

[Bug sanitizer/87884] New: ubsan causes wrong -Wformat-overflow warning

[stsp at users dot sourceforge.net]

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

Bug ID: 87884
   Summary: ubsan causes wrong -Wformat-overflow warning
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 44959
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44959=edit
test case

Hello.

Attached is the reduced test-case.
It gives:
---
gcc -c -Wall -fsanitize=undefined -O2 mangle.c -I.
mangle.c: In function 'name_convert':
mangle.c:57:3: warning: null destination pointer [-Wformat-overflow=]
   sprintf(s,"%s","test");
---

Which is wrong.
Plus, I am not sure if "-Wformat-overflow=" is a
correct switch for this type of warning.

[Bug middle-end/87813] sprintf pass calling evrp at -O0 and setting global ranges which affect strnlen expansion

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
(In reply to Aldy Hernandez from comment #6)

I agree, but it's just a small subset of such cases.  There are many optimizing
transformations that GCC does at -O0 that affect the IL later on: calls to
library built-ins are folded into other library calls (strcpy to memcpy), or to
MEM_REFs (memcpy), or even to constants (strlen).  For example:

  int f (void)
  {
return __builtin_strlen ("123");
  }

[Bug middle-end/87869] Unrolled loop leads to excessive code bloat with -Os on ARC EM.

[nbowler at draconx dot ca]

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

--- Comment #4 from Nick Bowler  ---
(In reply to Richard Biener from comment #3)
> I think a better target for optimizing would be the RTL side,
[...]
> I'm sure arc can store to a register address as well.

Yes, if the shortest possible store encoding were used on ARC instead of
the longest possible encoding, then the unrolled loop would not be nearly
as painful, e.g.,

 :
   0:   40c3 f000   mov_s   r0,0xf000
   6:   732cmov_s   r1,3
   8:   a020st_sr1,[r0,0]
   a:   a021st_sr1,[r0,0x4]
   c:   a022st_sr1,[r0,0x8]
   e:   a023st_sr1,[r0,0xc]
  10:   a024st_sr1,[r0,0x10]
  12:   a025st_sr1,[r0,0x14]
  14:   a026st_sr1,[r0,0x18]
  16:   a027st_sr1,[r0,0x1c]
  18:   a028st_sr1,[r0,0x20]
  1a:   a029st_sr1,[r0,0x24]
  1c:   a02ast_sr1,[r0,0x28]
  1e:   7ee0j_s [blink]

[Bug middle-end/87813] sprintf pass calling evrp at -O0 and setting global ranges which affect strnlen expansion

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
Aldy -- fixing that is a TODO for stage3.

[Bug target/87883] New: [ARM] ICE: Segmentation fault in arm_regno_class

[jozef.l at mittosystems dot com]

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

Bug ID: 87883
   Summary: [ARM] ICE: Segmentation fault in arm_regno_class
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jozef.l at mittosystems dot com
  Target Milestone: ---

Querying REGNO_REG_CLASS, from reginfo.c init_reg_sets, with an argument > 15
causes a segfault for arm-unknown-eabi.

For example, after applying the following contrived patch, a build of GCC seg
faults when running self-tests.

diff --git a/gcc/reginfo.c b/gcc/reginfo.c
index 33befa5..3fce076 100644
--- a/gcc/reginfo.c
+++ b/gcc/reginfo.c
@@ -165,6 +165,8 @@ init_reg_sets (void)
if (int_reg_class_contents[i][j / 32]
& ((unsigned) 1 << (j % 32)))
  SET_HARD_REG_BIT (reg_class_contents[i], j);
+   else
+ gcc_assert (REGNO_REG_CLASS (j) > -1);
 }

   /* Sanity check: make sure the target macros FIXED_REGISTERS and

> ./gcc/xgcc -B./gcc/ -xc -nostdinc /dev/null -S -o /dev/null 
> -fself-test=../../gcc/testsuite/selftests
> cc1: internal compiler error: Segmentation fault
> cc1: internal compiler error: Segmentation fault
> 0xc33ebf crash_signal
>   ../../gcc/toplev.c:325
> 0xc33ebf crash_signal
>   ../../gcc/toplev.c:325
> 0xfc3fba bitmap_check_index
>   ../../gcc/sbitmap.h:105
> 0xfc3fba bitmap_bit_p
>   ../../gcc/sbitmap.h:120
> 0xfc3fba arm_regno_class(int)
>   ../../gcc/config/arm/arm.c:23757
> 0xfc3fba bitmap_check_index
>   ../../gcc/sbitmap.h:105
> 0xfc3fba bitmap_bit_p
>   ../../gcc/sbitmap.h:120
> 0xfc3fba arm_regno_class(int)
>   ../../gcc/config/arm/arm.c:23757
> 0xb986a3 init_reg_sets()
>   ../../gcc/reginfo.c:169
> 0x616b7d general_init
>   ../../gcc/toplev.c:1171

This can also be observed when debugging the failing self-test invocation in
GDB

> ./gcc/xgcc -B./gcc/ -xc -nostdinc /dev/null -S -o /dev/null \
>   -fself-test=../../gcc/testsuite/selftests -wrapper gdb,--args

Breakpoint 2, init_reg_sets () at ../../gcc/reginfo.c:153
153 {
(gdb) call arm_regno_class(15)
$1 = NO_REGS
(gdb) call arm_regno_class(16)  

Program received signal SIGSEGV, Segmentation fault.
arm_regno_class (regno=16) at ../../gcc/config/arm/arm.c:23757
23757 if (IS_VFP_REGNUM (regno))

Observed on current trunk, gcc-8-branch and gcc-7-branch.
Bootstrap for x86_64-pc-linux-gnu, and a regular build for msp430-elf complete
successfully with the above patch.

[Bug tree-optimization/87873] [9 Regression] ICE: verify_gimple failed (error: incompatible types in PHI argument 0)

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Nov  5 14:55:53 2018
New Revision: 265812

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

PR tree-optimization/87873
* tree-ssa-loop-manip.h (split_loop_exit_edge): Add copy_constants_p
argument.
* tree-ssa-loop-manip.c (split_loop_exit_edge): Likewise.
* tree-vect-loop.c (vect_transform_loop): When splitting the
loop exit also create forwarder PHIs for constants.
* tree-vect-loop-manip.c (slpeel_duplicate_current_defs_from_edges):
Handle constant to_arg, add extra checking we match up the correct
PHIs.

* gcc.dg/pr87873.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr87873.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-manip.c
trunk/gcc/tree-ssa-loop-manip.h
trunk/gcc/tree-vect-loop-manip.c
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/87873] [9 Regression] ICE: verify_gimple failed (error: incompatible types in PHI argument 0)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug ada/87688] [9 regression] ACATS cb1010a cb1010d failure

[simon at pushface dot org]

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

--- Comment #5 from simon at pushface dot org ---
Bug no longer present in gcc version 9.0.0 20181103 (experimental) (GCC).
r265766.

[Bug sanitizer/87880] [9 regression] All macOS asan execution tests FAIL

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #4)
> > --- Comment #3 from Dominique d'Humieres  ---
> >> Weird: can you check where the definition of
> >> ___cxa_rethrow_primary_exception is coming from in your case?  On my
> >> 10.14.2 Beta1 system, I only found it in libc++abi.1.dylib.
> >
> > I see
> >
> > % nm x86_64-apple-darwin18.2.0/libsanitizer/asan/.libs/libasan.5.dylib | 
> > grep
> > cxa_rethrow_primary_exception
> > 000c73b0 s __ZL44substitution___cxa_rethrow_primary_exception
> >  U ___cxa_rethrow_primary_exception
> > 00018170 t _wrap___cxa_rethrow_primary_exception
> 
> Right, that's the reference from libasan.  However, this needs to be
> resolved from somewhere at runtime, and I don't see how this would happen.

if you can invoke a failing test with
DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 (+DYLD_LIBRARY_PATH if needed) ..
then the binding printout should show you where it's trying to resolve it from.

Looking at otool -lv will show you the load commands for the referenced libs.

===

The 10.6 fails are repeatable for me - good to hear 10.7/darwin11 is OK - I
need to figure out when the lib transitioned from working => non-working (might
be something associated with 64b code being run from a 32b kernel).

[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions

[iains at gcc dot gnu.org]

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

--- Comment #71 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #70)

> 
> powerpc64 darwin is *much* less tested than the 32b variant.
> 
> I don't have any access to my ppc64 machine for the next week but... it
> looks like our gcc exes are now getting too big for the 'our of the tin'
> linker.
> 
> The Apple ld64 impl. was quite broken for liner branch islanding on ppc64 -
> there were some work-arounds from the mac ports / fink folks.  However, I
> actually spent some time on it and more or less re-wrote the
> branch-islanding code - that code / and a bootstrap toolchain is available
> from my github account.  
> 
> https://github.com/iains/darwin-xtools (code)
> https://github.com/iains/darwin-gcc-5/releases (release for 5.3)
> 
> I have a bunch of updates locally - but need to be cleaned up and released
> .. time as ever the issue there.

caveats:
1. I have used these tools to build large 32b exes ( > 120Mb linked size)
2. the branch code and the relocations are the same for powerpc64 as for
powerpc on Darwin9 - so one might expect it to 'just work' using those
tools
.. but it hasn't been tested .. and as they say "if it ain't tested, it's
broke".

If it doesn't work for you - please file something on my github issues - it's
nothing to do with GCC :)

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #9 from Richard Biener  ---
Looks like combine doesn't want

(insn 11 10 13 2 (parallel [
(set (reg:QI 91)
(ior:QI (mem/c:QI (plus:SI (reg/f:SI 16 argp)
(const_int 4 [0x4])) [4 x+0 S1 A32])
(reg:QI 90 [ *b_3(D) ])))
(clobber (reg:CC 17 flags))
]) "t.c":12:11 429 {*iorqi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

for a combination (on x86_64 with -m32).

(insn 13 11 15 2 (parallel [
(set (reg:QI 93)
(and:QI (reg:QI 91)
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) "t.c":12:11 396 {*andqi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:QI 91)
(nil
(insn 15 13 16 2 (parallel [
(set (reg:QI 95)
(and:QI (reg:QI 90 [ *b_3(D) ])
(const_int -2 [0xfffe])))
(clobber (reg:CC 17 flags))
]) "t.c":12:11 396 {*andqi_1}
 (expr_list:REG_DEAD (reg:QI 90 [ *b_3(D) ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 16 15 17 2 (parallel [
(set (reg:QI 96)
(ior:QI (reg:QI 95)
(reg:QI 93)))
(clobber (reg:CC 17 flags))
]) "t.c":12:11 429 {*iorqi_1}
 (expr_list:REG_DEAD (reg:QI 95)
(expr_list:REG_DEAD (reg:QI 93)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)

Trying 11, 15, 13 -> 16:
   11: {r91:QI=[argp:SI+0x4]|r90:QI;clobber flags:CC;}
  REG_UNUSED flags:CC
   15: {r95:QI=r90:QI&0xfffe;clobber flags:CC;}
  REG_DEAD r90:QI
  REG_UNUSED flags:CC
   13: {r93:QI=r91:QI&0x1;clobber flags:CC;}
  REG_UNUSED flags:CC
  REG_DEAD r91:QI
   16: {r96:QI=r95:QI|r93:QI;clobber flags:CC;}
  REG_DEAD r95:QI
  REG_DEAD r93:QI
  REG_UNUSED flags:CC
Failed to match this instruction:
(parallel [
(set (reg:QI 96)
(ior:QI (and:QI (mem/c:QI (plus:SI (reg/f:SI 16 argp)
(const_int 4 [0x4])) [4 x+0 S1 A32])
(const_int 1 [0x1]))
(reg:QI 90 [ *b_3(D) ])))
(clobber (reg:CC 17 flags))
])
Failed to match this instruction:
(set (reg:QI 96)
(ior:QI (and:QI (mem/c:QI (plus:SI (reg/f:SI 16 argp)
(const_int 4 [0x4])) [4 x+0 S1 A32])
(const_int 1 [0x1]))
(reg:QI 90 [ *b_3(D) ])))
Failed to match this instruction:
(set (reg:QI 95)
(and:QI (mem/c:QI (plus:SI (reg/f:SI 16 argp)
(const_int 4 [0x4])) [4 x+0 S1 A32])
(const_int 1 [0x1])))

looks like it doesn't try to "factor" out the load?

[Bug c++/87882] New: -Wredundant-move false positive

[its at cleroth dot com]

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

Bug ID: 87882
   Summary: -Wredundant-move false positive
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: its at cleroth dot com
  Target Milestone: ---

Warning suggests to remove `std::move` on `Foo::Bar()` despite it producing
different code:

> #include 
> struct Foo {
>   Foo Bar() {
> return std::move(*this);
>   }
>   Foo Baz() {
> return *this;
>   }
>   std::string s;
> };
> void Move(Foo & f)
> {
> f = Foo{}.Bar();
> }
> void NoMove(Foo & f)
> {
> f = Foo{}.Baz();
> }

[Bug tree-optimization/87859] [8/9 Regression] store-merging miscompilation of mesa

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  5 14:12:15 2018
New Revision: 265807

URL: https://gcc.gnu.org/viewcvs?rev=265807=gcc=rev
Log:
PR tree-optimization/87859
* gimple-ssa-store-merging.c (struct merged_store_group): Add
first_nonmergeable_order member.
(merged_store_group::merged_store_group): Initialize them.
(imm_store_chain_info::coalesce_immediate_stores): Don't merge
stores with order >= first_nonmergeable_order.
Set merged_store->first_nonmergeable_order if we've skipped any
stores.  Attempt to merge overlapping INTEGER_CST stores that
we would otherwise skip.

* gcc.dg/store_merging_24.c: New test.
* gcc.dg/store_merging_25.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/store_merging_24.c
branches/gcc-8-branch/gcc/testsuite/gcc.dg/store_merging_25.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/gimple-ssa-store-merging.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/87837] [8/9 Regression] -O2 -fsanitize=signed-integer-overflow misses overflows on x86-64

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  5 14:11:32 2018
New Revision: 265806

URL: https://gcc.gnu.org/viewcvs?rev=265806=gcc=rev
Log:
PR sanitizer/87837
* match.pd (X + Y < X): Don't optimize if TYPE_OVERFLOW_SANITIZED.

* c-c++-common/ubsan/pr87837.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/c-c++-common/ubsan/pr87837.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/match.pd
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/87725] OpenMP 4.5 clause schedule(simd,monotonic:static) not understood

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  5 14:10:16 2018
New Revision: 265805

URL: https://gcc.gnu.org/viewcvs?rev=265805=gcc=rev
Log:
Backported from mainline
2018-10-25  Jakub Jelinek  

PR fortran/87725
* openmp.c (gfc_match_omp_clauses): Parse simd, monotonic and
nonmonotonic modifiers regardless of if they have been parsed
already or if the opposite one has.  Fix up check whether
comma after modifier should be parsed.
(resolve_omp_clauses): Diagnose schedule modifier restrictions.

* c-c++-common/gomp/schedule-modifiers-1.c (bar): Separate modifier
from kind with a colon rather than comma.
* gfortran.dg/gomp/schedule-modifiers-1.f90: New test.
* gfortran.dg/gomp/schedule-modifiers-2.f90: New test.

Added:
   
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/gomp/schedule-modifiers-1.f90
   
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/gomp/schedule-modifiers-2.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/openmp.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
   
branches/gcc-8-branch/gcc/testsuite/c-c++-common/gomp/schedule-modifiers-1.c

[Bug c++/86288] Recognize __gnu and/or __gnu__ as attribute-namespace

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  5 14:09:10 2018
New Revision: 265803

URL: https://gcc.gnu.org/viewcvs?rev=265803=gcc=rev
Log:
Backported from mainline
2018-10-24  Jakub Jelinek  

PR c++/86288
* parser.c (cp_parser_std_attribute): Canonicalize attr_ns, and when
:: is not present and attr_ns non-NULL, canonicalize also attr_id.
(cp_parser_attribute_spec): Fix comment typo.

* g++.dg/cpp0x/gen-attrs-66.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/gen-attrs-66.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/parser.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug middle-end/87647] [7/8 Regression] ICE on valid code in decode_addr_const, at varasm.c:2958

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  5 14:08:30 2018
New Revision: 265802

URL: https://gcc.gnu.org/viewcvs?rev=265802=gcc=rev
Log:
Backported from mainline
2018-10-20  Jakub Jelinek  

PR middle-end/87647
* varasm.c (decode_addr_const): Handle COMPOUND_LITERAL_EXPR.

* gcc.c-torture/compile/pr87647.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr87647.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/varasm.c

[Bug middle-end/85488] segmentation fault when compiling code using the ordered(n) clause in OpenMP 4.5

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  5 14:07:47 2018
New Revision: 265801

URL: https://gcc.gnu.org/viewcvs?rev=265801=gcc=rev
Log:
Backported from mainline
2018-10-19  Jakub Jelinek  

PR middle-end/85488
PR middle-end/87649
* omp-low.c (check_omp_nesting_restrictions): Diagnose ordered without
depend closely nested inside of loop with ordered clause with
a parameter.

* c-c++-common/gomp/doacross-2.c: New test.
* c-c++-common/gomp/sink-3.c: Expect another error during error
recovery.

Added:
branches/gcc-8-branch/gcc/testsuite/c-c++-common/gomp/doacross-2.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/omp-low.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/c-c++-common/gomp/sink-3.c

[Bug middle-end/87649] ICE in OpenMP doacross (ordered) loop

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  5 14:07:47 2018
New Revision: 265801

URL: https://gcc.gnu.org/viewcvs?rev=265801=gcc=rev
Log:
Backported from mainline
2018-10-19  Jakub Jelinek  

PR middle-end/85488
PR middle-end/87649
* omp-low.c (check_omp_nesting_restrictions): Diagnose ordered without
depend closely nested inside of loop with ordered clause with
a parameter.

* c-c++-common/gomp/doacross-2.c: New test.
* c-c++-common/gomp/sink-3.c: Expect another error during error
recovery.

Added:
branches/gcc-8-branch/gcc/testsuite/c-c++-common/gomp/doacross-2.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/omp-low.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/c-c++-common/gomp/sink-3.c

[Bug middle-end/18041] OR of two single-bit bitfields is inefficient

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
We're still "stuck" on GIMPLE, on x86_64 we manage to elide the redundant load
now and get

foo:
.LFB0:
.cfi_startproc
movzbl  (%rdi), %eax
movl%eax, %edx
shrb%dl
orl %eax, %edx
andl$-2, %eax
andl$1, %edx
orl %edx, %eax
movb%al, (%rdi)
ret

where we fail to notice the RMW.  A simpler testcase is

struct B { unsigned bit0 : 1; };

void
bar  (struct B *b, _Bool x)
{
  b->bit0 |= x;
}

which generates

bar:
.LFB0:
.cfi_startproc
movzbl  (%rdi), %eax
orl %eax, %esi
andl$-2, %eax
andl$1, %esi
orl %esi, %eax
movb%al, (%rdi)
ret

we'd need to recognize

(set (reg:QI 96)
(ior:QI (and:QI (reg:QI 90 [ *b_3(D) ])
 (const_int -2 [0xfffe])))
(and:QI (ior:QI (reg:QI 90 [ *b_3(D) ])
 (subreg:QI (reg:SI 98) 0))
 (const_int 1 [0x1]

(r90 & -2) | ((r90 | rx) & 1)
-> (r90 & -2) | (r90 & 1) | (rx & 1)
-> r90 | (rx & 1)

I have a patch for simplify-rtx.c that recognizes this generating

foo:
.LFB0:
.cfi_startproc
movzbl  (%rdi), %edx
movl%edx, %eax
shrb%al
andl$1, %eax
orl %edx, %eax
movb%al, (%rdi)
ret

and

bar:
.LFB1:
.cfi_startproc
andl$1, %esi
orb %sil, (%rdi)
ret

[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions

[iains at gcc dot gnu.org]

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

--- Comment #70 from Iain Sandoe  ---
(In reply to Douglas Mencken from comment #69)
> (In reply to Iain Sandoe from comment #64)
> > so all languages, m32/m64, --enable-checking=all,rtl,tree trunk bootstrap
> > completed without error (with the patch above + one to enable Ada to work on
> > Darwin9).
> 
> How do you build for ppc64? Because that’s what I got


I didn't :-) .. standard multilb build on powerpc-darwin builds (and tests) the
64b variants of the libraries - it doesn't build 64b tools.

> 
> ccache /Developer/usr/bin/g++-4.2 -m64 -std=gnu++98 -no-pie   -g  -DIN_GCC  
> -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
> -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
> -Wno-overlength-strings   -DHAVE_CONFIG_H  -o cc1 c/c-lang.o
> c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o
> c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o
> c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o
> c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o
> c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o
> c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o
> c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o
> c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o
> c-family/c-warn.o c-family/c-spellcheck.o darwin-c.o rs6000-c.o \
> cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
> ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
> ../libcpp/libcpp.a  -liconv ../libbacktrace/.libs/libbacktrace.a
> ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
> -L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./isl/.libs  -lisl
> -L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gmp/.libs
> -L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./mpfr/src/.libs
> -L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./mpc/src/.libs -lmpc
> -lmpfr -lgmp   -L./../zlib -lz
> ccache /Developer/usr/bin/g++-4.2 -m64 -std=gnu++98 -no-pie   -g  -DIN_GCC  
> -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
> -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
> -Wno-overlength-strings   -DHAVE_CONFIG_H  -o cc1plus \
> cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o 
> cp/constexpr.o
> cp/constraint.o cp/cp-gimplify.o cp/cp-objcp-common.o cp/cp-ubsan.o cp/cvt.o
> cp/cxx-pretty-print.o cp/decl.o cp/decl2.o cp/dump.o cp/error.o cp/except.o
> cp/expr.o cp/friend.o cp/init.o cp/lambda.o cp/lex.o cp/logic.o cp/mangle.o
> cp/method.o cp/name-lookup.o cp/optimize.o cp/parser.o cp/pt.o cp/ptree.o
> cp/repo.o cp/rtti.o cp/search.o cp/semantics.o cp/tree.o cp/typeck.o
> cp/typeck2.o cp/vtable-class-hierarchy.o attribs.o incpath.o
> c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
> c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o
> c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
> c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
> c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o
> c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o
> c-family/c-spellcheck.o darwin-c.o rs6000-c.o cc1plus-checksum.o
> libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a
> ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a  -liconv
> ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
> ../libdecnumber/libdecnumber.a 
> -L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./isl/.libs  -lisl
> -L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gmp/.libs
> -L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./mpfr/src/.libs
> -L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./mpc/src/.libs -lmpc
> -lmpfr -lgmp   -L./../zlib -lz
> ld: bl out of range (-17219580 max is +/-16M) from lookup_attribute(char
> const*, tree_node*)at 0x10106DA48 in __text of libbackend.a(stor-layout.o)
> to private_lookup_attribute(char const*, unsigned long, tree_node*)at
> 0x11A9C in __text of  attribs.o in lookup_attribute(char const*,
> tree_node*)from libbackend.a(stor-layout.o)
> collect2: ld returned 1 exit status
> make[3]: *** [cc1] Error 1
> make[3]: *** Waiting for unfinished jobs
> ld: bl out of range (-16777352 max is +/-16M) from
> gt_pch_nx_string_pool_data(void*) at 0x101271C9C in __text of
> libbackend.a(stringpool.o) to gt_pch_nx_lang_tree_node(void*) at 0x100271D0C
> in __text of  cp/tree.o in gt_pch_nx_string_pool_data(void*) from
> libbackend.a(stringpool.o)
> collect2: ld returned 1 exit status
> make[3]: *** [cc1plus] Error 1
> rm gcc.pod
> make[2]: *** [all-stage1-gcc] Error 2
> make[1]: *** [stage1-bubble] Error 2
> make: *** 

[Bug sanitizer/87860] [9 Regression] libsanitizer build fails on sparc64-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug sanitizer/87860] [9 Regression] libsanitizer build fails on sparc64-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Mon Nov  5 13:34:36 2018
New Revision: 265796

URL: https://gcc.gnu.org/viewcvs?rev=265796=gcc=rev
Log:
Fix build on sparc64-linux-gnu.

2018-11-05  Martin Liska  

PR sanitizer/87860
* sanitizer_common/sanitizer_linux.cc:  Cherry-pick upstream
r346129.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc

[Bug tree-optimization/87859] [8/9 Regression] store-merging miscompilation of mesa

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
> Now that I think about it, I think I could fix this differently by adding a
> flag to the store structures that it has been merged already, but I'll
> postpone that to next week, need to work on stage1 stuff this week.

Do you mean a flag that will enable to dump how a merge to struct looks like
before and after store merging.

Btw. do you also have a debug counter for store merging? If not, I would
consider adding one.

[Bug tree-optimization/87859] [8/9 Regression] store-merging miscompilation of mesa

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
I didn't have access to the preprocessed source and was lazy to prepare it
myself, so I just copied the corresponding structure definition without C++
ctors/dtors, figured out what I thought would be a bitset_t, and tried if I can
reproduce it with that.  As I could, I have cleaned that up and replaced the
fields so that they are named in a way to make it more readable what is going
on.
Now that I think about it, I think I could fix this differently by adding a
flag to the store structures that it has been merged already, but I'll postpone
that to next week, need to work on stage1 stuff this week.

[Bug tree-optimization/87859] [8/9 Regression] store-merging miscompilation of mesa

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #5)
> It got reported in http://bugzilla.redhat.com/1645400

Good, thus you nicely reduced the original source files!

[Bug tree-optimization/87859] [8/9 Regression] store-merging miscompilation of mesa

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
It got reported in http://bugzilla.redhat.com/1645400

[Bug tree-optimization/87859] [8/9 Regression] store-merging miscompilation of mesa

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Just out of curiosity, Jakub how did you get to the miscompilation?

[Bug sanitizer/87860] [9 Regression] libsanitizer build fails on sparc64-linux-gnu

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Fixed in libsanitizer mainline in:
https://reviews.llvm.org/rCRT346129

[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions

[dougmencken at gmail dot com]

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

--- Comment #69 from Douglas Mencken  ---
(In reply to Iain Sandoe from comment #64)
> so all languages, m32/m64, --enable-checking=all,rtl,tree trunk bootstrap
> completed without error (with the patch above + one to enable Ada to work on
> Darwin9).

How do you build for ppc64? Because that’s what I got

ccache /Developer/usr/bin/g++-4.2 -m64 -std=gnu++98 -no-pie   -g  -DIN_GCC   
-fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H  -o cc1 c/c-lang.o
c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o
c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o
c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o
c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o
c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o
c-family/c-spellcheck.o darwin-c.o rs6000-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a  -liconv ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a 
-L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./isl/.libs  -lisl
-L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gmp/.libs
-L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./mpfr/src/.libs
-L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./mpc/src/.libs -lmpc
-lmpfr -lgmp   -L./../zlib -lz
ccache /Developer/usr/bin/g++-4.2 -m64 -std=gnu++98 -no-pie   -g  -DIN_GCC   
-fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H  -o cc1plus \
  cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/class.o
cp/constexpr.o cp/constraint.o cp/cp-gimplify.o cp/cp-objcp-common.o
cp/cp-ubsan.o cp/cvt.o cp/cxx-pretty-print.o cp/decl.o cp/decl2.o cp/dump.o
cp/error.o cp/except.o cp/expr.o cp/friend.o cp/init.o cp/lambda.o cp/lex.o
cp/logic.o cp/mangle.o cp/method.o cp/name-lookup.o cp/optimize.o cp/parser.o
cp/pt.o cp/ptree.o cp/repo.o cp/rtti.o cp/search.o cp/semantics.o cp/tree.o
cp/typeck.o cp/typeck2.o cp/vtable-class-hierarchy.o attribs.o incpath.o
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o
c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o
c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o
c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o
c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o
c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o
c-family/c-spellcheck.o darwin-c.o rs6000-c.o cc1plus-checksum.o libbackend.a
main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a  -liconv
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a 
-L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./isl/.libs  -lisl
-L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./gmp/.libs
-L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./mpfr/src/.libs
-L/Volumes/hfsplushd/Development/gcc-toolchain/_build/./mpc/src/.libs -lmpc
-lmpfr -lgmp   -L./../zlib -lz
ld: bl out of range (-17219580 max is +/-16M) from lookup_attribute(char
const*, tree_node*)at 0x10106DA48 in __text of libbackend.a(stor-layout.o) to
private_lookup_attribute(char const*, unsigned long, tree_node*)at 0x11A9C
in __text of  attribs.o in lookup_attribute(char const*, tree_node*)from
libbackend.a(stor-layout.o)
collect2: ld returned 1 exit status
make[3]: *** [cc1] Error 1
make[3]: *** Waiting for unfinished jobs
ld: bl out of range (-16777352 max is +/-16M) from
gt_pch_nx_string_pool_data(void*) at 0x101271C9C in __text of
libbackend.a(stringpool.o) to gt_pch_nx_lang_tree_node(void*) at 0x100271D0C in
__text of  cp/tree.o in gt_pch_nx_string_pool_data(void*) from
libbackend.a(stringpool.o)
collect2: ld returned 1 exit status
make[3]: *** [cc1plus] Error 1
rm gcc.pod
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

[Bug tree-optimization/87873] [9 Regression] ICE: verify_gimple failed (error: incompatible types in PHI argument 0)

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
So the vectorizer issue is highlighted by the following assert.  It triggers
because scalar and if-converted loop do not have a 1:1 match in the number of
loop-closed PHIs.  And that happens because split_loop_exit_edge elides
copying of the PHI node with a constant argument.

diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index 1d1d1147696..b369200e15b 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -980,7 +980,12 @@ slpeel_duplicate_current_defs_from_edges (edge from, edge
to)
   else
{
  if (get_current_def (to_arg) == NULL_TREE)
-   set_current_def (to_arg, get_current_def (from_arg));
+   {
+ gcc_assert (types_compatible_p (TREE_TYPE (to_arg),
+ TREE_TYPE (get_current_def
+  (from_arg;
+ set_current_def (to_arg, get_current_def (from_arg));
+   }
}
   gsi_next (_from);
   gsi_next (_to);

we can keep the fragile code working by making split_loop_exit_edge also
copy constants (for the vectorizer use only).  Which also shows again
the code isn't prepared to handle constants here... (or rather constants
in one copy but not the other).

[Bug tree-optimization/79191] potentially truncating unsigned conversion defeats range propagation

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
(In reply to Eric Gallager from comment #4)
> Where exactly in the compiler is this optimization supposed to be done and

Eric, that's part of the problem. The optimization already exists in VRP, but
it is defeated by another optimization in match.pd. We could restrict the
match.pd optimization with single_use, although this might cause us to miss
other optimizations. If we replace Y=(unsigned long)(unsigned)X with
Y=X&4294967295, we could try and replace (unsigned)X<3 with Y<3 at the same
time, but it isn't clear how/where/when to do that (restrict the transformation
to single_use in match.pd and add the super special code in
tree-ssa-forwprop.c?). We could try and introduce some magic in VRP (without
value numbering, it could be, when processing X & 4294967295, checking the
other uses of X for a conversion to a 32-bit int and using its interval if
there is a suitable domination relation between the relevant statements), but
that seems hard and ugly. Basically the PR seems to be asking for a better idea
on where to perform this optimization ;-)

[Bug sanitizer/87875] Address sanitizer doen't work with nested functions with enabled stack-use-after-return check

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #7)
> Not also sure what happens if the executable and libraries don't need
> executable stack and you later dlopen some shared library that needs it
> (e.g. uses nested functions).  Don't remember if ld.so mprotects the main
> stack as well as all others.

Uff, looks complicated. I've just attached patch that greps for '[stack]' and
reads execute flags..

[Bug sanitizer/87875] Address sanitizer doen't work with nested functions with enabled stack-use-after-return check

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Attachment #44956|0   |1
is obsolete||

--- Comment #8 from Martin Liška  ---
Created attachment 44958
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44958=edit
Patch candidate v2

Patch where I use IsStackExecutable. Note that the function should be provided
an implementation for other targets as well.

[Bug other/82857] libbacktrace: please support binaries stripped with dwz -m (following the .gnu_debugaltlink)

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
Created attachment 44957
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44957=edit
WIP patch, follows .gnu_debugaltlink

[Bug bootstrap/87788] [9 Regression] Bootstrap fails for x86_64-apple-darwin* with default languages selection after D addition.

[mcccs at gmx dot com]

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

--- Comment #16 from MCCCS  ---
Hi, could you please change the component from "bootstrap"
to "d" ? The same error occurs during non-bootstrap
compiling too. Otherwise this is in the wrong category,
people might not see this and send duplicates.

[Bug target/86487] [7/8/9 Regression] insn does not satisfy its constraints on arm big-endian

[navyadeepika.garakapati at gmail dot com]

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

Navya  changed:

   What|Removed |Added

 CC||navyadeepika.garakapati@gma
   ||il.com

--- Comment #4 from Navya  ---
This bug has been fixed in current trunk gcc sources. 
r265398 is the patch ID which is fixing this.

[Bug sanitizer/87875] Address sanitizer doen't work with nested functions with enabled stack-use-after-return check

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Not also sure what happens if the executable and libraries don't need
executable stack and you later dlopen some shared library that needs it (e.g.
uses nested functions).  Don't remember if ld.so mprotects the main stack as
well as all others.

[Bug sanitizer/87875] Address sanitizer doen't work with nested functions with enabled stack-use-after-return check

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Martin Liška from comment #4)
> > Created attachment 44956 [details]
> > Patch candidate
> > 
> > @Jakub: What do you think about the suggested patch? May I attempt to
> > mainline it?
> 
> No, see above, that is not a good idea from security POV.
> You want to do that only if the real stack is executable.
> Dunno whether one should e.g. parse /proc/self/maps and find the stack in
> there, check the protection flags.

I see. So this one should be done at the place where a fake stack is created
(mmapped), right?

[Bug sanitizer/87875] Address sanitizer doen't work with nested functions with enabled stack-use-after-return check

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Martin Liška from comment #4)
> Created attachment 44956 [details]
> Patch candidate
> 
> @Jakub: What do you think about the suggested patch? May I attempt to
> mainline it?

No, see above, that is not a good idea from security POV.
You want to do that only if the real stack is executable.
Dunno whether one should e.g. parse /proc/self/maps and find the stack in
there, check the protection flags.

[Bug sanitizer/87875] Address sanitizer doen't work with nested functions with enabled stack-use-after-return check

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Note, it needs it executable only if the kernel would create an executable
stack normally (i.e. check PT_GNU_STACK segment headers or all libraries and
executable, or check if the real stack is executable or not).

--- Comment #4 from Martin Liška  ---
Created attachment 44956
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44956=edit
Patch candidate

@Jakub: What do you think about the suggested patch? May I attempt to mainline
it?

[Bug sanitizer/87875] Address sanitizer doen't work with nested functions with enabled stack-use-after-return check

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Note, it needs it executable only if the kernel would create an executable
stack normally (i.e. check PT_GNU_STACK segment headers or all libraries and
executable, or check if the real stack is executable or not).

[Bug sanitizer/87875] Address sanitizer doen't work with nested functions with enabled stack-use-after-return check

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
So I can confirm it's caused by nested functions, more precisely by nested
function trampolines as documented here:
https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html

```
GCC has traditionally supported nested functions by creating an executable
trampoline at run time when the address of a nested function is taken. This is
a small piece of code which normally resides on the stack, in the stack frame
of the containing function. The trampoline loads the static chain register and
then jumps to the real address of the nested function.
```

Which means the FakeStack has to really have PROT_EXEC. It will require
mainline change in libsanitizer.

[Bug ipa/87706] Inlined functions trigger invalid -Wmissing-profile warning

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Jan Hubicka from comment #2)
> cow is already dead at profile time (if it would not, we would end up using
> the counter). It seems to me that one remove unreachable code pass is
> missing.
> We used to remove unreachable code after early optimizations. Why we don't
> do that anymore?

Which pass name was it?

[Bug c/87868] testsuite/c-c++-common/pr60101.c with -O3 and ubsan

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
You attached the patch to bad PR.

[Bug tree-optimization/87859] [8/9 Regression] store-merging miscompilation of mesa

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Nov  5 10:28:19 2018
New Revision: 265794

URL: https://gcc.gnu.org/viewcvs?rev=265794=gcc=rev
Log:
PR tree-optimization/87859
* gimple-ssa-store-merging.c (struct merged_store_group): Add
only_constants and first_nonmergeable_order members.
(merged_store_group::merged_store_group): Initialize them.
(merged_store_group::do_merge): Clear only_constants member if
adding something other than INTEGER_CST store.
(imm_store_chain_info::coalesce_immediate_stores): Don't merge
stores with order >= first_nonmergeable_order.  Use
merged_store->only_constants instead of always recomputing it.
Set merged_store->first_nonmergeable_order if we've skipped any
stores.  Attempt to merge overlapping INTEGER_CST stores that
we would otherwise skip.

* gcc.dg/store_merging_24.c: New test.
* gcc.dg/store_merging_25.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/store_merging_24.c
trunk/gcc/testsuite/gcc.dg/store_merging_25.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog