t: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dhowells at redhat dot com
GCC build triplet: x86_64-unknown-linux-gnu, i686-pc-linu
--- Comment #1 from dhowells at redhat dot com 2006-08-03 13:38 ---
Created an attachment (id=12004)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12004&action=view)
Stripped down testcase for the bug
I get the error on line 92 of this source file:
warthog>./gcc/xgcc -
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
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,
on: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Created attachment 30605
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30605&action=e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58073
--- Comment #1 from dhowells at redhat dot com ---
Interestingly, the suboptimality shifts if the 'shift' value in the demo
program is changed to 0:
Going through the cases individually::
(1) return (mask(d) == (0x0 << s
||FIXED
--- Comment #2 from dhowells at redhat dot com
2012-06-01 13:31:06 UTC ---
Those fix it for me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52971
Bug #: 52971
Summary: gcc ICE with an sh64 cross-compilation
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51445
Bug #: 51445
Summary: g++ sometimes miscompiles code for the avr target
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
||FIXED
--- Comment #1 from dhowells at redhat dot com
2011-12-11 13:56:37 UTC ---
The problem appears to be fixed in gcc-4.6.2.
y: 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&action=edit
Testcase
g++ doesn't implement simple sparse arra
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
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&action=edit
Test case
I'm seeing the f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55351
--- Comment #2 from dhowells at redhat dot com
2012-11-20 15:09:42 UTC ---
The first hunk of the patch that adds:
MULTILIB_EXCEPTIONS = *m5-64media* *m5-64media-nofpu*
to gcc/config/sh/t-linux causes the sh-linux-gnu build to fail
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=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
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
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 #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 #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 betwee
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
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&action=edit
Test
: 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&action=edit
Test source
If
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&action=edit
Examp
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.
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=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=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=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 #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 #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 #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 #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, b
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
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=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 o
: 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=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.
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
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=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 :
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
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=71191
--- Comment #3 from dhowells at redhat dot com ---
Created attachment 38522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38522&action=edit
atomic_add_unless() test code
Here's a .c file containing the C code I referenced.
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 #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=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
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&action=edit
Test code
When building a cross compiler for h8300, an ICE
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.
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 #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
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=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-swit
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=79404
--- Comment #6 from dhowells at redhat dot com ---
That builds now, thanks!
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&action=edit
Test source
The attached
ormal
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);
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
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-
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=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=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
--- 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 #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
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&actio
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052
--- Comment #6 from dhowells at redhat dot com ---
Fixed how? Is Nick's patch good?
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:
addik
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649
--- Comment #1 from dhowells at redhat dot com ---
Created attachment 35201
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35201&action=edit
Assembler output from larger reduced case
Here is the assembler output from the larger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65649
--- Comment #2 from 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052
--- Comment #8 from dhowells at redhat dot com ---
This seems to work for me, 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=35539&action=edit
Reduced test ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66140
--- Comment #3 from dhowells at redhat dot com ---
The compiler works now, thanks!
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&action=edit
Reduced test case
When compiling the attached test case for alpha-linux-gnu w
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
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&action=edit
Test progr
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052
--- Comment #1 from 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
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-uclinu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052
--- Comment #2 from 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=65052
--- Comment #3 from 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 -f
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Created attachment 33082
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33082&action=edit
Reduced preprocessed source that induces the error message
When trying to build a cross-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #1 from dhowells at redhat dot com ---
I needed the following change to gcc (courtesy of Nick Clifton) to get cris-gcc
to build at all, even without libgcc:
Index: gcc/config.gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #2 from dhowells at redhat dot com ---
This also appears to occur for --target=sh64-linux on an unpatched gcc tree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #10 from dhowells at redhat dot com ---
(In reply to Hans-Peter Nilsson from comment #7)
> (In reply to dhowe...@redhat.com from comment #0)
> > I'm also very intrigued by that last line - I can reproduce it quite eas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #11 from dhowells at redhat dot com ---
(In reply to Hans-Peter Nilsson from comment #3)
> > libgcc is built with:
> > make -C cris-linux-gnu tooldir=/usr all-target-libgcc
>
> I'd expect "make all-targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #12 from dhowells at redhat dot com ---
(In reply to Hans-Peter Nilsson from comment #6)
> Created attachment 33121 [details]
> Patch to config.gcc
>
> Correct patch to config.gcc required to actually build the com
NCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
gcc ICE says "The bug is not reproducible, so it is likely a hardware or OS
problem." at the end - even when this isn't true.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812
--- Comment #1 from dhowells at redhat dot com ---
For an example ICE, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
This is easily reproducible, so the line is incorrect. It might be better
stated conditionally:
"If the b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #15 from dhowells at redhat dot com ---
(In reply to Hans-Peter Nilsson from comment #14)
> Could you please consider open a separate PR for the "is not reproducible"
> misdisagnosis?
https://gcc.gnu.org/bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812
--- Comment #3 from dhowells at redhat dot com ---
Hmmm... It appears you're right. The 'upstream tarball' in the Fedora gcc SRPM
seems already to be altered from what's upstream - even before the spec file
applies any patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61812
--- Comment #5 from dhowells at redhat dot com ---
(In reply to Andrew Pinski from comment #4)
> Also even though it might be a true gcc issue, it does not say it is a
> hardware issue, the message says likely. This could also mean a g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #19 from dhowells at redhat dot com ---
This seems to have done the trick, thanks!
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
When trying to build a cross-compiler for sh64 with libgcc, I get the following
error and several others like it (make -j is in operation) during the compiler
build:
/data/fedora/cross-gcc/gcc-4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #1 from dhowells at redhat dot com ---
System compiler being used:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
Target: x86_64-redhat-linux
Configured with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #2 from dhowells at redhat dot com ---
Created attachment 33144
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33144&action=edit
Old, no-longer functional patch to libgcc
I was given the attached patch when I was on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #3 from dhowells at redhat dot com ---
The compiler is configured thusly:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #4 from dhowells at redhat dot com ---
This behaviour can be produced with the SVNREV 212237 (2014-07-02) gcc-4.9.0
compiler tarball and no extra patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #5 from dhowells at redhat dot com ---
Note that I also see a number of warnings like:
/usr/bin/sh64-linux-gnu-nm: _sdivsi3_s.o: File format is ambiguous
1 - 100 of 132 matches
Mail list logo
