[Bug c/90340] New: Not optimal code when compiling C library for vsnprintf, code size increase 17%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 Bug ID: 90340 Summary: Not optimal code when compiling C library for vsnprintf, code size increase 17% Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: fredrik.hederstie...@securitas-direct.com Target Milestone: --- Created attachment 46284 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46284=edit Testcase with example code from Linux C library When compiling some old Linux kernel library code for vsnprintf, the code generated seems not optimal, and code size increased almost 17% for Cortex.M. This was starting with gcc-9.1.0, previous versions did not show this. (Generally when testing against CSiBE the overall average code size increased with gcc-9.1.0 compared to previous version for the first time since gcc-4.6.0) http://gcc.hederstierna.com/csibe/ Attached stripped example file from Linux library. Compliled with -Os (makefile attached) Gcc-8.2.0 generated more compact code size 806 bytes, Gcc-9.1.0 generated some large switch table code size 942 bytes. Difference is +136 bytes (+16.9%).
[Bug sanitizer/90337] sanitizer_linux.cc Fails to compile on Illumos-derived Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90337 --- Comment #7 from Andrew Pinski --- (In reply to Fazal Majid from comment #6) > @Andrew Pinski > > I looked for the files in question at https://github.com/google/sanitizers > and couldn't find them, so I assumed they were the GCC-specific port of the > LLVM sanitizer code. That is because upstream is part of the LLVM compiler-rt repo now. E.g. https://github.com/llvm-mirror/compiler-rt/blob/master/lib/sanitizer_common/sanitizer_linux.cc
[Bug libobjc/90268] compile failure for gcc9, missing libtool in that directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90268 Carl Hansen changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Carl Hansen --- That was prerelease. the actual release doesn't have problem. (Might have been local error) close bug
[Bug sanitizer/90337] sanitizer_linux.cc Fails to compile on Illumos-derived Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90337 --- Comment #6 from Fazal Majid --- @Andrew Pinski I looked for the files in question at https://github.com/google/sanitizers and couldn't find them, so I assumed they were the GCC-specific port of the LLVM sanitizer code.
[Bug c/86407] Ignore function attributes in function type declarations?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86407 --- Comment #5 from Alex Henrie --- The fundamental problem here is that some people want to combine calling convention attributes and certain other attributes in a macro and then use that macro everywhere, whereas other people want to place each attribute only where it technically belongs. To make both groups happy, we need more granular warning options. One possible solution is to add -Wattribute= and -Wno-attribute= switches for enabling and disabling warnings about specific attributes. For example, Wine could set `-Wno-attribute=ms_hook_prologue` to get warnings about all attributes except the __ms_hook_prologue__ attribute and then include that attribute in the WINAPI macro. Being able to disable warnings about particular attributes might also be useful if someone wants to change the calling convention of all functions that return a particular type. In that case it might be helpful to have a macro like "#define INT64 long long __attribute__((__cdecl__))", use it to declare both functions and variables, and then ignore warnings about __cdecl__ being in more places than it needs to be. Another possible solution is to split off warnings about function attributes being used on function pointers (presumably in addition to the function definitions) into a new option such as -Wstrict-function-attributes to let people turn off just that warning specifically. Either way, __force_align_arg_pointer__ should be changed from a type attribute to a function attribute, and the syntax for suppressing warnings should be the same or similar for both __ms_hook_prologue__ and __force_align_arg_pointer__.
[Bug sanitizer/90337] sanitizer_linux.cc Fails to compile on Illumos-derived Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90337 --- Comment #5 from Fazal Majid --- Yet another compile issue: mordac ~/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libsanitizer/sanitizer_common>/bin/ksh ../libtool --tag=CXX --mode=compile /home/majid/build/gcc-9.1.0/obj/./gcc/xgcc -shared-libgcc -B/home/majid/build/gcc-9.1.0/obj/./gcc -nostdinc++ -L/home/majid/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libstdc++-v3/src -L/home/majid/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libstdc++-v3/src/.libs -L/home/majid/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-solaris2.11/bin/ -B/usr/local/x86_64-pc-solaris2.11/lib/ -isystem /usr/local/x86_64-pc-solaris2.11/include -isystem /usr/local/x86_64-pc-solaris2.11/sys-include -fchecking=1 -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../../../../libsanitizer/sanitizer_common -I.. -I ../../../../libsanitizer/include -isystem ../../../../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-solaris2.11 -I../../../../libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I ../../../../libsanitizer/../libbacktrace -I ../libbacktrace -I ../../../../libsanitizer/../include -include ../../../../libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -MT sanitizer_posix_libcdep.lo -MD -MP -MF .deps/sanitizer_posix_libcdep.Tpo -c -o sanitizer_posix_libcdep.lo ../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc libtool: compile: /home/majid/build/gcc-9.1.0/obj/./gcc/xgcc -shared-libgcc -B/home/majid/build/gcc-9.1.0/obj/./gcc -nostdinc++ -L/home/majid/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libstdc++-v3/src -L/home/majid/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libstdc++-v3/src/.libs -L/home/majid/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-solaris2.11/bin/ -B/usr/local/x86_64-pc-solaris2.11/lib/ -isystem /usr/local/x86_64-pc-solaris2.11/include -isystem /usr/local/x86_64-pc-solaris2.11/sys-include -fchecking=1 -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../../../../libsanitizer/sanitizer_common -I.. -I ../../../../libsanitizer/include -isystem ../../../../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-solaris2.11 -I../../../../libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I ../../../../libsanitizer/../libbacktrace -I ../libbacktrace -I ../../../../libsanitizer/../include -include ../../../../libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -MT sanitizer_posix_libcdep.lo -MD -MP -MF .deps/sanitizer_posix_libcdep.Tpo -c ../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc -fPIC -DPIC -o .libs/sanitizer_posix_libcdep.o ../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc: In function 'void __sanitizer::ReleaseMemoryPagesToOS(__sanitizer::uptr, __sanitizer::uptr)': ../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc:66:5: error: 'madvise' was not declared in this scope 66 | madvise((char *)beg_aligned, end_aligned - beg_aligned, | ^~~ That's because with these settings /usr/include/mman.h defines posix_madvise() but not advise().
[Bug sanitizer/90337] sanitizer_linux.cc Fails to compile on Illumos-derived Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90337 --- Comment #4 from Andrew Pinski --- Patches to sanitizer should be sent upstream first.
[Bug sanitizer/90337] sanitizer_linux.cc Fails to compile on Illumos-derived Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90337 --- Comment #3 from Fazal Majid --- Created attachment 46283 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46283=edit Patch for the glob_t issue
[Bug sanitizer/90337] sanitizer_linux.cc Fails to compile on Illumos-derived Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90337
--- Comment #1 from Fazal Majid ---
Another error, due to glob_t having gained some extra fields in newer versions
of Illumos (apparently based on BSD code contributed by Guide van Rossum).
Oracle Solaris:
typedef struct glob_t {
size_t gl_pathc; /* Count of paths matched by pattern */
char**gl_pathv; /* List of matched pathnames */
size_t gl_offs;/* # of slots reserved in gl_pathv */
/* following are internal to the implementation */
char**gl_pathp; /* gl_pathv + gl_offs */
int gl_pathn; /* # of elements allocated */
} glob_t;
Illumos (see also:
https://github.com/illumos/illumos-gate/commit/a5229c74bcec7e2b136379c59a46f4b0717fd516)
typedef struct glob_t {
/*
* Members specified by POSIX
*/
size_t gl_pathc; /* Total count of paths matched by pattern */
char**gl_pathv; /* List of matched pathnames */
size_t gl_offs;/* # of slots reserved in gl_pathv */
/*
* Internal-use members:
*
* NB: The next two members are carried in both the
* libc backward compatibility wrapper functions and
* the extended functions.
*/
char**gl_pathp; /* gl_pathv + gl_offs */
int gl_pathn; /* # of elements allocated */
/*
* Non-POSIX extensions
*
* NB: The following members are not carried in
* the libc backward compatibility wrapper functions.
*/
int gl_matchc; /* Count of paths matching pattern. */
int gl_flags; /* Copy of flags parameter to glob. */
struct stat **gl_statv; /* Stat entries corresponding to gl_pathv */
/*
* Alternate filesystem access methods for glob; replacement
* versions of closedir(3), readdir(3), opendir(3), stat(2)
* and lstat(2).
*/
void (*gl_closedir)(void *);
struct dirent *(*gl_readdir)(void *);
void *(*gl_opendir)(const char *);
int (*gl_lstat)(const char *, struct stat *);
int (*gl_stat)(const char *, struct stat *);
} glob_t;
Patch p2.txt addresses this
[Bug sanitizer/90337] sanitizer_linux.cc Fails to compile on Illumos-derived Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90337 --- Comment #2 from Fazal Majid --- Created attachment 46282 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46282=edit Patch for the O_DIRECTORY issue
[Bug c++/90335] ICE with lambda as cnttp in a templated struct (segfault). C++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90335 --- Comment #2 from Boris Rúra --- Created attachment 46281 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46281=edit More minimal example. Removing the templates from aliases makes the code compile.
[Bug c++/90339] New: Change default c++ dialect to -std=gnu++17 in gcc 10 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90339 Bug ID: 90339 Summary: Change default c++ dialect to -std=gnu++17 in gcc 10 ? Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, In today's release announcement https://gcc.gnu.org/ml/gcc/2019-05/msg00024.html C++17 is now marked as no longer experimental in gcc 9. Support has matured for a few years. Do you think it would make sense to change in gcc 10 the default dialect to -std=gnu++17 so that distro packages slowly adapt their code to be C++17 compatible ? For example we hit a few cases last year where some components were typedef'ing a type named "byte" which resulted in ambiguity when using -std=gnu++17 defining std::byte. Cheers, Romain
[Bug c++/90338] New: member function pointer non-type template parameter compile fail while matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90338
Bug ID: 90338
Summary: member function pointer non-type template parameter
compile fail while matching
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.a.moran at gmail dot com
Target Milestone: ---
Created attachment 46280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46280=edit
A reproduction of the issue described
The code in question compiled in 8.3.0, but fails in 9.1.0.
We have two template functions that each take one type template parameter and
one non-type template parameter. The first template function's non-type
template parameter is of a member function type, and the second template
function's non-type template parameter is it's type template parameter. (I
think this is clearer in the reproduction).
If you then call the first template function actually giving it a pointer to a
member function that exactly matches, but the class whose member function it is
is non-literal, you get a compile-failure (error below).
> repro.cpp:13:22: error: ‘B’ is not a valid type for a template non-type
> parameter because it is not literal
>13 | match();
> | ^
> repro.cpp:1:8: note: ‘B’ is not literal because:
> 1 | struct B {
> |^
> repro.cpp:1:8: note: ‘B’ is not an aggregate, does not have a trivial
> default constructor, and has no ‘constexpr’ constructor that is not a copy or
> move constructor
It appears that when it considers
template
void match();
as a match, it errors out based on the fact that you _couldn't_ pass your class
type as a non-type template parameter (even though you're making no attempt to
do so). If you make the class trivial so that this error doesn't happen, you
can see that it does choose the correct match().
[Bug sanitizer/90337] New: sanitizer_linux.cc Fails to compile on Illumos-derived Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90337
Bug ID: 90337
Summary: sanitizer_linux.cc Fails to compile on Illumos-derived
Solaris
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at sentfrom 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: ---
sanitizer_linux.cc fails to compile on SmartOS (based on the Illumos fork of
OpenSolaris), The reason is that O_DIRECTORY was added to Oracle Solaris 11
post-fork but is not present in Illumos distributions.
My workaround is:
--- sanitizer_linux.cc.dist Fri May 3 13:25:45 2019
+++ sanitizer_linux.cc Fri May 3 13:27:33 2019
@@ -929,6 +929,11 @@
char task_directory_path[80];
internal_snprintf(task_directory_path, sizeof(task_directory_path),
"/proc/%d/task/", pid);
+#if SANITIZER_SOLARIS
+#ifndef O_DIRECTORY
+#define O_DIRECTORY 0
+#endif
+#endif
descriptor_ = internal_open(task_directory_path, O_RDONLY | O_DIRECTORY);
if (internal_iserror(descriptor_)) {
Report("Can't open /proc/%d/task for reading.\n", pid);
Here is the error:
mordac
~/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libsanitizer/sanitizer_common>/bin/ksh
../libtool --tag=CXX --mode=compile /home/majid/build/gcc-9.1.0/obj/./gcc/xgcc
-shared-libgcc -B/home/majid/build/gcc-9.1.0/obj/./gcc -nostdinc++
-L/home/majid/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libstdc++-v3/src
-L/home/majid/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libstdc++-v3/src/.libs
-L/home/majid/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-solaris2.11/bin/ -B/usr/local/x86_64-pc-solaris2.11/lib/
-isystem /usr/local/x86_64-pc-solaris2.11/include -isystem
/usr/local/x86_64-pc-solaris2.11/sys-include -fchecking=1 -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../../../../libsanitizer/sanitizer_common -I.. -I
../../../../libsanitizer/include -isystem
../../../../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-solaris2.11
-I../../../../libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11
-DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I
../../../../libsanitizer/../libbacktrace -I ../libbacktrace -I
../../../../libsanitizer/../include -include
../../../../libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -MT
sanitizer_linux.lo -MD -MP -MF .deps/sanitizer_linux.Tpo -c -o
sanitizer_linux.lo ../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc
libtool: compile: /home/majid/build/gcc-9.1.0/obj/./gcc/xgcc -shared-libgcc
-B/home/majid/build/gcc-9.1.0/obj/./gcc -nostdinc++
-L/home/majid/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libstdc++-v3/src
-L/home/majid/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libstdc++-v3/src/.libs
-L/home/majid/build/gcc-9.1.0/obj/x86_64-pc-solaris2.11/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-pc-solaris2.11/bin/ -B/usr/local/x86_64-pc-solaris2.11/lib/
-isystem /usr/local/x86_64-pc-solaris2.11/include -isystem
/usr/local/x86_64-pc-solaris2.11/sys-include -fchecking=1 -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../../../../libsanitizer/sanitizer_common -I.. -I
../../../../libsanitizer/include -isystem
../../../../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-solaris2.11
-I../../../../libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11
-DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I
../../../../libsanitizer/../libbacktrace -I ../libbacktrace -I
../../../../libsanitizer/../include -include
../../../../libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -MT
sanitizer_linux.lo -MD -MP -MF .deps/sanitizer_linux.Tpo -c
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc -fPIC -DPIC -o
.libs/sanitizer_linux.o
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc: In constructor
'__sanitizer::ThreadLister::ThreadLister(__sanitizer::pid_t)':
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cc:932:63: error:
'O_DIRECTORY' was not declared in this scope
932 | descriptor_ = internal_open(task_directory_path, O_RDONLY |
O_DIRECTORY);
|
[Bug debug/90336] New: gcc generates wrong debug information at -O1 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90336
Bug ID: 90336
Summary: gcc generates wrong debug information at -O1 to -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
This is a recent regression. Gcc-8 works fine. Bisect points to r260253.
The expected value of "l_90" should be 852. With optimization, it prints "-1".
$ gcc-trunk -v
Thread model: posix
gcc version 10.0.0 20190503 (experimental) [trunk revision 270847] (GCC)
$ gdb -v
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
#Expected output#
$ gcc-trunk -g abc.c outer.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x4004ad: file abc.c, line 11.
Breakpoint 1, d (e=852) at abc.c:11
11optimize_me_not();
$1 = 852
#Wrong output at -O3#
$ gcc-trunk -g abc.c outer.c -O3
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400497: file abc.c, line 11.
Breakpoint 1, d (e=e@entry=852) at abc.c:11
11optimize_me_not();
$1 = -1
$ cat abc.c
int a;
long b;
short c;
int d(e) {
int l_90 = -1L;
a & != (c = 0);
int *f, *g = _90, *i = _90;
*g = e;
int **h =
*h = i;
optimize_me_not();
if (b)
return a;
}
int main() { d(852); }
$ cat outer.c
void optimize_me_not() {}
$ cat cmds
b 11
r
p l_90
kill
q
[Bug rtl-optimization/90174] Bad register spill due to top-down allocation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174
--- Comment #4 from Vladimir Makarov ---
(In reply to Feng Xue from comment #0)
> Current regional RA uses a top-down allocation order, which may not properly
> split a long live range that crosses sub-region with high register pressure.
>
> In the following graph, lv0 is live in whole outer region, and suppose inner
> region is under high register pressure due to lots of live ranges inside it.
>
> According to RA algorithm, out region is processed firstly, lv0 is picked up
> as spill candidate. And then turn to inner region, also the part of lv0 in
> inner region is marked as being spilled. Finally result is that the whole
> lv0 should be spilled. But if in area excluding inner region, there is with
> low register pressure, we can get a better choice to place lv0 in register
> instead of memory, and only spill/reload lv0 at boundary of
> entry-into(A)/exist-from(B) inner region. In other word, inner region
> boundary are split points for lv0.
>
>
>|
>outer | lv0
>region | __ split point
>|/
> .--A---.
> | | |
> | | | | |
> | inner | | lv1 | |
> | region | | | |
> | | | lv2 | |
> | | | | |
> | | |
> '--B---'
>|\__
>|split point
>|
>
> Here is an example to show this. gcc produces bad spills as we point
> out(-m64 -O3, for x86-64), but llvm generates better spill/reload as we
> expect.
>
Thank you for your detailed report and proposed solutions.
I would say that top-down algorithm behaves better than bottom-up one. I
implemented Callahan-Koblentz (bottom-up algorithm) in GCC about 10 years ago
and it behaved worse than the current one. I think adding an additional pass
over regions probably would solve the problem but it will complicate already
complicated RA (which is about 60K lines now). In any case I'll think about
this problem.
The problem you are mentioning in this code is quite insignificant (one
memory access in the top most region).
I also checked the attachments. What I see is GCC generates a better big
loop body (a loop with high register pressure). GCC generated loop body has 50
x86-64 insns with 22 memory accesses vs 56 with 26 memory access for LLVM.
> int value[20];
>
> int user0;
> int user1;
> int user2[100];
> int user3;
>
> int fncall(void);
>
> void foo(int cond)
> {
> int lv_out = value[0];
> int i;
>
> user0 = lv_out; /* Better to place lv_out in register. */
>
> if (cond) {
> int sum = 0;
> int lv_in_1 = value[1];
> int lv_in_2 = value[2];
> int lv_in_3 = value[3];
> int lv_in_4 = value[4];
> int lv_in_5 = value[5];
> int lv_in_6 = value[6];
> int lv_in_7 = value[7];
> int lv_in_8 = value[8];
> int lv_in_9 = value[9];
> int lv_in_10 = value[10];
> int lv_in_11 = value[11];
> int lv_in_12 = value[12];
> int lv_in_13 = value[13];
> int lv_in_14 = value[14];
> int lv_in_15 = value[15];
>
> /* Better to spill lv_out here */
>
> for (i = 0; i < 1000; i++) {
> sum += lv_in_1;
> sum += lv_in_2;
> sum += lv_in_3;
> sum += lv_in_4;
> sum += lv_in_5;
> sum += lv_in_6;
> sum += lv_in_7;
> sum += lv_in_8;
> sum += lv_in_9;
> sum += lv_in_10;
> sum += lv_in_11;
> sum += lv_in_12;
> sum += lv_in_13;
> sum += lv_in_14;
> sum += lv_in_15;
>
> fncall();
>
> lv_in_1 ^= i;
> lv_in_2 ^= i;
> lv_in_3 ^= i;
> lv_in_4 ^= i;
> lv_in_5 ^= i;
> lv_in_6 ^= i;
> lv_in_7 ^= i;
> lv_in_8 ^= i;
> lv_in_9 ^= i;
> lv_in_10 ^= i;
> lv_in_11 ^= i;
> lv_in_12 ^= i;
> lv_in_13 ^= i;
> lv_in_14 ^= i;
> lv_in_15 ^= i;
> }
>
> /* Better to reload lv_out here */
>
> user1 = sum;
> }
>
> for (i = 0; i < 100; i++) {
> user2[i ^ 100] = lv_out; /* Better to place lv_out in register */
> }
>
> user3 = lv_out; /* Better to place lv_out in register */
> }
>
>
> For top-down allocation, we can only adjust inner region allocation result,
> but no way to refine decision that has been made on outside live-range, it
> is an intrinsic weakness of the top-down algorithm. To fix that, we may need
> to add a new
[Bug c++/90335] ICE with lambda as cnttp in a templated struct (segfault). C++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90335 --- Comment #1 from Boris Rúra --- gcc-9_1_0-release@1f54d412a51 Configured with: ../src/configure --prefix=/usr/gcc-trunk --enable-languages=c,c++ --disable-multilib --enable-checking=release --disable-nls --disable-bootstrap Thread model: posix gcc version 9.1.1 20190503 (GCC)
[Bug c++/90335] New: ICE with lambda as cnttp in a templated struct (segfault). C++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90335 Bug ID: 90335 Summary: ICE with lambda as cnttp in a templated struct (segfault). C++2a Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: boris.rura at gmail dot com Target Milestone: --- Created attachment 46279 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46279=edit Minimal example. Hello I've encountered this bug while trying out some C++2a features. Using a class with cnttp inside a templated structure and passing it a lambda doesn't work. Trying to pass a lambda generated by another lambda ICEs the compiler (segfault).
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.2 |10.0 --- Comment #25 from Jonathan Wakely --- Yes, that's why the bug is still open. Jakub's comment accompanied changing the target milestone from 9.1 to 9.2, because it wasn't fixed for 9.1. Changing it to 10, because it won't be done for 9.2 either.
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #94 from Zaak --- OK, great. I was confused by the target changing from 9.1 to 9.2. Thanks! On Fri, May 3, 2019 at 10:11 AM iains at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 > > --- Comment #93 from Iain Sandoe --- > (In reply to Jakub Jelinek from comment #91) > > GCC 9.1 has been released. > (In reply to Zaak from comment #92) > > Is my interpretation correct that the patch did not make it in time for > GCC > > 9.1? (I( want to make sure we're applying it in Homebrew if not.) > > the patch was applied before 9.1 branched, and is on the 9.1 branch. > see: https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00109.html > which was bootstrapped with xc10.2 command line tools and SDK. > > it needs applying to 8.x and 7.x - which will happen soon. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug libstdc++/61761] [C++11] std::proj returns incorrect values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61761
--- Comment #9 from Jonathan Wakely ---
Author: redi
Date: Fri May 3 19:25:05 2019
New Revision: 270859
URL: https://gcc.gnu.org/viewcvs?rev=270859=gcc=rev
Log:
Fix new testcase to not require std::copysign
Use __builtin_copysign{,f,l} when std::copysign isn't available.
PR libstdc++/61761
* testsuite/26_numerics/complex/proj.cc: Don't assume defines
std::copysign.
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/26_numerics/complex/proj.cc
[Bug c++/52119] [C++11] overflow in signed left shift isn't diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52119 --- Comment #17 from Jonathan Wakely --- Author: redi Date: Fri May 3 19:13:31 2019 New Revision: 270858 URL: https://gcc.gnu.org/viewcvs?rev=270858=gcc=rev Log: Avoid -Woverflow warning in __numeric_limits_integer This is the same fix as was done for std::numeric_limits in r183905. PR libstdc++/52119 * include/ext/numeric_traits.h (__glibcxx_min): Avoid integer overflow warning with -Wpedantic -Wsystem-headers. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/numeric_traits.h
[Bug other/90334] New: documentation for getting read-write SVN access is misleading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90334 Bug ID: 90334 Summary: documentation for getting read-write SVN access is misleading Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- https://www.gnu.org/software/gcc/svnwrite.html says: > If you already have an account on sourceware.org/gcc.gnu.org, ask > overse...@gcc.gnu.org to add access to the GCC repository. Since the email address was not a proper HTML link, I concluded that the HTTP-like text before that was also not linked, for whatever reason. Therefore I pasted sourceware.org/gcc.gnu.org to the URL bar of my browser and got redirected to https://sourceware.org/gcc.gnu.org, which says 404. Instead of using a slash for separating host names, the word "or" should be used.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 Thomas Koenig changed: What|Removed |Added CC||toon at moene dot org --- Comment #1 from Thomas Koenig --- (A reply to https://gcc.gnu.org/ml/fortran/2019-05/msg00021.html ; I want to have this in the PR's audit trail). Toon, I have added you to this because of your experience going back to g77, and also because you're a member of the steering committee. > I've debugged one of the packages and I > confirm that the breakage is related to passing of strings from C to > Fortran. Indeed, BLAS and LAPACK define a large number of subroutines > that take one or more explicit single-character strings as arguments. > Other than that, BLAS has only one function (xerbla), which takes a > string of unspecified length, LAPACK only has four (ilaenv, > ilaenv2stage, lsamen, xerbla). The C interfaces to BLAS/LAPACK from > Netlib depend on the historic behavior that explicit single-character > strings are interoperable, concretely CBLAS and LAPACKE provide C > interfaces/code that calls into Fortran BLAS/LAPACK without passing the > 1s as lengths of the character strings (functions taking a string of > unspecified length are trivial and re-implemented in C). OUCH. So, basically, people have been depending on C undefined behavior for ages, and this includes recent developments like LAPACKE. Only an accident of calling conventions has kept this "working". Oh my... If we are looking at the System V Application Binary Interface AMD64 Architecture Processor Supplement, I can understand how this worked. I suppose this never worked on Windows stdcall, where the callee cleans up the stack, so it must know the exact number of bytes, and the functions are therefore decorated with the number of bytes in the argument list. (By the way, interoperability has a special meaning in Fortran, where it is reserved for BIND(C) procedures and variables). > This has been > working fine for very many years as the Fortran code never needed to > access the length it knew was 1. R has been using the same practice, > which long predates ISO_C_BINDING/BIND(C), and I've seen online > discussions where people assumed interoperability of length 1 strings, > once mentioning also a citation from Fortran 2003 Handbook that says "A > Fortran character string with a length other than 1 is not > interoperable" (which invites interpretation that length 1 strings were > ). They are interoperable in the sense that they can be an argument to a BIND(C) procedure. This is the terminology used by the Fortran standard. > I am not an expert to say whether the current Fortran standard > requires that interoperability and I assume that it does not given this > gfortran change. What we are discussing here is outside the Fortran standard's scope. > This gfortran change breaks this interoperability: if a C function calls > a Fortran function, passing it a single-character string for a parameter > taking explicit single-character Fortran string, it may crash. I've > debugged one case with R package BDgraph, this example > "library(BDgraph); data.sim <- bdgraph.sim( n = 70, p = 5, size = 7, vis > = TRUE )" crashes due to corruption of C stack by Fortran function > DPOSV, when compiled with the new gfortran and with -O2. To see the > problem, one can just look at the disassembly of DPOSV (LAPACK), neither > the package nor R is not necessary: > > SUBROUTINE DPOSV( UPLO, N, NRHS, A, LDA, B, LDB, INFO ) > CHARACTER UPLO > > In one case, DPOSV calls DPOTRS before returning. The new gfortran with > -O2 performs tail-call optimization, jumping to DPOTRS. In the annotated > disassembly snippet, at 11747f1, DPOSV tries to ensure that there is > constant 1 as string length of UPLO when tail-calling into DPOTRS, so it > writes it to stack where there already should have been 1 as length of > UPLO passed to DPOSV. But this argument has not been passed to DPOSV, so > this causes stack corruption. [assembly elided] > Note that DPOSV never uses the length of the string (UPLO) from the > hidden argument, the compiler clearly knows that its length is 1. In > calls where the length is passed in registers, this does not cause > trouble (like LSAME) and indeed is needed as the registers have > different values > >IF( .NOT.LSAME( UPLO, 'U' ) .AND. .NOT.LSAME( UPLO, 'L' ) ) THEN > >117448: b9 01 00 00 00 mov$0x1,%ecx > >11744d: ba 01 00 00 00 mov$0x1,%edx > >117452: 48 8d 35 bb 12 09 00lea > 0x912bb(%rip),%rsi# 1a8714 > >117459: 4c 89 f7mov%r14,%rdi > >11745c: e8 1f 3d ef ff callq b180 > > but it seems to me that the compiler could just refrain from setting the > length to be 1 on the
[Bug c++/90333] New: Can't apply attributes to lambdas with trailing returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333
Bug ID: 90333
Summary: Can't apply attributes to lambdas with trailing
returns
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.a.moran at gmail dot com
Target Milestone: ---
In 8.3.0 we could do either one of these:
> []() __attribute__((always_inline)) -> int { return 0; }
> []() [[gnu::always_inline]] -> int { return 0; }
I understand that __attribute__ is a GCC extension, but it's my understanding
that the second one is standard behavior.
As of 9.1.0, the __attribute__ variant both fails with "expected '{' before
'->' token", and the [[gnu::always_inline]] variant fails because it's applying
the attribute to the trailing return type rather than the lambda.
I tried every possible position, but each fails
* __attribute__((always_inline)) []() -> int { return 0; }
* [[gnu::always_inline]] []() -> int { return 0; }
* These fail with "attributes at the beginning of statement are ignored"
* IE, it's not actually applying to the lambda.
* [] __attribute__((always_inline)) () -> int { return 0; }
* [] [[gnu::always_inline]] () -> int { return 0; }
* These fail with "expected '{' before '[' token" (or "__attribute__")
* []() __attribute__((always_inline)) -> int { return 0; }
* This fails with "expected '{' before '->' token
* []() [[gnu::always_inline]] -> int { return 0; }
* This fails with "attribute ignored"
* It is applying the attribute as an attribute of the return type
* []() -> __attribute__((always_inline)) int { return 0; }
* []() -> [[gnu::always_inline]] int { return 0; }
* This fails with "attribute does not apply to types"
* It is applying the attribute as an attribute of the return type
* []() -> int [[gnu::always_inline]] { return 0; }
* []() -> int __attribute__((always_inline)) { return 0; }
* This fails with "attribute does not apply to types"
* It is applying the attribute as an attribute of the return type
* []() -> int { return 0; } __attribute__((always_inline))
* Fails with "expected ';' before '__attribute__'"
* []() -> int { return 0; } [[gnu::always_inline]]
* Fails with "two consecutive '[' shall only introduce an attribute before
'[' token
It would appear that in 9.1.0 there's no way to specify attributes for a lambda
that has a trailing return type?
[Bug other/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #7 from Iain Sandoe --- (In reply to Matt Thompson from comment #6) > (In reply to Iain Sandoe from comment #5) > > (In reply to Matt Thompson from comment #4) > > > Also: I do have all the log files still, so if you'd like anything grep'ed > > > in there, let me know. > > > > not at this time.. I am trying to figure out what is different about our > > configurations. > > > > --- > > > > can you confirm that this was a clean build (including that the target > > install directory was deleted before the build?) > > It was a clean build. I always build out-of-source so it was a new directory > and I'd never installed GCC 9.1.0 before, so the install directory was new > as well. > > Let me try building again in a new directory with a new install location. Of > course, being the impressive GCC build, it might be Monday before I can > report back (it's a work laptop that stays at work). OK thanks, as it happens I won't be able to try on Darwin18 before next Weds, so no hurry.
[Bug other/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #6 from Matt Thompson --- (In reply to Iain Sandoe from comment #5) > (In reply to Matt Thompson from comment #4) > > Also: I do have all the log files still, so if you'd like anything grep'ed > > in there, let me know. > > not at this time.. I am trying to figure out what is different about our > configurations. > > --- > > can you confirm that this was a clean build (including that the target > install directory was deleted before the build?) It was a clean build. I always build out-of-source so it was a new directory and I'd never installed GCC 9.1.0 before, so the install directory was new as well. Let me try building again in a new directory with a new install location. Of course, being the impressive GCC build, it might be Monday before I can report back (it's a work laptop that stays at work).
[Bug other/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #5 from Iain Sandoe --- (In reply to Matt Thompson from comment #4) > Also: I do have all the log files still, so if you'd like anything grep'ed > in there, let me know. not at this time.. I am trying to figure out what is different about our configurations. --- can you confirm that this was a clean build (including that the target install directory was deleted before the build?)
[Bug other/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #3 from Matt Thompson --- For the grep: [(544) 01:48 PM] $ grep CFI gcc/auto-host.h /* Define 0/1 if your assembler supports CFI directives. */ #define HAVE_GAS_CFI_DIRECTIVE 0 #define HAVE_GAS_CFI_PERSONALITY_DIRECTIVE 1 #define HAVE_GAS_CFI_SECTIONS_DIRECTIVE 1 As for the other question, I didn't have any of my modules loaded so, I guess it used the mac "gcc" aka clang: [(545) 01:48 PM] $ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 10.0.1 (clang-1001.0.46.4) Target: x86_64-apple-darwin18.5.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin [(546) 01:48 PM] $ /usr/bin/xcodebuild -version Xcode 10.2.1 Build version 10E1001
[Bug other/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #4 from Matt Thompson --- Also: I do have all the log files still, so if you'd like anything grep'ed in there, let me know.
[Bug other/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #2 from Iain Sandoe --- (In reply to Iain Sandoe from comment #1) > please can you do "grep CFI" gccc/auto-host.h and put the output here? also what version of Xcode you're using and/or what version of GCC you are using to bootstrap. I built and installed all languages for the 9.1rc2 version - so unless there was a patch after than but before the release, this is a surprising fail..
[Bug other/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- please can you do "grep CFI" gccc/auto-host.h and put the output here?
[Bug tree-optimization/88709] Improve store-merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88709 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 46278 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46278=edit gcc10-pr88709-wip.patch Further progress on the patch.
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #93 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #91) > GCC 9.1 has been released. (In reply to Zaak from comment #92) > Is my interpretation correct that the patch did not make it in time for GCC > 9.1? (I( want to make sure we're applying it in Homebrew if not.) the patch was applied before 9.1 branched, and is on the 9.1 branch. see: https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00109.html which was bootstrapped with xc10.2 command line tools and SDK. it needs applying to 8.x and 7.x - which will happen soon.
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #92 from Zaak --- Is my interpretation correct that the patch did not make it in time for GCC 9.1? (I( want to make sure we're applying it in Homebrew if not.)
[Bug tree-optimization/90332] New: New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90332 Bug ID: 90332 Summary: New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- I am only seeing this on power 9; not sure it is run on other power Xs. Executing on host: /home3/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home3/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/slp-reduc-sad-2.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -maltivec -mpower9-vector -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o slp-reduc-sad-2.s(timeout = 300) spawn -ignore SIGHUP /home3/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home3/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/slp-reduc-sad-2.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -maltivec -mpower9-vector -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o slp-reduc-sad-2.s PASS: gcc.dg/vect/slp-reduc-sad-2.c (test for excess errors) PASS: gcc.dg/vect/slp-reduc-sad-2.c scan-tree-dump vect "vect_recog_sad_pattern: detected" PASS: gcc.dg/vect/slp-reduc-sad-2.c scan-tree-dump vect "vectorizing stmts using SLP" FAIL: gcc.dg/vect/slp-reduc-sad-2.c scan-tree-dump-not vect "access with gaps requires scalar epilogue loop" PASS: gcc.dg/vect/slp-reduc-sad-2.c scan-tree-dump-times vect "vectorized 1 loops" 1 Executing on host: /home3/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home3/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/slp-reduc-sad-2.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -flto -ffat-lto-objects -maltivec -mpower9-vector -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o slp-reduc-sad-2.s(timeout = 300) spawn -ignore SIGHUP /home3/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home3/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/slp-reduc-sad-2.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -flto -ffat-lto-objects -maltivec -mpower9-vector -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o slp-reduc-sad-2.s PASS: gcc.dg/vect/slp-reduc-sad-2.c -flto -ffat-lto-objects (test for excess errors) PASS: gcc.dg/vect/slp-reduc-sad-2.c -flto -ffat-lto-objects scan-tree-dump vect "vect_recog_sad_pattern: detected" PASS: gcc.dg/vect/slp-reduc-sad-2.c -flto -ffat-lto-objects scan-tree-dump vect "vectorizing stmts using SLP" FAIL: gcc.dg/vect/slp-reduc-sad-2.c -flto -ffat-lto-objects scan-tree-dump-not vect "access with gaps requires scalar epilogue loop" PASS: gcc.dg/vect/slp-reduc-sad-2.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/vect/vect.exp completed in 2 seconds === gcc Summary === # of expected passes8 # of unexpected failures2
[Bug middle-end/90331] New: New test case gcc.dg/pr87314-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90331 Bug ID: 90331 Summary: New test case gcc.dg/pr87314-1.c fails Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Executing on host: /home3/seurer/gcc/build/gcc-test/gcc/xgcc -B/home3/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr87314-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O -fdump-tree-original -ffat-lto-objects -fno-ident -S -o pr87314-1.s(timeout = 300) spawn -ignore SIGHUP /home3/seurer/gcc/build/gcc-test/gcc/xgcc -B/home3/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/pr87314-1.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O -fdump-tree-original -ffat-lto-objects -fno-ident -S -o pr87314-1.s PASS: gcc.dg/pr87314-1.c (test for excess errors) PASS: gcc.dg/pr87314-1.c scan-tree-dump-times original "hello" 1 FAIL: gcc.dg/pr87314-1.c scan-assembler hello testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/dg.exp completed in 0 seconds === gcc Summary === # of expected passes2 # of unexpected failures1
[Bug fortran/90305] ASSOCIATE with a substring of a deferred-length character selector yields garbage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90305 Dominique d'Humieres changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |RESOLVED Known to work||10.0, 9.1.0 Resolution|--- |DUPLICATE Known to fail||7.4.0, 8.3.0 --- Comment #2 from Dominique d'Humieres --- Confirmed for the 7 and 8 branches. Fixed between revisions r265171 (2018-10-15, wrong code) and r265310 (2018-10-19, OK), likely r265264 (pr58618). It looks to be a duplicate of pr58618. *** This bug has been marked as a duplicate of bug 58618 ***
[Bug fortran/58618] Wrong code with character substring and ASSOCIATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58618 Dominique d'Humieres changed: What|Removed |Added CC||damian at sourceryinstitute dot or ||g --- Comment #15 from Dominique d'Humieres --- *** Bug 90305 has been marked as a duplicate of this bug. ***
[Bug pch/90326] Using any precompiled header breaks definition of FLT_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90326
--- Comment #2 from Alex Smith ---
It still repros for me on 9.0.1-0.16.fc31.
Slightly reduced test case:
$ cat test.h
#define TEST 1
$ cat test.cpp
#include
static_assert(__FLT_MAX__ > 0);
int main() { return 0; }
$ g++ -o test test.cpp -include test.h
$ g++ -x c++-header -c test.h -o test.h.gch
$ g++ -o test test.cpp -include test.h
test.cpp:2:27: error: static assertion failed
2 | static_assert(__FLT_MAX__ > 0);
Note __FLT_MAX__ is failing as well as FLT_MAX.
However, if I remove "#include ", it compiles successfully.
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 --- Comment #24 from Jon Cohen --- I don't see anything in the release notes about call_once. Is this still an open issue?
[Bug other/90330] New: gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 Bug ID: 90330 Summary: gcc 9.1.0 fails to install on macOS 10.14.4 Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: matthew.thompson at nasa dot gov Target Milestone: --- All, I am trying to build GCC 9.1.0 on my Macbook today, but it's failing in the make install step. The make step was happy, but when I try to install, it fails. Note that I have built GCC from 5.4 up on this machine, including 8.2.0, but that was a while ago. There has been OS and XCode updates since then. Also, I do have the header files installed in /usr/include. First, I did the usual: ./contrib/download_prerequisites I then configured gcc with: ../gcc-9.1.0/configure --prefix=/Users/mathomp4/installed/Core/gcc-gfortran/9.1.0 --enable-languages=c,c++,fortran --disable-multilib |& tee configure.log I then ran: make -j4 |& tee make.log and finally: make install |& tee makeinstall.log The last step dies with an error seen below that seems C++-ish. As I'm a Fortran coder, it's a bit above me. I can also attach my build logs so you can see if I did something wrong (possible) if you like. The error is: make[2]: Entering directory '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD/gcc' g++ -std=gnu++98-g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -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 i386-c.o darwin-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 ./../intl/libintl.a -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD/./isl/.libs -lisl -L/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD/./gmp/.libs -L/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD/./mpfr/src/.libs -L/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD/./mpc/src/.libs -lmpc -lmpfr -lgmp -L./../zlib -lz ld: warning: could not create compact unwind for __ZL18ix86_target_stringxxiiPKcS0_11fpmath_unitbb.cold: stack size is large but stack subq instruction not found ld: warning: could not create compact unwind for __ZNK9vec_usage4dumpEP12mem_locationR9mem_usage: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for __ZL18cselib_record_setsP8rtx_insn.cold: stack size is large but stack subq instruction not found ld: warning: could not create compact unwind for __ZL16may_eliminate_ivP11ivopts_dataP6iv_useP7iv_candPP9tree_nodeP9tree_code: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for __ZL16may_eliminate_ivP11ivopts_dataP6iv_useP7iv_candPP9tree_nodeP9tree_code.cold: stack size is large but stack subq instruction not found ld: warning: could not create compact unwind for __Z12find_reloadsP8rtx_insniiiPs: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for __Z12find_reloadsP8rtx_insniiiPs.cold: stack size is large but stack subq instruction not found ld: warning: could not create compact unwind for __ZN12_GLOBAL__N_113pass_backprop7executeEP8function.cold: stack size is large but stack subq instruction not found ld: warning: could not create compact unwind for __ZL13powi_as_multsP20gimple_stmt_iteratorjP9tree_nodex: stack subq instruction is too different from dwarf stack size ld: warning: could not create compact unwind for __Z11inline_callP11cgraph_edgebP3vecIS0_7va_heap6vl_ptrEPibPb.cold: stack size is large but stack subq instruction not found ld: warning: could not create compact unwind for __ZL20process_alt_operandsi.cold: stack size is large but stack subq instruction not found Undefined symbols for architecture x86_64: "std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)", referenced from: ipa_icf::sem_item_optimizer::worklist_push(ipa_icf::congruence_class*) in libbackend.a(ipa-icf.o) ipa_icf::sem_item_optimizer::traverse_congruence_split(ipa_icf::congruence_class* const&,
[Bug fortran/90093] Extended C interop: optional argument incorrectly identified as PRESENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90093 Dominique d'Humieres changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-03 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug fortran/90329] New: Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 Bug ID: 90329 Summary: Incompatibility between gfortran and C lapack calls Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- The fix for PR 87689 (ABI violation on POWER) has led to problems with what some C programs expect as the Fortran calling convention to be. It seems that many C codes assume that no hidden string length is passed for a one-character string. This is wrong (and has been wrong since the days of the original Fortran compiler for Unix), but the code exists, and we should recommend a solution for it. This is important because C interfaces to LAPACK, as central a piece of software as you can find, is impacted by this. This has been quite extensively debugged by the R people, see https://gcc.gnu.org/ml/fortran/2019-05/msg00021.html . On x86_64, Tomas Kalibera found that, while things "mostly" worked, a tail call was causing problems because the stack space for the length was not allocated. -fno-optimize-sibling-calls seems to cure it, but that may not be the only thing affected by this. Note that this applies to gcc 7, gcc 8, gcc 9 and gcc 10, since the patch was applied to all open branches at the time (an ABI violation on a primary platform was deemed important enough).
[Bug tree-optimization/90328] New: Wrong loop distribution with aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90328
Bug ID: 90328
Summary: Wrong loop distribution with aliasing
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
I was investigating missed loop distribution opportunities probably related to
aliasing, and hit this case where gcc seems a bit too optimistic.
#include
struct T { int* p; T(T const):p(t.p){} };
T* f(T* a,T* b){
for(int i=0;i<1024;++i){
a[i].~T();
new(a+i)T(b[i]);
}
return a;
}
This gets optimized to a call to memcpy.
However, I believe it is legal to call f(x+1,x) where x is an array of size
1025, where it should replace every element with a copy of the first one.
This seems related to "new" and the use of a constructor. It is true that this
implies that a[i] and b[i] cannot alias, but not that the whole a and b cannot
alias.
[Bug ipa/88702] [7/8/9/10 regression] We do terrible job optimizing IsHTMLWhitespace from Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702 --- Comment #10 from Martin Liška --- (In reply to David Malcolm from comment #9) > If using a switch is better than a series of tests against constants, would > it make sense for the compiler to spot this case, and automatically convert > the conditions to a switch? Yes, we've got a PR for it somewhere..
[Bug tree-optimization/90269] loop distribution defeated by clobbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90269 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #5 from Marc Glisse --- .
[Bug ipa/88702] [7/8/9/10 regression] We do terrible job optimizing IsHTMLWhitespace from Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #9 from David Malcolm --- If using a switch is better than a series of tests against constants, would it make sense for the compiler to spot this case, and automatically convert the conditions to a switch?
[Bug target/89400] [7/8/9 Regression] ICE: output_operand: invalid %-code with -march=armv6kz -mthumb -munaligned-access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400 Richard Earnshaw changed: What|Removed |Added Status|NEW |ASSIGNED Summary|[7/8/9/10 Regression] ICE: |[7/8/9 Regression] ICE: |output_operand: invalid |output_operand: invalid |%-code with -march=armv6kz |%-code with -march=armv6kz |-mthumb -munaligned-access |-mthumb -munaligned-access --- Comment #7 from Richard Earnshaw --- Fixed on trunk so far.
[Bug target/89400] [7/8/9/10 Regression] ICE: output_operand: invalid %-code with -march=armv6kz -mthumb -munaligned-access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89400 --- Comment #6 from Richard Earnshaw --- Author: rearnsha Date: Fri May 3 13:45:59 2019 New Revision: 270853 URL: https://gcc.gnu.org/viewcvs?rev=270853=gcc=rev Log: [arm] PR target/89400 fix thumb1 unaligned access expansion Armv6 has support for unaligned accesses to memory. However, the thumb1 code patterns were trying to use the 32-bit code constraints. One failure mode from this was that the patterns are designed to be compatible with conditional execution and this was then causing an assert in the compiler. The unaligned_loadhis pattern is only used for expanding extv, which in turn is only enabled for systems supporting thumb2. Given that there is no simple expansion for a thumb1 sign-extending load (the instruction has no immediate offset form and requires two registers in the address) it seems simpler to just disable this for thumb1. Fixed thusly: PR target/89400 * config/arm/arm.md (unaligned_loadsi): Add variant for thumb1. Restrict 'all' variant to 32-bit configurations. (unaligned_loadhiu): Likewise. (unaligned_storehi): Likewise. (unaligned_storesi): Likewise. (unaligned_loadhis): Disable when compiling for thumb1. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md
[Bug tree-optimization/90269] loop distribution defeated by clobbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90269 --- Comment #4 from Marc Glisse --- Author: glisse Date: Fri May 3 13:41:36 2019 New Revision: 270852 URL: https://gcc.gnu.org/viewcvs?rev=270852=gcc=rev Log: Let ldist ignore clobbers 2019-05-03 Marc Glisse PR tree-optimization/90269 gcc/ * tree-loop-distribution.c (find_seed_stmts_for_distribution): Ignore clobbers. gcc/testsuite/ * g++.dg/tree-ssa/ldist-1.C: New file. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/ldist-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-loop-distribution.c
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291 --- Comment #14 from Jonathan Wakely --- https://wg21.link/cwg2061
[Bug tree-optimization/90327] [9/10 Regression] ICE in convert_move, at expr.c:218 since r265677 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90327 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code CC||rguenth at gcc dot gnu.org Target Milestone|--- |9.2
[Bug tree-optimization/90327] New: [9/10 Regression] ICE in convert_move, at expr.c:218 since r265677 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90327 Bug ID: 90327 Summary: [9/10 Regression] ICE in convert_move, at expr.c:218 since r265677 on s390x Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Following is causing ICE: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr90139.c -Og -c during RTL pass: expand /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr90139.c: In function ‘foo’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/pr90139.c:8:1: internal compiler error: in convert_move, at expr.c:218 8 | foo (void) | ^~~ 0x10c7156 emit_partition_copy /home/marxin/Programming/gcc2/gcc/tree-outof-ssa.c:222 0x10c7156 insert_part_to_rtx_on_edge /home/marxin/Programming/gcc2/gcc/tree-outof-ssa.c:391 0x10c7156 elim_create /home/marxin/Programming/gcc2/gcc/tree-outof-ssa.c:677 0x10c7156 eliminate_phi /home/marxin/Programming/gcc2/gcc/tree-outof-ssa.c:735 0x10c7156 expand_phi_nodes(ssaexpand*) /home/marxin/Programming/gcc2/gcc/tree-outof-ssa.c:1007 0x77b6ab7a __libc_start_main ../csu/libc-start.c:308 0x7f00d9 ??? ../sysdeps/x86_64/start.S:120
[Bug middle-end/89037] checking ice emitting 128-bit bit-field initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89037 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|9.2 |7.5
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291
--- Comment #13 from Nathan Sidwell ---
I don't know where the DR information is available without a password (C++
physical meetings are public, see https://isocpp.org/std/
Here is the text of 2061:
2061. Inline namespace after simplifications
Section: 9.7.1 [namespace.def] Status: CD4 Submitter: Richard Smith
Date: 2014-12-18 Priority: 0 Drafting: Maurer
[Adopted at the February, 2016 meeting.]
After the resolution of issue 1795, 9.7.1 [namespace.def] paragraph 3 now says:
In a named-namespace-definition, the identifier is the name of the
namespace. If the identifier, when looked up (6.4.1 [basic.lookup.unqual]),
refers to a namespace-name (but not a namespace-alias) introduced in the
declarative region in which the named-namespace-definition appears, the
namespace-definition extends the previously-declared namespace. Otherwise, the
identifier is introduced as a namespace-name into the declarative region in
which the named-namespace-definition appears.
This appears to break code like the following:
namespace A {
inline namespace b {
namespace C {
template void f();
}
}
}
namespace A {
namespace C {
template<> void f() { }
}
}
because (by definition of “declarative region”) C cannot be used as an
unqualified name to refer to A::b::C within A if its declarative region is
A::b.
Proposed resolution (September, 2015):
Change 9.7.1 [namespace.def] paragraph 3 as follows:
In a named-namespace-definition, the identifier is the name of the
namespace. If the identifier, when looked up (6.4.1 [basic.lookup.unqual]),
refers to a namespace-name (but not a namespace-alias) that was introduced in
the declarative region namespace in which the named-namespace-definition
appears or that was introduced in a member of the inline namespace set of that
namespace, the namespace-definition extends the previously-declared namespace.
Otherwise, the identifier is introduced as a namespace-name into the
declarative region in which the named-namespace-definition appears.
[nathan: I.e. we do unqualified lookup for the name, ignoring using directives.
That naturally descends into the immediate set of inline-namespaces.]
[Bug tree-optimization/90303] [9 Regression] ICE in hash_odr_name with fastcall attribute starting with r267359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90303 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |hash_odr_name with fastcall |hash_odr_name with fastcall |attribute starting with |attribute starting with |r267359 |r267359 --- Comment #7 from Jakub Jelinek --- Fixed for 10.1+ so far.
[Bug libstdc++/71044] Optimize std::filesystem implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71044 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|9.2 |9.0 --- Comment #11 from Jonathan Wakely --- I think we're all done here.
[Bug tree-optimization/90316] [8/9/10 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #7 from Than McIntosh --- I patched in your change and reran the original testacse. Verified that this fixes the problem, compile time now down to ~8 seconds. Thank you for the very quick turnaround-- much appreciated.
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291 --- Comment #12 from Igor A. Goussarov --- Thank you for taking interest and for the efforts, Nathan!
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291 --- Comment #11 from Nathan Sidwell --- thanks for your input. Richard Smith (Clang maintainer) & I are going to take this question to the evolution group. DR2061 is intended to fix a problem with the original intent of inline namespaces. However, you show an interesting different use case that conflicts.
[Bug tree-optimization/90316] [8/9/10 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 Richard Biener changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-05/msg00117.ht ||ml --- Comment #6 from Richard Biener --- Proposed patch. -O0 optimized compiler compiles the testcase in 40s for me now. Can you test it on the original source?
[Bug tree-optimization/87314] pointless comparison of malloc result to a string not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87314
--- Comment #10 from Richard Biener ---
(In reply to Jakub Jelinek from comment #9)
> The question is how far we want to go and what we just ignore.
> With -fmerge-all-constants, we can have:
> const char var[] = "foobar";
> int foo (void) { return [0] != "foobar"; }
> which will likely be now miscompiled.
GCC 8 produces the following and so doesn't actually merge the constants
.LC0:
.string "foobar"
.section.text.startup,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
movl$var, %eax
cmpq$.LC0, %rax
setne %al
movzbl %al, %eax
ret
.cfi_endproc
.LFE0:
.size main, .-main
.globl var
.section.rodata.str1.1
.type var, @object
.size var, 7
var:
.string "foobar"
And with -O0 it's even more obvious:
var:
.string "foobar"
.LC0:
.string "foobar"
and yes, we now optimize this.
> But we could even have two sources,
> const char var2[] = "foobar";
> compiled with -fmerge-all-constants and
> extern char var2[];
> int bar (void) { return [0] != "foobar"; }
> compiled with -fmerge-constants (the default).
>
> So, can we e.g. optimize less if we see flag_merge_all_constants and a
> TREE_READONLY decl(s) (both the above first case and your const int case)?
> If the decl(s) have DECL_INITIAL and bind to current TU, we could of course
> check further the initializers, and ignore the nasty second case above, by
> saying that
> if you define vars as const and declare as non-const, it is your problem and
> similarly, if you -fmerge-all-constants the defining TUs but not uses of
> those decls, it is again your fault? I'd lean towards that.
I didn't manage to merge the variable and the string literal, so I believe
this is a theoretical issue?
[Bug tree-optimization/90316] [8/9/10 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #5 from Richard Biener --- Author: rguenth Date: Fri May 3 11:22:33 2019 New Revision: 270849 URL: https://gcc.gnu.org/viewcvs?rev=270849=gcc=rev Log: 2019-05-03 Richard Biener PR tree-optimization/90316 * tree-ssa-pre.c (pass_pre::execute): Re-compute DOM fast queries before running VN. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/tree-ssa-pre.c
[Bug tree-optimization/87314] pointless comparison of malloc result to a string not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87314
--- Comment #9 from Jakub Jelinek ---
The question is how far we want to go and what we just ignore.
With -fmerge-all-constants, we can have:
const char var[] = "foobar";
int foo (void) { return [0] != "foobar"; }
which will likely be now miscompiled. But we could even have two sources,
const char var2[] = "foobar";
compiled with -fmerge-all-constants and
extern char var2[];
int bar (void) { return [0] != "foobar"; }
compiled with -fmerge-constants (the default).
So, can we e.g. optimize less if we see flag_merge_all_constants and a
TREE_READONLY decl(s) (both the above first case and your const int case)?
If the decl(s) have DECL_INITIAL and bind to current TU, we could of course
check further the initializers, and ignore the nasty second case above, by
saying that
if you define vars as const and declare as non-const, it is your problem and
similarly, if you -fmerge-all-constants the defining TUs but not uses of those
decls, it is again your fault? I'd lean towards that.
[Bug tree-optimization/90316] [8/9/10 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #4 from Richard Biener --- Author: rguenth Date: Fri May 3 11:21:18 2019 New Revision: 270848 URL: https://gcc.gnu.org/viewcvs?rev=270848=gcc=rev Log: 2019-05-03 Richard Biener PR tree-optimization/90316 * tree-ssa-pre.c (pass_pre::execute): Re-compute DOM fast queries before running VN. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/87314] pointless comparison of malloc result to a string not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87314
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> Is it safe with -fmerge-all-constants if the decls are TREE_READONLY?
I don't think DECL vs STRING_CST is any special here (or well, STRING_CSTs
will end up in mergeable string sections). It's probably more a question
for
const int a = 2;
const int b = 2;
int main() { return != }
which we "miscompile" since forever with -fmerge-all-constants.
[Bug tree-optimization/87314] pointless comparison of malloc result to a string not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87314 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Is it safe with -fmerge-all-constants if the decls are TREE_READONLY?
[Bug tree-optimization/87314] pointless comparison of malloc result to a string not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87314 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/89518] missed optimisation for array address calculations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89518 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/89518] missed optimisation for array address calculations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89518 --- Comment #3 from Richard Biener --- Author: rguenth Date: Fri May 3 10:46:13 2019 New Revision: 270846 URL: https://gcc.gnu.org/viewcvs?rev=270846=gcc=rev Log: 2019-05-03 Richard Biener PR middle-end/89518 * match.pd: Add pattern to optimize (A / B) * B + (A % B) to A. * gcc.dg/pr89518.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr89518.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/87314] pointless comparison of malloc result to a string not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87314 --- Comment #5 from Richard Biener --- Author: rguenth Date: Fri May 3 10:44:17 2019 New Revision: 270845 URL: https://gcc.gnu.org/viewcvs?rev=270845=gcc=rev Log: 2019-05-03 Richard Biener PR middle-end/87314 * match.pd (cmp (convert1?@2 addr@0) (convert2? addr@1)): Handle STRING_CST vs DECL or STRING_CST. * gcc.dg/pr87314-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr87314-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug target/88963] gcc generates terrible code for vectors of 64+ length which are not natively supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963 --- Comment #12 from Richard Biener --- Author: rguenth Date: Fri May 3 10:39:56 2019 New Revision: 270844 URL: https://gcc.gnu.org/viewcvs?rev=270844=gcc=rev Log: 2019-05-03 Richard Biener PR tree-optimization/88963 * tree-ssa-forwprop.c (pass_forwprop::execute): Rewrite vector loads feeding only BIT_FIELD_REFs to component loads. Rewrite stores fed by CONSTRUCTORs to component stores. * gcc.dg/tree-ssa/ssa-fre-31.c: Disable forwprop. * gcc.target/i386/pr88963-1.c: New testcase. * gcc.target/i386/pr88963-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr88963-1.c trunk/gcc/testsuite/gcc.target/i386/pr88963-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-31.c trunk/gcc/tree-ssa-forwprop.c
[Bug middle-end/88963] gcc generates terrible code for vectors of 64+ length which are not natively supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88963 Richard Biener changed: What|Removed |Added Component|target |middle-end --- Comment #13 from Richard Biener --- Fixed on GIMPLE, the RTL expansion issue with the stores remains so I keep this open.
[Bug pch/90326] Using any precompiled header breaks definition of FLT_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90326 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Can't reproduce (with Fedora gcc 9.0.1-0.16.fc31).
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291
--- Comment #10 from Igor A. Goussarov ---
Having reflected on my feelings about the described scenario, I came up with a
slightly different wording for my complaints about the behaviour of gcc-8.x:
The fact that using an inline namespace at one point in source may alter the
interpretation of an unrelated, unaware and otherwise well-defined code at some
other point further down the same translation unit looks unsafe. That's
dangerous interference right there.
Given the following source text:
namespace B
{
namespace A
{
void foo() {}
}
}
I would expect the compiler to generate B::A::foo() no matter what header files
may have been included prior to these lines.
BTW, is that core working group forum public? Maybe I'm missing some important
reasoning why the behaviour exhibited by gcc 8.x is actually desired?
P.S. I'm having days off now; most likely, I'll not be able to reply before May
9.
[Bug tree-optimization/90316] [8/9/10 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.4 Summary|large compile time increase |[8/9/10 Regression] large |in opt / alias stmt walking |compile time increase in |for Go example |opt / alias stmt walking ||for Go example
[Bug target/88809] do not use rep-scasb for inline strlen/memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88809 --- Comment #8 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Fri May 3 10:00:27 2019 New Revision: 270843 URL: https://gcc.gnu.org/viewcvs?rev=270843=gcc=rev Log: 2019-05-03 Dominique d'Humieres PR target/88809 * gcc.target/i386/pr88809.c: Adjust for darwin. * gcc.target/i386/pr88809-2.c: Adjust for i386 and darwin. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr88809-2.c trunk/gcc/testsuite/gcc.target/i386/pr88809.c
[Bug tree-optimization/90316] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #3 from Richard Biener ---
GCC 8 got enhanced get_continuation_for_phi, previously we gave up for this
kind of CFG.
2017-05-04 Richard Biener
* tree-ssa-alias.c (get_continuation_for_phi): Improve looking
for the last VUSE which def dominates the PHI. Directly call
maybe_skip_until.
(get_continuation_for_phi_1): Remove.
we do
/* If not, look if we can reach such candidate by walking defs
of a PHI arg without crossing other PHIs. */
if (! arg0)
for (i = 0; i < nargs; ++i)
{
arg0 = PHI_ARG_DEF (phi, i);
gimple *def = SSA_NAME_DEF_STMT (arg0);
/* Backedges can't work. */
if (dominated_by_p (CDI_DOMINATORS,
gimple_bb (def), phi_bb))
continue;
/* See below. */
if (gimple_code (def) == GIMPLE_PHI)
continue;
while (! dominated_by_p (CDI_DOMINATORS,
phi_bb, gimple_bb (def)))
{
arg0 = gimple_vuse (def);
if (SSA_NAME_IS_DEFAULT_DEF (arg0))
break;
def = SSA_NAME_DEF_STMT (arg0);
if (gimple_code (def) == GIMPLE_PHI)
{
/* Do not try to look through arbitrarily complicated
CFGs. For those looking for the first VUSE starting
from the end of the immediate dominator of phi_bb
is likely faster. */
arg0 = NULL_TREE;
goto next;
}
}
break;
next:;
}
which for the testcase can walk up the whole "right arm" of the CFG
repeatedly as well as computing the vuse to walk to.
[Bug pch/90326] New: Using any precompiled header breaks definition of FLT_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90326
Bug ID: 90326
Summary: Using any precompiled header breaks definition of
FLT_MAX
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pch
Assignee: unassigned at gcc dot gnu.org
Reporter: asmith at feralinteractive dot com
Target Milestone: ---
With Fedora 30's GCC 9.0.1 (gcc (GCC) 9.0.1 20190312 (Red Hat 9.0.1-0.10)),
including any precompiled header will result in FLT_MAX being defined to 0,
rather than the correct value.
Reproduction test case:
10:40:54 ~ $ cat test.cpp
#include
#include
int main()
{
float f = FLT_MAX;
printf("%f\n", f);
return 0;
}
10:40:56 ~ $ cat test.h
#define TEST 1
10:40:58 ~ $ g++ -o test test.cpp
10:41:08 ~ $ ./test
340282346638528859811704183484516925440.00
10:41:10 ~ $ g++ -o test test.cpp -include test.h
10:41:16 ~ $ ./test
340282346638528859811704183484516925440.00
10:41:17 ~ $ g++ -x c++-header -c test.h -o test.h.gch
10:41:28 ~ $ g++ -o test test.cpp -include test.h
10:41:32 ~ $ ./test
0.00
I'm unsure if any other definitions are affected but FLT_MAX is the one that
was most obviously broken to me as the incorrect value causes us a ton of
issues.
GCC 8.3.0 on Arch Linux is not affected.
[Bug rtl-optimization/90311] [9/10 Regression] wrong code with -O and __builtin_add_overflow() and compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90311 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #5 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug rtl-optimization/87871] [9/10 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #61 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug rtl-optimization/90007] [9/10 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #9 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug target/84379] Problems with sol2.c GTY handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84379 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #3 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug middle-end/82362] [8/9/10 Regression] SPEC CPU2006 436.cactusADM ~7% performance deviation with trunk@251713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82362 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #6 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug gcov-profile/85188] [GCOV] a int arrary and a goto statement around the for(;0;) statement will lead to incoccrect code coverage in Gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85188 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #2 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug c++/68615] Unhelpful location when missing a semi-colon on a function declaration at the end of a header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68615 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #5 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug tree-optimization/57534] [7/8/9/10 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #32 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug c++/85004] ambiguous diagnostic: passing ‘const S’ as ‘this’ argument discards qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85004 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #2 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug fortran/86277] Presence of optional arguments not recognized for zero length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #4 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug c++/71283] Inconsistent location for C++ warning options in the manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71283 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #9 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug middle-end/89037] checking ice emitting 128-bit bit-field initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89037 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #7 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug target/86681] ICE in extract_insn, at recog.c:2304 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86681 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #2 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug rtl-optimization/87902] [9/10 Regression] Shrink-wrapping multiple conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87902 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #9 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug gcov-profile/85349] [GCOV] struct varaible definition in while(1) will cause incorrect coverage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85349 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #2 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug target/90178] [9 Regression] Missed optimization: duplicated terminal basic block with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90178 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #12 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug c/84919] [8/9/10 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84919 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #15 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug target/70321] [7/8/9/10 Regression] STV generates less optimized code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70321 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #19 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug ipa/89584] [9/10 Regression] CPU2000 degradations with r268448 (172.mgrid -22%, 252.eon -8%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89584 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #2 from Jakub Jelinek --- GCC 9.1 has been released.
[Bug rtl-optimization/90249] [9/10 Regression] Code size regression on thumb2 due to sub-optimal register allocation starting with r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249 Jakub Jelinek changed: What|Removed |Added Target Milestone|9.0 |9.2 --- Comment #9 from Jakub Jelinek --- GCC 9.1 has been released.
