[Bug c/108370] gcc doesn't merge bitwise-AND if an explicit comparison against 0 is given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370 --- Comment #3 from dhowells at redhat dot com --- We don't want to do: return ((unsigned int) bio->bi_flags >> bit & 1) != 0; if we can avoid it as "bit" is usually constant - though I'm guessing the optimiser should handle that?
[Bug target/108371] New: gcc for x86_64 may sign/zero extent arguments unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108371
Bug ID: 108371
Summary: gcc for x86_64 may sign/zero extent arguments
unnecessarily
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
When compiling for x86_64, bool, char and short arguments that are passed
directly to an argument of exactly the same type on another function with no
modification, e.g.:
void __bio_release_pages(char mark_dirty);
void bio_release_pages(char mark_dirty)
{
__bio_release_pages(mark_dirty);
}
get sign/zero-extended unnecessarily. In the case of the above code, it
compiles to:
0: 40 0f be ff movsbl %dil,%edi
4: e9 00 00 00 00 jmp9
with "gcc -Os -c test.c". Can the extension be optimised away? Granted, the
upper bits bits of RDI could contain rubbish on entry to bio_release_pages(),
so sanitisation is not unreasonable - but on the other hand,
__bio_release_pages() would surely have to assume the same and do the same
sanitisation?
The toolchain used is the Fedora 37 system compiler:
gcc-12.2.1-4.fc37.x86_64
binutils-2.38-25.fc37.x86_64
[Bug c/108370] New: gcc doesn't merge bitwise-AND if an explicit comparison against 0 is given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108370
Bug ID: 108370
Summary: gcc doesn't merge bitwise-AND if an explicit
comparison against 0 is given
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
Created attachment 54245
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54245=edit
Demo code
If gcc sees a couple of calls to an inline function that does a bitwise-AND and
returns whether the result was zero or non-zero (e.g. a flag check helper), gcc
cannot merge them if the result of the AND is explicitly compared against 0,
even if the function's return type is a bool (which would do that anyway). For
example:
static inline bool bio_flagged(struct bio *bio, unsigned int bit)
{
return (bio->bi_flags & (1U << bit)) != 0;
}
void bio_release_pages(struct bio *bio, bool mark_dirty)
{
if (bio_flagged(bio, BIO_PAGE_REFFED) ||
bio_flagged(bio, BIO_PAGE_PINNED))
__bio_release_pages(bio, mark_dirty);
}
compiles bio_release_pages() to:
0: 66 8b 07mov(%rdi),%ax
3: a8 01 test $0x1,%al
5: 75 04 jneb
7: a8 02 test $0x2,%al
9: 74 09 je 14
b: 40 0f b6 f6 movzbl %sil,%esi
f: e9 00 00 00 00 jmp14
14: c3 ret
but:
static inline bool bio_flagged(struct bio *bio, unsigned int bit)
{
return bio->bi_flags & (1U << bit);
}
gives:
0: f6 07 03testb $0x3,(%rdi)
3: 74 09 je e
5: 40 0f b6 f6 movzbl %sil,%esi
9: e9 00 00 00 00 jmpe
e: c3 ret
Possibly the comparison against 0 could be optimised away.
I've attached some demo code that can be compiled with one of:
gcc -Os -c gcc-bool-demo.c
gcc -Os -c gcc-bool-demo.c -Dfix
The gcc I used above is the Fedora 37 system compiler:
gcc-12.2.1-4.fc37.x86_64
binutils-2.38-25.fc37.x86_64
but similar results can be seen with the Fedora arm cross-compiler:
0: e1d030b0ldrhr3, [r0]
4: e3130001tst r3, #1
8: 1a01bne 14
c: e3130002tst r3, #2
10: 012fff1ebxeqlr
14: eafeb 0 <__bio_release_pages>
vs
0: e1d030b0ldrhr3, [r0]
4: e3130003tst r3, #3
8: 012fff1ebxeqlr
c: eafeb 0 <__bio_release_pages>
[Bug c/99998] New: Unnecessary jump instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
Bug ID: 8
Summary: Unnecessary jump instruction
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
Created attachment 50539
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50539=edit
Test source
Using the Fedora 33 x86_64 compiler:
gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) (GCC)
Building the following (see also attached file):
typedef _Bool bool;
#define smp_rmb() __asm__ __volatile__("": : :"memory")
#define unlikely(x) __builtin_expect(!!(x), 0)
enum { PG_uptodate = 2 };
struct page {
unsigned long flags;
unsigned long compound_head;/* Bit zero is set */
};
static inline bool constant_test_bit(unsigned int nr, const void *addr)
{
const unsigned int *p = (const unsigned int *)addr;
return ((1UL << (nr & 31)) & (p[nr >> 5])) != 0;
}
static inline struct page *compound_head(struct page *page)
{
unsigned long head = page->compound_head;
if (unlikely(head & 1))
return (struct page *) (head - 1);
return page;
}
bool PageUptodate(struct page *page)
{
bool ret;
page = compound_head(page);
ret = constant_test_bit(PG_uptodate, >flags);
if (ret)
smp_rmb();
return ret;
}
with "gcc -Os" I get the following assembly excerpt:
PageUptodate:
.LFB2:
.cfi_startproc
movq8(%rdi), %rax
testb $1, %al
je .L2
leaq-1(%rax), %rdi
.L2:
movl(%rdi), %eax
shrq$2, %rax
andb$1, %al
je .L1
.L1:
ret
.cfi_endproc
There's a superfluous jump, JE, at the end jumping to the next instruction with
label .L1. This corresponds to the smp_rmb() which is just a compiler barrier.
This also happens with other optimisation levels.
[Bug c/99997] New: Missed optimisation with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7
Bug ID: 7
Summary: Missed optimisation with -Os
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
Created attachment 50538
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50538=edit
Test source
Using the Fedora 33 x86_64 compiler:
gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) (GCC)
Building the following (see also attached file):
typedef _Bool bool;
#define __always_inline inline __attribute__((__always_inline__))
enum { PG_head = 16 };
struct page {
unsigned long flags;
unsigned long compound_head;/* Bit zero is set */
};
static inline bool constant_test_bit(int nr, const void *addr)
{
const unsigned int *p = (const unsigned int *)addr;
return ((1UL << (nr & 31)) & (p[nr >> 5])) != 0;
}
static __always_inline bool PageTail(struct page *page)
{
return page->compound_head & 1;
}
static __always_inline bool PageCompound(struct page *page)
{
return constant_test_bit(PG_head, >flags) || PageTail(page);
}
bool PageTransCompound(struct page *page)
{
return PageCompound(page);
}
with "gcc -Os" I get the following assembly:
PageTransCompound:
.LFB3:
.cfi_startproc
movl(%rdi), %edx
movl$1, %eax
btl $16, %edx
jc .L2
movq8(%rdi), %rax
andl$1, %eax
.L2:
andl$1, %eax
ret
.cfi_endproc
There are two consecutive identical ANDL instructions, one of which is
superfluous. The compile could eliminate the one that's immediately prior to
the .L2 instruction.
[Bug tree-optimization/94527] RFE: Add an __attribute__ that marks a function as freeing an object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527 --- Comment #1 from dhowells at redhat dot com --- To quote Linus Torvalds, https://lore.kernel.org/lkml/CAHk-=wg2Vsb0JETo24=tc-t2drwmopmrfknc__r5sz6tenb...@mail.gmail.com/ > Think of it this way: free() doesn't really change the data, it kills > the lifetime of it. You can't access it afterwards - you can neither > read it nor write it validly. That is a completely different - and > independent - operation from writing to it. Side note: I'd really love to be able to describe that operation, but there's sadly no such extension. So the _real_ prototype for 'free()'-like operations should be something like void free(const volatile killed void *ptr); where that "killed" also tells the compiler that the pointer lifetime is dead, so that using it afterwards is invalid. So that the compiler could warn us about some of the most trivial use-after-free cases. Because we've had even those trivially stupid ones Yes, obviously various analysis systems do exactly that kind of analysis (and usually go much further), but then it's external things like coverity etc. The point being that the lifetime of an object is independent from being able to write to an object, and the "const" in the "free()" is not "I promise to not write to it", but "I can accept a constant pointer". We've had a number of places in the kernel where we do that kind of "lifetime" marking explicitly by assigning a NULL (or invalid value) to the pointer when we free it. I have this dim memory of us even (long long long ago) trying to use a #define kfree() ... to do that, but it turns out to be basically impossible to get the proper "use once" semantics, so it doesn't work if the argument to kfree() has side effects.
[Bug tree-optimization/94527] New: RFE: Add an __attribute__ that marks a function as freeing an object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527 Bug ID: 94527 Summary: RFE: Add an __attribute__ that marks a function as freeing an object Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dhowells at redhat dot com Target Milestone: --- Would it be possible to add a function attribute to indicate that the function is going to destroy the object a the parameter points to (ie. a free()-like function)? Perhaps something like: void free(const volatile void *ptr) __attribute__((free(1))); where the free(N) attribute indicates the parameter number[*]. [*] Note that it's possible that a free()-like function might also take additional parameters to provide context and that context won't be destroyed. The compiler could then warn upon future access through the pointer.
[Bug c++/87235] g++ doesn't implement sparse initialisation of arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87235 --- Comment #1 from dhowells at redhat dot com --- g++ -v gives: Using built-in specs. COLLECT_GCC=/usr/bin/g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 8.1.1 20180712 (Red Hat 8.1.1-5) (GCC)
[Bug c++/87235] New: g++ doesn't implement sparse initialisation of arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87235
Bug ID: 87235
Summary: g++ doesn't implement sparse initialisation of arrays
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
Created attachment 44662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44662=edit
Testcase
g++ doesn't implement simple sparse array initialisations, such as:
int a[] = {
[3] = 99,
[5] = 82,
};
This can be seen by compiling the attached program with "g++ -c x.cpp".
g++ produces lots of "sorry, unimplemented: non-trivial designated initializers
not supported" errors.
[Bug c++/84874] New: internal compiler error: in reshape_init_class, at cp/decl.c:5800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84874 Bug ID: 84874 Summary: internal compiler error: in reshape_init_class, at cp/decl.c:5800 Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dhowells at redhat dot com Target Milestone: --- Created attachment 43663 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43663=edit Test case I'm seeing the following ICE: g++ -Wall ice.cpp ice.cpp: In function ‘void sema_init(semaphore*)’: ice.cpp:30:2: internal compiler error: in reshape_init_class, at cp/decl.c:5800 }; ^ I've attached the preprocessed dump. I think the code should produce an error (as it does if compiled for C). The compiler is the Fedora 27 compiler, gcc-7.3.1-5.fc27.x86_64.
[Bug target/79404] [7 Regression] h8300: ICE at gcc/ira.c:5541 whilst building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79404 --- Comment #6 from dhowells at redhat dot com --- That builds now, thanks!
[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462 --- Comment #8 from dhowells at redhat dot com --- The patch works for me, thanks!
[Bug target/79462] sh: Stack smashing detected when building __ashrdi3 in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462 --- Comment #1 from dhowells at redhat dot com --- Here's the configuration command for hosting on ppc64le: CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mcpu=power8 -mtune=power8' \ CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mcpu=power8 -mtune=power8 ' \ CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \ AR_FOR_TARGET=/usr/bin/sh-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/sh-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/sh-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/sh-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/sh-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/sh-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/sh-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/sh-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/sh-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/sh-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/sh-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ configure --bindir=/usr/bin --build=ppc64le-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmpx --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/sh-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls --enable-obsolete --enable-plugin --enable-secureplt --enable-targets=all --exec-prefix=/usr --host=ppc64le-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=sh-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=sh-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-gcc-major-version-only --with-isl --with-newlib --with-plugin-ld=/usr/bin/sh-linux-gnu-ld --with-sysroot=/usr/sh-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers --with-multilib-list=m1,m2,m2e,m2a,m2a-single,m4,m4-single,m4-single-only,m4-nofpu --with-linker-hash-style=gnu Other arches would be similar. The gcc-7 version in question would be: %global DATE 20170209 %global SVNREV 245310 The binutils in 2.27 cross-compiled for sh.
[Bug target/79462] New: sh: Stack smashing detected when building __ashrdi3 in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462 Bug ID: 79462 Summary: sh: Stack smashing detected when building __ashrdi3 in libgcc Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dhowells at redhat dot com Target Milestone: --- Stack smashing is detected on some host arches (i686, ppc64, for example, but not x86_64) when building libgcc for an sh-target cross compiler: /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/xgcc -B/builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/ -B/usr/sh-linux-gnu/bin/ -B/usr/sh-linux-gnu/lib/ -isystem /usr/sh-linux-gnu/include -isystem /usr/sh-linux-gnu/sys-include-g -O2 -Wall -fexceptions -m2 -O2 -g -O2 -Wall -fexceptions -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -I. -I. -I../../.././gcc -I../../../../gcc-7.0.1-20170209/libgcc -I../../../../gcc-7.0.1-20170209/libgcc/. -I../../../../gcc-7.0.1-20170209/libgcc/../gcc -I../../../../gcc-7.0.1-20170209/libgcc/../include -DHAVE_CC_TLS -o _ashrdi3.o -MT _ashrdi3.o -MD -MP -MF _ashrdi3.dep -DL_ashrdi3 -c ../../../../gcc-7.0.1-20170209/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS *** stack smashing detected ***: /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1 terminated === Backtrace: = /lib64/libc.so.6(+0x969b8)[0x3fff947069b8] /lib64/libc.so.6(__fortify_fail+0x54)[0x3fff947d2fc4] /lib64/libc.so.6(__stack_chk_fail+0x20)[0x3fff947d2f60] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z14gen_cbranchdi4P7rtx_defS0_S0_S0_+0xd4)[0x10b904c4] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z23emit_cmp_and_jump_insnsP7rtx_defS0_8rtx_codeS0_12machine_modeiS0_i+0x170)[0x105e4b70] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z23do_compare_rtx_and_jumpP7rtx_defS0_8rtx_codei12machine_modeS0_P14rtx_code_labelS4_i+0x214)[0x102ff1a4] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x105ed30c] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z12expand_binop12machine_mode9optab_tagP7rtx_defS2_S2_i13optab_methods+0x1d54)[0x105ec814] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z12expand_binop12machine_mode9optab_tagP7rtx_defS2_S2_i13optab_methods+0x5b8)[0x105eb078] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x1039e220] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z18expand_expr_real_2P12separate_opsP7rtx_def12machine_mode15expand_modifier+0x3aa8)[0x103ca268] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z18expand_expr_real_1P9tree_nodeP7rtx_def12machine_mode15expand_modifierPS2_b+0x2f54)[0x103b6d14] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x103c5f7c] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z17expand_assignmentP9tree_nodeS0_b+0x5b8)[0x103c2e68] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x102743e0] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x10276178] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x1027ca08] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z16execute_one_passP8opt_pass+0x334)[0x10611e54] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x10612e04] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_Z17execute_pass_listP8functionP8opt_pass+0x38)[0x10612ea8] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_ZN11cgraph_node6expandEv+0x170)[0x102b85d0] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x102ba0e4] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_ZN12symbol_table25finalize_compilation_unitEv+0x1ec)[0x102bc61c] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1[0x1071e04c] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(_ZN6toplev4mainEiPPc+0xfcc)[0x101199ec] /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/./gcc/cc1(main+0x54)[0x1011bb34] /lib64/libc.so.6(+0x22b20)[0x3fff94692b20] /lib64/libc.so.6(__libc_start_main+0xb8)[0x3fff94692d18] === Memory map: 1000-1110 r-xp fc:05 9181442 /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/gcc/cc1 1110-1113 r--p 010f fc:05 9181442 /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/gcc/cc1 1113-1114 rw-p 0112 fc:05 9181442 /builddir/build/BUILD/gcc-7.0.1-20170209/sh-linux-gnu/gcc
[Bug target/79404] h8300: ICE at gcc/ira.c:5541 whilst building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79404
--- Comment #3 from dhowells at redhat dot com ---
Program received signal SIGSEGV, Segmentation fault.
0x007e13fb in allocno_copy_cost_saving (
allocno=allocno@entry=0x149f340, hard_regno=2)
at ../../gcc-7.0.1-20170204/gcc/ira-color.c:2764
2764 cost += cp->freq *
ira_register_move_cost[allocno_mode][rclass][rclass];
(gdb) p cp
$1 = (ira_copy_t) 0x14cee38
(gdb) p cp->freq
$2 = 194
0x007e13f0 <+176>: mov%r9,%rdx
0x007e13f3 <+179>: add0x12a4860(,%r10,8),%rdx
=> 0x007e13fb <+187>: movzwl (%rdx,%r11,1),%edx
r9 0x8 8
r100x21b539
r110x38 56
rdx0x8 8
$3 = (target_ira_int *) 0x12a4860
(gdb) p &((struct target_ira_int*)0)->x_ira_register_move_cost
$4 = (move_table *(*)[39]) 0x10a0
(gdb) p 0x10a0/8
$5 = 532
So r10 is the offset of x_ira_register_move_cost/8 + 7 where allocno_mode is 7
(DImode).
But:
(gdb) p default_target_ira_int.x_ira_register_move_cost[7]
$8 = (move_table *) 0x0
(gdb) p default_target_ira_int.x_ira_register_move_cost
$2 = {0x12f7170, 0x12f7170, 0x13e8f80, 0x0, 0x14876f0, 0x1487450, 0x14875a0,
0x0 }
[Bug target/79404] h8300: ICE at gcc/ira.c:5541 whilst building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79404 --- Comment #2 from dhowells at redhat dot com --- (In reply to dhowe...@redhat.com from comment #1) > gcc is SVNREV 245184 plus the Fedora patches. Also occurs with all patches dropped.
[Bug target/79404] h8300: ICE at gcc/ira.c:5541 whilst building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79404 --- Comment #1 from dhowells at redhat dot com --- gcc is SVNREV 245184 plus the Fedora patches.
[Bug target/79404] New: h8300: ICE at gcc/ira.c:5541 whilst building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79404 Bug ID: 79404 Summary: h8300: ICE at gcc/ira.c:5541 whilst building libgcc Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dhowells at redhat dot com Target Milestone: --- Created attachment 40686 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40686=edit Test code When building a cross compiler for h8300, an ICE occurs whilst it is building libgcc: /data/fedora/cross-gcc/ice.i: In function ‘__lshrdi3’: /data/fedora/cross-gcc/ice.i:80:1: internal compiler error: Segmentation fault } ^ 0x92805f crash_signal ../../gcc-7.0.1-20170204/gcc/toplev.c:333 0x7e13fb allocno_copy_cost_saving ../../gcc-7.0.1-20170204/gcc/ira-color.c:2764 0x7e9f83 improve_allocation ../../gcc-7.0.1-20170204/gcc/ira-color.c:2837 0x7e9f83 color_allocnos ../../gcc-7.0.1-20170204/gcc/ira-color.c:3141 0x7eb5b7 color_pass ../../gcc-7.0.1-20170204/gcc/ira-color.c:3250 0x7d7465 ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) ../../gcc-7.0.1-20170204/gcc/ira-build.c:1781 0x7e6c67 do_coloring ../../gcc-7.0.1-20170204/gcc/ira-color.c:3401 0x7e6c67 color ../../gcc-7.0.1-20170204/gcc/ira-color.c:4771 0x7e6c67 ira_color() ../../gcc-7.0.1-20170204/gcc/ira-color.c:4886 0x7d0ce3 ira ../../gcc-7.0.1-20170204/gcc/ira.c:5249 0x7d0ce3 execute ../../gcc-7.0.1-20170204/gcc/ira.c:5541 gcc is configured as: // Target: h8300-elf // Configured with: ../gcc-7.0.1-20170204/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmpx --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/h8300-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=h8300-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=h8300-elf --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-gcc-major-version-only --with-isl --with-newlib --with-plugin-ld=/usr/bin/h8300-linux-gnu-ld --with-sysroot=/usr/h8300-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers --with-linker-hash-style=gnu // Thread model: single // gcc version 7.0.1 20170204 (Red Hat Cross 7.0.1-1) (GCC) using binutils-2.27 cross-built for target h8300-elf. The command to build the test source is: /data/fedora/cross-gcc/gcc-7.0.1-20170204/h8300-linux-gnu/gcc/xgcc \ -B/data/fedora/cross-gcc/gcc-7.0.1-20170204/h8300-linux-gnu/gcc/ \ -B/usr/h8300-elf/bin/ \ -B/usr/h8300-elf/lib/ \ -O2 \ -c /data/fedora/cross-gcc/ice.i \ -o _lshrdi3.o
[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785 --- Comment #21 from dhowells at redhat dot com --- (In reply to Markus Trippelsdorf from comment #20) > *** Bug 78879 has been marked as a duplicate of this bug. *** Kernel bug or not, it should be noted that this means that you cannot use gcc from r236831 to compile any kernel from the introduction and use of ilog2() to the current day - and these kernel versions cannot be retroactively fixed.
[Bug tree-optimization/78317] "if (x & constant) z |= constant" should not be rendered with jumps and conditional moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78317
--- Comment #5 from dhowells at redhat dot com ---
Note that the issue doesn't require the value to be returned directly to
trigger it:
struct A { unsigned a; };
struct B { unsigned b; };
unsigned test5(struct A *x, struct B *y)
{
unsigned z = 0;
if (x->a & 0x10)
z |= 0x10;
if (x->a & 0x40)
z |= 0x40;
y->b = z;
}
is rendered as:
52: 8b 17 mov(%rdi),%edx
54: b9 10 00 00 00 mov$0x10,%ecx
59: 89 d0 mov%edx,%eax
5b: 83 e0 10and$0x10,%eax
5e: 0f 45 c1cmovne %ecx,%eax
61: 89 c1 mov%eax,%ecx
63: 83 c9 40or $0x40,%ecx
66: 80 e2 40and$0x40,%dl
69: 0f 45 c1cmovne %ecx,%eax
6c: 89 06 mov%eax,(%rsi)
6e: c3 retq
by gcc -Os, but:
23: 8b 07 mov(%rdi),%eax
25: 83 e0 50and$0x50,%eax
28: 89 06 mov%eax,(%rsi)
2a: c3 retq
by clang -Os.
[Bug c/78317] New: "if (x & constant) z |= constant" should not be rendered with jumps and conditional moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78317
Bug ID: 78317
Summary: "if (x & constant) z |= constant" should not be
rendered with jumps and conditional moves
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
Created attachment 40025
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40025=edit
Test code
The following code:
unsigned test1(unsigned x)
{
unsigned z = 0;
if (x & 0x10)
z |= 0x10;
return z;
}
on x86_64 compiled with -Os to:
0: 89 f8 mov%edi,%eax
2: ba 10 00 00 00 mov$0x10,%edx
7: 83 e0 10and$0x10,%eax
a: 0f 45 c2cmovne %edx,%eax
d: c3 retq
when what it should probable do is what clang does:
0: 83 e7 10and$0x10,%edi
3: 89 f8 mov%edi,%eax
5: c3 retq
as the bit can be transferred by an AND and an OR.
Further, two or more such statements can be combined, for instance:
unsigned test2(unsigned x)
{
unsigned z = 0;
if (x & 0x10)
z |= 0x10;
if (x & 0x40)
z |= 0x40;
return z;
}
but gcc gives the following:
e: 89 f8 mov%edi,%eax
10: ba 10 00 00 00 mov$0x10,%edx
15: 83 e0 10and$0x10,%eax
18: 0f 45 c2cmovne %edx,%eax
1b: 89 c2 mov%eax,%edx
1d: 83 ca 40or $0x40,%edx
20: 40 80 e7 40 and$0x40,%dil
24: 0f 45 c2cmovne %edx,%eax
27: c3 retq
when clang gives:
6: 83 e7 50and$0x50,%edi
9: 89 f8 mov%edi,%eax
b: c3 retq
If z isn't passed in, but rather is initialised to another argument, say y:
unsigned test3(unsigned x, unsigned y)
{
unsigned z = y;
if (x & 0x10)
z |= 0x10;
return z;
}
unsigned test4(unsigned x, unsigned y)
{
unsigned z = y;
if (x & 0x10)
z |= 0x10;
if (x & 0x40)
z |= 0x40;
return z;
}
then gcc gives:
0028 :
28: 89 f2 mov%esi,%edx
2a: 89 f0 mov%esi,%eax
2c: 83 ca 10or $0x10,%edx
2f: 40 80 e7 10 and$0x10,%dil
33: 0f 45 c2cmovne %edx,%eax
36: c3 retq
0037 :
37: 89 f2 mov%esi,%edx
39: 89 f0 mov%esi,%eax
3b: 83 ca 10or $0x10,%edx
3e: 40 f6 c7 10 test $0x10,%dil
42: 0f 45 c2cmovne %edx,%eax
45: 89 c2 mov%eax,%edx
47: 83 ca 40or $0x40,%edx
4a: 40 80 e7 40 and$0x40,%dil
4e: 0f 45 c2cmovne %edx,%eax
51: c3 retq
and clang gives:
000c :
c: 83 e7 10and$0x10,%edi
f: 09 f7 or %esi,%edi
11: 89 f8 mov%edi,%eax
13: c3 retq
0014 :
14: 89 f8 mov%edi,%eax
16: 83 e0 10and$0x10,%eax
19: 09 f0 or %esi,%eax
1b: 83 e7 40and$0x40,%edi
1e: 09 c7 or %eax,%edi
20: 89 f8 mov%edi,%eax
22: c3 retq
Both gcc and clang give suboptimal code for test4(). What they should do is:
and$0x50,%edi
or %esi,%edi
mov%edi,%eax
retq
Note that gcc also produces similarly suboptimal output for targets other than
x86_64.
[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785 --- Comment #17 from dhowells at redhat dot com --- (In reply to dhowe...@redhat.com from comment #16) > ... > 0027 : > 27: 0f bd c7bsr%edi,%eax > 2a: 83 f0 1fxor$0x1f,%eax > 2d: c3 retq > > though the XOR is superfluous - for any valid input to ilog2(), I think the > output is always in the range 0-31. Ah - it's not actually an AND, so the XOR isn't necessarily superfluous.
[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
--- Comment #16 from dhowells at redhat dot com ---
I guess the following could be used:
int clz_ilog2(unsigned long x)
{
return __builtin_clz(x);
}
which compiles to:
0027 :
27: 0f bd c7bsr%edi,%eax
2a: 83 f0 1fxor$0x1f,%eax
2d: c3 retq
though the XOR is superfluous - for any valid input to ilog2(), I think the
output is always in the range 0-31.
[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
--- Comment #15 from dhowells at redhat dot com ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to dhowe...@redhat.com from comment #13)
> ...
> Ugh, no. Why not just x && (x & -x) == x ? __builtin_ctz (x) : -1
> (or ctzl or ctzll depending on what the type is)?
Comparing the kernel's ilog2() to your suggestion:
int kernel_ilog2(unsigned long x)
{
return ilog2(x);
}
int jakub_ilog2(unsigned long x)
{
return x && (x & -x) == x ? __builtin_ctz (x) : -1;
}
compiled with -Os for x86_64 gives:
:
0: 83 c8 ffor $0x,%eax
3: 48 0f bd c7 bsr%rdi,%rax
7: c3 retq
0008 :
8: 83 c8 ffor $0x,%eax
b: 48 85 fftest %rdi,%rdi
e: 74 17 je 27 <jakub_ilog2+0x1f>
10: 48 89 famov%rdi,%rdx
13: 0f bc c7bsf%edi,%eax
16: 48 f7 daneg%rdx
19: 48 21 faand%rdi,%rdx
1c: 48 39 d7cmp%rdx,%rdi
1f: ba ff ff ff ff mov$0x,%edx
24: 0f 45 c2cmovne %edx,%eax
27: c3 retq
Note that in the kernel variant, the initial OR instruction is superfluous, but
is required by fls() and fls64() which x86_64 is using behind the scenes. Not
all arches, however, use fls() and fls64() to implement ilog2().
[Bug tree-optimization/72785] [7 Regression] kernel build error since r236831
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785 dhowells at redhat dot com changed: What|Removed |Added CC||dhowells at redhat dot com --- Comment #13 from dhowells at redhat dot com --- Another possibility, at least for handling ilog2(), could be to provide __builtin_ilog2(unsigned long x) as an alternative. Note that the kernel ilog2() has the property that the result is undefined if x==0 (and will jump to ilog2_NaN() if x is constant 0).
[Bug target/77600] M68K: gcc generates rubbish with -mshort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77600 --- Comment #1 from dhowells at redhat dot com --- warthog>m68k-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/m68k-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/m68k-linux-gnu/6.1.1/lto-wrapper Target: m68k-linux-gnu Configured with: ../gcc-6.1.1-20160427/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmpx --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/m68k-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=m68k-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=m68k-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl --with-newlib --with-plugin-ld=/usr/bin/m68k-linux-gnu-ld --with-sysroot=/usr/m68k-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers --with-linker-hash-style=gnu Thread model: single gcc version 6.1.1 20160427 (Red Hat Cross 6.1.1-1) (GCC)
[Bug target/77599] M68K: __builtin_bswap32() isn't compiled correctly with -mshort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77599 --- Comment #1 from dhowells at redhat dot com --- warthog>m68k-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/m68k-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/m68k-linux-gnu/6.1.1/lto-wrapper Target: m68k-linux-gnu Configured with: ../gcc-6.1.1-20160427/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmpx --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/m68k-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=m68k-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=m68k-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl --with-newlib --with-plugin-ld=/usr/bin/m68k-linux-gnu-ld --with-sysroot=/usr/m68k-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers --with-linker-hash-style=gnu Thread model: single gcc version 6.1.1 20160427 (Red Hat Cross 6.1.1-1) (GCC)
[Bug target/77600] New: M68K: gcc generates rubbish with -mshort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77600
Bug ID: 77600
Summary: M68K: gcc generates rubbish with -mshort
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
In certain cases gcc wants to generate the equivalent of:
move.b (%a0,-1),foo
but instead of generating:
moveq #-1.%d0
moveb(%a0,%d0.l)
or similar it generates the bogus sequence:
moveq #0,%d0
not.w %d0
which would be the fast way of generating a 16-bit -1 value rather than a
32-bit value.
Compiling:
void *my_memcpy(void *d, const void *s, long sz)
{
unsigned char *dp = d;
const unsigned char *sp = s;
while (sz--)
*dp++ = *sp++;
return d;
}
with:
m68k-linux-gnu-gcc -m68000 -S /tmp/memcpy.c -o - -O2 -mshort
produces:
my_memcpy:
link.w %fp,#0
move.l %a3,-(%sp)
move.l %a2,-(%sp)
move.l 8(%fp),%a0
move.l 16(%fp),%d0
jeq .L6
move.l %a0,%a2
ext.l %d0 <--- isn't the size a 'long int'?
lea (%a0,%d0.l),%a3
move.l 12(%fp),%a1
moveq #0,%d0 <--- dodgy bit
not.w %d0 <---
.L3:
addq.l #1,%a1
move.b (%a1,%d0.l),(%a2)+ <--- should this be %d0.w as the index?
cmp.l %a2,%a3
jne .L3
.L6:
move.l %a0,%d0
move.l (%sp)+,%a2
move.l (%sp)+,%a3
unlk %fp
rts
Dropping the -mshort, I see:
my_memcpy:
link.w %fp,#0
move.l %a2,-(%sp)
move.l 8(%fp),%a0
move.l 12(%fp),%a1
tst.l 16(%fp)
jeq .L6
move.l %a0,%a2
move.l 16(%fp),%d0
add.l %a1,%d0
.L3:
move.b (%a1)+,(%a2)+
cmp.l %a1,%d0
jne .L3
.L6:
move.l %a0,%d0
move.l (%sp)+,%a2
unlk %fp
rts
which looks correct, though there's a test of sz and then sz is loaded into %d0
in two separate instructions; possibly these two could be combined since move
to data reg sets the condition flags.
I'm using a gcc-6.1.1 cross-compiler built for x86_64, but the problem also
shows up on gcc-5.3.1. The gcc-6.1.1 compiler is svn rev 237634, dated
20160621.
[Bug target/77599] New: M68K: __builtin_bswap32() isn't compiled correctly with -mshort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77599
Bug ID: 77599
Summary: M68K: __builtin_bswap32() isn't compiled correctly
with -mshort
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
The following test code:
unsigned long x(unsigned long y)
{
return __builtin_bswap32(y);
}
is miscompiled for m68k when -mshort is specified. Compiling with
m68k-linux-gnu-gcc -m68000 -S /tmp/3.c -o - -mshort
I see:
x:
link.w %fp,#0
move.l 8(%fp),%d0
ror.w #8,%d0
move.w %d0,%d0
and.l #65535,%d0
unlk %fp
rts
dropping the -mshort I see:
x:
link.w %fp,#0
move.l 8(%fp),%d0
ror.w #8,%d0
swap %d0
ror.w #8,%d0
unlk %fp
rts
I'm using a gcc-6.1.1 cross-compiler built for x86_64, but the problem also
shows up on gcc-5.3.1. The gcc-6.1.1 compiler is svn rev 237634, dated
20160621.
[Bug c/77491] New: Suboptimal code produced with unnecessary moving of values on/off stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77491 Bug ID: 77491 Summary: Suboptimal code produced with unnecessary moving of values on/off stack Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dhowells at redhat dot com Target Milestone: --- Created attachment 39567 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39567=edit Test source The attached program produces unnecessary instructions moving registers on and off of the stack. Compiled with Fedora 24 gcc-6.1.1-3 20160621, using gcc -Os, for the first function I see: : 0: 9c pushfq 1: 59 pop%rcx 2: fa cli 3: 8b 07 mov(%rdi),%eax 5: 89 44 24 fc mov%eax,-0x4(%rsp) 9: 8b 54 24 fc mov-0x4(%rsp),%edx d: 83 fa 17cmp$0x17,%edx 10: 0f 94 c0sete %al 13: 75 06 jne1b <jump+0x1b> 15: c7 07 2b 00 00 00 movl $0x2b,(%rdi) 1b: 51 push %rcx 1c: 9d popfq 1d: 8b 54 24 fc mov-0x4(%rsp),%edx 21: 89 16 mov%edx,(%rsi) 23: c3 retq The instruction at 9 is unnecessary - either the value in EDX could be moved directly to EAX, or the comparison at d could be made against EAX. The instructions at 5, 1d and 21 could be combined to place the result directly in (ESI) rather than shuffling it on and off the stack. Looking at the second function: 0024 : 24: 9c pushfq 25: 58 pop%rax 26: fa cli 27: 8b 17 mov(%rdi),%edx 29: 89 54 24 fc mov%edx,-0x4(%rsp) 2d: 8b 54 24 fc mov-0x4(%rsp),%edx 31: 83 fa 17cmp$0x17,%edx 34: 75 06 jne3c <jump2+0x18> 36: c7 07 2b 00 00 00 movl $0x2b,(%rdi) 3c: 50 push %rax 3d: 9d popfq 3e: 8b 44 24 fc mov-0x4(%rsp),%eax 42: 89 44 24 f8 mov%eax,-0x8(%rsp) 46: 8b 44 24 f8 mov-0x8(%rsp),%eax 4a: c3 retq It would be best if the flags were stashed in ECX, not EAX, as happens with the first function. This would allow the return value to be set in instruction 27. The comparison in 31 could then be against EAX directly. Instructions 29, 2d, 3e, 42 and 46 are all redundant. Changing the #if in the code to disable the inline asm doesn't show all that much improvement in either function. Doing this also allows it to be built for aarch64 - which also shows unnecessary stack shuffling: : 0: d10043ffsub sp, sp, #0x10 4: b942ldr w2, [x0] 8: b9000fe2str w2, [sp,#12] c: b9400fe2ldr w2, [sp,#12] 10: 71005c5fcmp w2, #0x17 14: 1a9f17e3csetw3, eq 18: 5461b.ne24 <jump+0x24> 1c: 52800562mov w2, #0x2b // #43 20: b902str w2, [x0] 24: b9400fe0ldr w0, [sp,#12] 28: b920str w0, [x1] 2c: 2a0303e0mov w0, w3 30: 910043ffadd sp, sp, #0x10 34: d65f03c0ret 0038 : 38: d10043ffsub sp, sp, #0x10 3c: b941ldr w1, [x0] 40: b9000fe1str w1, [sp,#12] 44: b9400fe1ldr w1, [sp,#12] 48: 71005c3fcmp w1, #0x17 4c: 5461b.ne58 <jump2+0x20> 50: 52800561mov w1, #0x2b // #43 54: b901str w1, [x0] 58: b9400fe0ldr w0, [sp,#12] 5c: b9000be0str w0, [sp,#8] 60: b9400be0ldr w0, [sp,#8] 64: 910043ffadd sp, sp, #0x10 68: d65f03c0ret
[Bug c/77329] New: gcc doesn't always correctly calculate label addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77329
Bug ID: 77329
Summary: gcc doesn't always correctly calculate label addresses
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
The following code:
extern int printf(const char *, ...);
extern int A(int), B(int);
int test(void)
{
A(0);
foo:
printf("%p\n", &);
B(0);
return 99;
}
Incorrectly calculates the address of the label foo with -Os and -O2, but works
fine with -O0. For -Os on an x86_64 cross-compiler or native compiler of
version 6.1.1, I see:
.LC0:
.string "%p\n"
test:
.LFB0:
.cfi_startproc
.L2:
subq$8, %rsp
.cfi_def_cfa_offset 16
xorl%edi, %edi
callA
movl$.L2, %esi
movl$.LC0, %edi
xorl%eax, %eax
callprintf
xorl%edi, %edi
callB
movl$99, %eax
popq%rdx
.cfi_def_cfa_offset 8
ret
Note the .L2 label before the test function prologue - the address of this is
& I would expect .L2 to appear between the first and second statements.
.L2 does indeed appear there if the label address is placed in a variable and
then passed to a goto-statement.
Note that adding:
asm("jmp *%0" : : "r"(here));
before the return doesn't help.
The cross compiler is built thusly:
configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu
--datadir=/usr/share --disable-decimal-float --disable-dependency-tracking
--disable-gold --disable-libgcj --disable-libgomp --disable-libmpx
--disable-libquadmath --disable-libssp --disable-libunwind-exceptions
--disable-shared --disable-silent-rules --disable-sjlj-exceptions
--disable-threads --with-ld=/usr/bin/x86_64-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls
--enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=x86_64-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=x86_64-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-isl --with-newlib --with-plugin-ld=/usr/bin/x86_64-linux-gnu-ld
--with-sysroot=/usr/x86_64-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers --with-arch_32=i686 --with-tune=generic
--enable-gnu-indirect-function --with-linker-hash-style=gnu
The compiler is 20160621, svn rev 237634.
[Bug tree-optimization/58073] Suboptimal optimisation of ((x & 0x70) == 0x00 || (x & 0x70) == 0x10 || (x & 0x70) == 0x20) on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58073 --- Comment #5 from dhowells at redhat dot com --- There's a further potential optimisation. If shift is large enough that the bits under test are outside of the LSB, the TESTB changes to a TESTL at the same address: Shift 2: 0: f6 07 1ctestb $0x1c,(%rdi) 3: 0f 94 c0sete %al 6: c3 retq Shift 10: 0: f7 07 00 1c 00 00 testl $0x1c00,(%rdi) 6: 0f 94 c0sete %al 9: c3 retq Shift 18: 0: f7 07 00 00 1c 00 testl $0x1c,(%rdi) 6: 0f 94 c0sete %al 9: c3 retq However, one could do a TESTW or a TESTB instead with a smaller immediate value and a displaced address.
[Bug tree-optimization/58073] Suboptimal optimisation of ((x & 0x70) == 0x00 || (x & 0x70) == 0x10 || (x & 0x70) == 0x20) on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58073 --- Comment #4 from dhowells at redhat dot com --- (In reply to Andrew Pinski from comment #2) > ((x & 0x70) == 0x00 && (x & 0x70) == 0x10 && (x & 0x70) == 0x20) > > Should be false always. I suspect you had meant || rather than &&. Sorry, yes; I got the examples right, but the bz subject wrong. I've fixed that.
[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867 --- Comment #11 from dhowells at redhat dot com --- I applied the patch to the Fedora cross-gcc-6.1.1 rpm with one minor fixup. Using the example code I added in bug 70825 I now see: : 0: ba 2a 00 00 00 mov$0x2a,%edx 5: b8 17 00 00 00 mov$0x17,%eax a: f0 0f b1 17 lock cmpxchg %edx,(%rdi) e: c3 retq there's now no extraneous store before the locked instruction. And: 000f : f: ba 2a 00 00 00 mov$0x2a,%edx 14: b8 17 00 00 00 mov$0x17,%eax 19: f0 0f b1 17 lock cmpxchg %edx,(%rdi) 1d: c3 retq it now just passes the return value of cmpxchg back directly without potentially putting on and off the stack and maybe jumping round that bit. And: 0043 : 43: ba 2a 00 00 00 mov$0x2a,%edx 48: b8 17 00 00 00 mov$0x17,%eax 4d: f0 0f b1 17 lock cmpxchg %edx,(%rdi) 51: c3 retq where it makes no difference changing how the the return-statements are contructed in C. I've also booted a kernel built with the patched compiler.
[Bug target/71191] aarch64 and others: __atomic_load;arithmetic;__atomic_compare_exchange loops should be able to generate better code with LL/SC-type constructs than a CAS loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71191
--- Comment #6 from dhowells at redhat dot com ---
There are a couple of ways the problem could be reduced in scope. Most of the
constructs that the kernel has that fall into this category are conditional
adds/subtracts:
typedef struct { int counter; } atomic_t;
bool atomic_inc_unless_negative(atomic_t *v)
bool atomic_dec_unless_positive(atomic_t *v)
bool atomic_inc_not_zero(atomic_t *v)
bool atomic_dec_if_positive(atomic_t *v)
bool atomic_add_unless(atomic_t *v, int addend, int unless)
all of which conform to a pattern that looks like:
({
TYPE cur = __atomic_load_n(PTR, __ATOMIC_RELAXED);
TYPE new;
bool added = true;
do {
if (cur COMPARISON COMPAREND) {
added = false;
break;
}
new = cur + ADDEND;
} while (!__atomic_compare_exchange_n(PTR,
, new,
false,
__ATOMIC_SEQ_CST,
__ATOMIC_RELAXED));
added;
})
where PTR is a pointer to the memory variable to be modified, TYPE is the type
of *PTR, ADDEND and COMPAREND are integer values and COMPARISON is a numeric
comparison. Then there's:
bool atomic_inc_not_zero_hint(atomic_t *v, int hint)
This is similar to the above, except that hint is used in place of the initial
__atomic_load_n(). Note that if you're doing LL/SC rather than a CAS loop, the
hint is of no interest.
And then there is:
int __atomic_add_unless(atomic_t *v, int addend, int unless)
which returns the original value of v->counter instead of an indication as to
the success. I would probably replace this with something like:
bool atomic_add_unless_return(atomic_t *v, int addend, int unless, int
*_orig)
and return the original value of v->counter through the *_orig so that it
conforms more closely with the pattern above.
So the two ways to reduce the scope of the problem that I'm thinking of are:
(1) Add very restricted patterns. Just a single comparison and an add.
(2) Add extra intrinsics. I presume there would need to be one per
comparison:
bool __atomic_fetch_add_if_eq(T *ptr, T addend, T comparend, T *_orig,
int memorder_yes, int memorder_no);
bool __atomic_fetch_add_if_ne(...);
bool __atomic_fetch_add_if_lt(...);
bool __atomic_fetch_add_if_le(...);
bool __atomic_fetch_add_if_gt(...);
bool __atomic_fetch_add_if_ge(...);
[Bug target/71191] aarch64 and others: __atomic_load;arithmetic;__atomic_compare_exchange loops should be able to generate better code with LL/SC-type constructs than a CAS loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71191 --- Comment #5 from dhowells at redhat dot com --- (In reply to Ramana Radhakrishnan from comment #4) > (In reply to dhowe...@redhat.com from comment #0) > > ... > > If the CPU has LL/SC constructs available, something like this is probably > > better implemented using that than a CMPXCHG loop - _provided_ the bit > > between the __atomic_load and the __atomic_compare_exchange doesn't resolve > > to more than a few instructions > > Making the compiler deal with "doesn't resolve to more than a few > instructions" and dealing with architecture restrictions will be the fun > part here. > > It's architecture specific as to what can or cannot go into the loop. On > AArch64 there are restrictions on what kind of instructions can go into > these LL/SC loops using the exclusive instructions i.e. the LDAXR / STLXR > instructions. For e.g. these loops cannot contain other loads and stores > and we work pretty hard to make sure that there is no accidental spilling > inside these loops. See PR69904 for an example of where an optimization was > skirting on the edges of the architecture - aarch32 is quite similar to > aarch64 in this respect. I agree that this won't be easy. I'm quite okay with it being limited to only arithmetic instructions and branches out of the protected section (and definitely no memory accesses). Further, defining what is meant by a "few instructions" I can see is also tricky. > This is probably a bit harder to do in a generic manner rather than just > adding combine patterns as we will be doing that in the backend till kingdom > come. Adding some set patterns might well suffice. Something approximating add-unless would be really good as the kernel uses that a lot. > I'm leaving this as a target bug for now and marking it as relevant to both > the backends but I suspect this affects other architectures too that have > LL/SC style atomics. powerpc64 definitely.
[Bug target/71191] aarch64 and others: __atomic_load;arithmetic;__atomic_compare_exchange loops should be able to generate better code with LL/SC-type constructs than a CAS loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71191 --- Comment #3 from dhowells at redhat dot com --- Created attachment 38522 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38522=edit atomic_add_unless() test code Here's a .c file containing the C code I referenced.
[Bug target/71191] New: aarch64 and others: __atomic_load;arithmetic;__atomic_compare_exchange loops should be able to generate better code with LL/SC-type constructs than a CAS loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71191
Bug ID: 71191
Summary: aarch64 and others:
__atomic_load;arithmetic;__atomic_compare_exchange
loops should be able to generate better code with
LL/SC-type constructs than a CAS loop
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
In the kernel, we have various bits of code that boil down to:
int cur = __atomic_load_n(>counter, __ATOMIC_RELAXED);
int new;
do {
new = do_something_to cur;
} while (!__atomic_compare_exchange_n(>counter,
, new,
false,
__ATOMIC_SEQ_CST,
__ATOMIC_RELAXED));
and:
int cur = __atomic_load_n(>counter, __ATOMIC_RELAXED);
int new;
do {
if (new == not_this_value)
break;
new = do_something_to cur;
} while (!__atomic_compare_exchange_n(>counter,
, new,
false,
__ATOMIC_SEQ_CST,
__ATOMIC_RELAXED));
For example:
static __always_inline int __atomic_add_unless(atomic_t *v,
int addend, int unless)
{
int cur = __atomic_load_n(>counter, __ATOMIC_RELAXED);
int new;
do {
if (__builtin_expect(cur == unless, 0))
break;
new = cur + addend;
} while (!__atomic_compare_exchange_n(>counter,
, new,
false,
__ATOMIC_SEQ_CST,
__ATOMIC_RELAXED));
return cur;
}
int test_atomic_add_unless(atomic_t *counter)
{
return __atomic_add_unless(counter, 0x56, 0x23);
}
If the CPU has LL/SC constructs available, something like this is probably
better implemented using that than a CMPXCHG loop - _provided_ the bit between
the __atomic_load and the __atomic_compare_exchange doesn't resolve to more
than a few instructions
So, using armv8-a as an example, the test_atomic_add_unless() function above
compiles to:
test_atomic_add_unless:
sub sp, sp, #16 # unnecessary
ldr w1, [x0]# __atomic_load_n()
str w1, [sp, 12]# bug 70825
.L5:
ldr w1, [sp, 12]# bug 70825
cmp w1, 35
beq .L4
ldr w3, [sp, 12]# bug 70825
add w1, w1, 86
.L7:
ldaxr w2, [x0]# }
cmp w2, w3 # } __atomic_compare_exchange()
bne .L8 # }
stlxr w4, w1, [x0]# }
cbnzw4, .L7 # }
.L8:
beq .L4
str w2, [sp, 12]# bug 70825
b .L5
.L4:
ldr w0, [sp, 12]# bug 70825
add sp, sp, 16 # unnecessary
ret
Removing the bits added by gcc by bug 70825 and using registers throughout,
this can be reduced to:
test_atomic_add_unless:
ldr w1, [x0]# __atomic_load_n()
.L5:
cmp w1, 35
beq .L4
add w2, w1, 86
mov w3, w1
.L7:
ldaxr w1, [x0]# }
cmp w1, w3 # } __atomic_compare_exchange()
bne .L5 # }
stlxr w4, w2, [x0]# }
cbnzw4, .L7 # }
.L4:
mov w1, w0
ret
However, the atomic load, the arithmetic and the compare exchange can be
condensed further by moving the arithmetic inside the LL/SC section:
test_atomic_add_unless:
.L7:
ldaxr w1, [x0]# __atomic_load_n()
cmp w1, 35 # } if (cur == unless)
[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153 --- Comment #8 from dhowells at redhat dot com --- (In reply to Andrew Pinski from comment #7) > Created attachment 38509 [details] > Full fix which needs full testing This is looking good: 0058 : 58: 12001403and w3, w0, #0x3f 5c: 9346fc02asr x2, x0, #6 60: d2800020mov x0, #0x1// #1 64: 8b020c21add x1, x1, x2, lsl #3 68: 9ac32000lsl x0, x0, x3 6c: f8601020ldclrl x0, x0, [x1] 70: d65f03c0ret 0074 : 74: d2a00801mov x1, #0x40 // #4194304 78: f8611001ldclrl x1, x1, [x0] 7c: d65f03c0ret
[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244
--- Comment #20 from dhowells at redhat dot com ---
Here's a further underoptimisation with -Os:
bool foo_test_and_change_bit(unsigned long *p)
{
return test_and_change_bit(83, p);
}
is compiled to:
0015 :
15: f0 48 0f ba 7f 08 13lock btcq $0x13,0x8(%rdi)
1c: 0f 92 c0setb %al
1f: c3 retq
However, the bit number on BTCQ is an imm8, so the displacement on the memory
operand is unnecessary if the bit number will fit inside the imm8.
[Bug target/71162] New: powerpc64 __atomics should probably emit bne- after stdcx.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71162
Bug ID: 71162
Summary: powerpc64 __atomics should probably emit bne- after
stdcx.
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
On powerpc64, __atomic_fetch_or(), for example, emits a BNE instruction after
the STDCX. instruction to work out whether it needs to retry. For example,
compiling this:
static __always_inline
bool iso_test_and_set_bit(long bit, volatile unsigned long *addr, int memorder)
{
unsigned long mask = 1UL << (bit & (64 - 1));
unsigned long old;
addr += bit >> 6;
old = __atomic_fetch_or(addr, mask, memorder);
return old & mask;
}
long iso_t_a_s(long bit, volatile unsigned long *addr)
{
return iso_test_and_set_bit(bit, addr, __ATOMIC_SEQ_CST);
}
produces this:
00e4 <.iso_t_a_s>:
e4: 7c 00 04 ac hwsync
e8: 54 6a 06 be clrlwi r10,r3,26
ec: 7c 63 36 74 sradi r3,r3,6
f0: 39 20 00 01 li r9,1
f4: 78 63 1f 24 rldicr r3,r3,3,60
f8: 7d 29 50 36 sld r9,r9,r10
fc: 7c 84 1a 14 add r4,r4,r3
100: 7c 60 20 a8 ldarx r3,0,r4
104: 7c 6a 4b 78 or r10,r3,r9
108: 7d 40 21 ad stdcx. r10,0,r4
10c: 40 82 ff f4 bne 100 <.iso_t_a_s+0x1c>
110: 4c 00 01 2c isync
114: 7d 29 18 38 and r9,r9,r3
118: 30 69 ff ff addic r3,r9,-1
11c: 7c 63 49 10 subfe r3,r3,r9
120: 4e 80 00 20 blr
with gcc-6.1.1 targetted at powerpc64-linux-gnu and -Os.
Hopefully the need to retry is unlikely, so BNE- should probably be emitted
rather than BNE.
[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153 --- Comment #4 from dhowells at redhat dot com --- That looks better here: 007c : 7c: d2a00801mov x1, #0x40 // #4194304 80: f8611001ldclrl x1, x1, [x0] 84: d65f03c0ret But foo_clear_bit_unlock() still contains the double MVN instructions. From the patch you posted, I take it that only affects constant integer parameters.
[Bug target/71153] aarch64 __atomic_fetch_and() generates probably incorrect double inversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153 --- Comment #1 from dhowells at redhat dot com --- (In reply to dhowe...@redhat.com from comment #0) > ... If nothing else, the MOVN and MOV could be condensed into just a MOV. ... The MOVN and the MVN could be condensed, that is.
[Bug target/71153] New: aarch64 __atomic_fetch_and() generates probably incorrect double inversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153
Bug ID: 71153
Summary: aarch64 __atomic_fetch_and() generates probably
incorrect double inversion
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
Compiling this code:
static __always_inline
void clear_bit_unlock(long bit, volatile unsigned long *addr)
{
unsigned long mask = 1UL << (bit & (64 - 1));
addr += bit >> 6;
__atomic_fetch_and(addr, ~mask, __ATOMIC_RELEASE);
}
void bar_clear_bit_unlock(unsigned long *p)
{
clear_bit_unlock(22, p);
}
for aarch64-linux-gnu with "-march=armv8-a+lse -Os" generates a double negation
of the mask value in the assembly:
007c :
7c: 92a00801mov x1, #0xffbf // #-4194305
80: aa2103e1mvn x1, x1
84: f8611001ldclrl x1, x1, [x0]
88: d65f03c0ret
The instruction at 7c is loading an inverted value into x1 (it's actually a
MOVN instruction according to the opcode table that I can find); the value in
x1 is then inverted *again* by the MVN instruction.
Now, I can't find a description of how the LDCLRL instruction works, so I can't
say that it doesn't invert the parameter a third time (ie. apply an A AND-NOT B
operation), but it looks suspicious. If nothing else, the MOVN and MOV could
be condensed into just a MOV.
If a parameter is used instead of a constant:
void foo_clear_bit_unlock(long bit, unsigned long *p)
{
clear_bit_unlock(bit, p);
}
then two MVN instructions are generated:
0048 :
48: 12001403and w3, w0, #0x3f
4c: 9346fc02asr x2, x0, #6
50: d2800020mov x0, #0x1// #1
54: 8b020c21add x1, x1, x2, lsl #3
58: 9ac32000lsl x0, x0, x3
5c: aa2003e0mvn x0, x0
60: aa2003e2mvn x2, x0
64: f8621022ldclrl x2, x2, [x1]
68: d65f03c0ret
The C code appears to be correct, because on x86_64 it generates:
004c :
4c: f0 48 81 27 ff ff bflock andq $0xffbf,(%rdi)
53: ff
54: c3 retq
[Bug target/70973] x86: Can the __atomic_*() operations be made to list the LOCK prefixes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70973 --- Comment #1 from dhowells at redhat dot com --- There may be space that can be used in the memorder parameter: "The memory order parameter is a signed int, but only the lower 16 bits are reserved for the memory order. The remainder of the signed int is reserved for target use and should be 0. Use of the predefined atomic values ensures proper usage."
[Bug target/70973] New: x86: Can the __atomic_*() operations be made to list the LOCK prefixes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70973 Bug ID: 70973 Summary: x86: Can the __atomic_*() operations be made to list the LOCK prefixes? Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dhowells at redhat dot com Target Milestone: --- When generating x86 code, the Linux kernel constructs a list of the LOCK prefixes it applies to inline assembly-coded atomic operations. This allows the LOCK prefixes to be NOP'd out if there's only one CPU online. Would it be possible to duplicate this in gcc? What the kernel does is this: #ifdef CONFIG_SMP #define LOCK_PREFIX_HERE \ ".pushsection .smp_locks,\"a\"\n" \ ".balign 4\n" \ ".long 671f - .\n" /* offset */ \ ".popsection\n" \ "671:" #define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock; " #else /* ! CONFIG_SMP */ #define LOCK_PREFIX_HERE "" #define LOCK_PREFIX "" #endif placing a 32-bit relative pointer in the .smp_locks section (we're assuming that .smp_locks isn't going to be more than 2G away from the .text section). Note, however, some LOCK prefixes apparently cannot be dispensed with, so the listing cannot be unconditional via a command-line flag. Would it be possible to provide a constant to OR with the memorder parameter to flag that this atomic op should be listed in .smp_locks? E.g.: orig = __atomic_fetch_or(ptr, mask, __ATOMIC_ACQUIRE | __ATOMIC_RECORD_LOCK); This might also be useful in userspace. So, for example, pthread initialisation could replace a bunch of NOPs with a bunch of LOCKs so that single-threaded processes don't get a performance penalty from LOCKed instructions.
[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244 --- Comment #18 from dhowells at redhat dot com --- (In reply to Paolo Bonzini from comment #16) > > This also suggests there's an error in the current x86_64 kernel > > implementation > > as the kernel bitops are supposed to operate on machine word-size > > locations, so > > it should be using BTSQ not BTSL > > Why? Since bts adjust the memory address according to the bit number, btsl > and btsq are entirely the same instruction. Actually, no. BTSL takes a 32-bit bit number, whereas BTSQ takes a 64-bit bit number if I read the manual correctly. So, since test_and_set_bit() in the kernel takes a long bit number, BTSQ is the right thing to use. In practice, I don't imagine this is likely to be a real problem. I don't envision it as being likely that we will ever have a contiguous bitmap with >=2^31 bits in it.
[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244 --- Comment #17 from dhowells at redhat dot com --- (In reply to Paolo Bonzini from comment #16) > > ... > > it should be using BTSQ not BTSL > > Why? Since bts adjust the memory address according to the bit number, btsl > and btsq are entirely the same instruction. I suppose that's fair - the actual implementation is entirely up to the arch. Should Jakub's optimisation patch be fixed to generate BT?L rather than BT?Q instructions?
[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244 --- Comment #14 from dhowells at redhat dot com --- Okay, I built and booted an x86_64 kernel that had the XXX_bit() and test_and_XXX_bit() ops altered to use __atomic_fetch_YYY() funcs. The core kernel ended up ~8K larger in the .text segment. Examining ext4_resize_begin() as an example, this statement: if (test_and_set_bit_lock(EXT4_RESIZING, _SB(sb)->s_resize_flags)) ret = -EBUSY; looks like this in the unpatched kernel: 0x812169f3 <+122>: lock btsl $0x0,0x3b8(%rax) 0x812169fc <+131>: jb 0x81216a02 0x812169fe <+133>: xor%edx,%edx 0x81216a00 <+135>: jmp0x81216a07 0x81216a02 <+137>: mov$0xfff0,%edx 0x81216a07 <+142>: mov%edx,%eax and like this in the patched kernel: 0x81217414 <+122>: xor%edx,%edx 0x81217416 <+124>: lock btsq $0x0,0x3b8(%rax) 0x81217420 <+134>: setb %dl 0x81217423 <+137>: neg%edx 0x81217425 <+139>: and$0xfff0,%edx 0x81217428 <+142>: mov%edx,%eax So it looks good here at least:-) This also suggests there's an error in the current x86_64 kernel implementation as the kernel bitops are supposed to operate on machine word-size locations, so it should be using BTSQ not BTSL - which would make the __atomic_fetch_or() variant a byte shorter - and involving no conditional jumps.
[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244
--- Comment #13 from dhowells at redhat dot com ---
Very nice:-)
There are a couple of under optimisations yet. Firstly:
#define BITS_PER_LONG (sizeof(long) * 8)
#define _BITOPS_LONG_SHIFT 6
static __always_inline bool test_and_change_bit(long bit, volatile unsigned
long *ptr)
{
unsigned long mask = 1UL << (bit & (BITS_PER_LONG - 1));
unsigned long old;
ptr += bit >> _BITOPS_LONG_SHIFT;
old = __atomic_fetch_xor(ptr, mask, __ATOMIC_SEQ_CST);
return old & mask;
}
bool change_bit_3(unsigned long *p, long n)
{
return test_and_change_bit(n, p);
}
is compiled to:
0048 :
48: 48 89 f0mov%rsi,%rax
4b: 83 e6 3fand$0x3f,%esi
4e: 48 c1 f8 06 sar$0x6,%rax
52: f0 48 0f bb 34 c7 lock btc %rsi,(%rdi,%rax,8)
58: 0f 92 c0setb %al
5b: c3 retq
on x86, lines 48-4e are redundant as the btc instruction will do that for you.
I don't know whether it's more efficient this way or not, though.
Secondly:
static __always_inline bool test_bit(long bit, const unsigned long *ptr)
{
unsigned long mask = 1UL << (bit & (BITS_PER_LONG - 1));
unsigned long old;
ptr += bit >> _BITOPS_LONG_SHIFT;
old = __atomic_load_n(ptr, __ATOMIC_RELAXED);
return old & mask;
}
bool read_bit(unsigned long *p)
{
return test_bit(3, p);
}
is compiled to:
:
0: 48 8b 07mov(%rdi),%rax
3: 48 c1 e8 03 shr$0x3,%rax
7: 83 e0 01and$0x1,%eax
a: c3 retq
but could actually be either a TEST instruction or a BT instruction.
Still, thanks very much for looking at this!
[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244 --- Comment #10 from dhowells at redhat dot com --- A partial optimisation could be made if the mask is constant and only contains one bit (or/xor) or only lacks one bit (and). That is the most common case in the kernel by far, but it would still leave instances where the bit number is dynamic.
[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244 --- Comment #9 from dhowells at redhat dot com --- > BTW: A low-hanging fruit in this area would be using new asm flags feature, Heh - I remember asking for that years ago and being told it couldn't be done.
[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244
--- Comment #7 from dhowells at redhat dot com ---
We should also be able to reduce:
bool
test_bit (int *a, int bit)
{
uint mask = (1u << bit);
return (__atomic_load_n (a, __ATOMIC_xxx) & mask) != 0;
}
to a BT instruction on x86.
[Bug target/70821] x86_64: __atomic_fetch_add/sub() uses XADD rather than DECL in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70821 --- Comment #4 from dhowells at redhat dot com --- The patch works, thanks: 001c : 1c: f0 ff 0flock decl (%rdi) 1f: ba 00 00 00 00 mov$0x0,%edx 24: b8 00 00 00 00 mov$0x0,%eax 29: 48 0f 44 c2 cmove %rdx,%rax 2d: c3 retq
[Bug target/70821] x86_64: __atomic_fetch_add/sub() uses XADD rather than DECL in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70821 --- Comment #3 from dhowells at redhat dot com --- Yes, I'm testing with -Os.
[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244 --- Comment #6 from dhowells at redhat dot com --- I'm looking to implement Linux kernel atomics with C++-11 intrinsics, so being able to reduce a CMPXCHG-loop to BTR/BTS/BTC would be really handy.
[Bug target/70825] New: x86_64: __atomic_compare_exchange_n() accesses stack unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70825
Bug ID: 70825
Summary: x86_64: __atomic_compare_exchange_n() accesses stack
unnecessarily
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
Created attachment 38349
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38349=edit
Example code
__atomic_compare_exchange_n() stores the 'expected' value and, if not
discarded, the old value on the stack rather than in a register and then may
immediately retrieve the old value from there back into the register from
whence it just came.
For example:
static __always_inline int atomic_cmpxchg(atomic_t *v, int old, int new)
{
int cur = old;
if (__atomic_compare_exchange_n(>counter, , new, false,
__ATOMIC_SEQ_CST,
__ATOMIC_RELAXED))
return cur;
return cur;
}
void test_atomic_cmpxchg(atomic_t *counter)
{
atomic_cmpxchg(counter, 23, 42);
}
produces:
0: ba 2a 00 00 00 mov$0x2a,%edx
5: b8 17 00 00 00 mov$0x17,%eax
a: c7 44 24 fc 17 00 00movl $0x17,-0x4(%rsp)
11: 00
12: f0 0f b1 17 lock cmpxchg %edx,(%rdi)
16: c3 retq
Note line a where 0x17 is stored at -04(%rsp) unnecessarily (the value is
dicarded). Note also that this value is in %eax at the time and could be saved
from there rather than using an immediate operand.
And then:
int test_atomic_cmpxchg_2(atomic_t *counter)
{
return atomic_cmpxchg(counter, 23, 42);
}
where the value is returned, we get something like:
20: ba 2a 00 00 00 mov$0x2a,%edx
25: b8 17 00 00 00 mov$0x17,%eax
2a: c7 44 24 fc 17 00 00movl $0x17,-0x4(%rsp)
31: 00
32: f0 0f b1 17 lock cmpxchg %edx,(%rdi)
36: 74 04 je 3c <test_atomic_cmpxchg_2+0x1c>
38: 89 44 24 fc mov%eax,-0x4(%rsp)
3c: 8b 44 24 fc mov-0x4(%rsp),%eax
40: c3 retq
In this case, the return value is being constructed on the stack whereas the
value we actually want to return is in %eax at the conclusion of the CMPXCHG,
so lines 2a & 36-3c are redundant.
Changing atomic_cmpxchg() slightly:
static __always_inline int atomic_cmpxchg_B(atomic_t *v, int old, int new)
{
int cur = old;
if (__atomic_compare_exchange_n(>counter, , new, false,
__ATOMIC_SEQ_CST,
__ATOMIC_RELAXED))
--> return old;
return cur;
}
does generate code that's somewhat better:
a0: ba 2a 00 00 00 mov$0x2a,%edx
a5: b8 17 00 00 00 mov$0x17,%eax
aa: c7 44 24 fc 17 00 00movl $0x17,-0x4(%rsp)
b1: 00
b2: f0 0f b1 17 lock cmpxchg %edx,(%rdi)
b6: ba 17 00 00 00 mov$0x17,%edx
bb: 0f 45 d0cmovne %eax,%edx
be: 89 d0 mov%edx,%eax
c0: c3 retq
However, given the fact that old == cur must hold true if the CMPXCHG
succeeded, lines b6-be are redundant. Note that the unnecessary store (line
aa) is still there.
Note that clang does somewhat better than gcc:
50: b9 2a 00 00 00 mov$0x2a,%ecx
55: b8 17 00 00 00 mov$0x17,%eax
5a: f0 0f b1 0f lock cmpxchg %ecx,(%rdi)
5e: c3 retq
5f: 90 nop
See the attached example code which should be compiled to a .s file.
This is the case for all of:
gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
gcc version 6.0.0 20160219 (Red Hat Cross 6.0.0-0.1) (GCC)
gcc version 4.8.5 20150623 (Red Hat 4.8.5-2.x) (GCC)
[Bug target/70823] New: x86_64: __atomic_fetch_and/or/xor() should perhaps use BTR/BTS/BTC if they can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70823
Bug ID: 70823
Summary: x86_64: __atomic_fetch_and/or/xor() should perhaps use
BTR/BTS/BTC if they can
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
Created attachment 38347
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38347=edit
Test source
If given a mask that clears, sets or flips a single bit and the result is
checked for just that bit and reduced to bool, then the __atomic_fetch_and, _or
and _xor functions should consider using BTR, BTS or BTC as appropriate.
So, something like:
static __always_inline bool test_and_set_bit(unsigned bit, unsigned long
*ptr)
{
unsigned long mask = 1UL << (bit & (BITS_PER_LONG - 1));
unsigned long old;
ptr += bit / BITS_PER_LONG;
old = __atomic_fetch_or(ptr, mask, __ATOMIC_SEQ_CST);
return old & mask;
}
where the mask is constructed by 1UL << bitnr. As things stand, for the
example above, the result ends up with a CMPXCHG loop rather a BTS instruction:
b: 89 f9 mov%edi,%ecx
d: ba 01 00 00 00 mov$0x1,%edx
12: c1 ef 06shr$0x6,%edi
15: 48 d3 e2shl%cl,%rdx
18: 89 f9 mov%edi,%ecx
1a: 48 8b 04 ce mov(%rsi,%rcx,8),%rax
1e: 49 89 c0mov%rax,%r8
21: 48 89 c7mov%rax,%rdi
24: 49 09 d0or %rdx,%r8
27: f0 4c 0f b1 04 ce lock cmpxchg %r8,(%rsi,%rcx,8)
2d: 75 ef jne1e <set_bit+0x13>
2f: 48 85 fatest %rdi,%rdx
32: 0f 95 c0setne %al
35: c3 retq
Could we instead get something like:
bts%edi,(%rsi)
setne %al
retq
See the attached test source which should be compiled to a .s file.
This is the case for all of:
gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
gcc version 6.0.0 20160219 (Red Hat Cross 6.0.0-0.1) (GCC)
gcc version 4.8.5 20150623 (Red Hat 4.8.5-2.x) (GCC)
[Bug target/70821] New: x86_64: __atomic_fetch_add/sub() uses XADD rather than DECL in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70821
Bug ID: 70821
Summary: x86_64: __atomic_fetch_add/sub() uses XADD rather than
DECL in some cases
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
Created attachment 38346
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38346=edit
Test program
__atomic_fetch_add/sub() uses XADD rather than DECL when subtracting 1 from the
counter if the result is acted upon, but where this could be done through the
condition flags. For instance:
static __always_inline bool atomic_sub_and_test(int i, atomic_t *v)
{
return __atomic_sub_fetch(>counter, i, __ATOMIC_SEQ_CST);
}
const char *test_atomic_dec_and_test(atomic_t *counter)
{
if (atomic_sub_and_test(1, counter))
return "foo";
return "bar";
}
produces:
17: 83 c8 ffor $0x,%eax
1a: f0 0f c1 07 lock xadd %eax,(%rdi)
1e: ba 00 00 00 00 mov$0x0,%edx
23: ff c8 dec%eax
25: b8 00 00 00 00 mov$0x0,%eax
2a: 48 0f 44 c2 cmove %rdx,%rax
2e: c3 retq
when it should produce something more like this, which I get when adding 1
instead of subtracting 1, but with a DECL rather than an INCL:
46: f0 ff 07lock incl (%rdi)
49: ba 00 00 00 00 mov$0x0,%edx
4e: b8 00 00 00 00 mov$0x0,%eax
53: 48 0f 44 c2 cmove %rdx,%rax
57: c3 retq
Note that adding or subtracting 2 and testing the zeroness of the result gives
SUBL/ADDL as expected. If the result is not tested, DECL is generated as
expected:
13: f0 ff 0flock decl (%rdi)
16: c3 retq
See the attached test program.
This is the case for both:
gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
gcc version 6.0.0 20160219 (Red Hat Cross 6.0.0-0.1) (GCC)
The following version of gcc:
gcc version 4.8.5 20150623 (Red Hat 4.8.5-2.x) (GCC)
also produces XADD rather than INCL/DECL/ADDL/SUBL if the result is looked at
at all.
[Bug rtl-optimization/69764] [5 Regression] ICE on x86_64-linux-gnu at -O0 (in decompose, at rtl.h:2107)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69764 dhowells at redhat dot com changed: What|Removed |Added CC||dhowells at redhat dot com --- Comment #15 from dhowells at redhat dot com --- (In reply to Andreas Schwab from comment #7) > ... > In file included from ../../../libgcc/libgcc2.c:56:0: > ../../../libgcc/libgcc2.c: In function ‘__mulvsi3’: > ../../../libgcc/libgcc2.h:208:19: internal compiler error: in > maybe_legitimize_operand, at optabs.c:6893 > #define __NW(a,b) __ ## a ## si ## b >^ > ../../../libgcc/libgcc2.h:299:19: note: in expansion of macro ‘__NW’ > #define __mulvSI3 __NW(mulv,3) >^~~~ > ../../../libgcc/libgcc2.c:152:1: note: in expansion of macro ‘__mulvSI3’ > __mulvSI3 (Wtype a, Wtype b) > ^ > 0x9ab2ce maybe_legitimize_operand > ../../gcc/optabs.c:6893 > ... I'm seeing exactly this backtrace also building Fedora the cross-gcc-6 m68k target, but the error goes away with the patch from bug 69885.
[Bug target/69747] c6x cross-compiler fails with "Error: inconsistent uses of .cfi_sections"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69747 --- Comment #3 from dhowells at redhat dot com --- Hmmm... It works with binutils-2.25, so it looks like it may be.
[Bug target/69747] c6x cross-compiler fails with "Error: inconsistent uses of .cfi_sections"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69747
--- Comment #5 from dhowells at redhat dot com ---
The consistency check in the binutils source code:
if (cfi_sections_set && cfi_sections != sections)
as_bad (_("inconsistent uses of .cfi_sections"));
is added between 2.25 and 2.26 by commit:
commit 2f0c68f23bb3132cd5ac466ca8775c0d9e4960cd
Author: Catherine Moore <c...@codesourcery.com>
Date: Thu May 28 14:50:36 2015 -0700
Compact EH Support
so it looks like gcc is at fault.
[Bug target/69747] c6x cross-compiler fails with "Error: inconsistent uses of .cfi_sections"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69747 --- Comment #4 from dhowells at redhat dot com --- OTOH, looking at the output from gcc, I see: ... .cfi_sections .debug_frame .align 2 .global main .cfi_sections .debug_frame, .c6xabi.exidx ... binutils-2.25 is okay with this. If I add ", .c6xabi.exidx" to the end of the first .cfi_sections directive, binutils-2.26 is okay also. It may be that binutils has got more strict and this is actually a gcc bug.
[Bug target/69747] c6x cross-compiler fails with "Error: inconsistent uses of .cfi_sections"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69747 --- Comment #1 from dhowells at redhat dot com --- This gcc also fails: %global DATE 20160205 %global SVNREV 233185 %global gcc_version 6.0.0
[Bug target/69750] New: ICE in sh64 targetted gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69750
Bug ID: 69750
Summary: ICE in sh64 targetted gcc-6
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
When cross-building gcc-6 for sh64, the builds fail when configuring libgcc
with an ICE. This can be replicated by running the following command in the
build directory:
echo 'int main() { return 0; }' | ./gcc/xgcc -x c -c -g - -B ./gcc
-fexceptions
The gcc being built is the following:
%global DATE 20160205
%global SVNREV 233185
%global gcc_version 6.0.0
gcc is configured as follows:
CC=gcc \
CXX=g++ \
CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic' \
+echo ' -O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \
+sed 's/ -Wall / /g;s/ -fexceptions / /g' \
+sed 's/ -Werror=format-security / -Wformat -Werror=format-security /' \
CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/sh64-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/sh64-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/sh64-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/sh64-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/sh64-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/sh64-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/sh64-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/sh64-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/sh64-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/sh64-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/sh64-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-6.0.0-20160205/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmpx --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads
--with-ld=/usr/bin/sh64-linux-gnu-ld --enable-__cxa_atexit
--enable-checking=release --enable-gnu-unique-object --enable-initfini-array
--enable-languages=c,c+--enable-linker-build-id --enable-lto --enable-nls
--enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=sh64-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=sh64-linux-elf --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-isl --with-linker-hash-style=gnu --with-newlib
--with-plugin-ld=/usr/bin/sh64-linux-gnu-ld
--with-sysroot=/usr/sh64-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers
--with-multilib-list=m5-32media,m5-32media-nofpu,m5-compact,m5-compact-nofpu,m5-64media,m5-64media-nofpu
The binutils is binutils-2.26 configured for the same target.
[Bug target/69747] New: c6x cross-compiler fails with "Error: inconsistent uses of .cfi_sections"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69747
Bug ID: 69747
Summary: c6x cross-compiler fails with "Error: inconsistent
uses of .cfi_sections"
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
When building both gcc-5.3.1 and gcc-6 for c6x, the builds fail when
configuring libgcc with the following error:
/tmp/cc6wIVaX.s: Assembler messages:
/tmp/cc6wIVaX.s:12: Error: inconsistent uses of .cfi_sections
This can be tested in the build tree with:
echo 'int main() { return 0; }' | ./gcc/xgcc -x c -c -g - -B ./gcc
-fexceptions
The gcc being built is the following:
%global DATE 20151207
%global SVNREV 231358
%global gcc_version 5.3.1
gcc is configured as follows:
CC=gcc \
CXX=g++ \
CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic' \
CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic ' \
CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \
AR_FOR_TARGET=/usr/bin/c6x-linux-gnu-ar \
AS_FOR_TARGET=/usr/bin/c6x-linux-gnu-as \
DLLTOOL_FOR_TARGET=/usr/bin/c6x-linux-gnu-dlltool \
LD_FOR_TARGET=/usr/bin/c6x-linux-gnu-ld \
NM_FOR_TARGET=/usr/bin/c6x-linux-gnu-nm \
OBJDUMP_FOR_TARGET=/usr/bin/c6x-linux-gnu-objdump \
RANLIB_FOR_TARGET=/usr/bin/c6x-linux-gnu-ranlib \
READELF_FOR_TARGET=/usr/bin/c6x-linux-gnu-readelf \
STRIP_FOR_TARGET=/usr/bin/c6x-linux-gnu-strip \
WINDRES_FOR_TARGET=/usr/bin/c6x-linux-gnu-windres \
WINDMC_FOR_TARGET=/usr/bin/c6x-linux-gnu-windmc \
LDFLAGS='-Wl,-z,relro ' \
../gcc-5.3.1-20151207/configure --bindir=/usr/bin
--build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float
--disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp
--disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libunwind-exceptions --disable-shared --disable-silent-rules
--disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/c6x-linux-gnu-ld
--enable-__cxa_atexit --enable-checking=release --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++
--enable-linker-build-id --enable-lto --enable-nls --enable-obsolete
--enable-plugin --enable-targets=all --exec-prefix=/usr
--host=x86_64-redhat-linux-gnu --includedir=/usr/include
--infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var
--mandir=/usr/share/man --prefix=/usr --program-prefix=c6x-linux-gnu-
--sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc
--target=c6x-uclinux --with-bugurl=http://bugzilla.redhat.com/bugzilla/
--with-isl --with-linker-hash-style=gnu --with-newlib
--with-plugin-ld=/usr/bin/c6x-linux-gnu-ld
--with-sysroot=/usr/c6x-linux-gnu/sys-root --with-system-libunwind
--with-system-zlib --without-headers
The binutils is binutils-2.26 configured for the same target.
[Bug target/69750] ICE in sh64 targetted gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69750 --- Comment #1 from dhowells at redhat dot com --- Doing gdb ./gcc/cc1 and running it with: r -quiet foo.c -g -fexceptions -o /tmp/cc5gm5ki.s shows the failure as: Program received signal SIGSEGV, Segmentation fault. _IO_vfprintf_internal (s=s@entry=0x7bfff4e0, format=format@entry=0xea2d7b "*%s%s%ld", ap=ap@entry=0x7bfff608) at vfprintf.c:1311 1311 f = lead_str_end = __find_specmb ((const UCHAR_T *) format); Asking for a backtrace gives at least 6000 entries, starting like this: #0 _IO_vfprintf_internal (s=s@entry=0x7bfff4e0, format=format@entry=0xea2d7b "*%s%s%ld", ap=ap@entry=0x7bfff608) at vfprintf.c:1311 #1 0x766e488b in __IO_vsprintf (string=0x7bfff7b0 "\004", format=0xea2d7b "*%s%s%ld", args=args@entry=0x7bfff608) at iovsprintf.c:42 #2 0x766c7e57 in __sprintf (s=s@entry=0x7bfff7b0 "\004", format=format@entry=0xea2d7b "*%s%s%ld") at sprintf.c:32 #3 0x00b716f4 in force_const_mem (mode=mode@entry=SImode, x=x@entry=0x7fffea163e70) at ../../gcc-6.0.0-20160205/gcc/varasm.c:3732 #4 0x006cdc43 in emit_move_insn (x=x@entry=0x7fffea163eb8, y=y@entry=0x7fffea163e70) at ../../gcc-6.0.0-20160205/gcc/expr.c:3559 #5 0x006b3c70 in force_reg (mode=mode@entry=SImode, x=x@entry=0x7fffea163e70) at ../../gcc-6.0.0-20160205/gcc/explow.c:631 #6 0x006b490e in force_reg (x=0x7fffea163e70, mode=SImode) at ../../gcc-6.0.0-20160205/gcc/explow.c:451 #7 memory_address_addr_space (mode=SImode, x=0x7fffea163e70, as=) at ../../gcc-6.0.0-20160205/gcc/explow.c:457 #8 0x006a0775 in change_address_1 (memref=0x7fffea163ea0, mode=SImode, mode@entry=VOIDmode, addr=0x7fffea163e70, validate=validate@entry=1, inplace=) at ../../gcc-6.0.0-20160205/gcc/emit-rtl.c:2127 #9 0x006a3880 in replace_equiv_address (memref=, addr=, inplace=inplace@entry=true) at ../../gcc-6.0.0-20160205/gcc/emit-rtl.c:2399 #10 0x006b467a in validize_mem (ref=, ref@entry=0x7fffea163ea0) at ../../gcc-6.0.0-20160205/gcc/explow.c:495 at this point, #4-#10 repeat: #11 0x006cdbbb in emit_move_insn (x=x@entry=0x7fffea163e58, y=0x7fffea163ea0, y@entry=0x7fffea163e10) at ../../gcc-6.0.0-20160205/gcc/expr.c:3582 #12 0x006b3c70 in force_reg (mode=mode@entry=SImode, x=x@entry=0x7fffea163e10) at ../../gcc-6.0.0-20160205/gcc/explow.c:631 #13 0x006b490e in force_reg (x=0x7fffea163e10, mode=SImode) at ../../gcc-6.0.0-20160205/gcc/explow.c:451 #14 memory_address_addr_space (mode=SImode, x=0x7fffea163e10, as=) at ../../gcc-6.0.0-20160205/gcc/explow.c:457 #15 0x006a0775 in change_address_1 (memref=0x7fffea163e40, mode=SImode, mode@entry=VOIDmode, addr=0x7fffea163e10, validate=validate@entry=1, inplace=) at ../../gcc-6.0.0-20160205/gcc/emit-rtl.c:2127 #16 0x006a3880 in replace_equiv_address (memref=, addr=, inplace=inplace@entry=true) at ../../gcc-6.0.0-20160205/gcc/emit-rtl.c:2399 and repeat: #17 0x006b467a in validize_mem (ref=, ref@entry=0x7fffea163e40) at ../../gcc-6.0.0-20160205/gcc/explow.c:495 #18 0x006cdbbb in emit_move_insn (x=x@entry=0x7fffea163df8, ...
[Bug target/68538] New: ICE in gen_reg_rtx, at emit-rtl.c:1027 when cross-compiling for cris-linux-gnu target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68538 Bug ID: 68538 Summary: ICE in gen_reg_rtx, at emit-rtl.c:1027 when cross-compiling for cris-linux-gnu target Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dhowells at redhat dot com Target Milestone: --- Created attachment 36834 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36834=edit Test program I'm getting the following when compiling for a cris-linux-gnu target with gcc-5.2.1: warthog>cris-linux-gnu-gcc -O2 -c output.c output.c: In function ‘cfq_completed_request’: output.c:51:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027 } ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://bugzilla.redhat.com/bugzilla/> for instructions. Preprocessed source stored into /tmp/cc89FntN.out file, please attach this to your bugreport. A testcase is attached.
[Bug target/68538] ICE in gen_reg_rtx, at emit-rtl.c:1027 when cross-compiling for cris-linux-gnu target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68538 --- Comment #1 from dhowells at redhat dot com --- The cross-compiler was built from unpatched gcc sources produced from a gcc SVN branch with the following parameters: DATE 20151104 SVNREV 229753 gcc_version 5.2.1 The compiler was configured as: CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \ CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \ AR_FOR_TARGET=/usr/bin/cris-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/cris-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/cris-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/cris-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/cris-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/cris-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/cris-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/cris-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/cris-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/cris-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/cris-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ ../gcc-5.2.1-20151104/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-nls --disable-plugin --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/cris-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-indirect-function --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=cris-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=cris-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl --with-linker-hash-style=gnu --with-newlib --with-sysroot=/usr/cris-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers And built with: AR_FOR_TARGET=/usr/bin/cris-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/cris-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/cris-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/cris-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/cris-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/cris-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/cris-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/cris-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/cris-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/cris-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/cris-linux-gnu-windmc \ make -C cris-linux-gnu -j5 tooldir=/usr all-gcc make -C cris-linux-gnu -j5 tooldir=/usr all-target-libgcc The binutils was 2.25.1 built as a cross for cris-linux-gnu.
[Bug target/68459] New: ICE when compiling for alpha with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68459 Bug ID: 68459 Summary: ICE when compiling for alpha with -O3 Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dhowells at redhat dot com Target Milestone: --- Created attachment 36782 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36782=edit Reduced test case When compiling the attached test case for alpha-linux-gnu with -O3, the compiler segfaults and produces the following: alpha-linux-gnu-gcc -c -O3 /tmp/bz1265791-testcase.c /tmp/bz1265791-testcase.c: In function ‘synchronize_rcu_tasks’: /tmp/bz1265791-testcase.c:8:6: internal compiler error: Segmentation fault void synchronize_rcu_tasks(void) ^ /usr/libexec/gcc/alpha-linux-gnu/5.2.1/cc1 -quiet -v /tmp/bz1265791-testcase.c -quiet -dumpbase bz1265791-testcase.c -auxbase bz1265791-testcase -O3 -version -o /tmp/ccf0UqVc.s I caught it in gdb: Program received signal SIGSEGV, Segmentation fault. fold_builtin_alloca_with_align (stmt=0x719436c0) at ../../gcc-5.2.1-20150716/gcc/tree-ssa-ccp.c:2067 2067&& TREE_CODE (BLOCK_SUPERCONTEXT (block)) == FUNCTION_DECL)) and I got the following backtrace: #0 fold_builtin_alloca_with_align (stmt=0x719436c0) at ../../gcc-5.2.1-20150716/gcc/tree-ssa-ccp.c:2067 #1 ccp_fold_stmt (gsi=0x7fffd8a0) at ../../gcc-5.2.1-20150716/gcc/tree-ssa-ccp.c:2172 #2 0x00a07c17 in substitute_and_fold_dom_walker::before_dom_children ( this=0x7fffd960, bb=0x7191faf8) at ../../gcc-5.2.1-20150716/gcc/tree-ssa-propagate.c:1177 #3 0x00b8dfe8 in dom_walker::walk (this=0x7fffd960, bb=0x7191faf8) at ../../gcc-5.2.1-20150716/gcc/domwalk.c:188 #4 0x00a0762a in substitute_and_fold ( get_value_fn=get_value_fn@entry=0x9942f0 <get_constant_value(tree)>, fold_fn=fold_fn@entry=0x99bfa0 <ccp_fold_stmt(gimple_stmt_iterator*)>, do_dce=do_dce@entry=true) at ../../gcc-5.2.1-20150716/gcc/tree-ssa-propagate.c:1272 #5 0x00993b41 in ccp_finalize () at ../../gcc-5.2.1-20150716/gcc/tree-ssa-ccp.c:941 #6 do_ssa_ccp () at ../../gcc-5.2.1-20150716/gcc/tree-ssa-ccp.c:2382 #7 (anonymous namespace)::pass_ccp::execute (this=) at ../../gcc-5.2.1-20150716/gcc/tree-ssa-ccp.c:2414 #8 0x0083aa9e in execute_one_pass (pass=pass@entry=0x12221d0) at ../../gcc-5.2.1-20150716/gcc/passes.c:2330 #9 0x0083aeb6 in execute_pass_list_1 (pass=0x12221d0) at ../../gcc-5.2.1-20150716/gcc/passes.c:2382 ---Type to continue, or q to quit--- #10 0x0083aec8 in execute_pass_list_1 (pass=0x1222050, pass@entry=0x1221f90) at ../../gcc-5.2.1-20150716/gcc/passes.c:2383 #11 0x0083af09 in execute_pass_list (fn=0x7193cf18, pass=0x1221f90) at ../../gcc-5.2.1-20150716/gcc/passes.c:2393 #12 0x005fa268 in cgraph_node::expand (this=this@entry=0x7183a300) at ../../gcc-5.2.1-20150716/gcc/cgraphunit.c:1895 #13 0x005fb4ac in expand_all_functions () at ../../gcc-5.2.1-20150716/gcc/cgraphunit.c:2031 #14 symbol_table::compile (this=0x7183c000) at ../../gcc-5.2.1-20150716/gcc/cgraphunit.c:2384 #15 0x005fc8b8 in symbol_table::finalize_compilation_unit ( this=0x7183c000) at ../../gcc-5.2.1-20150716/gcc/cgraphunit.c:2461 #16 0x005114cb in c_write_global_declarations () at ../../gcc-5.2.1-20150716/gcc/c/c-decl.c:10798 #17 0x008d8d55 in compile_file () at ../../gcc-5.2.1-20150716/gcc/toplev.c:613 #18 0x004fde1f in do_compile () at ../../gcc-5.2.1-20150716/gcc/toplev.c:2067 #19 toplev::main (this=this@entry=0x7fffdce0, argc=argc@entry=13, argv=argv@entry=0x7fffdde8) at ../../gcc-5.2.1-20150716/gcc/toplev.c:2165 #20 0x004fe7aa in main (argc=13, argv=0x7fffdde8) at ../../gcc-5.2.1-20150716/gcc/main.c:39
[Bug target/68459] ICE when compiling for alpha with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68459 --- Comment #1 from dhowells at redhat dot com --- The backtrace was obtained from a compiler built from unpatched gcc sources produced from a gcc SVN branch with the following parameters: SVNREV 225895 DATE 20150716 gcc_version 5.2.1 The compiler was configured as follows: CC=gcc \ CXX=g++ \ CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic' \ CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \ CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \ AR_FOR_TARGET=/usr/bin/alpha-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/alpha-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/alpha-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/alpha-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/alpha-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/alpha-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/alpha-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/alpha-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/alpha-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/alpha-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/alpha-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ ../gcc-5.2.1-20150716/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-nls --disable-plugin --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/alpha-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-indirect-function --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=alpha-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=alpha-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl --with-linker-hash-style=gnu --with-newlib --with-sysroot=/usr/alpha-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers The binutils was a 2.25.1 cross hosted on x86_64 and targetted at alpha-linux-gnu.
[Bug target/66491] x86_64 target cross-compiler generates stack protector code unsuitable for the Linux kernel if the compiler wasn't built against a C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66491 --- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com --- Configured with: CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \ CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \ AR_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/x86_64-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/x86_64-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/x86_64-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/x86_64-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/x86_64-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/x86_64-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/x86_64-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/x86_64-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ ../gcc-5.1.1-20150422/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-nls --disable-plugin --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/x86_64-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-indirect-function --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=x86_64-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=x86_64-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-default-libstdcxx-abi=c++98 --with-isl --with-linker-hash-style=gnu --with-newlib --with-sysroot=/usr/x86_64-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers Built with: AR_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/x86_64-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/x86_64-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/x86_64-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/x86_64-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/x86_64-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/x86_64-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/x86_64-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/x86_64-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/x86_64-linux-gnu-windmc \ make -C x86_64-linux-gnu -j5 tooldir=/usr all-gcc make -C x86_64-linux-gnu DESTDIR=/home/dhowells/rpmbuild/BUILDROOT/cross-gcc-5.1.1-2.fc22.x86_64 install-gcc install-target-libgcc The binutils was 2.25 cross-compiled for x86_64.
[Bug target/66491] x86_64 target cross-compiler generates stack protector code unsuitable for the Linux kernel if the compiler wasn't built against a C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66491 --- Comment #2 from dhowells at redhat dot com dhowells at redhat dot com --- Possibly -mcmodel=kernel shouldn't be overloaded, but -fstack-protector should be - perhaps to have a -fstack-protector-gs option or similar.
[Bug target/66491] New: x86_64 target cross-compiler generates stack protector code unsuitable for the Linux kernel if the compiler wasn't built against a C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66491
Bug ID: 66491
Summary: x86_64 target cross-compiler generates stack protector
code unsuitable for the Linux kernel if the compiler
wasn't built against a C library
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
The Fedora gcc-5.1.1 cross-compiler targeting x86_64 doesn't generate
appropriate stack protection code as the compiler wasn't built against glibc.
For example, if the following command is run:
echo int foo(void) { char X[200]; return 3; } |
x86_64-linux-gnu-gcc -S -x c -c -O0 -mcmodel=kernel -fstack-protector - -o -
the code generated refers to __stack_chk_guard:
...
movq__stack_chk_guard(%rip), %rax
movq%rax, -8(%rbp)
xorl%eax, %eax
movl$3, %eax
movq-8(%rbp), %rdx
xorq__stack_chk_guard(%rip), %rdx
je .L3
call__stack_chk_fail
...
but it should instead use the %gs segment register to access the canary:
...
movq%gs:40, %rax
movq%rax, -8(%rbp)
xorl%eax, %eax
movl$3, %eax
movq-8(%rbp), %rdx
xorq%gs:40, %rdx
je .L3
call__stack_chk_fail
...
as is expected by the kernel.
This was originally logged in the Red Hat bugzilla as:
https://bugzilla.redhat.com/show_bug.cgi?id=1228800
The reporter looked into how cross-gcc is built and the problem seems to be
this:
gcc is configured with --without-headers. The configure script checks for
whether the target libc provides SSP (TARGET_LIBC_PROVIDES_SSP). In this case
it will be false.
The definition of TARGET_THREAD_SSP_OFFSET is conditional under #ifdef
TARGET_LIBC_PROVIDES_SSP (in gcc/config/i386/gnu-user64.h), so it will not be
defined.
config/i386/i386.md describes how to generate stack protector code. It will use
TLS canary only if #ifdef TARGET_THREAD_SSP_OFFSET.
As per one of the reporter's suggestions, -mcmodel=kernel should perhaps switch
to the %gs method, overriding anything the gcc selects based on the C library.
[Bug target/66140] ICE at extract_insn, at recog.c:2343 when compiling for alpha with gcc-5.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66140 --- Comment #3 from dhowells at redhat dot com dhowells at redhat dot com --- The compiler works now, thanks!
[Bug target/66140] New: ICE at extract_insn, at recog.c:2343 when compiling for alpha with gcc-5.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66140 Bug ID: 66140 Summary: ICE at extract_insn, at recog.c:2343 when compiling for alpha with gcc-5.1.1 Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dhowells at redhat dot com Target Milestone: --- Created attachment 35539 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35539action=edit Reduced test case I'm seeing the following ICE: alpha-linux-gnu-gcc -O2 -c alpha-reduced.c alpha-reduced.c: In function 'lpfc_bg_scsi_prep_dma_buf_s3': alpha-reduced.c:51:1: error: unrecognizable insn: } ^ (insn 88 87 89 9 (set (reg:DI 3 $3) (mem:DI (and:DI (plus:DI (mem/c:DI (plus:DI (reg/f:DI 30 $30) (const_int 64 [0x40])) [6 %sfp+0 S8 A64]) (const_int 3 [0x3])) (const_int -8 [0xfff8])) [0 S8 A64])) alpha-reduced.c:35 -1 (nil)) alpha-reduced.c:51:1: internal compiler error: in extract_insn, at recog.c:2343 with the attached test case when cross-compiling for alpha with gcc-5.1.1. The compiler is built from SVN rev 222331 dated 20150422 with no patches applied and is running on an x86_64 Linux system. The binutils is 2.25 based. The compiler was configured thus: CC=gcc \ CXX=g++ \ CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic' \ CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \ CFLAGS_FOR_TARGET='-g -O2 -Wall -fexceptions' \ AR_FOR_TARGET=/usr/bin/alpha-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/alpha-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/alpha-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/alpha-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/alpha-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/alpha-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/alpha-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/alpha-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/alpha-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/alpha-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/alpha-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ ../gcc-5.1.1-20150422/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-nls --disable-plugin --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/alpha-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-indirect-function --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=alpha-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=alpha-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl --with-linker-hash-style=gnu --with-newlib --with-sysroot=/usr/alpha-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers and built thus: AR_FOR_TARGET=/usr/bin/alpha-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/alpha-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/alpha-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/alpha-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/alpha-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/alpha-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/alpha-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/alpha-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/alpha-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/alpha-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/alpha-linux-gnu-windmc \ make -C alpha-linux-gnu -j5 tooldir=/usr all-gcc make -C alpha-linux-gnu -j5 tooldir=/usr all-target-libgcc
[Bug target/65052] ICE in c6x-uclinux target when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052 --- Comment #8 from dhowells at redhat dot com dhowells at redhat dot com --- This seems to work for me, thanks!
[Bug target/65649] New: gcc generates overlarge constants for microblaze-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649
Bug ID: 65649
Summary: gcc generates overlarge constants for
microblaze-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Whilst compiling libgcc for microblaze-linux-gnu, gcc produces overlarge
constants that don't fit into a 32-bits (microblaze is a 32-bit arch), eg:
addikr23,r0,0xb746a0003f80
the assembler complains about these:
_powisf2.s:71: Fatal error: operand must be a constant or a label
if it is hosted on a 32-bit arch (eg. i386) but not if it's hosted on a 64-bit
arch (eg. x86_64). This is logged here:
https://sourceware.org/bugzilla/show_bug.cgi?id=18189
However, gcc shouldn't be producing these at all.
Reducing the preprocessed C to the bare function gives:
float __powisf2 (float x, int m)
{
unsigned int n = m 0 ? -m : m;
float y = n % 2 ? x : 1;
while (n = 1)
{
x = x * x;
if (n % 2)
y = y * x;
}
return m 0 ? 1/y : y;
}
Reducing it still further to:
float __powisf2 (float x, int m)
{
unsigned int n = m 0 ? -m : m;
float y = n % 2 ? x : 1;
return y;
}
gives the error _only_ if -g is supplied. Looking at the assembly output of
this, the dodgy instruction is now:
addik r3,r0,0xb745e0003f80
with -g and:
addik r3,r0,0x3f80
without.
The compilation line is:
/root/cross-gcc/gcc-5.0.0-20150319/microblaze-linux-gnu/gcc/xgcc
-B/root/cross-gcc/gcc-5.0.0-20150319/microblaze-linux-gnu/gcc/
-B/usr/microblaze-linux-gnu/bin/ -B/usr/microblaze-linux-gnu/lib/ -O2 -fPIC
-fbuilding-libgcc -fno-exceptions -fno-stack-protector -fvisibility=hidden -o
_powisf2.o -c _powisf2.i --save-temps -g
[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649 --- Comment #2 from dhowells at redhat dot com dhowells at redhat dot com --- gcc was based on the gcc-5.0.0-20150319 tarball generated from the gcc branch redhat/gcc-5-branch plus the patches for the Fedora rawhide gcc and cross-gcc. Configuration was: CC=gcc \ CXX=g++ \ CFLAGS='-O2 -g -Wall -Wformat-security -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=atom -fasynchronous-unwind-tables' \ CXXFLAGS=' -O2 -g -Wformat-security -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=atom -fasynchronous-unwind-tables ' \ CFLAGS_FOR_TARGET='-g -O2 -Wall -fno-exceptions' \ AR_FOR_TARGET=/usr/bin/microblaze-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/microblaze-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/microblaze-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/microblaze-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/microblaze-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/microblaze-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/microblaze-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/microblaze-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/microblaze-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/microblaze-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/microblaze-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ ../gcc-5.0.0-20150319/configure --bindir=/usr/bin --build=i686-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-nls --disable-plugin --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/microblaze-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-indirect-function --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=i686-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=microblaze-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=microblaze-linux-gnu --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-isl --with-linker-hash-style=gnu --with-newlib --with-sysroot=/usr/microblaze-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers And the build: make -C microblaze-linux-gnu -j16 tooldir=/usr all-gcc make -C microblaze-linux-gnu -j16 tooldir=/usr all-target-libgcc The microblaze binutils was binutils-2.25 plus the Fedora F21 patches from the cross-binutils targetted at microblaze-linux-gnu.
[Bug target/65649] gcc generates overlarge constants for microblaze-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649 --- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com --- Created attachment 35201 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35201action=edit Assembler output from larger reduced case Here is the assembler output from the larger reduced case. The dodgy constant occurs on line 71 and also on line 124.
[Bug target/65052] ICE in c6x-uclinux target when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052 --- Comment #6 from dhowells at redhat dot com dhowells at redhat dot com --- Fixed how? Is Nick's patch good?
[Bug c/65052] New: ICE in c6x-uclinux target when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052
Bug ID: 65052
Summary: ICE in c6x-uclinux target when building libgcc
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
When building libgcc using a c6x-uclinux gcc-5 that I've just built, I see the
following ICE:
/data/fedora/cross-gcc/tmp/build/./gcc/xgcc
-B/data/fedora/cross-gcc/tmp/build/./gcc/ -B/usr/c6x-uclinux/bin/
-B/usr/c6x-uclinux/lib/ -isystem /usr/c6x-uclinux/include -isystem
/usr/c6x-uclinux/sys-include-O2 -g -Wall -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-mbig-endian -O2 -O2 -g -Wall -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -msdata=none -msdata=none -fPIC -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -msdata=none
-msdata=none -fPIC -I. -I. -I../../.././gcc
-I../../../../gcc-5.0.0-20150210/libgcc
-I../../../../gcc-5.0.0-20150210/libgcc/.
-I../../../../gcc-5.0.0-20150210/libgcc/../gcc
-I../../../../gcc-5.0.0-20150210/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS
-o _lshrdi3.o -MT _lshrdi3.o -MD -MP -MF _lshrdi3.dep -DL_lshrdi3 -c
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c: In function '__gnu_lshrdi3':
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c:426:1: error: insn does not
satisfy its constraints:
}
^
(insn 86 72 8 2 (cond_exec (eq (reg:SI 0 A0)
(const_int 0 [0]))
(unspec [
(label_ref:SI 36)
(const_int 0 [0])
] UNSPEC_REAL_JUMP))
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c:405 439 {*p real_jump}
(nil))
../../../../gcc-5.0.0-20150210/libgcc/libgcc2.c:426:1: internal compiler error:
in extract_constrain_insn_cached, at recog.c:2258
0x885148 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-5.0.0-20150210/gcc/rtl-error.c:110
0x88516f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-5.0.0-20150210/gcc/rtl-error.c:121
0x85d159 extract_constrain_insn_cached(rtx_insn*)
../../gcc-5.0.0-20150210/gcc/recog.c:2258
0xb0cb77 internal_dfa_insn_code(rtx_insn*)
../../gcc-5.0.0-20150210/gcc/config/c6x/c6x.md:407
0xb0be79 dfa_insn_code
/data/fedora/cross-gcc/tmp/build/gcc/insn-automata.c:735634
0xb0be79 state_transition(void*, rtx_def*)
/data/fedora/cross-gcc/tmp/build/gcc/insn-automata.c:735655
0xbbe910 prune_ready_list
../../gcc-5.0.0-20150210/gcc/haifa-sched.c:6278
0xbbf907 prune_ready_list
../../gcc-5.0.0-20150210/gcc/haifa-sched.c:6193
0xbbf907 schedule_block(basic_block_def**, void*)
../../gcc-5.0.0-20150210/gcc/haifa-sched.c:6604
0xc14e06 schedule_ebb(rtx_insn*, rtx_insn*, bool)
../../gcc-5.0.0-20150210/gcc/sched-ebb.c:557
0xc15516 schedule_ebbs()
../../gcc-5.0.0-20150210/gcc/sched-ebb.c:676
0xb0435b c6x_reorg
../../gcc-5.0.0-20150210/gcc/config/c6x/c6x.c:5998
0x883fb9 execute
../../gcc-5.0.0-20150210/gcc/reorg.c:4064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://bugzilla.redhat.com/bugzilla/ for instructions.
Makefile:466: recipe for target '_lshrdi3.o' failed
make[3]: *** [_lshrdi3.o] Error 1
make[3]: Leaving directory
'/data/fedora/cross-gcc/tmp/build/c6x-uclinux/be/libgcc'
[Bug c/65052] ICE in c6x-uclinux target when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052
--- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com ---
This can be produced by the following minimal source:
typedef int DItype __attribute__ ((mode (DI)));
typedef int shift_count_type __attribute__((mode (__libgcc_shift_count__)));
int __gnu_lshrdi3 (DItype u, shift_count_type b)
{
if (b == 0)
return u;
}
[Bug c/65052] ICE in c6x-uclinux target when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052 --- Comment #3 from dhowells at redhat dot com dhowells at redhat dot com --- The compiler was built as: #!/bin/bash cd /data/fedora/cross-gcc/tmp/ tar xf /tmp/gcc-5.0.0-20150210.tar.bz2 mkdir build cd build CC=gcc \ CXX=g++ \ CFLAGS='-O2 -g -Wall -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic' \ CXXFLAGS=' -O2 -g -Wformat -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -mtune=generic ' \ CFLAGS_FOR_TARGET=' -O2 -g -Wall -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches ' \ AR_FOR_TARGET=/usr/bin/c6x-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/c6x-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/c6x-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/c6x-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/c6x-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/c6x-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/c6x-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/c6x-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/c6x-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/c6x-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/c6x-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ nice -19 ../gcc-5.0.0-20150210/configure \ --bindir=/usr/bin \ --build=x86_64-redhat-linux-gnu \ --datadir=/usr/share \ --disable-decimal-float \ --disable-dependency-tracking \ --disable-gold \ --disable-libgcj \ --disable-libgomp \ --disable-libmudflap \ --disable-libquadmath \ --disable-libssp \ --disable-libunwind-exceptions \ --disable-nls \ --disable-plugin \ --disable-shared \ --disable-silent-rules \ --disable-sjlj-exceptions \ --disable-threads \ --with-ld=/usr/bin/c6x-linux-gnu-ld \ --enable-__cxa_atexit \ --enable-checking=release \ --enable-gnu-indirect-function \ --enable-gnu-unique-object \ --enable-initfini-array \ --enable-languages=c,c++ \ --enable-linker-build-id \ --enable-nls \ --enable-obsolete \ --enable-plugin \ --enable-targets=all \ --exec-prefix=/usr \ --host=x86_64-redhat-linux-gnu \ --includedir=/usr/include \ --infodir=/usr/share/info \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --mandir=/usr/share/man \ --prefix=/usr \ --program-prefix=c6x-linux-gnu- \ --sbindir=/usr/sbin \ --sharedstatedir=/var/lib \ --sysconfdir=/etc \ --target=c6x-uclinux \ --with-bugurl=http://bugzilla.redhat.com/bugzilla/ \ --with-isl \ --with-linker-hash-style=gnu \ --with-newlib \ --with-sysroot=/usr/c6x-linux-gnu/sys-root \ --with-system-libunwind \ --with-system-zlib \ --without-headers echo === BUILDING c6x-linux AR_FOR_TARGET=/usr/bin/c6x-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/c6x-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/c6x-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/c6x-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/c6x-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/c6x-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/c6x-linux-gnu-ranlib \ READELF_FOR_TARGET=/usr/bin/c6x-linux-gnu-readelf \ STRIP_FOR_TARGET=/usr/bin/c6x-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/c6x-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/c6x-linux-gnu-windmc \ nice -19 make tooldir=/usr all-gcc echo === BUILDING LIBGCC c6x-linux nice -19 make tooldir=/bin all-target-libgcc --- binutils-2.25 was used for the cross compiler. The compiler was built with: gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC) binutils-2.24
[Bug c/65052] ICE in c6x-uclinux target when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052 --- Comment #2 from dhowells at redhat dot com dhowells at redhat dot com --- Compiled with: /data/fedora/cross-gcc/tmp/build/./gcc/xgcc -B/data/fedora/cross-gcc/tmp/build/gcc/ -B/usr/c6x-uclinux/bin/ -O2 -c min.i
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111 --- Comment #13 from dhowells at redhat dot com dhowells at redhat dot com --- (In reply to Segher Boessenkool from comment #11) Re: #c7: In sh.c, change char amount[6] to signed char amount[6] -- does that help? That shouldn't make any difference to a compiler hosted on x86_64, as char is signed there by default. Did you mean change it to unsigned char amount[6]?
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111 --- Comment #15 from dhowells at redhat dot com dhowells at redhat dot com --- That fixes the ICE.
[Bug target/61996] [SH] -musermode conflicts with -matomic-model=soft-imask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61996 --- Comment #4 from dhowells at redhat dot com dhowells at redhat dot com --- That seems to work, thanks.
[Bug target/62218] New: gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 Bug ID: 62218 Summary: gcc produces invalid SH instruction (stc r2,sr) when building libgcc Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dhowells at redhat dot com Created attachment 33374 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33374action=edit Reduced test case A gcc build for SH produces an invalid opcode when building libgcc. It produces stc sr,rN when it should produce ldc sr,rN. /data/fedora/cross-gcc/gcc-4.9.1-20140717/sh-linux-gnu/./gcc/xgcc -B/data/fedora/cross-gcc/gcc-4.9.1-20140717/sh-linux-gnu/./gcc/ -B/usr/sh-linux-gnu/bin/ -O2 -mb -fpic -w -Wno-sync-nand -fbuilding-libgcc -o /tmp/linux-atomic.o -c /tmp/linux-atomic.i /tmp/ccHwXin4.s: Assembler messages: /tmp/ccHwXin4.s:19: Error: invalid operands for opcode /tmp/ccHwXin4.s:38: Error: invalid operands for opcode /tmp/ccHwXin4.s:56: Error: invalid operands for opcode Interestingly, if -Wno-sync-nand is removed, I see this: /tmp/linux-atomic.i:7:2: note: ‘__sync_fetch_and_nand’ changed semantics in GCC 4.4 return __sync_fetch_and_nand (x, y, z); in addition. I've attached /tmp/linux-atomic.i as a reduced test case.
[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 --- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com --- Created attachment 33375 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33375action=edit Assembly output from test case
[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 --- Comment #2 from dhowells at redhat dot com dhowells at redhat dot com --- The build is configured thus: AR_FOR_TARGET=/usr/bin/sh-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/sh-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/sh-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/sh-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/sh-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/sh-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/sh-linux-gnu-ranlib \ STRIP_FOR_TARGET=/usr/bin/sh-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/sh-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/sh-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ ../gcc-4.9.1-20140717/configure \ --bindir=/usr/bin \ --build=x86_64-redhat-linux-gnu \ --datadir=/usr/share \ --disable-decimal-float \ --disable-dependency-tracking \ --disable-gold \ --disable-libgomp \ --disable-libmudflap \ --disable-libquadmath \ --disable-libssp \ --disable-nls \ --disable-plugin \ --disable-shared \ --disable-silent-rules \ --disable-sjlj-exceptions \ --disable-threads \ --enable-checking= \ --enable-gnu-unique-object \ --enable-initfini-array \ --enable-languages=c,c++ \ --enable-linker-build-id \ --enable-nls \ --enable-obsolete \ --enable-targets=all \ --exec-prefix=/usr \ --host=x86_64-redhat-linux-gnu \ --includedir=/usr/include \ --infodir=/usr/share/info \ --libexecdir=/usr/libexec \ --localstatedir=/var \ --mandir=/usr/share/man \ --prefix=/usr \ --program-prefix=sh-linux-gnu- \ --sbindir=/usr/sbin \ --sharedstatedir=/var/lib \ --sysconfdir=/etc \ --target=sh-linux-gnu \ --with-bugurl=http://bugzilla.redhat.com/bugzilla/ \ --with-linker-hash-style=gnu \ --with-newlib \ --with-sysroot=/usr/sh-linux-gnu/sys-root \ --with-system-libunwind \ --with-system-zlib \ --without-headers \ --without-isl \ --without-cloog \ '--with-multilib-list=m1,m2,m2e,m4,m4-single,m4-single-only,m2a,m2a-single,!m2a,!m2a-single'
[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 --- Comment #3 from dhowells at redhat dot com dhowells at redhat dot com --- The gcc sources are: %global DATE 20140717 %global SVNREV 212747 %global gcc_version 4.9.1 only one patch is applied, attachment 33366 from bug 61996.
[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 --- Comment #4 from dhowells at redhat dot com dhowells at redhat dot com --- The following multilib subdirs are configured: mb m2 m2e m4 m4-single m4-single-only mb/m2 mb/m2e mb/m4 mb/m4-single mb/m4-single-only mb/m2a mb/m2a-single The problem occurs on the first (mb).
[Bug target/62218] gcc produces invalid SH instruction (stc r2,sr) when building libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218 --- Comment #5 from dhowells at redhat dot com dhowells at redhat dot com --- (In reply to dhowe...@redhat.com from comment #0) A gcc build for SH produces an invalid opcode when building libgcc. It produces stc sr,rN when it should produce ldc sr,rN. Sorry, that should be it produces stc rN,sr when it should produce ldc rN,sr.
[Bug target/61996] [SH] -musermode conflicts with -matomic-model=soft-imask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61996 --- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com --- Is this something I can add to the compiler build without a patch?
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111 --- Comment #6 from dhowells at redhat dot com dhowells at redhat dot com --- (In reply to Kazumoto Kojima from comment #5) ... even though general_extend_operand doesn't permit (truncate (mem ...)). An easy workaround might be to disable truncate in general_extend_operand before reload. --- gcc/config/sh/predicates.md.orig 2014-08-02 11:55:29.228875715 +0900 +++ gcc/config/sh/predicates.md 2014-08-17 08:30:20.439326569 +0900 ... This does appear to fix the ICE's. Unfortunately, it seems the kernel code has bit-rotted too much to get all the way through building.
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111 --- Comment #7 from dhowells at redhat dot com dhowells at redhat dot com --- Having said that, if I use make -k, I can get this: ../drivers/scsi/sd.c: In function 'sd_init_command': ../drivers/scsi/sd.c:1139:1: error: unrecognizable insn: } ^ (insn 1335 1334 9 190 (set (reg/v:DI 336 [ sector ]) (lshiftrt:DI (reg:DI 171 [ D.34693 ]) (const_int -10 [0xfff6]))) ../drivers/scsi/sd.c:707 -1 (nil)) ../drivers/scsi/sd.c:1139:1: internal compiler error: in extract_insn, at recog.c:2202 Do you want it reducing?
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #10 from dhowells at redhat dot com dhowells at redhat dot com ---
This is the reduced test case for comment 7:
extern void string_get_size(unsigned long long size);
void sd_read_capacity(unsigned long long capacity)
{
string_get_size(capacity -1);
}
[Bug target/62111] New: ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
Bug ID: 62111
Summary: ICE when building Linux kernel for sh64
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Created attachment 33303
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33303action=edit
Reduced preprocessed source
When trying to build the kernel with an sh64 cross-compiler, I get the
following error:
sh64-linux-gnu-gcc -Wp,-MD,arch/sh/kernel/.setup.o.d -nostdinc -isystem
/usr/lib/gcc/sh64-linux-elf/4.9.1/include -I../arch/sh/include
-Iarch/sh/include/generated -I../include -Iinclude -I../arch/sh/include/uapi
-Iarch/sh/include/generated/uapi -I../include/uapi -Iinclude/generated/uapi
-include ../include/linux/kconfig.h -I../arch/sh/kernel -Iarch/sh/kernel
-D__KERNEL__ -m5-64media-nofpu -ml -Wa,-isa=shmedia -ffreestanding
-I../arch/sh/include/cpu-sh5 -Iarch/sh/include/cpu-sh5
-I../arch/sh/include/cpu-common -Iarch/sh/include/cpu-common
-I../arch/sh/include/mach-common -Iarch/sh/include/mach-common -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security -pipe
-m5-64media-nofpu -ml -Wa,-isa=shmedia -ffreestanding
-I../arch/sh/include/cpu-sh5 -Iarch/sh/include/cpu-sh5
-I../arch/sh/include/cpu-common -Iarch/sh/include/cpu-common
-I../arch/sh/include/mach-common -Iarch/sh/include/mach-common
-fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0
-Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -Wdeclaration-after-statement -Wno-pointer-sign
-fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO -Werror
-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(setup)
-DKBUILD_MODNAME=KBUILD_STR(setup) -c -o arch/sh/kernel/setup.o
../arch/sh/kernel/setup.c
../arch/sh/kernel/setup.c: In function 'setup_arch':
../arch/sh/kernel/setup.c:312:1: internal compiler error: in sh_print_operand,
at config/sh/sh.c:1359
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla/ for instructions.
{standard input}: Assembler messages:
{standard input}:365: Warning: partial line at end of file ignored
Preprocessed source stored into /tmp/ccQ2JuUO.out file, please attach this to
your bugreport.
A reduced version of the preprocessed source is attached
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111 --- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com --- The following command line is sufficient to reproduce the error: sh64-linux-gnu-gcc -m5-64media-nofpu -ml -O2 -S -o testcase.o testcase.i Adding -v to the command line: Using built-in specs. COLLECT_GCC=/usr/bin/sh64-linux-gnu-gcc Target: sh64-linux-elf Configured with: ../gcc-4.9.1-20140717/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-nls --disable-plugin --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --enable-checking= --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-nls --enable-obsolete --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=sh64-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=sh64-linux-elf --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-linker-hash-style=gnu --with-newlib --with-sysroot=/usr/sh64-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers --with-isl=/data/fedora/cross-gcc/gcc-4.9.1-20140717/isl-install --with-cloog=/data/fedora/cross-gcc/gcc-4.9.1-20140717/cloog-install --with-multilib-list=m5-32media,m5-32media-nofpu,m5-compact,m5-compact-nofpu,m5-64media,m5-64media-nofpu Thread model: single gcc version 4.9.1 20140717 (Red Hat Cross 4.9.1-2) (GCC) COLLECT_GCC_OPTIONS='-m5-64media-nofpu' '-ml' '-O2' '-S' '-o' 'setup.o' '-v' /usr/libexec/gcc/sh64-linux-elf/4.9.1/cc1 -fpreprocessed testcase-min.i -quiet -dumpbase testcase-min.i -m5-64media-nofpu -ml -auxbase-strip setup.o -O2 -version -o setup.o GNU C (GCC) version 4.9.1 20140717 (Red Hat Cross 4.9.1-2) (sh64-linux-elf) compiled by GNU C version 4.8.3 20140624 (Red Hat 4.8.3-1), GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.9.1 20140717 (Red Hat Cross 4.9.1-2) (sh64-linux-elf) compiled by GNU C version 4.8.3 20140624 (Red Hat 4.8.3-1), GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: fb8656871dc1cbba0b3d802cd873a004 testcase-min.i: In function ‘setup_arch’: testcase-min.i:20:1: internal compiler error: in sh_print_operand, at config/sh/sh.c:1359 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla/ for instructions. Preprocessed source stored into /tmp/cctH44XH.out file, please attach this to your bugreport.
