[Bug inline-asm/64119] asm triggers local register variable data corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64119
Adam Warner adam at consulting dot net.nz changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #3 from Adam Warner adam at consulting dot net.nz ---
Seriously Andrew? Here's an opportunity to reconsider your closing of the bug
report.
//asm triggers local register variable data corruption
#include stdio.h
__attribute__((noinline)) void fn(int inputa, int inputb, int inputc) {
register int a asm (rax);
register int b asm (rbx);
register int c asm (rcx);
a = inputa; b = inputb; c = inputc;
printf(The values of a, b and c are %d, %d and %d respectively\n, a, b, c);
a = inputa; b = inputb; c = inputc;
printf(The values of a, b and c are %d, %d and %d respectively\n, a, b, c);
a = inputa; b = inputb; c = inputc;
asm volatile (mov %0, %0; mov %1, %1; mov %2, %2 : +r (a), +r (b), +r
(c));
printf(The values of a, b and c are %d, %d and %d respectively\n, a, b, c);
a = inputa; b = inputb; c = inputc;
printf(The values of a, b and c are %d, %d and %d respectively\n, a, b, c);
}
int main(void) {
fn(1, 2, 3);
return 0;
}
$ clang-3.6 -O3 gcc-asm-reg-var-data-corruption_b.c ./a.out
The values of a, b and c are 1, 2 and 3 respectively
The values of a, b and c are 1, 2 and 3 respectively
The values of a, b and c are 1, 2 and 3 respectively
The values of a, b and c are 1, 2 and 3 respectively
$ gcc-4.9 -O3 gcc-asm-reg-var-data-corruption_b.c ./a.out
The values of a, b and c are 1, 2 and 3 respectively
The values of a, b and c are 1, 2 and 3 respectively
The values of a, b and c are 53, 2 and 39 respectively
The values of a, b and c are 1, 2 and 3 respectively
Do you claim that one may not assign values to explicit register variables?
(which clearly appears to be happening when a, b and c are again set to a =
inputa; b = inputb; c = inputc; as evidenced by the output of the fourth printf
statement)
GCC is ignoring the variable assignments in the presence of a harmless asm
statement.
At this stage I cannot accept your justification for the compiler output. What
is your computational model?
Let's look at the relevant portions of clang's compiler output:
400537: 41 89 d6mov%edx,%r14d
40053a: 41 89 f7mov%esi,%r15d
40053d: 89 fd mov%edi,%ebp
... the input variables are saved in ebp, r14d and r15d.
400562: e8 99 fe ff ff callq 400400 printf@plt
400567: 89 e8 mov%ebp,%eax
400569: 44 89 fbmov%r15d,%ebx
40056c: 44 89 f1mov%r14d,%ecx
... eax, ebx and ecx are set to the input values as per the variable
assignments
(this is a requirement of the asm input constraints)
40056f: 48 89 c0mov%rax,%rax
400572: 48 89 dbmov%rbx,%rbx
400575: 48 89 c9mov%rcx,%rcx
... the harmless inline asm is output
400578: 48 89 c2mov%rax,%rdx
40057b: bf 54 06 40 00 mov$0x400654,%edi
400580: 31 c0 xor%eax,%eax
400582: 89 d6 mov%edx,%esi
400584: 89 da mov%ebx,%edx
400586: e8 75 fe ff ff callq 400400 printf@plt
... and the register variables moved into the ABI registers for the printf.
Let's look at gcc's compiler output around the asm statement:
400534: 41 89 d5mov%edx,%r13d
400537: 55 push %rbp
400538: 53 push %rbx
400539: 41 89 fcmov%edi,%r12d
40053c: 89 f5 mov%esi,%ebp
... the input variables are saved in ebp, r12d and r13d.
400565: e8 76 fe ff ff callq 4003e0 printf@plt
... The code a = inputa; b = inputb; c = inputc; has been completely thrown
away.
eax, ebx and ecx have not been set with the correct values to satisfy the
input
constraints of the inline asm:
40056a: 89 c0 mov%eax,%eax
40056c: 89 db mov%ebx,%ebx
40056e: 89 c9 mov%ecx,%ecx
... eax, ebx and ecx have not been primed with the correct values so copying
incorrect values achieves nothing.
400570: bf 28 06 40 00 mov$0x400628,%edi
400575: 89 da mov%ebx,%edx
400577: 89 c6 mov%eax,%esi
400579: 31 c0 xor%eax,%eax
40057b: e8 60 fe ff ff callq 4003e0 printf@plt
... thus garbage is printed.
I've only used features supported by both gcc and clang. clang's output is
[Bug fortran/64120] New: [F03] Wrong handling of allocatable character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120 Bug ID: 64120 Summary: [F03] Wrong handling of allocatable character string Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org The following code shows allocatable character does not work as it should: call g(1) contains subroutine g(x) integer :: x character(len=x), allocatable :: s allocate(s) write(*,*) x, len(s) end subroutine end It should output 1 1 but outputs 1 0. The tree dump shows that the argument x is never used in the string allocation. A longer testcase, including SAVE (which seems also mishandled, but it is probably linked to this issue): program test logical :: L L = g(1) write(*,*) L L = g(2) write(*,*) L contains logical function g(x) integer :: x character(len=x), allocatable :: s save if(.NOT.allocated(s)) then allocate(s) g = .FALSE. else g = .TRUE. end if write(*,*) len(s) end function g end
[Bug fortran/64120] [F03] Wrong handling of allocatable character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-30 Ever confirmed|0 |1
[Bug tree-optimization/64121] New: [5 Regression] ICE: SSA corruption with -O -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64121 Bug ID: 64121 Summary: [5 Regression] ICE: SSA corruption with -O -fsanitize=undefined Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 34145 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34145action=edit reduced testcase Compiler output: $ gcc -O -fsanitize=undefined testcase.c Unable to coalesce ssa_names 1 and 6 which are marked as MUST COALESCE. xp_1(ab) and xp_6(ab) testcase.c: In function 'execute': testcase.c:4:1: internal compiler error: SSA corruption execute (int *ip, int x) ^ 0xd2c828 fail_abnormal_edge_coalesce /mnt/svn/gcc-trunk/gcc/tree-ssa-coalesce.c:921 0xd2c828 coalesce_partitions /mnt/svn/gcc-trunk/gcc/tree-ssa-coalesce.c:1219 0xd2c828 coalesce_ssa_name() /mnt/svn/gcc-trunk/gcc/tree-ssa-coalesce.c:1364 0xcc27cf remove_ssa_form /mnt/svn/gcc-trunk/gcc/tree-outof-ssa.c:999 0xcc27cf rewrite_out_of_ssa(ssaexpand*) /mnt/svn/gcc-trunk/gcc/tree-outof-ssa.c:1233 0x7d3c37 execute /mnt/svn/gcc-trunk/gcc/cfgexpand.c:5703 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r218181 - ICE 4_9 r218177 - OK
[Bug tree-optimization/64121] [5 Regression] ICE: SSA corruption with -O -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64121 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-30 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed, -O -fsanitize=object-size is enough.
[Bug middle-end/64122] New: ICE: tree check: expected tree that contains 'decl common' structure, have 'ssa_name' in prepare_gimple_addressable, at gimplify.c:3228 with -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64122 Bug ID: 64122 Summary: ICE: tree check: expected tree that contains 'decl common' structure, have 'ssa_name' in prepare_gimple_addressable, at gimplify.c:3228 with -fgnu-tm Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 34146 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34146action=edit reduced testcase Compiler output: $ gcc -O2 -fgnu-tm -ftree-vectorize -mavx512cd testcase.c In function 'foo': cc1: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'ssa_name' in prepare_gimple_addressable, at gimplify.c:3228 0xe87ca4 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/tree.c:9398 0x9e24f1 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/tree.h:2878 0x9e24f1 prepare_gimple_addressable /mnt/svn/gcc-trunk/gcc/gimplify.c:3228 0x9e64fa gimplify_addr_expr /mnt/svn/gcc-trunk/gcc/gimplify.c:4939 0x9db1d1 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) /mnt/svn/gcc-trunk/gcc/gimplify.c:7780 0x9f0195 force_gimple_operand_1(tree_node*, gimple_statement_base**, bool (*)(tree_node*), tree_node*) /mnt/svn/gcc-trunk/gcc/gimplify-me.c:93 0x9f02cf force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*, bool (*)(tree_node*), tree_node*, bool, gsi_iterator_update) /mnt/svn/gcc-trunk/gcc/gimplify-me.c:130 0xc31346 expand_assign_tm /mnt/svn/gcc-trunk/gcc/trans-mem.c:2350 0xc32609 expand_block_tm /mnt/svn/gcc-trunk/gcc/trans-mem.c:2536 0xc32609 execute_tm_mark /mnt/svn/gcc-trunk/gcc/trans-mem.c:3037 0xc32609 execute /mnt/svn/gcc-trunk/gcc/trans-mem.c:3082 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-218181-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-218181-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 5.0.0 20141129 (experimental) (GCC) Tested revisions: r218181 - ICE 4_9 r218177 - different ICE 4_8 r218176 - -mavx512cd is not recognised
[Bug fortran/63469] Automatic reallocation of allocatable scalar length even when substring implicitly specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63469 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-30 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at r218188. Compiling the test with -fno-realloc-lhs gives Length of string with substring = 32 Length of string with substring = 32 Length of string without substring = 32 With revision 4.5.4 I get the error CHARACTER(:), ALLOCATABLE :: s 1 Error: Syntax error in CHARACTER declaration at (1)
[Bug fortran/63932] posible problem with allocatable character(:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63932 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-30 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at r218188. Compiling the test with 4.8.2 gives character(:), allocatable :: c 1 Error: Deferred-length character component 'c' at (1) is not yet supported
[Bug fortran/64120] [F03] Wrong handling of allocatable character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Already present in 4.5.4. With 4.4.7 I get character(len=x), allocatable :: s 1 Error: Scalar object 's' at (1) may not be ALLOCATABLE
[Bug fortran/63867] LEN is lost for a CHARACTER variable inside SELECT TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63867 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-30 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Present from 4.8.2 up to trunk (5.0 r218188). Compiling the test in comment 0 with 4.7.3 gives class(*), intent(in) :: s 1 Fatal Error: Unlimited polymorphism at (1) not yet supported Also, I should add that changing type is(character(len=*)) to type is(character(len=:)) given an internal compiler error (anyway, the code then is invalid) I don't get an ICE, but the error pr63867_db.f90:12.23: subroutine checklen1(s) 1 Error: Entity 's' at (1) has a deferred type parameter and requires either the pointer or allocatable attribute pr63867_db.f90:1.9: program p 1 Error: TODO: Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities
[Bug gcov-profile/64123] New: [5 Regression] Instrumented Firefox segfaults on start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123
Bug ID: 64123
Summary: [5 Regression] Instrumented Firefox segfaults on start
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Building Firefox with PGO results in a segfault in the instrumented
browser:
markus@x4 bin % gdb ./firefox
Reading symbols from ./firefox...done.
(gdb) set follow-fork-mode parent
(gdb) run
Starting program: /var/tmp/moz-build-dir/dist/bin/firefox
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/libthread_db.so.1.
Loading JavaScript value pretty-printers; see js/src/gdb/README.
If they cause trouble, type: disable pretty-printer .* SpiderMonkey
[New Thread 0x7fffe7caa700 (LWP 17887)]
[Thread 0x7fffe7caa700 (LWP 17887) exited]
Program received signal SIGSEGV, Segmentation fault.
0x77429fdd in fread () from /lib/libc.so.6
(gdb) bt
#0 0x77429fdd in fread () from /lib/libc.so.6
#1 0x77feff59 in gcov_read_words (words=words@entry=2) at
../../../gcc/libgcc/../gcc/gcov-io.c:518
#2 0x77ff055e in __gcov_read_counter () at
../../../gcc/libgcc/../gcc/gcov-io.c:555
#3 0x77fefc8d in gcov_get_counter () at
../../../gcc/libgcc/libgcov.h:316
#4 __gcov_merge_add (counters=0x77ff4a10
__gcov0._Z30mozalloc_set_oom_abort_handlerPFvmE, n_counters=optimized out)
at ../../../gcc/libgcc/libgcov-merge.c:56
#5 0x71f2a736 in merge_one_data (crc32=3590671895,
eof_pos_p=synthetic pointer, summary_pos_p=synthetic pointer,
this_prg=0x7fff8620, prg_p=0x7fff9df0,
gi_ptr=0x77ff4540, filename=0x48fb70
/var/tmp/moz-build-dir/memory/mozalloc/Unified_cpp_memory_mozalloc0.gcda) at
../../../gcc/libgcc/libgcov-driver.c:472
#6 dump_one_gcov (all_prg=synthetic pointer, this_prg=0x7fff8620,
crc32=3590671895, run_counted=0, gf=synthetic pointer, gi_ptr=0x77ff4540)
at ../../../gcc/libgcc/libgcov-driver.c:787
#7 gcov_do_dump (list=optimized out, run_counted=0) at
../../../gcc/libgcc/libgcov-driver.c:846
#8 0x71f2aab2 in __gcov_dump_one (root=root@entry=0x77ff5a80
__gcov_root) at ../../../gcc/libgcc/libgcov-driver.c:858
#9 0x71f2acd8 in __gcov_dump_int () at
../../../gcc/libgcc/libgcov-interface.c:164
#10 0x71f2ab7f in __gcov_flush () at
../../../gcc/libgcc/libgcov-interface.c:88
#11 0x71f28bc6 in __gcov_fork () at
../../../gcc/libgcc/libgcov-interface.c:179
#12 0x70fc4698 in fire_glxtest_process() () from
/var/tmp/moz-build-dir/dist/bin/libxul.so
#13 0x70fb7ab2 in XREMain::XRE_mainInit(bool*) () from
/var/tmp/moz-build-dir/dist/bin/libxul.so
#14 0x70fbdda3 in XREMain::XRE_main(int, char**, nsXREAppData const*)
() from /var/tmp/moz-build-dir/dist/bin/libxul.so
#15 0x70fbe47b in XRE_main () from
/var/tmp/moz-build-dir/dist/bin/libxul.so
#16 0x00404e59 in do_main(int, char**, nsIFile*) [clone .constprop.0]
()
#17 0x00403b2f in main ()
(gdb) up
#1 0x77feff59 in gcov_read_words (words=words@entry=2) at
../../../gcc/libgcc/../gcc/gcov-io.c:518
518 excess = fread (gcov_var.buffer + gcov_var.length,
(gdb) l
513 #else
514 if (gcov_var.length + words gcov_var.alloc)
515 gcov_allocate (gcov_var.length + words);
516 excess = gcov_var.alloc - gcov_var.length;
517 #endif
518 excess = fread (gcov_var.buffer + gcov_var.length,
519 1, excess 2, gcov_var.file) 2;
520 gcov_var.length += excess;
521 if (gcov_var.length words)
522 {
[Bug fortran/63667] ICE with DEFERRED procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63667 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-30 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed on 4.9 and trunk (5.0 r217946). On my working tree the ICE is gone, i.e., there is a fix in bugzilla for this PR and it is likely a duplicate (AFAICT Mikael Morin's patch for pr44978).
[Bug fortran/64124] New: [F95] Valid constant expr rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64124 Bug ID: 64124 Summary: [F95] Valid constant expr rejected Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org $ cat a.f90 character(len=kind(1)) x integer(len(x)) y end $ gfortran a.f90 -std=f95 a.f90:2.14: integer(len(x)) y 1 Error: Parameter 'x' at (1) has not been declared or is a variable, which does not reduce to a constant expression
[Bug fortran/64124] [F95] Valid constant expr rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64124 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-30 Blocks||32834 Ever confirmed|0 |1
[Bug bootstrap/64116] ice with -O3 -fgraphite-identity on bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64116 hete2 at gmx dot de changed: What|Removed |Added Known to fail||4.9.0, 4.9.1 --- Comment #1 from hete2 at gmx dot de --- gcc 4.8.3 doesn't exhibit this error. But bootstrapping fails with: /home/hete/gcc/gcc-4.8.3/Build2/./prev-gcc/xg++ -B/home/hete/gcc/gcc-4.8.3/Build2/./prev-gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/hete/gcc/gcc-4.8.3/Build2/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/hete/gcc/gcc-4.8.3/Build2/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/hete/gcc/gcc-4.8.3/Build2/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/hete/gcc/gcc-4.8.3/Build2/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/hete/gcc/gcc-4.8.3/libstdc++-v3/libsupc++ -L/home/hete/gcc/gcc-4.8.3/Build2/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/hete/gcc/gcc-4.8.3/Build2/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -O3 -fgraphite-identity -pipe -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace -DCLOOG_INT_GMP../../gcc/cfg.c -o cfg.o [CLooG] ERROR: index out of range make[3]: *** [cfg.o] Fehler 1 make[3]: *** Warte auf noch nicht beendete Prozesse... rm gfortran.pod gcc.pod make[3]: Verlasse Verzeichnis '/home/hete/gcc/gcc-4.8.3/Build2/gcc' make[2]: *** [all-stage3-gcc] Fehler 2 make[2]: Verlasse Verzeichnis '/home/hete/gcc/gcc-4.8.3/Build2' make[1]: *** [stage3-bubble] Fehler 2 make[1]: Verlasse Verzeichnis '/home/hete/gcc/gcc-4.8.3/Build2' make: *** [bootstrap] Fehler 2
[Bug bootstrap/61763] [4.9 Regression] bootstrap with -O3 gives comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61763
--- Comment #9 from Douglas Mencken dougmencken at gmail dot com ---
How do you actually compile with -O3?
../../flags_O2_to_O3.sh
sed -i '/ CFLAGS_FOR_TARGET=/{n;N;N;N;N;N;N;N;d}' ./configure.ac
sed -i '/ CXXFLAGS_FOR_TARGET=/{n;N;N;N;N;N;N;N;d}' ./configure.ac
sed -i 's/-c -g conftest/-c conftest/' ./configure.ac
sed -i 's/stage1_cflags=-g/stage1_cflags=/' ./configure.ac
Where flags_O2_to_O3.sh script is
http://ftp.osuosl.org/pub/manulix/scripts/service-scripts/flags_O2_to_O3.sh
[Bug fortran/64124] [F95] Valid constant expr rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64124 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- I see the error from 4.4.7 up to trunk (5.0 r218188). The error goes away if I replace character(len=kind(1)) x with character(len=kind(1)), parameter :: x='abcd' and gfortran compiles the following code character(len=kind(1)) x integer y(len(x),len(x)) print *, shape(y) end
[Bug c++/54483] undefined reference to static constexpr in .so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54483 Juisoo usack at math dot fu-berlin.de changed: What|Removed |Added CC||usack at math dot fu-berlin.de --- Comment #6 from Juisoo usack at math dot fu-berlin.de --- Created attachment 34147 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34147action=edit Files for testcase of initial post
[Bug c++/54483] undefined reference to static constexpr in .so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54483 --- Comment #7 from Juisoo usack at math dot fu-berlin.de --- Created attachment 34148 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34148action=edit second test case
[Bug c++/54483] undefined reference to static constexpr in .so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54483 --- Comment #8 from Juisoo usack at math dot fu-berlin.de --- The described case seems to work in GCC 4.9.2 with the attached files and g++ -c -fpic testicle.cc -std=c++11 g++ -shared -o libtesticle.so testicle.o g++ -L/home/usack/entwicklung/tetris -Wall -o testicles main.cc -ltesticle -std=c++11 However, if I add another data member which is initialized with val by default, I still get the undefined reference error, see second attachment.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #85 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Created attachment 34135 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34135action=edit patch to add -mlra option I'd like to apply the patch to add a transitional option -mlra like ARM and the revised patches in c#78 and c#83 on sh-lra branch after merge from trunk. It helps me a lot when building, comparing and testing sh-lra compilers. --- Comment #86 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #85) Created attachment 34135 [details] patch to add -mlra option I'd like to apply the patch to add a transitional option -mlra like ARM and the revised patches in c#78 and c#83 on sh-lra branch after merge from trunk. It helps me a lot when building, comparing and testing sh-lra compilers. Sure, makes sense to me. It's probably better to revert my commit r215244 to reinstate reload on the sh-lra branch.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #87 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Oleg Endo from comment #86) (In reply to Kazumoto Kojima from comment #85) Created attachment 34135 [details] patch to add -mlra option I'd like to apply the patch to add a transitional option -mlra like ARM and the revised patches in c#78 and c#83 on sh-lra branch after merge from trunk. It helps me a lot when building, comparing and testing sh-lra compilers. Sure, makes sense to me. It's probably better to revert my commit r215244 to reinstate reload on the sh-lra branch. Sorry, your patch in attachment 34135 does that already of course. We could also try to merge the sh-lra branch into trunk for the gcc 5 release. If all the LRA changes are conditional and the code paths are not changed if -mlra is not specified, it should be OK to do it. Some of the changes could probably also be applied unconditionally, such as r215241 and r215243.
[Bug tree-optimization/64111] [5.0 regression] ICE: conversion of register to a different size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64111 --- Comment #15 from Thiago Macieira thiago at kde dot org --- Created attachment 34149 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34149action=edit Reduced testcase to minimum This is the same testcase, now reduced to the minimum possible by creduce.
[Bug fortran/64120] [F03] Wrong handling of allocatable character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) Already present in 4.5.4. With 4.4.7 I get character(len=x), allocatable :: s 1 Error: Scalar object 's' at (1) may not be ALLOCATABLE Of course you'll get errors with 4.5.4 and 4.4.7. Support for deferred parameter type was added in 4.6. -- steve
[Bug fortran/64120] [F03] Wrong handling of allocatable character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Of course you'll get errors with 4.5.4 and 4.4.7. Support for deferred parameter type was added in 4.6. If I am not mistaken, the problem with this PR is allocatable scalars and not deferred parameter type. The tests compile without error with 4.5.4.
[Bug tree-optimization/64111] [5.0 regression] ICE: conversion of register to a different size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64111
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #16 from H.J. Lu hjl.tools at gmail dot com ---
The small testcase failed with GCC 4.8:
Testing /export/project/git/gcc-regression/master/190324/usr/bin/gcc:
rm -f *.o *.out
g++ -march=core-avx2 -O3 -fvisibility=hidden -x c++-header -c qt_pch.ii -o
pch.out
g++ -c -include .pch/Qt5Core -march=core-avx2 -O3 -fvisibility=hidden -o
file.o file.ii
file.ii: In member function \u2018int A::m_fn1()\u2019:
file.ii:10:5: error: conversion of register to a different size
int A::m_fn1() {
^
VIEW_CONVERT_EXPRvector(4) long long int(vect_var_.23_79);
vect_.27_83 = VIEW_CONVERT_EXPRvector(4) long long int(vect_var_.23_79);
file.ii:10:5: error: conversion of register to a different size
VIEW_CONVERT_EXPRvector(4) long long int(vect_var_.24_81);
vect_.28_85 = VIEW_CONVERT_EXPRvector(4) long long int(vect_var_.24_81);
file.ii:10:5: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [file.o] Error 1
Search ended: Fails from the first revision 190324.
Can not make sure it is a regression from that version.
[hjl@gnu-mic-2 gcc-regression]$
/export/project/git/gcc-regression/master/190324/usr/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/export/project/git/gcc-regression/master/190324/usr/bin/gcc
COLLECT_LTO_WRAPPER=/export/project/git/gcc-regression/master/190324/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../../../gcc/configure
--prefix=/export/project/git/gcc-regression/master/190324/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
MAKEINFO=/usr/bin/false --enable-languages=c,c++,fortran --disable-bootstrap
Thread model: posix
gcc version 4.8.0 20120812 (experimental) [trunk revision 190324] (GCC)
[hjl@gnu-mic-2 gcc-regression]$
[Bug fortran/64125] New: Allocation of character strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64125 Bug ID: 64125 Summary: Allocation of character strings Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fmartinez at gmv dot com Hi. The following code inside a module causes the compiler to crash (also in the latest version of 4.9) allocate( character(len=size(right))::left%chars ) ^ internal compiler error: in gimplify_expr, at gimplify.c:8646 0x572c28 ??? ../sysdeps/x86_64/elf/start.S:113 Cheers, Fran type t_string private character(len=:), allocatable :: chars end type t_string pure subroutine string_assign_from_array( left, right ) ! The target string type(t_string), intent(out) :: left ! The source string character, dimension(:), intent(in) :: right ! Copy memory allocate( character(len=size(right)) :: left%chars ) left%chars = transfer( right, left%chars ) end subroutine string_assign_from_array
[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63230 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||fmartinez at gmv dot com --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 64125 has been marked as a duplicate of this bug. ***
[Bug fortran/64125] Allocation of character strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64125 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Next time please provide a full test. With module test type t_string private character(len=:), allocatable :: chars end type t_string contains pure subroutine string_assign_from_array( left, right ) ! The target string type(t_string), intent(out) :: left ! The source string character, dimension(:), intent(in) :: right ! Copy memory allocate( character(len=size(right)) :: left%chars ) left%chars = transfer( right, left%chars ) end subroutine string_assign_from_array end module test I get the same ICEs (depending on --enable-checking=release in the configure command used to bootstrap) than with pr63230. Thus marking this PR as a duplicate. Note that I am sure that pr63230 is also a duplicate. *** This bug has been marked as a duplicate of bug 63230 ***
[Bug tree-optimization/64126] New: [5.0 Regression] FAIL: gcc.dg/pr37289.c scan-tree-dump original -\\(long unsigned int\\) x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64126
Bug ID: 64126
Summary: [5.0 Regression] FAIL: gcc.dg/pr37289.c scan-tree-dump
original -\\(long unsigned int\\) x
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: danglin at gcc dot gnu.org
Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
Build: hppa-unknown-linux-gnu
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdir/gcc/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr37289.c -fno-diagnostics-s
how-caret -fdiagnostics-color=never -fdump-tree-original -S -o pr37289.s
(timeout = 300)spawn /home/dave/gnu/gcc/objdir/gcc/xgcc
-B/home/dave/gnu/gcc/objdir/gcc/ /home/
dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr37289.c -fno-diagnostics-show-caret
-fdi
agnostics-color=never -fdump-tree-original -S -o pr37289.s
PASS: gcc.dg/pr37289.c (test for excess errors)FAIL: gcc.dg/pr37289.c
scan-tree-dump original -\\(long unsigned int\\) x
dave@mx3210:~/gnu/gcc/objdir/gcc/testsuite/gcc$ cat pr37289.c.003t.original
;; Function g (null)
;; enabled by -tree-original
{
f ((long unsigned int) -x);
}
[Bug tree-optimization/64126] [5.0 Regression] FAIL: gcc.dg/pr37289.c scan-tree-dump original -\\(long unsigned int\\) x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64126 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target|hppa-unknown-linux-gnu | Host|hppa-unknown-linux-gnu | Target Milestone|--- |5.0 Build|hppa-unknown-linux-gnu | --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- Fails everywhere.
[Bug c++/64127] New: [5.0 regression] ICE on invalid: tree check: expected identifier_node, have template_id_expr in cp_parser_diagnose_invalid_type_name, at cp/parser.c:2980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64127 Bug ID: 64127 Summary: [5.0 regression] ICE on invalid: tree check: expected identifier_node, have template_id_expr in cp_parser_diagnose_invalid_type_name, at cp/parser.c:2980 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dimhen at gmail dot com r214134 PASS r214718 FAIL r218182 FAIL $ cat x.ii template 0 int __copy_streambufs_eof; __copy_streambufs_eof $ ~/bin/gcc_214718/bin/g++ -fpreprocessed -c x.ii x.ii:1:11: error: expected identifier before numeric constant template 0 int __copy_streambufs_eof; ^ x.ii:1:11: error: expected '' before numeric constant x.ii:1:18: warning: variable templates only available with -std=c++14 or -std=gnu++14 template 0 int __copy_streambufs_eof; ^ x.ii:2:1: error: parse error in template argument list __copy_streambufs_eof ^ x.ii:2:1: error: '__copy_streambufs_eofexpression error ' does not name a type x.ii:2:1: internal compiler error: tree check: expected identifier_node, have template_id_expr in cp_parser_diagnose_invalid_type_name, at cp/parser.c:2932 0xea6824 tree_check_failed(tree_node const*, char const*, int, char const*, ...) /home/dimhen/src/gcc_current/gcc/tree.c:9149 0x6789a0 tree_check(tree_node*, char const*, int, char const*, tree_code) /home/dimhen/src/gcc_current/gcc/tree.h:2729 0x6789a0 cp_parser_diagnose_invalid_type_name /home/dimhen/src/gcc_current/gcc/cp/parser.c:2932 0x699cbf cp_parser_parse_and_diagnose_invalid_type_name /home/dimhen/src/gcc_current/gcc/cp/parser.c:3059 0x6a10e7 cp_parser_simple_declaration /home/dimhen/src/gcc_current/gcc/cp/parser.c:11359 0x684a93 cp_parser_block_declaration /home/dimhen/src/gcc_current/gcc/cp/parser.c:11287 0x6ab465 cp_parser_declaration /home/dimhen/src/gcc_current/gcc/cp/parser.c:11184 0x6aa118 cp_parser_declaration_seq_opt /home/dimhen/src/gcc_current/gcc/cp/parser.c:11070 0x6ab9b3 cp_parser_translation_unit /home/dimhen/src/gcc_current/gcc/cp/parser.c:4053 0x6ab9b3 c_parse_file() /home/dimhen/src/gcc_current/gcc/cp/parser.c:31935 0x7d6552 c_common_parse_file() /home/dimhen/src/gcc_current/gcc/c-family/c-opts.c:1122 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. $ ~/bin/gcc_214718/bin/g++ -v Using built-in specs. COLLECT_GCC=/home/dimhen/bin/gcc_214718/bin/g++ COLLECT_LTO_WRAPPER=/home/dimhen/bin/gcc_214718/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/dimhen/src/gcc_current/configure --prefix=/usr/local/gcc_current/ --enable-checking=yes,df,rtl,tree,fold --enable-languages=c,c++,lto --enable-plugin=yes --enable-static Thread model: posix gcc version 5.0.0 20140829 (experimental) [trunk revision 214718] (GCC)
[Bug tree-optimization/64126] [5.0 Regression] FAIL: gcc.dg/pr37289.c scan-tree-dump original -\\(long unsigned int\\) x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64126 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-30 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Caused by r218141 (see https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03510.html). The original dump contains now '(long unsigned int) -x'.
[Bug libstdc++/64128] New: Let vector take advantage of malloc_usable_size for malloc-using allocators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128 Bug ID: 64128 Summary: Let vector take advantage of malloc_usable_size for malloc-using allocators Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at contacts dot eelis.net Created attachment 34150 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34150action=edit testcase Changing this-_M_impl._M_end_of_storage = __new_start + __len; to this-_M_impl._M_end_of_storage = __new_start + malloc_usable_size(__new_start) / sizeof(value_type); in vector.tcc makes the runtime of the attached program drop from 0.35 seconds to 0.24 seconds on my machine, a 31% reduction. This shows there is low hanging fruit for a very common operation (vector::push_back). A proper implementation would of course only do this for allocators that are known to be malloc frontends. :)
[Bug inline-asm/64119] asm triggers local register variable data corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64119
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Adam Warner from comment #3)
Seriously Andrew? Here's an opportunity to reconsider your closing of the
bug report.
Did you read the documentation I pointed out? Because it is obvious you did
not.
//asm triggers local register variable data corruption
#include stdio.h
__attribute__((noinline)) void fn(int inputa, int inputb, int inputc) {
register int a asm (rax);
register int b asm (rbx);
register int c asm (rcx);
a = inputa; b = inputb; c = inputc;
printf(The values of a, b and c are %d, %d and %d respectively\n, a, b,
c);
a = inputa; b = inputb; c = inputc;
printf(The values of a, b and c are %d, %d and %d respectively\n, a, b,
c);
a = inputa; b = inputb; c = inputc;
asm volatile (mov %0, %0; mov %1, %1; mov %2, %2 : +r (a), +r (b),
+r (c));
printf(The values of a, b and c are %d, %d and %d respectively\n, a, b,
c);
a = inputa; b = inputb; c = inputc;
printf(The values of a, b and c are %d, %d and %d respectively\n, a, b,
c);
}
int main(void) {
fn(1, 2, 3);
return 0;
}
$ clang-3.6 -O3 gcc-asm-reg-var-data-corruption_b.c ./a.out
The values of a, b and c are 1, 2 and 3 respectively
The values of a, b and c are 1, 2 and 3 respectively
The values of a, b and c are 1, 2 and 3 respectively
The values of a, b and c are 1, 2 and 3 respectively
$ gcc-4.9 -O3 gcc-asm-reg-var-data-corruption_b.c ./a.out
The values of a, b and c are 1, 2 and 3 respectively
The values of a, b and c are 1, 2 and 3 respectively
The values of a, b and c are 53, 2 and 39 respectively
The values of a, b and c are 1, 2 and 3 respectively
What GCC is optimizing it to:
#include stdio.h
__attribute__((noinline)) void fn(int inputa, int inputb, int inputc) {
register int a asm (rax);
register int b asm (rbx);
register int c asm (rcx);
a = inputa; b = inputb; c = inputc;
printf(The values of a, b and c are %d, %d and %d respectively\n, a, b, c);
printf(The values of a, b and c are %d, %d and %d respectively\n, inputa,
inputb, inputc);
asm volatile (mov %0, %0; mov %1, %1; mov %2, %2 : +r (a), +r (b), +r
(c));
printf(The values of a, b and c are %d, %d and %d respectively\n, a, b, c);
printf(The values of a, b and c are %d, %d and %d respectively\n, inputa,
inputb, inputc);
}
Aka it is treating the local register variables as normal variables except for
inline-asm.
Do you claim that one may not assign values to explicit register variables?
(which clearly appears to be happening when a, b and c are again set to a =
inputa; b = inputb; c = inputc; as evidenced by the output of the fourth
printf statement)
No you can assign them, except they got optimized like normal variables in most
cases that means the assignments might be optimized away if there is already an
assignment.
GCC is ignoring the variable assignments in the presence of a harmless asm
statement.
No it is not see above on how GCC optimizes it and read the documentation again
about what is going on.
At this stage I cannot accept your justification for the compiler output.
What is your computational model?
It is standard C one.
...
clang output which is not useful this for discussion because this is about the
documentation of GCC and use in GCC
I've only used features supported by both gcc and clang. clang's output is
sensible and fits my mental model of the C virtual machine. gcc's output is
really surprising and I've had a lot of experience manipulating gcc via
inline asm. Are you sure gcc's output is justified?
Yes re-read the documentation. I explicitly put it here for you to understand
what GCC is doing.
I will again copy and paste the most important part of the documentation for
you to understand what is going on here:
References to local register variables may be deleted or moved or simplified.
--- CUT ---
They are being moved and simplified to only assigned before the first printf.
If you don't like that then create a new local register variable each time and
GCC won't optimize them away.
[Bug c++/64129] New: [5.0 regression] ICE on invalid: in grokfndecl, at cp/decl.c:7658
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64129
Bug ID: 64129
Summary: [5.0 regression] ICE on invalid: in grokfndecl, at
cp/decl.c:7658
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
r218182 FAIL
r214718 FAIL (different stack)
r214134 PASS
$ cat x.ii
template 0 int __copy_streambufs_eof;
class {
friend __copy_streambufs_eof (
$ /usr/local/gcc_current/bin/g++ -fpreprocessed -fsyntax-only x.ii
x.ii:1:11: error: expected identifier before numeric constant
template 0 int __copy_streambufs_eof;
^
x.ii:1:11: error: expected '' before numeric constant
x.ii:1:18: warning: variable templates only available with -std=c++14 or
-std=gnu++14
template 0 int __copy_streambufs_eof;
^
x.ii:3:35: error: wrong number of template arguments (0, should be 1)
friend __copy_streambufs_eof (
^
x.ii:1:18: note: provided for 'templateint anonymous int
__copy_streambufs_eofanonymous '
template 0 int __copy_streambufs_eof;
^
x.ii:3:37: error: expected identifier at end of input
friend __copy_streambufs_eof (
^
x.ii:3:37: error: expected ',' or '...' at end of input
x.ii:3:37: error: expected ')' at end of input
x.ii:3:37: error: ISO C++ forbids declaration of '__copy_streambufs_eof' with
no type [-fpermissive]
x.ii:3:37: internal compiler error: in grokfndecl, at cp/decl.c:7658
0x5eb4c5 grokfndecl
/home/dimhen/src/gcc_current/gcc/cp/decl.c:7658
0x5e01c9 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/home/dimhen/src/gcc_current/gcc/cp/decl.c:10716
0x68d006 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
/home/dimhen/src/gcc_current/gcc/cp/decl2.c:875
0x6cfd2d cp_parser_member_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:20992
0x6abb05 cp_parser_member_specification_opt
/home/dimhen/src/gcc_current/gcc/cp/parser.c:20544
0x6abb05 cp_parser_class_specifier_1
/home/dimhen/src/gcc_current/gcc/cp/parser.c:19736
0x6abb05 cp_parser_class_specifier
/home/dimhen/src/gcc_current/gcc/cp/parser.c:19972
0x6abb05 cp_parser_type_specifier
/home/dimhen/src/gcc_current/gcc/cp/parser.c:14632
0x6ae33f cp_parser_decl_specifier_seq
/home/dimhen/src/gcc_current/gcc/cp/parser.c:11867
0x6ce139 cp_parser_simple_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:11457
0x6ce693 cp_parser_block_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:11406
0x6af939 cp_parser_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:11303
0x6dbe7a cp_parser_declaration_seq_opt
/home/dimhen/src/gcc_current/gcc/cp/parser.c:11189
0x6dc1b7 cp_parser_translation_unit
/home/dimhen/src/gcc_current/gcc/cp/parser.c:4101
0x6dc1b7 c_parse_file()
/home/dimhen/src/gcc_current/gcc/cp/parser.c:32199
0x8124a2 c_common_parse_file()
/home/dimhen/src/gcc_current/gcc/c-family/c-opts.c:1039
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$ /usr/local/gcc_current/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc_current/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current/ --enable-checking=yes,df,rtl
--enable-languages=c,c++,lto --enable-plugin=yes --enable-static
Thread model: posix
gcc version 5.0.0 20141129 (experimental) [trunk revision 218182] (GCC)
$ ~/bin/gcc_214718/bin/g++ -fpreprocessed -fsyntax-only x.ii
x.ii:1:11: error: expected identifier before numeric constant
template 0 int __copy_streambufs_eof;
^
x.ii:1:11: error: expected '' before numeric constant
x.ii:1:18: warning: variable templates only available with -std=c++14 or
-std=gnu++14
template 0 int __copy_streambufs_eof;
^
x.ii:3:35: internal compiler error: Segmentation fault
friend __copy_streambufs_eof (
^
0xc6025f crash_signal
/home/dimhen/src/gcc_current/gcc/toplev.c:339
0x5d1dee uses_template_parms(tree_node*)
/home/dimhen/src/gcc_current/gcc/cp/pt.c:8239
0x5d3a93 lookup_template_variable(tree_node*, tree_node*)
/home/dimhen/src/gcc_current/gcc/cp/pt.c:7978
0x697c0a cp_parser_template_id
/home/dimhen/src/gcc_current/gcc/cp/parser.c:13636
0x697d95 cp_parser_class_name
/home/dimhen/src/gcc_current/gcc/cp/parser.c:19386
0x68bfd9 cp_parser_qualifying_entity
/home/dimhen/src/gcc_current/gcc/cp/parser.c:5564
0x68bfd9
[Bug tree-optimization/64130] New: vrp: handle non zero constant divided by range cannot be zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
Bug ID: 64130
Summary: vrp: handle non zero constant divided by range cannot
be zero.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
The following two functions should always be optimized to return 0
because x 0, x / a cannot be 0. But VRP misses this case for unknown
reasons, even though it has some code for it in ranges_from_anti_range()
int fsigned(int a)
{
return 100 / a == 0;
}
int funsigned(unsigned a)
{
return 100 / a == 0;
}
gcc50 -fno-non-call-exceptions -O2 -S tvrpdiv.c
gcc version 5.0.0 2014 (experimental) (GCC)
movl$100, %eax
cltd
idivl %edi
testl %eax, %eax
sete%al
movzbl %al, %eax
ret
xorl%edx, %edx
movl$100, %eax
divl%edi
testl %eax, %eax
sete%al
movzbl %al, %eax
[Bug ipa/64068] [5 Regression] ICE: in remove_unreachable_nodes, at ipa.c:546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64068
--- Comment #2 from Dmitry G. Dyachenko dimhen at gmail dot com ---
another testcase
$ /usr/local/gcc_current/bin/g++ -fpreprocessed -c -O2 x.ii
x.ii:46:19: internal compiler error: in remove_unreachable_nodes, at ipa.c:546
void fn4() { B(); }
^
0xb14713 symbol_table::remove_unreachable_nodes(bool, _IO_FILE*)
/home/dimhen/src/gcc_current/gcc/ipa.c:546
0x189e60c ipa_inline
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2193
0x189e60c execute
/home/dimhen/src/gcc_current/gcc/ipa-inline.c:2558
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$ cat x.ii
typedef int PROV_ENUMALGS_EX, PCCRYPT_OID_INFO;
class A {
int m_fn2();
virtual bool m_fn1(PCCRYPT_OID_INFO);
};
int fn1();
void fn2();
int A::m_fn2() { m_fn1(0); }
bool fn3() {
for (;;) {
if (fn1()) {
if (fn1() != 259)
fn2();
break;
}
return 1;
}
return 0;
}
class B {
public:
B() { fn3(); }
};
class C : A {
bool m_fn1(PCCRYPT_OID_INFO) { m_fn3(); }
int isSupportedByProvider_algId;
PROV_ENUMALGS_EX isSupportedByProvider_outEnumAlgs;
PROV_ENUMALGS_EX isSupportedByProvider_enumAlgs;
bool m_fn3() {
while (1) {
if (fn1()) {
if (fn1() != 259)
fn2();
break;
}
if (isSupportedByProvider_algId)
isSupportedByProvider_outEnumAlgs = isSupportedByProvider_enumAlgs;
return 1;
}
return 0;
}
};
void fn4() { B(); }
[Bug tree-optimization/64130] vrp: handle non zero constant divided by range cannot be zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- Uh? 100/1000==0, I don't understand your point.
[Bug tree-optimization/64130] vrp: handle non zero constant divided by range cannot be zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- So this should be optimized to a 100 instead.
[Bug tree-optimization/64130] vrp: handle non zero constant divided by range cannot be zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org ---
You're right. I actually meant
x = maxval(typeof(a)), x / a cannot be 0.
Corrected test case (assuming 64bit target):
#include limits.h
int fsigned(int a)
{
return 0x1fffL / a == 0;
}
int funsigned(unsigned a)
{
return 0x1fffL / a == 0;
}
So this should be optimized to a 100 instead.
Yes this would make sense too.
[Bug middle-end/60467] ICE with -fcilkplus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60467 ak at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ak at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from ak at gcc dot gnu.org --- Definitely fixed.
[Bug inline-asm/64119] asm triggers local register variable data corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64119 Adam Warner adam at consulting dot net.nz changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #5 from Adam Warner adam at consulting dot net.nz --- The documentation is not clear. But your explanation is fantastic. Thank you Andrew. It's a big step to fully comprehend that reassignment to a local register variable in GCC *does not work* to again make the register live for dataflow analysis. The approach GCC has chosen is one of maximum surprise. Thank you for describing a workaround: create a new local register variable each time and GCC won't optimize them away.
[Bug sanitizer/64131] [5 Regression] libsanitizer fails to build for AARCH64 with the glibc from the trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64131 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||build Target Milestone|--- |5.0 Summary|libsanitizer fails to build |[5 Regression] libsanitizer |for AARCH64 with the glibc |fails to build for AARCH64 |from the trunk |with the glibc from the ||trunk
[Bug sanitizer/64131] New: libsanitizer fails to build for AARCH64 with the glibc from the trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64131 Bug ID: 64131 Summary: libsanitizer fails to build for AARCH64 with the glibc from the trunk Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target: aarch64-linux-gnu libsanitizer is broken for AARCH64 with the trunk version of glibc. In file included from /data1/src/gcc-cavium/toolchain-thunder/scripts/../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:176:0: /data1/src/gcc-cavium/toolchain-thunder/scripts/../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:272:72: error: size of array ‘assertion_failed__1058’ is negative typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1] ^ /data1/src/gcc-cavium/toolchain-thunder/scripts/../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:266:30: note: in expansion of macro ‘IMPL_COMPILER_ASSERT’ #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__) ^ /data1/src/gcc-cavium/toolchain-thunder/scripts/../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1288:3: note: in expansion of macro ‘COMPILER_CHECK’ COMPILER_CHECK(sizeof(((__sanitizer_##CLASS *) NULL)-MEMBER) == \ ^ /data1/src/gcc-cavium/toolchain-thunder/scripts/../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1058:1: note: in expansion of macro ‘CHECK_SIZE_AND_OFFSET’ CHECK_SIZE_AND_OFFSET(ipc_perm, mode); ^ make[5]: *** [sanitizer_platform_limits_posix.lo] Error 1
[Bug sanitizer/64131] [5 Regression] libsanitizer fails to build for AARCH64 with the glibc from the trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64131 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I suspect the following glibc change introduced the bug into sanitizer: commit 5c40c3bab2fddaca8cfe12d75944d1fef8adf1a4 Author: Alan Hayward alan.hayw...@arm.com Date: Tue Nov 11 16:32:34 2014 + [AArch64] Add ipc.h. Adding ipc.h for AArch64 adjusted to behave correctly on big endian targets.
[Bug libstdc++/64128] Let vector take advantage of malloc_usable_size for malloc-using allocators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128 --- Comment #1 from Eelis gcc-bugzilla at contacts dot eelis.net --- Hmm, std::allocator::allocate calls ::operator new, which may be user-defined, so maybe there is no practical way to detect whether it is really using malloc. :(
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #88 from Kazumoto Kojima kkojima at gcc dot gnu.org --- For the record, here is the sh-lra revisions. 218191: Merge from trunk revision 218173. 218192: Add legitimize_address_displacement target macto. 218193: Split QI/HImode displacement addressing load/store via R0. Use std::swap in the sh-lra change. 218194: Add -mlra option. BTW, there are new ICEs with internal compiler error: in split_reg, at lra-constraints.c:4909 It looks that DCmode move causes them on sh-lra.
[Bug libstdc++/64132] New: [5.0 Regression] FAIL: 22_locale/numpunct/members/char/3.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64132 Bug ID: 64132 Summary: [5.0 Regression] FAIL: 22_locale/numpunct/members/char/3.cc execution test Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu spawn /home/dave/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/home/dave/gnu/gcc/o bjdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/ src -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs -L/home/da ve/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/dave/opt/g nu/gcc/gcc-5.0/hppa-linux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-5.0/hppa-linux-g nu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-5.0/hppa-linux-gnu/include -isystem /home/dave/opt/gnu/gcc/gcc-5.0/hppa-linux-gnu/sys-include -B/home/dave/gnu/gcc/o bjdir/hppa-linux-gnu/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length =0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR=. -nos tdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-lin ux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include -I/home/d ave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/inc lude/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util /home/dave/gn u/gcc/gcc/libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc -include b its/stdc++.h ./libtestc++.a -Wl,--gc-sections -lm -o ./3.exe PASS: 22_locale/numpunct/members/char/3.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/obj dir/hppa-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/objdir/hpp a-linux-gnu/./libstdc++-v3/src/.libs::/home/dave/gnu/gcc/objdir/gcc:/home/dave/g nu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/ objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-li nux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/. libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc spawn [open ...] 3.exe: /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/22_locale/numpunct/members/char/3.cc:39: void test02(): Assertion `g == ' failed. FAIL: 22_locale/numpunct/members/char/3.cc execution test extra_tool_flags are: -include bits/stdc++.h r210049 was ok.
[Bug other/64133] New: m68k-rtems-gcc generates invalid code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64133 Bug ID: 64133 Summary: m68k-rtems-gcc generates invalid code. Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: chris at contemporary dot net.au Created attachment 34151 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34151action=edit Preprocessed source The preprocessed output attached generates invalid code for the -O2 optimisation level and RTEMS fails to boot. The generated code is: clr.l 0.w trap #7 The full .s file can be seen in the attachments of RTEMS ticket https://devel.rtems.org/ticket/2204. Moving the second nested block of code that copies the vector table out of the file results in correct code. Also selecting -O seems to work.
[Bug other/64133] m68k-rtems-gcc generates invalid code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64133 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- You need -fno-delete-null-pointer-checks since you are accessing NULL pointers through out the code.
[Bug other/64133] m68k-rtems-gcc generates invalid code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64133 --- Comment #2 from Chris Johns chris at contemporary dot net.au --- Thanks for the quick response. The clean trap instruction did confuse me. I suppose my work around to move the code into another file stops gcc detecting the access. Is this true ? I am happy to build our code with the check enabled because accessing 0 is something we trap for with MMU targets such as ARM and PowerPC.
[Bug other/64133] m68k-rtems-gcc generates invalid code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64133 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Chris Johns from comment #2) Thanks for the quick response. The clean trap instruction did confuse me. I suppose my work around to move the code into another file stops gcc detecting the access. Is this true ? I am happy to build our code with the check enabled because accessing 0 is something we trap for with MMU targets such as ARM and PowerPC. It looks like it is just the startup code in the Init5235 function which needs this extra option, you can use the #pragma's too. Code like: *((short *)(0x)) = 0; Will produce the trap.
[Bug tree-optimization/16107] missed optimization with some math function builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16107 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- I have a patch using match-and-simplify.
[Bug tree-optimization/55180] Missed optimization abs(-x) - abs(x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55180 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Reopening since this is not a dup of that bug.
[Bug tree-optimization/55180] Missed optimization abs(-x) - abs(x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55180 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- But it was fixed in GCC 5.0.
[Bug tree-optimization/32685] Missed changing of sin into sinf (likewise for cos to cosf)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32685 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- This testcase has been fixed so closing as such.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 32685, which changed state. Bug 32685 Summary: Missed changing of sin into sinf (likewise for cos to cosf) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32685 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 32684, which changed state. Bug 32684 Summary: Missed tail call with sin/cos and sincos pass https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32684 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/32684] Missed tail call with sin/cos and sincos pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32684 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org --- Fixed. Pre gets rid of the REALPART_EXPR/COMPLEX_EXPR now.
[Bug tree-optimization/13876] loop not fully optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13876 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Known to fail|| --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org --- These all are optimized now so closing as fixed.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 13876, which changed state. Bug 13876 Summary: loop not fully optimized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13876 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug target/64134] New: (vector float){0, 0, b, a} Uses stores when it does need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64134
Bug ID: 64134
Summary: (vector float){0, 0, b, a} Uses stores when it does
need to
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target: aarch64
Take the following code:
#define vector __attribute__((vector_size(16)))
float a; float b;
vector float fb(void) { return (vector float){ 0,0,b,a};}
--- CUT ---
This produces:
fb:
adrpx1, b
adrpx0, a
ldrw1, [x1, #:lo12:b]
fmovs0, wzr
ldrw0, [x0, #:lo12:a]
subsp, sp, #16
stps0, s0, [sp]
strw1, [sp, 8]
strw0, [sp, 12]
ldrq0, [sp]
addsp, sp, 16
ret
This is really horrible and should be done as:
fb:
adrpx0, a
adrpx1, b
moviv0.4s, 0
ldrs1, [x0, #:lo12:a]
ldrs2, [x1, #:lo12:b]
insv0.s[3], v1.s[0]
insv0.s[2], v2.s[0]
ret
[Bug target/64134] (vector float){0, 0, b, a} Uses stores when it does need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64134
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
#define vector __attribute__((vector_size(16)))
float a; float b; float c; float d;
vector float fb(void) { return (vector float){ d,c,b,a};}
Is just as bad. We need to ins more in the aarch64 back-end.
[Bug tree-optimization/19049] not vectorizing a fortran loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19049 --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org --- We now get (at least on aarch64): t.f90:11:0: note: === vect_pattern_recog === t.f90:11:0: note: === vect_analyze_data_ref_accesses === t.f90:11:0: note: Detected single element interleaving *a_23(D)[_22] step 8 t.f90:11:0: note: Data access with gaps requires scalar epilogue loop t.f90:11:0: note: not consecutive access *a_23(D)[_25] = _28; t.f90:11:0: note: not vectorized: complicated access pattern. t.f90:11:0: note: bad data access.
[Bug tree-optimization/63738] [4.9/5 Regression] ssa corruption when compiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63738 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #9 from Oleg Endo olegendo at gcc dot gnu.org --- Richard, the testcase gcc.dg/torture/pr63738.c is causing an excess error here: warning: implicit declaration of function '_setjmp' [-Wimplicit-function-declaration]
[Bug target/63986] [5 Regression][SH] gcc.target/sh/pr51244-15.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63986 --- Comment #12 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Mon Dec 1 06:50:06 2014 New Revision: 218200 URL: https://gcc.gnu.org/viewcvs?rev=218200root=gccview=rev Log: gcc/ PR target/63986 PR target/51244 * config/sh/sh.c (sh_unspec_insn_p, sh_insn_operands_modified_between_p): New functions. (sh_split_movrt_negc_to_movt_xor): Do not delete insn if its operands are modified or if it has side effects, may trap or is volatile. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #80 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Mon Dec 1 06:50:06 2014 New Revision: 218200 URL: https://gcc.gnu.org/viewcvs?rev=218200root=gccview=rev Log: gcc/ PR target/63986 PR target/51244 * config/sh/sh.c (sh_unspec_insn_p, sh_insn_operands_modified_between_p): New functions. (sh_split_movrt_negc_to_movt_xor): Do not delete insn if its operands are modified or if it has side effects, may trap or is volatile. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c
