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?
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
: 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 cou
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) (
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) (
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 ki
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
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
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 initialisati
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79404
--- Comment #6 from dhowells at redhat dot com ---
That builds now, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462
--- Comment #8 from dhowells at redhat dot com ---
The patch works for me, thanks!
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
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
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
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.
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.
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 whi
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
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
s: 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 co
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
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
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) : -
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
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-
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-
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
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
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 produ
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
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 1c
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 yo
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
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
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 t
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.
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
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
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
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
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
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.
: 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
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 rema
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
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 s
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 numbe
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
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
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
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.
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70821
--- Comment #3 from dhowells at redhat dot com ---
Yes, I'm testing with -Os.
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.
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_exchang
: 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 m
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/
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
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.
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 bet
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
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
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
ty: 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:
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
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
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
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
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
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
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.
: 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
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!
: 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
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!
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
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
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
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?
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
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
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
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
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
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.
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.
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
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
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
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.
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
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
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?
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
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
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
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
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
1 - 100 of 132 matches
Mail list logo
