[Bug debug/90017] gcc generates wrong debug information at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90017 --- Comment #4 from Richard Biener --- (In reply to Qirun Zhang from comment #3) > (In reply to Alexandre Oliva from comment #2) > > This odd behavior is an artifact of the way GCC lays out the basic blocks, > > and how GDB interprets the line number program. > > > > The blocks containing the conditional calls to optimize_me_not in line 15 > > are moved to the end of the function, in reverse order, while the rest of > > the inner loop, with code from lines 12 to 14, remains in sequential order. > > > > What GDB sees then is a long chunk of code all at line 15, the first of > > which corresponds to the iteration l=8. l=7 is later, with another line > > number mark, then l=6 and so on, but without intervening line number > > changes, it takes it all as a single line. GDB pays no attention to the > > is_stmt=1 markers at each and every one of them, let alone to the different > > view numbers. > > > > So, yeah, definitely consumer issue. > > Hi Alex, > > Are you suggesting that it's a gdb bug? Perhaps, I can report it to gdb > instead? Thanks. Yes, reporting to gdb sounds appropriate.
[Bug rtl-optimization/90026] [8/9 Regression] ICE: verify_flow_info failed (error: missing barrier after block 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90026 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Apr 12 07:27:25 2019 New Revision: 270304 URL: https://gcc.gnu.org/viewcvs?rev=270304&root=gcc&view=rev Log: PR rtl-optimization/90026 * cfgcleanup.c (try_optimize_cfg): When removing empty bb with no successors, look for BARRIERs inside of the whole BB_FOOTER chain rather than just at the start of it. If e->src BB_FOOTER is not NULL in cfglayout mode, use emit_barrier_after_bb. * g++.dg/opt/pr90026.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr90026.C Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c trunk/gcc/testsuite/ChangeLog
[Bug c/89946] [8/9 Regression] ICE in assemble_start_function, at varasm.c:1871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89946 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Apr 12 07:28:35 2019 New Revision: 270305 URL: https://gcc.gnu.org/viewcvs?rev=270305&root=gcc&view=rev Log: PR c/89946 * varasm.c (assemble_start_function): Don't use tree_fits_uhwi_p and gcc_unreachable if it fails, just call tree_to_uhwi which verifies that too. Test TREE_CHAIN instead of list_length > 1. Start warning message with a lower-case letter. Formatting fixes. c-family/ * c-attribs.c (handle_patchable_function_entry_attribute): Add function comment. Warn if arguments of the attribute are not positive integer constants. testsuite/ * c-c++-common/pr89946.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr89946.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-attribs.c trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
[Bug rtl-optimization/90026] [8 Regression] ICE: verify_flow_info failed (error: missing barrier after block 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90026 Jakub Jelinek changed: What|Removed |Added Known to work||9.0 Summary|[8/9 Regression] ICE: |[8 Regression] ICE: |verify_flow_info failed |verify_flow_info failed |(error: missing barrier |(error: missing barrier |after block 2) |after block 2) Known to fail|9.0 | --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c/89946] [8 Regression] ICE in assemble_start_function, at varasm.c:1871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89946 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] ICE in |[8 Regression] ICE in |assemble_start_function, at |assemble_start_function, at |varasm.c:1871 |varasm.c:1871 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/90049] Wrong expanding for a unsigned short ssa_name in embedded assembly code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90049
Eric Botcazou changed:
What|Removed |Added
Target|mips-elf|
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Eric Botcazou ---
This is not a bug:
__asm__ __volatile__ ("addiu %0, %1, 0\t\n" "movn %0, %2, %3" :
"=&r"(g_b.s_b.c):"r"(g_b.s_b.c),"r"(g_a.s_a.c),"r"((0 == g_a.s_a.a)));
The movn instruction uses 32-bit quantities but g_a.s_a.c is only 16-bit and
there is no implicit cast for asm operands. You need to write it like this:
__asm__ __volatile__ ("addiu %0, %1, 0\t\n" "movn %0, %2, %3" :
"=&r"(g_b.s_b.c):"r"((int)g_b.s_b.c),"r"((int)g_a.s_a.c),"r"((0 ==
g_a.s_a.a)));
[Bug gcov-profile/90053] New: [GCOV] A statement in while loop is wrongly marked as not executed when they are within the if(setjmp()) statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90053
Bug ID: 90053
Summary: [GCOV] A statement in while loop is wrongly marked as
not executed when they are within the if(setjmp())
statement
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.2.0-1ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04)
$ cat small.c
#include
#include
#include
static jmp_buf segv_jmpbuf;
static void segv_handler(int seg) { __builtin_longjmp(segv_jmpbuf, 1); }
static int is_addressable(void *p, size_t size)
{
volatile char * volatile cp = (volatile char *)p;
volatile int ret;
struct sigaction sa, origsa;
sigset_t mask;
sa.sa_handler = segv_handler;
sa.sa_flags = 0;
sigfillset(&sa.sa_mask);
sigaction(SIGSEGV, &sa, &origsa);
sigprocmask(SIG_SETMASK, NULL, &mask);
if (__builtin_setjmp(segv_jmpbuf) == 0) {
printf("size: %d\n", size);
while(size--)
{ *cp++; }
ret = 1;
} else {
ret = 0;
}
sigaction(SIGSEGV, &origsa, NULL);
sigprocmask(SIG_SETMASK, &mask, NULL);
return ret;
}
int main(int argc, char **argv)
{
is_addressable(0x0, 1);
return 0;
}
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
size: 1
File 'small.c'
Lines executed:95.00% of 20
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:#include
-:3:#include
-:4:
-:5:static jmp_buf segv_jmpbuf;
1:6:static void segv_handler(int seg) {
__builtin_longjmp(segv_jmpbuf, 1); }
-:7:
1:8:static int is_addressable(void *p, size_t size)
-:9:{
1: 10: volatile char * volatile cp = (volatile char *)p;
-: 11: volatile int ret;
-: 12: struct sigaction sa, origsa;
-: 13: sigset_t mask;
-: 14:
1: 15: sa.sa_handler = segv_handler;
1: 16: sa.sa_flags = 0;
1: 17: sigfillset(&sa.sa_mask);
1: 18: sigaction(SIGSEGV, &sa, &origsa);
1: 19: sigprocmask(SIG_SETMASK, NULL, &mask);
-: 20:
2: 21: if (__builtin_setjmp(segv_jmpbuf) == 0) {
1: 22: printf("size: %d\n", size);
1: 23: while(size--)
#: 24: { *cp++; }
1: 25: ret = 1;
-: 26: } else {
1: 27: ret = 0;
-: 28: }
-: 29:
2: 30: sigaction(SIGSEGV, &origsa, NULL);
1: 31: sigprocmask(SIG_SETMASK, &mask, NULL);
-: 32:
1: 33: return ret;
-: 34:}
-: 35:
1: 36:int main(int argc, char **argv)
-: 37:{
1: 38: is_addressable(0x0, 1);
1: 39: return 0;
-: 40:}
Line #24 is wrongly marked as not executed. The value of variable #size# is 1
before executing the while statement. Thus, Line #24 should be executed.
[Bug target/52726] Composed error message will not get translated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52726 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Apr 12 08:10:51 2019 New Revision: 270308 URL: https://gcc.gnu.org/viewcvs?rev=270308&root=gcc&view=rev Log: PR target/52726 * config/tilepro/tilepro.c (tilepro_print_operand): Use just "invalid %%t operand" in output_operand_lossage message. Modified: trunk/gcc/ChangeLog trunk/gcc/config/tilepro/tilepro.c
[Bug c++/90047] [8/9 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:680
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90047 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Note, clang++ rejects this: /home/jakub/src/gcc/obj06i/usr/local/include/c++/9.0.1/type_traits:2427:44: error: no type named 'type' in 'std::enable_if'; 'enable_if' cannot be used to disable this declaration using enable_if_t = typename enable_if<_Cond, _Tp>::type; ^ pr90047.C:9:29: note: in instantiation of template type alias 'enable_if_t' requested here template ::value>* = nullptr> ^ pr90047.C:26:26: note: in instantiation of template class 'STR' requested here STR c1; ^
[Bug rtl-optimization/90049] Wrong expanding for a unsigned short ssa_name in embedded assembly code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90049
--- Comment #5 from Tao Wang ---
(In reply to Eric Botcazou from comment #4)
> This is not a bug:
>
> __asm__ __volatile__ ("addiu %0, %1, 0\t\n" "movn %0, %2, %3" :
> "=&r"(g_b.s_b.c):"r"(g_b.s_b.c),"r"(g_a.s_a.c),"r"((0 == g_a.s_a.a)));
>
> The movn instruction uses 32-bit quantities but g_a.s_a.c is only 16-bit and
> there is no implicit cast for asm operands. You need to write it like this:
>
> __asm__ __volatile__ ("addiu %0, %1, 0\t\n" "movn %0, %2, %3" :
> "=&r"(g_b.s_b.c):"r"((int)g_b.s_b.c),"r"((int)g_a.s_a.c),"r"((0 ==
> g_a.s_a.a)));
But if g_a.s_a.c is 17 bits width, then there is a bit extract action like
this: ubfxx3, x3, #0, #17.
So why does this can work and the 16 bit width can not?
[Bug c/89933] [7/8/9 Regression] ICE in merge_decls, at c/c-decl.c:2517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89933 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug rtl-optimization/90049] Wrong expanding for a unsigned short ssa_name in embedded assembly code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90049 --- Comment #6 from Andrew Pinski --- For 16bit, there is a direct integral mode called hi. Basically inline-asm is really exposing gcc internals out to the user in an interesting way.
[Bug gcov-profile/90053] [GCOV] A statement in while loop is wrongly marked as not executed when they are within the if(setjmp()) statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90053 --- Comment #1 from Richard Biener --- I think you need to use setjmp/longjmp, not the __builtin variants which have special semantics.
[Bug c++/89325] [7/8/9 Regression] False warnings about "optimization attribute" on operators when -fno-ipa-cp-clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89325 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||nathan at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Doesn't look like hidden to me, I'd say that r265744 has been the right fix for this. The diagnose_mismatched_attributes has been simply placed way too early, before we check if the two decls actually shouldn't be merged because they have different arguments (and not extern "C"). I'd say we should just say this is fixed for 9 and decide how to fix on release branches. Let me prepare a patch with some testcases for trunk.
[Bug gcov-profile/90054] New: [GCOV] A call statement to the __builtin_snprintf function is wrongly marked as not executed when it is in a for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90054
Bug ID: 90054
Summary: [GCOV] A call statement to the __builtin_snprintf
function is wrongly marked as not executed when it is
in a for loop
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.2.0-1ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04)
$ cat small.c
int b = 1, d = 2;
char res[2];
void fn3 ()
{
for (;;)
{
__builtin_snprintf (res, 2, "%d\n", d);
if (d)
break;
}
printf("%s\n", res);
}
int main ()
{
fn3 ();
return 0;
}
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
2
File 'small.c'
Lines executed:88.89% of 9
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int b = 1, d = 2;
-:2:char res[2];
-:3:
1:4:void fn3 ()
-:5:{
-:6: for (;;)
-:7: {
#:8:__builtin_snprintf (res, 2, "%d\n", d);
1:9:if (d)
1: 10: break;
-: 11: }
1: 12: printf("%s\n", res);
1: 13:}
-: 14:
1: 15:int main ()
-: 16:{
1: 17: fn3 ();
1: 18: return 0;
-: 19:}
Line #8 is wrongly marked as not executed.
When the builtin_snprintf function is replaced with snprintf function, the
coverage report is correct as:
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
2
File 'small.c'
Lines executed:90.00% of 10
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int b = 1, d = 2;
-:2:char res[2];
-:3:
1:4:void fn3 ()
-:5:{
-:6: for (;;)
#:7: {
-:8:// __builtin_snprintf (res, 2, "%d\n", d);
1:9:snprintf (res, 2, "%d\n", d);
1: 10:if (d)
1: 11: break;
-: 12: }
1: 13: printf("%s\n", res);
1: 14:}
-: 15:
1: 16:int main ()
-: 17:{
1: 18: fn3 ();
1: 19: return 0;
-: 20:}
[Bug ipa/88936] [7/8/9 Regression] -fipa-pta breaks bash (incorrect optimisation of recursive static function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936 --- Comment #12 from Richard Biener --- Created attachment 46146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46146&action=edit final fix I am testing the following now which should do less work (but waste more UIDs to be less conservative). The ipa-pta-3.c testcase is no longer affected, we're more optimistically identifying candidates by just looking at a variables function parameter solutions and globals for locals recursively reaching a function.
[Bug ipa/88936] [7/8/9 Regression] -fipa-pta breaks bash (incorrect optimisation of recursive static function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936
--- Comment #13 from Richard Biener ---
Testcase using globals instead of parameters:
static int *p;
void bar(int cnt)
{
int i = 0;
if (cnt == 0)
{
p = &i;
bar (1);
if (i != 1)
__builtin_abort ();
}
else if (cnt == 1)
*p = 1;
}
int main()
{
bar (0);
return 0;
}
[Bug fortran/78640] [F2018] gfortran accepts invalid allocatable polymorphic result in pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78640 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #4 from Jürgen Reuter --- In the meanwhile (F2018) this is C1584, and it says: "The function result of a pure function shall not be both polymorphic and allocatable, or have a polymorphic allocatable ultimate component." So this is still not allowed. Funnily, also ifort does not veto this code, nagfor however does: Error: pr78640.f90, line 9: Result variable of pure function F is polymorphic allocatable
[Bug gcov-profile/90054] [GCOV] A call statement to the __builtin_snprintf function is wrongly marked as not executed when it is in a for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90054 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed on trunk with r263111. Not planning to backport.
[Bug tree-optimization/90055] New: Incorrect result with ffast-math + tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90055 Bug ID: 90055 Summary: Incorrect result with ffast-math + tree-vectorize Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wence at gmx dot li Target Milestone: --- Created attachment 46147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46147&action=edit Bug-provoking file The attached code should produce the answer 0: $ gcc-7 -O0 bug.c -o bug $ ./bug sum: 0. Conversely: $ gcc-7 -O3 -ffast-math -march=haswell -mtune=generic bug.c -o bug $ ./bug sum: -0.3750 And also $ gcc-7 -O3 -ffast-math -march=haswell -mtune=haswell bug.c -o bug $ ./bug sum: -0.0937 If I turn off -ffast-math or add -fno-tree-loop-vectorize, the problem disappears. Output of gcc-7 -v -save-temps -O3 -ffast-math -march=haswell -mtune=generic bug.c -o bug: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-ffast-math' '-march=haswell' '-mtune=generic' '-o' 'bug' /usr/lib/gcc/x86_64-linux-gnu/7/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu bug.c -march=haswell -mtune=generic -ffast-math -O3 -fpch-preprocess -fstack-protector-strong -Wformat -Wformat-security -o bug.i ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/7/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-ffast-math' '-march=haswell' '-mtune=generic' '-o' 'bug' /usr/lib/gcc/x86_64-linux-gnu/7/cc1 -fpreprocessed bug.i -quiet -dumpbase bug.c -march=haswell -mtune=generic -auxbase bug -O3 -version -ffast-math -fstack-protector-strong -Wformat -Wformat-security -o bug.s GNU C11 (Ubuntu 7.3.0-27ubuntu1~18.04) version 7.3.0 (x86_64-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C11 (Ubuntu 7.3.0-27ubuntu1~18.04) version 7.3.0 (x86_64-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c8081a99abb72bbfd9129549110a350c COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-ffast-math' '-march=haswell' '-mtune=generic' '-o' 'bug' as -v --64 -o bug.o bug.s GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.30 COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-ffast-math' '-march=haswell' '-mtune=generic' '-o' 'bug' /usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=bug.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-th
[Bug c++/89325] [7/8/9 Regression] False warnings about "optimization attribute" on operators when -fno-ipa-cp-clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89325 Jakub Jelinek changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2019-04/msg00494.ht ||ml --- Comment #3 from Jakub Jelinek --- Testsuite patch https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00494.html
[Bug libstdc++/90050] std::filesystem::path segfault in destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050 --- Comment #1 from Mihai Preda --- I would hope somebody would take a look and reject this issues as invalid for some reason, because otherwise it's rather severe.
[Bug tree-optimization/90055] [7 Regression] Incorrect result with ffast-math + tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90055 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Known to work||6.5.0, 8.1.0 Keywords||needs-bisection, wrong-code Last reconfirmed||2019-04-12 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|Incorrect result with |[7 Regression] Incorrect |ffast-math + tree-vectorize |result with ffast-math + ||tree-vectorize Target Milestone|--- |7.5 Known to fail||7.1.0 --- Comment #1 from Richard Biener --- Confirmed - this is likely a duplicate since it seems to be fixed on the GCC 8 branch and trunk. -mavx2 -mfma triggers the issue. w/o -mfma the GCC 7 branch produces -0.0. The GCC 8 branch doesn't vectorize the loop at t.c:104 but the basic-block at 103. Note I observe different unrolling between 7 and 8 so the actual issue might be latent. Martin, can you bisect what fixed this?
[Bug tree-optimization/90055] [7 Regression] Incorrect result with ffast-math + tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90055 Martin Liška changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from Martin Liška --- Fixed on trunk with r250959 which is: 364bc5b93b76cf88(08 Aug 2017 14:09): [took: 2.844s] result: OK sum: 0. SVN revision: 250959 Author: amker * doc/invoke.texi: Document -ftree-loop-distribution for O3. * opts.c (default_options_table): Add OPT_ftree_loop_distribution. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@250959 138bc75d-0d04-0410-961f-82ee72b054a4 Using: gcc pr90055.c -O3 -ffast-math -march=haswell -mtune=haswell -fno-tree-loop-distribution it disappeared in r253934: Author: hubicka * x86-tune-costs.h (core_cost): Fix div, move and sqrt latencies. and it started with r238033.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929 Martin Liška changed: What|Removed |Added Target Milestone|--- |10.0 --- Comment #13 from Martin Liška --- Situation is more complicated, deferring to GCC 10: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00495.html
[Bug middle-end/90056] New: 548.exchange2_r regressions on AMD Zen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90056 Bug ID: 90056 Summary: 548.exchange2_r regressions on AMD Zen Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux As of revision 270053, the 548.exchange2_r benchmark from SPEC 2017 INTrate suite suffered a number of smaller regressions on AMD Zen CPUs: - At -O2, it is 4.5% slower than when compiled with GCC 7 - At -Ofast, it is 4.7% slower than when compiled with GCC 8 - At -Ofast -march=native -mutine=native, this difference is 6.9% - At -Ofast and native tuning, it is 6% slower with PGO than without it. According to https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/options the last regression on a different Ryzen CPU is 6.8 and PGO+LTO is 8.2% slower than just native -Ofast. Bisecting does not help much because the performance of the benchmark has varied a lot. For example in September there was no PGO regression but only because the non-PGO executable was equally slow. I only have data from February from an Intel machine, but there I only saw the native -Ofast regression, but it might have gone away meanwhile. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #66 from Jakub Jelinek ---
(In reply to Iain Sandoe from comment #62)
> (In reply to Iain Sandoe from comment #61)
> > (In reply to Jonathan Wakely from comment #60)
> > > PR 81797 was the relevant bug, which apparently is still present for
> > > darwin
> > > when using the buggy new APFS filesystem
> >
> > so, from discussion on IRC, and notes above, this seems to be a known issue
> > (with AFPS only) and the current remedy is to continue the bootstrap.
> >
> > Let's consider that we have a viable work-around and then please can we wait
> > for a response from Apple and the clang devs before making a final fix?
> >
> > (i.e. this is enough of a work-around to prevent folks from being blocked
> > right now)
>
> BTW if you look at
> https://godbolt.org/z/7nwoLN
> and flip between C and C++, you will see that clang++ is not generating the
> same code for _Atomic int x, as clang (C).
Trying clang vs. clang++ (7.0.1) on
_Atomic int a = 4;
void foo () { a++; }
(admittedly on x86_64-linux), I get the same generated code with C and C++,
except for the mangling of the function, so it seems _Atomic is not ignored.
On the other side, if we fixinclude it, the fixincluded headers will be only
used for gcc and not clang, right, so the condition I wrote should be
sufficient. If the fixincluded headers would be also used by clang, then we
might want to add && !defined(__clang__) to that.
[Bug gcov-profile/90057] New: [GCOV] Wrong coverage for "if()" statement while it is embedded with an empty "for(;0;)" loop statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90057
Bug ID: 90057
Summary: [GCOV] Wrong coverage for "if()" statement while it is
embedded with an empty "for(;0;)" loop statement
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.2.0-1ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04)
$ cat small.c
int main()
{
int b = 0, d = 0, f = 0, p = -1;
if (f > p && p)
for (; 0;)
;
else if (d)
b = 0 >= b;
return 0;
}
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:71.43% of 7
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:
1:2:int main()
-:3:{
1:4: int b = 0, d = 0, f = 0, p = -1;
-:5:
2:6: if (f > p && p)
1:7:for (; 0;)
-:8: ;
#:9: else if (d)
#: 10:b = 0 >= b;
-: 11:
1: 12: return 0;
-: 13:}
Line #6 is wrongly marked as executed twice.
While Line 7 is removed. The result is correct as:
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:66.67% of 6
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:
1:2:int main()
-:3:{
1:4: int b = 0, d = 0, f = 0, p = -1;
-:5:
1:6: if (f > p && p)
-:7:// for (; 0;)
-:8: ;
#:9: else if (d)
#: 10:b = 0 >= b;
-: 11:
1: 12: return 0;
-: 13:}
While Line #9 and Line #10 are both removed, the result is also correct as:
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 5
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:
1:2:int main()
-:3:{
1:4: int b = 0, d = 0, f = 0, p = -1;
-:5:
1:6: if (f > p && p)
1:7:for (; 0;)
-:8: ;
-:9: // else if (d)
-: 10: // b = 0 >= b;
-: 11:
1: 12: return 0;
-: 13:}
[Bug gcov-profile/90054] [GCOV] A call statement to the __builtin_snprintf function is wrongly marked as not executed when it is in a for loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90054 --- Comment #2 from Yibiao Yang --- (In reply to Martin Liška from comment #1) > Fixed on trunk with r263111. Not planning to backport. Got it. Thanks a lot.
[Bug gcov-profile/90053] [GCOV] A statement in while loop is wrongly marked as not executed when they are within the if(setjmp()) statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90053 --- Comment #2 from Yibiao Yang --- (In reply to Richard Biener from comment #1) > I think you need to use setjmp/longjmp, not the __builtin variants which have > special semantics. Thanks for the suggestion. This is a reduced version of the test program in the gcc testsuite: gcc-7.4.0/gcc/testsuite/gcc.dg/setjmp-2.c
[Bug regression/89733] [7/8/9 Regression] -Wuninitialized false positive with unclear message pointing to a class name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89733 --- Comment #8 from Jakub Jelinek --- On the reduced testcase the warning is completely correct. end_ is indeed uninitialized and then copied over in the Y constructor. As the ~F destructor is not defined, GCC can't optimize away those stores
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #67 from Iain Sandoe ---
(In reply to Jakub Jelinek from comment #66)
> (In reply to Iain Sandoe from comment #62)
> > (In reply to Iain Sandoe from comment #61)
> > > (In reply to Jonathan Wakely from comment #60)
> > > > PR 81797 was the relevant bug, which apparently is still present for
> > > > darwin
> > > > when using the buggy new APFS filesystem
> > >
> > > so, from discussion on IRC, and notes above, this seems to be a known
> > > issue
> > > (with AFPS only) and the current remedy is to continue the bootstrap.
> > >
> > > Let's consider that we have a viable work-around and then please can we
> > > wait
> > > for a response from Apple and the clang devs before making a final fix?
> > >
> > > (i.e. this is enough of a work-around to prevent folks from being blocked
> > > right now)
> >
> > BTW if you look at
> > https://godbolt.org/z/7nwoLN
> > and flip between C and C++, you will see that clang++ is not generating the
> > same code for _Atomic int x, as clang (C).
>
> Trying clang vs. clang++ (7.0.1) on
> _Atomic int a = 4;
> void foo () { a++; }
> (admittedly on x86_64-linux), I get the same generated code with C and C++,
> except for the mangling of the function, so it seems _Atomic is not ignored.
Indeed, not sure what caused the compiler explorer instance to report
differently, I can't repeat now (for trunk or 7.x clang).
> On the other side, if we fixinclude it, the fixincluded headers will be only
> used for gcc and not clang, right,
right,
I don't see any mechanism at the moment for clang to use GCC's fixed includes
(it could be forced with -isystem, I suppose - but that's the User's decision).
> so the condition I wrote should be
> sufficient. If the fixincluded headers would be also used by clang, then we
> might want to add && !defined(__clang__) to that.
The folks I'm hoping for comments from are travelling this week (or, I think,
in one case on vacation) so perhaps we can wait a few more days for some
conclusion before applying this (it needs to go on the branches too, I
suppose).
[Bug gcov-profile/90057] [GCOV] Wrong coverage for "if()" statement while it is embedded with an empty "for(;0;)" loop statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90057 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed on trunk in r263111.
[Bug c++/88075] [feature-request] allow "concept" instead of "concept bool" with -fconcepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88075 --- Comment #1 from Hannes Hauswedell --- I see that this has changed for snapshots of GCC9 now, thanks a lot! Is this something you can backport to to GCC7 and GCC8 that would really help downstream projects to reduce needless use of MACROs! Thanks!
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 --- Comment #17 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Fri Apr 12 12:51:58 2019 New Revision: 270313 URL: https://gcc.gnu.org/viewcvs?rev=270313&root=gcc&view=rev Log: gcc/ChangeLog: 2019-04-12 Kelvin Nilsen PR target/87532 * config/rs6000/rs6000.c (rs6000_split_vec_extract_var): Use inner mode of vector rather than mode of destination for move instruction. * config/rs6000/vsx.md (*vsx_extract__mode_var): Use QI inner mode with V16QI vector mode. gcc/testsuite/ChangeLog: 2019-04-12 Kelvin Nilsen PR target/87532 * gcc.target/powerpc/fold-vec-extract-char.p8.c: Adjust expected instruction counts. * gcc.target/powerpc/fold-vec-extract-int.p8.c: Likewise. * gcc.target/powerpc/fold-vec-extract-short.p8.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/vsx.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-char.p8.c trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-int.p8.c trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-extract-short.p8.c
[Bug middle-end/89970] [8/9 Regression] ICE in dispatch_function_versions, at config/i386/i386.c:32347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89970 --- Comment #4 from Martin Liška --- Author: marxin Date: Fri Apr 12 12:54:00 2019 New Revision: 270314 URL: https://gcc.gnu.org/viewcvs?rev=270314&root=gcc&view=rev Log: Handle multiple 'default' in target attribute (PR middle-end/89970). 2019-04-12 Martin Liska PR middle-end/89970 * multiple_target.c (create_dispatcher_calls): Wrap ifunc in error message. (separate_attrs): Handle multiple 'default's. (expand_target_clones): Rework error handling code. 2019-04-12 Martin Liska PR middle-end/89970 * gcc.target/i386/mvc15.c: New test. * gcc.target/i386/mvc3.c: Quote target in error pattern. * gcc.target/i386/mvc4.c: Remove duplicit 'default'. Added: trunk/gcc/testsuite/gcc.target/i386/mvc15.c Modified: trunk/gcc/ChangeLog trunk/gcc/multiple_target.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/mvc3.c trunk/gcc/testsuite/gcc.target/i386/mvc4.c
[Bug middle-end/89970] [8/9 Regression] ICE in dispatch_function_versions, at config/i386/i386.c:32347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89970 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED Known to fail||8.3.0 --- Comment #5 from Martin Liška --- Fixed on trunk, not planning to backport.
[Bug tree-optimization/87008] [8/9 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Is this now fixed on the trunk with r269556?
[Bug middle-end/85563] [8/9 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #15 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #12)
> > Canonical example would be if (int_arg + 32U <= 64U) __builtin_unreachable
> > (),
>
> We don't quite seem to put a range on int_arg with this. We have one
> temporarily, and deduce ranges for things computed based on int_arg, but I
> don't see one on int_arg itself after the pass.
I certainly do see that.
Try -O2 -fdump-tree-all-alias:
int
foo (int int_arg)
{
if (int_arg + 32U <= 64U) __builtin_unreachable ();
return int_arg;
}
Already in the evrp pass there is:
# RANGE ~[-32, 32]
int int_arg_3(D) = int_arg;
[Bug c++/90058] New: False Positive in undefined-sanitizer only with GCC8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90058 Bug ID: 90058 Summary: False Positive in undefined-sanitizer only with GCC8 Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: svenja.mehringer at gmail dot com Target Milestone: --- Created attachment 46148 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46148&action=edit intermediate cpp file Hi, When compiling with the undefined-sanitizer I get an uninitialized warning with GCC8 but not with GCC7 on the same intermediate file. I created the intermediate file with GCC-7.4.0 (flags: -fsanitize=undefined -fdiagnostics-color=always -O3 -DNDEBUG -pedantic -Wall -Wextra -Werror -std=c++17 -fconcepts -save-temps) Then when compiling the following (GCC-8.2.0) g++-8 -O3 -Wall -fsanitize=undefined -std=c++17 -fconcepts -pthread -o format_sam_test-gcc8 format_sam_test.ii gtest_project/src/gtest_project-build/googletest/libgtest.a gtest_project/src/gtest_project-build/googletest/libgtest_main.a this fails with ``` In file included from /srv/public/smehringer/seqan3/test/unit/io/alignment_file/format_sam_test.cpp:17: /srv/public/smehringer/seqan3/include/seqan3/io/alignment_file/format_sam.hpp: In lambda function: /srv/public/smehringer/seqan3/include/seqan3/io/alignment_file/format_sam.hpp:635:58: warning: ‘*((void*)& +12)’ may be used uninitialized in this function [-Wmaybe-uninitialized] write_range(stream_it, (header.ref_ids())[get<0>(mate).value()]); ``` but the exact same command compiles fine with GCC-7.4.0 I'm working on Linux: Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
[Bug d/90059] New: Solaris mcontext_t, ucontext_t declarations are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059 Bug ID: 90059 Summary: Solaris mcontext_t, ucontext_t declarations are wrong Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: *-*-solaris2.* Initially, all Solaris 11/SPARC execution tests (both 32 and 64-bit) FAILed like this: Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfec37d08 in rw_wrlock_impl () from /lib/libc.so.1 (gdb) where #0 0xfec37d08 in rw_wrlock_impl () from /lib/libc.so.1 #1 0xfec3e62c in sigaction () from /lib/libc.so.1 #2 0x000a8be4 in runModuleUnitTests () at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:506 #3 0x0007bfac in runAll (this=this@entry=0xffbfe78c) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:484 #4 0x0007ba9c in tryExec (this=0xffbfe78c, dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:460 #5 0x0007bcb4 in _d_run_main (argc=1, argv=, mainFunc=) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:493 #6 0x000686d4 in main (argc=1, argv=0xffbfe864) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/__entrypoint.di:44 #7 0x000684c4 in _start () Backtrace stopped: previous frame identical to this frame (corrupt stack?) with libphobos built with -g3 -O0: 0xfec37cec : save %sp, -96, %sp 0xfec37cf0 : ld [ %g7 + 0x54 ], %i5 0xfec37cf4 : sethi %hi(0x2800), %i3 0xfec37cf8 : mov %g7, %l6 0xfec37cfc : add %i3, 0x146, %i2 0xfec37d00 : rd %pc, %i4 0xfec37d04 : sethi %hi(0x6a000), %g1 => 0xfec37d08 : ldsb [ %i5 + %i2 ], %l7 (gdb) p/x $i5 $14 = 0x0 (gdb) p/x $i2 $15 = 0x2946 The first arg (an rwlock_t *) should never be NULL. After some debugging, this turned out to be memory corruption happening after the call to swapcontext in fiber_switchContext. The root cause was that the declarations of mcontext_t and ucontext_t in core.sys.posix.ucontext are badly wrong for Solaris/SPARC. After correcting them as in the attached patch, those SEGVs are gone. Solaris/x86 is mostly right, the only correction being the introduction of the uc_xrs member of struct ucontext_t. This doesn't change either size or alignment, so it's primarily a cosmetic issue. This again seems strongly to argue for an approach like libgo's (generating Go structure declarations from the system headers at build time) or at least libsanitizer's (verifying struct sizes and member offsets at runtime) to avoid such isses.
[Bug d/90059] Solaris mcontext_t, ucontext_t declarations are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug d/90059] Solaris mcontext_t, ucontext_t declarations are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90059 --- Comment #1 from Rainer Orth --- Created attachment 46149 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46149&action=edit Correct Solaris mcontext_t, ucontext_t declarations
[Bug c++/90058] False Positive in undefined-sanitizer only with GCC8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90058 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- As has been said many times, the -fsanitize= instrumentation affects (sometimes a lot) the optimizations and so introduces various late warning false positives. Use -fsanitize= to build the instrumented code, but pay more attention to warnings from non-instrumented builds.
[Bug d/90060] New: libphobos.druntime_shared/core/thread.d FAILs on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90060 Bug ID: 90060 Summary: libphobos.druntime_shared/core/thread.d FAILs on Solaris/SPARC Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc*-sun-solaris2.11 Created attachment 46150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46150&action=edit Use __makecontext_v2 on Solaris/SPARC With PR d/90059 fixed, (at least) the core.thread unittest FAILs: FAIL: libphobos.druntime_shared/core/thread.d execution test Segmentation fault while running unittests: Program terminated with signal SIGSEGV, Segmentation fault. #0 sparc64_is_sighandler (nframes=, cfa=0x7fffd470, pc=0x7f5c3fc8) at ./md-unwind-support.h:39 39 ./md-unwind-support.h: No such file or directory. [Current thread is 2 (Thread 1 (LWP 1))] (gdb) where #0 sparc64_is_sighandler (nframes=, cfa=0x7fffd470, pc=0x7f5c3fc8) at ./md-unwind-support.h:39 #1 sparc64_fallback_frame_state (fs=0x7fffbf40, context=0x7fffbb50) at ./md-unwind-support.h:271 #2 uw_frame_state_for (context=context@entry=0x7fffbb50, fs=fs@entry=0x7fffbf40) at /builds2/ulhg/workspace/Solaris_Trunk/Userland/full-build/02b-build-sparc/components/gcc7/gcc-7.3.0/libgcc/unwind-dw2.c:1257 #3 0x73b0ed50 in _Unwind_Backtrace ( trace=0x5d362438 , trace_argument=0x7fffc6d0) at /builds2/ulhg/workspace/Solaris_Trunk/Userland/full-build/02b-build-sparc/components/gcc7/gcc-7.3.0/libgcc/unwind.inc:290 #4 0x5d3624dc in backtrace_simple (state=0x7f5e8000, skip=, callback=0x5d2e40c4 , error_callback=0x5d2e4c28 , data=0x7fffc860) at /vol/gcc/src/hg/trunk/solaris/libbacktrace/simple.c:106 #5 0x5d2e521c in gcc.backtrace.LibBacktrace.this(int) ( this=0x7fffc860, firstFrame=1) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gcc/backtrace.d:227 #6 0x5d2cd248 in core.runtime.runModuleUnitTests().unittestSegvHandler(int, core.sys.posix.signal.siginfo_t*, void*) (signum=11, info=0x7fffd370, ptr=0x7fffd060) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:492 #7 #8 0x7ef261b0 in memset%sun4v-hwcap4 () from /lib/64/libc.so.1 #9 0x7ede9108 in makecontext () from /lib/64/libc.so.1 #10 0x000100015bbc in core.thread.Fiber.initStack() ( this=0x7f1f6000) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:5051 #11 0x000100015930 in core.thread.Fiber.reset() (this=0x7f1f6000) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:4294 #12 0x00010001536c in core.thread.Fiber.reset(void() delegate) ( this=0x7f1f6000, dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:4309 #13 0x0001000152a4 in core.thread.Fiber.this(void() delegate, ulong, ulong) (this=0x7f1f6000, dg=..., sz=32768, guardPageSize=8192) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:4157 #14 0x00010001620c in core.thread.TestFiber.this() ( this=0x7f1f6000) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:5175 #15 0x000100016300 in core.thread.runTen() () at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:5195 #16 0x000100016578 in core.thread.__unittestL5218_20() () at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/thread.d:5220 #17 0x000100018cf8 in core.thread.__modtest() () at :1 #18 0x5d2cd388 in __foreachbody2 (this=0x7fffe308, m=0x1001208b8 ) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:558 #19 0x5d2f49ec in object.ModuleInfo.__lambda2 ( this=0x7fffe230, m=0x1001208b8 ) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1599 #20 0x5d30f600 in rt.minfo.__foreachbody2 (this=0x7fffe158, sg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:777 #21 0x5d314410 in rt.sections_elf_shared.DSO.opApply(scope int(ref rt.sections_elf_shared.DSO) delegate) (dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:69 #22 0x5d30f4e8 in rt.minfo.moduleinfos_apply(scope int(immutable(object.ModuleInfo*)) delegate) (dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:770 #23 0x5d2f26bc in object.ModuleInfo.opApply(scope int(object.ModuleInfo*) delegate) (dg=...) at /vol/g
[Bug d/90060] libphobos.druntime_shared/core/thread.d FAILs on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90060 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug fortran/89291] internal compiler error: in gfc_trans_use_stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89291 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Dominique d'Humieres --- > If someone wants to try to download and build this. Too many prerequisites for me!-( Closing as INVALID.
[Bug translation/90061] New: ARM cortex-M hard fault on 64 bit sized object store to unaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061
Bug ID: 90061
Summary: ARM cortex-M hard fault on 64 bit sized object store
to unaligned address
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: mike at hamble dot online
Target Milestone: ---
When generating code for ARM Cortex M4 CPU, and a 64 bit object is stored in
memory to a possibly unaligned address, the code generated will cause an
exception in the case the address is not single word (32 bit aligned).
This fault is dependent on optimisation level in some cases.
This is because the 64 bit store operation generates either a STD or a STMIA
style instruction which requires 32 bit address alignment.
Single 32 bit word stores can be unaligned.
#pragma pack(push, 1)
struct hardwareExample
{
char x;
long a;
long b;
} s;
#pragma pack(pop)
If you are accessing hardware or message buffers where the structs map 1:1 to
external message content, you may well try to set the value of s.a and s.b
close together. The optimiser may try to combine these as a store multiple
operation on an ARM has always been more efficient than independent writes.
In -Og mode this code generates two independent 32 bit store unaligned
operations and it works.
In -Os mode this code will combine s.a and s.b store into a single STD or STMIA
instruction and produce a hard fault.
If the 64 bit value is an atomic type ; long long or double float for instance
then you cannot escape the hard fault.
In normal code , this problem does not occur as the structure would be created
with the correct alignment for the types, and would be allocated at the correct
alignment for the types concerned.
It is only where I am handling e.g. a binary GPS protocol.
There are always workarounds, it is just annoying that -Og code will work and
-Os code will fail (sometimes dependent on arbitrary structure alignment)
[Bug translation/90061] ARM cortex-M hard fault on 64 bit sized object store to unaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061 Michael James changed: What|Removed |Added Target||ARM Cortex M4 --- Comment #1 from Michael James --- I have seen the same bug in I believe versions of GCC from 4.x onwards
[Bug d/90062] New: SPARC stack alignment is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90062 Bug ID: 90062 Summary: SPARC stack alignment is wrong Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc*-*-* Created attachment 46151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46151&action=edit Correct SPARC stack alignment Even after the ucontext_t and makecontext patches, Solaris/SPARC execution tests were still FAILing (seem to have lost the notes about the details ;-(). However, I found that stack alignment was less than the SPARC ABI requires, i.e. doubleword alignment (also cf. sparc/sparc.h (SPARC_STACK_ALIGN)). The attached patch fixes that. However, I've been lazy and always use the existing 16-byte alignment code, although strictly speaking 32-bit SPARC only needs 8 bytes.
[Bug d/90062] SPARC stack alignment is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90062 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug tree-optimization/87008] [8 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008 Martin Jambor changed: What|Removed |Added Version|9.0 |8.3.1 Summary|[8/9 Regression] gimple |[8 Regression] gimple |mem-to-mem assignment badly |mem-to-mem assignment badly |optimized |optimized --- Comment #10 from Martin Jambor --- (In reply to Jakub Jelinek from comment #9) > Is this now fixed on the trunk with r269556? Yes. (And I guess it is about time I should start preparing a backport to GCC 8 too.)
[Bug d/90063] New: druntime DSO first assertion fails on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90063
Bug ID: 90063
Summary: druntime DSO first assertion fails on Solaris/SPARC
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: sparc*-sun-solaris2.11
The next issue with Solaris 11/SPARC execution tests is
FAIL: libphobos.druntime_shared/core/internal/hash.d execution test
Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x5e858a5c in gc_malloc (sz=80, ba=0,
ti=0x5e988de0 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gc/proxy.d:117
117 return instance.malloc(sz, ba, ti);
(gdb) where
#0 0x5e858a5c in gc_malloc (sz=80, ba=0,
ti=0x5e988de0 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gc/proxy.d:117
#1 0x5e7cc74c in core.memory.GC.malloc(ulong, uint, const(TypeInfo)) (
sz=80, ba=0,
ti=0x5e988de0 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/memory.d:380
#2 0x5e803b60 in _d_newclass (
ci=0x5e988de0 )
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/lifetime.d:96
#3 0x5e7c9df8 in onAssertError (file=..., line=398)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/exception.d:441
#4 0x5e7ca444 in _d_assert (file=..., line=398)
at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/exception.d:641
#5 0x5e815684 in _d_dso_registry (data=0x7fffcfa0)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:398
#6 0x000137cc in gdc.dso_ctor () at :1
#7 0x00012db8 in global constructors keyed to 4core8internal4hash ()
at
/vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../libdruntime/core/internal/hash.d:1
#8 0x7f3253f0 in call_array () from /usr/lib/sparcv9/ld.so.1
#9 0x7f325590 in call_init () from /usr/lib/sparcv9/ld.so.1
#10 0x7f335524 in elf_bndr () from /usr/lib/sparcv9/ld.so.1
#11 0x7f316488 in elf_rtbndr () from /usr/lib/sparcv9/ld.so.1
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
#5 0x5e815684 in _d_dso_registry (data=0x7fffcfa0)
at
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:398
398 assert(handleForAddr(data._slot) ==
handleForAddr(&rt_get_bss_start));
(gdb) p data
$2 = (rt.sections_elf_shared.CompilerDSOData *) 0x7fffcfa0
(gdb) p *data
$3 = {_version = 1, _slot = 0x1001043d8 ,
_minfo_beg = 0x1001043b0 <__start_minfo>, _minfo_end = 0x1001043c8}
I haven't dug further yet why this fails on Solaris/SPARC, but not on
Solaris/x86.
For the moment, I've just disabled the assert.
[Bug d/90063] druntime DSO first assertion fails on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90063 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug middle-end/85563] [8/9 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563 --- Comment #16 from Marc Glisse --- (In reply to Jakub Jelinek from comment #15) > I certainly do see that. Uh, indeed. I don't remember what I may have tested where we failed to set a range, or maybe I just got confused, better ignore my comment then.
[Bug d/90064] New: InSituRegion lacks SPARC64 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90064 Bug ID: 90064 Summary: InSituRegion lacks SPARC64 support Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc*-*-* Created attachment 46152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46152&action=edit InSituRegion SPARC64 support This tests only FAILs on 64-bit SPARC: FAIL: libphobos.phobos_shared/std/experimental/allocator/building_blocks/bitmapped_block.d (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/solaris/libphobos/src/std/experimental/allocator/building_blocks/region.d:402: error: undefined identifier 'growDownwards' /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/experimental/allocator/building_blocks/bitmapped_block.d:698: error: template instance std.experimental.allocator.building_blocks.region.InSituRegion!(10240LU, 64LU) error instantiating /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/experimental/allocator/building_blocks/bitmapped_block.d:700: note: while evaluating: static assert(hasMember!(InSituRegion!(10240LU, 64LU), "allocateAll")) The fix is trivial: just handle SPARC64 like SPARC. The attached patch does that.
[Bug d/90064] InSituRegion lacks SPARC64 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90064 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug d/90065] New: Unaligned accesses on strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90065 Bug ID: 90065 Summary: Unaligned accesses on strict-alignment targets Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparc*-*-* Created attachment 46153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46153&action=edit src/std/math.d alignment hack I see a couple of tests FAIL due to the same issue on Solaris/SPARC: they die with SIGBUS due to unaligned access, which is a no-no on strict-alignment targets. FAIL: libphobos.phobos_shared/std/math.d execution test Segmentation fault while running unittests: /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:492 extern (C) void core.runtime.runModuleUnitTests().unittestSegvHandler(int, core.sys.posix.signal.siginfo_t*, void*) [0x590cd287] ??:? __sighndlr [0x7eee41bf] /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:6178 pure nothrow @nogc @trusted real std.math.NaN(ulong) [0x10003744c] /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:1052 nothrow @nogc @safe void std.math.__unittestL1001_11() [0x100037273] /var/gcc/gcc-9.0.1-20190408/11.5-gcc-gas-libphobos/sparc-sun-solaris2.11/libphobos/testsuite/libphobos9/:1 void std.math.__modtest() [0x1000697c3] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:558 __foreachbody2 [0x590cd3c7] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1599 __lambda2 [0x590f4a2b] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:777 __foreachbody2 [0x5910f63f] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:69 int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) [0x5911444f] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:770 int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) [0x5910f527] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1598 int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x590f26fb] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:548 runModuleUnitTests [0x590cd0b3] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:484 runAll [0x5910323b] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:460 tryExec [0x5910317b] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/dmain2.d:493 _d_run_main [0x59103073] /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/__entrypoint.di:44 main [0x100069b3f] ??:? _start [0x100032e8b] truss shows the SIGBUS Incurred fault #5, FLTACCESS %pc = 0x10003734C siginfo: SIGBUS BUS_ADRALN addr=0x7FFFD942 Received signal #10, SIGBUS [default] siginfo: SIGBUS BUS_ADRALN addr=0x7FFFD942 but gdb currently mis-reports it as SIGSEGV (as does the libdruntime signal handler). Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x00010003734c in std.math.NaN(ulong) (payload=291) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:6178 6178*cast(ulong*)(2+cast(ubyte*)(&x)) = v; (gdb) where #0 0x00010003734c in std.math.NaN(ulong) (payload=291) at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:6178 #1 0x000100037174 in std.math.__unittestL1001_11() () at /vol/gcc/src/hg/trunk/solaris/libphobos/testsuite/../src/std/math.d:1052 #2 0x0001000696c4 in std.math.__modtest() () at :1 #3 0x57bcd3c8 in __foreachbody2 (this=0x7fffdfe8, m=0x1001bfb38 ) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/runtime.d:558 #4 0x57bf4a2c in object.ModuleInfo.__lambda2 ( this=0x7fffdf10, m=0x1001bfb38 ) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1599 #5 0x57c0f640 in rt.minfo.__foreachbody2 (this=0x7fffde38, sg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:777 #6 0x57c14450 in rt.sections_elf_shared.DSO.opApply(scope int(ref rt.sections_elf_shared.DSO) delegate) (dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/sections_elf_shared.d:69 #7 0x57c0f528 in rt.minfo.moduleinfos_apply(scope int(immutable(object.ModuleInfo*)) delegate) (dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/rt/minfo.d:770 #8 0x57bf26fc in object.ModuleInfo.opApply(scope int(object.ModuleInfo*) delegate) (dg=...) at /vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/object.d:1598 #9 0x57bcd0b4 in runModuleUnitTests () at /vol/gcc/src/hg/trunk/solaris/libphobos/
[Bug d/90065] Unaligned accesses on strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90065 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug translation/90061] ARM cortex-M hard fault on 64 bit sized object store to unaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2019-04-12
CC||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Alexander Monakov ---
Please provide an example, as a simple smoke-test is compiled correctly:
long f(struct hardwareExample *h)
{
return h->a + h->b;
}
produces
f:
ldr r2, [r0, #1] @ unaligned
ldr r0, [r0, #5] @ unaligned
add r0, r0, r2
bx lr
[Bug gcov-profile/90066] New: [GCOV] function with inline attribute leading to incorrect coverage for the "if" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90066
Bug ID: 90066
Summary: [GCOV] function with inline attribute leading to
incorrect coverage for the "if" statement
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.2.0-1ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04)
$ cat small.c
int check_int (int *i, int align)
{
*i = 20;
return *i;
}
typedef int aligned __attribute__((aligned(64)));
static void
inline __attribute__((always_inline))
foo (void)
{
aligned i;
if (check_int (&i, __alignof__(i)) != i)
; // abort ();
}
int main()
{
foo ();
return 0;
}
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 6
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int check_int (int *i, int align)
-:2:{
1:3: *i = 20;
1:4: return *i;
-:5:}
-:6:
-:7:typedef int aligned __attribute__((aligned(64)));
-:8:
-:9:static void
-: 10:inline __attribute__((always_inline))
-: 11:foo (void)
-: 12:{
-: 13: aligned i;
2: 14: if (check_int (&i, __alignof__(i)) != i)
-: 15:; // abort ();
-: 16:}
-: 17:
1: 18:int main()
-: 19:{
-: 20: foo ();
1: 21: return 0;
-: 22:}
Line #14 is wrongly marked as executed twice. This statement should be only
executed once.
1. While Line #10 @@inline __attribute__((always_inline))@@ is removed, the
result is correct as:
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 9
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int check_int (int *i, int align)
-:2:{
1:3: *i = 20;
1:4: return *i;
-:5:}
-:6:
-:7:typedef int aligned __attribute__((aligned(64)));
-:8:
-:9:static void
-: 10:// inline __attribute__((always_inline))
1: 11:foo (void)
-: 12:{
-: 13: aligned i;
1: 14: if (check_int (&i, __alignof__(i)) != i)
-: 15:; // abort ();
1: 16:}
-: 17:
1: 18:int main()
-: 19:{
1: 20: foo ();
1: 21: return 0;
-: 22:}
2. While Line #12 is not removed, the result is also correct as:
$ gcc -w -O0 --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov
File 'small.c'
Lines executed:85.71% of 7
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
1:1:int check_int (int *i, int align)
-:2:{
1:3: *i = 20;
1:4: return *i;
-:5:}
-:6:
-:7:typedef int aligned __attribute__((aligned(64)));
-:8:
-:9:static void
-: 10:inline __attribute__((always_inline))
-: 11:foo (void)
-: 12:{
-: 13: aligned i;
1: 14: if (check_
[Bug tree-optimization/81435] missing strlen optimization for strcat past the beginning of clear array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81435 --- Comment #3 from Martin Sebor --- I think it means that Andrew is a maintainer of the overall tree-ssa infrastructure. AFAIK, he has not done any work on the strlen optimizations in the file. Jakub is the author of the pass so he knows the most about it. But he's also aware of most bugs that come in so I don't think he needs to be CC'd. Most of the bugs I raised for the strlen pass are enhancements. I noticed them while testing various warnings (-Wstringop-overflow, -Wrestrict, etc.) where they imply false negatives. The optimizations themselves aren't necessarily critical to performance but the better the strlen pass is at optimizing stuff the better the warnings are at finding bugs. I expect to be doing some work on the strlen pass for GCC 10 so I might pick up some of these bugs in the process.
[Bug tree-optimization/87008] [8 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
--- Comment #11 from Marc Glisse ---
The original testcase also shows a small, unrelated regression: DSE3 used to be
able to remove the initialization of sum to 0 when there were 2 statements
(setting each element to 0). Now that we vectorize so that sum is initialized
with { 0.0, 0.0 } in a single statement, DSE doesn't manage anymore, it doesn't
see that the 2 writes together cover the whole thing. Probably if we improved
the vectorizer to vectorize this loop (I think the blocker is that we go from
{x,y} to {x+y,x+y}), it would manage again.
[Bug gcov-profile/90066] [GCOV] function with inline attribute leading to incorrect coverage for the "if" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90066 Martin Liška changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-12 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- This is again a test-case with a dead condition: _1 = check_int (&i, 64); i.0_2 = i; if (_1 != i.0_2) goto ; else goto ; : :
[Bug fortran/90048] Fortran OpenACC 'private' clause rejected for predetermined private loop iteration variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90048 Thomas Schwinge changed: What|Removed |Added Summary|Fortran OpenACC 'private' |Fortran OpenACC 'private' |clause rejected for |clause rejected for |implicitly private loop |predetermined private loop |iteration variable |iteration variable --- Comment #1 from Thomas Schwinge --- (Summary corrected to say "predetermined private" instead of "implicitly private".) OpenACC 2.6 (same in 2.7), in section 2.6.1. "Variables with Predetermined Data Attributes" states that "The loop variable in a C 'for' statement or Fortran 'do' statement that is associated with a loop directive is predetermined to be private to each thread that will execute each iteration of the loop. Loop variables in Fortran 'do' statements within a compute construct are predetermined to be private to the thread that executes the loop". It also states in section 2.6. "Data Environment" that "Variables with predetermined data attributes may not appear in a data clause that conflicts with that data attribute", which can be understood to mean that such variables may (redundantly) appear in clauses that conform with that data attribute.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #17 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #15)
> Forming thread by copy 0:a0r111-a4r117 (freq=500):
> Result (freq=3500): a0r111(2500) a4r117(1000)
> Forming thread by copy 2:a3r112-a5r116 (freq=125):
> Result (freq=4500): a3r112(1500) a5r116(3000)
> Forming thread by copy 1:a2r114-a3r112 (freq=62):
> Result (freq=5500): a2r114(1000) a3r112(1500) a5r116(3000)
> Pushing a1(r113,l0)(cost 0)
> Pushing a4(r117,l0)(cost 0)
> Pushing a0(r111,l0)(cost 0)
> Pushing a2(r114,l0)(cost 0)
> Pushing a3(r112,l0)(cost 0)
> Pushing a5(r116,l0)(cost 0)
> Popping a5(r116,l0) -- assign reg 3
> Popping a3(r112,l0) -- assign reg 4
> Popping a2(r114,l0) -- assign reg 3
> Popping a0(r111,l0) -- assign reg 0
> Popping a4(r117,l0) -- assign reg 0
> Popping a1(r113,l0) -- assign reg 2
> Assigning 4 to a5r116
> Disposition:
> 0:r111 l0 03:r112 l0 41:r113 l0 22:r114 l0 3
> 5:r116 l0 44:r117 l0 0
>
>
> r116 does not conflict with *any* other pseudo. It is alive in the first
> two insns of the function, which are
>
> (insn 50 3 7 2 (set (reg:SI 116)
> (reg:SI 0 r0 [ a ])) "ira-shrinkwrap-prep-1.c":14:1 181
> {*arm_movsi_insn}
> (nil))
> (insn 7 50 8 2 (parallel [
> (set (reg:CC 100 cc)
> (compare:CC (reg:SI 116)
> (const_int 0 [0])))
> (set (reg/v:SI 112 [ a ])
> (reg:SI 116))
> ]) "ira-shrinkwrap-prep-1.c":17:6 188 {*movsi_compare0}
> (expr_list:REG_DEAD (reg:SI 116)
> (nil)))
>
> r0 _is_ used by a successor (as the argument for the call to foo), but we
> could use r0 for r116 anyway, since what we assign to it is r0 :-)
CCing Vlad on this. I don't see that *movsi_compare0 would in any way prefer
the =r,0 alternative over =r,r and using the =r,r alternative would allow to
remove one instruction.
[Bug translation/90061] ARM cortex-M hard fault on 64 bit sized object store to unaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061
--- Comment #3 from Michael James ---
HiSimple tests do not seem to be failing here either regardless of
optimisation.They are all producing correct 32 bit load/stores that can be
non-aligned. I shall try and extract the code from my larger project on
Monday.MikePLEASE NOTE email address change to mike@hamble.online
Original message From: "amonakov at gcc dot gnu.org"
Date: 12/04/2019 15:07 (GMT+00:00) To:
mike@hamble.online Subject: [Bug translation/90061] ARM cortex-M hard fault on
64 bit sized
object store to unaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061Alexander Monakov changed: What |Removed
|Added
Status|UNCONFIRMED |WAITING Last reconfirmed|
|2019-04-12 CC|
|amonakov at gcc dot gnu.org Ever confirmed|0
|1--- Comment #2 from Alexander Monakov ---Please
provide an example, as a simple smoke-test is compiled correctly:long f(struct
hardwareExample *h){ return h->a + h->b;}producesf: ldr r2, [r0,
#1] @ unaligned ldr r0, [r0, #5] @ unaligned add
r0, r0, r2 bx lr-- You are receiving this mail because:You
reported the bug.
[Bug fortran/90067] New: Loop variables in Fortran 'do' statements within a compute construct must be predetermined private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90067 Bug ID: 90067 Summary: Loop variables in Fortran 'do' statements within a compute construct must be predetermined private Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- Found while working on PR90048. OpenACC 2.6 (same in 2.7), in section 2.6.1. "Variables with Predetermined Data Attributes" states that "The loop variable in a C 'for' statement or Fortran 'do' statement that is associated with a loop directive is predetermined to be private to each thread that will execute each iteration of the loop. Loop variables in Fortran 'do' statements within a compute construct are predetermined to be private to the thread that executes the loop". Regarding the latter, for Fortran 'do' statements that are not directly associated with a 'loop' directive, when these 'do' statements are (somewhere) nested inside a 'loop' construct, we implement this in the front end by adding a 'private' clause to the containing 'loop' construct, but when these 'do' statements are not (somewhere) nested inside a 'loop' construct, we do not add a 'private' clause to the containing compute construct. For example, for: integer :: i !$acc parallel do i = 1, 100 end do !$acc end parallel ..., we do not in the front end add a 'private(i)' clause to the 'parallel' construct. By the rules as presented in section 2.5. "Compute Constructs", the gimplifier will then fix this up by adding a 'firstprivate' clause, in the common case of the 'parallel' construct (same for the 'serial' construct, but a 'copy' clause for the 'kernels' construct!). While it might generally be beneficial to have a pass promoting 'firstprivate(x)' with a dominating write operation on 'x' to 'private(x)', here it would be better (and much simpler) to handle this in the front end.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #45 from Ramana Radhakrishnan ---
(In reply to Jakub Jelinek from comment #42)
> Thanks for the explanation.
> In that case, I think it would be better to just add
> __attribute__((target("general-regs-only")))
> to the
> #ifdef __ARM_EABI_UNWINDER__
> _Unwind_Reason_Code
> PERSONALITY_FUNCTION (_Unwind_State, struct _Unwind_Exception *,
> struct _Unwind_Context *);
> decl in unwind-c.c and similarly for eh_personality.cc and to other
> personality routines that use CONTINUE_UNWINDING as well (plus to
> unwind-arm.c and pr-support.c using pragma for everything).
Thanks for all the analysis, this is what I had - I've been swamped this week
on a few other things, let me get this wrapped up soonish. (read it as during
next week).(In reply to Bernd Edlinger from comment #44)
> Comment on attachment 46013 [details]
> updated patch.
>
> @@ -122,12 +122,21 @@ extern tree arm_fp16_type_node;
> #define TARGET_32BIT_P(flags) (TARGET_ARM_P (flags) || TARGET_THUMB2_P
> (flags))
>
> /* Run-time Target Specification. */
> -/* Use hardware floating point instructions. */
> +/* Use hardware floating point instructions. -mgeneral-regs-only prevents
> +the use of floating point instructions and registers but does not prevent
> +emission of floating point pcs attributes. */
> #define TARGET_HARD_FLOAT(arm_float_abi != ARM_FLOAT_ABI_SOFT\
> + && bitmap_bit_p (arm_active_target.isa, \
> + isa_bit_vfpv2) \
> + && TARGET_32BIT \
> + && !TARGET_GENERAL_REGS_ONLY)
> +
> +#define TARGET_HARD_FLOAT_SUB(arm_float_abi != ARM_FLOAT_ABI_SOFT
> \
>&& bitmap_bit_p (arm_active_target.isa, \
> isa_bit_vfpv2) \
>&& TARGET_32BIT)
>
>
> BTW, you could define TARGET_HARD_FLOAT in terms of TARGET_HARD_FLOAT_SUB and
> !TARGET_GENERAL_REGS_ONLY.
Yep I could - been traveling quite a lot and I haven't managed to find someone
else to catch this - I will pick this up next week .
My fault, apologies.
Ramana
[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953 --- Comment #4 from rene.r...@fu-berlin.de --- Hi gcc-team, is there any news about this issue? This ICE currently is always triggered when using the range-v3 library using the 1.0-beta branch with concepts. Let me know, if you need more information. Kind regards
[Bug target/89993] Inconsistent incoming stack boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89993 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from H.J. Lu --- -mstackrealign works as intended. It will align the stack for the function and won't align the stack for the outgoing stack.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #18 from Peter Bergner --- (In reply to Segher Boessenkool from comment #15) > Popping a5(r116,l0) -- assign reg 3 > Popping a3(r112,l0) -- assign reg 4 > Popping a2(r114,l0) -- assign reg 3 > Popping a0(r111,l0) -- assign reg 0 > Popping a4(r117,l0) -- assign reg 0 > Popping a1(r113,l0) -- assign reg 2 > Assigning 4 to a5r116 > Disposition: > 0:r111 l0 03:r112 l0 41:r113 l0 22:r114 l0 3 > 5:r116 l0 44:r117 l0 0 > > > r116 does not conflict with *any* other pseudo. It is alive in the first > two insns of the function, which are So we initially assign r3 to r116 presumably because it has the same cost as the other gprs and it occurs first in REG_ALLOC_ORDER. Then improve_allocation() decides that r4 is a better hard reg and switches the assignment to that. I'm not sure why it wouldn't choose r0 there instead.
[Bug tree-optimization/90055] [7 Regression] Incorrect result with ffast-math + tree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90055 --- Comment #3 from Andrew Pinski --- (In reply to Martin Liška from comment #2) > Fixed on trunk with r250959 which is: > > 364bc5b93b76cf88(08 Aug 2017 14:09): [took: 2.844s] result: OK > sum: 0. > SVN revision: 250959 > Author: amker > * doc/invoke.texi: Document -ftree-loop-distribution for O3. > * opts.c (default_options_table): Add OPT_ftree_loop_distribution. > > > git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@250959 > 138bc75d-0d04-0410-961f-82ee72b054a4 > > Using: > gcc pr90055.c -O3 -ffast-math -march=haswell -mtune=haswell > -fno-tree-loop-distribution > > it disappeared in r253934: > > Author: hubicka > * x86-tune-costs.h (core_cost): Fix div, move and sqrt latencies. Those look like they are all would cause the issue to go latent. > > and it started with r238033. This one does it might be the real cause of the issue.
[Bug c++/87603] [C++17] noexcept isn't special cased for constant expressions anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87603 --- Comment #10 from Marek Polacek --- Author: mpolacek Date: Fri Apr 12 15:29:03 2019 New Revision: 270320 URL: https://gcc.gnu.org/viewcvs?rev=270320&root=gcc&view=rev Log: PR c++/87603 - constexpr functions are no longer noexcept. * constexpr.c (is_sub_constant_expr): Remove unused function. * cp-tree.h (is_sub_constant_expr): Remove declaration. * except.c (check_noexcept_r): Don't consider a call to a constexpr function noexcept. * g++.dg/cpp0x/constexpr-noexcept.C: Adjust the expected result. * g++.dg/cpp0x/constexpr-noexcept3.C: Likewise. * g++.dg/cpp0x/constexpr-noexcept4.C: Likewise. * g++.dg/cpp0x/constexpr-noexcept8.C: New test. * g++.dg/cpp0x/inh-ctor32.C: Remove dg-message. * g++.dg/cpp1y/constexpr-noexcept1.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-noexcept8.C trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-noexcept1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/except.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-noexcept.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-noexcept3.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-noexcept4.C trunk/gcc/testsuite/g++.dg/cpp0x/inh-ctor32.C
[Bug c++/87603] [C++17] noexcept isn't special cased for constant expressions anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87603 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Marek Polacek --- Fixed for GCC 9 (all dialects changed).
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #19 from Wilco --- (In reply to Peter Bergner from comment #18) > (In reply to Segher Boessenkool from comment #15) > > Popping a5(r116,l0) -- assign reg 3 > > Popping a3(r112,l0) -- assign reg 4 > > Popping a2(r114,l0) -- assign reg 3 > > Popping a0(r111,l0) -- assign reg 0 > > Popping a4(r117,l0) -- assign reg 0 > > Popping a1(r113,l0) -- assign reg 2 > > Assigning 4 to a5r116 > > Disposition: > > 0:r111 l0 03:r112 l0 41:r113 l0 22:r114 l0 3 > > 5:r116 l0 44:r117 l0 0 > > > > > > r116 does not conflict with *any* other pseudo. It is alive in the first > > two insns of the function, which are > > So we initially assign r3 to r116 presumably because it has the same cost as > the other gprs and it occurs first in REG_ALLOC_ORDER. Then > improve_allocation() decides that r4 is a better hard reg and switches the > assignment to that. I'm not sure why it wouldn't choose r0 there instead. I would expect that r116 has a strong preference for r0 given the r116 = mov r0 and thus allocating r116 to r0 should have the lowest cost by a large margin.
[Bug translation/90041] Command line option without proper quoting in translation message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90041 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Apr 12 16:12:49 2019 New Revision: 270321 URL: https://gcc.gnu.org/viewcvs?rev=270321&root=gcc&view=rev Log: PR translation/90041 * exgettext: Print MissingArgError, UnknownError or Warn *.opt argument using error or warning instead of _ to mark it as gcc-internal-format. * c.opt (-fhandle-exceptions): Use %< and %> around option names in the Warn diagnostics. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/po/ChangeLog trunk/gcc/po/exgettext
[Bug rtl-optimization/89965] [8/9 Regression] wrong code with -O -mtune=nano-x2 -fcaller-saves -fexpensive-optimizations -fno-tree-dce -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Fri Apr 12 16:20:21 2019 New Revision: 270323 URL: https://gcc.gnu.org/viewcvs?rev=270323&root=gcc&view=rev Log: PR rtl-optimization/89965 * dce.c: Include rtl-iter.h. (struct check_argument_load_data): New type. (check_argument_load): New function. (find_call_stack_args): Check for loads from stack slots still tracked in sp_bytes and punt if any is found. * gcc.target/i386/pr89965.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr89965.c Modified: trunk/gcc/ChangeLog trunk/gcc/dce.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/89965] [8 Regression] wrong code with -O -mtune=nano-x2 -fcaller-saves -fexpensive-optimizations -fno-tree-dce -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89965 Jakub Jelinek changed: What|Removed |Added Known to work||9.0 Summary|[8/9 Regression] wrong code |[8 Regression] wrong code |with -O -mtune=nano-x2 |with -O -mtune=nano-x2 |-fcaller-saves |-fcaller-saves |-fexpensive-optimizations |-fexpensive-optimizations |-fno-tree-dce -fno-tree-ter |-fno-tree-dce -fno-tree-ter Known to fail|9.0 | --- Comment #13 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug translation/90041] Command line option without proper quoting in translation message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90041 --- Comment #5 from Jakub Jelinek --- %e/%n still not resolved and won't be until GCC 10.
[Bug fortran/90068] New: Array Constructor Containing Function Call Leaks Memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90068 Bug ID: 90068 Summary: Array Constructor Containing Function Call Leaks Memory Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: brichardson at structint dot com Target Milestone: --- It appears that without an intermediate value to save the result of the function call, the value returned by the function ends up being leaked memory. The following example program and commands demonstrate the problem. program array_memory_leak implicit none type, abstract :: base end type base type, extends(base) :: extended end type extended type :: container class(base), allocatable :: thing end type type, extends(base) :: collection type(container), allocatable :: stuff(:) end type collection call run() contains subroutine run() type(collection) :: my_thing type(container) :: a_container a_container = newContainer(newExtended()) ! This is fine my_thing = newCollection([a_container]) my_thing = newCollection([newContainer(newExtended())]) ! This is a memory leak end subroutine run function newExtended() type(extended) :: newExtended end function newExtended function newContainer(thing) class(base), intent(in) :: thing type(container) :: newContainer allocate(newContainer%thing, source = thing) end function newContainer function newCollection(things) type(container), intent(in) :: things(:) type(collection) :: newCollection newCollection%stuff = things end function newCollection end program array_memory_leak $ gfortran -g array_memory_leak.f90 -o array_memory_leak $ valgrind --leak-check=full ./array_memory_leak ==7652== Memcheck, a memory error detector ==7652== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==7652== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==7652== Command: ./array_memory_leak ==7652== ==7652== ==7652== HEAP SUMMARY: ==7652== in use at exit: 1 bytes in 1 blocks ==7652== total heap usage: 29 allocs, 28 frees, 13,554 bytes allocated ==7652== ==7652== 1 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==7652==at 0x483777F: malloc (vg_replace_malloc.c:299) ==7652==by 0x109A0B: newcontainer.3817 (array_memory_leak.f90:38) ==7652==by 0x10A17C: run.3822 (array_memory_leak.f90:27) ==7652==by 0x1091E6: MAIN__ (array_memory_leak.f90:18) ==7652==by 0x10A96B: main (array_memory_leak.f90:18) ==7652== ==7652== LEAK SUMMARY: ==7652==definitely lost: 1 bytes in 1 blocks ==7652==indirectly lost: 0 bytes in 0 blocks ==7652== possibly lost: 0 bytes in 0 blocks ==7652==still reachable: 0 bytes in 0 blocks ==7652== suppressed: 0 bytes in 0 blocks ==7652== ==7652== For counts of detected and suppressed errors, rerun with: -v ==7652== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) I'm running the official version of gcc on Arch Linux. I'm also running a version of 9.0 from September at work, which exhibits the same behavior.
[Bug middle-end/90070] Add optimization for optimizing small integer values by fp integral constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070 Michael Meissner changed: What|Removed |Added Target||powerpc64le-gnu-linux, ||powerpc64-gnu-linux CC||dje at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Host||powerpc64le-gnu-linux, ||powerpc64-gnu-linux Build||powerpc64le-gnu-linux, ||powerpc64-gnu-linux --- Comment #1 from Michael Meissner --- Obviously this is can speed up various machines, but there might be machines where this is not optimal. Now, in the full benchmark, there are many other things going on, but in looking at the code, I figured this small optimization might help.
[Bug fortran/90069] New: Polymorphic Return Type Memory Leak Without Intermediate Variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90069 Bug ID: 90069 Summary: Polymorphic Return Type Memory Leak Without Intermediate Variable Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: brichardson at structint dot com Target Milestone: --- It appears that, if a function returns a polymorphic (i.e. class(thing)) variable, if the result is not assigned to a variable, then a memory leak occurs. The following short program and command output demonstrates the problem. program returned_memory_leak implicit none type, abstract :: base end type base type, extends(base) :: extended end type extended type :: container class(*), allocatable :: thing end type call run() contains subroutine run() type(container) :: a_container a_container = theRightWay() a_container = theWrongWay() end subroutine function theRightWay() type(container) :: theRightWay class(base), allocatable :: thing allocate(thing, source = newAbstract()) theRightWay = newContainer(thing) end function theRightWay function theWrongWay() type(container) :: theWrongWay theWrongWay = newContainer(newAbstract()) end function theWrongWay function newAbstract() class(base), allocatable :: newAbstract allocate(newAbstract, source = newExtended()) end function newAbstract function newExtended() type(extended) :: newExtended end function newExtended function newContainer(thing) class(*), intent(in) :: thing type(container) :: newContainer allocate(newContainer%thing, source = thing) end function newContainer end program returned_memory_leak $ gfortran -g returned_memory_leak.f90 -o returned_memory_leak $ valgrind --leak-check=full ./returned_memory_leak ==7972== Memcheck, a memory error detector ==7972== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==7972== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==7972== Command: ./returned_memory_leak ==7972== ==7972== ==7972== HEAP SUMMARY: ==7972== in use at exit: 3 bytes in 3 blocks ==7972== total heap usage: 27 allocs, 24 frees, 13,526 bytes allocated ==7972== ==7972== 1 bytes in 1 blocks are definitely lost in loss record 1 of 3 ==7972==at 0x483777F: malloc (vg_replace_malloc.c:299) ==7972==by 0x1093BD: newabstract.3812 (returned_memory_leak.f90:41) ==7972==by 0x109601: therightway.3816 (returned_memory_leak.f90:28) ==7972==by 0x1098BE: run.3818 (returned_memory_leak.f90:19) ==7972==by 0x1091D6: MAIN__ (returned_memory_leak.f90:14) ==7972==by 0x109AD4: main (returned_memory_leak.f90:14) ==7972== ==7972== 1 bytes in 1 blocks are definitely lost in loss record 2 of 3 ==7972==at 0x483777F: malloc (vg_replace_malloc.c:299) ==7972==by 0x1093BD: newabstract.3812 (returned_memory_leak.f90:41) ==7972==by 0x10945E: thewrongway.3814 (returned_memory_leak.f90:35) ==7972==by 0x109965: run.3818 (returned_memory_leak.f90:20) ==7972==by 0x1091D6: MAIN__ (returned_memory_leak.f90:14) ==7972==by 0x109AD4: main (returned_memory_leak.f90:14) ==7972== ==7972== 1 bytes in 1 blocks are definitely lost in loss record 3 of 3 ==7972==at 0x483777F: malloc (vg_replace_malloc.c:299) ==7972==by 0x1093BD: newabstract.3812 (returned_memory_leak.f90:41) ==7972==by 0x10946D: thewrongway.3814 (returned_memory_leak.f90:35) ==7972==by 0x109965: run.3818 (returned_memory_leak.f90:20) ==7972==by 0x1091D6: MAIN__ (returned_memory_leak.f90:14) ==7972==by 0x109AD4: main (returned_memory_leak.f90:14) ==7972== ==7972== LEAK SUMMARY: ==7972==definitely lost: 3 bytes in 3 blocks ==7972==indirectly lost: 0 bytes in 0 blocks ==7972== possibly lost: 0 bytes in 0 blocks ==7972==still reachable: 0 bytes in 0 blocks ==7972== suppressed: 0 bytes in 0 blocks ==7972== ==7972== For counts of detected and suppressed errors, rerun with: -v ==7972== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) Note, whatever leak is happening in theRightWay function appears to have been fixed in the version of 9.0 from September that we are using at work, so don't worry about that one for this bug report. I'm using the official version on Arch Linux in the above.
[Bug middle-end/90070] New: Add optimization for optimizing small integer values by fp integral constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070
Bug ID: 90070
Summary: Add optimization for optimizing small integer values
by fp integral constant
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
I was looking at the Spec 2017 imagick benchmark, and in particular at the hot
function in enhance.c.
The code has many places where it has:
typedef struct _PixelPacket
{
unsigned short blue;
unsigned short green;
unsigned short red;
unsigned short opacity;
} PixelPacket;
typedef struct _MagickPixelPacket
{
float red;
float green;
float blue;
float opacity;
float index;
} MagickPixelPacket;
/* ... */
foo () {
MagickPixelPacket aggregate;
/* ... */
aggregate.red+=(5.0)*((r)->red);
/* ... */
}
In particular this becomes:
double temp1 = (double)r->red;
double temp2 = (double)aggregate.red;
double temp3 = temp2 + (temp1 * 5.0);
aggregate.red = (float) temp3;
This is due to 5.0 being considered a double precision constant.
It occurs to me that on many machines, multiplying an int by 5 is cheaper than
multiplying a double by 5.0. In particular, since you are multiply an unsigned
short by 5.0, you know the value will fit in a 32-bit or 64-bit integer. This
would mean the example might be executed as:
long temp1 = (long)r->red;
long temp2 = 5 * temp1;
float temp3 = (float) temp2;
aggregate.red += temp3;
Perhaps for non-fast-math it would need to be optimized as in case there are
rounding issues:
long temp1 = (long)r->red;
long temp2 = 5 * temp1;
double temp3 = aggregate.red;
double temp4 = (float) temp2;
double temp5 = temp3 * temp4;
aggregate.red = (float) temp5;
[Bug c/90071] New: internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071
Bug ID: 90071
Summary: internal compiler error: SSA corruption
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gsocshubham at gmail dot com
CC: mliska at suse dot cz
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Created attachment 46154
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46154&action=edit
Preprocessed code of program causing ICE "crash1.c"
---COMPILER CONFIGURATION-
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --enable-lto
--disable-bootstrap : (reconfigured) ../gcc/configure --enable-languages=c,c++
--enable-lto --disable-bootstrap
Thread model: posix
gcc version 9.0.1 20190412 (experimental) (GCC)
-COMMAND LINE USED FOR COMPILATION-
~/pull-gcc-9-trunk/build/gcc/xgcc -B ~/pull-gcc-9-trunk/build/gcc/
-I../../runtime/ crash1.c -w -O1
Unable to coalesce ssa_names 571 and 568 which are marked as MUST COALESCE.
p_61_571(ab) and p_61_568(ab)
during RTL pass: expand
crash1.c: In function ‘func_59’:
crash1.c:1696:20: internal compiler error: SSA corruption
1696 | static struct S0 * func_59(uint16_t p_60, uint32_t p_61, uint16_t
p_62)
|^~~
0xdc07c1 fail_abnormal_edge_coalesce
../../gcc/gcc/tree-ssa-coalesce.c:1002
0xdc07c1 coalesce_partitions
../../gcc/gcc/tree-ssa-coalesce.c:1424
0xdc07c1 coalesce_ssa_name(_var_map*)
../../gcc/gcc/tree-ssa-coalesce.c:1755
0xd585ab remove_ssa_form
../../gcc/gcc/tree-outof-ssa.c:1029
0xd585ab rewrite_out_of_ssa(ssaexpand*)
../../gcc/gcc/tree-outof-ssa.c:1287
0x7f8700 execute
../../gcc/gcc/cfgexpand.c:6314
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
REDUCED CODE
a;
static b;
c() {
int d, e = &&f;
void *g = &&h;
h:
++e;
if (a)
i:
goto *g;
for (;;) {
e = 0;
if (b)
goto i;
}
f:
goto *({ d || e < 0 || e >= 2; });
&e;
}
[Bug fortran/90072] New: Polymorphic Dispatch to Polymophic Return Type Memory Leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90072 Bug ID: 90072 Summary: Polymorphic Dispatch to Polymophic Return Type Memory Leak Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: brichardson at structint dot com Target Milestone: --- It appears that trying to do polymorphic dispatch to a function that has a polymorphic return type leads to a memory leak. But, by using a select type construct, the memory leak doesn't occur. The following program and module demonstrate the problem. program dispatch_memory_leak implicit none call run() contains subroutine run() use types, only: base_returned, base_called, first_extended class(base_called), allocatable :: to_call class(base_returned), allocatable :: to_get allocate(to_call, source = first_extended()) allocate(to_get, source = to_call%get()) ! This is a memory leak deallocate(to_get) select type(to_call) type is (first_extended) allocate(to_get, source = to_call%get()) ! This got fixed end select end subroutine run end program dispatch_memory_leak module types implicit none type, abstract :: base_returned end type base_returned type, extends(base_returned) :: first_returned end type first_returned type, extends(base_returned) :: second_returned end type second_returned type, abstract :: base_called contains procedure(get_), deferred :: get end type base_called type, extends(base_called) :: first_extended contains procedure :: get => getFirst end type first_extended type, extends(base_called) :: second_extended contains procedure :: get => getSecond end type second_extended abstract interface function get_(self) result(returned) import base_called import base_returned class(base_called), intent(in) :: self class(base_returned), allocatable :: returned end function get_ end interface contains function getFirst(self) result(returned) class(first_extended), intent(in) :: self class(base_returned), allocatable :: returned allocate(returned, source = first_returned()) end function getFirst function getSecond(self) result(returned) class(second_extended), intent(in) :: self class(base_returned), allocatable :: returned allocate(returned, source = second_returned()) end function getSecond end module types $ gfortran -c -g types.f90 -o types.o $ gfortran -c -g dispatch_memory_leak.f90 -o dispatch_memory_leak.o $ gfortran -g types.o dispatch_memory_leak.o -o dispatch_memory_leak $ valgrind --leak-check=full ./dispatch_memory_leak ==8261== Memcheck, a memory error detector ==8261== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==8261== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==8261== Command: ./dispatch_memory_leak ==8261== ==8261== ==8261== HEAP SUMMARY: ==8261== in use at exit: 2 bytes in 2 blocks ==8261== total heap usage: 26 allocs, 24 frees, 13,525 bytes allocated ==8261== ==8261== 1 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==8261==at 0x483777F: malloc (vg_replace_malloc.c:299) ==8261==by 0x1092EE: __types_MOD_getfirst (types.f90:41) ==8261==by 0x109446: run.3770 (dispatch_memory_leak.f90:13) ==8261==by 0x10973D: MAIN__ (dispatch_memory_leak.f90:4) ==8261==by 0x109789: main (dispatch_memory_leak.f90:4) ==8261== ==8261== 1 bytes in 1 blocks are definitely lost in loss record 2 of 2 ==8261==at 0x483777F: malloc (vg_replace_malloc.c:299) ==8261==by 0x1092EE: __types_MOD_getfirst (types.f90:41) ==8261==by 0x10959A: run.3770 (dispatch_memory_leak.f90:18) ==8261==by 0x10973D: MAIN__ (dispatch_memory_leak.f90:4) ==8261==by 0x109789: main (dispatch_memory_leak.f90:4) ==8261== ==8261== LEAK SUMMARY: ==8261==definitely lost: 2 bytes in 2 blocks ==8261==indirectly lost: 0 bytes in 0 blocks ==8261== possibly lost: 0 bytes in 0 blocks ==8261==still reachable: 0 bytes in 0 blocks ==8261== suppressed: 0 bytes in 0 blocks ==8261== ==8261== For counts of detected and suppressed errors, rerun with: -v ==8261== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) Note that the leak that occurs inside the select type construct here appears to have been fixed in the version of 9.0 that we are running at work. (That version is from some time in September). I'm running the official version from Arch Linux.
[Bug target/90073] New: Very slow code for AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90073
Bug ID: 90073
Summary: Very slow code for AVX2
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rcc.dark at gmail dot com
Target Milestone: ---
Created attachment 46155
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46155&action=edit
Source code and assembly output
Hi all, the following code generates very poor assembly code for AVX2 targets
(GCC 8.2, 8.3 and trunk; compiler flags -O3 -mavx2).
---
#include
using data = long long __attribute__((vector_size(64)));
void f(data& a, const data& x1, const data& x2) {
a ^= x1 ^ x2;
}
---
GCC generates 128-loads and stores, which leads to STLF stalls. Possibly a
duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80689
ICC generates the expected code. I attach GCC and ICC outputs, but you can
check them here https://godbolt.org/z/bwtGUE
[Bug middle-end/89288] ICE in tree_code_size, at tree.c:865
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288 --- Comment #4 from Martin Sebor --- Author: msebor Date: Fri Apr 12 19:01:17 2019 New Revision: 270326 URL: https://gcc.gnu.org/viewcvs?rev=270326&root=gcc&view=rev Log: PR c/88383 - ICE calling __builtin_has_attribute on a reference PR c/89288 - ICE in tree_code_size, at tree.c:865 PR c/89798 - excessive vector_size silently accepted and truncated PR c/89797 - ICE on a vector_size (1LU << 33) int variable gcc/ChangeLog: PR c/89797 * targhooks.c (default_vector_alignment): Avoid assuming argument fits in SHWI. * tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in a shift expression. * doc/extend.texi (__builtin_has_attribute): Add a clarifying note. gcc/c-family/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-attribs.c (type_valid_for_vector_size): Detect excessively large sizes. (validate_attribute): Handle DECLs and expressions. (has_attribute): Handle types referenced by expressions. Avoid considering array attributes in ARRAY_REF expressions . gcc/cp/ChangeLog: PR c/88383 PR c/89288 * parser.c (cp_parser_has_attribute_expression): Handle assignment expressions. gcc/testsuite/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-c++-common/attributes-1.c: Adjust. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/builtin-has-attribute-7.c: New test. * c-c++-common/builtin-has-attribute-4.c: Adjust expectations. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/pr71574.c: Adjust. * gcc.dg/pr25559.c: Adjust. * gcc.dg/attr-vector_size.c: New test. Added: trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-6.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-7.c trunk/gcc/testsuite/gcc.dg/attr-vector_size.c Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/targhooks.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attributes-1.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c trunk/gcc/testsuite/c-c++-common/pr71574.c trunk/gcc/testsuite/gcc.dg/pr25559.c trunk/gcc/tree.h
[Bug c/88383] ICE calling _builtin_has_attribute with an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88383 --- Comment #3 from Martin Sebor --- Author: msebor Date: Fri Apr 12 19:01:17 2019 New Revision: 270326 URL: https://gcc.gnu.org/viewcvs?rev=270326&root=gcc&view=rev Log: PR c/88383 - ICE calling __builtin_has_attribute on a reference PR c/89288 - ICE in tree_code_size, at tree.c:865 PR c/89798 - excessive vector_size silently accepted and truncated PR c/89797 - ICE on a vector_size (1LU << 33) int variable gcc/ChangeLog: PR c/89797 * targhooks.c (default_vector_alignment): Avoid assuming argument fits in SHWI. * tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in a shift expression. * doc/extend.texi (__builtin_has_attribute): Add a clarifying note. gcc/c-family/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-attribs.c (type_valid_for_vector_size): Detect excessively large sizes. (validate_attribute): Handle DECLs and expressions. (has_attribute): Handle types referenced by expressions. Avoid considering array attributes in ARRAY_REF expressions . gcc/cp/ChangeLog: PR c/88383 PR c/89288 * parser.c (cp_parser_has_attribute_expression): Handle assignment expressions. gcc/testsuite/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-c++-common/attributes-1.c: Adjust. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/builtin-has-attribute-7.c: New test. * c-c++-common/builtin-has-attribute-4.c: Adjust expectations. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/pr71574.c: Adjust. * gcc.dg/pr25559.c: Adjust. * gcc.dg/attr-vector_size.c: New test. Added: trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-6.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-7.c trunk/gcc/testsuite/gcc.dg/attr-vector_size.c Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/targhooks.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attributes-1.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c trunk/gcc/testsuite/c-c++-common/pr71574.c trunk/gcc/testsuite/gcc.dg/pr25559.c trunk/gcc/tree.h
[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797 --- Comment #4 from Martin Sebor --- Author: msebor Date: Fri Apr 12 19:01:17 2019 New Revision: 270326 URL: https://gcc.gnu.org/viewcvs?rev=270326&root=gcc&view=rev Log: PR c/88383 - ICE calling __builtin_has_attribute on a reference PR c/89288 - ICE in tree_code_size, at tree.c:865 PR c/89798 - excessive vector_size silently accepted and truncated PR c/89797 - ICE on a vector_size (1LU << 33) int variable gcc/ChangeLog: PR c/89797 * targhooks.c (default_vector_alignment): Avoid assuming argument fits in SHWI. * tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in a shift expression. * doc/extend.texi (__builtin_has_attribute): Add a clarifying note. gcc/c-family/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-attribs.c (type_valid_for_vector_size): Detect excessively large sizes. (validate_attribute): Handle DECLs and expressions. (has_attribute): Handle types referenced by expressions. Avoid considering array attributes in ARRAY_REF expressions . gcc/cp/ChangeLog: PR c/88383 PR c/89288 * parser.c (cp_parser_has_attribute_expression): Handle assignment expressions. gcc/testsuite/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-c++-common/attributes-1.c: Adjust. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/builtin-has-attribute-7.c: New test. * c-c++-common/builtin-has-attribute-4.c: Adjust expectations. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/pr71574.c: Adjust. * gcc.dg/pr25559.c: Adjust. * gcc.dg/attr-vector_size.c: New test. Added: trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-6.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-7.c trunk/gcc/testsuite/gcc.dg/attr-vector_size.c Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/targhooks.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attributes-1.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c trunk/gcc/testsuite/c-c++-common/pr71574.c trunk/gcc/testsuite/gcc.dg/pr25559.c trunk/gcc/tree.h
[Bug c/89798] excessive vector_size silently accepted and truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798 --- Comment #5 from Martin Sebor --- Author: msebor Date: Fri Apr 12 19:01:17 2019 New Revision: 270326 URL: https://gcc.gnu.org/viewcvs?rev=270326&root=gcc&view=rev Log: PR c/88383 - ICE calling __builtin_has_attribute on a reference PR c/89288 - ICE in tree_code_size, at tree.c:865 PR c/89798 - excessive vector_size silently accepted and truncated PR c/89797 - ICE on a vector_size (1LU << 33) int variable gcc/ChangeLog: PR c/89797 * targhooks.c (default_vector_alignment): Avoid assuming argument fits in SHWI. * tree.h (TYPE_VECTOR_SUBPARTS): Avoid sign overflow in a shift expression. * doc/extend.texi (__builtin_has_attribute): Add a clarifying note. gcc/c-family/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-attribs.c (type_valid_for_vector_size): Detect excessively large sizes. (validate_attribute): Handle DECLs and expressions. (has_attribute): Handle types referenced by expressions. Avoid considering array attributes in ARRAY_REF expressions . gcc/cp/ChangeLog: PR c/88383 PR c/89288 * parser.c (cp_parser_has_attribute_expression): Handle assignment expressions. gcc/testsuite/ChangeLog: PR c/88383 PR c/89288 PR c/89798 PR c/89797 * c-c++-common/attributes-1.c: Adjust. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/builtin-has-attribute-7.c: New test. * c-c++-common/builtin-has-attribute-4.c: Adjust expectations. * c-c++-common/builtin-has-attribute-6.c: New test. * c-c++-common/pr71574.c: Adjust. * gcc.dg/pr25559.c: Adjust. * gcc.dg/attr-vector_size.c: New test. Added: trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-6.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-7.c trunk/gcc/testsuite/gcc.dg/attr-vector_size.c Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/targhooks.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attributes-1.c trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-4.c trunk/gcc/testsuite/c-c++-common/pr71574.c trunk/gcc/testsuite/gcc.dg/pr25559.c trunk/gcc/tree.h
[Bug middle-end/89288] ICE in tree_code_size, at tree.c:865
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89288 Bug 89288 depends on bug 88383, which changed state. Bug 88383 Summary: ICE calling _builtin_has_attribute with an expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88383 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/89798] excessive vector_size silently accepted and truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED Target Milestone|--- |9.0 Known to fail||8.3.0 --- Comment #6 from Martin Sebor --- Fixed in r270326.
[Bug c/88383] ICE calling _builtin_has_attribute with an expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88383 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Martin Sebor --- Fixed in r270326.
[Bug target/90073] Very slow code for AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90073
--- Comment #1 from H.J. Lu ---
The problem is with the default -mtune=generic.
[hjl@gnu-cfl-1 gcc]$ cat /tmp/foo.cc
#include
using data = long long __attribute__((vector_size(64)));
void f(data& a, const data& x1, const data& x2) {
a ^= x1 ^ x2;
}
[hjl@gnu-cfl-1 gcc]$ ./xgcc -B./ -O3 -mtune=skylake -mavx2 /tmp/foo.cc -S
[hjl@gnu-cfl-1 gcc]$ cat foo.s
.file "foo.cc"
.text
.p2align 4
.globl _Z1fRDv8_xRKS_S2_
.type _Z1fRDv8_xRKS_S2_, @function
_Z1fRDv8_xRKS_S2_:
.LFB5519:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-64, %rsp
subq$200, %rsp
vmovdqa (%rsi), %ymm2
vmovdqa 32(%rsi), %ymm0
vpxor (%rdx), %ymm2, %ymm1
vpxor 32(%rdx), %ymm0, %ymm0
vpxor (%rdi), %ymm1, %ymm1
vpxor 32(%rdi), %ymm0, %ymm0
vmovaps %ymm1, (%rdi)
vmovaps %ymm0, 32(%rdi)
vzeroupper
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE5519:
.size _Z1fRDv8_xRKS_S2_, .-_Z1fRDv8_xRKS_S2_
.ident "GCC: (GNU) 9.0.1 20190412 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 gcc]$
[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #5 from Martin Sebor --- Fixed in r270326.
[Bug target/90073] Very slow code for AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90073
--- Comment #2 from Rodrigo ---
(In reply to H.J. Lu from comment #1)
> The problem is with the default -mtune=generic.
>
> [hjl@gnu-cfl-1 gcc]$ cat /tmp/foo.cc
> #include
>
> using data = long long __attribute__((vector_size(64)));
> void f(data& a, const data& x1, const data& x2) {
> a ^= x1 ^ x2;
> }
> [hjl@gnu-cfl-1 gcc]$ ./xgcc -B./ -O3 -mtune=skylake -mavx2 /tmp/foo.cc -S
>
> [hjl@gnu-cfl-1 gcc]$ cat foo.s
> .file "foo.cc"
> .text
> .p2align 4
> .globl _Z1fRDv8_xRKS_S2_
> .type _Z1fRDv8_xRKS_S2_, @function
> _Z1fRDv8_xRKS_S2_:
> .LFB5519:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq%rsp, %rbp
> .cfi_def_cfa_register 6
> andq$-64, %rsp
> subq$200, %rsp
> vmovdqa (%rsi), %ymm2
> vmovdqa 32(%rsi), %ymm0
> vpxor (%rdx), %ymm2, %ymm1
> vpxor 32(%rdx), %ymm0, %ymm0
> vpxor (%rdi), %ymm1, %ymm1
> vpxor 32(%rdi), %ymm0, %ymm0
> vmovaps %ymm1, (%rdi)
> vmovaps %ymm0, 32(%rdi)
> vzeroupper
> leave
> .cfi_def_cfa 7, 8
> ret
> .cfi_endproc
> .LFE5519:
> .size _Z1fRDv8_xRKS_S2_, .-_Z1fRDv8_xRKS_S2_
> .ident "GCC: (GNU) 9.0.1 20190412 (experimental)"
> .section.note.GNU-stack,"",@progbits
> [hjl@gnu-cfl-1 gcc]$
Hi! Using -mtune=skylake or -mtune=haswell doesn't fix the problem in my
installation (GCC 8.2, MingW64) or in GodBolt (8.2, 8.3 and trunk). Do you know
why could it be?
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226 H.J. Lu changed: What|Removed |Added CC||rcc.dark at gmail dot com --- Comment #7 from H.J. Lu --- *** Bug 90073 has been marked as a duplicate of this bug. ***
[Bug target/90073] Very slow code for AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90073 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from H.J. Lu --- Fixed on https://gitlab.com/x86-gcc/wip/tree/usr/hjl/pr89226/master which will be submitted for GCC 10. *** This bug has been marked as a duplicate of bug 89226 ***
[Bug target/90073] Very slow code for AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90073 --- Comment #4 from Rodrigo --- (In reply to H.J. Lu from comment #3) > Fixed on > > https://gitlab.com/x86-gcc/wip/tree/usr/hjl/pr89226/master > > which will be submitted for GCC 10. > > *** This bug has been marked as a duplicate of bug 89226 *** Thank you very much.
