https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737
--- Comment #22 from dhowells at redhat dot com ---
That's a shame. It's just that the error messages look very similar.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
--- Comment #12 from dhowells at redhat dot com ---
(In reply to Oleg Endo from comment #10)
> Created attachment 33197 [details]
> a possible fix
It permits me to build a slew of sh64 libgccs, so it's looking good.
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Created attachment 33303
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33303&action=edit
Reduced preprocessed source
When trying to build the kernel with an sh64 cross-compiler, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #1 from 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #2 from dhowells at redhat dot com ---
The binutils is based on the 2.24 branch, git commit
cab6c3ee9785f072a373afe31253df0451db93cf and was built targeting
sh64-linux-elf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #4 from dhowells at redhat dot com ---
The compiler is gcc-4.9.1, dated 20140717, svnrev 212747.
One patch is applied - see bug 61844.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61996
--- Comment #1 from 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 ---
(In reply to Kazumoto Kojima from comment #5)
> ...
>
> even though general_extend_operand doesn't permit (truncate (mem ...)).
> An easy workaround might be to di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #7 from 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #10 from 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);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #13 from 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 sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
--- Comment #15 from 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 ---
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=33374&action=edit
Reduced test case
A gcc build for SH produces an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218
--- Comment #1 from dhowells at redhat dot com ---
Created attachment 33375
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33375&action=edit
Assembly output from test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218
--- Comment #2 from 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218
--- Comment #3 from 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 ---
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62218
--- Comment #5 from 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 &qu
oduct: 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-com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66491
--- Comment #1 from 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 -Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66491
--- Comment #2 from 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.
--- Comment #8 from dhowells at redhat dot com 2007-10-30 22:28 ---
Seems to work for me. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28583
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=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=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
y: 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);
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&action=edit
Test source
Using the Fedora 33 x86_64 compiler:
gcc version 10.2.1 20201125 (Red Hat 1
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&action=edit
Test source
Using the Fedora 33 x86_64 compiler:
gcc version 10.2.1 20201125 (Red Hat 1
erity: 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&action=edit
Demo code
I
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
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?
101 - 132 of 132 matches
Mail list logo
