> The compiler should generate a pseudo-op that is processed by the
> assembler. If the right pseudo-op doesn't already exist, it needs
> to be added to both the assembler and compiler.
The assembler has pseudo-s for ".fpu" which says what kind of FPU it
has, but the generic hard/soft choice is
> I am strongly of the opinion that the right way to do this is to have
> the compiler generate appropriate directives in the assembly files it
> generates -- and to have users do the same. Relying on the defaults is
> just too dangerous.
So... where should this go?
I discovered that if you build a plain arm-elf toolchain, the default
float-abis for gcc and gas don't match. I added this patch locally to
make it "just work" but it seems to me it would be better to have the
defaults match, although I'm not sure how to enforce that. Comments?
Suggestions?
Ind
> OK, I'll do some testing with it tomorrow. Which GCC versions are affected?
I tested trunk and an old 4.2.1 internal branch, and found the bug on
both, so anything in between would be affected too. It goes back at
least to this patch, which mostly fixed the bug:
2008-02-19 Christian Bruel
I can confirm this fixes my test case. Had I known about
highest_pow2_factor() I might have come up with this myself ;-)
> Index: tree-ssa-loop-ivopts.c
> ===
> --- tree-ssa-loop-ivopts.c(revision 158148)
> +++ tree-ssa-loop-ivo
In tree-ssa-loop-ivopts.c:may_be_unaligned_p(), we call
get_inner_reference to figure out bitpos, but we don't take into
account toffset - which may make the reference less aligned than we
expect. Is this supposed to be accounted for by STEP ? It doesn't
always work with nested arrays - STEP is
> Is it still used outside the "Cygnus tree"?
How should I know? I don't know what users of free software do with
it...
It's a target library. Anyone writing code for any target might use
it.
> But I've previously noted that target libiberty seems completely useless;
It's a target library, like newlib, libz, libstdc++, or anything else.
How do you know there are no target applications that want to link
against it?
> DJ, can you add these files to the list that we get email about?
Added: ltgcc.m4 ltmain.sh ltoptions.m4 ltsugar.m4 ltversion.m4 lt~obsolete.m4
Note that the m32c port uses PSImode, so it may offer some suggestions
as example code.
> gets from the linker. Since the linker plugin is a shared
> object, and it uses libiberty functions, it needs to use a
> shared libiberty.
Why can't they just link a static libiberty?
"Joseph S. Myers" writes:
> It has been proposed (and not rejected, but not yet implemented)
I'm still working on it...
If loop optimization assumes sizeof(void *) == sizeof(size_t) and
won't work correctly otherwise, perhaps a check for that condition in
gate_tree_ssa_loop_ivopts() would be appropriate? I thought of just
disabling that flag in m32c.c, but I figured a more generic solution
would make more sense, a
> * DJGPP
Committed.
2009-08-13 DJ Delorie
* config/i386/djgpp-stdint.h: New.
* config.gcc (djgpp): Use it.
Index: config.gcc
===
--- config.gcc (revision 150731)
+++ config.gcc (working copy)
@@ -1169
On s390x it produces this insn:
(insn 8 7 9 3 323444.c:15 (set (mem/s:DI (reg:DI 46) [0 S8 A64])
(mem/s:DI (reg/v/f:DI 45 [ tp ]) [0 S8 A64])) -1 (nil))
Note that the alignments are 64 bit again, despite the field being
packed. mep-elf has similar results.
void *memcpy(void *dest, co
> Your code uses the (one and only) CRC-32 polynomial 0x04c11db7, so just
> describing it as the "CRC-32" function should be sufficient documentation.
> It's the same CRC function as used by PKZIP, Ethernet, and chksum.
> It's not compatible with the Intel CRC32 instruction which uses the
> CRC-32
Committed.
* config/mep/mep.c (mep_legitimize_arg): Leave control registers
alone too.
Index: config/mep/mep.c
===
--- config/mep/mep.c(revision 149868)
+++ config/mep/mep.c(working copy)
@@ -6201,13 +6201,15
> At the risk of being naive: implement it. I'm not quite sure what
> you're looking for here?
Ok, time to ask for a hint. I started at get_best_mode(), adding a
TREE argument for the type, and worked my way out, adding arguments to
functions as needed to propogate the type information. It's g
> At the risk of being naive: implement it. I'm not quite sure what
> you're looking for here?
I'd rather have some confidence that the way I choose to implement it
would be acceptable to those who would be reviewing it ;-)
I'll give it a shot at the same point in the code where we call the
tar
> >> I think the ARM specification is pretty sensible, and would make a
> >> good cross-platform approach.
> >
> > Could you distill it for us?
>
> The relevant bits are from AAPCS \S 7.1.7.5, and quoted below.
I finally got the last of the feedback I needed from our customers,
and they agree
Thanks, committed.
> The OPTION is there because this was introduced for the option
> attribute. But the entry in the target structure is named
> can_inline_p, and the macro should be TARGET_CAN_INLINE_P. So the
> doc is the desired state, and the code is not.
How's this?
* targhooks.c (default_target_ca
The documentation says:
@deftypefn {Target Hook} bool TARGET_CAN_INLINE_P (tree @var{caller}, tree
@var{callee})
But the code says:
#ifndef TARGET_OPTION_CAN_INLINE_P
#define TARGET_OPTION_CAN_INLINE_P default_target_option_can_inline_p
#endif
#define TARGET_OPTION_HOOKS \
> You could file this in Bugzilla instead, with all required fields
> filled in (host, target, compiler revision number, etc), and test
> cases as text attachments ;-)
Ok. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40626
When compiled with -frename-registers, this test case produces invalid
code. Specifically, the cpadd4.h opcode clobbers $c1 but the cpsub2.h
assumes it still has the value "a" in it. Compiling with
-fno-rename-registers results in valid code.
I've attached the full testcase and before/after dum
> I thought I had sent you mail approving the changes 2 weeks ago.
> Perhaps I misremembered, or perhaps it got lost somewhere. All of
> my comments about the internals of the mep would be things to do if
> you desired, but as port maintainer, I don't see that we have to
> apply standards set for
> > The opcode swaps two register banks. 32 SETs total.
>
> Perhaps you can cheat by using larger modes. E.g., if it's a 32-bit
> machine, using DImode will cut the number of operands in half.
They're DImode already, but I did figure out a workaround that reduces
it to 16 SETs, so I'm all set.
> That sounds like an awkward insn.
The opcode swaps two register banks. 32 SETs total.
> It would be nice if genrecog at least checked for an out of range
> letter.
Or used "ch-'a' < 32" tests, but would that work with EBCDIC build
machines?
> Pending initial (technical) approval
Ping? Still waiting for technical approval from a global maintainer.
http://people.redhat.com/dj/mep/
genrecog uses strings to keep track of where it is, specifically,
digits and letters. I've got an insn that writes to more than 26
registers. Would switching to something bigger than [A-Z] be
difficult? Perhaps using Japanese letters instead of English? ;-)
Some progress... the scheduler is willing to schedule them together if
I define the SCHED_REORDER2 hook (just SCHED_REORDER was
insufficient), and always return the number of ready insns. In my
case, the VLIW packing restrictions are fully defined by a DFA; I
don't need to further restrict packin
> The problem may be in the dependency cost between the SET (insn 27)
> and the USE (insn 30) being >= 1. Have you tried using
> targetm.sched.adjust_cost() hook to set the cost of USE to 0?
It doesn't get called for those two insns.
> Anyway, this seems strange, the scheduler should just outpu
> Pending initial (technical) approval
So... Can I get a global maintainer to approve it?
I'm working on a VLIW coprocessor for MeP. One thing I noticed is
that sched2 won't bundle the function's RET with the insn that sets
the return value register, apparently because there's an intervening
USE of that register (insn 30 in the example below).
Is there any way around this? The retur
Thanks!
On xstormy16, when structures with variable-length arrays are passed
to functions (execute/20020412-1.c), it appears that they're passed by
reference (based on examining the stack), despite the port not
explicitly requesting that.
This causes a mis-match in the va_arg code, which assumes the arra
> I think the ARM specification is pretty sensible, and would make a
> good cross-platform approach.
Could you distill it for us? If it's acceptable to my two customers,
it would be a good starting point to define an API for the targets.
We seem to have dropped this discussion. I now have *two* customers
asking for this functionality. Can we pick it up again? We need to
decide:
1. If the functionality will be allowed in gcc at all
2. What info the target needs to be provided to make the choices it wants
3. What, if any, comm
Andrew Pinski writes:
> You could do what the rs6000 back-end does for the altivec builtins
> and resolve them while the parser is run (the SPU back-end does the
> same thing too). Yes there are opaque vector types, you just use
> build_opaque_vector_type instead of build_vector_type.
Thanks, I
Is there an opaque vector type? Something that can be assigned
to/from other vector types of the same size, without warning?
I'm working on a coprocessor which has separate SIMD arithmetic
operations for each data size, but only one SIMD logical operation for
all sizes. I.e. there's four ADD in
> Ian, thanks for reporting this. I'll investigate this more. It
> affects only ports using priority allocation (I know only one which
> is m32c). DJ just recently reported a reload failure problem on
> m32c. Probably that is because of this wrong code.
In checking through this code, I see th
> When you used verbose, did you pass --verbose within RUNTESTFLAGS?
Yes, I passed enough -v's to see what was happening. Odd. Well, if
you've proven it to yourself, that's good enough for me.
> On Thu, 2009-04-23 at 20:34 -0400, DJ Delorie wrote:
> > 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 double
> I'm convinced that if check_effective_target_xxx exists then it is
> called and the test directive works as intended.
Hmmm... how did you prove this? I tried putting verbose in them,
nothing printed. I tried reversing them, no change in test results.
> The fp-int-convert tests are meant to be correct independent of the sizes
> involved, so this change is inappropriate and may point to a bug
> elsewhere.
It did, I fixed it. Thanks for the insight.
> But it doesn't need to store it *exactly*; it only tests that the
> conversion reverses if PREC_OK (argument to TEST_I_F_VAL) is true, and
> TEST_I_F sets PREC_OK to what should be an appropriate value (based on the
> types involved, LDBL_MANT_DIG, etc.) in each case. The other tests are
>
The fp-int-convert-long-double test does this:
static volatile signed long long ivin, ivout;
static volatile long double fv1, fv2;
ivin = ((signed long long) (((unsigned long long) ~(unsigned long long) 0) >>
1));
fv1 = ((signed long long) (((unsigned long long) ~(unsigned long long) 0)
> 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 {
> > +
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?
*
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" "" { targe
> We can test for the 'this cannot possibly work' cases, i.e. where there is
> no suitable register at all. That would address the problems you have
> originally identified for the m32c.
Sounds good to me ;-)
> > 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
> 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 an
> 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 ab
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 th
> 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 fi
> 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?
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 -vers
> 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
> impleme
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
> 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
DJGPP has its own , at least in DJGPP 2.04.
> 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 i
Richard Guenther 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 readin
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 d
> 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 p
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 t
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 could
> 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 con
> 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'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 = t
> OK.
Thanks, committed.
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]);
+ fo
> 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
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 (argv[0
> 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
> 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.
> 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 des
> > 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 0x08
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(
Never mind, I figured this one out.
Ping?
http://gcc.gnu.org/ml/gcc/2008-10/msg00491.html
> 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_assig
> 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
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 ind
> 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-bran
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) or
> 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 b
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,
assum
> 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 becau
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 i
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-assemble
> 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.
> I thought something like that was already done but I couldn't find it
> right now. Is it a problem? If so, we should certainly do this.
I see it done in other places, but not scanasm. How's this?
2008-10-23 DJ Delorie <[EMAIL PROTECTED]>
* lib/scanasm.exp:
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
201 - 300 of 742 matches
Mail list logo
