Hi Joern, Hi Alex,
The sh64-elf toolchain currently fails to build from the mainline
GCC sources because it contains unsupported SH assembler:
./xgcc \
-B./ \
-B/usr/local/sh64-superh-elf/bin/ \
-isystem /usr/local/sh64-superh-elf/include \
-isystem /usr/local/sh64
Hi Joern,
I have a patch for it, but due to problems with our hardware, newlib, and
issues with the way the linux libgcc is built, I have not been able to
test the
patch satisfactorily.
I can confirm that the patch allows GCC to build for both an sh64-elf
and an sh-elf target. I am now run
Hi Eric, Hi Richard,
We recently ran across an ICE building a target libiberty for one of
the multilibs of the mips64vrel-elf toolchain:
.../libiberty/regex.c: In function 'byte_re_match_2_internal':
.../libiberty/regex.c:7481: error: insn does not satisfy its constraints:
(insn 52
Hi Richard,
But I am pretty sure that this is the wrong solution. Since I am
not a MIPS expert however I am punting this problem to you guys. :-)
Yeah, I'm afraid it's the wrong solution. ;)
Thought so :-)
I gather from the insn above that a use of the GP pseudo
register has been int
Hi Eric, Hi Richard,
I need your brains...
The mips64vrel-elf toolchain is showing a lot of unexpected failures
in the gcc testsuite (and g++ testsuite) for multilibs which use
-mlong64 and -mgp32 together. For example the first one I came
across is this:
% ... mips64vrel-elf/gcc/
Hi Eric, Hi Richard,
We have received a bug report against the mips64vrel-elf toolchain
which is reproducible with the mainline sources. Since it (appears
to) involve MIPS code generation and I know almost nothing about
MIPS I am passing it on to you in the hopes that you might be able
heck the patch
into the 2.18 branch.
Cheers
Nick
PS. The bootstrap still does not succeed with this patch
installed. It fails later on with this error report:
i386-dis.c:4213: error: type mismatch in pointer plus expression
struct dis386 *
struct dis386[8] *
unsigned in
Hi Guys,
I tried bootstrapping the mainline gcc sources over the weekend,
using the current mainline binutils sources in an integrated source
tree. The bootstrap failed with a problem in bfd/elflink.c which I
have already reported and worked around. The build then failed
later on with
Hi Andrew,
As mentioned before this error message is really an internal error, we
really should be fixing GCC and not changing binutils. And I already
mentioned this is most likely PR 22371 and that you should be filing
bug reports about these two errors/ICEs.
I have filed PR 33122 to cover th
Hi Jeff, Hi Kazu,
We have run across an H8300 RTL generation bug which I think might be
generic, rather than specific to the H8300, although it may only
trigger for small targets.
Given the following source file:
struct fields { unsigned long long u2 : 33; } flags;
int main (voi
Hi Guys,
Sometime during the last month building newlib for any of the MIPS
ports broke with a gimple verification error:
.../newlib/libc/stdio/vfprintf.c:480: error: type mismatch in binary expression
unsigned char
unsigned char
int
D.3477 = D.3438 & -8;
[...]
.../newlib/libc/stdio/vfprin
Hi Bernd,
You probably know this already. The c6x-elf target fails to build
libgcc with the current FSF mainline sources:
gcc/libgcc2.c: In function ‘__gnu_mulsc3’:
gcc/libgcc2.c:1928:1: internal compiler error: in scan_trace, at
dwarf2cfi.c:2433
Please submit a full bug report,
I
Hi Guys,
I am stuck on a dataflow problem. PR 49801 is reported against the RX
toolchain, but I believe it to be a generic problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49801
The issue I think is the split2 pass which is converting this:
(set (pc) (if_then_else (geu (reg r
Hi Guys,
I tried to build an avr-elf toolchain today from the current mainline
GCC sources, but it fails building lto1 with:
gcc/config/avr/avr.c:2591: undefined reference to `c_addr_space_name'
Is there any chance that this can be fixed please ? (I am trying to
investigate a b
Hi Zdenek, Hi Daniel, Hi Geoff,
I think that I have found a small bug in the loop invariant code.
The problem is exhibited when building newlib for the xstormy16-elf
toolchain although it may happen with other targets as well. The
problem occurs when an insn contains an r-value use of a r
Hi Zdenek,
(parallel [
(set (pc)
(if_then_else (lt:SI (reg:SI 45)<---
(reg:SI 26))
(label_ref:HI 129)
(pc)))
(clobber (reg:SI 45))
Hi Alex, Hi Kaz,
The sh-elf target is currently failing to build libgcc on the FSF
mainline because:
libgcc/unwind-dw2.c: In function 'execute_stack_op':
libgcc/unwind-dw2.c:902:1: error: unable to generate reloads for:
(set (reg:SI 147 t)
(zero_extract:SI (reg:SI 621 [
Hi Guys,
Suppose a programmer creates a function called "memset" and then
compiles it with gcc. Eg:
% cat memset.c
void *
memset (void *s, int c, unsigned int n)
{
char *v = s;
while (n--)
*v++ = c;
return s;
}
% gcc -O3 -S -fno-bui
Hi Eric, Hi Richard,
A customer has reported the following bug with the MIPS target. Since
it is for a GNU extension to the C language (zero-length arrays) that
is being used in a non-intended fashion (the zero-length array is in a
structure with no other fields) I doubt if you will want
Hi Richard,
+ /* Even zero-sized arguments occupy one byte. */
+ if (size == 0)
+ size = 1;
That fixes it! Thanks.
Will you apply this patch yourself, or should I submit the patch and the
test case as a separate email to gcc-patches ?
Cheers
Nick
Hi Guys,
There appears to be a discrepancy in the way that G++ orders its
static destructors. Given this test program:
#include
using namespace std;
class A
{
public:
int i;
A(int j) : i(j) { cout << "constructor A" << endl; }
~A() { cout << "destructor A : i = " << i << e
Hi Jeff, Hi Alex,
Whilst working with the AM33 port I recently came across a piece of
code in the glibc sources which triggered an ICE in gcc because it
was generating an insn which did not match the constraints:
error: insn does not satisfy its constraints:
(insn (set (reg:SI a0)
Hi Guys,
The ia64-elf and i386-elf targets currently fail to build for me using
the mainline sources. The symptom is a seg-fault when running the
self tests:
./xgcc <...> -xc -S -c /dev/null -fself-test
: internal compiler error: Segmentation fault
The cause appears to be an att
nt to get target
greping wrong.
So - Jan, Uros, Jim, Steve - are these ia64 and i386 backend patches OK ?
Cheers
Nick
gcc/ChangeLog
2016-08-25 Nick Clifton
* config/ia64/ia64.c (ia64_init_builtins): Initialise the
float128_type_node if that has not been d
Hi Joseph,
>> * config/ia64/ia64.c (ia64_init_builtins): Initialise the
>> float128_type_node if that has not been done already.
>> * config/i386/i386.c (ix86_init_builtin_types): Likewise.
>
> No, this is wrong. The global node must remain as NULL when the type is
> not fully su
25 matches
Mail list logo
