m32c has no problem loading a 24-bit register from a 32-bit memory
location.
The only truncsipsi2* alternative part that seems to match is Raa / Sd* .
Does that mean that Sd* is as good as m?
m32c doesn't use any of the single-character constraints, as they're
too general to pretty much
In gcc.dg/Wconversion-real.c we see this:
vdouble = 3.1L; /* { dg-warning conversion { target large_long_double }
} */
It turns out check_effective_target_large_long_double is NEVER called.
You can change it to some bogus string:
fdouble (3.1L); /* { dg-warning conversion { target
SH (and I'm sure others) has some multilibs (like -m2a-single-only)
where sizeof(double) is 4, which breaks some testcases. Here's a
patch which adds checks for small doubles (and small long doubles),
and adjusts some of the tests which depend on large doubles.
Comments? Ok to apply?
On Thu, 23 Apr 2009, DJ Delorie wrote:
+# Return 1 if the target supports double larger than float,
+# 0 otherwise.
+
+proc check_effective_target_large_double { } {
+return [check_no_compiler_messages large_double object {
+ int dummy[sizeof(double) sizeof(float) ? 1 : -1
I suggest making reload reload the PSImode subreg instead, and
make the m32c machine description provide for a tertiary
reload so that the value can be loaded truncated.
Don't know how to set up a tertiary reload (it's not documented
anywhere).
Is this the type of patch you're thining
From looking at the m32c machine description I got the impression
that you can't directly load A_REGS in PSImode from a PSImode subreg
of a SImode memory location, but maybe I was mistaken.
The big problem with m32c (--mcpu=m32c) is that pointers are 24 bits,
which doesn't correspond to any
This is typical of the types of failures m32c got before IRA, too. I
had a good build on Feb 19th, but if I try to reproduce it, it fails
too.
Fails with -O2, works with -Os. Note: you might need -fno-ivopts to
get around the recent m32c/IV problems.
Any ideas? Any thoughts on why gcc has so
I'm not sure if this is the same problem, but didn't I suggest in
the past to fix this up during expansion? That is, if we end up
with a POINTER_PLUS_EXPR with different mode size pointer and offset
promote (or demote) the offset argument to pointer size properly?
What happened to these
As of this fix (yes, I know it was some time ago - I've been busy),
the m32c-elf build fails building the target libiberty:
./cc1 -fpreprocessed regex.i -quiet -dumpbase regex.c -mcpu=m32cm \
-auxbase-strip regex.o -g -O2 -W -Wall -Wwrite-strings -Wc++-compat \
-Wstrict-prototypes -pedantic
yes; however, maybe it would be easier to wait till Richard finishes the
work on not representing the overflow semantics in types (assuming that's
going to happen say in a few weeks?), which should make the fix
unnecessary,
Ah, ok. Can I ask for m32c to be on the test list for this work?
yes; however, maybe it would be easier to wait till Richard finishes the
work on not representing the overflow semantics in types (assuming that's
going to happen say in a few weeks?), which should make the fix
unnecessary,
Another thought - is this bug in the 4.4 branch? If so, a 4.4 fix
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042c/IHI0042C_aapcs.pdf
and, in particular, \S 7.1.7.5, entitled Volatile bit-fields.
A first question is if these are the semantics that you're looking for
in your project. If so, then we could collaborate with you on
implementing
DJGPP has its own stdint.h, at least in DJGPP 2.04.
I expect most of the OSes listed do; the types should still be entered
into GCC (so the Fortran front end can know them, for example), and
Well, I'm not a big fan of duplicating information, but if that's what
you want to do, here it is. Enjoy.
/* Copyright (C) 2003 DJ Delorie, see
So... can I/we move forward on this? Or will such a change be
rejected?
BTW, Since sending this I discovered that gcc treats these
differently wrt TARGET_NARROW_VOLATILE_BITFIELD:
volatile struct
{
unsigned int a:8;
unsigned int b:24;
} t1;
volatile struct
{
unsigned int a:7;
unsigned
Besides obvious register allocation differences
m32c is very sensitive to register allocation issues.
you basically duplicate the cmp patterns into cbranch and
m32c already has a cbranch, though. It gets split after reload.
Also, m32c needs a separate compare RTL insn in the end
because
Richard Guenther rguent...@suse.de writes:
We have been asked by the SC to not branch for now but wait for
the wording for the new runtime license to arrive from the FSF and
that being put in place.
We've been waiting a long time. At what point do we give up and
branch anyway?
Can you provide example code? I'm confused enough to believe
that you *should* get this effect with PCC_BITFIELD_TYPE_MATTERS
(modulo current bugs).
Imagine a device with four 8-bit registers followed by a 32-bit
register with an 8-bit field:
bytestatus (read-only, clears after reading)
One of our customers has a chip with memory-mapped peripheral
registers that need to be accessed in a specific mode. The registers
represent bitfields within the hardware, so a volatile struct is an
obvious choice to represent them in C.
However, gcc has a very simplistic heuristic for deciding
In varasm.c default_function_rodata_section():
section *
default_function_rodata_section (tree decl)
{
if (decl != NULL_TREE DECL_SECTION_NAME (decl))
{
const char *name = TREE_STRING_POINTER (DECL_SECTION_NAME (decl));
if (DECL_ONE_ONLY (decl) HAVE_COMDAT_GROUP)
{
The documentation doesn't match the implementation:
tm.texi:@deftypefn {Target Hook} bool TARGET_NARROW_VOLATILE_BITFIELDS (void)
target-def.h:#define TARGET_NARROW_VOLATILE_BITFIELD hook_bool_void_false
target-def.h: TARGET_NARROW_VOLATILE_BITFIELD, \
Note the 'S' at the end in the
What are the implications (GPL-wise) of using CGEN-generated files in
gcc? Specifically, I'm working on a second attempt to contribute the
MeP port, and its intrinsics are CGEN-generated (and there are a *lot*
of them - most opcodes have an intrinsic). I'd rather not have to
manually enter all
I believe the source code (i.e., what you'd change to modify the
intrinsics) needs including in the GCC release tarballs. I don't
think CGEN itself needs including, any more than OCaml needs
including because the ARM NEON intrinsic generators are written in
OCaml.
The same cgen files
I think adding a printf() clone to libiberty is WAY overkill just to
silence one failing test.
IIRC, that whole clause was because cygwin's dll itself linked with
libiberty, so the auto-detect stuff needed an override to make sure
the right files were there when you build cygwin1.dll. Otherwise, it
would detect that cygwin had strsignal, not build it, then fail later
when cygwin1.dll
As I repeatedly said having sizetype of a different precision than
pointer types will cause all sorts of problems ;)
And as I've rebutted repeatedly, I can't change the chip.
The middle-end generally assumes it can cast between sizetype and
pointers arbitrarily.
Bad assumption. It will
I guess tmp is not short unsigned int * but some other pointer type,
right? But bufend is short unsigned int *?
Both are short unsigned int * - pointers to shorts.
Can you open a bugzilla for this? It should be not too difficult to track
down the piece of IVOPTs that creates that
I'm looking a failure for m32c-elf (-mcpu=m32c) in
gcc.c-torture/execute/2412-6.c.
I've narrowed it down to a transformation done in 107t.ivopts.
In 104t.cunroll: (tmp_9 and tmp_16 are 24-bit pointer values):
tmp_9 = tmp_16 + 2;
if (bufend_6(D) tmp_9)
but in 107t.ivopts:
tmp_9 =
How about this?
--- gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr36321.c 2008-07-23
00:21:31.0 -0400
+++ ./pr36321.c 2008-11-24 13:46:04.0 -0500
@@ -17,7 +17,9 @@
}
+static char * volatile argp = pr36321.x;
+
int main(int argc, char **argv)
{
- foo (argv[0]);
+ foo
OK.
Thanks, committed.
gcc.c-torture/execute/pr36321.c fails on m32c because the simulator
doesn't set argv[0] *and* the simulator has NULL pointer detection:
void foo(char *str)
{
int len2 = strlen (str);
. . .
int main(int argc, char **argv)
{
foo
I think a more relevant question is whether it's ok to pass 0, {NULL} for
argc, argv.
You can do that on desktop linux, you know:
execl(some_prog_name, NULL);
argv[0] is NOT guaranteed to be non-NULL:
ISO/IEC 9899:1999(E) 5.1.2.2.1
2 If they are declared, the parameters to the main
The old register allocator hasn't been removed yet, but will be
before branching. There are still several targets that haven't been
converted to IRA, so unless they are converted soon, they will be
dropped. The unconverted targets are:
m32c
I'd like to once again point out that despite
What level of 'not support' is that? Is it completely unable to
generate code or are there only testsuite regressions?
There's no definition of that macro (that we could find) that lets you
build newlib successfully.
I can't run the testsuite without newlib.
How does it fail? Is it related to m32c, ehm, interesting
architectural features (24 bits addresses and only 2 address
registers IIRC)?
I think so.
The m32c family has such a non-orthogonal register set that there's a
lot of small register classes. There are few cases where GENERAL_REGS
is
Now I'm getting a ton of errors (like, around 5000) that look like this:
Just remove that assert for testing.
Looks good without the assert, 21 new passes and only 1 new failure:
PASS-FAIL: gcc.c-torture/execute/loop-ivopts-1.c execution, -O3
-fomit-frame-pointer -funroll-loops
I don't think this is a suitable general solution. Can you instead try the
attached which again tries to simply make sure we sign-extend a sizetype
offset if that is smaller than the pointer mode.
Now I'm getting a ton of errors (like, around 5000) that look like this:
[ gdb ] up
#1
Never mind, I figured this one out.
Ping? Is this the right thing to do? I'd like to get this (and a few
other m32c bugs) resolved before the next release.
This seems to work, with a suitable extendhipsi2 pattern for m32c:
Index: expr.c
===
--- expr.c
Ping?
http://gcc.gnu.org/ml/gcc/2008-10/msg00491.html
My knowledge of backend and RTL in general is very limited and I have
no clue what m32c-elf architecture is and don't seem to have access to
any such system.
m32c-elf is one of the many embedded (i.e. cross-compiled) targets
which has a simulator. You don't need to have access to physical
2008-11-07 Martin Jambor [EMAIL PROTECTED]
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Do not check
for INDIRECT_REFs.
(forward_propagate_addr_into_variable_array_index): Check that the
offset is not computed from a MULT_EXPR, use is_gimple_assign
This new failure seems to have been caused by r141613:
+2008-11-05 Martin Jambor [EMAIL PROTECTED]
+
+ PR middle-end/37861
+ * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Don't turn
+ pointer arithmetics into array_ref if the array is accessed
+ through an
For m32c-elf with gcc.c-torture/execute/980707-1.c, global seems to be
deleting a set that's needed to set the exit code - i.e. it's the
first argument to exit(). There's also this suspicious message in the
global dump:
More info: I've tracked this back to r138207, the gimple-tuples-branch
For m32c-elf with gcc.c-torture/execute/980707-1.c, global seems to be
deleting a set that's needed to set the exit code - i.e. it's the
first argument to exit(). There's also this suspicious message in the
global dump:
changing reg in insn 95
I can't tell if they're changing the pseudo (ok)
One thing to do is to call simplify_gen_subreg.
As I noted, that may return NULL, which is fatal in the case I'm
referencing.
But I don't think that will help. I think this code is simply
incorrect. It seems to assume that op_mode is at least as large as
GET_MODE (xop0), probably because
Ian Lance Taylor [EMAIL PROTECTED] writes:
simplify_gen_subreg will only return NULL when the RTL is already
bogus.
Be that as it may, but it was returning NULL in my case. (I tried
calling simplify_gen_subreg too).
The code in expmed.c seemed to be OK with generating bogus subregs,
assuming
One thing to do is to call simplify_gen_subreg. I don't know why this
code still calls gen_rtx_SUBREG. It's pretty old code.
But I don't think that will help. I think this code is simply
incorrect. It seems to assume that op_mode is at least as large as
GET_MODE (xop0), probably
Committed as attached. Thanks!
Sure.
2008-10-24 DJ Delorie [EMAIL PROTECTED]
* lib/scanasm.exp (scan-assembler, scan-assembler-not,
scan-hidden, scan-not-hidden, scan-file, scan-file-not,
scan-assembler-times, scan-assembler-dem, scan-assembler-dem
In expmed.c I see code like this:
if (REG_P (xop0) GET_MODE (xop0) != op_mode)
xop0 = gen_rtx_SUBREG (op_mode, xop0, 0);
However, this is wrong for big-endian targets (h8300-elf in my case)
because '0' is not the offset of the LSB of the register when it's a
pseudo and op_mode is
The following ports haven't been converted yet:
m32c
I've tried and tried to get IRA for m32c working. I asked Vlad and
Jeff to look at it, which they have/are, with no definite results yet.
In scanasm.exp we do this:
proc scan-assembler { args } {
upvar 2 name testcase
set output_file [file rootname [file tail $testcase]].s
However, in dejagnu, $name may have compiler switches appended to it:
# We append the compilation flags, if any, to ensure that the test case
OK, after you've run the testsuite with this change. The ChangeLog
entry should show the names of all of the procs you changed.
Is gcc.target/i386.exp enough? I originally found it with
xstormy16-elf on an older branch, but xstormy16 isn't a happy target
in trunk at the moment.
Joern Rennecke [EMAIL PROTECTED] writes:
I'm not sure if this changed with IRA,
Acts the same with 4.3 and 4.4.
reload will look for the alternative with the cheapest total cost of
alternative and reloads.
This was the key. Disparaging the smaller class's alternative with
'?' works - it
I've got this code:
(define_insn andhi3_24
[(set (match_operand:HI 0 mra_operand
=Sd,Sd,*Rhl,*Rhl,RhiSd,??Rmm,RhiSd,??Rmm)
(and:HI (match_operand:HI 1 mra_operand %0,0,*0,*0,0,0,0,0)
(match_operand:HI 2 mrai_operand
Imb,Imw,*Imb,*Imw,iRhiSd,?Rmm,?Rmm,iRhiSd)))]
(what is the current sizetype mode?)
HImode
There are no bitfield instructions. What I suggest is that you make
sizetype 16bits (HImode), as if I remember correctly you are not
concerned anyway about pointer offsets larger than what fits into
signed 16bits. If you then use the expansion
This is what I get with your patch and not mine:
neg.w r0 ; 7neghi2/1
mov.w r0,a0; 9
zero_extendhipsi2
add.l a0,r3r1 ; 15
Ok, here's where it's getting expanded:
#12 0x081e2805 in convert_modes (mode=PSImode, oldmode=HImode, x=0xb7f63450,
unsignedp=1)
at ../../gcc/gcc/expr.c:859
#13 0x0831f83a in expand_binop_directly (mode=945, binoptab=0x8824de0,
op0=0xb7f63410,
op1=0xb7f63450, target=0xb7f63440,
Ok, I just looked for POINTER_PLUS_EXPR and tried to make sure its
offset is always sign-extended. Can you check where on the call
path above we miss this special treatment?
It looks like it drops past them all and gets the generic treatment,
just before the MINUS_EXPR case.
This seems to work, with a suitable extendhipsi2 pattern for m32c:
Index: expr.c
===
--- expr.c (revision 140759)
+++ expr.c (working copy)
@@ -8455,12 +8459,34 @@ expand_expr_real_1 (tree exp, rtx target
if
Is this related to the loop termination bug I reported
on the m32c?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37665
Probably related, but I don't know if a patch to fix one will fix the
other.
I think this is the wrong place to fix this. If you would override
the sizetypes precision from your target, would that fix it? That
is, in stor-layout.c set_sizetype make the target allow adjusting
the passed type (which is supposed to be sizetype). If at all then
these types should be
Can you look in the CVS/SVN archives and see what the mn102 port did --
It used SImode for size_type but I think I tried that and it blew up
in useless_type_conversion_p. I can try again if you're interested in
the details.
I've got a partial patch which works with older (4.3) gccs, but fails
gimple's check for trunk (attached). My trivial test case...
char *
foo (char *a, int b)
{
return a-b;
}
...fails thusly:
integer_type 0xb7f52c30 public unsigned SI
size integer_cst 0xb7ee7540 type integer_type
NEGATE_EXPR on an unsigned type is fully defined. It's what you
should get when you say unsigned int i, j; ...; i = - j;.
I didn't say it was undefined, I said it seemed wrong. Esp since the
example starts with a plain int value.
I think the problem you are facing may be that
Michael Eager [EMAIL PROTECTED] writes:
Are there any architectures which have Pmode != INT?
m32c has Pmode == PSImode, at least with -mcpu=m32c. The r8c/m16c
variants have Pmode == HImode == int.
I'm running into a number of problems.
Yup! GCC doesn't like ports where sizeof(pointer) !=
Does the following fix it?
Nope, sorry. I was looking at this code in c-common.c, where the expr
is first created, but I don't know what that ends up calling:
/* Create the sum or difference. */
if (resultcode == MINUS_EXPR)
intop = fold_build1 (NEGATE_EXPR, sizetype, intop);
ret
m32c-elf-gcc -mcpu=m32c (16 bit ints, 24 bit pointers) miscompiles
this:
int *foo (int *a, int b)
{
return a-b;
}
as this:
_foo:
enter #0 ; 30prologue_enter_24
pushm r1,r3,a0; 31pushm
; end of prologue ; 32prologue_end
Sure, DJ. I'll look at this but unfortunately I can do it on next week
because I am busy with numerous other IRA bugs.
Next week would be fine :-)
As I wrote m32c is pretty nasty case and may be will need even insn
description changes.
I'm OK with that.
The following ports are unconverted and I don't recall seeing people
saying they were working on IRA ports, although I may have missed such
statements:
m32c
I am working on m32c but so far have not had good results. All class
combinations I've tried so far result in build failures in one
Presumably you're discussing these with Vlad?
We did exchange some emails about it, yes.
Is there some reason for the inconsistency,
Not really. Patches welcome.
You should file a PR in any case.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
Does m32c handle some addresses specially in any way at all similar to the
special SH handling discussed in PR 36780 and
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00932.html? Because some
sort of
If reload is generally flaky like this for m32c, perhaps a target macro to
say not to reload addresses in the particular case my patch affects would
be a sensible approach, if things worked better without reloading them
even though as far as reload knows they need reloading.
I wouldn't
Deepen Mantri [EMAIL PROTECTED] writes:
Does anybody know the reason behind not implementing these
instructions for H8SX targets?
Most likely, it's just a case of nobody volunteering to add them yet.
For some instructions, it may be difficult to teach GCC the nuances of
how they work.
All my builds returned this error last night. Is anyone else seeing this?
--- Start of forwarded message ---
Date: Thu, 19 Jun 2008 02:41:26 -0400
From: DJ Delorie [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: v850-elf failure in gcc-make
Failure step: v850-elf-gcc-make.log
calls
The R8C has a 20-bit addressing mode for data outside its normal
addressing range. However, gcc *really* wants to CSE these and put
their addresses in registers, which is not going to work (pointers are
16 bit, these addresses are 20 bit). How can I force gcc to use [sym]
or [sym+reg]
Joseph S. Myers [EMAIL PROTECTED] writes:
i[34567]86-*-coff*
DJGPP is ix86-coff - how would this deprecation affect djgpp?
I thought DJGPP was i[34567]86-pc-msdosdjgpp*. I do not think
having generic CPU-*-OBJFMT triplets that really refer to a
particular OS is a good idea. It's only certain generic triplets
I'm proposing to deprecate.
DJGPP is ix86-pc-msdosdjgpp, yes. However, it's based on the
ix86-coff
Showed up for v850, iq2000, and m32c... Manual compilation results in
zero warnings.
--- Start of forwarded message ---
Date: Fri, 13 Jun 2008 11:21:27 -0400
From: DJ Delorie [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Results for 4.4.0 20080613 (experimental) [trunk revision
I should start posting these to the testing list. Lots of m16c
improvements, but some m32c regressions. I haven't tried to diagnose
these yet, but if nobody claims it's their fault I will ;-)
Anyone know why the regressions happened?
PASS-FAIL:
, 12 Jun 2008 07:01:34 -0400
From: DJ Delorie [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Results for 4.4.0 20080612 (experimental) [trunk revision 136692]
(GCC) testsuite on m32c-unknown-elf
gcc result changes...
Multilib: m32c-sim/-mcpu=m16c
FAIL-PASS: gcc.c-torture/execute/builtins/pr23484
This regression came through just today...
--- Start of forwarded message ---
Date: Wed, 28 May 2008 09:23:10 -0400
From: DJ Delorie [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Results for 4.4.0 20080528 (experimental) [trunk revision 136068]
(GCC) testsuite on v850-unknown-elf
Same regression, but m32c is overall better since yesterday :-)
--- Start of forwarded message ---
Date: Wed, 28 May 2008 06:57:46 -0400
From: DJ Delorie [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Results for 4.4.0 20080528 (experimental) [trunk revision 136068]
(GCC) testsuite
If i read this right, it says it was a pass, and is now an XFAIL?
Yes.
If so, that is the expected result of Richi's patch, and he
mentioned it when he changed it to xfail
Ok.
Uh, so sizetype is 32bit but pointer displacements are 24bit? :(
Worse. sizetype is 16bit but pointer displacements are 24bit. There
are no 24bit address registers, nor are there enough 24bit math
opcodes to satisfy gcc (without switching to 32bit emulated math,
which is REALLY slow).
It's
Please how do I set environment variable DJGPP? What should I set it
to?
Your best bet for DJGPP-related questions is still the
[EMAIL PROTECTED] mailing list (or comp.os.msdos.djgpp newsgroup).
See http://www.delorie.com/djgpp/ for details.
The DJGPP ftp sites and mirrors have current gcc
I don't think you can tell that, but maybe look into tree-ssa-address.c where
it asks the target for costs via building some rtx-en.
I've got a target_address_cost hook, but it's never passed an RTX with
a negative displacement.
I don't think you can tell that, but maybe look into tree-ssa-address.c where
it asks the target for costs via building some rtx-en.
Ok, here's something... I adjusted my address_cost hook to figure
costs of offsets more accurately, and even though it only tests
offset vs no offset, it does
But it looks like update_ld_motion_stores() and insert_store() also
call gen_move_insn without adding clobbers if necessary. I suppose the
insns produced there should also go through insn_invalid_p somewhere.
I sent a hack for that to DJ, but I guess the proper place to fix this
is inside
(yet another m32c-related problem)
Something in ivopts is converting this:
ap.1_5 = ap_38 + 2;
ap.2_6 = (struct tiny *) ap_38;
SR.8_15 = ap.2_6-c;
to this:
ap.1_5 = ap_38 + 2;
SR.8_15 = MEM[base: ap.1_5, offset: 65534];
Now, recall that for -mcpu=m32c size_t is 16 bits but pointers
I've got a number of test cases that are all failing in the same place:
#1 0x081cf498 in purge_dead_edges (bb=0xb7f67834) at
../../gcc/gcc/cfgrtl.c:2332
2332 gcc_assert (single_succ_p (bb));
(similar to http://gcc.gnu.org/ml/gcc/2008-04/msg00473.html but I'm using trunk)
What's up here?
Why is store_motion doing this?
STORE_MOTION delete insn in BB 2:
(insn 8 7 27 2 dj.c:10 (parallel [
(set (mem/s/j:HI (reg/v/f:HI 26 [ s ]) [0
variable.buf+0 S2 A8])
(ashift:HI (reg/v:HI 27 [ n ])
It looks like it replaced the store with a reg move, and it should
have inserted the store back to memory with the clobber back later in
the CFG.
IE it pushed your store down to some later point in the CFG.
It's not the store that needs the clobber, it's the shift. The R8C
can only use
The patch simply enabled type checking by default. As I don't see how
we can easily address the underlying problem can you try the following
which simply makes this typechecking weaker?
That seems to work.
FYI test results show 98% pass rate for C++ and 98.6% pass rate for C,
so I'm not
Ok, I'll take care of properly comitting the patch.
Thanks!
More digging has identified this patch as the cause of the ongoing
C++-related m32c build failures:
2008-03-24 Richard Guenther [EMAIL PROTECTED]
PR c/22371
* gimplify.c (gimplify_modify_expr): For frontend type-correct
pointer assignments change conversions according
Anyone else seeing this on trunk?
if test -z $objects; then \
echo 'int __libgcc_eh_dummy;' eh_dummy.c; \
/sata/dj/gnu/newlib/h8300-elf/./gcc/xgcc
-B/sata/dj/gnu/newlib/h8300-elf/./gcc/ -B/sata/dj/gnu/install/h8300-elf/bin/
Sorry, didn't help.
(call (mem:QI (match_operand:QI 1 register_operand z))
Are you sure your z constraint only matches even numbered hard
registers?
801 - 900 of 1257 matches
Mail list logo
