[Bug sanitizer/63316] New: [5.0 Regression] False asan positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63316 Bug ID: 63316 Summary: [5.0 Regression] False asan positive Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch 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 In the one day between r215373 and r215412 asan detects an heap-buffer-overflow for the testcase below. This only happens when compiled >O0. valgrind reports nothing. > cat bug.f90 MODULE M1 IMPLICIT NONE TYPE T1 LOGICAL :: a,b,c INTEGER, POINTER :: common_pos END TYPE T1 END MODULE M1 MODULE M2 USE M1 IMPLICIT NONE INTEGER, PRIVATE, POINTER, SAVE :: foo CONTAINS SUBROUTINE S1(iterator) TYPE(T1), INTENT(OUT) :: iterator NULLIFY(iterator%common_pos) IF (iterator%a) THEN ALLOCATE(iterator%common_pos) foo => iterator%common_pos foo = 0 END IF END SUBROUTINE S1 END MODULE M2 USE M1 USE M2 TYPE(T1), POINTER :: iterator ALLOCATE(iterator) iterator%a=.TRUE. CALL S1(iterator) END > gfortran -fsanitize=address -fno-omit-frame-pointer -g -O1 -march=native > -ffree-form bug.f90 && ./a.out = ==66541==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020ef90 at pc 0x400b1a bp 0x7fffcd4a56f0 sp 0x7fffcd4a56e8 WRITE of size 4 at 0x6020ef90 thread T0 #0 0x400b19 in __m2_MOD_s1 /data/vjoost/gnu/bugs/bug.f90:19 #1 0x400b8c in MAIN__ /data/vjoost/gnu/bugs/bug.f90:29 #2 0x400b8c in main /data/vjoost/gnu/bugs/bug.f90:24 #3 0x3094e1ed5c in __libc_start_main (/lib64/libc.so.6+0x3094e1ed5c) #4 0x400978 (/data/vjoost/gnu/bugs/a.out+0x400978) 0x6020ef90 is located 0 bytes inside of 4-byte region [0x6020ef90,0x6020ef94) allocated by thread T0 here: #0 0x7f252ce9f309 in __interceptor_malloc ../../../../gcc/libsanitizer/asan/asan_malloc_linux.cc:73 #1 0x400ac5 in __m2_MOD_s1 /data/vjoost/gnu/bugs/bug.f90:17 #2 0x400b8c in MAIN__ /data/vjoost/gnu/bugs/bug.f90:29 #3 0x400b8c in main /data/vjoost/gnu/bugs/bug.f90:24 #4 0x3094e1ed5c in __libc_start_main (/lib64/libc.so.6+0x3094e1ed5c) SUMMARY: AddressSanitizer: heap-buffer-overflow /data/vjoost/gnu/bugs/bug.f90:19 __m2_MOD_s1 Shadow bytes around the buggy address: 0x0c047fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c047fff9df0: fa fa[04]fa fa fa 07 fa fa fa 07 fa fa fa 06 fa 0x0c047fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c047fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc ASan internal: fe ==66541==ABORTING vjo...@nanosim-s01.ethz.ch:/data/vjoost/gnu/bugs>
[Bug sanitizer/63316] [5.0 Regression] False asan positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63316 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch, m.zakirov at samsung dot com --- Comment #1 from Joost VandeVondele --- possibly r215380 ?
[Bug c++/63317] New: Internal compiler error in unify, cp/pt.c: 15820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63317 Bug ID: 63317 Summary: Internal compiler error in unify, cp/pt.c: 15820 Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: netheril96 at gmail dot com Created attachment 33521 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33521&action=edit The preprocessed output as well as command line I used and the g++'s version information The command line is Script started on Sat 20 Sep 2014 03:47:23 PM CST rsy@rsy-ubuntu-server:~/autojsoncxx$ CXX=g++-4.6 make test make test -C test/ make[1]: Entering directory `/home/rsy/autojsoncxx/test' g++-4.6 -std=c++0x -O2 -Wall -Wextra -pedantic -g -I../include -I../rapidjson/include -I../catch/single_include -c test.cpp -o test.o In file included from ../include/autojsoncxx/error.hpp:27:0, from ../include/autojsoncxx/base.hpp:27, from ../include/autojsoncxx/autojsoncxx.hpp:27, from userdef.hpp:25, from test.cpp:35: ../rapidjson/include/rapidjson/error/error.h:88:37: warning: comma at end of enumerator list [-pedantic] In file included from ../rapidjson/include/rapidjson/writer.h:27:0, from ../include/autojsoncxx/to_json.hpp:30, from ../include/autojsoncxx/autojsoncxx.hpp:33, from userdef.hpp:25, from test.cpp:35: ../rapidjson/include/rapidjson/internal/dtoa.h: In member function ‘rapidjson::internal::DiyFp rapidjson::internal::DiyFp::operator*(const rapidjson::internal::DiyFp&) const’: ../rapidjson/include/rapidjson/internal/dtoa.h:80:27: warning: ISO C++ does not support ‘__int128’ for ‘p’ [-pedantic] ../rapidjson/include/rapidjson/internal/dtoa.h:80:52: warning: ISO C++ does not support ‘__int128’ for ‘type name’ [-pedantic] ../rapidjson/include/rapidjson/internal/dtoa.h:80:88: warning: ISO C++ does not support ‘__int128’ for ‘type name’ [-pedantic] In file included from ../include/autojsoncxx/autojsoncxx.hpp:33:0, from userdef.hpp:25, from test.cpp:35: ../include/autojsoncxx/to_json.hpp: In function ‘void autojsoncxx::write_json(Writer&, const ValueType&) [with Writer = rapidjson::Writer > >, ValueType = std::vector]’: ../include/autojsoncxx/to_json.hpp:48:5: instantiated from ‘void autojsoncxx::to_json(OutputStream&, const ValueType&) [with OutputStream = rapidjson::GenericStringBuffer >, ValueType = std::vector]’ ../include/autojsoncxx/to_json.hpp:57:5: instantiated from ‘void autojsoncxx::to_json_string(std::string&, const ValueType&, std::size_t) [with ValueType = std::vector, std::string = std::basic_string, std::size_t = long unsigned int]’ test.cpp:341:33: instantiated from here ../include/autojsoncxx/to_json.hpp:41:5: internal compiler error: in unify, at cp/pt.c:15820 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Preprocessed source stored into /tmp/ccBvcXI4.out file, please attach this to your bugreport. make[1]: *** [test.o] Error 1 make[1]: Leaving directory `/home/rsy/autojsoncxx/test' make: *** [test] Error 2 rsy@rsy-ubuntu-server:~/autojsoncxx$ Script done on Sat 20 Sep 2014 03:47:40 PM CST g++'s full version information: g++-4.6 (Ubuntu/Linaro 4.6.4-6ubuntu2) 4.6.4 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Using built-in specs. COLLECT_GCC=g++-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.4-6ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-gnu-unique-object --disable-libmudflap --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.4 (Ubuntu/Linaro 4.6.4-6ubuntu2) The preprocessed output is attached. It compiles fine on g++-4
[Bug c++/63317] Internal compiler error in unify, cp/pt.c: 15820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63317 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- Fixed in 4.8 as mentioned in the bug report already. 4.6 is no longer maintained. Most likely a dup of bug 53122.
[Bug sanitizer/63316] [5.0 Regression] False asan positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63316 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-20 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > possibly r215380 ? It is.
[Bug c/63318] New: Hello World C program using inline assembly to invoke write(2) on amd64 Linux fails to print Hello World
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63318 Bug ID: 63318 Summary: Hello World C program using inline assembly to invoke write(2) on amd64 Linux fails to print Hello World Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ryao at gentoo dot org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu Created attachment 33522 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33522&action=edit A hello world program from stack overflow I tried building a Hello World program from stack overflow that used asm volatile to invoke write(2): https://stackoverflow.com/questions/9506353/how-to-invoke-a-system-call-via-sysenter-in-inline-assembly-x86-amd64-linux/9508738#9508738 Unfortunately, it fails to print Hello World when compiled with GCC, but prints Hello World fine when compiled with Clang. This is because GCC fails to emit a string, while Clang does not. Here is the assembly output of GCC: $ gcc -S -o - syscall.c .file "syscall.c" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp .cfi_def_cfa_register 6 subq$48, %rsp movq%fs:40, %rax movq%rax, -8(%rbp) xorl%eax, %eax movabsq $8022916924116329800, %rax movq%rax, -32(%rbp) movl$560229490, -24(%rbp) movw$10, -20(%rbp) movq$14, -48(%rbp) leaq-32(%rbp), %rax #APP # 8 "syscall.c" 1 movl $1, %eax movl $1, %edi movq %rax, %rsi movl -48(%rbp), %edx syscall # 0 "" 2 #NO_APP movq%rax, -40(%rbp) movl$0, %eax movq-8(%rbp), %rdx xorq%fs:40, %rdx je .L3 call__stack_chk_fail .L3: leave .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (Gentoo 4.8.3 p1.1, pie-0.5.9) 4.8.3" .section.note.GNU-stack,"",@progbits And here is the assembly output of Clang: $ clang -S -o - syscall.c .file "syscall.c" .text .globl main .align 16, 0x90 .type main,@function main: # @main .cfi_startproc # BB#0: pushq %rbp .Ltmp2: .cfi_def_cfa_offset 16 .Ltmp3: .cfi_offset %rbp, -16 movq%rsp, %rbp .Ltmp4: .cfi_def_cfa_register %rbp movl$0, %eax movl$0, -4(%rbp) movq$14, -16(%rbp) movl%eax, -28(%rbp) # 4-byte Spill #APP movl $1, %eax movl $1, %edi movq $main.hello, %rsi movl $14, %edx syscall #NO_APP movq%rax, -24(%rbp) movl-28(%rbp), %eax # 4-byte Reload popq%rbp ret .Ltmp5: .size main, .Ltmp5-main .cfi_endproc .type main.hello,@object # @main.hello .section.rodata,"a",@progbits main.hello: .asciz "Hello World!\n" .size main.hello, 14 .section".note.GNU-stack","",@progbits Here is information on my compiler versions: $ clang -v clang version 3.3 (tags/RELEASE_33/final) Target: x86_64-pc-linux-gnu Thread model: posix $ gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.3/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.8.3/work/gcc-4.8.3/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.3/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.3 p1.1, pie-0.5.9' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog Thread mode
[Bug c/63318] Hello World C program using inline assembly to invoke write(2) on amd64 Linux fails to print Hello World
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63318 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Your inline-asm is not reading from the string according to the constraints which is why GCC does not emit the copy into hello.
[Bug c/63318] Hello World C program using inline assembly to invoke write(2) on amd64 Linux fails to print Hello World
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63318 --- Comment #2 from Richard Yao --- What is the correct way to do this?
[Bug c/63318] Hello World C program using inline assembly to invoke write(2) on amd64 Linux fails to print Hello World
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63318 --- Comment #3 from Andrew Pinski --- asm volatile ( "movl $1, %%eax\n\t" "movl $1, %%edi\n\t" "movq %1, %%rsi\n\t" "movl %2, %%edx\n\t" "syscall" : "=a"(ret) : "g"(hello), "g"(hello_size), "m"(*string) : "%rdi", "%rsi", "%rdx", "%rcx", "%r11" ); Or asm volatile ( "movl $1, %%eax\n\t" "movl $1, %%edi\n\t" "movq %1, %%rsi\n\t" "movl %2, %%edx\n\t" "syscall" : "=a"(ret) : "g"(hello), "g"(hello_size) : "%rdi", "%rsi", "%rdx", "%rcx", "%r11", "memory" );
[Bug c/63318] Hello World C program using inline assembly to invoke write(2) on amd64 Linux fails to print Hello World
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63318 Richard Yao changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from Richard Yao --- Neither of the versions that you suggest work with my local GCC installation. The first fails to compile, but will compile if I 's/string/hello/'. The second compiles. Neither result in the compiler emitting "Hello World!\n". Clang does work in all cases, except for the first before the correction is made. Here is the output for the second version from GCC: $ gcc -S -o - syscall.c -Wall -Wextra -fno-strict-aliasing -fwrapv .file "syscall.c" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp .cfi_def_cfa_register 6 subq$48, %rsp movq%fs:40, %rax movq%rax, -8(%rbp) xorl%eax, %eax movabsq $8022916924116329800, %rax movq%rax, -32(%rbp) movl$560229490, -24(%rbp) movw$10, -20(%rbp) movq$14, -48(%rbp) leaq-32(%rbp), %rax #APP # 8 "syscall.c" 1 movl $1, %eax movl $1, %edi movq %rax, %rsi movl -48(%rbp), %edx syscall # 0 "" 2 #NO_APP movq%rax, -40(%rbp) movl$0, %eax movq-8(%rbp), %rdx xorq%fs:40, %rdx je .L3 call__stack_chk_fail .L3: leave .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (Gentoo 4.8.3 p1.1, pie-0.5.9) 4.8.3" .section.note.GNU-stack,"",@progbits It is clear that this used to work. If the failure is because the compiler has become more strict, then it should be possible to rewrite this in a way that produces a working program. If we cannot, I think this would qualify as a regression. Gentoo does not yet package newer versions of GCC, so it is possible that this is fixed in a newer version. If that is the case, I would like confirmation of that. I am setting this back to Unconfirmed lest that it be forgotten before we are on the same page.
[Bug c/63318] Hello World C program using inline assembly to invoke write(2) on amd64 Linux fails to print Hello World
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63318
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #5 from Andrew Pinski ---
This is still invalid.
Even though this is not fully correct:
#include
int main(void)
{
const char hello[] = "Hello World!\n";
const size_t hello_size = sizeof(hello);
ssize_t ret;
asm volatile
(
"movl $1, %%eax\n\t"
"movl $1, %%edi\n\t"
"movq %1, %%rsi\n\t"
"movl %2, %%edx\n\t"
"syscall"
: "=&a"(ret)
: "g"(hello), "g"(hello_size)
: "%rdi", "%rsi", "%rdx", "%rcx", "%r11"
);
return 0;
}
It works as you mark operand one as being clobbered early (which is kinda
correct as you change eax the very first instruction.
Really the correct way is to do:
#include
static inline syscall_1(long long syscallnum, long long arg0, long long arg1,
long long arg2)
{
register long long syscallnum_ __asm__("eax");
register long long arg0_ __asm__("edi");
register long long arg1_ __asm__("rsi");
register long long arg2_ __asm__("edx");
syscallnum_ = syscallnum;
arg0_ = arg0;
arg1_ = arg1;
arg2_ = arg2;
asm volatile
(
"syscall"
: "+r"(syscallnum_)
: "r"(arg0_), "r"(arg1_), "r"(arg2_)
: "%rcx", "%r11", "memory"
);
return syscallnum_;
}
int main(void)
{
const char hello[] = "Hello World!\n";
const size_t hello_size = sizeof(hello);
ssize_t ret;
ret = syscall_1(/*write*/1, /*fileno*/1, hello, hello_size);
return 0;
}
Note I might have swapped syscallnum and arg0.
[Bug c/63318] Hello World C program using inline assembly to invoke write(2) on amd64 Linux fails to print Hello World
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63318 --- Comment #6 from Richard Yao --- Created attachment 33523 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33523&action=edit Updated syscall.c That worked, although I am not sure how given that the string is missing in assembly output: $ gcc -S -o - syscall.c -Wall -Wextra -fno-strict-aliasing -fwrapv -O0 .file "syscall.c" .text .type syscall_1, @function syscall_1: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp .cfi_def_cfa_register 6 movq%rdi, -8(%rbp) movq%rsi, -16(%rbp) movq%rdx, -24(%rbp) movq%rcx, -32(%rbp) movq-8(%rbp), %rax movq-16(%rbp), %rdi movq-24(%rbp), %rsi movq-32(%rbp), %rdx #APP # 14 "syscall.c" 1 syscall # 0 "" 2 #NO_APP popq%rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size syscall_1, .-syscall_1 .globl main .type main, @function main: .LFB1: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq%rsp, %rbp .cfi_def_cfa_register 6 pushq %rbx subq$56, %rsp .cfi_offset 3, -24 movq%fs:40, %rax movq%rax, -24(%rbp) xorl%eax, %eax movabsq $8022916924116329800, %rax movq%rax, -48(%rbp) movl$560229490, -40(%rbp) movw$10, -36(%rbp) movq$14, -56(%rbp) movq-56(%rbp), %rdx leaq-48(%rbp), %rax movq%rdx, %rcx movq%rax, %rdx movl$1, %esi movl$1, %edi callsyscall_1 movl$0, %eax movq-24(%rbp), %rbx xorq%fs:40, %rbx je .L5 call__stack_chk_fail .L5: addq$56, %rsp popq%rbx popq%rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE1: .size main, .-main .ident "GCC: (Gentoo 4.8.3 p1.1, pie-0.5.9) 4.8.3" .section.note.GNU-stack,"",@progbits $ gcc syscall.c -Wall -Wextra -fno-strict-aliasing -fwrapv -O0 $ ./a.out Hello World!
[Bug c/63318] Hello World C program using inline assembly to invoke write(2) on amd64 Linux fails to print Hello World
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63318 --- Comment #7 from Andrew Pinski --- >That worked, although I am not sure how given that the string is missing in >assembly output: it is not missing: movabsq $8022916924116329800, %rax movq%rax, -48(%rbp) movl$560229490, -40(%rbp) movw$10, -36(%rbp) Those 4 instructions store the string into memory starting at -48(rbp).
[Bug target/54412] Request for 32-byte stack alignment with -mavx on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
--- Comment #11 from R Copley ---
On 20 September 2014 07:08, roland at rschulz dot eu
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
>
> --- Comment #10 from Roland Schulz ---
> Created attachment 33520
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33520&action=edit
> Slightly modified testcase
>
> This slightly modified testcase in which the return value isn't stored, still
> segfaults for me. With the 32bit mingw64 binary ((i686-win32-dwarf-rev1, Built
> by MinGW-W64 project) 4.9.1) it is OK, but with the 64bit binary
> ((x86_64-win32-seh-rev1, Built by MinGW-W64 project) 4.9.1) it segfaults.
Confirmed (with the same compiler, in the mingw-builds toolchain). I
compiled your testcase with command "gcc -O0 -g -ggdb -m64 -mavx
bug.c". It segfaults on the instruction marked "=>" below.
(gdb) disassemble /m
Dump of assembler code for function f:
6 {
0x004014f0 <+0>: push %rbp
0x004014f1 <+1>: mov%rsp,%rbp
0x004014f4 <+4>: mov%rcx,0x10(%rbp)
0x004014f8 <+8>: sub$0x40,%rsp
0x004014fc <+12>:mov%rsp,%rax
0x004014ff <+15>:add$0x1f,%rax
0x00401503 <+19>:shr$0x5,%rax
0x00401507 <+23>:shl$0x5,%rax
7 v4d x __attribute__ ((aligned (32))) = { 1.0, 2.0, 3.0, 4.0, };
0x0040150b <+27>:vmovapd 0x2aed(%rip),%ymm0# 0x404000
0x00401513 <+35>:vmovapd %ymm0,(%rax)
8 return x;
0x00401517 <+39>:mov0x10(%rbp),%rdx
0x0040151b <+43>:vmovapd (%rax),%ymm0
=> 0x0040151f <+47>:vmovapd %ymm0,(%rdx)
9 }
0x00401523 <+51>:mov0x10(%rbp),%rax
0x00401527 <+55>:mov%rbp,%rsp
0x0040152a <+58>:pop%rbp
0x0040152b <+59>:retq
End of assembler dump.
(gdb) print $rdx % 32
$1 = 16
[Bug c++/62017] AddressSanitizer reports *-buffer-overflow in destructor when multiple virtual inheritance is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62017 --- Comment #11 from Jason Merrill --- Author: jason Date: Sun Sep 21 02:42:40 2014 New Revision: 215427 URL: https://gcc.gnu.org/viewcvs?rev=215427&root=gcc&view=rev Log: PR c++/62017 * decl.c (begin_destructor_body): Only clobber the as-base part of *this. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug target/63312] FAIL: gcc.dg/torture/float128-exact-underflow.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63312 --- Comment #2 from Andreas Schwab --- This fixes the test for all opt levels, no regressions.
