[Bug analyzer/93543] [10 regression] bootstrap with clang fails in analyzer: reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93543 --- Comment #4 from Sebastian Huber --- (In reply to David Malcolm from comment #3) > Thanks. Does the patch in comment #1 fix it for you? I tested the patch on FreeBSD 12.1 with LLVM 8.0.1 and it fixes the issue.
[Bug analyzer/93543] [10 regression] bootstrap with clang 9.0.1 fails in analyzer: reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93543
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
||ains.de
--- Comment #2 from Sebastian Huber ---
LLVM 8.0.1 is also affected by this. In
https://en.cppreference.com/w/cpp/language/reinterpret_cast
I found this note:
"9) The null pointer value of any pointer type can be converted to any other
pointer type, resulting in the null pointer value of that type. Note that the
null pointer constant nullptr or any other value of type std::nullptr_t cannot
be converted to a pointer with reinterpret_cast: implicit conversion or
static_cast should be used for this purpose."
Consider the following test program:
struct function;
function *g(void)
{
return static_cast(nullptr);
}
function *f(void)
{
return reinterpret_cast(nullptr);
}
$ clang -c test.cc
test.cc:10:10: error: reinterpret_cast from 'nullptr_t' to 'function *' is not
allowed
return reinterpret_cast(nullptr);
^
1 error generated.
[Bug target/88789] epiphany: memory_resource.cc:235:62: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88789 Sebastian Huber changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||9.1.0 Version|9.0 |9.1.0 Resolution|--- |FIXED --- Comment #3 from Sebastian Huber --- The GCC 9.1.0 release and the current GCC 10 branch no longer have this issue.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #33 from Sebastian Huber --- (In reply to Eric Gallager from comment #32) > (In reply to Martin Liška from comment #31) > > Can the bug be marked as resolved? > > WAITING on a reply. From my point of view it is fixed I guess since Daniel Gutson didn't get an answer in the last four years, he will unlikely get it in the future.
[Bug libgcc/66032] RTEMS MIPS build fails on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032 Sebastian Huber changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #11 from Sebastian Huber --- (In reply to Chris Johns from comment #10) > (In reply to Joel Sherrill from comment #9) > > Yes. I believe it is the same bug. Use of GNU sed specifics on a system > > without GNU sed. > > > > I don't know if that changes the resolution. > > For this bug that is true however the other bug is still open and so the > issue is not resolved so I hope there is a chance someone with a suitable > level of sed knowledge may take a look to see if the use can be made to be > universal or highlight a bug in BSD sed. I had a look but I could not > determine if the issue is in the sed expressions used or BSD sed. I opened a FreeBSD bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235293
[Bug ada/89097] New: Ada build broken with long path names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89097 Bug ID: 89097 Summary: Ada build broken with long path names Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- I tried to build a native GCC with Ada support with a long build and source directory: pwd /home/user/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012 ls -l total 8 drwxr-xr-x 47 user user 4096 Jan 29 07:46 build drwxr-xr-x 40 user user 4096 Jan 28 13:47 gnu-mirror-gcc-597c6d15f88 GCC configure: ~/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/gnu-mirror-gcc-597c6d15f88/configure --prefix=$HOME/gcc-9 --disable-multilib --enable-languages='c,c++,ada' The build fails due to an empty s-oscons.ads: ls -l ./build/gcc/ada/rts/s-oscons* -rw-r--r-- 1 user user 0 Jan 29 07:46 ./build/gcc/ada/rts/s-oscons.ads -rw-r--r-- 1 user user 0 Jan 29 07:46 ./build/gcc/ada/rts/s-oscons.h -rw-r--r-- 1 user user 1501290 Jan 29 07:46 ./build/gcc/ada/rts/s-oscons-tmplt.i -rw-r--r-- 1 user user 444600 Jan 29 07:46 ./build/gcc/ada/rts/s-oscons-tmplt.s Error message: /home/user/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012/1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101211311411511611711811912012
[Bug lto/88643] -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 --- Comment #5 from Sebastian Huber --- I think the basic problem is that the LD --wrap feature works only with undefined symbols references and not relocations: See also: https://www.sourceware.org/ml/binutils/2019-01/msg00204.html
[Bug lto/88643] -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 Sebastian Huber changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #2 from Sebastian Huber --- Is this somehow related to the problem that the LD --wrap does not work for references internal to a translation unit? See: https://www.sourceware.org/ml/binutils/2018-12/msg00210.html https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=4ea904edb7b04ad526bd8a5401729a6c1f5a982f
[Bug target/88789] epiphany: memory_resource.cc:235:62: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88789 --- Comment #2 from Sebastian Huber --- I am not an epiphany expert. I just noticed this while testing the GCC builds for RTEMS.
[Bug c++/88789] New: epiphany: memory_resource.cc:235:62: error: static assertion failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88789 Bug ID: 88789 Summary: epiphany: memory_resource.cc:235:62: error: static assertion failed Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- Build fails in libstdc++ currently: libtool: compile: /home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/./gcc/xgcc -shared-libgcc -B/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/./gcc -nostdinc++ -L/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/src -L/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/src/.libs -L/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/libsupc++/.libs -nostdinc -B/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/newlib/ -isystem /home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/newlib/targ-include -isystem /home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/newlib/libc/include -B/home/user/install/rtems/6/epiphany-rtems6/bin/ -B/home/user/install/rtems/6/epiphany-rtems6/lib/ -isystem /home/user/install/rtems/6/epiphany-rtems6/include -isystem /home/user/install/rtems/6/epiphany-rtems6/sys-include -I/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/../libgcc -I/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/include/epiphany-rtems6 -I/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/build/epiphany-rtems6/libstdc++-v3/include -I/home/user/rtems-source-builder/rtems/build/epiphany-rtems6-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885-newlib-fbd3835384fa586fd32ce80280d81bb51ab042ba-x86_64-linux-gnu-1/gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/libsupc++ -std=gnu++17 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=cow-string-inst.lo -fimplicit-templates -g -O2 -c ../../../../../gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/src/c++17/cow-string-inst.cc -o cow-string-inst.o ../../../../../gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/src/c++17/memory_resource.cc: In member function 'void std::pmr::monotonic_buffer_resource::_M_new_buffer(std::size_t, std::size_t)': ../../../../../gnu-mirror-gcc-76fb04650b2bacd33eaff257f08fabcc237ec885/libstdc++-v3/src/c++17/memory_resource.cc:235:62: error: static assertion failed 235 | static_assert(alignof(monotonic_buffer_resource::_Chunk) == 1); | ~~~^~~~
[Bug tree-optimization/69196] [5 Regression] code size regression with jump threading at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196 --- Comment #29 from Sebastian Huber --- Just for reference some numbers for GCC 7.4.0 and GCC 9.0.0 20190104: sparc-rtems5-gcc --version sparc-rtems5-gcc (GCC) 7.4.0 20181206 (RTEMS 5, RSB ddba5372522da341fa20b2c75dfe966231cb6790, Newlib df6915f029ac9acd2b479ea898388cbd7dda4974) Copyright (C) 2017 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. sparc-rtems5-gcc -c -O2 -o vprintk.7.4.0.o vprintk.i sparc-rtems6-gcc --version sparc-rtems6-gcc (GCC) 9.0.0 20190104 (RTEMS 6, RSB cd4a4f61ea5bbd4236f7717a94cd5e67f8b3ad20, Newlib 34d9bb709390b14b4ed0b1ea2656bf6bf5a055c3) Copyright (C) 2019 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. sparc-rtems6-gcc -c -O2 -o vprintk.9.0.0.o vprintk.i size *.o textdata bss dec hex filename 688 0 0 688 2b0 vprintk.4.9.4.o 1272 0 01272 4f8 vprintk.6.0.0.o 933 0 0 933 3a5 vprintk.7.4.0.o 825 0 0 825 339 vprintk.9.0.0.o It seems the code size is quite volatile for this test case.
[Bug c/87683] Inline asm input/output operand does not prevent compiler optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87683
--- Comment #1 from Sebastian Huber ---
It seems it has nothing to do with the non-null attribute. This function
void d(void)
{
int s;
void *p;
s = posix_memalign(, 16, 16);
if (s != 22) {
a();
} else {
b();
}
}
is optimized to:
d:
.LFB1:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movl$16, %edx
movl$16, %esi
leaq8(%rsp), %rdi
callposix_memalign
addq$24, %rsp
.cfi_def_cfa_offset 8
jmp a
.cfi_endproc
.LFE1:
.size d, .-d
Why does GCC assume that s != 22? Memory allocation may fail, in this case
posix_memalign() may return ENOMEM which could be 22.
[Bug c/87683] New: Inline asm input/output operand does not prevent compiler optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87683
Bug ID: 87683
Summary: Inline asm input/output operand does not prevent
compiler optimization
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
I use this macro since 2016 to prevent certain compiler optimizations:
#define OBFUSCATE_VARIABLE(var) __asm__("" : "+r" (var))
This was suggested by:
https://gcc.gnu.org/ml/gcc/2016-09/msg00115.html
It seems that it doesn't prevent some compiler optimizations in combination
with the non-null attribute. Consider the following test case:
#include
#define OBFUSCATE_VARIABLE(var) __asm__("" : "+r" (var))
int posix_memalign(void **, size_t, size_t) __attribute__((__nonnull__(1)))
__attribute__((__alloc_align__(2))) __attribute__((__alloc_size__(3)))
__attribute__((__warn_unused_result__));
void a(void);
void b(void);
void c(void)
{
int s;
void **p;
p = 0;
OBFUSCATE_VARIABLE(p);
s = posix_memalign(p, 16, 16);
if (s != 22) {
a();
} else {
b();
}
}
GCC 7, 8, 9 unconditionally calls a() with -O2 without any warnings:
gcc -O2 -S -Wall -Wextra -pedantic test.c -o -
.file "test.c"
.text
.p2align 4,,15
.globl c
.type c, @function
c:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$16, %edx
movl$16, %esi
xorl%edi, %edi
callposix_memalign
addq$8, %rsp
.cfi_def_cfa_offset 8
jmp a
.cfi_endproc
.LFE0:
.size c, .-c
.ident "GCC: (SUSE Linux) 7.3.1 20180920 [gcc-7-branch revision
264438]"
.section.note.GNU-stack,"",@progbits
If I remove the inline asm, then I get a warning:
test.c: In function ‘c’:
test.c:19:4: warning: argument 1 null where non-null expected [-Wnonnull]
s = posix_memalign(p, 16, 16);
~~^~~
[Bug target/85904] [7/8 Regression] configure issue cross compiling on netbsd, with patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85904
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
||ains.de
--- Comment #8 from Sebastian Huber ---
This bug affects also all Newlib targets. However, the configure checks in
GLIBCXX_CROSSCONFIG do not work here, due to this Newlib speciality in
libstdc++-v3/configure.ac:
# First, test for "known" system libraries. We may be using newlib even
# on a hosted environment.
if test "x${with_newlib}" = "xyes"; then
[Bug target/83090] ICE on lm32-rtems building newlib libm (in require, at machmode.h:282)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83090 --- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- I was able to build GCC ab053afeec0450e64568a7a0d50d0e9a5ece2787 (20180116).
[Bug target/83810] New: sh: s-scaval.adb:103:07: warning: "IV_Ilf" overlays smaller object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83810 Bug ID: 83810 Summary: sh: s-scaval.adb:103:07: warning: "IV_Ilf" overlays smaller object Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- Created attachment 43113 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43113=edit Makefile to build the cross GCC I tried to build an Ada compiler for sh-rtems5. I am not sure if it is worth to support Ada on this target. I use in mainly to test the compiler build. /home/sh/b-gcc-sh/./gcc/xgcc -B/home/sh/b-gcc-sh/./gcc/ -nostdinc -B/home/sh/b-gcc-sh/sh-rtems5/newlib/ -isystem /home/sh/b-gcc-sh/sh-rtems5/newlib/targ-include -isystem /home/sh/src/gcc/newlib/libc/include -B/home/sh/install/sh-rtems5/bin/ -B/home/sh/install/sh-rtems5/lib/ -isystem /home/sh/install/sh-rtems5/include -isystem /home/sh/install/sh-rtems5/sys-include-c -g -O2 -m4-single-only -W -Wall -gnatpg -nostdinc -m4-single-only s-scaval.adb -o s-scaval.o s-scaval.adb:103:07: warning: "IV_Ilf" overlays smaller object s-scaval.adb:103:07: warning: program execution may be erroneous s-scaval.adb:103:07: warning: size of "IV_Ilf" is 64 s-scaval.adb:103:07: warning: size of "IS_Ilf" is 32 s-scaval.adb:104:07: warning: "IV_Ill" overlays smaller object s-scaval.adb:104:07: warning: program execution may be erroneous s-scaval.adb:104:07: warning: size of "IV_Ill" is 96 s-scaval.adb:104:07: warning: size of "IS_Ill" is 64 The attached Makefile can be used to reproduce the build. make clone make native make install/bin/sh-rtems5-ld make install/bin/sh-rtems5-gcc
[Bug target/83809] New: epiphany: a-direct.ads:478:09: alignment for "Search_Typeb119s" must be at least 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83809 Bug ID: 83809 Summary: epiphany: a-direct.ads:478:09: alignment for "Search_Typeb119s" must be at least 8 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- Created attachment 43112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43112=edit Makefile to build the cross GCC I tried to build an Ada compiler for epiphany-rtems5. I am not sure if it is worth to support Ada on this target. I use in mainly to test the compiler build. /home/sh/b-gcc-epiphany/./gcc/xgcc -B/home/sh/b-gcc-epiphany/./gcc/ -nostdinc -B/home/sh/b-gcc-epiphany/epiphany-rtems5/newlib/ -isystem /home/sh/b-gcc-epiphany/epiphany-rtems5/newlib/targ-include -isystem /home/sh/src/gcc/newlib/libc/include -B/home/sh/install/epiphany-rtems5/bin/ -B/home/sh/install/epiphany-rtems5/lib/ -isystem /home/sh/install/epiphany-rtems5/include -isystem /home/sh/install/epiphany-rtems5/sys-include-c -g -O2 -W -Wall -gnatpg -nostdinc a-direct.adb -o a-direct.o a-direct.ads:478:09: alignment for "Search_Typeb119s" must be at least 8 The attached Makefile can be used to reproduce the build. make clone make native make install/bin/epiphany-rtems5-ld make install/bin/epiphany-rtems5-gcc
[Bug target/83785] New: sh: ICE in maybe_record_trace_start, at dwarf2cfi.c:2344
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83785 Bug ID: 83785 Summary: sh: ICE in maybe_record_trace_start, at dwarf2cfi.c:2344 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- Created attachment 43097 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43097=edit Test case. /home/sh/b-gcc-sh/./gcc/xgcc -B/home/sh/b-gcc-sh/./gcc/ -c matmul_i8.i -O2 -g -funroll-loops --param max-unroll-times=4 during RTL pass: dwarf2 /home/sh/src/gcc/libgfortran/generated/matmul_i8.c: In function 'matmul_i8': /home/sh/src/gcc/libgfortran/generated/matmul_i8.c:2922:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2344 } ^ 0x102bef2f maybe_record_trace_start /home/sh/src/gcc/gcc/dwarf2cfi.c:2344 0x102bf587 create_trace_edges /home/sh/src/gcc/gcc/dwarf2cfi.c:2440 0x102c40b7 scan_trace /home/sh/src/gcc/gcc/dwarf2cfi.c:2653 0x102c4c77 create_cfi_notes /home/sh/src/gcc/gcc/dwarf2cfi.c:2679 0x102c4c77 execute_dwarf2_frame /home/sh/src/gcc/gcc/dwarf2cfi.c:3037 0x102c4c77 execute /home/sh/src/gcc/gcc/dwarf2cfi.c:3525 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.
[Bug target/83761] bfin: ICE: in require, at machmode.h:292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83761 --- Comment #3 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- Created attachment 43096 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43096=edit Test case. /home/sh/b-gcc-bfin/./gcc/xgcc -B/home/sh/b-gcc-bfin/./gcc/ -c sum_c8.i -O2 -g
[Bug target/83761] bfin: ICE: in require, at machmode.h:292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83761 --- Comment #1 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- Created attachment 43086 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43086=edit Makefile to build the cross GCC Use make clone make install/bin/bfin-rtems5-ld make install/bin/bfin-rtems5-gcc to build the cross GCC to reproduce the problem.
[Bug target/83761] New: bfin: ICE: in require, at machmode.h:292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83761 Bug ID: 83761 Summary: bfin: ICE: in require, at machmode.h:292 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- make[4]: Entering directory `/run/user/10351/b-gcc-bfin/bfin-rtems5/libgfortran' /bin/sh ./libtool --tag=CC --mode=compile /run/user/10351/b-gcc-bfin/./gcc/xgcc -B/run/user/10351/b-gcc-bfin/./gcc/ -nostdinc -B/run/user/10351/b-gcc-bfin/bfin-rtems5/newlib/ -isystem /run/user/10351/b-gcc-bfin/bfin-rtems5/newlib/targ-include -isystem /home/sh/src/gcc/newlib/libc/include -B/home/sh/install/bfin-rtems5/bin/ -B/home/sh/install/bfin-rtems5/lib/ -isystem /home/sh/install/bfin-rtems5/include -isystem /home/sh/install/bfin-rtems5/sys-include-DHAVE_CONFIG_H -I. -I/home/sh/src/gcc/libgfortran -iquote/home/sh/src/gcc/libgfortran/io -I/home/sh/src/gcc/libgfortran/../gcc -I/home/sh/src/gcc/libgfortran/../gcc/config -I../.././gcc -I/home/sh/src/gcc/libgfortran/../libgcc -I../libgcc -I/home/sh/src/gcc/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT sum_c8.lo -MD -MP -MF .deps/sum_c8.Tpo -c -o sum_c8.lo `test -f '/home/sh/src/gcc/libgfortran/generated/sum_c8.c' || echo '/home/sh/src/gcc/libgfortran/'`/home/sh/src/gcc/libgfortran/generated/sum_c8.c libtool: compile: /run/user/10351/b-gcc-bfin/./gcc/xgcc -B/run/user/10351/b-gcc-bfin/./gcc/ -nostdinc -B/run/user/10351/b-gcc-bfin/bfin-rtems5/newlib/ -isystem /run/user/10351/b-gcc-bfin/bfin-rtems5/newlib/targ-include -isystem /home/sh/src/gcc/newlib/libc/include -B/home/sh/install/bfin-rtems5/bin/ -B/home/sh/install/bfin-rtems5/lib/ -isystem /home/sh/install/bfin-rtems5/include -isystem /home/sh/install/bfin-rtems5/sys-include -DHAVE_CONFIG_H -I. -I/home/sh/src/gcc/libgfortran -iquote/home/sh/src/gcc/libgfortran/io -I/home/sh/src/gcc/libgfortran/../gcc -I/home/sh/src/gcc/libgfortran/../gcc/config -I../.././gcc -I/home/sh/src/gcc/libgfortran/../libgcc -I../libgcc -I/home/sh/src/gcc/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT sum_c8.lo -MD -MP -MF .deps/sum_c8.Tpo -c /home/sh/src/gcc/libgfortran/generated/sum_c8.c -o sum_c8.o during RTL pass: reload /home/sh/src/gcc/libgfortran/generated/sum_c8.c: In function 'sum_c8': /home/sh/src/gcc/libgfortran/generated/sum_c8.c:191:1: internal compiler error: in require, at machmode.h:292 } ^ 0x101e4f43 opt_mode::require() const /home/sh/src/gcc/gcc/machmode.h:292 0x101e4f43 replace_reg_with_saved_mem /home/sh/src/gcc/gcc/caller-save.c:1151 0x101e49a3 mark_referenced_regs /home/sh/src/gcc/gcc/caller-save.c:1053 0x101e49f3 mark_referenced_regs /home/sh/src/gcc/gcc/caller-save.c:1073 0x101e49f3 mark_referenced_regs /home/sh/src/gcc/gcc/caller-save.c:1073 0x101e6e2f save_call_clobbered_regs() /home/sh/src/gcc/gcc/caller-save.c:893 0x10771d27 reload(rtx_insn*, int) /home/sh/src/gcc/gcc/reload1.c:981 0x1059e8bb do_reload /home/sh/src/gcc/gcc/ira.c:5474 0x1059e8bb execute /home/sh/src/gcc/gcc/ira.c:5646
[Bug target/83681] epiphany: config/epiphany/epiphany.h:883:8: error: unknown type name 'rtl_opt_pass'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83681 Sebastian Huber <sebastian.hu...@embedded-brains.de> changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- Patch committed.
[Bug target/83681] New: epiphany: config/epiphany/epiphany.h:883:8: error: unknown type name 'rtl_opt_pass'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83681 Bug ID: 83681 Summary: epiphany: config/epiphany/epiphany.h:883:8: error: unknown type name 'rtl_opt_pass' Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- I cannot build an epiphany-rtems5 Ada compiler: /run/user/10351/b-gcc-epiphany/./gcc/xgcc -B/run/user/10351/b-gcc-epiphany/./gcc/ -nostdinc -B/run/user/10351/b-gcc-epiphany/epiphany-rtems5/newlib/ -isystem /run/user/10351/b-gcc-epiphany/epiphany-rtems5/newlib/targ-include -isystem /home/sh/src/gcc/newlib/libc/include -B/home/sh/install/epiphany-rtems5/bin/ -B/home/sh/install/epiphany-rtems5/lib/ -isystem /home/sh/install/epiphany-rtems5/include -isystem /home/sh/install/epiphany-rtems5/sys-include-c -DCROSS_DIRECTORY_STRUCTURE -DIN_GCC -W -Wall -g -O2 -g -O2 -fexceptions -DIN_RTS -DHAVE_GETIPINFO\ -iquote /home/sh/src/gcc/gcc \ -iquote . -iquote .. -iquote ../.. -iquote /home/sh/src/gcc/gcc/ada -iquote /home/sh/src/gcc/gcc -I/home/sh/src/gcc/include \ targext.c -o targext.o In file included from ../../tm.h:21, from targext.c:46: /home/sh/src/gcc/gcc/config/epiphany/epiphany.h:883:8: error: unknown type name 'rtl_opt_pass' extern rtl_opt_pass *make_pass_mode_switch_use (gcc::context *ctxt); ^~~~ /home/sh/src/gcc/gcc/config/epiphany/epiphany.h:883:52: error: expected ')' before ':' token extern rtl_opt_pass *make_pass_mode_switch_use (gcc::context *ctxt); ^ ) /home/sh/src/gcc/gcc/config/epiphany/epiphany.h:884:8: error: unknown type name 'rtl_opt_pass' extern rtl_opt_pass *make_pass_resolve_sw_modes (gcc::context *ctxt); ^~~~ /home/sh/src/gcc/gcc/config/epiphany/epiphany.h:884:53: error: expected ')' before ':' token extern rtl_opt_pass *make_pass_resolve_sw_modes (gcc::context *ctxt); ^ ) In file included from ../../tm.h:23, from targext.c:46: /home/sh/src/gcc/gcc/config/elfos.h:201: warning: "READONLY_DATA_SECTION_ASM_OP" redefined #define READONLY_DATA_SECTION_ASM_OP "\t.section\t.rodata" In file included from ../../tm.h:21, from targext.c:46: /home/sh/src/gcc/gcc/config/epiphany/epiphany.h:671: note: this is the location of the previous definition #define READONLY_DATA_SECTION_ASM_OP "\t.section .rodata"
[Bug target/83670] New: m32c ICE in leaf_function_p, at final.c:4368
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83670 Bug ID: 83670 Summary: m32c ICE in leaf_function_p, at final.c:4368 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- Created attachment 43016 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43016=edit Test program. m32c-rtems5-gcc -O2 test.i during RTL pass: pro_and_epilogue test.c: In function 'main': test.c:16:1: internal compiler error: in leaf_function_p, at final.c:4368 } ^ 0x103e7b8b leaf_function_p() /home/sh/src/gcc/gcc/final.c:4368 0x10c3c61f m32c_leaf_function_p /home/sh/src/gcc/gcc/config/m32c/m32c.c:4023 0x10c3c61f m32c_emit_prologue() /home/sh/src/gcc/gcc/config/m32c/m32c.c:4077 0x10dfb8e3 gen_prologue() /home/sh/src/gcc/gcc/config/m32c/prologue.md:26 0x10c35e57 target_gen_prologue /home/sh/src/gcc/gcc/config/m32c/blkmov.md:359 0x1044e9d3 make_prologue_seq /home/sh/src/gcc/gcc/function.c:5912 0x1044ed67 thread_prologue_and_epilogue_insns() /home/sh/src/gcc/gcc/function.c:6029 0x1044f7af rest_of_handle_thread_prologue_and_epilogue /home/sh/src/gcc/gcc/function.c:6520 0x1044f7af execute /home/sh/src/gcc/gcc/function.c:6562 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.
[Bug target/83090] ICE on lm32-rtems building newlib libm (in require, at machmode.h:282)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83090 Sebastian Huber <sebastian.hu...@embedded-brains.de> changed: What|Removed |Added CC||lekernel at gcc dot gnu.org, ||sebastian.huber@embedded-br ||ains.de --- Comment #1 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- ICE still exists with GCC 659f92d1990e0b84a6e30f6ecd76319552faf7b7 (20180103).
[Bug target/83387] PowerPC64: Infinite loops in do_reload() with -msoft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #15 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(In reply to Sebastian Huber from comment #14)
> (In reply to Peter Bergner from comment #13)
> > (In reply to Sebastian Huber from comment #12)
> > > (In reply to Peter Bergner from comment #9)
> > > [...]
> > > > Here, you can see that on ELFv2, we always assume HW FP regs are
> > > > avialable,
> > > > because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1,
> > > > aka
> > > > reg 33). I'm afraid that are going to be a *LOT* of these assumptions
> > > > builtin into the backend and tracking them all down and fixing them is
> > > > not
> > > > going to be easy. That's why I asked earlier, if you really really
> > > > need to
> > > > disable HW FP for your builds. If you do, then good luck to you finding
> > > > them all.
> > >
> > > Thanks for your investigations. I removed the 64-bit soft-float multilib.
> >
> > I can't promise this is all you need, but does the following patch help?
> >
> > Index: gcc/config/rs6000/rs6000.c
> > ===
> > --- gcc/config/rs6000/rs6000.c (revision 255700)
> > +++ gcc/config/rs6000/rs6000.c (working copy)
> > @@ -11095,7 +11095,8 @@ rs6000_discover_homogeneous_aggregate (m
> > homogeneous aggregates; these types are handled via the
> > targetm.calls.split_complex_arg mechanism. Complex types
> > can be elements of homogeneous aggregates, however. */
> > - if (DEFAULT_ABI == ABI_ELFv2 && type && AGGREGATE_TYPE_P (type))
> > + if (TARGET_HARD_FLOAT && DEFAULT_ABI == ABI_ELFv2 && type
> > + && AGGREGATE_TYPE_P (type))
> > {
> >machine_mode field_mode = VOIDmode;
> >int field_count = rs6000_aggregate_candidate (type, _mode);
> >
> >
> >
>
> With this patch I can build an Ada compiler with a -m64 and -msoft-float
> multilib.
How do we want to continue with this PR? Close it as WONTFIX or apply the patch
and close it as FIXED?
[Bug target/83387] PowerPC64: Infinite loops in do_reload() with -msoft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387
--- Comment #14 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(In reply to Peter Bergner from comment #13)
> (In reply to Sebastian Huber from comment #12)
> > (In reply to Peter Bergner from comment #9)
> > [...]
> > > Here, you can see that on ELFv2, we always assume HW FP regs are
> > > avialable,
> > > because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1, aka
> > > reg 33). I'm afraid that are going to be a *LOT* of these assumptions
> > > builtin into the backend and tracking them all down and fixing them is not
> > > going to be easy. That's why I asked earlier, if you really really need
> > > to
> > > disable HW FP for your builds. If you do, then good luck to you finding
> > > them all.
> >
> > Thanks for your investigations. I removed the 64-bit soft-float multilib.
>
> I can't promise this is all you need, but does the following patch help?
>
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c(revision 255700)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -11095,7 +11095,8 @@ rs6000_discover_homogeneous_aggregate (m
> homogeneous aggregates; these types are handled via the
> targetm.calls.split_complex_arg mechanism. Complex types
> can be elements of homogeneous aggregates, however. */
> - if (DEFAULT_ABI == ABI_ELFv2 && type && AGGREGATE_TYPE_P (type))
> + if (TARGET_HARD_FLOAT && DEFAULT_ABI == ABI_ELFv2 && type
> + && AGGREGATE_TYPE_P (type))
> {
>machine_mode field_mode = VOIDmode;
>int field_count = rs6000_aggregate_candidate (type, _mode);
>
>
>
With this patch I can build an Ada compiler with a -m64 and -msoft-float
multilib.
[Bug target/83387] PowerPC64: Infinite loops in do_reload() with -msoft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387 --- Comment #12 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Peter Bergner from comment #9) [...] > Here, you can see that on ELFv2, we always assume HW FP regs are avialable, > because we're forcing usage of HW FP registers (FP_ARG_RETURN, ie, f1, aka > reg 33). I'm afraid that are going to be a *LOT* of these assumptions > builtin into the backend and tracking them all down and fixing them is not > going to be easy. That's why I asked earlier, if you really really need to > disable HW FP for your builds. If you do, then good luck to you finding > them all. Thanks for your investigations. I removed the 64-bit soft-float multilib. Would it be possible to generate a proper ICE with a user friendly error message if someone uses -msoft-float on this target?
[Bug target/83387] PowerPC64: Infinite loops in do_reload() with -msoft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387 Sebastian Huber <sebastian.hu...@embedded-brains.de> changed: What|Removed |Added Target|powerpc-rtems5 |powerpc64le-unknown-linux-g ||nu Summary|PowerPC64 + Ada + RTEMS:|PowerPC64: Infinite loops |Infinite loops in |in do_reload() with |do_reload() |-msoft-float --- Comment #7 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- It seems to be a general problem with -msoft-float on PowerPC64. I built a native GCC on gcc112: [sh@gcc2-power8 ~]$ cd /home/sh/b-gcc-git/gcc/ada/rts [sh@gcc2-power8 rts]$ gdb --args /home/sh/b-gcc-git/gcc/gnat1 -gnatwa -quiet -nostdinc -nostdinc -dumpbase a-coteio.ads -auxbase-strip a-coteio.o -O2 -Wextra -Wall -g -gnatpg -msoft-float -gnatO a-coteio.o a-coteio.ads -o - GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "ppc64le-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Warning: /home/sh/gcc-7-20161030/gcc: No such file or directory. Warning: /home/sh/gcc-7-20161030/gcc/ada: No such file or directory. Warning: /home/sh/gcc-7-20161030/gcc/c: No such file or directory. Warning: /home/sh/gcc-7-20161030/gcc/cp: No such file or directory. Warning: /home/sh/gcc-7-20161030/gcc/fortran: No such file or directory. Warning: /home/sh/gcc-7-20161030/gcc/go: No such file or directory. Warning: /home/sh/gcc-7-20161030/gcc/jit: No such file or directory. Warning: /home/sh/gcc-7-20161030/gcc/lto: No such file or directory. Warning: /home/sh/gcc-7-20161030/gcc/objc: No such file or directory. Warning: /home/sh/gcc-7-20161030/gcc/objcp: No such file or directory. Traceback (most recent call last): File "", line 1, in ImportError: No module named gdbhooks /home/sh/.gdbinit:13: Error in sourced command file: Error while executing Python code. Reading symbols from /home/sh/b-gcc-git/gcc/gnat1...done. (gdb) r Starting program: /home/sh/b-gcc-git/gcc/gnat1 -gnatwa -quiet -nostdinc -nostdinc -dumpbase a-coteio.ads -auxbase-strip a-coteio.o -O2 -Wextra -Wall -g -gnatpg -msoft-float -gnatO a-coteio.o a-coteio.ads -o - .file "a-coteio.ads" .machine power7 .abiversion 2 .section".text" .Ltext0: .globl __truncdfsf2 ^C Program received signal SIGINT, Interrupt. 0x108158a0 in bitmap_and_compl_into (a=0x12c7a0b0, b=) at /home/sh/gcc-git/gcc/bitmap.c:1181 1181 gcc_checking_assert (!a->current == !a->first Missing separate debuginfos, use: debuginfo-install glibc-2.17-196.el7.ppc64le (gdb) bt #0 0x108158a0 in bitmap_and_compl_into (a=0x12c7a0b0, b=) at /home/sh/gcc-git/gcc/bitmap.c:1181 #1 0x10c83208 in spill_pseudos () at /home/sh/gcc-git/gcc/bitmap.h:806 #2 lra_spill () at /home/sh/gcc-git/gcc/lra-spills.c:595 #3 0x10c56998 in lra (f=) at /home/sh/gcc-git/gcc/lra.c:2514 #4 0x10bf216c in do_reload () at /home/sh/gcc-git/gcc/ira.c:5443 #5 (anonymous namespace)::pass_reload::execute (this=) at /home/sh/gcc-git/gcc/ira.c:5627 #6 0x10d36f20 in execute_one_pass (pass=0x12a04650) at /home/sh/gcc-git/gcc/passes.c:2497 #7 0x10d38114 in execute_pass_list_1 (pass=0x12a04650) at /home/sh/gcc-git/gcc/passes.c:2586 #8 0x10d3812c in execute_pass_list_1 (pass=0x12a03570) at /home/sh/gcc-git/gcc/passes.c:2587 #9 0x10d381b8 in execute_pass_list (fn=, pass=) at /home/sh/gcc-git/gcc/passes.c:2597 #10 0x108cb178 in cgraph_node::expand (this=0x3fffaf68) at /home/sh/gcc-git/gcc/context.h:48 #11 0x108ccf44 in expand_all_functions () at /home/sh/gcc-git/gcc/cgraphunit.c:2275 #12 symbol_table::compile (this=0x3fffaf42) at /home/sh/gcc-git/gcc/cgraphunit.c:2623 #13 0x108d084c in compile (this=0x3fffaf42) at /home/sh/gcc-git/gcc/cgraphunit.c:2716 #14 symbol_table::finalize_compilation_unit (this=0x3fffaf42) at /home/sh/gcc-git/gcc/cgraphunit.c:2716 #15 0x10e564b4 in compile_file () at /home/sh/gcc-git/gcc/toplev.c:480 #16 0x10277938 in do_compile () at /home/sh/gcc-git/gcc/toplev.c:2063 #17 toplev::main (this=0x3fffef50, argc=, argv=) at /home/sh/gcc-git/gcc/toplev.c:2198 #18 0x102798a8 in main (argc=, argv=0x3378) at /home/sh/gcc-git/gcc/main.c:39
[Bug target/83387] PowerPC64 + Ada + RTEMS: Infinite loops in do_reload()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387 --- Comment #6 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Peter Bergner from comment #5) > (In reply to Sebastian Huber from comment #4) > > If I remove the -msoft-float, the two example source files compile > > (-mno-altivec seems to cause no harm). > > Well the first question, is do you really need to use -msoft-float? Looking > at the E6500 hardware doc seems to show that it has both hardware FP and > Altivec units. For some applications fast context switches are important and the FP/AltiVec context is quite huge. It affects also the interrupt latency. I have to discuss this with the application developers. We probably don't need it in a 64-bit configuration. > > > > How can I dump the instruction? I don't know Ada well enough to figure it > > out from the source code. > > I don't know Ada as well, but I mean what does the RTL insn look like? > You'll probably need a debug build of your gcc for that so it isn't > optimized away and then you can print it from gdb. Ok, I will try to do this. I am not sure how it works with the cross compiler build: https://gcc.gnu.org/wiki/DebuggingGCC#gccbuilddebug
[Bug target/83387] PowerPC64 + Ada + RTEMS: Infinite loops in do_reload()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387 --- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Peter Bergner from comment #3) > (In reply to Sebastian Huber from comment #2) > > Is -msoft-float supported on 64-bit PowerPC? It is not important for us. I > > just copied the 32-bit multilibs without much thought. > > It is used by the linux kernel, but they also explicitly do not use > float/double types. If you have float/double types in your source code and > compile for 64-bit using -msoft-float, I could guess that you would run into > some of the assumptions in the 64-bit backend that floating point hardware > is always available. It's just a guess though, without knowing what the > insn / operand you're having problems with looks like. If I remove the -msoft-float, the two example source files compile (-mno-altivec seems to cause no harm). How can I dump the instruction? I don't know Ada well enough to figure it out from the source code.
[Bug target/83387] PowerPC64 + Ada + RTEMS: Infinite loops in do_reload()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387 --- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Peter Bergner from comment #1) > Is the insn you're dying with contain FP operands? I know the backend for > 64-bit PowerPC assumes/requires 64-bit FP hardware is available and since > you're using -msoft-float, I can imagine that you're running afoul of that > somehow. Is -msoft-float supported on 64-bit PowerPC? It is not important for us. I just copied the 32-bit multilibs without much thought. > > FYI, I tried logging into gcc67 but couldn't for some reason. I have no > problems logging into other gcc farm systems. My SSH config for gcc67 is: Compression yes Host gcc67 User sh Hostname gcc67.fsffrance.org
[Bug target/83387] New: PowerPC64 + Ada + RTEMS: Infinite loops in do_reload()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83387 Bug ID: 83387 Summary: PowerPC64 + Ada + RTEMS: Infinite loops in do_reload() Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- I added support for the 64-bit PowerPC some months ago using a variant of the ELFv2 ABI. I don't know which kind of long double support I use on this target. This is difficult for me to understand how this works on 64-bit PowerPC. This was no problem up to now since nobody used long double with RTEMS on this target. I tried to build a GCC with Ada support today for the powerpc-rtems5 target. It ends up in infinite loops while building the Ada run-time multilib for a 64-bit PowerPC variant. To reproduce the problem you can log in to gcc67: cd /home/sh/tmp/b-gcc/gcc/ada/rts_me6500_m64_nof_noaltivec gdb --args /home/sh/tmp/b-gcc/./gcc/gnat1 -gnatwa -quiet -nostdinc -nostdinc -dumpbase a-coteio.ads -auxbase-strip a-coteio.o -O2 -Wextra -Wall -g -mcpu=e6500 -msoft-float -gnatpg -mcpu=e6500 -m64 -msoft-float -mno-altivec -gnatO a-scteio.o a-scteio.ads -o - ... (gdb) bt #0 spill_pseudos (set=0x7fffdf50) at /home/sh/tmp/gcc/gcc/lra-eliminations.c:1164 #1 update_reg_eliminate(bitmap_head*) () at /home/sh/tmp/gcc/gcc/lra-eliminations.c:1288 #2 0x00cfbbb3 in lra_eliminate(bool, bool) () at /home/sh/tmp/gcc/gcc/lra-eliminations.c:1449 #3 0x00ce35ea in lra(_IO_FILE*) () at /home/sh/tmp/gcc/gcc/lra.c:2493 #4 0x00c9c6a2 in do_reload () at /home/sh/tmp/gcc/gcc/ira.c:5443 #5 (anonymous namespace)::pass_reload::execute(function*) () at /home/sh/tmp/gcc/gcc/ira.c:5627 #6 0x00d61a1b in execute_one_pass(opt_pass*) () at /home/sh/tmp/gcc/gcc/passes.c:2497 #7 0x00d62255 in execute_pass_list_1(opt_pass*) () at /home/sh/tmp/gcc/gcc/passes.c:2586 #8 0x00d62267 in execute_pass_list_1(opt_pass*) () at /home/sh/tmp/gcc/gcc/passes.c:2587 #9 0x00d62299 in execute_pass_list(function*, opt_pass*) () at /home/sh/tmp/gcc/gcc/passes.c:2597 #10 0x00aabaee in cgraph_node::expand() () at /home/sh/tmp/gcc/gcc/cgraphunit.c:2139 #11 0x00aaccbc in expand_all_functions () at /home/sh/tmp/gcc/gcc/cgraphunit.c:2275 #12 symbol_table::compile() [clone .part.75] () at /home/sh/tmp/gcc/gcc/cgraphunit.c:2623 #13 0x00aaefaa in symbol_table::compile (this=0x7753c000) at /home/sh/tmp/gcc/gcc/cgraphunit.c:2537 #14 symbol_table::finalize_compilation_unit (this=0x7753c000) at /home/sh/tmp/gcc/gcc/cgraphunit.c:2716 #15 0x00e1efc3 in compile_file () at /home/sh/tmp/gcc/gcc/toplev.c:480 #16 0x0068be0b in do_compile () at /home/sh/tmp/gcc/gcc/toplev.c:2059 #17 toplev::main(int, char**) () at /home/sh/tmp/gcc/gcc/toplev.c:2194 #18 0x0068e07b in main (argc=25, argv=0x7fffe418) at /home/sh/tmp/gcc/gcc/main.c:39 gdb --args /home/sh/tmp/b-gcc/./gcc/gnat1 -gnatwa -quiet -nostdinc -nostdinc -dumpbase a-coteio.ads -auxbase-strip a-coteio.o -O2 -Wextra -Wall -g -mcpu=e6500 -msoft-float -gnatpg -mcpu=e6500 -m64 -msoft-float -mno-altivec -gnatO a-coteio.o a-coteio.ads -o - ... (gdb) bt #0 process_bb_lives(basic_block_def*, int&, bool) () at /home/sh/tmp/gcc/gcc/lra-lives.c:726 #1 0x00cff3ea in lra_create_live_ranges_1(bool, bool) () at /home/sh/tmp/gcc/gcc/lra-lives.c:1316 #2 0x00cffea0 in lra_create_live_ranges(bool, bool) () at /home/sh/tmp/gcc/gcc/lra-lives.c:1380 #3 0x00ce36fa in lra(_IO_FILE*) () at /home/sh/tmp/gcc/gcc/lra.c:2434 #4 0x00c9c6a2 in do_reload () at /home/sh/tmp/gcc/gcc/ira.c:5443 #5 (anonymous namespace)::pass_reload::execute(function*) () at /home/sh/tmp/gcc/gcc/ira.c:5627 #6 0x00d61a1b in execute_one_pass(opt_pass*) () at /home/sh/tmp/gcc/gcc/passes.c:2497 #7 0x00d62255 in execute_pass_list_1(opt_pass*) () at /home/sh/tmp/gcc/gcc/passes.c:2586 #8 0x00d62267 in execute_pass_list_1(opt_pass*) () at /home/sh/tmp/gcc/gcc/passes.c:2587 #9 0x00d62299 in execute_pass_list(function*, opt_pass*) () at /home/sh/tmp/gcc/gcc/passes.c:2597 #10 0x00aabaee in cgraph_node::expand() () at /home/sh/tmp/gcc/gcc/cgraphunit.c:2139 #11 0x00aaccbc in expand_all_functions () at /home/sh/tmp/gcc/gcc/cgraphunit.c:2275 #12 symbol_table::compile() [clone .part.75] () at /home/sh/tmp/gcc/gcc/cgraphunit.c:2623 #13 0x00aaefaa in symbol_table::compile (this=0x7753c000) at /home/sh/tmp/gcc/gcc/cgraphunit.c:2537 #14 symbol_table::finalize_compilation_unit (this=0x7753c000) at /home/sh/tmp/gcc/gcc/cgraphunit.c:2716 #15 0x00e1efc3 in compile_file () at /home/sh/tmp/gcc/gcc/toplev.c:480 #16 0x0068be0b in do_compile () at /home/sh/tmp/gcc/gcc/toplev.c:2059 #17 toplev::main(int, char**) () at /home/sh/tmp
[Bug target/81132] New: [m68k] internal compiler error: in find_reloads, at reload.c:4077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81132
Bug ID: 81132
Summary: [m68k] internal compiler error: in find_reloads, at
reload.c:4077
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The following test program
static int vector_to_bit(int vector)
{
return 1U << (vector & 0x1fU);
}
static volatile int *vector_to_imr(int vector)
{
return (volatile int *)(vector + 64);
}
void bsp_interrupt_vector_disable(int vector)
{
volatile int *imr = vector_to_imr(vector);
int bit = vector_to_bit(vector);
*imr |= bit;
}
yields
m68k-rtems4.12-gcc -S -mcfv4e -O2 test.c -o /dev/null
test.c: In function 'bsp_interrupt_vector_disable':
test.c:14:1: internal compiler error: in find_reloads, at reload.c:4077
}
^
0x7f2c13 find_reloads(rtx_insn*, int, int, int, short*)
/home/EB/sebastian_h/archive/gcc-git/gcc/reload.c:4077
0x80037d calculate_needs_all_insns
/home/EB/sebastian_h/archive/gcc-git/gcc/reload1.c:1472
0x80037d reload(rtx_insn*, int)
/home/EB/sebastian_h/archive/gcc-git/gcc/reload1.c:987
0x6e798c do_reload
/home/EB/sebastian_h/archive/gcc-git/gcc/ira.c:5484
0x6e798c execute
/home/EB/sebastian_h/archive/gcc-git/gcc/ira.c:5656
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.
[Bug target/81131] New: [m68k] internal compiler error: in find_reloads, at reload.c:4077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81131
Bug ID: 81131
Summary: [m68k] internal compiler error: in find_reloads, at
reload.c:4077
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The following test program
static int vector_to_bit(int vector)
{
return 1U << (vector & 0x1fU);
}
static volatile int *vector_to_imr(int vector)
{
return (volatile int *)(vector + 64);
}
void bsp_interrupt_vector_disable(int vector)
{
volatile int *imr = vector_to_imr(vector);
int bit = vector_to_bit(vector);
*imr |= bit;
}
yields
m68k-rtems4.12-gcc -S -mcfv4e -O2 test.c -o /dev/null
test.c: In function 'bsp_interrupt_vector_disable':
test.c:14:1: internal compiler error: in find_reloads, at reload.c:4077
}
^
0x7f2c13 find_reloads(rtx_insn*, int, int, int, short*)
/home/EB/sebastian_h/archive/gcc-git/gcc/reload.c:4077
0x80037d calculate_needs_all_insns
/home/EB/sebastian_h/archive/gcc-git/gcc/reload1.c:1472
0x80037d reload(rtx_insn*, int)
/home/EB/sebastian_h/archive/gcc-git/gcc/reload1.c:987
0x6e798c do_reload
/home/EB/sebastian_h/archive/gcc-git/gcc/ira.c:5484
0x6e798c execute
/home/EB/sebastian_h/archive/gcc-git/gcc/ira.c:5656
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.
[Bug ada/81070] Cannot build s-intrr.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81070 --- Comment #1 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- The native GNAT is: gnat --version GNAT 7.1.1 20170530 [gcc-7-branch revision 248621]
[Bug ada/81070] New: Cannot build s-intrr.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81070 Bug ID: 81070 Summary: Cannot build s-intrr.adb Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- On GCC 7.1 branch (34df49547806512c6e1549a58048f161f5fa42bc) I get the following error while building the Ada run-time support: make[5]: 's-inmaop.o' is up to date. /build/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/newlib/ -isystem /build/git-build/b-gcc-git-arm-rtems4.12/arm-rtems4.12/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/arm-rtems4.12/bin/ -B/opt/rtems-4.12/arm-rtems4.12/lib/ -isystem /opt/rtems-4.12/arm-rtems4.12/include -isystem /opt/rtems-4.12/arm-rtems4.12/sys-include-c -g -O2 -W -Wall -gnatpg -nostdinc s-interr.adb -o s-interr.o s-interr.adb:206:06: subprogram "Interrupt_Connect" has wrong convention s-interr.adb:206:06: does not match "Interrupt_Connector" declared at line 199 s-interr.adb:206:06: probable missing pragma Convention for "Interrupt_Connector" ../gcc-interface/Makefile:296: recipe for target 's-interr.o' failed make[5]: *** [s-interr.o] Error 1 make[5]: Leaving directory '/build/git-build/b-gcc-git-arm-rtems4.12/gcc/ada/rts' gcc-interface/Makefile:2791: recipe for target 'gnatlib' failed make[4]: *** [gnatlib] Error 2 Configure command line: configure --target=arm-rtems4.12 --with-newlib --disable-nls --disable-lto --disable-plugin --enable-languages=c,c++,ada
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694 Sebastian Huber <sebastian.hu...@embedded-brains.de> changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #14 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- A git bisect identified this as the bad commit: commit 44bf3f4eef496f480662d10d4a314f7acb578c46 Author: jakub <jakub@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Wed Nov 30 13:02:48 2016 + * emit-rtl.c (verify_insn_sharing): Call verify_rtx_sharing instead of reset_used_flags. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@243019 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694 --- Comment #12 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- Its strange that it is so hard to reproduce. Maybe it has something to do with the default architecture version. It fails with: -mthumb -O2 -ftls-model=local-exec -march=armv4t -mthumb -O2 -ftls-model=local-exec -march=armv5t -mthumb -O2 -ftls-model=local-exec -march=armv6 It works with: -mthumb -O2 -ftls-model=local-exec -march=armv7
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #9 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
I did a fresh git clone today on gcc113 of the GCC compile farm. I built an
arm-linux-gnueabihf GCC:
./install/bin/arm-linux-gnueabihf-gcc --version --verbose
Using built-in specs.
COLLECT_GCC=./install/bin/arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/sh/install/libexec/gcc/arm-linux-gnueabihf/7.0.0/lto-wrapper
arm-linux-gnueabihf-gcc (GCC) 7.0.0 20161208 (experimental) [trunk revision
5b2a614:e5a02c3:beea0800baadbe98febe5a4e54112d76ea10a9d3]
Copyright (C) 2016 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.
Target: arm-linux-gnueabihf
Configured with: ../gcc/configure --prefix=/home/sh/install
--target=arm-linux-gnueabihf --disable-multilib --enable-languages=c
Thread model: posix
gcc version 7.0.0 20161208 (experimental) [trunk revision
5b2a614:e5a02c3:beea0800baadbe98febe5a4e54112d76ea10a9d3] (GCC)
COLLECT_GCC_OPTIONS='--version' '-v' '-mtls-dialect=gnu'
/home/sh/install/libexec/gcc/arm-linux-gnueabihf/7.0.0/cc1 -quiet -v
help-dummy -quiet -dumpbase help-dummy -mtls-dialect=gnu -auxbase help-dummy
-version --version -o /tmp/ccDBeQFm.s
GNU C11 (GCC) version 7.0.0 20161208 (experimental) [trunk revision
5b2a614:e5a02c3:beea0800baadbe98febe5a4e54112d76ea10a9d3] (arm-linux-gnueabihf)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='--version' '-v' '-mtls-dialect=gnu'
as -v -meabi=5 --version -o /tmp/cc6waYtC.o /tmp/ccDBeQFm.s
GNU assembler version 2.24 (aarch64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.24
Assembler messages:
Error: unrecognized option -meabi=5
I get:
./install/bin/arm-linux-gnueabihf-gcc -S task.i -mthumb -O2
-ftls-model=local-exec
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c: In function
‘gomp_create_target_task’:
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: error: invalid rtl
sharing found in the insn
(insn 1569 1568 1570 (unspec_volatile [
(const:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags 0xea] )
(const_int 4 [0x4])
] UNSPEC_TLS))
] VUNSPEC_POOL_4) -1
(nil))
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: error: shared rtx
(const:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags 0xea] )
(const_int 4 [0x4])
] UNSPEC_TLS))
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: internal compiler
error: internal consistency failure
0x7beabf verify_rtx_sharing
../../gcc/gcc/emit-rtl.c:2752
0x7bea1b verify_rtx_sharing
../../gcc/gcc/emit-rtl.c:2785
0x7bef07 verify_insn_sharing
../../gcc/gcc/emit-rtl.c:2838
0x7c3cfb verify_rtl_sharing()
../../gcc/gcc/emit-rtl.c:2861
0xa56e2f execute_function_todo
../../gcc/gcc/passes.c:1982
0xa5770f do_per_function
../../gcc/gcc/passes.c:1649
0xa578c7 execute_todo
../../gcc/gcc/passes.c:2015
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.
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694 --- Comment #7 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- Are you able to reproduce the problem with this information? You need the attached test case. The arm-eabi GCC build itself works.
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694 --- Comment #6 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to ktkachov from comment #5) > I cannot reproduce with that revision. > Again, how do you configure your gcc. > What is the output of arm-eabi-gcc -v that you built? arm-eabi-gcc -v Using built-in specs. COLLECT_GCC=arm-eabi-gcc COLLECT_LTO_WRAPPER=/scratch/install-arm-eabi/lib/gcc/arm-eabi/7.0.0/lto-wrapper Target: arm-eabi Configured with: /home/EB/sebastian_h/archive/gcc-git/configure --prefix=/scratch/install-arm-eabi --target=arm-eabi --verbose --enable-languages=c --disable-multilib Thread model: single gcc version 7.0.0 20161206 (experimental) [master revision c59a180:88a522b:8c1527e8f37c8e80912aa3a465d623381aaa41e0] (GCC)
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(In reply to ktkachov from comment #3)
> I can't reproduce on an arm-none-eabi compiler built with RTL checking. Do
> you pass any particular --with-arch/cpu/fpu/float options?
I built an arm-eabi-gcc using GCC version
1e15f9a7488be0a7446c364b93430d20621af476.
I get:
arm-eabi-gcc -mthumb -ftls-model=local-exec -O2 -S task.i
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c: In function
‘gomp_create_target_task’:
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: error: invalid rtl
sharing found in the insn
}
^
(insn 1584 1583 1585 (unspec_volatile [
(const:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags 0xea] )
(const_int 4 [0x4])
] UNSPEC_TLS))
] VUNSPEC_POOL_4) -1
(nil))
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: error: shared rtx
(const:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags 0xea] )
(const_int 4 [0x4])
] UNSPEC_TLS))
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: internal compiler
error: internal consistency failure
0x80f8dd verify_rtx_sharing
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2751
0x80f86a verify_rtx_sharing
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2784
0x80fc3b verify_insn_sharing
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2837
0x814317 verify_rtl_sharing()
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2860
0xaa2deb execute_function_todo
/home/EB/sebastian_h/archive/gcc-git/gcc/passes.c:1982
0xaa37e5 execute_todo
/home/EB/sebastian_h/archive/gcc-git/gcc/passes.c:2015
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.
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694 --- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to ktkachov from comment #1) > what is the configuration you're trying to build? A bare metal ARM EABI compiler should reproduce the problem. I try to build the arm-rtems4.12-gcc with a patch to enable use of thread-local storage. See also: https://gcc.gnu.org/ml/gcc/2016-12/msg00010.html
[Bug target/78694] New: [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
Bug ID: 78694
Summary: [ARM] ICE with -mthumb -ftls-model=local-exec -O2
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Created attachment 40264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40264=edit
Test case
The attached test case generates an ICE during GCC build (libgomp):
/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc
-B/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -mthumb
-ftls-model=local-exec -O2 -S task.i
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c: In function
'gomp_create_target_task':
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: error: invalid rtl
sharing found in the insn
}
^
(insn 1584 1583 1585 (unspec_volatile [
(const:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags 0xea] )
(const_int 4 [0x4])
] UNSPEC_TLS))
] VUNSPEC_POOL_4) -1
(nil))
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: error: shared rtx
(const:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags 0xea] )
(const_int 4 [0x4])
] UNSPEC_TLS))
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: internal compiler
error: internal consistency failure
0x6852ed verify_rtx_sharing
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2751
0x68527a verify_rtx_sharing
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2784
0x68564b verify_insn_sharing
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2837
0x689d27 verify_rtl_sharing()
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2860
0x91872b execute_function_todo
/home/EB/sebastian_h/archive/gcc-git/gcc/passes.c:1982
0x919105 execute_todo
/home/EB/sebastian_h/archive/gcc-git/gcc/passes.c:2015
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.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #11 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- Thanks for your kind help. Would it be possible to back port this to GCC 6 also?
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
--- Comment #8 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
(In reply to Chung-Lin Tang from comment #7)
> (In reply to Sebastian Huber from comment #6)
> > (In reply to Chung-Lin Tang from comment #5)
> > > > I checked the code generation on some targets for the test case above.
> > > > The
> > > > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets
> > > > generated all __atomic_* functions.
> > >
> > > > Only on Nios II it seems, the other targets emit __atomic_* calls.
> > >
> > > Many of those target archs use __sync_* by default on Linux, although you
> > > might generate __atomic_* on bare metal.
> > > That's the case on nios2; we should be generating __atomic_* calls if
> > > you're
> > > using nios2 ELF (bare metal), for Linux the compiler will generate
> > > __sync_*
> > > calls, unless the architecture has hardware instructions.
> >
> > This sounds reasonable. Which magic switch in GCC leads to the generation
> > of __sync_* functions instead of __atomic_* functions?
>
> You can use -fno-sync-libcalls to force OFF __sync_* and generate __atomic_*
> calls,
> if that's really what you want (although we have not implemented that kind
> of runtime support).
Ok, thanks for the hint. Now I know where the problem is really. In
"gcc/config/rtems.h" we define TARGET_LINUX_ABI to enable the TLS support for
RTEMS. This is due to (nios2.c):
#undef TARGET_HAVE_TLS
#define TARGET_HAVE_TLS TARGET_LINUX_ABI
We also have:
/* Implement TARGET_INIT_LIBFUNCS. */
static void
nios2_init_libfuncs (void)
{
/* For Linux, we have access to kernel support for atomic operations. */
if (TARGET_LINUX_ABI)
init_sync_libfuncs (UNITS_PER_WORD);
}
Would it be possible to add an alternative way to enable TLS support for RTEMS?
For example:
#ifndef TARGET_HAVE_TLS
#define TARGET_HAVE_TLS TARGET_LINUX_ABI
#endif
Then use in rtems.h:
#define TARGET_HAVE_TLS 1
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #6 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Chung-Lin Tang from comment #5) > > I checked the code generation on some targets for the test case above. The > > arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets > > generated all __atomic_* functions. > > > Only on Nios II it seems, the other targets emit __atomic_* calls. > > Many of those target archs use __sync_* by default on Linux, although you > might generate __atomic_* on bare metal. > That's the case on nios2; we should be generating __atomic_* calls if you're > using nios2 ELF (bare metal), for Linux the compiler will generate __sync_* > calls, unless the architecture has hardware instructions. This sounds reasonable. Which magic switch in GCC leads to the generation of __sync_* functions instead of __atomic_* functions? > > > > > > > > > > > libatomic is usually supported by those targets with more "rich" > > > > > atomic > > > > > instructions, and nios2 in its current form is obviously not one of > > > > > them. > > > > > > > > The libatomic is for architectures which lack atomic instructions. > > > > > > To clarify/correct my above statement, we do build libatomic like other > > > targets, but the basic __atomic_* functions used inside it is also > > > generated > > > as __sync_* calls. > > > > > > libatomic does NOT directly "implement" the basic __atomic_* operations, > > > that's supposed to be done inside the compiler. > > > > > > Can you more specifically describe what you're trying to do? Or is this > > > just > > > a general query? > > > > I don't find any Nios II specific parts in libatomic. > > > > Implementing __atomic_* functions via __sync_* in libatomic makes no sense > > to me. The host specific implementation should provide (libatomic_i.h): > > Most architectures don't have library implementations of __atomic_* > operations, especially if we already have __sync_*. The major difference is > the consistency model arguments in __atomic_* APIs, which is useless for > simpler architectures like nios2. The __sync_* stuff is deprecated.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Chung-Lin Tang from comment #3) > (In reply to Sebastian Huber from comment #2) > > (In reply to Chung-Lin Tang from comment #1) > > > Sebastian, I'm not sure what your problem is. The atomics in nios2 are > > > implemented by __sync_* functions placed in libgcc. The built-in function > > > expansion inside GCC is aware of this, and __atomic_* functions get mapped > > > to those. Is there anything affecting your use? > > > > I think this mapping of __atomic_* functions to __sync_* functions is > > wrong/outdated. Is this a speciality of the Nios II support? I am not > > aware of a second target support in GCC which does this. The __sync_* > > builtins are a legacy API: > > > > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins. > > html#g_t_005f_005fsync-Builtins > > Nios II is not the only target which implements __sync_*, see the libgcc > source code for details. The libgcc is not relevant for code generation as far as I know. I checked the code generation on some targets for the test case above. The arm, bfin, epiphany, i386, lm32, m68k, mips, moxie, sh, v850 targets generated all __atomic_* functions. > > In the current GCC code expansion paths, the __atomic_* functions are meant > to expand to hardware instruction sequences. In cases where we need to > generate library calls for atomics, GCC only generates __sync_* calls. Only on Nios II it seems, the other targets emit __atomic_* calls. > > > > > > > libatomic is usually supported by those targets with more "rich" atomic > > > instructions, and nios2 in its current form is obviously not one of them. > > > > The libatomic is for architectures which lack atomic instructions. > > To clarify/correct my above statement, we do build libatomic like other > targets, but the basic __atomic_* functions used inside it is also generated > as __sync_* calls. > > libatomic does NOT directly "implement" the basic __atomic_* operations, > that's supposed to be done inside the compiler. > > Can you more specifically describe what you're trying to do? Or is this just > a general query? I don't find any Nios II specific parts in libatomic. Implementing __atomic_* functions via __sync_* in libatomic makes no sense to me. The host specific implementation should provide (libatomic_i.h): /* Locking for a "small" operation. In the bare-metal single processor cases this could be implemented by disabling interrupts. Thus the extra word passed between the two functions, saving the interrupt level. It is assumed that the object being locked does not cross the locking granularity. Not actually declared here so that they can be defined static inline in a target-specfic . UWORD protect_start (void *ptr); void protect_end (void *ptr, UWORD); */ /* Locking for a "large' operation. This should always be some sort of test-and-set operation, as we assume that the interrupt latency would be unreasonably large. */ void libat_lock_n (void *ptr, size_t n); void libat_unlock_n (void *ptr, size_t n);
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Chung-Lin Tang from comment #1) > Sebastian, I'm not sure what your problem is. The atomics in nios2 are > implemented by __sync_* functions placed in libgcc. The built-in function > expansion inside GCC is aware of this, and __atomic_* functions get mapped > to those. Is there anything affecting your use? I think this mapping of __atomic_* functions to __sync_* functions is wrong/outdated. Is this a speciality of the Nios II support? I am not aware of a second target support in GCC which does this. The __sync_* builtins are a legacy API: https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#g_t_005f_005fsync-Builtins > > libatomic is usually supported by those targets with more "rich" atomic > instructions, and nios2 in its current form is obviously not one of them. The libatomic is for architectures which lack atomic instructions.
[Bug target/78357] New: nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357
Bug ID: 78357
Summary: nios2 uses non-standard atomic functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Some Nios II variants lack support for atomic operations in hardware. The GCC
Nios II support generates in this case non-standard __sync_* function calls,
e.g.
#include
_Bool cas(atomic_uint *a, unsigned int *e, unsigned int d)
{
return atomic_compare_exchange_strong_explicit(a, e, d,
memory_order_relaxed, memory_order_relaxed);
}
unsigned int add(atomic_uint *a, unsigned int v)
{
return atomic_fetch_add_explicit(a, v, memory_order_relaxed);
}
.file "atomic.c"
.global __sync_val_compare_and_swap_4
.section.text
.align 2
.global cas
.type cas, @function
cas:
addisp, sp, -12
stw r17, 4(sp)
stw ra, 8(sp)
stw r16, 0(sp)
ldw r16, 0(r5)
mov r17, r5
mov r5, r16
call__sync_val_compare_and_swap_4
cmpeq r16, r2, r16
bne r16, zero, .L2
stw r2, 0(r17)
.L2:
mov r2, r16
ldw ra, 8(sp)
ldw r17, 4(sp)
ldw r16, 0(sp)
addisp, sp, 12
ret
.size cas, .-cas
.global __sync_fetch_and_add_4
.align 2
.global add
.type add, @function
add:
addisp, sp, -4
stw ra, 0(sp)
call__sync_fetch_and_add_4
ldw ra, 0(sp)
addisp, sp, 4
ret
.size add, .-add
Thus, this target is not covered by libatomic. There are at least two options
to fix this problem:
1. Change the Nios II support to emit standard __atomic_* function calls:
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
2. Add the __sync_* functions to libatomic.
[Bug target/78199] [PowerPC] Missing optimization for local-exec TLS model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78199 --- Comment #1 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- A native 64-bit PowerPC GCC built on uname -a Linux gcc2-power8.osuosl.org 3.17.4-301.fc21.ppc64le #1 SMP Mon Dec 1 07:51:01 UTC 2014 ppc64le ppc64le ppc64le GNU/Linux generates this gcc -O2 -ftls-model=local-exec -S tls.c -o - .file "tls.c" .machine power8 .abiversion 2 .section".text" .align 2 .p2align 4,,15 .globl fi .type fi, @function fi: addis 9,13,i@tprel@ha addi 9,9,i@tprel@l lwa 3,0(9) blr .long 0 .byte 0,0,0,0,0,0,0,0 .size fi,.-fi .section".toc","aw" .align 3 .LC0: .quad s .section".text" .align 2 .p2align 4,,15 .globl fs .type fs, @function fs: .LCF1: 0: addis 2,12,.TOC.-.LCF1@ha addi 2,2,.TOC.-.LCF1@l .localentry fs,.-fs addis 9,2,.LC0@toc@ha # gpr load fusion, type long ld 9,.LC0@toc@l(9) lwa 3,0(9) blr .long 0 .byte 0,0,0,0,0,0,0,0 .size fs,.-fs .ident "GCC: (GNU) 7.0.0 20161030 (experimental)" .section.note.GNU-stack,"",@progbits
[Bug target/78199] New: [PowerPC] Missing optimization for local-exec TLS model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78199
Bug ID: 78199
Summary: [PowerPC] Missing optimization for local-exec TLS
model
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The following test case:
extern __thread int i;
extern int s;
int fi(void)
{
return i;
}
int fs(void)
{
return s;
}
generates:
powerpc-rtems4.12-gcc -O2 -S -ftls-model=local-exec tls.c -o -
.file "tls.c"
.machine ppc
.section".text"
.align 2
.globl fi
.type fi, @function
fi:
addis 9,2,i@tprel@ha
addi 9,9,i@tprel@l
lwz 3,0(9)
blr
.size fi, .-fi
.align 2
.globl fs
.type fs, @function
fs:
lis 9,s@ha
lwz 3,s@l(9)
blr
.size fs, .-fs
.ident "GCC: (GNU) 7.0.0 20161103 (experimental) [master revision
bad2001:22427cc:8c7ce92980721624d9f2ac6332fe34188d09b851]"
This can be optimized to:
fi:
lis 9,2,i@tprel@ha
lwz 9,i@tprel@l(2)
blr
This issue seems to be target specific, for example:
gcc -O2 -S -ftls-model=local-exec tls.c -o -
.file "tls.c"
.text
.p2align 4,,15
.globl fi
.type fi, @function
fi:
.LFB0:
.cfi_startproc
movl%fs:i@tpoff, %eax
ret
.cfi_endproc
.LFE0:
.size fi, .-fi
.p2align 4,,15
.globl fs
.type fs, @function
fs:
.LFB1:
.cfi_startproc
movls(%rip), %eax
ret
.cfi_endproc
.LFE1:
.size fs, .-fs
.ident "GCC: (GNU) 7.0.0 20161103 (experimental) [master revision
bad2001:22427cc:8c7ce92980721624d9f2ac6332fe34188d09b851]"
.section.note.GNU-stack,"",@progbits
However:
gcc -O2 -S -ftls-model=local-exec tls.c -o -
.file "tls.c"
.text
.p2align 4,,15
.globl fi
.type fi, @function
fi:
.LFB0:
.cfi_startproc
movq%fs:0, %rax
movli@tpoff(%rax), %eax
ret
.cfi_endproc
.LFE0:
.size fi, .-fi
.p2align 4,,15
.globl fs
.type fs, @function
fs:
.LFB1:
.cfi_startproc
movls(%rip), %eax
ret
.cfi_endproc
.LFE1:
.size fs, .-fs
.ident "GCC: (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision
202388]"
.section.note.GNU-stack,"",@progbits
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 Sebastian Huber <sebastian.hu...@embedded-brains.de> changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- Thanks, looks good to me.
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 --- Comment #11 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Segher Boessenkool from comment #10) > Doesn't fail with powerpc-rtems4.12 either. Are you sure you built trunk? > A clean build? I tested again today using: commit 89bcfdabe78607bf83aa58e3d2696a2c71e719e5 Author: tbsaunde <tbsaunde@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Wed Nov 2 03:46:17 2016 + remove cast from prev_nonnote_insn_bb gcc/ChangeLog: 2016-11-01 Trevor Saunders <tbsaunde+...@tbsaunde.org> * emit-rtl.c (prev_nonnote_insn_bb): Change argument type to rtx_insn *. * rtl.h (prev_nonnote_insn_bb): Adjust prototype. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241773 138bc75d-0d04-0410-961f-82ee72b054a4 I still get the ICE. The following flags seem to be essential (e.g. no ICE with -mno-spe): -O2 -mcpu=8540 -mspe -mabi=spe -g
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 --- Comment #8 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- On RTEMS I think -mspe is enabled for -mcpu=8540.
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 --- Comment #7 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- A git bisect indicates this as the bad commit: commit 14fdd09f470dea253089d6a5b27d7a2c3ab7d67a Author: segher <segher@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Wed Oct 12 15:34:39 2016 + rs6000: Separate shrink-wrapping This implements the hooks for separate shrink-wrapping for rs6000. It handles GPRs and LR. The GPRs get a component number corresponding to their register number; LR gets component number 0. * config/rs6000/rs6000.c (machine_function): Add new fields gpr_is_wrapped_separately and lr_is_wrapped_separately. (TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS, TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB, TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS, TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS, TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS, TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Define. (rs6000_get_separate_components): New function. (rs6000_components_for_bb): New function. (rs6000_disqualify_components): New function. (rs6000_emit_prologue_components): New function. (rs6000_emit_epilogue_components): New function. (rs6000_set_handled_components): New function. (rs6000_emit_prologue): Don't emit LR save if lr_is_wrapped_separately. Don't emit GPR saves if gpr_is_wrapped_separately for that register. (restore_saved_lr): Don't restore LR if lr_is_wrapped_separately. (rs6000_emit_epilogue): Don't emit GPR restores if gpr_is_wrapped_separately for that register. Don't make a REG_CFA_RESTORE note for registers we did not restore, either. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241065 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 93015f5b1887799cdee7723b46455953bf087911 61a2a5a9e1f078a49af4930e0f62f5269f18ad86 M gcc
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 --- Comment #3 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- My configure command line: configure --target=powerpc-rtems4.12 --verbose --with-newlib --disable-libstdcxx-pch --disable-nls --disable-lto --disable-plugin --enable-languages=c Should also work with a bare-metal 32-bit ELF powerpc GCC.
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 --- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Andrew Pinski from comment #1) > Most likely a dup of bug 78029. I am not sure. I get the ICE with the latest GCC which includes the fix for bug 78029.
[Bug target/78168] New: [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 Bug ID: 78168 Summary: [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- Created attachment 39926 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39926=edit Test case /build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -c fp-bit.i -O2 -mcpu=8540 -g /home/EB/sebastian_h/archive/gcc-git/libgcc/fp-bit.c: In function '_fpadd_parts': /home/EB/sebastian_h/archive/gcc-git/libgcc/fp-bit.c:718:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2285 } ^ 0x62f646 maybe_record_trace_start /home/EB/sebastian_h/archive/gcc-git/gcc/dwarf2cfi.c:2285 0x62f9cf create_trace_edges /home/EB/sebastian_h/archive/gcc-git/gcc/dwarf2cfi.c:2379 0x62fb4a scan_trace /home/EB/sebastian_h/archive/gcc-git/gcc/dwarf2cfi.c:2593 0x63075e create_cfi_notes /home/EB/sebastian_h/archive/gcc-git/gcc/dwarf2cfi.c:2619 0x63075e execute_dwarf2_frame /home/EB/sebastian_h/archive/gcc-git/gcc/dwarf2cfi.c:2977 0x63075e execute /home/EB/sebastian_h/archive/gcc-git/gcc/dwarf2cfi.c:3457 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.
[Bug rtl-optimization/78029] [7 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78029 Sebastian Huber <sebastian.hu...@embedded-brains.de> changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #7 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- I get the ICE while building a libgcc variant: /build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/xgcc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/./gcc/ -nostdinc -B/build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/ -isystem /build/git-build/b-gcc-git-powerpc-rtems4.12/powerpc-rtems4.12/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.12/powerpc-rtems4.12/bin/ -B/opt/rtems-4.12/powerpc-rtems4.12/lib/ -isystem /opt/rtems-4.12/powerpc-rtems4.12/include -isystem /opt/rtems-4.12/powerpc-rtems4.12/sys-include-g -O2 -mcpu=8540 -O2 -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/. -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../include -DHAVE_CC_TLS -o _addsub_df.o -MT _addsub_df.o -MD -MP -MF _addsub_df.dep -DFINE_GRAINED_LIBRARIES -DL_addsub_df -c /home/EB/sebastian_h/archive/gcc-git/libgcc/fp-bit.c -fvisibility=hidden -DHIDE_EXPORTS
[Bug tree-optimization/71957] [5/6/7 Regression] Invalid code generation with function static objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71957 Sebastian Huber <sebastian.hu...@embedded-brains.de> changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Sebastian Huber from comment #4) > (In reply to Richard Biener from comment #3) > > On a second look the testcase looks invalid as it invokes a virtual function > > via C on an object of type C. Why do you think doing this is valid? > > I try to generate a new test case without the reinterpret cast. Sorry, you are right, this is undefined behaviour. Without the reinterpret casts it is not reproducible. I reduced the test case from a larger code base via the delta tool. This code worked for years well. Using the -fsanitize=unreachable option would have saved some trouble.
[Bug tree-optimization/71957] [5/6/7 Regression] Invalid code generation with function static objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71957 --- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Richard Biener from comment #3) > On a second look the testcase looks invalid as it invokes a virtual function > via C on an object of type C. Why do you think doing this is valid? I try to generate a new test case without the reinterpret cast.
[Bug c++/71957] New: Invalid code generation with function static objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71957
Bug ID: 71957
Summary: Invalid code generation with function static objects
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The following test case produces wrong code with GCC 6. The problem is at least
visible on x86, ARM, SPARC and PowerPC.
class A {
public:
A(int);
};
template class B {
public:
virtual void* h(int) = 0;
};
template class C : public B {
public:
explicit C(int);
void* h(int);
};
C& g(void);
class D : public A {
static void* f(int);
};
void* D::f(int k) {
B& j = (reinterpret_cast<C&>(g()));
return j.h(k);
}
int f(void);
C& g(void) {
static C i(f());
return i;
}
g++ -Wfatal-errors -Wall -Wextra -S -O3 -fno-exceptions test.cc -o-
.file "test.cc"
.text
.align 2
.p2align 4,,15
.globl _ZN1D1fEi
.type _ZN1D1fEi, @function
_ZN1D1fEi:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$_ZGVZ1gvE1i, %edi
movzbl _ZGVZ1gvE1i(%rip), %eax
call__cxa_guard_acquire
<-- ERROR: It must check the return value of __cxa_guard_acquire()
call_Z1fv
movl$_ZZ1gvE1i, %edi
movl%eax, %esi
call_ZN1CI1AEC1Ei
movl$_ZGVZ1gvE1i, %edi
call__cxa_guard_release
<-- ERROR Invalid function return
.cfi_endproc
.LFE0:
.size _ZN1D1fEi, .-_ZN1D1fEi
.p2align 4,,15
.globl _Z1gv
.type _Z1gv, @function
_Z1gv:
.LFB1:
.cfi_startproc
movzbl _ZGVZ1gvE1i(%rip), %eax
testb %al, %al
je .L15
movl$_ZZ1gvE1i, %eax
ret
.p2align 4,,10
.p2align 3
.L15:
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$_ZGVZ1gvE1i, %edi
call__cxa_guard_acquire
testl %eax, %eax
je .L5
call_Z1fv
movl$_ZZ1gvE1i, %edi
movl%eax, %esi
call_ZN1CI1AEC1Ei
movl$_ZGVZ1gvE1i, %edi
call__cxa_guard_release
.L5:
movl$_ZZ1gvE1i, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size _Z1gv, .-_Z1gv
.local _ZGVZ1gvE1i
.comm _ZGVZ1gvE1i,8,8
.local _ZZ1gvE1i
.comm _ZZ1gvE1i,8,8
.ident "GCC: (GNU) 6.1.1 20160705 [gcc-6-branch revision
fcd04db:3fed107:ebf5486fa49b6660091b549d17e945f63e698eac]"
.section.note.GNU-stack,"",@progbits
[Bug tree-optimization/69196] [5/6/7 Regression] code size regression with jump threading at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196 --- Comment #25 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- With GCC 6.1 there is now only a slight increase in code size compared to GCC 4.9. I am not sure if there is anything left to do on this PR. sparc-rtems4.11-gcc --version sparc-rtems4.11-gcc (GCC) 4.9.4 20150723 (prerelease) [master revision 022fc2d:bffd767:fd457cef14f3bc6673e90a2de80005feea743ab7] Copyright (C) 2015 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. sparc-rtems4.12-gcc --version sparc-rtems4.12-gcc (GCC) 6.1.1 20160502 [gcc-6-branch revision cf53985:351726f:7429c1e9312a17e16f7d5be217ca79b82e56d01b] Copyright (C) 2016 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. sparc-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i sparc-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i size vprintk.4.11.o textdata bss dec hex filename 688 0 0 688 2b0 vprintk.4.11.o size vprintk.4.12.o textdata bss dec hex filename 785 0 0 785 311 vprintk.4.12.o powerpc-rtems4.11-gcc --version powerpc-rtems4.11-gcc (GCC) 4.9.4 20150723 (prerelease) [master revision 022fc2d:bffd767:fd457cef14f3bc6673e90a2de80005feea743ab7] Copyright (C) 2015 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. powerpc-rtems4.12-gcc --version powerpc-rtems4.12-gcc (GCC) 6.1.1 20160502 [gcc-6-branch revision cf53985:351726f:7429c1e9312a17e16f7d5be217ca79b82e56d01b] Copyright (C) 2016 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. powerpc-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i powerpc-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i size vprintk.4.11.o textdata bss dec hex filename 797 0 0 797 31d vprintk.4.11.o size vprintk.4.12.o textdata bss dec hex filename 1005 0 01005 3ed vprintk.4.12.o arm-rtems4.11-gcc --version arm-rtems4.11-gcc (GCC) 4.9.4 20150723 (prerelease) [master revision 022fc2d:bffd767:fd457cef14f3bc6673e90a2de80005feea743ab7] Copyright (C) 2015 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. arm-rtems4.12-gcc --version arm-rtems4.12-gcc (GCC) 6.1.1 20160502 [gcc-6-branch revision cf53985:351726f:7429c1e9312a17e16f7d5be217ca79b82e56d01b] Copyright (C) 2016 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. arm-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i arm-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i size vprintk.4.11.o textdata bss dec hex filename 512 0 0 512 200 vprintk.4.11.o size vprintk.4.12.o textdata bss dec hex filename 641 0 0 641 281 vprintk.4.12.o
[Bug target/69617] PowerPC/e6500: Atomic byte/halfword operations not properly supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69617 --- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- Yes, sorry, I meant the load with reservation and store conditional instructions.
[Bug target/69617] New: PowerPC/e6500: Atomic byte/halfword operations not properly supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69617
Bug ID: 69617
Summary: PowerPC/e6500: Atomic byte/halfword operations not
properly supported
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The PowerPC/e6500 support lacks support for the load/store byte/halfword with
decoration indexed instructions:
#include
unsigned char inc_uchar(atomic_uchar *a)
{
return atomic_fetch_add(a, 1);
}
unsigned short inc_ushort(atomic_ushort *a)
{
return atomic_fetch_add(a, 1);
}
powerpc-rtems4.12-gcc -O2 -Wall -Wextra -pedantic -mcpu=e6500 -m32 -S atomic.c
cat atomic.s
.file "atomic.c"
.machine power4
.section".text"
.align 2
.p2align 4,,15
.globl inc_uchar
.type inc_uchar, @function
inc_uchar:
rlwinm 8,3,3,27,28
li 7,255
xori 8,8,0x18
li 6,1
sync
slw 7,7,8
slw 6,6,8
rlwinm 9,3,0,0,29
.L2:
lwarx 3,0,9
add 5,3,6
andc 10,3,7
and 5,5,7
or 10,10,5
stwcx. 10,0,9
bne- 0,.L2
isync
srw 3,3,8
rlwinm 3,3,0,0xff
blr
.size inc_uchar, .-inc_uchar
.align 2
.p2align 4,,15
.globl inc_ushort
.type inc_ushort, @function
inc_ushort:
rlwinm 8,3,3,27,27
li 7,0
xori 8,8,0x10
ori 7,7,0x
li 6,1
sync
slw 7,7,8
slw 6,6,8
rlwinm 9,3,0,0,29
.L6:
lwarx 3,0,9
add 5,3,6
andc 10,3,7
and 5,5,7
or 10,10,5
stwcx. 10,0,9
bne- 0,.L6
isync
srw 3,3,8
rlwinm 3,3,0,0x
blr
.size inc_ushort, .-inc_ushort
.ident "GCC: (GNU) 6.0.0 20160202 (experimental)
[Bug target/69618] New: PowerPC/e6500: Atomic fence operations not properly supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69618
Bug ID: 69618
Summary: PowerPC/e6500: Atomic fence operations not properly
supported
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
On the PowerPC/e6500 elemental synchronization operations should be used for
acquire/release barriers. Currently a lwsync is used instead:
#include
void release(void)
{
atomic_thread_fence(memory_order_release);
}
void acquire(void)
{
atomic_thread_fence(memory_order_acquire);
}
powerpc-rtems4.12-gcc -O2 -Wall -Wextra -pedantic -mcpu=e6500 -m32 -S fence.c
cat fence.s
.file "fence.c"
.machine power4
.section".text"
.align 2
.p2align 4,,15
.globl release
.type release, @function
release:
lwsync
blr
.size release, .-release
.align 2
.p2align 4,,15
.globl acquire
.type acquire, @function
acquire:
lwsync
blr
.size acquire, .-acquire
.ident "GCC: (GNU) 6.0.0 20160202 (experimental)
See also e6500 Core Reference Manual, 5.5.5.2.1 (Simplified memory barrier
recommendations) and EREF: A Programmer’s Reference Manual for Freescale Power
Architecture Processors (06/2014), 7.4.8.3 (Forcing Load and Store Ordering
(Memory Barriers)).
For acquire semantic a "ESYNC 12" instruction should be used (Load-Load- and
Load-Store-Barriere) and for release semantic a "ESYNC 5" instruction
(Store-Store- and Load-Store-Barrier). See also Memory Model Rationales,
section "Why ordering constraints are never limited to loads or stores"
(www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2176.html).
The e6500 core honours in contrast to the general PowerPC architecture a
Load-Store-Ordering (EREF, 7.4.8.2 (Architecture Ordering Requirements), number
4), so maybe for acquire semantic "ESYNC 8" instruction (Load-Load-Barrier) and
for release semantic a "ESYNC 1" instruction is sufficient
(Store-Store-Barrier). See EREF, 7.4.8.4 (Architectural Memory Access
Ordering), 7.4.8.6.1 (Acquire Lock and Import Shared Memory) and 7.4.8.7.1
(Export Shared Memory and Release Lock).
[Bug tree-optimization/69196] [5/6 Regression] code size regression with jump threading at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196 --- Comment #12 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- New numbers for SPARC and PowerPC (rtems4.12-gcc 6.0.0 20160127): sparc-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i sparc-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i size vprintk.4.11.o textdata bss dec hex filename 688 0 0 688 2b0 vprintk.4.11.o size vprintk.4.12.o textdata bss dec hex filename 1252 0 01252 4e4 vprintk.4.12.o powerpc-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i powerpc-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i size vprintk.4.11.o textdata bss dec hex filename 797 0 0 797 31d vprintk.4.11.o size vprintk.4.12.o textdata bss dec hex filename 1005 0 01005 3ed vprintk.4.12.o
[Bug debug/65779] [5 Regression] undefined local symbol on powerpc [regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779 Sebastian Huber <sebastian.hu...@embedded-brains.de> changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #18 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Jakub Jelinek from comment #17) > Fixed on the trunk so far. I can confirm that the originally reported problem is fixed by this change. Works with 6.0.0 20160124, fails with 6.0.0 20160117.
[Bug target/69027] implement indirect tail calls on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69027 --- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- I have an admittedly quite exotic use case where it hurts. I changed a switch statement to adaptor functions in RTEMS to avoid dead code, e.g. https://git.rtems.org/rtems/diff/cpukit/score/src/threadhandler.c?id=ccd54344d904b657123e4e4ba795a32212382be2 The _Thread_Handler() function in RTEMS calls the thread entry function. Since threads normally don't return every space used on the stack in this area is lost. Due to the change from the switch to a function call we waste now 96 bytes of space grade RAM for each thread.
[Bug tree-optimization/69196] code size regression with jump threading at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> ---
I did a very rough check to see which code is faster on the PSIM/GDB simulator
using the following input data:
void printk(const char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
vprintk(fmt, ap);
va_end(ap);
}
void test(void)
{
char *s = "x";
printk("abc%sx%ix%cx%lu\n", s, 0, 'c', 1UL);
}
GCC 4.9: 311 time units
GCC 6: 316 time units
I guess its quite difficult to determine if this target independent code size
increase is actually a regression in general. At least in this particular
function with this particular input data on this particular target/simulator
the code size is nearly doubled and the execution is slightly slower.
[Bug target/69196] Code size regression on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196 --- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- Ok, with -Os I don't have the problem: sparc-rtems4.11-gcc -c -Os -o vprintk.4.11.o vprintk.i sparc-rtems4.12-gcc -c -Os -o vprintk.4.12.o vprintk.i size vprintk.4.11.o textdata bss dec hex filename 612 0 0 612 264 vprintk.4.11.o size vprintk.4.12.o textdata bss dec hex filename 608 0 0 608 260 vprintk.4.12.o It seems that this is not SPARC specific. I get it also on PowerPC: powerpc-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i powerpc-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i size vprintk.4.11.o textdata bss dec hex filename 797 0 0 797 31d vprintk.4.11.o size vprintk.4.12.o textdata bss dec hex filename 1385 0 01385 569 vprintk.4.12.o I am not sure if this is an improvement.
[Bug target/69196] New: Code size regression on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196 Bug ID: 69196 Summary: Code size regression on SPARC Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- Created attachment 37274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37274=edit Test case. This is quite an increase of the code size for the attached test case. sparc-rtems4.11-gcc (GCC) 4.9.4 20150723 (prerelease) sparc-rtems4.12-gcc (GCC) 6.0.0 20160108 (experimental) sparc-rtems4.11-gcc -c -O2 -o vprintk.4.11.o vprintk.i sparc-rtems4.12-gcc -c -O2 -o vprintk.4.12.o vprintk.i size vprintk.4.11.o textdata bss dec hex filename 688 0 0 688 2b0 vprintk.4.11.o size vprintk.4.12.o textdata bss dec hex filename 1272 0 01272 4f8 vprintk.4.12.o I noticed a size increase for various files, but this one was quite drastic.
[Bug target/69027] New: SPARC: Missing optimization for fall through functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69027
Bug ID: 69027
Summary: SPARC: Missing optimization for fall through functions
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Consider the following test case:
int i(void);
int f(void)
{
return i();
}
int g(int (*j)(void))
{
return (*j)();
}
GCC generates on SPARC something like this:
sparc-rtems4.12-gcc -O2 -S fallthrough.c && cat fallthrough.s
.file "fallthrough.c"
.section".text"
.align 4
.global f
.type f, #function
.proc 04
f:
or %o7, %g0, %g1
calli, 0
or %g1, %g0, %o7
.size f, .-f
.align 4
.global g
.type g, #function
.proc 04
g:
save%sp, -96, %sp
call%i0, 0
nop
jmp %i7+8
restore %g0, %o0, %o0
.size g, .-g
.ident "GCC: (GNU) 6.0.0 20151221 (experimental)
For g() an superfluous stack frame is generated.
On PowerPC for example this is optimized to:
.file "fallthrough.c"
.machine ppc
.section".text"
.align 2
.globl f
.type f, @function
f:
b i
.size f, .-f
.align 2
.globl g
.type g, @function
g:
mtctr 3
bctr
.size g, .-g
.ident "GCC: (GNU) 6.0.0 20151126 (experimental)
[Bug rtl-optimization/68910] [5/6 regression] huge stack frame and poor code with instruction scheduling at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910 --- Comment #14 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Eric Botcazou from comment #13) > Thanks for reporting the problem. Thanks for the quick fix. The stack frame is still larger than necessary at least on the -mcpu=cypress and -mcpu=leon3 targets. However, the range is similar to GCC 4.3.2, so this looks like an old problem. sparc-rtems4.12-gcc -S -O2 sha512c.i -mcpu=leon3 .file "sha512c.i" .section".text" .align 4 .global SHA512_Transform .type SHA512_Transform, #function .proc 020 SHA512_Transform: save%sp, -2760, %sp mov 128, %o2 mov %i1, %o1 add %fp, -640, %o0 callmemcpy, 0 st %i0, [%fp+68] add %fp, -640, %g4 add %fp, -128, %o4 ld [%g4+116], %i1 .LL8: [...] bne .LL7 add%fp, -704, %o3 jmp %i7+8 restore .size SHA512_Transform, .-SHA512_Transform .ident "GCC: (GNU) 6.0.0 20151221 (experimental) Your reduced test case gcc.target/sparc/20151219-1.c doesn't show this large stack frame.
[Bug rtl-optimization/68910] [5/6 regression] huge stack frame and poor code with instruction scheduling at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910 --- Comment #9 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- In case I revert (e.g. double revert) to enable the LRA for SPARC commit a28f6dc56909fc35dd83d4364bc68c69e2450a51 Author: davem <davem@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Tue Sep 22 03:52:45 2015 + Revert LRA SPARC changes for now. gcc/ PR/67622 Revert: 2015-09-11 David S. Miller <da...@davemloft.net> then the clr instructions are gone. However, the stack frame is still huge: sparc-rtems4.12-gcc -S -O2 sha512c.i -mcpu=cypress .file "sha512c.i" .section".text" .align 4 .global SHA512_Transform .type SHA512_Transform, #function .proc 020 SHA512_Transform: save%sp, -3992, %sp mov 128, %o2 mov %i1, %o1
[Bug target/68910] [5/6 regression] huge stack frame and poor code with instruction scheduling at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910 --- Comment #6 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Eric Botcazou from comment #5) > I have the huge stack frame with the 4.9.x compiler too so the spilling > effect itself is probably not new. Yes, sorry for imprecise known-to-work information. The huge stack frame is also in 4.3.2 (2792 bytes), but it got worse with every GCC release.
[Bug target/68910] New: SPARC/cypress: Poor code generation, huge stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910 Bug ID: 68910 Summary: SPARC/cypress: Poor code generation, huge stack frame Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- Created attachment 37036 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37036=edit Test case. The code for the SHA512_Transform() function is very poor for the SPARC cypress target. sparc-rtems4.12-gcc -c -O2 sha512c.i -mcpu=cypress sha512c.o: file format elf32-sparc Disassembly of section .text: : 0: 9d e3 b0 58 save %sp, -4008, %sp 4: 94 10 20 80 mov 0x80, %o2 8: 92 10 00 19 mov %i1, %o1 c: 90 07 bd 80 add %fp, -640, %o0 [...] 10c: 40 00 00 00 call 10c <SHA512_Transform+0x10c> 110: 90 07 bd 40 add %fp, -704, %o0 114: c0 27 bd 20 clr [ %fp + -736 ] 118: c0 27 bd 24 clr [ %fp + -732 ] 11c: c0 27 bd 10 clr [ %fp + -752 ] 120: c0 27 bd 14 clr [ %fp + -748 ] 124: c0 27 bd 08 clr [ %fp + -760 ] 128: c0 27 bd 0c clr [ %fp + -756 ] 12c: c0 27 bd 00 clr [ %fp + -768 ] 130: c0 27 bd 04 clr [ %fp + -764 ] 134: c0 27 bc f8 clr [ %fp + -776 ] 138: c0 27 bc fc clr [ %fp + -772 ] [...] Compared to v8: sparc-rtems4.12-gcc -c -O2 sha512c.i -mcpu=v8 : 0: 9d e3 bc b8 save %sp, -840, %sp 4: 94 10 20 80 mov 0x80, %o2 8: 92 10 00 19 mov %i1, %o1 c: 90 07 bd 80 add %fp, -640, %o0 10: 40 00 00 00 call 10 <SHA512_Transform+0x10> 14: f0 27 a0 44 st %i0, [ %fp + 0x44 ] [...] No massive clr instructions.
[Bug target/68910] SPARC/cypress: Poor code generation, huge stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910 Sebastian Huber <sebastian.hu...@embedded-brains.de> changed: What|Removed |Added Known to fail||6.0 --- Comment #2 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- sparc-rtems4.12-gcc (GCC) 6.0.0 20151215 (experimental)
[Bug target/68910] SPARC/cypress: Poor code generation, huge stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68910 --- Comment #1 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- Code generation for leon3 is also quite bad.
[Bug target/66867] Suboptimal code generation for atomic_compare_exchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867 --- Comment #3 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- clang 3.7 generates optimal code on x86 in both cases: .text .file "test.c" .globl f .align 16, 0x90 .type f,@function f: # @f .cfi_startproc # BB#0: movl$1, %ecx xorl%eax, %eax lockcmpxchgl%ecx, (%rdi) retq .Lfunc_end0: .size f, .Lfunc_end0-f .cfi_endproc .globl g .align 16, 0x90 .type g,@function g: # @g .cfi_startproc # BB#0: movl$1, %ecx xorl%eax, %eax lockcmpxchgl%ecx, (%rdi) retq .Lfunc_end1: .size g, .Lfunc_end1-g .cfi_endproc .ident "clang version 3.7.0 (tags/RELEASE_370/final)" .section".note.GNU-stack","",@progbits
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 Sebastian Huber <sebastian.hu...@embedded-brains.de> changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #11 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- Yes, the mingw build is still broken. Git has compatibility functions for setenv() and unsetenv(): https://github.com/git/git/blob/master/compat/setenv.c https://github.com/git/git/blob/master/compat/unsetenv.c Maybe something like this can be used in GCC as well.
[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #7 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Jonathan Wakely from comment #6) > (In reply to Sebastian Huber from comment #4) > > Sorry, I should have linked my patch: > > > > https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00028.html > > AH yes, that would work too, and doesn't require the compiler to do any > overload resolution. > > N.B. all libstdc++ patches need to be CC'd to the libstdc++ list, I don't > read gcc-patches. I tested my patch on Linux, and it seems to work fine. I guess the pretty printer failures are not related to since they are produced by gdb. Should I test your patches as well? My C++ knowledge is not good enough to judge which solution is better. Native configuration is x86_64-pc-linux-gnu === libstdc++ tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-abi/abi.exp ... Running /home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... Running /home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp ... FAIL: libstdc++-prettyprinters/48362.cc print t1 FAIL: libstdc++-prettyprinters/48362.cc print t2 FAIL: libstdc++-prettyprinters/cxx11.cc print efl FAIL: libstdc++-prettyprinters/cxx11.cc print refl FAIL: libstdc++-prettyprinters/cxx11.cc print fl FAIL: libstdc++-prettyprinters/cxx11.cc print rfl FAIL: libstdc++-prettyprinters/cxx11.cc print eum FAIL: libstdc++-prettyprinters/cxx11.cc print reum FAIL: libstdc++-prettyprinters/cxx11.cc print eumm FAIL: libstdc++-prettyprinters/cxx11.cc print reumm FAIL: libstdc++-prettyprinters/cxx11.cc print eus FAIL: libstdc++-prettyprinters/cxx11.cc print reus FAIL: libstdc++-prettyprinters/cxx11.cc print eums FAIL: libstdc++-prettyprinters/cxx11.cc print reums FAIL: libstdc++-prettyprinters/cxx11.cc print uom FAIL: libstdc++-prettyprinters/cxx11.cc print ruom FAIL: libstdc++-prettyprinters/cxx11.cc print uomm FAIL: libstdc++-prettyprinters/cxx11.cc print ruomm FAIL: libstdc++-prettyprinters/debug.cc print str FAIL: libstdc++-prettyprinters/debug.cc print bs FAIL: libstdc++-prettyprinters/debug.cc print deq FAIL: libstdc++-prettyprinters/debug.cc print deqiter FAIL: libstdc++-prettyprinters/debug.cc print lst FAIL: libstdc++-prettyprinters/debug.cc print lstiter FAIL: libstdc++-prettyprinters/debug.cc print lstciter FAIL: libstdc++-prettyprinters/debug.cc print mp FAIL: libstdc++-prettyprinters/debug.cc print mpiter FAIL: libstdc++-prettyprinters/debug.cc print sp FAIL: libstdc++-prettyprinters/debug.cc print spciter FAIL: libstdc++-prettyprinters/debug.cc print sll FAIL: libstdc++-prettyprinters/debug.cc print slliter FAIL: libstdc++-prettyprinters/libfundts.cc print str FAIL: libstdc++-prettyprinters/libfundts.cc print o FAIL: libstdc++-prettyprinters/libfundts.cc print ob FAIL: libstdc++-prettyprinters/libfundts.cc print oi FAIL: libstdc++-prettyprinters/libfundts.cc print op FAIL: libstdc++-prettyprinters/libfundts.cc print om FAIL: libstdc++-prettyprinters/libfundts.cc print os FAIL: libstdc++-prettyprinters/libfundts.cc print a FAIL: libstdc++-prettyprinters/libfundts.cc print ab FAIL: libstdc++-prettyprinters/libfundts.cc print ai FAIL: libstdc++-prettyprinters/libfundts.cc print ap FAIL: libstdc++-prettyprinters/libfundts.cc print as FAIL: libstdc++-prettyprinters/libfundts.cc print as2 FAIL: libstdc++-prettyprinters/libfundts.cc print am FAIL: libstdc++-prettyprinters/shared_ptr.cc print esp FAIL: libstdc++-prettyprinters/shared_ptr.cc print ewp1 FAIL: libstdc++-prettyprinters/shared_ptr.cc print ewp2 FAIL: libstdc++-prettyprinters/shared_ptr.cc print sp1 FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp1 FAIL: libstdc++-prettyprinters/shared_ptr.cc print wp2 FAIL: libstdc++-prettyprinters/simple.cc print str FAIL: libstdc++-prettyprinters/simple.cc print bs FAIL: libstdc++-prettyprinters/simple.cc print deq FAIL: libstdc++-prettyprinters/simple.cc print deqiter FAIL: libstdc++-prettyprinters/simple.cc print lst FAIL: libstdc++-prettyprinters/simple.cc print lstiter FAIL: libstdc++-prettyprinters/simple.cc print lstciter FAIL: libstdc++-prettyprinters/simple.cc print mp FAIL: libstdc++-prettyprinters/simple.cc print mpiter FAIL: libstdc++-prettyprinters/simple.cc print sp FAIL: libstdc++-prettyprinters/simple.cc print spciter FAIL: libstdc++-prettyprinters/simple.cc print sll FAIL: libstdc++-prettyprinters/simple.cc print slliter FAIL: libstdc++-prettyprinters/simple11.cc print str FAIL: libstdc++-prettyprinters/simple
[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #9 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Jonathan Wakely from comment #8) > There's no need to test on linux, I can do that myself. If it works on your > non-pthreads target I'll commit your patch. Here it works fine: https://lists.rtems.org/pipermail/devel/2015-September/012445.html
[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #5 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- (In reply to Sebastian Huber from comment #4) > I think the your second version doesn't work in case the types are equal, it > looks similar to my first attempt to fix this which didn't work on Linux. Please ignore this comment, you use different second parameter types.
[Bug libstdc++/67408] assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408 --- Comment #4 from Sebastian Huber <sebastian.hu...@embedded-brains.de> --- Sorry, I should have linked my patch: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00028.html I think the your second version doesn't work in case the types are equal, it looks similar to my first attempt to fix this which didn't work on Linux. I try your first version tomorrow.
[Bug libstdc++/67408] New: assumes that __gthread_mutex_t and__gthread_recursive_mutex_t are the same types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67408
Bug ID: 67408
Summary: assumes that __gthread_mutex_t
and__gthread_recursive_mutex_t are the same types
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The problem is in in:
[...]
#if _GTHREAD_USE_MUTEX_TIMEDLOCK
template
class __timed_mutex_impl
{
[...]
auto __mutex = static_cast<_Derived*>(this)->native_handle();
return !__gthread_mutex_timedlock(__mutex, &__ts);
Here I get this for example:
In file included from
libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/1.cc:26:0:
libstdc++-v3/include/mutex: In instantiation of 'bool
std::__timed_mutex_impl<_Derived>::_M_try_lock_until(const
std::chrono::time_point<std::chrono::_V2::system_clock, _Duration>&) [with
_Duration = std::chrono::duration
>; _Derived = std::recursive_timed_mutex]':
libstdc++-v3/include/mutex:242:55: required from 'bool
std::__timed_mutex_impl<_Derived>::_M_try_lock_until(const
std::chrono::time_point<_Clock, _Duration>&) [with _Clock =
std::chrono::_V2::steady_clock; _Duration = std::chrono::duration >; _Derived = std::recursive_timed_mutex]'
libstdc++-v3/include/mutex:217:55: required from 'bool
std::__timed_mutex_impl<_Derived>::_M_try_lock_for(const
std::chrono::duration<_Rep, _Period>&) [with _Rep = long long int; _Period =
std::ratio<1ll>; _Derived = std::recursive_timed_mutex]'
libstdc++-v3/include/mutex:332:39: required from 'bool
std::recursive_timed_mutex::try_lock_for(const std::chrono::duration<_Rep1,
_Period1>&) [with _Rep = long long int; _Period = std::ratio<1ll>]'
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/1.cc:39:54:
required from here
libstdc++-v3/include/mutex:234:37: error: cannot convert
'_Mutex_recursive_Control*' to '__gthread_mutex_t* {aka _Mutex_Control*}' for
argument '1' to 'int __gthread_mutex_timedlock(__gthread_mutex_t*, const
__gthread_time_t*)'
return !__gthread_mutex_timedlock(__mutex, &__ts);
^
[Bug c++/67064] New: Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
Bug ID: 67064
Summary: Register asm variable broken
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The following test case fails on x86_64-pc-linux-gnu, powerpc-rtems,
sparc-rtems:
struct s {
int i;
};
register struct s *reg __asm__( 1 );
int f(void)
{
int i;
i = reg-i;
i = (reg)-i;
return i;
}
Yields:
prreg.cc:5:20: warning: call-clobbered register used for global register
variable
register struct s *reg __asm__( 1 );
^
prreg.cc: In function ‘int f()’:
prreg.cc:12:8: error: address of explicit register variable ‘reg’ requested
i = (reg)-i;
^
Please note, that the line 11 i = reg-i; works.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #2 from Sebastian Huber sebastian.hu...@embedded-brains.de --- Indeed -std=gnu++98 gets rid of this error. So this is working as intended for C++11 and later? This is really nice in combination with defines and macros that use ( ) around its content.
[Bug target/66867] Suboptimal code generation for C11 atomic_compare_exchange_strong_explicit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867
--- Comment #1 from Sebastian Huber sebastian.hu...@embedded-brains.de ---
This problem is also present on x86. The depreated
__sync_bool_compare_and_swap() produces better code.
#include stdatomic.h
void f(atomic_uint *a)
{
unsigned int e = 0;
atomic_compare_exchange_strong_explicit(a, e, 1, memory_order_relaxed,
memory_order_relaxed);
}
void g(unsigned int *a)
{
__sync_bool_compare_and_swap(a, 0, 1);
}
.file cas.c
.section.text.unlikely,ax,@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl f
.type f, @function
f:
.LFB0:
.cfi_startproc
movl$1, %edx
xorl%eax, %eax
movl$0, -4(%rsp) - Superfluous
lock cmpxchgl %edx, (%rdi)
ret
.cfi_endproc
.LFE0:
.size f, .-f
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.section.text.unlikely
.LCOLDB1:
.text
.LHOTB1:
.p2align 4,,15
.globl g
.type g, @function
g:
.LFB1:
.cfi_startproc
movl$1, %edx
xorl%eax, %eax
lock cmpxchgl %edx, (%rdi)
ret
.cfi_endproc
.LFE1:
.size g, .-g
.section.text.unlikely
.LCOLDE1:
.text
.LHOTE1:
.ident GCC: (GNU) 6.0.0 20150717 (experimental)
.section.note.GNU-stack,,@progbits
[Bug libgcc/66854] libgcc2.c:1846:9: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854 --- Comment #4 from Sebastian Huber sebastian.hu...@embedded-brains.de --- (In reply to Michael Meissner from comment #3) Created attachment 35978 [details] Proposed patch to fix the problem I believe this patch fixes the problem. I was able to build libgcc with this patch installed. I could not complete a full RTEMS build (I suspect I am missing some parts of the software). Thanks for the quick fix. With your patch I can build without errors. To build the powerpc-rtems target you need a link to the latest Newlib in your GCC directory, e.g. newlib - ../newlib-git/newlib. I used the following configure options: ../gcc-git/configure --prefix=/opt/rtems-4.11 --target=powerpc-rtems4.11 --verbose --with-gnu-as --with-gnu-ld --with-newlib --disable-libstdcxx-pch --disable-nls --disable-lto --disable-plugin --without-included-gettext --enable-version-specific-runtime-libs --enable-threads --enable-newlib-io-c99-formats --enable-libgomp --enable-languages=c,c++
[Bug libgcc/66854] libgcc2.c:1846:9: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854 Sebastian Huber sebastian.hu...@embedded-brains.de changed: What|Removed |Added CC||meissner at linux dot vnet.ibm.com --- Comment #1 from Sebastian Huber sebastian.hu...@embedded-brains.de --- 8b2f7251e4502efddba091ba4468e385ac435b52 is the first bad commit commit 8b2f7251e4502efddba091ba4468e385ac435b52 Author: meissner meissner@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Thu Jul 9 18:55:01 2015 + 2015-07-09 Michael Meissner meiss...@linux.vnet.ibm.com * config/rs6000/rs6000-protos.h (rs6000_secondary_reload_memory): Use machine mode, not enum machine_mode in the prototype. * config/rs6000/rs6000.h (FLOAT128_IEEE_P): New helper macros to classify 128-bit floating point support. (FLOAT128_IBM_P): Likewise. (FLOAT128_VECTOR_P): Likewise. (FLOAT128_2REG_P): Likewise. (SCALAR_FLOAT_MODE_NOT_VECTOR_P): Likewise. (SLOW_UNALIGNED_ACCESS): Add IEEE 128-bit floating point support. (HARD_REGNO_CALLER_SAVE_MODE): Likewise. (HARD_REGNO_CALL_PART_CLOBBERED): Likewise. * config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Drop tests against TFmode/TDmode, since those modes do not use VSX addresses. (rs6000_hard_regno_mode_ok): Add IEEE 128-bit floating point support. (rs6000_init_hard_regno_mode_ok): Use new helper macros instead of tests against TFmode, etc. (invalid_e500_subreg): Add tests against IFmode/KFmode. (reg_offset_addressing_ok_p): Likewise. (rs6000_legitimate_offset_address_p): Likewise. (rs6000_legitimize_address): Likewise. (rs6000_legitimize_reload_address): Likewise. (rs6000_legitimate_address_p): Clean up tests against TFmode and TDmode to use the new helper macros, which will include IFmode and KFmode. (rs6000_emit_move): Likewise. (rs6000_darwin64_record_arg_recurse): Likewise. (print_operand): Likewise. (rs6000_member_type_forces_blk): Treat IEEE 128-bit floating point that uses a single vector register as a vector and not as a floating point register in terms of the calling sequence. (rs6000_discover_homogeneous_aggregate): Likewise. (rs6000_return_in_memory): Likewise. (init_cumulative_args): Likewise. (rs6000_function_arg_boundary): Likewise. (rs6000_function_arg_advance_1): Likewise. (rs6000_function_arg): Likewise. (rs6000_pass_by_reference): Likewise. (rs6000_gimplify_va_arg): Likewise. (rs6000_secondary_reload_memory): Use machine_mode not enum machine mode. (rs6000_split_multireg_move): Use new helper macros. (spe_func_has_64bit_regs_p): Likewise. (rs6000_output_function_epilogue): Add IFmode/KFmode support. (output_toc): Use new helper macros. (rs6000_register_move_cost): Likewise. (rs6000_function_value): Add IEEE 128-bit floating point calling sequence support. (rs6000_libcall_value): Likewise. (rs6000_scalar_mode_supported_p): Add support for IEEE 128-bit floating point support. (rs6000_vector_mode_supported_p): Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225631 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 20fc90df33f1389e7c30b7b9e2499cb9045f0eca 8dffd9d0aa758f63d522a76fc4edea6a610bc9fc M gcc
[Bug c/66867] New: Suboptimal code generation for C11 atomic_compare_exchange_strong_explicit()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867
Bug ID: 66867
Summary: Suboptimal code generation for C11
atomic_compare_exchange_strong_explicit()
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
At least on ARM and PowerPC for the following test case
#include stdatomic.h
void f(atomic_uint *a)
{
unsigned int e = 0;
atomic_compare_exchange_strong_explicit(a, e, 1, memory_order_relaxed,
memory_order_relaxed);
}
a superfluous stack frame and store is generated:
.file test-cas.c
.machine ppc
.section.text
.align 2
.globl f
.type f, @function
f:
stwu 1,-24(1) - Superfluous
li 9,0
li 10,1
stw 9,8(1) - Superfluous
.L2:
lwarx 9,0,3
cmpwi 0,9,0
bne- 0,.L3
stwcx. 10,0,3
bne- 0,.L2
.L3:
addi 1,1,24 - Superfluous
blr
.size f, .-f
.ident GCC: (GNU) 6.0.0 20150714 (experimental)
[Bug libgcc/66854] New: libgcc2.c:1846:9: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854 Bug ID: 66854 Summary: libgcc2.c:1846:9: internal compiler error: Segmentation fault Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- make[4]: Entering directory `/scratch/git-build/b-gcc-git-powerpc-rtems4.11/powerpc-rtems4.11/m403/libgcc' # If this is the top-level multilib, build all the other # multilibs. /scratch/git-build/b-gcc-git-powerpc-rtems4.11/./gcc/xgcc -B/scratch/git-build/b-gcc-git-powerpc-rtems4.11/./gcc/ -nostdinc -B/scratch/git-build/b-gcc-git-powerpc-rtems4.11/powerpc-rtems4.11/newlib/ -isystem /scratch/git-build/b-gcc-git-powerpc-rtems4.11/powerpc-rtems4.11/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.11/powerpc-rtems4.11/bin/ -B/opt/rtems-4.11/powerpc-rtems4.11/lib/ -isystem /opt/rtems-4.11/powerpc-rtems4.11/include -isystem /opt/rtems-4.11/powerpc-rtems4.11/sys-include-g -O2 -mcpu=403 -O2 -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/. -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../include -DHAVE_CC_TLS -o _powisf2.o -MT _powisf2.o -MD -MP -MF _powisf2.dep -DL_powisf2 -c /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c: In function '__powisf2': /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:1846:9: internal compiler error: Segmentation fault x = x * x; ^ 0xa5ea6f crash_signal /home/EB/sebastian_h/archive/gcc-git/gcc/toplev.c:352 0xd63016 tree_class_check /home/EB/sebastian_h/archive/gcc-git/gcc/tree.h:3236 0xd63016 rs6000_pass_by_reference /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.c:10836 0x56bb84 pass_by_reference(rs6000_args*, machine_mode, tree_node*, bool) /home/EB/sebastian_h/archive/gcc-git/gcc/calls.c:878 0x56d1cf emit_library_call_value_1 /home/EB/sebastian_h/archive/gcc-git/gcc/calls.c:4033 0x573ff1 emit_library_call_value(rtx_def*, rtx_def*, libcall_type, machine_mode, int, ...) /home/EB/sebastian_h/archive/gcc-git/gcc/calls.c:4631 0x984cd7 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /home/EB/sebastian_h/archive/gcc-git/gcc/optabs.c:2133 0x670f1e expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int) /home/EB/sebastian_h/archive/gcc-git/gcc/expmed.c:3266 0x6902b6 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /home/EB/sebastian_h/archive/gcc-git/gcc/expr.c:8598 0x582482 expand_gimple_stmt_1 /home/EB/sebastian_h/archive/gcc-git/gcc/cfgexpand.c:3340 0x582482 expand_gimple_stmt /home/EB/sebastian_h/archive/gcc-git/gcc/cfgexpand.c:3400 0x5847ad expand_gimple_basic_block /home/EB/sebastian_h/archive/gcc-git/gcc/cfgexpand.c:5412 0x589d0e execute /home/EB/sebastian_h/archive/gcc-git/gcc/cfgexpand.c:6023 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. make[4]: *** [_powisf2.o] Error 1
[Bug libgomp/65467] New: [libgomp] sorry, unimplemented: '_Atomic' with OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
Bug ID: 65467
Summary: [libgomp] sorry, unimplemented: '_Atomic' with OpenMP
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
CC: jakub at gcc dot gnu.org
It seems that stdatomic.h is not available with -fopenmp:
stdatomic.h:40:1: sorry, unimplemented: '_Atomic' with OpenMP
typedef _Atomic _Bool atomic_bool;
Is this a principal problem with the OpenMP standard or libgomp?
The __atomic built-ins seem to work, e.g.
int f(int *a, int b)
{
return __atomic_fetch_add(a, b, 0);
}
[Bug libgomp/65385] New: [libgomp] omp task untied test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385 Bug ID: 65385 Summary: [libgomp] omp task untied test case fails Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de CC: jakub at gcc dot gnu.org Created attachment 35006 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35006action=edit Test program. The task untied test case of the OpenMP Validation SuiteV 3.0a fails on Linux. http://web.cs.uh.edu/~openuh/download/
[Bug libgomp/65385] [libgomp] omp task untied test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65385 --- Comment #1 from Sebastian Huber sebastian.hu...@embedded-brains.de --- Created attachment 35008 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35008action=edit Test program.
[Bug libgomp/65386] New: [libgomp] omp task final test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65386 Bug ID: 65386 Summary: [libgomp] omp task final test case fails Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de CC: jakub at gcc dot gnu.org Created attachment 35007 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35007action=edit Test program. The task final test case of the OpenMP Validation SuiteV 3.0a fails on Linux. http://web.cs.uh.edu/~openuh/download/
[Bug libgomp/65386] [libgomp] omp task final test case fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65386 --- Comment #1 from Sebastian Huber sebastian.hu...@embedded-brains.de --- Created attachment 35009 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35009action=edit Test program.
